Arsitektur layanan Cloud Deploy

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

{i>High-level view<i}

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

Hubungan antarkomponen Cloud Deploy

Seperti yang ditunjukkan dalam 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.

  • Kemampuan Observasi Google Cloud dan Cloud Audit Logs.

    Kemampuan Observabilitas Google Cloud 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 eksternal, pengujian, dan sistem terkait lainnya.

    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 Anda (GKE atau GKE Enterprise).

Resource Cloud Deploy

Diagram berikut menunjukkan resource yang digunakan Cloud Deploy untuk menghadirkan aplikasi Anda, dan hubungan antara resource tersebut:

Hubungan antara resource Cloud Deploy

Seperti yang ditunjukkan dalam diagram ini, hubungan di antara resource adalah sebagai berikut:

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

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

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

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

    Setiap peluncuran mencakup setidaknya satu fase, yang mewakili kumpulan operasi (tugas) dalam peluncuran yang dikelompokkan secara logis, misalnya, deploy atau deploy dan memverifikasi.

    Setiap fase mencakup satu atau beberapa tugas, yang menunjukkan apa yang akan dilakukan selama peluncuran, baik men-deploy maupun memverifikasi. Setiap tugas dapat menyertakan satu atau beberapa tugas berjalan, yang merupakan instance tugas, misalnya, upaya untuk men-deploy. 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 deployment paralel , setiap target turunan dikaitkan dengan satu peluncuran turunan.

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

  • Satu target dapat dikaitkan dengan satu atau beberapa pipeline pengiriman.

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

Selanjutnya, peluncuran memiliki satu atau beberapa fase, dan fase memiliki satu atau beberapa tugas serta satu atau beberapa tugas berjalan.

Meluncurkan resource

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

  • Fase

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

  • Pekerjaan

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

  • JobRuns

    Instance tugas, misalnya upaya verifikasi. Setiap tugas bisa memiliki nol atau beberapa JobRun. JobRun adalah resource turunan dari peluncuran.

Otomatisasi berisi aturan otomatisasi yang dapat dirujuk 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 turunan-turunan di bawah pipeline pengiriman.

Referensi otomatisasi

Bagaimana keduanya saling melengkapi 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, dengan meneruskan artefak build atau referensi ke image.

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

  2. Saat rilis baru dibuat, Cloud Deploy 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. Umumnya, 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 menghasilkan satu manifes yang efektif.

    4. Memanggil operasi render.

      Jika Anda menggunakan target bawaan, Cloud Deploy 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 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 sesuai permintaan nanti), Cloud Deploy melakukan hal berikut:

    1. Memanggil hook pra-deploy, jika ada.

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

    2. Memanggil operasi deploy.

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

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

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

      Proses deployment ke target pertama sama seperti untuk 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-deployment, jika ada, setelah verify, jika verify ditentukan. Jika tidak, hook pasca-deployment akan dipanggil setelah deploy.

      Jika Anda menggunakan strategi deployment canary, hook pasca-deployment akan dijalankan sebagai tugas terakhir pada fase peluncuran akhir.

  4. Jika 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 Console.

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

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

    Proses ini berlaku tidak hanya 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 dalam Mengintegrasikan Cloud Deploy dengan sistem eksternal.

  6. Anda dapat menentukan otomatisasi untuk otomatis melakukan berbagai operations dalam pipeline pengiriman. Pengujian 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 Kemampuan Observasi Google Cloud dan Cloud Audit Logs.

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

Langkah selanjutnya