容器技术的使用支撑了目前 DevOps 三大主要实践：工作流、及时反馈、持续学习。

有人说容器技术与 DevOps 二者在发展的过程中是互相促进的关系。得益于 DevOps 设计理念的流行，容器生态系统在设计上与组件选择上也有相应发展。同时，由于容器技术在生产环境中的使用，反过来也促进了 DevOps 三大主要实践：支撑 DevOps 的三个实践。

工作流

容器中的工作流

每个容器都可以看成一个独立的运行环境，对于容器内部，不需要考虑外部的宿主环境、集群环境，以及其它基础设施。在容器内部，每个功能看起来都是以传统的方式运行。从外部来看，容器内运行的应用一般作为整个应用系统架构的一部分：比如 web API、web app 用户界面、数据库、任务执行、缓存系统、垃圾回收等。运维团队一般会限制容器的资源使用，并在此基础上建立完善的容器性能监控服务，从而降低其对基础设施或者下游其他用户的影响。

现实中的工作流

那些跟“容器”一样业务功能独立的团队，也可以借鉴这种容器思维。因为无论是在现实生活中的工作流（代码发布、构建基础设施，甚至制造 《杰森一家》中的斯贝斯利太空飞轮 等），还是技术中的工作流（开发、测试、运维、发布）都使用了这样的线性工作流，一旦某个独立的环节或者工作团队出现了问题，那么整个下游都会受到影响，虽然使用这种线性的工作流有效降低了工作耦合性。

DevOps 中的工作流

DevOps 中的第一条原则，就是掌控整个执行链路的情况，努力理解系统如何协同工作，并理解其中出现的问题如何对整个过程产生影响。为了提高流程的效率，团队需要持续不断的找到系统中可能存在的性能浪费以及问题，并最终修复它们。

践行这样的工作流后，可以避免将一个已知缺陷带到工作流的下游，避免局部优化导致可能的全局性能下降，要不断探索如何优化工作流，持续加深对于系统的理解。

—— Gene Kim，《支撑 DevOps 的三个实践》，IT 革命，2017.4.25

反馈

容器中的反馈

除了限制容器的资源，很多产品还提供了监控和通知容器性能指标的功能，从而了解当容器工作不正常时，容器内部处于什么样的状态。比如目前流行的 Prometheus，可以用来收集容器和容器集群中相应的性能指标数据。容器本身特别适用于分隔应用系统，以及打包代码和其运行环境，但同时也带来了不透明的特性，这时，从中快速收集信息来解决其内部出现的问题就显得尤为重要了。

现实中的反馈

在现实中，从始至终同样也需要反馈。一个高效的处理流程中，及时的反馈能够快速地定位事情发生的时间。反馈的关键词是“快速”和“相关”。当一个团队被淹没在大量不相关的事件时，那些真正需要快速反馈的重要信息很容易被忽视掉，并向下游传递形成更严重的问题。想象下如果露西和埃塞尔能够很快地意识到：传送带太快了，那么制作出的巧克力可能就没什么问题了（尽管这样就不那么搞笑了）。（LCTT 译注：露西和埃塞尔是上世纪 50 年代的著名黑白情景喜剧《我爱露西》中的主角）

DevOps 中的反馈

DevOps 中的第二条原则，就是快速收集所有相关的有用信息，这样在问题影响到其它开发流程之前就可以被识别出。DevOps 团队应该努力去“优化下游”，以及快速解决那些可能会影响到之后团队的问题。同工作流一样，反馈也是一个持续的过程，目标是快速的获得重要的信息以及当问题出现后能够及时地响应。

快速的反馈对于提高技术的质量、可用性、安全性至关重要。

—— Gene Kim 等人，《DevOps 手册：如何在技术组织中创造世界级的敏捷性，可靠性和安全性》，IT 革命，2016

持续学习

容器中的持续学习

践行第三条原则“持续学习”是一个不小的挑战。在不需要掌握太多边缘的或难以理解的东西的情况下，容器技术让我们的开发工程师和运营团队依然可以安全地进行本地和生产环境的测试，这在之前是难以做到的。即便是一些激进的实验，容器技术仍然让我们轻松地进行版本控制、记录和分享。

现实中的持续学习

举个我自己的例子：多年前，作为一个年轻、初出茅庐的系统管理员（仅仅工作三周），我被安排对一个运行着某个大学核心 IT 部门网站的 Apache 虚拟主机配置进行更改。由于没有方便的测试环境，我直接在生产站点上修改配置，当时觉得配置没问题就发布了，几分钟后，我无意中听到了隔壁同事说：

“等会，网站挂了？”

“没错，怎么回事？”

很多人蒙圈了……

在被嘲讽之后（真实的嘲讽），我一头扎在工作台上，赶紧撤销我之前的更改。当天下午晚些时候，部门主管 —— 我老板的老板的老板 —— 来到我的工位询问发生了什么事。“别担心，”她告诉我。“我们不会责怪你，这是一个错误，现在你已经学会了。”

而在容器中，这种情形在我的笔记本上就很容易测试了，并且也很容易在部署生产环境之前，被那些经验老道的团队成员发现。

DevOps 中的持续学习

持续学习文化的一部分是我们每个人都希望通过一些改变从而能够提高一些东西，并勇敢地通过实验来验证我们的想法。对于 DevOps 团队来说，失败无论对团队还是个人来说都是成长而不是惩罚，所以不要畏惧失败。团队中的每个成员不断学习、共享，也会不断提升其所在团队与组织的水平。

随着系统越来越被细分，我们更需要将注意力集中在具体的点上：上面提到的两条原则主要关注整体流程，而持续学习关注的则是整个项目、人员、团队、组织的未来。它不仅对流程产生了影响，还对流程中的每个人产生影响。

实验和冒险让我们能够不懈地改进我们的工作，但也要求我们尝试之前未用过的工作方式。

—— Gene Kim 等人，《凤凰计划：让你了解 IT、DevOps 以及如何取得商业成功》，IT 革命，2013

容器技术带给 DevOps 的启迪

有效地应用容器技术可以学习 DevOps 的三条原则：工作流，反馈以及持续学习。从整体上看应用程序和基础设施，而不是对容器外的东西置若罔闻，教会我们考虑到系统的所有部分，了解其上游和下游影响，打破隔阂，并作为一个团队工作，以提升整体表现和深度了解整个系统。通过努力提供及时准确的反馈，我们可以在组织内部创建有效的反馈机制，以便在问题发生影响之前发现问题。最后，提供一个安全的环境来尝试新的想法并从中学习，教会我们创造一种文化，在这种文化中，失败一方面促进了我们知识的增长，另一方面通过有根据的猜测，可以为复杂的问题带来新的、优雅的解决方案。

via: https://opensource.com/article/18/9/containers-can-teach-us-devops

作者：Chris Hermansen 选题：lujun9972 译者：littleji 校对：pityonline, wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

或许你已经了解到 Docker 容器镜像是一个轻量、独立、含有运行某个应用所需全部软件的可执行包，这也是为什么容器镜像会经常被开发者用于构建和分发应用。假如你很好奇一个 Docker 镜像里面包含了什么东西，那么这篇简要的指南或许会帮助到你。今天，我们将学会使用一个名为 Dive 的工具来分析和探索 Docker 镜像每层的内容。

通过分析 Docker 镜像，我们可以发现在各个层之间可能重复的文件并通过移除它们来减小 Docker 镜像的大小。Dive 工具不仅仅是一个 Docker 镜像分析工具，它还可以帮助我们来构建镜像。Dive 是一个用 Go 编程语言编写的自由开源工具。

安装 Dive

首先从该项目的 发布页 下载最新版本，然后像下面展示的那样根据你所使用的发行版来安装它。

假如你正在使用 Debian 或者 Ubuntu，那么可以运行下面的命令来下载并安装它。

$ wget https://github.com/wagoodman/dive/releases/download/v0.0.8/dive_0.0.8_linux_amd64.deb

$ sudo apt install ./dive_0.0.8_linux_amd64.deb

在 RHEL 或 CentOS 系统中

$ wget https://github.com/wagoodman/dive/releases/download/v0.0.8/dive_0.0.8_linux_amd64.rpm

$ sudo rpm -i dive_0.0.8_linux_amd64.rpm

Dive 也可以使用 Linuxbrew 包管理器来安装。

$ brew tap wagoodman/dive

$ brew install dive

至于其他的安装方法，请参考 Dive 项目的 GitHub 网页。

分析并探索 Docker 镜像的内容

要分析一个 Docker 镜像，只需要运行加上 Docker 镜像 ID 的 dive 命令就可以了。你可以使用 sudo docker images 来得到 Docker 镜像的 ID。

$ sudo dive ea4c82dcd15a

上面命令中的 ea4c82dcd15a 是某个镜像的 ID。

然后 dive 命令将快速地分析给定 Docker 镜像的内容并将它在终端中展示出来。

正如你在上面的截图中看到的那样，在终端的左边一栏列出了给定 Docker 镜像的各个层及其详细内容，浪费的空间大小等信息。右边一栏则给出了给定 Docker 镜像每一层的内容。你可以使用 Ctrl+空格 来在左右栏之间切换，使用 UP/DOWN 光标键来在目录树中进行浏览。

下面是 dive 的快捷键列表：

• Ctrl+空格 —— 在左右栏之间切换
• 空格 —— 展开或收起目录树
• Ctrl+A —— 文件树视图：展示或隐藏增加的文件
• Ctrl+R —— 文件树视图：展示或隐藏被移除的文件
• Ctrl+M —— 文件树视图：展示或隐藏被修改的文件
• Ctrl+U —— 文件树视图：展示或隐藏未修改的文件
• Ctrl+L —— 层视图：展示当前层的变化
• Ctrl+A —— 层视图：展示总的变化
• Ctrl+/ —— 筛选文件
• Ctrl+C —— 退出

在上面的例子中，我使用了 sudo 权限，这是因为我的 Docker 镜像存储在 /var/lib/docker/ 目录中。假如你的镜像保存在你的家目录 （$HOME）或者在其他不属于 root 用户的目录，你就没有必要使用 sudo 命令。

你还可以使用下面的单个命令来构建一个 Docker 镜像并立刻分析该镜像：

$ dive build -t <some-tag>

Dive 工具仍处于 beta 阶段，所以可能会存在 bug。假如你遇到了 bug，请在该项目的 GitHub 主页上进行报告。

好了，这就是今天的全部内容。现在你知道如何使用 Dive 工具来探索和分析 Docker 容器镜像的内容以及利用它构建镜像。希望本文对你有所帮助。

更多精彩内容即将呈现，请保持关注！

干杯！

via: https://www.ostechnix.com/how-to-analyze-and-explore-the-contents-of-docker-images/

作者：SK 选题：lujun9972 译者：FSSlc 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

你所需了解的容器如何工作的知识。

现在人们严重过度使用了“容器”这个术语。另外，对不同的人来说，它可能会有不同的含义，这取决于上下文。

传统的 Linux 容器只是系统上普通的进程。一组进程与另外一组进程是相互隔离的，实现方法包括：资源限制（控制组 [cgoups]）、Linux 安全限制（文件权限，基于 Capability 的安全模块、SELinux、AppArmor、seccomp 等）还有名字空间（进程 ID、网络、挂载等）。

如果你启动一台现代 Linux 操作系统，使用 cat /proc/PID/cgroup 命令就可以看到该进程是属于一个控制组的。还可以从 /proc/PID/status 文件中查看进程的 Capability 信息，从 /proc/self/attr/current 文件中查看进程的 SELinux 标签信息，从 /proc/PID/ns 目录下的文件查看进程所属的名字空间。因此，如果把容器定义为带有资源限制、Linux 安全限制和名字空间的进程，那么按照这个定义，Linux 操作系统上的每一个进程都在一个容器里。因此我们常说 Linux 就是容器，容器就是 Linux。而容器运行时是这样一种工具，它调整上述资源限制、安全限制和名字空间，并启动容器。

Docker 引入了容器镜像的概念，镜像是一个普通的 TAR 包文件，包含了：

• rootfs（容器的根文件系统）：一个目录，看起来像是操作系统的普通根目录（/），例如，一个包含 /usr, /var, /home 等的目录。
• JSON 文件（容器的配置）：定义了如何运行 rootfs；例如，当容器启动的时候要在 rootfs 里运行什么命令（CMD）或者入口（ENTRYPOINT），给容器定义什么样的环境变量（ENV），容器的工作目录（WORKDIR）是哪个，以及其他一些设置。

Docker 把 rootfs 和 JSON 配置文件打包成基础镜像。你可以在这个基础之上，给 rootfs 安装更多东西，创建新的 JSON 配置文件，然后把相对于原始镜像的不同内容打包到新的镜像。这种方法创建出来的是分层的镜像。

开放容器计划 Open Container Initiative （OCI）标准组织最终把容器镜像的格式标准化了，也就是 镜像规范 OCI Image Specification （OCI）。

用来创建容器镜像的工具被称为容器镜像构建器。有时候容器引擎做这件事情，不过可以用一些独立的工具来构建容器镜像。

Docker 把这些容器镜像（tar 包）托管到 web 服务中，并开发了一种协议来支持从 web 拉取镜像，这个 web 服务就叫 容器仓库 container registry 。

容器引擎是能从镜像仓库拉取镜像并装载到容器存储上的程序。容器引擎还能启动容器运行时（见下图）。

容器存储一般是 写入时复制 copy-on-write （COW）的分层文件系统。从容器仓库拉取一个镜像时，其中的 rootfs 首先被解压到磁盘。如果这个镜像是多层的，那么每一层都会被下载到 COW 文件系统的不同分层。 COW 文件系统保证了镜像的每一层独立存储，这最大化了多个分层镜像之间的文件共享程度。容器引擎通常支持多种容器存储类型，包括 overlay、devicemapper、btrfs、aufs 和 zfs。

容器引擎将容器镜像下载到容器存储中之后，需要创建一份容器运行时配置，这份配置是用户/调用者的输入和镜像配置的合并。例如，容器的调用者可能会调整安全设置，添加额外的环境变量或者挂载一些卷到容器中。

容器运行时配置的格式，和解压出来的 rootfs 也都被开放容器计划 OCI 标准组织做了标准化，称为 OCI 运行时规范。

最终，容器引擎启动了一个容器运行时来读取运行时配置，修改 Linux 控制组、安全限制和名字空间，并执行容器命令来创建容器的 PID 1 进程。至此，容器引擎已经可以把容器的标准输入/标准输出转给调用方，并控制容器了（例如，stop、start、attach）。

值得一提的是，现在出现了很多新的容器运行时，它们使用 Linux 的不同特性来隔离容器。可以使用 KVM 技术来隔离容器（想想迷你虚拟机），或者使用其他虚拟机监视器策略（例如拦截所有从容器内的进程发起的系统调用）。既然我们有了标准的运行时规范，这些工具都能被相同的容器引擎来启动。即使在 Windows 系统下，也可以使用 OCI 运行时规范来启动 Windows 容器。

容器编排器是一个更高层次的概念。它是在多个不同的节点上协调容器执行的工具。容器编排工具通过和容器引擎的通信来管理容器。编排器控制容器引擎做容器的启动和容器间的网络连接，它能够监控容器，在负载变高的时候进行容器扩容。

via: https://opensource.com/article/18/8/sysadmins-guide-containers

作者：Daniel J Walsh 选题：lujun9972 译者：belitex 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

Linux 容器是由 Linux 内核所提供的具有特定隔离功能的进程 —— 包括文件系统、进程和网络的隔离。容器有助于实现可移植性 —— 应用可以在容器镜像中与其依赖项一起分发，并可在几乎任何有容器运行时环境的 Linux 系统上运行。

虽然容器技术存在了很长时间，但 Linux 容器是由 Docker 而得到了广泛推广。 “Docker” 这个词可以指几个不同的东西，包括容器技术和工具，周围的社区，或者 Docker Inc. 公司。但是，在本文中，我将用来指管理 Linux 容器的技术和工具。

什么是 Docker

Docker 是一个以 root 身份在你的系统上运行的守护程序，它利用 Linux 内核的功能来管理正在运行的容器。除了运行容器之外，它还可以轻松管理容器镜像 —— 与容器注册库交互、存储映像、管理容器版本等。它基本上支持运行单个容器所需的所有操作。

但即使 Docker 是管理 Linux 容器的一个非常方便的工具，它也有两个缺点：它是一个需要在你的系统上运行的守护进程，并且需要以 root 权限运行，这可能有一定的安全隐患。然而，Podman 在解决这两个问题。

Podman 介绍

Podman 是一个容器运行时环境，提供与 Docker 非常相似的功能。正如已经提示的那样，它不需要在你的系统上运行任何守护进程，并且它也可以在没有 root 权限的情况下运行。让我们看看使用 Podman 运行 Linux 容器的一些示例。

使用 Podman 运行容器

其中一个最简单的例子可能是运行 Fedora 容器，在命令行中打印 “Hello world!”：

$ podman run --rm -it fedora:28 echo "Hello world!"

使用通用 Dockerfile 构建镜像的方式与 Docker 相同：

$ cat Dockerfile
FROM fedora:28
RUN dnf -y install cowsay

$ podman build . -t hello-world
... output omitted ...

$ podman run --rm -it hello-world cowsay "Hello!"

为了构建容器，Podman 在后台调用另一个名为 Buildah 的工具。你可以阅读最近一篇关于使用 Buildah 构建容器镜像的文章 —— 它不仅仅是使用典型的 Dockerfile。

除了构建和运行容器外，Podman 还可以与容器托管进行交互。要登录容器注册库，例如广泛使用的 Docker Hub，请运行：

$ podman login docker.io

为了推送我刚刚构建的镜像，我只需打上标记来代表特定的容器注册库，然后直接推送它。

$ podman -t hello-world docker.io/asamalik/hello-world
$ podman push docker.io/asamalik/hello-world

顺便说一下，你是否注意到我如何以非 root 用户身份运行所有内容？此外，我的系统上没有运行又大又重的守护进程！

安装 Podman

Podman 默认在 Silverblue 上提供 —— 一个基于容器的工作流的新一代 Linux 工作站。要在任何 Fedora 版本上安装它，只需运行：

$ sudo dnf install podman

via: https://fedoramagazine.org/running-containers-with-podman/

作者：Adam Šamalík 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

在 Linux DNS 查询剖析（第一部分），Linux DNS 查询剖析（第二部分） 和 Linux DNS 查询剖析（第三部分） 中，我们已经介绍了以下内容：

• nsswitch
• /etc/hosts
• /etc/resolv.conf
• ping 与 host 查询方式的对比
• systemd 和对应的 networking 服务
• ifup 和 ifdown
• dhclient
• resolvconf
• NetworkManager
• dnsmasq

在第四部分中，我将介绍容器如何完成 DNS 查询。你想的没错，也不是那么简单。

1) Docker 和 DNS

在 Linux DNS 查询剖析（第三部分） 中，我们介绍了 dnsmasq，其工作方式如下：将 DNS 查询指向到 localhost 地址 127.0.0.1，同时启动一个进程监听 53 端口并处理查询请求。

在按上述方式配置 DNS 的主机上，如果运行了一个 Docker 容器，容器内的 /etc/resolv.conf 文件会是怎样的呢？

我们来动手试验一下吧。

按照默认 Docker 创建流程，可以看到如下的默认输出：

$  docker run  ubuntu cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

search home
nameserver 8.8.8.8
nameserver 8.8.4.4

奇怪！

地址 8.8.8.8 和 8.8.4.4 从何而来呢？

当我思考容器内的 /etc/resolv.conf 配置时，我的第一反应是继承主机的 /etc/resolv.conf。但只要稍微进一步分析，就会发现这样并不总是有效的。

如果在主机上配置了 dnsmasq，那么 /etc/resolv.conf 文件总会指向 127.0.0.1 这个 回环地址 loopback address 。如果这个地址被容器继承，容器会在其本身的 网络上下文 networking context 中使用；由于容器内并没有运行（在 127.0.0.1 地址的）DNS 服务器，因此 DNS 查询都会失败。

“有了！”你可能有了新主意：将 主机的 的 IP 地址用作 DNS 服务器地址，其中这个 IP 地址可以从容器的 默认路由 default route 中获取：

root@79a95170e679:/# ip route
default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2

使用主机 IP 地址真的可行吗？

从默认路由中，我们可以找到主机的 IP 地址 172.17.0.1，进而可以通过手动指定 DNS 服务器的方式进行测试（你也可以更新 /etc/resolv.conf 文件并使用 ping 进行测试；但我觉得这里很适合介绍新的 dig 工具及其 @ 参数，后者用于指定需要查询的 DNS 服务器地址）：

root@79a95170e679:/# dig @172.17.0.1 google.com | grep -A1 ANSWER.SECTION
;; ANSWER SECTION:
google.com.             112     IN      A       172.217.23.14

但是还有一个问题，这种方式仅适用于主机配置了 dnsmasq 的情况；如果主机没有配置 dnsmasq，主机上并不存在用于查询的 DNS 服务器。

在这个问题上，Docker 的解决方案是忽略所有可能的复杂情况，即无论主机中使用什么 DNS 服务器，容器内都使用 Google 的 DNS 服务器 8.8.8.8 和 8.8.4.4 完成 DNS 查询。

我的经历：在 2013 年，我遇到了使用 Docker 以来的第一个问题，与 Docker 的这种 DNS 解决方案密切相关。我们公司的网络屏蔽了 8.8.8.8 和 8.8.4.4，导致容器无法解析域名。

这就是 Docker 容器的情况，但对于包括 Kubernetes 在内的容器 编排引擎 orchestrators ，情况又有些不同。

2) Kubernetes 和 DNS

在 Kubernetes 中，最小部署单元是 pod；它是一组相互协作的容器，共享 IP 地址（和其它资源）。

Kubernetes 面临的一个额外的挑战是，将 Kubernetes 服务请求（例如，myservice.kubernetes.io）通过对应的 解析器 resolver ，转发到具体服务地址对应的 内网地址 private network 。这里提到的服务地址被称为归属于“ 集群域 cluster domain ”。集群域可由管理员配置，根据配置可以是 cluster.local 或 myorg.badger 等。

在 Kubernetes 中，你可以为 pod 指定如下四种 pod 内 DNS 查询的方式。

Default

在这种（名称容易让人误解）的方式中，pod 与其所在的主机采用相同的 DNS 查询路径，与前面介绍的主机 DNS 查询一致。我们说这种方式的名称容易让人误解，因为该方式并不是默认选项！ClusterFirst 才是默认选项。

如果你希望覆盖 /etc/resolv.conf 中的条目，你可以添加到 kubelet 的配置中。

ClusterFirst

在 ClusterFirst 方式中，遇到 DNS 查询请求会做有选择的转发。根据配置的不同，有以下两种方式：

第一种方式配置相对古老但更简明，即采用一个规则：如果请求的域名不是集群域的子域，那么将其转发到 pod 所在的主机。

第二种方式相对新一些，你可以在内部 DNS 中配置选择性转发。

下面给出示例配置并从 Kubernetes 文档中选取一张图说明流程：

apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-dns
  namespace: kube-system
data:
  stubDomains: |
    {"acme.local": ["1.2.3.4"]}
  upstreamNameservers: |
    ["8.8.8.8", "8.8.4.4"]

在 stubDomains 条目中，可以为特定域名指定特定的 DNS 服务器；而 upstreamNameservers 条目则给出，待查询域名不是集群域子域情况下用到的 DNS 服务器。

这是通过在一个 pod 中运行我们熟知的 dnsmasq 实现的。

剩下两种选项都比较小众：

ClusterFirstWithHostNet

适用于 pod 使用主机网络的情况，例如绕开 Docker 网络配置，直接使用与 pod 对应主机相同的网络。

None

None 意味着不改变 DNS，但强制要求你在 pod 规范文件 specification 的 dnsConfig 条目中指定 DNS 配置。

CoreDNS 即将到来

除了上面提到的那些，一旦 CoreDNS 取代 Kubernetes 中的 kube-dns，情况还会发生变化。CoreDNS 相比 kube-dns 具有可配置性更高、效率更高等优势。

如果想了解更多，参考这里。

如果你对 OpenShift 的网络感兴趣，我曾写过一篇文章可供你参考。但文章中 OpenShift 的版本是 3.6，可能有些过时。

第四部分总结

第四部分到此结束，其中我们介绍了：

• Docker DNS 查询
• Kubernetes DNS 查询
• 选择性转发（子域不转发）
• kube-dns

via: https://zwischenzugs.com/2018/08/06/anatomy-of-a-linux-dns-lookup-part-iv/

作者：zwischenzugs 译者：pinewall 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

Docker 是一个开源项目，为开发人员和系统管理员提供了一个开放平台，可以将应用程序构建、打包为一个轻量级容器，并在任何地方运行。Docker 会在软件容器中自动部署应用程序。

Django 是一个用 Python 编写的 Web 应用程序框架，遵循 MVC（模型-视图-控制器）架构。它是免费的，并在开源许可下发布。它速度很快，旨在帮助开发人员尽快将他们的应用程序上线。

在本教程中，我将逐步向你展示在 Ubuntu 16.04 中如何为现有的 Django 应用程序创建 docker 镜像。我们将学习如何 docker 化一个 Python Django 应用程序，然后使用一个 docker-compose 脚本将应用程序作为容器部署到 docker 环境。

为了部署我们的 Python Django 应用程序，我们需要其它 docker 镜像：一个用于 Web 服务器的 nginx docker 镜像和用于数据库的 PostgreSQL 镜像。

我们要做什么？

1. 安装 Docker-ce
2. 安装 Docker-compose
3. 配置项目环境
4. 构建并运行
5. 测试

步骤 1 - 安装 Docker-ce

在本教程中，我们将从 docker 仓库安装 docker-ce 社区版。我们将安装 docker-ce 社区版和 docker-compose（其支持 compose 文件版本 3）。

在安装 docker-ce 之前，先使用 apt 命令安装所需的 docker 依赖项。

sudo apt install -y \
    apt-transport-https \
    ca-certificates \
    curl \
    software-properties-common

现在通过运行以下命令添加 docker 密钥和仓库。

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
sudo add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"

更新仓库并安装 docker-ce。

sudo apt update
sudo apt install -y docker-ce

安装完成后，启动 docker 服务并使其能够在每次系统引导时启动。

systemctl start docker
systemctl enable docker

接着，我们将添加一个名为 omar 的新用户并将其添加到 docker 组。

useradd -m -s /bin/bash omar
usermod -a -G docker omar

以 omar 用户身份登录并运行 docker 命令，如下所示。

su - omar
docker run hello-world

确保你能从 Docker 获得 hello-world 消息。

Docker-ce 安装已经完成。

步骤 2 - 安装 Docker-compose

在本教程中，我们将使用支持 compose 文件版本 3 的最新 docker-compose。我们将手动安装 docker-compose。

使用 curl 命令将最新版本的 docker-compose 下载到 /usr/local/bin 目录，并使用 chmod 命令使其有执行权限。

运行以下命令：

sudo curl -L https://github.com/docker/compose/releases/download/1.21.0/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose

现在检查 docker-compose 版本。

docker-compose version

确保你安装的是最新版本的 docker-compose 1.21。

已安装支持 compose 文件版本 3 的 docker-compose 最新版本。

步骤 3 - 配置项目环境

在这一步中，我们将配置 Python Django 项目环境。我们将创建新目录 guide01，并使其成为我们项目文件的主目录，例如包括 Dockerfile、Django 项目、nginx 配置文件等。

登录到 omar 用户。

su - omar

创建一个新目录 guide01，并进入目录。

mkdir -p guide01
cd guide01/

现在在 guide01 目录下，创建两个新目录 project 和 config。

mkdir project/ config/

注意：

• project 目录：我们所有的 python Django 项目文件都将放在该目录中。
• config 目录：项目配置文件的目录，包括 nginx 配置文件、python pip 的requirements.txt 文件等。

创建一个新的 requirements.txt 文件

接下来，使用 vim 命令在 config 目录中创建一个新的 requirements.txt 文件。

vim config/requirements.txt

粘贴下面的配置：

Django==2.0.4  
gunicorn==19.7.0  
psycopg2==2.7.4

保存并退出。

创建 Nginx 虚拟主机文件 django.conf

在 config 目录下创建 nginx 配置目录并添加虚拟主机配置文件 django.conf。

mkdir -p config/nginx/
vim config/nginx/django.conf

粘贴下面的配置：

upstream web {
  ip_hash;
  server web:8000;
}
 
# portal
server {
  location / {
        proxy_pass http://web/;
  }
  listen 8000;
  server_name localhost;
 
  location /static {    
    autoindex on;    
    alias /src/static/;    
  }
}

保存并退出。

创建 Dockerfile

在 guide01 目录下创建新文件 Dockerfile。

运行以下命令：

vim Dockerfile

现在粘贴下面的 Dockerfile 脚本：

FROM python:3.5-alpine
ENV PYTHONUNBUFFERED 1  

RUN apk update && \
    apk add --virtual build-deps gcc python-dev musl-dev && \
    apk add postgresql-dev bash

RUN mkdir /config  
ADD /config/requirements.txt /config/  
RUN pip install -r /config/requirements.txt
RUN mkdir /src
WORKDIR /src

保存并退出。

注意：

我们想要为我们的 Django 项目构建基于 Alpine Linux 的 Docker 镜像，Alpine 是最小的 Linux 版本。我们的 Django 项目将运行在带有 Python 3.5 的 Alpine Linux 上，并添加 postgresql-dev 包以支持 PostgreSQL 数据库。然后，我们将使用 python pip 命令安装在 requirements.txt 上列出的所有 Python 包，并为我们的项目创建新目录 /src。

创建 Docker-compose 脚本

使用 vim 命令在 guide01 目录下创建 docker-compose.yml 文件。

vim docker-compose.yml

粘贴以下配置内容：

version: '3'
  services:
    db:
      image: postgres:10.3-alpine
      container_name: postgres01
    nginx:
      image: nginx:1.13-alpine
      container_name: nginx01
      ports:
        - "8000:8000"
      volumes:
        - ./project:/src
        - ./config/nginx:/etc/nginx/conf.d
      depends_on:
        - web
    web:
      build: .
      container_name: django01
      command: bash -c "python manage.py makemigrations && python manage.py migrate && python manage.py collectstatic --noinput && gunicorn hello_django.wsgi -b 0.0.0.0:8000"
      depends_on:
        - db
      volumes:
        - ./project:/src
      expose:
        - "8000"
      restart: always

保存并退出。

注意：

使用这个 docker-compose 文件脚本，我们将创建三个服务。使用 alpine Linux 版的 PostgreSQL 创建名为 db 的数据库服务，再次使用 alpine Linux 版的 Nginx 创建 nginx 服务，并使用从 Dockerfile 生成的自定义 docker 镜像创建我们的 python Django 容器。

配置 Django 项目

将 Django 项目文件复制到 project 目录。

cd ~/django
cp -r * ~/guide01/project/

进入 project 目录并编辑应用程序设置 settings.py。

cd ~/guide01/project/
vim hello_django/settings.py

注意：

我们将部署名为 “hello\_django” 的简单 Django 应用程序。

在 ALLOW_HOSTS 行中，添加服务名称 web。

ALLOW_HOSTS = ['web']

现在更改数据库设置，我们将使用 PostgreSQL 数据库来运行名为 db 的服务，使用默认用户和密码。

DATABASES = {  
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'postgres',
        'USER': 'postgres',
        'HOST': 'db',
        'PORT': 5432,
    }
}

至于 STATIC_ROOT 配置目录，将此行添加到文件行的末尾。

STATIC_ROOT = os.path.join(BASE_DIR, 'static/')

保存并退出。

现在我们准备在 docker 容器下构建和运行 Django 项目。

步骤 4 - 构建并运行 Docker 镜像

在这一步中，我们想要使用 guide01 目录中的配置为我们的 Django 项目构建一个 Docker 镜像。

进入 guide01 目录。

cd ~/guide01/

现在使用 docker-compose 命令构建 docker 镜像。

docker-compose build

启动 docker-compose 脚本中的所有服务。

docker-compose up -d

等待几分钟让 Docker 构建我们的 Python 镜像并下载 nginx 和 postgresql docker 镜像。

完成后，使用以下命令检查运行容器并在系统上列出 docker 镜像。

docker-compose ps
docker-compose images

现在，你将在系统上运行三个容器，列出 Docker 镜像，如下所示。

我们的 Python Django 应用程序现在在 docker 容器内运行，并且已经创建了为我们服务的 docker 镜像。

步骤 5 - 测试

打开 Web 浏览器并使用端口 8000 键入服务器地址，我的是：http://ovh01:8000/。

现在你将看到默认的 Django 主页。

接下来，通过在 URL 上添加 /admin 路径来测试管理页面。

http://ovh01:8000/admin/

然后你将会看到 Django 管理登录页面。

Docker 化 Python Django 应用程序已成功完成。

参考

• https://docs.docker.com/

via: https://www.howtoforge.com/tutorial/docker-guide-dockerizing-python-django-application/

作者：Muhammad Arul 译者：MjSeven 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出