Cloud Native Dev-To-Deploy Pipeline With GitHub And Cloud Foundry

GitHub is among the most popular version control tools available in the market. Teams of all sizes, within companies of all kinds — make use of GitHub for their source control needs. As of today, GitHub goes beyond providing repositories for code and extends this to storing containers using the GitHub Container Registry.

Cloud Foundry, in particular the cf-for-k8s project, has two main uses for GitHub tooling. One — all the apps are pushed from source. This means that the version control system, which holds the source code, is central to all the operations that happen on Cloud Foundry environments. Second, the cf-for-k8s project makes use of a cloud hosted container registry during the cf push process. When the application needs to be deployed, it is packaged as a container using Buildpacks and first uploaded to a container registry. It is then pulled from here and then deployed to the container runtime/Kubernetes-powered infrastructure.

In summary, the two vital steps of Cloud Foundry deployments both make use of tools that are offered by GitHub.

Source Code Management as repositories is GitHub’s central product. A more recent announcement was made about offering Container Registries as well, which leads us to this effort of creating an end-to-end Cloud Foundry experience on Kubernetes using the cf-for-k8s project with pure-play GitHub tools. In addition, we will be making use of GitHub actions to enable automated deployment of code to Kubernetes.

Let’s quickly take a look at the steps needed to take in order to make this happen.

Before starting, an account (free tier works too) on GitHub will be needed. Follow the steps from the official GitHub docs to create your account.

Next, this account should have the container registry enabled. At the time of this writing, the GitHub Container Registry is available as a Beta/preview feature. Follow these steps to enable the container registry on your account.

You will need to install the cf-for-k8s project on an infrastructure provider of your choosing. Here are instructions on how to do it with Google Kubernetes Engine and DigitalOcean Kubernetes Service. One modification to the instructions provided there — when entering the values for the app_registry in the cf-values.yml file, use the following snippet:

app_registry:
  hostname: https://ghcr.io
  repository_prefix: "ghcr.io/ramiyengar"
  username: "ramiyengar"
  password: "!@#$%^&*(*&^%$#@!@#$%^&*&^%$#@#$%^"

The API end point of the GitHub Container Registry is https://ghcr.io. The repository prefix that it takes is ghcr.io/<username>. The password to be used is the Personal Access Token (PAT) that needs to be generated on GitHub. Follow these instructions to create one. Remember to copy the PAT and paste it into cf-values.yml under app_registry/password. We’re taking this step so that all the components needed to install and operate cf-for-k8s use GitHub components.

Next, Pick a sample repo to work with and deploy. This should be a repo on GitHub. You can use existing repositories or create a new one. In this repo, we will add a workflow using GitHub Actions.

The goal of this workflow is to deploy the code to a Kubernetes-based infrastructure. It will make use of cf push, which is available because cf-for-k8s has been installed on the cluster.

The GitHub Actions workflow which will be used to build and deploy the app has two parts -

1. <org>/repo/cf-cli-action

2. .github/workflows/main.yml

The first part is a basic setup which makes use of a Docker container from which the source code shall be pushed to the remote Kubernetes cluster. Here’s the way the cf-cli-action repository is organized:

─ cf-cli-action
  ├── action.yml
  ├── Dockerfile
  ├── entrypoint.sh
  ├── LICENSE.md
  └── README.md

The Dockerfile included here will setup a basic Ubuntu image and install the Cloud Foundry CLI on it. The contents of the Dockerfile are as follows:

FROM ubuntu:18.04
RUN apt-get update
RUN apt-get install -y ca-certificates jq
RUN echo "deb [trusted=yes] https://packages.cloudfoundry.org/debian stable main" > /etc/apt/sources.list.d/cloudfoundry-cli.list
RUN apt-get update
RUN apt-get install -y cf7-cli
ADD entrypoint.sh /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]

The entrypoint script executes a simple set of instructions which make use of the cf-for-k8s end point and signs into the remote server, followed by the cf push command which deploys the code. The script contains the following commands:

#!/bin/sh -l
cf api --skip-ssl-validation "$INPUT_CF_API"
cf auth "$INPUT_CF_USERNAME" "$INPUT_CF_PASSWORD"
if [ -n "$INPUT_CF_ORG" ] && [ -n "$INPUT_CF_SPACE" ]; then
  cf target -o "$INPUT_CF_ORG" -s "$INPUT_CF_SPACE"
fi
pwd
ls -latr
sh -c "cf7 $*"

Please note:

• The cf-cli-action is based on a user (@citizen-of-planet-earth) contribution available on the GitHub Marketplace.
• This repo can exist as a fork/clone/copy anywhere, or can be invoked directly by using the cf-cli-action@master annotation within the main.yml of GitHub Actions.

This is a good segue to the second part of the workflow, which is the main.yml located inside the .github/workflows folder. This is the default configuration for GitHub Actions.

Click on the “Actions” tab of your repository. This will open up a page with several options to setup a Github Workflow. Choose the one that says “Setup a Workflow Yourself →”.

This will create a main.yml file inside the repository, under the .github/workflows folder. The main.yml file has the context, trigger, and statements represented in a declarative syntax. The contents of the main.yml file we will be using are:

name: Deploy Using Actions
on:
  push:
    branches:
      - master
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - uses: ram-demos/cf-cli-action@master
      with:
        cf_api: https://api.34.70.72.42.xip.io
        cf_username: ${{ secrets.CF_ADMIN_EMAIL }}
        cf_password: ${{ secrets.CF_ACCESS_PASSWORD }}
        cf_org: sample
        cf_space: test
        command: push

The main.yml file takes a name, a trigger, and executes any number of jobs. The complete documentation for the file is available here. The important things to know are the two steps which the automation workflow needs to take. The first is to checkout the source code into the container that has been created using the Dockerfile from the cf-cli-action repo. The second is to use the cf-fli-action commands and deploy the code using the cf push command. This main.yml file will also supply all the values required for signing into the right Cloud Foundry tenant and setup the target for deployment.

Here’s an English translation of the main.yml file — This workflow is named “Deploy Using Actions”. When any code is checked into the ‘master’ branch of the current repo, this workflow needs to be triggered. Once triggered, run the job named ‘deploy’ on the latest LTS Ubuntu release available. The job named ‘deploy’ will first execute the set of instructions included within the built-in actions/checkout component, which will switch the code to the latest version from the target entity. It will then run the cf-cli-action from another repo, which will login to the remote Cloud Foundry instance by using the cf api endpoint, username, password, target org, target space, and finally execute the cf command specified.

Once you set this flow up, any code that is pushed into the GitHub repo will trigger a fully automated build and deploy flow.

This tutorial is meant to serve as a first step to automating deployments made using Cloud Foundry. Cloud Foundry provides a highly efficient, modern model for cloud native application delivery on top of Kubernetes — and we would like software development teams of all shapes and sizes to take advantage of this simplified developer experience.

For more information, please visit cloudfoundry.org. The best way to connect with the Cloud Foundry community is to join our Slack Workspace at https://slack.cloudfoundry.org/. Those in the Slack community will help you get answers to any queries you may have about using Cloud Foundry.