Ephemeral Container #

Dalam dunia containerization, Docker sering diasosiasikan dengan container yang menjalankan aplikasi utama — web server, API, worker — yang hidup berhari-hari, berminggu-minggu, atau bahkan berbulan-bulan. Tapi ada kategori container lain yang sama pentingnya: ephemeral container, yaitu container yang diciptakan untuk satu tugas spesifik lalu langsung lenyap.

Container ephemeral adalah pekerja sekali pakai. Ia dibuat, menjalankan satu perintah atau satu workflow, lalu dihapus. Tidak ada state yang harus dijaga, tidak ada proses yang harus di-restart, dan tidak ada data yang boleh hilang saat ia mati — karena memang tidak seharusnya ada.

Memahami konsep ephemeral adalah prasyarat untuk seluruh section storage ini. Mengapa? Karena hampir semua keputusan storage Docker — kenapa volume dibutuhkan, kenapa data harus dipisahkan, kenapa backup berfokus pada data — berangkat dari satu prinsip sederhana: container ephemeral, data persistent.

Artikel ini membahas apa itu ephemeral container, karakteristiknya, kapan harus menggunakannya, dan bagaimana membedakan dengan long-running container. Di akhir, kamu akan punya framework berpikir yang jelas untuk memutuskan apakah suatu workload harus dijalankan sebagai container ephemeral atau long-running.

Apa Itu Ephemeral Container? #

Secara definisi, ephemeral container adalah container yang:

• Dibuat untuk tujuan sementara — biasanya satu tugas spesifik, bukan aplikasi yang terus menyala.
• Tidak menyimpan state penting — semua data yang dihasilkan harus ditulis ke volume, atau memang sengaja hilang.
• Tidak perlu restart — saat mati, biarkan mati. Tugas sudah selesai atau memang harus dihentikan paksa.
• Otomatis dihapus setelah selesai — flag --rm memastikan container tidak menumpuk.

docker run --rm alpine echo "Hello, ephemeral world"

Perintah di atas adalah contoh paling sederhana. Container dibuat, menjalankan echo, selesai, dan langsung dihapus oleh Docker daemon karena flag --rm. Total waktu hidupnya mungkin kurang dari satu detik.

flowchart LR
    A[Buat container] --> B[Jalankan tugas]
    B --> C{Tugas selesai?}
    C -- Ya --> D[Container auto-remove]
    C -- Tidak --> B
    D --> E[Cleanup<br/>tidak ada sisa]

Karakteristik yang Membedakan #

Ephemeral container punya ciri-ciri yang bisa kamu kenali dari desainnya:

• Umur pendek — detik, menit, atau sampai tugas selesai. Tidak pernah hari.
• Stateless — tidak ada data yang harus dijaga antara invokasi.
• Purpose-specific — satu container = satu tujuan. Bukan multi-purpose.
• Disposable — boleh mati, boleh dihapus, tidak ada recovery.
• Idempotent — tugas yang sama dijalankan ulang harus menghasilkan hasil yang sama (atau boleh berbeda tanpa konsekuensi).

Perbedaan paling mencolok dibanding long-running container adalah harapan terhadap kematian. Pada long-running container, kematian adalah异常的 — kamu harus restart, debugging, alerting. Pada ephemeral container, kematian adalah tujuan — saat container mati, itu berarti tugasnya selesai.

Ephemeral vs Long-Running: Perbedaan Mendasar #

Memahami kapan menggunakan masing-masing adalah keputusan arsitektur yang sering diabaikan. Banyak engineer secara default menjalankan semua workload sebagai long-running, padahal banyak yang sebenarnya lebih cocok sebagai ephemeral.

flowchart TB
    subgraph LONG["Long-Running Container"]
        L1[Selalu menyala] --> L2[Melayani trafik]
        L2 --> L3[Restart policy: always]
        L3 --> L4[Stateful boleh]
    end
    
    subgraph EPH["Ephemeral Container"]
        E1[Dibuat on-demand] --> E2[Jalankan satu tugas]
        E2 --> E3[Tugas selesai → exit]
        E3 --> E4[Auto-remove dengan --rm]
    end

Cara ingat: Long-running container adalah “restoran buka 24 jam” — pelanggan datang kapan saja, harus siap. Ephemeral container adalah “tukang pos satu kali antar” — selesaikan satu tugas, selesai.

Anatomi Container Ephemeral #

Untuk memahami cara kerja ephemeral, bedah apa yang terjadi saat kamu menjalankan container sekali pakai.

Lifecycle Tipikal #

stateDiagram-v2
    [*] --> Created: docker run --rm image cmd
    Created --> Running: container start
    Running --> Exited: command selesai
    Exited --> Removed: auto-remove (--rm)
    Removed --> [*]

Tidak ada state Restarting, tidak ada transisi ke Paused, tidak ada Restart setelah exit. Lifecycle linear: lahir, jalan, selesai, hilang.

Apa yang Terjadi di Belakang #

Saat docker run --rm image command dieksekusi:

1. Docker menarik image dari cache atau registry (kalau belum ada).
2. Docker membuat container baru dengan writable layer kosong.
3. Container start, menjalankan command.
4. command selesai, container exit.
5. Karena flag --rm, Docker langsung menghapus container dan writable layer-nya.

Totalnya: upperdir dibuat, dipakai singkat, lalu dihapus. Tidak ada side effect ke host, tidak ada container yang menumpuk, tidak ada port yang bocor.

Sumber Daya Setelah Container Mati #

Karena upperdir ikut dihapus, semua perubahan runtime hilang:

• File yang ditulis di /tmp — hilang.
• Cache yang di-generate di /var/cache — hilang.
• Log yang ditulis ke stdout/stderr — masih bisa di-capture (lihat best practice).
• File di volume atau bind mount — tetap ada (karena disimpan di host, bukan di upperdir).

Ini menjelaskan kenapa data penting harus ditulis ke volume, bukan ke filesystem container. Container ephemeral tidak punya konsep “data harus bertahan” — semua data yang perlu persist harus dieksternalisasi.

Use Case Ephemeral Container #

Ephemeral container sangat cocok untuk workload yang sifatnya batch, sekali jalan, atau tidak stateful. Berikut use case yang paling umum.

1. Menjalankan Perintah Sekali Jalan #

Paling sederhana dan paling sering dipakai:

docker run --rm node:20 node -e "console.log('Hello from Node')"

Kamu tidak perlu install Node.js di host. Tidak ada setup environment. Tidak ada污染 ke sistem. Container hidup sepersekian detik lalu hilang.

# Cek versi tool tanpa install
docker run --rm python:3.12 python --version
docker run --rm golang:1.22 go version
docker run --rm postgres:16 psql --version

Pola ini sangat berguna di CI/CD pipeline dan workstation developer yang ingin tetap bersih.

2. Database Migration #

Saat deploy versi baru aplikasi, kamu sering perlu menjalankan migration. Migration adalah tugas sekali jalan, bukan proses yang harus terus menyala:

docker run --rm \
  --network app-network \
  -e DATABASE_URL=postgres://... \
  myapp-image:latest \
  ./migrate up

Container dibuat, migration dijalankan, selesai, container dihapus. Database naik versi tanpa kamu harus login ke container database atau menjalankan migration manual.

flowchart LR
    A[CI/CD trigger deploy] --> B[Pull image baru]
    B --> C[Jalankan migration container]
    C --> D{Migration sukses?}
    D -- Ya --> E[Deploy app container baru]
    D -- Tidak --> F[Rollback]

3. Debugging Container yang Sedang Berjalan #

Saat aplikasi production bermasalah dan kamu tidak ingin install tool debug di container production, gunakan container ephemeral dengan network atau volume yang sama:

# Masuk ke network container production
docker run --rm -it \
  --network container:myapp-container \
  alpine sh

# Akses volume database production untuk inspect
docker run --rm -it \
  --volumes-from mysql-container \
  alpine sh

Container debug ini:

• Berbagi network namespace dengan container target (bisa curl localhost ke service yang sama).
• Berbagi volume tertentu (bisa baca langsung file data).
• Tidak mengubah container target.
• Saat selesai debugging, container debug dihapus, tidak ada jejak.

Pola lanjutan: Sejak Kubernetes 1.16, ada fitur resmi ephemeral debug container yang melakukan hal serupa di cluster. Docker CLI mengikuti pola yang sama dengan docker run --rm --network container:....

4. CI/CD Pipeline #

Hampir semua pipeline CI modern berjalan di container ephemeral. GitHub Actions, GitLab CI, CircleCI — semuanya menjalankan setiap job di container fresh yang dihapus setelah job selesai.

# GitHub Actions example
jobs:
  test:
    runs-on: ubuntu-latest
    container:
      image: node:20
    steps:
      - uses: actions/checkout@v4
      - run: npm install
      - run: npm test
    # container otomatis dihapus setelah job selesai

Keuntungan pola ini:

• Environment bersih setiap job — tidak ada state yang bocor antar run.
• Reproducible — pipeline selalu mulai dari kondisi image yang sama.
• Parallel-ready — banyak job berjalan bersamaan tanpa konflik resource.
• No cleanup code — provider CI yang menangani disposal.

5. Batch Processing dan ETL #

Pekerjaan yang membaca data, memproses, dan menulis output — tanpa state antara run — adalah kandidat sempurna untuk ephemeral:

# Backup harian
docker run --rm \
  -v postgres-data:/source:ro \
  -v /backups:/backup \
  postgres:16 \
  pg_dump -U postgres mydb > /backup/mydb-$(date +%F).sql

# Image processing
docker run --rm \
  -v /photos:/input:ro \
  -v /output:/output \
  imagemagick \
  mogrify -resize 50% /input/*.jpg

# Data transform
docker run --rm \
  -v /raw:/data:ro \
  python:3.12 \
  python /scripts/transform.py

Container selesai, output tersimpan di host (via volume), container hilang. Bersih dan efisien.

6. Tes Terisolasi #

Menjalankan integration test yang butuh database, message broker, atau service lain tanpa mencemari host:

# Tes dengan database sementara
docker run --rm -d --name test-db -e POSTGRES_PASSWORD=test postgres:16
docker run --rm --network container:test-db myapp:test ./run-integration-tests
docker rm -f test-db

Atau lebih elegan dengan Docker Compose profile untuk test:

services:
  db:
    image: postgres:16
    profiles: ["test"]
  app-test:
    build: .
    profiles: ["test"]
    depends_on: [db]
    command: npm test

docker compose --profile test run --rm app-test

Ephemeral Container di Docker Compose #

Docker Compose punya sub-command run yang khusus untuk menjalankan container sekali jalan di dalam stack:

docker compose run --rm app npm test

Karakteristik docker compose run:

• Tidak ikut lifecycle up — tidak menambah atau me-recreate service.
• Tidak di-restart — saat exit, selesai.
• Selesai → hilang — dengan flag --rm, container dihapus otomatis.
• Bisa menjalankan command yang berbeda dari command di compose file.

Ini berguna untuk menjalankan migration, seed data, atau perintah administratif di stack yang sudah running:

# Jalankan migration di stack production
docker compose run --rm app ./migrate up

# Jalankan seed
docker compose run --rm app ./seed

# Backup database langsung
docker compose run --rm db pg_dump -U postgres mydb > backup.sql

flowchart LR
    UP[docker compose up<br/>long-running services] --> APP[App container]
    UP --> DB[DB container]
    UP --> REDIS[Redis container]
    
    RUN[docker compose run --rm<br/>ephemeral task] --> MIG[Migration]
    RUN --> SEED[Seed data]
    RUN --> BACKUP[Backup]

Perbedaan penting antara docker compose up dan docker compose run:

Flag Penting untuk Container Ephemeral #

Beberapa flag CLI yang wajib kamu tahu saat bekerja dengan ephemeral container.

--rm — Auto Remove #

docker run --rm alpine echo "bye"

Container dihapus otomatis setelah exit. Wajib untuk ephemeral — tanpa --rm, container akan tetap ada (status exited) dan menumpuk di docker ps -a.

--name — Identifier (Opsional) #

docker run --rm --name temp-tool alpine sh -c "echo 'task'"

Bisa dipakai untuk debug, tapi perlu dihindari di workflow paralel (nama bentrok).

-e / --env — Environment Variable #

docker run --rm -e DATABASE_URL=postgres://... myapp ./task

Untuk passing konfigurasi ke container sekali jalan.

--network container:NAME — Share Network #

docker run --rm --network container:app myapp curl http://localhost:8080

Berguna untuk debug — container baru berbagi network namespace dengan container target.

--volumes-from NAME — Share Volumes #

docker run --rm --volumes-from mysql-data alpine ls /var/lib/mysql

Membaca isi volume container lain tanpa ikut membuat.

-i -t — Interactive Terminal #

docker run --rm -it alpine sh

Untuk masuk ke shell interaktif. Pada container ephemeral debug, ini kombinasi yang sangat umum.

--restart=no — Default untuk Ephemeral #

Default --restart adalah no — container tidak akan di-restart setelah exit. Ini cocok untuk ephemeral, tapi jangan pakai untuk long-running service.

Ephemeral Container dan --rm — Apa yang Sebenarnya Terjadi #

Untuk benar-benar memahami ephemeral, penting tahu apa yang --rm lakukan dan tidak lakukan.

Yang --rm Lakukan #

• Menghapus container dari daftar docker ps -a setelah exit.
• Membersihkan writable layer container.
• Release port dan resource yang dipakai container.

Yang --rm TIDAK Lakukan #

• Tidak menghapus image — image tetap ada, bisa dipakai ulang.
• Tidak menghapus volume — volume yang di-mount tetap ada (bahkan setelah container hilang).
• Tidak menghapus network — network yang dibuat (via --network) tetap ada, kecuali kamu hapus manual.
• Tidak menghapus bind mount — path host tetap ada, container hanya berhenti mengaksesnya.

Ini menjelaskan kenapa data di volume tetap aman walau container ephemeral mati. Volume disimpan di host, bukan di upperdir container.

flowchart TB
    IMG[Image<br/>tetap ada] -.-> C
    VOL[Volume<br/>tetap ada] -.-> C
    NET[Network<br/>tetap ada] -.-> C
    
    subgraph LIFECYCLE["Lifecycle Container"]
        C[Container<br/>upperdir]
    end
    
    C -- exit --> DEL[Dihapus oleh --rm]
    
    style DEL fill:#ff6b6b
    style IMG fill:#51cf66
    style VOL fill:#51cf66
    style NET fill:#51cf66

Hati-hati: Jika kamu lupa --rm dan menjalankan banyak container tanpa menghapusnya, mereka akan menumpuk sebagai “exited containers”. Mereka tidak makan resource CPU/RAM, tapi mereka memenuhi output docker ps -a dan bisa membingungkan audit. Bersihkan dengan docker container prune.

Filosofi “Cattle, Not Pets” #

Ephemeral container adalah manifestasi konkret dari prinsip terkenal di dunia infrastruktur:

Pets are given names like “puss” and “boff”. Cattle are given numbers like “3458” and “8877”. — Bill Baker, Microsoft

Pets (binatang peliharaan) — dijaga, di-patch, di-naming dengan sayang. Saat sakit, diobati. Saat mati, dimakamkan dengan hormat. Contoh: server tradisional dengan hostname web-server-01 yang harus di-maintain bertahun-tahun.

Cattle (ternak) — diberi nomor, tidak diberi nama. Saat sakit atau tidak produktif, dipotong dan diganti yang baru. Contoh: container dengan nama random yang di-restart atau di-recreate tanpa ceremony.

Ephemeral container adalah cattle. Kamu tidak boleh sayang padanya. Jangan kasih nama, jangan simpan state di dalamnya, jangan coba “memperbaiki” container yang rusak — cukup hapus dan jalankan yang baru.

flowchart TB
    subgraph PETS["PETS — Tradisional"]
        P1[Server web-01] --> P2[Patch OS]
        P2 --> P3[Update app]
        P3 --> P4[Monitor]
        P4 --> P5{Rusak?}
        P5 -- Ya --> P6[Debug & repair]
    end
    
    subgraph CATTLE["CATTLE — Container"]
        C1[Container random] --> C2{Jalan?}
        C2 -- Tidak --> C3[Hapus]
        C2 -- Ya --> C4[Kerja sampai selesai]
        C4 --> C5[Auto-remove]
        C3 --> C6[Buat container baru]
        C6 --> C1
    end

Prinsip ini bukan hanya filosofi — ia punya konsekuensi teknis yang nyata:

• Container bisa di-replace tanpa kehilangan data (karena data di volume).
• Container bisa di-scale dengan menjalankan instance baru (orchestrator seperti Kubernetes atau Swarm melakukan ini otomatis).
• Container bisa di-update dengan image baru tanpa ceremony (rolling update).
• Container bisa di-rollback dengan kembali ke image lama (kalau image baru bermasalah).

Tanpa pola cattle, container hanya menjadi “VM yang lebih ringan” — kamu masih terjebak dalam mentalitas pet. Dengan pola cattle, container menjadi unit komputasi yang benar-benar disposable dan scalable.

Kapan TIDAK Menggunakan Ephemeral Container #

Ephemeral bukan silver bullet. Ada situasi di mana long-running lebih tepat:

• Web server, API, atau service yang harus menerima request kapan saja — kalau container mati, request berikutnya gagal. Ini butuh restart policy dan uptime tinggi.
• Worker yang memproses job terus-menerus — queue consumer harus tetap menyala, menarik job dari broker.
• Database server — meski tidak menerima request dari user, DB harus tetap hidup untuk melayani query.
• Stateful service dengan koneksi persisten — game server, SSH bastion, atau aplikasi dengan WebSocket yang harus dijaga koneksinya.
• Service dengan startup lambat — kalau container butuh 5 menit untuk siap, menjalankan sebagai ephemeral setiap kali request masuk tidak praktis.

Untuk workload seperti ini, gunakan long-running container dengan:

• Restart policy always atau unless-stopped.
• Persistent volume untuk data.
• Health check untuk auto-restart saat hang.
• Orchestrator (Swarm, Kubernetes) untuk scaling dan healing otomatis.

Best Practice Container Ephemeral #

1. Selalu Gunakan --rm untuk Container Sekali Jalan #

# BENAR
docker run --rm alpine echo "hello"

# ANTI-PATTERN: container menumpuk sebagai exited
docker run alpine echo "hello"

# Bersihkan container exited yang lupa dihapus
docker container prune

2. Pastikan Tugas Idempotent #

Container ephemeral bisa dijalankan ulang. Tugas yang dijalankan harus menghasilkan output yang sama (atau tidak konflik) meskipun dijalankan berkali-kali.

# Idempotent: buat tabel, jalankan ulang tetap aman
docker run --rm myapp ./migrate up

# Tidak idempotent: append tanpa cek
docker run --rm myapp ./append-data  # ← bisa duplikat saat dijalankan ulang

3. Simpan State di Luar Container #

Semua state harus ditulis ke volume atau external system:

# BENAR: tulis ke volume
docker run --rm -v /backup:/output postgres:16 pg_dump ... > /output/db.sql

# ANTI-PATTERN: tulis ke filesystem container
docker run --rm postgres:16 pg_dump ... > /tmp/db.sql  # hilang saat container mati

4. Capture Output via stdout/stderr #

Untuk logging, tulis ke stdout/stderr dan biarkan Docker atau driver log menanganinya:

# Output bisa di-capture ke file host
docker run --rm myapp ./task > /logs/task.log 2>&1

5. Gunakan Image Kecil untuk Start Cepat #

Container ephemeral yang sering dijalankan (CI/CD, batch) harus start secepat mungkin. Gunakan base image kecil dan multi-stage build.

# Lambat: 800 MB image dengan Ubuntu + toolchain
docker run --rm myapp:dev ./task  # butuh 5 detik start

# Cepat: 15 MB image alpine atau distroless
docker run --rm myapp:prod ./task  # butuh 0.3 detik start

6. Set Resource Limit jika Perlu #

Container ephemeral yang berjalan di shared host harus punya batas resource agar tidak mengganggu workload lain:

docker run --rm \
  --memory=256m \
  --cpus=0.5 \
  myapp ./heavy-task

7. Handle Error Code dengan Benar #

Exit code container ephemeral bisa di-capture oleh caller (CI/CD, scheduler):

docker run --rm myapp ./task
EXIT_CODE=$?

if [ $EXIT_CODE -ne 0 ]; then
  echo "Task failed"
  exit $EXIT_CODE
fi

Exit code 0 = sukses, 1-125 = error aplikasi, 126 = command tidak bisa dieksekusi, 127 = command tidak ditemukan, 137 = SIGKILL (OOM atau timeout).

Ephemeral Container di Orchestrator Modern #

Pola ephemeral bukan hanya untuk docker run manual. Orchestrator modern seperti Kubernetes dan Docker Swarm menjadikan ephemeral sebagai pola default.

Kubernetes — Job dan CronJob #

Kubernetes punya resource Job untuk workload ephemeral:

apiVersion: batch/v1
kind: Job
metadata:
  name: db-migrate
spec:
  template:
    spec:
      containers:
      - name: migrate
        image: myapp:1.2
        command: ["./migrate", "up"]
      restartPolicy: Never
  backoffLimit: 3

Job berjalan sampai completion. Jika gagal, Kubernetes retry sampai backoffLimit. Setelah selesai, Job dianggap done.

Untuk workload periodik, ada CronJob:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: nightly-backup
spec:
  schedule: "0 2 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            image: backup-tool:1.0
            command: ["./backup.sh"]
          restartPolicy: Never

Ini menjalankan container ephemeral setiap malam pukul 2. Container hidup hanya selama backup berjalan, lalu mati.

Docker Swarm — Mode Global/Replication #

Swarm bisa menjalankan container ephemeral secara global di semua node untuk maintenance task:

docker service create \
  --mode global \
  --restart-condition none \
  alpine sh -c "do-maintenance"

Container berjalan di semua node, mati setelah selesai, tidak di-restart.

Anti-Pattern yang Harus Dihindari #

1. Mengandalkan Filesystem Container untuk Data Penting #

# ANTI-PATTERN: data hilang saat container mati
docker run --rm myapp ./process  # tulis output ke /tmp atau /app/output

Selalu tulis ke volume atau external storage.

2. Menganggap Container Akan Selalu Ada #

Jangan tulis logika yang bergantung pada container tertentu. Selalu asumsikan container bisa mati kapan saja.

3. Menyimpan Konfigurasi Manual di Dalam Container #

Konfigurasi harus di-passing via env var, file di volume, atau di-bake ke image secara reproducible.

4. Tidak Menggunakan --rm #

Container exited yang menumpuk memenuhi docker ps -a, membingungkan audit, dan kadang membuat engineer salah kaprah menganggap container masih running.

# Audit container exited
docker ps -a --filter "status=exited"

# Bersihkan
docker container prune

5. Memaksakan Long-Running untuk Tugas Batch #

Jangan pakai restart policy always untuk tugas yang harus selesai. Gunakan long-running untuk service, ephemeral untuk batch.

Hubungan dengan Konsep Lainnya #

Ephemeral container adalah bagian dari ephemeral infrastructure yang lebih besar:

Inti dari semua konsep ini sama: jangan memperbaiki yang rusak, buat ulang dari awal. Ini menghasilkan sistem yang:

• Lebih konsisten — tidak ada drift karena selalu start dari definisi.
• Lebih mudah di-debug — masalah reproducible, bisa di-recreate di environment terkontrol.
• Lebih aman — tidak ada state sensitif yang tertinggal.

Ringkasan #

• Ephemeral container adalah container sekali pakai: dibuat, menjalankan satu tugas, selesai, dihapus (--rm). Lawan dari long-running container yang menyala terus-menerus.
• Karakteristik utama: umur pendek, stateless, purpose-specific, disposable, dan idempotent. Kematian bukan insiden — kematian adalah tujuan.
• Use case utama: perintah sekali jalan, database migration, debugging, CI/CD pipeline, batch processing, ETL, dan tes terisolasi. Hampir semua workflow yang sifatnya batch dan sekali jalan cocok untuk ephemeral.
• Perbedaan dengan long-running: long-running punya restart policy, toleransi kematian rendah, dan biasanya stateful (dengan volume). Ephemeral tidak punya restart policy, kematian adalah tujuan, dan wajib stateless.
• Docker Compose mendukung ephemeral lewat docker compose run --rm <service> <command>. Ini berbeda dari docker compose up yang menjalankan long-running services.
• Flag wajib: --rm untuk auto-remove, -it untuk interactive, --network container: untuk debug. Tanpa --rm, container exited akan menumpuk.
• Filosofi “cattle, not pets” adalah jiwa dari ephemeral container. Container tidak diberi nama, tidak dijaga, dan tidak disayang — saat rusak, hapus dan buat yang baru.
• Kontraindikasi: web server, API, queue worker, database server, dan service yang harus menerima request kapan saja. Ini lebih cocok untuk long-running.
• Data ephemeral tetap harus ditulis ke volume atau external storage. Writable layer container akan hilang, dan data di /tmp ikut hilang. Topik ini akan dibahas mendalam di artikel selanjutnya.

← Sebelumnya: File System & Layer   Berikutnya: Persistent Data →