by Charly Vega

查理·維加(Charly Vega)

為什么Docker對初創企業有意義 (Why Docker makes sense for startups)

Docker is becoming the standard to develop and run containerized applications.

Docker正在成為開發和運行容器化應用程序的標準。

Long ago, this piece of technology might have made sense to system administrator and PaaS (Platform as a Service) providers. But we’ve been hearing rather little from startups about their Docker adoption. Particularly the 1–to-10-employee-strong ones. This is an impression that somewhat correlates with Datadog HQ’s recent research:

很久以前，這項技術對于系統管理員和PaaS(平臺即服務)提供商來說是有意義的。但是，我們從初創公司那里聽到的關于采用Docker的信息很少。特別是1至10名員工的公司。這種印象與Datadog HQ的最新研究有些相關：

In case you’re unsure if it’s worth the trouble, we thought we’d reveal how much adopting a container-friendly architecture has helped our startup. And why you might take Docker for a spin if you haven’t yet.

如果您不確定是否值得麻煩，我們認為我們應該揭示采用容器友好的體系結構對我們的創業有多大幫助。以及為什么還不帶Docker的原因。

開發經驗 (The Development Experience)

If you work in a small two pizza startup, there’s a high chance people in your team are a multidisciplinary lot. Once projects are no longer siloed, you’ll receive a warm welcome into development environment hell.

如果您在一家只有兩個比薩餅店的小型公司工作，那么您團隊中的人很有可能是多學科的。一旦項目不再孤島，您將受到開發環境的熱烈歡迎。

Consider a simple scenario of a front-end engineer needing a not-yet-in-production API from a back-end. You could overcome this by making do with mocked data, or setting up staging environments. These are great. But nothing beats the agility of running integrations against the back-end code itself.

考慮一個簡單的場景，前端工程師需要一個后端尚未生產的API。您可以通過處理模擬數據或設置暫存環境來克服此問題。這些很棒。但是，沒有什么比在后端代碼本身上運行集成的敏捷性更好的了。

Tools like docker-compose did wonders for us. All a newcomer has to do is install a single thing. One invocation of docker-compose will have Docker setup everything for you so you can jump straight back into coding.

docker-compose之類的工具為我們帶來了奇跡。新手要做的就是安裝一件事。調用docker-compose將使Docker為您設置所有內容，因此您可以直接跳回編碼。

The declarative nature of these tools provides a simple description of how runtime components talk to each other. This makes reasoning about your top-level architecture all the easier.

這些工具的聲明性性質提供了有關運行時組件如何相互通信的簡單描述。這使您對頂層架構的推理變得更加容易。

可移植性 (Portability)

As well as being useful in development, Docker also brought us simplicity when packaging our code for production. This is because it makes development and production environments all the more symmetric. That is a point made by 12factor’s dev/prod parity.

Docker不僅在開發中有用，而且在打包生產代碼時也為我們帶來了簡化。這是因為它使開發和生產環境更加對稱。這就是12factor的dev / prod奇偶性提出的觀點。

We have great language-specific tools like rbenv (Ruby version management) and nvm (Node Version Manager). They safeguard us from things like runtime version mismatches. You would outpace their capabilities if your code depended on some obscure native binaries or a particular file system structure.

我們有特定于語言的出色工具，例如rbenv (Ruby版本管理)和nvm (節點版本管理器)。它們可以保護我們免受運行時版本不匹配之類的問題的影響。如果您的代碼依賴于某些晦澀的本機二進制文件或特定的文件系統結構，那么您將超越它們的功能。

This is where containers go the extra mile. They allow us to package our application together with exactly the kind of environment we need.

這是集裝箱多走一趟的地方。它們使我們能夠將應用程序與所需的確切環境打包在一起。

This same portability shines on hybrid-cloud setups. This point I need not tell you much more than our story migrating our cloud.

混合云設置也具有相同的可移植性。關于這一點，除了我們遷移云的故事之外，我不需要告訴您太多其他信息。

We were unhappy with our cloud provider’s poor reliability and support at the time. We decided to make the switch to the king of IaaS (Infrastructure as a Service), AWS (Amazon Web Services).

我們對我們的云提供商當時糟糕的可靠性和支持感到不滿。我們決定改用IaaS(基礎設施即服務)之王 AWS(亞馬遜網絡服務)。

We foresaw that this migration would take place sooner than later. So, we’d been migrating our applications to run on Docker for a few months by then. When the time came to say farewell to our old cloud, the whole transition process took little more than a couple of days.

我們預見到，這種遷移遲早會發生。因此，到那時為止，我們已經將應用程序遷移到Docker上運行了幾個月。是時候告別我們的舊云了，整個過渡過程只花了幾天的時間。

Such a drastic transition could be considered a rare event. But I’ve never found erring on the side of flexibility to be problematic.

這種劇烈的過渡可以認為是罕見的事件。但是我從來沒有發現在靈活性方面犯了錯誤。

It’s worth noting that it’s not all about apps. Hosted turnkey solutions may solve cross-cutting concerns such as monitoring and logging. Yet these can be replaced with containerized open-source solutions that are easier to set up, and leave you in a better position to avoid cloud jail.

值得注意的是，這不僅與應用有關。托管的統包解決方案可以解決跨領域的問題，例如監視和日志記錄。但是，可以用更易于設置的容器化開源解決方案代替這些解決方案，并使您處于更好的位置以避免云監獄。

編排 (Orchestration)

Whether you need an orchestration system or not is not the right question. It’s whether you want to have it be self-managed or to be the human orchestrator fixing a downtime at 3 AM.

是否需要編排系統不是正確的問題。您是要對其進行自我管理，還是要讓人類協調器解決凌晨3點的停機問題。

The analogy is having to care for of a lot of moving parts. Software systems become more complex and fragmented at runtime. They become fragile when faced with network partitioning.

類比是要照顧很多活動部件。軟件系統在運行時變得更加復雜和分散。當面對網絡分區時，它們變得脆弱。

Now, containers on their own don’t solve this problem — quite the opposite in fact. Their ephemeral nature makes your system ever so dynamic. This makes it difficult to set dependencies in stone at deploy time.

現在，單獨使用容器并不能解決這個問題-實際上恰恰相反。它們的短暫特性使您的系統變得如此動態。這使得在部署時很難在石頭上設置依賴關系。

Scale to a clustered infrastructure, and the situation worsens. It reaches the point of never being certain of where your processes might end up running. This makes locating and addressing them all the more difficult. But it is the need to embrace this nature that gives way to a whole host of solutions.

擴展到集群基礎架構，情況會惡化。它達到了永遠無法確定進程最終在何處運行的地步。這使得查找和解決這些問題變得更加困難。但是有必要擁??抱這種性質，讓整個解決方案讓步。

We tried several clustering systems. These included Google’s Kubernetes, Mesosphere’s Marathon and Hashicorp’s Nomad.

我們嘗試了幾種集群系統。其中包括Google的Kubernetes，Mesosphere的馬拉松和Hashicorp的Nomad。

We settled on Docker’s own Docker Swarm for most of our deployments using the simple Docker for AWS CloudFormation template.

我們使用簡單的Docker for AWS CloudFormation 模板為大多數部署選擇了Docker自己的Docker Swarm 。

First declaratively express the desired state of your system about the services it should run. Then Swarm will constantly monitor the actual state of your containers. It will reconcile the desired state by rescheduling the workload to other nodes in the event of a node failure. It will also self-heal the cluster by re-provisioning new servers should a node become unrecoverable.

首先以聲明方式表達您的系統有關其應運行的服務的期望狀態。然后，Swarm將不斷監視容器的實際狀態。如果發生節點故障，它將通過將工作負載重新安排到其他節點來協調期望的狀態。如果節點變得不可恢復，它將通過重新配置新服務器來自我修復群集。

Provisioning your own container cluster may escape your needs. However, new Caas (Containers-as-a-Service) platforms are popping up, often at no extra cost than your underlying infrastructure usage.

調配您自己的容器集群可以滿足您的需求。但是，正在彈出新的Caas (容器即服務)平臺，通常不需要付出比基礎架構使用額外的費用。

You’ll find service discovery, load-balancing, software-defined networks, persistent storage, task scheduling and RAFT consensus. This guarantees a scary but fun ride through a whirlpool of cool-sounding jargon.

您會發現服務發現，負載平衡，軟件定義的網絡，持久性存儲，任務調度和RAFT共識。這樣可以確保您在聽起來冷酷而行話的漩渦中驚恐而有趣。

減少基礎設施賬單 (Cutting down your infrastructure bill)

You don’t need yet another article on “How we shaved our server costs by {{ rand_amount }} after switching to {{ rand_language }}”. So I’ll try to come up with something different.

您無需再發表另一篇文章“我們如何通過以下方式節省服務器成本 {{ rand_amount }} 切換到 {{ rand_language }} ”。 S 0我會盡力拿出不同的東西。

Microservices are all the rage these days. We’ve come to split our applications into several different services here at Beta Labs. This approach allows us to mix and match different languages and frameworks. That keeps us free to work with the best tool for the job every time.

如今，微服務風靡一時。在Beta Labs，我們已經將我們的應用程序分為幾個不同的服務。這種方法使我們可以混合和匹配不同的語言和框架。這樣一來，我們就可以每次使用最佳工具自由地工作。

Please bear with me. I’m trying to make a case for microservices in 10 words or less.

請多多包涵。我正在嘗試用10個字以內的詞來說明微服務。

Following 12factor’s “One codebase, many deploys”, this means each service should get deployed as its own application in PaaS parlance. This happens to be how most PaaS pricing models scale.

遵循12factor的“ 一個代碼庫，很多部署” ，這意味著每個服務都應按照PaaS的話作為自己的應用程序進行部署。這恰好是大多數PaaS定價模型的擴展方式。

Let’s throw some numbers at it. Running an available setup for a Ruby app in Heroku means running at least two web Standard 1X dynos. This will set you back $50 per month for a total of 1 application constrained to 512MB of memory.

讓我們扔一些數字。在Heroku中為Ruby應用程序運行可用的設置意味著至少運行兩個Web Standard 1X dynos 。這樣一來，您每月只需花費$ 50，即可獲得總共1個應用程序，并限制為512MB內存。

That’s $50 GB per month for front-end services. Add one worker dyno for simple background processing, and that’s another $25 per month.

前端服務每月需要50 GB。再加上一個工人dyno進行簡單的后臺處理，那又是每月25美元。

You may also want a couple of lightweight back-end services, such as a piece of middleware or broker with custom logic, which could make do with 1 instance each. You could go over the $100 per month mark with ease.

您可能還需要一些輕量級的后端服務，例如一塊具有自定義邏輯的中間件或代理，它們可以分別處理一個實例。您可以輕松地超過每月100美元的大關。

That’s before we start talking add-ons. Add a further $30 per month for a basic Redis and a PostgreSQL instance. Heroku’s Logplex is only for streaming. So, if you want to keep your logs for a bit longer, you’ll also want to add a logging service that can be shared across apps.

那是在我們開始談論附加組件之前。每月再為基本Redis和PostgreSQL實例再加30美元。 Heroku的Logplex僅用于流式傳輸。因此，如果您希望將日志保留更長的時間，則還需要添加一個可以在應用程序之間共享的日志服務。

Let’s see how we could do better.

讓我們看看如何做得更好。

Let’s borrow from Martin Fowler’s description of microservices. The combined use of containers with a clustering system provides a beautiful and fitting platform for dynamically scaling your services.

讓我們借鑒Martin Fowler對微服務的描述。容器與群集系統的組合使用為動態擴展服務提供了一個漂亮而合適的平臺。

Our containers get placed on nodes with the most available resources. All nodes share an internal SDN (Software Defined Network). So, your services can talk to each other without leaving the cluster.

我們的容器被放置在具有最多可用資源的節點上。所有節點共享一個內部SDN (軟件定義網絡)。因此，您的服務可以彼此對話，而無需離開群集。

Let’s go back to our example from earlier. Such a system would fit on a 3-node, t2.micro-based Docker Swarm cluster, which clocks in at roughly $50 per month. You could have a total of 3GB of memory. You may even have extra headroom to run your own containerized Redis instances, if you feel so daring.

讓我們回到前面的例子。這樣的系統將適合基于3節點，基于t2.micro的Docker Swarm集群，該集群的每月費用約為50美元。您總共可能有3GB的內存。如果您感到膽怯，甚至可能還有額外的空間來運行自己的容器化Redis實例。

Heroku’s dynos are a lot more gifted in the CPU department with 8 virtual cores against 1. But unless you’re running on a language with native threads, a multi-process-per-dyno setup could make you find 512MB of memory insufficient fast. Also, it won’t make much of a difference if your workload is I/O intensive.

Heroku的dynos在CPU部門擁有8個虛擬內核(相對于1個)的功能更為豐富。但是，除非您使用具有本機線程的語言運行，否則每個dyno進程的多進程設置可能會使您很快發現512MB內存不足。另外，如果您的工作量是I / O密集型的，那也不會有太大的不同。

Don’t get me wrong, as far as making DevOps a non-issue goes, it doesn’t get much better than Heroku . I’m not suggesting you or anyone in your team should go it alone and spend nights learning how to get high availability setups right in PostgreSQL. We’d be comparing apples to oranges.

不要誤會我的意思，就讓DevOps成為毫無問題的事情而言，它并沒有比Heroku更好。我并不是建議您或團隊中的任何人都應該獨自一人，花一些時間學習如何在PostgreSQL中獲得高可用性設置。我們將比較蘋果和桔子。

I do nonetheless feel it’s important to point out you are paying extra for all that reliability and ease of use. With that you can judge for yourself what is actually worth the price and what you can get done yourself.

我仍然感覺指出你額外付出的一切可靠性和易用性是非常重要的。這樣一來，您就可以自己判斷哪些是真正值得的價格，以及您自己可以完成什么。

Oh, while we’re at it, don’t forget you can run your Docker containers in Heroku.

哦，在此期間，請不要忘記您可以在Heroku中運行Docker容器。

固有安全性 (Inherent security)

This argument won’t hold much water when comparing the Docker platform to a PaaS. Yet, you’ll find you reduce the risk of certain vulnerabilities when compared to your Ubuntu box running multiple apps .

在將Docker平臺與PaaS進行比較時，該論據沒有多大用處。但是，與運行多個應用程序的Ubuntu盒相比，您會發現減少某些漏洞的風險。

Why is it any different? Enter Linux containers. An intriguing concept once presented by the likes of Heroku when reading through their guides now sits at the very core of Docker. And with them comes a much appreciated security feature: isolation.

為什么有什么不同？輸入Linux容器。 Heroku之類的人曾經在閱讀其指南時提出過一個有趣的概念，如今它已成為Docker的核心。隨之而來的是一個廣受歡迎的安全功能：隔離。

Take the worst case scenario of someone executing code remotely inside your server. Sounding too far-fetched? Check out ImageTragick. Applications tend to have a one-to-one relationship with containers. You should be able to isolate the damage to that application’s domain, keeping whatever else you choose to run on your hosts safe.

以最壞的情況為例，有人在您的服務器內部遠程執行代碼。聽起來太牽強了嗎？查看ImageTragick 。應用程序往往與容器具有一對一的關系。您應該能夠隔離對該應用程序域造成的損害，并確保您選擇在主機上運行的所有其他內容都安全。

This is a similar characteristic to what VMs (Virtual Machines) have provided for quite some time. But they’ve always had the slightly more rigid nature of longer boot-up and provisioning times, plus the overhead of running full operating systems.

這與VM( 虛擬機 )已經提供了相當長的一段時間類似。但是，它們始終具有更長的啟動和供應時間的剛性，而運行完整的操作系統的開銷卻更大。

One could almost be forgiven for giving them longer lifecycles and treating them more like Pets than Cattle, but running more apps in this way leads to the potential compromise of more secrets.

給予它們更長的生命周期并像對待Cat而不是Cattle那樣對待它們，幾乎可以原諒，但是以這種方式運行更多的應用程序可能會泄露更多秘密。

While running containerized applications lowers this risk, this is not to say you’ll be immune to developer malpractice. You wouldn’t want to compromise access to the host’s Docker daemon, for instance. But all in all, containerized environments do help in reducing your attack surface as an organization.

盡管運行容器化應用程序可以降低這種風險，但這并不是說您可以避免開發人員的不當行為。例如，您不想破壞對主機的Docker守護程序的訪問。但是總而言之，容器化環境確實有助于減少組織的攻擊面。

Just be cautious and don’t keep your images public (cheap shot, I know).

只是要小心，不要讓圖像公開(我知道便宜的照片)。

你感覺像 (You feel like it)

Okay this might be completely biased by what our inner geeks find to be motivating, but…

好吧，這可能完全被我們內心的極客所激發的偏頗，但是……

We can’t say we haven’t had to work around some rough edges early on. I have to admit to being drawn to hipster tools rather easily.

我們不能說我們不必在早期就解決一些粗糙的問題。我必須承認相當容易被時髦工具吸引。

One should be able to add new tools to the arsenal if one feels it will contribute to one’s happiness as an engineer . Wasn’t that part of the whole selling point for startups in the first place?

如果人們認為這將有助于工程師的幸福，那么人們就應該能夠向其添加新工具。首先，這不是初創企業整個賣點的一部分嗎？

Should you decide to go Docker-less, you’ll almost certainly find that being a little container-savvy will be handy in years to come.

如果您決定不使用Docker，那么幾乎可以肯定的是，在以后的幾年中，精通容器會很方便。

結論 (Conclusion)

So, was it a silky-smooth road to containerized paradise? Hell, no.

那么，這是通往貨代天堂的順滑之路嗎？一定不行。

Could we have settled with more stable tools until Docker’s rough edges were fully polished? Probably.

在Docker的粗糙邊緣完全磨光之前，我們是否可以使用更穩定的工具？大概。

Would we have completely failed as a startup if we hadn’t adopted Docker? Most definitely not.

如果我們不采用Docker，我們會在創業中徹底失敗嗎？絕對不是。

Would we invest in adopting containers again? A resounding yes is in order.

我們會再次投資采用容器嗎？肯定的回答是正確的 。

These points are far from being exclusive to startups. I’d even say company size is almost irrelevant. Rest assured, my endorsement won’t jeopardize Docker’s reputation among the corporate types either way.

這些要點遠非新興公司所獨有。我什至會說公司規模幾乎無關緊要。放心，我的認可不會以任何方式損害Docker在企業類型中的聲譽。

We are not advocating that Docker is the only way to solve these timeless problems. And we haven’t talked much about its downfalls.

我們并不主張Docker是解決這些永恒問題的唯一方法。而且我們還沒有談論它的失敗。

But for now, it does remain the closest one-stop shop solution to all the commonplace problems we presented above.

但就目前而言，它確實仍然是我們上面介紹的所有常見問題最接近的一站式解決方案。

All in all, it’s pretty safe to say containers are here to stay — oh wait, did you hear about this whole serverless thing? Come to think of it, containers are so old-fashioned…

總而言之，可以肯定地說容器將保留在這里-哦，等等，您是否聽說過整個無服務器事件？想一想，容器太過老式了……

Thanks for reading! Be sure to leave a comment if you have any thoughts or questions. If you found this article helpful, some claps would mean a lot!

謝謝閱讀！如果您有任何想法或疑問，請務必發表評論。如果您發現這篇文章對您有所幫助，那么鼓掌就意味著很多！