Belajar Tmux - Remote Development & SSH Workflow

#Pendahuluan

Di episode 17 sebelumnya kita membangun keterampilan membuat script sendiri, widget status yang ringan, dan konfigurasi modular dengan source-file. Semua itu mempersiapkan kalian untuk skenario yang paling menentukan: bekerja di mesin remote. Di sinilah tmux membuktikan alasan keberadaannya.

Setiap engineer yang pernah mengelola server produksi tahu rasanya: sedang menjalankan migrasi database, lalu jaringan Wifi sekantor padam, dan semua pekerjaan ikut mati. Tanpa perlindungan, koneksi SSH yang terputus akan mengirim sinyal SIGHUP ke proses-proses di dalamnya, dan proses-proses itu — dev server, migrasi, backup — mati bersama koneksi. Tmux memutus rantai itu: proses berjalan di dalam server tmux yang hidup di mesin remote, bukan di dalam koneksi SSH kalian.

Pada episode ini kita membahas empat pilar kerja remote yang matang: workflow attach/detach, mosh untuk jaringan yang tidak stabil, jump host lewat bastion, dan teknik nested tmux ketika server juga menjalankan tmux. Semua contoh merujuk tmux 3.7b sebagai versi stabil terbaru.

#Masalah yang Dipecahkan Tmux di Koneksi Remote

Analogi sederhana: bekerja langsung di atas koneksi SSH itu seperti menulis di papan tulis — begitu papan dibawa pergi, tulisan hilang. Bekerja di dalam tmux seperti menulis di workshop: papan tulis (tmux server) tetap di tempatnya, dan kalian hanya meminjam jendela untuk melihatnya. Ketika jendela (client) ditutup, workshop tidak ikut hilang.

Secara teknis, tmux server adalah proses daemon yang berjalan di mesin tempat session berada. Client — terminal yang kalian lihat — hanya jendela ke server itu. Karena pekerjaan terjadi di server, memutus client tidak memengaruhi proses di dalam pane. Ini adalah alasan kenapa tmux hampir selalu menjadi alat pertama yang diinstall di server produksi oleh SysAdmin berpengalaman.

#Workflow Attach/Detach di Server Remote

Pola dasar kerja remote dengan tmux sangat sederhana: buat session saat pertama masuk, detach sebelum menutup koneksi, dan attach kembali kapan pun dibutuhkan. Berikut alur lengkapnya dalam dua momen berbeda:

ssh deploy@prod-01
tmux attach -t web || tmux new -s web

ssh deploy@prod-01
tmux attach -t web

Baris tmux attach -t web || tmux new -s web adalah idiom attach-or-create: jika session web sudah ada, kalian langsung menempel padanya; jika belum, session baru dibuat. Dengan idiom ini, kalian tidak perlu menghafal status session sebelum masuk — perintah yang sama selalu aman dijalankan.

Ketika selesai atau koneksi mulai tidak stabil, tekan prefix + d untuk detach. Pane, window, dan proses di dalamnya tetap berjalan di server. Kalian bisa menutup terminal, tidur semalam, lalu kembali dan menjalankan tmux attach -t web — semua masih di tempat kalian tinggalkan. Untuk melihat daftar session yang masih hidup tanpa attach, gunakan tmux ls.

#mosh untuk Koneksi Lambat

SSH bekerja dengan latensi penuh: setiap penekanan tombol menunggu balasan dari server, sehingga di jaringan lambat terasa seperti mengetik di dalam lumpur. mosh (mobile shell) menyelesaikan masalah ini dengan konsep berbeda: mosh menjalankan klien dan server sendiri, memberikan local echo sehingga pengetikan terasa instan, dan mempertahankan koneksi ketika IP berubah — misalnya saat berpindah dari Wifi kantor ke tethering.

Install mosh di Ubuntu/DebianInstall mosh di macOS

sudo apt install mosh

brew install mosh

Pemakaiannya nyaris identik dengan SSH:

mosh deploy@prod-01
tmux attach -t web || tmux new -s web

Penting untuk dipahami: mosh dan tmux bukanlah pesaing, melainkan pasangan. mosh menjaga koneksi tetap responsif dan tahan perubahan jaringan, sementara tmux menjaga pekerjaan tetap hidup bahkan ketika koneksi hilang sepenuhnya. Di dalam mosh yang stabil, tmux tetap berfungsi sebagai lapisan keamanan terakhir.

#Jump Host dan Bastion dengan Tmux

Di infrastruktur nyata, server aplikasi biasanya tidak bisa diakses langsung dari internet — kalian harus menembus bastion terlebih dahulu. OpenSSH modern menyederhanakan ini dengan ProxyJump, tanpa perlu menginstal tool tambahan di mesin lokal:

Host bastion
  HostName bastion.example.com
  User admin
 
Host app-01
  HostName 10.0.0.11
  User deploy
  ProxyJump bastion

Dengan konfigurasi di atas, ssh app-01 otomatis melompat melalui bastion tanpa langkah manual. Sekarang perhatikan peran tmux di lapisan ini: banyak tim memilih menjalankan tmux di bastion itu sendiri, sehingga setiap sesi kerja yang berpindah-pindah target server tetap berada dalam satu konteks yang konsisten. Session di bastion menjadi semacam ruang kerja bersama yang bertahan, tidak peduli berapa kali koneksi masuk dan keluar.

#Remote Development Patterns

#Dev server di session detached

Ketika dev server harus berjalan terus di remote — misalnya di mesin development bersama — buat session secara detached lalu attach saat perlu melihat output:

ssh deploy@prod-01
tmux new -d -s api 'npm run dev'
tmux attach -t api

Flag -d berarti session dibuat tanpa menempelkan client. Dev server langsung berjalan di background, dan kalian bisa attach kapan saja untuk melihat log tanpa mengganggu prosesnya.

#Tailing log dengan window khusus

Memantau error log secara live adalah pekerjaan harian SysAdmin. Alih-alih membuka file berulang kali, ikat proses tail di dalam session:

Tail log di window khusus

tmux new -s log 'tail -f /var/log/app/error.log'

Karena perintah tail berjalan di dalam pane, scrollback tmux menyimpan seluruh riwayat log — kalian bisa scroll ke belakang, mencari pattern, bahkan menyalin baris error langsung ke clipboard, jauh melampaui batas tail -f di shell polos.

#Long-running job yang tidak takut koneksi putus

Migrasi database, backup besar, atau rsync data dalam jumlah besar adalah contoh job yang paling rentan mati ketika koneksi terputus. Dengan tmux, job ini menjadi aman:

tmux new -d -s backup 'pg_dump app > backup.sql'
tmux attach -t backup

Jika koneksi putus di tengah job, tmux attach -t backup saat kembali akan menampilkan output yang terus berjalan di posisi terakhir — tanpa satu byte pun yang hilang.

#Nested Tmux: Tmux di dalam Tmux

Skenario paling menantang muncul ketika kalian sudah menjalankan tmux di mesin lokal, lalu SSH ke server yang juga menjalankan tmux. Kini ada dua lapisan yang mengklaim prefix yang sama. Menekan C-b akan ditelan oleh lapisan terluar, sehingga kalian kesulitan mengendalikan tmux di dalamnya.

Solusinya adalah memberi prefix berbeda pada setiap lapisan. Pendekatan paling umum: biarkan mesin lokal memakai C-b, dan remap tmux di server menjadi C-a.

set -g prefix C-a
unbind C-b
bind C-a send-prefix

set -g prefix C-b
bind C-b send-prefix

Di konfigurasi server, set -g prefix C-a mengganti prefix, unbind C-b membebaskan C-b agar tidak bersaing, dan bind C-a send-prefix membuat menekan C-a dua kali mengirim prefix ke lapisan yang lebih dalam. Sementara itu, mesin lokal mempertahankan C-b dan bind C-b send-prefix — sebenarnya ini sudah menjadi default tmux, tetapi menuliskannya secara eksplisit membuat konfigurasi mudah dibaca.

Berikut peta lengkapnya:

#Kesalahan Umum (Common Pitfalls)

1. Menjalankan job panjang tanpa tmux. Migrasi atau backup yang dijalankan langsung di shell mati bersama koneksi karena SIGHUP. Jadikan aturan: job yang lebih lama dari beberapa menit selalu masuk session tmux.
2. Mengira detach berarti mematikan proses. Detach tidak menghentikan apa pun — justru kebalikannya, proses terus berjalan. Biasakan mengecek tmux ls dan membersihkan session yang tidak terpakai agar server tidak menumpuk resource.
3. Nested tmux tanpa remap prefix. Mengendalikan tmux di dalam tmux tanpa perbedaan prefix berujung pada perintah yang salah lapisan, termasuk detach yang tidak disengaja. Remap C-a di server atau kuasai trik send-prefix.
4. Mengharapkan mosh bekerja di infrastruktur yang hanya membuka TCP 22. mosh membutuhkan port UDP 60000-61000. Jika firewall tidak mengizinkannya, mosh gagal koneksi — kembalilah ke SSH, dan biarkan tmux yang menjaga session.
5. Attach tanpa memeriksa siapa yang sudah terhubung. Sesi shared bersifat read-write secara default; attach tanpa -r berarti kalian ikut mengetik di layar orang lain. Periksa dengan tmux list-clients — detail ini akan kita perdalam di episode 19.
6. Lupa bahwa window tutup ketika prosesnya selesai. Jika kalian ingin pane tetap terbuka setelah perintah selesai — misalnya untuk membaca output — aktifkan set -g remain-on-exit on agar window tidak langsung hilang.

#Penutup

Episode ini menempatkan tmux pada posisi yang paling penting dalam karir engineering: pelindung pekerjaan jarak jauh. Kalian memahami kenapa koneksi SSH yang putus tidak lagi berarti pekerjaan yang mati, menguasai idiom attach-or-create, tahu kapan dan kenapa memakai mosh untuk jaringan lambat, bisa menembus bastion dengan ProxyJump sambil menjaga konteks kerja di dalam tmux, dan mampu menangani nested tmux dengan remap prefix yang bersih.

Poin yang harus kalian bawa:

• tmux attach -t web || tmux new -s web adalah pola aman yang bisa dijalankan kapan saja.
• mosh menjaga koneksi, tmux menjaga pekerjaan — keduanya saling melengkapi, bukan bersaing.
• Bastion layak memakai tmux untuk konteks kerja yang konsisten, tapi jangan pernah menaruh secret di sana.
• Nested tmux ditaklukkan dengan prefix berbeda di setiap lapisan.

Sekarang kalian bisa mengelola satu server dengan tenang. Di episode 19 selanjutnya kita akan membahas multi-server dan shared session — broadcast command ke banyak server sekaligus, pair programming dengan session bersama, dan mengatur permission termasuk attach read-only. Sampai jumpa di episode 19!