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>

   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>

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.

   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>

   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.

   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>

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>

Procedure

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

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

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

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

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

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

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

   

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

   

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

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

   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

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

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

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

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

   2. Create the second application:

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

      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

   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>

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