docker持续交付_与Docker的持续集成和交付

docker持续交付

持续交付就是通过在短时间内生产可靠的软件来降低风险并更快地交付价值。 正如Martin Fowler所说 ，您实际上在以下情况下会连续交付：

• 您的软件可以在其整个生命周期内进行部署。
• 您的团队优先考虑使软件可部署而不是使用新功能。
• 每当有人对其进行更改时，任何人都可以获取有关其系统生产准备情况的快速，自动化的反馈。
• 您可以按需将任何版本的软件执行按钮部署到任何环境。

软件的容器化使我们可以进一步改进此过程。 最大的改进是速度和抽象水平，这些水平被用作该领域进一步创新的基石。

在本文中，我将向您展示如何使用Docker设置持续交付管道。 我们将看到如何将此工具用于Linux容器作为持续交付管道的一部分，使我们能够很好地封装服务的构建过程。 它还使我们可以通过几个简单的步骤来部署任何修订。

“了解如何使用Docker设置持续交付管道。” –通过@codeship

点击鸣叫

在本文中，我将主要使用术语“持续交付”，因为它代表了实现我们最终目标的完整步骤。 但是，持续集成是持续交付的最重要部分。

与Docker持续集成

让我们以Go语言编写的Hello World Web服务器作为示例服务。 您可以在此处找到此示例中使用的所有代码： https : //github.com/ContainerSolutions/cd-with-docker-tutorial

持续集成设置包括：

• 运行单元测试
• 构建我们用于构建服务的Docker映像
• 运行构建容器并编译我们的服务
• 构建我们运行和部署的Docker映像
• 将最终映像推送到Docker注册表

自动化测试

在此示例中运行测试非常简单：

go test

构建Docker映像

单个服务集成的核心是制作最终工件—在我们的例子中是Docker映像。

因为在此示例中我故意选择了编译语言Go，所以在集成过程中，我们需要构建一个可执行文件。 我们最终将可执行文件放置在此Docker映像中。

现在，人们可能会认为，我们将使用专用于持续集成的主机上安装的构建工具来构建Web服务器可执行文件，然后以某种方式将二进制文件复制到Docker映像。 但这在集装箱化世界中是禁忌。 让我们在容器中完成所有操作。 这样，我们就不会依赖主机上安装的任何构建工具，它将使整个安装程序易于复制和封装。

构建可执行文件可以是单个Docker映像构建过程以及运行时环境设置的一部分。 或者我们可以将两者分开。 将所有内容都放在一个构建过程中， 即使之后我们在Dockerfile中单独的RUN命令中对其进行清理 ，我们最终也会在Docker映像文件系统中得到额外的内容（构建过程中的剩余内容）。

有些人在单个RUN命令中使用技巧来创建，操纵和删除不需要的内容。 尽管它有时很方便，但我一般不推荐它； 在我看来，这增加了Dockerfile的复杂性。 当然，在某些情况下，您可能希望保留源以及所有最终工件。

但是，我推荐的方法是创建单独的“构建”和“分发” Dockerfile。 使用Dockerfile.build进行软件构建过程中的繁重工作，并使用Dockerfile.dist创建尽可能轻巧和干净的可分发Docker映像。

以下是Dockerfile.build 。 如您所见，一旦运行了构建文件，就可以从golang映像创建容器，编译示例服务，然后输出二进制文件。

FROM golang:1.4

RUN mkdir -p /tmp/build 
ADD hello-world.go /tmp/build/ 
WORKDIR /tmp/build 
RUN go build hello-world.go 
CMD tar -czf - hello-world

在Dockerfile.dist中 ，我们仅使用此二进制文件并在运行时运行它：

FROM debian:jessie

RUN mkdir /app 
ADD build.tar.gz /app/ 
ENTRYPOINT /app/hello-world

我们的build.sh脚本（我们的持续集成管道的重要组成部分）如下所示：

# !/bin/sh
docker build -t hello-world-build -f Dockerfile.build . 
docker run hello-world-build > build.tar.gz 
docker build -t hello-world -f Dockerfile.dist .

如您所见，这三个简单的Docker命令为我们提供了一个干净的小型Hello-World Docker映像，该映像已准备好按需部署和运行。 一旦将FROM子句中使用的两个映像都提取到本地并缓存后，我们的构建过程将花费几毫秒或最多几秒钟的时间，并且占用的资源非常少。

存储Docker映像

创建我们的构建过程工件后，我们希望将其推送到Docker Registry，在那里可以用于部署。

请注意，正确标记图像非常重要。 Docker生态系统遭受 “最新”标签的使用。 如果对每个新映像使用唯一的标记，则将来可以轻松访问所有映像版本以进行部署。

我们可以选择是使用自己的Docker Registry还是依赖Docker Hub 。 在Docker Hub上，您可以存储图像的公共或私有存储库。 这也是人们寻找您的图片的第一个位置（如果您希望任何人寻找它们）。

另一方面，您自己的Docker Registry可让您完全控制映像的存储，性能和安全性。 更高级的设置可能会结合两种方法。

这样，您可以使用适当的标签来标记新图像并将其推送到公共集线器（用实际值替换your_username和your_tag ）：

# !/bin/sh
docker tag hello-world:latest your_username/hello-world:your_tag 
docker push your_username/hello-world:your_tag

连续交付的容器

一旦我们的Docker映像构建管道正常工作并且映像很好地保存在存储库中，我们肯定要部署我们的服务。

如何部署应用程序取决于您的基础架构或云提供商。 如今，一些云提供商在其API中支持Docker映像（ 例如 Amazon EC2容器服务 ， Digital Ocean或Giant Swarm ）。 您可以通过资源抽象工具（例如Apache Mesos （更多有关在Mesos上运行容器的信息 ）或Google Kubernetes ）进一步利用容器化应用程序的功能，这些资源使您能够以自己的方式部署和管理容器。

在我们的Hello World示例中，远程部署意味着在安装了Docker的目标计算机上远程运行以下命令：

# !/bin/sh
docker stop hello-production 
docker run --rm -p 8000:80 --name hello-production hello-world

超越Docker的持续交付

使用容器化软件并不是天生就意味着要实现微服务。 但是，容器支持这种架构模式，因为它们鼓励开发人员基于关注点的分离来拆分其整体。

微服务还使用标准化且易于更换的管子，通过普通网络促进容器组件之间的通信。 要了解有关微服务的更多信息以及为什么它们可能是您的软件项目的理想架构模式，我建议使用Sam Newman的Building Microservices 。

带有容器化软件的连续交付管道还使您可以建立一种新型的测试环境； （微）服务的子集部署在小型集群中，这些集群表示正在测试的系统正在运行，其中某些部分有意被禁用或断开连接。

就连续集成时间而言，创建这样的部署矩阵并对其进行编程几乎不会产生任何额外成本。 它确实对生产中软件的稳定性和弹性产生了巨大影响。 这样的测试系统使团队能够准备好应对任何种类的Chaos Monkey 。

“与Docker的持续集成和交付” –通过@codeship

点击鸣叫

翻译自: https://www.javacodegeeks.com/2015/06/continuous-integration-and-delivery-with-docker.html

docker持续交付