Hello guys, pada kali ini saya mau sharing tentang bagaimana kita melakukan setup terhadap environment yang kita kerjakan.

CI/CD

Pada pengerjaan pengembangan aplikasi ini, kami menggunakan GitLab sebagai repositori kode kami. Nah, hal yang cukup keren dari GitLab adalah, GitLab tidak hanya dapat berfungsi sebagai sekedar tempat penampungan dan kolaborasi kode saja, namun juga terdapat banyak fitur lain yang menarik untuk digunakan. Pada kali ini, kami juga memanfaatkan fitur CI/CD yang diberikan oleh GitLab.

GitLab dapat secara otomatis dikonfigurasikan CI-nya dengan hanya menuliskan konfigurasi dalam sebuah file bernama .gitlab-ci.yml dengan format YML dan diletakkan di root repository. Nah secara umum pipeline dari CI kami berbentuk seperti:

test-mario

Test mario merupakan integrasi yang melakukan tes terhadap backend secara keseluruhan. CI pada GitLab didukung oleh penggunakan image docker sehingga cukup mudah bagi kami untuk melakukan setup karena stack kami juga menggunakan docker sebagai kontener. Pada test-mario kita menggunakan image yang berisikan python dan ditambahkan service berupa postgres yang merupakan stack minimal dalam melakukan testing. Kemudian diberikan konfigurasi, dan script merupakan instruksi secara sekuensial bagaimana cara kita melakukan testing. Dengan menerapkan test-mario maka backend akan diuji setiap kali push sehingga kualitas kode dari backend dapat terjaga.

test-peach

Test peach merupakan integrasi yang melakukan tes terhadap frontend secara keseluruhan. Pada test-paech kita menggunakan image yang berisikan node-js yang merupakan stack minimal dalam melakukan testing. Kemudian diberikan konfigurasi, dan script merupakan instruksi secara sekuensial bagaimana cara kita melakukan testing. Dengan menerapkan test-peach maka frontend akan diuji setiap kali push sehingga kualitas kode dari frontend dapat terjaga seperti juga dengan backend.

*test-mario & test-peach dilakukan secara paralel karena tidak terdapat dependensi dan akan mempercepat proses test.

release

Pada stage release, kode frontend dan backend yang telah lulus test akan dimasukkan ke dalam kontener docker menggunakan image yang berisikan docker tools. Kemudian kita menggunakan fitur dari GitLab yang lain yaitu registry. Untuk dapat membagikan image docker kita melalui internet, kita perlu menaruh docker image kita ke dalam sebuah docker image repository. Salah satu docker image repository adalah menggunakan fitur GitLab yang mereka namakan dengan Registry. Jadi semua docker image dari frontend & backend kita akan di push ke GitLab Registry. Oiya, proses release hanya dilakukan di branch master & sit_uat ya!

deploy

Nah, untuk deployment, kita menggunakan orchestrator berupa Kubernetes yang di-host pada server Azure. Walaupun bisa dibilang cukup rumit di sisi setupnya, namun pada implementasi di .gitlab-ci.yml cukuplah mudah. Kita menggunakan docker image milik orang bernama roffe yang berisikan linux minimal dengan kubectl. Kubectl lah yang kita butuhkan untuk mengkonfigurasikan Kubernetes kita yang berada di Azure service. Secret key diambil melalui environment variables GitLab untuk dapat mengakses Azure service, kemudian dengan kubectl memerintahkan Kubernetes untuk mengambil docker image frontend & backend kita yang baru saja di push ke Registry untuk dilakukan deployment.

Environment

Setelah mengetahui tentang bagaimana proses CI/CD kami, kali ini saya akan berbagi tentang bagaimana kita melakukan setup terhadap environment kami. Karena setupnya cukup panjang dan rumit, pada kali ini saya hanya akan menjelaskan secara umum saja.

Kubernetes

Kubernetes merupakan orchestrator yang berperan untuk melakukan deployment docker image kita ke dalam server.

Konfigurasi pada kubernetes dituliskan dalam bentuk YML dan dikirimkan kepada Kubernetes yang terletak pada server azure menggunakan kubectl. Secara umum, untuk deployment 1 servis utama, membutuhkan 3 konfigurasi.

Deployment

Mirip dengan konfigurasi pada gitlab-ci, deployment berguna untuk memberikan konfigurasi dan spesifikasi serta cara untuk mendeploy dengan benar produk kita. Kita harus menentukan darimana docker image harus diunduh, kemudian spesifikasi maksimal dan minimal mesin, command yang harus dijalankan.

contoh:

mario-master-deployment.yml

Service

Service berguna untuk menjadikan deployment kita yang telah di-deploy untuk dijadikan sebuah service. Parameter konfigurasi yang harus diberikan adalah, menentukan port yang harus di-forward dan port mana yang harus dibuka pada publik.

contoh:

mario-master-service.yml

Ingress

Kita menggunakan Ingress yang berbasis Nginx untuk melakukan host backend dan menyambungkannya dengan domain yang kita miliki.

contoh:

mario-master-ingress.yml

Ada banyak sekali konfigurasi yang harus kami berikan dalam menyiapkan deployment secara keseluruhan yang dapat dilihat di repository kami.

Secara umum, skema dari deployment kita dapat digambarkan sebagai:

COBA_COBA

COBA_COBA merupakan environment yang kami gunakan untuk melakukan testing terhadap implementasi yang baru dibuat terhadap server. Deployment pada COBA_COBA berasal dari kode yang di-push ke dalam branch story yang telah berhasil melalui CI/CD sampai akhir.

SIT_UAT

Setiap sebuah story telah selesai diimplementasikan, maka story tersebut akan di-merge ke dalam branch sit_uat dan akan dilakukan CD ke environment SIT_UAT. Pada setiap akhir sprint, produk sprint akan dilakukan demonstrasi dan review pada sprint review kepada product owner untuk diberikan acceptance atau rejection. Ketika fitur di-reject oleh product owner, maka fitur harus di-rollback dari SIT_UAT dan SIT_UAT harus bersih dari fitur tersebut.

PRODUCTION

Kode pada branch sit_uat yang telah diterima akan dipindahkan ke dalam branch master. Kode yang telah diterima oleh branch master akan dideploy secara otomatis ke dalam environment PRODUCTION dimana merupakan environment yang dirilis kepada publik dan siap untuk digunakan.

Nah, sekarang sudah mengerti kan bagaimana secara umum kami merancang environment serta CI/CD pada proyek kali ini? Sampai jumpa lagi ya guys!

Halo semua! Pada kali ini saya akan berbagi tentang konsep arsitektur pada aplikasi kami. Dalam penjelasannya nanti, akan banyak sekali istilah yang mungkin kurang familiar ataupun belum pernah didengar. Oleh karena itu, pertama kali kita akan menjelaskan dahulu apa saja sih stack-stack yang ada pada aplikasi kami.

GitLab (Repository + Runner + Registry)

Kalian sudah tau dong apa itu GitLab? Ya, GitLab merupakan repositori tempat kami menyimpan dan mempublikasikan kode. Namun bukan hanya itu saja, kami juga memanfaatkan beberapa fitur dari GitLab yaitu runner dan registry. Runner merupakan fitur dimana GitLab memberikan virtual machine untuk kita melakukan pengujian/interaksi pada kode kita saat melakukan push ke dalam repositori. Kemudian registry merupakan tempat penyimpanan docker image. Apa itu docker image? Nanti akan dijelaskan di bawah ya!

Docker Container Image

Menurut website Docker sendiri:

A container image is a lightweight, stand-alone, executable package of a piece of software that includes everything needed to run it: code, runtime, system tools, system libraries, settings. Available for both Linux and Windows based apps, containerized software will always run the same, regardless of the environment. Containers isolate software from its surroundings, for example differences between development and staging environments and help reduce conflicts between teams running different software on the same infrastructure.

Secara simpel, bayangkan saja docker container image sebagai sebuah virtual machine mini yang akan membuat aplikasi kita independen dan fleksibel terhadap infrastruktur dari mesin yang menjalankannya.

Kubernetes (Orchestrator)

Kubernetes merupakan orchestrator yang dapat menjadwalkan dan menjalankan kontainer aplikasi pada kelompok mesin fisik atau virtual. Namun, Kubernetes juga memungkinkan pengembang untuk ‘cut the cord’ ke mesin fisik dan virtual, bergerak dari infrastruktur host-sentris ke infrastruktur kontainer, yang memberikan keuntungan dan manfaat penuh yang melekat pada kontainer. Kubernetes menyediakan infrastruktur untuk membangun lingkungan pengembangan yang benar-benar kontainer-sentris. Disini Kubernetes digunakan untuk melakukan deployment pada docker container image yang kita miliki.

Flask (Framework Backend)

Flask merupakan framework mini yang cukup fleksibel dan berbahasa Python. Walaupun Flask dapat digunakan sebagai MVC dengan frontend menggunakan templating yang dimiliki Flask yaitu Jinja, namun konsep kontainer-sentris dan microarchitecture-oriented membuat kami memutuskan untuk menjadikan Flask hanya sebagai backend dengan konsep restfulAPI.

React-Js (Framework Frontend)

React-Js merupakan framework untuk frontend berbasis javascript yang cukup populer pada masa kini. Nah, React-Js sendiri kami gunakan sebagai frontend yang menampilkan aplikasi secara grafis kepada pengguna.

Celery (Worker)

Aplikasi kita memiliki tugas yang mengharuskan backend untuk dapat mengerjakan sebuah komputasi yang memakan waktu yang cukup lama. Dengan demikian dibutuhkannya bantuan dalam bentuk worker sehingga pekerjaan dapat dikerjakan secara paralel. Disini kami menggunakan Celery sebagai worker berbasis Python yang membantu backend dalam melakukan tugas yang berat.

Redis (Broker & Queue)

Redis dapat dibilang sebagai tempat penyimpanan layaknya database, namun uniknya dia menyimpan data di memori, bukan diska. Secara singkat disini kami menggunakan Redis untuk dua hal, yaitu sebagai broker yang menampung dan mengantrikan tugas-tugas yang diberikan oleh core backend untuk diberikan kepada worker, dan sebagai result backend yaitu tempat menampung hasil ataupun status dari kerja worker.

Postgresql (Database)

Singkat saja, postgresql merupakan database berbasis SQL tempat kami menyimpan data-data yang dibutuhkan.

Our Current Architecture Schema

Skema diatas merupakan gambaran dari aliran pengembangan aplikasi kami mulai dari kode yang dihasilkan oleh pemrogram hingga bagaimana aplikasi dapat disajikan kepada pengguna. Berikut merupakan penjelasannya:

1. Ketika seorang pemrogram melakukan push kode menggunakan git, kode akan dikumpulkan dan digabungkan didalam sebuah repositori milik GitLab. 
2. Pada branch tertentu (master/sit-uat), push ke dalam branch tersebut akan memicu berjalannya runner yang akan melakukan proses tes, rilis, dan deployment.
3. Kode yang akan dirilis akan dijadikan sebuah kontainer docker terlebih dahulu dan kemudian akan di push ke dalam penyimpanan kontainer milik GitLab yaitu GitLab Registry.
4. Pada proses deployment, runner akan memicu kubernetes untuk melakukan proses pull pada kontainer/image docker yang baru di-push.
5. Kubernetes kemudian melakukan deployment menggunakan konfigurasi yang diberikan pada repositori. Deployment yang dilakukan antara lain adalah: redis (broker & result backend), postgresql (database), mario (backend), luigi (worker), dan peach (frontend).
6. Ketika suatu pengguna mengunjungi peach (frontend), maka peach (frontend) akan mengirimkan API untuk melakukan proses yang dikehendaki oleh pengguna kepada mario (backend).
7. Untuk proses yang tergolong cepat, mario (backend) dapat langsung mengambil data dari postgresql, namun untuk proses yang lambat (kalkulasi, dll.), mario (backend) akan memberikan tugasnya kepada luigi (worker) melalui perantara redis.
8. Redis merupakan broker yang menampung tugas-tugas yang diberikan oleh mario (backend), kemudian luigi (worker) akan melakukan pengecekan berkala pada redis, mengambil tugasnya, mengerjakannya, dan mengembalikannya kepada redis yang sekarang bekerja sebagai result backend.
9. Dalam pengerjaannya luigi (worker) dapat menduplikasi dirinya menjadi banyak agar dapat menyelesaikan tugas secara paralel. Kapasitas penduplikasiannya sendiri dapat diatur dalam pengaturan dan menyesuaikan kapasitas dari mesin. Luigi (worker) juga memiliki akses kepada postgresql untuk melakukan transaksi pada database.
10. Setelah mario (backend) selesai menyelesaikan tugasnya, hasilnya akan dikembalikan lagi kepada peach (frontend) untuk ditampilkan kepada pengguna.

Secara ringkas dapat digambarkan sebagai:

Simple Architecture

Pada dasarnya, konsep microarchitecture yang kami implementasikan menerapkan teknik dasar dari dependency injection.

Dependency injection memiliki fleksibilitas yang lebih tinggi dibandingkan dengan Layered Pattern yang juga merupakan teknik umum yang cukup populer.

Kekurangan dari dependency injection adalah dibagian management karena terdiri dari banyak servis kecil sehingga lebih sulit diurus.

Namun bagian terbaiknya adalah, arsitektur bersifat independen satu sama lain sehingga menjadi fleksibel.

Begitu deh secara singkat dapat dijelaskan arsitektur aplikasi kami. Tidak rumit bukan? Sampai jumpa lagi untuk penjelasan arsitektur yang lebih mendalam di seri Allocarchitecture berikutnya ya!