管理部署流程 - 部署 | 构建应用程序 | Red Hat OpenShift Service on AWS

管理 DeploymentConfig 对象

管理 DeploymentConfig 对象

从 Red Hat OpenShift Service on AWS 4.14 开始，DeploymentConfig 对象已弃用。 DeploymentConfig 对象仍然受支持，但不建议用于新安装。只有安全相关和关键问题才会得到修复。

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

DeploymentConfig 对象可以从 Red Hat OpenShift Service on AWS Web 控制台的“工作负载”页面或使用 oc CLI 进行管理。除非另有说明，否则以下步骤显示 CLI 用法。

编辑

启动部署

您可以启动一次部署来开始应用程序的部署过程。

步骤

要从现有的 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
```

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

编辑

在容器内执行命令

您可以向容器添加命令，通过覆盖镜像的 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命令。例如，以下命令将frontend DeploymentConfig对象的副本数设置为3。
```
$ oc scale dc frontend --replicas=3
```
副本数量最终会传播到由DeploymentConfig对象frontend配置的部署的期望状态和当前状态。

编辑

从 DeploymentConfig 对象访问私有仓库

您可以向DeploymentConfig对象添加一个密钥，以便它可以访问私有仓库中的镜像。此过程显示了 AWS Web 控制台上的 Red Hat OpenShift 服务方法。

步骤

创建一个新项目。
导航到工作负载 → 密钥。
创建一个包含访问私有镜像仓库凭据的密钥。
导航到工作负载 → 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>