Praktik terbaik untuk Workflows

Workflows memungkinkan Anda mengoordinasikan dan mengotomatiskan layanan di seluruhGoogle Cloud. Menerapkan praktik arsitektur yang direkomendasikan akan membantu Anda meningkatkan keandalan, mengoptimalkan biaya eksekusi, serta membangun orkestrasi yang tangguh dan mudah dikelola.

Daftar rekomendasi ini tidak lengkap dan tidak mengajarkan dasar-dasar cara menggunakan Workflows. Dokumen ini mengasumsikan bahwa Anda sudah memiliki pemahaman umum tentang lanskap Google Cloud secara keseluruhan dan Workflows. Untuk mengetahui informasi selengkapnya, lihat Google Cloud Well-Architected Framework dan Ringkasan Workflows.

Memilih pola komunikasi yang optimal

Saat mendesain arsitektur microservice untuk men-deploy beberapa layanan, Anda dapat memilih dari pola komunikasi berikut:

  • Komunikasi langsung antar-layanan

  • Komunikasi tidak langsung berbasis peristiwa (juga dikenal sebagai koreografi)

  • Konfigurasi, koordinasi, dan pengelolaan otomatis (juga dikenal sebagai orkestrasi)

Pastikan untuk mempertimbangkan manfaat dan kelemahan dari setiap opsi sebelumnya dan pilih pola yang optimal untuk kasus penggunaan Anda. Misalnya, komunikasi langsung antar-layanan mungkin lebih mudah diterapkan daripada opsi lain, tetapi komunikasi ini menggabungkan layanan Anda secara erat. Sebaliknya, arsitektur berbasis peristiwa memungkinkan Anda menggabungkan layanan secara longgar; namun, pemantauan dan proses debug mungkin lebih rumit. Terakhir, orchestrator pusat seperti Workflows, meskipun kurang fleksibel, memungkinkan Anda mengoordinasikan komunikasi antar-layanan tanpa pengaitan erat dari komunikasi langsung layanan ke layanan, atau kerumitan peristiwa yang dikoreografikan.

Anda juga dapat menggabungkan pola komunikasi. Misalnya, dalam orkestrasi berbasis peristiwa, layanan yang terkait erat dikelola dalam orkestrasi yang dipicu oleh peristiwa. Demikian pula, Anda dapat mendesain sistem yang menghasilkan satu orkestrasi pesan Pub/Sub ke sistem orkestrasi lainnya.

Tips umum

Setelah Anda memutuskan untuk menggunakan Workflows sebagai orchestrator layanan, perhatikan tips bermanfaat berikut.

Menghindari URL hardcode

Anda dapat mendukung alur kerja yang portabel di beberapa lingkungan dan lebih mudah dikelola dengan menghindari URL hardcode. Anda dapat melakukannya dengan cara berikut:

  • Tentukan URL sebagai argumen runtime.

    Hal ini dapat membantu saat alur kerja Anda dipanggil melalui library klien atau API. (Namun, hal ini tidak akan berfungsi jika alur kerja Anda dipicu oleh peristiwa dari Eventarc dan satu-satunya argumen yang dapat diteruskan adalah payload peristiwa.)

    Contoh

    main:
  params: [args]
  steps:
    - init:
        assign:
          - url1: ${args.urls.url1}
          - url2: ${args.urls.url2}

    Saat menjalankan alur kerja, Anda dapat menentukan URL. Contoh:

    gcloud workflows run multi-env --data='{"urls":{"url1": "URL_ONE", "url2": "URL_TWO"}}'

  • Gunakan variabel lingkungan dan buat alur kerja yang dikonfigurasi secara dinamis bergantung pada lingkungan tempat alur kerja tersebut di-deploy. Atau, buat alur kerja yang dapat digunakan kembali sebagai template dan dikonfigurasi sesuai dengan variabel lingkungan yang dikelola secara terpisah.

  • Gunakan teknik substitusi yang memungkinkan Anda membuat satu file definisi alur kerja, tetapi men-deploy varian menggunakan alat yang menggantikan placeholder dalam alur kerja Anda. Misalnya, Anda dapat menggunakan Cloud Build untuk men-deploy alur kerja dan di file konfigurasi Cloud Build, tambahkan langkah untuk mengganti URL placeholder dalam alur kerja.

    Contoh

    steps:
‐ id: 'replace-urls'
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: bash
  args:
    - -c
    - |
      sed -i -e "s~REPLACE_url1~$_URL1~" workflow.yaml
      sed -i -e "s~REPLACE_url2~$_URL2~" workflow.yaml
‐ id: 'deploy-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  args: ['workflows', 'deploy', 'multi-env-$_ENV', '--source', 'workflow.yaml']

    Kemudian, Anda dapat mengganti nilai variabel pada waktu build. Contoh:

    gcloud builds submit --config cloudbuild.yaml \
    --substitutions=_ENV=staging,_URL1="URL_ONE",_URL2="URL_TWO"

    Untuk mengetahui informasi selengkapnya, lihat Mengirim build melalui CLI dan API.

    Atau, Anda dapat menggunakan Terraform untuk menyediakan infrastruktur dan menentukan file konfigurasi yang membuat alur kerja untuk setiap lingkungan menggunakan variabel input.

    Contoh

    variable "project_id" {
  type = string
}

variable "url1" {
  type = string
}

variable "url2" {
  type = string
}

locals {
  env = ["staging", "prod"]
}

# Define and deploy staging and production workflows
resource "google_workflows_workflow" "multi-env-workflows" {
  for_each = toset(local.env)

  name            = "multi-env-${each.key}"
  project         = var.project_id
  region          = "us-central1"
  source_contents = templatefile("${path.module}/workflow.yaml", { url1 : "${var.url1}-${each.key}", url2 : "${var.url2}-${each.key}" })
}

    Saat variabel dideklarasikan dalam modul root konfigurasi, variabel tersebut dapat ditetapkan nilainya dengan sejumlah cara. Contohnya

    terraform apply -var="project_id=PROJECT_ID" -var="url1=URL_ONE" -var="url2=URL_TWO"

  • Gunakan konektor Secret Manager untuk menyimpan URL dengan aman di Secret Manager dan mengambilnya.

Menggunakan langkah bertingkat

Setiap alur kerja harus memiliki setidaknya satu langkah. Secara default, Workflows memperlakukan langkah-langkah seolah-olah berada dalam daftar yang diurutkan dan menjalankannya satu per satu hingga semua langkah dijalankan. Secara logis, beberapa langkah harus dikelompokkan bersama dan Anda dapat menggunakan blok steps untuk menyusun serangkaian langkah. Hal ini memudahkan karena Anda dapat mengarah ke langkah atomik yang benar untuk memproses serangkaian langkah.

Contoh

main:
    params: [input]
    steps:
    - callWikipedia:
        steps:
        - checkSearchTermInInput:
            switch:
                - condition: ${"searchTerm" in input}
                  assign:
                    - searchTerm: ${input.searchTerm}
                  next: readWikipedia
        - getCurrentDate:
            call: http.get
            args:
                url: https://timeapi.io/api/Time/current/zone?timeZone=Europe/Amsterdam
            result: currentDate
        - setFromCallResult:
            assign:
                - searchTerm: ${currentDate.body.dayOfWeek}
        - readWikipedia:
            call: http.get
            args:
                url: https://en.wikipedia.org/w/api.php
                query:
                    action: opensearch
                    search: ${searchTerm}
            result: wikiResult
    - returnOutput:
            return: ${wikiResult.body[1]}

Gabungkan ekspresi

Semua ekspresi harus diawali dengan $ dan diapit dalam tanda kurung kurawal:

${EXPRESSION}

Untuk menghindari masalah penguraian YAML, Anda dapat menggabungkan ekspresi dalam tanda kutip. Misalnya, ekspresi yang berisi titik dua dapat menyebabkan perilaku yang tidak terduga saat titik dua ditafsirkan sebagai penentu peta. Anda dapat mengatasi masalah ini dengan mengapit ekspresi YAML dalam tanda kutip tunggal:

'${"Name: " + myVar}'

Anda juga dapat menggunakan ekspresi yang mencakup beberapa baris. Misalnya, Anda mungkin perlu menggabungkan kueri SQL dalam tanda kutip saat menggunakan konektor BigQuery Workflows.

Contoh

- runQuery:
    call: googleapis.bigquery.v2.jobs.query
    args:
        projectId: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")}
        body:
            useLegacySql: false
            useQueryCache: false
            timeoutMs: 30000
            # Find top 100 titles with most views on Wikipedia
            query: ${
                "SELECT TITLE, SUM(views)
                FROM `bigquery-samples.wikipedia_pageviews." + table + "`
                WHERE LENGTH(TITLE) > 10
                GROUP BY TITLE
                ORDER BY SUM(VIEWS) DESC
                LIMIT 100"
                }
    result: queryResult

Untuk seluruh definisi alur kerja, lihat Menjalankan beberapa tugas BigQuery secara paralel.

Menggunakan panggilan deklaratif

Gunakan Workflows untuk memanggil layanan dari alur kerja itu sendiri dan menangani hasilnya, serta untuk menjalankan tugas sederhana seperti melakukan panggilan HTTP. Workflows dapat memanggil layanan, mengurai respons, dan membuat input untuk layanan terhubung lainnya. Dengan memanggil layanan, Anda dapat menghindari komplikasi pemanggilan tambahan, dependensi tambahan, dan layanan yang memanggil layanan. Pertimbangkan untuk mengganti layanan yang bebas dari logika bisnis dengan panggilan API deklaratif dan gunakan Workflows untuk mengabstraksi kompleksitas.

Namun, Anda harus membuat layanan untuk melakukan pekerjaan apa pun yang terlalu kompleks untuk Workflows; misalnya, menerapkan logika bisnis yang dapat digunakan kembali, komputasi kompleks, atau transformasi yang tidak didukung oleh ekspresi Workflows dan library standarnya. Kasus yang rumit biasanya lebih mudah diimplementasikan dalam kode, daripada menggunakan YAML atau JSON dan sintaksis Workflows.

Simpan hanya yang Anda butuhkan

Jaga konsumsi memori agar tetap terkendali sehingga Anda tidak mengalami batas resource atau error yang menunjukkan hal ini, seperti ResourceLimitError, MemoryLimitExceededError, atau ResultSizeLimitExceededError.

Pilih-pilih dalam menyimpan data di variabel, filter dan simpan hanya yang Anda perlukan. Jika layanan menampilkan payload yang terlalu besar, gunakan fungsi terpisah untuk melakukan panggilan dan hanya menampilkan data yang diperlukan.

Anda dapat mengosongkan memori dengan menghapus variabel. Misalnya, Anda mungkin ingin mengosongkan memori yang diperlukan untuk langkah berikutnya. Atau, Anda mungkin memiliki panggilan dengan hasil yang tidak Anda pedulikan, dan Anda dapat menghilangkan hasil tersebut sepenuhnya.

Anda dapat menghapus variabel dengan menetapkan null. Di YAML, Anda juga dapat menetapkan nilai kosong atau ~ ke variabel. Hal ini mengidentifikasi memori yang dapat diklaim kembali dengan aman.

Contoh

  - step:
      assign:
        - bigVar:

Menggunakan sub-alur kerja dan alur kerja eksternal

Anda dapat menggunakan sub-alur kerja untuk menentukan bagian logika atau serangkaian langkah yang ingin Anda panggil beberapa kali, sehingga menyederhanakan definisi alur kerja. Sub-alur kerja mirip dengan fungsi atau rutinitas dalam bahasa pemrograman. Fungsi ini dapat menerima parameter dan menampilkan nilai, sehingga Anda dapat membuat alur kerja yang lebih kompleks dengan berbagai aplikasi yang lebih luas.

Perhatikan bahwa sub-alur kerja bersifat lokal untuk definisi alur kerja Anda dan tidak dapat digunakan kembali dalam alur kerja lain. Namun, Anda dapat memanggil alur kerja dari alur kerja lain. Konektor Workflows dapat membantu Anda melakukannya. Untuk mengetahui informasi selengkapnya, lihat ringkasan konektor untuk Workflow Executions API dan Workflows API.

Menggunakan konektor Workflows

Workflows menyediakan sejumlah konektor yang memudahkan akses ke produk Google Cloud lain dalam alur kerja. Konektor menyederhanakan layanan panggilan karena menangani pemformatan permintaan untuk Anda, menyediakan metode dan argumen sehingga Anda tidak perlu mengetahui detail Google Cloud API. Konektor juga memiliki perilaku bawaan untuk menangani percobaan ulang dan operasi yang berjalan lama sehingga Anda dapat menghindari iterasi dan menunggu panggilan selesai; konektor akan menangani hal ini untuk Anda.

Jika Anda perlu memanggil API Google Cloud , periksa terlebih dahulu apakah ada konektor Workflows untuk API tersebut. Jika Anda tidak melihat konektor untuk produk Google Cloud , Anda dapat memintanya.

Pelajari cara menggunakan konektor dan, untuk referensi mendetail tentang konektor yang tersedia, lihat Referensi konektor.

Menjalankan langkah-langkah alur kerja secara paralel

Meskipun Workflows dapat menjalankan langkah-langkah secara berurutan, Anda juga dapat menjalankan langkah-langkah independen secara paralel. Dalam beberapa kasus, hal ini dapat mempercepat eksekusi alur kerja Anda secara signifikan. Untuk mengetahui informasi selengkapnya, lihat Menjalankan langkah-langkah alur kerja secara paralel.

Menerapkan percobaan ulang dan pola saga

Desain alur kerja yang tangguh dan dapat menangani kegagalan layanan sementara dan permanen. Error untuk Workflows mungkin muncul, misalnya, karena permintaan HTTP, fungsi, konektor yang gagal, atau dihasilkan oleh kode alur kerja Anda sendiri. Tambahkan penanganan error dan percobaan ulang agar kegagalan di satu langkah tidak menyebabkan seluruh alur kerja gagal.

Beberapa transaksi bisnis mencakup beberapa layanan, sehingga Anda memerlukan mekanisme untuk mengimplementasikan transaksi yang mencakup layanan. Pola desain saga adalah cara untuk mengelola konsistensi data di seluruh microservice dalam skenario transaksi terdistribusi. Saga adalah urutan transaksi yang memublikasikan peristiwa untuk setiap transaksi dan yang memicu transaksi berikutnya. Jika transaksi gagal, saga akan menjalankan transaksi kompensasi yang menangkal kegagalan sebelumnya dalam urutan. Coba tutorial Pola Saga dan Percobaan Ulang di Workflows di GitHub.

Menggunakan callback untuk menunggu

Callback memungkinkan eksekusi alur kerja menunggu layanan lain membuat permintaan ke endpoint callback; permintaan tersebut melanjutkan eksekusi alur kerja.

Dengan callback, Anda dapat memberi sinyal ke alur kerja bahwa peristiwa tertentu telah terjadi, dan menunggu peristiwa tersebut tanpa polling. Misalnya, Anda dapat membuat alur kerja yang memberi tahu Anda saat produk tersedia kembali atau saat item telah dikirim; atau yang menunggu untuk memungkinkan interaksi manusia seperti meninjau pesanan atau memvalidasi terjemahan. Anda juga dapat menunggu peristiwa menggunakan callback dan pemicu Eventarc.

Mengorkestrasi tugas yang berjalan lama

Jika perlu menjalankan workload pemrosesan batch yang berjalan lama, Anda dapat menggunakan Batch atau tugas Cloud Run, dan Anda dapat menggunakan Workflows untuk mengelola layanan. Hal ini memungkinkan Anda menggabungkan keunggulan serta menyediakan dan mengorkestrasi seluruh proses secara efisien.

Batch adalah layanan terkelola sepenuhnya yang memungkinkan Anda menjadwalkan, mengantrekan, dan menjalankan workload batch pada instance virtual machine (VM) Compute Engine. Anda dapat menggunakan konektor Workflows untuk Batch guna menjadwalkan dan menjalankan tugas Batch. Untuk mengetahui detailnya, coba tutorial.

Tugas Cloud Run digunakan untuk menjalankan kode yang melakukan pekerjaan (tugas) dan berhenti ketika pekerjaan tersebut selesai. Workflows memungkinkan Anda menjalankan tugas Cloud Run sebagai bagian dari alur kerja untuk melakukan pemrosesan data yang lebih kompleks atau mengorkestrasi sistem tugas yang ada. Coba tutorial yang menunjukkan cara menggunakan Workflows untuk menjalankan tugas Cloud Run.

Menyelaraskan waktu tunggu dan ukuran payload di seluruh layanan

Saat Workflows memanggil layanan Google Cloud downstream, perbedaan dalam waktu tunggu permintaan, batas respons HTTP, dan batas memori dapat menyebabkan kegagalan TimeoutError, ValueError, atau MemoryLimitExceededError. Bandingkan batas resource Workflows dengan batas layanan target, dan pilih pola integrasi yang sesuai dengan durasi dan ukuran payload workload Anda. Contoh:

Skenario integrasi Batas Workflows Batas layanan target Pola yang direkomendasikan
Panggilan HTTP sinkron (http.get, http.post, http.request) ke layanan Cloud Run atau Cloud Run Functions
  • Waktu tunggu permintaan HTTP maksimum 30 menit (1.800 detik), dengan default 300 detik untuk panggilan http.* dan 1.800 detik untuk permintaan HTTP konektor
  • Ukuran respons HTTP maksimum 2 MB sebelum memunculkan ValueError
  • Memori variabel kumulatif 512 KB sebelum memunculkan MemoryLimitExceededError
  • Waktu tunggu permintaan maksimum 60 menit (3.600 detik) untuk layanan Cloud Run dan Cloud Run Functions (generasi ke-2), atau maksimum 9 menit (540 detik) untuk fungsi generasi ke-1
  • Ukuran respons HTTP/1.1 maksimum 32 MB

Lihat Mengonfigurasi waktu tunggu permintaan untuk layanan dan Batas resource untuk Cloud Run.

Untuk workload yang berjalan lebih dari 30 menit, jangan gunakan panggilan http.* sinkron ke layanan Cloud Run.

Sebagai gantinya, jalankan tugas Cloud Run menggunakan konektor Cloud Run Admin API, atau gunakan endpoint callback Workflows asinkron.

Konektor Cloud Run Admin API mendukung polling operasi yang berjalan lama (LRO), yang waktu tunggunya habis setelah 30 menit (1.800 detik) secara default. Untuk tugas yang berjalan lebih dari 30 menit, konfigurasikan waktu tunggu tugas tugas Cloud Run (secara default 10 menit, dapat dikonfigurasi hingga 168 jam, atau 7 hari) dan connector_params.timeout pada panggilan konektor (hingga 1 tahun, atau 31536000 detik).
Kueri BigQuery dan payload API besar (googleapis.bigquery.v2.jobs.query dan respons REST)
  • Memori variabel kumulatif 512 KB sebelum memunculkan MemoryLimitExceededError
  • Panjang string UTF-8 maksimum 256 KB
  • Ukuran respons HTTP maksimum 2 MB sebelum memunculkan ValueError

Hasil kueri BigQuery dan payload REST API dapat melebihi beberapa megabyte atau gigabyte.

Lihat kuota dan batas tugas kueri BigQuery.

Hindari menarik set hasil yang besar ke dalam variabel alur kerja.

Gunakan penomoran halaman maxResults, tulis output kueri besar ke tabel tujuan atau bucket Cloud Storage menggunakan EXPORT DATA, atau pindahkan transformasi dan pemfilteran payload ke layanan Cloud Run atau fungsi Cloud Run sebelum menampilkan ringkasan ringkas ke Workflows.

Memisahkan tugas yang berjalan lama menggunakan container

Anda dapat mengotomatiskan eksekusi container yang berjalan lama menggunakan Workflows dan Compute Engine. Misalnya, Anda dapat memasukkan tugas yang berjalan lama ke dalam container sehingga dapat dijalankan di mana saja, lalu menjalankan container tersebut di VM Compute Engine selama durasi maksimum eksekusi alur kerja (satu tahun).

Dengan Workflows, Anda dapat mengotomatiskan pembuatan VM, menjalankan container di VM, dan menghapus VM. Hal ini memungkinkan Anda menggunakan server dan menjalankan container, tetapi mengabstraksi kompleksitas pengelolaan keduanya, dan dapat membantu jika Anda mengalami batasan waktu saat menggunakan layanan seperti Cloud Run Functions atau Cloud Run. Coba tutorial Container yang berjalan lama dengan Workflows dan Compute Engine di GitHub.

Menjalankan alat command line dari Workflows

Cloud Build adalah layanan yang menjalankan build Anda di Google Cloud sebagai serangkaian langkah build, dengan setiap langkah build dijalankan dalam container Docker. Eksekusi langkah build serupa dengan eksekusi perintah di dalam skrip.

Google Cloud CLI mencakup alat command line gcloud, bq, dan kubectl, tetapi tidak ada cara langsung untuk menjalankan perintah gcloud CLI dari Workflows. Namun, Cloud Build menyediakan image container yang menyertakan gcloud CLI. Anda dapat menjalankan perintah gcloud CLI di container tersebut dari langkah Cloud Build, dan Anda dapat membuat langkah tersebut di Workflows menggunakan konektor Cloud Build.

Contoh

Jalankan gcloud dalam alur kerja:

# This example shows how to execute gcloud commands from Workflows
# using Cloud Build and returns the output

main:
  steps:
  - execute_command:
      call: gcloud
      args:
          args: "workflows list"
      result: result
  - return_result:
      return: ${result}

gcloud:
  params: [args]
  steps:
  - create_build:
      call: googleapis.cloudbuild.v1.projects.builds.create
      args:
        projectId: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")}
        parent: ${"projects/" + sys.get_env("GOOGLE_CLOUD_PROJECT_ID") + "/locations/global"}
        body:
          serviceAccount: ${sys.get_env("GOOGLE_CLOUD_SERVICE_ACCOUNT_NAME")}
          options:
            logging: CLOUD_LOGGING_ONLY
          steps:
          - name: gcr.io/google.com/cloudsdktool/cloud-sdk
            entrypoint: /bin/bash
            args: ${["-c", "gcloud " + args + " > $$BUILDER_OUTPUT/output"]}
      result: result_builds_create
  - return_build_result:
      return: ${text.split(text.decode(base64.decode(result_builds_create.metadata.build.results.buildStepOutputs[0])), "\n")}

Run kubectl in a workflow:

# This example shows how to execute kubectl commands from Workflows
# using Cloud Build and returns the output

main:
  steps:
  - execute_command:
      call: kubectl
      args:
          args: "--help"
      result: result
  - return_result:
      return: ${result}

kubectl:
  params: [args]
  steps:
  - create_build:
      call: googleapis.cloudbuild.v1.projects.builds.create
      args:
        projectId: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")}
        parent: ${"projects/" + sys.get_env("GOOGLE_CLOUD_PROJECT_ID") + "/locations/global"}
        body:
          serviceAccount: ${sys.get_env("GOOGLE_CLOUD_SERVICE_ACCOUNT_NAME")}
          options:
            logging: CLOUD_LOGGING_ONLY
          steps:
          - name: gcr.io/cloud-builders/kubectl
            entrypoint: /bin/bash
            args: ${["-c", "kubectl " + args + " > $$BUILDER_OUTPUT/output"]}
      result: result_builds_create
  - return_build_result:
      return: ${text.split(text.decode(base64.decode(result_builds_create.metadata.build.results.buildStepOutputs[0])), "\n")}

Menggunakan Terraform untuk membuat alur kerja

Terraform adalah alat infrastructure as code yang memungkinkan Anda membuat, mengubah, dan meningkatkan infrastruktur cloud secara tepat menggunakan kode.

Anda dapat menentukan dan men-deploy alur kerja menggunakan resource google_workflows_workflow Terraform. Untuk mengetahui informasi selengkapnya, lihat Membuat alur kerja menggunakan Terraform.

Untuk membantu Anda mengelola dan memelihara alur kerja yang besar, Anda dapat membuat alur kerja dalam file YAML terpisah dan mengimpor file tersebut ke Terraform menggunakan fungsi templatefile yang membaca file di jalur tertentu dan merender kontennya sebagai template.

Contoh

  # Define a workflow
  resource "google_workflows_workflow" "workflows_example" {
    name            = "sample-workflow"
    region          = var.region
    description     = "A sample workflow"
    service_account = google_service_account.workflows_service_account.id
    # Import main workflow YAML file
    source_contents = templatefile("${path.module}/workflow.yaml",{})
  }

Demikian pula, jika Anda memiliki alur kerja utama yang memanggil beberapa sub-alur kerja, Anda dapat menentukan alur kerja utama dan sub-alur kerja dalam file terpisah, dan menggunakan fungsi templatefile untuk mengimpornya.

Contoh

  # Define a workflow
  resource "google_workflows_workflow" "workflows_example" {
    name            = "sample-workflow"
    region          = var.region
    description     = "A sample workflow"
    service_account = google_service_account.workflows_service_account.id
    # Import main workflow and subworkflow YAML files
    source_contents = join("", [
      templatefile(
        "${path.module}/workflow.yaml",{}
      ),

      templatefile(
        "${path.module}/subworkflow.yaml",{}
      )])
  }

Perhatikan bahwa jika Anda merujuk ke nomor baris saat men-debug alur kerja, semua file YAML yang diimpor melalui file konfigurasi Terraform akan digabungkan dan di-deploy sebagai satu alur kerja.

Men-deploy alur kerja dari repositori Git

Cloud Build menggunakan pemicu build untuk mengaktifkan otomatisasi CI/CD. Anda dapat mengonfigurasi pemicu untuk memproses peristiwa yang masuk, seperti saat commit baru dikirim ke repositori atau saat permintaan pull dimulai, lalu otomatis menjalankan build saat peristiwa baru masuk.

Anda dapat menggunakan pemicu Cloud Build untuk memulai build secara otomatis dan men-deploy alur kerja dari repositori Git. Anda dapat mengonfigurasi pemicu untuk men-deploy alur kerja pada setiap perubahan pada repositori sumber, atau men-deploy alur kerja hanya jika perubahan tersebut cocok dengan kriteria tertentu.

Pendekatan ini dapat membantu Anda mengelola siklus proses deployment. Misalnya, Anda dapat men-deploy perubahan pada alur kerja di lingkungan staging, menjalankan pengujian terhadap lingkungan tersebut, lalu meluncurkan perubahan ini secara bertahap ke lingkungan produksi. Untuk mengetahui informasi selengkapnya, lihat Men-deploy alur kerja dari repositori Git menggunakan Cloud Build.

Mengoptimalkan penggunaan

Biaya untuk menjalankan alur kerja sangat minim. Namun, untuk penggunaan volume tinggi, terapkan panduan berikut untuk mengoptimalkan penggunaan dan mengurangi biaya:

  • Daripada menggunakan domain kustom, pastikan setiap panggilan ke layanan Google Cloudmenggunakan *.appspot.com, *.cloud.goog, *.cloudfunctions.net, atau *.run.app agar Anda ditagih untuk langkah internal, bukan eksternal.

  • Terapkan kebijakan percobaan ulang kustom yang menyeimbangkan kebutuhan latensi dan keandalan Anda dengan biaya. Percobaan ulang yang lebih sering akan menurunkan latensi dan meningkatkan keandalan, tetapi juga dapat meningkatkan biaya.

  • Saat menggunakan konektor yang menunggu operasi yang berjalan lama, tetapkan kebijakan polling kustom yang mengoptimalkan latensi untuk biaya. Misalnya, jika Anda memperkirakan operasi akan memerlukan waktu lebih dari satu jam, Anda mungkin menginginkan kebijakan yang awalnya melakukan polling setelah satu menit jika terjadi kegagalan langsung, dan kemudian setiap 15 menit setelahnya.

  • Gabungkan penetapan menjadi satu langkah.

  • Hindari penggunaan langkah sys.log yang berlebihan. Sebaiknya gunakan log panggilan.

  • Memahami operasi mana yang dianggap sebagai langkah. Operasi yang tidak dihitung sebagai langkah tersendiri akan dihitung saat digunakan dalam langkah yang berlaku. Misalnya, hal berikut dihitung sebagai satu langkah:

    - type_check:
    return: if(get_type((int("6"))) == integer, 1, 2)

    Operasi kunci yang dihitung dan tidak dihitung dalam batas langkah maksimum dikategorikan dalam tabel berikut:

    Kategori Operasi
    Dihitung sebagai langkah
    • Operasi data: Menetapkan, menampilkan nilai
    • Mengontrol alur: Lompatan (next), pengalihan, memulai loop for, dan setiap iterasi loop for
    • Panggilan: Memanggil sys.get_env atau fungsi library standar lainnya, alur kerja lain, atau konektor
    • Konkurensi: Memunculkan thread dan eksekusi paralel
    • Penanganan error: Setiap blok raise, try, retry, dan except dihitung sebagai langkah terpisah, meskipun operasi lain merupakan bagian dari langkah yang lebih besar yang sama.

      Misalnya, langkah yang menyertakan blok try dengan operasi panggilan dihitung sebagai tiga langkah: satu untuk langkah utama, satu untuk percobaan, dan satu untuk panggilan. Menambahkan blok retry akan menambahkan tiga langkah lagi (masing-masing satu untuk coba lagi, coba, dan panggil), sehingga totalnya menjadi enam langkah.
    Tidak dihitung sebagai langkah

Ringkasan praktik terbaik

Tabel berikut merangkum tips umum dan praktik terbaik yang direkomendasikan dalam dokumen ini.

Tips umum
Praktik terbaik

Langkah berikutnya