Pengembangan Perangkat Lunak Di Mana Saja: Tempat Kerja Jarak Jauh Terdistribusi Saya

Bekerja sebagai pekerja lepas jarak jauh memiliki banyak manfaat, tetapi menyiapkan lingkungan kerja terdistribusi yang efektif dapat menjadi tantangan nyata. Tentu saja, ada banyak pendekatan yang dapat diambil, dan tidak ada satu cara "terbaik" yang cocok untuk semua orang. Organisasi tempat kerja digital jarak jauh memang merupakan hal yang sangat pribadi, dan apa yang bekerja dengan baik untuk satu pengembang mungkin tidak bekerja dengan baik sama sekali untuk orang lain.

Dengan mengingat hal itu, pengaturan yang saya sajikan di sini adalah yang bekerja dengan baik untuk saya secara pribadi, terutama pada proyek jarak jauh yang melibatkan pengembangan dan administrasi sistem. Saya percaya pendekatan ini memiliki sejumlah keuntungan, tetapi setiap pembaca harus mempertimbangkan bagaimana mengadaptasi ini dengan cara yang paling sesuai untuk mereka, berdasarkan kombinasi kebutuhan operasional dan preferensi pribadi mereka.

Pendekatan saya sebagian besar didasarkan pada fitur yang ditawarkan oleh SSH dan alat terkait di Linux. Perhatikan bahwa pengguna MacOS dan sistem mirip Unix lainnya dapat memanfaatkan prosedur yang dijelaskan juga, sejauh sistem mereka mendukung alat yang dijelaskan.

Mini-Server Pribadi Saya

Langkah pertama yang penting dalam pengaturan saya adalah server bertenaga Raspberry Pi 2 di rumah saya sendiri, yang digunakan untuk meng-host semuanya mulai dari repositori kode sumber saya hingga situs demo.

Meskipun saya melakukan perjalanan, apartemen saya berfungsi sebagai "basis operasi tetap" jarak jauh saya dengan konektivitas Internet yang layak (100 Mbit/dtk) dan hampir tidak ada latensi tambahan. Artinya, dari apartemen saya, pada dasarnya saya hanya dibatasi oleh kecepatan jaringan tujuan. Pengaturan yang saya jelaskan berfungsi paling baik dengan jenis konektivitas ini, meskipun itu bukan keharusan. Bahkan, saya juga menggunakan pendekatan ini ketika saya memiliki koneksi ADSL bandwidth yang relatif rendah, dengan sebagian besar hal bekerja dengan baik. Satu-satunya persyaratan nyata, menurut pengalaman saya, adalah bandwidth tidak terukur atau sangat murah.

Sebagai pengguna perumahan, saya memiliki router jaringan rumah termurah yang dapat dibeli oleh ISP saya, yang tidak cukup untuk apa yang perlu saya lakukan. Oleh karena itu saya telah meminta agar ISP menempatkan router ke "mode jembatan", di mana ia hanya berfungsi sebagai terminator koneksi, menawarkan titik akhir PPPoE ke tepat satu sistem yang terhubung. Ini berarti perangkat berhenti bekerja sebagai titik akses WiFi atau bahkan sebagai router rumah biasa. Semua tugas ini ditangani oleh router Mikrotik kecil profesional RB951G-2HnD. Ini melakukan layanan NAT untuk jaringan lokal saya (yang saya beri nomor 10.10.10.0/24), dan menawarkan DHCP ke perangkat berkabel dan nirkabel yang terhubung dengannya. Mikrotik dan Raspberry Pi memiliki alamat statis karena digunakan dalam konteks di mana diperlukan alamat yang terkenal. Dalam kasus saya, masing-masing adalah 10.10.10.1 dan 10.10.10.10.

Sambungan rumah saya tidak memiliki alamat IP statis. Untuk tujuan saya, ini hanya ketidaknyamanan ringan bekerja dari jarak jauh karena tujuannya adalah untuk menciptakan lingkungan kerja pribadi atau SOHO, bukan situs 24/7. (Bagi mereka yang memang membutuhkan alamat IP statis untuk server mereka, perlu dicatat bahwa biaya alamat IP statis terus turun dan tersedia opsi IP VPN statis yang cukup murah.) Pialang DNS yang saya gunakan, Joker.com , menawarkan layanan DNS dinamis gratis bersama semua layanan lainnya, jadi satu subdomain dari domain pribadi saya ada sebagai nama dinamis. Saya menggunakan nama ini untuk menghubungkan dari luar ke jaringan saya sendiri, dan Mikrotik dikonfigurasi untuk meneruskan SSH dan HTTP melalui NAT ke Raspberry Pi. Saya hanya perlu mengetikkan yang setara dengan ssh mydomain.example.com untuk masuk ke server rumah pribadi saya.

Data Di Mana Saja

Satu hal penting yang tidak ditawarkan oleh Raspberry Pi adalah redundansi. Saya telah melengkapinya dengan kartu 32 GB, dan itu masih banyak data yang hilang jika terjadi sesuatu. Untuk menyiasatinya, dan untuk memastikan akses ke data saya jika akses Internet perumahan tersendat, saya mencerminkan semua data saya ke server eksternal seperti cloud. Karena saya di Eropa, masuk akal bagi saya untuk mendapatkan server bare-metal khusus (yaitu tidak tervirtualisasi) terkecil dari Online.net, yang dilengkapi dengan CPU VIA kelas bawah, menawarkan RAM 2 GB dan SSHD 500 GB. Seperti mini-server Raspberry Pi, saya tidak membutuhkan kinerja CPU atau bahkan memori yang tinggi, jadi ini adalah pasangan yang sempurna. (Sebagai tambahan, saya ingat server "besar" pertama saya yang memiliki dua CPU Pentium 3 dan 1 GB RAM, dan mungkin setengah kecepatan Raspberry Pi 2, dan bagaimana kami melakukan hal-hal hebat dengannya, yang telah memengaruhi saya minat dalam pengoptimalan.)

Saya mencadangkan Raspberry Pi saya ke server seperti cloud jarak jauh menggunakan rdiff-backup. Dilihat dari ukuran relatif sistem, cadangan ini akan memberi saya riwayat yang hampir tidak terbatas. Satu hal lain yang saya miliki di server seperti cloud adalah instalasi ownCloud, yang memungkinkan saya untuk menjalankan layanan pribadi seperti Dropbox. ownCloud sebagai produk bergerak menuju groupware dan kolaborasi, sehingga menjadi lebih berguna jika lebih banyak orang menggunakannya. Sejak saya mulai menggunakannya, saya benar-benar tidak memiliki data lokal yang tidak dicadangkan ke Raspberry Pi atau ke server seperti cloud, dan sebagian besar dicadangkan dua kali. Setiap redundansi cadangan tambahan yang dapat Anda buat selalu merupakan hal yang baik, jika Anda menghargai data Anda.

"Keajaiban" SSHFS

Sebagian besar pekerjaan saya akhir-akhir ini melibatkan pengembangan hal-hal yang tidak terkait langsung dengan web (mengejutkan, saya tahu!), Jadi alur kerja saya sering mengikuti siklus edit-kompilasi-jalankan klasik. Bergantung pada keadaan spesifik suatu proyek, saya mungkin memiliki file-nya secara lokal di laptop saya, saya dapat meletakkannya di direktori yang disinkronkan dengan ownCloud, atau, yang lebih menarik, saya dapat menempatkannya langsung di Raspberry Pi dan menggunakannya dari sana .

Opsi terakhir dimungkinkan berkat SSHFS, yang memungkinkan saya memasang direktori jarak jauh dari Raspberry Pi secara lokal. Ini hampir seperti sepotong kecil keajaiban: Anda dapat memiliki direktori jarak jauh di server mana pun yang memiliki akses SSH (bekerja di bawah izin yang dimiliki pengguna Anda di server) yang dipasang sebagai direktori lokal.

Punya direktori proyek jarak jauh? Pasang secara lokal dan lakukan. Jika Anda memerlukan server yang kuat untuk pengembangan atau pengujian dan – untuk beberapa alasan hanya pergi ke sana dan menggunakan vim di konsol bukanlah pilihan – pasang server itu secara lokal dan lakukan apa pun yang Anda inginkan. Ini bekerja sangat baik ketika saya menggunakan koneksi bandwidth rendah ke Internet: bahkan jika saya bekerja di editor teks konsol, pengalamannya jauh lebih baik jika saya menjalankan editor itu secara lokal dan kemudian hanya mentransfer file melalui SSHFS, bukan daripada mengerjakan sesi SSH jarak jauh.

Perlu membandingkan beberapa direktori /etc pada server jarak jauh yang berbeda? Tidak masalah. Cukup gunakan SSHFS untuk memasang masing-masing secara lokal dan kemudian gunakan diff (atau alat lain apa pun yang berlaku) untuk membandingkannya.

Atau mungkin Anda perlu memproses file log yang besar tetapi Anda tidak ingin menginstal alat pengurai log di server (karena memiliki trilyun dependensi) dan untuk alasan apa pun menyalin log tidak nyaman. Sekali lagi, tidak masalah. Cukup pasang direktori log jarak jauh secara lokal melalui SSHFS dan jalankan alat apa pun yang Anda butuhkan – bahkan jika itu besar, berat, dan digerakkan oleh GUI. SSH mendukung kompresi on-the-fly dan SSHFS memanfaatkannya, jadi bekerja dengan file teks cukup ramah bandwidth.

Untuk tujuan saya, saya menggunakan opsi berikut pada baris perintah sshfs :

sshfs -o reconnect -o idmap=user -o follow_symlinks -C server.example.com:. server

Inilah yang dilakukan opsi baris perintah ini:

• -o reconnect - Memberi tahu sshfs untuk menyambungkan kembali titik akhir SSH jika rusak. Ini sangat penting karena secara default, ketika koneksi terputus, titik pemasangan akan gagal tiba-tiba atau hanya hang (yang menurut saya lebih umum). Tampaknya bagi saya bahwa ini harus menjadi opsi default.
• -o idmap=user - Memberi tahu sshfs untuk memetakan pengguna jarak jauh (yaitu, pengguna yang kita sambungkan) agar sama dengan pengguna lokal. Karena Anda dapat terhubung melalui SSH dengan nama pengguna yang berubah-ubah, ini "memperbaiki" hal-hal sehingga sistem lokal menganggap pengguna itu sama. Hak akses dan izin pada sistem jarak jauh berlaku seperti biasa untuk pengguna jarak jauh.
• -o follow_symlinks - Meskipun Anda dapat memiliki sejumlah sistem file jarak jauh yang dipasang secara acak, saya merasa lebih nyaman untuk memasang hanya satu direktori jarak jauh, direktori home saya, dan di dalamnya (dalam sesi SSH jarak jauh) saya dapat membuat symlink ke direktori penting di tempat lain pada sistem jarak jauh, seperti /srv atau /etc atau /var/log . Opsi ini membuat sshfs menyelesaikan symlink jarak jauh ke dalam file dan direktori, memungkinkan Anda untuk menindaklanjuti ke direktori yang ditautkan.
• -C - Mengaktifkan kompresi SSH. Ini sangat efektif dengan metadata file dan file teks, jadi ini adalah hal lain yang sepertinya harus menjadi opsi default.
• server.example.com:. - Ini adalah titik akhir jarak jauh. Bagian pertama ( server.example.com dalam contoh ini) adalah nama host, dan bagian kedua (setelah titik dua) adalah direktori jarak jauh yang akan dipasang. Dalam hal ini, saya telah menambahkan "." untuk menunjukkan direktori default tempat pengguna saya berakhir setelah login SSH, yang merupakan direktori home saya.
• server - Direktori lokal tempat sistem file jarak jauh akan dipasang.

Terutama jika Anda menggunakan bandwidth rendah atau koneksi Internet tidak stabil, Anda perlu menggunakan SSHFS dengan otentikasi kunci publik/pribadi SSH, dan agen SSH lokal. Dengan cara ini, Anda tidak akan dimintai kata sandi (baik kata sandi sistem atau kata sandi kunci SSH) saat menggunakan SSHFS dan fitur sambungkan kembali akan berfungsi seperti yang diiklankan. Perhatikan bahwa jika Anda tidak mengatur agen SSH sehingga memberikan kunci yang tidak terkunci sesuai kebutuhan dalam sesi Anda, fitur sambungkan kembali biasanya akan gagal. Web penuh dengan tutorial kunci SSH, dan sebagian besar lingkungan desktop berbasis GTK saya telah mencoba memulai agen mereka sendiri (atau "dompet", atau apa pun yang mereka pilih untuk menyebutnya) secara otomatis.

Beberapa Trik SSH Tingkat Lanjut

Memiliki titik tetap di Internet yang dapat diakses dari jarak jauh dari mana saja di dunia, dan yang berada pada koneksi bandwidth tinggi – bagi saya ini adalah sistem Raspberry Pi saya, dan itu benar-benar dapat berupa VPS generik apa pun – mengurangi stres dan memungkinkan Anda melakukannya segala macam hal dengan bertukar dan menggali data.

Butuh nmap cepat dan Anda terhubung melalui jaringan ponsel? Lakukan saja dari server itu. Perlu menyalin beberapa data dengan cepat dan SSHFS terlalu berlebihan? Cukup gunakan SCP biasa.

Situasi lain yang mungkin Anda hadapi dengan kami di mana Anda memiliki akses SSH ke server tetapi port 80-nya (atau yang lainnya) di-firewall ke jaringan luar tempat Anda terhubung. Untuk menyiasatinya, Anda dapat menggunakan SSH untuk meneruskan port ini ke mesin lokal Anda, dan kemudian mengaksesnya melalui localhost . Pendekatan yang lebih menarik adalah menggunakan host yang terhubung dengan Anda melalui SSH untuk meneruskan port pada komputer lain , mungkin di belakang firewall yang sama. Jika, misalnya, Anda memiliki host berikut:

• 192.168.77.15 - Host di jaringan lokal jarak jauh di belakang firewall, yang harus Anda sambungkan ke port 80-nya
• foo.example.com - Host tempat Anda memiliki akses SSH, yang dapat terhubung ke host di atas
• sistem lokal Anda, localhost

Perintah untuk meneruskan port 80 pada 192.168.77.15 ke localhost:8080 melalui server SSH foo.example.com adalah:

ssh -L 8080:192.168.77.15:80 -C foo.example.com

Argumen ke -L menentukan port lokal, dan alamat serta port tujuan. Argumen -C memungkinkan kompresi, sehingga Anda dapat menghemat bandwidth lagi, dan akhirnya Anda cukup mengetikkan nama host SSH. Perintah ini akan membuka sesi shell SSH biasa ke host, dan selain itu, dengarkan port localhost 8080, yang dapat Anda sambungkan.

Salah satu trik paling mengesankan yang dikembangkan SSH dalam beberapa tahun terakhir adalah kemampuannya untuk membuat terowongan VPN nyata. Ini memanifestasikan dirinya sebagai perangkat jaringan virtual di kedua sisi koneksi (dengan asumsi mereka memiliki alamat IP yang sesuai diatur) dan dapat memungkinkan Anda mengakses jaringan jarak jauh seolah-olah Anda secara fisik ada (melewati firewall). Untuk alasan teknis dan keamanan, ini memerlukan akses root pada kedua mesin yang sedang terhubung dengan terowongan, sehingga jauh lebih tidak nyaman daripada hanya menggunakan penerusan port atau SSHFS atau SCP. Yang ini untuk pengguna tingkat lanjut di luar sana, yang dapat dengan mudah menemukan tutorial tentang cara melakukannya.

Kantor Jarak Jauh Di Mana Saja

Terlepas dari kebutuhan untuk bekerja dari satu lokasi, Anda dapat bekerja secara harfiah dari mana saja yang memiliki konektivitas Internet setengah layak menggunakan teknologi dan teknik yang telah saya uraikan (termasuk sambil menunggu mobil Anda di mekanik). Pasang sistem asing melalui SSH, port forward, terowongan bor, untuk mengakses server pribadi Anda atau data berbasis cloud dari jarak jauh, sambil menghadap pantai yang bermandikan sinar matahari, atau minum kopi ramah lingkungan kelas hipster di kota yang berkabut. Lakukan saja!