Docker高级管理--Compose容器编排与私有仓库（Docker技术集群与应用）

本文介绍了Docker的三大工具：Docker Machine用于创建和管理Docker主机，Docker Compose用于单引擎模式下的多容器应用部署和管理，而Docker Swarm则是一个集群管理工具，提供微服务应用编排功能。Docker Machine支持在不同环境配置Docker主机，Compose通过yaml文件实现容器编排，Swarm则提供集群管理和应用编排，但相比Kubernetes功能较少。

Docker Machine

简介

Docker Machine 是一种可以让您在虚拟主机上安装 Docker 的工具，并可以使用 docker-machine 命令来管理主机。

Docker Machine 也可以集中管理所有的 docker 主机，比如快速的给 100 台服务器安装上 docker。

Docker Machine 管理的虚拟主机可以是机上的，也可以是云供应商，如阿里云，腾讯云，AWS，或 DigitalOcean。

使用 docker-machine 命令，您可以启动，检查，停止和重新启动托管主机，也可以升级 Docker 客户端和守护程序，以及配置 Docker 客户端与您的主机进行通信。

Swarm 集群管理

简介

Docker Swarm 是 Docker 的集群管理工具。它将 Docker 主机池转变为单个虚拟 Docker 主机。 Docker Swarm 提供了标准的 Docker API，所有任何已经与 Docker 守护程序通信的工具都可以使用 Swarm 轻松地扩展到多个主机。

支持的工具包括但不限于以下各项：

Dokku
Docker Compose
Docker Machine
Jenkins

原理

如下图所示，swarm 集群由管理节点（manager）和工作节点（work node）构成。

swarm mananger：负责整个集群的管理工作包括集群配置、服务管理等所有跟集群有关的工作。
work node：即图中的 available node，主要负责运行相应的服务来执行任务（task）。

Docker Compose 概述

现有 docker 进行项目部署存在的问题

1、为了完成一个完整项目势必用到N多个容器（一个容器只运行一个进程）配合完成项目中业务开发，一旦引入N多个容器，容器之间就会形成某种依赖，也就意味某个容器或某些容器的运行需要其他容器优先启动之后才能正常运行。容器的编排显得至关重要，容器的运行一定要有先后顺序。

2、现在这种方式使用容器，没有办法站在项目的角度将一个项目用到的一组容器划分到一起，日后难点在于项目的多服务器部署。比如项目在当前服务器上运行成功，需要将项目再部署到另一台服务器上，但我们不清楚哪组容器是项目引用的，哪组容器是别的引用的。

Docker Compose 简介

Compose 项目是 Docker 官方的开源项目，负责实现对 Docker 容器集群的快速编排。从功能上看，跟 OpenStack 中的 Heat 十分类似。

快速编排：站在项目角度将一组相关联容器整合在一起，对这组容器按照指定顺序进行启动。

Compose 在GitHub上的地址：https://github.com/docker/compose

Compose 是用于定义和运行多容器 Docker 应用程序的工具。通过 Compose，您可以使用 YML 文件来配置应用程序需要的所有服务。然后，使用一个命令，就可以从 YML 文件配置中创建并启动所有服务。使用 Docker Compose 可以轻松、高效的管理容器。

先检查当前环境中是否有compose；

如果发现没有，将以下包，拉取到指定的位置即可；

然后给这个文件一个执行权；

再次查看就可以了；

然后快速部署本次实验环境所需的镜像；

执行导入脚本即可将该目录下的所有镜像导入到系统中；

检查一下：

写一个简单点的compose文件；

注意文件名和后缀名必须和图中一样；

注意:yaml语言格式及其严格，注意空格，不能多，不能少。

在使用compose的时候，确保在该文件的目录下输入；

查看创建的容器；

因为在创建的时候映射了其容器网站的站点目录；

所以，可以创建一个测试文件进行测试；

查看以compose运行起来的容器的日志；

要注意：查看的是服务的名称，而不是容器的名称；

compose管理的是一个服务，而不是一个容器。

一个服务可以包含多个容器。

注意：输入命令的路径，要和compose文件在同目录下；

webapp-1：即服务中的第一个容器；

登录到容器中；

docker-compose run webapp bash

或者在容器外指定指令到容器内；/ls 等等。

以及查看服务中映射的端口；

如何关闭服务；

如何重启服务；

如何删除服务；

一般情况下就是先关闭，再删除；

也可以使用kill的指令杀死服务；

但只是杀死了，服务还在。还是需要rm的指令进行删除的；

利用compose的方式对容器做副本；

但是在创建副本的时候，注意多个容器是不能共用一个端口的；

所以要修改yaml文件；

不能再手动指定映射的端口了。

加scale的选项，指定副本数；

创建副本的应用场景基本都是做集群的，而访问集群一般都是用代理的方式访问的。因此这时就可以加个反向代理，以反向代理的方式进行访问这个集群，集群间用名称通信即可；

这种方式也加强了内部的安全性，因为外部用户是无法直接访问容器的。

YAML文件主要要求：

1：缩进

2：不能用tab键代替缩进

3：缩进量一般用两个空格

4：key和value，key后要有冒号，冒号后有一个空格

5：属性的具体参数，换行后缩进两个空格，加横杠，横杠后有一个空格

6：#号可以注释

7：在写value的时候，如果包含特殊的字符，这个value要引号引起来

8：value的数据类型（布尔型），要使用引号

再做一个针对nginx的服务；

然后将文件中指定的路径创建出来，把文件放入到该目录下；

然后查看该配置文件中的参数与编排文件中指定的是否有出入；

最后再把末尾的daemon off语句删除掉即可，只要保证容器在运行的时候有程序在前台运行即可；

在编排文件的目录下创建容器：

但是此时发现，并没有该容器运行起来；

检查nginx。conf的配置文件；

将php的参数改为本地回环地址即可，因为这个配置文件是用于搭建lnmp容器架构时用到的；

这样就运行了起来；

再打开一个服务器，拉取本次实验所需的软件包；

注意版本；新版本功能更多；

Harbor 介绍

Harbor 是由 VMware 开源的一款云原生制品仓库，Harbor 的核心功能是存储和管理 Artifact。Harbor 允许用户用命令行工具对容器镜像及其他 Artifact 进行推送和拉取，并提供了图形管理界面帮助用户查看和管理这些 Artifact。在 Harbor 2.0 版本中，除容器镜像外，Harbor 对符合 OCI 规范的 Helm Chart、CNAB、OPA Bundle 等都提供了更多的支持。

如上图所示是 Harbor 2.0 的架构图，从上到下可分为代理层、功能层和数据层。

代理层：代理层实质上是一个 Nginx 反向代理，负责接收不同类型的客户端请求，包括浏览器、用户脚本、Docker 等，并根据请求类型和 URI 转发给不同的后端服务进行处理。
功能层：
- Portal：是一个基于 Argular 的前端应用，提供 Harbor 用户访问的界面。
- Core：是 Harbor 中的核心组件，封装了 Harbor 绝大部分的业务逻辑。
- JobService：异步任务组件，负责 Harbor 中很多比较耗时的功能，比如 Artifact 复制、扫描、垃圾回收等。
- Docker Distribution：Harbor 通过 Distribution 实现 Artifact 的读写和存取等功能。
- RegistryCtl：Docker Distribution 的控制组件。
- Notary（可选）：基于 TUF 提供镜像签名管理的功能。
- 扫描工具（可选）：镜像的漏洞检测工具
- ChartMuseum（可选）：提供 API 管理非 OCI 规范的 Helm Chart，随着兼容 OCI 规范的 Helm Chart 在社区上被更广泛地接受，Helm Chart 能以 Artifact 的形式在 Harbor 中存储和管理，不再依赖 ChartMuseum，因此 Harbor 可能会在后续版本中移除对 ChartMuseum 的支持。
数据层：
- Redis：主要作为缓存服务存储一些生命周期较短的数据，同时对于 JobService 还提供了类似队列的功能。
- PostgreSQL：存储 Harbor 的应用数据，比如项目信息、用户与项目的关系、管理策略、配置信息、Artifact 的元数据等等。
- Artifact 存储：存储 Artifact 本身的内容，也就是每次推送镜像、Helm Chart 或其他 Artifact 时，数据最终存储的地方。默认情况下，Harbor 会把 Artifact 写入本地文件系统中。用户也可以修改配置，将 Artifact 存储在外部存储中，例如亚马逊的对象存储 S3、谷歌云存储 GCS、阿里云的对象存储 OSS 等等。