Ukuran Image #

Dalam praktik modern software engineering, Docker image bukan sekadar artefak build, tetapi bagian penting dari supply chain aplikasi. Ukuran Docker image yang terlalu besar sering kali menjadi sumber berbagai masalah tersembunyi: proses build lambat, waktu pull image lama, biaya bandwidth meningkat, cold start container lebih berat, hingga permukaan serangan (attack surface) yang lebih luas.

Artikel ini adalah artikel pengantar yang membahas prinsip umum dan pola pikir dalam mengurangi ukuran Docker image, tanpa terikat pada bahasa pemrograman tertentu. Untuk implementasi teknis yang lebih spesifik, setiap bahasa pemrograman akan dibahas secara terpisah pada artikel lanjutan.

Tujuan utama artikel ini adalah membentuk mental model yang benar: mengapa Docker image bisa membengkak, apa saja faktor utamanya, dan strategi umum apa yang bisa diterapkan lintas bahasa dan framework.

Mengapa Ukuran Docker Image Itu Penting? #

Sebelum masuk ke teknik, penting untuk memahami dampaknya:

1. Kecepatan CI/CD Image besar = waktu build & pull lebih lama, terutama pada pipeline CI yang sering melakukan rebuild.

2. Waktu Deploy & Scaling Pada Kubernetes, ECS, atau Docker Swarm, node baru harus menarik image terlebih dahulu. Image besar memperlambat autoscaling.

3. Biaya Infrastruktur Bandwidth, registry storage, dan waktu compute meningkat seiring ukuran image.

4. Keamanan Semakin banyak file, library, dan tool di image, semakin besar pula attack surface.

5. Operasional & Debugging Image ramping lebih mudah dipahami, dipelihara, dan diaudit.

Apa Penyebab Docker Image Menjadi Besar? #

Beberapa penyebab umum yang sering terjadi di hampir semua bahasa pemrograman:

1. Base Image Terlalu Gemuk #

Menggunakan image seperti:

• ubuntu:latest
• debian:latest

untuk aplikasi sederhana sering kali tidak sebanding dengan kebutuhan runtime sebenarnya.

2. Dependency Build Ikut Terbawa ke Runtime #

Compiler, package manager, build tools, dan header file sering kali:

• Dibutuhkan saat build
• Tidak dibutuhkan saat runtime

Namun tetap ikut masuk ke image final.

3. Layer Docker yang Tidak Efisien #

• Terlalu banyak RUN terpisah
• File sementara tidak dibersihkan
• Cache package manager tertinggal

Semua ini menumpuk di layer Docker.

4. Konteks Build Terlalu Besar #

• node_modules
• .git
• File test
• Dokumentasi internal

Ikut terkirim ke Docker daemon jika .dockerignore tidak diatur dengan benar.

5. “One Image Fits All” #

Image dipakai sekaligus untuk:

• Development
• Testing
• Production

Padahal kebutuhan tiap environment berbeda.

Prinsip Dasar Mengurangi Ukuran Docker Image #

Bagian ini adalah inti dari artikel pengantar.

Pisahkan Build dan Runtime #

Prinsip paling fundamental:

Apa yang dibutuhkan saat build belum tentu dibutuhkan saat runtime

Solusi umum:

• Gunakan multi-stage build
• Stage pertama: compile / build
• Stage terakhir: hanya runtime artifact

Hasilnya:

• Image lebih kecil
• Lebih aman
• Lebih bersih

Gunakan Base Image yang Tepat #

Base image ideal memiliki karakteristik:

• Sekecil mungkin
• Stabil
• Sesuai kebutuhan runtime

Pendekatan umum:

• Hindari OS image penuh jika tidak diperlukan
• Pertimbangkan image minimal atau distroless

Base image bukan soal “yang paling kecil”, tapi “yang paling tepat”.

Minimalkan Isi Image Final #

Tanyakan pada diri sendiri:

• Apakah file ini dibutuhkan saat aplikasi berjalan?
• Apakah tool ini hanya untuk debugging?
• Apakah dokumentasi ini relevan di production?

Prinsipnya:

Image production seharusnya hanya berisi apa yang dibutuhkan untuk menjalankan aplikasi.

Optimalkan Layer Docker #

Beberapa prinsip umum:

• Gabungkan perintah yang saling berkaitan
• Hapus cache dan file sementara dalam layer yang sama
• Urutkan instruksi agar cache Docker lebih efektif

Layer yang rapi:

• Lebih kecil
• Lebih cepat di-rebuild

Kelola Build Context dengan .dockerignore #

.dockerignore adalah senjata yang sering diremehkan.

Idealnya, Docker hanya menerima:

• Source code yang relevan
• File konfigurasi yang dibutuhkan

Bukan:

• Dependency lokal
• Artefak build lama
• File editor

Semakin kecil build context, semakin cepat dan bersih proses build.

Bedakan Image Development dan Production #

Image untuk development boleh:

• Lebih besar
• Punya debugging tools
• Hot reload

Image production sebaiknya:

• Minimal
• Immutable
• Fokus pada runtime

Jangan kompromikan production demi kenyamanan development.

Dampak Positif Docker Image yang Ramping #

Jika prinsip-prinsip di atas diterapkan dengan benar, dampaknya biasanya langsung terasa:

• Build CI lebih cepat
• Pull image lebih ringan
• Deployment lebih responsif
• Surface keamanan berkurang
• Konsumsi resource lebih efisien

Dan yang paling penting: arsitektur container menjadi lebih disiplin dan terstruktur.

Penutup #

Artikel ini adalah fondasi konseptual untuk memahami bagaimana dan mengapa ukuran Docker image bisa dan perlu dikurangi. Semua prinsip yang dibahas di sini bersifat lintas bahasa dan framework.

Pada artikel-artikel berikutnya, setiap bahasa pemrograman akan dibahas secara terpisah, lengkap dengan:

• Contoh Dockerfile nyata
• Strategi khusus per ekosistem
• Trade-off yang perlu dipahami
• Best practice untuk production

Dengan memahami prinsip umumnya terlebih dahulu, pembahasan teknis per bahasa tidak lagi terasa sebagai kumpulan trik, melainkan bagian dari satu pendekatan desain yang utuh.

Untuk optimasi ukuran image di setiap bahasa pemrograman kami buat terpisah:

1. Golang
2. Python
3. Java (Spring Boot)
4. PHP
5. Typescript
6. Ruby
7. Rust

Artikel di atas membahas strategi dasar untuk optimasi ukuran image dan dibuat agar tidak tergantung pada framework tertentu (kecuali java).