Studi kasus — 03
Homelab & eksperimen infrastruktur
Catatan lab tentang container, reverse proxy, dan server Linux
Pekerjaan infrastruktur praktis yang saya jalankan untuk proyek sendiri — situs statis dalam container, Caddy di depan, isolasi layanan, dan eksperimen lanjutannya.
- Peran
- Lab pribadi — membangun dan mengoperasikan
- Periode
- Berjalan
- Status
- Lab
Apa ini
Halaman ini adalah catatan lab, bukan produk. Isinya infrastruktur yang benar-benar saya jalankan untuk pekerjaan sendiri dan hal-hal yang sedang saya uji di atasnya. Setiap entri diberi status supaya tidak ada yang terbaca selesai padahal belum:
| Status | Arti |
|---|---|
| Running | Sedang dipakai, untuk sesuatu yang nyata |
| Testing | Sedang dikerjakan, belum dipercaya |
| Planned | Sudah dicatat, belum dibangun |
Running
Situs statis sebagai container. Situs pribadi dibangun di stage Node dan disajikan oleh image Caddy. Build-nya reproducible dari repositori, image runtime-nya kecil, dan deployment tidak bergantung pada Node yang terpasang di host. Containerfile situs ini adalah contoh terkini dari pola tersebut.
Satu proses per container. Setiap layanan punya image dan direktori data sendiri, bukan berbagi host panjang dengan semuanya. Upgrade dan rollback jadi membosankan, dan itu tujuannya.
Reverse proxy di depan, TLS di tepi. Caddy menangani TLS dan meneruskan ke container berdasarkan nama. Sertifikat diperbarui otomatis; container layanan tidak pernah memegang sertifikat publik sendiri.
Linux sebagai sistem operasi, bukan detail. Deployment, log, izin, dan firewall adalah hal yang saya konfigurasi dan baca langsung. Bekerja dari terminal adalah default, bukan cadangan.
Testing
Isolasi layanan di jaringan privat. Memindahkan layanan ke jaringan Podman di mana hanya proxy yang bisa dijangkau dari luar, bukan mempublikasikan port langsung. Pertanyaan terbukanya seberapa banyak konfigurasi diekspresikan lewat compose file versus unit systemd.
Backup dan jalur restore. Backup yang belum pernah direstore hanyalah hipotesis. Pekerjaannya menuliskan prosedur restore dan mengujinya di volume sementara sebelum jadwalnya dipercaya.
Monitoring tanpa platform. Log, systemctl status, dan satu pengecekan uptime biasanya cukup untuk beberapa layanan. Saya sedang menguji di mana batasnya sebelum stack monitoring penuh jadi masuk akal.
Planned
- Catatan disaster recovery untuk setiap layanan self-hosted: di mana datanya, bagaimana di-backup, dan bagaimana membangunnya ulang.
- Batas resource per container supaya satu layanan yang kacau tidak menjatuhkan host.
- Diagram jaringan lab yang tetap akurat — yang sekarang ada di kepala saya, dan itu bukan media penyimpanan yang bisa diandalkan.
Yang ingin saya pelajari
Tujuannya bukan menjalankan sebanyak mungkin layanan. Tujuannya memahami mode kegagalan: apa yang terjadi saat container restart di tengah penulisan, saat sertifikat kedaluwarsa, saat DNS menunjuk host yang salah, atau saat disk penuh tengah malam.
Itu kumpulan kekhawatiran yang sama dengan sistem universitas yang saya kerjakan, hanya dengan taruhan lebih rendah dan kebebasan lebih besar untuk merusak sesuatu. Kalau sebuah pola bertahan di sini, saya lebih percaya memakainya di produksi.
Catatan terkait
Deployment container dan konfigurasi reverse proxy ditulis di catatan teknik: