Acorn Images Are Special

At this point, I need to take a minor detour and talk about Acorn images, because they are quite special. Viewed formally, they are regular and standards-compliant Docker images, which means that Acorn images can also be uploaded to Docker Hub or any other container registry that supports the Open Container Initiative (OCI) specification for container images.

However, unlike Docker-only images, Acorn images contain significantly more information and material in their metadata and overlay compared with the basic image. In principle, the requirement for an Acorn container is always that it contains all the components needed to run an application without exception. For this reason, existing images cannot easily be used with Acorn. As described, Acorn is an application that uses the image together with the application as a kind of package in the form of a container.

But this does not mean that standard images from the major vendors cannot at least be used as a basis for your own images in Acorn. The process of moving from a pre-built image to a custom image with a suitable configuration is straightforward.

Your Own Image

The way an Acorn image is created is a good way to understand how Acorn works in detail. Development always starts with an empty directory; then, you copy your own files to the directory so that they will be in the container later. You have no limits to what you can do here. For example, if the Docker base image that will be used later uses Debian or Ubuntu, a DEB package you want to install in the container could be saved here.

Basically, the Acorn container format wraps itself around existing Docker containers like a cocoon, which is also expressed by the need to have a normal Dockerfile that meets all formal requirements inside the working folder for the new Acorn image (Figure 3). The FROM directive specifies which base image (e.g., from Docker Hub) will be used. Files for the working folder of the new Acorn image are added by the ADD directive. Details for building Docker containers can be found in a number of tutorials online. Once the Dockerfile is prepared accordingly, it's time to do the Acornfile work.

Figure 3: Without a Dockerfile, an Acornfile is useless. Acorn builds its own local container with docker build. To do this, you need a file named Dockerfile, and it must be syntactically correct.

The Acorn syntax, which is loosely based on the CUE language now takes over. It is reminiscent of JSON or YAML and is not particularly difficult to learn. The Acornfile is divided into several blocks; again, the Acorn documentation provides detailed information [2]. For example, a separate block named args lets you define variables that Acorn automatically substitutes in when the variable is accessed. However, the most important section is the containers section. It defines the parameters of the application container to be built by Acorn itself and, at the same time, lists other containers that can be part of the deployment. The app named app plays a key role, because it is the direct pointer to the local app that you want Acorn to wrap in a container. If a Dockerfile exists, the build: "." statement in the app section ensures that Acorn triggers the build process.

It is important not to underestimate the option of configuring additional containers at the same time. For example, if the app in the container requires PostgreSQL as a database, a suitable container (postgres:alpine) can be started directly from the Acornfile and provided with the appropriate parameters for later operations. In most cases, this means at least defining the port in the ports statement, as shown in the example from Listing 1.

If containers supplied by manufacturers are to be supplemented with local files, you can do so in the container definition with the files directive. The dirs parameter can also be used to assign volumes to folders in the container. However, for this to work, the Acornfile also needs to include a volumes section outside of the containers section with the appropriate volume definition; otherwise, Acorn will not create the referenced volume when deploying to Kubernetes, and the reference will go nowhere.

If you need a password in the container, you can use the secrets directive in Acorn to create it automatically and have it stored in Kubernetes. The password can also be displayed later with the K8s API, if necessary. However, this will only be necessary in the rarest of cases. Either way, Acorn prevents repeated use of the same password by not accepting a default password but creating one dynamically and making it usable as a parameter for the applications in the containers. References between fixed values such as arguments and passwords and other directives are explicitly provided for in Acorn. You could access the defined password, pg-pass, elsewhere in the Acornfile, for example, with secret://pg-pass/token.

Now continue with the

acorn run -n lm-test .

command, which creates a container with the content of the local directory in Kubernetes named lm-test, or you can decide to make a genuine, distributable image of your application:

acorn login <host-name>
acorn build -t <host-name>/<label>/<tag> .
acorn push <host-name>/<label>/<tag>

Note that <host-name> needs to be replaced by the hostname of the Docker registry, label with a unique identifier (e.g., lm-test), and tag with a valid version number (e.g., v0.1). Once the push completes, the image can be launched and used in any Kubernetes cluster with the

acorn run -n lm-test <host-name>/<label>/<tag>

command.

Infrastructure as Code

One of Acorn's great strengths is the ability to define the entire infrastructure of a virtual container environment in Kubernetes in simple template language. The obvious choice is to use this advantage for true Infrastructure as Code.

The idea is that container development for Acorn takes place in a Git directory, which also serves as classic version control. Services such as GitLab or GitHub all support the use of hooks (i.e., triggering actions in response to certain events). A push command to a directory managed by Git to build Acorn containers can be such an event. In the Acorn documentation, the developers describe in detail how hooks in GitHub can be used to create a new image with a new version every time the files in the folder are changed and uploaded to a container registry.

This process will especially benefit environments that use Acorn on a large scale and want to roll out containers on many different Kubernetes platforms. This automatic mechanism makes sure that the latest image is available everywhere in the environment immediately after a Git commit.