Dokumen ini menjelaskan framework untuk menerapkan proses continuous integration/continuous deployment (CI/CD) modern di platform deployment software multi-tim yang menggunakan Google Kubernetes Engine.
Kemudian, Anda dapat melakukan iterasi pada platform untuk lebih meningkatkan performa untuk 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 untuk mencapai peningkatan kecepatan pengembangan dan deployment yang belum pernah ada sebelumnya. Namun, meskipun adopsi Kubernetes dan penampung meningkat, banyak organisasi tidak sepenuhnya menyadari manfaat dalam kecepatan rilis, stabilitas, dan efisiensi operasional karena praktik CI/CD mereka tidak memanfaatkan sepenuhnya Kubernetes atau mengatasi masalah operasi dan keamanan.
Pendekatan CI/CD yang benar-benar modern harus mencakup lebih dari sekadar otomatisasi. Untuk mewujudkan peningkatan kecepatan dan keamanan sepenuhnya, serta menggunakan kecanggihan Kubernetes dan container, Anda perlu menyederhanakan 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 penerapan, organisasi Anda dapat memperoleh manfaat berikut untuk pengembangan dan operasi:
Mengurangi waktu tunggu untuk perubahan.
Izinkan tim operasi dan keamanan membuat serta memperbarui praktik terbaik untuk menyediakan aplikasi dan kebijakan penyediaan di seluruh platform.
Sederhanakan orientasi aplikasi dengan memberi tim project awal yang sepenuhnya berfungsi dan dapat di-deploy yang memiliki praktik terbaik organisasi Anda.
Mengurangi waktu yang diperlukan untuk memulihkan layanan.
Kelola semua konfigurasi secara deklaratif menggunakan GitOps untuk audit, rollback, dan peninjauan yang disederhanakan.
Standarkan metodologi deployment dan pemantauan di seluruh organisasi untuk mengurangi waktu yang diperlukan untuk mengidentifikasi faktor-faktor yang berkontribusi pada masalah yang memengaruhi 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.
Gunakan GitOps untuk deployment, pengelolaan rilis yang lebih baik, dan pelacakan perubahan.
Terapkan guard rail agar tim layanan dapat sering melakukan deployment.
Buat proses peluncuran progresif untuk men-deploy secara konsisten di seluruh lingkungan praproduksi, sehingga developer memiliki keyakinan yang diperlukan untuk men-deploy perubahan ke produksi.
Untuk melihat bagaimana manfaat dan konsep ini diwujudkan dengan GKE dan CI/CD, lihat dokumen lain dalam seri 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.
Karakteristik organisasi
Mengadopsi platform modern memerlukan dukungan berikut dari tim teknis dan pimpinan 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 mengadopsi alat dan teknik ini, Anda memerlukan dukungan kuat dari satu atau beberapa anggota tim kepemimpinan. Penasehat kepemimpinan yang paling efektif adalah mereka yang melihat perubahan ini sebagai proses peningkatan berkelanjutan dan ingin memberdayakan tim mereka, bukan mengelolanya.
Penyesuaian strategi teknis dan bisnis. Sebaiknya tim bisnis dan tim teknis Anda menyelaraskan empat ukuran pengiriman software utama yang ditentukan oleh DevOps Research and Assessment (DORA): lama pengerjaan perubahan, frekuensi deployment, waktu untuk memulihkan layanan, dan tingkat kegagalan perubahan. Menyelaraskan ukuran tersebut akan memberi tim bisnis dan tim teknis Anda sasaran bersama, sehingga mereka dapat bersama-sama menghitung laba atas investasi, menyesuaikan laju perubahan, dan mengubah tingkat investasi.
Referensi. Agar berhasil, tim yang mengembangkan praktik CI/CD modern dan membangun rantai alat memerlukan resource yang diperlukan: waktu, orang, dan infrastruktur. Tim ini memerlukan waktu untuk mencoba dan memilih proses dan alat terbaik. Idealnya, tim ini mewakili berbagai fungsi dalam proses pengiriman software dan dapat menarik resource lain dari seluruh organisasi. Terakhir, tim memerlukan kemampuan untuk menyediakan infrastruktur, termasuk resource cloud dan alat software.
Kesediaan untuk mengadopsi alat baru. Alat dan teknik CI/CD modern sering kali disertai dengan alat dan proses baru. Tim perlu bereksperimen dengan proses dan alat tersebut dan terbuka untuk mengadopsinya. Feedback loop diperlukan agar tim platform dapat mendengar 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 siap mengubah cara mereka beroperasi dan bekerja sama. Misalnya, tim pengembangan dan operasi harus bersedia mengambil lebih banyak tanggung jawab atas keamanan, dan tim keamanan dan operasi harus bersedia menyederhanakan proses persetujuan perubahan.
Kemampuan teknis
Mengadopsi pendekatan CI/CD modern juga mengharuskan tim Anda secara teknis bersiap dengan cara berikut:
Pengalaman dengan penampung. Tim yang mengadopsi pendekatan CI/CD modern memerlukan beberapa pengalaman dengan penampung. Idealnya, pengalaman ini menyertakan teknik pengembangan untuk mem-build image container dan menggabungkan container untuk mem-build sistem yang lebih besar.
Strategi continuous integration. Tim memerlukan beberapa pengalaman menggunakan alat CI (seperti Jenkins, TeamCity, Bamboo, dan CircleCI) dan melakukan beberapa continuous integration serta pengujian otomatis. Sebaiknya organisasi merencanakan cara meningkatkan proses tersebut lebih lanjut.
Otomatisasi deployment. Tim memerlukan beberapa pengalaman dengan otomatisasi deployment. Contoh alat deployment otomatis mencakup skrip shell dasar, Terraform, Chef, atau Puppet. Memiliki pengetahuan dasar tentang alat dan proses deployment otomatis sangatlah penting untuk menyederhanakan dan mengotomatiskan deployment.
Arsitektur berorientasi layanan. Meskipun bukan prasyarat untuk adopsi proses CI/CD modern, adopsi arsitektur modular dan berorientasi layanan harus menjadi sasaran jangka panjang 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 membuat 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 implementasi praktik terbaik. Pertimbangan desain berikut akan ditinjau:
Platform pengiriman software. Framework dan kemampuan teknis yang membentuk fondasi proses rilis aplikasi yang andal dan berkecepatan tinggi.
Infrastruktur platform. Komponen infrastruktur dan pertimbangan pengelolaan yang Anda perlukan untuk mem-build platform dan menjalankan aplikasi.
Alur kerja pengiriman software. Cara tim bekerja sama untuk mem-build, menguji, dan men-deploy kode secara lebih efisien.
Repositori kode. Repositori yang menjalankan beberapa fungsi, termasuk menyimpan logika bisnis yang sebenarnya, konfigurasi khusus aplikasi, dan kode untuk membuat infrastruktur. Ini juga dapat berupa repositori awal yang memfasilitasi penerapan praktik terbaik dan membantu mempertahankan konsistensi di seluruh proses otomatis.
Zona landing aplikasi. Entitas logika yang memungkinkan developer men-deploy dan melakukan iterasi pada aplikasi mereka secara otonom menggunakan guard rail yang Anda terapkan.
Model operasi. Alat, proses, dan metode teknis untuk mengelola infrastruktur dan aplikasi yang membentuk platform.
Pemerintahan. Proses dan pertimbangan yang perlu Anda lakukan untuk mempertahankan dan mengelola platform pengiriman software.
Platform pengiriman software
Platform pengiriman software menyatukan alat dan menyederhanakan proses yang diperlukan untuk mem-build, mengirimkan, men-deploy, dan mengoperasikan aplikasi.
Tanggung jawab untuk mempertahankan konfigurasi, stabilitas, waktu aktif, dan skala aplikasi bervariasi di antara tim operator, keamanan, dan developer, tetapi semua komponen dan tim harus bekerja sama untuk mempercepat rilis. Meskipun dokumen ini menjelaskan metode untuk meningkatkan pengelolaan kontrol sumber dan visibilitas aplikasi, dokumen ini terutama berfokus pada continuous integration (CI), continuous delivery (CD), dan pengelolaan konfigurasi.
Untuk mem-build platform pengiriman software yang lengkap, Anda memerlukan setiap komponen dalam diagram berikut:
Setiap komponen ini menyediakan fungsi untuk sistem dan aplikasi yang berjalan di platform:
Pemantauan infrastruktur. Tingkat dasar pemantauan yang diperlukan saat penyediaan untuk memverifikasi fungsi yang benar dari cluster Google Kubernetes Engine (GKE), instance virtual machine (VM), dan infrastruktur lainnya yang diperlukan agar aplikasi dapat berfungsi.
Orkesrasi container. Platform yang mengoordinasikan deployment dan operasi aplikasi berbasis container. Contoh platform untuk orkestrasi container adalah Kubernetes, GKE, atau GKE Enterprise.
Container registry. Kontrol penyimpanan dan akses untuk image container.
CI. Proses penerapan tugas otomatis ke aplikasi sebelum deployment. Tugas CI biasanya mencakup build, paket, 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 rolling.
Kebijakan. Kebijakan konfigurasi keamanan dan infrastruktur yang ditentukan oleh tim operasi dan keamanan serta terus diterapkan dan ditegakkan 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 adalah Git.
Pengelolaan konfigurasi. Sistem yang digunakan dalam menyimpan dan menerapkan konfigurasi aplikasi untuk berbagai lingkungan.
Kemampuan observasi aplikasi. Logging, pemantauan, pemberitahuan, dan pelacakan tingkat aplikasi yang digunakan tim developer, operator, dan keamanan untuk memecahkan masalah dan memverifikasi pengoperasian aplikasi yang tepat.
Infrastruktur platform
Untuk mem-build platform pengiriman software yang skalabel, Anda memerlukan cluster Kubernetes untuk pengembangan, lingkungan praproduksi, dan beberapa cluster produksi. Cluster dapat menjalankan berbagai fungsi:
Pengembangan. Di cluster ini, developer melakukan deployment ad hoc aplikasi mereka untuk pengujian dan eksperimen.
Lingkungan aplikasi.
Praproduksi. Untuk setiap lingkungan praproduksi dalam alur kerja, Anda harus memiliki cluster Kubernetes untuk menghosting aplikasi. Cluster ini harus menyerupai cluster produksi sehingga Anda dapat mengurangi atau menghilangkan perbedaan antara lingkungan dan, sebagai hasilnya, meningkatkan tingkat keberhasilan deployment.
Produksi. Cluster ini menjalankan workload produksi Anda. Anda harus menggunakan beberapa cluster yang terdistribusi secara geografis. Tindakan ini akan meningkatkan keandalan dari kegagalan infrastruktur dan meringankan masalah operasi Hari ke-2, seperti upgrade dan penskalaan cluster.
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 memberikan keyakinan kepada tim developer, operator, dan keamanan bahwa lingkungan praproduksi dan produksi beroperasi dengan cara yang serupa. Anda dapat menggunakan Config Sync untuk menyimpan dan menerapkan konfigurasi umum di seluruh cluster armada. Setelah konfigurasi cluster Anda diseragamkan, dapat diaudit, dan skalabel, Anda dapat berfokus pada alur kerja pengiriman software serta orientasi dan deployment aplikasi.
Anda 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 melakukan inisialisasi repositori aplikasi dan konfigurasi menggunakan repositori awal dan alat otomatis. Misalnya, Anda dapat menggunakan Cloud Build untuk menjalankan Terraform guna melakukan aktivasi dan menginisialisasi aplikasi baru secara otomatis.
Anda men-deploy aplikasi ke zona landing-nya sendiri di setiap cluster, sehingga aplikasi terisolasi jaringan dan identitas. Anda melakukan inisialisasi zona landing aplikasi di seluruh lingkungan menggunakan Config Sync, dan menggunakan Cloud 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 pembangun platform mulai menentukan proses CI/CD, mereka perlu memastikan bahwa setiap komponen menghasilkan atau menggunakan artefak yang mematuhi antarmuka standar. Penggunaan antarmuka standar menyederhanakan penggantian komponen saat implementasi yang lebih baik hadir di pasar.
Saat membuat platform untuk aplikasi dalam container, Anda dapat menggunakan tiga antarmuka standar antara 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 pada diagram berikut:
Alur kerja ini berfungsi sebagai berikut:
Developer meng-commit kode aplikasi mereka ke repositori kode.
Sistem CI menguji kode, membuat artefak image Docker, dan menyimpan artefak di registry.
Setelah artefak siap di-deploy, referensi ke artefak tersebut akan ditambahkan ke konfigurasi aplikasi.
Konfigurasi aplikasi tersebut dirender ke dalam format yang dapat dibaca Kubernetes dan disimpan di repositori kode. Update pada repositori ini memicu pipeline deployment yang men-deploy artefak di lingkungan pengembangan terintegrasi.
Setelah pengujian di lingkungan pengembangan terintegrasi selesai, operator akan mempromosikan deployment ke lingkungan praproduksi.
Setelah memastikan aplikasi berfungsi seperti yang diharapkan di 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 melakukan perubahan pada repositorinya, 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 melakukan kebijakan tersebut ke repositori kebijakan mereka.
Dengan menggunakan metodologi GitOps, Anda dapat mewajibkan pendekatan deklaratif untuk setiap perubahan pada aplikasi dan cluster. Dengan pendekatan ini, semua perubahan tunduk pada audit dan peninjauan sebelum dapat diterapkan. Dalam model deklaratif ini, Anda menyimpan file konfigurasi di repositori Git, yang memungkinkan Anda mempertahankan log perubahan, melakukan rollback deployment yang gagal, dan melihat potensi dampak perubahan yang diusulkan.
Dalam
arsitektur referensi terkait,
Anda menggunakan
kustomize
untuk mengontrol konfigurasi aplikasi di organisasi Anda. Alat kustomize
memungkinkan operator membuat apa yang disebut basis konfigurasi aplikasi yang
dapat disesuaikan oleh tim pengembangan Anda tanpa perlu menambahkan atau mengubah kode apa pun di
basis. Dengan menentukan konfigurasi dasar, tim platform dapat membuat dan melakukan iterasi
pada praktik terbaik untuk organisasi. Operator dan developer dapat melakukan iterasi pada deployment mereka secara independen, dengan developer menerapkan praktik terbaik yang disiapkan oleh operator. Saat operator perlu menerapkan praktik terbaik baru untuk
organisasi, mereka akan membuat perubahan di basis, dan perubahan tersebut
akan otomatis ditarik dengan deployment berikutnya dari developer.
Repositori kode
Repositori kode sumber adalah inti dari sistem CI/CD. Operator, developer, dan engineer keamanan masing-masing memiliki repositorinya sendiri untuk menyebarkan perubahan ke platform. Menggunakan repositori Git sebagai dasar untuk semua perubahan dalam sistem memberikan beberapa manfaat:
Kemampuan audit bawaan. Commit 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 pada 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 mengaktifkan aplikasi sekaligus mengadopsi praktik terbaik organisasi sejak awal. Dengan operator yang mengelola repositori, developer dapat menggunakan update apa pun pada praktik terbaik organisasi dengan gangguan sesedikit mungkin pada alur kerja mereka.
Operator dapat mengenkode praktik terbaik organisasi mereka ke dalam dua repositori. Repositori pertama adalah tempat operator mempertahankan praktik terbaik pipeline CI/CD bersama. Dalam repositori ini, operator menyediakan library tugas yang telah ditentukan sebelumnya kepada developer yang dapat mereka gunakan untuk membuat pipeline. Repositori aplikasi developer secara otomatis mewarisi tugas ini dan logika di dalamnya; tugas tidak perlu disalin secara manual. Contoh tugas yang dapat Anda standarkan di seluruh organisasi meliputi hal berikut:
Pembuatan dan penyimpanan artefak
Metodologi pengujian untuk berbagai bahasa
Langkah-langkah penerapan
Pemeriksaan kebijakan
Pemindaian keamanan
Repositori kedua yang dikelola operator menyimpan praktik terbaik untuk mengonfigurasi aplikasi. Dalam konteks GKE, praktik terbaik meliputi 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 memberikan jalur yang disederhanakan kepada developer untuk men-deploy aplikasi mereka sesuai dengan praktik terbaik organisasi.
Repositori aplikasi
Repositori aplikasi menyimpan logika bisnis aplikasi dan konfigurasi khusus yang diperlukan agar aplikasi dapat beroperasi dengan benar.
Saat operator membuat dan mempertahankan praktik terbaik dengan cara yang dikodifikasi, 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 lebih lanjut menyesuaikan deployment aplikasi dengan menambahkan konfigurasi khusus lingkungan seperti URL database atau label dan anotasi resource.
Contoh artefak yang dapat Anda simpan di repositori aplikasi meliputi hal berikut:
Kode sumber aplikasi
Dockerfileyang menjelaskan cara mem-build dan menjalankan aplikasiDefinisi pipeline CI/CD
Ekstensi atau modifikasi pada basis konfigurasi aplikasi yang dibuat oleh operator
Repositori infrastruktur sebagai kode
Repositori infrastruktur sebagai kode menyimpan kode untuk mem-build infrastruktur yang diperlukan untuk menjalankan aplikasi. Infrastruktur tersebut mungkin mencakup platform jaringan dan orkestrasi container seperti GKE. Biasanya, admin infrastruktur memiliki repositori ini. Operator dapat memperbaruinya untuk menerapkan praktik terbaik.
Contoh artefak yang dapat Anda simpan di repositori aplikasi meliputi hal berikut:
- 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 konsisten dan ditingkatkan keamanannya adalah prioritas utama bagi operator dan engineer keamanan.
Konfigurasi
Konfigurasi terpusat memungkinkan Anda menyebarkan perubahan konfigurasi di seluruh sistem. Beberapa item konfigurasi umum yang dapat Anda kelola secara terpusat meliputi hal berikut:
Namespace Kubernetes
Kuota
Kontrol akses berbasis peran (RBAC)
Kebijakan jaringan
Anda harus menerapkan jenis konfigurasi ini secara konsisten di seluruh cluster agar tim aplikasi tidak menyalahgunakan atau melanggar 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 di 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 awal membantu penerapan praktik terbaik CI/CD, infrastruktur, dan pengembangan di seluruh platform. Repositori awal dapat sangat mengurangi biaya yang terkait dengan penerapan praktik terbaik. Praktik terbaik, pada gilirannya, membantu meningkatkan kecepatan fitur, keandalan, dan produktivitas tim. Dalam arsitektur referensi terkait, ada beberapa repositori awal untuk infrastruktur dan aplikasi awal CI, CD, konfigurasi Kubernetes, Go, Java, dan Python.
Continuous integration
Organisasi biasanya memiliki kumpulan tugas standar yang diterapkan ke aplikasi selama CI. Misalnya, dalam implementasi referensi, kumpulan dasar tahap CI adalah sebagai berikut: mengompilasi kode, dan mem-build image container. Karena tahap tersebut ditentukan di repositori awal, tahap tersebut diterapkan secara seragam di seluruh platform. Setiap tim aplikasi dapat menambahkan langkah tambahan.
Continuous delivery
Serupa dengan 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 dev, praproduksi, 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
akan menginisialisasi repositori lingkungan aplikasi dengan kumpulan konfigurasi dasar
yang dikenal baik. Setiap tim aplikasi kemudian dapat menyesuaikan
konfigurasi sesuai kebutuhan mereka.
Aplikasi awal
Aplikasi awal dapat membantu Anda mengurangi overhead yang terkait dengan penerapan praktik terbaik—misalnya, praktik terbaik observabilitas dan penampung.
Kemampuan observasi. Untuk mengoperasikan aplikasi secara efisien dan membantu memastikan keandalan, aplikasi harus memperhitungkan logging, metrik, dan pelacakan. Aplikasi awal membantu tim membuat framework dan strategi yang mendorong visibilitas.
Praktik terbaik penampung. Saat mem-build aplikasi dalam container, Anda harus mem-build image container yang kecil dan bersih. Praktik terbaik untuk container mencakup mengemas satu aplikasi dalam gambar, menghapus alat yang tidak diperlukan dari gambar, dan secara aktif mencoba membuat gambar kecil dari image dasar minimal.
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, stack teknologi, dan jenis aplikasi yang dikembangkan tim Anda.
Repositori pemicu infrastruktur
Repositori awal infrastruktur dilengkapi dengan kode yang telah ditulis sebelumnya yang diperlukan untuk membuat berbagai komponen infrastruktur. Repositori ini menggunakan template dan modul standar seperti yang diputuskan oleh tim infrastruktur.
Misalnya, dalam implementasi referensi, platform-template berisi kode awal untuk mem-build 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 menyediakan 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 menggunakan CI/CD bersama, konfigurasi aplikasi bersama, serta kebijakan dan konfigurasi yang konsisten di seluruh cluster, Anda dapat menggabungkan kemampuan ini untuk membuat zona landing aplikasi.
Zona landing adalah entity logika yang terkunci yang memungkinkan developer men-deploy dan melakukan iterasi pada aplikasi mereka. Zona landing aplikasi menggunakan guard rail yang Anda terapkan sehingga developer dapat beroperasi secara otonom. Untuk setiap aplikasi, Anda membuat namespace Kubernetes di setiap cluster dari setiap lingkungan (misalnya, untuk produksi, pengembangan, atau staging). Konsistensi ini membantu operator men-debug dan mengelola lingkungan dari waktu ke waktu.
Diagram berikut menggambarkan konsep zona landing:
Model operasi
Saat Anda mengoperasikan platform pengiriman software dengan CI/CD modern, penting untuk menjaga lingkungan, infrastruktur, dan proses tetap konsisten dan up-to- date. Oleh karena itu, Anda perlu 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 perluasan, dan memungkinkan tim berfokus pada penyediaan aplikasi, sebaiknya Anda men-deploy infrastruktur multi-tenant. Men-deploy aplikasi di infrastruktur multi-tenant akan menghilangkan kebutuhan tim aplikasi untuk mengelola infrastruktur dan memungkinkan tim operator dan keamanan berfokus untuk menjaga infrastruktur tetap konsisten.
Pertimbangan untuk infrastruktur multi-tenant
Saat Anda mem-build platform pengiriman software multi-tenant, ada beberapa hal yang dapat Anda pertimbangkan untuk di-build ke dalam platform:
Isolasi beban kerja. Konsep zona landing aplikasi adalah untuk 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 tenant. Untuk mendapatkan perincian biaya pada setiap namespace dan label dalam cluster, Anda dapat menggunakan pengukuran penggunaan GKE. Pengukuran penggunaan GKE melacak informasi tentang permintaan resource dan penggunaan resource untuk workload cluster, yang dapat Anda filter lebih lanjut berdasarkan namespace dan label. Saat Anda mengaktifkan pengukuran penggunaan GKE di cluster multi-tenant, data penggunaan resource akan ditulis ke tabel BigQuery. Anda dapat mengekspor metrik khusus tenant ke set data BigQuery di project tenant yang sesuai, lalu auditor 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 perlu menerapkan kuota resource. Buat kuota resource untuk setiap namespace berdasarkan jumlah Pod yang di-deploy oleh setiap tenant, serta jumlah memori dan CPU yang diperlukan oleh 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 beberapa cluster yang tersedia, Anda dapat meluncurkan aplikasi satu per satu ke cluster untuk tingkat validasi canary tambahan. Selain itu, memiliki beberapa cluster akan memudahkan masalah yang terkait dengan siklus proses upgrade dan pengelolaan 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 spesifik per aplikasi. Untuk metrik dan pemantauan, Anda dapat menggunakan Google Cloud Managed Service for Prometheus dan Grafana untuk setiap namespace. Untuk log, Anda perlu membuat sink guna mengekspor entri log ke set data BigQuery, lalu memfilter set data menurut namespace tenant. Selanjutnya, tenant 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 dibuat dan digunakan oleh beberapa tim sehingga penting untuk memiliki batas isolasi yang tepat di antara berbagai komponen platform. Batas isolasi membantu membangun platform yang andal dengan memberikan karakteristik berikut:
Memisahkan tanggung jawab. Setiap tim mengelola resource dalam batas isolasinya tanpa perlu khawatir dengan resource lainnya. Misalnya, tim infrastruktur hanya bertanggung jawab untuk mengelola cluster GKE. Operator atau developer hanya bertanggung jawab untuk mengelola 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 terpengaruh. Anda dapat membuat perubahan pada komponen secara independen tanpa memengaruhi komponen lain.
Mengurangi error manual. Karena kontrol akses bersifat terperinci, Anda dapat menghindari error manual seperti tidak sengaja men-deploy ke cluster produksi dari lingkungan pengembangan.
Batas isolasi ini dapat ada di antara aplikasi, infrastruktur, dan aplikasi yang berbeda, atau bahkan di antara lingkungan aplikasi yang berbeda.
Tata kelola
Tujuan utama 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).
Aktivasi dan pengelolaan aplikasi
Tujuan mengadopsi metodologi dan alat CI/CD modern adalah untuk menyederhanakan proses rilis dan aktivasi layanan baru. Aktivasi aplikasi baru harus menjadi proses yang mudah yang dapat Anda lakukan dengan input minimal 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 ditangani secara otomatis melalui proses penyediaan. Setelah diaktifkan, tim operasi dan keamanan secara alami disertakan dalam proses rilis melalui permintaan penggabungan, pembaruan kebijakan, dan penerapan praktik terbaik.
Sebaiknya buat beberapa otomatisasi untuk melakukan aktivasi aplikasi baru. Hal ini dapat mencakup pembuatan repositori kode, pipeline CI/CD, zona landing, dan infrastruktur apa pun yang diperlukan untuk aplikasi. Otomatisasi memisahkan dependensi kompleks tim pengembangan terhadap tim lain di organisasi dan memberikan otonomi kepada developer untuk melakukan layanan mandiri pada aplikasi. Hal ini memungkinkan developer mulai melakukan iterasi pada kode aplikasi dengan sangat cepat dan tidak membuang waktu untuk melakukan tugas selain menulis kode. Otomatisasi ini akan memungkinkan developer menjalankan aplikasi di lingkungan pengembangan. Untuk memindahkan aplikasi ke lingkungan yang lebih tinggi, tim lain harus terlibat dan proses peninjauan harus diikuti.
Dalam arsitektur referensi terkait, otomatisasi ini disebut Application Factory.
Platform sebagai produk
Alur kerja CI/CD adalah produk software, kecuali bahwa pengguna produk adalah tim pengembangan, operasi, dan keamanan. Dengan mempertimbangkan hal tersebut, platform ini memerlukan peran dan proses pengembangan software yang sama, seperti pemilik produk, pemasaran (meskipun bersifat internal), lingkaran masukan 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 lain saat bekerja, yang akan dibahas di bagian ini.
Memilih aplikasi uji coba
Memilih aplikasi pertama yang akan dipindahkan ke platform dapat menjadi langkah pertama yang sulit. Kandidat yang baik untuk uji coba adalah layanan yang memproses data atau menangani permintaan, tetapi tidak menyimpan data—misalnya lapisan penyimpanan dalam cache, frontend web, atau aplikasi pemrosesan berbasis peristiwa. Biasanya, aplikasi ini lebih tahan terhadap downtime dan error deployment dalam jumlah kecil yang dapat terjadi setiap kali Anda menggunakan teknik deployment dan pengelolaan konfigurasi 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 frekuensi yang lebih tinggi dan lebih asinkron. Tim pengembangan perlu menyadari bagaimana perubahan memengaruhi sistem downstream atau dependen dan bagaimana perubahan tersebut diuji. Jalur komunikasi antara tim pengembangan, operasi, dan keamanan harus lancar. Sebaiknya investasikan dalam praktik pembuatan versi yang lebih baik, baik untuk aplikasi maupun kontrak data yang digunakan berbagai layanan untuk berkomunikasi. Selain meningkatkan metode komunikasi dan pembuatan versi, menerapkan fitur dalam bagian kecil dan 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 membuat fitur yang ditampilkan secara eksternal, mereka membuat alat dan proses internal yang membantu memfasilitasi pengembangan, deployment, dan pengoperasian aplikasi yang ditampilkan secara eksternal. Alat platform digunakan oleh tim mereka sendiri serta tim pengembangan dan keamanan. Operator harus membuat alat untuk membantu meluncurkan versi baru aplikasi dan juga melakukan rollback jika terjadi error aplikasi atau kegagalan deployment. Operator juga harus lebih menekankan pada pembuatan sistem pemantauan dan pemberitahuan untuk mendeteksi kegagalan secara proaktif dan memberikan pemberitahuan yang sesuai.
Pertimbangan tim keamanan
Tim keamanan harus berupaya agar keamanan lebih menjadi tanggung jawab bersama antara mereka dan tim operasi serta pengembangan. Pola ini biasanya disebut shifting left pada keamanan, yang melibatkan keamanan informasi (InfoSec) sejak awal proses pengembangan, developer menggunakan alat yang telah disetujui sebelumnya, dan pengujian keamanan di otomatisasi. Selain teknik tersebut, Anda dapat menentukan dan menerapkan kebijakan keamanan secara terprogram dengan Policy Controller. Kombinasi teknik dan alat menempatkan penerapan keamanan dalam postur yang lebih proaktif.
Langkah selanjutnya
Pelajari lebih lanjut praktik terbaik untuk menyiapkan federasi identitas.
Membaca tentang pola pemantauan dan logging hybrid dan multi-cloud.