Use ephemeral disks to store container images #1991
-
I’d like the ability to use the ephemeral disks provided in a host as storage for container images. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 8 replies
-
It is possible to use a bootstrap container to change the root directory of either docker or containerd so that container images can be stored in ephemeral disks. Given a bootstrap container called [settings.bootstrap-containers.setup-runtime-storage]
source = "<SOURCE>"
mode = "always"
essential = true # You may change this depending on your requirements Where FROM alpine
RUN apk add e2fsprogs bash parted
ADD setup-runtime-storage ./
RUN chmod +x ./setup-runtime-storage
ENTRYPOINT ["sh", "setup-runtime-storage"] And #!/usr/bin/env bash
set -ex
# Symlinks to ephemeral disks are created here by udev
EPHEMERAL_DISKS=/.bottlerocket/rootfs/dev/disk/ephemeral
# Exit early if there aren't ephemeral disks
if [ ! -d ${EPHEMERAL_DISKS} ]; then
echo "${EPHEMERAL_DISKS} doesn't exist"
exit 1
fi
# Use the first ephemeral disk
DISK="$(cd ${EPHEMERAL_DISKS} && readlink -f $(ls | head -n 1))"
# There will be only one partition
PARTITION="${DISK}p1"
# For k8s, use containerd, for ECS use docker
CONTAINER_RUNTIME=<containerd/docker>
# Path where the disk will be mounted
MOUNT_POINT=/.bottlerocket/rootfs/mnt/${CONTAINER_RUNTIME}
# The path to the container's runtime root
RUNTIME_ROOT_PATH=/.bottlerocket/rootfs/var/lib/${CONTAINER_RUNTIME}
# If the partition doesn't exist, create it
if [ ! -e ${PARTITION} ]; then
parted -s ${DISK} mklabel gpt 1>/dev/null
parted -s ${DISK} mkpart primary ext4 0% 100% 1>/dev/null
mkfs.ext4 -F ${PARTITION}
fi
mkdir -p ${MOUNT_POINT}
mount ${PARTITION} ${MOUNT_POINT}
# If the container's runtime root directory exists, you have to manually delete it
if [ ! -d ${RUNTIME_ROOT_PATH} ]; then
# Use /mnt since the symlink will be seen from the host's perspective
ln -snf /mnt/${CONTAINER_RUNTIME} ${RUNTIME_ROOT_PATH}
fi With the provided configurations the bootstrap container will be executed at every boot, and the boot will fail if the bootstrap container fails. From the admin container, you can see that containerd/docker are using the new mounted disk by listing the files in the partition: bash-5.0# ls -la /mnt/docker/
total 68
drwx--x---. 14 root root 4096 Feb 23 01:36 .
drwxr-xr-x. 3 root root 4096 Feb 23 01:36 ..
drwx--x--x. 4 root root 4096 Feb 23 01:36 buildkit
drwx--x---. 3 root root 4096 Feb 23 01:37 containers
drwx------. 3 root root 4096 Feb 23 01:36 image
drwx------. 2 root root 16384 Feb 23 01:36 lost+found
drwxr-x---. 3 root root 4096 Feb 23 01:36 network
drwx--x---. 17 root root 4096 Feb 23 01:37 overlay2
drwx------. 4 root root 4096 Feb 23 01:36 plugins
drwx------. 2 root root 4096 Feb 23 01:36 runtimes
drwx------. 2 root root 4096 Feb 23 01:36 swarm
drwx------. 2 root root 4096 Feb 23 01:37 tmp
drwx------. 2 root root 4096 Feb 23 01:36 trust
drwx-----x. 2 root root 4096 Feb 23 01:36 volumes The script provided is just an example and should only be used as a reference. |
Beta Was this translation helpful? Give feedback.
-
The issue with the solution shown here is that it assumes the secondary disk is an instance store, as the Issue I am running into now is that the order of disks is constantly changing from nvme2n1 and nvme1n1 that I can't just hard code the disk name. |
Beta Was this translation helpful? Give feedback.
-
The recommended approach is changing with Bottlerocket 1.9.0 because of the issue with CSI plugins reported in #2218 (thanks, @diranged) and the fix in #2240. The example from @arnaldo2792 above shows using a symlink, but for best results I'd recommend using a bind mount instead in newer versions. The right approach depends on whether the bootstrap container needs to support older and newer versions of Bottlerocket. If older versions aren't a concern, the logic can be simplified by quite a bit. Here's the
And here's the
|
Beta Was this translation helpful? Give feedback.
The recommended approach is changing with Bottlerocket 1.9.0 because of the issue with CSI plugins reported in #2218 (thanks, @diranged) and the fix in #2240. The example from @arnaldo2792 above shows using a symlink, but for best results I'd recommend using a bind mount instead in newer versions.
The right approach depends on whether the bootstrap container needs to support older and newer versions of Bottlerocket. If older versions aren't a concern, the logic can be simplified by quite a bit.
Here's the
Dockerfile
for the container: