Cet article est un portage de mon blog personnel Practical Cloud Python --SERVERLESS FRAMEWORK & How to use PYTHON environment variables vers Qiita. Merci d'avoir visité Practical Cloud Python.
Abstract
Explique comment gérer les variables d'environnement qui peuvent être appréciées par la gestion de la scène et le codage.
La source de l'exemple est ouverte au public, veuillez donc consulter ici un exemple de mise en œuvre.
https://github.com/hassaku63/sls-env-example
Il a une configuration de Lambda (planifié) -> SQS-> Lambda (consommateur de file d'attente).
Les packages et plug-ins suivants sont utilisés.
Serverless Framework
Python
L'exemple de source est le code qui est censé être publié sur Slack. Le jeton et le nom du canal sont des informations confidentielles, ils sont donc décrits dans .env.
La structure sans serveur utilise le plug-in Serverless Dotenv pour inclure la définition du fichier .env dans provider.environment lors de l'empaquetage de déploiement.
Le plugin Dotenv charge automatiquement un fichier .env suffixé avec le nom de l'étape spécifiée. Par exemple, à l'étape de développement, chargez .env.dev comme définition de la variable d'environnement (voir la section sur la résolution automatique des noms de fichiers Env). Utilisez cette fonction pour les paramètres qui modifient le jeton API, etc. pour chaque étape.
Il est également déclaré dans la variable d'environnement pour gérer les noms de ressources de SQS et DynamoDB. Cela est dû au fait que les noms des ressources de la file d'attente et de la table sont requis lors de l'utilisation du client boto3 à partir du code.
https://gist.github.com/hassaku63/0e4e61db60bd48b5d86459ceabb9dd34
provider:
name: aws
runtime: python3.8
profile: ${opt:profile, default}
stage: ${opt:stage, dev}
region: ${opt:region, us-east-1}
timeout: 30
environment:
# To tell lambda function to AWS AccountId by use pseudo-parameters plugin.
# AccountId is used to construct SQS Queue URL
AWS_ACCOUNT_ID: '#{AWS::AccountId}'
# MY_QUEUE_NAME is used to construct Queue URL in lambda.
# And also convenient to reference resource ARN in IAM Policy statement
MY_QUEUE_NAME: ${self:service}-my-queue-${self:provider.stage}
La partie marquée comme $ {self: service} -my-queue- $ {self: provider.stage} est le nom de la file d'attente utilisée dans cette source. Les noms de service et d'étape sont inclus pour garantir l'unicité des noms de ressources lors de l'utilisation de plusieurs étapes de déploiement.
Lors de la mise en file d'attente de Python vers SQS, vous devez spécifier QueueUrl comme identificateur de ressource cible. Pour assembler QueueUrl, vous avez besoin de trois éléments: ID de compte AWS, région AWS et QueueName. Puisque nous voulons pouvoir y faire référence dans Lambda, nous les déclarons dans des variables d'environnement (notez que seules les régions doivent être définies par nous-mêmes car Lambda les définit automatiquement comme variables d'environnement par défaut lors de l'exécution. il n'y a pas).
Il est question de savoir si les variables d'environnement doivent être écrites en .env ou serverless.yml, mais je pense que vous devriez juger s'il s'agit d'informations que vous voulez garder secrètes. Si le nombre de variables d'environnement devient trop grand et qu'il devient redondant, il est préférable de ne sélectionner que celles qui ne sont pas vraiment des variables d'environnement et de les déclarer comme variables d'environnement. S'il y a des parties qui ne sont pas essentielles (telles que des sous-chaînes qui font partie du nom de la ressource), je pense que ce serait une bonne idée de les définir dans la section personnalisée.
Si vous souhaitez gérer des variables d'environnement à partir de Python, vous devez utiliser os.environ. Cependant, il n'y a aucun moyen de remarquer le nom de la variable Typo lors du codage, car l'auto-complétion IDE ne fonctionne pas avec cette écriture. Ce n'est pas une bonne expérience de développement de remarquer une mauvaise saisie des variables d'environnement jusqu'à ce que vous les déployez. En outre, utiliser os.environ à chaque fois que le nombre de gestionnaires Lambda augmente est une violation de DRY.
Pour éviter cela, chargez des variables d'environnement et créez settings.py pour les définir en tant que constantes Python. Tout le code Python doit lire les variables d'environnement de ce module. Cela vous permettra de profiter de l'auto-complétion IDE tout en préservant DRY et de réduire la possibilité de faute de frappe.
https://gist.github.com/hassaku63/0e971fb0823aea561f33db880d0269e4
"""
Declare all environment variables defined in .env.<stage-name> and serverless.yml as python variables.
If you would like to use environment variables in your code, you import this module then reference as constants of python variable.
By use this technique, you are able to use IDE auto-completion effectively when you writing python code.
It is useful to reduce miss-typing of environment variables.
"""
import os
import pathlib
import json
import dotenv
project_root_dir = pathlib.Path(__file__).parent / '../'
dotenv.load_dotenv()
MYAPP_STAGE_NAME = os.environ.get('MYAPP_STAGE_NAME')
stage_env_path = project_root_dir / f'.env.{MYAPP_STAGE_NAME}'
dotenv.load_dotenv(stage_env_path.resolve())
# Slack
SLACK_BOT_TOKEN = os.environ.get('SLACK_BOT_TOKEN')
SLACK_CHANNEL = os.environ.get('SLACK_CHANNEL')
# AWS
AWS_ACCOUNT_ID = os.environ.get('AWS_ACCOUNT_ID')
# Notice: You don't need to define AWS_REGION in .env and serverless.yml
# because of lambda runtime automatically set AWS_REGION env var when execute.
AWS_REGION = os.environ.get('AWS_REGION')
# SQS
MY_QUEUE_NAME = os.environ.get('MY_QUEUE_NAME', '')
À ce stade, python-dotenv est utilisé pour charger le .env en fonction de l'étape. Je m'attends à ce que .env soit à la racine du projet. Recherchez le répertoire relatif des paramètres dans Pathlib, utilisez la variable d'environnement MYAPP_STAGE_NAME pour déterminer le nom de l'étape et utilisez ce nom comme suffixe .env.
Serverless Framework et Python ont des packages supplémentaires pour travailler avec .env. Faisons bon usage des variables d'environnement en les utilisant.
Il peut y avoir des références à des noms de ressources dans votre code, tels que les identificateurs de ressources DynamoDB et SQS. Les variables d'environnement peuvent également être utilisées dans de tels cas. En la définissant comme une variable d'environnement, la variable peut être réutilisée même en faisant référence au nom de la ressource dans le modèle.
Utilisons os.environ pour créer un module de regroupement des variables d'environnement en constantes Python. Vous pouvez également utiliser la complétion automatique de l'EDI, et comme la description est centralisée en un seul endroit, une erreur de frappe est moins susceptible de se produire et c'est facile.
Recommended Posts