8.2. 管理部署过程

流程

1. 要从现有的 DeploymentConfig 对象启动新的部署过程，请运行以下命令：

   $ oc rollout latest dc/<name>

   注意

   如果部署过程已在进行中，此命令会显示一条消息，不会部署新的复制控制器。

流程

1. 要显示所有最近为提供的 DeploymentConfig 对象创建的复制控制器的详细信息，包括任何当前运行的部署过程，请运行以下命令：

   $ oc rollout history dc/<name>

2. 要查看修订的相关细节，请使用 --revision 标志：

   $ oc rollout history dc/<name> --revision=1

3. 如需有关 DeploymentConfig 对象和最新修订的详细信息，请使用 oc describe 命令：

   $ oc describe dc <name>

流程

1. 重启已经失败的部署过程：

   $ oc rollout retry dc/<name>

   如果成功部署了最新的修订，该命令会显示一条消息，且不会重试部署过程。

   注意

   重试部署会重启部署过程，且不创建新的部署修订。重启的复制控制器具有与失败时相同的配置。

流程

1. 回滚到配置的最近一次部署成功的修订：

   $ oc rollout undo dc/<name>

   恢复 DeploymentConfig 对象的模板以匹配 undo 命令中指定的部署修订，并且会启动新的复制控制器。如果没有通过 --to-revision 指定修订，则使用最近一次成功部署的修订。

2. 部署过程中会禁用 DeploymentConfig 对象中的镜像更改触发器，以防止在回滚完成不久后意外启动新的部署过程。

   重新启用镜像更改触发器：

   $ oc set triggers dc/<name> --auto

流程

1. 在 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
   # ...

流程

1. 输出给定 DeploymentConfig 对象的最新修订的日志：

   $ oc logs -f dc/<name>

   如果最新的修订正在运行或已失败，命令会返回负责部署 Pod 的进程的日志。如果成功，它将从应用程序的 pod 返回日志。

2. 您还可以查看来自旧的失败部署进程的日志，只要存在这些进程（旧的复制控制器及其部署器 pod）并且没有手动清理或删除：

   $ oc logs --version=1 dc/<name>

流程

1. 在以下示例中，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 创建失败，显示无法满足配额要求。

流程

1. 要手动扩展 DeploymentConfig 对象，请使用 oc scale 命令。例如，以下命令将 frontend DeploymentConfig 对象中的副本设置为 3。

   $ oc scale dc frontend --replicas=3

   副本数量最终会传播到 DeploymentConfig 对象 frontend 配置的部署的预期和当前状态。

流程

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

流程

1. 要在创建 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 永不会被调度。

流程

1. 编辑 DeploymentConfig 对象：

   $ oc edit dc/<deployment_config>

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

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