管理部署流程 - 部署 | 构建应用程序 | OpenShift Container Platform 4.17

管理 DeploymentConfig 对象

管理 DeploymentConfig 对象

从 OpenShift Container Platform 4.14 开始，DeploymentConfig 对象已弃用。DeploymentConfig 对象仍然受支持，但不推荐用于新安装。只有安全相关和关键问题才会被修复。

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

DeploymentConfig 对象可以通过 OpenShift Container Platform 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
```

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

在容器内执行命令

您可以向容器添加命令，这会通过覆盖镜像的 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。如果由于Cannot allocate memory 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对象添加密钥，以便它可以访问私有仓库中的镜像。此过程显示了OpenShift Container Platform Web控制台方法。

步骤

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

将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标签，并且您向Pod添加了上述disktype: ssd标签，则Pod仅调度到具有所有三个标签的节点上。

标签只能设置为一个值，因此在具有管理员设置的默认值region=east的Pod配置中设置region=west的节点选择器，会导致Pod永远不会被调度。

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