Déployer des applications Symfony + React sur AWS via CI

Bonjour, dans cet article, je vais vous montrer comment déployer l'application Symfony 4 sur AWS. Il existe un exemple d'un tel processus dans la documentation officielle, mais ma version n'est pas aussi triviale que le téléchargement d'une archive zip avec une application. Dans la cour de 2019, en mode docker, l'architecture de microservice et les pratiques CI / CD commencent enfin à être incluses dans les outils non seulement des ingénieurs DevOps, mais aussi des développeurs mortels ordinaires. Pour rendre l'article plus intéressant, j'ai ajouté une façade à React.JS, pour couvrir les besoins de plus de personnes, si votre application n'utilise pas Encore - cela n'a pas d'importance, je vous indiquerai comment changer le fichier Docker pour vous, la prise en charge de React.JS ne l'affecte que . Qui sera intéressé par ce tutoriel? Tout d'abord, il s'adresse aux développeurs PHP qui souhaitent changer leur pratique de déploiement - s'éloigner des canons habituels et utiliser docker pour emballer leur application et disposer l'image. Mais vous pouvez aller un peu plus loin, et la suite de la narration visera à déployer automatiquement l'application depuis Git via la plateforme CI / CD (CircleCI sera utilisé, mais si vous êtes intéressé par la configuration de Gitlab, écrivez dans les commentaires, je la joindrai). En fait, il n'est absolument pas important pour React / PHP que vous ayez une application ou, par exemple, .NET Core, cette partie sera intéressante pour les développeurs pour acquérir des compétences d'automatisation du déploiement en général. Le code source est disponible dans le référentiel github, lien à la fin de l'article. Eh bien, allons-y!

Je suppose que vous avez votre propre application Symfony, mais à des fins de démonstration, j'ai esquissé «bonjour, monde!» Contenant les packages suivants:

`symfony/webpack-encore-bundle symfony/form symfony/orm-pack symfony/profiler-pack symfony/security-bundle symfony/twig-bundle symfony/validator symfony/phpunit-bridge` est un ensemble minimal de gentleman. Pour le moment, la structure des dossiers devrait être la suivante:



Vous devez maintenant configurer votre infrastructure cloud. Je ne me concentrerai pas sur l'enregistrement et l'activation de la période d'essai d'AWS, à ce stade, nous devons créer 2 instances de base de données - j'utiliserai 2 types d'environnement: STG (staging) pour tester la mise en œuvre de nouvelles «fonctionnalités» et PROD (production) comme directement «combat» serveur De nombreux articles ont été écrits sur les avantages de la base de données de services gérés, de plus, nous recherchons principalement la commodité pour le développeur dans ce guide, nous utilisons donc RDS, plutôt que d'élever notre propre serveur de base de données distinct. En tant que SGBD pour cet exemple, j'ai utilisé PostgreSQL, vous êtes libre de choisir celui qui vous convient, accédez au service RDS et créez 2 instances de la capacité et du volume dont vous avez besoin. Étant donné que le fichier .env est disponible pour nous hors de la boîte dans Symfony, nous allons l'utiliser, par exemple, pour PROD, et pour STG nous allons créer une copie de .env.stg et changer APP_ENV=dev en APP_ENV=stg .env.stg dans .env.stg et APP_ENV=dev sur APP_ENV=prod dans .env , et entrez également les paramètres de connexion à la .env pour chacune des instances créées.

Génial, un début a été fait! Comme vous le savez, les dépendances symfony sont installées via composer, pour l'installer, utilisez le fichier composer.sh, que nous mettons à la racine du projet:


Ceci est un guide d' installation du logiciel de composer .

Maintenant, pour chaque environnement, créez votre propre Dockerfile à la racine du projet:


et


Les fichiers peuvent être utilisés «tels quels», aucune macro n'est utilisée pour les modifications. Parcourons le contenu du Dockerfile pour dissiper la touche «magique». En tant que «fondation», nous utilisons l'image officielle PHP 7.2.19 avec le serveur Web Apache intégré (vous êtes libre d'utiliser n'importe lequel de votre choix, de configurer un bundle avec Nginx, et ainsi de suite, dans cet exemple, j'utilise ce qui précède comme le plus, à mon avis, pratique). La ligne d'exposition n'est pas importante pour nous pour le moment, elle ne fait rien en soi, mais à l'avenir, elle sera utilisée par ElasticBeanstalk, qui en a besoin pour se déployer correctement. Les constructions suivantes utilisent des paramètres de production optimisés pour PHP recommandés par le fabricant, activent mod_rewrite pour Apache et augmentent la mémoire maximale pour un script PHP de 128 à 256 Mo, ce qui est nécessaire pour que composer fonctionne correctement. Ensuite, nous installons les applications nécessaires, les dépendances et extensions PHP, et les configurons immédiatement. Nous attribuons le dossier / var / www au répertoire de travail de notre application - le code source de notre application y sera copié. Comme apache, par défaut, utilise / var / www comme point d'entrée pour son hôte, et que le fichier d'index symfony se trouve dans / var / www / public, nous changeons la racine du document apache avec la construction suivante. Ensuite, nous installons séquentiellement compositeur, nodejs et fil (si vous n'utilisez pas encore / react.js dans votre application, vous n'avez pas besoin des deux derniers points). Enfin, nous copions notre code source et commençons l'installation des dépendances via composer pour symfony et yarn pour react.js. La signification d'un Dockerfile distinct pour STG réside dans l'avant-dernière instruction pour docker - copier .env.stg vers .env, de sorte que le fichier .env dans l'image STG contiendra les paramètres pertinents pour cet environnement. Vous pouvez localement (bien sûr avec docker installé) collecter l'image, l'exécuter et vous assurer que l'application fonctionne et n'a besoin de rien d'autre pour ce travail:

 docker build -t tmp:stg -f Dockerfile.stg . docker run -p 80:80 tmp:stg 

pour STG et

 docker build -t tmp:prod . docker run -p 80:80 tmp:prod 

pour PROD.
Nous pouvons utiliser EC2, configurer ELB / ASG, etc., ou utiliser ElasticBeanstalk, qui est juste un cadeau pour nous en termes de commodité. Accédez à la section ElasticBeanstalk et créez une nouvelle application avec son nom et sa description. Ensuite, créez 2 environnements mentionnés précédemment: STG et PROD, créez les deux environnements en tant qu'environnement de serveur Web, spécifiez «Docker» comme plate-forme et laissez l'exemple d'application comme code d'application. Le déploiement vers ElasticBeanstalk se fait en téléchargeant des fichiers de projet ou des instructions, généralement dans une archive zip. Dans notre cas, le flux sera le suivant: nous collectons l'image docker de notre application, la chargeons dans le référentiel et chargeons l'instruction à la place de l'archive source ou de l'image docker, qui indique à ElasticBeanstalk de prendre l'image du serveur distant et de la déployer. Et tout cela est automatique.

Commençons par créer un référentiel pour stocker les images docker. Il y a 2 options:

1 - votre projet est privé, son code est fermé et le référentiel, respectivement, doit également être fermé. Dans ce cas, vous devez conserver votre propre registre d'images quelque part ou utiliser un cloud privé. AWS a ECR à ces fins, vous pouvez y créer un référentiel, mais personne ne vous y oblige.

2 - vous avez un projet open source et vous pouvez utiliser dockerhub.

Dans notre exemple, le code est ouvert, mais je vais montrer comment utiliser des référentiels fermés, après avoir compris ce processus, la connexion d'une image à partir de dockerhub ne sera pas difficile. La première chose dont nous avons besoin est de créer le référentiel lui-même, après quoi vous obtiendrez son URI unique. La narration supplémentaire ira pour les tiers (pas les référentiels AWS ECR et leur intégration), pour ECR j'écrirai après cela.

Après avoir créé le référentiel, nous devons nous connecter à ce service et il y a une petite astuce ... Allez dans les paramètres de votre docker installé localement et vérifiez que vous avez la possibilité d'enregistrer les mots de passe dans le stockage externe supprimé (pour les utilisateurs de macOS: «Stockez en toute sécurité les connexions de docker dans macOS Keychain ”), sinon le fichier de configuration dont nous avons besoin sera vide. Et donc, nous autorisons dans le service sélectionné à stocker les registres de vos images:

 docker login -u LOGIN -p PASSWORD REGISTRY 

après l'authentification réussie, la construction suivante apparaîtra dans le fichier de configuration ~ / .docker / config.json:

 "REGISTRY" : { "auth" : "BASE64_ENCODED_TOKEN" } 

S'il n'apparaît pas, vérifiez à nouveau la configuration du docker décrite ci-dessus.

Maintenant, tout est prêt pour préparer le fichier d'instructions pour ElasticBeanstalk - Dockerrun.aws.json, son code sera comme ceci:


En général, l'instruction ressemble à ceci: après s'être connecté en utilisant la clé localisée par KEY_PATH dans le stockage S3 BUCKET_ID, charger l'image par IMAGE_URL en écrasant celle enregistrée, la démarrer en redirigeant le port 80 vers le même port du conteneur. Maintenant sur les constantes utilisées:

BUCKET_ID est le «sac à dos» créé automatiquement pour vous dans le service S3, sous la forme élastiquebeanstalk-REGION-HASH, c'est là que le système localise les fichiers de service pour votre ElasticBeanstalk, y compris les fichiers d'application que vous téléchargez à l'aide du bouton «Télécharger et déployer».

KEY_PATH - chemin d'accès au fichier d'autorisation vers le référentiel d'images, j'utilise le format APP_NAME / cr.json, c'est-à-dire dans le dossier à l'intérieur de BUCKET_ID sous le nom de mon application (je crée, sinon encore) je mets le fichier cr.json contenant le code reçu après autorisation dans le registre Images localement:


IMAGE_URL est l'URI unique de votre registre d'image + tag de l'image elle-même, tout doit être clair ici.

Voilà, nous pouvons maintenant télécharger ce fichier en tant que version de notre application dans ElasticBeanstalk, et il va extraire l'image spécifiée et la déployer.

Il reste à automatiser ce processus. Et pour être absolument intéressant, je vais implémenter la séquence d'étapes pour le flux suivant: pour tous les commits PAS dans la branche master, l'image sera collectée et déployée dans l'environnement STG, et si nous poussons dans le master, ou mieux, fermez-le et remplissez-le avec une demande de fusion , le code sera déployé sur PROD. Ainsi, nous obtenons dans PROD un assistant à jour, dans lequel tout devrait bien se passer, et des branches pour développer et tester de nouveaux codes dans STG. Pour cette implémentation, nous avons besoin d'instructions pour télécharger les images les plus récentes, copier Dockerrun.aws.json dans Dockerrun.aws.stg.json et renommer Dockerrun.aws.json en Dockerrun.aws.prod.json (juste pour plus de commodité).

La seule chose qui distingue Dockerrun.aws.stg.json de Dockerrun.aws.prod.json est IMAGE_URL:


Comme je l'ai dit au début de l'article, j'utiliserai CircleCI comme CI / CD, ce qui, selon mes sentiments personnels, est plus rapide que GitlabCI si j'utilise la version SaaS gratuite. Free Travis ferait l'affaire, mais comme il ne fonctionne pas avec les référentiels git privés, je n'ai pas spécifiquement fait de démonstration dessus afin qu'il n'y ait pas de déception quand une telle opportunité était nécessaire. Je laisserai les paramètres du projet dans CircleCI aux lecteurs pour qu'ils les étudient eux-mêmes, je donnerai les instructions nécessaires pour le déploiement moi-même - à la racine de notre projet, nous créerons le dossier .circleci, dans ce config.yml avec le contenu suivant:


J'ai peint le flux lui-même un peu plus tôt, le voici traduit en yaml-instructions pour CircleCI, passons par l'implémentation d'étapes spécifiques. Il est important de noter la présence de variables d'environnement définies pour CI qui seront utilisées par lui lors des travaux:

CI_REGISTRY, CI_REGISTRY_USER, CI_REGISTRY_PASSWORD sont nécessaires pour accéder au stockage d'images docker - la même chose que nous avons mise dans cr.json, uniquement sans base64

CI_REGISTRY / CI_REGISTRY_ID composent une URL d'image unique, sans balise

AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY - les noms parlent d'eux-mêmes, ce sont des crédits AWS pour l'utilisateur au nom duquel CircleCI déploiera. Accédez à AWS IAM et créez un utilisateur, ajoutez-le au groupe d'administrateurs et fournissez uniquement un accès par programme. N'oubliez pas que AWS_SECRET_ACCESS_KEY n'est disponible pour la visualisation / copie qu'une seule fois, après avoir cliqué sur le lien Afficher, vous ne le verrez plus.

Retour aux étapes de configuration de CircleCI. Quelle est la magie? Checkout charge le code source de la branche git dans le répertoire de travail actuel, ce processus est répété dans chaque travail. Dans le processus de construction, nous nous connectons séquentiellement au référentiel, collectons le code basé sur Dockerfile.stg sous la balise XXX: dev et l'envoyons au référentiel. build-master fait de même, uniquement pour le build, il utilise le Dockerfile «normal» sous la balise XXX: latest.

deploy-stg installe l'AWS EB CLI et crée un profil d'autorisation dans le fichier ~ / .aws / config, qui est nécessaire pour que la CLI fonctionne correctement, puis initialise les variables pour la CLI - vous devrez spécifier la région que vous choisissez, la plate-forme - toujours Docker et le nom de votre application. Ensuite, nous copions le contenu de Dockerrun.aws.stg.json dans le nouveau fichier Dockerrun.aws.json et, en utilisant l'environnement et la région spécifiques, donnons une commande pour déployer notre application en utilisant le profil d'autorisation créé. Par défaut, à la suite de cette commande, tout le code de la branche surveillée se retrouvera dans une archive zip, qui sera téléchargée sur ElasticBeanstalk et décompressée là, mais cette opération est relativement coûteuse, donc nous avons créé un nouveau fichier Dockerrun.aws.json, qui est suffisant pour déployer le créé par nous image distante, et nous avons seulement besoin de la télécharger, en fait. Pour ce faire, créez un fichier .ebignore à la racine du projet:


Ce fichier utilise la syntaxe .gitignore et il s'agit de .gitignore, mais pas pour la CLI Git, mais pour la CLI AWS EB. Dans ce fichier, je dis à la CLI de sauter tous les fichiers sauf Dockerrun.aws.json. Voilà, maintenant, lorsque vous exécutez le travail deploy-stg dans ElasticBeanstalk, seul le fichier que nous avons créé sera envoyé. deploy-prod fait la même chose, copie uniquement le contenu du fichier Dockerrun.aws.prod.json dans Dockerrun.aws.json, et le dernier est une indication de la séquence de travail au format CircleCI (deploy-stg après construction et deploy-prod après construction -master), et sur quelles branches les données recherchent (ignorer: - master et uniquement: - master).

Une question un peu différente est avec AWS ECR, comme je l'ai promis, nous y reviendrons. Vous n'avez pas besoin de vous connecter à distance à l'ECR et de créer un fichier cr.json, car ElasticBeanstalk «connaît un frère en personne». En conséquence, Dockerrun.aws.json sera différent - il n'y aura tout simplement pas de bloc d'authentification:


Mais comment se fera alors l'authentification? Le fait est que le service qui accède à l'ECR a un certain ensemble de droits, qui à leur tour sont basés sur certaines politiques de sécurité. Dans notre cas, lorsque le déploiement est lancé via l'AWS CLI à partir d'un serveur tiers (à partir de CI), le rôle «aws-elasticbeanstalk-ec2-role» est utilisé, recherchez-le dans AWS IAM dans la section des rôles et attachez-lui la stratégie supplémentaire «AmazonEC2ContainerRegistryReadOnly». Désormais, le téléchargement à partir d'un référentiel privé vers son «voisin» réussira sans erreur.

Mais cela se charge exactement à partir du même VPC, via la CLI, la commande de connexion Docker n'est pas non plus "sans astuces": vous devez obtenir (obtenir simplement) des crédits pour la connexion Docker via l'AWS CLI, pour cela, il existe une commande

aws ecr get-login --region REGION --no-include-email

Cette commande vous renverra une ligne du formulaire de connexion docker ..., mettez simplement, dans la console que vous devez exécuter

eval $(aws ecr get-login --region EB_REGION --no-include-email)

La commande recevra d'abord une chaîne pour l'authentification, puis démarrera le processus correspondant. Au vu de ces règles pour AWS ECR, le fichier d'instructions pour CircleCI ressemblera à ceci:


Pour prendre en charge docker-in-docker, nous avons ajouté setup_remote_docker aux étapes de l'assemblage, vous devez déjà connaître le reste du contenu de cet article. C'est tout, maintenant la structure de notre projet est la suivante:



Essayez de changer le code, poussez-le dans la branche de tâche, puis faites une demande de fusion (pull) au maître et acceptez-le. Plus de «mouvements» pour publier des mises à jour. Il est possible (et quelqu'un a besoin) d'aller plus loin, d'écrire vos propres bureaux de travail pour les migrations en continu, de prendre une étape obligatoire intermédiaire pour passer les autotests, etc.

Code source GitHub: tutorial-aws-symfony-ci