OpenShift Application Operations: Difference between revisions
No edit summary |
|||
(67 intermediate revisions by the same user not shown) | |||
Line 7: | Line 7: | ||
=Overview= | =Overview= | ||
<tt>oc new-app</tt> is a tool that generates an appropriate JSON configuration so OpenShift can build an image based on it. The configuration | <tt>oc new-app</tt> 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 [[OpenShift Concepts#Projects|project]]. For more details on projects and applications, see [[OpenShift_Concepts#Projects_and_Applications|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 [[OpenShift Concepts#Build_Configuration|build configuration]] and builds the source into a new version of the application. | |||
2. As result of [[OpenShift Concepts#Build_Configuration|build configuration]] configuration execution, a new container image based on the [[OpenShift Concepts#Image_Stream|image stream]] compatible with the source code is created. | |||
3. Creates a [[OpenShift Concepts#Deployment_Configuration|deployment configuration]] that deploys the new image. | |||
4. Deploys a [[OpenShift Concepts#Pod|pod]]. | |||
5. Configures a [[OpenShift Concepts#Service|service]]. | |||
6. Optionally, a [[OpenShift Concepts#Route|route]] is created to expose the service externally. | |||
=What Build Strategy?= | |||
If new-app finds a [[Docker Concepts#Dockerfile|Dockerfile]] in the source repository, it uses the [[OpenShift_Concepts#Docker_Build|Docker build strategy]]. Otherwise it uses the [[OpenShift_Concepts#Source-to-Image_.28S2I.29_Build|source strategy]]. The strategy can also be explicitly set with --strategy option. | |||
=Create a New Application= | |||
==Create a New Application from a Git Repository== | |||
{{Internal|OpenShift Create an Application from a Git Repository|Create an Application from a Git Repository}} | |||
=Create a New Application= | ==<span id='Instantiate_a_Stored_Template'></span><span id='Create_an_Application_from_a_Template'></span>Create a New Application from a Template== | ||
{{Internal|OpenShift_Create_an_Application_from_a_Template|Create an Application from a Template}} | |||
==Create a New Application from a Docker Image== | |||
{{Internal|OpenShift_Create_an_Application_from_a_Docker_Image|Create an Application from a Docker Image}} | |||
=Application Life Cycle Events and State Monitoring= | =Application Life Cycle Events and State Monitoring= | ||
Line 56: | Line 52: | ||
* routes | * routes | ||
* services | * services | ||
* deployment configuration (when the deployment configuration is deleted, the associated replication controllers are deleted) | |||
* builds | |||
* build configuration | * build configuration | ||
* | * image streams | ||
* | * pods | ||
{{Warn|[[OpenShift_Project_Operations#Delete_a_Project|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.}} | {{Warn|[[OpenShift_Project_Operations#Delete_a_Project|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 [[OpenShift_Concepts#Deployment|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 [[oc rollback|rollback]]. | |||
=Scaling Up and Down the Number of Replicas associated with a DeploymentConfig= | =Scaling Up and Down the Number of Replicas associated with a DeploymentConfig= | ||
Line 66: | Line 84: | ||
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> | ||
Line 94: | Line 112: | ||
A rollout is exposed as a [[OpenShift Concepts#Replication_Controller|replication controller]], and the deployment process manages scaling down old replication controllers and scaling up new ones. Implements one of the [[OpenShift_Concepts#Deployment_Strategy|deployment strategies]]. | A rollout is exposed as a [[OpenShift Concepts#Replication_Controller|replication controller]], and the deployment process manages scaling down old replication controllers and scaling up new ones. Implements one of the [[OpenShift_Concepts#Deployment_Strategy|deployment strategies]]. | ||
oc rollout cancel|[[#history|history]]|[[#latest|latest]]|pause|resume|retry|status|[[#undo|undo]] dc/<''deployment-configuration-name''> | oc rollout [[#cancel|cancel]]|[[#history|history]]|[[#latest|latest]]|[[#pause|pause]]|[[#resume|resume]]|retry|status|[[#undo|undo]] dc/<''deployment-configuration-name''> | ||
If a deployment process is already in progress, the utility warns and a new replication controller is not deployed. | If a deployment process is already in progress, the utility warns and a new replication controller is not deployed. | ||
== | ==Options== | ||
====latest==== | ====latest==== | ||
====history==== | ====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==== | ====undo==== | ||
Line 109: | Line 131: | ||
<tt>--to-revision</tt> forces a specific version to roll back to. | <tt>--to-revision</tt> 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. After the changes are applied, resume deployment with <tt>oc [[#resume|resume]] ...</tt> | |||
oc rollout pause dc <''dc-name''> | |||
====resume==== | |||
oc rollout resume dc <''dc-name''> | |||
=Configuring Deployment Triggers from Command Line= | |||
[[OpenShift_Concepts#Deployment_Configuration_Triggers|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 [[Software Development|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= | |||
[[Software_Development#A.2FB_Deployments|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 | |||
=Build and Deploy a JEE Application= | |||
{{Internal|OpenShift Build and Deploy a JEE Application with S2I#Create_the_Application|Build and Deploy a JEE Application with S2I}} |
Latest revision as of 23:00, 24 January 2018
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
Create a New Application from a Template
Create a New Application from a Docker Image
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
- deployment configuration (when the deployment configuration is deleted, the associated replication controllers are deleted)
- builds
- build configuration
- image streams
- pods
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. After the changes are applied, resume deployment with oc resume ...
oc rollout pause dc <dc-name>
resume
oc rollout resume dc <dc-name>
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