Docker on kenji.blog

Langkah-langkah Membangun Lingkungan Pengembangan Lokal yang Dapat Direproduksi Menggunakan Docker

Sun, 13 Sep 2026 01:00:00 +0900

1. Pendahuluan: Keluar dari Siklus “Di Lingkungan Saya Berjalan Normal”

Dalam dunia pengembangan perangkat lunak, masalah “Di lingkungan saya berjalan normal (It works on my machine)” yang disebabkan oleh perbedaan lingkungan antar pengembang, telah lama menjadi faktor yang membuang-buang waktu dalam banyak proyek. Perbedaan OS, versi bahasa yang diinstal, dependensi pustaka, konflik dengan alat yang diinstal secara global, dll. membuat lingkungan lokal selalu dihadapkan pada “ketidakpastian status”.

Hal yang dapat menyelesaikan masalah ini dari akarnya adalah teknologi kontainer seperti Docker, dan paradigma Infrastructure as Code (IaC). Dengan mengontainerisasi lingkungan pengembangan lokal, kita dapat mewujudkan isolasi di tingkat OS, serta memungkinkan sistem kontrol versi pada lingkungan itu sendiri bersama dengan basis kode.

Dalam artikel ini, kita akan membahas secara mendalam, lengkap dengan perspektif matematis dan mekanisme teknis yang mendasarinya, mengenai langkah-langkah membangun “lingkungan pengembangan lokal yang dapat direproduksi, sehingga siapa pun, kapan pun, dan di mesin mana pun ketika dihidupkan, akan menghasilkan kondisi yang persis sama”, dengan memanfaatkan Docker, Docker Compose, dan VSCode DevContainers.

2. Kedekatan antara Infrastructure as Code (IaC) dan Teknologi Kontainer

Prinsip IaC dan Penerapannya di Lingkungan Lokal

Infrastructure as Code (IaC) adalah pendekatan di mana pengelolaan dan penyediaan konfigurasi infrastruktur dilakukan melalui file definisi yang dapat dibaca mesin, bukan melalui proses manual. Prinsip inti IaC mencakup elemen-elemen berikut:

Pendekatan Deklaratif (Declarative Approach): Mendefinisikan “seperti apa status akhir seharusnya” daripada “bagaimana cara mengubah status tersebut”.
Idempotensi (Idempotency): Tidak peduli seberapa sering skrip dieksekusi, hasil yang sama (status) selalu terjamin.
Kontrol Versi (Version Control): Status infrastruktur disimpan sebagai kode dalam VCS seperti Git, yang memungkinkan pelacakan riwayat perubahan dan tinjauan rekan (peer review).

Mempraktikkan IaC dalam lingkungan pengembangan lokal berarti mengodekan “bentuk ideal” dari lingkungan pengembangan menggunakan Dockerfile, docker-compose.yml, dan devcontainer.json. Dengan ini, anggota baru yang bergabung dalam tim dapat merasakan pengalaman pengenalan (onboarding) di mana mereka hanya perlu meng-clone repositori dan menjalankan satu perintah untuk dapat langsung memulai pengembangan.

Fitur Kernel yang Mendukung Teknologi Kontainer

Berbeda dengan virtualisasi tipe hypervisor seperti Mesin Virtual (VM), teknologi kontainer adalah teknologi virtualisasi ringan yang mengisolasi proses sambil berbagi kernel OS host. Untuk mewujudkan hal ini, fungsi-fungsi kernel Linux berikut ini banyak digunakan:

Namespaces: Menyediakan tampilan yang independen dari sumber daya sistem (PID, jaringan, titik pemasangan (mount points), pengguna, dll.) untuk setiap proses.
Cgroups (Control Groups): Melakukan pembatasan dan alokasi sumber daya fisik yang dapat digunakan oleh proses (CPU, memori, I/O disk, dll.).
UnionFS (Union File System): Teknologi yang memungkinkan tumpang tindih secara transparan dari beberapa struktur direktori (lapisan/layer) agar tampak sebagai satu sistem file tunggal. Lapisan citra (image layer) Docker bergantung pada teknologi ini.

Mari pertimbangkan model matematika dari pembatasan sumber daya. Misalkan total kapasitas memori mesin host adalah $M_{\text{total}}$, dan batas memori untuk $n$ buah kontainer yang berjalan di host adalah $m_i$. Kondisi yang diperlukan agar sistem dapat berjalan stabil, dengan memperhitungkan basis memori $M_{\text{os}}$ yang dikonsumsi oleh OS host dan proses lainnya, dapat direpresentasikan oleh pertidaksamaan berikut:

$$ \sum_{i=1}^{n} m_i \le M_{\text{total}} - M_{\text{os}} $$

Dengan menggunakan Cgroups untuk mendefinisikan $m_i$ secara ketat bagi setiap kontainer, saat terjadi kebocoran memori pada kontainer tertentu, kita dapat mencegah kontainer lain atau keseluruhan sistem host ikut mati akibat OOM (Out Of Memory) Killer.

3. Desain Dockerfile yang Efisien: Menguasai Build Multi-tahap (Multi-stage Build)

Langkah pertama menuju lingkungan yang dapat direproduksi adalah mendesain Dockerfile yang mendefinisikan lingkungan eksekusi aplikasi. Di sini, dengan mengambil Python (FastAPI) sebagai contoh, kita akan membahas praktik terbaik untuk Dockerfile yang aman dan ringan dengan memanfaatkan build multi-tahap.

Build multi-tahap adalah teknik yang memisahkan lingkungan build (lingkungan berat yang mencakup kompiler dan alat pengembangan) dari lingkungan eksekusi (lingkungan ringan yang hanya berisi hasil akhir yang diperlukan) dengan menggunakan beberapa perintah FROM di dalam sebuah Dockerfile tunggal.

Dockerfile Praktis untuk Python FastAPI

Kode berikut ini merupakan contoh Dockerfile tingkat lanjut yang menggabungkan pengelolaan dependensi menggunakan Poetry dengan build multi-tahap.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52


# ---------------------------------------------------------
# Stage 1: Builder (Lingkungan Build)
# ---------------------------------------------------------
FROM python:3.11-slim AS builder

# Pengaturan variabel lingkungan yang diperlukan
ENV PYTHONUNBUFFERED=1 \
 PYTHONDONTWRITEBYTECODE=1 \
 POETRY_VERSION=1.6.1 \
 POETRY_HOME="/opt/poetry" \
 POETRY_VIRTUALENVS_IN_PROJECT=true \
 POETRY_NO_INTERACTION=1

# Menginstal dependensi paket
RUN apt-get update && apt-get install -y --no-install-recommends \
 curl build-essential && \
 curl -sSL https://install.python-poetry.org | python3 - && \
 apt-get clean && rm -rf /var/lib/apt/lists/*

ENV PATH="$POETRY_HOME/bin:$PATH"

WORKDIR /app

# Menyalin dan menginstal file dependensi
COPY pyproject.toml poetry.lock ./
RUN poetry install --no-root --only main

# ---------------------------------------------------------
# Stage 2: Runtime (Lingkungan Eksekusi)
# ---------------------------------------------------------
FROM python:3.11-slim AS runtime

ENV PYTHONUNBUFFERED=1 \
 PYTHONDONTWRITEBYTECODE=1 \
 PATH="/app/.venv/bin:$PATH"

# Membuat pengguna dengan hak akses non-privelege minimum
RUN groupadd -r appuser && useradd -r -g appuser appuser

WORKDIR /app

# Hanya menyalin lingkungan virtual (dependensi) dari builder
COPY --from=builder --chown=appuser:appuser /app/.venv /app/.venv

# Menyalin kode aplikasi
COPY --chown=appuser:appuser ./src /app/src

# Beralih ke pengguna non-privilege
USER appuser

# Perintah default saat kontainer dijalankan
ENTRYPOINT ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "8000"]

Evaluasi Matematis Ukuran Citra karena Build Multi-tahap

Misalkan ukuran citra ketika di-build pada satu tahap adalah $S_{\text{single}}$, dan ukuran citra saat build multi-tahap diterapkan adalah $S_{\text{multi}}$. Tingkat pengurangan ukuran $R$ dapat dihitung sebagai berikut:

$$ R = \left( 1 - \frac{S_{\text{multi}}}{S_{\text{single}}} \right) \times 100 \ (\%) $$

Sebagai contoh, jika $S_{\text{single}}$ mencakup citra dasar OS (sekitar 110MB), paket pengembangan (gcc, dll. sekitar 150MB), Poetry itu sendiri (sekitar 40MB), pustaka dependensi proyek (sekitar 80MB), dan kode sumber (sekitar 5MB), sehingga total menjadi 385MB. Di sisi lain, pada $S_{\text{multi}}$, hanya pustaka dependensi (80MB) dan kode sumber (5MB) yang disalin ke citra dasar (110MB), sehingga totalnya menjadi 195MB.

$$ R = \left( 1 - \frac{195}{385} \right) \times 100 \approx 49.35\% $$

Dengan menerapkan build multi-tahap seperti ini, kita dapat mengurangi ukuran citra sekitar setengahnya. Pengurangan ukuran citra akan berdampak langsung pada pemendekan waktu pull dari registry, penghematan kapasitas disk, serta peningkatan keamanan dengan mengurangi area serangan (Attack Surface).

4. Orkestrasi Berbagai Kontainer Menggunakan Docker Compose

Dalam pengembangan aplikasi web modern, arsitektur layanan mikro yang menggabungkan banyak komponen seperti server Web, basis data, dan server cache adalah hal yang umum. Untuk mengelola semua ini secara terpusat di lingkungan lokal, kita menggunakan docker-compose.yml.

Kali ini, kita akan membangun sistem dengan struktur tiga lapisan di lingkungan lokal: “Web (FastAPI)”, “Basis Data (PostgreSQL)”, dan “Cache (Redis)”.

Diagram Arsitektur (Mermaid)

Diagram blok di bawah ini mengilustrasikan hubungan antara masing-masing kontainer, jaringan, dan volume pada mesin lokal.

graph TD
User["Mesin Host (Browser/curl)"] -->|Localhost:8000| Web["Kontainer Web FastAPI"]
subgraph "Jaringan Docker Bridge (app-network)"
Web -->|Port 5432| DB["Kontainer PostgreSQL"]
Web -->|Port 6379| Redis["Kontainer Redis"]
end
DB --> Volume1["Volume Bernama (postgres_data)"]
Redis --> Volume2["Volume Bernama (redis_data)"]
HostDir["Kode Sumber Host (./src)"] -.->|Bind Mount| Web

Implementasi dan Penjelasan Mendalam tentang docker-compose.yml

Berikut disajikan contoh docker-compose.yml yang kokoh, yang dapat diandalkan untuk membangun lingkungan yang nyata.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63


version: '3.8'

services:
 web:
 build:
 context: .
 target: runtime
 container_name: dev_web
 ports:
 - "8000:8000"
 volumes:
 - ./src:/app/src:ro  # Melakukan mount kode host sebagai read-only (untuk hot reload)
 environment:
 - DATABASE_URL=postgresql://postgres:${POSTGRES_PASSWORD}@db:5432/${POSTGRES_DB}
 - REDIS_URL=redis://redis:6379/0
 env_file:
 - .env
 depends_on:
 db:
 condition: service_healthy
 redis:
 condition: service_started
 networks:
 - app-network
 command: ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "8000", "--reload"]

 db:
 image: postgres:15-alpine
 container_name: dev_db
 ports:
 - "5432:5432"
 environment:
 POSTGRES_USER: postgres
 POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
 POSTGRES_DB: ${POSTGRES_DB}
 volumes:
 - postgres_data:/var/lib/postgresql/data
 networks:
 - app-network
 healthcheck:
 test: ["CMD-SHELL", "pg_isready -U postgres -d ${POSTGRES_DB}"]
 interval: 5s
 timeout: 5s
 retries: 5

 redis:
 image: redis:7-alpine
 container_name: dev_redis
 ports:
 - "6379:6379"
 volumes:
 - redis_data:/data
 networks:
 - app-network
 command: ["redis-server", "--appendonly", "yes"]

volumes:
 postgres_data:
 redis_data:

networks:
 app-network:
 driver: bridge

Volume (Volumes) dan Persistensi Data

Secara prinsip, kontainer bersifat “stateless (tanpa status)” dan “ephemeral (berumur pendek)”. Saat kontainer dihancurkan, data di dalamnya juga akan hilang. Untuk menyimpan data basis data atau cache, kita perlu melakukan mount ke area sistem file mesin host pada kontainer.

Bind Mount: Pada layanan web di atas, pengaturan ./src:/app/src:ro merupakan Bind Mount. Direktori spesifik di host dipetakan secara langsung ke dalam kontainer. Ini digunakan untuk langsung mencerminkan pengeditan kode lokal ke dalam kontainer (hot reload). Praktik terbaik dari perspektif keamanan adalah dengan memberikan opsi :ro (Read-Only) sehingga kontainer tidak dapat mengubah kode sumber pada host.
Volume Bernama (Named Volume): Contohnya adalah postgres_data dan redis_data. Ini adalah area yang dikelola secara internal oleh Docker (seperti /var/lib/docker/volumes/), memiliki performa I/O yang lebih baik daripada bind mount, dan dapat menyerap perbedaan sistem file di berbagai OS. Untuk memastikan keberlangsungan basis data, pastikan untuk menggunakan opsi ini.

Jaringan (Networking) dan Penemuan Layanan (Service Discovery)

Docker Compose secara default akan membuat jaringan bridge sendiri untuk tiap proyek. Inilah jaringan app-network pada contoh di atas. Kontainer-kontainer yang berada di jaringan yang sama dapat saling meresolusi nama (resolusi DNS) bukan dengan alamat IP, melainkan dengan nama layanannya (contoh: db, redis) sebagai nama host. Misalnya, dari kontainer Web, kita bisa mengakses basis data menggunakan URL postgresql://postgres:password@db:5432/mydb. Hal ini memungkinkan pergantian tujuan koneksi secara transparan dengan menggunakan variabel lingkungan, baik di lingkungan lokal maupun lingkungan produksi, tanpa perlu mengubah kode infrastruktur.

Pemeriksaan Kesehatan (Healthcheck) dan Kontrol Urutan Booting

Arahan depends_on memang mengontrol urutan pengaktifan kontainer, namun jika kita hanya menentukan depends_on, kontainer Web mungkin akan aktif saat “kontainer DB diaktifkan”. Padahal, proses inisialisasi basis data (seperti peluncuran proses PostgreSQL atau persiapan tabel) membutuhkan waktu beberapa detik, dan dapat menyebabkan koneksi dari kontainer Web menuju DB mengalami kegagalan/error. Untuk mencegah hal tersebut, kita mendefinisikan healthcheck, dan dengan menyetel condition: service_healthy, kita bisa menunda aktifnya kontainer Web sampai “DB terkonfirmasi berada dalam status siap menerima permintaan koneksi”.

5. Manajemen Variabel Lingkungan dan Keamanan (.env)

Memasukkan informasi rahasia ke dalam docker-compose.yml secara langsung, seperti kata sandi basis data maupun kunci API, adalah pola anti yang mutlak harus dihindari. Sebaliknya, gunakan file variabel lingkungan .env untuk menyuntikkan nilai-nilai tersebut.

Buat file .env di akar proyek (project root).

1
2
3
4


# file .env (Pastikan untuk menambahkannya ke .gitignore agar tidak dikelola oleh Git)
POSTGRES_PASSWORD=supersecretpassword
POSTGRES_DB=devdb
API_SECRET_KEY=dev_secret_key_12345

Docker Compose secara default akan membaca file .env yang berada di direktori eksekusi dan mengekspansi placeholder ${VAR_NAME} di dalam file YAML. Pendekatan ini memungkinkan pengelolaan yang aman dari nilai-nilai konfigurasi yang berbeda untuk berbagai lingkungan, seperti lokal, staging, dan lingkungan produksi, tanpa perlu memodifikasi kode infrastruktur.

6. Pengalaman Pengembangan Terbaik melalui VSCode DevContainers

Sampai di sini, kita telah sukses membangun ekosistem backend yang kokoh memakai Docker. Meski begitu, masih ada langkah ekstra yang bisa dilakukan. Dengan memanfaatkan fitur VSCode DevContainers (Remote - Containers), kita dapat menjalankan bagian backend dari editor (VSCode) secara langsung dari dalam kontainer.

Melalui hal ini, kita bahkan tidak perlu menginstal Python maupun Node.js ke mesin lokal. Seluruh komponen, mulai dari Linter (flake8/eslint), formatters (black/prettier), hingga ekstensi IDE, bisa didefinisikan ke dalam basis kode (codebase) dan dibagikan ke seluruh tim.

Konfigurasi devcontainer.json

Buatlah direktori bernama .devcontainer di akar proyek, lalu letakkan file konfigurasi di dalamnya.

.devcontainer/devcontainer.json:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


{
 "name": "Lingkungan Dev Python FastAPI",
 "dockerComposeFile": ["../docker-compose.yml"],
 "service": "web",
 "workspaceFolder": "/app",
 "customizations": {
 "vscode": {
 "settings": {
 "python.defaultInterpreterPath": "/app/.venv/bin/python",
 "python.formatting.provider": "black",
 "editor.formatOnSave": true
 },
 "extensions": [
 "ms-python.python",
 "ms-python.vscode-pylance",
 "ms-python.black-formatter",
 "tamasfe.even-better-toml"
 ]
 }
 },
 "forwardPorts": [8000, 5432, 6379],
 "remoteUser": "appuser",
 "postCreateCommand": "poetry install"
}

Dengan menyertakan file tersebut di repositori, begitu VSCode dipakai untuk membuka proyek, akan muncul dialog “Reopen in Container”. Cukup satu klik, seluruh kontainer yang diperlukan bakal aktif, ekstensi akan dipasang, dan kita siap memulai kegiatan koding secara instan. Ini benar-benar mirip sebuah sihir.

7. Pemodelan Performa dan Urutan Proses Permintaan (Request)

Kita akan menggunakan diagram urutan untuk meninjau siklus hidup pemrosesan permintaan (request) pada aplikasi Web dalam lingkungan pengembangan lokal yang telah dibuat, lalu kita telaah model matematik dari performanya.

Diagram Urutan (Alur Permintaan / Request Flow)

sequenceDiagram
participant Client as "Browser / VSCode"
participant Web as "FastAPI (Web)"
participant Redis as "Cache Redis"
participant DB as "PostgreSQL"
Client->>Web: "GET /api/users/123"
activate Web
Web->>Redis: "Cek Cache untuk user:123"
activate Redis
alt "Cache Hit (Data tersedia)"
Redis-->>Web: "Kembalikan Data User dari Cache"
Web-->>Client: "200 OK (Respons Cepat)"
else "Cache Miss (Data tidak tersedia)"
Redis-->>Web: "Null (Tidak Ditemukan)"
deactivate Redis
Web->>DB: "SELECT * FROM users WHERE id = 123"
activate DB
DB-->>Web: "Kembalikan Baris Database"
deactivate DB
Web->>Redis: "SET Data user:123 (TTL: 60s)"
activate Redis
Redis-->>Web: "OK"
deactivate Redis
Web-->>Client: "200 OK (Respons Standar)"
end
deactivate Web

Model Matematis untuk Penundaan Proses (Latensi)

Mari rumuskan model matematis dari waktu pemrosesan permintaan rerata $T_{\text{total}}$ dalam ekosistem ini. Waktu latensi untuk setiap bagian didefinisikan sebagai berikut:

$T_{\text{net}}$: Latensi jaringan di antara klien dengan kontainer Web
$T_{\text{app}}$: Waktu proses esensial (pure) di bagian aplikasi (serialisasi dll.)
$T_{\text{cache}}$: Waktu baca-tulis dari dan ke Redis
$T_{\text{db}}$: Waktu pengeksekusian kueri menuju PostgreSQL
$p_{\text{miss}}$: Persentase kegagalan cache (Cache miss rate) ($0 \le p_{\text{miss}} \le 1$)

Dengan begitu, nilai harapan untuk waktu respon rerata bisa dirumuskan menjadi:

$$ T_{\text{total}} = T_{\text{net}} + T_{\text{app}} + T_{\text{cache}} + p_{\text{miss}} \times (T_{\text{db}} + T_{\text{cache\_write}}) $$

Untuk lingkungan pengembangan lokal (di dalam Docker), $T_{\text{net}}$ nilainya akan nyaris 0. Namun, ada aspek yang butuh perhatian serius: performa I/O saat melakukan Bind Mount. Pada Docker Desktop versi Windows atau macOS, waktu tunda (overhead) akibat aktivitas berbagi file antara host OS dan mesin virtual (kontainer) berisiko membengkakkan $T_{\text{app}}$ (waktu bacaan kode dll.). Sebagai solusi atas masalah ini, kami sangat merekomendasikan pemakaian DevContainers seperti dibahas di atas agar seluruh kode sumber ditampung pada named volume, atau memosisikan Docker Engine supaya berjalan secara asli pada sistem WSL2 (Windows Subsystem for Linux 2).

8. Mengoptimalkan Kinerja Build Docker: Strategi Lapisan Cache (Layer Cache)

Saat menulis Dockerfile, durasi penyusunan (build time) bisa berubah secara drastis apabila kita memahami cara kerja sistem “layer cache”. Untuk tiap baris instruksi yang ada di Dockerfile (contoh: FROM, RUN, COPY), Docker akan membuat sistem file pembanding (lapisan/layer), kemudian mempertahankannya sebagai cache. Ketika dilakukan penyusunan ulang, ia akan memakai kembali layer dari cache yang tiada perubahan.

Prinsip pentingnya: “Tuliskan berurutan mulai dari yang paling jarang mengalami perubahan”.

Mari modelkan dampak perubahan kode sumber terhadap waktu build. Waktu build keseluruhan adalah $T_{\text{build}}$, lama eksekusi tiap tahapan $T_{\text{layer}_i}$, dan probabilitas tersedianya cache sebagai variabel boolean $c_i \in \{0, 1\}$ (bernilai 1 jika cache ditemukan).

$$ T_{\text{build}} = T_{\text{init}} + \sum_{i=1}^{n} (1 - c_i) \times T_{\text{layer}_i} $$

Sekali saja terjadi gagal memanggil cache di lapisan tertentu $k$ ($c_k = 0$), cache di setiap lapisan berikutnya ($j > k$) akan otomatis tak beroperasi ($c_j = 0$).

1
2
3
4


# Praktik Buruk (Mendahulukan penyalinan source code)
COPY ./src /app/src
COPY pyproject.toml poetry.lock ./
RUN poetry install

Dengan posisi seperti ini, mengubah satu kalimat di kode sumber akan membuat COPY awal gagal mengakses cache, sehingga RUN poetry install yang memakan waktu akan terus-terusan dieksekusi.

1
2
3
4


# Praktik Terbaik (Menyelesaikan pengaturan dependensi terlebih dulu)
COPY pyproject.toml poetry.lock ./
RUN poetry install
COPY ./src /app/src

Apabila disusun begini, kendati kode sumbernya diubah, cache layer untuk proses instalasi dependensi (poetry install) akan teraplikasikan ($c_i = 1$). Pada akhirnya, proses penyusunan (build) bisa dipersingkat sedemikian jauh; dari hitungan menit berubah jadi sekadar beberapa detik saja.

9. Penyelesaian Masalah dan Tips

Berikut daftar masalah dan solusi yang lazim ditemukan sewaktu menjalankan ekosistem lokal.

Error bentrok port (Port conflict error) Jika terjadi pesan error layaknya Bind for 0.0.0.0:8000 failed: port is already allocated, kemungkinan besar port tersebut sedang dipakai di mesin lokal. Solusi ringkasnya adalah mengganti angka pada port host, dengan menjadikannya ports: - "8080:8000".
Kapasitas disk habis Pemakaian Docker dalam kurun waktu lama tanpa dirawat bisa membuat berbagai volume dan citra yang tidak penting lagi (Dangling Images/Volumes) kian menumpuk. Disk bahkan bisa termakan sampai belasan GB. Cobalah sering-sering mengeksekusi ini guna menata ulang sistem:
1

docker system prune -a --volumes
Problem hak akses file (Permission issues) Apabila kamu menerapkan Bind Mount pada Linux, user pemilik file yang digenerate di dalam kontainer akan ditetapkan sebagai root, yang membuat sang file kadang tak dapat dimodifikasi di pihak host. Langkah penanganannya, yaitu bikinlah profil pengguna non-privilege di Dockerfile, lantas serasikan UID/GID dengan profil kamu sendiri yang ada di OS (contoh: 1000:1000).

10. Penutup: Peran Penjaminan Keberulangan demi Efisiensi Perkembangan Proyek

Pemaduan Docker, Docker Compose, serta VSCode DevContainers berhasil menciptakan ruang kerja lokal tangguh dan kebal masalah, sebuah metode sempurna yang membuat “siapa pun yang merilis lingkungan, kondisinya akan tetap sama dengan sebelumnya”.

Hadirnya pendekatan IaC (Infrastructure as Code) di ekosistem pengembangan tidak melulu demi mempersingkat langkah-langkah pengaturan pada tahap pertama. Konsep ini justru berfungsi sebagai tameng yang menghapus kecemasan terhadap resiko yang menyertai tiap perubahan setup, membuat eksplorasi teknologi baru bertambah gampang, memfasilitasi peralihan secara mulus ke proses CI/CD, dan secara menakjubkan mendongkrak laju sekaligus standar siklus proyek.

Praktikkan segala panduan mengenai penyederhanaan kapasitas citra dengan build multi-tahap, pengelolaan status via healthcheck, ataupun pemanfaatan cache di Dockerfile yang semuanya sudah terjabarkan di dalam esai ini. Cobalah secepatnya untuk menciptakan pengalaman pengembangan (DX: Developer Experience) bermutu tinggi bagi karya-karyamu.

Panduan Pengaturan Lingkungan Pengembangan Ultimate untuk WSL2 (Windows Subsystem for Linux)

Sat, 12 Sep 2026 23:00:00 +0900

“WSL2 (Windows Subsystem for Linux 2)”, yang menyediakan lingkungan pengembangan native Linux di Windows, telah menjadi alat yang sangat penting dalam pengembangan perangkat lunak modern. Namun, ada perbedaan besar dalam kinerja dan pengalaman pengembangan antara menggunakannya dalam status default dan memahaminya serta menyesuaikan arsitekturnya dengan tepat.

Artikel ini membahas segala hal mulai dari penjelasan arsitektur yang menjadi inti dari WSL2, hingga pengaturan untuk memaksimalkan kinerja, membangun lingkungan terminal yang nyaman, integrasi mulus dengan Docker dan VS Code, dan pengaturan jaringan lanjutan. Kami akan menjelaskan secara menyeluruh semua langkah untuk membangun “Lingkungan Pengembangan Ultimate” yang dibutuhkan oleh insinyur profesional dalam volume lebih dari 10.000 karakter.

1. Arsitektur WSL2 dan Evolusi dari WSL1

Untuk sepenuhnya memaksimalkan potensi WSL2, penting untuk memahami terlebih dahulu struktur internalnya. Pendekatan untuk menjalankan binari Linux di Windows sangat berbeda antara WSL generasi pertama (WSL1) dan WSL2.

WSL1: Lapisan Konversi Panggilan Sistem

WSL1 mengadopsi mekanisme untuk mengonversi (menerjemahkan) panggilan sistem Linux ke API NT Windows secara real time. Ini memiliki keuntungan berupa overhead sumber daya yang sangat kecil karena tidak menggunakan mesin virtual (VM). Namun, sulit untuk sepenuhnya meniru panggilan sistem yang kompleks seperti operasi I/O sistem file, dan menyebabkan penurunan kinerja yang drastis, terutama pada proses yang menangani sejumlah besar file kecil, seperti npm install pada Node.js atau operasi repositori Git.

WSL2: VM Utilitas Ringan dan Kernel Linux Penuh

Pada WSL2, arsitekturnya telah diperbarui, dan kernel Linux asli yang dibangun oleh Microsoft berjalan secara langsung di atas “VM Utilitas Ringan” yang menggunakan subset dari arsitektur Hyper-V. Ini menjamin kompatibilitas 100% untuk panggilan sistem dan secara dramatis meningkatkan kinerja I/O file dibandingkan dengan WSL1 dengan menggunakan disk virtual (VHDX) yang memanfaatkan sistem file ext4 native Linux.

Diagram Mermaid di bawah ini menunjukkan perbedaan struktural antara WSL1 dan WSL2.

flowchart TD
subgraph "Lingkungan OS Windows"
A["Kernel NT Windows"]
A --> F["Sistem File NTFS (Drive C:)"]
end
subgraph "Arsitektur WSL2"
B["Hypervisor Hyper-V"]
B --> C["VM Utilitas Ringan"]
C --> D["Kernel Linux (Microsoft)"]
D --> E["Ruang Pengguna Ubuntu (glibc, bash, dll.)"]
D --> G["Disk Virtual ext4 (.vhdx)"]
end
A -.->|"Berbagi File Jaringan Protokol Plan 9 (9P)"| D
style B fill:#f9f,stroke:#333,stroke-width:2px
style D fill:#bbf,stroke:#333,stroke-width:2px

Pelajaran penting yang dapat diambil dari struktur ini adalah “Akses ke file di sisi Linux (di dalam VHDX) sangat cepat, namun akses ke file di sisi Windows (/mnt/c/) sangat lambat karena harus melalui protokol 9P”. Kode sumber proyek harus selalu ditempatkan di bawah direktori home (~) pada sisi WSL.

2. Analisis Matematika Kinerja: Mengapa WSL2 Cepat?

Mari kita evaluasi peningkatan kinerja WSL2 secara kuantitatif menggunakan model matematika. Salah satu operasi yang paling memakan waktu dalam pengembangan perangkat lunak adalah proses yang melibatkan sejumlah besar I/O file (misalnya, menginstal pustaka atau mem-build).

Total waktu eksekusi $T_{total}$ untuk suatu proses dinyatakan sebagai jumlah waktu komputasi oleh CPU $T_{compute}$ dan waktu yang dibutuhkan untuk disk I/O $T_{io}$.

$$ T_{total} = T_{compute} + T_{io} $$

Dalam kasus WSL1, karena ada overhead untuk mengonversi operasi sisi Linux ke operasi NTFS, waktu I/O dimodelkan sebagai berikut. Di sini, $n$ adalah jumlah operasi file, $t_{ntfs\_syscall}$ adalah waktu eksekusi panggilan sistem sisi Windows, dan $t_{trans}$ adalah overhead dari lapisan konversi.

$$ T_{wsl1\_io} = \sum_{i=1}^{n} (t_{ntfs\_syscall_i} + t_{trans_i}) $$

Di sisi lain, pada kasus WSL2, karena kernel mengeluarkan I/O secara langsung ke sistem file ext4, overheadnya hanya berupa penundaan yang sangat kecil $t_{virt}$ akibat virtualisasi.

$$ T_{wsl2\_io} = \sum_{i=1}^{n} (t_{ext4_i} + t_{virt_i}) $$

Pada sistem file umum, karena $t_{ext4} \ll t_{ntfs\_syscall} + t_{trans}$, jika $n$ sangat besar (melakukan puluhan hingga ratusan ribu operasi file), perbedaan waktu I/O antara WSL1 dan WSL2 akan melebar secara eksponensial.

Selain itu, jika rasio overhead komputasi CPU di lingkungan virtualisasi adalah $\rho$, dengan virtualisasi berbantuan perangkat keras terbaru (Intel VT-x / AMD-V), rasio tersebut akan berada pada kisaran $\rho \approx 0.01 \sim 0.03$ (1 hingga 3%). Oleh karena itu, bahkan pada tugas komputasi murni, ia akan memberikan kinerja sebesar $97\% \sim 99\%$ yang sebanding dengan lingkungan native Linux.

3. Instalasi dan Pembangunan Fondasi

Pada Windows 10/11, instalasi WSL2 telah menjadi sangat sederhana. Cukup buka PowerShell dengan hak administrator dan jalankan perintah berikut.

1
2
3
4
5
6


# WSL2 dan Ubuntu akan diinstal secara default
wsl --install

# Jika Anda ingin menentukan distribusi tertentu
# Dapat diperiksa dengan wsl --list --online
wsl --install -d Ubuntu-24.04

Setelah penginstalan dan melalui proses restart, Anda akan diminta untuk mengatur nama pengguna dan kata sandi UNIX saat pertama kali dijalankan. Pengguna ini terpisah dari pengguna Windows dan hanya valid di dalam WSL.

Jika Anda sudah menggunakan WSL1, konversikan ke WSL2 dengan perintah berikut.

1
2
3
4
5


# Mengonversi distribusi yang ada ke WSL2
wsl --set-version Ubuntu 2

# Menjadikan WSL2 sebagai versi default untuk distribusi yang akan ditambahkan di masa mendatang
wsl --set-default-version 2

4. Rahasia Kontrol Sumber Daya: .wslconfig dan wsl.conf

Salah satu jebakan terbesar di WSL2 adalah “konsumsi memori tak terbatas (pembengkakan proses Vmmem)”. Karena WSL2 menggunakan cache halaman dari kernel Linux, setiap kali I/O dilakukan, ia akan memakan memori host (Windows) tanpa batas. Untuk mencegah hal ini, perlu dilakukan pembatasan sumber daya melalui file konfigurasi.

File konfigurasi WSL2 dibagi menjadi dua: .wslconfig yang memengaruhi Windows secara keseluruhan, dan wsl.conf yang memengaruhi internal setiap distribusi.

4.1. .wslconfig (Sisi Windows)

Buat file di direktori profil pengguna Windows (C:\Users\<Nama Pengguna>\.wslconfig) untuk mengontrol alokasi sumber daya ke VM.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


# C:\Users\<Nama Pengguna>\.wslconfig
[wsl2]
# Jumlah memori maksimum yang dialokasikan untuk VM. Disarankan sekitar 50% hingga 75% dari total memori host
memory=16GB

# Jumlah core CPU yang digunakan (Jika dihilangkan, semua core akan digunakan)
processors=8

# Ukuran file swap
swap=8GB

# Lokasi penyimpanan file swap (Jika ingin menghemat ruang di drive C)
# swapfile=D:\\wsl\\swap.vhdx

# Aktifkan penerusan localhost (Untuk mengakses WSL melalui localhost dari sisi Windows)
localhostForwarding=true

# Secara otomatis melepaskan memori (Hanya Windows 11)
# Secara dinamis melepaskan cache halaman untuk mencegah pembengkakan Vmmem
autoMemoryReclaim=dropcache

[experimental]
# Fitur jaringan lanjutan tersedia pada Windows 11 22H2 dan lebih baru
# Hal ini memungkinkan dukungan IPv6 dan berbagi alamat IP yang sama antara WSL dan Windows
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=true

4.2. wsl.conf (Sisi Linux)

Edit /etc/wsl.conf di dalam WSL untuk mengontrol perilaku khusus distribusi.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


# /etc/wsl.conf (Diedit di dalam WSL)
[network]
# Nonaktifkan pembuatan /etc/resolv.conf yang dibuat secara otomatis saat WSL dijalankan
# Berguna jika Anda ingin mengatur DNS kustom (misalnya: 8.8.8.8)
generateResolvConf=false

# Atur nama host kustom
hostname=WSL-DevNode

[automount]
# Pengaturan saat memasang drive Windows
enabled=true
options="metadata,uid=1000,gid=1000,umask=022"
# Ubah titik pemasangan (mount point) drive C dari /mnt/c ke /c (untuk mempersingkat jalur)
root=/

[boot]
# Aktifkan systemd (WSL 0.67.6 atau lebih baru)
# Ini memungkinkan snap dan berbagai daemon (seperti Docker) untuk berjalan secara native
systemd=true

[user]
# Pengguna default untuk login
default=kenji

Untuk menerapkan pengaturan ini, Anda perlu menjalankan wsl --shutdown di PowerShell untuk menghentikan sepenuhnya VM WSL sebelum menghidupkannya kembali.

5. Lingkungan Terminal Ultimate: Zsh + Powerlevel10k

Produktivitas tidak akan meningkat jika Anda tetap menggunakan bash bawaan. Kami akan membangun prompt terkuat dengan menggabungkan Zsh, yang menawarkan fitur pelengkapan otomatis dan visibilitas yang kuat, dengan tema super cepat “Powerlevel10k”.

5.1. Pengenalan dan Pengaturan Windows Terminal

Instal “Windows Terminal” dari Microsoft Store. Buka pengaturan JSON (settings.json), tetapkan profil default ke WSL (Ubuntu), dan ubah font menjadi Nerd Font untuk pengembangan (misalnya: HackGen Console NF atau MesloLGS NF).

5.2. Menginstal Zsh dan Oh My Zsh

Jalankan perintah berikut di terminal WSL.

1
2
3
4
5
6


# Memperbarui paket dan menginstal Zsh
sudo apt update && sudo apt upgrade -y
sudo apt install -y zsh git curl

# Menjalankan skrip instalasi Oh My Zsh
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

5.3. Menginstal Powerlevel10k dan Plugin

Kami akan memperkenalkan plugin (penyorotan sintaksis dan pelengkapan otomatis input) untuk lebih meningkatkan Zsh, serta tema Powerlevel10k.

1
2
3
4
5
6
7
8


# Powerlevel10k
git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k

# zsh-autosuggestions
git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions

# zsh-syntax-highlighting
git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting

Edit ~/.zshrc untuk mengaktifkan tema dan plugin.

1
2
3
4
5


# Perubahan pada ~/.zshrc
ZSH_THEME="powerlevel10k/powerlevel10k"

# Tambahkan ke array plugin
plugins=(git zsh-autosuggestions zsh-syntax-highlighting)

Simpan dan jalankan source ~/.zshrc, panduan konfigurasi Powerlevel10k (p10k configure) akan dimulai. Ikuti petunjuk di layar untuk menyesuaikan prompt Anda sendiri (gaya prompt, ada/tidaknya ikon, informasi yang ditampilkan, dll.). Nama cabang dan status Git, versi Node.js, waktu eksekusi perintah, dll. akan ditampilkan secara real-time, sehingga secara dramatis meningkatkan efisiensi pengembangan Anda.

6. VS Code Remote - Integrasi Mulus dengan WSL

Dalam pengembangan menggunakan WSL2, ekstensi “Remote - WSL” adalah mekanisme yang memungkinkan akses mulus ke file di dalam WSL dari IDE (Visual Studio Code) yang diinstal pada sisi Windows.

Penjelasan Arsitektur

Diagram urutan di bawah ini menunjukkan bagaimana VS Code berkomunikasi dengan WSL2.

sequenceDiagram
autonumber
participant U as "Pengembang"
participant V as "UI VS Code (Windows)"
participant S as "Server VS Code (WSL2)"
participant F as "Sistem File ext4 (WSL2)"
U->>V: "Ketik `code .` di Terminal WSL"
V->>S: "Membangun Koneksi RPC melalui Vsock"
Note over V,S: Berkomunikasi menggunakan Hyper-V socket alih-alih TCP/IP
S->>F: "Membaca File Sumber / Menjalankan Linter"
F-->>S: "Mengembalikan Data & Analisis"
S-->>V: "Mengalirkan hasil Language Server ke UI"
V-->>U: "Menampilkan penyorotan sintaksis & kesalahan"

VS Code di sisi Windows hanya berfungsi sebagai “klien tipis (UI)”, dan semua tugas berat seperti Language Server, debugger, dan eksekusi terminal diproses oleh “VS Code Server” di sisi WSL. Hal ini memungkinkan lingkungan yang bersih hanya di sisi WSL tanpa perlu menginstal Node.js atau Python di sisi Windows.

Pengaturan VS Code yang Wajib

Instal “WSL” (ms-vscode-remote.remote-wsl) dari “Extensions” di VS Code. Setelah itu, cukup pindah ke direktori proyek di terminal WSL dan jalankan code ., dan VS Code di sisi Windows akan diluncurkan dengan direktori tersebut terbuka.

Poin Penting (Masalah Kode Baris Baru): Kode baris baru berbeda antara Windows dan Linux (Windows menggunakan CRLF, Linux menggunakan LF). Saat mengembangkan di WSL, pastikan untuk mengatur pengaturan core.autocrlf Git dan pengaturan default file VS Code ke LF. Jika Anda mengabaikan hal ini, Anda akan diganggu oleh kesalahan misterius saat menjalankan skrip shell atau kontainer Docker.

1
2


# Pengaturan kode baris baru Git di sisi WSL
git config --global core.autocrlf input

Tambahkan juga hal berikut ini ke settings.json (pengaturan remote) di VS Code.

1
2
3
4


{
 "files.eol": "\n",
 "terminal.integrated.defaultProfile.linux": "zsh"
}

7. Optimasi Docker Desktop dan Integrasi WSL2

Ada dua pendekatan utama untuk menggunakan Docker di lingkungan WSL2.

Menginstal Docker Desktop for Windows dan mengaktifkan fitur integrasi WSL2.
Menginstal langsung Docker Engine Native di dalam WSL2 (seperti Ubuntu).

Pendekatan 1: Docker Desktop (Direkomendasikan)

Ini sering kali direkomendasikan karena mudah dikelola dengan GUI dan akses transparan ke kontainer antara Windows dan WSL. Periksa hal-hal berikut dari Pengaturan (Settings) Docker Desktop.

Centang General -> Use the WSL 2 based engine.
Centang Resources -> WSL Integration -> Enable integration with my default WSL distro dan nyalakan tombol geser untuk distribusi (Ubuntu) yang Anda gunakan.

Ini memungkinkan Anda menjalankan perintah docker langsung dari terminal WSL2, dan komunikasi dengan daemon Docker akan dialihkan melalui VM ringan khusus (docker-desktop dan docker-desktop-data) yang dikelola oleh Docker Desktop.

Pendekatan 2: Pengenalan Langsung Docker Engine Native

Jika Anda memiliki batasan jaringan perusahaan (seperti menghindari versi berbayar Docker Desktop) atau ingin mengurangi overhead kinerja hingga batas ekstrem, aktifkan systemd di /etc/wsl.conf lalu instal Docker sebagai server Ubuntu murni.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# Kutipan dari prosedur instalasi resmi Docker di WSL2 Ubuntu dengan systemd diaktifkan
sudo apt-get update
sudo apt-get install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Menambahkan repositori
echo \
 "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
 "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
 sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Menambahkan pengguna saat ini ke grup docker (untuk menjalankan tanpa sudo)
sudo usermod -aG docker $USER

Setelah restart, systemctl start docker akan berfungsi persis seperti di lingkungan Linux native dan menawarkan kinerja yang tinggi.

8. Integrasi Kunci SSH: Otentikasi Mulus di Windows dan WSL

Saat melakukan kloning SSH dari Git atau koneksi SSH ke server jarak jauh, mengelola kunci SSH secara terpisah di sisi Windows dan sisi WSL sangatlah merepotkan. Untuk menyeimbangkan antara keamanan dan kenyamanan, kami akan mengonfigurasi jembatan untuk menghubungkan agen SSH (atau manajer kata sandi seperti 1Password) yang berjalan di Windows ke sisi WSL.

Di sini, kita akan membahas pendekatan yang paling aman dan modern, yaitu menggunakan fitur agen SSH 1Password atau OpenSSH Authentication Agent dari Windows dan meneruskannya ke soket domain UNIX WSL2 menggunakan npiperelay atau socat.

Penerusan Soket ssh-agent

Biasanya, agen SSH yang disediakan sebagai Named Pipe (pipa bernama) di Windows perlu dikonversi ke file soket di sisi WSL. Anda dapat menggunakan wsl-ssh-agent atau fitur yang disediakan oleh 1Password untuk membuatnya lebih mudah.

Di layar pengaturan 1Password, aktifkan “Developer” -> “Gunakan Agen SSH”. Selanjutnya, tambahkan pengaturan berikut ke ~/.zshrc atau ~/.bashrc di sisi WSL untuk mengikat soket secara otomatis saat login.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Menambahkan ke ~/.zshrc (Contoh jika menggunakan Agen SSH 1Password)
export SSH_AUTH_SOCK=$HOME/.ssh/agent.sock
# Jika soket tidak ada atau proses tidak terikat saat WSL dijalankan, teruskan menggunakan socat dan npiperelay
ALREADY_RUNNING=$(ps -aux | grep "[n]piperelay.exe -ei -s //./pipe/openssh-ssh-agent" | wc -l)
if [ $ALREADY_RUNNING -eq 0 ]; then
 if [ -S $SSH_AUTH_SOCK ]; then
 rm $SSH_AUTH_SOCK
 fi
 # Memulai socat di latar belakang dan menghubungkan Named Pipe di sisi Windows ke soket UNIX di sisi WSL
 (setsid socat UNIX-LISTEN:$SSH_AUTH_SOCK,fork EXEC:"npiperelay.exe -ei -s //./pipe/openssh-ssh-agent",nofork &) >/dev/null 2>&1
fi

*Anda harus menginstal npiperelay.exe dan menambahkannya ke path di sisi Windows terlebih dahulu.

Setelah pengaturan ini selesai, ketika Anda menjalankan ssh-add -l dari terminal WSL, daftar kunci publik dari kunci SSH yang terdaftar di 1Password atau di sisi Windows akan ditampilkan. Dengan demikian, Anda dapat lolos otentikasi dengan aman tanpa harus menyalin file kunci privat ke dalam WSL.

9. Pemeliharaan: Optimasi (Kompaksi) VHDX yang Membengkak

Salah satu kelemahan terbesar WSL2 adalah bahwa “ukuran file dari disk virtual di sisi Windows (.vhdx) tidak menyusut secara otomatis bahkan jika Anda menghapus image Docker atau menghapus file”. Jika Anda terus mengembangkan untuk jangka waktu yang lama, file ext4.vhdx dapat membengkak hingga puluhan atau ratusan GB.

Untuk mengosongkan ruang disk, Anda perlu mengoptimalkan (Compact) VHDX dari sisi Windows secara berkala.

Pertama, matikan WSL sepenuhnya.
1

wsl --shutdown
Buka PowerShell dengan hak administrator, dan jalankan perintah diskpart di bawah ini, atau perintah Optimize-VHD dari modul Hyper-V (yang terakhir hanya dapat digunakan jika Hyper-V diaktifkan).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Jika modul Hyper-V tersedia
Optimize-VHD -Path "$env:LOCALAPPDATA\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx" -Mode Full

# Jika menggunakan diskpart
diskpart
# Masukkan secara interaktif dalam prompt di bawah ini
DISKPART> select vdisk file="C:\Users\<Nama Pengguna>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx"
DISKPART> attach vdisk readonly
DISKPART> compact vdisk
DISKPART> detach vdisk
DISKPART> exit

Dengan melakukan operasi ini secara berkala, Anda bisa memulihkan ruang kosong di drive C yang terbuang percuma.

10. Penutup

WSL2 telah sepenuhnya melampaui batasan sebagai “sekadar bonus Linux yang berjalan di Windows”, dan telah berevolusi menjadi platform pengembangan yang kuat yang tidak kalah, atau bahkan lebih baik dari mesin macOS atau mesin Linux native.

Dengan menerapkan semua pengaturan yang dijelaskan dalam artikel ini (optimasi sumber daya dengan .wslconfig, peningkatan terminal dengan Zsh + Powerlevel10k, akses transparan dengan VS Code Remote, serta integrasi SSH dan pemeliharaan VHDX), Anda akan dapat melengkapi “Lingkungan Pengembangan Ultimate” yang bebas stres, cepat, dan aman.

Meskipun membutuhkan sedikit upaya untuk menyiapkan lingkungan tersebut, begitu Anda menetapkan pengaturannya, produktivitas rekayasa perangkat lunak Anda akan meningkat secara dramatis di masa mendatang. Kami harap Anda mengeksplorasi penyesuaian lebih lanjut berdasarkan panduan ini sesuai dengan proyek dan preferensi Anda.