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!

谢谢阅读！如果您有任何想法或疑问，请务必发表评论。如果您发现这篇文章对您有所帮助，那么鼓掌就意味着很多！