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.