Sebelumnya gue udah menulis sekilas tentang edgy.network (#12), ditulisan ini gue akan membahas tentang prototype pertama gue dengan edgy.network. Jika kalian mengetahui kesalahan, tips, dsb tolong untuk beritahu since I'm not professional™ network engineer/sysadmin/devops, oke?
DNS
Untuk sekarang masih menggunakan third-party DNS yakni DNSimple. Ada rencana untuk menggunakan self-hosted DNS (via coredns.io), tapi masih difikirkan
Builder
Gue sudah membuat "simple" builder, yang mana "basically" cuma program sederhana Node.js yang bergantung dengan child_process.
Reverse Proxy
Masih menggunakan Nginx, di prototype kedua akan menggunakan traefik.
How it works?
Ada 4 langkah sederhana yang dilakukan untuk high-level view nya. Yakni:
Webhook
Ketika kita memutuskan untuk "deploy" (via git push), maka GitHub akan mengirimkan webhook ke endpoint kita, dan API kita akan membuat job baru untuk build. Nantinya, via CLI pun bisa.
Build
Dedicated worker akan memproses job tersebut (build), lalu membuat Docker image berdasarkan template yang sudah disediakan. Dan disini kita hanya membutuhkan artifak yang digenerate oleh platform yang kamu gunakan (Hugo? Next.js? Gridsome? Dsb)
Static Web Server
Template tersebut hanyalah Static Web Server yang dibuat menggunakan Node.js, yang memiliki beberapa fitur yang sudah dijanjikan (seperti HTTP/2, Brotli compression with gzip fallback, some caching strategies, dsb).
Proxy the request
Lalu Nginx mem-proxy request tersebut ke container yang sudah dibuat.
Screenshot diatas adalah directory tmp yang akan di flush setiap seminggu sekali. Artifact yang sudah dibuild oleh builder di copy ke directory baru yang ada di tmp (penamaannya menggunakan: {project-name}-{cuuid}).
Directory cert berisi Let's Encrypt certificate (wildcard), dan node_modules adalah dependensi yang digunakan untuk static server tersebut (spoiler alert: Fastify)
Berdasarkan engine yang sudah ditentukan (Gridsome? Next.js? Hugo?), si index.js akan meng-mount build artifact tersebut ke nama default directory yang sudah ditentukan di manifest pada build-time (docker).
Screenshot diatas adalah container-container yang ada. Berdasarkan stress test yang gue lakukan menggunakan vegeta, dari 4k req dalam 10 detik, server bisa meng-handle 2k req/s (status code 200, sisanya 0, bukan 500). Screenshot nya ada di ig story ku dan itupun hands-free :(
Some Notes
Ada beberapa catatan seputar edgy.network
Immutability
Gue pelajari dari layanan-layanan yang sudah ada, dan ya, setiap deployment akan di design immutable juga. Setiap container memiliki identifier khusus (kuncinya: container-name.edgy.network). Container name nantinya diambil dari project name untuk base nya, bila konflik, akan ditambah beberapa "penghias" via cuuid slug.
Dan ada rencana juga untuk membuat "staging" deployment via GitHub PR dengan identifier khusus.
Caching strategies
Nantinya by default expire 1 tahun, dengan embel-embel immutable. Also read this.
Cache validation masih bergantung dengan Etag. Nanti klo udah buat edge server, akan dibuat yang lebih kompleks.
Custom domain
Sejujurnya, untuk sekarang pointing nya masih ke IP (via A record) and I know this is bad (from security & user perspectives). Nantinya, akan dibuat via CNAME karena seperti yang kita tau tidak ada yang bisa memprediksi IP mana yang harus di point (untuk sekarang masih pakai 1 server, belum cluster).
Maksudnya, daripada harus point ke IP, mending ke unique url yang sudah dibuat. Untuk point custom domain sendiri pun masih ada masalah (di SSL certificate) seperti ini contohnya tapi gue yakin masalah ini gak akan sulit-sulit amat.
Why Nginx?
Karena gue sudah terbiasa dengan nginx, khususnya untuk reverse proxy, jadi gue pakai itu
Why Traefik?
Karena semua deployment dibungkus dengan docker container, juga nantinya akan menggunakan docker swarm. Sekaligus gue akan bereksperimen dengan "Mini DIY CDN", yang maksudnya setiap request akan di-serve oleh edge server terdekat denga geo ip yang dimaksud (untuk sekarang masih dari jakarta aja)
Jadi, kalau ada request dari surabaya, maka nantinya request tersebut dihandle oleh edge server yang terdekat (rencana jogja, mungkin nanti bikin juga di sby). Mengapa melakukan ini? Sesuai dengan misi edgy.network :))
Some Question
Backup
Hampir rata-rata layanan menyimpan file-file di cloud provider via object storage. Gue ngerti, salah satunya untuk alasan backup. Gak mungkin dong ada kesalahan di server, lalu semua user disuruh melakukan deploy ulang.
Kenapa gak disimpen di server sendiri? Andaikata server kita bermasalah di harddisk, kita bisa apa? Meskipun katanya don't put all your eggs in one basket, tapi gue lebih mempecayai 3rd party karena alasan SLA.
Jadi kemungkinan gue juga akan menggunakan itu
Builder Caveat
Builder sederhana ini masih bergantung dengan hmm threshold, me-limit 3 job process. Selebihnya, pending dan tunggu sampai builder sudah siap digunakan (n < 3). Jelas ini tidak efektif, dan nantinya akan menggunakan cluster API nya Node.js.
Mengapa melakukan ini? Demi menghindari software fault, atau yang lebih parah server fault.
Security & Scalability
You know, I am Frontend Developer, not Backend Developer. Dan kebetulan pernah menjadi fullstack developer, sebelum benar-benar ingin fokus menjadi Frontend Developer Professional™
Dan gue sepertinya membutuhkan "security advisor" untuk project ini. Basic-basic security seperti only use ssh key for root user, ufw, use secure password, dsb sudah gue terapkan. Namun seperti DDOS attack & brute-force preventation dan lain sebagainya sejujurnya belum gue terapkan karena keterbatasan my knowledge.
Apalagi dimasalah scalability, zero knowledge banget. Khususnya di horizontal scalability.
That's it!
Prototype pertama ini menghabiskan waktu 7 hari (senin-kamis riset, jumat-minggu implementasi). Ditulis menggunakan JavaScript, dan ditenagai teknologi docker + nginx. Nantinya akan fullstack docker, dan ber-eksperimen dengan swarm.
Singkatnya, gue berambisi membuat "local CDN" sederhana, yang mana inginnya agar website (setidaknya website gue dulu) bisa diakses "lebih cepat" di daerah manapun di Indonesia.
Thanks for stopping by.
And yes this project will be open source, evilfactory rulez.
Sebelumnya gue udah menulis sekilas tentang edgy.network (#12), ditulisan ini gue akan membahas tentang prototype pertama gue dengan edgy.network. Jika kalian mengetahui kesalahan, tips, dsb tolong untuk beritahu since I'm not professional™ network engineer/sysadmin/devops, oke?
DNS
Untuk sekarang masih menggunakan third-party DNS yakni DNSimple. Ada rencana untuk menggunakan self-hosted DNS (via coredns.io), tapi masih difikirkan
Builder
Gue sudah membuat "simple" builder, yang mana "basically" cuma program sederhana Node.js yang bergantung dengan
child_process
.Reverse Proxy
Masih menggunakan Nginx, di prototype kedua akan menggunakan traefik.
How it works?
Ada 4 langkah sederhana yang dilakukan untuk high-level view nya. Yakni:
Webhook
Ketika kita memutuskan untuk "deploy" (via git push), maka GitHub akan mengirimkan webhook ke endpoint kita, dan API kita akan membuat job baru untuk build. Nantinya, via CLI pun bisa.
Build
Dedicated worker akan memproses job tersebut (build), lalu membuat Docker image berdasarkan template yang sudah disediakan. Dan disini kita hanya membutuhkan artifak yang digenerate oleh platform yang kamu gunakan (Hugo? Next.js? Gridsome? Dsb)
Static Web Server
Template tersebut hanyalah Static Web Server yang dibuat menggunakan Node.js, yang memiliki beberapa fitur yang sudah dijanjikan (seperti HTTP/2, Brotli compression with gzip fallback, some caching strategies, dsb).
Proxy the request
Lalu Nginx mem-proxy request tersebut ke container yang sudah dibuat.
Hasilnya bisa dilihat di:
Dan gue akan menyisipkan beberapa screenshot.
Screenshot diatas adalah directory
tmp
yang akan di flush setiap seminggu sekali. Artifact yang sudah dibuild oleh builder di copy ke directory baru yang ada ditmp
(penamaannya menggunakan:{project-name}-{cuuid}
).Directory
cert
berisi Let's Encrypt certificate (wildcard), dannode_modules
adalah dependensi yang digunakan untuk static server tersebut (spoiler alert: Fastify)Berdasarkan engine yang sudah ditentukan (Gridsome? Next.js? Hugo?), si
index.js
akan meng-mount build artifact tersebut ke nama default directory yang sudah ditentukan di manifest pada build-time (docker).Screenshot diatas adalah container-container yang ada. Berdasarkan stress test yang gue lakukan menggunakan vegeta, dari 4k req dalam 10 detik, server bisa meng-handle 2k req/s (status code 200, sisanya 0, bukan 500). Screenshot nya ada di ig story ku dan itupun hands-free :(
Some Notes
Ada beberapa catatan seputar edgy.network
Immutability
Gue pelajari dari layanan-layanan yang sudah ada, dan ya, setiap deployment akan di design immutable juga. Setiap container memiliki identifier khusus (kuncinya: container-name.edgy.network). Container name nantinya diambil dari project name untuk base nya, bila konflik, akan ditambah beberapa "penghias" via cuuid slug.
Dan ada rencana juga untuk membuat "staging" deployment via GitHub PR dengan identifier khusus.
Caching strategies
Nantinya by default expire 1 tahun, dengan embel-embel immutable. Also read this.
Cache validation masih bergantung dengan Etag. Nanti klo udah buat edge server, akan dibuat yang lebih kompleks.
Custom domain
Sejujurnya, untuk sekarang pointing nya masih ke IP (via A record) and I know this is bad (from security & user perspectives). Nantinya, akan dibuat via CNAME karena seperti yang kita tau tidak ada yang bisa memprediksi IP mana yang harus di point (untuk sekarang masih pakai 1 server, belum cluster).
Maksudnya, daripada harus point ke IP, mending ke unique url yang sudah dibuat. Untuk point custom domain sendiri pun masih ada masalah (di SSL certificate) seperti ini contohnya tapi gue yakin masalah ini gak akan sulit-sulit amat.
Why Nginx?
Karena gue sudah terbiasa dengan nginx, khususnya untuk reverse proxy, jadi gue pakai itu
Why Traefik?
Karena semua deployment dibungkus dengan docker container, juga nantinya akan menggunakan docker swarm. Sekaligus gue akan bereksperimen dengan "Mini DIY CDN", yang maksudnya setiap request akan di-serve oleh edge server terdekat denga geo ip yang dimaksud (untuk sekarang masih dari jakarta aja)
Jadi, kalau ada request dari surabaya, maka nantinya request tersebut dihandle oleh edge server yang terdekat (rencana jogja, mungkin nanti bikin juga di sby). Mengapa melakukan ini? Sesuai dengan misi edgy.network :))
Some Question
Backup
Hampir rata-rata layanan menyimpan file-file di cloud provider via object storage. Gue ngerti, salah satunya untuk alasan backup. Gak mungkin dong ada kesalahan di server, lalu semua user disuruh melakukan deploy ulang.
Kenapa gak disimpen di server sendiri? Andaikata server kita bermasalah di harddisk, kita bisa apa? Meskipun katanya don't put all your eggs in one basket, tapi gue lebih mempecayai 3rd party karena alasan SLA.
Jadi kemungkinan gue juga akan menggunakan itu
Builder Caveat
Builder sederhana ini masih bergantung dengan hmm threshold, me-limit 3 job process. Selebihnya, pending dan tunggu sampai builder sudah siap digunakan (n < 3). Jelas ini tidak efektif, dan nantinya akan menggunakan cluster API nya Node.js.
Mengapa melakukan ini? Demi menghindari software fault, atau yang lebih parah server fault.
Security & Scalability
You know, I am Frontend Developer, not Backend Developer. Dan kebetulan pernah menjadi fullstack developer, sebelum benar-benar ingin fokus menjadi Frontend Developer Professional™
Dan gue sepertinya membutuhkan "security advisor" untuk project ini. Basic-basic security seperti only use ssh key for root user, ufw, use secure password, dsb sudah gue terapkan. Namun seperti DDOS attack & brute-force preventation dan lain sebagainya sejujurnya belum gue terapkan karena keterbatasan my knowledge.
Apalagi dimasalah scalability, zero knowledge banget. Khususnya di horizontal scalability.
That's it!
Prototype pertama ini menghabiskan waktu 7 hari (senin-kamis riset, jumat-minggu implementasi). Ditulis menggunakan JavaScript, dan ditenagai teknologi docker + nginx. Nantinya akan fullstack docker, dan ber-eksperimen dengan swarm.
Singkatnya, gue berambisi membuat "local CDN" sederhana, yang mana inginnya agar website (setidaknya website gue dulu) bisa diakses "lebih cepat" di daerah manapun di Indonesia.
Thanks for stopping by.
And yes this project will be open source, evilfactory rulez.