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

   kind: DeploymentConfig
   apiVersion: apps.openshift.io/v1
   metadata:
     name: example-dc
   # ...
   spec:
     template:
   # ...
       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:

   kind: DeploymentConfig
   apiVersion: apps.openshift.io/v1
   metadata:
     name: example-dc
   # ...
   spec:
     template:
   # ...
       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:

   kind: Deployment
   apiVersion: apps/v1
   metadata:
     name: hello-openshift
   # ...
   spec:
   # ...
     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

     :

     kind: Deployment
     apiVersion: apps/v1
     metadata:
       name: hello-openshift
     # ...
     spec:
     # ...
       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. Navigate to Workloads Secrets.
3. Create a secret that contains credentials for accessing a private image repository.
4. Navigate to Workloads DeploymentConfigs.
5. Create a

   DeploymentConfig

   object.
6. 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
   metadata:
     name: my-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:

   apiVersion: apps.openshift.io/v1
   kind: DeploymentConfig
   metadata:
     name: example-dc
   # ...
   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

   Note

   This image does not expose any ports. If you want to expose your applications over an external LoadBalancer service or enable access to the application over the public internet, create a service by using the

   oc expose dc/deployment-example --port=<port>

   command after completing this procedure.

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.
2. Click your application to see the Details panel.
3. In the Actions drop-down menu, select Edit Deployment to view the Edit Deployment page.

4. 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.
5. Click Save.

Procedure

1. In the Topology view, click 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.
2. Click your application to see the Details panel.
3. In the Actions drop-down menu, select Edit Deployment to view the Edit Deployment page.

4. 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.
5. Click Save.

1. Click your application to see the Details panel.
2. In the Actions drop-down menu, select Edit Deployment Config to see the deployment configuration details of the application.
3. In the YAML editor, change the

   spec.strategy.type

   to

   Recreate

   and click Save.
4. In the Topology view, select the node to see the Overview tab in the side panel. The Update Strategy is now set to Recreate.

5. 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.
2. Click your application to see the Details panel.
3. In the Actions drop-down menu, select Edit Deployment to view the Edit Deployment page.

4. 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.
5. 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. See the Additional resources section for more information about route annotations.

   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

   apiVersion: route.openshift.io/v1
   kind: Route
   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
   # ...