Menggunakan GitOps dengan Amazon Elastic Kubernetes Service pada Landbay

Dalam lanskap pinjaman digital yang terus berkembang, Landbay, pemberi pinjaman hipotek pemenang penghargaan di pasar beli-untuk-sewa Inggris Raya, sedang merevolusi infrastruktur digitalnya. Dengan platform broker terbaik di kelasnya yang mendukung operasi penjaminannya, platform Landbay dibangun di layanan AWS dan terdiri dari sekitar 60 layanan mikro, yang mengikuti arsitektur tiga tingkat sehingga menggabungkan server web, Amazon Elastic Kubernetes Service (Amazon EKS), dan lapisan data multilapisan. Melalui penggabungan kemampuan Layanan AWS Cloud dengan proyek sumber terbuka, Landbay mampu memanfaatkan pendekatan baru ini untuk membuat arsitektur terbaik di kelasnya berdasarkan Amazon Elastic Kubernetes Service.

Keuntungan GitOps

Seiring dengan semakin populernya arsitektur layanan mikro, GitOps telah muncul sebagai standar baru untuk mekanisme deployment ini. Dua produk penting telah muncul dalam Cloud Native Computing Foundation (CNCF): Flux & ArgoCD. Landbay memilih Flux untuk integrasi native-nya menggunakan Kubernetes dengan mengekspos definisi sumber daya kustom (CRD) untuk menentukan deployment, rilis helm, Kustomisasi, dan lainnya. Hal ini, pada gilirannya, memberdayakan para rekayasawan perangkat lunak untuk menguasai Kubernetes, sehingga lebih mudah memahami bagaimana Flux cocok dalam ekosistem.

Gambaran Umum Solusi

Untuk memberikan pemahaman yang komprehensif tentang implementasi GitOps Landbay, mari kita tinjau komponen arsitektural utama dan hubungannya dalam ekosistem AWS:

• Amazon Elastic Container Registry (ECR): Landbay memanfaatkan Amazon ECR untuk menyimpan bagan Helm, serta citra Docker.
• Pengontrol DNS Eksternal & AWS Elastic Load Balancing: Pengontrol ini digunakan untuk mengonfigurasi Route53 dan penyeimbang beban, yang memastikan akses eksternal ke entri Kubernetes.
  
• Integrasi AWS Secrets Manager: Untuk alasan arsitektur dan keamanan, Landbay telah memilih integrasi langsung dengan AWS Secrets Manager, daripada menggunakan alat eksternal seperti pengontrol rahasia eksternal, yang selaras dengan model tanggung jawab bersama AWS serta meningkatkan postur keamanan keseluruhan solusi.
  
• Manajemen Konfigurasi Terraform: Terraform dapat digunakan untuk menjembatani kesenjangan dengan menyediakan ConfigMap dan meringkas item konfigurasi utama (titik akhir, CIDR subnet, dll.). Flux kemudian dapat menggunakan peta konfigurasi melalui fitur pascapembangunannya (lihat gambar 2).
  

Lingkungan Kubernetes dan Arsitektur Data Landbay

Landbay adalah pengadopsi Terraform yang antusias dan semua infrastrukturnya diatur dengan infrastruktur-sebagai-kode (IAC). Pendekatan ini memastikan sinkronisitas di seluruh lingkungan pengujian dan produksi serta memastikan semua perubahan infrastruktur melalui proses siklus hidup pengembangan perangkat lunak standar.

Untuk memastikan tidak ada waktu henti selama peningkatan Amazon EKS, Landbay menggunakan grup simpul yang dikelola EKS dengan tiga grup simpul terkelola, yang masing-masing menargetkan zona ketersediaan tertentu. Konfigurasi ini memungkinkan mereka untuk menggunakan volume tetap, yang difasilitasi oleh driver CSI Amazon Elastic Block Store (EBS). Selain itu, Landbay menggunakan topologySpreadConstraints(DoNotSchedule) untuk memastikan bahwa StatefulSets tersebar di seluruh zona ketersediaan.

Untuk layanan penting, kelas prioritas kustom digunakan untuk mengosongkan deployment prioritas rendah.

Untuk menurunkan biaya di lingkungan pengujian, Landbay memanfaatkan kemampuan Instans Spot Amazon EC2 melalui grup simpul yang dikelola Terraform dan Amazon EKS.

Akhirnya, Landbay menggunakan Bottlerocket dengan menghadirkan permukaan serangan yang jauh berkurang. Operator Kubernetes-nya digunakan untuk meningkatkan simpul secara bertahap dalam klaster menggunakan konsep gelombang. Sementara akses ke sistem file root dikunci, sehingga integrasi dengan IAM dan Systems Manager (SSM) memenuhi persyaratan dasar Landbay.

Add-On Amazon EKS

Selain plugin CNI Amazon Virtual Private Cloud (Amazon VPC), Landbay menjalankan add-on berikut:

1. CoreDNS: Memastikan resolusi layanan DNS dalam klaster
2. KubeProxy: Mendukung penemuan layanan dan jaringan dalam Kubernetes.
   
3. CNI Amazon VPC dengan enableNetworkPolicy: Memungkinkan penerapan kebijakan jaringan yang membantu Landbay mengamankan berbagai akses ke namespace dan pod.
   
4. Driver CSI Amazon EBS: Memungkinkan penggunaan volume tetap.
   

Konfigurasi Manajemen Akses

Landbay menggunakan Pusat Identitas AWS IAM untuk mengontrol semua akses ke API AWS. Amazon EKS memungkinkan pemetaan peran SSO ke dalam grup Kubernetes, yang memungkinkan pemetaan tidak langsung ke grup Azure Entra ID melalui tim Admin IT. Pendekatan ini memastikan pemisahan perhatian antara tim Admin IT dan seluruh organisasi.

Fragmen di atas kemudian dapat digunakan untuk mengatur sumber daya kubernetes_config_map_v1-data aws_auth:

Untuk menghindari proliferasi peran, Kubernetes menyediakan mekanisme untuk meningkatkan izin dari Rilis Helm lain ke grup yang ada menggunakan ‘aggregate-to-admin’:

Pengontrol Penyeimbang Beban AWS

Untuk meningkatkan integrasi antarlayanan, Landbay telah memanfaatkan Pengontrol Penyeimbang Beban AWS (LBC) dan Pengontrol DNS Eksternal.

Pengontrol Penyeimbang Beban AWS memungkinkan penyediaan Penyeimbang Beban langsung dari Entri serta kemampuan untuk menggunakan ulang Penyeimbang Beban yang dikelola secara eksternal dan menetapkan pod target. Dengan memisahkan penyediaan Penyeimbang Beban ke dalam proyek terpisah, tim DevOps dapat memiliki hak istimewa yang lebih besar pada satu repositori kode sumber sambil tetap memberikan alat untuk tugas kepada para rekayasawan yang mengelola target.

Pengontrol juga mengelola grup keamanan karena diperlukan di backend antara Penyeimbang Beban dan targetnya. Selain itu, dengan menggunakan anotasi group.name, Penyeimbang Beban yang sama dapat dibagikan dengan beberapa grup target di belakang layar

Landbay juga menggunakan Pengontrol Penyeimbang Beban AWS untuk menyediakan Penyeimbang Beban Jaringan guna memungkinkan entri dari fungsi AWS Lambda yang berjalan dalam VPC ke infrastruktur EKS.

Melengkapi hal ini, pengontrol DNS Eksternal memungkinkan pod Kubernetes membatasi akses penulisan ke Route53. Fitur ini memfasilitasi pemaparan otomatis layanan eksternal dengan nama DNS yang ramah secara otomatis, sehingga meningkatkan pengalaman pengguna secara keseluruhan.

Dari sudut pandang keamanan, pengontrol Penyeimbang Beban Aplikasi (ALB) dan pengontrol DNS eksternal memerlukan serangkaian izin IAM terbatas, yang dapat dikunci dengan ketat. Misalnya, pengontrol DNS hanya memerlukan akses penulisan ke zona Route 53 tertentu (route53:ChangeResourceRecordSets) serta beberapa izin Daftar.

Manajemen Rahasia dalam Kubernetes

Sementara sebagian besar solusi mengatasi masalah seputar manajemen rahasia, seperti rotasi rahasia dan integrasi, menggunakan penyimpanan rahasia Kubernetes atau menyinkronkan rahasia eksternal ke Kubernetes akan mengakibatkan rahasia disimpan dalam teks biasa di etcd yang mendasari Kubernetes. Meskipun penggunaan 'rahasia terenkripsi dalam EKS' membantu mengurangi vektor serangan fisik, akses melalui API Kubernetes mengekspos nilai mentah rahasia, sesuai model tanggung jawab bersama AWS.

Menggunakan driver Antarmuka Penyimpanan Kontainer (CSI) yang disediakan AWS memberikan manfaat tetapi juga menjauhkan arsitektur dari manajemen Kubernetes native. Mengingat bahwa driver CSI dan solusi penyedia eksternal memerlukan integrasi langsung dengan penyedia rahasia eksternal, Landbay memutuskan untuk mengintegrasikan layanan mikronya secara langsung terhadap AWS Secret Manager.

Opsi integrasi langsung menghindari pengenalan yang lebih banyak kompleksitas di lingkungan yang dapat menyebabkan biaya pemeliharaan dan dukungan yang lebih tinggi. Opsi ini juga menghindari keberadaan rahasia teks biasa dalam volume kontainer, sehingga meningkatkan keamanan.

Penyediaan Flux di Lingkungan AWS

Flux, solusi GitOps pilihan Landbay, menyediakan penyedia Terraform untuk melakukan bootstrap pada klaster EKS. Pada interval reguler yang dapat dikonfigurasi, Flux memastikan bahwa semua manifes Kubernetes yang ditentukan dalam Repositori Git direkonsiliasi terhadap sumber daya yang ada yang di-deploy di Kubernetes, dan mengembalikan setiap penyimpangan yang terdeteksi. Setelah Flux di-bootstrap, Flux dapat melakukan rekonsiliasi pertamanya, menginstal layanan yang dikonfigurasi, pod, set stateful, dan lainnya ke klaster Kubernetes, seperti yang ditunjukkan pada gambar di bawah ini.

Flux dapat memanfaatkan AWS Elastic Container Registry (ECR) sebagai Repositori Helm karena ECR memiliki dukungan kelas pertama untuk artefak OCI. Hal ini memungkinkan Flux bertindak sebagai perekat antara ECR dan EKS, menggunakan Kustomisasi untuk menerapkan konfigurasi khusus lingkungan.

Salah satu keuntungan utama dari pendekatan ini adalah pemisahan logis antara bagian Integrasi Berkelanjutan (CI) dari jalur deployment (pembangunan, pengujian, & pengemasan) dan bagian Deployment Berkelanjutan (CD) (pengiriman ke lingkungan). Dari perspektif keamanan, Flux menarik perubahan, yang memungkinkan izin akses dikunci secara signifikan untuk deployment harian. Untuk menghindari penundaan deployment, satu-satunya izin yang diperlukan adalah alat pembangunan untuk 'memberi tahu' Flux tentang rekonsiliasi awal, yang dapat dilakukan melalui kubeconfig yang terkunci, dengan pengguna terbatas.

Hasilnya, melakukan deployment, mengembalikan, atau mempromosikan layanan mikro baru menjadi semudah memperbarui fragmen penentuan versi semantik (semver) dalam file YAML, atau mengembalikan komitmen. Setelah mengamati perubahan Git, Flux memicu rekonsiliasi dengan Kubernetes dan memperbarui layanan yang relevan.

Struktur Repositori Flux dan Komponen Bersama

Flux menyediakan dokumentasi yang komprehensif tentang struktur repositori yang direkomendasikan. Pendekatan Landbay relatif mudah dan mengikuti praktik terbaik ini.

Konfigurasi klaster ditentukan dalam folder khusus mereka sendiri, yang masing-masing mereferensikan komponen bersama. Dalam folder klaster ini, penggunaan Kustomisasi yang ekstensif memastikan isolasi antarklaster. Hal ini memungkinkan konfigurasi khusus lingkungan, seperti penentuan versi dan memori.

Struktur yang diilustrasikan di atas menciptakan keseimbangan antara berbagi kode dan mempertahankan sifat deklaratif dan eksplisit dari paradigma GitOps, yang memungkinkan seorang rekayasawan untuk membaca repositori Git serta memastikan komponen, versi, atau paket mana yang telah diinstal pada klaster.

Dengan memisahkan komponen, Landbay dapat menyederhanakan proses pembangunan klaster baru. Dari sini, konfigurasi klaster menjadi masalah pemilihan “batu bata LEGO” dan merakitnya dengan beberapa konfigurasi khusus lingkungan.

Selanjutnya, saat beberapa klaster beroperasi di cloud dan memerlukan komponen tambahan, klaster lain dapat ditargetkan pada rekayasawan DevOps yang bekerja secara lokal. Pendekatan pengembangan lokal ini menyediakan putaran umpan balik yang lebih cepat dan tidak menyertakan komponen yang terkait langsung dengan layanan AWS.

Pengembangan Lokal sebagai Batu Loncatan

Pendekatan pengembangan lokal ini juga merupakan batu loncatan untuk deployment cepat di lingkungan pengembangan sementara yang berbasis cloud. Dengan menggunakan namespace Kubernetes dan menghapus dependensi pada layanan yang dikelola AWS, Landbay dapat menggunakan Flux untuk melakukan bootstrap pada lingkungan mandiri baru dengan cepat.

Dalam kasus ini, lingkungan pengembangan Landbay dapat menggantikan Amazon Relational Database Service (RDS) dengan kontainer MariaDB sederhana, Amazon OpenSearch Service dengan kontainer OpenSearch yang setara. Meskipun pendekatan ini menjaga lingkungan pengembangan secara arsitektur “sejalan” (misalnya namespace yang sama, penemuan layanan, jaringan), konsekuensinya adalah kurangnya ketahanan operasional–yang mungkin dapat diterima untuk beberapa lingkungan pengembangan.

Mengintegrasikan EKS, GitOps, dan Layanan AWS

Di Landbay, infrastruktur AWS dikelola sepenuhnya oleh Terraform. Oleh karena itu, sangat penting untuk menjembatani kesenjangan antara elemen yang disediakan Terraform (RDS, OpenSearch, dll.) dan pod lain yang berjalan dalam klaster. Cara native untuk mengakses konfigurasi di Kubernetes dalam layanan mikro adalah melalui ConfigMaps.

Diagram berikut menunjukkan hubungan timbal balik antara proyek Terraform dan Flux kami.

Proyek Terraform pertama bertanggung jawab untuk menyiapkan semua jaringan dasar, penyeimbang beban yang terhubung ke internet, dan layanan yang dikelola AWS. Proyek kedua membuat klaster EKS, melakukan bootstrap Flux ke dalam klaster, mengamankan klaster EKS, mengatur setiap peran IAM, dan mengelola masalah tingkat rendah seperti grup simpul terkelola yang menjalankan Bottlerocket. Proyek ini menciptakan lingkungan ConfigMap yang menanyakan AWS untuk semua variabel lingkungan serta menginjeksinya ke Kubernetes.

Proyek akhir adalah proyek Flux khusus. Hal ini menentukan konfigurasi klaster untuk lingkungan, yang menautkan ke satu set komponen bersama, lalu menyesuaikan rilis Helm dan manifes Kubernetes agar sesuai dengan lingkungan yang relevan. ConfigMap Lingkungan kemudian dapat digunakan sebagai bagian dari kustomisasi dalam repositori Flux. Flux juga menawarkan fitur substitusi variabel pascapembangunan, yang memungkinkan penggunaan substitusi variabel dengan serangkaian fungsi penggantian string bash yang terdefinisi dengan baik.

Misalnya, dalam bagan Helm, nilai dapat menggunakan substitusi variabel pascapembangunan. Seperti yang dapat dilihat dalam ilustrasi di bawah ini, pendekatan ini meningkatkan repositori GitOps agar komponen bersama dapat menjadi agnostik lingkungan.

Kesimpulan

Keputusan Landbay untuk mengadopsi GitOps melalui Flux, yang terintegrasi erat dengan Amazon EKS dan ekosistem AWS yang lebih luas, telah terbukti membawa perubahan besar. Dengan menggunakan pendekatan mutakhir ini, Landbay telah membuka segudang manfaat yang telah menyederhanakan operasi mereka dan meningkatkan postur keamanannya. Mungkin salah satu keuntungan yang paling signifikan adalah realisasi dari efisiensi rekayasa secara keseluruhan. Mulai dari deployment yang lebih cepat serta pengurangan waktu tunggu hingga pemanfaatan solusi pihak ketiga yang lancar, integrasi GitOps dengan layanan EKS dan AWS telah merevolusi proses pengembangan Landbay.

Selain itu, lanskap keamanan Landbay telah diperkuat, menjadi lebih tangguh dan hemat biaya untuk dipelihara. Dengan memanfaatkan Bottlerocket, dapat memisahkan tugas melalui izin SCM/Git dan memungkinkan peningkatan yang mudah melalui Helm, Landbay telah memperkuat komitmennya terhadap keamanan sekaligus mengoptimalkan biaya operasional.

Dampak paling mendalam dari perjalanan transformatif ini terletak pada peningkatan visibilitas dan transparansi status dan perubahan beban kerja EKS. Dengan GitOps, konfigurasi dideklarasikan menggunakan YAML, serta semua perubahan disimpan sebagai komitmen Git. Pergeseran paradigma ini telah menghasilkan keuntungan yang signifikan bagi tim Dukungan, Risiko, Kepatuhan, dan Audit Landbay, yang memberdayakan mereka dengan wawasan dan kontrol yang luar biasa atas sistem penting mereka.

Jika Anda siap mentransformasi perusahaan rintisan Anda seperti Landbay, bergabunglah dengan AWS Activate untuk mendapatkan akses ke templat yang dapat di-deploy, kredit AWS, dan peluang pembelajaran.