Maison / Technologie / Déploiement sur AWS Free Tire avec Docker et Fabric

Déploiement sur AWS Free Tire avec Docker et Fabric

Dans cet article, je souhaite résumer tout ce dont vous aurez besoin pour créer un environnement et un déploiement de développement corrects pour une petite application.
Pour ce faire, nous allons utiliser Pneu sans AWS et Docker conteneurs et orchestration et Django app comme projet typique

Lien sur ce projet github: https://github.com/creotiv/aws-docker-example

Avant d'aller plus loin, installez d'abord Docker: https://docs.docker.com/install/linux/docker-ce/ubuntu/

Tout le code fonctionnant sous Python 3.6

Docker

Docker est un moteur de virtualisation de conteneur qui vous permet de créer des environnements rapides et bon marché pour une utilisation en production et en développement. Les conteneurs ne sont pas des machines virtuelles. L'idée clé des conteneurs est de les rendre aussi minces que possible. Vous ne pouvez donc pas utiliser le conteneur Windows sur le système Linus. Voici une bonne image pour voir la différence.

Docker image et conteneur

Les images et les conteneurs sont les deux composants principaux du système Docker.

Image – est une construction claire de l'environnement sans aucun état de fonctionnement

Conteneur – est une image en cours d'exécution / arrêtée avec un certain état (enregistrements de base de données créés, fichiers téléchargés, etc.)

Ce qui est génial dans Images, c'est qu'ils ont créé avec un seul fichier (Dockerfile) et peuvent donc être stockés dans Git / Docker Hub, simplement transférés sur le réseau. Cela rend les CD / CI beaucoup plus simples et légers.

Docker compose

Dans la plupart des cas, l'outil docker-compose est utilisé pour exécuter tous les conteneurs sur une machine dev / CI / CD locale avec la même configuration que celle utilisée en production. Mais il peut également être utilisé pour un scénario de déploiement sur une seule machine (mais nous utiliserons Docker Swarm pour cela).

Orchestration

Docker Swarm – est un service d’orchestration de conteneurs, qui contrôle essentiellement l’exécution de conteneurs sur différentes machines avec différentes configurations et gère toutes les communications entre elles.
Docker Swarm n’existe pas seulement le moteur d’orchestration qui existe, il existe également des Kubernets, AWS ECS, le service de conteneur Azure, le moteur de conteneur Google, etc.
Pour les grosses applications de production, je recommande d’utiliser Kubernets. Mais pour cette simple démonstration, nous utiliserons Docker Swarm comme le choix le plus simple et le plus approprié pour les projets de petite / moyenne taille.

Tester des choses localement

Avant d’apporter des modifications sur des machines distantes, il est bon de tester les choses localement.

Notre application utilisera 3 conteneurs pour l'instance de Django + Gunicorn, Nginx, PosgreSQL, et pour chacun d'eux, nous avons besoin d'une image.

Faire des images avec Dockerfiles

Avant d'essayer d'écrire un gros fichier Dockerfile avec beaucoup de code d'installation, il est bon de le rechercher sur Docker Hub(aka github pour les images de docker).
Nous rechercherons Python, Nginx, PostgreSQL. Par exemple, voici une image python https://hub.docker.com/_/python
Pour toutes nos images, nous utiliserons les dernières images Alpine Linus. Nous n'écrirons pas Dockerfile pour PostgreSQL car nous utiliserons une image claire sans aucune modification.

Dockerfile for App:

https://medium.com/media/6fad06d5ee97ef80b99340e4fad84a72/href

Dockerfile pour Nginx

https://medium.com/media/446b945d5924dea3277ff6213fc7d2d7/href

Essayons maintenant de comprendre ce qui se passe ici.

DE – utilisé pour définir l’image que nous utilisons comme point de départ de nos modifications. Dans le premier cas, nous utilisons une image python avec la balise 3.7.2-alpine3.9.
si nous n'avons pas besoin de l'image précédente, nous ne pouvons pas le définir à partir de zéro "From scratch"

ENV – définir une variable d'environnement.

COURIR – lancer une commande.

WORKDIR– changer le répertoire de base de l'image. si le répertoire n’existe pas, il le crée.

COPIE– copier des données d’un fs local vers une fs d’image

POINT D'ACCÈS—Commande qui sera exécutée à chaque initialisation de conteneur à partir de cette image.

Donc, pour le conteneur d’applications, nous installons certaines bibliothèques système nécessaires, puis nous créons un répertoire d’application dans / usr / src / app, nous y copions la configuration requise pour l’application, nous les installons, nous copions notre répertoire d’application.

Nous utilisons notre point d’entrée pour contrôler l’initialisation de PostgreSQL (car Swarm contrôle uniquement l’initialisation du conteneur et non les services qu’elle contient) et les mises à jour de Django.
Voici un autre moyen de contrôler les services: https://docs.docker.com/compose/startup-order/

https://medium.com/media/7ef6ea72b1cdc1febeae0e3f88231cc6/href

Après avoir compris comment cela fonctionne, construisons nos premières images
docker build -t [TITLE][DIRECTORY WITH DOCKERFILE]

docker build -t awsdemo-app app
docker construire -t awsdemo-nginx nginx

Maintenant, si nous appelons des images de menu fixe, nous verrons nos deux images construites 🙂

Comprendre docker-composer

Il est recommandé d’utiliser différentes versions des fichiers docker-compose.yml pour différents environnements.
Nous avons donc aussi deux d'entre eux, docker-compose.prod.yml pour prod, et docker-compose.yml pour dev environment (la différence ne concerne que le mode DEBUG et le paramètre de recharge de code pour gunicorn).

https://medium.com/media/bcddba8f543d82f0a64845d5b9dc2dbe/href

Premièrement, il existe de nombreuses versions de la syntaxe docker et docker-compose. Nous allons utiliser la 3ème version la plus récente.

Prestations de service– mise en place de conteneurs
Les volumes– configuration du stockage persistant de nos données (sur une machine locale, car nous ne voulons pas perdre de base de données ni de fichiers après chaque redémarrage du conteneur)
Les réseaux– établissement de connexions réseau entre conteneurs (pour notre cas, nous utiliserons le type de réseau le plus simple – réseau maillé)

Chaque service a un nom qui a également un domaine dans notre réseau.
Image– configuration de l'image à partir de laquelle le conteneur sera créé. Premières images locales, puis images distantes (Docker Hub, etc.)
Commander– commande à exécuter après l'initialisation du conteneur. Exécution de Gunicorn avec un code de rechargement à chaud sur le port 8000
Les ports– reliant les ports entre docker et mahcine local
Les volumes– Lier des volumes à une instance. Ici ./app/:/usr/src/app/ nous relions notre répertoire d'application local au répertoire d'application de conteneur afin de pouvoir modifier le code au moment de l'exécution sans redémarrage du conteneur
Environnement– configuration des variables env du conteneur
Dépend de– établissement de dépendances (ordre d'initialisation)
Les réseaux– connexion aux réseaux

Plus d'informations sur la syntaxe et les paramètres de composition de docker ici: https://docs.docker.com/compose/overview/

Lançons maintenant docker-compos up and open http: // localhost / pour voir le résultat.

Si les choses fonctionnent, nous pouvons passer au stade du déploiement.

Déployer

Pneu sans AWS

Par défaut, AWS vous donne 750h d'instance EC T3.micro.
Nous allons exécuter notre projet sur Ubuntu Server 18.04 LTS (HVM), Type de volume SSD – ami-34c14f4a

Cliquez sur 'Lancer l'instance'

Choisissez le serveur Ubuntu 18.04

Choisissez le type d'instance t3.micro

Cliquez sur suivant jusqu'à la page du groupe de sécurité.Ici, vous devrez ajouter All Tcp aux règles du pare-feu, de sorte que vous puissiez accéder à n’importe quel port tcp du public (pour la production, seuls les ports nécessaires).

Cliquez sur suivant jusqu'à la page du groupe de sécurité

En fin de compte, il créera une clé ssh que nous utiliserons pour accéder à l'instance.

Déploiement avec Fabric2

Pour les choses devops, je recommanderais d'utiliser Fabric2 pour les projets de taille moyenne à moyenne et Ansible pour les projets de taille moyenne à grande. Mais aujourd'hui, nous utiliserons Fabric2 car simple comme porte.

Commençons par installer pip install Fabric2

Ce que Fabric fait est essentiellement de se connecter à host sur ssh et d’exécuter des commandes pouvant être définies en tant que tâches. Entrypoint car c'est fabfile.pyet pour l'exécuter, appelez simplement fab2 COMMAND

https://medium.com/media/5a52f2c25cde344e56a27aab3d114ff6/href

Donc, ce que nous avons 4 tâches ici: Installez-instance, Set-Pass, déployer, pgdump
Après avoir créé une instance sur AWS, nous devons installer de nombreux éléments dessus avant de pouvoir exécuter docker. J'ai utilisé une approche simple, commande par ligne, mais cela peut aussi être à l'intérieur d'un fichier shell et nous pouvons simplement l'exécuter.

N'oubliez pas de changer les paramètres HOST et KEY_FILE

Votre domaine que vous pouvez trouver dans le tableau de bord AWS EC dans les paramètres d'instance (Public DNS (IPv4))

instance d'installation

  1. 19 # vérifie si le menu fixe est en cours d’exécution s’il n’est pas exécuté.
  2. 21–28 # installer des dockers
  3. 29 # initialiser le serveur principal de Docker Swarm
  4. 30–33 # Créer une clé SSH pour pouvoir extraire un github privé.
  5. 34–36 # en attente pendant que l'utilisateur ajoutera la clé à clés github ssh

6. 37 # ajout du domaine github à un hôte connu. dans le cas contraire, il le demandera au premier tirage

7. 38–41 # Créer un répertoire d'application et le cloner à partir de github

8. 42–43 # Images de construction

9. 44 # Ajoutez nos conteneurs à l'essaim. La pile est un groupe de services qui fonctionnent ensemble.

10. 45–51 # en attente du conteneur Web et tentative de définition du mot de passe django superutilisateur

$ (docker ps -q -f nom = awsdemo_web) – utilisé pour obtenir l'ID du conteneur de services. Cela ne fonctionnera pas si nous avons une réplication avec plus d'un conteneur pour le service.

déployer

Pour le déploiement, nous obtenons simplement toutes les modifications de github puis la mise à jour du service.
Mises à jour en mode Swarm en cours d'exécution sans rompre les connexions. Ancien conteneur fonctionnera jusqu'à ce que toutes les anciennes requêtes ne soient plus traitées. Toutes les nouvelles requêtes iront à la nouvelle instance de conteneur.

pgdump

Ici, nous commençons par exécuter pg_dump sur le conteneur de base de données, puis nous en copions les données dans la machine distante, puis nous utilisons Fabric2 Class Transfer pour télécharger le fichier sur notre machine locale.

Maintenant, installons toutes ces choses.

instance d'installation fab2
fab2 set-pass

Maintenant, si vous allez sur votre domaine AWS, vous devriez voir

J'espère que c'était utile 🙂


Déploiement sur AWS Free Tire avec Docker et Fabric a été publié à l'origine dans Hacker midi sur Medium, où les gens poursuivent la conversation en soulignant et en répondant à cette histoire.

Source

A propos newstrotteur-fr

Découvrez également

Lenovo apporte l’application Dial Assistant à Windows 10, disponible au téléchargement sur le Microsoft Store

Microsoft n’est pas le seul à songer à faciliter la vie des professionnels de la …

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *