Deploy application to VPC using rolling deployments
By following this tutorial, you can create an IBM Cloud Continuous Delivery Toolchain and then use the toolchain and DevOps practices to develop a simple Java web application that you deploy to the IBM Cloud® Virtual Server Instances within the VPC. Once deployed the application is then accessible over internet via application load balancer.
The tutorial also guides you to create a secure and scalable VPC Infrastructure using terraform Infrastructure-As-Code (IAC) template to carry out rolling deployments.
The Rolling strategy deploys a new version of the application to a subset of the production environment while keeping the rest of the environment available for the live user traffic. For the sake of simplicity, assuming a batch size of n, the rolling strategy deploys a new version of the application to n instances at a time.
- Instances are first removed/drained of the production traffic by detaching them from the load balancer.
- Deployment is carried out by copying the new artifact to the instances and restarting the application.
- Once the deployment finishes, acceptance tests are carried out on the instances.
- If successful, the instances are attached back to the backend pool of servers.
The same process is carried out to all the instances of the backend pool.
The Rolling strategy helps to keep the application available to the users while new code is being deployed to the production environment. The downside of the approach is that two versions of the same application are visible to the user.
| VPC Infrastructure | Comments |
|---|---|
| VPC (Virtual Private Cloud) | The virtual private cloud |
| Subnets | |
| Load balancer | Layer-7 load balancer with dns enpoint |
| Backend pool | |
| Public gateways | |
| Bastion Host |
Any of the methods in this tutorial takes you to the guided setup experience. You are guided through the toolchain setup process in a logical order, and you are presented with the recommended configuration options that are needed to create your toolchain.
A progress indicator shows the steps to complete the configuration. You can use the progress indicator to navigate to a previous step with a mouse click. The configuration options for the current step are displayed in the main area of the page.
To advance to the next step, click Continue. You can advance to the next step only when the configuration for the current step is complete and valid. You can navigate to the previous step by clicking Back.
Some steps include an Advanced Options toggle. These steps by default present you with the minimum recommended configuration needed. However, advanced users that need finer grained control can click the Advanced Options toggle to reveal all options for the underlying integration.
After all the steps are successfully completed, you create the toolchain by clicking Create on the Summary step.
TIP: You can always go back to previous or explore the next steps in the guided installer. The toolchain installer retains all the configuration settings from the successive steps.
Start the toolchain configuration by selecting the Develop and Deploy application to VPC using deployment strategies template from the Toolchains catalog.
Review the default information for the toolchain settings. The toolchain's name identifies it in IBM Cloud. Make sure that the toolchain's name is unique within your toolchains for the same region and resource group in IBM Cloud.
Note: The present tutorial creates the toolchain in us-south region. Please select the appropriate region for your toolchain.
The toolchain creates Continuous Deployment Pipeline to deploy the application (executable java jar) on virtual machine instances within vpc. Select from one of the deployment strategies Rolling, Blue-Green or Canary. Based on your selection, additional details needs to be provided in the the Deployment Target step.
The present document assumes the Rolling deployment strategy as an example.
The Application step that refers to the application source code repository is shown in the following image. The toolchain template provides a sample Java Spring App using maven build.
The PR (Pull Request) and CI (Continous Integration) pipeline builds the application source code from the application source code repository.
The Inventory step that refers to the inventory repository is shown in the following image. The inventory repository records details of artifacts that are built by the CI toolchains.
The CI (Continuous Integration) pipeline uploads the built artifact (e.g jar) to the COS (Cloud Object Store) and corressponding metadata in JSON format to the inventory repository configured in this step. Later, when the CD (Continuous Deployment) pipeline is triggered, the build metadata is read from inventory repository and the same artifact is pulled from artifact store (Cloud Object Store)
Several tools in this toolchain require secrets to access privileged resources. An IBM Cloud API key is an example of such a secret. All secrets should be stored securely in a secrets vault and then referenced as required by the toolchain.
With IBM Cloud, you can choose from various secrets management and data protection offerings that help you to protect your sensitive data and centralize your secret. The Secrets step allows you to specify which secret vault integrations are added to your toolchain. Use the provided toggles to add or remove the vault integrations that you require as explained in Managing IBM Cloud secrets.
This tutorial uses IBM Secrets Manager as the vault for secrets.
Use IBM Secrets Manager to securely store and apply secrets like API keys, Image Signature, or HashiCorp credentials that are part of your toolchain.
Refer the details for IBM Key Protect or HashiCorp vault for managing your secrets in case you plan to use either of them instead of Secrets Manager
Any change to the source triggers the continuous integration pipeline. When a continuous integration run succeeds, a build or binary artifact is created and saved in transient storage, and then deployed to the target Virtual Server Instances. The toolchain provides option to use IBM Cloud Cloud Object Store (COS) to store transient build artifacts. In the case of sample Spring Java App, the executable jar file built by the Continuous Integration (CI) pipeline.
Alternatively, you may choose to use Artifactory if you have an artifactory instance of your own.
DevOps Insights
IBM Cloud DevOps Insights is included in the created toolchain. You do not need to provide any configuration steps for DevOps Insights, the CI pipeline will automatically use the insights instance included in the toolchain. DevOps Insights aggregates code, test, build, and deployment data to provide visibility into the velocity and quality of all your teams and releases.
The toolchain contains three pipelines:
-
Pull Request (PR) Pipeline: This pipeline is triggered when a merge or pull request is created in the Application Source Code Repository. Typically, this request is manually created by the application source code developer to merge changes from their development branch to the master branch or any other branch. The PR Pipeline runs the Unit Test and Static Scans on the Application Source Code.
-
Continuous Integration (CI) Pipeline: This pipeline is triggered when a change is merged to the master branch of the Application Source Code repository. The CI Pipeline runs the Unit Test, Code Coverage, Static Scans on the Application Source Code, CIS check, and Bill Of Materials (BOM) check. The CI Pipeline generates the binary build artifact and uploads them to the Cloud Object Store or Artifactory as configured in the toolchain. The CI Pipeline also generates the metadata of the build artifacts and stores it in the Inventory repository.
-
Continuous Deployment (CD) Pipeline: The CD Pipeline is responsible for deployment of the build artifacts to the deployment environment. The pipeline verifies the successful deployment of the application by running the health check. This pipeline must be manually triggered after successful completion of CI Pipeline. Depending on the deployment strategy selected, additional triggers are configured for the CD Pipeline.
To start the PR pipeline, create a merge request in your application repository. To achieve this, do the following:
- On the toolchain page, click the application repository tile. By default it gets created with a name compliance-app-
- Create a branch from master
- Update some code like in app or readme file and Save changes.
- Submit merge request.
- Back on the toolchain page, click the
pr-pipelinetile. Observe: the PR pipeline has been initiated.
The corresponding Merge Request in your application repository will be in "Pending" state until all the stages of PR Pipeline finish successfully.
After the PR Pipeline run is successful, click to explore the steps executed by the pipeline.
To start the CI Pipeline, navigate back to the merge request created earlier in your application repository.
- Click the
Mergebutton, to merge changes from the branch created in earlier step to the master. - Back on the toolchain page observe that the CI pipeline is triggered automatically.
- Click the
ci-pipelinetile. - Observe the running CI pipeline and wait for the pipeline run to finish.
After the CI Pipeline run is successful, click to explore the steps executed by the pipeline.
To start the CD pipeline do the following:
- On the toolchain page, click the Continuous Deployment tile.
- Trigger the CD pipeline manually
In this strategy, the deployment happens without any downtime by incrementally updating all production instances with new version of the software.
Rollback requires redeploying the previous release, which may not be immediate.
In the secure app development world, shift left is a practice referred to preventing and finding issues like defects, security vulnerabilities and performing compliance checks early in the software delivery process. These checks are run on the code/repository itself and do not need the built application binary, should be run as early as possible to prevent non-compliant code from being merged to master branch of repository.
Results from of unit tests run, vulnerability scans are published to the DevOps Insights instance inside the toolchain. You can navigate to it by clicking the DevOps Insights toolcard in the toolchain. You can review the collected evidence on the Quality Dashboard page.
Get help fast directly from the IBM Cloud Continuous Delivery development teams by joining us on Slack.
For more support options, see Getting help and support for Continuous Delivery.