Dokumen ini menjelaskan framework untuk menerapkan proses continuous integration/continuous delivery (CI/CD) modern di platform pengiriman software multi-tim yang menggunakan Google Kubernetes Engine.
Kemudian, Anda dapat melakukan iterasi pada platform 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 IT security, DevOps, dan Site Reliability Engineering. Sebaiknya Anda telah berpengalaman menggunakan alat dan proses deployment otomatis 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 belum pernah terjadi sebelumnya dalam kecepatan pengembangan dan deployment. Namun, meskipun adopsi Kubernetes dan container meningkat, banyak organisasi tidak sepenuhnya menyadari manfaat dalam kecepatan rilis, stabilitas, dan efisiensi operasional karena praktik CI/CD mereka tidak memanfaatkan Kubernetes sepenuhnya 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 keunggulan Kubernetes dan container, Anda perlu menyederhanakan proses aktivasi aplikasi, praktik CI/CD, dan proses operasional.
Dengan menggunakan infrastruktur yang 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 penyediaan aplikasi dan kebijakan penyediaan di seluruh platform.
Sederhanakan aktivasi aplikasi dengan memberi tim project awal yang berfungsi penuh 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.
Menstandardisasi metodologi deployment dan pemantauan di seluruh organisasi untuk mengurangi waktu yang diperlukan untuk mengidentifikasi faktor-faktor penyebab masalah yang memengaruhi layanan.
Meningkatkan frekuensi deployment.
Pastikan developer aplikasi dapat melakukan iterasi secara independen di sandbox pengembangan (atau landing zone) mereka sendiri tanpa mengganggu satu sama lain.
Gunakan GitOps untuk deployment, pengelolaan rilis yang lebih baik, dan pelacakan perubahan.
Terapkan batas aman agar tim layanan dapat melakukan deployment secara sering.
Buat proses peluncuran progresif untuk men-deploy secara konsisten di seluruh lingkungan praproduksi, sehingga memberikan keyakinan yang dibutuhkan developer untuk men-deploy perubahan ke produksi.
Untuk melihat cara 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 harus menilai apakah organisasi dan tim Anda siap mengadopsi platform baru.
Ciri-ciri organisasi
Untuk mengadopsi platform modern, Anda 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. Sponsor kepemimpinan yang paling efektif adalah mereka yang melihat perubahan ini sebagai proses peningkatan berkelanjutan dan ingin memberdayakan tim mereka, bukan mengelola mereka.
Penyelarasan strategi teknis dan bisnis. Kami merekomendasikan agar tim bisnis dan tim teknis Anda menyelaraskan empat ukuran utama delivery software yang ditentukan oleh DevOps Research and Assessment (DORA): lama pengerjaan perubahan, frekuensi deployment, waktu untuk memulihkan layanan, dan tingkat kegagalan perubahan. Menyelaraskan tindakan tersebut akan memberikan sasaran yang sama bagi tim bisnis dan tim teknis Anda, sehingga mereka dapat bersama-sama menghitung laba atas investasi, menyesuaikan tingkat perubahan, dan mengubah tingkat investasi.
Referensi. Agar berhasil, tim yang mengembangkan praktik CI/CD modern dan membangun rantai alat memerlukan sumber daya yang diperlukan: waktu, orang, dan infrastruktur. Tim ini memerlukan waktu untuk mencoba dan memilih proses dan alat terbaik. Idealnya, tim ini mewakili banyak fungsi berbeda 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.
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 dan bersedia mengadopsinya. Loop masukan 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 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 siap secara teknis dengan cara berikut:
Pengalaman dengan container. Tim yang menerapkan pendekatan CI/CD modern memerlukan pengalaman dengan container. Idealnya, pengalaman ini mencakup teknik pengembangan untuk mem-build image container dan menggabungkan container untuk membangun sistem yang lebih besar.
Strategi continuous integration. Tim memerlukan pengalaman menggunakan alat CI (seperti Jenkins, TeamCity, Bamboo, dan CircleCI) dan melakukan beberapa continuous integration dan pengujian otomatis. Sebaiknya organisasi merencanakan cara untuk lebih meningkatkan proses tersebut.
Otomatisasi deployment. Tim memerlukan pengalaman dalam otomatisasi deployment. Contoh alat deployment otomatis mencakup 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 adopsi proses CI/CD modern, adopsi arsitektur modular dan berorientasi layanan harus menjadi tujuan 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 batang utama, 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 starter menyederhanakan aktivasi dan penerapan praktik terbaik. Pertimbangan desain berikut 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 membangun platform dan menjalankan aplikasi Anda.
Alur kerja pengiriman software. Cara tim bekerja sama untuk membangun, 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 membangun infrastruktur. Hal ini juga dapat berupa repositori awal yang memfasilitasi penerapan praktik terbaik dan membantu menjaga konsistensi di seluruh proses otomatis.
Zona landing aplikasi. Entitas logika yang memungkinkan developer men-deploy dan melakukan iterasi pada aplikasi mereka secara mandiri menggunakan batas aman yang Anda siapkan.
Model operasi. Alat, proses, dan metode teknis untuk mengelola infrastruktur dan aplikasi yang membentuk platform.
Tata kelola. 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 membangun, mengirimkan, men-deploy, dan mengoperasikan aplikasi.
Tanggung jawab untuk mempertahankan konfigurasi, stabilitas, waktu aktif, dan skala aplikasi bervariasi 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 kemampuan observasi aplikasi, dokumen ini terutama berfokus pada continuous integration (CI), continuous delivery (CD), dan pengelolaan konfigurasi.
Untuk membangun platform pengiriman software yang lengkap, Anda memerlukan setiap komponen dalam diagram berikut:
Setiap komponen ini menyediakan fungsionalitas untuk sistem dan aplikasi yang berjalan di platform:
Pemantauan infrastruktur. Tingkat dasar pemantauan yang diperlukan saat melakukan penyediaan untuk memverifikasi fungsi yang benar dari cluster Google Kubernetes Engine (GKE), instance virtual machine (VM), dan infrastruktur lain yang diperlukan agar aplikasi 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 pembangunan, pengemasan, dan pengujian. Jenis tugas bervariasi berdasarkan aplikasi dan organisasi.
CD. Proses deployment yang sangat terotomatisasi 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 diterapkan dan diberlakukan secara berkelanjutan oleh platform.
Pengelolaan kode sumber. Misalnya, penyimpanan yang dikontrol versinya untuk kode, file konfigurasi, dan definisi kebijakan. Dalam sistem CI/CD modern, pengelolaan kode sumber biasanya menggunakan Git.
Pengelolaan konfigurasi. Sistem yang digunakan untuk menyimpan dan menerapkan konfigurasi aplikasi untuk lingkungan yang berbeda.
Kemampuan observasi aplikasi. Pencatatan aktivitas, pemantauan, pemberitahuan, dan pelacakan tingkat aplikasi yang digunakan oleh tim developer, operator, dan keamanan untuk memecahkan masalah dan memverifikasi pengoperasian aplikasi yang tepat.
Infrastruktur platform
Untuk membangun 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 didistribusikan secara geografis. Dengan begitu, keandalan dari kegagalan infrastruktur akan meningkat dan kekhawatiran terkait operasi Hari ke-2, seperti upgrade dan penskalaan cluster, akan berkurang.
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 armada cluster Anda. Setelah konfigurasi cluster Anda distandardisasi, dapat diaudit, dan dapat diskalakan, 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 dengan menggunakan repositori starter dan alat otomatis. Misalnya, Anda dapat menggunakan Cloud Build untuk menjalankan Terraform guna mengaktifkan dan menginisialisasi aplikasi baru secara otomatis.
Anda men-deploy aplikasi ke zona landing-nya sendiri di setiap cluster, sehingga aplikasi diisolasi berdasarkan jaringan dan identitas. Anda melakukan inisialisasi zona landing aplikasi di seluruh lingkungan menggunakan Config Sync, dan Anda 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 platform pengiriman software adalah sistem CI/CD. Saat developer platform mulai menentukan proses CI/CD, mereka harus memastikan bahwa setiap komponen menghasilkan atau menggunakan artefak yang mematuhi antarmuka standar. Penggunaan antarmuka standar menyederhanakan penggantian komponen saat penerapan yang lebih baik tersedia di pasar.
Saat membuat platform untuk aplikasi yang di-container, Anda dapat menggunakan tiga antarmuka standar antar-komponen: repositori Git, image Docker, dan manifest 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 dalam diagram berikut:
Alur kerja ini berfungsi sebagai berikut:
Developer melakukan 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 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 diterapkan di seluruh organisasi. Saat operator melakukan perubahan pada repositori, update konfigurasi aplikasi (dan deployment berikutnya) dapat dipicu secara otomatis. Atau, perubahan operator dapat diambil saat developer men-deploy perubahan mereka berikutnya.
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 memelihara log perubahan, membatalkan 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 yang disebut sebagai dasar konfigurasi aplikasi yang
dapat disesuaikan oleh tim pengembangan Anda tanpa perlu menambahkan atau mengubah kode apa pun di
dasar. 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 melakukan perubahan di dasar, dan perubahan tersebut
akan otomatis ditarik dengan deployment berikutnya oleh developer.
Repositori kode
Repositori kode sumber adalah inti dari sistem CI/CD. Operator, developer, dan engineer keamanan masing-masing memiliki repositori sendiri untuk menyebarkan perubahan ke dalam 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 pengembalian Git memungkinkan Anda mengembalikan 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 guna membantu tim Anda mengaktifkan aplikasi sekaligus menerapkan 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. Di repositori ini, operator menyediakan library tugas yang telah ditentukan sebelumnya yang dapat digunakan developer untuk membangun pipeline mereka. Repositori aplikasi developer secara otomatis mewarisi tugas-tugas ini dan logikanya; tugas-tugas tersebut tidak perlu disalin secara manual. Contoh tugas yang dapat Anda standarisasi di seluruh organisasi meliputi:
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 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 memiliki jalur yang disederhanakan 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 secara terstruktur, developer dapat menggunakan praktik terbaik tersebut. Untuk melakukannya, developer mereferensikan tugas untuk CI/CD dan dasar 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 mencakup hal berikut:
Kode sumber aplikasi
Dockerfile
yang menjelaskan cara membangun dan menjalankan aplikasiDefinisi pipeline CI/CD
Ekstensi atau modifikasi pada dasar konfigurasi aplikasi yang dibuat oleh operator
Repositori infrastruktur sebagai kode
Repositori infrastruktur sebagai kode menyimpan kode untuk membangun infrastruktur yang diperlukan untuk menjalankan aplikasi. Infrastruktur dapat mencakup platform orkestrasi container dan jaringan seperti GKE. Biasanya, admin infrastruktur memiliki repositori ini. Operator dapat memperbaruinya untuk menerapkan praktik terbaik.
Contoh artefak yang dapat Anda simpan di repositori aplikasi mencakup hal berikut:
- Kode bahasa deklaratif (Terraform, Pulumi) yang merepresentasikan 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 menyebarkan perubahan konfigurasi ke seluruh sistem. Beberapa item konfigurasi umum yang dapat Anda kelola secara terpusat mencakup 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 menyalahartikan infrastruktur. Menggunakan repositori Git untuk menyimpan konfigurasi dapat meningkatkan proses seperti audit 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 starter membantu penerapan praktik terbaik CI/CD, infrastruktur, dan pengembangan di seluruh platform. Repositori starter dapat mengurangi biaya yang terkait dengan penerapan praktik terbaik secara signifikan. Praktik terbaik ini, pada gilirannya, membantu meningkatkan kecepatan fitur, keandalan, dan produktivitas tim. Dalam arsitektur referensi terkait, terdapat beberapa repositori awal untuk konfigurasi CI, CD, Kubernetes, aplikasi dan infrastruktur awal Go, Java, dan Python.
Continuous integration
Organisasi biasanya memiliki serangkaian tugas standar yang diterapkan ke aplikasi selama CI. Misalnya, dalam implementasi referensi, kumpulan dasar tahap CI adalah sebagai berikut: kompilasi kode, dan bangun image container. Karena tahap tersebut ditentukan di repositori starter, tahap tersebut diterapkan secara seragam di seluruh platform. Setiap tim aplikasi dapat menambahkan langkah-langkah tambahan.
Continuous delivery
Mirip 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 starter memungkinkan tim platform menerapkan metodologi tersebut secara seragam di seluruh aplikasi dan lingkungan. Dalam penerapan referensi, proses deployment mencakup peluncuran untuk dev, deployment 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 starter untuk konfigurasi Kubernetes, platform dapat memberikan dasar yang konsisten untuk konfigurasi aplikasi. Misalnya, dalam
implementasi referensi, konfigurasi dasar kustomize
menginisialisasi repositori lingkungan aplikasi dengan serangkaian konfigurasi dasar yang diketahui baik. Setiap tim aplikasi kemudian dapat menyesuaikan konfigurasi sesuai kebutuhan mereka.
Aplikasi awal
Aplikasi starter dapat membantu Anda mengurangi overhead yang terkait dengan penerapan praktik terbaik—misalnya, praktik terbaik observasi dan container.
Kemampuan observasi. Untuk mengoperasikan aplikasi secara efisien dan membantu memastikan keandalan, aplikasi perlu memperhitungkan logging, metrik, dan pelacakan. Aplikasi starter membantu tim membangun dalam framework dan strategi yang meningkatkan kemampuan observasi.
Praktik terbaik container. Saat membangun aplikasi yang di-containerkan, Anda harus membangun image container yang kecil dan bersih. Praktik terbaik untuk container mencakup mengemas satu aplikasi dalam image, menghapus alat yang tidak diperlukan dari image, dan secara aktif mencoba menghasilkan image 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 starter yang disesuaikan untuk bahasa, stack teknologi, dan jenis aplikasi yang dikembangkan tim Anda.
Repositori starter infrastruktur
Repositori starter infrastruktur dilengkapi dengan kode yang telah ditulis sebelumnya yang diperlukan untuk membuat berbagai komponen infrastruktur. Repositori ini menggunakan template dan modul standar sebagaimana diputuskan oleh tim infrastruktur.
Misalnya, dalam penerapan 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 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 dalam organisasi. Misalnya, modul infrastructure as code 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 pendaratan aplikasi.
Landing zone adalah entity logika yang dikunci dan memungkinkan developer men-deploy dan melakukan iterasi pada aplikasi mereka. Zona landing aplikasi menggunakan batas aman yang Anda terapkan sehingga developer dapat beroperasi secara mandiri. Untuk setiap aplikasi, Anda membuat namespace Kubernetes di setiap cluster dari setiap lingkungan (misalnya, untuk produksi, pengembangan, atau penyiapan). Konsistensi ini membantu operator men-debug dan memelihara lingkungan dari waktu ke waktu.
Diagram berikut menggambarkan konsep zona landing:
Model operasi
Saat mengoperasikan platform pengiriman software dengan CI/CD modern, penting untuk menjaga konsistensi dan memperbarui lingkungan, infrastruktur, dan proses. Oleh karena itu, Anda perlu merencanakan dan memilih model operasi untuk platform dengan cermat. Anda dapat memilih dari berbagai model, seperti cluster sebagai layanan, cetak biru, atau infrastruktur multi-tenant.
Karena penting untuk mempertahankan infrastruktur yang konsisten, membatasi penyebaran, dan memungkinkan tim berfokus pada penyampaian aplikasi, sebaiknya Anda men-deploy infrastruktur multi-tenant. Men-deploy aplikasi di infrastruktur multi-tenant menghilangkan kebutuhan tim aplikasi untuk mengelola infrastruktur dan memungkinkan tim operator dan keamanan berfokus untuk menjaga konsistensi infrastruktur.
Pertimbangan untuk infrastruktur multi-tenant
Saat Anda membangun platform pengiriman software multi-tenant, ada beberapa hal yang dapat Anda pertimbangkan untuk dibangun ke dalam platform:
Isolasi workload. 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 secara terpusat dan diterapkan 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 beban kerja cluster, yang dapat Anda filter lebih lanjut berdasarkan namespace dan label. Saat Anda mengaktifkan pengukuran penggunaan GKE di cluster multi-tenant, catatan penggunaan resource 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 membagikan 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 men-deploy aplikasi satu per satu ke cluster untuk tingkat validasi canary tambahan. Selain itu, memiliki beberapa cluster mengurangi kekhawatiran yang terkait 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 khusus 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 untuk mengekspor entri log ke set data BigQuery, lalu memfilter set data menurut namespace tenant. Kemudian, penyewa 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 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 mengkhawatirkan resource lainnya. 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 berdasarkan batas isolasi, gunakan kontrol akses terperinci untuk membatasi akses.
Mengurangi area yang terpengaruh. Anda dapat membuat perubahan pada komponen secara independen tanpa memengaruhi komponen lainnya.
Mengurangi kesalahan 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 yang berbeda, infrastruktur dan aplikasi, atau bahkan di antara lingkungan aplikasi yang berbeda.
Tata kelola
Tujuan utama platform pengiriman software dan sistem CI/CD modern adalah untuk meningkatkan efisiensi keseluruhan proses pengiriman software. Dalam hal pengelolaan platform, Anda memiliki dua pertimbangan utama: aktivasi aplikasi, yang umumnya termasuk dalam kategori tata kelola; dan pengembangan serta pemeliharaan platform yang berkelanjutan (yaitu, memperlakukan platform seperti produk).
Pengelolaan dan orientasi aplikasi
Tujuan mengadopsi alat dan metodologi CI/CD modern adalah untuk menyederhanakan proses rilis dan orientasi layanan baru. Mengaktifkan aplikasi baru harus menjadi proses yang mudah yang dapat Anda lakukan dengan input minimal dari tim operasi dan keamanan. Hal ini tidak berarti 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 otomatis disertakan dalam proses rilis melalui permintaan penggabungan, update kebijakan, dan penerapan praktik terbaik.
Sebaiknya buat beberapa otomatisasi untuk mengaktifkan aplikasi baru. Hal ini dapat mencakup pembuatan repositori kode, pipeline CI/CD, landing zone, dan infrastruktur apa pun yang diperlukan untuk aplikasi. Otomatisasi memisahkan dependensi kompleks tim pengembangan pada tim lain dalam 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 dalam melakukan tugas selain menulis kode. Otomatisasi ini akan 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 Application Factory.
Platform sebagai produk
Alur kerja CI/CD adalah produk software, kecuali pengguna produk tersebut adalah tim pengembangan, operasi, dan keamanan. Dengan demikian, platform ini memerlukan peran dan proses pengembangan software yang sama, seperti pemilik produk, pemasaran (meskipun berfokus pada internal), siklus 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 mereka bekerja, yang dibahas di bagian ini.
Memilih aplikasi uji coba
Memilih aplikasi pertama yang akan dipindahkan ke platform bisa 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 sedikit gangguan dan error deployment yang dapat terjadi kapan saja saat Anda menggunakan teknik pengelolaan konfigurasi dan deployment 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 dampak perubahan pada sistem hilir atau sistem dependen dan cara perubahan tersebut diuji. Jalur komunikasi antara tim pengembangan, operasi, dan keamanan harus lancar. Sebaiknya lakukan praktik pembuatan versi yang lebih baik untuk aplikasi dan kontrak data yang digunakan oleh berbagai layanan untuk berkomunikasi. Selain meningkatkan metode komunikasi dan pembuatan versi, penerapan fitur dalam potongan kecil dan penggunaan cabang dan tombol fitur dapat meningkatkan cara Anda menguji dan merilis fitur.
Pertimbangan operator
Dengan platform pengiriman software, tim operasi perlu berfungsi lebih seperti tim pengembangan. Daripada membangun fitur yang menghadap eksternal, mereka membangun alat dan proses internal yang membantu memfasilitasi pengembangan, deployment, dan pengoperasian aplikasi yang menghadap 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 pembangunan sistem pemantauan dan pemberitahuan untuk mendeteksi kegagalan secara proaktif dan memberikan pemberitahuan yang sesuai.
Pertimbangan tim keamanan
Tim keamanan harus berupaya menjadikan keamanan sebagai tanggung jawab bersama antara mereka dan tim operasi serta pengembangan. Pola ini biasanya disebut menggeser ke kiri dalam keamanan, yang mana keamanan informasi (InfoSec) terlibat sejak awal dalam proses pengembangan, developer bekerja dengan alat yang telah disetujui sebelumnya, dan pengujian keamanan diotomatiskan. Selain teknik tersebut, Anda dapat secara terprogram menentukan dan menerapkan kebijakan keamanan dengan Policy Controller. Kombinasi teknik dan alat ini membuat penegakan keamanan menjadi lebih proaktif.
Langkah berikutnya
Pelajari lebih lanjut praktik terbaik untuk menyiapkan federasi identitas.
Baca Kubernetes dan tantangan pengiriman software berkelanjutan.
Membaca tentang pola pemantauan dan logging hybrid dan multi-cloud.