I’ve recently moved some of the components that assist with the running of bgp4_table and bgp6_table into ‘the cloud’. Specifically I migrated the tweeter service, that actually compiles and tweets the data out, and the grapher service, which creates the images that goes with those tweets.
tweeter is written in Go, while grapher is using Python. I’d prefer to use Go as much as possible, but Python still has better graphing libraries. For graphing I use Matplotlib
The cloud service I’m using for both is Google’s Cloud Run. You place your app inside a docker container, upload the image and invoke it from there. I use the HTTPS endpoint for the tweeter service, and that calls the grapher service container over gRPC. I tweet 180 times a month and Google gives you 2 million invocations a month free so I’m well within the free tier here.
When moving to Docker containers, most online guides will show you how to pull in a fairly large container for your particular project. Whether that be something like docker pull python:3.8.3-buster or docker pull golang:latest - This is fine for initial testing, but the resulting containers can be pretty large. Not only that, but there are a load of internal libraries running which you don’t need, increasing the attack surface of your container.
Google has created some tiny containers instead that give you just enough OS to run your app and nothing more. I’ve been using them with both Go and Python and there are quirks to both. I’ll go over the two main ways I use this in Golang which is the easiest, and then show what I do with my Python containers.
Go is compiled. This means once you have a fully functioning application, you can compile this to a single binary and run this somewhere else. Go also allows you to cross-compile your binaries, meaning you can create a binary that’ll run on an ARM Linux server from an x86_64 Windows machine. Both of these attributes makes it very easy to move to distroless containers in the Go world.
Option 1 - Multistage build
The first option is to use a multistage build. This means you use a regular container to compile you app, and then you copy all the relevant parts over to a distroless container. In fact this is how the distroless Go FAQ shows it. This is an example Dockerfile:
FROM golang:1.14 as build-env WORKDIR /go/src/app ADD . /go/src/app RUN go get -d -v ./... RUN go build -o /go/bin/app FROM gcr.io/distroless/base COPY --from=build-env /go/bin/app / CMD ["/app"]
Here we have an initial container using golang:1.14 and we name is build-env. This is a temporary container. Our source code is passed into this container, we get our dependencies, and then we build the app. The second part then pulls the distroless:base container and copies the binary from the build-env container. What you’re left with is a tiny distroless container with a compiled binary ready to be invoked.
Option 2 - Makefile
There is a faster way to do this though. Remember Go allows cross-compilation, so you could just compile the binary on your machine and copy that into a new distroless container. It doesn’t matter what OS/Arch you’re running vs the container, as we just compile to the target container OS/Arch. This is an example Makefile:
build: GOOS=linux go build -o app docker build -t xxxx/xxxx/appname . rm -f app
And this is the Dockerfile:
FROM gcr.io/distroless/base ADD app /app ADD config.ini / ENTRYPOINT ["/app"]
Now all I need to do is run make build and I have a container ready to do. In this instance I’m setting the OS to linux and compiling the app to that target OS. I then call the Dockerfile which builds a new container and copies over the binary. I’m also copying a local config.ini used in this particular app. The Makefile then deletes the binary on my local machine. This process is extremely fast as the compiling is done locally and only the resulting binary is copied into a distroless container.
Unfortunately Python is not so straight forward. Python does not compile so you need to have all your dependencies inside the distroless container. I did try Pyinstaller but I couldn’t get it to work. Maybe that could be an option if you manage to get it working. In my case I reverted to a multistage build, then copied the libraries over to my distroless container. This continer is running Python 3.7, so I just match that in my initial container. No makefile this time, just a Dockerfile:
FROM python:3.7-slim AS build-env WORKDIR /app ADD ./ ./ RUN pip3 install --upgrade pip && \ pip install -r ./requirements.txt FROM gcr.io/distroless/python3-debian10 COPY --from=build-env /app /app COPY --from=build-env /usr/local/lib/python3.7/site-packages /usr/local/lib/python3.7/site-packages WORKDIR /app ENV PYTHONPATH=/usr/local/lib/python3.7/site-packages CMD ["app.py"]
requirements.txt contains a list of the Python libraries I need installed. My example:
grpcio grpcio-tools protobuf matplotlib
The end result here being a distroless Python container with both my app and the required dependencies ready to go.