Engineering
May 20, 2020
4 min read

How to Automate Deployment of Microservices With an API Gateway to a Multi-Cloud Environment

Mike Bilodeau

In today’s enterprise computing landscape, multi-cloud organizations are quickly becoming the norm rather than the exception. By leveraging an API-first strategy with a microservice-based architecture, companies can achieve significant speed to market across multiple clouds. In order to achieve this, container orchestration and a well-designed CI/CD strategy are essential components in this journey.

In this article, we will demonstrate how to create an automated workflow for deploying microservices as well as configuring an API gateway in front of those services. We will be using Kong Gateway as our API gateway. All of these components will run inside Kubernetes and be deployed using Github Actions. We will assume that you already have Kubernetes clusters available and that you can connect to each cluster from your local development machine. You will also need a Docker Hub account so you can build and push the images for our microservices. Additionally, you will need the Kubernetes package manager, Helm, installed.

We will show you how to do the following:

  1. Create the environment for an automated workflow
  2. Modify deployment scripts
  3. Automatically trigger the build and deploy process which will run on your computer
  4. Verify Kong is running
  5. Verify the upstream service is running
  6. Secure the upstream service
  7. Make changes to the upstream service

Create the Environment for an Automated Workflow

  1. Create a new, blank Github repository using the template repository by going here and clicking the “Use this template” button.
  2. Clone the repository.
  3. Under your Github project Settings tab, click on "Secrets." Then add two secrets, DOCKER_USERNAME and DOCKER_PASSWORD, with your Docker Hub account credentials.

  1. Under your Github project Settings tab, click on "Actions" and then press the “Add runner” button and follow the instructions for creating a self-hosted Github Action runner. A self-hosted Github Action runner is a program that runs on your machine and listens for repository events like push. When it receives an event, the action runs on your machine. Note: Make sure you run the commands from the Github instructions inside your-github-repo directory.

Upon successful execution of the action-runner, you will see:

Now that we have everything running, we can modify some code.

Modify Deployment Scripts

For this exercise, we are going to use a JavaScript action. In a new terminal window, cd your-github-repo, and run the following commmands which will download the necessary libraries for running JavaScript actions.

  1. npm init -y
  2. npm install @actions/core
  3. npm install @actions/github

Note: You will need NodeJS version 12.x or greater.

After the dependencies are installed, open the following files in your favorite text editor. Look for "TODO" and edit appropriately.

  1. your-github-repo/.github/actions/multi-cloud-deploy-action/helm_deploy.sh
  2. your-github-repo/.github/workflows/main.yml
  3. your-github-repo/startrek/values.yaml

Automatically Trigger a Build and Deploy That Runs on Your Computer

  1. Commit and push your changes to Github. This should trigger a build.
  2. Monitor results under your Actions tab.

After you commit and push your changes, Github will start the workflow by running through steps in your main workflow file. See your-github-repo/.github/workflows/main.yml. The entire workflow will run on your local machine. Following are the main steps that our workflow performs.

Main Workflow Steps
  1. Login to your Docker Hub account
  2. Build a Docker image of the upstream service and push to Docker Hub
  3. Deploy and configure Kong inside Kubernetes
  4. Pull your upstream service from Docker Hub and deploy your service to Kubernetes

Upon successful completion, you should see something similar in your terminal window that is running the self-hosted runner.

If you encounter an error deploying, please check the Github Action tab in your Github repository control panel.

Verify Kong is Running

kubectl get pods -n kong-ce

You should see output similar to the following:

Now that our project has been deployed successfully, we are free to make changes to both our services as well as the Kong configuration. First, we need the external host of your Kubernetes cluster.

Execute this command:

kubectl get svc -n kong-ce

You should see output similar to the following:

Verify upstream service is running

Copy the EXTERNAL-IP from the blog-kong-proxy record and execute the following:

Note: We are using the httpie command line client. See https://httpie.org for installation instructions.

You should see similar output:

Secure the Upstream Service

Now, let’s make some changes to the Kong gateway to enable some authentication, so we can secure our startrek service. Create a new file called security.yaml inside of your your-github-repo/startrek/templates directory and then paste the below contents. Then, uncomment line 44, # plugins.konghq.com: startrek-auth in your-github-repo/startrek/values.yaml. Save your changes, and then commit and push.

After that is finished deploying, execute http http://your-external-host/startrek/ships host:startrek.com again, and you should see the below output.

Add the API key like this, and you should see successful results.

Make Changes to Upstream Service

Feel free to make changes to the startrek service code in your-github-repo/services/startrek/app.py. Commit and push, and your application code should reflect your changes. When you make changes to your application, the Github Action builds a Docker image and pushes it to your Docker Hub account, see your-github-repo/.github/workflows/main.yml. Login to your account to see the versioned images.

For this exercise, we used the Kong Community Edition. Kong Enterprise provides additional management and security benefits for enterprise organizations like support for OIDC authentication, Mutual TLS, Vault integration and more. It also includes an out of the box Dev Portal for making your APIs discoverable throughout your organization.

Thank you for taking the time to read through this post. Hopefully, you have found this exercise useful. By no means is this a complete CI/CD solution, but it is a starting point and hopefully gets the creativity flowing for some good ideas within your organization.