Modern Frontend CI/CD Architecture — The Missing Guide (Part. 2): The CD.

This is the second part of the "Modern Frontend CI/CD Architecture — The Missing Guide". We recommend you read the 1st part about how to set up a Continous Integration pipeline.

tl;dr: The complete diagram of the Frontend CI/CD architecture pipeline.

Kubernetes as our CD pipeline

Now that we have a working Continuous Integration, let’s configure the Continuous Deployment using Kubernetes as our deployment orchestrator.

We’ll assume you’re familiar with the basics of Kubernetes. If not, head over to the official website for more information.

First things first, let’s create a Kubernetes cluster (if you don’t have one ready). For the purpose of this blog post, we’ll just create a g1-small instance using the new template menu recently introduced by GCP:

GCP default template configuration for Kubernetes clusters

Note: make sure you set at least 3 nodes for this cluster, otherwise GKE may have some issues upgrading your Pods.

Next, in order for Kubernetes to deploy our containers — the snapshots we built earlier by the CI pipeline — after each build, we will have to create three components (these are all what we need for our purpose):

1. a Deployment controller;
2. a Service;
3. an Ingress Resource.

Deployment controller

This deployment will create a Kubernetes Pod and we will name it following this custom pattern: xlayers-_SHORT_SHA_. The final name would look something like: xlayers-47c200d.

Note 1: Before applying this configuration, we’ll substitute _SHORT_SHA_ with the correct value provided by Cloud Build.

Note 2: We didn’t specify the replicas for the deployment. So this will default to 1. You may wanna increase the replicas to meet your needs.

Most importantly, this Pod will be attached to a container named xlayers, on port 80. The container created is based on a specific snapshot image pushed by the Cloud Build CI (see steps above).

Service

This service specifies how to access the set of Pods created by the deployment. The targeted Pods are defined by the spec.selector.app field. Here we need these Pods to be accessed on port 80.

Ingress Resource

Finally, this Ingress resource contains a set of rules that allow inbound connections to reach the cluster services. In our scenario we want an URL like https://xlayers-47c200d.angular.run/ to be forwarded to the backend — aka a service — called xlayers-47c200d.

DNS Configuration

In order to be able to map a subdomain *.angular.run, we need to update the angular.run DNS record by adding the following rule in our DNS provider:

The IPV4 address used here is the one associated to your Kubernetes cluster’s LoadBalancer.

Please note that this IP address is ephemeral! You may want to reserve a static IP address for your project.

Apply ALL THE THINGS

We’re ready now to try our CD configuration. For this, we’ll update the cloudbuild.yaml accordingly:

We simply and proudly patch our Kubernetes configuration (deployment, service, ingress) on the fly in our build steps, using simple Perl search and replace command, which substitutes the _SHORT_SHA_ pattern in our configuration file with the actual value provided by the Cloud Build environment $SHORT_SHA.

And Voilà!

Here is what we have accomplished so far on the CD part:

The Continuous Deployment pipeline.

To read more about the bonus features, head over to the part 3 of this article.

Follow @manekinekko for more updates about Web and Cloud technologies.