Deploying Nodejs sample application on Kubernetes

1. Sample application:

The goal is to have a simple Node.js web application that prints “Hello World!” when accessed via HTTP. The first part is the Dockerfile. This defines how to package up the application into a Docker container image that can run standalone.

Some key points:

• FROM node:16-alpine: Builds on top of an existing Node.js Alpine Linux image. This gives us Node already installed and optimized Linux OS.
• WORKDIR /usr/app: Sets default directory for following commands. Good practice for organization.
• COPY app.js .: Copies our application code file from host into the image directory.
• CMD [“node”, “app.js”]: Runs the application using node command to execute our app.js code.

Dokerfile:

FROM node:16-alpine
WORKDIR /usr/app  
COPY app.js .
CMD ["node", "app.js"]

Next is the app.js code itself:

1. const http = require(‘http’): Imports Node.js HTTP server library
2. createServer(): Creates new HTTP server instance
3. res.end(‘Hello World!’): Sends “Hello World!” text when requests received
4. server.listen(3000): Starts HTTP server on port 3000

In summary, the Dockerfile packages up the Node app, while the app.js prints “Hello World!” via a simple HTTP server on port 3000 for us to access the greeting.

const http = require('http');

const server = http.createServer((req, res) => {
  res.end('Hello World!');
});

server.listen(3000);

Container Image

$ docker build -t myaccount/hello-world:v1 .
$ docker push myaccount/hello-world:v1

The basic flow is:

1. Package application code into container image
2. Push image to a registry like Docker Hub
3. Kubernetes will pull image onto nodes to deploy app

The docker build command:

• -t myaccount/hello-world:v1: Tags image with repository name and version tag
• .: Specifies context of current directory for Dockerfile
• Packages up app files into portable image layering on Node.js base

Next, docker push:

• Publishes the application image to Docker Hub repository
• Requires Docker Hub account and repository for image storage
• Uploads our built image using account credentials and target repo name
• Allows Kubernetes cluster to access image from anywhere

The major benefit of this image build/publish flow is decoupling application packaging from deployment. The image serves as fixed unit that then gets run anywhere.

So in summary, we take app code → containerize into image → push to registry → deploy image onto Kubernetes. This enables a consistent environment for the app across infra.

Many websites and apps now run on clusters of computers called containers. Containers let apps run smoothly as groups work on updating and improving the software behind the apps. A system called Kubernetes helps manage and update all those containerized apps. Sometimes app updates go wrong or cause problems for users. Kubernetes has clever ways to update apps that avoid issues.

The main method is called a rolling update. This slowly switches the software behind the scenes from an old version to a new one. A few containers at a time are updated to the new software. Kubernetes checks that each small batch works fine before updating more. This means no downtime for users! Another useful capability is rollbacks. If a new software version causes glitches, Kubernetes can automatically revert to the previous stable version. There is no need for websites to crash or stay broken!