Zum Metadatenserver-Endpunkt v1 migrieren

Übersicht der Migration

Mithilfe der folgenden Schritte migrieren Sie zu v1.0:

  1. Identifizieren Sie die VM-Instanzen, die die verworfenen Metadatenserver-Endpunkte verwenden.

    Wenn Sie Google Kubernetes Engine-Cluster haben, müssen Sie die GKE-Knoten identifizieren, die den verworfenen Endpunkt verwenden.

  2. Ermitteln Sie auf den identifizierten VM-Instanzen oder Knoten die Prozesse, die die verworfenen Metadatenserver-Endpunkte verwenden.

    • Wenn der Prozess zu einer Anwendung gehört, die Sie nicht entwickelt haben, aktualisieren Sie die Anwendung, um den Metadatenserver-Endpunkt v1 verwenden zu können. Eine Liste der bekannten Anwendungen, die eine Aktualisierung erfordern, finden Sie unter Anwendungen, die eine Aktualisierung erfordern.
    • Wenn der Prozess zu einer von Ihnen entwickelten Anwendung gehört und mit Ihrem Code einer der alten Endpunkte aufgerufen wird, führen Sie die folgenden Schritte aus:
      1. Machen Sie sich mit den Unterschieden zwischen v1 und den verworfenen Metadatenserver-Endpunkten vertraut.
      2. Aktualisieren Sie Abfragen, um den Metadatenserver-Endpunkt v1 zu verwenden.
    • Wenn der Prozess zu einer von Ihnen entwickelten Anwendung gehört, mit Ihrem Code jedoch keine Anfragen an die Legacy-Endpunkte gestellt werden, können die Anfragen möglicherweise von SDKs oder anderen Abhängigkeiten stammen. Dieses Problem beheben Sie, wenn Sie alle SDKs und Abhängigkeiten aktualisieren, die von der Anwendung verwendet werden. Die Versionen der Google-Bibliotheken, die eine Aktualisierung erfordern, finden Sie unter Unterstützte Bibliotheksversionen.
  3. (Optional) Deaktivieren Sie die Metadatenserver-Endpunkte v0.1 und v1beta1.

    VM-Instanzen identifizieren

    Sie können Anfragen an zwei neue Endpunkte senden, um zu ermitteln, welche VM-Instanzen v0.1- und v1beta1-Endpunkte verwenden.

    Die Ausgabe aus der Abfrage dieser neuen Endpunkte gibt an, wie oft eine bestimmte VM-Instanz auf die verworfenen Endpunkte zugegriffen hat. Hinweis: Jedes Mal, wenn eine VM-Instanz gestoppt wird, wird der Zähler zurückgesetzt.

    Mit den folgenden Befehle ermitteln Sie, ob eine VM-Instanz auf die v0.1- und v1beta1-Endpunkte zugegriffen hat:

    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
    

    Im folgenden Beispiel für Python sehen Sie, wie Sie diese neuen Endpunkte programmatisch überwachen können:

    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)

    GKE-Knoten identifizieren

    Informationen zur Identifizierung der Knoten in Ihren Google Kubernetes Engine-Clustern, die die v0.1- und v1beta1-Endpunkte verwenden, finden Sie unter Arbeitslasten identifizieren, die die Legacy-Metadatenserver-Endpunkte verwenden.

    Prozesse identifizieren

    Nachdem Sie die VM-Instanzen ermittelt haben, die Anfragen an die verworfenen Metadatenserver-Endpunkte senden, können Sie die Prozesse auf diesen VM-Instanzen finden, von denen diese Anfragen stammen.

    Zum Identifizieren der Prozesse verwenden Sie Logging- oder Monitoring-Tools wie ngrep oder auditd.

    ngrep

    Sie können ngrep (Netzwerk-grep) verwenden, um Pakete zu erfassen und den Inhalt dieser Pakete zu filtern. Führen Sie den folgenden Befehl auf Ihrer VM-Instanz aus, um Paketinformationen für Prozesse zu erfassen, die Anfragen an die verworfenen Endpunkte senden:

    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
    

    Wenn Anfragen an die verworfenen Endpunkte gesendet werden, sieht die Ausgabe etwa so aus:

    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: */*....
    

    Die Ausgabe enthält die folgenden Informationen:

    • Die Stamm-URL: /computeMetadata/v1beta1/instance/id.
    • Der User-Agent, der für die Anfrage verwendet wird. In diesem Beispiel ist das curl/7.52.1.
    • Die IP-Adresse (Quell-IP-Adresse) und den Port für die VM-Instanz, von der die Anfrage stammt. In diesem Beispiel lautet die IP-Adresse 10.128.0.4 und der Port ist 41312.
    • Wenn der Prozess noch aktiv ist, können Sie sich die Port-Informationen ansehen, um die Prozess-ID zu ermitteln.

    Port-Informationen ansehen

    Mit dem folgenden Verfahren können Sie möglicherweise Prozesse mit ausstehenden HTTP GET-Anfragen identifizieren. Mit diesem Verfahren werden die Prozesse ermittelt, die sowohl mit den aktuellen als auch mit den verworfenen Metadatenendpunkten kommunizieren.

    Mit dem folgenden Befehl auf Ihrer VM-Instanz listen Sie die Sockets mit offenen Verbindungen zum Metadatenserver auf:

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

    Die Ausgabe sieht etwa so aus:

    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)
    

    In der Spalte NAME werden die Quell-IP-Adresse, die Ziel-IP-Adresse und die Ports angezeigt. Wenn dies nicht ausreicht, um einen Prozess zu identifizieren, können Sie den ps-Befehl verwenden, um weitere Informationen abzurufen.

    ps 798 805 809

    Die Ausgabe sieht etwa so aus:

    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 (nur Linux)

    Auditd ist ein Daemon, der Audit-Logs basierend auf einer Reihe von Regeln auf Festplatte schreiben kann. Durch die Einrichtung einer Regel für den Systemaufruf connect können Sie ermitteln, welcher Prozess die einzelnen Verbindungen zu den verworfenen Metadatenserver-Endpunkten herstellt.

    1. Führen Sie den folgenden Befehl auf Ihrer VM-Instanz aus, um eine Regel zum Prüfen von connect-Systemaufrufen einzurichten:

      sudo auditctl -a exit,always -F arch=b64 -S connect -k CONNECT
    2. Führen Sie den folgenden Befehl auf Ihrer VM-Instanz aus, um Verbindungen mit den verworfenen Endpunkten abzufragen:

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

      Die Ausgabe kann etwa so aussehen:

      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
      

      Die Ausgabe enthält die folgenden Informationen:

      • Den Prozesstitel: proctitle
      • Die Anfrage-URL curl metadata.goog/computeMetadata/v1beta1/instance/id
      • Den Speicherort der ausführbaren Datei: exe=/usr/bin/curl
      • Den Nutzer: uid=alice

      Nachdem Sie die Prozesse identifiziert haben, können Sie die Regel entfernen. Mit dem folgenden Befehl entfernen Sie die Regel:

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

    Unterschiede zwischen den Metadatenserver-Endpunkten v1beta1 und v1.0

    Der Metadatenserver v1 funktioniert etwas anders als der vorherige v1beta1-Server. Der neue Metadatenserver erfordert, dass alle Anfragen den Header Metadata-Flavor: Google enthalten, was darauf hinweist, dass die Anfrage dem Abrufen von Metadatenwerten dienen soll.

    Sie aktualisieren Ihre Anfragen mit diesem neuen Header. Eine Anfrage an das disks/-Attribut sieht jetzt beispielsweise so aus:

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

    Unterschiede zwischen den Metadatenserver-Endpunkten v0.1 und v1.0

    Im Allgemeinen unterscheiden sich die Metadatenserver-Endpunkte v0.1 in folgender Weise von den v1-Endpunkten:

    • Das Stammverzeichnis für die Abfrage des Metadatenserver-Endpunkts wurde von http://metadata.google.internal/0.1/meta-data/ in http://metadata.google.internal/computeMetadata/v1/ geändert.
    • v1-Metadatenserver-Anfragen müssen den Header Metadata-Flavor: Google enthalten. Eine Anfrage an das disks/-Attribut sieht jetzt beispielsweise so aus:

      curl "http://metadata.google.internal/computeMetadata/v1/instance/disks/" -H "Metadata-Flavor: Google"
    • Benutzerdefinierte Metadaten können sowohl auf Projekt- als auch auf Instanzebene abgefragt werden.

      Im Metadatenserver v0.1 befinden sich für das Attribut attributes/ sowohl die Instanz- als auch die Projektmetadatenwerte im selben Verzeichnis. Wenn ein Attribut sowohl Instanz- als auch Projektmetadatenwerte enthält, wird der Instanzmetadatenwert für einen bestimmten Schlüssel zurückgegeben.

      Bei v1-Abfragen muss die URL angeben, ob Instanz- oder Projektmetadaten angefordert werden. Um beispielsweise das Attribut sshKeys abzufragen, führen Sie einen oder beide der folgenden Schritte aus:

      Führen Sie für sshKeys, die für das Projekt festgelegt sind, den folgenden Befehl aus:

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

      Führen Sie für sshKeys, die für diese Instanz festgelegt sind, den folgenden Befehl aus:

      curl "http://metadata.google.internal/computeMetadata/v1/instance/attributes/sshKeys" -H "Metadata-Flavor: Google"
    • Einige Metadateneinträge in v0.1 geben JSON-Objekte zurück. Auf dem Metadatenserver v1 sind diese Metadateneinträge nach Verzeichnissen geordnet. Durch diese Eintragsanordnung können Sie bestimmte Indexeinträge und Werte für diese zuvor verschachtelten Felder abfragen. Weitere Informationen zum Abfragen einer Verzeichnisliste oder Zugreifen auf JSON-Objekte in v1 finden Sie unter Attribute als Verzeichniseinträge.

    Eine detailliertere Zuordnung der Metadatenserver-Endpunkte zwischen v0.1 und v1 finden Sie in den folgenden Tabellen.

    Instanzattribute

    Die folgenden Metadateneinträge werden in das instance/-Verzeichnis verschoben:

    v0.1-Stamm: http://metadata.google.internal/0.1/meta-data/
    v1-Stamm: http://metadata.google.internal/computeMetadata/v1
    Metadateneintrag Version URI (relativ zum Stamm) Beispielausgabe
    Beschreibung v0.1 description My instance description
    v1 instance/description
    Hostname v0.1 hostname my-instance.c.my-project.internal
    v1 instance/hostname
    Image v0.1 image projects/eip-images/global/images/debian-9-drawfork-v20180109
    v1 instance/image
    Maschinentyp v0.1 machine-type projects/12345/machineTypes/n1-standard-1
    v1 instance/machine-type
    Instanztags v0.1 tags ["cheese", "lettuce"]
    v1 instance/tags
    Zone v0.1 zone projects/12345/zones/us-central1-c
    v1 instance/zone

    Projektattribute

    Die folgenden Metadateneinträge werden in das project/-Verzeichnis verschoben:

    v0.1-Stamm: http://metadata.google.internal/0.1/meta-data/
    v1-Stamm: http://metadata.google.internal/computeMetadata/v1
    Metadateneintrag Version URI (relativ zum Stamm) Beispielausgabe
    Projekt-ID v0.1 project-id my-project
    v1 project/project-id
    Numerische Projekt-ID v0.1 numeric-project-id 12345
    v1 project/numeric-project-id

    Attribute, die verschoben werden

    Die folgenden Metadateneinträge werden an einen neuen Endpunkt verschoben:

    v0.1-Stamm: http://metadata.google.internal/0.1/meta-data/
    v1-Stamm: http://metadata.google.internal/computeMetadata/v1
    Metadateneintrag Version URI (relativ zum Stamm) Beispielausgabe
    Domain v0.1 domain c.my-project.internal
    v1 instance/hostname my-instance.c.my-project.internal

    Attribute, die umbenannt werden

    Die folgenden Metadateneinträge werden umbenannt:

    v0.1-Stamm: http://metadata.google.internal/0.1/meta-data/
    v1-Stamm: http://metadata.google.internal/computeMetadata/v1
    Metadateneintrag Version URI (relativ zum Stamm) Beispielausgabe
    Instanz-ID v0.1 instance-id 123456789
    v1 instance/id 123456789

    Attribute als Verzeichniseinträge

    Die folgenden Metadateneinträge gaben JSON-Objekte in v0.1 zurück und sind in v1 in Verzeichnissen angeordnet.

    Für diese Metadateneinträge können Sie eine der folgenden Methoden verwenden, um auf die Endpunkte zuzugreifen:

    v0.1-Stamm: http://metadata.google.internal/0.1/meta-data/
    v1-Stamm: http://metadata.google.internal/computeMetadata/v1
    Metadateneintrag Version URI (relativ zum Stamm) Beispielausgabe
    Laufwerke 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"}]
    Netzwerkschnittstellen 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":[]}]
    Dienstkontoinformationen (alle Dienstkonten) 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"]}}
    Dienstkontoinformationen (einzelnes Dienstkonto) 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"]}
    

    OAuth 2.0-Zugriffstokens abfragen

    Die folgenden Metadateneinträge geben OAuth2-Zugriffstokens zurück.

    v0.1-Stamm: http://metadata.google.internal/0.1/meta-data/
    v1-Stamm: http://metadata.google.internal/computeMetadata/v1
    Metadateneintrag Version URI (relativ zum Stamm) Beispielausgabe
    OAuth2-Token v0.1 (Methode 1)

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

    oder

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

    
    {"expires":1568854217,
    "oauth2_access_token":"ya29.c.KmyIB0i4tH1xLzKGrqeeK6TGWEW3b18Lcq...."}
    
    v0.1 (Methode 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"}

    Anwendungen, die eine Aktualisierung erfordern

    Um den Metadatenserver-Endpunkt v1 zu verwenden, aktualisieren Sie die folgenden Anwendungen auf die unterstützte Mindestversion oder eine höhere Version.

    Anwendung Unterstützte Mindestversion
    Facter (entiwckelt von Puppet) 3.14.5
    Stackdriver Monitoring-Agent 5.5.2-375

    Unterstützte Bibliotheksversionen

    Die Migration zum Metadatenserver-Endpunkt v1 hat auf manche Google-Bibliotheken keinerlei Auswirkungen. Wenn Sie jedoch eine der in der folgenden Tabelle aufgeführten Bibliotheken verwenden, ist ein Upgrade auf die unterstützte Mindestversion oder eine höhere Version erforderlich.

    Sprache Google-Bibliothek Unterstützte Mindestversion
    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