管理部署流程 - 部署 | 构建应用程序 | OpenShift Dedicated

管理 DeploymentConfig 对象

管理 DeploymentConfig 对象

从 OpenShift Dedicated 4.14 版本开始，DeploymentConfig 对象已弃用。仍然支持 DeploymentConfig 对象，但不推荐用于新安装。仅修复与安全相关的和关键问题。

请改用 Deployment 对象或其他替代方案来提供 Pod 的声明式更新。

可以使用 OpenShift Dedicated Web 控制台的“工作负载”页面或使用 oc 命令行工具来管理 DeploymentConfig 对象。除非另有说明，否则以下步骤显示命令行工具的使用方法。

启动部署

您可以启动滚动更新以开始应用程序的部署过程。

步骤

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

查看部署

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

步骤

要显示为提供的 DeploymentConfig 对象创建的所有最近的副本控制器的详细信息，包括任何当前正在运行的部署过程，请运行以下命令：
```
$ oc rollout history dc/<name>
```
要查看特定修订版本的详细信息，请添加 --revision 标志：
```
$ oc rollout history dc/<name> --revision=1
```
有关 DeploymentConfig 对象及其最新修订版本的更多详细信息，请使用 oc describe 命令：
```
$ oc describe dc <name>
```

重试部署

如果 DeploymentConfig 对象的当前修订版本未能部署，您可以重新启动部署过程。

步骤

要重新启动失败的部署过程：
```
$ oc rollout retry dc/<name>
```
如果它的最新修订版本已成功部署，则命令会显示一条消息，并且不会重试部署过程。

重试部署会重新启动部署过程，而不会创建新的部署修订版本。重新启动的副本控制器具有与其失败时相同的配置。

回滚部署

回滚会将应用程序恢复到之前的修订版本，可以使用 REST API、CLI 或 Web 控制台执行。

步骤

要回滚到配置的上次成功部署的修订版本：
```
$ oc rollout undo dc/<name>
```
DeploymentConfig 对象的模板将恢复为与撤消命令中指定的部署修订版本匹配，并启动一个新的副本控制器。如果没有使用 --to-revision 指定修订版本，则使用上次成功部署的修订版本。
作为回滚的一部分，DeploymentConfig 对象上的镜像更改触发器被禁用，以防止在回滚完成后不久意外启动新的部署过程。

要重新启用镜像更改触发器：
```
$ oc set triggers dc/<name> --auto
```

如果最新的部署过程失败，DeploymentConfig 也支持自动回滚到配置的上次成功修订版本。在这种情况下，系统会保留最新的未能部署的模板，用户需要自行修复其配置。

在容器内执行命令

您可以向容器添加命令，通过覆盖镜像的 ENTRYPOINT 来修改容器的启动行为。这与生命周期钩子不同，生命周期钩子可以在部署的每个指定时间运行一次。

步骤

将 command 参数添加到 DeploymentConfig 对象的 spec 字段。您还可以添加 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
# ...

查看部署日志

步骤

要流式传输给定DeploymentConfig对象的最新版本的日志
```
$ oc logs -f dc/<name>
```
如果最新版本正在运行或失败，则命令将返回负责部署 Pod 的进程的日志。如果成功，则返回应用程序 Pod 的日志。
您还可以查看旧的失败部署进程的日志，当且仅当这些进程（旧的复制控制器及其部署程序 Pod）存在并且未被手动修剪或删除时。
```
$ oc logs --version=1 dc/<name>
```

部署触发器

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），并且镜像更改触发器指向的镜像流标签尚不存在，则一旦构建将镜像导入或推送到镜像流标签，初始部署过程将自动启动。

设置部署触发器

步骤

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

设置部署资源

部署由在节点上消耗资源（内存、CPU 和临时存储）的 Pod 完成。默认情况下，Pod 会消耗无限的节点资源。但是，如果项目指定了默认容器限制，则 Pod 将消耗最多达到这些限制的资源。

部署的最小内存限制为 12 MB。如果容器由于无法分配内存的 Pod 事件而无法启动，则内存限制太低。增加或删除内存限制。删除限制允许 Pod 消耗无限的节点资源。

您还可以通过将资源限制指定为部署策略的一部分来限制资源使用。部署资源可以与重新创建、滚动或自定义部署策略一起使用。

步骤

在以下示例中，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 创建将失败，并指出无法满足配额。

手动扩展

除了回滚之外，您还可以通过手动扩展副本数来对副本数进行细粒度控制。

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

步骤

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

从 DeploymentConfig 对象访问私有仓库

您可以将密钥添加到DeploymentConfig对象，以便它可以访问私有仓库中的镜像。此过程显示了 OpenShift Dedicated Web 控制台方法。

步骤

创建一个新项目。
导航到工作负载→密钥。
创建一个包含访问私有镜像仓库的凭据的密钥。
导航到工作负载→DeploymentConfigs。
创建一个DeploymentConfig对象。
在DeploymentConfig对象编辑器页面上，设置拉取密钥并保存更改。

使用不同的服务帐户运行 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>