Publié par Nous allons monter une infrastructure dans le Cloud AWS via CloudFormation. Il s’agit d’un script au format YAML (ou JSON) qui constituera une stack. Cette stack va monter les instances dont nous aurons besoin pour notre projet. Le projet consiste à monter un site wordpress dockerisé hautement-disponible (2 zones et un load-balancer). Un autoscaling doit être prévu et une notification via le service SNS doit être envoyée.Les instance EC2 dans un sous-réseau public, les instances RDS dans un sous-réseau privé. Le site wordpress doit être disponible immédiatement avec ses plugins (notamment une sauvegarde des fichiers dans un bucket S3. Par ailleurs, en parallèle, on montera une structure hybride: un serveur de fichiers on-premise ainsi qu’un intranet EC2 dans le Cloud: la liaison se fera par VPN.
Le service d’Infrastructure-As-Code, CloudFormation, va nous permettre d’automatiser l’infrastructure du projet, les réseaux, les routes, les instances, les pare-feux… Les fichiers peuvent être visualisés sur ce repository Github. La méthode des stacks imbriquées a été utilisée.
CloudFormation
Nous allons charger nos fichiers depuis un bucket S3.
Nous retrouvons les paramètres enregistrés dans notre stack principale.
Les sous-réseaux sont définis et on peut constater que 3 zones sont définies par défaut: 2 pour wordpress, une pour l’intranet. Puis nous cliquons sur « suivant » jusqu’à « créer une pile ».
A partir de cet instant, la stack met environ 25 minutes pour être créée.
Nous y créons:
- Un VPC
- Des sous-réseaux
- Une passerelle internet attachée au VPC
- Routage (tables associées et routes)
- IPs élastiques et passerelles NAT
- Des groupes de sécurité
- Un bucket S3 lié à un rôle IAM
- Une base de données et son réplica en zone B
- Un équilibreur de charge
- Une mise à l’échelle pour les instances WordPress dockerisées
- Un service déclenchant des alarmes (scale-up, scale-down)
- Un service de notification de ces alarmes
- Une instance EC2 VPN et une instance EC2 Intranet
Si tout va bien, nous obtenons un message « CREATE_COMPLETE » pour chaque stack imbriquée et pour la stack principale.
Allons voir le détail dans la console. Nous avons notre VPC avec le CIDR 10.0.0.0/16. Nos sous-réseaux se trouveront donc dans ce CIDR.
Nous trouvons également 6 sous-réseaux avec leur CIDR IPv4 et leur zone de disponibilité.
Aussi, une passerelle Internet a été créée et attachée au VPC. 3 passerelles NAT ont également été créées.
4 adresses IP élastiques ont été créées: 3 pour chaque passerelle NAT et une pour l’instance EC2 VPN.
Dans la console, nous trouvons également nos groupes de sécurité. Par exemple, un groupe de sécurité pour RDS avec le port 3306 ouvert.
Des NACL sont également générés automatiquement. dans le cadre de ce projet, nous resterons sur la première barrière de sécurité que constituent les groupes de sécurité.
Ci-dessous un schéma représentant la différence entre Security Group et NACL.
Enfin, nous trouvons nos tables de routage:
Nous trouvons bien nos routes: routes publiques associées à la passerelle Internet, routes privées associées à une passerelle NAT. Par ailleurs, notre bucket S3 a bien été créé.
Voyons maintenant notre base de données et son réplica.
Notre instance est bien en zone A et son réplica est bien en zone B.
Allons maintenant voir nos instances EC2. Nous avons bien nos 4 instances: 2 pour WordPress, 1 pour le VPN, 1 pour l’Intranet.
Voyons maintenant notre équilibreur de charge. Nous avons besoin d’un groupe cible d’abord, à savoir nos 2 instances EC2 WordPress.
On voit bien notre Listener sur le port 80.
Sur cette dernière image, nous pouvons voir notre équilibreur de charge sur les 2 zones de disponibilité. Il nous faut également un groupe de mise à l’échelle relié au LoadBalancer ainsi qu’une configuration de lancement. Nous aurons 2 instances minimum, 3 maximum.
Voici notre configuration de lancement. Nous pouvons également afficher les données utilisateur.
Dans le groupe Auto Scaling, nous pouvons également retrouver nos 2 politiques de mise à l’échelle.
Enfin, nos alarmes CloudWatch sont configurées et le service SNS est bien configuré. Nous recevons le mail de confirmation.
Le site WordPress:
Nous y avons accès grâce au nom du DNS de l’équilibreur de charge.
Accédons maintenant à la partie administrateur: nous trouvons bien notre plugin S3.
Ajoutons maintenant un fichier dans les médias.
Puis regardons dans le bucket S3 créé pour stocker les médias des instances WordPress. Nous trouvons bien le même fichier.
Vérifions maintenant le crash d’une instance EC2 et vérifions qu’une autre se régénère instantanément.
Une nouvelle instance se recrée dans la même zone de disponibilité que celle qui a été résiliée.
Nous avons toujours accès à notre site wordpress.
Il nous reste maintenant 2 points à aborder:
- Le container Docker
- Le scale-up et la vérification de la création d’une troisième instance.
Concernant Docker, nous nous sommes basés sur le cours Openclassrooms de Maxence Maireaux.
Nous avons utilisé l’image WordPress Conetix (cette image intègre déjà la CLI de WordPress). Nous démarrons le conteneur grâce à la commande docker run.
Puis les commandes docker exec core config et docker exec core install afin d ‘entrer les données dans le fichier wp-config.php et pour qu’elles soient automatiquement intégrées. Aussi, nous inscrivons les informations liées au bucket S3 dans ce même fichier wp-config.php.
Connectons-nous sur une instance WordPress. Avec la commande docker ps, nous verrons bien notre container lancé. Si nous l’arrêtons, nous n’aurons plus accès à notre site WordPress. Notre WordPress est donc bien dockerisé.
Si nous accédons au fichier wp-config.php, nous constaterons que les informations ont bien été rentrées.
Nous allons maintenant tester la montée en charge en augmentant la charge du CPU sur chaque instance grâce à un stress test grâce à l’outil stress.
Nous constatons bien une alarme car le processeur est utilisé à plus de 80%. Nous recevons une notification par mail grâce au service SNS.
Nous constatons que la troisième instance est bien créée.
Si nous arrêtons le stress test, nous repassons alors à 2 instances WordPress.
Connexion à l’instance VPN via SSH
La liaison OpenVPN transite via le port 1194.
Le tunnel sera établi entre les adresses 10.0.0.1 et 10.0.0.2
2 routes ont été ajoutées et concernent le réseau on-premise.
Nous allons d’ailleurs ouvrir le port 1194 sur notre routeur et utiliser VirtualBox pour créer nos 2 serveurs sous Linux.
- Un routeur VPN (interfaces: bridge et réseau interne)
- Un serveur de fichiers (interface réseau internet)
Puis, nous allons sur notre routeur VPN on-premise sous VirtualBox et récupérons la clé VPN.
Ensuite, nous configurons le fichier de configuration avec le port, la clé et les routes AWS.
Enfin, nous démarrons le service sur l’instance VPN AWS et sur le routeur VPN.
Nous pouvons par ailleurs, vérifier la nouvelle interface.
Enfin, nous vérifions les pings depuis l’instance AWS.
Nous vérifions aussi les pings depuis le serveur de fichiers.
Enfin, nous démarrons une machine Ubuntu Desktop afin de vérifier l’accès à l’intranet via le VPN.
Nous avons vu un aperçu d’AWS. Ce projet peut être approfondi avec Amazon Route53, Amazon CloudFront, Amazon Glacier, Amazon CodeDeploy ou encore AWS CodeDeploy par exemple…
