## 一、状态码大类

| 状态码分类 | 说明                                                         |
| ---------- | ------------------------------------------------------------ |
| 1xx        | **响应中**——临时状态码，表示请求已经接受，告诉客户端应该继续请求或者如果它已经完成则忽略它 |
| 2xx        | **成功**——表示请求已经被成功接收，处理已完成                 |
| 3xx        | **重定向**——重定向到其它地方：它让客户端再发起一个请求以完成整个处理。 |
| 4xx        | **客户端错误**——处理发生错误，责任在客户端，如：客户端的请求一个不存在的资源，客户端未被授权，禁止访问等 |
| 5xx        | **服务器端错误**——处理发生错误，责任在服务端，如：服务端抛出异常，路由出错，HTTP版本不支持等 |



## 二、常见的响应状态码

| 状态码  | 英文描述                               | 解释                                                         |
| ------- | -------------------------------------- | ------------------------------------------------------------ |
| ==200== | **`OK`**                               | 客户端请求成功，即**处理成功**，这是我们最想看到的状态码     |
| 302     | **`Found`**                            | 指示所请求的资源已移动到由`Location`响应头给定的 URL，浏览器会自动重新访问到这个页面 |
| 304     | **`Not Modified`**                     | 告诉客户端，你请求的资源至上次取得后，服务端并未更改，你直接用你本地缓存吧。隐式重定向 |
| 400     | **`Bad Request`**                      | 客户端请求有**语法错误**，不能被服务器所理解                 |
| 403     | **`Forbidden`**                        | 服务器收到请求，但是**拒绝提供服务**，比如：没有权限访问相关资源 |
| ==404== | **`Not Found`**                        | **请求资源不存在**，一般是URL输入有误，或者网站资源被删除了  |
| 405     | **`Method Not Allowed`**               | 请求方式有误，比如应该用GET请求方式的资源，用了POST          |
| 428     | **`Precondition Required`**            | **服务器要求有条件的请求**，告诉客户端要想访问该资源，必须携带特定的请求头 |
| 429     | **`Too Many Requests`**                | 指示用户在给定时间内发送了**太多请求**（“限速”），配合 Retry-After(多长时间后可以请求)响应头一起使用 |
| 431     | **` Request Header Fields Too Large`** | **请求头太大**，服务器不愿意处理请求，因为它的头部字段太大。请求可以在减少请求头域的大小后重新提交。 |
| ==500== | **`Internal Server Error`**            | **服务器发生不可预期的错误**。服务器出异常了，赶紧看日志去吧 |
| 503     | **`Service Unavailable`**              | **服务器尚未准备好处理请求**，服务器刚刚启动，还未初始化好   |

- 资料链接: [状态码大全](https://cloud.tencent.com/developer/chapter/13553)

http响应状态码

在 Python 中，可以使用集合 (`set`) 来为列表去重。集合中的元素是唯一的，这意味着集合会自动移除重复的元素。你可以将列表转换为集合，然后再将集合转换回列表。以下是一个示例：

```python
# 原始列表
my_list = [1, 2, 2, 3, 4, 4, 5]

# 使用集合去重
unique_list = list(set(my_list))

print(unique_list)
```

这个代码会输出：

```
[1, 2, 3, 4, 5]
```



需要注意的是，集合会移除重复项，但是集合本身是无序的，因此转换回列表时，元素的顺序可能与原始列表不同。如果顺序很重要，可以考虑使用以下方法：

```python
# 使用集合和列表推导式保留顺序
unique_list = []
seen = set()

for item in my_list:
    if item not in seen:
        unique_list.append(item)
        seen.add(item)

print(unique_list)
```

这个方法会保持原始列表中元素的顺序，同时去除重复项。

列表去重

# 基本概念
## 是什么
> 容器编排：就是针对容器生命周期的管理，对容器的生命周期进行更快速方便的方式进行管理

## 为什么需要？
> - 依赖管理，当一个容器必须在另一个容器运行完成后，才能运行时，就需要进行依赖管理  
> - 副本数控制，容器有时候也需要集群，快的对容器集群进行弹性伸缩  
> - 配置共享，通过配置文件统一描述需要运行的服务相关信息，自动化的解析配置内容，并构建对应的服务 



# Docker Compse (单机环境的容器编排)
- **[Docker Compse 官方文档](https://docs.docker.com/reference/cli/docker/compose/)**

> 有的时候我们会需要涉及到在一台机器部署多个容器，那么此时再手动的每次输入相关的一堆配置命令再来启动容器，还是产生了很多无意义的重复性劳动。针对单机的多容器部署的情况，Docker 为我们提供了一个单机版本的服务编排工具 docker-compose

> Docker-Compose 可以高效便捷的管理单机上运行的所有容器，它通过 yaml 配置文件的方式完成之前执行 docker run 命令所设置的所有参数，你可以先针对单机上的所有容器进行相关配置，配置完成后即可使用 docker-compose 对单机多容器进行高效的管理

![image.png](/static/img/639efcee56ff3489a33fddacf26aeafd.image.webp)

## 配置文件
### 版本简述
docker-compose 的 api 版本与大版本一致，compose 版本与 docker 版本之间存在一定关联

| Compose 版本 | Docker 版本  |
|--------------|--------------|
| 3.4          | 17.09.0+     |
| 3.3          | 17.06.0+     |
| 3.2          | 17.04.0+     |
| 3.1          | 1.13.1+      |
| 3.0          | 1.13.0+      |
| 2.3          | 17.06.0+     |
| 2.2          | 1.13.0+      |

这个表格将 Compose 版本和相应的 Docker 版本进行了对比。

### 服务 services
> 需要运行的容器配置，可以理解为原先用 docker run 命令后面跟的一系列配置信息，都陪在这个下面

### 网络 networks
> docker-compose 公共自定义网络管理，配置好以后，可以直接在 services 中引用该网络配置，这个配置可以多个 service 使用

### 数据卷 volumes
> docker-compose 下的统一数据卷管理，可以给多个 service 使用

## 常用命令
```bash
Define and run multi-container applications with Docker.

Usage:
  docker-compose [-f <arg>...] [options] [COMMAND] [ARGS...]
  docker-compose -h|--help

Options:
  -f, --file FILE             Specify an alternate compose file (default: docker-compose.yml)
  -p, --project-name NAME     Specify an alternate project name (default: directory name)
  --verbose                   Show more output
  -v, --version               Print version and exit
  -H, --host HOST             Daemon socket to connect to

  --tls                       Use TLS; implied by --tlsverify
  --tlscacert CA_PATH         Trust certs signed only by this CA
  --tlscert CLIENT_CERT_PATH  Path to TLS certificate file
  --tlskey TLS_KEY_PATH       Path to TLS key file
  --tlsverify                 Use TLS and verify the remote
  --skip-hostname-check       Don't check the daemon's hostname against the name specified
                              in the client certificate (for example if your docker host
                              is an IP address)
```
- Commands:
    - build              构建或重新构建一个服务
    - bundle             Generate a Docker bundle from the Compose file
    - config             验证并查看 compose 文件
    - create             创建一个服务
    - down               停止并删除容器、网络、镜像和数据卷
    - events             Receive real time events from containers
    - exec               在一个运行中的容器执行命令
    - help               获取帮助信息
    - kill               关闭一个容器
    - logs               显示服务的日志信息
    - pause              暂停一个服务
    - port               打印一个端口绑定的公开端口
    - ps                 查看容器列表
    - pull               拉取镜像
    - push               推送镜像
    - restart            重启容器
    - rm                 删除已经停止的容器
    - run                运行一个一次性执行的命令
    - scale              设置服务的容器数量
    - start              启动服务
    - stop               停止服务
    - unpause            恢复一个暂停的服务
    - up                 创建并启动一个容器
    - version            显示 compose 的版本信息

### 构建服务
> 可以选择基于已有的镜像或者 Dockerfile 进行重新构建，利用 docker-compose build 可进行构建操作，也可以指定 docker-compose build \<service name> 来构建指定服务
    
### 创建服务
> 配置好 yml 文件后，通过 docker-compose create 创建配置文件中的所有服务，通过指定服务名来创建具体服务

### 拉取镜像
> docker-compose pull 服务名，可以拉取指定服务的镜像

### 容器的运行/启动/停止
- docker-compose run 服务名：运行服务
- docker-compose start 服务名：启动服务
- docker-compose stop 服务名：停止服务
- docker-compose restart 服务名：重启服务

### 查看管理的容器列表
> docker-compose ps 查看服务列表

### 查看日志
> docker-compose logs 服务名：查看指定服务的日志信息

## 示例
```yaml
# 版本号
version: "2.1"

services:
  # 定义名为 nginx 的服务
  nginx:
    # 指定使用的镜像为官方的 nginx 镜像
    image: "nginx"
    # 指定容器的名称为 nginx_compose
    container_name: "nginx_compose"
    # 设置容器的重启策略为 always，表示无论容器退出的原因是什么，都会自动重启
    restart: "always"
    # 将服务连接到名为 gycnet01 的自定义网络
    networks:
      - gycnet01
    # 挂载卷，映射到容器内部的 /usr/share/nginx/html 目录
    volumes:
      - nginx_volume:/usr/share/nginx/html
    # 设置环境变量，用于容器内应用程序的配置
    environment:
      APP_ENV: dev
    # 配置 DNS 服务器，指定容器使用 8.8.8.8 作为 DNS 解析器
    dns:
      - 8.8.8.8
    # ports: 将主机的 80 端口映射到容器的 80 端口
    ports:
      - 80:80

# 配置网络
networks:
  # 定义一个名为 gycnet01 的自定义网络
  gycnet01:
    # 使用默认的 bridge 驱动创建网络
    driver: bridge
    # 配置 IP 地址管理（IPAM）设置
    ipam:
      driver: default
      config:
        # 指定子网范围为 188.18.0.0/16
        - subnet: 188.18.0.0/16
          # 设置网络的默认网关为 188.18.0.1
          gateway: 188.18.0.1

# 配置卷
volumes:
  # 定义一个名为 nginx_volume 的卷
  nginx_volume:
    # 留空，使用默认的本地驱动
```

- **使用`docker compose scale <容器名称>=数量`将会创建指定数量的容器**
- 需要修改yaml文件
```yaml
services:
  nginx:
    image: "nginx"
    restart: "always"
    networks:
      - gycnet01
    volumes:
      - nginx_volume:/usr/share/nginx/html
    environment:
      APP_ENV: dev
    dns:
      - 8.8.8.8
    ports:
      - "80"

networks:
  gycnet01:
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: 188.18.0.0/16
          gateway: 188.18.0.1

volumes:
  nginx_volume:
```
- ports: - 80：这里的端口映射将把宿主机的 80 端口映射到容器的 80 端口。需要注意的是，当您扩展多个容器时，只有第一个容器实例可以绑定到宿主机的 80 端口。后续容器将无法绑定到同一个宿主机端口，因为端口冲突会导致错误。

# docker swarm(swarm)
- **[官方文档](https://github.com/docker/swarm)**

- 架构图

![swarm架构.png](/static/img/1a990e98d141f34d0a60f24a90cc79be.swarm%C3%A6%C2%9E%C2%B6%C3%A6%C2%9E%C2%84.webp)

> Swarm 是 Docker 公司推出的用来管理 docker 集群的平台，几乎全部用GO语言来完成的开发的， 它是将一群 Docker 宿主机变成一个单一的虚拟主机，Swarm 使用标准的 Docker API 接口作为其前端的访问入口，换言之，各种形式的DockerClient(compose, docker-py 等) 均可以直接与 Swarm 通信，甚至 Docker 本身都可以很容易的与 Swarm 集成，这大大方便了用户将原本基于单节点的系统移植到 Swarm 上，同时Swarm 内置了对 Docker 网络插件的支持，用户也很容易的部署跨主机的容器集群服务。

> Docker Swarm 和 Docker Compose 一样，都是 Docker 官方容器编排项目，但不同的是，Docker Compose 是一个在单个服务器或主机上创建多个容器的工具，而 Docker Swarm 则可以在多个服务器或主机上创建容器集群服务，对于微服务的部署，显然 Docker Swarm 会更加适合。

> 从 Docker 1.12.0 版本开始，Docker Swarm 已经包含在 Docker 引擎中（docker swarm），并且已经内置了服务发现工具，我们就不需要像之前一样，再配置 Etcd 或者 Consul 来进行服务发现配置了。

> Swarm deamon只是一个调度器(Scheduler)加路由器(router),Swarm自己不运行容器，它只是接受Docker客户端发来的请求，调度适合的节点来运行容器，这就意味着，即使Swarm由于某些原因挂掉了，集群中的节点也会照常运行，放Swarm重新恢复运行之后，他会收集重建集群信息。

## 关键概念
### Swarm
> 集群的管理和编排是使用嵌入 docker 引擎的 SwarmKit，可以在docker 初始化时启动 swarm 模式或者加入已存在的 swarm

- swarm 集群节点的管理命令：docker swarm --help
    - 初始化集群节点
    - 加入节点
    - 退出节点

### Node
> 运行 Docker 的主机可以主动初始化一个 Swarm 集群或者加入一个已存在的 Swarm 集群，这样这个运行 Docker 的主机就成为一个 Swarm 集群的节点 (node) 。

> 节点分为管理 (manager) 节点和工作 (worker) 节点。

> 管理节点用于 Swarm 集群的管理，docker swarm 命令基本只能在管理节点执行（节点退出集群命令 docker swarm leave 可以在工作节点执行）。一个 Swarm 集群可以有多个管理节点，但只有一个管理节点可以成为 leader，leader 通过 raft 协议实现。通常，第一个启用docker swarm的节点将成为leader，后来加入的都是follower。当前的leader如果挂掉，剩余的节点将重新选举出一个新的leader。每一个manager都有一个完整的当前集群状态的副本，可以保证manager的高可用。

> 工作节点是任务执行节点，管理节点将服务 (service) 下发至工作节点执行。管理节点默认也作为工作节点。你也可以通过配置让服务只运行在管理节点。worker节点之间，通过control plane进行通信，这种通信使用gossip协议，并且是异步的。

> 来自 Docker 官网的这张图片形象的展示了集群中管理节点与工作节点的关系。

![swarm-diagram.png](/static/img/b877ea8d8c74c696577d608f53e61c08.swarm-diagram.webp)
    
### Task
> 任务 （Task）是 Swarm 中的最小的调度单位，目前来说就是一个单一的容器。

### Service
> 服务 （Services） 是指一组任务的集合，服务定义了任务的属性。服务有两种模式：

- replicated services 按照一定规则在各个工作节点上运行指定个数的任务。

- global services 每个工作节点上运行一个任务

- 两种模式通过 docker service create 的 --mode 参数指定。

服务与任务的关系：

![services-diagram.png](/static/img/f60a0cd1646b3de342ecda5ed985248c.services-diagram.webp)

服务的生命周期:

![service-lifecycle.png](/static/img/2f81fd79a0fc51498911a606b9fcce0a.service-lifecycle.webp)

## 应用实战
### 集群搭建
#### 初始化集群
登录管理节点，并执行如下命令
`docker swarm init --advertise-addr IP(192.168.113.120)`

- 使用 docker info 可以查看 swarm 集群状态

- docker node ls 可以查看集群节点信息

![image.png](/static/img/be552f5e11303ba470542fa4a1978e95.image.webp)

#### 增加工作节点
分别在两个工作节点上执行加入节点命令

`docker swarm join \
-- token 集群初始化时的 token 信息 \
192.168.113.120:2377`

![image.png](/static/img/49e9dac8aaa96802c2d87586939bd9aa.image.webp)

#### 查看集群
- 进入主节点，输入如下命令查看集群节点信息
`docker node ls`

![image.png](/static/img/d82b3b459ced66fc933c3c72043dde65.image.webp)


### 部署服务
#### 新建服务
进入主节点，创建一个 helloworld 服务
`docker service create --replicas 1 -p 80:80 --name nginx_swarm nginx`

![image.png](/static/img/39835a90075e8f85bd6baa0617b68132.image.webp)

- 命令解释：
    - `docker service create` 创建一个服务
    - `--name` 设置服务名称
    - `--replicas` 设置启动多少个实例

- 命令详解: 
    - **`docker service create`**：这是 Docker Swarm 模式下创建服务的命令。服务是 Docker Swarm 中的一个重要概念，它允许你在多个节点上运行和管理容器。

    - **`--replicas 2`**：指定服务的副本数为 2。也就是说，这个服务会在集群中运行两个相同的 `nginx` 容器实例。

    - **`-p 80:80`**：这是端口映射的选项。第一个 `80` 是主机上的端口，第二个 `80` 是容器内的端口。这个映射意味着访问集群节点的端口 `80` 时，流量会被转发到容器内的 `80` 端口，也就是 `nginx` 默认的 HTTP 服务端口。

    - **`--name nginx_swarm`**：指定服务的名称为 `nginx_swarm`。你可以使用这个名字来管理或查询这个服务。

    - **`nginx`**：这是服务所运行的镜像名称。在这个例子中，`nginx` 是一个来自 Docker 官方镜像库的镜像，它会在容器中运行一个 Nginx Web 服务器。



- 通过 `docker service ps <service id>` 可以查看服务信息

![image.png](/static/img/5ef34ded0feb2895e4a0ea50b092fb05.image.webp)

- 通过 `docker service ls` 可以查看 Swarm 集群下运行的所有服务

![image.png](/static/img/6a8d914701ef0caa7644fcfbfa90c345.image.webp)

#### 监控集群状态
- 查看服务信息：
`docker service inspect --pretty <service id>`
`--pretty` 参数可以简化输出内容

- `docker service ps <service id>` 可以查看运行中的服务信息

![image.png](/static/img/e6a58d191940da38187dc6fc436a446c.image.webp)

- 进入工作节点通过 `docker ps` 可以查看容器运行状态

![image.png](/static/img/8a287a2b5dae042a9ca612c1c2e4a4c8.image.webp)

### 弹性伸缩
#### 调整实例个数
- 更新服务的实例个数：
`docker service update --replicas <num> <service id/name>`

```bash
docker service update --replicas 1 nginx_swarm
```
- 命令详解: 
    - **`docker service update`**：用来更新 Docker Swarm 中已存在的服务

    - **`--replicas 1`**：设置服务的副本数为 1。这意味着该服务将运行一个容器实例

    - **`nginx_swarm`**：要更新的服务的名称。在这个例子中，服务的名称是 `nginx_swarm`

![image.png](/static/img/a223b2be313910b711594f94a374d5e1.image.webp)

#### 调整集群大小
- 添加新的 Docker 节点，执行 `docker swarm join` 命令可以加入集群

- 执行 `docker swarm leave` 可以退出集群，也可以带上 `--force` 参数强制退出集群

Docker容器编排

# 1.springboot项目
```dockerfile
# 基础镜像
FROM openjdk:8

# 将项目jar包拷贝到容器中
COPY ./springboot-docker-demo-1.0.0.jar app.jar

# 配置项目环境变量
ENV APP_OPTS=""
# JVM 环境变量
ENV JVM_OPTS="-Duser.timezone=Asia/Shanghai -Xms128m -Xmx128m"

# 暴露端口
EXPOSE 8080

# 设置启动时命令
CMD ["sh", "-c", "java $JVM_OPTS -jar /app.jar $APP_OPTS"]
```

- 使用`docker build -t springboot-docker:1.0.0 .`命令构建镜像
- 运行容器`docker run -d --rm -P springboot-docker:1.0.0 `



# 2. javaweb项目
```dockerfile
# 使用官方的 Tomcat 9.0 镜像作为基础镜像
FROM tomcat:9.0

# 设置工作目录为 Tomcat 的 webapps 目录
# 这是 Tomcat 默认的应用部署目录
WORKDIR /usr/local/tomcat/webapps

# 将本地的 WAR 包（javaweb-docker-demo-1.0-SNAPSHOT.war）复制到 Tomcat 的 webapps 目录中
# 并将其重命名为 ROOT.war，这样 Tomcat 会将它作为根上下文部署
COPY javaweb-docker-demo-1.0-SNAPSHOT.war ROOT.war

# 使用 Tomcat 镜像的默认启动命令，不需要额外设置
# 这条命令实际上是 Tomcat 镜像默认的启动命令
CMD ["sh", "-c", "../bin/catalina.sh run"]
```

Dockerfile部署Java项目

# 基本概念
## 是什么？
> Docker 为我们提供的一个用于自定义构建镜像的一个配置文件：描述如何构建一个对象  

> 利用 Docker 提供的 build 命令，指定 Dockerfile 文件，就可以按照配置的内容将镜像构建出来

## 为什么需要？
> 作为开发者需要将自己开发好的项目打包成 Docker 镜像，便于后面直接作为 Docker 容器运行

> 作为运维人员需要构建更精简的基础设施服务镜像，满足公司的需求以及尽可能减少冗余的功能占用过多的资源

## 能干什么？
- 可以自定义镜像内容
- 构建公共基础镜像减少其他镜像配置
- 开源程序的快速部署
- 实现企业内部项目的快速交付

![450977-20190512115951746-136143052.png](/static/img/e257dbf2499de96d9b73c36f143338c6.450977-20190512115951746-136143052.webp)



# 构建镜像
## commit
> 基于一个现有的容器，构建一个新的镜像

- 命令：
```bash
docker commit [OPTIONS] CONTAINER [REPOSITORY[:TAG]]
```

- 例：
```bash
docker commit -a="gyc" -m="first image" centos7 mycentos:7
```

- OPTIONS：
    - -a：镜像的作者
    - -c：使用 Dockerfile 指令来构建镜像
    - -m：提交时的描述
    - -p：在 commit 时暂停容器

## build
> `docker build` 命令用于从 Dockerfile 构建 Docker 镜像。

- 基本格式：
```bash
docker build [OPTIONS] PATH
```

- 常用参数说明：

    - `-t` 或 `--tag`：指定镜像的标签（名字），例如 `my-image:latest`。
    - `-f` 或 `--file`：指定 Dockerfile 的路径（默认为当前目录下的 `Dockerfile`）。
    - `--no-cache`：在构建过程中不使用缓存。
    - `--build-arg`：设置构建时的变量。

- 示例：

```bash
docker build -t my-image:latest .
```

- 这个命令将在当前目录（`.`）下查找 Dockerfile 并构建镜像，镜像名称为 `my-image`，标签为 `latest`。

- 如果你有一个自定义路径的 Dockerfile，可以这样使用：

```bash
docker build -t my-image:latest -f /path/to/Dockerfile .
```
- 这样 Dockerfile 会从指定路径读取，而构建上下文仍是当前目录。

# Dockerfile指令
## 常用指令
### FROM
> 指定以什么镜像作为基础镜像，在改进项的基础之上构建新的镜像。

>如果不想以任何镜像作为基础：FROM scratch

- 语法：
    - FROM \<image>
    - FROM \<image>:\<tag>
    - FROM \<image>:\<digest>

- 以上为三种写法，后两者为指定具体版本，第一种则使用 latest 也就是最新版

### MAINTAINER
> 指定该镜像的作者

- 语法：
    - MAINTAINER \<name>

### LABEL
> 为镜像设置标签，一个 Dockerfile 中可以配置多个 LABEL

- 语法：
    - LABEL \<key>=\<value>

- 如：
    - LABEL "example.label"="Example Label"
    - LABEL label-value="LABEL"
    - LABEL version="1.0.0"
    - LABEL description="可以写成多行，使用 \
    - 符号可以拼接多行的 value"

- PS：LABEL 指令会继承基础镜像（FROM）中的 LABEL，如果当前镜像 LABEL 的 key 与其相同，则会将其覆盖

### ENV
- 设置容器的环境变量，可以设置多个

- 语法：
    - ENV \<key> \<value>
    - ENV \<key>=\<value> \<key>=\<value> ...

- 两种语法的区别为第一种一次只能设置一个环境变量，第二种可以一次设置多个

### RUN
> 构建镜像的过程中要执行的命令

- 语法：
    - RUN \<command>
    - RUN ["executable", "param1", "param2"]

- 第一种写法就是直接写 Shell 脚本即可

- 第二种写法类似函数调用，第一个参数为可执行文件，后面的都是参数

### ADD
- 复制命令，把 src 的文件复制到镜像的 dest 位置

- 语法：
    - ADD \<src> \<dest>
    - ADD ["\<src>", "\<dest>"]

### WORKDIR
> 设置工作目录，可以简单理解为 cd 到指定目录，如果该目录不存在会自动创建，对 RUN、CMD、ENTRYPOINT、COPY、ADD 生效，可以设置多次 WORKDIR

- 如：
    - WORKDIR \<dir>

- 表示在容器内创建了 dir 目录，并且当前目录已经是 dir 目录了

### VOLUME
> 设置挂载目录，可以将主机中的指定目录挂载到容器中

- 语法：
    - VOLUME ["\<dir>"]
    - VOLUME \<dir>
    - VOLUME \<dir> \<dir>

- 以上三种写法都可

### EXPOSE
> 改镜像运行容器后，需要暴露给外部的端口，但仅仅表示该容器想要暴露某些端口，并不会与主机端口有映射关系，如果想将容器暴露的端口与主机映射则需要使用 -p 或 -P 参数来映射，可以暴露多个端口

- 语法：
    - EXPOSE \<port>[/<tcp/udp>]

### CMD
> 该镜像启动容器时默认执行的命令或参数

- 语法：
    - CMD ["executable", "param1", "param2"]
    - CMD ["param1", "param2"]
    - CMD \<command> \<param1> \<param2>

- 以上为该命令的三种写法，第三种与普通 Shell 命令类似，第一、二两种都是可执行文件 + 参数的形式，另外数组内的参数必须使用双引号。

- 案例：
    - 第一种：CMD ["sh", "-c", "echo \$HOME"] 等同于 sh -c "echo $HOME"

    - 第二种：CMD ["echo", "\$HOME"] 等同于 echo $HOME

### ENTRYPOINT
> 运行容器时的启动命令，感觉与 CMD 命令会很像，实际上还是有很大区别，简单对比一下：

- 相同点：
    在整个 Dockerfile 中只能设置一次，如果写了多次则只有最后一次生效
- 不同点：
    - ENTRYPOINT 不会被运行容器时指定的命令所覆盖，而 CMD 会被覆盖

- 如果同时设置了这两个指令，且 CMD 仅仅是选项而不是参数，CMD 中的内容会作为 ENTRYPOINT 的参数（一般不这么做）

- 如果两个都是完整命令，那么只会执行最后一条

- 语法：
    - ENTRYPOINT ["executable", "param1", "param2"]
    - ENTRYPOINT command param1 param2

## 拓展指令
### ARG
> 设置变量，在镜像中定义一个变量，当使用 docker build 命令构建镜像时，带上 --build-arg \<name>=\<value> 来指定参数值，如果该变量名在 Dockerfile 中不存在则会抛出一个警告

- 语法：
    - ARG \<name>[=\<default value>]

### USER
> 设置容器的用户，可以是用户名或 UID，如果容器设置了以 daemon 用户去运行，那么 RUN、CMD 和 ENTRYPOINT 都会以这个用户去运行，一定要先确定容器中有这个用户，并且拥有对应的操作权限。

- 语法：
    - USER \<username>
    - USER \<PID>

### ONBUILD
> 表示在构建镜像时做某操作，不过不对当前 Dockerfile 的镜像生效，而是对以当前 Dockerfile 镜像作为基础镜像的子镜像生效

- 语法：
    - ONBUILD [INSTRUCTION]

- 例：
    - 当前镜像为 A，设置了如下指令 
    `ONBUILD RUN ls -al`

    - 镜像 B：  
        FROM 镜像A  
        ......  
        构建镜像 B 时，会执行 ls -al 命令
        
### STOPSIGNAL
> STOPSIGNAL 指令设置将发送到容器的系统调用信号以退出。此信号可以是与内核的系统调用表中的位置匹配的有效无符号数，例如 9，或 SIGNAME 格式的信号名，例如 SIGKILL。

> 默认的stop-signal是SIGTERM，在docker stop的时候会给容器内PID为1的进程发送这个signal，通过--stop-signal可以设置自己需要的signal，主要的目的是为了让容器内的应用程序在接收到signal之后可以先做一些事情，实现容器的平滑退出，如果不做任何处理，容器将在一段时间之后强制退出，会造成业务的强制中断，这个时间默认是10s。

- 例
```bash
STOPSIGNAL \<signal>
```

### HEALTHCHECK
> 容器健康状况检查，可以指定周期检查容器当前的健康状况，该命令只能出现一次，如果有多次则只有最后一次生效。

- 语法：
    - HEALTHCHECK [OPTIONS] CMD command
    - HEALTHCHECK NONE

- 第一种：在容器内部按照指定周期运行指定命令来检测容器健康状况
- 第二种：取消在基础镜像

- OPTIONS 选项：
    - --interval=DURATION 两次检查的间隔时间，默认30s
    - --timeout=DURATION 命令执行的超时时间，默认30s
    - --retries=N 当连续失败指定次数，容器会被认定为不健康，默认为3次
    - 返回参数：
    - 0：success => 健康状态
    - 1：unhealthy => 不健康状态
    - 2：reserved => 保留值

## ENTRYPOINT 和 CMD 的用法和区别

### `ENTRYPOINT`

- **定义**：`ENTRYPOINT` 指定了容器启动时要执行的主要命令，并且这个命令不能被覆盖。
- **用途**：适用于需要确保容器启动时始终执行特定命令的情况。
- **用法**：
  - **Exec 格式**（推荐）：
    ```Dockerfile
    ENTRYPOINT ["executable", "param1", "param2"]
    ```
  - **Shell 格式**：
    ```Dockerfile
    ENTRYPOINT executable param1 param2
    ```

### `CMD`

- **定义**：`CMD` 提供了容器启动时的默认参数，这些参数可以被 `docker run` 命令行中指定的参数覆盖。
- **用途**：适用于提供默认参数或命令，并允许在启动容器时覆盖它们的情况。
- **用法**：
  - **Exec 格式**（推荐）：
    ```Dockerfile
    CMD ["param1", "param2"]
    ```
  - **Shell 格式**：
    ```Dockerfile
    CMD executable param1 param2
    ```

### 使用示例

#### 示例 1：使用 `ENTRYPOINT` 和 `CMD` 的组合

假设您要创建一个容器，它启动时会运行一个 Python 脚本，并且您希望能够覆盖脚本的参数。

```Dockerfile
# Dockerfile
FROM python:3.9-slim

# 将 Python 脚本复制到容器中
COPY script.py /usr/src/app/script.py

# 设置 ENTRYPOINT
ENTRYPOINT ["python", "/usr/src/app/script.py"]

# 提供默认参数
CMD ["default_arg1", "default_arg2"]
```

**解释**：
- `ENTRYPOINT` 指定了容器启动时始终运行 `python /usr/src/app/script.py`。
- `CMD` 提供了默认参数 `default_arg1` 和 `default_arg2`，这些参数可以在 `docker run` 命令中被覆盖。

**运行**：
- 使用默认参数：
  ```bash
  docker run myimage
  ```
  这将运行 `python /usr/src/app/script.py default_arg1 default_arg2`。

- 使用自定义参数：
  ```bash
  docker run myimage custom_arg1 custom_arg2
  ```
  这将运行 `python /usr/src/app/script.py custom_arg1 custom_arg2`。

#### 示例 2：仅使用 `ENTRYPOINT`

如果您希望容器总是执行一个固定的命令，并且不希望在 `docker run` 中覆盖该命令，可以仅使用 `ENTRYPOINT`：

```Dockerfile
# Dockerfile
FROM ubuntu:latest

# 设置 ENTRYPOINT
ENTRYPOINT ["/bin/echo", "Hello"]
```

**运行**：
- 运行容器：
  ```bash
  docker run myimage World
  ```
  这将输出 `Hello World`。`ENTRYPOINT` 中的 `/bin/echo` 是固定的，而 `docker run` 中提供的 `World` 是传递给 `echo` 命令的参数。

#### 示例 3：仅使用 `CMD`

如果您不需要指定固定的命令，只是提供默认参数，可以仅使用 `CMD`：

```Dockerfile
# Dockerfile
FROM ubuntu:latest

# 设置 CMD
CMD ["echo", "Hello World"]
```

**运行**：
- 使用默认命令：
  ```bash
  docker run myimage
  ```
  这将输出 `Hello World`。

- 使用自定义命令：
  ```bash
  docker run myimage "Custom Message"
  ```
  这将输出 `Custom Message`。

### 总结

- **`ENTRYPOINT`**：用于指定容器启动时始终执行的主要命令。如果 `ENTRYPOINT` 和 `CMD` 都定义了，`CMD` 提供的参数将作为 `ENTRYPOINT` 中命令的默认参数。
- **`CMD`**：用于提供容器启动时的默认参数，这些参数可以被 `docker run` 命令中的参数覆盖。

选择使用 `ENTRYPOINT`、`CMD` 还是两者结合取决于您是否需要固定的执行命令或提供默认参数并允许覆盖。