Memanggil Cloud Run functions atau Cloud Run

Memanggil layanan Google Cloud seperti fungsi Cloud Run atau Cloud Run dari Workflows dilakukan melalui permintaan HTTP. Metode permintaan HTTP yang paling umum memiliki pintasan panggilan (seperti http.get dan http.post), tetapi Anda dapat membuat semua jenis permintaan HTTP dengan menetapkan kolom call ke http.request dan menentukan jenis permintaan menggunakan kolom method. Untuk mengetahui informasi selengkapnya, lihat Membuat permintaan HTTP.

Untuk mengirim permintaan yang diautentikasi:

  • Alur kerja Anda harus dikaitkan dengan akun layanan yang telah diberi satu atau beberapa peran Identity and Access Management (IAM) yang berisi izin yang diperlukan.

  • Anda harus menambahkan informasi autentikasi secara eksplisit ke definisi alur kerja. Secara default, permintaan HTTP tidak berisi token akses atau identitas karena alasan keamanan.

Untuk mengetahui informasi selengkapnya, lihat Memberikan izin alur kerja untuk mengakses resource Google Cloud .

Kapan harus memanggil layanan

Bagaimana Anda tahu kapan harus membuat langkah-langkah di YAML atau JSON menggunakan sintaksis Workflows atau kapan harus membuat layanan—misalnya, layanan Cloud Run atau fungsi Cloud Run—untuk melakukan pekerjaan tersebut?

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. Memanggil layanan memungkinkan Anda menghindari komplikasi pemanggilan tambahan, dependensi tambahan, dan layanan yang memanggil layanan.

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

Waktu tunggu permintaan dan batas payload

Saat memanggil layanan Cloud Run atau fungsi Cloud Run melalui HTTP, ingatlah bahwa permintaan HTTP sinkron (http.get, http.post, http.request) di Workflows secara default memiliki waktu tunggu 5 menit (300 detik), mendukung waktu tunggu maksimum 30 menit (1.800 detik), dan mengizinkan ukuran respons maksimum 2 MB (tunduk pada batas memori variabel 512 KB jika disimpan dalam variabel).

Meskipun layanan Cloud Run dan Cloud Run Functions (generasi ke-2) mendukung waktu tunggu permintaan hingga 60 menit, setiap langkah http.* sinkron di Workflows akan mengalami waktu tunggu habis dengan TimeoutError setelah waktu tunggu yang dikonfigurasi (hingga 30 menit). Untuk workload yang berjalan lebih dari 30 menit atau menampilkan payload besar, gunakan tugas Cloud Run atau endpoint callback. Untuk perbandingan batas dan pola yang direkomendasikan, lihat Menyelaraskan waktu tunggu dan ukuran payload di seluruh layanan.

Memanggil layanan yang dibatasi untuk traffic masuk internal

Workflows dapat memanggil fungsi Cloud Run atau layanan Cloud Run dalam Google Cloud project atau perimeter Kontrol Layanan VPC yang sama yang memiliki traffic masuk yang dibatasi untuk traffic internal. Dengan konfigurasi ini, layanan Anda tidak dapat dijangkau dari internet, tetapi dapat dijangkau dari Workflows.

Untuk menerapkan batasan ini, Anda harus menyesuaikan setelan ingress layanan atau fungsi Anda. Perhatikan bahwa layanan Cloud Run harus dijangkau di URL run.app-nya, bukan di domain kustom. Untuk mengetahui informasi selengkapnya, lihat Membatasi traffic masuk jaringan (untuk Cloud Run dan Cloud Run Functions generasi ke-2) dan Mengonfigurasi setelan jaringan (generasi ke-1) (untuk Cloud Run Functions generasi ke-1). Tidak ada perubahan lain yang diperlukan pada alur kerja Anda.

Menggunakan akun layanan dengan izin yang diperlukan

Saat membuat permintaan ke layanan Google Cloud lain, alur kerja Anda harus dikaitkan dengan akun layanan yang memiliki izin yang benar untuk mengakses resource yang diminta. Untuk mempelajari akun layanan yang terkait dengan alur kerja yang ada, lihat Memverifikasi akun layanan yang terkait dengan alur kerja.

Saat menyiapkan akun layanan, Anda mengaitkan identitas yang meminta dengan resource yang ingin Anda beri akses—Anda menjadikan identitas yang meminta sebagai principal resource—lalu menetapkan peran yang sesuai. Peran menentukan izin yang dimiliki identitas dalam konteks resource.

Misalnya, untuk mengonfigurasi fungsi Cloud Run penerima (generasi ke-1) agar menerima permintaan dari fungsi atau layanan panggilan tertentu, Anda harus menambahkan akun layanan pemanggil sebagai akun utama pada fungsi penerima dan memberikan peran Invoker Cloud Functions (roles/cloudfunctions.invoker) kepada akun utama tersebut. Demikian pula, untuk menyiapkan akun layanan untuk layanan Cloud Run atau Cloud Run Functions (generasi ke-2), Anda memberikan peran Cloud Run Invoker (roles/run.invoker) ke akun layanan tersebut. Untuk mempelajari lebih lanjut, lihat Kontrol akses dengan IAM atau Ringkasan autentikasi Cloud Run.

Memanggil fungsi Cloud Run

Di Cloud Run Functions, izin pemanggilan tersedia dengan mengelola layanan Cloud Run yang mendasarinya. Jika alur kerja Anda memanggil layanan Cloud Run Functions, Anda tidak perlu memberikan peran IAM Cloud Functions Invoker (roles/cloudfunctions.invoker) ke akun layanan pemanggil. Sebagai gantinya, Anda harus memberikan peran IAM Cloud Run Invoker (roles/run.invoker).

Untuk mengetahui informasi selengkapnya, lihat Membandingkan Cloud Run Functions.

Menambahkan informasi autentikasi ke alur kerja Anda

Saat membuat permintaan ke Cloud Run Functions atau Cloud Run, gunakan OIDC untuk melakukan autentikasi.

Untuk membuat permintaan HTTP menggunakan OIDC, tambahkan bagian auth ke bagian args definisi alur kerja Anda, setelah Anda menentukan URL. Dalam contoh ini, permintaan dikirim untuk memanggil fungsi Cloud Run:

YAML

  - step_A:
      call: http.get
      args:
          url: https://us-central1-project.cloudfunctions.net/functionA
          query:
              firstNumber: 4
              secondNumber: 6
              operation: sum
          auth:
              type: OIDC
              audience: OIDC_AUDIENCE

JSON

    [
      {
        "step_A": {
          "call": "http.get",
          "args": {
            "url": "https://us-central1-project.cloudfunctions.net/functionA",
            "query": {
              "firstNumber": 4,
              "secondNumber": 6,
              "operation": "sum"
            },
            "auth": {
              "type": "OIDC",
              "audience": "OIDC_AUDIENCE"
            }
          }
        }
      }
    ]
Parameter audience opsional menentukan audiens OIDC (OIDC_AUDIENCE) untuk token. Secara default, atribut ini ditetapkan ke nilai yang sama dengan url; namun, jika url menyertakan segmen jalur tambahan di luar URL root layanan atau fungsi, tetapkan audience ke URL root (misalnya, https://us-central1-project.cloudfunctions.net/functionA).

Menentukan jenis media untuk data respons

Jika header Content-Type untuk respons menentukan jenis media application/json, respons JSON yang disimpan dalam variabel akan otomatis dikonversi ke peta yang dapat diakses.

Jika perlu, ubah API yang dipanggil untuk menentukan jenis media application/json untuk header respons Content-Type. Atau, Anda dapat menggunakan fungsi json.decode dan text.encode untuk mengonversi isi respons menjadi peta. Contoh:

json.decode(text.encode(RESPONSE_FROM_API))

Untuk mengetahui informasi selengkapnya, lihat Mengakses data respons HTTP yang disimpan dalam variabel.

Menjalankan tugas Cloud Run

Tidak seperti layanan Cloud Run, tugas Cloud Run tidak memproses atau melayani permintaan HTTP. Untuk mengeksekusi tugas Cloud Run dari sebuah workflow, gunakan konektor Cloud Run Admin API. Jika tugas memerlukan waktu lebih dari 30 menit untuk diselesaikan, konfigurasikan waktu tunggu tugas (secara default 10 menit, dapat dikonfigurasi hingga 168 jam, atau 7 hari) dan connector_params.timeout dalam panggilan konektor (yang secara default 1.800 detik dan dapat ditetapkan hingga 31.536.000 detik, atau 1 tahun).

Untuk contoh end-to-end dari eksekusi job Cloud Run yang memproses data yang diteruskan sebagai variabel lingkungan ke tugas, lihat Eksekusi job Cloud Run menggunakan Workflows.

Untuk contoh end-to-end dari eksekusi tugas Cloud Run yang memproses data yang disimpan di sebuah bucket Cloud Storage, yang memungkinkan Anda mengenkripsi data menggunakan kunci enkripsi yang dikelola pelanggan (CMEK), lihat artikel Eksekusi tugas Cloud Run yang memproses data peristiwa yang disimpan di Cloud Storage.

Langkah berikutnya