OpenShift Application Operations: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 116: Line 116:
Scaling up and down an application means controlling the application pod replicas, via oc scale command. The command defines the number of replicas in the [[OpenShift_Concepts#Replication_Controller|replication controller]] state. This procedure can be applied after a configuration change, such as a modification in the [[OpenShift Concepts#ConfigMap|ConfigMap]].
Scaling up and down an application means controlling the application pod replicas, via oc scale command. The command defines the number of replicas in the [[OpenShift_Concepts#Replication_Controller|replication controller]] state. This procedure can be applied after a configuration change, such as a modification in the [[OpenShift Concepts#ConfigMap|ConfigMap]].


  oc scale --replicas=<''replica-count''> dc <''deployment-configuration-name''>
  [[oc scale]] --replicas=<''replica-count''> dc <''deployment-configuration-name''>
or  
or  
  oc scale -replicas=<''replica-count''> deploymentconfig/<''deployment-configuration-name''>
  [[oc scale]] -replicas=<''replica-count''> deploymentconfig/<''deployment-configuration-name''>


<font color=red>TODO: Investigate the relationship between the deployment configuration and the replication controller.</font>
<font color=red>TODO: Investigate the relationship between the deployment configuration and the replication controller.</font>

Revision as of 02:30, 25 November 2017

Internal

Overview

oc new-app is a tool that generates an appropriate JSON configuration so OpenShift can build an image based on it. The configuration contains various resources of an application, maintained inside a project. For more details on projects and applications, see Projects and Applications. The command is a shortcut to configure a project with common resources for a standard development workflow. Source code, images and templates may be specified at this stage. The command looks for images on the new local Docker installation, if available, in the Docker registry and the OpenShift image stream.

When new-app is executed, OpenShift does the following:

1. Creates a build configuration and builds the source into a new version of the application.

2. As result of build configuration configuration execution, a new container image based on the image stream compatible with the source code is created.

3. Creates a deployment configuration that deploys the new image.

4. Deploys a pod.

5. Configures a service.

6. Optionally, a route is created to expose the service externally.

What Build Strategy?

If new-app finds a Dockerfile in the source repository, it uses the Docker build strategy. Otherwise it uses the source strategy. The strategy can also be explicitly set with --strategy option.

Create a New Application

Create a New Application from a Git Repository

If a source code URL is specified, OpenShift will pull the source code and convert it into an image to run inside a pod, attempting to guess what build strategy to use. Local source must be in a Git repository that has a remote repository that the server can see. new-app will create a build configuration and a deployment configuration. A service will be connected to the first public port of the app. oc status can be used to check on progress.

oc new-app https://github.com/test/testapp.git

Successful creation output:

--> Found image eaf9dfd (5 weeks old) in image stream "openshift/nodejs" under tag "6" for "nodejs"

    Node.js 6
    ---------
    Node.js 6 available as docker container is a base platform for building and running various Node.js 6 applications and frameworks. Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

    Tags: builder, nodejs, nodejs6

    * The source repository appears to match: nodejs
    * A source build using source code from https://github.com/test/testapp will be created
      * The resulting image will be pushed to image stream "testapp:latest"
      * Use 'start-build' to trigger a new build
    * This image will be deployed in deployment config "testapp"
    * Port 8080/tcp will be load balanced by service "testapp"
      * Other containers can access this service through the hostname "testapp"

--> Creating resources ...
    imagestream "testapp" created
    buildconfig "testapp" created
    deploymentconfig "testapp" created
    service "testapp" created
--> Success
    Build scheduled, use 'oc logs -f bc/testapp' to track its progress.
    Run 'oc status' to view your app.

Forcing a source-to-image build based on repository sources:

oc new-app nodejs:latest~https://github.com/wkulhanek/ocp-appdev-helloworld-nodejs.git \
 --strategy=source --name=hello-nodejs

Instantiate a Stored Template

new-app can also be used to instantiate a stored template:

oc new-app --template=example-template --param=USERNAME=somevalue

Application Life Cycle Events and State Monitoring

Remove an Application

To remove an application, all resources associated to the application must be deleted. The resources are:

  • routes
  • services
  • build configuration
  • deploy configuration
  • replication controller

Deleting a project deletes all resources associated with the project, even if they are associated with more than one application. If a project includes multiple applications, deleting the project deletes resources for all applications.

Deploy

oc deploy [--retry|--latest] dc/<deployment-configuration-name>

Used for deployments.

Options

--cancel

The cancellation is a bet-effort operation and may take some time to complete.

--retry

Re-runs the previously deployed deployment. Retrying the deployment just restarts the deployment, it does not create a new deployment version.

--enable-triggers

Re-enables triggers disabled by a rollback.

Scaling Up and Down the Number of Replicas associated with a DeploymentConfig

Scaling up and down an application means controlling the application pod replicas, via oc scale command. The command defines the number of replicas in the replication controller state. This procedure can be applied after a configuration change, such as a modification in the ConfigMap.

oc scale --replicas=<replica-count> dc <deployment-configuration-name>

or

oc scale -replicas=<replica-count> deploymentconfig/<deployment-configuration-name>

TODO: Investigate the relationship between the deployment configuration and the replication controller.

Procedure

Identify the name of the deployment config:

oc get dc -o name --selector=....

or

oc get dc

Then set the number of replicas to 0:

oc scale --replicas=0 deploymentconfig/<deploymentconfig-name> 

After all pods associated with deployment configuration have been stopped, scale it back up again.

oc scale --replicas=1 deploymentconfig/<deploymentconfig-name>

Rollout

A rollout is exposed as a replication controller, and the deployment process manages scaling down old replication controllers and scaling up new ones. Implements one of the deployment strategies.

oc rollout cancel|history|latest|pause|resume|retry|status|undo dc/<deployment-configuration-name>

If a deployment process is already in progress, the utility warns and a new replication controller is not deployed.

Options

latest

history

Information about all available application revisions. To view details about a specific revision, use --revision=<revision-label>

oc rollout history dc/<deployment-configuration-name> --revision=<revision-label>

undo

Rolls back the application to the last successful deployment.

--to-revision forces a specific version to roll back to.

Rollback undo disable image change triggers on deployment configuration, to prevent to accidentally start a new deployment after rollback completes. The image change triggers can be enabled with:

oc set triggers dc/<deployment-configuration-name> --auto

cancel

Cancellation is a "best-effort" operation. When canceled, the deployment configuration is automatically rolled back by scaling up the previous replication controller.

pause

This is to avoid frequent redeployments when machine changes on the deployment configuration. Then user resume.

resume

Configuring Deployment Triggers from Command Line

Deployment triggers can be set/modified from command line:

oc set triggers dc/<deployment-config-name> --from-image=<image>:latest -c hello world
oc set triggers dc/<deployment-config-name> --from-config=true
oc set triggers dc/<deployment-config-name> --manual
oc set triggers dc/<deployment-config-name> --remove-all

Blue/Green Deployment

To implement a blue/green deployment, Use a route and two services, and switch the route:

oc new-app openshift/deployment-example:v1 --name=example-green
oc new-app openshift/deployment-example:v1 --name=example-blue
oc expose svc/example-green --name=bluegreen-example

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

A/B Deployment

A/B deployment implementation.

oc new-app --name='cotd1' php~https://github.com/wkulhanek/cotd.git -e SELECTOR=cats
oc new-app --name='cotd2' php~https://github.com/wkulhanek/cotd.git -e SELECTOR=cities
oc expose service cotd1 --name='abcotd'
oc set route-backends abcotd cotd1=50 cotd2=50
oc annotate route/abcotd haproxy.router.openshift.io/balance=roundrobin