Arsitektur layanan Cloud Deploy

Dokumen ini menjelaskan hubungan antara Cloud Deploy dan sistem eksternal yang digunakannya untuk men-deploy aplikasi Anda. Sistem ini adalah layanan Google Cloud lainnya dan alat pihak ketiga.

Tampilan tingkat tinggi

Diagram berikut menunjukkan hubungan antara Cloud Deploy dan sistem terpisah yang menjadi andalannya.

Hubungan antar-komponen Cloud Deploy

Seperti yang ditunjukkan pada diagram ini, Cloud Deploy berinteraksi dengan sistem berikut:

  • Sistem CI Anda

    Cloud Deploy mendukung sebagian besar alat CI, selama satu output dari proses CI Anda dapat berupa panggilan ke API atau CLI Cloud Deploy untuk membuat rilis.

  • Cloud Build

    Cloud Deploy memanggil Cloud Build untuk merender manifes dan men-deploy ke runtime target.

  • Skaffold

    Cloud Deploy menggunakan Skaffold melalui Cloud Build untuk merender dan men-deploy manifes, sehingga men-deploy aplikasi Anda.

  • Cloud Storage

    Cloud Deploy menyimpan sumber rendering dan manifes yang dirender di bucket Cloud Storage.

  • Google Cloud Observability dan Cloud Audit Logs.

    Google Cloud Observability mengumpulkan dan menyediakan data logging untuk Cloud Deploy.

    Lihat juga Logging audit.

  • Pub/Sub

    Cloud Deploy memublikasikan pesan ke beberapa topik Pub/Sub. Anda dapat menggunakan layanan ini untuk berintegrasi dengan alur kerja, pengujian, dan sistem terkait lainnya yang bersifat eksternal.

    Lihat Berlangganan notifikasi Cloud Deploy untuk mengetahui informasi selengkapnya.

  • Runtime target

    Cloud Deploy menggunakan skaffold apply, melalui Cloud Build, untuk men-deploy aplikasi ke runtime target (GKE atau GKE Enterprise).

Resource Cloud Deploy

Diagram berikut menunjukkan resource yang digunakan Cloud Deploy untuk men-deploy aplikasi Anda, dan hubungan di antara resource tersebut:

Hubungan antar-resource Cloud Deploy

Seperti yang ditunjukkan dalam diagram ini, hubungan antar-resource adalah sebagai berikut:

  • Pipeline pengiriman dapat menghasilkan nol rilis atau lebih dan dapat mereferensikan satu atau beberapa target, termasuk multi-target dan target turunan terkait.

  • Pipeline pengiriman juga dapat mereferensikan satu atau beberapa otomatisasi, yang mengotomatiskan tindakan pada resource Cloud Deploy.

  • Setiap rilis menyertakan instance pipeline—"snapshot" dari pipeline dan target pengiriman seperti yang dikonfigurasi saat rilis dibuat.

  • Setiap rilis dapat menghasilkan nol atau beberapa peluncuran, dan dapat mereferensikan nol atau beberapa artefak.

    Setiap peluncuran mencakup minimal satu fase, yang mewakili kumpulan operasi (tugas) dalam peluncuran yang secara logis dikelompokkan bersama, misalnya, deployment atau deployment dan verifikasi.

    Setiap fase mencakup satu atau beberapa tugas, yang mewakili hal yang harus dilakukan pada peluncuran—baik deployment maupun verifikasi. Setiap tugas dapat mencakup satu atau beberapa eksekusi tugas, yang merupakan instance tugas, misalnya, upaya untuk men-deploy. Eksekusi tugas adalah resource turunan dari peluncuran.

    Multi-target, yang digunakan untuk deployment paralel, membuat peluncuran pengontrol, yang membuat peluncuran turunan, yang sesuai dengan target turunan.

  • Setiap peluncuran dikaitkan dengan satu target.

    Untuk pen-deployment paralel , setiap target turunan dikaitkan dengan satu peluncuran turunan.

  • Setiap target dikaitkan dengan satu cluster GKE atau Anthos, atau tujuan runtime lain untuk aplikasi.

  • Target dapat dikaitkan dengan satu atau beberapa pipeline pengiriman.

  • Artefak adalah output dari proses CI Anda (misalnya, image container) yang di-deploy ke runtime target sebagai bagian dari peluncuran.

Selain itu, peluncuran memiliki satu atau beberapa fase, dan fase memiliki satu atau beberapa tugas dan satu atau beberapa tugas berjalan.

Resource peluncuran

Seperti yang ditunjukkan dalam diagram ini, peluncuran mencakup hal berikut:

  • Fase

    Fase berisi satu atau beberapa tugas (misalnya, deploy, atau deploy dan verifikasi). Setiap peluncuran memiliki satu atau beberapa fase. Fase adalah sub-pesan dalam peluncuran.

  • Pekerjaan

    Operasi spesifik yang akan dilakukan pada peluncuran, misalnya men-deploy atau memverifikasi. Tugas adalah sub-pesan dalam peluncuran.

  • JobRuns

    Instance tugas, misalnya upaya untuk memverifikasi. Setiap tugas dapat memiliki nol atau beberapa JobRun. JobRun adalah resource turunan dari peluncuran.

Otomatisasi berisi aturan otomatisasi, yang dapat direferensikan oleh nol atau beberapa resource AutomationRun. AutomationRuns adalah instance aturan otomatisasi yang dijalankan, misalnya promosi otomatis dari satu target ke target lainnya. Resource Automation dan AutomationRun adalah resource peer-child di bawah pipeline pengiriman.

Referensi otomatisasi

Cara alat tersebut bekerja sama untuk mengirimkan rilis Anda

Bagian ini menjelaskan cara Cloud Deploy berinteraksi dengan komponen yang tercantum dalam dokumen ini untuk mengotomatiskan pengiriman aplikasi Anda sebagai rilis.

  1. Sistem CI Anda memanggil pipeline pengiriman Cloud Deploy.

    Proses CI Anda memanggil Cloud Deploy menggunakan CLI atau API untuk membuat rilis baru, yang meneruskan artefak atau referensi build ke image.

    Untuk informasi selengkapnya tentang cara mengintegrasikan sistem CI, lihat Mengintegrasikan Cloud Deploy dengan sistem lain.

  2. Saat rilis baru dibuat, Cloud Deploy akan melakukan hal berikut:

    1. Menyimpan instance pipeline pengiriman sebagai bagian dari rilis.

      Instance pipeline ini tetap tidak berubah untuk rilis ini, meskipun konfigurasi pipeline pengiriman diubah. Lihat Instance pipeline per rilis untuk mengetahui informasi selengkapnya.

      Selain itu, versi Skaffold disimpan sebagai bagian dari rilis. Biasanya, ini akan menjadi versi Skaffold default, tetapi karena Anda dapat menentukan versi lain, informasi tersebut akan disimpan.

    2. Memanggil Cloud Build, yang mendapatkan sumber rendering Skaffold dari Cloud Storage.

      Cloud Deploy menyimpan sumber rendering di bucket Cloud Storage default atau alternatif.

    3. Memanggil skaffold diagnose (menggunakan versi Skaffold yang disimpan saat pembuatan rilis) untuk membuat satu manifes yang efektif.

    4. Memanggil operasi render.

      Jika Anda menggunakan target bawaan, Cloud Deploy akan memanggil skaffold render untuk merender manifes menggunakan image atau artefak build yang disediakan. Cloud Deploy mengganti nama image di spec.templates.spec.containers.image dengan jalur image lengkap (termasuk ringkasan atau tag) yang disediakan pada perintah gcloud deploy releases create atau dalam file artefak build yang direferensikan oleh perintah tersebut.

      Jika Anda menggunakan target kustom, Cloud Deploy akan memanggil operasi render yang ditentukan untuk jenis target kustomnya.

      Cloud Deploy menyimpan manifes yang dirender di bucket Cloud Storage default atau alternatif.

      Cloud Deploy melakukan tindakan ini menggunakan lingkungan eksekusi default atau alternatif.

  3. Saat peluncuran dibuat (secara otomatis setelah pembuatan rilis atau on demand nanti), Cloud Deploy akan melakukan hal berikut:

    1. Memanggil hook pra-penyebaran, jika ada yang ditentukan.

      Jika Anda menggunakan strategi deployment canary, hook pra-deploy akan dipanggil di awal fase pertama.

    2. Memanggil operasi deploy.

      Jika Anda menggunakan target bawaan, Cloud Deploy akan otomatis membuat dan men-deploy peluncuran ke target pertama, dengan memanggil skaffold apply. Jika Anda menggunakan target bawaan, peluncuran pertama akan dibuat secara otomatis setelah pembuatan rilis.

      Jika Anda menggunakan target kustom, Cloud Deploy akan otomatis membuat peluncuran ke target pertama, dengan memanggil operasi deploy yang ditentukan untuk jenis target kustomnya.

      Untuk target bawaan dan target kustom, peluncuran ke target pertama, hanya otomatis jika rilis dibuat menggunakan command line.

      Proses deployment ke target pertama sama dengan promosi, seperti yang dijelaskan pada langkah berikutnya.

    3. Memanggil skaffold verify, jika verify adalah true untuk target dalam konfigurasi pipeline pengiriman dan jika verifikasi ditentukan dalam konfigurasi Skaffold.

    4. Memanggil hook pasca-penyebaran, jika ada yang ditentukan, setelah verify, jika verify ditentukan. Jika tidak, hook pasca-penyebaran akan dipanggil setelah deploy.

      Jika Anda menggunakan strategi deployment canary, hook pasca-deployment dilakukan sebagai tugas terakhir dalam fase peluncuran akhir.

  4. Saat tiba waktunya untuk mempromosikan rilis ke target berikutnya, Cloud Build akan mengambil manifes khusus target dari Cloud Storage. Kemudian, Cloud Build memanggil skaffold apply untuk menerapkan manifes yang dirender ke runtime target yang ditentukan.

    Jika target memerlukan persetujuan, Anda dapat menyetujui atau menolaknya melalui CLI atau menggunakan Konsol.

    Selain itu, Cloud Deploy menghasilkan pesan Pub/Sub, yang dapat Anda langgani untuk memulai alur kerja persetujuan secara otomatis.

    Cloud Deploy menggunakan versi Skaffold dan instance pipeline yang terkait dengan rilis ini, dan melakukan langkah ini di lingkungan eksekusi default atau kustom.

    Proses ini tidak hanya berlaku untuk promosi, tetapi juga untuk rollback dan deployment ulang.

  5. Selama operasi Cloud Deploy, layanan memublikasikan notifikasi ke beberapa topik Pub/Sub (misalnya, saat peluncuran memerlukan persetujuan).

    Integrasi ini dan integrasi lainnya dijelaskan lebih lanjut di Mengintegrasikan Cloud Deploy dengan sistem eksternal.

  6. Anda dapat menentukan otomatisasi untuk secara otomatis melakukan berbagai operasi dalam pipeline pengiriman. Perintah ini dapat dijalankan pada waktu yang ditentukan. automationRun mewakili eksekusi aturan otomatisasi.

  7. Selama operasi Cloud Deploy, layanan ini menulis log platform dan log audit ke Google Cloud Observability dan Cloud Audit Logs.

Melalui semua langkah ini, kontrol alur dan akses ke resource dibatasi menggunakan Identity and Access Management.

Langkah selanjutnya