4.2. 管理部署过程
4.2.1. 管理 DeploymentConfig
使用 OpenShift Container Platform Web 控制台的 Workloads 页面或 oc
CLI 可以管理 DeploymentConfig。以下流程演示了 CLI 的用法(除非另有说明)。
4.2.1.1. 启动部署
您可以启动一个推出部署来启动应用程序的部署过程。
流程
要从现有的 DeploymentConfig 启动新的部署过程,请运行以下命令:
$ oc rollout latest dc/<name>
注意如果部署过程已在进行中,此命令会显示一条消息,不会部署新的 ReplicationController。
4.2.1.2. 查看部署
您可以查看部署来获取应用程序所有可用修订的基本信息。
流程
要显示所有最近为提供的 DeploymentConfig 创建的 ReplicationController 的详细信息,包括任何当前运行的部署过程,请运行以下命令:
$ oc rollout history dc/<name>
要查看修订的相关细节,请使用
--revision
标志:$ oc rollout history dc/<name> --revision=1
如需关于部署配置和最新修订的详细信息,可使用
oc describe
命令:$ oc describe dc <name>
4.2.1.3. 重试部署
如果无法部署 DeploymentConfig 的当前修订,您可以重启部署过程。
流程
重启已经失败的部署过程:
$ oc rollout retry dc/<name>
如果成功部署了最新的修订,命令会显示一条消息,而且不重试部署过程。
注意重试部署会重启部署过程,且不创建新的部署修订。重启的 ReplicationController 会拥有与失败时相同的配置。
4.2.1.4. 回滚部署
回滚将应用恢复到上一修订,可通过 REST API、命令行或 Web 控制台进行。
流程
回滚到配置的最近一次部署成功的修订:
$ oc rollout undo dc/<name>
恢复 DeploymentConfig 的模板以匹配 undo 命令中指定的部署修订,并且启动新的 ReplicationController。如果没有通过
--to-revision
指定修订,则使用最近一次成功部署的修订。部署过程中会禁用 DeploymentConfig 中的镜像更改触发器,以防止在回滚完成不久后意外启动新的部署过程。
重新启用镜像更改触发器:
$ oc set triggers dc/<name> --auto
DeploymentConfig 也支持最新部署过程失败时自动回滚到配置的最近一次成功修订。这时,系统会原样保留部署失败的最新模板,由用户来修复其配置。
4.2.1.5. 在容器内执行命令
您可以为容器添加命令,用来覆盖决镜像的 ENTRYPOINT
设置来改变容器的启动行为。这与生命周期 hook 不同,后者在每个部署的指定时间点上运行一次。
流程
在 DeploymentConfig 的
spec
字段中添加command
参数。您也可以添加args
字段来修改command
(如果command
不存在,则修改ENTRYPOINT
)。spec: containers: - name: <container_name> image: 'image' command: - '<command>' args: - '<argument_1>' - '<argument_2>' - '<argument_3>'
例如,使用
-jar
和/opt/app-root/springboots2idemo.jar
参数来执行java
命令:spec: containers: - name: example-spring-boot image: 'image' command: - java args: - '-jar' - /opt/app-root/springboots2idemo.jar
4.2.1.6. 查看部署日志
流程
获得指定 DeploymentConfig 的最新修订的日志:
$ oc logs -f dc/<name>
如果最新的修订正在运行或已失败,命令会返回负责部署 Pod 的进程的日志。如果成功,它将从应用程序的 Pod 返回日志。
您还可以查看来自旧的失败部署进程的日志,只要存在这些进程(旧的 ReplicationController 及其部署器 Pod)并且没有手动清理或删除:
$ oc logs --version=1 dc/<name>
4.2.1.7. 部署触发器
DeploymentConfig 可以包含触发器,推动创建新部署过程来响应集群内的事件。
如果 DeploymentConfig 上没有定义任何触发器,则默认添加 ConfigChange
触发器。如果触发器定义为空白字段,则必须手动启动部署。
ConfigChange 部署触发器
当 DeploymentConfig 的 Pod 模板中检测到配置更改时,ConfigChange
触发器会产生新的 ReplicationController。
如果 DeploymentConfig 上定义了 ConfigChange
触发器,则在 DeploymentConfig 本身创建后会自动创建第一个 ReplicationController,而且不会暂停。
ConfigChange 部署触发器
triggers: - type: "ConfigChange"
imageChange 部署触发器
ImageChange
触发器会在镜像流标签的内容发生改变时(推送镜像的新版本时)产生新的 ReplicationController。
imageChange 部署触发器
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
创建新的 ReplicationController。
如果 DeploymentConfig 上定义了 ImageChange
触发器(带有 ConfigChange
触发器且 automatic=false
,或者 automatic=true
)并且 ImageChange
触发器指向的 ImageStreamTag
尚不存在,则初始部署过程将在镜像导入时或镜像由构建推送到 ImageStreamTag
时立即自动启动。
4.2.1.7.1. 设置部署触发器
流程
您可以使用
oc set triggers
命令为 DeploymentConfig 设置部署触发器。例如,若要设置ImageChangeTrigger
,请使用以下命令:$ oc set triggers dc/<dc_name> \ --from-image=<project>/<image>:<tag> -c <container_name>
4.2.1.8. 设置部署资源
只有在集群管理员启用了临时存储技术预览功能时,这个资源才可用。此功能默认为禁用。
部署由在节点上消耗资源(内存、CPU 和临时存储)的 Pod 完成。默认情况下,Pod 消耗无限的节点资源。但是,如果某个项目指定了默认容器限值,则 Pod 消耗的资源会被限制在这些限值范围内。
您还可以在部署策略中指定资源限值来限制资源使用。部署资源可以用在 Recreate 、Rolling 或 Custom 部署策略中。
流程
在以下示例中,
resources
、cpu
、memory
和ephemeral-storage
中每一个都是可选的:type: "Recreate" resources: limits: cpu: "100m" 1 memory: "256Mi" 2 ephemeral-storage: "1Gi" 3
不过,如果您的项目定义了配额,则需要以下两项之一:
设定了显式
requests
的resources
部分:type: "Recreate" resources: requests: 1 cpu: "100m" memory: "256Mi" ephemeral-storage: "1Gi"
- 1
requests
对象包含与配额中资源列表对应的资源列表。
-
您项目中定义的限值范围,其中
LimitRange
对象中的默认值应用到部署过程中创建的 Pod。
要设置部署资源,请选择以上选项之一。否则,部署 Pod 创建失败,显示无法满足配额要求。
4.2.1.9. 手动扩展
除了回滚外,您还可以通过手动缩放来对副本数量进行细致的控制。
也可以使用 oc autoscale
命令自动扩展 Pod。
流程
要手动扩展 DeploymentConfig,请使用
oc scale
命令。例如,以下命令将frontend
DeploymentConfig 中的副本数设置为3
。$ oc scale dc frontend --replicas=3
副本数量最终会传播到 DeploymentConfig
frontend
配置的部署的预期和当前状态。
4.2.1.10. 从 DeploymentConfig 访问私有存储库
您可以在 DeploymentConfig 中添加 secret,让它能够访问私有存储库中的镜像。此流程演示了 OpenShift Container Platform Web 控制台方法。
流程
- 创建新项目。
- 在 Workloads 页面中,创建一个含有用于访问私有镜像存储库的凭证的 secret。
- 创建 DeploymentConfig。
- 在 DeploymentConfig 编辑器页面中,设置 Pull Secret 并保存您的更改。
4.2.1.11. 将 Pod 分配给特定的节点
您可以结合使用节点选择器和带标签的节点来控制 Pod 的放置。
集群管理员可为项目设置默认的节点选择器,以便将 Pod 放置限制到特定的节点。作为开发人员,您可以设置 Pod 配置的节点选择器来进一步限制节点。
流程
要在创建 Pod 时添加节点选择器,请编辑 Pod 配置并添加
nodeSelector
值。这可添加到单个 Pod 配置中,也可以添加到 Pod 模板中:apiVersion: v1 kind: Pod spec: nodeSelector: disktype: ssd ...
具有节点选择器时创建的 Pod 会分配给带有指定标签的节点。这里指定的标签将与集群管理员添加的标签结合使用。
例如,如果项目中包含由集群管理员添加的
type=user-node
和region=east
标签,并且您将上述disktype: ssd
标签添加到某一 Pod,那么该 Pod 仅会调度到具有所有这三个标签的节点上。注意标签只能设置为一个值;因此,如果在具有管理员设置的默认值
region=east
的 Pod 配置中设置节点选择器region=west
,这会导致 Pod 永不会被调度。
4.2.1.12. 使用其他服务帐户运行 Pod
您可以使用非默认服务帐户运行 Pod。
流程
编辑 DeploymentConfig:
$ oc edit dc/<deployment_config>
将
serviceAccount
和serviceAccountName
参数添加到spec
字段,再指定您要使用的服务帐户:spec: securityContext: {} serviceAccount: <service_account> serviceAccountName: <service_account>