Convertir des backends en services

L'API Backend est obsolète depuis le 13 mars 2014 et sera supprimée le 28 février 2019. Les développeurs sont tenus de migrer toutes les instances backend vers les services. Dans le cas contraire, les instances ne seront plus gérables et cesseront de diffuser le trafic.

L'architecture App Engine d'origine repose sur une seule instance frontend et des instances backend facultatives. Si vous avez une application qui utilise des backends, vous souhaiterez peut-être convertir les backends en un format de service afin de tirer pleinement parti des fonctionnalités supplémentaires offertes par les services, comme la possibilité de créer des versions de backends.

App Engine exécute automatiquement un backend existant en tant que nouvelle version, autre que celle de base, du service par défaut. Les backends résidents se voient attribuer un scaling manuel, et les backends dynamiques bénéficient d'un scaling de base.

Vous pouvez convertir des instances backend en services nommés versionnés et dotés de classes d'instance et de type de scaling explicites. Vous devez remplacer le fichier backends.yaml d'origine par plusieurs fichiers .yaml comme indiqué ci-dessous.

Voici un fragment de fichier .yaml qui définit trois backends (memdb, worker et cmdline) :

backends:
- name: memdb
  class: B8
  instances: 5
- name: worker
  start: worker.app
  options: failfast
- name: cmdline
  options: dynamic

Pour convertir ces backends en services, créez un fichier .yaml distinct pour chaque service :

Dans memdb.yaml :

service: memdb
version: uno
instance_class: B8
manual_scaling:
  instances: 5

Dans worker.yaml :

service: worker
version: uno
# For failfast functionality, please use the ‘X-AppEngine-FailFast’ header on requests made to this service.
manual_scaling:
  instances: 1
handlers:
# If a service has an _ah/start handler, it should be listed first.
- url: /_ah/start
  script: worker.app

Notez que la définition d'origine du backend "worker" utilisait le tag start: pour lier le script worker.app au chemin _ah/start. Pour les services, cette liaison est définie en tant que gestionnaire avec le chemin _ah/start explicite. En outre, s'il existe plusieurs gestionnaires, le gestionnaire _ah/start doit être répertorié en premier.

Dans cmdline.yaml :

service: cmdline
version: uno
basic_scaling:
  max_instances: 1

Le SDK Python contient un script qui peut effectuer ces transformations à votre place. À partir de deux fichiers .yaml, un pour l'application et un pour ses backends, il crée de nouveaux fichiers .yaml définissant des services pour chaque backend. En partant de l'exemple de migration ci-dessus, supposons que le fichier d'origine définissant les trois backends s'appelle backends.yaml et que le fichier définissant l'application principale s'appelle app.yaml. Le script générerait trois nouveaux fichiers .yaml : memdb.yaml, worker.yaml et cmdline.yaml. Voici comment l'appeler :

[PATH_TO_SDK]/google-cloud-sdk/platform/google_appengine/backends_conversion.py backends.yaml app.yaml
Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Environnement standard App Engine pour Python