7. 微服务之Docker自动化部署
7.1 Docker 介绍
Docker 是一个快速交付应用、运行应用的技术：
- 可以将程序及其依赖、运行环境一起打包为一个镜像，可以迁移到任意Linux操作系统
- 运行时利用沙箱机制形成隔离容器，各个应用互不干扰
- 启动、移除都可以通过一行命令完成，方便快捷
7.2 Docker 优势
大型项目组件较多，运行环境也较为复杂，部署时会碰到一些问题：
- 依赖关系复杂，容易出现兼容性问题
- 开发、测试、生产环境有差异
Docker 如何解决依赖的兼容问题？
- 将应用的 libs（函数库）、Deps（依赖）、配置与应用一起打包，形成可移植镜像
- 应用运行在容器中，使用沙箱机制，相互隔离
Docker 如何解决不同系统环境的问题？
操作系统结构：
Docker 解决办法：
- Docker 镜像中包含完整运行环境，包括系统应用函数库，它仅依赖系统的Linux内核，因此可以在任意Linux操作系统上运行
7.3 Docker与虚拟机
虚拟机是在操作系统中模拟硬件设备，然后运行另一个操作系统，比如在 Windows 系统里面运行 Ubuntu 系统，这样就可以运行任意的 Ubuntu 应用了。
Docker 和 虚拟机的差异：
- Docker 是一个系统进程；虚拟机是在操作系统中的操作系统
- Docker 体积小、启动速度快、性能好；虚拟机体积大、启动速度慢、性能一般
7.4 Docker架构
镜像：Docker 将应用程序及其所需的依赖、函数库、环境、配置等文件打包在一起，称为镜像。
容器：镜像中的应用程序运行后形成的进程就是容器，只是Docker会给容器做隔离，对外不可见。
DockerHub：是一个Docker镜像的托管平台，这样的平台称为 Docker Registry，类似 gitHub。
Docker 是一个CS架构的程序，由两部分组成：
- 服务端：Docker守护进程，负责处理Docker指令，管理镜像、容器等
- 客户端：通过命令或RestAPI向Docker服务端发送指令。可以在本地或远程向服务端发送指令。
7.5 Docker 基本操作命令
systemctl start docker # 启动docker服务
systemctl stop docker # 停止docker服务
systemctl restart docker # 重启docker服务
docker -v # 查看docker版本
7.6 Docker 镜像操作命令
docker images # 查看镜像
docker rmi # 删除镜像
docker build # 构建镜像
docker save # 保存镜像为一个压缩包
docker load # 加载压缩包为镜像
docker push # 推送镜像到服务
docker pull # 从服务拉取镜像
具体可以通过 docker xxx --help 来查看具体操作指令
从DockerHub拉取镜像：
直接搜索镜像
优先选择官方的
复制指令，直接拉取，默认最新版本
7.7 Docker 容器相关命令
1.运行 nginx 容器：
docker run --name ng -p 80:80 -d nginx
- docker run：创建并运行一个容器
- --name：给容器起个名字，例如 ng
- -p：将宿主机端口与容器端口映射，冒号左侧是宿主机端口，右侧是容器端口
- -d：后台运行容器
- nginx：镜像名称，例如 nginx
2.查看容器状态：
docker ps
- 默认查看运行状态的容器
- 添加 -a 参数查看所有状态的容器
3.删除容器：
docker rm
- 不能删除运行中的容器
- 添加 -f 参数，可以删除
4.进入容器：
docker exec -it ng bash
- docker exec：进入容器内部，执行一个命令
- -it：给当前进入的容器创建一个标准输入、输出终端，允许我们与容器交互
- ng：要进入的容器的名称
- bash：进入容器后要执行的命令，bash是一个Linux终端交互命令
- exec 命令可以进入容器修改文件，但是在容器内修改文件因为不会携带linux相关编辑工具，所以不推荐
7.8 Docker 数据卷
容器与数据耦合问题：
- 不便于修改：当我们要修改Nginx的html内容时，需要进入容器内部修改，很不方便
- 数据不可复用：在容器内的修改对外是不可见的，所有修改对新创建的容器是不可复用的
- 升级维护困难：数据在容器内，如果要升级容器必然删除旧容器，所有数据都会跟着删除
数据卷 是一个虚拟目录，指向宿主机文件系统中的某个目录，形成容器中的文件和系统文件之间的映射，容器中的文件更改时系统对应文件也会更改，反之也一样。
docker volume [command]
docker volume 命令是数据卷操作，根据命令后跟随的 command 来确定下一步的操作：
- create 创建一个volume
- inspect 显示一个或多个volume的信息
- ls 列出所有的volume
- prune 删除未使用的volume
- rm 删除一个或多个指定的volume
例子：
- 创建数据卷 temp
- 查看所有数据卷
- 查看数据卷详细信息卷
该路径指向的是数据卷所在位置，可以根据这个位置获取数据卷对应的容器内文件并进行修改
数据卷挂载
docker run \
--name ng \
-v html:/root/html \
-p 8080:80 \
-d nginx \
和运行容器指令一样，只是命令里增加了：
-v html:/root/html：把 html 数据卷挂载到容器内的 /root/html 这个目录中
- -v volume名称 : 容器内目录
- -v 宿主机文件 : 容器内文件
- -v 宿主机目录 : 容器内目录
数据卷挂载与目录直接挂载的优缺点：
- 数据卷挂载耦合度低，由docker来管理目录，但是目录较深，不好找
- 目录挂载耦合度高，需要我们自己管理目录，不过目录容易寻找查看
实践体会：
目录直接挂载：可以不用提前创建宿主机目录，在容器运行时会自动创建，宿主机路径可以写 $PWD/xxx ，其中 $PWD 代表当前目录 ，注意：目录直接挂载是以宿主机目录为准，即在挂载的时候若宿主机目录为空，那么也会导致挂载后对应容器内的目录为空，但是若Dockerhub中对应镜像有官方挂载指导，例如mysql：
应该是有做过处理，宿主机空目录挂载容器目录后会共享容器目录内的文件
数据卷挂载：只能创建单个目录，不能创建子级目录，并且可以使多个容器目录都挂载到同一个数据卷中，利用数据卷挂载可以实现宿主机-容器文件共享，当数据卷为空时也不会覆盖掉对应容器目录内的文件
7.9 自定义镜像-Dockerfile
镜像结构：
镜像是将应用程序及其需要的系统函数库、环境、配置、依赖打包而成。
例如 mysql 镜像：
镜像是分层结构，每一层称为一个 Layer
- BaseImage层：包含基本的系统函数库、环境变量、文件系统
- Entrypoint：入口，是镜像中应用启动的命令
- 其它：在 BaseImage 基础上添加依赖、安装程序、完成整个应用的安装和配置
Dockerfile 介绍
Dockerfile 就是一个文本文件，其中包含一个个的指令，用指令来说明要执行什么操作来构建 镜像。每一个指令都会形成一层Layer。
常用指令：
| 指令 | 说明 | 示例 |
|---|---|---|
| FROM | 指定基础镜像 | FROM centos:7 |
| ENV | 设置环境变量，可在后面指令使用 | ENV key value |
| COPY | 拷贝本地文件到镜像的指定目录 | COPY ./mysql-5.7.rpm /tmp |
| RUN | 执行Linux的shell命令，一般都是安装过程的命令 | RUN yum install gcc |
| EXPOSE | 指定容器运行时监听的端口，是给镜像使用者看的 | EXPOSE 8080 |
| ENTRYPOINT | 镜像中应用的启动命令，容器运行时调用 | ENTRYPOINT java -jar xx.jar |
7.10 DockerCompose容器自动化部署
docker-compose 可以基于 compose 文件帮我们快速的部署分布式应用，而无需手动一个个创建和运行容器
compose文件是 yml 格式文件，通过指令定义集群中的每个 容器 如何运行
需要提前安装 docker-compose
7.11 微服务部署：
对于微服务的部署，首先对于每个微服务模块都定义一个 Dockerfile 文件来创建镜像：
FROM java:8-alpine # 指定JDK1.8镜像环境
COPY ./app.jar /tmp/app.jar # 将当前目录下的app.jar包移到镜像tmp目录中
ENTRYPOINT java -jar /tmp/app.jar # 镜像中应用启动命令，容器运行时调用
每个微服务模块打包成 app.jar 包
在 pom.xml 文件中，配置
<build>
<finalName>appfinalName>
<plugins>
<plugin>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-maven-pluginartifactId>
plugin>
plugins>
build>
在父目录下创建 docker-compose.yml 文件
version: "3.2"
services:
user-service: # 容器名
build: ./user-service # 在当前目录下的user-service目录中运行Dockerfile文件生成镜像并运行容器
order-service:
build: ./order-service
gateway:
build: ./gateway
ports:
- "10010:10010" # 网关，进行宿主机端口映射,只暴露该端口供访问
networks:
default:
external:
name: my-net # 将这些容器都添加进自定义网卡
最后目录结构：
将文件上传到服务器后，进入 cloud-demo 目录中（一定要先进入该目录中），调用 docker-compose 相关指令运行 docker-compose.yml 文件，即会调用脚本自动生成相关微服务模块镜像并运行容器
docker-compose up -d
部署成功后，可以通过
docker-compose logs -f
查看运行后的所有日志情况
关于一些自己的心得体会：
虽然在 docker-compose.yml 文件中定义了各个微服务的容器名，但是当最后部署生成镜像时，实际镜像名称为 docker-compose.yml 所在目录名_容器名
运行容器时，其容器名称为 docker-compose.yml 所在目录名_容器名_1
而之所以内部用容器名称调用其它微服务时候依然可以用自己在 docker-compose.yml 中定义的容器名称，应该是因为 docker-compose 做了处理，可以识别出来，因为可以直接通过定义的容器名称
查看到具体微服务日志（要在 docker-compose.yml 所在目录），而直接用 docker
查不到，要换成具体容器名称（不用指定具体目录），才能查到
那么为什么这些一起打包部署的容器内部可以直接通过容器名来互相访问呢？
因为默认情况下，Docker Compose 会为我们的应用创建一个网卡，服务的每个容器都会加入该网卡中。这样，容器就可被该网卡中的其他容器通过 以容器名称作为 hostname 访问。
而该网卡默认名称为 docker-compose.yml 所在目录名_default
具体还不懂的话，可以看我另外一篇 关于Docker中容器之间互相访问问题
而我的情况是，对于 nacos 和 mysql 我是先进行了部署，放在了自定义网卡 my-net 当中，所以在这个网卡内可以直接通过容器名作为 hostname 访问，而对于通过 docker-compose 部署的微服务模块，如果不给他们指定 my-net 网卡，那么其会自动创建另外一个默认网卡，那么就无法实现与 nacos 和 mysql 的正常通信，所以在 docker-compose.yml 文件中需要配置指定网卡
version: "3.2"
services:
user-service:
build: ./user-service
order-service:
build: ./order-service
gateway:
build: ./gateway
ports:
- "10010:10010"
# 指定默认网卡
networks:
default:
external:
name: my-net
运行结果
docker inspect my-net
添加成功，那么容器内部可以通过 以容器名称作为 hostname 来进行正常访问了