A Kubernetes controller is a piece of software that continuously watches at least one type of Kubernetes resource type for changes. When a watched resource does change, the controller is responsible for making any necessary changes to the cluster in order to achieve the desired state. This process is known as reconciliation.
I recently added user impersonation to the Kubernetes client for Node.js. When this feature was requested, I went looking for some official documentation. Apparently, I was not the only one. Unfortunately, that issue only links to the Kubeconfig schema reference, and not any actual examples. So, I decided to write up something short and simple. For additional information, see the official impersonation docs.
EKS has a nice feature called IAM Roles for Service Accounts (IRSA) that allows Kubernetes service accounts to assume AWS IAM roles using annotations. This is nice because it allows you to avoid long-term credentials like access keys in your applications. Unfortunately, like many things on AWS, IRSA can be a bit tedious to configure properly.
I occasionally need to setup multi-factor authentication (MFA) for AWS IAM users that have no access to the AWS web console. This happens often enough that I need to lookup the commands each time, but not often enough that I have ever written it down. That changes now.
It's almost that time again. Node 22 is currently scheduled to be released in about a week and a half. I'd like to briefly mention some of the changes that have gone into Node's test runner (node:test) recently because they are unlikely to get called out in the official release notes.
When the Node.js test runner was initially created, it was supposed to be very minimal. Of course, developers are never happy with simple and/or minimal, so the test runner has already grown far beyond what it was ever intended to be. Since that trend seems likely to continue, I have put together a short wishlist of improvements that I would love to see in Node's test runner even though I have moved on from Node.js myself.
In order to pull private Docker images from ECR into Kubernetes, you need to authenticate with the Docker registry. The credentials can then be stored in a Docker config secret. However, the credentials in that secret will eventually expire, leading to failures when pulling. One solution to this problem is to periodically refresh credentials via a CronJob.
Sometimes you need to configure HTTPS locally using a self-signed certificate. Here is a quick step by step guide. Note: this guide does not rely on "insecure" options such as curl's --insecure flag.
OpenTelemetry is a collection of APIs and tooling for adding tracing, metrics, and other telemetry data to applications. One of those tools is the OpenTelemetry Collector, or otelcol.
At some point in the distant past, certain Node.js projects adopted the convention of using the NODE_ENV environment variable to denote how the project was being run. For example:
Kubernetes allows Docker images to be pulled from arbitrary registries and spun up as pods in a cluster. Both public and private Docker registries are supported. For example, the following Deployment (copied from the Kubernetes documentation) pulls the nginx:1.14.2 image from Docker Hub. Note that a similar configuration is possible in a Pod definition.
Amazon's Elastic Container Registry (ECR) is a fully managed Docker container registry. If you have ever used Docker Hub, ECR is essentially the AWS equivalent. You can push to, pull from, and otherwise interact with ECR using the Docker CLI tools.
Node.js began shipping an experimental test runner starting in version 18). A year later, in Node 20, the test runner was marked stable. Since its introduction, I would say the test runner has been generally well received. I have read blog posts, interacted with users on the Node.js issue tracker, listened to conference talks and YouTube videos, and even had conversations with people in real life like the old days. I have noticed a few points that keep coming up, so I decided to write this blog post to help people set appropriate expectations for Node's test runner.
The Node.js TSC participated in an AMA recently. I was lucky enough to be one of the TSC panelists. You can read about the AMA on the OpenJS Foundation blog, or watch the full video here.
This post is a more detailed followup to this tweet in which I advocate for using Node's assert module as your goto assertion library.
This post originally appeared as part of JavaScript January 2018.
A key aspect of understanding a program's runtime behavior is identifying where it is spending its time. Generally, an application will either be waiting on I/O or performing calculations using the CPU. Node.js is excellent at handling large amounts of I/O, but must be cautious about CPU utilization because of its single threaded nature. Luckily, developers can identify, and even visualize CPU hotspots in their code using a profiler.
As Node.js developers, we are extremely spoiled. The level of abstraction provided to us by JavaScript allows us to focus on creating interesting applications instead of wrestling with low level system concepts such as threads and synchronization. But, whether we like to think about it or not, our JavaScript code sits on top of a lot of low level code, mostly written in C/C++, as shown in the following figure. This article will trace a simple JavaScript function call as it traverses various layers of this figure. A basic understanding of the event loop is assumed. If you need an introduction or refresher, check out this guide.
Node.js seems to increase in both popularity and sophistication on a daily basis. The project recently scored a major feature, as support for the V8 Inspector was merged into Node's master branch. This gives Node applications direct integration with DevTools, the top notch debugging tools that ship with Google Chrome. Unlike previous tools like Node Inspector, there are no required external dependencies except Chrome. The Chrome Debugging Protocol, used by V8 Inspector, can also communicate with tools from other vendors such as Microsoft and Firefox.
The Internet is not a safe place. Sometimes, not even the simple act of downloading a file is what it seems. On February 20th 2016, hackers created a modified Linux Mint ISO containing a backdoor, and linked to it from linuxmint.com. A blog post was issued containing instructions for detecting the compromised ISO.
In September of 2015, I gave a talk on Node v4.0.0 at the Nova Node meetup. The talk covered the road to v4, the io.js fork, convergence, what has changed, and a look into the future, including LTS. You can listen to the talk here.
NodeUp is a popular podcast covering the Node.js community. In July of 2015, I was a guest on episode #88, which focused on the ongoing Node.js/io.js convergence process. You can listen to the entire episode here.
Although JavaScript is very powerful, the language's fundamentals do not have a very steep learning curve. Prior to the explosion of web applications, JavaScript was thought of as a toy language for amateur programmers. Some of JavaScript's features were specifically designed to cater to beginners. One such feature is automatic semicolon insertion. Automatic semicolon insertion is also one of JavaScript's most controversial features.