Develop and deploy an application on IBM Cloud VPC using deployment strategies
Use this tutorial to understand the creation of an open toolchain that uses different deployment strategies like Rolling, Blue-Green and Canary to develop and deploy a simple Spring Java web app to IBM Cloud VPC. The tutorial takes you through steps required to create a toolchain with IBM Cloud Continuous Delivery service. This toolchain implements standard DevOps practices like setting up an application git repo, a PR (Pull Request) pipeline, CI (Continuous Integration) pipeline and CD (Continuous Delivery) pipeline. In addition, the toolchain also provides shift-left capabilities like code-risk analysis, cis scans, vulnerability scans that are integrated as part of the PR and CI pipelines.
The tutorial also guides you to provision a secure and scalable VPC infrastructure using IBM Cloud Schematics and terraform Infrastructure-As-Code (IAC) template to create VPC Infrastructure required to adopt advanced deployment strategies like Rolling, Blue-Green and Canary. Once the VPC infrastructure is ready, setup the toolchain to create the CI and CD Pipelines to test build, deploy and test application code.
Once the VPC infrastructure is provisioned and the toolchain is setup the tutorial takes you through steps to change the application code, push the change to the application repository and test the same using PR pipelines. Once tested, how to use the CI pipeline to build the application binary and then use the CD pipeline to deploy the binary to the virtual server instances provisioned for the deployment strategy of your choice.
Tekton is an open-source, vendor-neutral, Kubernetes-native framework that you can use to build, test, and deploy apps. Tekton provides a set of shared components for building continuous integration and continuous delivery (CICD) systems. As an open-source project, Tekton is managed by the Continuous Delivery Foundation (CDF). The goal is to modernize continuous delivery by providing industry specifications for pipelines, workflows, and other building blocks. With Tekton, you can build, test, and deploy across cloud providers or on-premises systems by abstracting the underlying implementation details. Tekton pipelines are built into IBM Cloud Continuous Delivery. Read more about the IBM Cloud Kubernetes Service.
Template works with both standard or lite plan for Kubernetes. Standard plan gives you ability to access your app via DNS name, whereas in the lite plan, the app is available via nodeport.
A deployment strategy is a way to change or update an application in a production environment in a controlled manner. There is more than one reason why this topic assumes importance. Some of the most prominent reasons are:
- Avoid a downtime of an application
- Conduct specific tests like a new functionality or for specific users or both,
- Limit issues in production to a limited users in case there happens to be an issue.
- In case there are any issues found, gain control over rapid rollback to the previous version.
Let's understand the various types of deployment strategies:
This deployment strategy deploys a new release, stopping and updating all running instances at once, thus causing downtime.
For rollback, the old version must be redeployed.
This strategy is simple, fast and cheap. At the same time, it is the riskiest and causes down time. Thus, not recommended for critical applications that need to be highly available.
Deploy a new release with no downtime by incrementally updating all its instances in a rapid manner. Rollback requires redeploying the previous release, which may not be immediate.
In this deployment strategy, you can leverage two permanent production environments (blue and green) with only one receiving traffic at any time. Deploy the new release to the idle environment, then switch all traffic to it with no downtime. For rapid rollback, simply switch all traffic back to the other environment that remained unchanged.
This deployment strategy is fast, easily understood and easy to rollback as we simply flip the traffic to old deployment.
Deploy a new release in parallel with the original production environment, with no downtime, then incrementally route more traffic to it until it replaces the original one which can be torn down. We can control the amount of traffic and the time interval of the update to the new release.
For rapid rollback during progressive rollout, all traffic can be routed back to the original production environment.
In this approach the risk of introducing any issues to the production is reduced by slowly directing the traffic. This method is also the slowest to transition from old to a new release of the software being deployed. Canary deployments allow organizations to test two different versions of the software side by side in production.
To set up the prerequisites for your toolchains, follow these steps:
- Set up an {{site.data.keyword.cloud_notm}} account{: external}. Depending on your {{site.data.keyword.cloud_notm}} account type, access to certain resources might be limited. Depending on your account plan limits, certain capabilities that are required by some of the deployment staretgies might not be available. For more information, see Setting up your {{site.data.keyword.cloud_notm}} account and Upgrading your account.
- You need a Kubernetes cluster and an API key. You can create them by using either the UI or the CLI. The cluster might take some time to provision. As the cluster is created, it progresses through these stages: Deploying, Pending, and Ready. Learn more. Rolling and Blue/green deployments can be tried on a lite plan but for Canary, you must create a Kubernetes cluster with standard plan.
- You will need an instance of Continuous Delivery service.
- Optional. Store all of the secrets in a secrets management vault and manage them centrally from a single location. Managing IBM Cloud secrets can help you to choose from various secrets management and data protection offerings. If you don't already have an instance of the secrets management vault provider of your choice, create one.
- Optional. Create a namespace by using the container registry command line. In a command-line window, enter the command: ibmcloud cr namespace-add Alternatively, you can create a namespace on the Container Registry page. For more information, see IBM Cloud Container Registry service.
The target cluster is configured during toolchain setup (by using an IBM Cloud API key and cluster name). You can later change these settings by altering the Delivery Pipeline configuration. Any code merged to the target Git repository branch is automatically built, validated, and deployed into the Kubernetes cluster.
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.
You can always go back to the previous or explore the next steps in the guided installer. The toolchain installer retains all the configuration settings from the successive steps. {: tip}
{: #cd-ci-toolchain-create-options} {: step}
You'll create a "Develop a Kubernetes app" toolchain. For this task, you need your API key and Kubernetes cluster name.
Start the toolchain configuration by clicking Create toolchain button.
{: #cd-ci-toolchain-name-region} {: step}
Review the default information for the toolchain settings. The toolchain's name identifies it in {{site.data.keyword.cloud_notm}}. Make sure that the toolchain's name is unique within your toolchains for the same region and resource group in {{site.data.keyword.cloud_notm}}.
The toolchain region can differ from cluster and registry region. {: note}
{: #cd-ci-toolchain-select-strategy} {: step}
The toolchain creates Continuous Deployment Pipeline to deploy the application docker image on IBM Kubernetes Services. Select from one of the deployment strategies Rolling or Blue-Green or Canary. Based on your selection you will have to provide adidtional details to the deployment target step. Following example shows Rolling deployment strategy as an example.
{: #cd-ci-toolchain-tool-integrations} {: step}
Multiple repositories must be configured during the guided setup, as described in the next sections.
{: #cd-ci-tool-integration-application}
The Application step that refers to the application source code repository is shown in the following image. The recommended options are displayed by default, but you can click the Advanced Options toggle to see all of the configuration options available for the underlying Git integration. The default behavior of the toolchain is to Use default sample that clones the sample application as IBM hosted GRIT Repository.
You can change the name of the application repository.
The region of the repository remains the same as the region of the toolchain.
The toolchain template provides a sample NodeJS app. If you want to link an existing Application Repository for the toolchain, select the Bring your own app option, and provide it as input to Repository URL field. As noted earlier, the toolchain currently supports linking only to existing GRIT repositories.
By default, the application repository template will be cloned to your Git Repo and Issue Tracking organization. To change the organization, enable Advanced options, and edit the Repository owner field.
{: #cd-ci-tool-integration-inventory}
The inventory repository records details of artifacts that are built by the CI toolchains. You can choose to either create a new inventory repository, which will be a clone of the inventory repository template{:external}, or use an existing inventory repository that you are sharing between toolchains.
By default, the inventory repository template will be cloned to your Git Repo and Issue Tracking organization. To change the organization, enable Advanced options, and edit the Repository owner field.
{: #cd-ci-tool-integration-secrets} {: step}
Several tools in this toolchain require secrets to access privileged resources. An {{site.data.keyword.cloud_notm}} 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 {{site.data.keyword.cloud_notm}}, 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 {{site.data.keyword.cloud_notm}} secrets. This documentation gives you information on prerequisites and how to use a list of prescribed secret names that are otherwise known as hints. By using hints in a template, a toolchain can be automatically populated with preconfigured secrets without any need to manually select them from various vault integrations that are attached to the toolchain.
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
{: #cd-ci-deployment-target} {: step}
Configure the target Kubernetes cluster where the application will be deployed. Once the application passes the build, test and scan phase the pipeline deploys the built application image to target Kubernetes cluster. This deployment is then ready for acceptance test or integration test.
Using the API key that is either created, retrieved from a vault, or manually entered the following fields load automatically if the API key has sufficient access. If the API key is valid, the Container registry region and namespace Cluster region, name, namespace and Resource group will be automatically populated. You may change any of these fields to match your configuration if needed.
-
App name: The name of the application.
- Default: hello-contianers
-
IBM Cloud API Key: The API key is used to interact with the ibmcloud CLI tool in several tasks.
- Preferred: An existing key can be imported from an existing secret vault of your choice by clicking the key icon.
- An existing key can be copy and pasted.
- A new key can be created from here by clicking the New +.
- Generate a new api-key if you don’t have one or copy an existing key to the field.
The newly generated API key can be immediately saved to an existing secret vault of your choice. {: tip}
The deployment is carried out as per the deployment strategy you have selected earlier in Select Deployment Strategy step of the guided setup. The snapshot below shows the details if you would have selected Rolling or Blue-Green
In case you chose Canary in Select Deployment Strategy step of the guided setup, there are additional details needed in the Deployment Target step of the guided setup.
-
Canary step size: Defines how much amount of traffic needs to be redirected to new release of Canary deployment.
-
Canary step interval: Defines interval time between each Canary test to move to the new release of Canary deployment.
{: #cd-ci-optional tools} {: step}
Orion WebIDE
The Eclipse Orion Web IDE is a browser-based development environment where you can develop for the web in JavaScript, HTML, and CSS with the help of content assist, code completion, and error checking. No additional configuration is needed to use this tool.
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.
{: #cd-ci-toolchain-summary} {: step}
On the Summary page, click Create, and wait for the toolchain to be created.
The individual toolchain integrations can be configured also after the pipeline is created. {: tip}
{: #cd-ci-pull-request} {: step}
{: #cd-ci-ci-pipeline} {: step}
{: #cd-ci-exploring_deployment} {: step}
{: #cd-ci-exploring_rolling}
{: #cd-ci-blue-green}
{: #cd-ci-canary}
{: #cd-related-content}
- Getting started with clusters
- Getting started with toolchains{: external}
- Getting started with Continuous Delivery
{: #cd-tutorial-help}
Get help fast directly from the {{site.data.keyword.cloud_notm}} {{site.data.keyword.contdelivery_short}} development teams by joining us on Slack{: external}.
For more support options, see Getting help and support for {{site.data.keyword.contdelivery_short}}.
{: #tutorial-cd-devsecops-next}