Migra al extremo del servidor de metadatos v1

Descripción general de la migración

Si quieres migrar a la versión 1.0, completa los pasos siguientes:

  1. Identifica las instancias de VM que usan los extremos del servidor de metadatos obsoleto.

    Si tienes clústeres de Google Kubernetes Engine, debes identificar los nodos de GKE que usan el extremo obsoleto.

  2. En los nodos o instancias de VM identificados, busca los procesos que usan los extremos del servidor de metadatos obsoletos.

    • Si el proceso pertenece a una aplicación que no desarrollaste, actualiza la aplicación a fin de usar un extremo del servidor de metadatos v1. Si quieres obtener una lista de las aplicaciones comunes que requieren una actualización, consulta las aplicaciones que requieren una actualización.
    • Si el proceso pertenece a una aplicación que desarrollaste y tu código llama a cualquiera de los extremos heredados, completa los pasos siguientes:
      1. Consulta las diferencias entre v1 y los extremos del servidor de metadatos obsoleto.
      2. Actualiza las consultas a fin de usar el extremo del servidor de metadatos v1.
    • Si el proceso pertenece a una aplicación que desarrollaste, pero tu código no realiza solicitudes a ninguno de los extremos heredados, los SDK o las otras dependencias pueden realizarlas. Para solucionarlo, actualiza todos los SDK y las dependencias que usa la aplicación. Si quieres ver las versiones de las bibliotecas de Google que requieren una actualización, consulta las versiones de biblioteca compatibles.
  3. De forma opcional, puedes inhabilitar los extremos del servidor de metadatos v0.1 y v1beta1.

    Identifica las instancias de VM

    Si quieres identificar qué instancias de VM usan extremos v0.1 y v1beta1, puedes realizar solicitudes a dos extremos nuevos.

    El resultado de la consulta de estos extremos nuevos te indica la cantidad de veces que una instancia de VM en particular accedió a los extremos obsoletos. Nota: Cada vez que se detiene una instancia de VM, el contador se restablece.

    Para ver si una instancia de VM accedió a los extremos v0.1 y v1beta1, ejecuta los comandos siguientes:

    curl -H "Metadata-Flavor: Google" computeMetadata/v1/instance/legacy-metadata-access/0.1
    curl -H "Metadata-Flavor: Google" computeMetadata/v1/instance/legacy-metadata-access/v1beta1
    

    Identifica los nodos de GKE

    Si quieres identificar los nodos de tus clústeres de Google Kubernetes Engine que usan los extremos v0.1 y v1beta1, consulta Identifica cargas de trabajo con los extremos del servidor de metadatos heredados.

    Identifica los procesos

    Una vez que identificaste las instancias de VM que realizan solicitudes a los extremos del servidor de metadatos obsoletos, puedes encontrar los procesos en estas instancias de VM que realizan estas solicitudes.

    Si quieres identificar los procesos, usa las herramientas de registro o supervisión como ngrep o auditd.

    ngrep

    Puedes usar ngrep (red grep) para recopilar paquetes y filtrar los contenidos de estos paquetes. Si quieres recopilar información de paquetes para los procesos que realizan solicitudes a los extremos obsoletos, ejecuta el comando siguiente en tu instancia de VM:

    sudo ngrep -l -q "v1beta1|0\.1/meta-data" tcp \
    and dst host 169.254.169.254 or metadata.google.internal \
    and dst port 80
    

    Si se realiza alguna solicitud a los extremos obsoletos, el resultado será similar al que figura a continuación:

    T 10.128.0.4:41312 -> 169.254.169.254:80 [AP]
    GET /computeMetadata/v1beta1/instance/id HTTP/1.1..Host: metadata.goog..User-Agent: curl/7.52.1..Accept: */*....
    

    El resultado contiene la información siguiente:

    • La URL raíz: /computeMetadata/v1beta1/instance/id
    • El usuario-agente que se usa para realizar la solicitud En este ejemplo, es curl/7.52.1.
    • La dirección IP (IP de origen) y el puerto para la instancia de VM en que se originó la solicitud. En este ejemplo, la dirección IP es 10.128.0.4 y el puerto 41312.
    • Si el proceso aún está activo, puedes revisar la información del puerto a fin de encontrar el ID del proceso.

    Revisa la información del puerto

    A través del procedimiento siguiente, se pueden identificar los procesos con solicitudes HTTP GET pendientes. Este procedimiento busca los procesos que se comunican con los extremos de metadatos actuales y obsoletos.

    Para mostrar los sockets con conexiones abiertas al servidor de metadatos, ejecuta el comando siguiente en tu instancia de VM:

    sudo lsof -n -P +c 0 -i @169.254.169.254

    El resultado se ve de la manera siguiente:

    COMMAND         PID USER   FD   TYPE     DEVICE SIZE/OFF NODE NAME
    google_network_ 798 root    7u  IPv4 1674967626      0t0  TCP 10.128.0.4:44876->169.254.169.254:80 (ESTABLISHED)
    google_accounts 805 root    5u  IPv4 1674980506      0t0  TCP 10.128.0.4:44878->169.254.169.254:80 (ESTABLISHED)
    google_clock_sk 809 root    5u  IPv4 1674982496      0t0  TCP 10.128.0.4:44880->169.254.169.254:80 (ESTABLISHED)
    google_clock_sk 809 root    6u  IPv4 1674914460      0t0  TCP 10.128.0.4:44874->169.254.169.254:80 (CLOSE_WAIT)
    

    La columna NAME muestra la IP de origen, la IP de destino y los puertos. Si esto no es suficiente para identificar un proceso, puedes usar el comando ps a fin de obtener más información.

    ps 798 805 809

    El resultado se ve de la manera siguiente:

    PID TTY      STAT   TIME COMMAND
    798 ?        Ss     9:07 /usr/bin/python /usr/bin/google_network_daemon
    805 ?        Ss    14:19 /usr/bin/python /usr/bin/google_accounts_daemon
    809 ?        Ss     4:33 /usr/bin/python /usr/bin/google_clock_skew_daemon
    

    auditoría (solo Linux)

    Auditd es un daemon que puede escribir registros de auditoría en el disco en función de un conjunto de reglas. Si configuras una regla para la llamada al sistema connect, puedes identificar qué proceso crea cada conexión a los extremos obsoletos del servidor de metadatos.

    1. Si quieres configurar una regla para auditar llamadas al sistema connect, ejecuta el comando siguiente en tu instancia de VM:

      sudo auditctl -a exit,always -F arch=b64 -S connect -k CONNECT
    2. Si quieres solicitar conexiones a los extremos obsoletos, ejecuta el comando siguiente en tu instancia de VM:

      sudo ausearch -m SOCKADDR -k CONNECT --interpret | grep -C 3 'computeMetadata/v1beta1\|0\.1/meta-data'

      El resultado podría parecerse al siguiente:

      type=PROCTITLE msg=audit(09/26/2019 22:20:21.498:847) : proctitle=curl metadata.goog/computeMetadata/v1beta1/instance/id
      type=SOCKADDR msg=audit(09/26/2019 22:20:21.498:847) : saddr={ fam=inet laddr=169.254.169.254 lport=80 }
      type=SYSCALL msg=audit(09/26/2019 22:20:21.498:847) : arch=x86_64 syscall=connect success=no exit=EINPROGRESS(Operation now in progress) a0=0x3 a1=0x7fffd965bd50 a2=0x10 a3=0x14856d3402026e items=0 ppid=27641 pid=28977 auid=alice uid=alice gid=alice euid=alice suid=alice fsuid=alice egid=alice sgid=alice fsgid=alice tty=pts9 ses=2828 comm=curl exe=/usr/bin/curl key=CONNECT
      

      El resultado contiene la información siguiente:

      • El título del proceso: proctitle
      • La solicitud url: curl metadata.goog/computeMetadata/v1beta1/instance/id
      • La ubicación del archivo ejecutable: exe=/usr/bin/curl
      • El usuario: uid=alice

      Una vez que identificaste los procesos, puedes quitar la regla. Para quitar la regla, ejecuta el comando siguiente:

      sudo auditctl -d exit,always -F arch=b64 -S connect -k CONNECT

    Diferencias entre los extremos del servidor de metadatos v1beta1 y v1.0

    El servidor de metadatos v1 tiene un funcionamiento un tanto distinto que el servidor v1beta1 anterior. El servidor de metadatos nuevo requiere que todas las solicitudes proporcionen el encabezado Metadata-Flavor: Google, que indica que la solicitud se realizó con la intención de recuperar los valores de metadatos.

    Actualiza tus solicitudes a fin de incluir este encabezado nuevo. Por ejemplo, una solicitud para el atributo disks/ ahora luce así:

    user@myinst:~$ curl "http://metadata.google.internal/computeMetadata/v1/instance/disks/" -H "Metadata-Flavor: Google"
    

    Diferencias entre los extremos del servidor de metadatos v0.1 y v1.0

    En general, los extremos del servidor de metadatos v0.1 difieren de v1 de las maneras siguientes:

    • La raíz que se usa para consultar el extremo del servidor de metadatos cambió de http://metadata.google.internal/0.1/meta-data/ a http://metadata.google.internal/computeMetadata/v1/.
    • Las solicitudes del servidor de metadatos v1 deben incluir el encabezado Metadata-Flavor: Google. Por ejemplo, una solicitud para el atributo disks/ ahora luce así:

      curl "http://metadata.google.internal/computeMetadata/v1/instance/disks/" -H "Metadata-Flavor: Google"
    • Los metadatos personalizados se pueden consultar en el nivel de proyecto y de instancia.

      En el servidor de metadatos v0.1, para la propiedad attributes/, los valores de metadatos de la instancia y del proyecto están en el mismo directorio. Si un atributo tiene valores de metadatos de instancia y de proyecto, se muestra el valor de metadatos de la instancia para una clave determinada.

      Para las consultas de v1, la URL debe especificar si se requiere la instancia o los metadatos del proyecto. Por ejemplo, si quieres consultar el atributo sshKeys, ejecuta uno o ambos de los valores siguientes:

      Para los sshKeys que se configuraron en el proyecto, ejecuta el comando siguiente:

      curl "http://metadata.google.internal/computeMetadata/v1/project/attributes/sshKeys" -H "Metadata-Flavor: Google"

      Para los sshKeys que se configuraron en esta instancia, ejecuta el comando siguiente:

      curl "http://metadata.google.internal/computeMetadata/v1/instance/attributes/sshKeys" -H "Metadata-Flavor: Google"
    • Algunas entradas de metadatos en v0.1 muestran los objetos JSON. En el servidor de metadatos v1, estas entradas de metadatos se organizan por directorios. Esta organización de entradas te permite consultar las entradas y los valores de índices específicos para estos campos anidados con anterioridad. Si quieres obtener más información sobre cómo consultar una lista de directorios o acceder a objetos JSON en v1, consulta Atributos como listas de directorios.

    Si quieres obtener una asignación más detallada de los extremos del servidor de metadatos v0.1 a v1, consulta las tablas siguientes.

    Atributos de la instancia

    Las entradas de metadatos siguientes se transfieren al directorio instance/:

    v0.1 raíz http://metadata.google.internal/0.1/meta-data/
    v1 raíz http://metadata.google.internal/computeMetadata/v1
    Entrada de metadatos Versión URI (relacionada con la raíz) Resultado de ejemplo
    Descripción v0.1 description My instance description
    v1 instance/description
    Nombre de host v0.1 hostname my-instance.c.my-project.internal
    v1 instance/hostname
    Imagen v0.1 image projects/eip-images/global/images/debian-9-drawfork-v20180109
    v1 instance/image
    Tipo de máquina v0.1 machine-type projects/12345/machineTypes/n1-standard-1
    v1 instance/machine-type
    Etiquetas de la instancia v0.1 tags ["cheese", "lettuce"]
    v1 instance/tags
    Zona v0.1 zone projects/12345/zones/us-central1-c
    v1 instance/zone

    Atributos del proyecto

    Las entradas de metadatos siguientes se transfieren al directorio project/:

    v0.1 raíz http://metadata.google.internal/0.1/meta-data/
    v1 raíz http://metadata.google.internal/computeMetadata/v1
    Entrada de metadatos Versión URI (en relación con la raíz) Resultado de ejemplo
    ID del proyecto v0.1 project-id my-project
    v1 project/project-id
    ID numérico del proyecto v0.1 numeric-project-id 12345
    v1 project/numeric-project-id

    Atributos que se transfieren

    Las entradas de metadatos siguientes se transfieren a un extremo nuevo:

    v0.1 raíz http://metadata.google.internal/0.1/meta-data/
    v1 raíz http://metadata.google.internal/computeMetadata/v1
    Entrada de metadatos Versión URI (en relación con la raíz) Resultado de ejemplo
    Dominio v0.1 domain c.my-project.internal
    v1 instance/hostname my-instance.c.my-project.internal

    Atributos que cambian se renombran

    Las entradas de metadatos siguientes cambian de nombre:

    v0.1 raíz http://metadata.google.internal/0.1/meta-data/
    v1 raíz http://metadata.google.internal/computeMetadata/v1
    Entrada de metadatos Versión URI (en relación con la raíz) Resultado de ejemplo
    ID de instancia v0.1 instance-id 123456789
    v1 instance/id 123456789

    Atributos como listas de directorios

    Las entradas de metadatos siguientes mostraron objetos JSON en v0.1 y están organizados en directorios en v1.

    Para estas entradas de metadatos, puedes usar cualquiera de los métodos siguientes a fin de acceder a los extremos:

    v0.1 raíz http://metadata.google.internal/0.1/meta-data/
    v1 raíz http://metadata.google.internal/computeMetadata/v1
    Entrada de metadatos Versión URI (en relación con la raíz) Resultado de ejemplo
    Discos v0.1 disks
    
    {"disks":[{
    "deviceName":"persistent-disk-0",
    "index":0,
    "mode":"READ_WRITE",
    "type":"PERSISTENT"}]}
    v1 instance/attached-disks/?recursive=true
    
    [{"deviceName": "persistent-disk-0",
    "index":0,
    "mode":"READ_WRITE",
    "type":"PERSISTENT"}]
    Interfaces de red v0.1 network
    
    {"networkInterface":
    [{"accessConfiguration":
    [{"externalIp":"35.194.6.47",
    "type":"ONE_TO_ONE_NAT"}],
    "ip":"10.128.0.4",
    "mac":"42:01:0a:80:00:04","mtu":1460,
    "network":"projects/12345/networks/default"}]}
    v1 instance/network-interfaces/?recursive=true
    
    [{"accessConfigs":
    [{"externalIp":"35.194.6.47",
    "type":"ONE_TO_ONE_NAT"}],
    "dnsServers":["169.254.169.254"],
    "forwardedIps":[],
    "gateway":"10.128.0.1",
    "ip":"10.128.0.4",
    "ipAliases [],
    "mac":"42:01:0a:80:00:04","mtu":1460,
    "network":"projects/12345/networks/default",
    "subnetmask":"255.255.240.0","targetInstanceIps":[]}]
    Información de la cuenta de servicio (todas las cuentas de servicio) v0.1 service-accounts
    
    {"serviceAccounts":
    [{"scopes":["https://www.googleapis.com/auth/devstorage.read_only"],
    "serviceAccount":"12345-compute@developer.gserviceaccount.com"}]}
    v1 instance/service-accounts/?recursive=true
    
    {"123451-compute@developer.gserviceaccount.com":
    {"aliases":["default"],
    "email":"123451-compute@developer.gserviceaccount.com",
    "scopes":["https://www.googleapis.com/auth/devstorage.read_only"]},
    "default":{"aliases":["default"],
    "email":"123451-compute@developer.gserviceaccount.com",
    "scopes":["https://www.googleapis.com/auth/devstorage.read_only"]}}
    Información de la cuenta de servicio (única cuenta de servicio) v0.1 service-accounts/<email|default>
    
    {"scopes":["https://www.googleapis.com/auth/devstorage.read_only"],
    "serviceAccount":"123451-compute@developer.gserviceaccount.com"}
    
    v1 instance/service-accounts/<email|default>/?recursive=true
    
    {"aliases":["default"],
    "email":"123451-compute@developer.gserviceaccount.com",
    "scopes":["https://www.googleapis.com/auth/devstorage.read_only"]}
    

    Consulta los tokens de acceso de OAuth 2.0

    Las entradas de metadatos siguientes muestran los tokens de acceso OAuth2.

    v0.1 raíz http://metadata.google.internal/0.1/meta-data/
    v1 raíz http://metadata.google.internal/computeMetadata/v1
    Entrada de metadatos Versión URI (en relación con la raíz) Resultado de ejemplo
    Token de OAuth2 v0.1 (método 1)

    auth-token?service_account=<email|default>&scope=scopeA,scopeB

    o

    auth_token?service_account=<email|default>&scope=scopeA,scopeB

    
    {"expires":1568854217,
    "oauth2_access_token":"ya29.c.KmyIB0i4tH1xLzKGrqeeK6TGWEW3b18Lcq...."}
    
    v0.1 (método 2) service-accounts/<email|default>/acquire
    
    {"accessToken":"ya29.c.KmyIB0i4tH1xLNzKGrqeeK6TGWEW3b18Lcq.....",
    "expiresAt":1568854217,"expiresIn":2022}
    v1 instance/service-accounts/<email|default>/token
    
    {"access_token":"ya29.c.KmyIB0i4tH1xLNzKGrqeeK6TGWEW3b18Lcq....",
    "expires_in":2022,"token_type":"Bearer"}

    Aplicaciones que requieren una actualización

    Para usar el extremo del servidor de metadatos v1, actualiza las aplicaciones siguientes a la versión mínima compatible o a una versión superior.

    Aplicación Versión mínima compatible
    Facter (desarrollado por Puppet) 3.14.5
    Agente de Stackdriver Monitoring 5.5.2-375

    Versiones de biblioteca compatibles

    Algunas bibliotecas de Google no se ven afectadas por la migración al extremo del servidor de metadatos v1. Sin embargo, si usas alguna de las bibliotecas que se enumeran en la tabla siguiente, asegúrate de actualizar a la versión mínima compatible o una versión superior.

    Idioma Biblioteca de Google Versión mínima compatible
    Java com.google.api-client 1.18.0-rc
    Node.js google-cloud/debug-agent 3.0.0
    Node.js google-cloud/profiler 0.2.0
    Node.js google-cloud/trace-agent 2.11.0
    Node.js gcp-metadata 0.5.0
    Node.js gcs-resumable-upload 0.13.0
    Node.js googleapis 27.0.0
    Node.js google-auth-library 1.3.0
    Node.js google-cloud/bigquery 2.0.0
    Node.js google-cloud/bigquery-data-transfer 0.4.0
    Node.js google-cloud/bigtable 0.15.0
    Node.js google-cloud/cloud-container 0.3.0
    Node.js google-cloud/compute 0.11.0
    Node.js google-cloud/datastore 2.0.0
    Node.js dialogflow 0.6.0
    Node.js google-cloud/dlp 0.8.0
    Node.js google-cloud/dns 0.8.0
    Node.js google-cloud/error-reporting 0.5.0
    Node.js google-cloud/firestore 0.16.1
    Node.js google-cloud/language 2.0.0
    Node.js google-cloud/logging-bunyan 0.9.0
    Node.js google-cloud/logging 2.0.0
    Node.js google-cloud/logging-winston 0.10.0
    Node.js google-cloud/monitoring 0.6.0
    Node.js google-cloud/os-login 0.3.0
    Node.js google-cloud/pubsub 0.20.0
    Node.js google-cloud/redis 0.2.0
    Node.js google-cloud/resource 0.9.0
    Node.js google-cloud/spanner 2.0.0
    Node.js google-cloud/speech 2.0.0
    Node.js google-cloud/storage 2.0.0
    Node.js google-cloud/tasks 0.2.0
    Node.js google-cloud/text-to-speech 0.3.0
    Node.js google-cloud/translate 2.0.0
    Node.js google-cloud/vision 0.21.0
    Node.js google-cloud/profiler 0.2.0
    Node.js google-cloud/trace-agent 2.11.0
    Node.js google-gax 0.17.0
    Node.js gce-images 1.0.0
    Node.js gcp-metadata 0.5.0
    Node.js gcs-resumable-upload 0.13.0
    Node.js googleapis 27.0.0
    Node.js google-auth-library 1.3.0
    Node.js google-cloud/bigquery 2.0.0
    Node.js google-cloud/bigquery-data-transfer 0.4.0
    Node.js google-cloud/bigtable 0.15.0
    Node.js google-cloud/cloud-container 0.3.0
    Node.js google-cloud/common 0.18.0
    Node.js google-cloud/common-grpc 0.7.0
    Node.js google-cloud/compute 0.11.0
    Node.js google-cloud/datastore 2.0.0
    Node.js dialogflow 0.6.0
    Node.js google-cloud/dlp 0.8.0
    Node.js google-cloud/dns 0.8.0
    Node.js google-cloud/error-reporting 0.5.0
    Node.js google-cloud/firestore 0.16.1
    Node.js google-cloud/language 2.0.0
    Node.js google-cloud/logging 2.0.0
    Node.js google-cloud/logging-bunyan 0.9.0
    Node.js google-cloud/logging-winston 0.10.0
    Node.js google-cloud/monitoring 0.6.0
    Node.js google-cloud/os-login 0.3.0
    Node.js googleapis/nodejs-pubsub 0.20.0
    Node.js google-cloud/redis 0.2.0
    Node.js google-cloud/resource 0.9.0
    Node.js google-cloud/spanner 2.0.0
    Node.js google-cloud/speech 2.0.0
    Node.js google-cloud/storage 2.0.0
    Node.js google-cloud/tasks 0.2.0
    Node.js google-cloud/text-to-speech 0.3.0
    Node.js google-cloud/translate 2.0.0
    Node.js google-cloud/video-intelligence 1.3.0
    Node.js google-cloud/vision 0.21.0
    PHP google-cloud/video-intelligence 1.3.3
    Python oauth2client 2.0.0
    Python google-api-python-client 1.6.0
    Python googleapis/google-cloud-python 0.10.0
    Python google-cloud-happybase 0.20.0
    Ruby gcloud 0.11.1
    Ruby google-api-client 0.8.6
¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Documentación de Compute Engine