VickyApp
Buka menu navigasi

Studi kasusInfrastruktur & platform

Platform kontainer yang menyiapkan lingkungan klien secara otomatis

Satu platform bersama menggantikan penyiapan server manual, sehingga lini layanan baru bisa tumbuh tanpa menambah beban kerja tim operasi.

  • Infrastruktur
  • Otomasi
  • Platform
Peran
System Administrator & DevOps Engineer
Periode
2024 — sekarang
Status
Berjalan
Dipakai
  • Docker Swarm
  • Traefik
  • Portainer
  • n8n
  • GitHub Actions
  • Linux

Konteks dan masalah

Perusahaan hendak membuka lini layanan baru: menjalankan aplikasi milik klien di infrastruktur kami, bukan menyerahkan server untuk diurus sendiri oleh klien. Sebelumnya setiap permintaan berarti menyiapkan satu server, mengaturnya satu per satu, lalu menyerahkan hasilnya dengan tangan. Cara itu membatasi berapa banyak klien yang bisa dilayani sekaligus, dan membuat mutu layanan bergantung pada siapa yang mengerjakannya hari itu.

Yang menjadi kendala

  • Menyiapkan lingkungan untuk klien baru menghabiskan waktu berjam-jam per klien dan seluruhnya dikerjakan dengan tangan.
  • Setiap lingkungan bisa berbeda satu sama lain, sehingga masalah yang tampak sama tidak selalu punya penyebab yang sama saat ditelusuri.
  • Tidak ada jalur rilis yang konsisten. Perubahan dikirim dengan masuk ke server satu per satu, dan riwayat perubahan tidak tercatat.
  • Aplikasi klien berjalan berdampingan, jadi satu lingkungan yang bermasalah berisiko mengganggu yang lain.

Batasan yang tidak bisa diubah

  • Tim operasi tetap kecil. Kapasitas tidak bertambah meski jumlah klien bertambah.
  • Klien berjalan di platform yang sama dan tidak boleh saling mengganggu.
  • Lini layanan harus bisa dirawat oleh orang yang tidak membangunnya, jadi keputusan harus tercatat, bukan tinggal di kepala satu orang.
  • Penambahan kapasitas harus bisa dilakukan tanpa mengganggu klien yang sedang berjalan.

Peran dan tanggung jawab saya

  • Merancang dan membangun klaster kontainer sebelas node dari nol, dengan pemisahan peran yang jelas: satu node untuk trafik masuk, tiga node pengendali, dan tujuh node pekerja.
  • Menyusun penyiapan klien otomatis dengan menghubungkan API manajemen platform ke alur kerja otomasi, sehingga permintaan aplikasi baru tidak lagi dikerjakan manual.
  • Membangun jalur rilis dari repositori kode menuju server, menggantikan pengiriman perubahan lewat akses langsung ke server.
  • Menjaga platform tetap berjalan dan ikut menangani gangguan produksi bersama tim operasi.

Cara saya mengerjakannya

  1. 01

    Mencatat pekerjaan yang paling sering diulang

    Apa yang dikerjakan untuk setiap klien baru didata lebih dulu, lalu dipisahkan mana yang benar-benar berbeda per klien dan mana yang bisa diseragamkan. Yang seragam itulah yang layak diotomatiskan.

  2. 02

    Menetapkan satu pintu masuk dan satu cara rilis

    Seluruh trafik dipusatkan pada satu titik agar penambahan klien tidak mengubah konfigurasi di banyak tempat. Rilis dikirim dari repositori, bukan dari server, sehingga setiap perubahan meninggalkan jejak.

  3. 03

    Mengotomatiskan penyiapan lingkungan klien

    Alur otomasi memanggil API platform untuk membuat dan mengenali lingkungan baru, lalu menyerahkannya tanpa langkah manual di tengah.

  4. 04

    Menguji dengan klien nyata sebelum menambah kapasitas

    Platform dijalankan untuk klien pertama sebelum node ditambah, supaya kelemahan rancangan terlihat saat dampaknya masih kecil.

Lini layanan ini dimulai dari satu pertanyaan sederhana: bagaimana menjalankan aplikasi milik klien di infrastruktur kami tanpa memperlakukan setiap klien sebagai proyek tersendiri. Sebelum pekerjaan ini, jawabannya adalah menyiapkan satu server, mengaturnya satu per satu, lalu menyerahkan hasilnya. Cara itu bekerja untuk beberapa klien, dan berhenti bekerja begitu jumlahnya bertambah.

Dari permintaan klien menjadi satu pekerjaan yang sama

Langkah pertama bukan menambah mesin, melainkan mencatat apa yang sebenarnya dikerjakan setiap kali ada klien baru. Dari catatan itu terlihat bahwa sebagian besar langkahnya sama: menyalakan lingkungan, mengatur cara aplikasi diakses, menyerahkan akses. Hanya sebagian kecil yang benar-benar berbeda per klien. Bagian yang sama itulah yang layak dijadikan satu pekerjaan tetap, sementara bagian yang berbeda dibiarkan tetap bisa disesuaikan.

Membangun batas antar klien dari topologinya

Klien berjalan pada platform yang sama, jadi batas antar mereka harus jelas sejak dari susunan mesinnya. Satu mesin dipakai khusus sebagai titik masuk seluruh trafik, tiga mesin mengatur penempatan beban kerja, dan sisanya menjalankan aplikasi. Pemisahan ini membuat penambahan klien baru tidak mengubah konfigurasi di banyak tempat sekaligus, dan membuat satu lingkungan yang bermasalah lebih mudah dikurung.

Setelah lingkungannya seragam, langkah penyiapan masih dikerjakan dengan tangan. Bagian ini dihubungkan ke alur otomasi, sehingga permintaan lingkungan baru dibuat dan dikenali oleh sistem sebelum hasilnya diserahkan ke klien. Cara pengiriman perubahan juga berpindah: dari masuk ke server satu per satu menjadi rilis dari repositori kode, yang sekaligus meninggalkan catatan siapa mengubah apa.

Ringkasan hasil

Platform berjalan sebagai klaster sebelas mesin: satu titik masuk, tiga pengendali, tujuh pekerja, dan sekitar tiga ratus kontainer aktif di dalamnya. Penyiapan lingkungan klien baru berjalan otomatis tanpa langkah manual, dan rilis aplikasi dikirim melalui pipeline alih-alih lewat akses langsung ke server. Yang paling terasa bagi tim adalah lini layanan ini bisa terus tumbuh tanpa menambah orang.

Hasil

  • Klaster kontainer sebelas node berjalan di produksi: satu node trafik masuk, tiga node pengendali, dan tujuh node pekerja.

    Topologi ini yang benar-benar dipasang dan dioperasikan, bukan rancangan di atas kertas.

    terverifikasi

  • Sekitar 300 kontainer aktif berjalan di platform tersebut.

    Angka dari produksi, bukan perkiraan.

    terverifikasi

  • Penyiapan lingkungan aplikasi untuk klien baru berjalan otomatis setelah API manajemen platform dihubungkan ke alur kerja otomasi.

    terverifikasi

  • Rilis aplikasi dikirim melalui pipeline, menggantikan penerapan manual lewat akses SSH ke server.

    terverifikasi

  • Pemisahan peran antar node membuat batas antar klien lebih jelas dan mengurangi pekerjaan berulang yang masih harus dikerjakan tangan.

Detail teknis

Bagian ini hanya diperlukan bila Anda ingin menilai sisi teknisnya. Isi di atas sudah cukup untuk memahami hasilnya.

Buka detail implementasi3 keputusan

Klaster Docker Swarm sebelas node dengan Traefik sebagai ingress pada node khusus, tiga manager, dan tujuh worker. Portainer dipakai sebagai API dan antarmuka manajemen, n8n merangkai otomasi penyiapan klien, dan GitHub Actions menjadi jalur rilis.

Menyediakan satu node khusus untuk ingress, bukan menjalankannya di node yang juga melayani beban kerja.
Node ini menjadi satu-satunya titik masuk, jadi ia tidak boleh berebut sumber daya dengan aplikasi klien. Konsekuensinya satu node penuh tidak pernah dipakai menjalankan beban kerja, sehingga kapasitas efektif untuk aplikasi berkurang satu node.
Memilih Docker Swarm alih-alih Kubernetes.
Platform ini harus bisa dirawat oleh tim yang lebih kecil daripada tim Kubernetes pada umumnya, dan beban awalnya tidak menuntut orkestrasi selengkap itu. Yang dikorbankan adalah ekosistem dan keleluasaan penjadwalan yang lebih kaya, sehingga kebutuhan yang lebih rumit nanti akan memaksa peninjauan ulang.
Mengotomatiskan penyiapan klien lewat API manajemen, bukan lewat skrip terpisah per klien.
Skrip per klien cepat dibuat tetapi jumlahnya berlipat setiap kali ada klien baru. Cara ini mengikat proses ke antarmuka yang disediakan platform, sehingga perubahan versi pada platform harus diikuti, bukan diabaikan.

Jumlah klien bertambah tanpa penambahan orang, dan itu membuat dokumentasi menjadi bagian dari pekerjaan, bukan pelengkap. Yang akan dilakukan berbeda: menetapkan batas sumber daya per klien sejak awal, karena menegakkannya pada klaster yang sudah berisi jauh lebih sulit.

Yang saya pelajari

  • Otomasi yang berguna dimulai dari pekerjaan yang paling sering diulang, bukan dari alat yang paling menarik.
  • Satu pintu masuk membuat penambahan klien menjadi perubahan kecil, dan itu lebih berpengaruh daripada menambah kapasitas mesin.
  • Rancangan yang hanya dipahami pembangunnya akan menjadi masalah begitu tim bertambah, jadi catatan keputusan harus dibuat saat keputusannya diambil.