Deploying Microfrontends to Kubernetes

In the previous chapter, we learned how to manually deploy our microfrontends to a static storage provider such as Firebase.

In this chapter, we will go deeper into cloud and DevOps territory by learning how to deploy our apps to a managed Kubernetes cluster. Kubernetes has become the de facto choice to deploy enterprise-grade web apps (both backend and frontend) to the cloud.

When it comes to deploying SPAs, we run usually the webpack build command to generate our JavaScript bundles and assets in the /build or /dist folder, which we then simply copy to a static website hosting provider to make our app available to our users. However, deploying microfrontends is a bit more complex.

In this chapter, we will see how to deploy our module-federated microfrontend to a managed Kubernetes cluster.

We will cover the following topics:

• How to containerize our apps using Docker
• The basics of Kubernetes and its various components
...

Technical requirements

In addition to all the standard technical requirements that we mentioned in the previous chapters, you will need the following:

• An Azure cloud subscription
• Access to GitHub and GitHub Actions
• A high-level understanding of CI and CD concepts
• Knowledge of Docker and containerizing apps will be helpful

The code files for this chapter can be found at the following URL, where we essentially started with the microfrontend we built in Chapter 6: https://github.com/PacktPublishing/Building-Micro-Frontends-with-React.

We also assume you have a basic working knowledge of Git, such as branching committing code and raising a pull request.

Introduction to Kubernetes

Kubernetes, also known as K8s, has taken the cloud and DevOps world by storm. Originally developed by Google and now part of the Cloud Native Computing Foundation, Kubernetes provides all the tools necessary to deploy and manage large-scale, mission-critical applications on the cloud from a single interface.

Traditionally, managing a large-scale, production-grade application on the cloud meant having to deal with things such as web servers, load balancers, auto-scaling, and internal and external traffic routing. Kubernetes now brings all of that under a single umbrella and provides a consistent way to manage all the components of a cloud environment.

The premise of Kubernetes is that you tell it the end state of what you want via a spec file, and Kubernetes will go about getting it done for you. For example, if you tell Kubernetes that you want three replicas for your application with a service load balancer, Kubernetes will figure out how to spin up...

Containerizing our micro-apps with Docker

Containers are a way to package software applications in a standardized and portable way, allowing them to run consistently across different environments. They provide a lightweight and efficient way to run applications and are particularly well-suited for microservices architectures, where an application is composed of multiple, independently deployable services.

In this section, we will look at how to install Docker and create a Docker image by creating a Dockerfile.

Installing Docker

Docker Engine is available for personal use on multiple Linux, Mac, and Windows systems via Docker Desktop. You can follow the instructions here to install the Docker engine: https://docs.docker.com/engine/install/.

Note

If you don’t want to or can’t use Docker Desktop on your Windows or Mac, there are alternatives, such as Rancher Desktop, Podman, and Colima.

Once you have Docker installed, verify it by running the following...

Creating a Kubernetes configuration file

Earlier in this chapter, in the Introduction to Kubernetes section, we learned about the various Kubernetes services that we will use to deploy our microfrontends.

Deploying these services on Kubernetes is commonly done by defining the various configuration settings in a .yaml file and then applying the configuration to the Kubernetes cluster.

In this section, we will learn about the structure of these Kubernetes spec files and how to go about creating them for our deployments, services, and Ingress.

The structure of a Kubernetes spec file

A Kubernetes spec file is a YAML document that describes the desired state of a Kubernetes object, such as a Deployment, Pod, Service, or ConfigMap. The structure of a Kubernetes spec file generally consists of two main parts – the metadata section and the spec section. Each file always starts by defining the apiVersion and the kind of spec file.

The metadata section includes information...

Setting up a managed Kubernetes Cluster on Azure

In this section, we will learn how to set up a managed Kubernetes cluster on Azure. The reason it’s called managed is because the master node, which is sort of the brain of Kubernetes, is managed by Azure, and we only need to spin up the worker nodes. We will see how to log in to Azure and create a subscription key, and we will install Azure CLI and collect the various credentials that we need for our DevOps pipeline.

For this chapter, we will use Azure Kubernetes Service (AKS) to set up our cloud-based managed Kubernetes cluster. You can also set up a managed Kubernetes cluster on Google Cloud using Google Kubernetes Engine (GKE), or you can use Amazon Elastic Kubernetes Service (EKS) on AWS.

Irrespective of whichever hosting provider you use to set up your Kubernetes cluster, the Dockerfile and the Kubernetes configuration .yaml files remain the same.

Logging into the Azure portal and setting up a subscription key

...

Setting up CI/CD with GitHub Actions

In this section, we will learn how to go about setting up a DevOps pipeline using GitHub Actions. A DevOps pipeline is a series of steps that we define to automate the build and deployment of our apps. In this section, we will learn how to set up GitHub secrets and the workflow .yml file.

GitHub Actions is an automation and workflow tool provided by GitHub that allows developers to automate software development workflows and streamline their software development process. With GitHub Actions, you can create custom workflows that automate tasks such as building, testing, deploying, and releasing code directly from your GitHub repository. Other tools that we can use for CI and CD are Jenkins, Azure DevOps, Google Cloud Build, and so on. For the purpose of this chapter, we will use GitHub Actions.

Setting up GitHub secrets

As part of the CI and CD steps, GitHub Actions needs to push the Docker image to Docker Hub and spin up new Kubernetes...

Updating the remotes

Once you have your pipelines deployed successfully, log in to portal.azure.com, go to the Kubernetes services, select your Kubernetes cluster, go to the Services and Ingress link, and note the external IP address for the service of the micro apps.

You can achieve the same by running the kubectl get services command in the terminal.

Once we have the IP address, we need to update our module federation remotes with the updated URLs.

Now, as you may have figured out, the URLs for our microapps are different locally and on Kubernetes. Since we want to be able to run our apps locally as well as on Kubernetes, we will need to conditionally load in the remotes based on whether the app is running in dev or production mode. We do this as follows:

In the apps/home/next.config.js file within the remotes object, we update the code as follows:

const remotes = (isServer) => {
  const location = isServer ? "ssr" : "chunks";
 ...

Summary

And with that, we have come to the end of this chapter. I hope you have been able to follow along and enjoyed the joys and pains of wearing a DevOps engineer’s hat.

As you can see, we covered a lot in this chapter. We learned about Kubernetes and its various key components. We saw how you spin up an empty Kubernetes cluster on Azure and learned about the Kubernetes spec files that deploy our micro apps into a Kubernetes cluster. We learned how to containerize our micro apps using Docker and how to set up Docker Hub as a remote image repository. Then, we went through the detailed steps of setting up a CI/CD pipeline using GitHub Actions, and finally, we made the necessary tweaks to our code base so that we can run our module-federated microfrontend on Kubernetes. Now that you have managed to complete this chapter, give yourself a pat on the back and take a well-deserved break before we start with the next chapter, where we will see how to manage our microfrontend in...