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

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

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

सेट GOOGLE_APPLICATION_CREDENTIALS

Workload Identity Federation क्रेडेंशियल कॉन्फ़िगरेशन फ़ाइल या सेवा खाते की कुंजी फ़ाइल के पूरे पाथ पर GOOGLE_APPLICATION_CREDENTIALS एनवायरमेंट वैरिएबल सेट करें. इससे क्लाइंट लाइब्रेरी, 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 के साथ रॉ एचटीटीपी अनुरोध करती है, तो 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 अनुमतियां: सेवा खाते को Service Usage Consumer की भूमिका (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. डेस्टिनेशन खाते का ऐक्सेस: सेवा खाते को अपने डेस्टिनेशन खातों का ज़रूरी ऐक्सेस दें. सिलसिलेवार निर्देशों के लिए, खाते का ऐक्सेस सेट अप करना लेख पढ़ें.

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

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

इस आर्किटेक्चर में, ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल इस्तेमाल करने के बजाय, 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 ऐप्लिकेशन की पुष्टि की प्रोसेस पूरी करना

https://www.googleapis.com/auth/datamanager एक संवेदनशील स्कोप है. इसलिए, बाहरी Google खातों से उपयोगकर्ता के क्रेडेंशियल पाने के लिए इस्तेमाल किए जाने वाले किसी भी Google Cloud ऐप्लिकेशन को प्रोडक्शन में जाने से पहले, Google OAuth की पुष्टि करानी होगी:

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

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

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

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

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

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