Category: Docker

Accessing services on the host from a Docker container or a Podman one

I use Podman to provide Docker-like stuff on my dev machine without effectively being root.

Talking to the container host in Docker

There is a little trick for accessing HTTP services on the container host in Docker: you add --add-host host.docker.internal:host-gateway to the command line when you run the docker container, for example:

docker run -d --add-host host.docker.internal:host-gateway my-container:latest

Now in your code you can refer to the Docker container host using the name host.docker.internal.

Talking to the container host in Podman

However, this doesn’t work in Podman. Instead, you need to add --network slirp4netns:allow_host_loopback=true to the command line, for example:

docker run -d --network slirp4netns:allow_host_loopback=true my-container:latest

Now in your code you can refer to the Podman container host using the name host.containers.internal.

Supporting both

For this to work in both Docker and Podman, your container needs to know which framework it is working inside, and use either host.docker.internal or host.containers.internal explicitly, which is a pity.

Creating a tiny Docker image of a Rust project

I am building a toy project in Rust to help me learn how to deploy things in AWS. I’m considering using Elastic Beanstalk (AWS’s platform-as-a-service) and also Kubernetes. Both of these support deploying via Docker containers, so I am learning how to package a Rust executable as a Docker image.

My program is a small web site that uses Redis as a back end database. It consists of some Rust code and a couple of static files.

Because Rust has good support for building executables with very few dependencies, we can actually build a Docker image with almost nothing in it, except my program and the static files.

Thanks to Alexander Brand’s blog post How to Package Rust Applications Into Minimal Docker Containers I was able to build a Docker image that:

  1. Is very small
  2. Does not take too long to build

The main concern for making the build faster is that we don’t download and build all the dependencies every time. To achieve that we make sure there is a layer in the Docker build process that includes all the dependencies being built, and is not re-built when we only change our source code.

Here is the Dockerfile I ended up with:

# 1: Build the exe
FROM rust:1.42 as builder
WORKDIR /usr/src

# 1a: Prepare for static linking
RUN apt-get update && \
    apt-get dist-upgrade -y && \
    apt-get install -y musl-tools && \
    rustup target add x86_64-unknown-linux-musl

# 1b: Download and compile Rust dependencies (and store as a separate Docker layer)
RUN USER=root cargo new myprogram
WORKDIR /usr/src/myprogram
COPY Cargo.toml Cargo.lock ./
RUN cargo install --target x86_64-unknown-linux-musl --path .

# 1c: Build the exe using the actual source code
COPY src ./src
RUN cargo install --target x86_64-unknown-linux-musl --path .

# 2: Copy the exe and extra files ("static") to an empty Docker image
FROM scratch
COPY --from=builder /usr/local/cargo/bin/myprogram .
COPY static .
USER 1000
CMD ["./myprogram"]

The FROM rust:1.42 as build line uses the newish Docker feature multi-stage builds – we create one Docker image (“builder”) just to build the code, and then copy the resulting executable into the final Docker image.

In order to allow us to build a stand-alone executable that does not depend on the standard libraries in the operating system, we use the “musl” target, which is designed to be statically linked.

The final Docker image produced is pretty much the same size as the release build of myprogram, and the build is fast, so long as I don’t change the dependencies in Cargo.toml.

A couple more tips to make the build faster:

1. Use a .dockerignore file. Here is mine:

/target/
/.git/

2. Use Docker BuildKit, by running the build like this:

DOCKER_BUILDKIT=1 docker build  .

Build with a different Java version (e.g. 11) using Docker

To spin up a temporary environment with a different Java version without touching your real environment, try this Docker command:

docker run -i -t --mount "type=bind,src=$PWD,dst=/code" openjdk:11-jdk bash

(Change “11-jdk” to the version you want as listed on the README.)

Then you can build the code inside the current directory something like this:

cd code
./gradlew test

Or similar for other build tools, although you may need to install them first.

Run bash inside any version of Linux using Docker

Docker is useful for some things, and not as useful as you think for others.

Here’s something massively useful: get a throwaway bash prompt inside any version of any Linux distribution in one command:

docker run -i -t --mount "type=bind,src=$HOME/Desktop,dst=/Desktop" ubuntu:18.10 bash

This command downloads a recent Ubuntu 18.10 image, mounts my desktop as /Desktop in the container, and gives me a bash prompt. From here I can install any packages I want and then use them.

For example, today I used it to decrypt a file that was encrypted with a cipher my main OS did not have a package for.

When I exit bash, the container stops and I can find it with docker ps -a then remove it with docker rm. To really clean up I can find the downloaded images with docker image ls and remove them with docker image rm.

ZX Spectrum BASIC Web Server

Finally, you can write your web sites in ZX Spectrum BASIC, using my new project, ZX Spectrum BASIC CGI server .

How it works

Here’s what happens when a request comes in:

  • Apache HTTPD receives the request, and runs the CGI script that does the magic.
  • The CGI script (written in Bash) generates some BASIC code that provides the HTTP meta-vars (e.g. PATH_INFO for the path of the request) as DATA statements and wraps some other boilerplate around the code of the .basic file asked for in the request, and writes out another .basic file which is ready to be executed.
  • Then it uses BAS2TAP (my mirror here) to create an audio tape file representing the program.
  • Next it launches the Fuse spectrum emulator (inside an Xvfb wrapper to make it think it has a display), telling it to load from the audio tape and run the program.
  • The program runs, and writes its HTTP responses to the Spectrum printer using LPRINT statements.
  • Fuse uses very basic OCR to understand what characters are printed, and writes them into a text file.
  • The CGI script monitors the output file, waiting for a line containing an end marker (“ENDSPECTRUMBASIC”). When it finds it, it kills the emulator (since it can’t made to auto-exit, I think).
  • The CGI script sends the contents of the output file (minus the end marker) back to Apache, which returns it as a response.

Simple.

Why?

Originally designed to demonstrate how Docker can help isolate other services from “interesting” dependencies, this became a bit of a labour of love.

I’ll never stop being grateful to the designers of the ZX Spectrum, or the authors of “Further Programming for the ZX Spectrum”.