Microservice Deployment

Deploying an application is a standard part of most release pipelines. One of the challenges you want to avoid is duplicating effort by redefining the process of deploying your application over and over.

CloudBees CD/RO has application and environment modeling capabilities which avoid this problem. It allows you to define the process once and use it over and over.

An application model allows you to define all of the processes you may run in relation to a given application. This can include processes such as deploying, removing, upgrading, etc.

Similar to object-oriented programming, this approach gives you the full context of what actions are available to you against a given application.

Reviewing the application

In this lab, you’ll be going through the process of creating and running an application deployment model for the following application.

This application is a simple webpage, but it will take in a couple of environment variables, specifically $NAME and $ENVIRONMENT. This will illustrate which environment it was deployed to and by whom.

There are many ways to deploy an application, especially one as simple as this. For this exercise we’ll be employing Helm, a Kubernetes package manager, to perform the deployment.

30-second Helm primer

CloudBees CD/RO will abstract away the need to run individual Helm commands, but it is helpful to know what Helm is doing behind the scenes.

Helm is effectively a template engine and state manager for Kubernetes resources.

It takes something that looks like this:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  labels:
    application: my-app
spec:
  replicas: 1

And turns it into:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "chart.fullname" . }}
  labels:
    {{- include "chart.labels" . | nindent 4 }}
spec:
  replicas: {{ .Values.replicaCount }}

It takes this template and runs it against a values.yaml file which includes the values to inject as well as values passed in via the command line.

It then applies these generated resources into the cluster in what it calls a release.

It keeps track of the configuration state from each of the releases so you can perform upgrades or rollback without issue.

Creating the application model

First you’ll need to navigate to the Applications page.

Then you’ll click on the New button in the top right.

Then Create New

Then proceed to fill out the form. You can call the application Workshop App and target the project you created in the pre-reqs. Then select Microservice for the application type.

Now you have a blank microservice application model.

As you can see, there are two big components standing out here. There is the microservice model block on the left (in pink). There is the environment model on the right (in purple).

Defining the microservice component

First we’ll start with the microservice definition on the left. This is where you’ll specify the Helm chart you want to deploy as well as any values you need to pass in.

To begin, click on the blue “Add microservice” button which will bring up the necessary form.

We’ll create a new microservice from scratch. You can just click next and leave the default option selected.

Next you need to fill out the definition form.

Values - You’ll want to make sure the subdomain is targeting your username.

ingress:
  hosts:
    - host: my-username.cdro-workshop.cb-demos.io
      paths:
        - path: /
          pathType: ImplementationSpecific
  tls:
    - secretName: insurance-frontend-tls
      hosts:
        - my-username.cdro-workshop.cb-demos.io

name: "my-username"
environment: "QA"

Now hit “OK” and the microservice component will be created.

Defining the environment

Now, before we’re able to deploy our newly-defined application, we need to define an environment to deploy it into.

Get started by clicking the blue “+” button on the right side.

It should be noted that we aren’t creating a new Kubernetes cluster, but rather a new environment definition based on a cluster.

Similar to the application definition, you can just click “Next” and leave the default option of “New environment” on this page.

Now you’ll define the cluster environment.

Next you’ll define the cluster reference.

The last step in configuring our microservice application is to map the microservice (hello-app) to your environment (QA). To do that click on the button and map your application

Mapping Tile	Mapped Application

Running the deployment

Now you’re ready to deploy the application.

Go ahead and click the “Deploy” button in the bottom right. This will launch a modal where you can specify which application process to run and which environment to target.

In this case, you’ll select Deploy Application as the process and QA as the environment (these should be the only options presented). When you’re ready, hit “OK”.

It will bring you to the application run page where you can see the steps updating live as they are happening.

After a short time, you should see a view like this where all of the stages are complete.

You can click the top list item to see more detail on the overall run and you can also click the individual steps to see specific details from just that step.

Visiting our application

Now we can visit the application we just deployed by visiting the URL from the values definition of our application. This will be in the form of https://my-username.cdro-workshop.cb-demos.io.

You should see the name of your username and the environment QA listed.

In the next lab we’ll be diving deeper into the environments and setting up environment specific variables.