Sedang memikirkan seputar project edgy.network karena mumpung weekend. Dan hal pembeda dengan "hosting" yang sudah ada adalah CI & CD. No ftp upload.
Sudah banyak layanan lain yang sudah gue coba (dan pakai!), dan beberapa yang sangat gue suka adalah Netlify & Zeit Now, yang mungkin akan menjadi kompetitor nanti. Workflow dalam menggunakan layanan tersebut (secara garis besar) adalah:
clone git repo
"runner" nge-build
jika pass, maka buat URL baru (untuk preview, bila non master)
jika oke, merge branch tersebut ke master (bila non master) dan point URL production ke situ.
Sekilas terlihat singkat, namun ada beberapa yang menjadi konsen gue.
File System
Berurusan dengan fs memang lumayan menantang. Meskipun yang gue lihat rata-rata file-file yang ada hanya untuk keperluan Read-only, yang gue fikirkan adalah bagaimana cara menyimpan file tersebut agar "aman".
Zeit gue yakin menggunakan virtual FS, karena proses deployment mereka adalah upload file satu-satu, lalu trigger create deployment dengan membawa list file yang sudah diupload tersebut (dalam bentuk List).
Kalau Netlify, lebih simple. Dia tinggal git clone project yang ada, done. Untuk skala kecil, mungkin proses yang seperti dilakukan oleh Netlify yang paling efektif. Baru ketika sudah menggunakan arsitektur "distributed", cara yang digunakan Zeit yang lebih efektif. IMO.
Security
Anggap gue memilih cara seperti Netlify. Hal yang gue fikirkan adalah, misal setiap ada trigger "runner", gue membuat container baru, berdasarkan dengan "type" engine yang sudah didefinisikan (anggap menggunakan Hugo). Masalahnya, kalau container-container tersebut gak pernah di delete, maka mau gak mau gue harus memiliki process dan storage yang besar.
Karena, anggap ada deployment baru, lalu generate url seperti ini: https://staging--666.edgy.network, yang mana URL tersebut mengarah ke container aec777666abc. Lalu user merge branch yang ada ke master, ngirim webhook ke gue, dan otomatis gue point url production dia (https://edgy.network) ke (https://staging--666.edgy.network). Anggap user melakukan rollback ke url sebelumnya, mau gak mau container tersebut harus masih ada.
Aman nya, karena ter-isolasi. User lain tidak terganggu dengan file-file dari user lain.
Masalahnya, container paling light-weight aja sekitar 5 MB untuk bare alpine linux. Belum ditambah node_modules yang... you know. Ide gue pertama adalah menggunakan container "khusus" untuk build. Misal, khusus untuk Hugo; Khusus untuk Zola, khusus untuk Next.js; Gridsome, dsb. Lalu, artifact yang sudah terbuat, dideploy ke container berdasarkan alpine tersebut (5MB + ~20MB = ~25 MB). Rasional lah, ya?
Yang jadi masalah, ketika dalam suatu periode, banyak proses docker yang berjalan dan server gue gak bisa handle tersebut. Maka, ide kedua gue adalah "runner" berada pada satu server, namun deployment via alpine tersebut. Untuk sekarang sepertinya tidak terlalu ribet, karena Hugo hanyalah global binary (rata-rata pada pakai Hugo, kan?). Gue tinggal buat temporary directory (clone), build via Hugo, distribute via alpine.
Jika sudah mencampai threshold yang sudah ditentukan, delete temp directory tersebut. Okay. Masalah incremental build dsb bisa difikirkan nanti. Kita ga butuh file source mereka, kan? Yang penting, hasil build nya.
OK thanks for brainstorming with this way, I love it.
faultables
commented
5 years ago
Sedang memikirkan seputar project edgy.network karena mumpung weekend. Dan hal pembeda dengan "hosting" yang sudah ada adalah CI & CD. No ftp upload.
Sudah banyak layanan lain yang sudah gue coba (dan pakai!), dan beberapa yang sangat gue suka adalah Netlify & Zeit Now, yang mungkin akan menjadi kompetitor nanti. Workflow dalam menggunakan layanan tersebut (secara garis besar) adalah:
Sekilas terlihat singkat, namun ada beberapa yang menjadi konsen gue.
File System
Berurusan dengan fs memang lumayan menantang. Meskipun yang gue lihat rata-rata file-file yang ada hanya untuk keperluan Read-only, yang gue fikirkan adalah bagaimana cara menyimpan file tersebut agar "aman".
Zeit gue yakin menggunakan virtual FS, karena proses deployment mereka adalah upload file satu-satu, lalu trigger create deployment dengan membawa list file yang sudah diupload tersebut (dalam bentuk List).
Kalau Netlify, lebih simple. Dia tinggal
git cloneproject yang ada, done. Untuk skala kecil, mungkin proses yang seperti dilakukan oleh Netlify yang paling efektif. Baru ketika sudah menggunakan arsitektur "distributed", cara yang digunakan Zeit yang lebih efektif. IMO.Security
Anggap gue memilih cara seperti Netlify. Hal yang gue fikirkan adalah, misal setiap ada trigger "runner", gue membuat container baru, berdasarkan dengan "type" engine yang sudah didefinisikan (anggap menggunakan Hugo). Masalahnya, kalau container-container tersebut gak pernah di delete, maka mau gak mau gue harus memiliki process dan storage yang besar.
Karena, anggap ada deployment baru, lalu generate url seperti ini: https://staging--666.edgy.network, yang mana URL tersebut mengarah ke container
aec777666abc. Lalu user merge branch yang ada kemaster, ngirim webhook ke gue, dan otomatis gue point url production dia (https://edgy.network) ke (https://staging--666.edgy.network). Anggap user melakukan rollback ke url sebelumnya, mau gak mau container tersebut harus masih ada.Aman nya, karena ter-isolasi. User lain tidak terganggu dengan file-file dari user lain.
Masalahnya, container paling light-weight aja sekitar 5 MB untuk bare alpine linux. Belum ditambah
node_modulesyang... you know. Ide gue pertama adalah menggunakan container "khusus" untuk build. Misal, khusus untuk Hugo; Khusus untuk Zola, khusus untuk Next.js; Gridsome, dsb. Lalu, artifact yang sudah terbuat, dideploy ke container berdasarkan alpine tersebut (5MB + ~20MB = ~25 MB). Rasional lah, ya?Yang jadi masalah, ketika dalam suatu periode, banyak proses docker yang berjalan dan server gue gak bisa handle tersebut. Maka, ide kedua gue adalah "runner" berada pada satu server, namun deployment via alpine tersebut. Untuk sekarang sepertinya tidak terlalu ribet, karena Hugo hanyalah global binary (rata-rata pada pakai Hugo, kan?). Gue tinggal buat temporary directory (clone), build via Hugo, distribute via alpine.
Jika sudah mencampai threshold yang sudah ditentukan, delete temp directory tersebut. Okay. Masalah incremental build dsb bisa difikirkan nanti. Kita ga butuh file source mereka, kan? Yang penting, hasil build nya.
OK thanks for brainstorming with this way, I love it.