New Project Stack Workflow: From Templates to a Running Project

New Project Stack Workflow: From Templates to a Running Project adalah prosedur yang saya jalankan setiap kali project baru butuh infrastrukturnya: logging, storage, messaging, gateway di depan semuanya, dan akhirnya aplikasinya sendiri. Titik awalnya seperangkat template dan generator; titik akhirnya adalah saat request pertama melewati gateway sampai ke aplikasi dan telemetry-nya muncul di dashboard.

Halaman ini bukan tutorial. Yang diceritakan adalah cara saya mengubah "menyiapkan project baru" dari sesi panjang menyalin dan membetulkan menjadi rangkaian keputusan yang cukup diambil sekali: stack apa saja yang dibutuhkan project, dalam urutan apa stack itu lahir, langkah mana dikerjakan generator sendiri, mana yang tetap saya pegang, dan kenapa.

Sekilas

Pemicu	Project baru butuh infrastrukturnya, atau project yang sudah ada butuh service tambahan
Frekuensi	Sekali per project baru, dan sekali per service yang ditambahkan belakangan
Masukan	Nama project, network Docker-nya, kredensial tiap stack, dan stack apa saja yang dibutuhkan
Hasil	Setiap stack yang dibutuhkan project, healthy dan saling terhubung
Selesai bila	Request pertama melewati gateway sampai ke aplikasi, dan telemetry-nya muncul di dashboard

Pekerjaan berulangnya

Project saya tak pernah cuma satu container. Biasanya ia butuh stack log, database, object storage, kadang message broker, gateway yang mengurus login di depan semuanya, dan aplikasinya. Masing-masing adalah stack tersendiri, dan semuanya saling merujuk: gateway butuh alamat storage, broker, dan log collector; aplikasi butuh database-nya; semua mengirim telemetry ke stack log.

Cara gampang membangun semua itu adalah menyalin folder project terakhir lalu menyuntingnya, dan justru cara itulah yang membawa nama lama, kredensial lama, dan data lama ke project baru tanpa ada yang sadar. Karena itu setiap jenis stack mendapat generator sendiri yang dibangun dari template, dan generator-generator itu mendapat urutan. Prosedur di bawah adalah urutan tersebut, beserta alasan-alasannya.

Alurnya

1. Tentukan stack yang dibutuhkan project, lalu siapkan network-nya.
2. Generate stack log.
3. Generate storage, object storage, dan broker, sesuai kebutuhan.
4. Generate gateway yang mengarah ke semuanya.
5. Generate aplikasinya.
6. Daftarkan aplikasi ke gateway, lalu pasang nginx di depannya.
7. Buktikan dengan request pertama.

Langkah dan keputusan di baliknya

1. Tentukan stack yang dibutuhkan project. Tak setiap project butuh broker atau object storage, dan stack yang tak dibutuhkan tetap harus diperbarui, di-backup, dan diawasi. Memilih adalah langkah manual dan datang paling awal. Semua generator saya berbagi satu bentuk — satu file per tool, cara bertanya yang sama, jawaban yang sama lewat environment variable, dan satu variable yang melewati semua konfirmasi — jadi generator mana pun yang saya pilih, perilakunya seragam.

2. Siapkan network project. Setiap stack milik satu project bergabung ke satu network Docker yang dinamai menurut project itu. Generator pertama yang saya jalankan memakai network yang sudah ada atau membuatnya, dan setiap generator membaca alamat gateway network itu dari Docker, bukan menghitungnya dari subnet; di alamat itulah stack-stack mempublikasikan port-nya. Setiap stack menyimpan datanya di bawah satu direktori berprefix yang disusun mengikuti folder stack, jadi stack milik project berbeda, atau environment berbeda dari project yang sama, tak pernah menulis ke data satu sama lain.

3. Generate stack log paling dulu. Stack log adalah tujuan laporan semua stack lain, jadi ia datang sebelum mereka: ketika storage, broker, gateway, dan aplikasi menyala, sudah ada collector yang siap menerima telemetry-nya, dan start pertama mereka pun terlihat. Generator-nya menyalakan collector, Elasticsearch, dan Kibana dalam urutan yang mereka butuhkan dan menyiapkan dashboard, jadi data sudah tampil sejak menit pertama.

4. Generate storage dan object storage. Stack database membuat setiap database tambahan dengan owner sendiri dan dinding di antara mereka; stack object storage menyalakan MinIO dari direktori data kosong dengan kredensial baru lalu membuat bucket privat dan publik. Tak satu pun membawa apa-apa dari template asalnya.

5. Generate broker, bila project membutuhkannya. Generator broker menulis broker MQTT dan AMQP yang tiap pintu masuk publiknya hanya menerima satu jenis kredensial, dan token-nya terikat ke namanya sendiri. Ia datang sebelum gateway karena gateway mem-publish event-nya ke broker dan butuh alamatnya.

6. Generate gateway yang mengarah ke semua stack sebelumnya. Generator gateway menanyakan alamat object storage wrapper, endpoint log collector, dan broker, karena itulah ia datang sesudah ketiganya: pada titik ini alamat-alamat itu sudah ada dan bisa diperiksa, bukan ditebak. Ia menanam administrator pertama dan rute pertama ke echo server kecil, jadi gateway bisa dites sebelum aplikasinya ada.

7. Generate aplikasinya. Generator aplikasi membaca fakta-faktanya dari aplikasi itu sendiri: port dari Dockerfile-nya, konfigurasi dari foldernya sendiri, dan tempat konfigurasi itu di-mount. Bila aplikasi punya database sendiri, ia menunggu database itu healthy sebelum start. Ia datang paling akhir di antara stack karena dialah yang bergantung pada semua yang lain.

8. Daftarkan aplikasi ke gateway. Langkah ini tetap manual. Mendaftarkan backend lewat management API gateway, yang hanya menerima super administrator yang sudah login, dan mengimpor permission aplikasi adalah langkah yang saya tinjau sebelum dijalankan, karena tanpanya setiap user biasa ditolak sebelum request-nya sampai ke aplikasi.

9. Pasang nginx dan sertifikat di depannya. Lalu lintas publik mencapai stack-stack lewat nginx di host, yang mengakhiri TLS. Mengaktifkan nginx butuh hak lebih tinggi, jadi generator hanya menulis konfigurasinya dan bertanya dulu sebelum memasangnya, sedangkan sertifikat datang dari certificate authority, bukan dari generator. Langkah ini sengaja manual: inilah saat project mulai bisa dijangkau dari luar.

10. Buktikan dengan request pertama. Container yang healthy bukan definisi selesai. Request pertama dikirim lewat gateway ke aplikasi dalam keadaan login, lalu trace-nya dicari di dashboard stack log. Baru ketika keduanya terjadi, infrastruktur project itu dianggap selesai.

Yang saya otomatiskan, dan yang sengaja tidak

Langkah	Otomatis atau manual	Alasan
Memilih stack	manual	kebutuhan project adalah keputusan rancangan, bukan nilai bawaan
Menjawab pertanyaan generator	manual, atau dari environment variable	nama dan kredensial milik project; jawaban yang sama bisa diputar ulang untuk membangun kembali
Network, direktori data, kepemilikan	otomatis	kesalahan di sini senyap, dan generator tak pernah lupa satu pun
Membuat dan menyalakan tiap stack	otomatis	urutan start, seed, dan setup selalu sama setiap kali
Mendaftarkan aplikasi ke gateway	manual	butuh super administrator yang login, dan permission-nya layak ditinjau
nginx dan sertifikat	manual	butuh hak lebih tinggi, dan inilah saat project menjadi publik
Request pertama	manual	inilah bukti bahwa semua stack bekerja bersama, bukan satu per satu

Saat gagal

Saya mencari tahu di mana putusnya sebelum memutuskan apa yang harus dilakukan, dan generator memudahkannya dengan menunggu setiap service melapor healthy lalu menyatakan terus terang bila ada yang tidak.

Bila satu stack tak kunjung healthy, generator-nya menyerah sesudah menunggu sekitar dua menit dan menyebut service mana yang ditunggunya. Penyebabnya ada di keluaran service itu sendiri, dibaca dengan docker compose logs di folder stack-nya: password yang salah, direktori yang tak bisa ditulisi, ketergantungan yang tak pernah menjawab.

Bila port bentrok atau satu stack tak bisa menjangkau stack lain, penyebabnya biasanya network: nama network yang salah, subnet yang berbeda dari perkiraan, atau port yang di-bind ke alamat yang tak dipakai stack lain. docker network inspect memperlihatkan gateway dan subnet network yang sebenarnya, yang juga dibaca setiap generator.

Sesudah itu saya generate ulang dari nol. Setiap generator menawarkan untuk menimpa folder yang sudah ada, dan jawaban yang sama bisa diberikan lagi lewat environment variable. Stack yang baru saja dibuat belum menyimpan apa pun yang layak dipertahankan, jadi membangunnya ulang dari jawaban yang sudah dibetulkan lebih cepat dan lebih bersih ketimbang memperbaikinya dengan tangan.

Kenapa urutan ini

Setiap stack lahir sesudah stack-stack yang dirujuknya. Stack log paling dulu karena semua yang lain melapor kepadanya, dan proses start yang tak terlihat tak bisa di-debug. Storage, object storage, dan broker menyusul karena mereka tak bergantung pada apa pun selain network. Gateway berikutnya karena ia butuh alamat mereka, dan aplikasi datang sesudah gateway karena ia bergantung pada semuanya. Langkah-langkah manual datang paling akhir karena merekalah yang membuka project ke dunia luar, dan itu baru boleh terjadi setelah semua yang ada di belakangnya terbukti.

Variasi

Project tanpa broker atau object storage. Generator keduanya cukup tak dijalankan, dan gateway diberi tahu bahwa broker dinonaktifkan. Urutan langkah yang tersisa tetap sama.

Menambah service ke project yang sudah ada. Aplikasi kedua hanya butuh generator aplikasi, bergabung ke network project yang sudah ada, lalu didaftarkan ke gateway. Stack-stack yang sudah ada tak disentuh.

Menguji generator itu sendiri. Setiap kali mengubah generator, saya menjalankannya di mode otomatis, dengan setiap jawaban diberikan lewat environment variable dan setiap konfirmasi dilewati, lalu membiarkannya membangun dan menyalakan stack lengkap. Generator yang tak bisa berjalan tanpa orang di depan keyboard tak bisa dites dengan cara ini, dan karena itulah semuanya mendukung mode tersebut.

Istilah

Stack

Sekumpulan container yang dideskripsikan satu file compose dan dinyalakan bersama, misalnya database beserta cache-nya.

Generator

Script yang menanyakan nilai-nilai project lalu menulis folder stack lengkap dari template.

Template

Folder berisi file yang disalin dan diisi generator, dengan nilai khas project yang diganti.

Docker network

Network privat yang diikuti container supaya bisa saling menjangkau lewat nama.

Healthy

Status yang dilaporkan container ketika health check-nya sendiri lolos, yang tak mengatakan apa pun soal apakah ia bekerja bersama yang lain.

TLS terminator

Server yang menangani enkripsi untuk service di belakangnya dan meneruskan lalu lintas yang sudah didekripsi kepada mereka.

Environment variable

Nilai bernama yang diberikan ke program dari luar, di sini dipakai untuk menjawab pertanyaan generator di muka.