Ce facteur est un facteur de gestion des dépendances à la fois original et au-delà. Dans les langages de développement modernes, la plupart des outils de gestion de packages sont fournis pour résoudre les références de bibliothèques telles que npm, pip et gradle. La résolution des dépendances d'application à l'aide d'une telle gestion de package garantit qu'un ensemble d'applications bien configuré peut être créé et exécuté dans n'importe quel environnement. De plus, en termes de dépendances, vous devez prêter attention non seulement aux bibliothèques d'applications, mais également à la création de scripts et de scripts de déploiement. Il est nécessaire d'empêcher l'utilisation implicite de ces scripts pour les bibliothèques et commandes installées sur un système spécifique.
De plus, lorsque je crée une application dans un environnement Windows comme moi, si le script est écrit dans un shell, j'ai le sentiment qu'il dépend du système. Tant que vous avez une version d'exécution sur n'importe quel système d'exploitation. Je pense que nous devrions faire des efforts dans le but de pouvoir couvrir tout le développement, les tests et l'exécution de l'application dans des conditions égales. ..
Cette fois également, je continuerai à pratiquer ce facteur basé sur Lambda et Python. Je vais continuer avec le flux de la gestion des packages à l'aide de pipenv de Python à la création d'un package pour déployer des fonctions Lambda basées sur celui-ci. Python à utiliser est 3.8, et l'installation d'exécution commencera à partir du point où elle est terminée.
pipenv pipenv est un outil qui intègre la gestion des paquets avec pip et la gestion de l'environnement virtuel avec venv. Je pense que c'est à un niveau élevé en tant qu'outil pour séparer et gérer explicitement les dépendances.
pip install pipenv
PIPENV_VENV_IN_PROJECT=1
Cela garantira que l'environnement virtuel créé par virtualenvv est spécifique au projet. Étant donné que plusieurs projets sont traités en même temps, il est recommandé de les séparer si loin du point de vue de la séparation des dépendances.
pipenv --python 3.8
Le fichier Pipfile '' et le dossier .venv '' sont créés directement sous le dossier du projet, et vous êtes prêt à partir.
En utilisant pipenv, il est possible de l'utiliser uniquement dans l'environnement de développement et de gérer les packages inutiles dans le code produit. Des outils tels que autopep8 et pylint lui correspondent, alors installez-le comme suit.
pipenv install --dev autopep8 pylint
boto3
La version Python du kit SDK AWS, boto3, est préinstallée dans l'environnement d'exécution de Lambda. En d'autres termes, si vous souhaitez utiliser boto3 inclus dans l'environnement d'exécution, installez boto3 en tant que package de développement afin qu'il ne soit pas inclus dans le code produit. Ceci est efficace car cela réduit le temps de chargement de l'énorme code de boto3 au démarrage à froid de Lambda. Cependant, boto3 inclus dans l'environnement d'exécution a une faiblesse en ce que l'utilisateur ne peut pas contrôler la version. Si AWS modifie l'environnement d'exécution Lambda, il existe toujours un risque que la version de boto3 dans l'environnement de production change soudainement un jour. De plus, si la mise à niveau de la version inclut un changement de freinage, elle peut soudainement cesser de fonctionner. De plus, boto3 inclus dans l'environnement d'exécution est une version légèrement plus ancienne du module, il ne peut donc pas être utilisé dans les cas d'utilisation où la dernière version de boto3 est requise. Lors de l'exploitation d'un système fonctionnant 24h / 24, 365 jours par an, il est recommandé que boto3 soit inclus dans l'application, même au détriment des performances de démarrage à froid.
Cette fois, nous allons construire un projet en intégrant boto3 dans l'application. Installez le package ci-dessous.
pipenv install boto3
Pour déployer la fonction Lambda, les modules nécessaires, y compris les packages dépendants, doivent être compressés au format ZIP et téléchargés. Le processus de conversion en ZIP est le suivant.
Tout d'abord, la structure du projet prérequis est la suivante.
root
+ src
| + lambda_function.py
+ packing.py
+ Pipfile
+ Pipfile.lock
+ setup.py
__src folder __: Application pour la fonction Lambda. Contient le gestionnaire Lambda. packing.py: Code pour l'empaquetage des fonctions Lambda Pipfile: fichier de configuration pipenv Pipfile.lock: informations détaillées sur l'environnement construit avec pipenv. Utilisez ce fichier pour reproduire complètement l'environnement setup.py: fichier de configuration pour le déploiement des applications de fonction Lambda avec pip
Tout d'abord, setup.py est le suivant. Il s'agit d'un fichier de configuration pour installer un ensemble d'applications sous le dossier src avec la commande pip, qui est utilisée pour empaqueter l'application. Dans ce qui suit, lambda_function.py et les packages sous `` src '', le cas échéant, seront installés. Il s'agit du paramètre d'installation de pip.
from setuptools import setup, find_packages
setup(
name="12factor",
version="1.0.0",
packages=find_packages(where='src'),
py_modules=['lambda_function'],
package_dir={'': 'src'},
)
Ensuite, packing.py pour l'emballage réel est le suivant. J'écris en python pour pouvoir créer des ZIP dans n'importe quel environnement sans dépendre du système. Le flux général est de collecter les fichiers nécessaires dans . Dist en tant que dossier temporaire et de les compresser. De plus, ce programme n'est pas exécuté dans l'environnement de développement, mais il est supposé être exécuté dans un environnement propre où le code source est obtenu à partir de git etc. Je l'utilise pour l'empaquetage en créant temporairement un environnement virtuel de . Venv. Soyez prudent car si vous créez un environnement virtuel de . Venv dans l'environnement de développement, il sera détruit.
pipfile.lock dans le dossier ZIP. La commande pipenv sync reproduit fidèlement les packages, ce qui en fait la solution la plus appropriée du point de vue de la "gestion des dépendances". Si vous spécifiez un dossier pour ZIP dans la variable d'environnement PIP_TARGET. pipenv sync Seuls les packages dépendants seront installés dans ce dossier lorsque vous exécuterez la commande.import os
import shutil
import subprocess
DISTINATION_FOLDER = '.dist'
if __name__ == '__main__':
#Créer un dossier pour ZIP
shutil.rmtree(DISTINATION_FOLDER, ignore_errors=True)
os.mkdir(DISTINATION_FOLDER)
#Changer le dossier dans lequel les packages sont enregistrés lors de la synchronisation pipenv
os.environ['PIP_TARGET'] = DISTINATION_FOLDER
#Supprimer si l'environnement virtuel existe déjà
subprocess.call('pipenv --rm')
# pipfile.Reproduction de l'environnement virtuel à partir de la serrure
subprocess.call('pipenv sync')
#Installer le code d'application avec pip
subprocess.call('pip install -t {} .'.format(DISTINATION_FOLDER))
# ZIP
shutil.make_archive('lambda_function', 'zip', DISTINATION_FOLDER)
#Supprimer l'environnement virtuel
subprocess.call('pipenv --rm')
Comme troisième facteur, j'ai pratiqué les méthodes de gestion des dépendances en utilisant Python et Lambda. Je pense que la sensibilité avec laquelle vous gérez les dépendances dépend du projet, mais j'espère que l'exemple présenté ici pourra être utilisé comme exemple lorsqu'il est géré le plus strictement.
La prochaine fois, "(4) Design, Build, Release, Execution / Build, Release, Execution - Séparez strictement les trois étapes de Build, Release et Execution". Table des matières de cette série Tableau de toutes les séries