2 tahun yang lalu sampai 05 November 2023, situs ini berjalan di 1 droplet (VM) DigitalOcean dengan spek 2 vCPU dan 4 GB memory. Mesin virtual tersebut menjalankan Fedora CoreOS (FCOS) dan di provision menggunakan Ansible melalui playbook di repo forem/selfhost. Per tulisan ini diterbitkan, tidak ada cara lain untuk setup self-managed Forem selain menggunakan Ansible dan menggunakan cloud provider DigitalOcean, AWS, ataupun GCP.
Hari ini, situs ini sudah 100% berjalan di server rumah saya dengan spek 2 CPU dan 8 GB memory menggunakan sistem operasi Debian Bookworm dalam virtualisasi via KVM, dengan sistem operasi Ubuntu sebagai Host OS nya.
Di tulisan ini, saya ingin berbagi bagaimana melakukan "self host forem" tanpa Ansible, apa ekspektasi dari pemindahan ke rumah baru ini, dan juga beberapa hal lain yang mungkin menarik untuk dibagikan dan atau diketahui.
THANK GOD IT WAS CONTAINERS
Mengingat memiliki sedikit pengalaman kurang menyenangkan dengan Ansible di masa lalu (just like everyone else), saat pertama kali install Forem ini, umumnya seseorang menggunakan Ansible untuk mengotomatisasikan "toil" yang ada. Di banyak kasus, menggunakan shell scripts pun sudah cukup untuk automation khususnya untuk melakukan bootstrapping. Jika shell script tidak cukup, kemungkinannya hanya 2: Aplikasi yang dijalankan cukup kompleks sampai butuh ilmu roket atau si pembuat anti dengan curl | sh.
Di repo forem/selfhost sudah diperingatkan jika forem adalah "complex piece of software" namun saya tidak memiliki kata complex di kamus hidup saya.
Bagaimanapun, menurut saya pribadi, untuk menjalankan Forem "self-managed" ini tidak terlalu kompleks, mengingat:
- Hanya fokus di 1 sistem operasi (Fedora CoreOS), terlebih FCOS ini menggunakan pendekatan "immutable OS" yang memungkinkan "maintenance OS" sedikit/tidak diperlukan
- Aplikasi berjalan sebagai container melalui Podman
- Tidak ada "role/variant" lain seperti "setup untuk HA", misalnya
- Tidak menggunakan Dynamic Inventory (IIRC) nya Ansible
Karena menggunakan teknologi container, migrasi seharusnya relatif seamless berkat "deterministic build" dalam proses "packaging" software menjadi OCI image. Kita bisa menggunakan Image ID sebagai checksum dan bisa memastikan jika software yang berjalan di mesin B adalah software yang benar-benar sama dengan yang berjalan di mesin A.
Dan karena menggunakan Podman (container engine yang daemonless) saya tahu dimana tempat yang harus saya lihat: systemd services.
Voila!
Berkat dua informasi diatas, kita bisa "(over)simplify" setup nya dengan Docker Compose meskipun tidak se-handy yang ditawarkan oleh Podman melalui Systemd Services.
Sebelumnya, untuk deployment versi baru menggunakan perintah foremctl deploy yang singkatnya hanya melakukan:
- "Re-tag" image menjadi "current" dan "rollback"
- Stop running containers dan menampilkan "maintenance mode" saat proses rollout (no blue-green deployment fwiw)
- Tidak melakukan magic lain seperti "don't break the postgres when migrations are fucked up" or something
Sekarang, berarti tinggal melakukan hal serupa namun tidak ada fancy "maintenance mode" because who cares.
There is always Reverse Proxy
Dalam proses setup self-managed Forem, setidaknya ada 2 reverse proxy yang berjalan: Traefik sebagai TLS termination proxy dan OpenResty untuk everything else. Tidak ada panduan khusus untuk menjalankan Forem dibelakang CDN di dokumentasi resminya, namun bagaimanapun CDN hanyalah Reverse Proxy.
Sekarang, setidaknya ada... ehm, 5 reverse proxy yang berjalan. Dan ada alasan khusus untuk itu.
Karena saya cukup yakin jika 80% konten di website ini (atau pada umumnya) cache-able, saya membutuhkan CDN untuk mempercepat pemuatan website dan juga dapat membantu mengurangi beban server kentang saya di rumah. Bunny dipilih karena:
- Memiliki PoP di Jakarta, Indonesia
- Relatif cepat
- Relatif terjangkau
- Bukan Cloudflare (paling penting)
Karena Bunny tidak bisa langsung mengobrol dengan jaringan di rumah saya, saya membutuhkan mesin yang bertugas untuk menjembatani antara Bunny dengan jaringan rumah saya. Nanti kita cerita tentang ini di lain hari.
Mesin tersebut murni hanya untuk menjembatani dan paket ditukar melalui protokol Wireguard. Tapi kadang mesin tersebut digunakan sebagai "exit node" juga untuk menonton hentai untuk mengakali throttling. Harusnya ini gak perlu dibahas disini ya?
Anyway, bukan tidak mungkin untuk tidak menggunakan si "relay server" dan tanpa mengeluarkan biaya apapun berkat Cloudflare dan Argo Tunnel nya. Saya pernah menulisnya disini 2 tahun yang lalu dan sampai hari ini masih digunakan di domain pribadi.
Jika ingin menggunakan Argo Tunnel, setidaknya DNS harus diatur oleh Cloudflare (gratis) dan proses nya sesederhana mengubah nameserver ke sesuatu yang disediakan oleh Cloudflare.
Ah, Cloudflare pun bertindak sebagai penyedia CDN. Dan, ya, gratis juga.
Akibat dari sebab
Sekilas spek yang digunakan sekarang lebih besar sedikit daripada yang digunakan di DO, namun tentu saja server DO bukanlah server kentang yang jalanin kafka bentar kipas langsung bunyi kencang.
Dan juga tumpukan aplikasi forem ini bukanlah satu-satunya yang berjalan di server rumah saya. Ada belasan aplikasi lain yang berjalan (termasuk 2 kafka) dan selamat berkompetisi dalam menggunakan CPU dan memory. Ekspektasinya, aplikasi akan berjalan lebih lambat dari sebelumnya untuk beberapa kasus, seperti memuat apapun yang tidak/belum di cache oleh si Bunny.
Selain itu, jaringan rumah saya underdog. Selain dipakai ramai-ramai juga memiliki bandwidth yang terbatas. Pikirkan seperti bagaimana frustasinya menonton video 4K di Pornhub dan setiap 3 detik buffering. Dan juga saya mengatur QoS dengan limit 10 Mbps (1.25 MB/s) di router utama rumah saya, nah, sederhananya, saya menggunakan exit node tersebut untuk menghindari throttling yang saya buat sendiri.
Umumnya untuk menikmati video 4K setidaknya harus memiliki bandwidth 20 Mbps, throttling ini saya buat agar mendapatkan resolusi maksimal 1080p saat tidak sengaja mengakses YouT*ube agar konektivitas di perangkat lain tidak terganggu.Trivia
Berkat dari pengalaman sebelumnya, saya mengatur "failover" di jaringan rumah saya. Jika jaringan internet pertama sedang gangguan (sering, hello MNC Play) maka internet akan diteruskan ke jaringan internet lain (telklomslel). ISP kedua ini terkenal dengan ulahnya yang kadang bikin mempertanyakan kenapa kita lahir di negara ini, jadi jangan berharap banyak saat jaringan sedang di handle oleh doi (expect degradation and other random issues).
Tapi berbekal keyakinan saya jika 80% konten khususnya di website ini cache-able, seharusnya tidak perlu dipusingkan terkait performa ini dan ingat, forem dibuat menggunakan Ruby On Rails dan juga dengan bangga disisipkan di sidebar Forem ("Made with love and Ruby On Rails").
Penutup
Karena proses migrasi diyakini seamless, seharusnya tidak ada aksi yang harus dilakukan. Bahkan session di peramban pun saya rasa masih persist seakan tidak ada perubahan yang terjadi.
Dan karena saya salah satu penganut "make it work, make it right, make it fast" maka pemantauan berkelanjutan dan optimasi akan dilakukan khususnya saat langit sedang cerah dan kamu sedang lucu-lucunya (cringe).
Target saya adalah mendapatkan 80%+ di Cache HIT Ratio.
Ada known issue di postgres yang belum di fine-tune karena buru-buru. Seharusnya semua aplikasi menggunakan satu instance postgres yang sama di VM dengan nama arabasta yang sudah di fine-tune sampai ke batasnya.
Tapi selainnya, saya rasa tidak ada kendala?
Jika ada pertanyaan atau atau umpan balik, itulah gunanya kolom komentar.
Bye for now.
Top comments (0)