From c44664059180485be88301e2f80ab1a5c13cc420 Mon Sep 17 00:00:00 2001 From: khs1994 Date: Fri, 8 Mar 2019 12:21:07 +0800 Subject: [PATCH] Fix format and update outdate content --- basic_concept/container.md | 2 +- basic_concept/repository.md | 4 ++-- compose/django.md | 2 +- compose/rails.md | 2 +- compose/wordpress.md | 2 +- image/build.md | 6 +++--- image/buildkit/README.md | 13 +++++++++++++ image/commit.md | 2 +- image/dockerfile/cmd.md | 2 +- image/list.md | 2 +- image/pull.md | 2 +- introduction/what.md | 2 +- repository/dockerhub.md | 28 +++++++++++++--------------- 13 files changed, 40 insertions(+), 29 deletions(-) create mode 100644 image/buildkit/README.md diff --git a/basic_concept/container.md b/basic_concept/container.md index 24f06be..aafb409 100644 --- a/basic_concept/container.md +++ b/basic_concept/container.md @@ -4,7 +4,7 @@ 容器的实质是进程，但与直接在宿主执行的进程不同，容器进程运行于属于自己的独立的 [命名空间](https://en.wikipedia.org/wiki/Linux_namespaces)。因此容器可以拥有自己的 `root` 文件系统、自己的网络配置、自己的进程空间，甚至自己的用户 ID 空间。容器内的进程是运行在一个隔离的环境里，使用起来，就好像是在一个独立于宿主的系统下操作一样。这种特性使得容器封装的应用比直接在宿主运行更加安全。也因为这种隔离的特性，很多人初学 Docker 时常常会混淆容器和虚拟机。 -前面讲过镜像使用的是分层存储，容器也是如此。每一个容器运行时，是以镜像为基础层，在其上创建一个当前容器的存储层，我们可以称这个为容器运行时读写而准备的存储层为**容器存储层**。 +前面讲过镜像使用的是分层存储，容器也是如此。每一个容器运行时，是以镜像为基础层，在其上创建一个当前容器的存储层，我们可以称这个为容器运行时读写而准备的存储层为 **容器存储层**。 容器存储层的生存周期和容器一样，容器消亡时，容器存储层也随之消亡。因此，任何保存于容器存储层的信息都会随容器删除而丢失。 diff --git a/basic_concept/repository.md b/basic_concept/repository.md index c018f76..8b66b60 100644 --- a/basic_concept/repository.md +++ b/basic_concept/repository.md @@ -2,7 +2,7 @@ 镜像构建完成后，可以很容易的在当前宿主机上运行，但是，如果需要在其它服务器上使用这个镜像，我们就需要一个集中的存储、分发镜像的服务，[Docker Registry](../repository/registry.md) 就是这样的服务。 -一个 **Docker Registry** 中可以包含多个**仓库**（`Repository`）；每个仓库可以包含多个**标签**（`Tag`）；每个标签对应一个镜像。 +一个 **Docker Registry** 中可以包含多个 **仓库**（`Repository`）；每个仓库可以包含多个 **标签**（`Tag`）；每个标签对应一个镜像。 通常，一个仓库会包含同一个软件不同版本的镜像，而标签就常用于对应该软件的各个版本。我们可以通过 `<仓库名>:<标签>` 的格式来指定具体是这个软件哪个版本的镜像。如果不给出标签，将以 `latest` 作为默认标签。 @@ -26,4 +26,4 @@ Docker Registry 公开服务是开放给用户使用、允许用户管理镜像 开源的 Docker Registry 镜像只提供了 [Docker Registry API](https://docs.docker.com/registry/spec/api/) 的服务端实现，足以支持 `docker` 命令，不影响使用。但不包含图形界面，以及镜像维护、用户管理、访问控制等高级功能。在官方的商业化版本 [Docker Trusted Registry](https://docs.docker.com/datacenter/dtr/2.0/) 中，提供了这些高级功能。 -除了官方的 Docker Registry 外，还有第三方软件实现了 Docker Registry API，甚至提供了用户界面以及一些高级功能。比如，[VMWare Harbor](https://github.com/goharbor/harbor) 和 [Sonatype Nexus](../repository/nexus3_registry.md)。 +除了官方的 Docker Registry 外，还有第三方软件实现了 Docker Registry API，甚至提供了用户界面以及一些高级功能。比如，[Harbor](https://github.com/goharbor/harbor) 和 [Sonatype Nexus](../repository/nexus3_registry.md)。 diff --git a/compose/django.md b/compose/django.md index b9776c9..7cee4d2 100644 --- a/compose/django.md +++ b/compose/django.md @@ -1,6 +1,6 @@ ## 使用 Django -本小节内容适合 `Python` 开发人员阅读。 +> 本小节内容适合 `Python` 开发人员阅读。 我们现在将使用 `Docker Compose` 配置并运行一个 `Django/PostgreSQL` 应用。 diff --git a/compose/rails.md b/compose/rails.md index c498fc1..6bc1960 100644 --- a/compose/rails.md +++ b/compose/rails.md @@ -1,6 +1,6 @@ ## 使用 Rails -本小节内容适合 `Ruby` 开发人员阅读。 +> 本小节内容适合 `Ruby` 开发人员阅读。 我们现在将使用 `Compose` 配置并运行一个 `Rails/PostgreSQL` 应用。 diff --git a/compose/wordpress.md b/compose/wordpress.md index 84f0438..e61adcf 100644 --- a/compose/wordpress.md +++ b/compose/wordpress.md @@ -1,6 +1,6 @@ ## 使用 WordPress -本小节内容适合 `PHP` 开发人员阅读。 +> 本小节内容适合 `PHP` 开发人员阅读。 `Compose` 可以很便捷的让 `Wordpress` 运行在一个独立的环境中。 diff --git a/image/build.md b/image/build.md index af054d8..7a74516 100644 --- a/image/build.md +++ b/image/build.md @@ -2,7 +2,7 @@ 从刚才的 `docker commit` 的学习中，我们可以了解到，镜像的定制实际上就是定制每一层所添加的配置、文件。如果我们可以把每一层修改、安装、构建、操作的命令都写入一个脚本，用这个脚本来构建、定制镜像，那么之前提及的无法重复的问题、镜像构建透明性的问题、体积的问题就都会解决。这个脚本就是 Dockerfile。 -Dockerfile 是一个文本文件，其内包含了一条条的**指令(Instruction)**，每一条指令构建一层，因此每一条指令的内容，就是描述该层应当如何构建。 +Dockerfile 是一个文本文件，其内包含了一条条的 **指令(Instruction)**，每一条指令构建一层，因此每一条指令的内容，就是描述该层应当如何构建。 还以之前定制 `nginx` 镜像为例，这次我们使用 Dockerfile 来定制。 @@ -25,7 +25,7 @@ RUN echo '

Hello, Docker!

' > /usr/share/nginx/html/index.html ### FROM 指定基础镜像 -所谓定制镜像，那一定是以一个镜像为基础，在其上进行定制。就像我们之前运行了一个 `nginx` 镜像的容器，再进行修改一样，基础镜像是必须指定的。而 `FROM` 就是指定**基础镜像**，因此一个 `Dockerfile` 中 `FROM` 是必备的指令，并且必须是第一条指令。 +所谓定制镜像，那一定是以一个镜像为基础，在其上进行定制。就像我们之前运行了一个 `nginx` 镜像的容器，再进行修改一样，基础镜像是必须指定的。而 `FROM` 就是指定 **基础镜像**，因此一个 `Dockerfile` 中 `FROM` 是必备的指令，并且必须是第一条指令。 在 [Docker Hub](https://hub.docker.com/search?q=&type=image&image_filter=official) 上有非常多的高质量的官方镜像，有可以直接拿来使用的服务类的镜像，如 [`nginx`](https://hub.docker.com/_/nginx/)、[`redis`](https://hub.docker.com/_/redis/)、[`mongo`](https://hub.docker.com/_/mongo/)、[`mysql`](https://hub.docker.com/_/mysql/)、[`httpd`](https://hub.docker.com/_/httpd/)、[`php`](https://hub.docker.com/_/php/)、[`tomcat`](https://hub.docker.com/_/tomcat/) 等；也有一些方便开发、构建、运行各种语言应用的镜像，如 [`node`](https://hub.docker.com/_/node)、[`openjdk`](https://hub.docker.com/_/openjdk/)、[`python`](https://hub.docker.com/_/python/)、[`ruby`](https://hub.docker.com/_/ruby/)、[`golang`](https://hub.docker.com/_/golang/) 等。可以在其中寻找一个最符合我们最终目标的镜像为基础镜像进行定制。 @@ -132,7 +132,7 @@ docker build [选项] <上下文路径/URL/-> ### 镜像构建上下文（Context） -如果注意，会看到 `docker build` 命令最后有一个 `.`。`.` 表示当前目录，而 `Dockerfile` 就在当前目录，因此不少初学者以为这个路径是在指定 `Dockerfile` 所在路径，这么理解其实是不准确的。如果对应上面的命令格式，你可能会发现，这是在指定**上下文路径**。那么什么是上下文呢？ +如果注意，会看到 `docker build` 命令最后有一个 `.`。`.` 表示当前目录，而 `Dockerfile` 就在当前目录，因此不少初学者以为这个路径是在指定 `Dockerfile` 所在路径，这么理解其实是不准确的。如果对应上面的命令格式，你可能会发现，这是在指定 **上下文路径**。那么什么是上下文呢？ 首先我们要理解 `docker build` 的工作原理。Docker 在运行时分为 Docker 引擎（也就是服务端守护进程）和客户端工具。Docker 的引擎提供了一组 REST API，被称为 [Docker Remote API](https://docs.docker.com/develop/sdk/)，而如 `docker` 命令这样的客户端工具，则是通过这组 API 与 Docker 引擎交互，从而完成各种功能。因此，虽然表面上我们好像是在本机执行各种 `docker` 功能，但实际上，一切都是使用的远程调用形式在服务端（Docker 引擎）完成。也因为这种 C/S 设计，让我们操作远程服务器的 Docker 引擎变得轻而易举。 diff --git a/image/buildkit/README.md b/image/buildkit/README.md new file mode 100644 index 0000000..0fa2eab --- /dev/null +++ b/image/buildkit/README.md @@ -0,0 +1,13 @@ +## BuildKit + +BuildKit 是下一代的镜像构建组件，在 https://github.com/moby/buildkit 开源。 + +下面介绍如何在 Docker CE 18.09+ 版本中使用 BuildKit 构建 Docker 镜像。 + +```bash +$ export DOCKER_BUILDKIT=1 + +# Windows + +$ set $env:DOCKER_BUILDKIT=1 +``` diff --git a/image/commit.md b/image/commit.md index 6872a79..2cb9008 100644 --- a/image/commit.md +++ b/image/commit.md @@ -126,6 +126,6 @@ docker run --name web2 -d -p 81:80 nginx:v2 首先，如果仔细观察之前的 `docker diff webserver` 的结果，你会发现除了真正想要修改的 `/usr/share/nginx/html/index.html` 文件外，由于命令的执行，还有很多文件被改动或添加了。这还仅仅是最简单的操作，如果是安装软件包、编译构建，那会有大量的无关内容被添加进来，如果不小心清理，将会导致镜像极为臃肿。 -此外，使用 `docker commit` 意味着所有对镜像的操作都是黑箱操作，生成的镜像也被称为**黑箱镜像**，换句话说，就是除了制作镜像的人知道执行过什么命令、怎么生成的镜像，别人根本无从得知。而且，即使是这个制作镜像的人，过一段时间后也无法记清具体在操作的。虽然 `docker diff` 或许可以告诉得到一些线索，但是远远不到可以确保生成一致镜像的地步。这种黑箱镜像的维护工作是非常痛苦的。 +此外，使用 `docker commit` 意味着所有对镜像的操作都是黑箱操作，生成的镜像也被称为 **黑箱镜像**，换句话说，就是除了制作镜像的人知道执行过什么命令、怎么生成的镜像，别人根本无从得知。而且，即使是这个制作镜像的人，过一段时间后也无法记清具体在操作的。虽然 `docker diff` 或许可以告诉得到一些线索，但是远远不到可以确保生成一致镜像的地步。这种黑箱镜像的维护工作是非常痛苦的。 而且，回顾之前提及的镜像所使用的分层存储的概念，除当前层外，之前的每一层都是不会发生改变的，换句话说，任何修改的结果仅仅是在当前层进行标记、添加、修改，而不会改动上一层。如果使用 `docker commit` 制作镜像，以及后期修改的话，每一次修改都会让镜像更加臃肿一次，所删除的上一层的东西并不会丢失，会一直如影随形的跟着这个镜像，即使根本无法访问到。这会让镜像更加臃肿。 diff --git a/image/dockerfile/cmd.md b/image/dockerfile/cmd.md index 120abc3..d21c611 100644 --- a/image/dockerfile/cmd.md +++ b/image/dockerfile/cmd.md @@ -28,7 +28,7 @@ CMD [ "sh", "-c", "echo $HOME" ] 提到 `CMD` 就不得不提容器中应用在前台执行和后台执行的问题。这是初学者常出现的一个混淆。 -Docker 不是虚拟机，容器中的应用都应该以前台执行，而不是像虚拟机、物理机里面那样，用 upstart/systemd 去启动后台服务，容器内没有后台服务的概念。 +Docker 不是虚拟机，容器中的应用都应该以前台执行，而不是像虚拟机、物理机里面那样，用 `systemd` 去启动后台服务，容器内没有后台服务的概念。 一些初学者将 `CMD` 写为： diff --git a/image/list.md b/image/list.md index 6e881e4..e7f27dd 100644 --- a/image/list.md +++ b/image/list.md @@ -15,7 +15,7 @@ ubuntu latest f753707788c5 4 weeks ago 列表包含了 `仓库名`、`标签`、`镜像 ID`、`创建时间` 以及 `所占用的空间`。 -其中仓库名、标签在之前的基础概念章节已经介绍过了。**镜像 ID** 则是镜像的唯一标识，一个镜像可以对应多个**标签**。因此，在上面的例子中，我们可以看到 `ubuntu:18.04` 和 `ubuntu:latest` 拥有相同的 ID，因为它们对应的是同一个镜像。 +其中仓库名、标签在之前的基础概念章节已经介绍过了。**镜像 ID** 则是镜像的唯一标识，一个镜像可以对应多个 **标签**。因此，在上面的例子中，我们可以看到 `ubuntu:18.04` 和 `ubuntu:latest` 拥有相同的 ID，因为它们对应的是同一个镜像。 ### 镜像体积 diff --git a/image/pull.md b/image/pull.md index ede2438..7733f70 100644 --- a/image/pull.md +++ b/image/pull.md @@ -64,7 +64,7 @@ UBUNTU_CODENAME=bionic * `-it`：这是两个参数，一个是 `-i`：交互式操作，一个是 `-t` 终端。我们这里打算进入 `bash` 执行一些命令并查看返回结果，因此我们需要交互式终端。 * `--rm`：这个参数是说容器退出后随之将其删除。默认情况下，为了排障需求，退出的容器并不会立即删除，除非手动 `docker rm`。我们这里只是随便执行个命令，看看结果，不需要排障和保留结果，因此使用 `--rm` 可以避免浪费空间。 * `ubuntu:18.04`：这是指用 `ubuntu:18.04` 镜像为基础来启动容器。 -* `bash`：放在镜像名后的是**命令**，这里我们希望有个交互式 Shell，因此用的是 `bash`。 +* `bash`：放在镜像名后的是 **命令**，这里我们希望有个交互式 Shell，因此用的是 `bash`。 进入容器后，我们可以在 Shell 下操作，执行任何所需的命令。这里，我们执行了 `cat /etc/os-release`，这是 Linux 常用的查看当前系统版本的命令，从返回的结果可以看到容器内是 `Ubuntu 18.04.1 LTS` 系统。 diff --git a/introduction/what.md b/introduction/what.md index db2fc0e..2b5b373 100644 --- a/introduction/what.md +++ b/introduction/what.md @@ -2,7 +2,7 @@ Docker 最初是 dotCloud 公司创始人 Solomon Hykes 在法国期间发起的一个公司内部项目，它是基于 dotCloud 公司多年云服务技术的一次革新，并于 [2013 年 3 月以 Apache 2.0 授权协议开源][docker-soft]，主要项目代码在 [GitHub](https://github.com/moby/moby) 上进行维护。Docker 项目后来还加入了 Linux 基金会，并成立推动 [开放容器联盟（OCI）](https://www.opencontainers.org/)。 -Docker 自开源后受到广泛的关注和讨论，至今其 GitHub 项目已经超过 4 万 6 千个星标和一万多个 fork。甚至由于 Docker 项目的火爆，在 2013 年底，[dotCloud 公司决定改名为 Docker](https://blog.docker.com/2013/10/dotcloud-is-becoming-docker-inc/)。Docker 最初是在 Ubuntu 12.04 上开发实现的；Red Hat 则从 RHEL 6.5 开始对 Docker 进行支持；Google 也在其 PaaS 产品中广泛应用 Docker。 +Docker 自开源后受到广泛的关注和讨论，至今其 [GitHub 项目](https://github.com/moby/moby) 已经超过 5 万 2 千个星标和一万多个 fork。甚至由于 Docker 项目的火爆，在 2013 年底，[dotCloud 公司决定改名为 Docker](https://blog.docker.com/2013/10/dotcloud-is-becoming-docker-inc/)。Docker 最初是在 Ubuntu 12.04 上开发实现的；Red Hat 则从 RHEL 6.5 开始对 Docker 进行支持；Google 也在其 PaaS 产品中广泛应用 Docker。 Docker 使用 Google 公司推出的 [Go 语言](https://golang.org/) 进行开发实现，基于 Linux 内核的 [cgroup](https://zh.wikipedia.org/wiki/Cgroups)，[namespace](https://en.wikipedia.org/wiki/Linux_namespaces)，以及 [AUFS](https://en.wikipedia.org/wiki/Aufs) 类的 [Union FS](https://en.wikipedia.org/wiki/Union_mount) 等技术，对进程进行封装隔离，属于 [操作系统层面的虚拟化技术](https://en.wikipedia.org/wiki/Operating-system-level_virtualization)。由于隔离的进程独立于宿主和其它的隔离的进程，因此也称其为容器。最初实现是基于 [LXC](https://linuxcontainers.org/lxc/introduction/)，从 0.7 版本以后开始去除 LXC，转而使用自行开发的 [libcontainer](https://github.com/docker/libcontainer)，从 1.11 开始，则进一步演进为使用 [runC](https://github.com/opencontainers/runc) 和 [containerd](https://github.com/containerd/containerd)。 diff --git a/repository/dockerhub.md b/repository/dockerhub.md index 6aea421..2284b9c 100644 --- a/repository/dockerhub.md +++ b/repository/dockerhub.md @@ -28,15 +28,13 @@ saltstack/centos-6-minimal tutum/centos-6.4 DEPRECATED. Use tutum/centos:6.4 instead. ... 5 [OK] ``` -可以看到返回了很多包含关键字的镜像，其中包括镜像名字、描述、收藏数（表示该镜像的受关注程度）、是否官方创建、是否自动创建。 +可以看到返回了很多包含关键字的镜像，其中包括镜像名字、描述、收藏数（表示该镜像的受关注程度）、是否官方创建（OFFICIAL）、是否自动构建 （AUTOMATED）。 -官方的镜像说明是官方项目组创建和维护的，automated 资源允许用户验证镜像的来源和内容。 - -根据是否是官方提供，可将镜像资源分为两类。 +根据是否是官方提供，可将镜像分为两类。 一种是类似 `centos` 这样的镜像，被称为基础镜像或根镜像。这些基础镜像由 Docker 公司创建、验证、支持、提供。这样的镜像往往使用单个单词作为名字。 -还有一种类型，比如 `tianon/centos` 镜像，它是由 Docker 的用户创建并维护的，往往带有用户名称前缀。可以通过前缀 `username/` 来指定使用某个用户提供的镜像，比如 tianon 用户。 +还有一种类型，比如 `tianon/centos` 镜像，它是由 Docker Hub 的注册用户创建并维护的，往往带有用户名称前缀。可以通过前缀 `username/` 来指定使用某个用户提供的镜像，比如 tianon 用户。 另外，在查找的时候通过 `--filter=stars=N` 参数可以指定仅显示收藏数量为 `N` 以上的镜像。 @@ -74,24 +72,24 @@ NAME DESCRIPTION STARS username/ubuntu ``` -### 自动创建 +### 自动构建 -自动创建（Automated Builds）功能对于需要经常升级镜像内程序来说，十分方便。 +自动构建（Automated Builds）功能对于需要经常升级镜像内程序来说，十分方便。 -有时候，用户创建了镜像，安装了某个软件，如果软件发布新版本则需要手动更新镜像。 +有时候，用户构建了镜像，安装了某个软件，当软件发布新版本则需要手动更新镜像。 -而自动创建允许用户通过 Docker Hub 指定跟踪一个目标网站（目前支持 [GitHub](https://github.com) 或 [BitBucket](https://bitbucket.org)）上的项目，一旦项目发生新的提交或者创建新的标签（tag），Docker Hub 会自动构建镜像并推送到 Docker Hub 中。 +而自动构建允许用户通过 Docker Hub 指定跟踪一个目标网站（支持 [GitHub](https://github.com) 或 [BitBucket](https://bitbucket.org)）上的项目，一旦项目发生新的提交 （commit）或者创建了新的标签（tag），Docker Hub 会自动构建镜像并推送到 Docker Hub 中。 -要配置自动创建，包括如下的步骤： +要配置自动构建，包括如下的步骤： -* 创建并登录 Docker Hub，以及目标网站； +* 登录 Docker Hub； -* 在目标网站中连接帐户到 Docker Hub； +* 在 Docker Hub 点击右上角头像，在账号设置（Account Settings）中关联（Linked Accounts）目标网站； -* 在 Docker Hub 中 [配置一个自动创建](https://registry.hub.docker.com/builds/add/)； +* 在 Docker Hub 中新建或选择已有的仓库，在 `Builds` 选项卡中选择 `Configure Automated Builds`； * 选取一个目标网站中的项目（需要含 `Dockerfile`）和分支； -* 指定 `Dockerfile` 的位置，并提交创建。 +* 指定 `Dockerfile` 的位置，并保存。 -之后，可以在 Docker Hub 的 [自动创建页面](https://registry.hub.docker.com/builds/) 中跟踪每次创建的状态。 +之后，可以在 Docker Hub 的仓库页面的 `Timeline` 选项卡中查看每次构建的状态。