PT Instrumeta Teknologi Nusantara

Arsitektur Infrastruktur Edunusa

Dokumen ini menjelaskan bagaimana platform pendidikan digital itn-edunusa berjalan: mulai dari kode yang ditulis developer, sampai menjadi layanan yang dipakai pengguna, termasuk siapa saja yang boleh mengaksesnya dan bagaimana semuanya dipantau.

Docker single-host VM Proxmox Traefik + Kong Vault Vector → VictoriaLogs → Grafana Diverifikasi 2026-09-12

Cara baca: pilih tingkat detail yang Anda butuhkan.

Mode Lengkap menampilkan nama teknis, alamat IP, dan konfigurasi.

00Ringkasan

Lima kalimat yang menjelaskan seluruh sistem. Sisanya hanya memperdalam bagian ini.

Video ringkasan · versi Desktop · buka di tab baru

Analogi singkat

Bayangkan sebuah gedung kantor. Proxmox adalah tanahnya, satu mesin virtual adalah gedungnya, dan Docker adalah rak-rak di dalam gedung yang masing-masing berisi satu aplikasi. Traefik adalah resepsionis yang mengarahkan setiap tamu ke ruangan yang benar, Kong adalah loket khusus yang hanya melayani permintaan data, dan Vault adalah brankas kunci yang tidak boleh dibuka sembarang orang.

  1. Developer menulis kode dan mendorongnya ke GitHub. Tidak ada yang di-upload manual ke server.
  2. GitHub Actions membangun aplikasi menjadi image, yaitu paket siap jalan, lalu menyimpannya di GHCR.
  3. Server menarik image itu dan menjalankannya sebagai container, satu container per layanan per environment.
  4. Pengguna masuk lewat Traefik. Halaman web dilayani langsung, sedangkan permintaan data lewat Kong dulu.
  5. Semua yang terjadi tercatat. Log tiap container dikumpulkan Vector, disimpan VictoriaLogs, dan dilihat di Grafana.

Tiga environment

production untuk pengguna nyata, staging untuk uji coba sebelum rilis, development untuk tim internal. Ketiganya terpisah, termasuk database-nya.

Satu server, banyak container

Semuanya berjalan di satu mesin virtual. Tidak ada Kubernetes. Pemisahan antar layanan dilakukan lewat container dan jaringan Docker.

Dua pintu masuk

Publik hanya bisa membuka production dan staging. Sisanya, termasuk semua alat internal, wajib lewat VPN kantor.

01Lapisan platform

Di mana sebenarnya semua ini berjalan.

Bahasa sederhana

Server fisiknya tidak dipakai langsung. Di atasnya dijalankan satu komputer virtual bernama edunusa-tools, dan di dalam komputer virtual itulah semua layanan hidup sebagai container. Jadi ada empat lapis: server fisik, komputer virtual, Docker, lalu container.

Proxmox VE — hypervisor di server fisik VM edunusa-tools — Ubuntu 24.04.4 LTS · 32 vCPU · 24 GB RAM Docker Engine Traefikreverse proxy KongAPI gateway Frontend× 3 environment Backend× 3 environment Postgres× 3 environment MinIOpenyimpanan file Vaultbrankas kunci Vectorpencatat log
Proxmox VE — server fisik VM edunusa-tools Ubuntu 24.04.4 · 32 vCPU · 24 GB RAM Docker Engine Traefik reverse proxy Kong API gateway Frontend × 3 environment Backend × 3 environment Postgres × 3 environment MinIO penyimpanan berkas Vault brankas kunci Vector pencatat log
Empat lapisan, dari server fisik sampai container layanan.

Spesifikasi mesin virtual

AspekDetail
Hostnameedunusa-tools
Sistem operasiUbuntu 24.04.4 LTS x86_64 · kernel 6.8.0-136
HypervisorKVM/QEMU — Standard PC i440FX + PIIX (pc-i440fx-10.1)
CPUQEMU Virtual 2.5+ · 32 vCPU @ 2.099 GHz
Memori19.930 MiB terpakai dari 24.023 MiB
Jaringan111.221.43.101 (publik/VPN) + bridge Docker 172.17–172.22
Lain-lain821 paket dpkg · bash 5.2.21 · uptime ±48 hari

Konsekuensi: karena semuanya satu mesin virtual, kapasitas RAM adalah batas nyata. Saat ini sekitar 83 persen memori sudah terpakai, jadi penambahan layanan baru perlu dihitung dulu.

02Dari kode ke container

Perjalanan satu perubahan kode sampai berjalan di server.

Bahasa sederhana

Developer tidak pernah menyentuh server secara langsung. Mereka cukup mengirim kode ke GitHub, lalu robot otomatis yang mengemas kode itu menjadi paket siap pakai, menyimpannya di gudang, dan menyuruh server mengambil serta menjalankannya.

Developer tulis & commit kode git push GitHub repo itn-edunusa-* trigger GitHub Actions test → scan → build → push template reusable dipakai semua repo itn-edunusa-pipeline-templates simpan GHCR gudang image server menarik image perintah deploy lewat SSH Runner di server self-hosted · be-1..7 & fe-1..7 docker pull lalu compose up memakai secret dari Vault jalankan Container aktif satu container per layanan per environment production staging · development Vault — sumber tunggal semua kredensial variabel environment · kunci SSH · token · kubeconfig tidak ada rahasia yang disimpan di dalam repo login AppRole, lalu ambil rahasia dipakai saat deploy Rollback deploy ulang tag image lama, tanpa build ulang
Developer tulis & commit kode git push GitHub repo itn-edunusa-* trigger GitHub Actions test → scan → build → push template reusable dipakai semua repo itn-edunusa-pipeline-templates simpan image GHCR gudang image server menarik image Runner di server self-hosted · be-1..7 & fe-1..7 docker pull lalu compose up memakai secret dari Vault jalankan Container aktif satu container per layanan production · staging · development Vault env · kunci SSH · token · kubeconfig dipakai oleh GitHub Actions dan Runner tidak ada rahasia di dalam repo
Alur build dan deploy. Garis merah putus-putus adalah pengambilan kredensial dari Vault.

Apa yang memicu pipeline

Workflow cicd.yml di tiap repo dipicu oleh push ke salah satu dari tiga branch, dan nama branch itulah yang menentukan environment tujuannya:

on: push: branches: [development, staging, production]

Tidak ada persetujuan manusia sebelum production. Push ke branch production berjalan terus sampai container di server diganti. Jadi pola yang dipakai di sini adalah Continuous Deployment, bukan Continuous Delivery.

Gerbang persetujuannya sebenarnya sudah tersedia di template — job container_build_push dan deploy punya environment: yang bisa diisi — tetapi nilainya hanya terisi bila use_github_environment (atau variabel repo USE_GITHUB_ENVIRONMENT) dinyalakan. Nilai bawaannya false dan repo belum menyalakannya, sehingga GitHub tidak memasang perlindungan apa pun.

Yang menahan rilis buruk bukan persetujuan, melainkan health check dan rollback otomatis di langkah 8 dan 9 di bawah.

Tahapan yang dijalankan pipeline

  1. Checkout — kode diambil dari repo yang memicu pipeline.
  2. Test — pemeriksaan otomatis dijalankan saat Pull Request lewat ci.pr.yml, sebelum kode digabung.
  3. Security audit — pemeriksaan dependensi sesuai runtime, ditambah Gitleaks untuk memastikan tidak ada rahasia yang ikut ter-commit.
  4. Build image — kode dikemas menjadi image dengan penanda commit, sehingga setiap build bisa dilacak asal-usulnya.
  5. Pindai image — Trivy memeriksa kerentanan pada image yang baru dibangun, dan Syft menghasilkan SBOM. Mode bawaannya strict, artinya temuan yang memenuhi syarat menggagalkan pipeline sebelum image dipakai.
  6. Push ke GHCR — image disimpan di registry. Inilah yang membuat rollback murah, karena versi lama masih tersimpan.
  7. Deploy — server diperintahkan lewat SSH untuk menarik image dan menjalankan ulang container.
  8. Health check — container yang baru dipanggil berulang kali sampai membalas kode status yang diharapkan. Jalur internal dan jalur publik diperiksa dengan cara yang berbeda.
  9. Rollback otomatis — bila ada langkah deploy yang gagal, termasuk health check, pipeline menjalankan rollback-single-host untuk mengembalikan container ke versi sebelumnya tanpa menunggu operator.

Perlu dicatat bahwa langkah 8 adalah pemeriksaan sekali saat deploy, bukan pengawasan yang terus berjalan. Ia menangkap rilis yang gagal, tetapi tidak menangkap container yang memburuk beberapa jam kemudian.

Detail teknis pipeline

Repo itn-edunusa-pipeline-templates adalah satu-satunya sumber kebenaran untuk semua pipeline. Strukturnya berlapis:

consumer (workflow di tiap repo) → runtime-specific service (nodejs / golang / hono / java) → base service

Penamaan image mengikuti pola berikut:

ghcr.io/pt-instrumeta-teknologi-nusantara/itn-edunusa-<service>-<fe|be>:<environment>-<commit> contoh nyata: itn-edunusa-cbt-fe:production-b692530 itn-edunusa-be:development-beeef6b
KomponenPeran
ci.pr.ymlWorkflow CI yang berjalan pada Pull Request.
cicd.ymlWorkflow konsumen di tiap repo. Dipicu push ke development, staging, atau production, lalu memanggil template yang sesuai.
container-build-pushMembangun image, memindainya dengan Trivy, menghasilkan SBOM lewat Syft, lalu mendorongnya ke registry.
gitleaks-scanMemeriksa apakah ada rahasia yang ikut ter-commit.
deploy-single-hostAction yang menjalankan docker pull dan compose up di server lewat SSH.
health-check-frontendMemanggil ulang container setelah deploy sampai membalas kode status yang diharapkan. Ada versi terpisah untuk jalur internal dan publik, juga untuk backend.
rollback-single-hostDijalankan otomatis dengan if: failure() bila deploy atau health check gagal.
rollback-to-tagWorkflow manual untuk kembali ke tag image lama tanpa membangun ulang.
ghcr-retention-cleanupMembersihkan image lama di registry agar tidak menumpuk.
Runner self-hostedTujuh runner backend dan tujuh runner frontend, berjalan di server yang sama.

03Vault — pengelolaan rahasia

Password, kunci, dan token disimpan di satu tempat, bukan tersebar di kode.

Bahasa sederhana

Vault adalah brankas terpusat. Pipeline tidak menyimpan password di dalam kode atau di GitHub. Setiap kali butuh, pipeline memperkenalkan diri ke Vault dengan sepasang identitas, lalu meminjam rahasia yang diperlukan hanya untuk sekali proses. Brankasnya sendiri hanya bisa dibuka dari jaringan kantor atau VPN.

Apa yang disimpan

  • Variabel environment untuk tiap layanan
  • Kunci privat SSH untuk deploy
  • Token dan API key
  • Kubeconfig

Cara pipeline masuk

Memakai AppRole, yaitu pasangan role_id dan secret_id yang ditukar menjadi token sementara. Nilainya di-mask agar tidak pernah muncul di log build.

Siapa yang boleh membuka

Hanya dari VPN kantor. Dibatasi dua lapis sekaligus: firewall sistem operasi dan daftar IP di Traefik.

AspekDetail
Alamattools-vault.edunusa.co.id
Entrypointwebsecure · sertifikat mytlschallenge
Jaringantraefik-internal
Middlewareedunusa-internal-allow@file
Allowlist IP39.194.0.0/10 (kantor) + 111.221.43.104/32 (OpenVPN)
AutentikasiAppRole (role_id + secret_id), nilai di-mask

Action yang berhubungan dengan Vault

ActionFungsi
vault-authLogin AppRole dan menghasilkan token Vault sementara.
fetch-vault-fieldsMembaca secret per layanan dari KV store, dipakai sebagai variabel build dan deploy.
resolve-ssh-credentialsMengambil kunci SSH dari Vault, bukan dari GitHub Secrets.
resolve-kubeconfigMengambil kubeconfig dari Vault.

04Jalur traffic saat aplikasi dipakai

Ke mana permintaan pengguna mengalir setelah semua container berjalan.

Bahasa sederhana

Semua permintaan masuk lewat satu pintu bernama Traefik. Kalau yang diminta adalah halaman web, Traefik langsung menyerahkannya ke container frontend. Kalau yang diminta adalah data, permintaan itu dilewatkan dulu ke Kong sebagai loket pemeriksaan, baru diteruskan ke backend.

Zona internal — hanya bisa dibuka dari VPN kantor Pengguna publik siswa, guru, umum HTTPS Tim internal dari kantor / OpenVPN Gerbang akses firewall + daftar IP hanya IP terdaftar Traefik pintu masuk tunggal, port 443 memasang sertifikat TLS otomatis dari Let’s Encrypt mengarahkan ke container tujuan halaman web Frontend React · Vue · Next.js cbt · sso · spp · rapor production & staging: terbuka untuk publik development: hanya dari VPN tidak melewati Kong permintaan data / API Kong API Gateway satu instans terpisah per environment memeriksa autentikasi dan batas laju production staging development teruskan Backend Node.js · Golang Hono · Java wapi · simultan pelita · presensi alat internal & dashboard Alat internal Grafana · Vault · pgAdmin4 Node-RED · EMQX · OpenWA Redis · Kong tools jaringan traefik-internal tertutup dari internet publik baca & tulis data Data & penyimpanan PostgreSQL 18 × 3 environment MinIO untuk berkas koneksi antar container tidak dibatasi daftar IP akses manusia tetap wajib VPN
1 · Pengguna publik membuka halaman Pengguna publik siswa, guru, umum HTTPS :443 Traefik pintu masuk tunggal, memasang TLS langsung, tanpa Kong Frontend cbt · sso · spp · rapor production & staging: terbuka publik development: hanya dari VPN 2 · Permintaan data lewat gateway Traefik permintaan API Kong API Gateway satu instans per environment memeriksa autentikasi dan batas laju teruskan Backend Node.js · Golang · Hono · Java wapi · simultan · pelita · presensi baca & tulis data Data & penyimpanan PostgreSQL 18 × 3 · MinIO lewat jaringan Docker internal 3 · Tim internal membuka alat internal Tim internal dari kantor atau OpenVPN lewat VPN Gerbang akses firewall + daftar IP terdaftar lolos, lalu ke Traefik Alat internal Grafana · Vault · pgAdmin4 · Node-RED EMQX · OpenWA · Redis · Kong tools
Frontend dilayani langsung oleh Traefik. Backend selalu melewati Kong. Zona bergaris merah hanya terbuka dari VPN.

Frontend: langsung dari Traefik

Setiap container frontend membawa aturan domainnya sendiri, jadi Traefik tahu container mana yang harus melayani sebuah alamat. Frontend tidak melewati Kong.

Backend: wajib lewat Kong

Container backend sengaja tidak diberi aturan domain di Traefik. Semua akses API melewati Kong, yang menangani autentikasi, pembatasan laju, dan perutean.

Kong terpisah per environment

Ada tiga instans Kong, satu untuk production, staging, dan development. Perubahan aturan di satu environment tidak menyentuh yang lain.

Bukti konfigurasi

Label pada container frontend development, yang menegaskan pembatasan berbasis daftar IP:

traefik.http.routers.itn-edunusa-cbt-fe-development-ctr.rule = Host(`development-cbt.edunusa.co.id`) traefik.http.routers.itn-edunusa-cbt-fe-development-ctr.middlewares = edunusa-internal-allow@file

Container backend menonaktifkan Traefik sepenuhnya lewat traefik.enable=false, dan tiap gateway dinamai kong-gateway-{production|staging|development}.

05Siapa boleh mengakses apa

Satu tabel yang menjawab pertanyaan paling sering muncul.

Komponen Dari internet Dari VPN kantor Catatan
Frontend productionBisaBisaTanpa pembatasan IP.
Frontend stagingBisaBisaTanpa pembatasan IP.
Frontend developmentTidakBisaDibatasi middleware daftar IP.
API backendLewat KongLewat KongContainer backend tidak punya rute Traefik sendiri.
VaultTidakBisaDibatasi firewall dan daftar IP sekaligus.
GrafanaTidakBisaDashboard log, port 5000.
PostgreSQLTidakBisaUntuk operator. Backend mengaksesnya lewat jaringan Docker.
MinIO, pgAdmin4, Node-RED, EMQX, OpenWA, RedisTidakBisaSemua berada di jaringan traefik-internal.

Perbedaan penting: pembatasan daftar IP berlaku untuk akses manusia dari luar. Komunikasi antar container di dalam server, misalnya backend membaca database, berjalan di jaringan Docker internal dan tidak melewati pembatasan itu.

Dua lapis pembatasan bekerja bersamaan:

  • UFW — firewall di tingkat sistem operasi, berlaku sebelum permintaan sampai ke container.
  • Middleware Traefik edunusa-internal-allow@file — daftar IP 39.194.0.0/10 (kantor) dan 111.221.43.104/32 (OpenVPN).

06Data & penyimpanan

Di mana data aplikasi disimpan.

PostgreSQL 18

Tiga instans terpisah, satu per environment. Data production tidak bercampur dengan staging maupun development.

  • postgresql-database-production
  • postgresql-database-staging
  • postgresql-database-development

MinIO

Penyimpanan berkas dengan antarmuka yang kompatibel dengan Amazon S3. Bucket dipisah per environment, salah satunya dipakai untuk menyimpan media OpenWA.

07Pencatatan & pemantauan

Bagaimana tim tahu ada yang bermasalah, dan di layanan mana.

Bahasa sederhana

Setiap container terus mencetak catatan tentang apa yang sedang dikerjakannya. Vector mengumpulkan semua catatan itu dan memberinya label, misalnya berasal dari environment apa dan layanan mana. VictoriaLogs menyimpannya, lalu Grafana menampilkannya sebagai dashboard yang bisa dicari.

Semua container frontend, backend, database, Traefik, Kong, Vault keluaran layar tiap container docker socket Agen di server lain Vector agent kirim lewat HTTP port 8687 Vector mengumpulkan & memberi label label: environment, jenis log, nama layanan, asal server membaca format JSON bila ada, selebihnya teks biasa simpan VictoriaLogs gudang penyimpanan log log diindeks agar bisa dicari per environment, layanan, dan jenis log versi 1.51 query Grafana dashboard log aplikasi & infrastruktur, dipisah per environment hanya dari VPN
Semua container di VM edunusa-tools docker socket Agen server lain Vector agent HTTP port 8687 Vector mengumpulkan & memberi label label: environment, jenis log, nama layanan, asal server membaca JSON bila ada, selebihnya teks simpan VictoriaLogs gudang penyimpanan log · versi 1.51 diindeks agar bisa dicari per environment, layanan, dan jenis log query Grafana dashboard log aplikasi & infrastruktur dipisah per environment hanya bisa dibuka dari VPN
Log mengalir satu arah, dari container sampai ke dashboard.

Detail konfigurasi logging

TahapKonfigurasi
Sumber 1 Docker socket unix:///var/run/docker.sock, menangkap stdout dan stderr semua container. Dikecualikan: portainer, hermes, omniroute.
Sumber 2 HTTP listener pada port 8687, menerima kiriman dari Vector agent di server lain.
Pelabelan environment diturunkan dari akhiran nama container. log_type memisahkan log aplikasi dari log infrastruktur seperti Postgres, Redis, Vault, MinIO, Kong, dan Traefik. source_server menandai asal server.
Pengiriman http://victorialogs:9428/insert/elasticsearch/ dengan mode bulk.
Stream field terindeks environment, service, log_type, source_server.
Visualisasi Grafana pada port 5000, dengan VictoriaLogs sebagai datasource.

08Jaringan Docker

Container dipisahkan ke beberapa jaringan agar akses tidak saling bocor.

Nama jaringanFungsi
bridgeJaringan bawaan Docker.
traefikContainer yang dirutekan oleh Traefik, baik publik maupun internal.
traefik-externalTempat frontend, backend, dan Kong terhubung untuk menerima rute Traefik.
traefik-internalAlat internal dan database. Hanya terbuka dari VPN, dengan tambahan daftar IP.
kong-*Jaringan gateway per environment untuk backend.

09Ringkasan keamanan

Tujuh keputusan yang membentuk postur keamanan sistem ini.

Permukaan publik sengaja sempit

Dari internet, hanya frontend production dan staging yang terbuka. Semua sisanya tertutup.

Pembatasan berlapis dua

Firewall sistem operasi dan daftar IP di Traefik bekerja bersamaan. Satu lapis gagal, lapis lain masih menahan.

Rahasia terpusat

Semua kredensial hanya ada di Vault, tidak di repo dan tidak di GitHub Secrets. Nilainya di-mask agar tidak bocor lewat log build.

Image hanya dari CI

Container hanya boleh berjalan dari image yang dibangun pipeline dan tersimpan di GHCR. Tidak ada build manual di server.

Image dipindai sebelum dipakai

Trivy memeriksa kerentanan tiap image yang baru dibangun, dengan mode bawaan strict sehingga temuan yang memenuhi syarat menggagalkan pipeline. Syft menghasilkan SBOM, dan Gitleaks menjaga agar rahasia tidak ikut ter-commit.

Enkripsi otomatis

Semua alamat *.edunusa.co.id memakai TLS yang diperbarui Traefik secara otomatis.

Pemulihan cepat

Deploy yang gagal health check dikembalikan sendiri oleh pipeline lewat rollback-single-host. Untuk pemulihan yang disengaja, tersedia rollback-to-tag ke tag image lama tanpa build ulang.

Belum ada gerbang sebelum production

Push ke branch production langsung ter-deploy tanpa persetujuan. Perlindungan environment GitHub sudah tersedia di template tetapi belum dinyalakan. Ini titik terlemah pada postur rilis, bukan pada postur jaringan.

Environment terisolasi

Frontend, backend, gateway, dan database dipisah per environment, sehingga percobaan di development tidak menyentuh data production.

10Glosarium

Istilah yang muncul di dokumen ini, dijelaskan tanpa jargon.

Container
Satu aplikasi beserta seluruh kebutuhannya, dibungkus agar bisa dijalankan di mana saja dengan hasil yang sama. Analogi: kotak makan siap saji.
Image
Cetakan yang dipakai untuk membuat container. Satu image bisa dijalankan berkali-kali. Analogi: resep beku yang tinggal dipanaskan.
Registry / GHCR
Gudang tempat image disimpan. GHCR adalah gudang milik GitHub yang dipakai di sini.
CI/CD
Proses otomatis yang menguji, mengemas, dan mengirim kode ke server tanpa langkah manual.
Runner
Program di server yang menerima dan menjalankan perintah dari GitHub Actions.
Reverse proxy
Perantara yang menerima semua permintaan dari luar dan meneruskannya ke layanan yang tepat. Di sini perannya dipegang Traefik.
API gateway
Pintu khusus untuk permintaan data, yang bisa memeriksa izin dan membatasi jumlah permintaan. Di sini perannya dipegang Kong.
Middleware
Aturan tambahan yang dijalankan sebelum permintaan diteruskan, misalnya memeriksa apakah IP pengirim terdaftar.
Vault
Brankas digital untuk password, kunci, dan token, dengan pencatatan siapa mengambil apa.
AppRole
Cara sebuah program membuktikan identitasnya ke Vault, memakai sepasang identitas dan bukan password manusia.
Environment
Salinan sistem yang terpisah. Production dipakai pengguna nyata, staging untuk uji akhir, development untuk tim.
VPN
Terowongan terenkripsi yang membuat perangkat dari luar seolah berada di dalam jaringan kantor.
Firewall / UFW
Penyaring yang memutuskan koneksi mana yang boleh masuk ke server, bekerja sebelum permintaan sampai ke container.
TLS
Enkripsi yang membuat alamat diawali https. Sertifikatnya diambil dan diperbarui otomatis oleh Traefik.
Rollback
Kembali ke versi aplikasi sebelumnya yang sudah terbukti aman.
Log
Catatan aktivitas yang dihasilkan setiap layanan, dipakai untuk menelusuri masalah.
MinIO / S3
Penyimpanan berkas seperti gambar dan dokumen, memakai cara kerja yang sama dengan layanan S3 Amazon.
Proxmox / VM
Perangkat lunak yang membagi satu server fisik menjadi beberapa komputer virtual yang saling terpisah.

11Catatan sumber

Dari mana isi dokumen ini berasal, dan apa yang belum terverifikasi.

Sumber kebenaran

  • Kondisi aktual server, diambil pada 8 September 2026.
  • Berkas workflow di repo itn-edunusa-pipeline-templates dan cicd.yml milik repo konsumen, dibaca langsung pada 12 September 2026.
  • Label Traefik yang terpasang pada container yang sedang berjalan.
  • Keluaran neofetch pada mesin virtual edunusa-tools.

Koreksi 12 September 2026. Versi sebelumnya menjelaskan tahapan pipeline tanpa menyebut pemicunya, sehingga mudah dibaca seolah-olah rilis ke production melewati persetujuan. Setelah berkas workflow dibaca langsung, ternyata push ke branch production berjalan sampai deploy tanpa gerbang apa pun. Pada kesempatan yang sama ditemukan pula tiga langkah yang sudah berjalan tetapi belum pernah didokumentasikan: pemindaian image oleh Trivy, pembuatan SBOM oleh Syft, serta health check yang diikuti rollback otomatis. Bagian 02 dan 09 sudah diperbarui.

Belum terverifikasi

  • Apakah API backend environment development juga dibatasi daftar IP seperti frontend-nya.
  • Apakah container frontend memanggil backend langsung lewat jaringan Docker, selain lewat Kong.
  • Kebijakan retensi log di VictoriaLogs, yaitu berapa lama log disimpan sebelum dihapus.
  • Prosedur backup dan pemulihan PostgreSQL serta MinIO.
  • Apakah variabel repo USE_GITHUB_ENVIRONMENT atau IMAGE_SECURITY_MODE diisi di setelan GitHub. Keduanya tidak terlihat dari berkas dan hanya bisa dipastikan dari halaman setelan repo. Dokumen ini menganggap keduanya memakai nilai bawaan, yaitu gerbang environment mati dan pemindaian image strict.
  • Apakah seluruh repo memanggil template versi @v2 yang sama. Yang diperiksa baru itn-edunusa-sso-fe.

Cara memperbarui dokumen ini: setiap perubahan pada label Traefik, penambahan environment, atau perubahan alur pipeline perlu tercermin di sini. Ubah juga tanggal verifikasi di bagian atas agar pembaca tahu seberapa baru isinya.