CHAPTER 3. DEPLOYMENTS $ oc new-app openshift/deployment-example --name=ab-example-a --as-deployment- config=true --labels=ab-example=true --env=SUBTITLE\=shardA $ oc delete svc/ab-example-a The application is deployed and a service is created. This is the first shard. 2. Make the application available via a route, or use the service IP directly: 3. Browse to the application at  ab-example-<project_name>.<router_domain>  to verify you see the  v1  image. 4. Create a second shard based on the same source image and label as the first shard, but with a different tagged version and unique environment variables: 5. At this point, both sets of pods are being served under the route. However, because both browsers (by leaving a connection open) and the router (by default, through a cookie) attempt to preserve your connection to a back-end server, you might not see both shards being returned to you. 6. If you trigger a deployment on either shard, only the pods in that shard are affected. You can trigger a deployment by changing the  SUBTITLE  environment variable in either  DeploymentConfig  object: a. Use the  oc scale  command to reduce replicas of  ab-example-a  to  0 . b. Scale  ab-example-a  to  1  replica and  ab-example-b  to  0 : To force your browser to one or the other shard: $ oc scale dc/ab-example-a --replicas=0 $ oc scale dc/ab-example-a --replicas=1; oc scale dc/ab-example-b --replicas=0 Refresh your browser to show  v2  and  shard B  (in red). Refresh your browser to show  v1  and  shard A  (in blue). $ oc edit dc/ab-example-a or $ oc edit dc/ab-example-b $ oc new-app openshift/deployment-example:v2 \ --name=ab-example-b --labels=ab-example=true \ SUBTITLE="shard B" COLOR="red" --as-deployment-config=true $ oc delete svc/ab-example-b $ oc expose deploymentconfig ab-example-a --name=ab-example --selector=ab- example\=true $ oc expose service ab-example 73