devbox.id

Developer tools, self-hosted dev environments, productivity for solo engineers

VSCode Remote Development Container: Dev Environment Beres

by Marcus Chen
VSCode Remote Development Container: Dev Environment Beres

Berapa kali kamu dengar kalimat "di komputerku jalan kok"? Kalau kamu solo engineer yang sering ganti mesin — laptop baru, VPS baru, atau onboarding kolaborator sesekali — kalimat itu bukan lelucon, itu mimpi buruk.

Solusinya bukan dokumentasi README yang makin panjang. Solusinya adalah vscode remote development container: environment dev yang hidup di dalam Docker container, diakses langsung dari VSCode seolah kamu kerja lokal. Semua dependency, extension, bahkan setting terminal — terkunci di dalam container itu.

Artikel ini bukan overview marketing. Aku tulis berdasarkan setup yang aku pakai sendiri untuk proyek-proyek backend Go dan Python. Kamu akan dapat konfigurasi konkret, bukan konsep abstrak.

Apa Sebenarnya VSCode Remote Development Container Itu?

Dev Containers (nama resminya sekarang) adalah fitur dari ekstensi Dev Containers — dulu namanya "Remote - Containers". Cara kerjanya sederhana:

  1. Kamu punya file .devcontainer/devcontainer.json di root project.
  2. VSCode baca file itu, build atau pull Docker image yang kamu tentukan.
  3. VSCode attach ke container itu. File system host di-mount ke dalam container.
  4. Semua proses — terminal, language server, linter, debugger — jalan di dalam container.

Dari sisi kamu sebagai developer, rasanya sama persis seperti kerja lokal. Tapi environment-nya terisolasi dan reproducible.

Satu hal yang sering disalahpahami: ini bukan tentang deploy. Container ini murni untuk development. Production image kamu tetap terpisah.

Kenapa Ini Penting untuk Solo Engineer

Kalau kamu tim besar, ada DevOps yang urus environment. Kalau kamu solo, kamu sendiri yang harus pastikan:

  • Laptop lama rusak → laptop baru bisa langsung produktif dalam 30 menit
  • Ganti OS (misalnya pindah dari macOS ke Linux) → tidak ada yang break
  • Kontributor sesekali bisa langsung clone dan jalan tanpa setup manual

Aku pernah habis hampir 4 jam setup environment Python di MacBook M1 baru gara-gara konflik antara Homebrew, pyenv, dan native ARM binary. Setelah pakai dev container, setup di mesin baru cuma: install Docker, install VSCode, clone repo, buka di container. Selesai.

Ada trade-off: performa I/O file di macOS bisa lebih lambat karena bind mount. Tapi untuk kebanyakan proyek backend, perbedaannya tidak signifikan.

Struktur File yang Kamu Butuhkan

Minimal kamu butuh dua file:

.devcontainer/
  devcontainer.json
  Dockerfile          ← opsional, kalau mau custom image

devcontainer.json Minimal (Pakai Pre-built Image)

Ini contoh untuk proyek Python:

{
  "name": "Python Dev",
  "image": "mcr.microsoft.com/devcontainers/python:3.12-bullseye",
  "features": {
    "ghcr.io/devcontainers/features/git:1": {}
  },
  "customizations": {
    "vscode": {
      "extensions": [
        "ms-python.python",
        "ms-python.black-formatter",
        "charliermarsh.ruff"
      ],
      "settings": {
        "python.defaultInterpreterPath": "/usr/local/bin/python",
        "editor.formatOnSave": true,
        "[python]": {
          "editor.defaultFormatter": "ms-python.black-formatter"
        }
      }
    }
  },
  "postCreateCommand": "pip install -r requirements.txt",
  "remoteUser": "vscode"
}

Perhatikan postCreateCommand — ini jalan sekali setelah container dibuat. Cocok untuk install dependency.

devcontainer.json dengan Docker Compose

Kalau project kamu butuh database atau service lain, pakai Docker Compose:

{
  "name": "Go + Postgres",
  "dockerComposeFile": "../docker-compose.dev.yml",
  "service": "app",
  "workspaceFolder": "/workspace",
  "customizations": {
    "vscode": {
      "extensions": [
        "golang.go",
        "mtxr.sqltools",
        "mtxr.sqltools-driver-pg"
      ]
    }
  },
  "postCreateCommand": "go mod download",
  "remoteUser": "vscode"
}

Dan docker-compose.dev.yml-nya:

version: '3.8'
services:
  app:
    build:
      context: .
      dockerfile: .devcontainer/Dockerfile
    volumes:
      - ..:/workspace:cached
    command: sleep infinity
    environment:
      - DATABASE_URL=postgres://dev:dev@db:5432/devdb
    depends_on:
      - db

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: dev
      POSTGRES_PASSWORD: dev
      POSTGRES_DB: devdb
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  postgres_data:

Dengan setup ini, kamu buka VSCode, container app dan Postgres langsung jalan bersamaan. Tidak perlu buka terminal terpisah untuk start database.

Dockerfile Custom: Kapan Perlu, Kapan Tidak

Pre-built image dari Microsoft (mcr.microsoft.com/devcontainers/) sudah cukup untuk banyak kasus. Tapi kamu perlu Dockerfile custom kalau:

  • Butuh versi tool yang sangat spesifik
  • Ada system dependency yang tidak ada di pre-built image
  • Mau minimize ukuran image

Contoh Dockerfile untuk Go dengan air (live reload):

FROM mcr.microsoft.com/devcontainers/go:1.22-bullseye

# Install air untuk live reload
RUN go install github.com/cosmtrek/air@v1.49.0

# Install migrate untuk database migration
RUN go install -tags 'postgres' github.com/golang-migrate/migrate/v4/cmd/migrate@v4.17.0

# Install tools lain
RUN apt-get update && apt-get install -y \
    postgresql-client \
    && rm -rf /var/lib/apt/lists/*

Pakai versi eksplisit (@v1.49.0, bukan @latest). Ini penting supaya build reproducible — enam bulan lagi kamu rebuild container, hasilnya sama.

Features: Cara Modular Tambah Tool

Salah satu fitur yang underrated dari Dev Containers adalah features. Ini semacam plugin untuk container kamu — bisa tambah tool tanpa harus tulis Dockerfile dari nol.

"features": {
  "ghcr.io/devcontainers/features/node:1": {
    "version": "20"
  },
  "ghcr.io/devcontainers/features/docker-in-docker:2": {},
  "ghcr.io/devcontainers/features/github-cli:1": {}
}

Dengan tiga baris itu kamu dapat Node.js 20, Docker-in-Docker (untuk build image dari dalam container), dan GitHub CLI — tanpa sentuh Dockerfile.

Katalog lengkap features ada di containers.dev/features. Aku biasanya cek sini dulu sebelum nulis Dockerfile custom.

Perbandingan: Dev Container vs Alternatif Lain

Pendekatan Reproducible Isolasi Setup Awal Performa
Dev Container (VSCode) ✅ Tinggi ✅ Per-project Sedang ⚠️ macOS lebih lambat
Nix + direnv ✅ Tinggi ✅ Per-project Tinggi ✅ Native
Vagrant ✅ Tinggi ✅ Full VM Tinggi ❌ Lebih berat
Manual + dotfiles ❌ Rendah ❌ Global Rendah ✅ Native
GitHub Codespaces ✅ Tinggi ✅ Per-project Rendah ✅ (cloud)

Dev Container menang di sweet spot: reproducible, tidak terlalu sulit setup, dan kamu tetap di environment lokal. Nix lebih powerful tapi kurva belajarnya curam. Vagrant sudah terasa dated di 2024. GitHub Codespaces pakai format yang sama (devcontainer.json) tapi kamu bayar per jam — mulai dari $0.18/jam untuk 2-core, bisa naik cepat kalau lupa matiin.

Kalau kamu sudah pakai VSCode dan Docker ada di mesin kamu, Dev Container adalah pilihan paling pragmatis.

Tips Praktis yang Tidak Ada di Dokumentasi Resmi

1. Pakai named volume untuk cache dependency

Bind mount dari host ke container di macOS lambat. Untuk folder seperti node_modules atau Go module cache, pakai named volume:

"mounts": [
  "source=projectname-go-cache,target=/go,type=volume",
  "source=projectname-vscode-extensions,target=/root/.vscode-server/extensions,type=volume"
]

Extension VSCode juga disimpan di named volume — artinya rebuild container tidak perlu download ulang semua extension.

2. Forward port dengan label yang jelas

"forwardPorts": [8080, 5432, 6379],
"portsAttributes": {
  "8080": { "label": "App Server", "onAutoForward": "notify" },
  "5432": { "label": "Postgres", "onAutoForward": "silent" },
  "6379": { "label": "Redis", "onAutoForward": "silent" }
}

3. Jangan simpan secret di devcontainer.json

File ini masuk ke git. Untuk environment variable sensitif, pakai localEnv atau containerEnv yang referensikan env var dari host:

"containerEnv": {
  "AWS_ACCESS_KEY_ID": "${localEnv:AWS_ACCESS_KEY_ID}",
  "AWS_SECRET_ACCESS_KEY": "${localEnv:AWS_SECRET_ACCESS_KEY}"
}

Set variabel-nya di shell profile host kamu (~/.zshrc atau ~/.bashrc), bukan di file yang di-commit.

4. initializeCommand untuk validasi awal

"initializeCommand": "docker info > /dev/null 2>&1 || (echo 'Docker tidak berjalan!' && exit 1)"

Ini jalan di host sebelum container dibuild. Berguna untuk validasi prerequisite.

Workflow Sehari-hari

Setelah setup, workflow harianku begini:

  1. git clone <repo> di terminal host
  2. code <folder> — VSCode terbuka
  3. VSCode detect .devcontainer/devcontainer.json, muncul notifikasi "Reopen in Container"
  4. Klik. Tunggu build pertama (bisa 2-5 menit tergantung image). Build berikutnya pakai cache, biasanya under 30 detik.
  5. Kerja normal. Terminal di VSCode adalah shell di dalam container.

Kalau mau rebuild container (misalnya setelah update devcontainer.json): Command Palette → "Dev Containers: Rebuild Container".

Satu hal yang aku appreciate: karena semua extension di-define di devcontainer.json, tidak ada lagi situasi "aku pakai extension X tapi kamu tidak" dalam satu project. Semua orang — atau semua mesin kamu — dapat setup yang identik.

Untuk yang tertarik eksplorasi lebih jauh tentang self-hosted environment, bisa baca juga artikel tentang setup VPS untuk development dan manajemen dotfiles dengan GNU Stow yang pernah aku tulis sebelumnya.

Kesimpulan

VSCode remote development container bukan silver bullet. Kalau kamu kerja di satu mesin yang tidak pernah ganti, dengan satu stack yang sudah stabil, mungkin overhead-nya tidak worth it. Tapi kalau kamu sering ganti mesin, punya beberapa project dengan stack berbeda, atau sekadar capek dengan "dependency hell" — ini investasi setup yang bayar balik dengan cepat.

Langkah konkret untuk besok: ambil satu project yang paling sering kamu setup ulang. Buat folder .devcontainer, tulis devcontainer.json minimal dengan pre-built image yang sesuai, dan coba buka di container. Kalau berhasil, kamu baru saja eliminasi satu sumber frustrasi yang selama ini terasa normal padahal tidak seharusnya.