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

इस गाइड की मदद से, 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 IAM की अनुमतियां: सेवा खाते को उस Google Cloud प्रोजेक्ट में Service Usage Consumer की भूमिका (roles/serviceusage.serviceUsageConsumer) दें जिसमें 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 एनवायरमेंट वैरिएबल का इस्तेमाल करके, इसे एडीसी को दें.

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

सेट 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 IAM की अनुमतियां: सेवा खाते को उस Google Cloud प्रोजेक्ट में Service Usage Consumer की भूमिका (roles/serviceusage.serviceUsageConsumer) दें जिसमें Data Manager API चालू है.

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

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

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

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

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

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

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

  1. ऑफ़लाइन ऐक्सेस का अनुरोध करना: उपयोगकर्ताओं को Google की OAuth सहमति वाली स्क्रीन पर भेजें. इस स्क्रीन पर, access_type=offline और prompt=consent के साथ https://www.googleapis.com/auth/datamanager स्कोप का अनुरोध किया जाता है. आपका सर्वर, ऑथराइज़ेशन कोड को ऐक्सेस टोकन और 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();

    ऐप पर जाएं

    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 खातों से उपयोगकर्ता के क्रेडेंशियल पाने के लिए इस्तेमाल किए जाने वाले किसी भी Google Cloud ऐप्लिकेशन को प्रोडक्शन में जाने से पहले, Google OAuth की पुष्टि की प्रक्रिया से गुज़रना होगा:

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

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

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

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

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

प्रोडक्शन पर स्विच करते समय, इन मुख्य बातों का ध्यान रखें: