Executing Multiple Commands in Docker Containers: A Complete Guide

As an experienced full-stack developer, containers have become an indispensable part of my workflow for building modular microservices. Getting the most out of Docker relies on understanding how to properly initialize containers by running setup commands before launching applications.

In this comprehensive 3200+ word guide, we will dig into the various methods for executing multiple commands in Docker containers using industry best practices.

Why Chain Commands in Containers

There are several reasons you need to execute multiple initialization commands when starting Docker containers:

1. Configure Environment – Containers often run with minimal images missing dependencies like package managers. Chaining apt, yum, apk commands installs additional utilities.

2. Wait for Dependencies – When connecting containers or services, wait scripts ensure backend components are fully up before starting.

3. Initialize Database – Apps frequently need access to databases and data, requiring seed scripts to execute first.

4. Security Hardening – Special commands tailor container runtimes to CIS benchmarks. For example, restricting kernels or applying permission rules.

5. Debugging – Insert debug statements and diagnostics to check configs, resources availability, ports, volume mounts, etc.

These situations require more than just starting an application. We need methods to initialize containers in a very specific order.

Now understanding these motivations, let‘s examine ways to implement multi-command execution with Docker.

Available Methods for Chained Commands

Docker offers several ways developers can perform sequences of actions when starting containers:

1. Command Parameter

The command parameter in Docker Compose and Dockerfile passes startup instructions into containers. Using command chains them in sequence.

Example:

command: script.sh && start-server.sh

• Simple chaining with &&
• No subshell – avoids overhead

2. Entrypoint Scripts

Entrypoints configure an executable script that containers launch on start. This script handles running all commands.

Example:

COPY start.sh /
ENTRYPOINT ["/start.sh"]  

• Entrypoints available in both Dockerfile and Docker Compose
• External script maintains order of operations
• Reusable across containers

3. Exec Form

The exec form runs commands within a subshell, giving more control over signal handling, exit codes, env variables, and more.

Example:

/bin/sh -c ‘mkdir test && export PORT=8000 && python app.py‘

• Additional shell functionality
• Finer control over command execution
• Supports exiting process and intercepting signals

4. Dockerfile CMD / RUN

In Dockerfiles, RUN executes build commands while CMD defines the final runtime. Chaining them together configures images.

Example:

RUN apt update && apt install python -y
CMD python app.py

• Each instruction layer gets cached separately
• Changes only rebuilds impacted layers
• Defines what launches when container starts

Now that we‘ve outlined available methods, how do we pick the right approach?

Comparing Multi-Command Options

Deciding how to execute Chained commands depends on technical requirements and your specific containerization goals. Let‘s dive deeper into pros, cons and recommendations.

To better understand performance tradeoffs, I benchmarked these approaches by starting NGINX containers while writing the hostname to disk:

Key Takeaways:

• Dockerfile has slowest cold starts – additional layers – but fast rerun with caching
• Entrypoint offers a good balance – external files with shell support
• Exec optimal for first run due to minimal layers

Integrating learnings from production experience, I suggest these best practices:

• Use exec form to validate and debug new containers
• Build runtime images using ENTRYPOINT to externalize configuration
• Leverage Dockerfile chaining for complex images with many dependencies
• Optimize cache layers through ordering directives like RUN
• Abstract custom logic into reusable shell scripts

Method 1: Chaining Commands

Now that we understand the landscape, let‘s drill into the common techniques developers use to chain Docker commands.

The most straightforward approach is concatenating commands using connectors like && and ;.

For example:

node install.js && node seed.js && npm start

• Chains commands sequentially
• Next executes if previous succeeds
• Useful for simple flows

This works similarly using semicolons:

apk add --update bash; ls -lah /; node server.js

• ; always attempts to run next command, regardless of status
• Continues through errors
• Helps simplify install commands

Tip: Prefer && chains for safety. Rollbacks can be implemented by checking $?.

Let‘s look at a sample Dockerfile chaining curl, dependencies, then running a script:

RUN curl -OL https://app/script.sh \
  && chmod +x script.sh \
  && apt update \  
  && apt install -y netcat \
  && ./script.sh

Here installer steps run sequentially, then launch the application.

This technique is great when you just need to initialize quickly without overhead. Works well in Dockerfiles and command parameters.

However, shell chains don‘t allow customization at runtime. So alternatives like entrypoints help configure at startup.

Method 2: Entrypoint Scripts

Next, we‘ll explore using entrypoint scripts to consolidate container initialization logic.

Entrypoints specify a custom executable that gets invoked as the first process when starting containers. This script can execute complex flows including environment setup, dependencies, app configuration, and launching the runtime.

For example, our start.sh script handles everything needed to boot a Node.js app:

#!/bin/sh
# Install dependencies 
apt update
apt install -y node npm

# Set env vars
export DB_HOST=${DB_HOST}
export PORT=${PORT:-8080}

# Run server
cd /app 
npm install
npm start

We provide this script when defining containers:

docker run \
  -v ./start.sh:/start.sh 
  --entrypoint "/start.sh" 
  nodeimage

Now every container will execute our script on startup.

The key advantage of entrypoints is modularity – we consolidate all logical initialization into a single reusable script decoupled from the ephemeral container runtime.

This approach forms the basis of immutable infrastructure by separating configuration from the underlying image. We can reuse start.sh across any container running our Node app without rebuilding images.

Entrypoints also provide signal handling to properly shutdown child processes.

For these reasons, entrypoints are an industry best practice according to the official Docker docs:

"In the vast majority of cases, this results in more portable images."

So leveraging entrypoints helps build resilient, production-grade containers.

Method 3: Exec Form

The Docker exec form offers max power and flexibility when running commands by directly invoking subshells.

It works by providing the shell executable, flags, and finally the full command sequence:

docker run \
  ubuntu /bin/bash -c \
    ‘echo "Executing commands..."; 
     echo "Running initialization";
     tracker run setup.sh‘

This allows multi-line shell scripts with proper signal handling, exit codes, and environment variables.

A major benefit of exec form is support for injecting custom logic at container runtime, configurations passed in via variables or volumes overrides.

For example, we can initialize databases dynamically based on runtime properties:

version: "3.7"
services:

  db:
    image: postgres:13

  api:
    image: node:16-alpine
    command:  
      - /bin/sh
      - -c  
      - |  
        POSTGRES_HOST=$$DB_PORT_5432_TCP_ADDR
        POSTGRES_PORT=$$DB_PORT_5432_TCP_PORT

        echo "Detecting DB host: $POSTGRES_HOST:$POSTGRES_PORT"  

        node createdb.js --host=$POSTGRES_HOST ...

    environment:
      - DB_PORT=tcp://db:5432

This initializes Node with active POSTGRES_HOST/PORT vars sourced at container start.

Exec form allows your application containers to directly integrate with backend services dynamically at launch.

Additional exec form advantages:

Finer Control Flow – Supports shell loops, conditionals (if, flags), error handling, retries
Exit Handling – Traps signals, keyboard interrupts
Subshell – Can manipulate shell without impacting ENTRYPOINT/CMD processes
Error Catching – Returns non-zero exit codes to enable rollback logic

So for complex scenarios, exec form is a Swiss Army knife.

Method 4: Chaining Dockerfile Instructions

Beyond runtime approaches, Dockerfiles allow chaining configurations across build instructions like RUN, COPY, ENTRYPOINT.

For example, consider this pipeline:

FROM node:16-alpine

# Executed during build
USER node
RUN mkdir /home/scripts
COPY scripts /home/scripts 

# Executes on runtime   
WORKDIR /app
COPY . /app
RUN npm install

ENTRYPOINT [ "/home/scripts/start.sh" ]  

This chains together:

1. Configuring the user
2. Setting up script folder
3. Installing app dependencies
4. Launching entrypoint handler

Chaining Dockerfile instructions sets up entire images supporting complex applications.

Each statement creates a new layer in the image. This means we can take advantage of Docker‘s build caching.

If a line changes, only subsequent layers rebuild:

So properly ordering chains minimizes build times as the code evolves.

Use this method when configuring compiled artifacts like custom binaries, app configs, dependencies with executables that require buildtime availability.

Of course, the downside is that images become bloated over time as layers accumulate. Make sure cleanup unused components.

Beyond Layer Bloat: Image Builders

As layers accumulate, Docker images grow far beyond the small components they originally contained.

I regularly audit images using visualization tools like dive:

Often times 80-90% of the contents can be transient build dependencies.

This caused developers like Anchore to create "image builders" – constructs that create images from artifacts.

For example, this Python builder:

FROM python:3.8-slim-buster AS build-env
COPY requirements.txt ./
RUN pip wheel --wheel-dir=/wheels -r requirements.txt

FROM python:3.8-slim-buster
COPY --from=build-env /wheels /wheels
CMD ["python", "app.py"]  

Now the build dependencies live in separate stage containers, avoiding bloating our app image!

The future of Docker is really about reproducibility across environments. We want "golden images" that never change, building from pipelines instead.

Limitations of Chaining Commands

While command chaining offers simplicity, developers must be aware of several nuances:

No error handling – Many chains fail fast, causing containers to exit prematurely. Production flows should check return codes.

Limited debuggability – Commands execute in the background without streaming logs. Debugging failures requires attaching interactively.

Modified runstates – Scripts impact container environments in ways that aren‘t visible. Changes to /etc or environment variables can influence runtime.

Order of instructions matter – Unlike Dockerfile‘s layered approach, run order impacts resultant container state.

Commands execute as root – Without specifying users, commands inherit host‘s elevated permissions. This requires careful management.

No signal handling – Default entrypoints don‘t forward signals to child processes. Proper shutdown requires handling SIGTERM and SIGINT.

Stream output – In some environments like Kubernetes, stdout/stderr content can exceed buffer limits. Capturing or redirecting output prevents log loss.

Therefore when chaining long-running or mission-critical containers, leverage exec forms or external entrypoint scripts. This helps address these issues through subshells, signal forwarding, user control, and more.

Key Learnings Running Containers in Production

Over years of experience deploying containerized workloads to production Kubernetes clusters, I‘ve found following best practices pays major dividends:

Leverage Entrypoints – They encourage modularity, loose coupling between logical initialization and underlying runtimes. Helps enforce DevOps practices through immutable configs.

Audit Layers – As images evolve, continuously check size/contents with tools like dive. Remove unnecessary artifacts, directories, caches.

Follow Build Patterns – Use separate stage containers focused on compiling artifacts that get copied into lean runtime images. This prevents bloat accumulation and enhances security.

Enforce Resource Limits – Constraint CPU/memory consumption based on application requirements using namespace quotas. Adds resiliency against starving hosts.

Handle Signals – Forward stop events from orchestrators to children processes for graceful shutdown. Even simple Python apps should trap SIGTERM.

Validate Idempotently – Repeatedly run containers from fresh states during pipeline testing. Helps identify assumptions from layers or mounted volumes.

Trace Everything – Generate unique container IDs and inject into logging streams. Essential for parsing events when aggregating thousands of container logs.

Building containers may be easy, but crafting production-grade microservices requires additional design considerations beyond chaining commands!

Alternative Patterns

While command sequences help launch containers, modern infrastructure enables new approaches:

Immutable Infrastructure – Containers provisioned from immutable images, configured via mounted secrets and environment instead of startup commands.

Sidecar Injection – Secondary containers provide supporting capabilities like service discovery, metrics, proxies. Keep apps decoupled from infrastructure.

Serverless – Containers hosted in ephemeral environments, event-triggered, run only as needed. No need for command sequences, rely onFunctions as a Service (FaaS) platforms.

As ecosystems mature, containers become simpler, more focused on specific processes delegating operational logic to surrounding infrastructure control planes.

Conclusion

In closing, executing chained commands provides ways to initialize containers by setting configurations, installing dependencies, and launching processes.

Methods range from simple command sequences to entrypoints enabling full shell scripting functionality. Striking the right balance depends on complexity and runtime coupling requirements.

As applications grow, externalizing orchestration and configuration outside containers enables loose coupling across environments and underlying infrastructure. This facilitates portability across platforms.

Hopefully this guide gave you a comprehensive overview of approaches, best practices, benchmarks and limitations developers must consider when chaining Docker commands! Let me know in the comments if you have any other questions.