diff --git a/applications/deployments/managing-deployment-processes.adoc b/applications/deployments/managing-deployment-processes.adoc index 2035382a012..9a72e34e5ca 100644 --- a/applications/deployments/managing-deployment-processes.adoc +++ b/applications/deployments/managing-deployment-processes.adoc @@ -11,6 +11,7 @@ toc::[] include::snippets/deployment-config-deprecated.adoc[] +[role="_abstract"] `DeploymentConfig` objects can be managed from the {product-title} web console's *Workloads* page or using the `oc` CLI. The following procedures show CLI usage unless otherwise stated. include::modules/deployments-starting-deployment.adoc[leveloffset=+2] @@ -32,11 +33,12 @@ include::modules/deployments-setting-triggers.adoc[leveloffset=+3] include::modules/deployments-setting-resources.adoc[leveloffset=+2] // When the Nodes book is added to ROSA/OSD, check if this link is valid. + ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] [role="_additional-resources"] .Additional resources - -* For more information about resource limits and requests, see xref:../../nodes/clusters/nodes-cluster-resource-configure.adoc#nodes-cluster-resource-configure-about_nodes-cluster-resource-configure[Understanding managing application memory]. +* xref:../../nodes/clusters/nodes-cluster-resource-configure.adoc#nodes-cluster-resource-configure-about_nodes-cluster-resource-configure[Understanding managing application memory] +//in __. endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] include::modules/deployments-scaling-manually.adoc[leveloffset=+2] diff --git a/modules/deployments-accessing-private-repos.adoc b/modules/deployments-accessing-private-repos.adoc index 8b3771943e5..03a2f8299a6 100644 --- a/modules/deployments-accessing-private-repos.adoc +++ b/modules/deployments-accessing-private-repos.adoc @@ -6,7 +6,8 @@ [id="deployments-accessing-private-repos_{context}"] = Accessing private repositories from DeploymentConfig objects -You can add a secret to your `DeploymentConfig` object so that it can access images from a private repository. This procedure shows the {product-title} web console method. +[role="_abstract"] +To pull container images from a private repository into a `DeploymentConfig` object in {product-title}, you can add a pull secret. Create the secret in the web console, then set it as the pull secret on the `DeploymentConfig` object. .Procedure diff --git a/modules/deployments-assigning-pods-to-nodes.adoc b/modules/deployments-assigning-pods-to-nodes.adoc index 1d92e7d4a90..38b2d5259a6 100644 --- a/modules/deployments-assigning-pods-to-nodes.adoc +++ b/modules/deployments-assigning-pods-to-nodes.adoc @@ -6,8 +6,8 @@ [id="deployments-assigning-pods-to-nodes_{context}"] = Assigning pods to specific nodes -You can use node selectors in conjunction with labeled nodes to control pod -placement. +[role="_abstract"] +To control which nodes run your application pods in {product-title}, you can set a node selector on a `Pod` configuration or pod template. Combine your selector with labels on nodes, including any default project selectors set by a cluster administrator. Cluster administrators can set the default node selector for a project in order to restrict pod placement to specific nodes. As a developer, you can set a node diff --git a/modules/deployments-exec-cmd-in-container.adoc b/modules/deployments-exec-cmd-in-container.adoc index 4f0767aaf56..a4241dc2957 100644 --- a/modules/deployments-exec-cmd-in-container.adoc +++ b/modules/deployments-exec-cmd-in-container.adoc @@ -6,7 +6,8 @@ [id="deployments-exe-cmd-in-container_{context}"] = Executing commands inside a container -You can add a command to a container, which modifies the container's startup behavior by overruling the image's `ENTRYPOINT`. This is different from a lifecycle hook, which instead can be run once per deployment at a specified time. +[role="_abstract"] +To change how a container starts in a `DeploymentConfig` object in {product-title}, you can set a `command` and optional `args` in the pod template. These values override the image `ENTRYPOINT` and differ from lifecycle hooks, which run once per deployment at a specified time. .Procedure diff --git a/modules/deployments-retrying-deployment.adoc b/modules/deployments-retrying-deployment.adoc index bb9b2ae7838..8318a0c2887 100644 --- a/modules/deployments-retrying-deployment.adoc +++ b/modules/deployments-retrying-deployment.adoc @@ -6,7 +6,8 @@ [id="deployments-retrying-deployment_{context}"] = Retrying a deployment -If the current revision of your `DeploymentConfig` object failed to deploy, you can restart the deployment process. +[role="_abstract"] +To restart a failed rollout of a `DeploymentConfig` object in {product-title}, you can retry the deployment. Use the `oc rollout retry` command to restart the same revision without creating a new deployment revision. .Procedure diff --git a/modules/deployments-rolling-back.adoc b/modules/deployments-rolling-back.adoc index 69123a04490..55cb4c08f9c 100644 --- a/modules/deployments-rolling-back.adoc +++ b/modules/deployments-rolling-back.adoc @@ -6,6 +6,7 @@ [id="deployments-rolling-back_{context}"] = Rolling back a deployment +[role="_abstract"] Rollbacks revert an application back to a previous revision and can be performed using the REST API, the CLI, or the web console. .Procedure diff --git a/modules/deployments-running-pod-svc-acct.adoc b/modules/deployments-running-pod-svc-acct.adoc index 6d2762c0378..883498661e9 100644 --- a/modules/deployments-running-pod-svc-acct.adoc +++ b/modules/deployments-running-pod-svc-acct.adoc @@ -6,7 +6,8 @@ [id="deployments-running-pod-svc-acct_{context}"] = Running a pod with a different service account -You can run a pod with a service account other than the default. +[role="_abstract"] +To run pods under a non-default identity in {product-title}, you can assign a different service account to a `DeploymentConfig` object. Edit the object and set the `serviceAccount` and `serviceAccountName` fields to the account you want to use. .Procedure diff --git a/modules/deployments-scaling-manually.adoc b/modules/deployments-scaling-manually.adoc index e1d10cad691..022b2800a2a 100644 --- a/modules/deployments-scaling-manually.adoc +++ b/modules/deployments-scaling-manually.adoc @@ -6,7 +6,8 @@ [id="deployments-scaling-manually_{context}"] = Scaling manually -In addition to rollbacks, you can exercise fine-grained control over the number of replicas by manually scaling them. +[role="_abstract"] +To control how many pod replicas run for a `DeploymentConfig` object in {product-title}, you can scale manually. Use the `oc scale` command to set the desired number of replicas. [NOTE] ==== diff --git a/modules/deployments-setting-resources.adoc b/modules/deployments-setting-resources.adoc index 036c181eacb..a50b168fc26 100644 --- a/modules/deployments-setting-resources.adoc +++ b/modules/deployments-setting-resources.adoc @@ -6,6 +6,9 @@ [id="deployments-setting-resources_{context}"] = Setting deployment resources +[role="_abstract"] +To limit CPU, memory, and ephemeral storage used by a deployment in {product-title}, you can set resource limits on the deployment strategy. Define limits in the `resources` section so deployer pods do not consume unbounded node capacity. + A deployment is completed by a pod that consumes resources (memory, CPU, and ephemeral storage) on a node. By default, pods consume unbounded node resources. However, if a project specifies default container limits, then pods consume resources up to those limits. [NOTE] @@ -31,13 +34,13 @@ spec: type: "Recreate" resources: limits: - cpu: "100m" <1> - memory: "256Mi" <2> + cpu: "100m" + memory: "256Mi" ephemeral-storage: "1Gi" <3> ---- -<1> `cpu` is in CPU units: `100m` represents 0.1 CPU units (100 * 1e-3). -<2> `memory` is in bytes: `256Mi` represents 268435456 bytes (256 * 2 ^ 20). -<3> `ephemeral-storage` is in bytes: `1Gi` represents 1073741824 bytes (2 ^ 30). +* `spec.resources.limits.cpu` specifies the CPU units: `100m` represents 0.1 CPU units (100 * 1e-3). +* `spec.resources.limits.memory` specifies the bytes for memory: `256Mi` represents 268435456 bytes (256 * 2 ^ 20). +* `spec.resources.limits.ephemeral-storage` specifies the bytes for ephemeral-storage: `1Gi` represents 1073741824 bytes (2 ^ 30). + However, if a quota has been defined for your project, one of the following two items is required: + @@ -55,12 +58,13 @@ spec: # ... type: "Recreate" resources: - requests: <1> + requests: cpu: "100m" memory: "256Mi" ephemeral-storage: "1Gi" ---- -<1> The `requests` object contains the list of resources that correspond to the list of resources in the quota. ++ +The `spec.resources.requests` object contains the list of resources that correspond to the list of resources in the quota. - A limit range defined in your project, where the defaults from the `LimitRange` object apply to pods created during the deployment process. -- diff --git a/modules/deployments-setting-triggers.adoc b/modules/deployments-setting-triggers.adoc index e6696cc31e1..7072a389037 100644 --- a/modules/deployments-setting-triggers.adoc +++ b/modules/deployments-setting-triggers.adoc @@ -6,6 +6,9 @@ [id="deployments-setting-triggers_{context}"] = Setting deployment triggers +[role="_abstract"] +To automatically start a new rollout when an image changes in {product-title}, you can set deployment triggers on a `DeploymentConfig` object. Use the `oc set triggers` command to configure an image change trigger for a container. + .Procedure . You can set deployment triggers for a `DeploymentConfig` object using the `oc set triggers` command. For example, to set a image change trigger, use the following command: diff --git a/modules/deployments-starting-deployment.adoc b/modules/deployments-starting-deployment.adoc index 80bc6be3810..8abac758b1b 100644 --- a/modules/deployments-starting-deployment.adoc +++ b/modules/deployments-starting-deployment.adoc @@ -6,7 +6,8 @@ [id="deployments-starting-a-deployment_{context}"] = Starting a deployment -You can start a rollout to begin the deployment process of your application. +[role="_abstract"] +To begin a new rollout of your application in {product-title}, you can start a deployment from an existing `DeploymentConfig` object. Use the `oc rollout latest` command to create a new replication controller and run the deployment process. .Procedure diff --git a/modules/deployments-triggers.adoc b/modules/deployments-triggers.adoc index 5a07c2efe4a..55aba23a75e 100644 --- a/modules/deployments-triggers.adoc +++ b/modules/deployments-triggers.adoc @@ -6,7 +6,8 @@ [id="deployments-triggers_{context}"] = Deployment triggers -A `DeploymentConfig` object can contain triggers, which drive the creation of new deployment processes in response to events inside the cluster. +[role="_abstract"] +A deployment trigger on a `DeploymentConfig` object in {product-title} starts a new deployment process when cluster events occur. Use config change or image change triggers to roll out automatically, or leave triggers empty if you want to start deployments only manually. [WARNING] ==== @@ -55,7 +56,7 @@ spec: triggers: - type: "ImageChange" imageChangeParams: - automatic: true <1> + automatic: true from: kind: "ImageStreamTag" name: "origin-ruby-sample:latest" @@ -63,7 +64,7 @@ spec: containerNames: - "helloworld" ---- -<1> If the `imageChangeParams.automatic` field is set to `false`, the trigger is disabled. +If the `triggers.imageChangeParams.automatic` field is set to `false`, the trigger is disabled. With the above example, when the `latest` tag value of the `origin-ruby-sample` image stream changes and the new image value differs from the current image specified in the `DeploymentConfig` object's `helloworld` container, a new replication controller is created using the new image for the `helloworld` container. diff --git a/modules/deployments-viewing-deployment.adoc b/modules/deployments-viewing-deployment.adoc index ab060091318..d38466d3bc4 100644 --- a/modules/deployments-viewing-deployment.adoc +++ b/modules/deployments-viewing-deployment.adoc @@ -6,7 +6,8 @@ [id="deployments-viewing-a-deployment_{context}"] = Viewing a deployment -You can view a deployment to get basic information about all the available revisions of your application. +[role="_abstract"] +To review the rollout history of your application in {product-title}, you can view a deployment. Use the `oc rollout history` and `oc describe` commands to inspect revisions of a `DeploymentConfig` object. .Procedure diff --git a/modules/deployments-viewing-logs.adoc b/modules/deployments-viewing-logs.adoc index 471a0d521d4..5293d3cf0c1 100644 --- a/modules/deployments-viewing-logs.adoc +++ b/modules/deployments-viewing-logs.adoc @@ -6,6 +6,9 @@ [id="deployments-viewing-logs_{context}"] = Viewing deployment logs +[role="_abstract"] +To troubleshoot a rollout in {product-title}, you can view deployment logs for a `DeploymentConfig` object. Use the `oc logs` command to stream logs from the latest revision or from an older failed deployment process. + .Procedure . To stream the logs of the latest revision for a given `DeploymentConfig` object: