Terminating Sidecar Containers in Kubernetes Job Specs

Kubernetes Jobs
are useful for one-off tasks. However, there are some problems when
you have to define sidecar containers
in your job spec. Primarily, the job’s pod will not terminate
when the sidecar containers are still running. If your sidecar container is a
logging agent or a proxy for other services,
they usually do not terminate. Furthermore, the sidecar container must terminate
with an exit code of 0 or else the job may restart.

One suggested solution is to have a script watch for the creation of a file on
a shared volume. When the script detects a file, the script will terminate the
container. For instance, here is a sample job spec which waits for a file to be
created in a shared volume in a sidecar container:

The usage of inotifywait is to be a bit more efficient than just using
sleep. In the above example, instead of modifying an existing image,
the commands to run the sidecar container are slightly modified and a script is
mounted via a volume to the sidecar container.

While watching for a file to be created is not exactly ideal, it is a quick
workable hack until a general solution is available.

Terraform Remote State

When using Terraform, I find that storing state
remotely has great benefits.
If you work with others or on multiple machines, remote state allows re-using
Terraform defined infrastructure without copying the state manually to all other
users. More importantly, it allows a “core” set of resources to be defined and owned
by one project while
the root level output resources are re-usable
in other related Terraform projects.

The core infrastructure that I generally have are definitions for DNS zones
(so related projects can import the DNS managed zone identifier and create
subdomains), wildcard SSL certificates for test domains, and general repository
definitions for where the code is stored.

If you have multiple users, you will need to look into remote state locking
solutions as well with your backends,

Set Global Prefix Config for npm

So when installing npm modules globally, they will be installed in a directory
that’s owned by my user instead of to a system directory. This prevents write
permission issues when trying to install modules not owned by my user.