In this lab you will learn about deployment environments in software delivery lifecycle and deploy the application into these deployment environments.
A deployment environment describes a distinct space for an application to run during a particular stage of a CI/CD pipeline. Typical environments include development, test, stage, and production, for example. In this lab you will create Dev and Prod deployment environments for the CoolStore application which is deployed throughout this session:
-
Dev Environment: this environment is used during development of the Cart service and every change made by developers gets deployed into this environment. Other services e.g. Cart and Inventory would have also their own dedicated Dev environments which allows the developers to write code and test their service without disrupting other teams. If the changes made pass the automated tests, the code will be deployed into the Prod environment.
-
Production Environment: the live environment for the entire CoolStore webshop with all services deployed and serving requests to customers. Any interruption in this environment would directly affect the customers.
A Project in OpenShift is a mechanism to scope applications in a cluster and is the central vehicle by which access to resources is managed. A project allows users to organize and manage their applications in isolation from other users. Users must be given access to projects by administrators, or if allowed to create projects, automatically have access to their own projects. Granular access control and network traffic policies for projects in OpenShift makes them a suitable way for modeling deployment environments that fulfil the collaboration, networking and isolation requirements.
In this lab, you will create the Dev deployment environment and deploy the Cart service into this environment. Cart service is developed in Java using the Spring Boot framework.
In the current lab, in order for you to become familiar with both the OpenShift Web Console and the OpenShift command line interface (CLI), every step is explained via both the Web Console and CLI which you can choose based on your preferences. Either way leads to the exact same result. Let’s start with with creating the Dev deployment environment and deploying the Cart service.
In OpenShift Web Console, click on the Create Project button in order to create a new project, enter the following details and click on Create button:
Caution
|
Replace {{PROJECT_SUFFIX}} with the number provided to you by the instructor.
|
-
Name:
dev-{{PROJECT_SUFFIX}}
-
Display Name:
Cart Dev
The Dev deployment project for the Cart service is created now and is ready for the Cart service to be deployed.
By default, the current user who created the project is the admin for this project. The OpenShift cluster admins or the project admins can define granular access control on the project and control how can view, modify or deploying applications in each project. This is particularly essential for example when you want developers to be able to view the Prod environments and get debug information without allowing them to modify the state of those environments. In order to review the access control on the Dev project, click on Resources → Membership on the left sidebar menu. Note that the current user has the admin role.
Now, let’s deploy the Spring Boot application, Cart service, into the Dev environment. OpenShift supports deploying containerized apps in three different ways and allows developer to pick the process that is most suitable for their projects:
-
From application source code
-
From application binary (e.g. app.jar)
-
From docker images
OpenShift introduces a mechanism called {{OPENSHIFT_DOCS_BASE}}/architecture/core_concepts/builds_and_image_streams.html#source-build[Source-to-Image (S2I)] which is a tool for building docker container images. It produces ready-to-run images by injecting application source into a container image and assembling a new image. The new image incorporates the application runtime base image and built source code and is ready to use with the docker run command. The application base runtime might be various language runtimes such as Java, Ruby, NodeJS, Python, etc or middleware runtimes such as Apache Tomcat, JBoss EAP, etc.
S2I can also take application binaries such as JAR, WAR or EAR files as input and build a new docker image for the application combined with the application runtime.
If you already have a process in-place for building docker images, OpenShift allows you to point to the ready docker images and deploy them as is on the platform.
In this lab, you will use the S2I mechanism for building the Cart service from source code. Since Cart service is based on Spring Boot, you only need the Java language runtime for running this service and therefore you will use the certified OpenJDK application runtime which is provided in OpenShift out-of-the-box. Click on Browse Catalog to open the service catalog. The catalog shows the list of available language and application runtimes, services as well as templates. A template describes how to build, configure and deploy a set of containers in a reproducible manner. OpenShift templates simplify composing complex multi-container applications and makes it easy to recreate and configure complete applications from scratch by deploying a template.
Enter jdk in the text field in order to find the Red Hat OpenJDK 1.8 language runtime, and then click on the one that shows duke, the java mascot.
Now that you have chosen the Java language runtime, you can enter the URL to the Cart service application source code to specify it as an input to the S2I process. Click Next and enter the following in the text fields:
Caution
|
Replace {{PROJECT_SUFFIX}} with the number provided to you by the instructor.
|
-
Name:
cart
-
Git URL:
http://{{GIT_SERVER_INTERNAL_URL}}/{{GIT_USER}}/cart-service.git
Click on advanced options to review advanced options for setting memory and cpu limits, environment variables, scaling and more when deploying an application. In this lab, similar to most development teams a Maven artifact repository (e.g. Sonatype Nexus and Artifactory) is used for managing Maven artifacts. Add the following environment variable under Build Configuration to specify the Maven repository manager URL to be used during the build phase:
-
Name:
MAVEN_MIRROR_URL
-
Value:
{{NEXUS_INTERNAL_URL}}/repository/maven-all-public
Note that the Maven repository manager URL is an internal URL and is not accessible externally. Click on Create button and then on Continue to the project overview..
All required resources are created in order to build and deploy the Cart service in the Dev project. OpenShift provides an out-of-the-box load-balancer which is automatically updated to route traffic to Cart service when the container is deployed and ready to receive traffic.
In the project overview, the Cart service S2I build process is running to build first the application JAR file and then a docker image by layering the JAR file on the OpenJDK base image.
You can see the build logs as build is making progress. If you want to see the full logs, click on View Log link to see the build logs in a larger window. You can click on the Follow link to follow the logs in the browser.
When the build finishes and the application docker image is created, the docker image is pushed by default to OpenShift internal registry and then deployed to OpenShift. Builds also support pushing the built image to other image registries outside OpenShift.
OpenShift uses {{OPENSHIFT_DOCS_BASE}}/dev_guide/application_health.html[container health checks] to detect and handle or heal unhealthy containers which is not set yet on the deployed Cart service. OpenShift runs the following probes to manage the container and application health:
-
Liveness Probe: a liveness probe checks if the container is still running. If the liveness probe fails, OpenShift restarts the container
-
Readiness Probe: a readiness probe determines if a container is ready to service requests. If the readiness probe fails, OpenShift removes that container from the list of endpoints in the service load-balancer. A readiness probe can be used to signal the service load-balancer that even though a container is running, it should not receive any traffic.
There are multiple ways to check a container liveness and readiness. You can define an HTTP URL, a command to execute in the container or a TCP socket to connect to. Click on cart deployment to see the deployment configuration for the Cart service. Alternatively, you can click on Applications → Deployments from the left-side menu and then on cart. Click on Action menu button and then Edit Health Checks to configure HTTP liveness and readiness probes for the Cart service.
-
Type:
HTTP
-
Path:
/health
-
Port:
8080
-
Initial Delay:
15
Wait till the Cart service is re-deployed with the new health check configurations and then verify that the Cart service is functioning by pointing your browser to the Cart service REST endpoint.
Caution
|
Replace {{PROJECT_SUFFIX}} with the number provided to you by the instructor.
|
Alternatively, you can use the curl
command to verify that the Cart service is functioning:
$ curl http://{{CART_ROUTE}}/health
{"status":"UP","diskSpace":{"status":"UP","total":10725883904,"free":9970741248,"threshold":10485760},"refreshScope":{"status":"UP"},"hystrix":{"status":"UP"}}
Note that Cart is a REST service and does not provide any web page at the root of the application.
You can perform the same steps as above using the OpenShift CLI commands. Start with creating the Dev project:
Caution
|
Replace {{PROJECT_SUFFIX}} with the number provided to you by the instructor.
|
$ oc new-project dev-{{PROJECT_SUFFIX}} --display-name="Cart Dev"
You can now create the Cart service by specifying the language runtime base image, the source code repository and a name for the service:
Caution
|
Replace {{PROJECT_SUFFIX}} with the number provided to you by the instructor.
|
$ oc new-app java:8~http://{{GIT_SERVER_URL}}/{{GIT_USER}}/cart-service.git \
--name=cart \
--build-env=MAVEN_MIRROR_URL={{NEXUS_INTERNAL_URL}}/repository/maven-all-public
--> Found image 56cfa0a (6 weeks old) in image stream "openshift/java" under tag "8" for "java:8"
Java Applications
-----------------
Platform for building and running plain Java applications (fat-jar and flat classpath)
Tags: builder, java
* A source build using source code from http://{{GIT_SERVER_URL}}/{{GIT_USER}}/cart-service.git will be created
* The resulting image will be pushed to image stream "cart:latest"
* Use 'start-build' to trigger a new build
* This image will be deployed in deployment config "cart"
* Ports 8080/tcp, 8443/tcp, 8778/tcp will be load balanced by service "cart"
* Other containers can access this service through the hostname "cart"
--> Creating resources ...
imagestream "cart" created
buildconfig "cart" created
deploymentconfig "cart" created
service "cart" created
--> Success
Build scheduled, use 'oc logs -f bc/cart' to track its progress.
Application is not exposed. You can expose services to the outside world by executing one or more of the commands below:
'oc expose svc/cart'
Run 'oc status' to view your app.
The Cart service is accessible by default within OpenShift. You can update the built-in load-balancer in OpenShift to route traffic to the Cart service by exposing the internal Cart service:
$ oc expose svc/cart
route "cart" exposed
You can also view the build logs as the build is running:
$ oc logs bc/cart -f
And finally, define the /health
HTTP URL as the liveness and readiness probes for the Cart service:
$ oc set probe dc/cart --readiness --liveness --get-url=http://:8080/health --initial-delay-seconds=15