Introduction au Lab 1

Ce premier TP constitue notre introduction au déploiement d’applications dans un environnement cloud. L’objectif est de comprendre les différences fondamentales entre un déploiement local, un déploiement via une plateforme PaaS (Platform as a Service) comme Render, et un déploiement via une infrastructure IaaS (Infrastructure as a Service) comme AWS EC2. À travers ces exemples pratiques, nous allons progressivement prendre en main les outils essentiels de DevOps, en commençant par déployer une simple application Node.js “Hello, World!“.


Example: Run the Sample App Locally

Mise en place de l’environnement

Dans un premier temps, nous créons la structure de répertoires nécessaire pour stocker le code des différents exemples du cours. On crée un dossier devops-base et on y crée la structure pour le chapitre 1 :

$ mkdir devops_base
$ cd devops_base
$ mkdir -p ch1/sample-app
$ cd ch1/sample-app

Création de l’application Node.js

Ensuite, dans le dossier ch1/sample-app, on crée le fichier app.js qui contient notre application “Hello, World!” :

$ nano app.js
const http = require('http');
 
const server = http.createServer((req, res) => {
  res.writeHead(200, { 'Content-Type': 'text/plain' });
  res.end('Hello, World!\n');
});
 
const port = process.env.PORT || 8080;
server.listen(port, () => {
  console.log(`Listening on port ${port}`);
});

Cette application fait deux choses, elle répond à toutes les requêtes avec un code 200 et le texte “Hello, World!”, et elle écoute sur le port défini par la variable d’environnement PORT, ou par défaut sur le port 8080.

Lancement de l’application

On lance l’application avec la commande node app.js.

$ node app.js
Listening on port 8080

On ouvre ensuite dans notre navigateur http://localhost:8080 et on obtient bien le message “Hello, World!“. L’application fonctionne correctement en local.

Navigateur Navigateur


Deploying An App Using PaaS

Présentation de Render

Render est une plateforme PaaS (Platform as a Service) qui propose un tier gratuit, ce qui nous permet de tester le déploiement sans coût. Contrairement à AWS EC2 qui est une solution IaaS donnant accès directement aux ressources serveur, Render enlève toute la complexité de l’infrastructure et se concentre sur le packaging de l’application, pipelines de déploiement, gestion des bases de données, etc.

Étapes de déploiement

Étape 1 : Création d’un compte Render

On crée un nouveau compte sur Render.

Étape 2 : Déploiement d’un nouveau web service

Depuis le Render Dashboard, on clique sur le bouton “Deploy a Web Service”. On sélectionne l’onglet “Public Git Repository” et on entre l’URL du dépôt Git public contenant notre application Node.js. On clique sur “Connect”, puis on configure le web service avec les valeurs données dans le sujet.

On laisse les autres paramètres à leurs valeurs par défaut et on clique sur “Deploy Web Service” pour lancer le déploiement.

Étape 3 : Test de l’application

Après quelques minutes, le log de déploiement affiche “Your service is live”. En haut à gauche de la page, on récupère l’URL générée automatiquement par Render. On ouvre cette URL dans le navigateur et on obtient bien “Hello, World!“.


Deploying an App Using IaaS

Présentation d’AWS EC2

AWS (Amazon Web Services) est la solution IaaS choisie pour ce lab car elle propose un tier gratuit généreux et une large gamme de services cloud fiables. Contrairement à Render, EC2 nous donne un accès direct aux ressources serveur, ce qui offre plus de flexibilité mais demande plus de configuration.

Étapes de déploiement

Étape 1 : Création d’un compte AWS et d’un utilisateur IAM

On crée un compte sur https://aws.amazon.com. Pour des raisons de sécurité, on ne travaille pas avec le compte root. On crée donc un utilisateur IAM via la console IAM en lui attribuant la politique AdministratorAccess. On sauvegarde les identifiants (URL de connexion, nom d’utilisateur, mot de passe) dans un gestionnaire de mots de passe sécurisé.

Étape 2 : Lancement de l’instance EC2

On se connecte avec l’utilisateur IAM et on se rend sur la console EC2. On clique sur “Lancer une instance” et on configure l’instance avec les paramètres suivants :

  • Name : sample-app
  • AMI : Amazon Linux 2023 (tier gratuit)
  • Instance type : t3.micro
  • Key pair : “Proceed without a key pair”
  • Firewall : on crée un nouveau Security Group en activant uniquement “Allow HTTP traffic from the internet” (port 80)

Création de l'instance EC2 Création de l’instance EC2

Étape 3 : Ajout du script User Data

Ensuite dans la section “Données utilisateur”, on copie le script User Data qui sera exécuté au premier démarrage de l’instance :

Ajout du script Ajout du script

Ce script installe Node.js, écrit le code de l’application dans un fichier app.js (en écoutant sur le port 80 cette fois, celui ouvert dans le Security Group), puis lance l’application en arrière-plan avec nohup.

Étape 4 : Test du déploiement

Une fois l’instance passée de l’état “Pending” à “Running”, on récupère son adresse IP publique dans les détails de l’instance. On ouvre l’url dans notre navigateur (en veillant à bien taper http:// et non https://) et on obtient bien “Hello, World!“.

Instance créée Instance créée

Navigateur instance Navigateur instance

Étape 5 : Résiliation de l’instance

Une fois les tests terminés, on résilie l’instance en sélectionnant “État de l’instance” afin d’éviter toute facturation inattendue.

Résiliation instance Résiliation instance

Résiliation instance 2 Résiliation instance 2


Conclusion

Ce premier TP nous a permis de prendre en main les bases du déploiement d’applications dans le cloud. Avec Render (PaaS), le déploiement est rapide et ne nécessite aucune configuration d’infrastructure. Avec AWS EC2 (IaaS), nous avons un contrôle total sur le serveur, mais cela demande de configurer manuellement le Security Group, le script User Data, et la gestion des processus.

Travailler sur ces deux applications met en évidence un compromis fondamental en DevOps : facilité d’utilisation face au contrôle et à la flexibilité. L’approche EC2 avec User Data présentée ici reste simplifiée et comporte des limites que nous règlerons dans les labs suivants grâce à des outils d’automatisation plus robustes comme Ansible, Packer et OpenTofu.