Init container pattern in Docker - Commands & Configuration

Introduction

Sometimes your main application needs some setup before it starts. The init container pattern lets you run a small helper container first to prepare things, like loading data or waiting for a service, before your main app runs.

When your app needs to wait for a database to be ready before starting.

When you want to load configuration files or secrets before the main app runs.

When you need to run a script to prepare data or environment before the main container.

When you want to ensure network services are reachable before launching your app.

When you want to separate setup logic from the main application for clarity and reuse.

Config File - docker-compose.yml

docker-compose.yml

version: '3.8'
services:
  init-helper:
    image: busybox
    command: ['sh', '-c', 'echo Preparing environment; sleep 5; echo Done']
  my-app:
    image: nginx:1.23
    depends_on:
      - init-helper
    command: ['nginx', '-g', 'daemon off;']

This docker-compose.yml file defines two services. The init-helper runs first and does a simple setup task (here simulated by sleep and echo). The my-app service depends on init-helper, so it waits until the init-helper container starts before starting. This ensures the environment is ready before the main app runs.

Commands

Start the init-helper container in detached mode to run the setup tasks before the main app.

Terminal

docker-compose up -d init-helper

Expected Output

Creating network "default" with the default driver

Creating volume "default" with default driver

Creating init-helper ... done

→

-d - Run containers in detached mode (in the background)

Start the main application container. It waits for init-helper to start because of the depends_on setting.

Terminal

docker-compose up -d my-app

Expected Output

Creating my-app ... done

→

-d - Run containers in detached mode (in the background)

Check the status of both containers to confirm init-helper finished and my-app is running.

Terminal

docker-compose ps

Expected Output

    Name                   Command               State           Ports

--------------------------------------------------------------------------------

default_init-helper_1   sh -c echo Preparing env ...   Exit 0



default_my-app_1        nginx -g daemon off;          Up      80/tcp

View the logs of the init-helper container to see the setup steps it performed.

Terminal

docker-compose logs init-helper

Expected Output

init-helper_1  | Preparing environment

init-helper_1  | Done

Key Concept

If you remember nothing else from this pattern, remember: run a small setup container first to prepare the environment before your main app starts.

Common Mistakes

Not using depends_on to link the init container and main container

The main container may start before the init container finishes, causing failures if setup is incomplete.

Use depends_on in docker-compose to ensure the main container waits for the init container to start.

Running init container and main container together without waiting

Setup tasks may not complete before the main app starts, leading to errors or missing data.

Start the init container first, wait for it to finish, then start the main container.

Summary

Define an init container service that runs setup commands before the main app.

Use depends_on in docker-compose to make the main app wait for the init container.

Start the init container first, then the main app, and verify their status with docker-compose commands.

Practice

1. What is the main purpose of an init container in Docker or Kubernetes?

easy

A. To run setup tasks before the main application starts

B. To replace the main application container

C. To run the main application continuously

D. To monitor the main container's logs

Solution

1. Step 1: Understand init container role

   Init containers run before the main container to prepare the environment.

2. Step 2: Compare options

   Only To run setup tasks before the main application starts describes running setup tasks before the main app starts, which is the init container's job.

3. Final Answer:

   To run setup tasks before the main application starts -> Option A

4. Quick Check:

   Init container purpose = run setup tasks before main app [OK]

Hint: Init containers run first to prepare environment [OK]

Common Mistakes:

• Thinking init containers replace main containers
• Assuming init containers run continuously
• Confusing init containers with monitoring tools

2. Which of the following is the correct way to define an init container in a Kubernetes Pod YAML?

easy

A. initContainers:
- name: init
image: busybox
command: ['sh', '-c', 'echo Init']

B. containers:
- name: init
image: busybox
command: ['sh', '-c', 'echo Init']

C. init:
- name: init
image: busybox
command: ['sh', '-c', 'echo Init']

D. preContainers:
- name: init
image: busybox
command: ['sh', '-c', 'echo Init']

Solution

1. Step 1: Recall Kubernetes Pod spec structure

   Init containers are defined under the initContainers field in the Pod spec.

2. Step 2: Match correct YAML key

   Only initContainers: - name: init image: busybox command: ['sh', '-c', 'echo Init'] uses initContainers correctly; others use invalid keys.

3. Final Answer:

   initContainers with proper container spec -> Option A

4. Quick Check:

   Init containers key = initContainers [OK]

Hint: Init containers use 'initContainers' key in Pod YAML [OK]

Common Mistakes:

• Using 'containers' instead of 'initContainers'
• Using invalid keys like 'init' or 'preContainers'
• Misplacing init container definition outside Pod spec

3. Given this Pod spec snippet, what will happen if the init container fails?

initContainers:
  - name: setup
    image: busybox
    command: ['sh', '-c', 'exit 1']
containers:
  - name: app
    image: nginx

medium

A. The main app container will start normally

B. The Pod will ignore the init container failure and continue

C. The Pod will restart the init container until it succeeds

D. The main app container will start but with errors

Solution

1. Step 1: Understand init container failure behavior

   If an init container fails, Kubernetes restarts it until it succeeds or the Pod is stopped.

2. Step 2: Analyze options

   Only The Pod will restart the init container until it succeeds correctly states the Pod restarts the init container on failure; main container won't start until success.

3. Final Answer:

   The Pod will restart the init container until it succeeds -> Option C

4. Quick Check:

   Init container failure = Pod restarts init container [OK]

Hint: Init container failure causes restart, blocks main container [OK]

Common Mistakes:

• Thinking main container starts despite init failure
• Assuming Pod ignores init container failure
• Believing main container runs with errors from init failure

4. You wrote this Pod YAML but the init container does not run before the main container:

containers:
  - name: app
    image: nginx
initContainers:
  - name: setup
    image: busybox
    command: ['sh', '-c', 'echo Setup']

What is the likely error?

medium

A. The initContainers section is placed after containers, order matters

B. The initContainers key is incorrectly indented or misplaced

C. The command syntax is invalid for init containers

D. The image busybox cannot be used as an init container

Solution

1. Step 1: Check YAML structure rules

   Init containers must be correctly indented and placed at the same level as containers under the Pod spec.

2. Step 2: Identify common YAML mistakes

   Misplaced or wrongly indented initContainers causes it to be ignored, so init container won't run.

3. Final Answer:

   The initContainers key is incorrectly indented or misplaced -> Option B

4. Quick Check:

   YAML indentation errors cause init container not to run [OK]

Hint: Check YAML indentation and placement for initContainers [OK]

Common Mistakes:

• Assuming order of keys matters in YAML
• Using wrong command syntax inside init container
• Believing image choice blocks init container

5. You want to use an init container to download a configuration file before your main app starts. Which approach correctly shares the file between the init container and the main container?

hard

A. Copy the file from init container to main container using Docker cp command

B. Run the init container after the main container starts to copy the file

C. Store the file inside the init container image and expect main container to access it

D. Use a shared emptyDir volume mounted in both init and main containers

Solution

1. Step 1: Understand file sharing between containers

   Containers in the same Pod can share files using a shared volume like emptyDir.

2. Step 2: Evaluate options for sharing files

   Only Use a shared emptyDir volume mounted in both init and main containers correctly uses a shared volume mounted in both containers to share files.

3. Final Answer:

   Use a shared emptyDir volume mounted in both init and main containers -> Option D

4. Quick Check:

   Shared volume = file sharing between init and main containers [OK]

Hint: Use shared volume like emptyDir for file sharing [OK]

Common Mistakes:

• Trying to copy files between containers manually
• Expecting files inside init container image to be accessible
• Running init container after main container starts