'gcloud app deploy' vs. 'appcfg.py' [geschlossen]

9

Ich war lange Zeit Benutzer von appcfg.py und ich habe sogar einige Bash-Skripte darauf gebaut.

  1. Sollten wir zu gcloud app deploy wechseln? Wird appcfg.py veraltet sein? Wenn ja, was ist die Zeitleiste?

  2. Warum gibt es keine Toleranzfrist für die Abwärtskompatibilität der Yaml-Datei? Wechseln zu gcloud app deploy Ich bekomme:

  

Das Feld [Anwendung] wird in der Datei [... / app.yaml] angegeben. Dies   Das Feld wird nicht von gcloud verwendet und muss entfernt werden. Projektname sollte   stattdessen wird entweder durch gcloud config set project MY_PROJECT angegeben   oder indem Sie das Flag --project für einzelne Befehlsausführungen setzen.

und

  

FEHLER: Das Feld [Version] wird in der Datei [... / app.yaml] angegeben. Dies   Das Feld wird nicht von gcloud verwendet und muss entfernt werden. Versionen sind   automatisch generiert, kann aber auch manuell angegeben werden   indem Sie das Flag --version auf einzelne Befehlsausführungen setzen.

Ich sage dies, wie dies mit dem Modul / Dienstfeld möglich war:

  

WARNUNG: Der "Modul" -Parameter in Anwendung .yaml-Dateien ist   veraltet. Bitte verwenden Sie stattdessen den Parameter "service".

  1. Wie laden Sie queue.yaml , dispatch.yaml und cron.yaml mit gcloud app deploy ?

  2. Was sind die Unterschiede zwischen den beiden Arten der Bereitstellung einer App?

    Ich bin an Vorbehalten interessiert & amp; Dinge wie:

  

FLAGS --promote Bewerben Sie die bereitgestellte Version, um den gesamten Datenverkehr zu erhalten. Standardmäßig true.

Das bedeutet w / gcloud app deploy Die App wird bereitgestellt und die neue Version wird als aktive Version festgelegt. Dies ist genau der umgekehrte Weg. appcfg.py strong> Dinge getan, wie Sie dort set_default_version aufrufen müssten, um eine Version als aktiv zu markieren.

Das wirft meine letzte Frage auf: Wenn ich mich dafür entscheide, es NICHT aktiv zu machen, indem ich entweder

benutze
  

$ gcloud config set app / promote_by_default false

oder

  

Verwenden Sie --no-promote zum Deaktivieren.

Muss ich den Standardwert erneut bereitstellen, damit ich ihn aktivieren kann?

    
eRadical 01.09.2016, 20:52
quelle

1 Antwort

7

Lange Rede kurzer Sinn:

  1. gcloud app deploy wird der bevorzugte Pfad für zukünftige Bereitstellungen sein und wird derzeit unterstützt. Sie haben etwa ein Jahr, nachdem wir den Übergang für veraltet erklärt haben.
  2. Bevor wir appcfg.py ablehnen, haben wir einen vollständigen Migrationsleitfaden mit allen Änderungen. Wir wollen keine vollständige Abwärtskompatibilität, da wir diese Chance nutzen, einige Warzen mit den alten Werkzeugen zu reparieren.
  3. Sie können gcloud app deploy cron.yaml usw. ausführen, um die alternativen YAML-Dateien bereitzustellen.
  4. Wir planen erneut, einen Migrationsleitfaden zu schreiben, bevor wir Sie zu den neuen Werkzeugen zwingen wollen.

Also ich denke, dass Sie sich darauf stürzen können, bis wir das appcfg tooling offiziell veraltet haben - gcloud app ist wirklich für mutige Entdecker gedacht, die das neueste und glänzendste für jetzt wollen.

    
Zachary Newman 01.09.2016, 21:18
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Berechnen von Pi in JavaScript mit Gregory-Leibniz-Serie