September 2024 Summaries

Docker images package software and its dependencies into portable executables built from Dockerfiles, and growing adoption of Arm64 hardware such as AWS Graviton, Raspberry Pi devices, and Apple M-series Macs has increased the need for images supporting both AMD64 and Arm64. Docker Buildx can target these platforms with platform-specific build flags, but building Arm64 images on common x86-64 CI runners often relies on QEMU emulation, which can substantially slow builds, increase CI costs, and occasionally create compatibility problems. Native Arm64 runners avoid these limitations by executing Arm64 builds directly on matching hardware, improving speed and reliability. The discussion presents Blacksmith’s managed Arm64 GitHub Actions runners as an option for native builds, claiming lower costs than GitHub-hosted runners, and shows how a CI matrix can assign AMD64 and Arm64 builds to separate native runners before pushing architecture-specific images.

Blacksmith announced that it has completed a SOC 2 Type 2 audit and observation period, extending its SOC 2 Type 1 compliance achieved in May 2024. Developed by the AICPA, SOC 2 Type 2 evaluates whether a service provider’s security controls operate effectively over time, rather than only assessing their design at a single point. Blacksmith cites several security measures supporting its compliance, including isolated ephemeral virtual machines powered by AWS-maintained Firecracker for GitHub Actions workloads, minimal retention of execution metadata, no GitHub app access to customer secrets, strict access controls, incident-response procedures, and disaster-recovery planning. The company says the certification offers customers greater assurance that their information and workflows are protected, while committing to ongoing security improvements and recurring audits.

Docker uses a client-server architecture to package, deploy, and manage applications in isolated, portable containers, with the Docker Client sending API requests to the Docker Daemon on a Docker host. The daemon performs core operations such as building images from Dockerfiles, pulling and pushing layered images through registries such as Docker Hub, creating and monitoring containers, and coordinating lower-level runtimes including containerd and runc, which use Linux namespaces and cgroups for isolation and resource management. Docker images are read-only templates composed of reusable layers, while containers add a writable execution layer; networks and volumes provide communication and persistent storage, respectively. The overview describes bridge, host, overlay, and MACVLAN networking modes, including overlay networks for multi-host Docker Swarm deployments, and contrasts Docker-managed volumes with bind mounts, recommending volumes for their portability, isolation, sharing, lifecycle management, and backup capabilities. Understanding these components and their interactions helps users troubleshoot deployments, manage resources, strengthen security, and prepare for more advanced Docker networking, monitoring, and operational topics.

Docker multi-stage builds optimize container images by separating compilation and build dependencies from the final runtime environment, addressing the large sizes, slower builds, maintenance difficulties, and expanded security risks common in traditional single-stage Dockerfiles. Each stage begins with a separate FROM instruction and can use an appropriate base image, such as Go or Node.js images for building and lightweight Alpine or Nginx images for deployment, while COPY --from transfers only required binaries or assets into the final image. Independent stages, such as frontend and backend builds, may run concurrently, and naming stages improves Dockerfile clarity. Effective practices include arranging rarely changed dependency steps before frequently updated application code to maximize layer-cache reuse, selecting minimal runtime images, and retaining only necessary artifacts. This approach produces smaller, faster-to-transfer, more secure, modular, and maintainable images suitable for production deployments.

Docker can consume substantial local disk space through accumulated images, running and stopped containers, persistent volumes, and build cache, while unused networks may also affect system performance. The `docker system df` command provides an overview of usage and reclaimable storage, helping identify common sources of bloat such as unused or dangling images, stopped containers, orphaned volumes, and cached build layers. Disk space can be reclaimed with commands including `docker image prune --all`, `docker container prune`, `docker volume prune`, and `docker builder prune`, though users should understand that these actions can remove resources they may need later. Long-term management includes using multi-stage builds, `.dockerignore` files, specific image tags, efficient Dockerfiles, regular cleanup routines, and monitoring tools such as Docker Desktop or alternatives like OrbStack to maintain a responsive development environment.