Tout d’abord, un peu de théorie. Ce qui s'est passé ?
En termes simples, ce document est conçu pour simplifier le développement d'applications SaaS, en informant les développeurs et les ingénieurs DevOps sur les problèmes et les pratiques les plus souvent rencontrés dans le développement d'applications modernes.
Le document a été créé par les développeurs de la plateforme Heroku.
L'application Twelve-Factor peut être appliquée à des applications écrites dans n'importe quel langage de programmation et utilisant n'importe quelle combinaison de services de support (bases de données, files d'attente de messages, caches, etc.).
En bref sur les facteurs sur lesquels repose cette méthodologie :
- Base de code – Une base de code suivie dans le contrôle de version – plusieurs déploiements
- Dépendances – Déclarer et isoler explicitement les dépendances
- Configuration – Enregistrer la configuration au runtime
- Services de support – Considérez les services de support comme des ressources plug-in
- Construire, publier, exécuter – Séparer strictement les étapes d’assemblage et d’exécution
- Processus – Exécuter l’application comme un ou plusieurs processus sans état
- Liaison de Port – Services d’exportation via liaison de port
- Parallélisme – Faites évoluer votre application à l’aide de processus
- Jetable – Maximisez la fiabilité avec un démarrage rapide et un arrêt propre
- Parité développement/exploitation des applications – Gardez vos environnements de développement, de préparation et de production aussi similaires que possible
- Enregistrement – Afficher le journal sous forme de flux d’événements
- Tâches administratives – Effectuer des tâches d’administration/gestion à l’aide de processus ad hoc
Vous pouvez obtenir plus d’informations sur les 12 facteurs à partir des ressources suivantes :
- - à lire absolument
- — traduction officielle
- - un nouveau regard sur les 12 facteurs dans le but de les améliorer.
Qu’est-ce que le déploiement Bleu-Vert ?
Le déploiement Blue-Green est une méthode de livraison d'une application à production de manière à ce que le client final ne constate aucun changement de sa part. En d’autres termes, déployer une application avec zéro les temps d'arrêt.
Le schéma classique de BG Deploy ressemble à celui présenté dans l’image ci-dessous.
- Au départ il y a 2 serveurs physiques avec absolument le même code, application, projet, et il y a un routeur (balancer).
- Le routeur dirige initialement toutes les requêtes vers l'un des serveurs (vert).
- Au moment où vous devez à nouveau publier, l'ensemble du projet est mis à jour sur un autre serveur (bleu), qui ne traite actuellement aucune demande.
- Une fois le code activé bleu Le serveur est complètement mis à jour, le routeur reçoit une commande pour passer de vert sur bleu serveur.
- Désormais, tous les clients voient le résultat du code exécuté avec bleu serveur.
- Pour quelques temps, vert le serveur sert de copie de sauvegarde en cas d'échec du déploiement sur bleu serveur et en cas de panne et de bugs, le routeur rétablit le flux utilisateur vers vert serveur avec l'ancienne version stable, et le nouveau code est envoyé pour révision et test.
- Et à la fin du processus, il est mis à jour de la même manière vert serveur. Et après l'avoir mis à jour, le routeur rétablit le flux de requêtes vers vert serveur.
Tout cela a l’air très bien et à première vue, cela ne devrait poser aucun problème.
Mais comme nous vivons dans un monde moderne, l'option avec commutation physique comme indiqué dans le schéma classique ne nous convient pas. Enregistrez les informations pour l'instant, nous y reviendrons plus tard.
Mauvais et bons conseils
Clause de non-responsabilité : Les exemples ci-dessous montrent les utilitaires/méthodologies que j'utilise, vous pouvez utiliser absolument toutes les alternatives avec des fonctions similaires.
La plupart des exemples recouperont d'une manière ou d'une autre le développement web (c'est une surprise), avec PHP et Docker.
Les paragraphes ci-dessous fournissent une description pratique simple de l'utilisation des facteurs à l'aide d'exemples spécifiques ; si vous souhaitez obtenir plus de théorie sur ce sujet, suivez les liens ci-dessus vers la source originale.
1. Base de code
Utilisez FTP et FileZilla pour télécharger des fichiers sur les serveurs un par un, ne stockez pas le code ailleurs que sur le serveur de production.
Le projet doit toujours avoir une seule base de code, c'est-à-dire que tout le code provient d'une seule Git dépôt. Les serveurs (production, staging, test1, test2...) utilisent le code des branches d'un référentiel commun. De cette façon, nous obtenons la cohérence du code.
2. Dépendances
Téléchargez toutes les bibliothèques dans les dossiers directement à la racine du projet. Effectuez des mises à jour simplement en transférant le nouveau code dans le dossier contenant la version actuelle de la bibliothèque. Installez tous les utilitaires nécessaires directement sur le serveur hôte où 20 services supplémentaires sont exécutés.
Un projet doit toujours avoir une liste de dépendances clairement compréhensible (par dépendances, j'entends aussi l'environnement). Toutes les dépendances doivent être explicitement définies et isolées.
Prenons comme exemple Compositeur и Docker.
Compositeur — un gestionnaire de packages qui permet d'installer des bibliothèques en PHP. Composer vous permet de spécifier des versions de manière stricte ou vague et de les définir explicitement. Il peut y avoir 20 projets différents sur le serveur et chacun aura une liste personnelle de packages et de bibliothèques indépendantes des autres.
Docker — un utilitaire qui vous permet de définir et d'isoler l'environnement dans lequel l'application s'exécutera. Ainsi, tout comme avec composer, mais de manière plus approfondie, nous pouvons déterminer avec quoi l'application fonctionne. Sélectionnez une version spécifique de PHP, installez uniquement les packages nécessaires au fonctionnement du projet, sans rien ajouter de plus. Et surtout, sans interférer avec les packages et l'environnement de la machine hôte et des autres projets. Autrement dit, tous les projets sur le serveur exécutés via Docker peuvent utiliser absolument n'importe quel ensemble de packages et un environnement complètement différent.
3.Configuration
Stockez les configurations sous forme de constantes directement dans le code. Constantes séparées pour le serveur de test, séparées pour la production. Liez le fonctionnement de l'application en fonction de l'environnement directement dans la logique métier du projet en utilisant des constructions if else.
Les configurations - c'est la seule façon dont les déploiements de projets doivent différer. Idéalement, les configurations doivent être transmises via des variables d'environnement (vars env).
Autrement dit, même si vous stockez plusieurs fichiers de configuration .config.prod .config.local et que vous les renommez au moment du déploiement en .config (la configuration principale à partir de laquelle l'application lit les données) - ce ne sera pas la bonne approche, car dans ce cas, les informations des configurations seront accessibles au public à tous les développeurs d'applications et les données du serveur de production seront compromises. Toutes les configurations doivent être stockées directement dans le système de déploiement (CI/CD) et générées pour différents environnements avec différentes valeurs nécessaires pour un environnement spécifique au moment du déploiement.
4. Services tiers
Soyez strictement lié à l'environnement, utilisez des connexions différentes pour les mêmes services dans certains environnements.
En fait, ce point recoupe fortement celui sur les configurations, car sans ce point, les données de configuration normales ne peuvent pas être créées et, en général, la capacité de configuration tombera à néant.
Toutes les connexions aux services externes, tels que les serveurs de files d'attente, les bases de données, les services de mise en cache, doivent être les mêmes pour l'environnement local et l'environnement tiers/de production. Autrement dit, à tout moment, en changeant la chaîne de connexion, je peux remplacer les appels à la base n°1 par la base n°2 sans changer le code de l'application. Ou, à titre d'exemple, lors de la mise à l'échelle du service, vous n'aurez pas à spécifier la connexion d'une manière particulière pour un serveur de cache supplémentaire.
5. Construire, publier, exécuter
Ayez uniquement la version finale du code sur le serveur, sans aucune possibilité d'annuler la version. Pas besoin de remplir l'espace disque. Quiconque pense pouvoir mettre du code en production avec une erreur est un mauvais programmeur !
Toutes les étapes du déploiement doivent être séparées les unes des autres.
Ayez une chance de revenir en arrière. Réalisez des versions avec d'anciennes copies de l'application (déjà assemblées et prêtes au combat) enregistrées en accès rapide, afin qu'en cas d'erreurs vous puissiez restaurer l'ancienne version. Autrement dit, il existe conditionnellement un dossier de presse et dossier actuel, et après un déploiement et un assemblage réussis, le dossier actuel lié par un lien symbolique à la nouvelle version qui se trouve à l'intérieur de presse avec le nom conventionnel du numéro de version.
C'est là que l'on se souvient du déploiement Blue-Green, qui vous permet non seulement de basculer entre le code, mais également de basculer entre toutes les ressources et même les environnements avec la possibilité de tout restaurer.
6. Processus
Stockez les données sur l’état de l’application directement dans l’application elle-même. Utilisez des sessions dans la RAM de l'application elle-même. Utilisez autant de partage que possible entre services tiers. Fiez-vous au fait que l’application ne peut avoir qu’un seul processus et ne permet pas de mise à l’échelle.
Concernant les sessions, stockez les données uniquement dans un cache contrôlé par des services tiers (memcached, redis), donc même si vous avez 20 processus d'application en cours d'exécution, n'importe lequel d'entre eux, ayant accédé au cache, pourra continuer à travailler avec le client dans le même état dans lequel l'utilisateur travaillait avec l'application dans un autre processus. Avec cette approche, il s'avère que quel que soit le nombre de copies de services tiers que vous utilisez, tout fonctionnera normalement et sans problème d'accès aux données.
7. Liaison de port
Seul le serveur Web doit savoir comment travailler avec des services tiers. Ou mieux encore, installez des services tiers directement dans le serveur Web. Par exemple, en tant que module PHP dans Apache.
Tous vos services doivent être accessibles les uns aux autres via l'accès à une adresse et un port (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), c'est-à-dire qu'à partir de nginx, je peux accéder à la fois à php- fpm et à postgres, et de php-fpm à postgres et nginx et en fait depuis chaque service, je peux accéder à un autre service. De cette façon, la viabilité d’un service n’est pas liée à la viabilité d’un autre service.
8. Parallélisme
Travaillez avec un seul processus, sinon plusieurs processus ne pourront pas s'entendre !
Laissez de la place à la mise à l’échelle. L'essaim Docker est idéal pour cela.
Docker Swarm est un outil permettant de créer et de gérer des clusters de conteneurs à la fois entre différentes machines et un groupe de conteneurs sur la même machine.
En utilisant Swarm, je peux déterminer combien de ressources j'allouerai à chaque processus et combien de processus du même service je lancerai, et l'équilibreur interne, recevant des données sur un port donné, les transmettra automatiquement aux processus. Ainsi, voyant que la charge sur le serveur a augmenté, je peux ajouter plus de processus, réduisant ainsi la charge sur certains processus.
9. Jetabilité
N'utilisez pas de files d'attente pour travailler avec des processus et des données. La suppression d'un processus devrait affecter l'ensemble de l'application. Si un service tombe en panne, tout tombe en panne.
Chaque processus et service peut être désactivé à tout moment et cela ne devrait pas affecter les autres services (bien sûr, cela ne signifie pas que le service sera indisponible pour un autre service, mais qu'un autre service ne sera pas désactivé après celui-ci). Tous les processus doivent être terminés en douceur, de sorte qu'une fois terminés, aucune donnée ne soit endommagée et que le système fonctionne correctement la prochaine fois que vous l'allumerez. Autrement dit, même en cas d'arrêt d'urgence, les données ne doivent pas être endommagées (le mécanisme de transaction convient ici, les requêtes dans la base de données ne fonctionnent qu'en groupe, et si au moins une requête du groupe échoue ou est exécutée avec un erreur, alors aucune autre requête du groupe n'échoue finalement en fait).
10. Parité développement/exploitation des applications
La production, le staging et la version locale de l'application doivent être différentes. En production nous utilisons le framework Yii Lite, et localement Yii, pour que cela fonctionne plus rapidement en production !
En réalité, tous les déploiements et travaux avec le code devraient se faire dans un environnement presque identique (nous ne parlons pas de matériel physique). De plus, tout employé de développement devrait être en mesure de déployer le code en production si nécessaire, et non un service de développement spécialement formé, qui, uniquement grâce à une force particulière, peut mettre l'application en production.
Docker nous aide également dans ce domaine. Si tous les points précédents sont respectés, l'utilisation de docker amènera le processus de déploiement de l'environnement à la fois en production et sur la machine locale à saisir une ou deux commandes.
11. Journaux
Nous écrivons des journaux dans des fichiers et des bases de données ! Nous ne supprimons pas les fichiers et les bases de données des journaux. Achetons simplement un disque dur de 9000 XNUMX Peta octets et c'est très bien.
Tous les journaux doivent être considérés comme un flux d'événements. L'application elle-même ne doit pas être impliquée dans le traitement des journaux. Les journaux doivent être générés soit sur stdout, soit envoyés via un protocole tel que udp, afin que l'utilisation des journaux ne crée aucun problème pour l'application. graylog est bon pour ça. Graylog recevant tous les journaux via udp (ce protocole ne nécessite pas d'attendre une réponse sur la réception réussie du paquet) n'interfère en aucune façon avec l'application et ne s'occupe que de la structuration et du traitement des journaux. La logique d'application ne change pas pour fonctionner avec de telles approches.
12. Tâches administratives
Pour mettre à jour les données, les bases de données, etc., utilisez un point de terminaison créé séparément dans l'API, son exécution 2 fois de suite entraînera la duplication de tout. Mais vous n’êtes pas stupide, vous ne cliquerez pas deux fois et nous n’avons pas besoin de migration.
Toutes les tâches d'administration doivent être effectuées dans le même environnement que tout le code, au niveau de la version. Autrement dit, si nous devons modifier la structure de la base de données, nous ne le ferons pas manuellement en modifiant les noms des colonnes et en en ajoutant de nouvelles via certains outils de gestion visuelle de la base de données. Pour de telles choses, nous créons des scripts distincts - des migrations, qui sont exécutés partout et dans tous les environnements de la même manière avec un résultat commun et compréhensible. Pour toutes les autres tâches, telles que remplir le projet avec des données, des méthodologies similaires doivent être utilisées.
Exemple d'implémentation en PHP, Laravel, Laradock, Docker-Compose
PS Tous les exemples ont été réalisés sur MacOS. La plupart d’entre eux conviennent également à Linux. Utilisateurs de Windows, pardonnez-moi, mais je n'ai pas travaillé avec Windows depuis longtemps.
Imaginons une situation dans laquelle nous n’avons aucune version de PHP installée sur notre PC et rien du tout.
Installez les dernières versions de docker et docker-compose. (on peut le trouver sur Internet)
docker -v &&
docker-compose -v
1. Nous mettons
git clone https://github.com/Laradock/laradock.git &&
ls
Concernant Laradock, je dirai que c'est une chose très cool, qui contient beaucoup de conteneurs et de choses auxiliaires. Mais je ne recommanderais pas d'utiliser Laradock tel quel sans modifications en production en raison de sa redondance. Il est préférable de créer vos propres conteneurs à partir d'exemples dans Laradock, ce sera beaucoup plus optimisé, car personne n'a besoin de tout ce qui est là en même temps.
2. Configurez Laradock pour exécuter notre application.
cd laradock &&
cp env-example .env
2.1. Ouvrez le répertoire habr (le dossier parent dans lequel laradock est cloné) dans un éditeur. (Dans mon cas PHPStorm)
A ce stade, nous donnons seulement un nom au projet.
2.2. Lancez l'image de l'espace de travail. (Dans votre cas, la création des images prendra un certain temps)
Workspace est une image spécialement préparée pour travailler avec le framework au nom du développeur.
Nous entrons dans le conteneur en utilisant
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Installer Laravel
composer create-project --prefer-dist laravel/laravel application
2.4. Après l'installation, nous vérifions si le répertoire contenant le projet a été créé et tuons composer.
ls
exit
docker-compose down
2.5. Revenons à PHPStorm et définissons le chemin correct vers notre application Laravel dans le fichier .env.
3. Ajoutez tout le code à Git.
Pour ce faire, nous allons créer un référentiel sur Github (ou ailleurs). Allons dans le répertoire habr du terminal et exécutons le code suivant.
echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin [email protected]:nzulfigarov/habr-12factor.git # здесь будет ссылка на ваш репо
git push -u origin master
git status
Vérifions si tout est en ordre.
Pour plus de commodité, je recommande d'utiliser une interface visuelle pour Git, dans mon cas c'est . (voici un lien de parrainage)
4. C'est parti !
Avant de commencer, assurez-vous que rien ne bloque sur les ports 80 et 443.
docker-compose up -d nginx php-fpm
Ainsi, notre projet se compose de 3 prestations distinctes :
- nginx - serveur Web
- php-fpm - php pour recevoir des requêtes d'un serveur Web
- espace de travail - php pour les développeurs
À l'heure actuelle, nous avons réussi à créer une application qui répond à 4 points sur 12, à savoir :
1. Base de code — tout le code est dans un seul référentiel (petite remarque : il peut être correct d'ajouter un docker à l'intérieur du projet laravel, mais ce n'est pas important).
2. Dépendances - Toutes nos dépendances sont explicitement écrites dans application/composer.json et dans chaque Dockerfile de chaque conteneur.
3. Services de support — Chacun des services (php-fom, nignx, workspace) vit sa propre vie et est connecté de l'extérieur et lorsque vous travaillez avec un service, l'autre ne sera pas affecté.
4. Processus — chaque service est un processus. Chacun des services ne maintient pas d'état interne.
5. Liaison de Port
docker ps
Comme on peut le voir, chaque service fonctionne sur son propre port et est accessible à tous les autres services.
6. Parallélisme
Docker nous permet de générer plusieurs processus des mêmes services avec un équilibrage automatique de la charge entre eux.
Arrêtons les conteneurs et faisons-les passer le drapeau --échelle
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Comme nous pouvons le voir, des copies ont été créées du conteneur php-fpm. Nous n’avons rien besoin de changer en travaillant avec ce conteneur. Nous continuons également d'y accéder sur le port 9000, et Docker régule pour nous le chargement entre conteneurs.
7. Jetable - chaque conteneur peut être tué sans nuire à l'autre. L'arrêt ou le redémarrage du conteneur n'affectera pas le fonctionnement de l'application lors des lancements ultérieurs. Chaque conteneur peut également être levé à tout moment.
8. Parité développement/exploitation des applications - tous nos environnements sont identiques. En exécutant le système sur un serveur en production, vous n’aurez rien à modifier dans vos commandes. Tout sera basé sur Docker de la même manière.
9. Enregistrement — tous les journaux de ces conteneurs sont diffusés et sont visibles dans la console Docker. (dans ce cas en effet, avec d’autres contenants faits maison, cela peut ne pas être le cas si vous n’en prenez pas soin)
docker-compose logs -f
Mais il y a un problème dans la mesure où les valeurs par défaut de PHP et Nginx écrivent également des journaux dans un fichier. Pour répondre aux 12 facteurs, il faut désactiver écrire des journaux dans un fichier dans les configurations de chaque conteneur séparément.
Docker offre également la possibilité d'envoyer des journaux non seulement vers la sortie standard, mais également vers des éléments tels que graylog, que j'ai mentionné ci-dessus. Et dans graylog, nous pouvons exploiter les journaux à notre guise et notre application ne le remarquera en aucun cas.
10. Tâches administratives — toutes les tâches d'administration sont résolues par Laravel grâce à l'outil artisanal exactement comme le souhaiteraient les créateurs de l'application à 12 facteurs.
A titre d'exemple, je vais montrer comment certaines commandes sont exécutées.
Nous entrons dans le conteneur.
docker-compose exec workspace bash
php artisan list
Nous pouvons maintenant utiliser n'importe quelle commande. (veuillez noter que nous n'avons pas configuré la base de données et le cache, donc la moitié des commandes ne seront pas exécutées correctement, car elles sont conçues pour fonctionner avec le cache et la base de données).
11. Les configurations et 12. Construire, publier, exécuter
Je voulais consacrer cette partie au déploiement bleu-vert, mais elle s'est avérée trop complète pour cet article. J'écrirai un article séparé à ce sujet.
En un mot, le concept est basé sur des systèmes CI/CD comme Jenkins и CI Gitlab. Dans les deux cas, vous pouvez définir des variables d'environnement associées à un environnement spécifique. En conséquence, dans cette situation, le point c sera rempli Configurations.
Et le point sur Construire, publier, exécuter est résolu par des fonctions intégrées portant le nom Pipeline.
Pipeline vous permet de diviser le processus de déploiement en plusieurs étapes, en mettant en évidence les étapes d'assemblage, de publication et d'exécution. Également dans Pipeline, vous pouvez créer des sauvegardes, et bien n'importe quoi. Il s’agit d’un outil au potentiel illimité.
Le code de l'application est à .
N'oubliez pas d'initialiser le sous-module lors du clonage de ce référentiel.
PS : Toutes ces approches peuvent être utilisées avec n’importe quel autre utilitaire et langage de programmation. L'essentiel est que l'essence ne diffère pas.
Source: habr.com