docker 部署生产_Docker如何简化生产部署

docker 部署生产

最重要的是，现代发展的主要重点通常基于三个中心概念：

效率
可靠性
重复性

但是，当现代应用程序体系结构经常同时具有一系列变量而又在多个部署环境中进一步恶化时，您如何实现这三个目标呢？

为了实现这些目标，您需要一种能够消除设计，开发和部署过程中大部分可变性的技术。

对我来说，Docker是那种技术。尤其是如果您希望将部署从一系列测试和审查环境中的开发阶段简化到生产阶段时，尤其如此。

这听起来似乎是一个重大主张，但过去其他技术一直在争论，但未能兑现。但是我相信Docker是不同的。在本文中，我提出了三个关键原因，这是简化生产的关键。让我们开始。

1 –支持打包的应用程序

几个月前，当我第一次来到Docker时，这就是给我最深刻的印象。 Docker的中心概念是它允许您对应用程序进行容器化。或者，它允许您打包应用程序并进行部署。

当您的应用程序是单个二进制文件（例如，用Go编写的软件或Java JAR文件）时，此假设最有效。但是对于使用动态语言（例如PHP，Python和Ruby）的应用程序，它同样可以很好地工作。

使用Docker时，应用程序不必是单个二进制文件。它们可以合并n层体系结构，该体系结构由运行时，Web服务器和许多其他服务（例如数据库，缓存和排队服务器）组成。

为了说明我的意思，请看下面的图片。它代表一个基本PHP应用程序（我最熟悉的应用程序），其中包含三个组件：

一个PHP运行时，其中包含应用程序代码
Web服务器（NGINX，Apache，Lighttpd等）
数据源（MariaDb，PostgreSQL，SQLite等）

但是，如果我们的应用程序编写正确，那么它将不依赖于特定的数据库供应商，也不依赖于我提到的任何其他服务。它将可能使用框架和一组开发实践，这些框架和开发实践将抽象化与任何给定服务的特定交互。

在这种情况下，Docker非常适合。我们可以打包应用程序，并将其与所需的所有其他服务一起放入容器配置中。可以根据需要在开发，登台，测试和生产之间进行更改的服务。

为了将其放在适当的上下文中，请使用以下简单的Dockerfile。这会将我一直在研究的假设PHP应用程序打包到一个自定义Docker容器中：

FROM php:7.0-fpm
EXPOSE 9000RUN mkdir -p /var/www/html
COPY . /var/www/html
WORKDIR /var/www/htmlRUN docker-php-ext-install pdo_mysql \&& docker-php-ext-install jsonRUN apt-get update \&& apt-get --yes --force-yes install git \&& apt-get --yes --force-yes install zip \&& apt-get --yes --force-yes install unzipRUN ./composer.phar install

从上到下进行研究，我们发现它是基于正式的Docker PHP 7 FPM映像开始的容器，因为代码库需要最低版本PHP 7.0。

然后，在容器内，它创建项目的目录根目录，在其中复制代码，并将其设置为工作目录。

之后，它将提供两个PHP扩展以及三个二进制文件，这是应用程序运行所必需的。

然后，它使用PHP的包管理器Composer来包含代码库所需的第三方库依赖关系。在应用程序的composer.json程序包配置文件中标识的依赖项。

无论是第一次，第十次，百分之一甚至百万分之一的构建，构建容器的步骤都是相同的。而且，它们非常清晰，非常精确。他们还有简洁的好处。对于其他方法，我无法说。

这种方法从方程中消除了巨大的可变性。无论是用于开发（或任何其他环境）中PHP运行时，都将是相同的。它将基于相同版本PHP，具有相同的扩展名（在相同的主要版本，次要版本和点发行版本），并且具有所需的所有其他二进制文件，并且版本相同。

正如我最近在Codeship博客上所说的那样，这大大降低了技术风险，并增强了对产品质量的信心。

诸如“它可以在我的计算机上工作”之类的懒惰论点实际上是不可能的。当一个环境与另一个环境不存在差异时，构建如何因不同环境而失败？

在这里，我将请我的朋友和PHP社区的一位Docker专家Chris Tankersley说：

由于每个构建都捆绑到一个映像[容器]中，因此可以确保每次构建都进入服务器时，它都是准确而完整的。

Docker Glasgow的 David McKay还要说的是：

因为您已经构建了工件，所以您可以确信，运行测试所针对的就是部署的对象。

鉴于此，除非容器配置不完整，否则不会丢失任何内容。但是，这应该已经被接受。

！新的号召性用语

2 –支持在多个位置“一次构建，多次部署”

假设我们在上一节中描述的构建Docker容器是我们连续部署过程的一部分，那么它将在每次提交或合并请求合并时运行并创建新版本的应用程序容器。

创建容器后，可以将其部署到任何环境中，无论是经过测试，登台，生产还是其他任何环境。

构建步骤可能会随着时间而改变；他们可能会变得更复杂，但可能不会。但是，鉴于构建说明的清晰性，它的重复非常简单，这使其非常可预测和可靠。

建成后，它现在是一个独立的组件，可以部署到任何地方。如果适用，它可以存储在官方Docker Hub中。或者，它可以存储在您的组织维护的自定义Docker容器存储库中。无论如何，一旦到达那里，就可以将其拉入任何位置的容器设置中。

而且，如果正确构建，该应用程序将不会在代码库中存储任何配置或凭据。相反，它们将作为环境变量存在于环境中。完成此操作后，变量可以被容器接收并传递给应用程序。

是否想在开发中使用本地Redis容器（如果愿意，可以使用基于文件系统的缓存），但是在生产中，您想使用Redis Cloud之类的远程服务？没问题在相应的环境中，更改环境变量并监视应用程序以使用不同的服务设置。

从应用程序的角度来看，无论组合，位置，大小和复杂性如何，它都使用位于某处的远程服务。只要服务是可访问的并且应做的事，您的应用程序就可以运行。

考虑到所有这些，只要测试通过，就可以构建和存储包含应用程序的容器以供以后使用。然后可以从那里检索它并将其部署到所需的任何环境中。

考虑一下出现的简化。

作为另一位Docker专家， Chris Fidao表示：

这履行了虚拟机向我们承诺的承诺，但未能执行

3 –支持轻松回滚

尽管部署的重点通常是部署下一个版本，但可能会出错。实际上没关系-时不时地。

有时，尽管我们在流程和测试过程中做出了最大努力，但错误还是会通过或发生，但出乎意料之外。

在这种情况下，即使应用程序的功能有所减少，您也必须退出上一个版本，回到应用程序按预期工作的时候（希望是上个版本）。

好吧，这取决于您的Docker容器的构建和存储方式，当然可以使用。现在，据我所知，Docker并未立即提供此类功能。但是您应该能够很容易地实现它。

在简单的设置中，新创建的内部版本将覆盖之前的内部版本，从而仅生成应用程序容器的一个副本。但是您的连续部署服务可以设置为不同的方式。相反，它可以为任何数量的发行版创建和维护容器。

假设构建管道至少创建并存储了最后五个构建，并将它们存储在容器存储库中。如果当前构建失败，则可以使用先前的发行版依次部署容器，直到应用程序再次运行。

正如我所说，我没有要指出的具体实现。但是，除了设置现有的CI管道之外，要使它可用也不会花费很多工作。

如果时间和费用是一个问题，我并不是说不应该这样，那就考虑一下这会减少的成本，以及收入下降以及服务意外中断对声誉的影响。

结论

我相信Docker可以简化生产部署的三个坚实原因：

它支持打包的应用程序。
它支持在多个位置“一次构建，多次部署”。
它支持简单的回滚。

通过使用Docker（一种允许您对应用程序进行容器化的工具），您可以简化从开发到生产的所有环境中应用程序的部署。

如果您尚未将Docker视为开发工具链的一部分，那么我希望这会激发您这样做的动力。这是一个有很多优点的工具，而且只会变得越来越好。

翻译自: https://www.javacodegeeks.com/2016/12/docker-streamlines-production-deployments.html

docker 部署生产