Dokumen ini menjelaskan framework untuk menerapkan proses continuous integration/continuous delivery (CI/CD) yang modern pada platform pengiriman software multi-tim yang menggunakan Google Kubernetes Engine.
Anda kemudian dapat melakukan iterasi di platform ini untuk lebih meningkatkan performa pengembangan dan operasi, termasuk kecepatan rilis, keandalan platform, dan waktu pemulihan dari kegagalan.
Dokumen ini adalah bagian dari rangkaian:
CI/CD modern dengan GKE: Framework pengiriman software (dokumen ini)
CI/CD modern dengan GKE: Membangun sistem CI/CD (arsitektur referensi)
Dokumen ini ditujukan untuk arsitek perusahaan dan developer aplikasi, serta tim keamanan IT, DevOps, dan Site Reliability Engineering. Beberapa pengalaman dengan alat dan proses deployment otomatis berguna untuk memahami konsep dalam dokumen ini.
Kasus untuk CI/CD modern
CI/CD adalah pendekatan pengembangan software yang memungkinkan Anda mengotomatiskan fase build, pengujian, dan deployment pengembangan software menggunakan sejumlah alat dan proses yang dapat diulang.
Selain otomatisasi CI/CD, Kubernetes dan container telah memungkinkan perusahaan mencapai peningkatan yang sama sekali baru dalam kecepatan pengembangan dan deployment. Namun, meskipun adopsi Kubernetes dan container terus bertambah, banyak organisasi tidak sepenuhnya menyadari manfaat dalam kecepatan rilis, stabilitas, dan efisiensi operasional karena praktik CI/CD mereka tidak sepenuhnya memanfaatkan Kubernetes atau menangani masalah operasi dan keamanan.
Pendekatan CI/CD yang benar-benar modern harus mencakup lebih dari sekadar otomatisasi. Untuk mewujudkan peningkatan kecepatan dan keamanan secara penuh, serta untuk memanfaatkan kecanggihan Kubernetes dan container, Anda perlu menyederhanakan proses orientasi aplikasi, praktik CI/CD, dan proses operasional.
Dengan menggunakan infrastruktur konsisten yang ditawarkan oleh platform GKE, metode CI/CD yang seragam, dan praktik terbaik dalam implementasi, organisasi Anda dapat memperoleh manfaat berikut untuk pengembangan dan operasi:
Mengurangi waktu tunggu untuk perubahan.
Izinkan tim operasi dan keamanan membuat dan memperbarui praktik terbaik untuk penyediaan aplikasi dan kebijakan penyediaan di seluruh platform.
Sederhanakan proses orientasi aplikasi dengan memberi tim project awal yang berfungsi sepenuhnya dan dapat di-deploy yang memiliki praktik terbaik organisasi Anda bawaan.
Mengurangi waktu yang diperlukan untuk memulihkan layanan.
Mengelola semua konfigurasi secara deklaratif menggunakan GitOps untuk audit, rollback, dan peninjauan yang disederhanakan.
Standardisasi metodologi deployment dan pemantauan di seluruh organisasi untuk mengurangi waktu yang diperlukan untuk mengidentifikasi faktor yang berkontribusi dari masalah yang berdampak pada layanan.
Meningkatkan frekuensi deployment.
Pastikan developer aplikasi dapat melakukan iterasi secara independen di sandbox pengembangan mereka sendiri (atau zona landing) tanpa mengganggu satu sama lain.
Menggunakan GitOps untuk deployment, pengelolaan rilis yang lebih baik, dan pelacakan perubahan.
Terapkan pembatas agar tim layanan diberdayakan untuk sering melakukan deployment.
Buat proses peluncuran yang progresif untuk men-deploy secara konsisten di seluruh lingkungan praproduksi, sehingga developer merasa yakin bahwa mereka perlu men-deploy perubahan ke produksi.
Untuk melihat bagaimana manfaat dan konsep ini diwujudkan dengan GKE dan CI/CD, lihat dokumen lain dalam rangkaian ini:
Menilai kesiapan untuk pendekatan modern
Sebelum menerapkan alat dan proses CI/CD modern dengan GKE, Anda perlu menilai apakah organisasi dan tim Anda siap mengadopsi platform baru.
Sifat Organisasi
Pengadopsian platform modern memerlukan dukungan berikut dari tim teknis dan kepemimpinan bisnis Anda:
Sponsor kepemimpinan. Mengadopsi platform pengiriman software biasanya merupakan upaya besar yang dilakukan oleh beberapa tim lintas fungsi. Proses ini biasanya menghasilkan perubahan pada peran dan tanggung jawab serta praktik pengembangan software. Agar berhasil dalam mengadopsi alat dan teknik ini, Anda memerlukan dukungan kuat dari satu atau beberapa anggota tim kepemimpinan. Sponsor kepemimpinan yang paling efektif adalah mereka yang memandang perubahan ini sebagai proses peningkatan berkelanjutan dan ingin memberdayakan tim mereka, bukan mengelolanya.
Penyelarasan strategi teknis dan bisnis. Sebaiknya tim bisnis dan tim teknis Anda menyelaraskan empat langkah utama pengiriman software yang ditentukan oleh DevOps Research and Assessment (DORA): lama pengerjaan perubahan, frekuensi deployment, waktu pemulihan layanan, dan tingkat kegagalan perubahan. Dengan menyelaraskan tindakan tersebut, tim bisnis dan tim teknis Anda memiliki sasaran yang sama, sehingga mereka dapat menghitung laba atas investasi bersama, menyesuaikan tingkat perubahan, dan memodifikasi tingkat investasi.
Referensi. Agar sukses, tim yang mengembangkan praktik CI/CD modern dan membangun rantai alat memerlukan sumber daya yang diperlukan: waktu, personel, dan infrastruktur. Tim ini memerlukan waktu untuk mencoba dan memilih proses dan alat terbaik. Idealnya, tim-tim ini mewakili banyak fungsi yang berbeda dalam proses pengiriman software dan dapat menarik resource lain dari seluruh organisasi. Terakhir, tim membutuhkan kemampuan dalam menyediakan infrastruktur, termasuk resource cloud dan alat software.
Keterbukaan untuk mengadopsi alat baru. Alat dan teknik CI/CD modern sering kali dilengkapi dengan alat dan proses baru. Tim perlu bereksperimen dengan proses dan alat tersebut, serta terbuka untuk mengadopsinya. Feedback loop diperlukan agar tim platform dapat mendengar masukan dari tim aplikasi, operasi, dan keamanan yang menggunakan platform.
Kesiapan budaya. Agar berhasil men-deploy dan mengadopsi sistem CI/CD modern dengan GKE, organisasi dan tim teknis yang mengembangkan sistem harus bersiap untuk mengubah cara mereka beroperasi dan bekerja sama. Misalnya, tim pengembangan dan operasi harus bersedia melakukan lebih banyak tanggung jawab atas keamanan, serta tim keamanan dan operasi harus bersedia menyederhanakan proses persetujuan perubahan.
Kemampuan teknis
Mengadopsi pendekatan CI/CD modern juga mengharuskan tim Anda secara teknis sudah siap dengan cara berikut:
Pengalaman dengan container. Tim yang mengadopsi pendekatan CI/CD modern memerlukan pengalaman dengan container. Idealnya, pengalaman ini mencakup teknik pengembangan untuk mem-build image container dan menggabungkan container untuk mem-build sistem yang lebih besar.
Strategi continuous integration. Tim memerlukan pengalaman dalam menggunakan alat CI (seperti Jenkins, TeamCity, Bamboo, dan CircleCI) serta melakukan beberapa continuous integration dan pengujian otomatis. Sebaiknya organisasi merencanakan cara untuk meningkatkan proses tersebut lebih lanjut.
Otomatisasi deployment. Tim memerlukan pengalaman dalam otomatisasi deployment. Contoh alat deployment otomatis meliputi skrip shell dasar, Terraform, Chef, atau Puppet. Memiliki pengetahuan dasar tentang alat dan proses deployment otomatis sangat penting untuk menyederhanakan dan mengotomatiskan deployment.
Arsitektur berorientasi layanan. Meskipun bukan prasyarat untuk menerapkan proses CI/CD modern, penerapan lebih banyak arsitektur modular dan berorientasi layanan harus menjadi tujuan jangka panjang bagi organisasi yang ingin mengadopsi alat dan teknik CI/CD modern dengan GKE. Arsitektur berbasis layanan telah terbukti meningkatkan kecepatan dan keandalan.
Kontrol sumber modern. Alat kontrol sumber modern seperti Git memungkinkan tim membangun alur kerja seperti pengembangan berbasis trunk, cabang fitur, dan permintaan penggabungan.
Mendesain CI/CD modern dengan GKE
Bagian ini menjelaskan platform pengiriman software dan komponennya. Untuk meningkatkan performa pengiriman software, Anda perlu menerapkan CI/CD dan praktik terbaik teknis lainnya yang memungkinkan tim merilis dengan cepat dan beroperasi secara efisien.
Bagian ini juga membahas infrastruktur yang diperlukan untuk mendukung siklus proses pengiriman software dan cara mengelola infrastruktur tersebut secara konsisten dengan GKE. Terakhir, bagian ini memberikan contoh alur kerja pengiriman software dan menunjukkan cara repositori awal menyederhanakan orientasi dan penerapan praktik terbaik. Pertimbangan desain berikut ditinjau:
Platform pengiriman software. Framework dan kemampuan teknis yang membentuk dasar proses rilis aplikasi yang cepat dan reliabel.
Infrastruktur platform. Pertimbangan pengelolaan dan komponen infrastruktur yang diperlukan untuk membangun platform dan menjalankan aplikasi Anda.
Alur kerja pengiriman software. Cara tim bekerja sama untuk membangun, menguji, dan men-deploy kode dengan lebih efisien.
Repositori kode. Repositori yang melakukan beberapa fungsi, termasuk menyimpan logika bisnis aktual, konfigurasi khusus aplikasi, dan kode untuk membangun infrastruktur. Ini juga dapat menjadi repositori awal yang memfasilitasi penerapan praktik terbaik dan membantu menjaga konsistensi di seluruh proses otomatis.
Zona landing aplikasi. Entity logika yang memungkinkan developer men-deploy dan melakukan iterasi secara mandiri pada aplikasi mereka menggunakan kolom pelindung yang Anda terapkan.
Model operasi. Alat, proses, dan metode teknis untuk mengelola infrastruktur dan aplikasi yang membentuk platform.
Tata kelola. Proses dan pertimbangan yang Anda perlukan untuk memelihara dan mengelola platform pengiriman software.
Platform pengiriman software
Platform pengiriman software menyatukan alat dan menyederhanakan proses yang diperlukan untuk membangun, mengirim, men-deploy, dan mengoperasikan aplikasi.
Tanggung jawab untuk mempertahankan konfigurasi, stabilitas, waktu beroperasi, dan skala aplikasi berbeda-beda antara operator, keamanan, dan tim developer, tetapi semua komponen dan tim harus bekerja sama untuk mempercepat rilis. Meskipun dokumen ini menjelaskan metode untuk meningkatkan pengelolaan kontrol sumber dan kemampuan observasi aplikasi, dokumen ini terutama berfokus pada continuous integration (CI), continuous delivery (CD), dan manajemen konfigurasi.
Untuk membangun platform pengiriman software yang lengkap, Anda memerlukan setiap komponen dalam diagram berikut:
Setiap komponen ini menyediakan fungsi ke sistem dan aplikasi yang berjalan di platform:
Pemantauan infrastruktur. Tingkat dasar pemantauan yang diperlukan saat menyediakan untuk memverifikasi apakah cluster Google Kubernetes Engine (GKE) berfungsi dengan benar, instance virtual machine (VM), dan infrastruktur lain yang diperlukan agar aplikasi dapat berfungsi.
Orkestrasi container. Platform yang mengoordinasikan deployment dan operasi aplikasi berbasis container. Contoh platform untuk orkestrasi container adalah Kubernetes, GKE, atau GKE Enterprise.
Container registry. Penyimpanan dan kontrol akses untuk image container.
CI. Proses penerapan tugas otomatis ke aplikasi sebelum deployment. Tugas CI biasanya mencakup pembuatan, pengemasan, dan pengujian. Jenis tugas bervariasi berdasarkan aplikasi dan organisasi.
CD. Proses deployment yang sangat otomatis dan diterapkan dengan frekuensi tinggi. Contoh metodologi mencakup persetujuan manual, deployment canary, deployment blue-green, atau deployment berkelanjutan.
Kebijakan. Kebijakan konfigurasi keamanan dan infrastruktur yang ditentukan oleh tim operasi dan keamanan serta terus diterapkan dan diberlakukan oleh platform.
Pengelolaan kode sumber. Misalnya, penyimpanan yang dikontrol versi untuk kode, file konfigurasi, dan definisi kebijakan. Dalam sistem CI/CD modern, pengelolaan kode sumber biasanya Git.
Pengelolaan konfigurasi. Sistem yang digunakan untuk menyimpan dan menerapkan konfigurasi aplikasi untuk lingkungan yang berbeda.
Kemampuan observasi aplikasi. Logging, pemantauan, pemberitahuan, dan pelacakan tingkat aplikasi yang digunakan oleh tim developer, operator, dan keamanan untuk memecahkan masalah dan memverifikasi operasi aplikasi yang benar.
Infrastruktur platform
Untuk mem-build platform pengiriman software yang skalabel, Anda memerlukan cluster Kubernetes untuk pengembangan, lingkungan praproduksi, dan beberapa cluster produksi. Cluster dapat melayani banyak fungsi yang berbeda:
Pengembangan. Di cluster ini, developer melakukan deployment ad hoc dari aplikasi mereka untuk pengujian dan eksperimen.
Lingkungan aplikasi.
Pra-produksi. Untuk setiap lingkungan praproduksi dalam alur kerja, Anda harus memiliki cluster Kubernetes untuk menghosting aplikasi Anda. Cluster ini harus menyerupai cluster produksi, sehingga Anda dapat mengurangi atau menghilangkan perbedaan di antara lingkungan dan, hasilnya, meningkatkan tingkat keberhasilan deployment.
Produksi. Cluster tersebut menjalankan beban kerja produksi Anda. Anda harus menggunakan beberapa cluster yang terdistribusi secara geografis. Tindakan ini akan meningkatkan keandalan dari kegagalan infrastruktur dan mengurangi masalah operasi Hari ke-2, seperti upgrade cluster dan penskalaan.
Diagram berikut menunjukkan arsitektur tingkat tinggi:
Dalam arsitektur ini, Anda mengelola cluster untuk setiap lingkungan melalui Config Sync. Konfigurasi cluster yang konsisten sangat penting karena memberi developer, operator, dan tim keamanan keyakinan bahwa lingkungan praproduksi dan produksi beroperasi dengan cara yang sama. Anda dapat menggunakan Config Sync untuk menyimpan dan menerapkan konfigurasi umum di seluruh fleet cluster Anda. Setelah konfigurasi cluster distandarisasi, dapat diaudit, dan skalabel, Anda dapat berfokus pada alur kerja pengiriman software, serta orientasi dan deployment aplikasi.
Anda dapat mengelola deployment ke cluster pengembangan, staging, dan produksi melalui pipeline CI/CD aplikasi. Pengelolaan kontrol sumber berfungsi sebagai titik koordinasi untuk kode dan konfigurasi aplikasi. Pipeline CI/CD dan image container untuk aplikasi diisolasi ke lingkungan aplikasi tersebut. Anda menginisialisasi repositori aplikasi dan konfigurasi menggunakan repositori awal dan alat otomatis. Misalnya, Anda dapat menggunakan Cloud Build untuk menjalankan Terraform guna mengaktivasi dan menginisialisasi aplikasi baru secara otomatis.
Anda men-deploy aplikasi ke zona landing masing-masing di setiap cluster, sehingga aplikasi terisolasi pada jaringan dan identitas. Anda melakukan inisialisasi zona landing aplikasi di seluruh lingkungan menggunakan Config Sync, dan menggunakan Anthos Service Mesh atau Multi Cluster Ingress untuk membuat cluster produksi tampak seperti satu cluster dengan membuat mesh jaringan yang mencakup banyak cluster.
Alur kerja pengiriman software
Komponen inti dari platform pengiriman software adalah sistem CI/CD. Saat builder platform mulai menentukan proses CI/CD, mereka harus memastikan bahwa setiap komponen menghasilkan atau menggunakan artefak yang mematuhi antarmuka standar. Menggunakan antarmuka standar akan menyederhanakan penggantian komponen saat implementasi yang lebih baik diluncurkan ke pasar.
Saat membuat platform untuk aplikasi dalam container, Anda dapat menggunakan tiga antarmuka standar antar-komponen: repositori Git, image Docker, dan manifes Kubernetes. Antarmuka ini memungkinkan Anda membuat pipeline CI/CD yang dapat digunakan kembali dan fleksibel dengan alur kerja pengembangan, build, dan rilis, seperti yang ditunjukkan diagram berikut:
Alur kerja ini berjalan sebagai berikut:
Developer memasukkan kode aplikasi mereka ke repositori kode.
Sistem CI menguji kode, membuat artefak image Docker, dan menyimpan artefak tersebut di registry.
Setelah artefak siap untuk deployment, referensi ke artefak tersebut akan ditambahkan ke konfigurasi aplikasi.
Konfigurasi aplikasi tersebut dirender menjadi format yang dapat dibaca Kubernetes dan disimpan dalam repositori kode. Update untuk repositori ini memicu pipeline deployment yang men-deploy artefak di lingkungan pengembangan terintegrasi.
Setelah pengujian di lingkungan pengembangan terintegrasi selesai, operator mempromosikan deployment ke lingkungan pra-produksi.
Setelah memastikan aplikasi berfungsi seperti yang diharapkan dalam lingkungan praproduksi, operator mendapatkan persetujuan di pipeline deployment dan mempromosikan rilis ke lingkungan produksi.
Saat operator membuat perubahan pada konfigurasi dasar, perubahan tersebut akan diterapkan di seluruh organisasi. Saat operator meng-commit perubahan ke repositori-nya, update konfigurasi aplikasi (dan deployment berikutnya) dapat dipicu secara otomatis. Atau, perubahan operator dapat diambil saat developer men-deploy perubahan mereka lagi.
Secara paralel, engineer keamanan dapat menerapkan dan menyesuaikan kebijakan yang menentukan apa yang dapat di-deploy, lalu menerapkan kebijakan tersebut ke repositori kebijakan mereka.
Dengan metodologi GitOps, Anda dapat mewajibkan pendekatan deklaratif untuk setiap perubahan pada aplikasi dan cluster. Dengan pendekatan ini, semua perubahan harus diaudit dan ditinjau sebelum dapat diberlakukan. Dalam model deklaratif ini, Anda menyimpan file konfigurasi di repositori Git, yang memungkinkan Anda menyimpan log perubahan, melakukan rollback deployment yang gagal, dan melihat potensi dampak dari perubahan yang diusulkan.
Dalam arsitektur referensi terkait, Anda menggunakan kustomize untuk mengontrol konfigurasi aplikasi di organisasi Anda. Alat kustomize
memungkinkan operator membuat dasar yang disebut konfigurasi aplikasi yang
dapat disesuaikan oleh tim pengembangan Anda tanpa perlu menambahkan atau mengubah kode apa pun di
dasar tersebut. Dengan menentukan konfigurasi dasar, tim platform dapat membuat dan melakukan iterasi
praktik terbaik untuk organisasi. Operator dan developer dapat melakukan iterasi deployment secara independen, dan developer akan menerapkan praktik terbaik yang disiapkan oleh operator. Ketika operator perlu menerapkan praktik terbaik baru untuk organisasi, mereka membuat perubahan pada dasarnya, dan perubahan tersebut secara otomatis ditarik dengan deployment berikutnya dari developer.
Repositori kode
Repositori kode sumber berada di jantung sistem CI/CD. Operator, developer, dan engineer keamanan memiliki repositori masing-masing untuk menyebarkan perubahan ke dalam platform. Menggunakan repositori Git sebagai dasar untuk semua perubahan dalam sistem akan memberikan beberapa manfaat:
Kemampuan audit bawaan. {i>Commit<i} berisi informasi tentang kapan, apa, dan siapa yang mengubah sistem.
Proses rollback yang disederhanakan. Kemampuan kembali Git memungkinkan Anda melakukan rollback ke status sistem sebelumnya.
Pembuatan Versi. Anda dapat memberi tag commit Git untuk menunjukkan versi status sistem.
Transaksi. Anda harus menyelesaikan konflik status secara eksplisit dan meninjaunya sebelum dapat mengintegrasikan perubahan ke dalam status.
Diagram berikut menunjukkan cara berbagai tim berinteraksi dengan repositori terpusat untuk semua perubahan:
Bagian berikut menjelaskan cara operator, developer, dan engineer keamanan menggunakan repositori Git dalam sistem CI/CD modern.
Repositori operator
Repositori yang dikelola operator berisi praktik terbaik untuk CI/CD dan konfigurasi aplikasi untuk membantu tim Anda melakukan aktivasi aplikasi sambil mengadopsi praktik terbaik organisasi sejak awal. Dengan operator yang mengelola repositori, developer dapat menggunakan update apa pun pada praktik terbaik organisasi dengan sesedikit mungkin gangguan pada alur kerja mereka.
Operator dapat mengenkode praktik terbaik organisasi mereka menjadi dua repositori. Repositori pertama adalah tempat operator mengelola praktik terbaik pipeline CI/CD bersama. Dalam repositori ini, operator menyediakan library tugas bawaan yang dapat digunakan developer untuk membangun pipeline mereka. Repositori aplikasi developer secara otomatis mewarisi tugas dan logika di dalamnya; tugas-tugas tersebut tidak perlu disalin secara manual. Contoh tugas yang dapat distandarkan di seluruh organisasi mencakup tugas berikut:
Pembuatan dan penyimpanan artefak
Metodologi pengujian untuk berbagai bahasa
Langkah-langkah penerapan
Pemeriksaan kebijakan
Pemindaian keamanan
Repositori kedua yang dikelola oleh operator menyimpan praktik terbaik untuk mengonfigurasi aplikasi. Dalam konteks GKE, praktik terbaik mencakup memastikan cara mengelola manifes deklaratif dalam model resource Kubernetes. Manifes ini menjelaskan status aplikasi yang diinginkan. Operator dapat membuat konfigurasi dasar untuk berbagai jenis aplikasi sehingga developer mendapatkan jalur yang disederhanakan untuk men-deploy aplikasi mereka sesuai dengan praktik terbaik organisasi.
Repositori aplikasi
Repositori aplikasi menyimpan logika bisnis aplikasi dan konfigurasi khusus apa pun yang diperlukan agar aplikasi dapat beroperasi dengan benar.
Saat operator membuat dan mengelola praktik terbaik dengan cara yang terkodifikasi, developer dapat menggunakan praktik terbaik tersebut. Untuk melakukannya, developer mereferensikan tugas untuk CI/CD dan basis aplikasi yang dibuat operator di repositori mereka sendiri. Setelah developer melakukan perubahan, operator dapat menyesuaikan deployment aplikasi lebih lanjut dengan menambahkan konfigurasi khusus lingkungan, seperti URL database, atau label dan anotasi resource.
Contoh artefak yang dapat Anda simpan di repositori aplikasi mencakup:
Kode sumber aplikasi
Dockerfileyang menjelaskan cara membangun dan menjalankan aplikasiDefinisi pipeline CI/CD
Ekstensi atau modifikasi pada basis konfigurasi aplikasi yang dibuat oleh operator
Repositori Infrastructure as Code
Infrastruktur sebagai repositori kode menyimpan kode untuk membangun infrastruktur yang diperlukan untuk menjalankan aplikasi. Infrastrukturnya dapat mencakup jaringan dan platform orkestrasi container seperti GKE. Biasanya, admin infrastruktur adalah pemilik repositori ini. Operator dapat memperbaruinya untuk menerapkan praktik terbaik.
Contoh artefak yang dapat Anda simpan di repositori aplikasi mencakup:
- Kode bahasa deklaratif (Terraform, Pulumi) yang mewakili objek infrastruktur.
Skrip shell atau python yang melengkapi definisi API deklaratif.
Ekstensi atau modifikasi pada template infrastruktur dasar yang dibuat oleh tim infrastruktur.
Repositori konfigurasi dan kebijakan
Memastikan platform yang ditingkatkan keamanannya dan konsisten adalah prioritas utama bagi operator dan engineer keamanan.
Konfigurasi
Konfigurasi terpusat memungkinkan Anda menerapkan perubahan konfigurasi ke seluruh sistem. Beberapa item konfigurasi umum yang dapat Anda kelola secara terpusat mencakup:
Namespace Kubernetes
Kuota
Kontrol akses berbasis peran, {i>Role-based access control<i}
Kebijakan jaringan
Anda harus secara konsisten menerapkan jenis konfigurasi ini di seluruh cluster sehingga tim aplikasi tidak menyalahgunakan atau menyalahgunakan infrastruktur. Menggunakan repositori Git untuk menyimpan konfigurasi dapat meningkatkan proses seperti mengaudit dan men-deploy konfigurasi melalui metode seperti GitOps. Alat seperti Config Sync dapat menyederhanakan proses penerapan konfigurasi secara seragam di seluruh infrastruktur Anda.
Kebijakan
Karena developer dapat memperluas konfigurasi dasar yang dibuat operator, Anda memerlukan cara untuk membatasi resource yang dibuat dalam cluster yang membentuk platform. Dalam beberapa kasus, Anda dapat membuat kebijakan yang memungkinkan developer membuat resource hanya jika resource tersebut memenuhi persyaratan tertentu, misalnya membuat objek Layanan Kubernetes yang tidak dapat dikonfigurasi untuk load balancing eksternal.
Dalam arsitektur referensi terkait, Anda menggunakan Pengontrol Kebijakan untuk menerapkan kebijakan.
Repositori awal
Repositori pemicu membantu penerapan CI/CD, infrastruktur, dan praktik terbaik pengembangan di seluruh platform. Repositori awal dapat secara signifikan mengurangi biaya yang terkait dengan penerapan praktik terbaik. Pada akhirnya, praktik terbaik membantu meningkatkan kecepatan fitur, keandalan, dan produktivitas tim. Dalam arsitektur referensi terkait, ada beberapa repositori awal untuk aplikasi dan infrastruktur awal CI, CD, Kubernetes, Go, Java, dan Python.
Continuous integration
Organisasi biasanya memiliki serangkaian tugas standar yang diterapkan ke aplikasi selama CI. Misalnya, dalam implementasi referensi, kumpulan dasar dari tahapan CI adalah sebagai berikut: mengompilasi kode, dan mem-build image container. Karena tahapan tersebut ditentukan di repositori awal, tahapan tersebut diterapkan secara seragam di seluruh platform. Tim aplikasi individual dapat menambahkan langkah-langkah tambahan.
Continuous delivery
Seperti halnya CI, proses untuk CD biasanya memiliki serangkaian langkah standar untuk men-deploy aplikasi melalui lingkungan pengembangan, praproduksi, dan produksi. Terlepas dari metodologi deployment yang digunakan, repositori awal memungkinkan tim platform menerapkan metodologi tersebut secara seragam di seluruh aplikasi dan lingkungan. Dalam implementasi referensi, proses deployment mencakup peluncuran untuk deployment pengembangan, pra-produksi, deployment produksi di beberapa cluster, dan persetujuan manual untuk deployment produksi menggunakan Cloud Deploy.
Konfigurasi aplikasi
Agar platform pengiriman software efektif, Anda memerlukan cara yang seragam dan konsisten untuk menerapkan konfigurasi aplikasi. Dengan menggunakan alat seperti
kustomize dan repositori awal untuk konfigurasi Kubernetes, platform
dapat memberikan dasar yang konsisten untuk konfigurasi aplikasi. Misalnya, dalam
implementasi referensi, konfigurasi dasar kustomize
menginisialisasi repositori lingkungan aplikasi dengan kumpulan dasar konfigurasi
yang paling baik yang diketahui. Setiap tim aplikasi kemudian dapat menyesuaikan
konfigurasi dengan kebutuhan mereka.
Aplikasi awal
Aplikasi awal dapat membantu Anda mengurangi overhead yang terkait dengan penerapan praktik terbaik, misalnya, praktik terbaik kemampuan observasi dan container.
Kemampuan observasi. Untuk mengoperasikan aplikasi secara efisien dan membantu memastikan keandalan, aplikasi harus memperhitungkan logging, metrik, dan pelacakan. Aplikasi pemicu membantu tim membangun framework dan strategi yang mendukung kemampuan observasi.
Praktik terbaik penampung. Saat mem-build aplikasi dalam container, Anda harus mem-build image container yang berukuran kecil dan bersih. Praktik terbaik untuk container mencakup memaketkan satu aplikasi dalam gambar, menghapus alat yang tidak diperlukan dari image, dan secara aktif mencoba menghasilkan gambar kecil dari image dasar yang minimal. Untuk mengetahui informasi selengkapnya, baca Praktik terbaik untuk membangun container.
Arsitektur referensi menyediakan aplikasi Go dasar, aplikasi Java dasar, dan aplikasi Python dasar sebagai titik awal. Anda harus menambahkan aplikasi awal yang disesuaikan untuk bahasa, technology stack, dan jenis aplikasi yang dikembangkan oleh tim Anda.
Repositori awal infrastruktur
Repositori awal infrastruktur dilengkapi dengan kode bawaan yang diperlukan untuk membuat berbagai komponen infrastruktur. Repositori ini menggunakan template dan modul standar sebagaimana ditentukan oleh tim infrastruktur.
Misalnya, dalam implementasi referensi, platform-template berisi kode awal untuk membangun project Google Cloud, Virtual Private Cloud, dan cluster GKE. Template ini biasanya digunakan oleh tim infrastruktur untuk mengelola infrastruktur yang digunakan oleh beberapa tim aplikasi sebagai resource bersama. Demikian pula, infra-template berisi kode infrastruktur awal dasar yang mungkin diperlukan aplikasi, misalnya, database Cloud Storage atau Spanner. Template ini biasanya digunakan oleh tim aplikasi untuk mengelola infrastruktur aplikasi mereka.
Repositori template bersama
Repositori template bersama memberikan template tugas standar yang dapat digunakan kembali oleh siapa saja di organisasi. Misalnya, modul infrastruktur sebagai kode seperti modul Terraform yang dapat digunakan untuk membuat resource infrastruktur seperti jaringan dan komputasi.
Zona landing aplikasi
Saat Anda menggunakan CI/CD bersama, konfigurasi aplikasi bersama, serta kebijakan dan konfigurasi yang konsisten di seluruh cluster, Anda dapat menggabungkan kemampuan tersebut untuk membuat zona landing aplikasi.
Zona landing adalah entity logika terkunci yang memungkinkan developer men-deploy dan melakukan iterasi pada aplikasi mereka. Zona landing aplikasi menggunakan kolom pengaman yang Anda terapkan sehingga developer dapat beroperasi secara mandiri. Untuk setiap aplikasi, Anda membuat namespace Kubernetes di setiap cluster dari setiap lingkungan (misalnya untuk production, dev, atau staging). Konsistensi ini membantu operator melakukan debug dan memelihara lingkungan dari waktu ke waktu.
Diagram berikut mengilustrasikan konsep zona pendaratan:
Model operasi
Saat Anda mengoperasikan platform pengiriman software dengan CI/CD modern, penting untuk menjaga lingkungan, infrastruktur, dan proses tetap konsisten dan terbaru. Oleh karena itu, Anda harus merencanakan dan memilih model operasi untuk platform dengan cermat. Anda dapat memilih dari berbagai model, seperti cluster as a service, blueprint, atau infrastruktur multi-tenant.
Karena penting untuk mempertahankan infrastruktur yang konsisten, membatasi inefisiensi, dan memungkinkan tim berfokus pada pengiriman aplikasi, sebaiknya Anda men-deploy infrastruktur multi-tenant. Dengan men-deploy aplikasi di infrastruktur multi-tenant, tim aplikasi tidak perlu mengelola infrastruktur, sehingga tim operator dan keamanan dapat fokus untuk menjaga konsistensi infrastruktur.
Pertimbangan untuk infrastruktur multi-tenant
Saat Anda mem-build platform pengiriman software multi-tenant, ada beberapa hal yang dapat dipertimbangkan untuk disertakan ke dalam platform:
Isolasi beban kerja. Konsep zona landing aplikasi adalah menyediakan framework untuk mengisolasi workload. Zona landing adalah kombinasi namespace, kebijakan jaringan, dan RBAC. Semua kebijakan ini harus dikelola dan diterapkan secara terpusat melalui Config Sync.
Pemantauan penggunaan penyewa. Untuk mendapatkan perincian biaya pada namespace dan label individual dalam cluster, Anda dapat menggunakan pengukuran penggunaan GKE. Pengukuran penggunaan GKE melacak informasi permintaan resource dan penggunaan resource untuk workload cluster, yang dapat Anda filter lebih lanjut berdasarkan namespace dan label. Saat Anda mengaktifkan pengukuran penggunaan GKE pada cluster multi-tenant, data penggunaan resource akan ditulis ke tabel BigQuery. Anda dapat mengekspor metrik khusus tenant ke set data BigQuery dalam project tenant yang sesuai, dan auditor kemudian dapat menganalisis metrik tersebut untuk menentukan perincian biaya.
Kuota resource. Untuk memastikan semua tenant yang berbagi cluster memiliki akses yang adil ke resource cluster, Anda harus menerapkan kuota resource. Buat kuota resource untuk setiap namespace berdasarkan jumlah Pod yang di-deploy oleh setiap tenant, serta jumlah memori dan CPU yang dibutuhkan setiap Pod.
Beberapa cluster untuk setiap lingkungan. Untuk meningkatkan keandalan aplikasi dan platform, Anda harus menggunakan beberapa cluster untuk setiap lingkungan praproduksi dan produksi. Dengan tersedianya beberapa cluster, Anda dapat meluncurkan aplikasi satu per satu ke cluster untuk level validasi canary tambahan. Selain itu, memiliki beberapa cluster akan menghilangkan kekhawatiran yang berkaitan dengan siklus proses pengelolaan dan upgrade cluster.
Logging dan pemantauan khusus tenant. Untuk menyelidiki operasi aplikasi mereka, tenant memerlukan akses ke log dan metrik. Dalam lingkungan multi-tenant, logging dan pemantauan harus bersifat khusus aplikasi. Untuk metrik dan pemantauan, Anda dapat menggunakan Google Cloud Managed Service for Prometheus dan Grafana untuk setiap namespace. Untuk log, Anda harus membuat sink untuk mengekspor entri log ke set data BigQuery, lalu memfilter set data berdasarkan namespace tenant. Penyewa kemudian dapat mengakses data yang diekspor di BigQuery.
Untuk mengetahui informasi selengkapnya tentang infrastruktur multi-tenant, lihat Praktik terbaik untuk multi-tenancy perusahaan.
Batas isolasi
Platform pengiriman software dibangun dan digunakan oleh banyak tim, sehingga penting untuk memiliki batasan isolasi yang tepat di antara berbagai komponen platform. Batas isolasi membantu membangun platform yang tangguh dengan memberikan sifat berikut:
Memisahkan tanggung jawab. Setiap tim mengelola resource dalam batas-batas isolasi mereka tanpa mengkhawatirkan sisanya. Misalnya, tim infrastruktur hanya bertanggung jawab untuk memelihara cluster GKE. Operator atau developer hanya bertanggung jawab untuk memelihara pipeline CI/CD dan kode aplikasi.
Kontrol akses terperinci. Jika resource dipisahkan oleh batas isolasi, gunakan kontrol akses terperinci untuk membatasi akses.
Mengurangi area yang terdampak. Anda dapat membuat perubahan pada komponen secara independen tanpa memengaruhi komponen lain.
Mengurangi error manual. Karena kontrol akses sangat terperinci, Anda dapat menghindari error manual, seperti deployment ke cluster produksi secara tidak sengaja dari lingkungan pengembangan.
Batas-batas isolasi ini bisa berada di antara aplikasi, infrastruktur, dan aplikasi yang berbeda, atau bahkan antara lingkungan aplikasi yang berbeda.
Tata kelola
Tujuan utama dari platform pengiriman software dan sistem CI/CD modern adalah untuk meningkatkan efisiensi proses pengiriman software secara keseluruhan. Dalam hal mengelola platform, Anda memiliki dua pertimbangan utama: orientasi aplikasi, yang umumnya termasuk dalam kategori tata kelola; dan pengembangan dan pemeliharaan platform yang berkelanjutan (yaitu, memperlakukan platform seperti produk).
Orientasi dan pengelolaan aplikasi
Tujuan penggunaan metodologi dan alat CI/CD modern adalah untuk menyederhanakan proses rilis dan orientasi layanan baru. Orientasi aplikasi baru harus menjadi proses mudah yang dapat Anda lakukan dengan sedikit input dari tim operasi dan keamanan. Hal ini tidak berarti bahwa tim operasi dan keamanan tidak terlibat, tetapi input awal mereka dari perspektif deployment dan keamanan akan otomatis ditangani melalui proses penyediaan. Setelah diaktivasi, tim operasi dan keamanan secara alami disertakan dalam proses rilis melalui permintaan penggabungan, pembaruan kebijakan, dan penerapan praktik terbaik.
Sebaiknya buat beberapa otomatisasi untuk mengaktivasi aplikasi baru. Hal ini dapat mencakup pembuatan repositori kode, pipeline CI/CD, zona pendaratan, dan infrastruktur apa pun yang diperlukan untuk aplikasi. Otomatisasi memisahkan ketergantungan yang kompleks dari tim pengembangan pada tim lain dalam organisasi dan memberikan otonomi kepada developer untuk melayani aplikasi secara mandiri. Hal ini memungkinkan developer mulai melakukan iterasi pada kode aplikasi dengan sangat cepat dan tidak membuang waktu dalam melakukan tugas selain menulis kode. Otomatisasi harus memungkinkan developer menjalankan aplikasi di lingkungan pengembangan. Untuk membawa aplikasi ke lingkungan yang lebih tinggi, tim lain harus dilibatkan dan proses peninjauan harus diikuti.
Dalam arsitektur referensi terkait, otomatisasi ini disebut sebagai Factory Aplikasi.
Platform sebagai produk
Alur kerja CI/CD adalah produk software, dengan pengecualian pengguna produk tersebut adalah tim pengembangan, operasi, dan keamanan. Dengan mempertimbangkan hal itu, platform ini memerlukan peran dan proses pengembangan software yang sama, seperti pemilik produk, pemasaran (meskipun berjalan secara internal), feedback loop pengguna, dan siklus pengembangan fitur.
Men-deploy CI/CD dengan GKE
Saat Anda mulai men-deploy CI/CD modern dengan GKE ke organisasi, memilih aplikasi uji coba terbaik sangatlah penting. Tim pengembangan, operasi, dan keamanan juga perlu mempertimbangkan faktor-faktor lain saat bekerja, yang akan dibahas di bagian ini.
Memilih aplikasi uji coba
Memilih aplikasi pertama untuk dipindahkan ke platform bisa menjadi langkah awal yang sulit. Kandidat yang baik untuk uji coba adalah layanan yang memproses data atau menangani permintaan, tetapi tidak menyimpan data—misalnya lapisan cache, frontend web, atau aplikasi pemrosesan berbasis peristiwa. Biasanya, aplikasi ini lebih tahan terhadap periode nonaktif dan error deployment dalam jumlah kecil yang dapat terjadi setiap kali Anda bekerja dengan teknik deployment dan manajemen konfigurasi yang baru. Seiring tim mendapatkan lebih banyak pengalaman dengan CI/CD dan mulai merasakan manfaat dalam keandalan dan kecepatan, Anda dapat mulai memindahkan layanan inti ke platform pengiriman software.
Pertimbangan developer
Saat Anda bekerja dalam proses pengembangan CI/CD modern, fitur, perubahan, dan deployment dapat terjadi dengan peningkatan frekuensi dan lainnya secara asinkron. Tim pengembangan perlu menyadari bagaimana perubahan memengaruhi sistem downstream atau dependen dan cara perubahan tersebut diuji. Jalur komunikasi antara tim pengembangan, operasi, dan keamanan harus fleksibel. Praktik yang baik adalah untuk berinvestasi dalam praktik pembuatan versi yang lebih baik untuk aplikasi dan kontrak data yang digunakan untuk berkomunikasi oleh berbagai layanan. Bersama dengan peningkatan metode komunikasi dan pembuatan versi, mengimplementasikan fitur dalam bagian-bagian kecil serta memanfaatkan cabang dan flag fitur dapat meningkatkan cara Anda menguji dan merilis fitur.
Pertimbangan operator
Dengan platform pengiriman software, tim operasi harus berfungsi lebih seperti tim pengembangan. Alih-alih mem-build fitur yang ditampilkan ke pihak eksternal, mereka membangun alat dan proses internal yang membantu memfasilitasi pengembangan, deployment, dan operasi aplikasi yang ditampilkan kepada pihak eksternal. Alat platform digunakan oleh tim mereka sendiri serta tim pengembangan dan keamanan. Operator harus membuat alat untuk membantu peluncuran versi baru aplikasi dan juga meluncurkannya kembali jika terjadi error aplikasi atau kegagalan deployment. Operator juga harus lebih menekankan upaya membangun sistem pemantauan dan peringatan agar mendeteksi kegagalan secara proaktif dan memberikan peringatan yang sesuai.
Pertimbangan tim keamanan
Tim keamanan harus berupaya menjadikan keamanan sebagai tanggung jawab bersama antara mereka sendiri, serta tim operasi dan pengembangan. Pola ini biasanya disebut shift kiri pada keamanan, yang melibatkan keamanan informasi (InfoSec) di awal proses pengembangan, developer menggunakan alat yang telah disetujui, dan pengujian keamanan diotomatiskan. Selain teknik tersebut, Anda dapat menentukan dan menerapkan kebijakan keamanan secara terprogram dengan Pengontrol Kebijakan. Kombinasi teknik dan alat menempatkan penegakan keamanan dalam postur yang lebih proaktif.
Langkah selanjutnya
Pelajari lebih lanjut praktik terbaik untuk menyiapkan penggabungan identitas.
Bacaan tentang pola pemantauan dan logging hybrid dan multi-cloud.