Kubernetes Cookbook. Kirill Kazakov

represents the build stage.

      WORKDIR /app

      This line sets the working directory for the following instructions. It is like the “cd’ command in the shell. The “WORKDIR” instruction can be used multiple times in a Dockerfile. It will create the directory if it does not exist.

      COPY..

      This line copies the current directory’s content to the `/app’ directory in the container.

      RUN – mount=type=cache, target=$CARGO_HOME/registry/cache \

      cargo build – release

      This line runs the build command. By default, the Rust origin image includes the Cargo package manager. By Cargo command, we build the static binary of our application in a release mode.

      Mounts is a relatively new Docker feature. It allows you to mount various types of volume to the container. In this case, we mount the Cargo cache directory. The persistent cache helps speed up the build steps. If you rebuild a layer, a persistent cache ensures that you only download new or changed packages.

      FROM gcr.io/distroless/cc-debian12

      Now, we are beginning the second stage of the build process. We use the Distroless Docker image by Google, which has a minimal Linux and glibc runtime. It is designed for mainly statically compiled languages such as Rust. This image is commonly used for creating highly minimal images. We chose to use it to reduce the final image size in which our app will eventually run.

      Reducing image size is important because it decreases the time it takes to download and deploy the image. It also reduces the attack surface of the image. The smaller the image, the fewer the number of packages and dependencies it contains. This means there are fewer vulnerabilities to exploit.

      ENV RUST_LOG=info

      This line sets the environment variable. It is similar to the “export’ command in the shell. We set the “RUST_LOG” variable to the “info’ level. It means that the application will log only information messages.

      COPY – from=builder /app/target/release/auth-app.

      This line copies the binary from the first build stage to the current directory of the second stage image. We didn’t set “WORKDIR” in the second build stage, so by default, the current directory is the root directory.

      CMD [”. /auth-app”, "-a”, “0.0.0.0”, "-p”, “8080”]

      This line sets the default command to run when the container starts.

      Now, we can build the image by using the following command:

      docker build -t auth-app.

      The `-t’ flag sets the image tag. The same tag as we placed in the “FROM” instruction in the first build stage. We didn’t put the version after the colon, so Docker automatically builds with the “latest’ tag. The’. ’ at the end of the command means a build’s context. The build process happens inside the build context’s directory.

      After the image is built, we can check it by using the following command:

      docker images

      See the obtained size of our build image, which is compared to a regular Rust image, is much smaller:

      REPOSITORY TAG IMAGE ID CREATED SIZE

      auth-app latest 94e11dc49c66 2 minutes ago 34.8MB

      rust 1.73-bookworm 890a6b209e1c 3 days ago 1.5GB

      Now, the time is to create an instance of this image. We call such an instance a container. We can do it by using the following command:

      docker run -p 8080:8080 auth-app: latest

      The `-p’ flag maps the container port to the host port. The first port is the host port, and the second is the container port. Also, we explicitly specified a tag. However, Docker will pull the “latest’ tag without it by default if not specified. Let’s now request the `/health’ endpoint:

      curl http://localhost:8080/health

      You should see the following response, meaning that our application is healthy:

      {“status”: “OK”}

      Containerizing with Podman

      To start with Podman, you need to install Podman Desktop. You can download it from the [official website] (https://podman.io/docs/installation). Once you’ve installed it, you can check the Podman version by using this command:

      podman – version

      You should see the version of Podman:

      podman version 4.7.0

      Compared to Docker Desktop, Podman requires an additional step from the user to start a virtual machine. You can do it by running the command below:

      podman machine start

      By default, the Podman machine is configured in rootless mode. So if your container requires root permissions (as an example, you need to get access to privileged ports), you need to change the machine settings to root mode:

      podman machine set – rootful

      We will run our application in rootless mode, which is more secure. If the “USER” instruction is not specified, the image will run as root by default. It could be a better way to do it, so we need to create a user and group in the container and run the application as this user. So, let’s adjust the second stage in our Dockerfile:

      # … (first stage is omitted)

      FROM gcr.io/distroless/cc-debian12

      ENV RUST_LOG=info

      COPY – from=builder /app/target/release/auth-app.

      USER nobody: nobody

      ENTRYPOINT [”. /auth-app”]

      CMD [” -a”, “0.0.0.0”, "-p”, “8080”]

      The “nobody’ user is uniquely reserved in Unix-like operating systems. To limit the harm if a process is compromised, it’s common to run daemons or other processes as the “nobody’ user. Also, we added the “ENTRYPOINT” instruction to the Dockerfile. It is like “CMD” but cannot be overridden when running the container.

      After that, you can build the image similarly to Docker by using the following statement:

      podman build -t auth-app: latest.

      Start the container using, overriding predefined “CMD” instruction:

      podman run -p 5555:5555 auth-app -a 0.0.0.0 -p 5555

      The part after the image name is the “CMD” instruction. It overrides the default command specified in the Dockerfile with a new port. After requesting the `/health’ endpoint with a new port, we should get the same response as with Docker, which will say that our application is healthy.

      Containerizing with Colima

      To install Colima, you can obtain the latest release from the official [Github repository] (https://github.com/abiosoft/colima), and follow the provided installation guide. Once you’ve installed it, you can check the Colima version by using this command:

      colima – version

      You should see something like this:

      colima version 0.5.6

      git commit: ceef812c32ab74a49df9f270e048e5dced85f932

      To start Colima machine, you need to use “start’ command:

      colima start

      This command adds Docker context to your environment. You can use the Docker client (Docker CLI) to interact with the Docker