一个“小白”眼中的容器

容器的诞生改变了部署和托管 Web 应用程序的方式。在开始阅读 Docker 入门指南之前，我就已知晓，但除此之外，我一无所知。直到开始使用容器之后，我才意识到这个容器的潜力所在，它远比使用虚拟机来托管 REST API 要强大得多。让我们来谈谈容器如何让你的生活变得更美好，即使你已经发誓永远不会将你宝贵的宠物应用程序部署在除裸机之外的任何环境中。以下是我在过去六个月中发现的一些不那么正统的容器使用方法。

将容器作为构建 / 部署服务器

我的容器之旅就是从这里开始的。

我喜欢 DevOps。在我职业生涯的某个阶段，我遇见了 TeamCity 和 Octopus Deploy，这个充满活力的组合让我感受到了 CI/CD 的闪亮魔力。我是我们团队中唯一一个愿意花时间写脚本、维护开发服务器和搭建新环境的人，这些工作对我来说非常有趣。唯一让我抓狂的是我们的基础设施是一堆物理服务器和 Azure VM，而我通常没有它们的访问权限。

不久前，我参与了一个 100％的云原生新项目。我们达成的第一个共识是采用基础设施即代码模式，并尽可能实现 CI/CD 的最佳实践。我们都不想被公司内部网络的界限所束缚，于是决定所有的 Ops 技术也应该是基于云的“XX 即服务”，这样我们就可以随时随访问 Docker、Git 和 NPM 存储库。于是我卷起袖子，开始寻找构建服务器的最佳方案，这个时候我的脑子里冒出了一个恼人的想法：“我该如何在没有服务器的情况下构建出一个构建服务器”？我最担心的是，如果无法在线创建理想的环境，我将无法控制局面，构建、交付和审核工件的方式也将受到限制。有那么一刻，我陷入了黑暗之中。

但我并没有惊慌失措。首先，我知道我们需要一个基于云的版本控制系统，尽管我对 GitLab 青睐有加，但经过讨论，我们还是决定使用 Atlassian 的 Bitbucket（出于技术之外的一些原因）。我知道 GitLab 和 GitHub 都提供了 CI/CD 方面的产品，于是我看了一下 Bitbucket，然后发现了一个叫作 Bitbucket 管道的东西。

管道的概念是这样的：你提供一系列命令以及说明为什么以及何时运行这些命令的规则——这些就是所谓的管道。一个管道可能包含从构建和运行单元测试到生产环境部署和验证部署的一系列操作。管道中包含的是 bash shell 命令，这些命令将在 Docker 容器中执行。过程如下：

这是我第一次学会如何在现实生活中使用容器。我个人认为，这种能够在云端拥有按需构建和部署的服务器的想法是非常强大的，而且我觉得没有什么理由不将它应用于所有的云部署。对我来说，这种方法的主要优点如下：

1. 如果你使用 Dockerfile 创建镜像，就可以轻松跟踪 CI/CD 基础设施的变更。由于已经采用基础设施即代码，你可以将它们提交到版本控制系统中，这样就可以更容易地找到错误，精确定位改进的部分，并将知识分享给团队成员。
2. 修改 Dockerfile 文件比修改虚拟机要容易得多。
3. 不需要维护物理基础设施，我想这是一个很明显的优势。
4. 成本效益。在 Bitbucket 高级订阅和工件存储上花些钱是合情合理的，因为这样就不需要花钱在硬件、许可费用上，Dev/Ops 也不需要花时间将这些东西连接起来，并在发生故障时修复故障。

虽然我只提到了 Atlassian 的管道，但还有其他产品可选择，例如 Jenkins 或 GitLab CI。Bitbucket 的入门级账户是免费的，但如果因为某些原因你不喜欢 Atlassian，可以尝试竞争对手的产品，但我相信这些产品都大同小异。

将容器作为开发工作区

大多数开发人员的机器上都安装了很多开发工具。有时候我们甚至会忘了之前已经装过同样的工具，直到再次安装时被告知要安装的版本与已安装的版本产生冲突。更糟糕的是，当我们升级或更换机器后，需要再次安装所有的工具。大多数情况下，我们不停在寻找需要用到的工具、库和插件，而且有时候我们会陷入试错的泥潭。比如：“装上这个，装上那个，看看可不可以成功构建项目。哦，不行！还缺了什么？啊，为什么我不干脆包块偏远的瓜田做个农民？！”

当公司不断有新开发人员加入时，这将变成一个更大的问题。他们都要经历这个繁琐的过程，实在是太浪费时间了。如果我们能够在弹指挥手间快速配置和分发封装好的开发工作区，一切都会变得更加容易。使用容器就可以搞定这一切。但是，一篇博文不足以完整地涵盖这个主题，所以请参看 YouTube 视频： https://youtu.be/vE1iDPx6-Ok 。它差不多两个小时，但完全值得一看。

我给这个过程画了一张有意思的插图。

当然，这个概念并不适合所有人。你可能需要在将哪些东西保留在机器上和使用容器运行哪些东西之间找到折衷。但不要忘了，软件开发就是要不断地寻找折衷方案！

将容器作为“隔离的工作区模块”

我必须承认，尽管我计划实现一个类似于视频中描述的解决方案，但还没有这么去做。一方面是因为我有点懒，一方面是因为没有新开发人员需要我这么去做。不过没关系，最重要的是，它已经成为我灵感的源泉。

我现在仍然没有一个包含了所有工具和基础设施的 Docker 镜像。不过，我还是创建了一系列包含 AWS CLI、无服务器等内容的镜像，因为我不想将这些东西直接安装到我的机器上。我还将我的应用程序依赖的各种服务器都放进容器中，例如 PostrgreSQL、Redis、ES 等。

尽管这种方式不如上一节中提到的完全自动化解决方案那样高效，但它仍然有一些明显的好处：

1. 更干净的系统——容器中的应用程序都被隔离在当前容器内，不会给宿主系统带来任何副作用。
2. 因为我的容器使用相同的命令运行，可以运行在带有 Linux/Unix shell 的任何机器上，所以还是具备了一定的可移植性。
3. 自动化的潜力。我可以创建一些 shell 脚本将不同的容器捆绑在一起。例如，只用一个命令就可以启动和停止 Redis 服务器、MySql 服务器和 Koa 应用程序。
4. 使用管道镜像在本地构建项目，这样就可以确保在本地和在“构建服务器”上构建工件的方式是完全相同的。我还可以为 Docker 镜像添加标签，并对它们进行版本化，以确保每次构建代码的某个版本时都能获得相同的结果。
5. 能够测试新的东西或有风险的东西。关于 IT 卫生（hygiene），有两则有意思的轶事。首先是一个关于俄罗斯系统管理员的故事。这个管理员非常偏执，一定要在一个特殊的虚拟机中打开所有的电子邮件附件。另一个是两年前我看到的一个推文。一位博主（也是一名安全研究员）发布了一个 shell 脚本，并声称这个脚本可以播放一些令人咂舌的 ASCII 动画，但实际上是将僵尸网络客户端下载到受害者的机器上。在几天的时间内，这个人就拥有了数万个僵尸网络客户端。好在这只是一次练习，旨在向人们展示来自网络的随机代码有多危险。所以我的观点是，虽然我们可能不像那个俄罗斯系统管理员那样偏执和谨慎，但仍然可以使用隔离容器来试验新事物——无论它们带有多大的潜在风险。

我不得不说，我很遗憾没有及早学习有关 Docker 的基础知识，而是直接开始以这种方式使用容器——比如我的宿主系统中的独立工作区。但这绝对可以帮我更好地组织我的工作区，最重要的是，它帮我节省了很多时间。

下面是我用来构建包含无服务器框架、Newman、localstack 和 AWS CLI 的镜像的 Dockerfile 文件示例，我用它在本地运行无服务器项目。最后一行是 shell 命令，用于在交互模式下运行这个镜像的容器实例（假设镜像叫作“my-dev-image-yo”）。

FROM amazonlinux:latest
 
RUN curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.8/install.sh | bash
RUN export NVM_DIR="$HOME/.nvm" && [ -s "$NVM_DIR/nvm.sh" ] \
    && \. "$NVM_DIR/nvm.sh" && [ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion" \
    && nvm install v6.10.0 \
    && npm install serverless -g \
    && npm install newman -g \
    && npm install serverless-localstack -g
    
# Installing pip
RUN yum install -y python-pip
RUN yum install -y python-setuptools
RUN easy_install-2.6 pip
RUN pip install awscli-local
 
RUN echo "All done"
 
# Run with docker run --rm -v /git:/git -it my-dev-image-yo

结论

如果你一直在问自己是否应该开始花费宝贵的时间来学习容器，我的答案是“是”。你绝对应该这么做。如果你的公司坚持使用 COBOL 和基于 Teletype 的系统，你掌握的 Docker 技能仍然能够派上用场。

Docker 的官方入门指南是一个很好的着手点，不过也不要忘了上面提到的视频。 Docker 现在拥有庞大且不断增长的社区，所以，如果你通过谷歌搜索“如何在 Docker 容器中运行 XX”，搜索结果一定不会让你失望。

英文原文： https://itnext.io/containers-as-i-didnt-know-them-67cd4eaf3739

感谢张婵对本文的审校。