प्रोडक्शन में डिप्लॉय करें

यह गाइड, Data Manager API को प्रोडक्शन में डिप्लॉय करने के लिए, पुष्टि करने का सही तरीका चुनने और उसे कॉन्फ़िगर करने में आपकी मदद करती है.

डिप्लॉयमेंट का अपना तरीका चुनें

पुष्टि करने का वह तरीका चुनें जो आपके ऐप्लिकेशन के आर्किटेक्चर और डिप्लॉयमेंट एनवायरमेंट के मुताबिक हो:

Google Cloud पर पुष्टि करने के बारे में सामान्य जानकारी के लिए, Google Cloud पर पुष्टि करने के बारे में फ़ैसला लेने का ट्री देखें.

Google Cloud में मौजूद वर्कलोड

Google Cloud पर चलने के दौरान, कोई सेवा खाता अटैच करें सीधे तौर पर अपने कंप्यूट संसाधन से या GKE के लिए Workload Identity Federation को कॉन्फ़िगर करें. क्लाइंट लाइब्रेरी, सेवा खाते के लिए कम समय के क्रेडेंशियल पाने के लिए, ADC का इस्तेमाल करती हैं . इसके लिए, क्रेडेंशियल फ़ाइलों या एनवायरमेंट वैरिएबल की ज़रूरत नहीं होती.

Compute Engine

वर्चुअल मशीन इंस्टेंस बनाते समय, सेवा खाता और Data Manager API का दायरा तय करें, ताकि इंस्टेंस मेटाडेटा सर्वर से मिलने वाले ऐक्सेस टोकन में, ज़रूरी अनुमति शामिल हो.

gcloud compute instances create INSTANCE_NAME \
  --service-account="SERVICE_ACCOUNT_EMAIL" \
  --scopes="https://www.googleapis.com/auth/datamanager,https://www.googleapis.com/auth/cloud-platform"

मौजूदा इंस्टेंस पर, दायरों या सेवा खाते को अपडेट करने के लिए, इंस्टेंस को रोकें. इसके बाद, set-service-account की मदद से कॉन्फ़िगरेशन अपडेट करें. इसके बाद, इंस्टेंस को फिर से चालू करें:

gcloud compute instances stop INSTANCE_NAME

gcloud compute instances set-service-account \
  INSTANCE_NAME \
  --service-account="SERVICE_ACCOUNT_EMAIL" \
  --scopes="https://www.googleapis.com/auth/datamanager,https://www.googleapis.com/auth/cloud-platform"

gcloud compute instances start INSTANCE_NAME

Cloud Run

सेवा को डिप्लॉय करते समय, सेवा खाते के बारे में बताएं:

gcloud run deploy SERVICE_NAME \
  --image="IMAGE_URL" \
  --service-account="SERVICE_ACCOUNT_EMAIL"

Cloud Functions

फ़ंक्शन को डिप्लॉय करते समय, सेवा खाते के बारे में बताएं:

gcloud functions deploy FUNCTION_NAME \
  --service-account="SERVICE_ACCOUNT_EMAIL" \
  --runtime="RUNTIME" \
  --trigger-http

GKE

  1. अपने क्लस्टर पर, GKE के लिए Workload Identity Federation चालू करें.

  2. अपने Kubernetes सेवा खाते (केएसए) को Google सेवा खाते (जीएसए) से बाइंड करें:

    # Define the Kubernetes service account member:
KUBERNETES_MEMBER="serviceAccount:PROJECT_ID.svc.id.goog[KUBERNETES_NAMESPACE/KUBERNETES_SA_NAME]"

# Grant the Workload Identity User role to the Kubernetes service account:
gcloud iam service-accounts add-iam-policy-binding \
  SERVICE_ACCOUNT_EMAIL \
  --role="roles/iam.workloadIdentityUser" \
  --member="${KUBERNETES_MEMBER}"

  3. Kubernetes सेवा खाते में, Google सेवा खाते का ईमेल पता जोड़ें:

    kubectl annotate serviceaccount KUBERNETES_SA_NAME \
  --namespace="KUBERNETES_NAMESPACE" \
  iam.gke.io/gcp-service-account="SERVICE_ACCOUNT_EMAIL"

  4. अपने पॉड की खास जानकारी में, Kubernetes सेवा खाते के बारे में बताएं:

    apiVersion: v1
kind: Pod
metadata:
  name: data-manager-worker
spec:
  serviceAccountName: KUBERNETES_SA_NAME
  containers:
  - name: worker
    image: IMAGE_URL

आईएएम और खाते के ऐक्सेस की पुष्टि करना

अपने ऐप्लिकेशन को प्रोडक्शन में डिप्लॉय करने से पहले, पुष्टि करें कि आपके सेवा खाते के पास ज़रूरी अनुमतियां हैं या नहीं:

  1. Google Cloud की आईएएम अनुमतियां: सेवा खाते को सेवा के इस्तेमाल करने वाले ग्राहक की भूमिका (roles/serviceusage.serviceUsageConsumer) दें. यह भूमिका उस Google Cloud प्रोजेक्ट में दें जिसमें Data Manager API चालू है.

    gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
  --role="roles/serviceusage.serviceUsageConsumer"

  2. डेस्टिनेशन खाते का ऐक्सेस: सेवा खाते को, अपने डेस्टिनेशन खातों का ज़रूरी ऐक्सेस दें. सिलसिलेवार निर्देशों के लिए, खाते का ऐक्सेस सेट अप करना देखें.

Google Cloud के बाहर मौजूद वर्कलोड

कंपनी की इमारत में मौजूद डेटा सेंटर या अन्य क्लाउड सेवा देने वाली कंपनियों के प्लैटफ़ॉर्म पर कोड चलाने के दौरान, पुष्टि करने के इन तरीकों में से कोई एक तरीका चुनें:

  • Workload Identity Federation (सुझाया गया तरीका): Workload Identity Federation को कॉन्फ़िगर करें, ताकि आपका ऐप्लिकेशन, सेवा खाते की कुंजियों को मैनेज किए बिना, आपके बाहरी आइडेंटिटी प्रोवाइडर से मिले क्रेडेंशियल को कम समय के Google Cloud क्रेडेंशियल के लिए बदल सके. क्रेडेंशियल कॉन्फ़िगरेशन फ़ाइल जनरेट करें और GOOGLE_APPLICATION_CREDENTIALS एनवायरमेंट वैरिएबल का इस्तेमाल करके, इसे ADC को उपलब्ध कराएं.

  • सेवा खाते की कुंजियां (फ़ॉल बैक): अगर Workload Identity Federation उपलब्ध नहीं है, तो सेवा खाते की कुंजी बनाएं और GOOGLE_APPLICATION_CREDENTIALS एनवायरमेंट वैरिएबल का इस्तेमाल करके, इसे ADC को उपलब्ध कराएं.

GOOGLE_APPLICATION_CREDENTIALS सेट करना

GOOGLE_APPLICATION_CREDENTIALS एनवायरमेंट वैरिएबल को, Workload Identity Federation क्रेडेंशियल कॉन्फ़िगरेशन फ़ाइल या सेवा खाते की कुंजी फ़ाइल के पूरे पाथ पर सेट करें, ताकि क्लाइंट लाइब्रेरी, ADC का इस्तेमाल करके आपके क्रेडेंशियल को अपने-आप ढूंढ सकें.

Linux / macOS

अपने शेल प्रोफ़ाइल या डिप्लॉयमेंट स्क्रिप्ट में, एनवायरमेंट वैरिएबल सेट करें:

export GOOGLE_APPLICATION_CREDENTIALS=\
  "/path/to/credentials.json"

Windows (PowerShell)

PowerShell में, एनवायरमेंट वैरिएबल सेट करें:

$env:GOOGLE_APPLICATION_CREDENTIALS = `
  "C:\path\to\credentials.json"

Docker / कंटेनर

क्रेडेंशियल फ़ाइल को कंटेनर में माउंट करें और एनवायरमेंट वैरिएबल सेट करें:

ENV GOOGLE_APPLICATION_CREDENTIALS="/secrets/credentials.json"

इसके अलावा, रनटाइम पर एनवायरमेंट वैरिएबल पास करें:

HOST_CREDS="/host/path/credentials.json"
docker run -e GOOGLE_APPLICATION_CREDENTIALS="/secrets/credentials.json" \
  -v "${HOST_CREDS}:/secrets/credentials.json:ro" \
  IMAGE_NAME

Kubernetes

क्रेडेंशियल को सीक्रेट के तौर पर माउंट करें और पॉड के एनवायरमेंट में इसका रेफ़रंस दें:

apiVersion: v1
kind: Pod
metadata:
  name: data-manager-worker
spec:
  containers:
  - name: worker
    image: IMAGE_URL
    env:
    - name: GOOGLE_APPLICATION_CREDENTIALS
      value: "/etc/secrets/google/credentials.json"
    volumeMounts:
    - name: credentials-volume
      mountPath: "/etc/secrets/google"
      readOnly: true
  volumes:
  - name: credentials-volume
    secret:
      secretName: data-manager-credentials

REST और curl के अनुरोधों की पुष्टि करना

अगर आपकी ऑटोमेटेड पाइपलाइन, क्लाइंट लाइब्रेरी का इस्तेमाल करने के बजाय, curl की मदद से रॉ एचटीटीपी अनुरोध करती है, तो Google Cloud CLI का इस्तेमाल करके, बिना इंटरैक्ट किए पुष्टि करें और ऐक्सेस टोकन मैनेज करें. इसके लिए, टोकन पर मैन्युअल तरीके से हस्ताक्षर करने की ज़रूरत नहीं होती:

  1. अपने एनवायरमेंट में कॉन्फ़िगर की गई क्रेडेंशियल फ़ाइल का इस्तेमाल करके, Google Cloud CLI को अनुमति दें:

    gcloud auth login --cred-file="${GOOGLE_APPLICATION_CREDENTIALS}"

  2. जनरेट किए गए ऐक्सेस टोकन को, अपने एपीआई अनुरोधों के Authorization हेडर में पास करें:

    curl -X POST "https://datamanager.googleapis.com/v1/..." \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -d @request.json

    Google Cloud CLI, ऐक्सेस टोकन को अपने-आप कैश करता है और इसकी समयसीमा खत्म होने से पहले इसे रीफ़्रेश करता है.

आईएएम और खाते के ऐक्सेस की पुष्टि करना

अपने ऐप्लिकेशन को प्रोडक्शन में डिप्लॉय करने से पहले, पुष्टि करें कि आपके सेवा खाते के पास ज़रूरी अनुमतियां हैं या नहीं:

  1. Google Cloud की आईएएम अनुमतियां: सेवा खाते को सेवा के इस्तेमाल करने वाले ग्राहक की भूमिका (roles/serviceusage.serviceUsageConsumer) दें. यह भूमिका उस Google Cloud प्रोजेक्ट में दें जिसमें Data Manager API चालू है.

    gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
  --role="roles/serviceusage.serviceUsageConsumer"

  2. डेस्टिनेशन खाते का ऐक्सेस: सेवा खाते को, अपने डेस्टिनेशन खातों का ज़रूरी ऐक्सेस दें. सिलसिलेवार निर्देशों के लिए, खाते का ऐक्सेस सेट अप करना देखें.

उपयोगकर्ताओं की ओर से कार्रवाई करना

मार्केटिंग प्लैटफ़ॉर्म और एजेंसियां जैसे तीसरे पक्ष के प्लैटफ़ॉर्म को अक्सर, अपने प्लैटफ़ॉर्म पर साइन अप करने वाले कई विज्ञापन देने वालों की ओर से, एपीआई अनुरोध भेजने की ज़रूरत होती है.

इस आर्किटेक्चर में, Application Default Credentials का इस्तेमाल करने के बजाय, OAuth 2.0 वेब सर्वर फ़्लो का इस्तेमाल करें. इससे, हर विज्ञापन देने वाले से ऑफ़लाइन ऐक्सेस के साथ उपयोगकर्ता क्रेडेंशियल हासिल किए जा सकते हैं. इसके बाद, इन क्रेडेंशियल का इस्तेमाल करके, रनटाइम पर क्लाइंट लाइब्रेरी को कॉन्फ़िगर किया जा सकता है. यह इस बात पर निर्भर करता है कि अनुरोध किस विज्ञापन देने वाले के खाते को मैनेज कर रहा है.

OAuth 2.0 वेब फ़्लो लागू करना

मल्टी-टैनेंट ऐप्लिकेशन के लिए, उपयोगकर्ता को डेलिगेट करने की सुविधा सेट अप करने का तरीका यहां बताया गया है:

  1. ऑफ़लाइन ऐक्सेस का अनुरोध करना: उपयोगकर्ताओं को, Google की OAuth सहमति वाली स्क्रीन पर भेजें. इसमें https://www.googleapis.com/auth/datamanager दायरे का अनुरोध किया जाता है. साथ ही, इसमें access_type=offline और prompt=consent शामिल हैं. आपका सर्वर, ऑथराइज़ेशन कोड को ऐक्सेस टोकन और refresh_token के लिए बदलता है. सिलसिलेवार निर्देशों के लिए, वेब सर्वर ऐप्लिकेशन के लिए OAuth 2.0 देखें.

  2. क्रेडेंशियल को सुरक्षित तरीके से स्टोर करना: हर उपयोगकर्ता के रीफ़्रेश टोकन को, आपके प्लैटफ़ॉर्म पर उसके खाते से जुड़े एन्क्रिप्टेड क्रेडेंशियल स्टोर में सुरक्षित तरीके से स्टोर करें.

  3. रनटाइम पर क्लाइंट लाइब्रेरी को शुरू करना: किसी खास उपयोगकर्ता की ओर से एपीआई अनुरोध भेजते समय, उपयोगकर्ता के लिए स्टोर किए गए रीफ़्रेश टोकन और अपने ऐप्लिकेशन के लिए क्लाइंट आईडी और क्लाइंट सीक्रेट से उपयोगकर्ता क्रेडेंशियल बनाएं. इसके बाद, क्लाइंट को शुरू करते समय इन्हें पास करें:

    .NET

    using Google.Ads.DataManager.V1;
using Google.Apis.Auth.OAuth2;

UserCredential credential = CredentialFactory.FromJsonParameters<UserCredential>(
    new JsonCredentialParameters
    {
        Type = JsonCredentialParameters.AuthorizedUserCredentialType,
        ClientId = clientId,
        ClientSecret = clientSecret,
        RefreshToken = refreshToken
    });

IngestionServiceClient client = new IngestionServiceClientBuilder
{
    Credential = credential
}.Build();

    Go

    import (
    "context"

    datamanager "cloud.google.com/go/datamanager/apiv1"
    "golang.org/x/oauth2"
    "golang.org/x/oauth2/google"
    "google.golang.org/api/option"
)

cfg := &oauth2.Config{
    ClientID:     clientID,
    ClientSecret: clientSecret,
    Endpoint:     google.Endpoint,
}
ts := cfg.TokenSource(ctx, &oauth2.Token{RefreshToken: refreshToken})

client, err := datamanager.NewIngestionClient(ctx, option.WithTokenSource(ts))

    Java

    import com.google.ads.datamanager.v1.IngestionServiceClient;
import com.google.ads.datamanager.v1.IngestionServiceSettings;
import com.google.api.gax.core.FixedCredentialsProvider;
import com.google.auth.oauth2.UserCredentials;

UserCredentials credentials =
    UserCredentials.newBuilder()
        .setClientId(clientId)
        .setClientSecret(clientSecret)
        .setRefreshToken(refreshToken)
        .build();

IngestionServiceSettings settings =
    IngestionServiceSettings.newBuilder()
        .setCredentialsProvider(FixedCredentialsProvider.create(credentials))
        .build();

try (IngestionServiceClient client = IngestionServiceClient.create(settings)) {
  // Send API requests using client...
}

    Node.js

    const {IngestionServiceClient} = require('@google-ads/datamanager').v1;
const {UserRefreshClient} = require('google-auth-library');

const authClient = new UserRefreshClient({
  clientId,
  clientSecret,
  refreshToken,
});

const client = new IngestionServiceClient({authClient});

    PHP

    use Google\Ads\DataManager\V1\Client\IngestionServiceClient;
use Google\Auth\Credentials\UserRefreshCredentials;

$credentials = new UserRefreshCredentials(
    null,
    [
        'client_id' => $clientId,
        'client_secret' => $clientSecret,
        'refresh_token' => $refreshToken,
    ]
);

$client = new IngestionServiceClient(['credentials' => $credentials]);

    Python

    from google.ads.datamanager_v1 import IngestionServiceClient
from google.oauth2.credentials import Credentials

credentials = Credentials.from_authorized_user_info({
    "client_id": client_id,
    "client_secret": client_secret,
    "refresh_token": refresh_token,
})

client = IngestionServiceClient(credentials=credentials)

    Ruby

    require "google/ads/data_manager/v1"
require "googleauth"

credentials = Google::Auth::UserRefreshCredentials.new(
  client_id: client_id,
  client_secret: client_secret,
  refresh_token: refresh_token
)

client = Google::Ads::DataManager::V1::IngestionService::Client.new do |config|
  config.credentials = credentials
end

OAuth ऐप्लिकेशन की पुष्टि की प्रोसेस पूरी करना

Data Manager API के दायरे संवेदनशील होते हैं. इसलिए, Google Cloud के किसी भी ऐसे क्लाउड ऐप्लिकेशन को, जिसका इस्तेमाल बाहरी Google खातों से उपयोगकर्ता क्रेडेंशियल पाने के लिए किया जाता है, प्रोडक्शन में जाने से पहले Google OAuth की पुष्टि की प्रोसेस से गुज़रना होगा:

  • डेवलपमेंट: Google Cloud कंसोल में, ऑडियंस पेज पर ऐप्लिकेशन की पब्लिशिंग स्थिति टेस्टिंग पर सेट होने पर, सिर्फ़ तय किए गए टेस्ट खाते ही आपके ऐप्लिकेशन को अनुमति दे सकते हैं.
  • प्रोडक्शन: अपने ऐप्लिकेशन को बाहरी उपयोगकर्ताओं के लिए उपलब्ध कराने से पहले, पब्लिशिंग की स्थिति प्रोडक्शन में पर सेट करें और पुष्टि के लिए ऐप्लिकेशन सबमिट करें.
.

सेवा खातों का इस्तेमाल करके चलने वाले वर्कलोड के लिए, ऐप्लिकेशन की पुष्टि की ज़रूरत नहीं होती. इसके अलावा, कुछ स्थितियों में ऐप्लिकेशन की पुष्टि की ज़रूरत नहीं होती. जैसे, इंटरनल ऐप्लिकेशन. ज़्यादा जानकारी के लिए, ऐप्लिकेशन की पुष्टि कब ज़रूरी नहीं होती देखें.

अगर आपकी कंपनी को डेटा पार्टनर के तौर पर अनुमति मिली है, तो डेटा को लगातार इनजेस्ट करने के लिए, हर उपयोगकर्ता के OAuth टोकन मैनेज करने के बजाय, पार्टनर लिंक का इस्तेमाल किया जा सकता है.

पार्टनर लिंक की मदद से, विज्ञापन देने वाले लोग अपने खातों को Google Ads, Display &Video 360 या Google Ad Manager के यूज़र इंटरफ़ेस (यूआई) में, आपके डेटा पार्टनर खाते से कनेक्ट करते हैं. लिंक सेट अप होने के बाद, आपका ऐप्लिकेशन, ADC के ज़रिए अपने सेवा खाते के क्रेडेंशियल का इस्तेमाल करके, इनजेशन के अनुरोध भेजता है. इससे, लंबे समय तक मान्य रहने वाले उपयोगकर्ता रीफ़्रेश टोकन को स्टोर और मैनेज करने की ज़रूरत नहीं पड़ती.

प्रोडक्शन के लिए सबसे सही तरीके

प्रोडक्शन में माइग्रेट करते समय, ऑपरेशन से जुड़ी इन अहम बातों को ध्यान में रखें: