In a previous article, I showed how easy it was to deploy a Node.js application during development to Red Hat OpenShift using the Nodeshift command-line interface (CLI). In this article, we will take a look at using Nodeshift to deploy Node.js applications to vanilla Kubernetes—specifically, with Minikube.
Getting started
If you want to follow along with this tutorial, you will need to run Minikube. I won't cover the setup process, but Minikube's documentation can guide you through it. For the tutorial, I also assume that you have installed Node.js and Node Package Manager (npm).
The code samples we'll use are available on GitHub. Our example is a very basic Node.js application with a Dockerfile. In fact, it is taken from the Dockerizing a Node.js web app guide on Nodejs.org.
The Nodeshift CLI
As the Nodeshift module readme states, Nodeshift is an opinionated command-line application and programmable API that you can use to deploy Node.js applications to Red Hat OpenShift. You can easily run it using the npx command, and it will create the appropriate YAML files to deploy your application.
Nodeshift is a great tool to use if you are developing against an OpenShift cluster, which uses the Source-to-Image (S2I) workflow. In short, Nodeshift creates an OpenShift BuildConfig, which calls a Node.js S2I image to build your Node application. In most cases, you can achieve this by running npm install. The build result is put into an OpenShift ImageStream that resides in the internal OpenShift container registry. This image is then used to deploy your application.
But what about deploying to a vanilla Kubernetes cluster that doesn’t know anything about BuildConfigs, ImageStreams, or S2I? Well, as of Nodeshift's 7.3 release, you can now deploy your Node.js applications to Minikube.
Deploying Node.js to Minikube
Before we look at how Nodeshift works for deploying a Node.js application to Minikube, let’s take a minute for a high-level overview of deploying to Kubernetes.
First, you will create an application container image, which you can do with Docker. Once you have a container image, you'll need to push that image to a container registry that your cluster has access to, something like Docker Hub. Once the image is available, you must then specify that image in your deployment YAML and create a service to expose the application.
This flow starts to be more cumbersome when you start iterating on your code. It isn’t really development-friendly if you need to run a Docker build and push that new image to Docker Hub every time. Not to mention that you also need to update your deployment with the new version of the image to ensure it redeploys.
Nodeshift's goal is to make developers' lives easier when deploying to OpenShift and Kubernetes. Let's see how Nodeshift helps with each of those unwieldy steps.
Minikube's internal Docker server
A major difference between OpenShift and Kubernetes is that there is no easy way to run S2I builds on plain Kubernetes. We also don’t want to run a Docker build and push to Docker Hub every time we change our code. Fortunately, Minikube gives us an alternative.
Minikube has its own internal Docker server that we can connect to using the Docker Engine API. We can use this server to run our Docker build in the environment, which means that we don’t have to push the image to an external resource like Docker Hub. We can then use this image in our deployment.
To get access to the internal Docker server, Minikube has a command to export some environment variables to add to your terminal shell. This command is minikube docker-env, which might output something like this:
export DOCKER_TLS_VERIFY="1" export DOCKER_HOST="tcp://192.168.39.12:2376" export DOCKER_CERT_PATH="/home/lucasholmquist/.minikube/certs" export MINIKUBE_ACTIVE_DOCKERD="minikube" # To point your shell to minikube's docker-daemon, run: # eval $(minikube -p minikube docker-env)
Making it easier with Nodeshift
Nodeshift abstracts the details we don’t really care about so we can focus on our applications. In this case, we don’t want to think about how to connect to Minikube's internal server or how to run Docker commands by hand, and we don’t want to think about updating our deployment YAML every time we build a new image to redeploy it.
Using the Nodeshift CLI with the --kube flag simplifies those tasks. Let’s see how it works using our example application.
We will use npx to deploy the Node.js application to Minikube, so we don’t need to install anything globally. Run it like this in the example directory:
$ npx nodeshift --kube
Nodeshift creates a service and deployment by default if none are provided. Also, note that the type of service it creates is a LoadBalancer, which allows us to expose our application without using ingress.
The Nodeshift CLI runs the same goals for a Kubernetes deploy as it does for an OpenShift deploy. The key difference comes during the build phase. Instead of creating an OpenShift BuildConfig and running an S2I process on the cluster, Nodeshift uses the dockerode module to connect to Minikube's internal Docker server and run a build using the provided Dockerfile. The built image is now in that internal registry, ready to be deployed by the deployment YAML that the Nodeshift CLI creates. Nodeshift also adds a randomly-generated number to the deployment's metadata, which is then applied during every redeploy. This will trigger Minikube to redeploy the application with the new image.
The following is an example log output:
~/develop/nodeshift-starters/basic-node-app-dockerized» npx nodeshift --kube
2021-02-09T20:03:18.405Z INFO loading configuration
2021-02-09T20:03:18.452Z INFO Using the kubernetes flag.
2021-02-09T20:03:18.762Z INFO using namespace default at https://192.168.39.12:8443
2021-02-09T20:03:18.763Z WARNING a file property was not found in your package.json, archiving the current directory.
2021-02-09T20:03:18.773Z INFO creating archive of .dockerignore, .gitignore, Dockerfile, README.md, package-lock.json, package.json, server.js
2021-02-09T20:03:18.774Z INFO Building Docker Image
2021-02-09T20:03:18.848Z TRACE {"stream":"Step 1/7 : FROM node:14"}
2021-02-09T20:03:18.848Z TRACE {"stream":"\n"}
2021-02-09T20:03:18.849Z TRACE {"stream":" ---\u003e cb544c4472e9\n"}
2021-02-09T20:03:18.849Z TRACE {"stream":"Step 2/7 : WORKDIR /usr/src/app"}
2021-02-09T20:03:18.849Z TRACE {"stream":"\n"}
2021-02-09T20:03:18.849Z TRACE {"stream":" ---\u003e Using cache\n"}
2021-02-09T20:03:18.849Z TRACE {"stream":" ---\u003e 57c9e3a4e918\n"}
2021-02-09T20:03:18.849Z TRACE {"stream":"Step 3/7 : COPY package*.json ./"}
2021-02-09T20:03:18.850Z TRACE {"stream":"\n"}
2021-02-09T20:03:19.050Z TRACE {"stream":" ---\u003e 742050ca3266\n"}
2021-02-09T20:03:19.050Z TRACE {"stream":"Step 4/7 : RUN npm install"}
2021-02-09T20:03:19.050Z TRACE {"stream":"\n"}
2021-02-09T20:03:19.109Z TRACE {"stream":" ---\u003e Running in f3477d5f2b00\n"}
2021-02-09T20:03:21.739Z TRACE {"stream":"\u001b[91mnpm WARN basic-node-app-dockerized@1.0.0 No description\n\u001b[0m"}
2021-02-09T20:03:21.744Z TRACE {"stream":"\u001b[91mnpm WARN basic-node-app-dockerized@1.0.0 No repository field.\n\u001b[0m"}
2021-02-09T20:03:21.745Z TRACE {"stream":"\u001b[91m\n\u001b[0m"}
2021-02-09T20:03:21.746Z TRACE {"stream":"added 50 packages from 37 contributors and audited 50 packages in 1.387s\n"}
2021-02-09T20:03:21.780Z TRACE {"stream":"found 0 vulnerabilities\n\n"}
2021-02-09T20:03:22.303Z TRACE {"stream":"Removing intermediate container f3477d5f2b00\n"}
2021-02-09T20:03:22.303Z TRACE {"stream":" ---\u003e afb97a82c035\n"}
2021-02-09T20:03:22.303Z TRACE {"stream":"Step 5/7 : COPY . ."}
2021-02-09T20:03:22.303Z TRACE {"stream":"\n"}
2021-02-09T20:03:22.481Z TRACE {"stream":" ---\u003e 1a451003c472\n"}
2021-02-09T20:03:22.481Z TRACE {"stream":"Step 6/7 : EXPOSE 8080"}
2021-02-09T20:03:22.482Z TRACE {"stream":"\n"}
2021-02-09T20:03:22.545Z TRACE {"stream":" ---\u003e Running in a76389d44b59\n"}
2021-02-09T20:03:22.697Z TRACE {"stream":"Removing intermediate container a76389d44b59\n"}
2021-02-09T20:03:22.697Z TRACE {"stream":" ---\u003e 8ee240b7f9ab\n"}
2021-02-09T20:03:22.697Z TRACE {"stream":"Step 7/7 : CMD [ \"node\", \"server.js\" ]"}
2021-02-09T20:03:22.698Z TRACE {"stream":"\n"}
2021-02-09T20:03:22.759Z TRACE {"stream":" ---\u003e Running in 1f7325ab3c64\n"}
2021-02-09T20:03:22.911Z TRACE {"stream":"Removing intermediate container 1f7325ab3c64\n"}
2021-02-09T20:03:22.912Z TRACE {"stream":" ---\u003e d7f5d1e95592\n"}
2021-02-09T20:03:22.912Z TRACE {"aux":{"ID":"sha256:d7f5d1e9559242f767b54b168c36df5c7cbce6ebc7eb1145d7f6292f20e8cda2"}}
2021-02-09T20:03:22.913Z TRACE {"stream":"Successfully built d7f5d1e95592\n"}
2021-02-09T20:03:22.929Z TRACE {"stream":"Successfully tagged basic-node-app-dockerized:latest\n"}
2021-02-09T20:03:22.933Z WARNING No .nodeshift directory
2021-02-09T20:03:22.954Z INFO openshift.yaml and openshift.json written to /home/lucasholmquist/develop/nodeshift-starters/basic-node-app-dockerized/tmp/nodeshift/resource/
2021-02-09T20:03:22.975Z INFO creating new service basic-node-app-dockerized
2021-02-09T20:03:22.979Z TRACE Deployment Applied
2021-02-09T20:03:23.036Z INFO Application running at: http://192.168.39.12:30076
2021-02-09T20:03:23.036Z INFO complete
Following the deployment, the Nodeshift CLI also provides the URL where the application is running in the console output. The output might look something like this:
... INFO Application running at http://192.168.39.12:30769 ...
Navigating to the URL provided returns "Hello World."
Conclusion
This article gave a brief overview of the Nodeshift CLI's support for deploying to Minikube. In the future, we plan to add more Kubernetes platforms and other developer-friendly features, like possibly having the Nodeshift CLI create a default Dockerfile if there isn’t one.
If you like what you see and want to learn more, check out the Nodeshift project. As always, if there are more features you would like to see, create an issue over on GitHub. To learn more about what Red Hat is up to on the Node.js front, check out our Node.js landing page.
Last updated: March 8, 2021