Baris Context: default yang kita temui pada output docker version dan docker info sekarang saatnya dibedah. Bayangkan situasi yang sangat umum di dunia nyata: Budi mengembangkan aplikasi di laptop dengan Docker Engine lokal, sementara timnya punya satu server uji bernama server.example.com yang juga menjalankan daemon Docker — dan suatu hari mungkin ada lagi Docker Desktop di VM Windows. Satu program docker saja kini harus bisa mengurus tiga daemon yang berbeda-beda alamatnya. Tanpa mekanisme yang rapi, kita terpaksa mengedit variabel lingkungan setiap kali pindah target, dan kesalahan paling berbahaya di sini adalah menjalankan perintah ke daemon yang salah — misalnya membersihkan container di server uji padahal yang dimaksud adalah laptop sendiri. Docker menjawab kebutuhan ini dengan context: kumpulan pengaturan koneksi yang diberi nama dan bisa dipilih dengan satu perintah.

Satu CLI Banyak Daemon #

Mekanisme context berakar pada arsitektur client-server yang kita bahas pada Chapter Arsitektur Docker. Program docker di terminal adalah klien murni yang tidak pernah membuat container dengan tangannya sendiri — klien hanya mengirim permintaan REST API ke sebuah daemon, dan daemon itu bisa berada di mana saja: di socket Unix pada mesin yang sama, di server jauh yang bisa dijangkau lewat SSH, atau di dalam VM internal Docker Desktop.

Pertanyaannya menjadi sederhana namun krusial: ketika kita mengetik docker ps, permintaan itu dikirim ke daemon mana? Context adalah jawaban resmi untuk pertanyaan tersebut. Sebuah context menyimpan nama, deskripsi, dan endpoint — alamat lengkap cara menghubungi daemon, termasuk pengaturan TLS bila dipakai. Satu context aktif berlaku untuk semua perintah sampai kita menggantinya, dan pengaturan ini tersimpan sehingga bertahan antar sesi terminal.

Perlu dicatat bahwa pengguna Docker Desktop akan melihat konteks bernama desktop-linux di mesin mereka, karena daemon Desktop hidup di dalam VM dengan socket tersendiri. Mesin latihan kita memakai Docker Engine langsung di Ubuntu, sehingga daftar context di chapter ini hanya memuat context bawaan.

Melihat Daftar Context #

Perintah docker context ls milik objek context mencantumkan seluruh context yang dikenal CLI beserta endpoint-nya:

bash
$ docker context ls

Output yang Dihasilkan:

text
NAME        DESCRIPTION                               DOCKER ENDPOINT ...
default *   Current DOCKER_HOST based configuration   unix:///var/run/docker.sock ...

Mari kita telaah tabel di atas:

  1. Kolom NAME — nama context yang akan kita pakai untuk berpindah target; nama inilah yang ditulis pada baris Context: di output docker version.
  2. Tanda * di samping default — penanda context yang sedang aktif; semua perintah docker kita saat ini ditujukan ke context ini.
  3. Kolom DOCKER ENDPOINT — alamat daemon yang dituju; unix:///var/run/docker.sock adalah socket lokal, tepat endpoint bawaan yang kita bahas pada chapter-chapter sebelumnya.
  4. Tanda ... di ujung kanan — tabel aslinya lebih lebar daripada terminal sehingga Docker memotongnya; kolom-kolom lanjutan berisi endpoint layanan lain di dalam context yang sama.

Membuat dan Mengaktifkan Context Baru #

Sekarang kita buat context untuk server uji di kantor. Endpoint yang kita pakai adalah ssh://[email protected]: klien Docker akan membuka koneksi SSH ke server, lalu mengirim permintaan REST API melalui terowongan tersebut — tidak ada port daemon yang perlu dibuka ke publik:

bash
$ docker context create server-kantor --docker host=ssh://[email protected]

Output yang Dihasilkan:

text
server-kantor

Context sudah dibuat, namun belum aktif — pembuatan dan pengaktifan adalah dua langkah terpisah. Kita alihkan target CLI dengan docker context use, lalu pastikan pilihan kita dengan docker context show:

bash
$ docker context use server-kantor

Output yang Dihasilkan:

text
server-kantor
bash
$ docker context show

Output yang Dihasilkan:

text
server-kantor

Mari kita telaah ketiga perintah di atas:

  1. docker context create server-kantor --docker host=... — server-kantor adalah nama context, sedangkan --docker host= mendefinisikan endpoint untuk layanan docker di dalam context tersebut; output satu baris adalah nama context yang baru dibuat.
  2. docker context use server-kantor — mulai panggilan ini, seluruh perintah docker di terminal kita ditujukan ke daemon di server kantor; docker ps akan menampilkan container milik server, bukan laptop.
  3. docker context show — pencetak nama context aktif; berguna untuk memastikan target sebelum menjalankan perintah yang berdampak besar.

Kita lihat hasilnya pada daftar context — tanda bintang sudah berpindah:

bash
$ docker context ls

Output yang Dihasilkan:

text
NAME              DESCRIPTION                               DOCKER ENDPOINT ...
default           Current DOCKER_HOST based configuration   unix:///var/run/docker.sock ...
server-kantor *                                             ssh://[email protected] ...

Kolom DESCRIPTION untuk server-kantor memang kosong karena kita tidak memberikan --description saat membuatnya; deskripsi bisa ditambahkan saat pembuatan bila daftar context kita kelak membludak. Setelah selesai bekerja dengan server, kita kembalikan target ke daemon lokal dengan cara yang sama:

bash
$ docker context use default

Output yang Dihasilkan:

text
default

Context yang tidak terpakai dapat dibuang dengan docker context rm server-kantor, dengan catatan context yang sedang aktif tidak boleh dihapus sebelum dialihkan lebih dulu. Nama context juga bisa dipakai ulang setelah penghapusan, sehingga daftar context tetap mudah dikelola meski server di baliknya berganti-ganti.

DOCKER_HOST vs DOCKER_CONTEXT #

Context bukan satu-satunya cara mengarahkan klien. Jauh sebelum context ada, variabel lingkungan DOCKER_HOST sudah dipakai untuk menyebut alamat endpoint secara langsung, dan variabel DOCKER_CONTEXT kemudian hadir sebagai pasangan yang menyebut nama context. Flag baris perintah juga bisa menimpa keduanya — teks bantuan pada --context sendiri menyatakan bahwa flag tersebut mengesampingkan DOCKER_HOST sekaligus context aktif. Tabel berikut merangkum urutan prioritasnya:

PrioritasSumberJangkauanKeterangan
1Flag -c, --context atau -H, --hostSatu pemanggilanMenimpa variabel lingkungan dan context aktif
2Variabel DOCKER_HOSTSeluruh sesi terminalAlamat endpoint yang ditulis langsung; menimpa context aktif
3Variabel DOCKER_CONTEXTSeluruh sesi terminalNama context pengganti tanpa flag
4Context aktif hasil docker context useTersimpan di konfigurasiBerlaku sampai diganti
5Context defaultKondisi awalEndpoint socket lokal

Membaca tabelnya: sumber di atas menimpa sumber di bawah. Satu hal yang perlu kita lindungi diri darinya adalah memasang DOCKER_HOST dan DOCKER_CONTEXT secara bersamaan — daripada mengandalkan urutan prioritas keduanya, kosongkan salah satu supaya tidak ada kejutan saat skrip berpindah mesin.

Di Mana Context Disimpan #

Context bukan berkas sihir yang tersembunyi di dalam binary CLI. Semua context buatan kita disimpan di bawah direktori ~/.docker/contexts/meta/, di mana setiap context menempati satu folder bernama hash SHA-256 dari nama contextnya, dan di dalam folder itu tersimpan berkas meta.yaml. Context server-kantor kita, misalnya, berada di folder cbec4c735fe449172a5be290df1ec6640f6e7a3845681a47ec60cbba2fc00b72. Isi berkasnya sederhana:

yaml
Name: server-kantor
Metadata:
  Description: ""
Endpoints:
  docker:
    Host: ssh://[email protected]
    SkipTLSVerify: false

Mari kita telaah isi berkas tersebut:

  1. Name — nama context yang sama dengan yang tampil pada docker context ls.
  2. Endpoints.docker.Host — endpoint daemon yang menjadi tujuan context ini; struktur berkas memungkinkan context menyimpan endpoint untuk beberapa layanan sekaligus di bawah Endpoints.
  3. SkipTLSVerify: false — verifikasi TLS tetap aktif; nilai ini relevan untuk endpoint TCP yang terenkripsi, bukan untuk endpoint SSH seperti milik kita.

Kita hampir tidak pernah menyunting berkas ini secara manual karena perintah docker context create, use, dan rm mengurus semuanya dengan aman. Context yang sedang aktif sendiri dicatat pada berkas ~/.docker/config.json di kunci currentContext — berkas konfigurasi klien yang sudah kita kenal pada Chapter Konfigurasi Docker CLI.

Target kita kembali ke default, daemon lokal di laptop siap menerima perintah, dan panel instrumen sudah dibaca tuntas. Semua bekal kebiasaan CLI kini lengkap: tata bahasa perintah, bantuan mandiri, dan kemampuan memilih daemon. Saatnya menjalankan container sungguhan dari nol di mesin ini dan membedah setiap fase kelahirannya — tugas yang dikerjakan Chapter Menjalankan Container Pertama dengan docker run hello-world dan sebuah web server nginx.

Referensi #