AKS is Microsoft's managed container environment hosted on Azure. Using Kubernetes, AKS gives you the power of orchestration for your applications with provisioning, upgrading and scaling. All of this without initial setup or ongoing maintenance. Kubernetes is an open-source system for automating deployment, scaling and management of containerised applications.
You may be asking why it's important to understand this infrastructure. With a lot of infrastructure moving towards containerised solutions it's worth understanding, as a Node.js developer, how your applications run in a production environment.
Being able to replicate a production setup on your local machine can make debugging issues quicker and easier.
Understanding the build process once you're ready to ship code can help avoid situations where developers don't understand how applications are built and run in production.
Shared knowledge can help contribute towards a collaborative environment between development and operations teams.
This post steps you through deploying a Node.js application to AKS using Helm ; beginning with replicating the setup locally and then transferring over to a hosted, production-ready environment.
Helm makes managing Kubernetes applications easier via customisable Charts which define application setup, provide repeatable installations and serve as a single point of authority.
Before diving into the Azure setup, let's replicate the production setup locally. This provides you with a playground to test changes without the need to push to a hosted environment.
Heres what the local setup looks like:
To build your Kubernetes deployment, service and ingress run the following command:
A Helm chart is a collection of files describing Kubernetes resources using templates and configuration files.
Templates use values from configuration files, the default being
values.yaml or from overrides defined on the command line using the
Rather than taking the values from the default
values.yaml file pass in an override file called
values.dev.yaml with specific settings for local deployment.
To ensure everything is up and running run
kubectl get pods .
This gives you a list of pods and their status.
If for any reason any of the pods don't have the 'Running' status then it's likely that there was a problem with the installation.
kubectl describe pod react-pwa-app- to list the events that took place during installation.
Another useful command you can run against your pods is
kubectl logs react-pwa-app- . If your application is 'Running' then you can see the logs from your application initialisation.
Once your pods are up and running set up an NGINX ingress controller daemon to act as a load balancing proxy for your applications.
Run the following command:
Rather than creating your own charts, you can use charts from the Helm registry for this.
The controller listens for deployments or changes to ingress resources, updates its NGINX config and reloads when required.
Finally, add a host entry to map localhost:80 to hn.nearform.local, you can do that with the following command:
Now navigate to hn.nearform.local in your browser to see your application running.
If you get a response but it's not what you're expecting then make sure there isn't anything already running on port 80, you can check by running the following command:
If there is something else running you may be able to disable it with the following command:
Now you have a local setup close to production that can be ported over to Azures hosted solution!
To update your application in the cluster re-run the docker build command to rebuild the image and then run upgrade with Helm:
Now that you're running locally its time to port it over to a hosted environment to create an externally accessible application.
Heres what the setup looks like on AKS: as you can see it mirrors our local setup closely.
Microsoft already has some very good documentation on setting up your Kubernetes cluster and a container registry on Azure. I'd highly recommend following the guide on setting up your Azure environment .
What isn't covered here though, and what we'll go over in this post, is the use of Helm for AKS deployments.
You've taken a Node.js application and deployed it to a modern infrastructure while avoiding some of the setup and maintenance costs associated with building a production ready, scalable, containerised solution.
The declarative nature of much of this setup lends itself well to automation. The next steps are to automate the process of upgrading applications via CI as well as scripting the initial setup to be replicable for any application.