Docker Buildx

# Use inline cache with local filesystem
docker buildx build \
  --cache-from type=local,src=./cache \
  --cache-to type=local,dest=./cache \
  -t myimage:latest .
# This stores build cache layers to the ./cache directory
# Future builds can reuse this cache even if the Docker daemon is restarted
# Ideal for local development or CI systems with persistent storage

# Use registry for distributed caching
docker buildx build \
  --cache-from type=registry,ref=username/myapp:cache \
  --cache-to type=registry,ref=username/myapp:cache,mode=max \
  -t username/myapp:latest \
  --push .
# Stores build cache in a separate tag in your registry
# Allows teams to share build cache across different machines and CI/CD pipelines
# The mode=max option stores all layers including intermediate ones
# Reduces build times in distributed environments by avoiding redundant work

# Cache in GitHub Actions
docker buildx build \
  --cache-from type=gha \
  --cache-to type=gha,mode=max \
  -t username/myapp:latest .
# Specifically optimized for GitHub Actions workflows
# Uses GitHub's built-in cache system for faster CI builds
# Works automatically with GitHub's runner architecture
# Persists between workflow runs to speed up repeated builds

# syntax=docker/dockerfile:1
FROM --platform=$BUILDPLATFORM golang:1.18 AS builder

# These ARGs are automatically set by buildx
ARG TARGETPLATFORM   # Platform for the target image (e.g., linux/amd64)
ARG BUILDPLATFORM    # Platform where the build is running (e.g., linux/arm64)
RUN echo "I am running on $BUILDPLATFORM, building for $TARGETPLATFORM"

WORKDIR /app
COPY . .
# Parse the platform values to set Go environment variables
RUN GOOS=$(echo $TARGETPLATFORM | cut -d/ -f1) \
    GOARCH=$(echo $TARGETPLATFORM | cut -d/ -f2) \
    go build -o /app/myapp .
# This enables cross-compilation: Go code is compiled for the target platform
# regardless of where the build is actually running

FROM alpine
COPY --from=builder /app/myapp /usr/local/bin/
CMD ["myapp"]
# The resulting image contains only the compiled binary for the target platform
# Multi-stage builds help create smaller, more secure images

# syntax=docker/dockerfile:1
FROM alpine

# Use secret from buildx directly mounted during build
RUN --mount=type=secret,id=mysecret \
    cat /run/secrets/mysecret > /app/secret-data
# This is the most secure method - the secret is never stored in any image layer
# Secret is only available during this specific RUN instruction

# Use secret as file (NOT RECOMMENDED FOR SENSITIVE DATA)
COPY mysecret.txt /app/
# This method adds the secret file to an image layer, making it retrievable
# Only use for non-sensitive data or development environments

# Use secret as environment variable (USE WITH CAUTION)
ARG SECRET_ENV
ENV APP_SECRET=$SECRET_ENV
# Build args can be viewed in image history
# Environment variables might be exposed in container metadata
# For production, prefer the --mount=type=secret approach

# Output to Docker daemon
docker buildx build --output type=docker -t myimage .
# Loads the resulting image directly into the Docker daemon
# Equivalent to the traditional 'docker build' behavior
# Only works with the 'docker' driver or single-platform builds

# Output to registry
docker buildx build --output type=registry -t username/myapp .
# Pushes the image directly to a container registry
# Requires being logged into the registry (docker login)
# Doesn't load the image into the local Docker daemon
# Efficient for CI/CD pipelines that push directly to registries

# Output to local image
docker buildx build --load -t myimage .
# Imports the built image into Docker's local image store
# Shorthand for '--output type=docker'
# Allows immediate use with 'docker run' after building

# Output to local directory
docker buildx build --output type=local,dest=./output .
# Instead of creating a container image, exports the build result to a directory
# Useful for extracting compiled binaries or static files from the build
# Perfect for build workflows that need artifacts rather than full images

# Output to tar file
docker buildx build --output type=tar,dest=./image.tar .
# Creates a tarball containing the build result
# Can be transported between systems and loaded manually
# Useful for air-gapped environments or custom distribution methods

group "default" {
  targets = ["app", "worker"]
}

target "app" {
  dockerfile = "Dockerfile.app"
  tags = ["myapp:latest"]
  platforms = ["linux/amd64", "linux/arm64"]
}

target "worker" {
  dockerfile = "Dockerfile.worker"
  tags = ["myworker:latest"]
  args = {
    WORKER_VERSION = "1.0"
  }
}

{
  "group": {
    "default": {
      "targets": ["app", "worker"]
    }
  },
  "target": {
    "app": {
      "dockerfile": "Dockerfile.app",
      "tags": ["myapp:latest"],
      "platforms": ["linux/amd64", "linux/arm64"]
    },
    "worker": {
      "dockerfile": "Dockerfile.worker",
      "tags": ["myworker:latest"],
      "args": {
        "WORKER_VERSION": "1.0"
      }
    }
  }
}

# Clone private repository using SSH key
FROM alpine
RUN --mount=type=ssh mkdir -p -m 0700 ~/.ssh && \
    ssh-keyscan github.com >> ~/.ssh/known_hosts && \
    git clone git@github.com:username/private-repo.git
# The --mount=type=ssh exposes the host's SSH agent to the build process
# Requires passing --ssh default when running buildx build
# Example: docker buildx build --ssh default=~/.ssh/id_rsa --no-cache .
# No SSH keys are stored in the image, maintaining security

# Cache package manager
RUN --mount=type=cache,target=/var/cache/apt \
    apt-get update && apt-get install -y package
# Creates a persistent cache volume mounted at /var/cache/apt
# Cache persists between builds, significantly speeding up package installations
# Does not affect the final image size - cache exists only during build
# Multiple builds can share the same cache concurrently
# Unlike volume mounts in regular Docker, this is build-specific

# Use temporary bind mount
RUN --mount=type=bind,source=./config,target=/config \
    cp /config/app.conf /etc/app/config.conf
# Mounts the ./config directory from build context into /config in container
# Files can be read and copied but don't become part of any layer
# Useful for configuration files, templates, or any content needed only during build
# The readonly option can be added for additional security: type=bind,source=./config,target=/config,readonly