esegui il deployment del backend dell'API

Questa pagina spiega come eseguire il deployment del codice backend dell'API e Extensible Service Proxy (ESP) a Google Kubernetes Engine, Compute Engine e App Engine flessibile completamente gestito di Google Cloud.

Anche se i passaggi di deployment variano a seconda della piattaforma che ospita l'API, c'è sempre un passaggio in cui fornire a ESP nome servizio e un'opzione che configura ESP in modo che utilizzi l'ultima versione di cui è stato eseguito il deployment Configurazione del servizio Cloud Endpoints. Con queste informazioni, l'ESP può ottenere la configurazione degli endpoint della tua API, che consente all'ESP di eseguire il proxy delle richieste e delle risposte in modo che gli endpoint possano gestire la tua API.

Prerequisiti

Per iniziare, questa pagina presuppone che tu abbia:

Preparazione per il deployment

App Engine

Con l'aggiunta di un piccolo passaggio di configurazione (descritto nel passaggi successivi), eseguendo il deployment dell'API in modo che sia gestita Endpoints è la stessa cosa del deployment di qualsiasi applicazione nell'ambiente flessibile di App Engine. Segui la documentazione di App Engine per:

Per eseguire il deployment dell'API in App Engine, utilizza gcloud app deploy . Questo comando crea automaticamente un'immagine container utilizzando Container Builder e poi il deployment dell'immagine nel tuo ambiente flessibile di App Engine.

Prima del deployment:

Compute Engine

Affinché Endpoints possa gestire la tua API, devi installare e configurare ESP, nonché il codice del server di backend per la tua API. Devi di installare Docker sulla tua istanza VM di Compute Engine, eseguire l'immagine Docker ESP liberamente disponibile Container Registry.

Prima del deployment:

Di seguito vengono descritti i passaggi generali da eseguire prima di eseguire il deployment di API ed ESP su Compute Engine. Nel in generale, puoi fare tutto i passaggi su cui normalmente eseguire il codice del server di backend in Compute Engine.

  1. Crea, configura e avvia l'istanza VM. Consulta le Documentazione di Compute Engine.
  2. Installa Docker Enterprise Edition (EE) o Docker Community Edition (CE) su dell'istanza VM. Consulta Installa Docker.
  3. Crea un container Docker per il codice del server di backend. Consulta Documentazione di Cloud Build.
  4. Esegui il push del container Container Registry o un altro registro.
  5. Assicurati di riuscire a:

GKE

Quando crei un cluster nella console Google Cloud, per impostazione predefinita Gli ambiti OAuth concessi all'account di servizio del cluster includono ambiti richiesti da Endpoints:

  • Controllo servizio: abilitato
  • Gestione del servizio: sola lettura

Quando crei un cluster utilizzando il comando gcloud container clusters create o utilizzando un di configurazione di terze parti, assicurati di specificare i seguenti ambiti:

  • "https://www.googleapis.com/auth/servicecontrol"
  • "https://www.googleapis.com/auth/service.management.readonly"

Per ulteriori informazioni, consulta Che cosa sono gli ambiti di accesso?

Prima del deployment:

Con l'aggiunta di una piccola sezione al Manifest del deployment file, puoi eseguire l'immagine Docker ESP sui cluster di container insieme ai tuoi per applicazioni containerizzate. Di seguito vengono descritti nel dettaglio i passaggi da eseguire prima di poter eseguire il deployment dell'API con ESP con GKE. In genere, esegui tutti i passaggi che abitualmente eseguire il codice del tuo server di backend su GKE.

  1. Esegui il deployment dell'applicazione containerizzata nei cluster di container. I passaggi generali descritti nella documentazione di GKE sono:
    1. Pacchettizza la tua app in un'immagine Docker.
    2. Carica l'immagine in un registry.
    3. Crea un cluster di container.
    4. Esegui il deployment dell'app nel cluster.
    5. Esponi la tua app su internet.
  2. Assicurati di poter:
    • Avvia il server della tua API.
    • Invia richieste alla tua API.

Deployment di API ed ESP

App Engine

Per eseguire il deployment dell'API e di ESP in App Engine:

  1. Ottieni lo nome servizio della tua API. Si tratta del nome che hai specificato nel Campo host del documento OpenAPI.
  2. Modifica il file app.yaml e aggiungi una sezione denominata endpoints_api_service che contiene il nome del servizio. Puoi usa il file app.yaml del tutorial come modello:
    Java
    endpoints_api_service:
  # The following values are to be replaced by information from the output of
  # 'gcloud endpoints services deploy openapi-appengine.yaml' command.
  name: ENDPOINTS-SERVICE-NAME
  rollout_strategy: managed
    di Gemini Advanced.
    Python
    endpoints_api_service:
  # The following values are to be replaced by information from the output of
  # 'gcloud endpoints services deploy openapi-appengine.yaml' command.
  name: ENDPOINTS-SERVICE-NAME
  rollout_strategy: managed
    di Gemini Advanced.
    Vai
    endpoints_api_service:
  # The following values are to be replaced by information from the output of
  # 'gcloud endpoints services deploy openapi-appengine.yaml' command.
  name: ENDPOINTS-SERVICE-NAME
  rollout_strategy: managed
    PHP
    endpoints_api_service:
  # The following values are to be replaced by information from the output of
  # 'gcloud endpoints services deploy openapi-appengine.yaml' command. If you have
  # previously run the deploy command, you can list your existing configuration
  # ids using the 'configs list' command as follows:
  #
  #     gcloud endpoints configs list --service=YOUR-PROJECT-ID.appspot.com
  #
  name: ENDPOINTS-SERVICE-NAME
  rollout_strategy: managed
    di Gemini Advanced.
    Ruby
    endpoints_api_service:
  # The following values are to be replaced by information from the output of
  # 'gcloud endpoints services deploy openapi-appengine.yaml' command.
  name: ENDPOINTS-SERVICE-NAME
  rollout_strategy: managed
    di Gemini Advanced.
    NodeJS
    endpoints_api_service:
  # The following values are to be replaced by information from the output of
  # 'gcloud endpoints services deploy openapi-appengine.yaml' command.
  name: ENDPOINTS-SERVICE-NAME
  rollout_strategy: managed

    Sostituisci ENDPOINTS-SERVICE-NAME con il nome del servizio dell'API. Ad esempio: 

    endpoints_api_service:
  name: example-project-12345.appspot.com
  rollout_strategy: managed

    L'opzione rollout_strategy: managed configura ESP in modo da utilizzare la configurazione del servizio di cui è stato eseguito il deployment più recente. Quando specifichi questa opzione, fino a 5 minuti dopo aver eseguito il deployment di una nuova configurazione del servizio, ESP rileva la modifica e inizia a utilizzarla automaticamente. Ti consigliamo di specificare questa opzione anziché un ID configurazione specifico da utilizzare per ESP.

    Se la tua applicazione è basata su microservizi, devi includere la sezione endpoints_api_service in ogni file app.yaml.

  3. Salva i file app.yaml.
  4. Esegui il deployment del codice di backend e di ESP in App Engine: 
    gcloud app deploy

Poiché hai aggiunto la sezione endpoints_api_service al app.yaml file, il comando gcloud app deploy esegue il deployment e configura ESP in un contenitore separato rispetto al tuo ambiente flessibile App Engine. Tutto il traffico delle richieste viene instradato tramite ESP, ed è proxy richieste e risposte da e verso il container che esegue il codice del server di backend.

Se devi configurare ESP in modo che utilizzi un ID di configurazione specifico:

  1. Nella sezione endpoints_api_service del file app.yaml, aggiungi il campo config_id e impostalo su un valore specifico ID di configurazione.
  2. Rimuovi rollout_strategy: managed o imposta rollout_strategy a fixed. fixed configura ESP in modo che utilizzi la configurazione del servizio specificato in config_id.
  3. Esegui di nuovo il deployment di API ed ESP: gcloud app deploy

Ti consigliamo di non mantenere ESP configurato in modo da utilizzare una specifica da molto tempo perché, se esegui il deployment di un servizio aggiornato, devi riavviare ESP per utilizzare la nuova configurazione.

Per rimuovere l'ID configurazione specifico:

  1. Rimuovi l'opzione config_id dal file app.yaml.
  2. Aggiungi l'opzione rollout_strategy: managed.
  3. Esegui il comando gcloud app deploy

Quando utilizzi l'opzione rollout_strategy: managed, non includere config_id: YOUR_SERVICE_CONFIG_ID nel file app.yaml. In questo caso, gcloud app deploy non riesce con il seguente errore:

config_id is forbidden when rollout_strategy is set to "managed".

Quando esegui il deployment dell'API nell'ambiente flessibile di App Engine per la prima volta, potrebbe verificarsi un ritardo perché la macchina virtuale (VM) e altri dell'infrastruttura. Per ulteriori informazioni, vedi Garantire il corretto deployment in App Engine documentazione.

Compute Engine

Per eseguire il deployment dell'API con ESP in Compute Engine con Docker:

  1. Connetterti alla tua istanza VM. Sostituisci INSTANCE_NAME con il nome dell'istanza VM. 
    gcloud compute ssh INSTANCE_NAME
  2. Crea la tua rete di contenitori denominata esp_net: 
    sudo docker network create --driver bridge esp_net
  3. Esegui un'istanza dell'immagine del codice del server di backend e connettila alla rete del container esp_net: 
    sudo docker run \
    --detach \
    --name=YOUR_API_CONTAINER_NAME \
    --net=esp_net \
    gcr.io/YOUR_PROJECT_ID/YOUR_IMAGE:1.0
    • Sostituisci YOUR_API_CONTAINER_NAME con il nome del tuo containerizzato.
    • Sostituisci YOUR_PROJECT_ID con il progetto Google Cloud ID utilizzato quando hai inviato l'immagine.
    • Sostituisci YOUR_IMAGE con il nome della tua immagine.
  4. Recupera il nome del servizio della tua API. Si tratta del nome che hai specificato nel Campo host del documento OpenAPI.
  5. Esegui un'istanza dell'immagine Docker di ESP: 
    sudo docker run \
    --name=esp \
    --detach \
    --publish=80:8080 \
    --net=esp_net \
    gcr.io/endpoints-release/endpoints-runtime:1 \
    --service=SERVICE_NAME \
    --rollout_strategy=managed \
    --backend=YOUR_API_CONTAINER_NAME:8080
    • Sostituisci SERVICE_NAME con il nome del servizio.
    • Sostituisci YOUR_API_CONTAINER_NAME con il nome dell'API containerizzato.

    Opzione --rollout_strategy=managed configura ESP in modo che utilizzi l'ultima configurazione del servizio di cui è stato eseguito il deployment. Quando specificare questa opzione, fino a 5 minuti dopo il deployment di un nuovo servizio configurazione, ESP rileva la modifica e inizia automaticamente a utilizzarla. Me consigliamo di specificare questa opzione anziché un ID configurazione specifico per ESP.

Se devi configurare ESP in modo che utilizzi un ID di configurazione specifico:

  1. Includi l'opzione --version e impostala su un ID configurazione specifico.
  2. Rimuovi l'opzione --rollout_strategy=managed o imposta --rollout_strategy a fixed. fixed configura ESP in modo che utilizzi la configurazione del servizio specificato in --version.
  3. Esegui di nuovo il comando docker run.

Se specifichi sia --rollout_strategy=managed sia --version, ESP inizia con la configurazione che hai specificato in --version, ma poi viene eseguito in modalità gestita e ottiene la configurazione più recente.

Ti consigliamo di non mantenere ESP configurato in modo da utilizzare una specifica da molto tempo perché, se esegui il deployment di un servizio aggiornato, devi riavviare ESP per utilizzare la nuova configurazione.

Per rimuovere l'ID configurazione specifico:

  1. Nei flag ESP per docker run, rimuovi l'opzione --version.
  2. Aggiungi l'opzione --rollout_strategy=managed.
  3. Esegui il comando docker run per riavviare ESP.

Vedi startup ESP opzioni per l'elenco completo delle opzioni che puoi specificare all'avvio ESP.

GKE

Per eseguire il deployment di ESP in GKE:

  1. Ottieni il nome del servizio di l'API (il nome specificato nel campo host del documento OpenAPI).
  2. Apri il file manifest del deployment (denominato deployment.yaml) e aggiungi quanto segue al file dei container: 
    containers:
- name: esp
  image: gcr.io/endpoints-release/endpoints-runtime:1
  args: [
    "--http_port=8081",
    "--backend=127.0.0.1:8080",
    "--service=SERVICE_NAME",
    "--rollout_strategy=managed"
  ]

    Sostituisci SERVICE_NAME con il nome del servizio dell'API.

    L'opzione --rollout_strategy=managed" configura ESP in modo che utilizzi la configurazione del servizio di cui è stato eseguito il deployment più recente. Quando specificare questa opzione, fino a 5 minuti dopo il deployment di un nuovo servizio configurazione, ESP rileva la modifica e inizia automaticamente a utilizzarla. Me consigliamo di specificare questa opzione anziché un ID configurazione specifico per ESP.

  3. Avvia il servizio Kubernetes utilizzando Comando kubectl create: 
    kubectl create -f deployment.yaml

Se devi configurare ESP per utilizzare un ID configurazione specifico:

  1. Nel file manifest di deployment, aggiungi l'opzione --version e impostala su un ID configurazione specifico.
  2. Rimuovi --rollout_strategy=managed o imposta --rollout_strategy a fixed. fixed configura ESP in modo che utilizzi la configurazione del servizio specificato in --version.
  3. Avvia il servizio Kubernetes: kubectl create -f deployment.yaml

Se specifichi sia --rollout_strategy=managed sia --version, ESP inizia con la configurazione da te specificato in --version, ma che poi viene eseguito in modalità gestita e ottiene la configurazione più recente.

Ti consigliamo di non mantenere ESP configurato in modo da utilizzare un un ID configurazione specifico per molto tempo, perché se esegui il deployment di un servizio aggiornato devi riavviare ESP per utilizzare la nuova configurazione.

Per rimuovere l'ID configurazione specifico:

  1. Nel file manifest di Deployment, rimuovi l'opzione --version .
  2. Aggiungi --rollout_strategy=managed.
  3. Avvia il servizio Kubernetes: kubectl create -f deployment.yaml

Consulta le opzioni di avvio di ESP per un elenco completo delle opzioni che puoi specificare all'avvio di ESP.

monitora l'attività dell'API

Dopo aver eseguito il deployment dell'ESP e del backend dell'API, puoi utilizzare strumenti come curl o Postman per inviare richieste all'API. Se non ricevi un esito positivo risposta, consulta Risoluzione degli errori di risposta.

Dopo aver inviato alcune richieste, puoi:

Passaggi successivi