IBM Cloud Docs
Develop and deploy an app by using IBM Cloud Satellite

Develop and deploy an app by using IBM Cloud Satellite

In this tutorial, you learn how to create an open toolchain by using IBM Cloud® Continuous Delivery and deploy your app on Satellite. You also learn how toolchains are implemented in the Continuous Delivery service and how to develop and deploy a simple web application (app) by using toolchains.

IBM Cloud Satellite brings public cloud services to any environment, allowing customers with stringent regulatory requirements to use the flexibility and agility of these services for their secure on-premises data center. Continuous Delivery uses Satellite Config to deploy an app across a group of clusters in IBM Cloud Satellite. With Satellite Config, you create a configuration to specify which Kubernetes resources you want to deploy to a cluster group of Kubernetes or Red Hat® OpenShift® on IBM Cloud® clusters that are running in your Satellite location or in IBM Cloud.

The toolchain that is used in this tutorial implements standard DevOps practices such as code scanning, acceptance tests, Git repos, and continuous integration and continuous delivery capabilities. After you create clusters and associate them with a Continuous Delivery cluster group, create a toolchain to change your app's code and push the change to the Git Repos and Issue Tracking repo. When you push changes to your repo, the Tekton-based delivery pipeline automatically builds and deploys the code.

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 systems. As an open source project, Tekton is managed by the Continuous Delivery Foundation. 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 Continuous Delivery. For more information about the IBM Cloud® Kubernetes Service, see IBM Cloud® Kubernetes Service.

The template that is used in this tutorial works with the Standard plan for Kubernetes.

Before you begin

Before you start this tutorial, make sure that you have the following resources in place:

  • An IBM Cloud account. Depending on your IBM Cloud 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 strategies might not be available. For more information about IBM Cloud accounts, see Setting up your IBM Cloud account and Upgrading your account.

  • A Kubernetes cluster and an API key. You can create these resources by using either the UI or the CLI. The cluster might take some time to provision. As the cluster is created, it progresses through the Deploying, Pending, and Ready stages. For more information about Kubernetes clusters, see Kubernetes clusters.

  • A Satellite cluster group that contains the cluster that is required by the toolchain. The toolchain in this tutorial supports a Satellite cluster group that contains only one type of cluster: a Kubernetes cluster or a Satellite cluster.

  • An instance of the Continuous Delivery service.

  • Optional. Secrets that are stored in a secrets management vault and managed centrally from a single location. For more information about choosing from the various secrets management and data protection offerings, see Managing IBM Cloud secrets. If you don't already have an instance of the secrets management vault provider of your choice, create one.

  • Optional. A namespace that is created by using the container registry command line. To create a namespace, type the following command from the command line:

    ibmcloud cr namespace-add <my namespace>

    Alternatively, you can create a namespace on the Container Registry page. For more information about creating a namespace in this location, see IBM Cloud Container Registry service.

Related content

Create the toolchain

In this step, you create a Develop and Deploy application to Kubernetes using deployment strategies toolchain. The target Kubernetes cluster is configured during the toolchain setup by using your IBM Cloud API key and your Kubernetes cluster name. You can change these settings later by updating the Delivery Pipeline configuration. Any code that is merged into the target Git repo branch is automatically built, validated, and deployed into the Kubernetes cluster.

To create a Develop and Deploy application to Kubernetes using deployment strategies toolchain, click

Create toolchain

Alternatively, from the IBM Cloud console, click the Menu icon hamburger icon > Platform Automation > Toolchains. On the Toolchains page, click Create a Toolchain. On the Create a Toolchain page, click Develop and Deploy application to Kubernetes using deployment strategies.

Configure the toolchain name and region

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.

The toolchain region can differ from the cluster and registry region.

Kubernetes secure app toolchain name and region
Kubernetes secure app toolchain name and region

Select the deployment strategy

The toolchain creates a Continuous Deployment Pipeline to deploy the application Docker image on the cluster group that is defined in Satellite.

  1. Click Multiple clusters via Satellite to deploy your app by using Satellite.

    Kubernetes secure app deployment strategies
    Deployment strategies

  2. Click Continue.

Configure the application source code repo

In the Application step, the recommended options for the application source code repo are displayed by default. To view all of the available options for the underlying Git integration, click Advanced Options. By default, the toolchain uses the default sample that clones the sample app as an IBM-hosted Git Repos and Issue Tracking repo.

Kubernetes secure app repository
Kubernetes secure app repository

You can change the name of the app repo. The region of the repo remains the same as the region of the toolchain.

The toolchain template provides a Hello Containers Application app. If you want to link an existing Application repo for the toolchain, select Bring your own app and specify the URL for the repo. The toolchain supports linking only to existing Git Repos and Issue Tracking repos.

By default, the application repo template is cloned to your Git Repos and Issue Tracking org. To change the org, enable Advanced options and specify the repo owner.

Configure the inventory repo

The inventory repo records the details of the artifacts that are built by the continuous integration toolchains. You can either create a new inventory repo that is a clone of the inventory repo template or use an existing inventory repo that you share between toolchains.

Kubernetes secure app inventory repo
Kubernetes secure app inventory repo

By default, the inventory repo template is cloned to your Git Repos and Issue Tracking org. To change the org, select Advanced options and specify the repo owner.

Securely store secrets

Several tools within this toolchain require secrets, such as an IBM Cloud API key. You must securely store all secrets in a secrets vault and reference them as required by the toolchain.

Using 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. In the Secrets step, you can specify which secret vault integrations to add or remove from your toolchain. For more information about adding and removing vault integrations, including prerequisites and by using hints, see Managing IBM Cloud secrets.

By using hints within a template, a toolchain is automatically populated with preconfigured secrets; you don't need to manually select secrets from vault integrations that are attached to the toolchain.

This tutorial uses the IBM Secrets Manager as the secrets vault.

Kubernetes secure app secrets options
Kubernetes secure app secrets options

IBM Secrets Manager securely stores and applies secrets such as API keys, Image Signature, or HashiCorp credentials that are part of your toolchain.

Kubernetes secure app secrets options
Kubernetes Secure app secrets options

For more information about managing your secrets in IBM Key Protect or HashiCorp, see IBM Key Protect or HashiCorp.

Configure the deployment target

Configure the target Kubernetes cluster to deploy the app to. After the app passes the build, test, and scan phase, the pipeline deploys the built app image to the target Kubernetes cluster. This deployment is now ready for acceptance testing or integration testing.

If the API key has the required access, the following fields automatically load by using the API key that is either created, retrieved from a vault, or manually specified. If the API key is valid, values for the Container registry region and namespace Cluster region, name, namespace, and Resource group are automatically populated. You can update any of these fields to match your configuration.

  • App name: The name of the app. The default app name is hello-containers.

  • IBM Cloud API Key: The API key that is used to interact with the ibmcloud CLI tool in several tasks. Use one of the following methods to specify the API key that you want to use:

    • Click the key icon to import an existing API key from a secret vault of your choice.
    • Copy and paste an existing API key.
    • Click New to create an API key.
    • Generate a new api-key if you don’t have an existing API key.

    You can immediately save the generated API key to an existing secrets vault of your choice.

  • Satellite Cluster group name: The name of the cluster group that was created in Satellite. Your app is deployed to this cluster group.

  • Cluster namespace: If the cluster namespace does not exist in the clusters within the cluster group, the toolchain creates it.

Kubernetes secure app deployment target details for Rolling or Blue-Green
Kubernetes secure app Rolling deployment target details

Add optional tool integrations

You can add the IBM Cloud® DevOps Insights tool integration to your toolchain without any additional configuration.

DevOps Insights is included in the created toolchain. You do not need to provide any configuration steps for DevOps Insights. The continuous integration pipeline automatically uses the DevOps Insights instance that is included in the toolchain. DevOps Insights aggregates code, test, build, and deployment data to provide visibility into the velocity and quality of all of your teams and releases.

Click Continue.

Complete the toolchain setup

On the Summary page, click Create. Several steps run automatically to set up your toolchain.

You can configure the individual toolchain integrations after the pipeline is created.

Kubernetes secure app toolchain Summary
Kubernetes secure app toolchain summary

Explore your new toolchain

After you create your toolchain, it shows each of the tool integrations that are part of the toolchain in a diagram.

Explore the pipelines

You can explore the pipelines to understand the toolchain flow and the different operations that run within each pipeline. The toolchain that you just created contains three pipelines:

  • Pull request pipeline: Runs when a developer merges changes from their development branch to the master branch, or to any other branch in the repo. The pull request pipeline runs the Unit Test and Static Scans on the Application Source Code.
  • Continuous integration pipeline: Runs when you merge a change into the master branch of the Application Source Code repo. The continuous integration pipeline runs the Unit Test, Code Coverage, and Static Scans on the Application Source Code, CIS check, and Bill Of Materials (BOM) check. The continuous delivery pipeline also generates the binary build artifacts and uploads them to the IBM Cloud® Kubernetes Service, as configured in the toolchain. And the continuous integration pipeline generates the metadata of the build artifacts and stores it in the Inventory repo.
  • Continuous deployment pipeline: Deploys build artifacts to the deployment environment. The pipeline verifies the successful deployment of the app by running the health check. You must manually trigger this pipeline after the continuous integration pipeline successfully completes. Depending on the deployment strategy that you selected, more triggers are added to the continuous delivery pipeline.

Run the pull request and continuous integration pipelines

To start the pull request pipeline, create a merge request in your app repo:

  1. On the Toolchain's Overview page, on the Repositories card, click the compliance-app-<timestamp> app repo.
  2. From the master repo, create a branch.
  3. Update some code in the sample node app or readme file and save these changes.
  4. Submit the merge request.
  5. On the Toolchain's Overview page, on the Repositories card, click the pr-pipeline repo to start the pull request pipeline. The corresponding merge request in your app repo remains in the pending state until all of the stages of the pull request pipeline successfully complete.
  6. After the pull request pipeline run succeeds, you can select it to explore the completed steps.

Pull request pipeline success
Pull request pipeline success

To start the continuous integration pipeline, merge the continuous integration merge request in your app repo:

  1. Go to the merge request.
  2. Merge the request so that your changes are copied to the master branch of your app repo. The continuous integration pipeline is automatically triggered.
  3. On the continuous integration Toolchain Overview page, on the Repositories card, click the ci-pipeline repo to start the continuous integration pipeline.
  4. After the continuous integration pipeline run succeeds, you can click the pipeline run to explore the completed steps.

Continuous integration pipeline success
Continuous integration pipeline success

Shift left practice

In the secure app development world, shift left is a practice that prevents and finds issues such as defects and security vulnerabilities and runs compliance checks early in the software delivery process. Shift left includes the following practices:

  • Run checks that can be run on the code or the repo itself and do not need the built image, as early as possible. These checks prevent noncompliant code from being merged into the master branch of the repo. Because evidence is not collected from the pull request pipeline, its goal is to shift compliance checks as far left as possible.
  • All checks are run in every pipeline run. If a previous check fails, the pipeline progresses to the next check. To evaluate if you have any failures in your run, check the final step of your pipeline that has a pipeline evaluator.

Results from unit tests and vulnerability scans are published to the DevOps Insights instance within the toolchain. To review these results, click the DevOps Insights tile within the toolchain and go to the Quality Dashboard page.

To evaluate if you have any failures in your pipeline run, check the final step of your pipeline, which has a pipeline evaluator.

Explore the continuous delivery pipeline

The pull request and continuous integration pipelines are common across all of the deployment strategies. The continuous delivery pipeline design and implementation changes are based on the deployment strategy that you previously selected in this tutorial.

You can start a continuous delivery pipeline in either of the following ways:

  • Trigger the continuous delivery pipeline manually.
  • Automatically trigger the continuous delivery pipeline after each Merge action in the Inventory repo. After the merge, you must manually trigger the continuous deliver pipeline run.

A Git Repos and Issue Tracking trigger is set up to trigger an automatic continuous delivery pipeline, but it is disabled by default. You can enable this trigger after the first time that you promote a change.

Continuous delivery pipeline triggers for rolling deployment
Triggers in continuous delivery pipeline for rolling deployment

Next steps

If you want to remove the sample app that is running on Kubernetes, you must clean the Kubernetes cluster:

  1. Go to the Kubernetes Cluster home page.

  2. Select the cluster where the sample app is running.

  3. Click Kubernetes dashboard.

  4. From the location where the sample app is running, select namespace.

    Kubernetes namespace
    Kubernetes namespace

  5. Delete the related deployments, services, and ingresses that are listed within the selected namespace.

Looking for help?

Get help 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.