8.2. 管理部署过程

8.2.1. 管理 DeploymentConfig 对象

重要

自 OpenShift Container Platform 4.14 起，DeploymentConfig 对象已弃用。DeploymentConfig 对象仍被支持，但不建议用于新安装。只有与安全相关的和严重的问题才会被解决。

反之，使用 Deployment 对象或其他替代方法为 pod 提供声明性更新。

DeploymentConfig 对象可以通过 OpenShift Container Platform Web 控制台的 Workloads 页面或使用 oc CLI 管理。以下流程演示了 CLI 的用法（除非另有说明）。

8.2.1.1. 启动部署

您可以启动一个部署推出（rollout）来开始应用程序的部署过程。

流程

要从现有的 DeploymentConfig 对象启动新的部署过程，请运行以下命令：
```
$ oc rollout latest dc/<name>
```
注意
如果部署过程已在进行中，此命令会显示一条消息，不会部署新的复制控制器。

8.2.1.2. 查看部署

您可以查看部署来获取应用程序所有可用修订的基本信息。

流程

要显示所有最近为提供的 DeploymentConfig 对象创建的复制控制器的详细信息，包括任何当前运行的部署过程，请运行以下命令：
```
$ oc rollout history dc/<name>
```
要查看修订的相关细节，请使用 --revision 标志：
```
$ oc rollout history dc/<name> --revision=1
```
如需有关 DeploymentConfig 对象和最新修订的详细信息，请使用 oc describe 命令：
```
$ oc describe dc <name>
```

8.2.1.3. 重试部署

如果 DeploymentConfig 对象的当前修订无法部署，您可以重启部署过程。

流程

重启已经失败的部署过程：
```
$ oc rollout retry dc/<name>
```
如果成功部署了最新的修订，该命令会显示一条消息，且不会重试部署过程。
注意
重试部署会重启部署过程，且不创建新的部署修订。重启的复制控制器具有与失败时相同的配置。

8.2.1.4. 回滚部署

回滚将应用恢复到上一修订，可通过 REST API、命令行或 Web 控制台进行。

流程

回滚到配置的最近一次部署成功的修订：
```
$ oc rollout undo dc/<name>
```
恢复 DeploymentConfig 对象的模板以匹配 undo 命令中指定的部署修订，并且会启动新的复制控制器。如果没有通过 --to-revision 指定修订，则使用最近一次成功部署的修订。
部署过程中会禁用 DeploymentConfig 对象中的镜像更改触发器，以防止在回滚完成不久后意外启动新的部署过程。
重新启用镜像更改触发器：
```
$ oc set triggers dc/<name> --auto
```

注意

部署配置也支持最新部署过程失败时自动回滚到配置的最近一次成功修订。这时，系统会原样保留部署失败的最新模板，由用户来修复其配置。

8.2.1.5. 在容器内执行命令

您可以为容器添加命令，用来覆盖决镜像的 ENTRYPOINT 设置来改变容器的启动行为。这与生命周期 hook 不同，后者在每个部署的指定时间点上运行一次。

流程

在 DeploymentConfig 对象的 spec 字段中添加 command 参数。您也可以添加 args 字段来修改 command（如果 command 不存在，则修改 ENTRYPOINT）。

kind: DeploymentConfig
apiVersion: apps.openshift.io/v1
metadata:
  name: example-dc
# ...
spec:
  template:
# ...
    spec:
     containers:
     - name: <container_name>
       image: 'image'
       command:
         - '<command>'
       args:
         - '<argument_1>'
         - '<argument_2>'
         - '<argument_3>'

例如，使用 -jar 和 /opt/app-root/springboots2idemo.jar 参数来执行 java 命令：

kind: DeploymentConfig
apiVersion: apps.openshift.io/v1
metadata:
  name: example-dc
# ...
spec:
  template:
# ...
    spec:
      containers:
        - name: example-spring-boot
          image: 'image'
          command:
            - java
          args:
            - '-jar'
            - /opt/app-root/springboots2idemo.jar
# ...

8.2.1.6. 查看部署日志

流程

输出给定 DeploymentConfig 对象的最新修订的日志：
```
$ oc logs -f dc/<name>
```
如果最新的修订正在运行或已失败，命令会返回负责部署 Pod 的进程的日志。如果成功，它将从应用程序的 pod 返回日志。
您还可以查看来自旧的失败部署进程的日志，只要存在这些进程（旧的复制控制器及其部署器 pod）并且没有手动清理或删除：
```
$ oc logs --version=1 dc/<name>
```

8.2.1.7. 部署触发器

DeploymentConfig 对象可以包含触发器，推动创建新部署过程以响应集群中的事件。

警告

如果 DeploymentConfig 对象上没有定义任何触发器，则默认添加配置更改触发器。如果触发器定义为空白字段，则必须手动启动部署。

配置更改部署触发器

当在 DeploymentConfig 对象的 pod 模板中发现配置改变时，配置更改触发器会生成一个新的复制控制器。

注意

如果在 DeploymentConfig 对象上定义了配置更改触发器，则在 DeploymentConfig 对象本身创建后会自动创建第一个复制控制器,且不会暂停。

配置更改部署触发器

kind: DeploymentConfig
apiVersion: apps.openshift.io/v1
metadata:
  name: example-dc
# ...
spec:
# ...
  triggers:
    - type: "ConfigChange"

镜像更改部署触发器

镜像更改触发器会在镜像流标签内容更改时（推送镜像的新版本时）产生新的复制控制器。

镜像更改部署触发器

kind: DeploymentConfig
apiVersion: apps.openshift.io/v1
metadata:
  name: example-dc
# ...
spec:
# ...
  triggers:
    - type: "ImageChange"
      imageChangeParams:
        automatic: true 1
        from:
          kind: "ImageStreamTag"
          name: "origin-ruby-sample:latest"
          namespace: "myproject"
        containerNames:
          - "helloworld"

1: 如果 imageChangeParams.automatic 字段设置为 false，则触发器被禁用。

在上例中，当 origin-ruby-sample 镜像流的 latest 标签值更改并且新镜像值与 DeploymentConfig 对象的 helloworld 容器中指定的当前镜像不同时，会使用 helloworld 容器的新镜像创建新的复制控制器。

注意

如果在 DeploymentConfig 对象上定义了镜像更改触发器（带有配置更改触发器和 automatic=false，或 automatic=true）并且镜像更改触发器指向的镜像流标签尚不存在，则初始部署过程将在镜像导入时或由构建推送到镜像流标签时立即自动开始。

8.2.1.7.1. 设置部署触发器

流程

您可以使用 oc set triggers 命令为 DeploymentConfig 对象设置部署触发器。例如，要设置镜像更改触发器，请使用以下命令：
```
$ oc set triggers dc/<dc_name> \
    --from-image=<project>/<image>:<tag> -c <container_name>
```

8.2.1.8. 设置部署资源

部署由节点上消耗资源（内存、CPU 和临时存储）的 pod 完成。默认情况下，pod 消耗无限的节点资源。但是，如果某个项目指定了默认容器限值，则 pod 消耗的资源会被限制在这些限值范围内。

注意

部署的最小内存限值为 12MB。如果容器因为一个 Cannot allocate memory pod 事件启动失败，这代表内存限制太低。增加或删除内存限制。删除限制可让 pod 消耗无限的节点资源。

您还可以在部署策略中指定资源限值来限制资源使用。部署资源可用于 recreate、rolling 或 custom 部署策略。

流程

在以下示例中，resources、cpu、memory 和 ephemeral-storage 中每一个都是可选的：
```
kind: Deployment
apiVersion: apps/v1
metadata:
  name: hello-openshift
# ...
spec:
# ...
  type: "Recreate"
  resources:
    limits:
      cpu: "100m" 1
      memory: "256Mi" 2
      ephemeral-storage: "1Gi" 3
```
1
cpu 以 CPU 单元数为单位：100m 表示 0.1 个 CPU 单元（100 * 1e-3）。
2
memory 以字节为单位：256Mi 表示 268435456 字节 (256 * 2 ^ 20)。
3
ephemeral-storage 以字节为单位：1Gi 表示 1073741824 字节 (2 ^ 30)。
不过，如果您的项目定义了配额，则需要以下两项之一：
- 设定了显式 requests 的 resources 部分：
```
kind: Deployment
apiVersion: apps/v1
metadata:
  name: hello-openshift
# ...
spec:
# ...
  type: "Recreate"
  resources:
    requests: 1
      cpu: "100m"
      memory: "256Mi"
      ephemeral-storage: "1Gi"
```
  1
  requests 对象包含与配额中资源列表对应的资源列表。
- 您项目中定义的限值范围，其中 LimitRange 对象中的默认值应用到部署过程中创建的 pod。
要设置部署资源，请选择以上选项之一。否则，部署 pod 创建失败，显示无法满足配额要求。

其他资源

如需有关资源限值和请求的更多信息，请参阅了解管理应用程序内存。

8.2.1.9. 手动扩展

除了回滚外，您还可以通过手动缩放来对副本数量进行细致的控制。

注意

也可以使用 oc autoscale 命令自动扩展 Pod。

流程

要手动扩展 DeploymentConfig 对象，请使用 oc scale 命令。例如，以下命令将 frontend DeploymentConfig 对象中的副本设置为 3。
```
$ oc scale dc frontend --replicas=3
```
副本数量最终会传播到 DeploymentConfig 对象 frontend 配置的部署的预期和当前状态。

8.2.1.10. 从 DeploymentConfig 对象访问私有存储库

您可以在 DeploymentConfig 对象中添加 secret，以便它可以从私有存储库访问镜像。此流程演示了 OpenShift Container Platform Web 控制台方法。

流程

创建一个新项目。
导航到 Workloads Secrets。
创建一个包含用于访问私有镜像存储库的凭证的 secret。
进入到 Workloads DeploymentConfigs。
创建 DeploymentConfig 对象。
在 DeploymentConfig 对象编辑器页面中，设置 Pull Secret 并保存您的更改。

8.2.1.11. 将 Pod 分配给特定的节点

您可以结合使用节点选择器和带标签的节点来控制 pod 的放置。

集群管理员可为项目设置默认的节点选择器，以便将 pod 放置限制到特定的节点。作为开发人员，您可以设置 Pod 配置的节点选择器来进一步限制节点。

流程

要在创建 Pod 时添加节点选择器，请编辑 Pod 配置并添加 nodeSelector 值。这可添加到单个 Pod 配置中，也可以添加到 Pod 模板中：
```
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
# ...
spec:
  nodeSelector:
    disktype: ssd
# ...
```
具有节点选择器时创建的 Pod 会分配给带有指定标签的节点。这里指定的标签将与集群管理员添加的标签结合使用。
例如，如果项目中包含由集群管理员添加的 type=user-node 和 region=east 标签，并且您将上述 disktype: ssd 标签添加到某一 pod，那么该 pod 仅会调度到具有所有这三个标签的节点上。
注意
标签只能设置为一个值；因此，如果在具有管理员设置的默认值 region=east 的 Pod 配置中设置节点选择器 region=west，这会导致 pod 永不会被调度。

8.2.1.12. 使用其他服务帐户运行 pod

您可以使用非默认服务帐户运行 pod。

流程

编辑 DeploymentConfig 对象：
```
$ oc edit dc/<deployment_config>
```

将 serviceAccount 和 serviceAccountName 参数添加到 spec 字段，再指定您要使用的服务帐户：

apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
metadata:
  name: example-dc
# ...
spec:
# ...
  securityContext: {}
  serviceAccount: <service_account>
  serviceAccountName: <service_account>