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 obsoletos del servidor de metadatos.

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

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

    • Si el proceso pertenece a una aplicación que no desarrollaste, actualiza la aplicación a fin de que use un extremo del servidor de metadatos v1. Si quieres obtener una lista de las aplicaciones más 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 el código llama a cualquiera de los extremos heredados, sigue los pasos que se indican a continuación:
      1. Consulta las diferencias entre v1 y los extremos obsoletos del servidor de metadatos.
      2. Actualiza las consultas a fin de que usen el extremo del servidor de metadatos v1.
    • Si el proceso pertenece a una aplicación que desarrollaste, pero el código no realiza solicitudes a ninguno de los extremos heredados, las pueden hacer los SDK o las otras dependencias. 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 v0.1 y v1beta1 del servidor de metadatos.

    Identifica las instancias de VM

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

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

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

        curl -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/legacy-endpoint-access/0.1
        curl -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/legacy-endpoint-access/v1beta1
        

    En el siguiente ejemplo de Python, se muestra cómo mirar de forma programática estos extremos nuevos:

    def wait_for_legacy_usage(callback):
            url = '{}/instance/legacy-endpoint-access'.format(METADATA_URL)
            last_etag = '0'
            counts = None
            while True:
                r = requests.get(
                    url,
                    params={
                        'last_etag': last_etag,
                        'recursive': True,
                        'wait_for_change': True
                    },
                    headers=METADATA_HEADERS)
                if r.status_code == 503:  # Metadata server unavailable
                    print('Metadata server unavailable. Sleeping for 1 second.')
                    time.sleep(1)
                    continue
                if r.status_code == 404:  # Feature not yet supported
                    print('Legacy endpoint access not supported. Sleeping for 1 hour.')
                    time.sleep(3600)
                    continue
                r.raise_for_status()
    
                last_etag = r.headers['etag']
                access_info = json.loads(r.text)
                if not counts:
                    counts = access_info
                if access_info != counts:
                    diff = {
                        ver: access_info[ver] - counts[ver] for ver in counts
                    }
                    counts = access_info
                    callback(diff)

    Identifica los nodos de GKE

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

    Identifica los procesos

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

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

    ngrep

    Puedes usar ngrep (grep de red) para recopilar paquetes y filtrar su contenido. Si quieres recopilar información de paquetes de los procesos que realizan solicitudes a los extremos obsoletos, ejecuta el siguiente comando en la 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 siguiente:

        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 de la instancia de VM en la 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 siguiente procedimiento, se pueden identificar los procesos con solicitudes HTTP GET pendientes. Con este procedimiento, se buscan 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 la 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
        

    auditd (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 siguiente comando en la instancia de VM:

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

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

      Tu 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
          

      En el resultado, se incluye la siguiente información:

      • 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 siguiente comando:

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

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

    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 valores de metadatos.

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

        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 los del v1 en los siguientes aspectos:

    • 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 como la siguiente:

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

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

      En las consultas de v1, la URL debe especificar si se solicitan metadatos de la instancia o del proyecto. Por ejemplo, a fin de consultar el atributo sshKeys, ejecuta uno o ambos de los siguientes comandos:

      Para las 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 objetos JSON. En el servidor de metadatos v1, estas entradas de metadatos se organizan por directorios. Esta organización de las 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 de v0.1 a v1, consulta las siguientes tablas.

    Atributos de la instancia

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

    Raíz v0.1: http://metadata.google.internal/0.1/meta-data/
    Raíz v1: 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/:

    Raíz v0.1: http://metadata.google.internal/0.1/meta-data/
    Raíz v1: 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:

    Raíz v0.1: http://metadata.google.internal/0.1/meta-data/
    Raíz v1: 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 a los que se les cambia el nombre

    Las entradas de metadatos siguientes cambian de nombre:

    Raíz v0.1: http://metadata.google.internal/0.1/meta-data/
    Raíz v1: 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 siguientes entradas de metadatos mostraron objetos JSON en v0.1 y están organizadas en directorios en v1.

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

    Raíz v0.1: http://metadata.google.internal/0.1/meta-data/
    Raíz v1: 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 (una sola 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.

    Raíz v0.1: http://metadata.google.internal/0.1/meta-data/
    Raíz v1: http://metadata.google.internal/computeMetadata/v1
    Entrada de metadatos Versión URI (en relación con la raíz) Resultado de ejemplo
    Token de OAuth 2.0 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 siguientes aplicaciones a la versión mínima compatible o a una versión posterior.

    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 enumeradas en la siguiente tabla, asegúrate de actualizar a la versión mínima compatible o a una versión posterior.

    Lenguaje Biblioteca de Google Versión mínima compatible
    Java com.google.api-client 1.18.0-rc
    Node.js dialogflow 0.6.0
    Node.js firebase-admin 8.2.0
    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 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 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