3.2. Managing deployment processes

Procedure

1. To start a new deployment process from an existing DeploymentConfig object, run the following command:

   $ oc rollout latest dc/<name>

   注意

   If a deployment process is already in progress, the command displays a message and a new replication controller will not be deployed.

Procedure

1. To show details about all recently created replication controllers for the provided DeploymentConfig object, including any currently running deployment process, run the following command:

   $ oc rollout history dc/<name>

2. To view details specific to a revision, add the --revision flag:

   $ oc rollout history dc/<name> --revision=1

3. For more detailed information about a DeploymentConfig object and its latest revision, use the oc describe command:

   $ oc describe dc <name>

Procedure

1. To restart a failed deployment process:

   $ oc rollout retry dc/<name>

   If the latest revision of it was deployed successfully, the command displays a message and the deployment process is not retried.

   注意

   Retrying a deployment restarts the deployment process and does not create a new deployment revision. The restarted replication controller has the same configuration it had when it failed.

Procedure

1. To rollback to the last successful deployed revision of your configuration:

   $ oc rollout undo dc/<name>

   The DeploymentConfig object’s template is reverted to match the deployment revision specified in the undo command, and a new replication controller is started. If no revision is specified with --to-revision, then the last successfully deployed revision is used.

2. Image change triggers on the DeploymentConfig object are disabled as part of the rollback to prevent accidentally starting a new deployment process soon after the rollback is complete.

   To re-enable the image change triggers:

   $ oc set triggers dc/<name> --auto

Procedure

1. Add the command parameters to the spec field of the DeploymentConfig object. You can also add an args field, which modifies the command (or the ENTRYPOINT if command does not exist).

   spec:
     containers:
       -
       name: <container_name>
       image: 'image'
       command:
         - '<command>'
       args:
         - '<argument_1>'
         - '<argument_2>'
         - '<argument_3>'

   For example, to execute the java command with the -jar and /opt/app-root/springboots2idemo.jar arguments:

   spec:
     containers:
       -
       name: example-spring-boot
       image: 'image'
       command:
         - java
       args:
         - '-jar'
         - /opt/app-root/springboots2idemo.jar

Procedure

1. To stream the logs of the latest revision for a given DeploymentConfig object:

   $ oc logs -f dc/<name>

   If the latest revision is running or failed, the command returns the logs of the process that is responsible for deploying your pods. If it is successful, it returns the logs from a pod of your application.

2. You can also view logs from older failed deployment processes, if and only if these processes (old replication controllers and their deployer pods) exist and have not been pruned or deleted manually:

   $ oc logs --version=1 dc/<name>

Procedure

1. In the following example, each of resources, cpu, memory, and ephemeral-storage is optional:

   type: "Recreate"
   resources:
     limits:
       cpu: "100m" 1
       memory: "256Mi" 2
       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).

   However, if a quota has been defined for your project, one of the following two items is required:

   • A resources section set with an explicit requests:

       type: "Recreate"
       resources:
         requests: 1
           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.

   • A limit range defined in your project, where the defaults from the LimitRange object apply to pods created during the deployment process.

   To set deployment resources, choose one of the above options. Otherwise, deploy pod creation fails, citing a failure to satisfy quota.

Procedure

1. To manually scale a DeploymentConfig object, use the oc scale command. For example, the following command sets the replicas in the frontend DeploymentConfig object to 3.

   $ oc scale dc frontend --replicas=3

   The number of replicas eventually propagates to the desired and current state of the deployment configured by the DeploymentConfig object frontend.

Procedure

1. Create a new project.
2. From the Workloads page, create a secret that contains credentials for accessing a private image repository.
3. Create a DeploymentConfig object.
4. On the DeploymentConfig object editor page, set the Pull Secret and save your changes.

Procedure

1. To add a node selector when creating a pod, edit the Pod configuration, and add the nodeSelector value. This can be added to a single Pod configuration, or in a Pod template:

   apiVersion: v1
   kind: Pod
   spec:
     nodeSelector:
       disktype: ssd
   ...

   Pods created when the node selector is in place are assigned to nodes with the specified labels. The labels specified here are used in conjunction with the labels added by a cluster administrator.

   For example, if a project has the type=user-node and region=east labels added to a project by the cluster administrator, and you add the above disktype: ssd label to a pod, the pod is only ever scheduled on nodes that have all three labels.

   注意

   Labels can only be set to one value, so setting a node selector of region=west in a Pod configuration that has region=east as the administrator-set default, results in a pod that will never be scheduled.

Procedure

1. Edit the DeploymentConfig object:

   $ oc edit dc/<deployment_config>

2. Add the serviceAccount and serviceAccountName parameters to the spec field, and specify the service account you want to use:

   spec:
     securityContext: {}
     serviceAccount: <service_account>
     serviceAccountName: <service_account>