Chapter 8. Deployments

Procedure

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

   $ oc rollout latest dc/<name>

   Copy to Clipboard Toggle word wrap
   Note

   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>

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

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

   $ oc describe dc <name>

   Copy to Clipboard Toggle word wrap

Procedure

1. To restart a failed deployment process:

   $ oc rollout retry dc/<name>

   Copy to Clipboard Toggle word wrap

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

   Note

   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>

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

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>'

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

Procedure

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

   $ oc logs -f dc/<name>

   Copy to Clipboard Toggle word wrap

   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>

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

   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"

     Copy to Clipboard Toggle word wrap

     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

   Copy to Clipboard Toggle word wrap

   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
   ...

   Copy to Clipboard Toggle word wrap

   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.

   Note

   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>

   Copy to Clipboard Toggle word wrap

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>

   Copy to Clipboard Toggle word wrap

Procedure

1. Create an application based on the example deployment images found in Quay.io:

   $ oc new-app quay.io/openshifttest/deployment-example:latest

   Copy to Clipboard Toggle word wrap

2. If you have the router installed, make the application available via a route or use the service IP directly.

   $ oc expose svc/deployment-example

   Copy to Clipboard Toggle word wrap
3. Browse to the application at deployment-example.<project>.<router_domain> to verify you see the v1 image.

4. Scale the DeploymentConfig object up to three replicas:

   $ oc scale dc/deployment-example --replicas=3

   Copy to Clipboard Toggle word wrap

5. Trigger a new deployment automatically by tagging a new version of the example as the latest tag:

   $ oc tag deployment-example:v2 deployment-example:latest

   Copy to Clipboard Toggle word wrap
6. In your browser, refresh the page until you see the v2 image.

7. When using the CLI, the following command shows how many pods are on version 1 and how many are on version 2. In the web console, the pods are progressively added to v2 and removed from v1:

   $ oc describe dc deployment-example

   Copy to Clipboard Toggle word wrap

Procedure

1. Navigate to the Topology view. Click on your application to see the Details panel.
2. In the Actions drop-down menu, select Edit Deployment to view the Edit Deployment page.

3. You can edit the following Advanced options for your deployment:

   1. Optional: You can pause rollouts by clicking Pause rollouts, and then selecting the Pause rollouts for this deployment checkbox.

      By pausing rollouts, you can make changes to your application without triggering a rollout. You can resume rollouts at any time.

   2. Optional: Click Scaling to change the number of instances of your image by modifying the number of Replicas.
4. Click Save.

Procedure

1. In the Topology view of the Developer perspective, click on the application node to see the Overview tab in the side panel. Note that the Update Strategy is set to the default Rolling strategy.

2. In the Actions drop-down menu, select Start Rollout to start a rolling update. The rolling deployment spins up the new version of the application and then terminates the old one.

   Figure 8.1. Rolling update

   

   View larger image

   

Procedure

1. Navigate to the Topology view. Click on your application to see the Details panel.
2. In the Actions drop-down menu, select Edit Deployment to view the Edit Deployment page.

3. You can edit the following Advanced options for your deployment:

   1. Optional: You can pause rollouts by clicking Pause rollouts, and then selecting the Pause rollouts for this deployment checkbox.

      By pausing rollouts, you can make changes to your application without triggering a rollout. You can resume rollouts at any time.

   2. Optional: Click Scaling to change the number of instances of your image by modifying the number of Replicas.
4. Click Save.

1. In the Actions drop-down menu, select Edit Deployment Config to see the deployment configuration details of the application.
2. In the YAML editor, change the spec.strategy.type to Recreate and click Save.
3. In the Topology view, select the node to see the Overview tab in the side panel. The Update Strategy is now set to Recreate.

4. Use the Actions drop-down menu to select Start Rollout to start an update using the recreate strategy. The recreate strategy first terminates pods for the older version of the application and then spins up pods for the new version.

   Figure 8.2. Recreate update

   

   View larger image

   

Procedure

1. Navigate to the Topology view. Click on your application to see the Details panel.
2. In the Actions drop-down menu, select Edit Deployment to view the Edit Deployment page.

3. You can edit the following Advanced options for your deployment:

   1. Optional: You can pause rollouts by clicking Pause rollouts, and then selecting the Pause rollouts for this deployment checkbox.

      By pausing rollouts, you can make changes to your application without triggering a rollout. You can resume rollouts at any time.

   2. Optional: Click Scaling to change the number of instances of your image by modifying the number of Replicas.
4. Click Save.

Procedure

1. Use the oc set deployment-hook command to set the type of hook you want: --pre, --mid, or --post. For example, to set a pre-deployment hook:

   $ oc set deployment-hook dc/frontend \
       --pre -c helloworld -e CUSTOM_VAR1=custom_value1 \
       --volumes data --failure-policy=abort -- /usr/bin/command arg1 arg2

   Copy to Clipboard Toggle word wrap

Procedure

1. Create two independent application components.

   1. Create a copy of the example application running the v1 image under the example-blue service:

      $ oc new-app openshift/deployment-example:v1 --name=example-blue

      Copy to Clipboard Toggle word wrap

   2. Create a second copy that uses the v2 image under the example-green service:

      $ oc new-app openshift/deployment-example:v2 --name=example-green

      Copy to Clipboard Toggle word wrap

2. Create a route that points to the old service:

   $ oc expose svc/example-blue --name=bluegreen-example

   Copy to Clipboard Toggle word wrap
3. Browse to the application at bluegreen-example-<project>.<router_domain> to verify you see the v1 image.

4. Edit the route and change the service name to example-green:

   $ oc patch route/bluegreen-example -p '{"spec":{"to":{"name":"example-green"}}}'

   Copy to Clipboard Toggle word wrap
5. To verify that the route has changed, refresh the browser until you see the v2 image.

1. Create the two applications and give them different names. Each creates a Deployment object. The applications are versions of the same program; one is usually the current production version and the other the proposed new version.

   1. Create the first application. The following example creates an application called ab-example-a:

      $ oc new-app openshift/deployment-example --name=ab-example-a

      Copy to Clipboard Toggle word wrap

   2. Create the second application:

      $ oc new-app openshift/deployment-example:v2 --name=ab-example-b

      Copy to Clipboard Toggle word wrap

      Both applications are deployed and services are created.

2. Make the application available externally via a route. At this point, you can expose either. It can be convenient to expose the current production version first and later modify the route to add the new version.

   $ oc expose svc/ab-example-a

   Copy to Clipboard Toggle word wrap

   Browse to the application at ab-example-a.<project>.<router_domain> to verify that you see the expected version.

3. When you deploy the route, the router balances the traffic according to the weights specified for the services. At this point, there is a single service with default weight=1 so all requests go to it. Adding the other service as an alternateBackends and adjusting the weights brings the A/B setup to life. This can be done by the oc set route-backends command or by editing the route.

   Note

   When using alternateBackends, also use the roundrobin load-balancing strategy to ensure requests are distributed as expected to the services based on weight. roundrobin can be set for a route by using a route annotation.

   Setting the oc set route-backend to 0 means the service does not participate in load-balancing, but continues to serve existing persistent connections.

   Note

   Changes to the route just change the portion of traffic to the various services. You might have to scale the deployment to adjust the number of pods to handle the anticipated loads.

   To edit the route, run:

   $ oc edit route <route_name>

   Copy to Clipboard Toggle word wrap

   Example output

   ...
   metadata:
     name: route-alternate-service
     annotations:
       haproxy.router.openshift.io/balance: roundrobin
   spec:
     host: ab-example.my-project.my-domain
     to:
       kind: Service
       name: ab-example-a
       weight: 10
     alternateBackends:
     - kind: Service
       name: ab-example-b
       weight: 15
   ...

   Copy to Clipboard Toggle word wrap