ARM

Modern Docker builds should treat CPU architecture as an explicit build output. A developer may build on an amd64 laptop, deploy to arm64 cloud nodes, and still publish one image name that works for both platforms. See the cross-builds chapter for the full Mac-to-x86, x86-to-ARM64, and multi-platform release workflow.

Use Buildx for multi-platform builds.

docker buildx ls
docker buildx create --name multiarch --driver docker-container --use
docker buildx inspect --bootstrap

If the builder needs CPU emulation, install QEMU/binfmt support on the build host.

docker run --privileged --rm tonistiigi/binfmt --install all

Build and push one manifest list containing both amd64 and arm64 images.

docker buildx build \
    --platform linux/amd64,linux/arm64 \
    -t registry.example.com/team/app:latest \
    --push .

For local testing, load a single-platform image into the local Docker image store.

docker buildx build --platform linux/arm64 --load -t app:arm64 .

Do not assume that every base image supports every platform. Check the manifest before choosing the base image.

docker buildx imagetools inspect python:3-slim

Basic ARM container

An example Dockerfile to build a basic ARM container for Raspberry Pi-style work is as follows.

FROM arm32v7/ubuntu

ENV DEBIAN_FRONTEND=noninteractive

RUN apt-get update -y && \
    apt-get upgrade -y

RUN apt-get install -y \
    wget \
    build-essential \
    tk-dev \
    libncurses5-dev \
    libncursesw5-dev \
    libreadline6-dev \
    libdb5.3-dev \
    libgdbm-dev \
    libsqlite3-dev \
    libssl-dev \
    libbz2-dev \
    libexpat1-dev \
    liblzma-dev \
    zlib1g-dev \
    libffi-dev \
    gfortran \
    libopenblas-dev \
    liblapack-dev \
    python-dev \
    default-libmysqlclient-dev \
    libfreetype6-dev \
    libxml2-dev \
    libxslt1-dev

RUN apt-get clean

Notice the following.

The base image is arm32v7/ubuntu.
The ENV DEBIAN_FRONTEND=noninteractive instruction is to enable non-interactive installs (so we do not get prompted for Yes or No).
We install a lot of system libraries since we want to do interesting things later on.

Build.

docker build --no-cache -t rpi-base:local .

Run.

docker run -it rpi-base:local

Jupyter Lab

What if we want to have a reproducible, consistent data science work environment on the Raspberry Pi? We can build a container to spin up a Jupyter Lab instance.

FROM rpi-base:local

ENV CONDA_HOME=/root/miniconda
ENV PATH=${CONDA_HOME}/bin:${PATH}
ENV JUPYTER_TYPE=lab

# setup OS
RUN apt-get update -y && \
    apt-get upgrade -y && \
    apt-get install supervisor -y

# setup supervisor
COPY jupyter.conf /etc/supervisor/conf.d/

# setup miniconda
RUN wget -q http://repo.continuum.io/miniconda/Miniconda3-latest-Linux-armv7l.sh -O /tmp/miniconda.sh && \
    /bin/bash /tmp/miniconda.sh -b -p /root/miniconda && \
    conda update -n root conda -y && \
    conda update --all -y && \
    pip install --upgrade pip && \
    conda config --add channels rpi && \
    conda install python=3.6 -y && \
    conda install jupyter jupyterlab nodejs scikit-learn numpy scipy matplotlib -y -c anaconda -c conda-forge

# setup mount point
RUN mkdir /ipynb
VOLUME ["/ipynb"]

# setup ports
EXPOSE 8888

# clean up
RUN apt-get clean

CMD ["/usr/bin/supervisord", "-c", "/etc/supervisor/supervisord.conf", "-n"]