What is Helm?

From the Helm website: “Helm helps you manage Kubernetes applications”.
If you use Kubernetes, there’s a good chance you will be using at least some portion of Helm. Helm has many features, and is most well known for Helm Charts. You can (and should) also use Helm to deploy your application to Kubernetes.

Helm Post-Renderer

The Helm Post-Renderer feature allows Helm to deploy an application using advance configurations using tools like Kustomize.

Windows Batch Script with Helm Post-Renderer and WSL

I want my Kubernetes deployment (using Helm and Kustomize) to be able to work on my laptop, and also in a GitLab CI/CD pipeline. And because my Windows laptop has WSL (no WSL2!) I can do a few cool Linux things with it, like directly run Helm commands (Maybe WSL2 also has this problem). If only I could use a real Linux laptop at work, but anyways..

The Helm Post-Renderer gives an error when running a Linux Bash script in WSL. So much to my amazement, in 2021 I needed to write a Windows Batch Script!

Error message in WSL

Running a Helm install/upgrade gives the error:

helm upgrade --install release123 my-charts/app123-charts --version=0.1.0 --namespace=dev1 --values=../values.yaml --post-renderer ./kustomize.sh --debug --dry-run

## Error: error while running post render on files: error while running command \\C\Users\username\helm\my-charts\app123-charts\app-kustomize\kustomize-post-render\kustomize.sh. error output:
## : fork/exec \\C\Users\username\helm\my-charts\app123-charts\app-kustomize\kustomize-post-render\kustomize.sh: %1 is not a valid Win32 application.

Just the error:

%1 is not a valid Win32 application.

Okay, that’s interesting. Running a helm command gives me a Windows related error. So now we need to do it the Windows way.

Helm Post-Renderer Windows Batch Script

This Windows Batch Script will work from Windows (kustomize.bat):

@echo off

REM fix mapped drive in TS: https://stackoverflow.com/questions/9013941/how-to-run-batch-file-from-network-share-without-unc-path-are-not-supported-me/34182234#34182234
@pushd %~dp0

REM findstr is pure windows command: https://superuser.com/questions/853580/real-windows-equivalent-to-cat-stdin/1425671#1425671
FINDSTR . > all.yaml

kustomize build . && del all.yaml || exit 1

@popd

The above Batch Script also works from a Windows Terminal Server that is mapping a drive.

Helm Post-Renderer Linux Bash script

For reference, the same in Linux would be (kustomize.sh):

#!/bin/bash

cat <&0 > all.yaml

kustomize build . && rm all.yaml

Above Linux bash script source: Taylor Thomas.

Conclusion

With this Windows Batch Script, you can run Helm install/upgrade commands directly on your Windows laptop so you can deploy to your local or remote Kubernetes cluster. This can help to debug your true pipeline deployments, if using something like GitLab CI/CD since it’s now possible to deploy using the same method.

The post Helm Post-Renderer and an ugly Windows Batch Script appeared first on Ryan Daniels.

Using a dynamic Dockerfile can have great benefits when used in your CI/CD pipeline. You can use the ARG statement in your Dockerfile to pass in a variable at build time. Even use a variable in the FROM statement! Dockerfile ARG FROM ARG. That will make more sense later.

This post is about Container virtualization technology, and problems when building a container image using Docker Engine.
For some background on a dynamic Dockerfile, check out Jeff Geerling’s post.

One problem I’ve come across with this, is the Dockerfile ARG variable usage isn’t intuitive. It is actually kind of weird. And I’m not alone on this! There’s lots of feedback in GitHub Issue #34129.

What’s the Problem?

A variable declared at the top of the Dockerfile using ARG doesn’t work if you try to use it after the FROM statement. Not by default at least. It only works if used in the FROM statement.

ARG TAG=latest
FROM myimage:$TAG # <------ This works!
LABEL BASE_IMAGE="myimage:$TAG" # <------ Does not work!

The FROM above will use the TAG passed in from a build-arg, or default to use the string “latest”.
But the LABEL won’t work. The TAG portion will be empty!

This was tested with the most recent version of Docker Engine (version: 19.03.5).

How Does it Work?

To use a variable in the FROM section, you need to put the ARG before the FROM. So far so good. But, now let’s use that variable again after the FROM? No you can’t. It’s not there. Unless you use another ARG statement after the FROM.
Wait, it gets more weird. Any ARG before the FIRST FROM, can be used in any FROM (for multi-stage builds). In fact the ARG must be above the first FROM even if you only want to use it in a later FROM. Wow, that’s a lot of ARGs and FROMs. The ARG is kind of “global” but only if you declare it again inside the build stage.

Dockerfile ARG FROM ARG

Let’s look at an example to make it easier. Below is not a useful Dockerfile. It’s only an example to illustrate this.

#These ARGs are used in the FROM statements
#Or as global variables if declared again (without the default value)
ARG BUILDER_TAG=latest
ARG BASE_TAG=latest
ARG APP="app.go"

#First build stage
FROM mybuildapp:$BUILDER_TAG AS builder
ARG APP
RUN compile_my_app $APP

#Second build stage
FROM registry.access.redhat.com/ubi8/ubi-minimal:$BASE_TAG
ARG BASE_TAG
ARG APP
LABEL BASE_IMAGE="registry.access.redhat.com/ubi8/ubi-minimal:$BASE_TAG"
COPY --from=builder $APP .

Now, let’s run the example build:

docker build . \
  --pull
  --build-arg BUILDER_TAG="2.0" \
  --build-arg BASE_TAG="8.1" \
  --build-arg APP="the_best_app.go" \
  -t image_tag

Once the Docker build finishes, this is the result of your command line argument usage inside the docker image:

BUILDER_TAG="2.0"
BASE_TAG="8.1"
APP="the_best_app.go"

Results

The BUILDER_TAG and BASE_TAG will be used in the FROM statements. BASE_TAG is also used inside the second build stage. And APP will be used in both build stages. ARG APP="app.go" only needs to be declared if you want to set a default value. In my example we don’t really need that since we are passing in a build argument.

Conclusion

Remember that ARGs at the top of the Dockerfile can be used in the FROM statements. They are “global” only if you declare the ARG again in each build stage (after FROM (and before the next FROM if using a multi-stage build)).
You can remember it this way: Dockerfile ARG FROM ARG
But, after wasting an hour on this, it was more like: Dockerfile Arrggh! FROM Arrggh!

You can use something like this in your CI/CD, for automatic docker image building.

Side note: Building an image using Podman does not have the same issue as Docker Engine (tested with Podman version 1.4.4, 1.6.3, and 1.7.0). You do not need to specify the ARG again inside the build stage when Podman creates the container image!

Further reading:
Dockerfile Reference: Understand how ARG and FROM interact
Dockerfile Reference: Scope
Multi-Stage Builds

The post Dockerfile ARG FROM ARG trouble with Docker appeared first on Ryan Daniels.