Init container pattern in Docker - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the Docker Compose service to add an init container using the correct key.

Docker

services:
  app:
    image: myapp:latest
    [1]:
      - init-myservice
    init-myservice:
      image: busybox
      command: ['sh', '-c', 'echo Init container running']

Drag options to blanks, or click blank then click option'

Adepends_on

Binit_containers

CinitContainers

Dinit

Attempts:

3 left

💡 Hint

Common Mistakes

Using Kubernetes keys like 'initContainers' in Docker Compose.

Using camelCase keys instead of Docker Compose keys.

The correct key to define dependencies between services in Docker Compose is depends_on. Docker Compose does not support init containers natively, so initContainers is not valid here. The depends_on key ensures that the init-myservice service starts before the app service.

2fill in blank

medium

Complete the Kubernetes pod spec to add an init container that runs a shell command.

Docker

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  [1]:
  - name: init-myservice
    image: busybox
    command: ['sh', '-c', 'echo Init container running']
  containers:
  - name: app
    image: myapp:latest

Drag options to blanks, or click blank then click option'

Ainit_containers

Binit

CinitContainers

Dcontainers

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'containers' instead of 'initContainers'.

Using snake_case instead of camelCase.

The initContainers field is used in Kubernetes pod specs to define init containers that run before app containers.

3fill in blank

hard

Fix the error in the init container command to correctly run a shell script.

Docker

initContainers:
- name: init-myservice
  image: busybox
  command: ['[1]', '-c', 'echo Init container running']

Drag options to blanks, or click blank then click option'

Abash

Bsh

Cshell

Dcmd

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'bash' which may not be installed in busybox.

Using 'cmd' which is Windows-specific.

The sh shell is available in the busybox image and is used to run shell commands. Using bash would fail if bash is not installed.

4fill in blank

hard

Fill both blanks to define an init container that creates a directory before the main container starts.

Docker

initContainers:
- name: init-dir
  image: busybox
  command: ['[1]', '-c', 'mkdir -p /data']
containers:
- name: app
  image: myapp:latest
  volumeMounts:
  - name: data-volume
    mountPath: [2]

Drag options to blanks, or click blank then click option'

Ash

B/data

C/app/data

Dbash

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'bash' instead of 'sh' in busybox.

Mounting volume at a different path than created.

The init container uses sh to run the mkdir command. The main container mounts the volume at /data to use the directory created.

5fill in blank

hard

Fill all three blanks to create a pod spec with an init container that waits for a file before starting the app container.

Docker

apiVersion: v1
kind: Pod
metadata:
  name: wait-pod
spec:
  initContainers:
  - name: wait-for-file
    image: busybox
    command: ['[1]', '-c', 'until test -f /data/ready.txt; do echo waiting; sleep 2; done']
    volumeMounts:
    - name: data-volume
      mountPath: [2]
  containers:
  - name: app
    image: myapp:latest
    volumeMounts:
    - name: data-volume
      mountPath: [3]
  volumes:
  - name: data-volume
    emptyDir: {}

Drag options to blanks, or click blank then click option'

Ash

B/data

C/app/data

Dbash

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'bash' which may not be in busybox.

Mounting volumes at different paths in init and app containers without reason.

The init container uses sh to run the wait loop. The volume is mounted at /data in the init container and /app/data in the app container, showing how mount paths can differ.

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