Since its introduction in 2014 to the world, Kubernetes has been helping usher in the next generation of distributed workloads. As workloads started to be containerized, so did the need to manage the containers, thus the inception of container orchestrators. There have been a few container orchestrators out there before Kubernetes such as Docker Swarm and Apache Mesos. Though as a feature developer, Kubernetes can certainly feel like an 800-pound gorilla in the room. In this tutorial, we will go over the what, where, and why of containerization and Kubernetes. For the first out of two parts, we will go over what a container and Kubernetes are and Dockerize a NodeJS application.
Containers
If you mention containers to a technologist, most likely they would immediately jump to Docker. Though there has been containerization well before the Docker format and ecosystem was created in 2013. For example, LXC e.g Linux Containers and Solaris Zones were around for a while. Containers contain exactly what your application needs to run and can be portable. Compared to a physical or virtual machine, containers are smaller in footprint and start time since they are a smaller profile than an entire operating system. Semantics-wise, an image [e.g what you create] turns into a container when the image is running. Though when compared to a physical or virtual machine, containers by their nature are ephemeral meaning they are short-lived per se and designed to die. The ephemerality of containers has to be taken into design consideration, especially for stateful workloads. As a container has a lifecycle e.g an inception and an end, tooling had to be created to manage this thus the genesis of Kubernetes.
Howdy Kubernetes
If you only had one running container, there would not be a need for a container orchestrator. Though most likely your organization or even your very own workload would have more than one. Hitting GitHub in the Summer of 2014, Kubernetes has become the prominent container orchestrator in the marketplace. Hailing from a few internal projects such as Facebook Tupperware, Google Borg, and Microsoft Apollo, Kubernetes has taken learnings from these platforms even as Kubernetes continues to evolve. Kubernetes is a core container orchestrator meaning Kubernetes handles resource management and scheduling. Basically, Kubernetes will place work and enforce a schedule e.g minimums and maximums. What separated Kubernetes from other platforms is that Kubernetes is a declarative state system. Basically means you declare what you want and Kubernetes will try its best to fulfill what you want. This is different than imperative systems where you have to provide very exact instructions to get to the state you require. This has led to newer operational paradigms such as GitOps, but for now, we will focus on getting your JavaScript workloads onto Kubernetes.
Preparing to Make an Image of a JavaScript App
The first step to getting your trusty workload into Kubernetes is to create an image. The prominent format now deployed to Kubernetes is Docker. There are a few ways to create a Docker image of your JS application such as using a Continuous Integration Solution. If you are using GitHub, you could create a GitHub Action to build and push your Docker image to a registry. For the example, you can forgo that and just use your local machine.
Prerequisites
You will need to have an application that you will want to Dockerize and the Docker Runtime and a Docker registry to push the image to. The easiest is to fork an example application into your personal GitHub repository install the Docker Runtime and leverage public Docker Hub as a registry.
- Sample Application: https://github.com/ravilach/easy-node-docker
- Install Docker Runtime Mac: https://docs.docker.com/desktop/mac/install/
- Docker Hub: https://hub.docker.com/
Once you sign up for Docker Hub, if you don’t have a repository for your Docker image you can create one e.g “samplejs”.
After you have created a repository for your image, you can clone/download the example project onto your local machine.
Once cloned/downloaded, you should have the repository files on your local machine.
Now you are ready to run a few Docker commands.
Making an Image of a JavaScript App
To make an image of your JS App, you need a Docker engine and instructions for Docker; in this case, we are leveraging a Dockerfile. If you crack open the Dockerfile, you can see the basic format. One is to run an NPM Install and what the startup command [CMD] is. The Docker documentation has more details about what the prudent sections of the Dockerfile are.
Create a Docker Image
Creating a Docker image is straightforward. You will need to make sure your Docker engine or Docker Desktop [be sure to make sure you meet the licensing requirements for Docker Desktop].
To grab some of the naming conventions, head back to your Docker Hub repository and look at the Docker push command.
With that, you can head back to the root of your project and execute the following command. You can tag this as version “1.0.0”.
docker build --tag <your_dockerhub_user>/samplejs:1.0.0 .
You will see Docker creating all of the Docker layers created. You can validate that the image was created successfully.
docker images
Pushing a Docker Image
Now that you have your Docker image, you can push your Docker image to a public repository. Docker Desktop comes pre-wired to Docker Hub, so you can use a Docker login command to authenticate.
docker login
Now that you are authenticated, you can now Docker push into Docker Hub.
docker push <your_dockerhub_user>/samplejs:1.0.0
With your first Docker push, you can navigate back to Docker Hub’s UI and see that your new tag is available.
Now that you have an image, you are ready to head to Kubernetes. In part two of this series, we will go through deploying to Kubernetes with Shipa.
Cheers,
-Ravi
