DevOps, Cloud & Microservices

Mise en place d'un pipeline CICD avec Jenkins & Ansible, pour la stack Odoo, PostgreSQL, pgAdmin

Carlin FONGANG — Tue, 07 May 2024 19:22:45 GMT

LinkedIn | GitLab | GitHub | Credly

1. Introduction

Le déploiement continu et l'intégration continue (CI/CD) sont des pratiques essentielles dans le développement de logiciels modernes, permettant aux équipes de livrer des applications avec plus de rapidité, fiabilité et sécurité. Ce projet vise à établir un pipeline CI/CD utilisant Jenkins et Ansible pour automatiser le déploiement de plusieurs applications, incluant Odoo, PostgreSQL, pgAdmin, et une application web personnalisée nommée ic-webapp.

1.1. Objectifs

Le principal objectif de ce lab est de mettre en place une infrastructure automatisée qui permettra non seulement d'accélérer le processus de déploiement des mises à jour logicielles mais aussi de minimiser les risques d'erreurs humaines. Cela sera bénéfique pour améliorer la continuité des opérations commerciales et optimiser la gestion des ressources. Plus précisément, le projet vise à :

- Automatiser : Automatiser le processus de déploiement des applications pour garantir des livraisons rapides et sans erreur.

- Sécuriser : Assurer que toutes les configurations et les déploiements se font dans un environnement sécurisé pour protéger les données et les services.

- Documenter : Fournir une documentation claire et détaillée qui peut être utilisée pour la maintenance et l'évolution future du système.

1.2. Aperçu des technologies utilisées

Pour atteindre ces objectifs, le pipeline CI/CD sera construit en utilisant :

- Jenkins : Un serveur d'automatisation open source qui offre un large éventail de plugins pour supporter la construction et le déploiement de divers projets logiciels.

- Ansible : Un outil d'automatisation qui permet de configurer des systèmes, déployer des logiciels, et orchestrer des tâches plus avancées telles que la gestion de la configuration continue.

- Docker : Utilisé pour la conteneurisation des applications, garantissant ainsi que les logiciels fonctionnent de manière uniforme et cohérente à travers différents environnements de développement et de production.

- Git : Système de contrôle de version pour gérer les changements dans les documents, les programmes, et d'autres collections d'informations liées au développement du logiciel.

- Terraform : Terraform est un outil de gestion d'infrastructure sous forme de code (Infrastructure as Code - IaC) développé par HashiCorp.

1.3. Aperçu de l'Architecture

Le pipeline sera configuré pour gérer les déploiements sur trois serveurs différents, chacun hébergé sur le cloud (AWS) ou en On Premises, selon la préférence et les ressources disponibles. Chaque serveur jouera un rôle spécifique dans l'architecture globale :

- Serveur Jenkins : Gère l'intégration et le déploiement continu des applications.

- Serveur Applications : Héberge les applications web ic-webapp et pgAdmin.

- Serveur Odoo : Exécute l'application de gestion Odoo et sa base de données PostgreSQL.

- Un nœud Jenkins : C'est une instance qui permettra d'étendre les capacités de l'instance Jenkins maître. cet agent permettra d'exécuter les tâches assignées par l'instance maître et permettent une distribution efficace des charges de travail

La documentation suivante détaillera chaque aspect du pipeline, de l'installation et la configuration des outils à la création et l'exécution des scripts de déploiement, en passant par la gestion des erreurs et des versions.

2. Prérequis

Avant de mettre en place le pipeline CI/CD avec Jenkins, Docker, Ansible, et Terraform pour le déploiement de la stack Odoo, Postgres, pgAdmin, et une application Python, il est essentiel de s'assurer que tous les prérequis suivants sont correctement installés et configurés :

2.1. Configuration des serveurs

1. Serveur Jenkins : Une instance (AWS t2.medium recommandé) où Jenkins sera installé, qui servira à orchestrer le pipeline CI/CD.

2. Serveur Applications : Une instance (AWS t2.micro recommandé) pour héberger les applications web vitrine ic-webapp et pgAdmin.

3. Serveur Odoo : Une instance (AWS t2.micro recommandé) qui sera dédiée à l'application Odoo et la base de donnée sous Postgres.

4. Un nœud Jenkins : C'est une instance qui permettra d'étendre les capacités de l'instance Jenkins maître. cet agent permettra d'exécuter les tâches assignées par l'instance maître et permettent une distribution efficace des charges de travail

Chaque serveur doit disposer d'une connectivité réseau appropriée (SSH avec clés, acces via le protocole TCP dans les ingress ...).au niveau des security groups

2.2. Logiciels nécessaires (Jenkins, Docker, Ansible, Git)

1. Jenkins : Une instance Jenkins doit être préinstallé et configuré pour gérer les jobs et orchestrer le pipeline. >> Comment installer Jenkins

2. Docker : Docker doit être installé sur les instance pour permettre la conteneurisation des applications. Cela inclut Docker Engine et, Docker Compose pour gérer les applications multi-conteneurs (nous utiliserons Ansible pour simplifier cette tache). >> Comment installer Docker

3. Ansible : Ansible est utilisé pour l'automatisation de la configuration et du déploiement des applications sur les serveurs. Il doit être installé sur le serveur Jenkins pour exécuter les playbooks. >> Comment installer Ansible

4. Git : Nécessaire pour le versionnage des codes source et des configurations d'infrastructures. Git doit être installé sur le serveur Jenkins pour permettre le clonage des dépôts et la gestion des versions. Terraform (optionnel) : Si utilisé, Terraform doit être configuré pour gérer l'infrastructure sous forme de code, ce qui permet un déploiement et une gestion dynamiques des ressources cloud.

5. Terraform : (optionnel), installé sur une machine tièrce, nous perettra de provisionner les défferentes instances dont nous aurons besoin. >> Comment installer Terraform

2.3. Connaissances Requises

Compréhension de CI/CD : Une compréhension de base des concepts de l'intégration continue et du déploiement continu.

Base en scriptage : Connaissance en Bash pour scripts shell et en YAML pour les configurations Docker et Ansible.

Administration système : Compétences en gestion de systèmes Unix/Linux, notamment pour la configuration réseau, la gestion des processus, et la surveillance.

Gestion de réseau : Connaissance des concepts réseau de base, essentiels pour configurer correctement les interactions entre les différents services et applications.

3. Configuration de l'Infrastructure

3.1. Provisionner des instances à l'aide de terraform avec gitlab comme outil de remote state

Dans ce depôt, vous retrouverez des explication sur comment utiliser les modules terraform proposer pour provisionner une instance ec2 en utilisant gitlab comme remote state manager ou même la solution s3 de AWS pour le même rôle :

\>> Provisionner une instance ec2 grâce à Terraform

3.2 Préparation de Jenkins

3.2.1. Installation de Jenkins

Pour l'installation de Jenkins, se référer à la documentation : Installation de Jenkins sur une instance ec2 (AWS)

3.2.2. Configuration de l'agent Jenkins (slaves)

La configuration des agents Jenkins, également appelés "nœuds" ou "slaves", est une étape cruciale pour étendre les capacités d'un instance Jenkins maître. Ces agents exécutent les tâches assignées par l'instance maître et permettent une distribution efficace des charges de travail, surtout lors de l'exécution de plusieurs jobs ou de jobs particulièrement lourds. La mise en place correcte des agents assure une meilleure scalabilité et optimisation des ressources dans un environnement CI/CD.

Pour mettre en œuvre cette solution, nous allons provisionner, grace à terraform une nouvelle instance qui servira de noeud à l'instance master Jenkins en utilisant le IaaC terraform proposé plus haut, où en provisionnant une instance manuellement dépuis la console aws

Installation de Java

Une fois connecté en ssh à notre instance ec2 qui devra servir de noed, entrez les commandes suivantes depuis le terminal

sudo apt update
sudo apt install openjdk-11-jdk -y

3.2.3. Configuration de Jenkins

Plugin requis

Installer le plugins : SSH Build Agents

Ce plugin permet à Jenkins de se connecter et de lancer des agents sur des machines distantes via SSH.

Crédentials

Se rendre dans "Manage Jenkins" > "Manage Credentials".
Ajoutez une nouvelle credential de type "SSH Username with private key".
Entrez le nom d'utilisateur de votre instance EC2 et la clé privée que vous avez configurée pour l'accès SSH.

Ajouter un nouvel agent

Allez dans "Manage Jenkins" > "Manage Nodes and Clouds".
Cliquez sur "New Node".
Entrez un nom pour le nœud, sélectionnez "Permanent Agent", puis cliquez sur "Create".

Création d'un node sous Jenkins

Configurez les paramètres de l'agent :

Remote root directory: Un chemin dans lequel Jenkins peut exécuter des builds (/home/ubuntu/jenkins_path).
Labels: Des étiquettes pour identifier l'agent.
Usage: Déterminez comment cet agent sera utilisé (exclusivement ou laissé à Jenkins pour décider).
Launch method: Sélectionnez "Launch agents via SSH".
Host: L'adresse IP ou le DNS de votre instance EC2.
Credentials: Sélectionnez les credentials SSH que vous avez créés.
Host Key Verification Strategy: Choisissez "Non verifying Verification Strategy" pour simplifier, mais pour plus de sécurité, il est recommandé de configurer une stratégie de vérification.

Lancement de l'agent

Une fois tout configuré, Jenkins essaiera de se connecter à l'instance EC2 et de démarrer l'agent lorsqu'un build doit être exécuté sur ce nœud. Vous pouvez vérifier le statut de l'agent dans la section "Manage Nodes and Clouds" pour vous assurer qu'il est connecté correctement.

Agent Jenkins en ligne

3.3. Configuration du gestion SCM

se rendre dans l'option ConfigureTools où à l'adresse : http://public_ip_address_jenkins_instance/configureTools/

Mettre à jour le repertoire de git pour la prise en charge du build

4. Développement du Pipeline (CI)

4.1. Structure générale du pipeline (stages)

Structure Générale du Pipeline CI/CD

La mise en place d'un pipeline CI/CD pour la solution Odoo, PostgreSQL, pgAdmin, et une application web vitrine nécessite une structuration claire et détaillée des étapes de build, test, release et déploiement.

Voici un aperçu de la structure générale du pipeline qui sera implémentée dans Jenkins pour automatiser l'ensemble du processus de développement et de déploiement.

Stages du Pipeline

Initialisation :

Checkout : Récupération du code source depuis le système de gestion de version. Préparation de l'environnement : Installation des dépendances nécessaires pour le build et le test.

Build :

Construction des images Docker : Pour l'application vitrine une image Docker est construite en utilisant un Dockerfiles spécifique.

Tests :

health check : Exécution d'une commande shell pour vérifier la disponibilité du service une fois le conteneur test lancée.

Release :

Tagging des images : Attribution de tags à l'images Docker construite, en utilisant un identifiants de version ou des hashes de commit pour la traçabilité de la release. Push des images : Envoi des images vers un registre Docker pour stockage et récupération lors du déploiement.

Déploiement :

Déploiement : Déploiement de chaque stack (odoo+postgres et pgadmin+ic-webapp) sur les serveurs de production distinct.

Intégration et Déploiement Continus

Le pipeline est conçu pour permettre une intégration et un déploiement continus, où chaque commit dans le dépôt de code (Gitlab) déclenche automatiquement un nouveau cycle de ce pipeline. Cette automatisation assure que toutes les modifications sont rapidement testées et prêtes à être déployées, minimisant ainsi le temps de mise en marché et augmentant la réactivité aux besoins des utilisateurs.

4.2. Détails de chaque étape du pipeline

4.2.1 Déclaration des variables

Dans le Jenkinsfile, la section des variables d'environnement joue un rôle crucial en définissant les paramètres qui seront utilisés à travers les différentes étapes du pipeline.

   environment {
        IMAGE_NAME = "ic-webapp"
        IMAGE_TAG = "latest"
        LOCAL_TAG = "1.0"
        IP_ANSIBLE = "18.211.168.237"
        IP_ODOO = "54.226.148.2"
        IP_PGADMIN = "54.209.185.19"
        JENKINS_PATH = "jenkins_path"
        USER_SERVER = "ubuntu"
        REPO_ODOO = "https://gitlab.com/CarlinFongang-Labs/projet-odoo/deploy-odoo-postgresql-pgadmin/odoo-postgresql-ansible.git"
        REPO_PGADMIN = "https://gitlab.com/CarlinFongang-Labs/projet-odoo/deploy-odoo-postgresql-pgadmin/pgadmin-webapp-with-ansible.git"
    }
    agent {
        label 'runner_ec2_aws'
    }

Voici une explication de chaque variable et son importance dans le processus de CI/CD :

Variables générales

IMAGE_NAME: Nom de l'image Docker qui sera construite et déployée. Cela permet de personnaliser et de reconnaître facilement l'image au sein des registres Docker.

IMAGE_TAG: Tag de l'image Docker pour la version la plus récente. Utiliser latest permet de s'assurer que la dernière version de l'image est toujours utilisée là où c'est nécessaire.

LOCAL_TAG: Une version spécifique de l'image, ici "1.0", qui peut être utilisée pour assurer un suivi de versions spécifiques ou pour des déploiements ciblés.

IP_ANSIBLE, IP_ODOO, IP_PGADMIN: Adresses IP des serveurs sur lesquels les différentes applications seront déployées. Ces adresses permettent à Ansible de cibler correctement les machines pour le déploiement

Chemins et références

JENKINS_PATH: Le chemin dans le système de fichiers où Jenkins stocke les données de travail. Cela peut inclure des scripts, des fichiers temporaires ou des configurations spécifiques à Jenkins.

USER_SERVER: Nom d'utilisateur utilisé pour les connexions SSH lors des déploiements Ansible. Typiquement, ubuntu est le nom d'utilisateur par défaut pour les instances EC2 Ubuntu sur AWS.

Références de répertoire Git

REPO_ODOO: URL du dépôt Git contenant les configurations et les scripts Ansible pour déployer l'application Odoo. Ce lien est essentiel pour permettre au pipeline de récupérer les dernières configurations et scripts nécessaires au déploiement. REPO_PGADMIN: URL du dépôt Git pour les configurations de pgAdmin. Cela assure que les scripts et configurations nécessaires pour déployer pgAdmin sont accessibles et à jour.

Configuration de l'agent Jenkins

agent { label 'runner_ec2_aws' }: Définit l'agent Jenkins qui exécutera le pipeline. Ici, runner_ec2_aws fait référence au label assigné à un notre agents Jenkins configurés précédement et qui fonctionne dans un environnement AWS. Cela garantit que les tâches du pipeline sont exécutées dans l'environnement approprié.

4.2.2. Build: Création de l'image Docker

La phase de build est une étape crutiale dans notre pipeline CI/CD où le code source de notre application est transformé en un artefact. Pour notre application vitrine, cette phase est orchestrée à l'aide de Docker, qui nous permet de construire une image contenant tout le nécessaire pour exécuter notre application.

4.2.3. Déclaration des secrets

Pour renseigner des secrets dans Jenkins et les utiliser de manière sécurisée dans des pipelines, nous pouvons configurer et utiliser les secrets comme des mots de passe, des clés SSH, des tokens API, et d'autres informations sensibles :

1: Accéder aux Credentials dans Jenkins Allez dans le menu principal, cliquez sur "Manage Jenkins". Choisissez "Manage Credentials".

2: Choisir le Scope des Credentials Sous "Stores scoped to Jenkins", cliquez sur "(global)" pour définir les credentials qui sont accessibles à tous les jobs, ou choisissez un domaine spécifique si vous voulez restreindre l'accès à certains jobs ou pipelines.

3: Ajouter un Nouveau Credential

Cliquez sur "Add Credentials" sur le côté gauche.
Choisissez le type de credentials que vous souhaitez ajouter. Les options courantes incluent :
Username with password – pour les combinaisons nom d'utilisateur/mot de passe.
Secret text – pour les tokens API ou les secrets arbitraires.
SSH Username with private key – pour les connexions SSH sécurisées.
Certificate – pour l'authentification basée sur certificat.
Remplissez les champs nécessaires, tels que :
Scope: Choisissez "Global" (accessible de partout) ou "Jenkins" (limité à des jobs spécifiques).
ID: Laissez ce champ vide pour autogénérer un ID, ou entrez un identifiant personnalisé.
Description: Fournissez une description claire pour identifier ce credential dans la liste.
Username, Password/Secret, Private Key, etc., selon le type de credential ajouté.

\>\> Découvrez comment créer un token éphémère Dockerhub

Description du Dockerfile

Le Dockerfile défini pour une application utilisant Python 3.6 basé sur une image Alpine Linux, cette image est choisie car offre une grande légèreté et une bonne sécurité. Voici les étapes détaillées du processus de build :

ARG version="3.6-alpine"
FROM python:${version}

LABEL desciption="ic-webapp"
LABEL maintainer="Carlinfg "

WORKDIR /opt

# Installer Flask and git
RUN apk update && \
    apk add --no-cache git bash gawk && \
    pip install Flask

RUN git clone https://github.com/LaboCloud/ic-webapp.git /opt


# Copy the releases.txt file into the working directory
COPY releases.txt /opt/releases.txt
COPY env_vars.sh /opt/env_vars.sh

# Permissions
RUN chmod +x /opt/env_vars.sh && \
    chmod +x env_vars.sh

# Set environment variables
ENV ODOO_URL=$ODOO_URL
ENV PGADMIN_URL=$PGADMIN_URL

# Port
EXPOSE 8080

# Start
ENTRYPOINT ["sh", "-c", "source /opt/env_vars.sh", "-s"]
CMD ["python", "app.py"]

1. Base et dépendances :

Image de base : L'image de base est python:3.6-alpine. Alpine est choisie pour sa simplicité et sa petite taille.

Installation de Dépendances : Installation de Git, Bash et Gawk. Ces outils sont nécessaires pour cloner le répertoire du projet et exécuter des scripts shell.

2. Récupération du code source :

Le code source de l'application est cloné depuis un dépôt Git externe directement dans le répertoire de travail /opt du conteneur.

3. Configuration de l'environnement :

Fichiers de configuration : Les fichiers releases.txt et env_vars.sh sont copiés dans le conteneur. Ces fichiers contiennent respectivement les variables de configuration et un script pour initialiser ces variables d'environnement.

Permissions : Des permissions d'exécution sont attribuées au script env_vars.sh pour assurer sa bonne exécution. Variables d'Environnement : Les variables ODOO_URL et PGADMIN_URL sont définies dans l'environnement du conteneur à partir des valeurs extraites par le script env_vars.sh.

4. Exposition de port et démarrage :

Le port 8080 est exposé pour permettre l'accès à l'application depuis l'extérieur du conteneur.

ENTRYPOINT ["sh", "-c", "source /opt/env_vars.sh", "-s"] : Le conteneur est configuré pour exécuter le script env_vars.sh au démarrage, suivi de la commande python app.py pour démarrer l'application Flask.

Description du script "env_vars.sh"

Ce script Bash, destiné à être utilisé dans notre conteneur, il nous permet de gère les variables d'environnement pour les URL de d'Odoo et pgAdmin, en fonction de leur présence dans un fichier de configuration releases.txt.

présente brièvement ce script 

#!/bin/bash
releases_file_path="/opt/releases.txt"

if test -f "$releases_file_path"; then
   export ODOO_URL=$(awk -F ': ' '/ODOO_URL/ {print $2}' $releases_file_path)
   export PGADMIN_URL=$(awk -F ': ' '/PGADMIN_URL/ {print $2}' $releases_file_path)
else
   echo "Les URL par défaut des variables ODOO_URL and PGADMIN_URL, vont être utilisées"
fi

exec "$@"

Une fois les instances destinées à accueillir Odoo et pgAdmin provisionnées et les adresses IP connues, nous pourrons renseigner ces IP/EIP dans le fichier releases.txt afin que ces dernieres soient prise en compte et embarquées dans l'image docker lors de la phase de build dans le pipeline Jenkins.

Notre fichier releases.txt se présente sous le formation suivant :

ODOO_URL: http://54.226.148.2:8090
PGADMIN_URL: http://54.209.185.19:8080
VERSION: 2.0

pour mettre en œuvre la tache de build du Dockerfile préalablement défini dans un pipeline Jenkins, nous allons rédiger un script groovy approprié à cette tâche :

        stage('Build image') {
            steps {
                script {
                    sh 'which git'
                    sh 'docker build -t $IMAGE_NAME:$LOCAL_TAG .'
                }
            }
        }

4.2.4. Test d'acceptation

Dans la phase de "Test d'acceptation" de notre pipeline Jenkins, l'application est d'abord déployée dans un environnement de conteneur isolé pour simuler son comportement en production et ensuite testé.

        stage('Run contenair') {
            //agent { docker { image 'alpine' } }
            steps {
                script {
                    sh 'docker run -d -p 8080:8080 --name $IMAGE_NAME-test $IMAGE_NAME:$LOCAL_TAG'
                    sh 'sleep 5'
                    sh 'sudo apt install curl -y'
                }
            }
        }
        stage('Test image') {
            agent any
            steps {
                script {
                    sh '''
                        docker ps
                        IP_TEST=$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' "$IMAGE_NAME-test")
                        response=$(curl -s -o /dev/null -w "%{http_code}" "http://$IP_TEST:8080")
                        if [ "$response" -eq 200 ]; then
                            echo "La connexion au conteneur est réussie."
                        else
                            echo "Erreur: La connexion au conteneur a échoué avec le code de réponse HTTP $response."
                        fi
                    '''  
                }
            }
        }

Voici les étapes principales :

Lancement du conteneur : Un conteneur Docker est démarré à partir de l'image construite précédemment, exposant l'application sur le port spécifié.

Installation de Curl : Curl est installé pour faciliter les tests HTTP, permettant de faire des requêtes simples pour tester la connectivité et la réponse de l'application.

Validation du service :

Récupération de l'IP : L'adresse IP interne du conteneur est récupérée, ce qui est utilisé pour adresser les requêtes de test.
Requête HTTP : Une requête HTTP est envoyée à l'application via la commande Curl. Le code de réponse HTTP est vérifié pour s'assurer qu'il est égal à 200, indiquant que l'application répond correctement et est prête pour le déploiement. Si le code est différent, une erreur est signalée indiquant un échec de connexion.

4.2.5 Stop Test: Nettoyage post-tests

        stage('Clean Test') {
            agent any
            steps {
                script {
                    sh '''
                        docker stop ${IMAGE_NAME}-test && docker rm ${IMAGE_NAME}-test
                    '''
                }
            }
        }

Le stage "Clean Test" dans notre pipeline Jenkins permet de maintenir un environnement de build propre et gérer efficacement les ressources. Ce stage est spécifiquement mis en place pour nettoyer les conteneurs Docker qui ont été utilisés pour les tests, assurant qu'aucun artefact ou état résiduel ne compromet les exécutions futures du pipeline.

4.2.6. Release: tag des images et gestion des versions

Le stage "Release Docker image" joue un rôle central dans notre pipeline de CI/CD en s'assurant que l'image Docker construite et testée est publiée sur DockerHub. Ce processus permet de rendre les images disponibles pour un déploiement ultérieur sur différents environnements ou pour être utilisées par d'autres parties prenantes du projet.

        stage('Release Docker image') {
            environment {
                DOCKERHUB_USER = credentials('DHUB_USER')
                DOCKERHUB_TOKEN = credentials('DHUB_TOKEN')        
            }
            agent any
            steps {
                script {                    
                    sh 'docker tag $IMAGE_NAME:$LOCAL_TAG $DOCKERHUB_USER/$IMAGE_NAME:$IMAGE_TAG'
                    sh 'docker tag $IMAGE_NAME:$LOCAL_TAG $DOCKERHUB_USER/$IMAGE_NAME:$GIT_COMMIT'
                    sh 'echo $DOCKERHUB_TOKEN | docker login -u $DOCKERHUB_USER --password-stdin'
                    sh 'docker push $DOCKERHUB_USER/$IMAGE_NAME:$IMAGE_TAG'
                    sh 'docker push $DOCKERHUB_USER/$IMAGE_NAME:$GIT_COMMIT'  
                    sh 'echo "Publication de l image sur DockerHub..." '
                }
            }
        }

5. Utilisation d'Ansible pour le déploiement (CD)

5.1. Création des rôles Ansible pour Odoo, postgres, pgAdmin et ic-webapp

5.1.1. Utilisation des docker-compose dans Ansible pour la création d'un role, playbook odoo et postgres

Description du role odoo

Organisation des répertoires du rôle

5.1.2 Structure du role Ansible pour Odoo

1. Variables (vars/main.yml et defaults/main.yml):

vars/main.yml: Contient les configurations spécifiques nécessaires pour le déploiement, comme les images Docker pour Odoo et PostgreSQL, les ports, et les volumes.

defaults/main.yml: Définit les valeurs par défaut qui peuvent être utilisées globalement ou surchargées spécifiquement lors de l'exécution du playbook.

2. Template Docker Compose (templates/odoo-template.yml.j2):

Ce fichier est un modèle Jinja2 pour Docker Compose qui configure les services Odoo et PostgreSQL. Il inclut des directives pour les volumes, les réseaux, et les secrets nécessaires pour sécuriser la communication entre les services.

version: '3.7'

services:
  odoo_web_service:
    image: {{ ODOO_IMAGE }}
    depends_on:
      - db
    ports:
      - "{{ ODOO_PORT }}:8069"
    volumes:
      - "{{ ODOO_DATA_VOLUME }}:/var/lib/odoo"
      - "{{ ODOO_CONFIG_VOLUME }}:/etc/odoo"
      - "{{ ODOO_ADDONS_VOLUME }}:/mnt/extra-addons"
    networks:
      - odoo_network
    environment:
      - PASSWORD_FILE=/run/secrets/postgresql_password
    secrets:
      - postgresql_password
    restart: always

  db:
    image: {{ POSTGRES_IMAGE }}
    environment:
      - POSTGRES_DB={{ POSTGRES_DB }}
      - POSTGRES_PASSWORD_FILE=/run/secrets/postgresql_password
      - POSTGRES_USER={{ POSTGRES_USER }}
      - PGDATA=/var/lib/postgresql/data/pgdata
    volumes:
      - "{{ POSTGRES_DATA_VOLUME }}:/var/lib/postgresql/data/pgdata"
    secrets:
      - postgresql_password
    networks:
      - odoo_network
    restart: always

networks:
  odoo_network:
    driver: bridge

volumes:
  {{ ODOO_DATA_VOLUME }}:
  {{ POSTGRES_DATA_VOLUME }}:

secrets:
  postgresql_password:
    file: {{ POSTGRES_PASSWORD_FILE }}

ce template reprend intégralement la structure d'un docker compose conventionnel et intègre des variable ansible, ce qui le rend flexible et réutilisable selon le contexte

Tâches Ansible (tasks/main.yml):

Création du répertoire Docker Compose:

- name: Ensure the Docker Compose directory exists
  ansible.builtin.file:
    path: "{{ odoo_compose_directory }}"
    state: directory

Cette tâche crée le répertoire où le fichier Docker Compose sera stocké et ensuite exécuté, cela permet de s'assurer de l'emplacement du fichier avant toutes actions futures

Gestion des secrets

- name: Ensure odoo_pg_pass exists
  ansible.builtin.file:
    path: "{{ POSTGRES_PASSWORD_FILE }}"
    state: touch
    mode: '644'
  become: true

Cette tache permet de s'assure que le fichier contenant le mot de passe PostgreSQL existe et est accessible.

Déploiement de la configuration Docker Compose:

- name: Deploy Odoo Compose configuration
  ansible.builtin.template:
    src: "{{ odoo_compose_file }}"
    dest: "{{ odoo_compose_directory }}/odoo-compose.yml"
  become: true

Cette tache permet de déployer le fichier Docker Compose dans le répertoire spécifié en utilisant le template Jinja2 précédent.

Exécution de Docker Compose

- name: Run Docker Compose
  ansible.builtin.shell:
    chdir: "{{ odoo_compose_directory }}"
    cmd: "docker-compose -f odoo-compose.yml up -d"
  become: true

Lance les services spécifiés dans le fichier Docker Compose, démarrant ainsi les conteneurs pour Odoo et PostgreSQL.

Pour en savoir plus : Le role odoo et postgres est disponible sur le dépôt via ce lien

Vous pourrez y consulter les variables utilisées ainsi que leurs roles et comment les ajuster

Déploiement de la stack Odoo

Pour mettre en œuvre le stage correspondant au déploiement de la stack Odoo, ayant le role déjà disponible, nous avons commencé par rédigé un playbook, qui à été intégré par la suite dans le stage

Description du playbook odoo-deploy.yml

Organisation du playbook Odoo

Le playbook Ansible décrit ci-dessous est conçu pour orchestrer le déploiement de l'application Odoo en utilisant le roles qui à été mis en place à cet effet et qui facilitent la configuration et la mise en service des instances nécessaires. Ce playbook est structuré en deux phases principales :

vérification de la connectivité SSH via le role check_ssh", l'installation de docker et docker-compose via le role "prepare_docker" et la configuration du déploiement d'Odoo via le role "odoo_deploy".

---
- name: Verify SSH Connectivity on Dynamic Hosts
  hosts: dynamic_hosts
  gather_facts: no
  roles:
    - check_ssh

- name: Setup Odoo
  hosts: dynamic_hosts
  vars_files:
    - group_vars/all.yml
  roles:
    - prepare_docker
    - odoo_deploy

fichier odoo-deploy.yml

Notez que ce playbook à la particularité d'embarquer une variable ansible dans le fichier hosts.yml, cette variable permet de récupérer l'adresse IP de l'instance sur laquelle sera déployé le stack au moment de l'exécution de celle-ci.

all:
  children:
    dynamic_hosts:
      vars:
        ansible_user: "{{ USER_SERVER }}"
      hosts:
        prod:
          ansible_host: "{{ lookup('env', 'IP_ODOO') }}"

fichier hosts.yml

Pour en savoir plus sur le playbook ainsi que son utilisation : Dépôt du playbook permettant de déployer la stack Odoo+Postgres

5.1.3 Utilisation des docker-compose dans Ansible pour la création d'un role, playbook pgAdmin et ic-webapp

De la même façon que que le role odoo_deploy ainsi que le playbook odoo-deploy ont été mis en œuvre, nous avons repris intégralement le même process pour l'élaboration des role et playbook ansible de la stack pgAdmin et ic-webapp

Pour en savoir plus sur le role pgadmin_deploy ainsi que son utilisation

Pour en savoir plus sur le playbook pgadmin-deploy ainsi que son utilisation

6 Automatisation des déploiements

6.1. Jobs Jenkins pour le déploiement d'Odoo et PGAdmin

6.1.1. Description du stage pour le déploiement de la stack Odoo

Ce stage à pour objectif d'automatiser le déploiement de la pile comprenant l'application Odoo et la base de données PostgreSQL sur une instance ec2 spécifié par la variable IP_ODOO dans le fichier hosts.yml.

        stage('Deploy stack Odoo_Postgres') {
            environment {
                SSH_EC2 = credentials('SSH_EC2')
            }
            steps {
                script { 
                    sh'''
                        export PATH=$PATH:/home/ubuntu/.local/bin
                        rm -rf odoo-stack-deploy
                        git clone $REPO_ODOO ./odoo-stack-deploy
                        cd odoo-stack-deploy

                        ansible-galaxy install -r roles/requirements.yml -f
                        chmod 600 $SSH_EC2

                        ssh -o StrictHostKeyChecking=no -i $SSH_EC2 ${USER_SERVER}@${IP_ODOO} "
                        rm -rf .secrets
                        mkdir .secrets
                        echo "odoo" > .secrets/odoo_pg_pass
                        "

                        ansible-playbook -i hosts.yml odoo-deploy.yml --private-key $SSH_EC2 -vvv  
                    '''
                }
            }
        }

6.1.2. Description du stage pour le déploiement de la stack pgAdmin

Ce stage à pour objectif d'automatiser le déploiement de la pile comprenant l'application pgAdmin et le site vitrine ic-webapp dont l'image à été buildé à l'entrée du pipeline, ceci sur une instance ec2 spécifié par la variable IP_PGADMIN dans le fichier hosts.yml.

        stage('Deploy stack PGAdmin_IC_WebApp') {
            environment {
                SSH_EC2 = credentials('SSH_EC2')
            }
            steps {
                script { 
                    sh'''
                        export PATH=$PATH:/home/ubuntu/.local/bin
                        rm -rf pgadmin-stack-deploy
                        git clone $REPO_PGADMIN  ./pgadmin-stack-deploy
                        cd pgadmin-stack-deploy
                        ansible-galaxy install -r roles/requirements.yml -f
                        chmod 600 $SSH_EC2

                        ssh -o StrictHostKeyChecking=no -i $SSH_EC2 ${USER_SERVER}@${IP_PGADMIN} "
                        ls
                        "

                        ansible-playbook -i hosts.yml pgadmin-deploy.yml --private-key $SSH_EC2 -vvv
                    '''
                }
            }
        }

6.2. Configuration des webhook Jenkins et Gitlab

Étape 1 : Générer un Token Gitlab personnel

Générer un Token personnel, pour cela, vous pouvez vous rendre dans Profile Settings > Access Tokens.

Étape 2 : Configurer Jenkins pour accepter les webhooks de GitLab

Installer le Plugin GitLab : Allez à Manage Jenkins > Manage Plugins > Available, recherchez "GitLab Plugin" et installez-le.

Configurer le Plugin GitLab :

Dans Manage Jenkins > Configure System, descendez jusqu'à la section GitLab.
Renseignez l'URL de GitLab et un token d’accès personnel (Personal Access Token)

Étape 3 : Configurer le Projet Jenkins pour utiliser GitLab

Configurer le Projet (pipeline) Jenkins :

Ouvrez la configuration dU projet Jenkins. Projet > Configurer
Sous la section Source Code Management, choisissez "Git" et renseignez l’URL de votre dépôt GitLab.
Dans la section Build Triggers, cochez Build when a change is pushed to GitLab. GitLab webhook push doit être sélectionné.
Configurez les autres options selon vos besoins spécifiques (par exemple, les branches à construire).

Étape 4 : Créer un Webhook dans GitLab

Accédez au projet dans GitLab
Allez dans Settings > Webhooks.
Entrez l'URL du webhook Jenkins, qui est généralement sous la forme http://JENKINS_URL/project/NOM_DU_JOB. L'URL exacte dans Jenkins sous la configuration du projet, dans la section Build Triggers.
Choisissez les événements pour lesquels vous souhaitez déclencher des builds. Généralement, vous sélectionnerez "Push events" pour les projets de développement standard. Cliquez sur Add Webhook.

Étape 5 : Tester le Webhook

Après avoir configuré le webhook, nous pouvons utiliser le bouton Test à côté du webhook dans GitLab pour envoyer une requête de test à Jenkins et vérifier que la connexion est établie correctement.

Si tout est configuré correctement, Jenkins devrait déclencher un build lorsque le webhook est activé par un push dans le dépôt GitLab.

6.3. Run et test du pipile

6.3.1. Exécution manuelle du pipeline

Apres provisionnement des instances destinées à accueillir Odoo et pgAdmin, nous allons récupérer les IP publics de celle-ci que nous allons renseigner dans le fichier "releases.txt", pour ensuite lancer manuellement notre pipeline et observer le résultat

Site vitrine ic-webapp

Acces à l'interface d'Odoo

Acces à l'interface de pgAdmin

6.3.2. Exécution automatique du pipeline (déclenchement via webhook)

Pipeline update via le webhook

L'application reste disponible après la mise jour du pipeline

On peut confirmer le bon fonctionnement de webhook également via le détails de la requête push effectué par Gitlab réussie

Références

Configurer des webhook jenkins et gitlab

Provisionner un instance ec2 avec terraform

Installer Ansible

Playbook Odoo et PostgreSQL

Playbook pgAdmin & ic-webapp

Kubernetes | Déploiement d'une BD MySQL et Wordpress (PV, PVC, et deployment)

Carlin FONGANG — Tue, 16 Apr 2024 23:01:24 GMT

LinkedIn | GitLab | GitHub | Credly

Contexte

Ce laboratoire vise à effectuer un déploiement de Wordpress sur un cluster Kubernetes.

Objectifs

Création d'un déploiement MySQL : Nous mettrons en place un déploiement MySQL avec un seul réplica pour gérer notre base de données.
Exposition de MySQL : Un service de type ClusterIP sera créé pour exposer nos pods MySQL, permettant ainsi à d'autres services du cluster de communiquer avec la base de données.
Déploiement de WordPress : Nous configurerons un déploiement WordPress avec les variables d'environnement nécessaires pour se connecter à la base de données MySQL.
Stockage des données WordPress : Le déploiement WordPress sera configuré pour stocker les données dans un volume monté sur le répertoire /data d’un des nœuds du cluster, assurant la persistance des données.
Exposition de WordPress : Nous créerons un service de type NodePort pour exposer l'interface de WordPress à l'extérieur, rendant le site accessible sur internet.

1. Prérequis : Liste des exigences matérielles et logicielles.

Dans notre cas, nous allons provisionner une instances EC2 s'exécutant sous Ubuntu 20.04 Focal Fossa LTS, grace au provider AWS, à partir delaquelle nous effectuerons toutes nos opérations.

Provisionner une instance EC2 sur AWS à l'aide de Terraform (recommandé)

Provisionner une instance EC2 sur AWS à l'aide d'Ansible

2. Création d'un cluster

Consultez le document Installer kubeadm

Voici une structure détaillée pour la documentation technique sur l'installation de WordPress via Kubernetes :

3. Création du Persistent Volume

nano mysql-pv.yml

Description du manfiest

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mysql-pv
  labels:
    type: local
spec:
  capacity:
    storage: 3Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: standard
  hostPath:
    path: /data/mysql-pv

kubectl apply -f mysql-pv.yml

Le Persistent Volume (PV) a été crée

3. Création du déploiement MySQL

3.1. Manifeste PersistentVolumeClaim

nano mysql-pvc.yml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pvc
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 2Gi
  storageClassName: standard

kubectl apply -f mysql-pvc.yml

3.2. Détails du manifeste de déploiement.

nano mysql-deployment.yml

Contenu du manifest

apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress-mysql
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:latest
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: "password"
        - name: MYSQL_DATABASE
          value: "db-acd"
        - name: MYSQL_USER
          value: "acd"
        - name: MYSQL_PASSWORD
          value: "devops-acd"
        ports:
        - containerPort: 3306
        volumeMounts:
        - name: mysql-data
          mountPath: /var/lib/mysql
      volumes:
      - name: mysql-data
        persistentVolumeClaim:
          claimName: mysql-pvc

kubectl apply -f mysql-deployment.yml

Nous pouvons vérifier les pods en cours d'exécution :

kubectl get pod

Pod mysql en cours d'exécution

L'on peut vérifier également les détails du pod en cours d'exécution et constater et constater qu'il utiliser bien le PVC déclaré un précédement

 kubectl describe pods wordpress-mysql-75b599b99-9d756

3.3. Création du service ClusterIP pour MySQL.

Pour permettre à d'autres pods de communiquer avec MySQL, nous exposerons le déploiement via un service de type ClusterIP.

nano sv-mysql.yml

apiVersion: v1
kind: Service
metadata:
  name: sv-mysql
spec:
  type: ClusterIP
  ports:
  - port: 3306
  selector:
    app: mysql

kubectl apply -f sv-mysql.yml

ClusterIP en cours d'exécution

En entrant la commande ci-dessous, on peut virifier que le ClusterIP est bien exécuté et associé aux pod dont le label est bien "app=mysql"

kubectl describe svc sv-mysql

4. Installation de WordPress

4.1. Création du Persistent Volume

nano wordpress-pv.yml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: wordpress-pv
  labels:
    type: local
spec:
  capacity:
    storage: 3Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: standard
  hostPath:
    path: /data/wordpress-pv

kubectl apply -f wordpress-pv.yml

4.2. Manifeste PersistentVolumeClaim pour WordPress

nano wordpress-pvc.yml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: wordpress-pvc
spec:
  storageClassName: standard
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi

kubectl apply -f wordpress-pvc.yml

4.3. Manifest de déploiement de WordPress.

nano wordpress-deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress
spec:
  replicas: 1
  selector:
    matchLabels:
      app: wordpress
  template:
    metadata:
      labels:
        app: wordpress
    spec:
      containers:
      - name: wordpress
        image: wordpress:latest
        env:
        - name: WORDPRESS_DB_HOST
          value: "sv-mysql"  # Doit correspondre au nom du service qui expose MySQL
        - name: WORDPRESS_DB_USER
          value: "acd"              # Doit correspondre à MYSQL_USER
        - name: WORDPRESS_DB_PASSWORD
          value: "devops-acd"       # Doit correspondre à MYSQL_PASSWORD
        - name: WORDPRESS_DB_NAME
          value: "db-acd"           # Doit correspondre à MYSQL_DATABASE
        ports:
        - containerPort: 80
        volumeMounts:
        - name: wordpress-storage
          mountPath: /var/www/html
      volumes:
      - name: wordpress-storage
        persistentVolumeClaim:
          claimName: wordpress-pvc

 kubectl get deploy

On peut également vérifier à quel PVC le pod wordpress est rataché

kubectl get pod

ensuite

kubectl describe pods wordpress-6bcf6b499b-92b2z

4.3. Exposition de wordpress

nano sv-wordpress.yml

apiVersion: v1
kind: Service
metadata:
  name: wordpress
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 80
    nodePort: 30000
  selector:
    app: wordpress

kubectl apply -f sv-wordpress.yml

kubectl get services

Vérification et Tests

En entrant l'ip d'un des nodes suivi du port 30000 dans le navigateur, on accède à la page de configuration de wordpress

Documentation

Volumes Persistants

Installer kubeadm sur ubuntu

Creating a Single Control-Plane Cluster with kubeadm

Kubernetes | Volume et stockage persistant

Carlin FONGANG — Sun, 14 Apr 2024 12:07:27 GMT

LinkedIn | GitLab | GitHub | Credly

Contexte

Ce lab vise à présenter les étapes de mise en place d'un volume persistant sur Kubernetes.

Objectifs

Dans ce laboratoire, nous allons mettre en place un environnement utilisant Kubernetes pour démontrer l'utilisation de volumes persistants avec MySQL :

Création du Pod MySQL :
- Rédigez un manifeste mysql-volume.yml pour déployer un pod MySQL nommé mysql-volume. Configurez les variables d'environnement pour le nom de la base de données, l'utilisateur, et les mots de passe.
- Assurez-vous que le répertoire de données MySQL soit persistant en le montant sur /data-volume.
Gestion des Volumes :
- Écrivez un manifeste pv.yml pour créer un volume persistant (PV) de 5 Go, utilisant le dossier local local/data-pv.
- Rédigez un manifeste pvc.yml pour un claim de volume persistant (PVC) de 1 Go qui utilise le PV créé précédemment.
Déploiement de MySQL avec PVC :
- Déployez MySQL avec le PVC à l'aide d'un nouveau manifeste mysql-pv.yml, assurant que MySQL utilise ce volume pour le stockage des données.
Vérifications :
- Lancez les ressources et vérifiez que le pod MySQL est bien démarré et utilise le dossier /data-volume.
- Confirmez que les PV et PVC sont correctement créés et prêts à être utilisés.

1. Définition des concepts

1.1. C'est quoi un Volume Persistant (PV) ?

Un Volume Persistant (PV) dans Kubernetes est une ressource dans le cluster qui permet de stocker des données de manière persistante, indépendamment du cycle de vie des pods qui les utilisent. Les PV sont des volumes de stockage provisionnés par un administrateur ou dynamiquement par Kubernetes à l'aide de classes de stockage. Ils offrent une manière de gérer des volumes de stockage sur une infrastructure sous-jacente, permettant aux utilisateurs de consommer du stockage abstrait sans se préoccuper des détails spécifiques à un environnement ou un fournisseur.

1.2. C'est quoi un Persistent Volume Claim (PVC) ?

Un Persistent Volume Claim (PVC) dans Kubernetes est une requête de stockage. Il permet de demander des ressources de stockage spécifiques (taille et accessibilités), qui sont ensuite liées à des Persistent Volumes (PV) existants dans le cluster selon leur capacité et leurs accès. Un PVC consomme des ressources de PV, agissant comme une sorte de ticket pour l’utilisation de ressources de stockage définies dans un PV. Cela permet une abstraction entre la demande et la provision de stockage, offrant ainsi flexibilité et automatisation.

2. Prérequis : Liste des exigences matérielles et logicielles.

Dans notre cas, nous allons provisionner une instances EC2 s'exécutant sous Ubuntu 20.04 Focal Fossa LTS, grace au provider AWS, à partir delaquelle nous effectuerons toutes nos opérations.

Provisionner une instance EC2 sur AWS à l'aide de Terraform (recommandé)

Provisionner une instance EC2 sur AWS à l'aide d'Ansible

Nos nodes tournent sous ubuntu 20.04 LTS.

2. Création d'un cluster

Consultez le document Installer kubeadm

3. Déploiement du Pod MySQL

3.1. Rédaction du manifeste `mysql-volume.yml`.

sudo nano mysql-volume.yml

apiVersion: v1
kind: Pod
metadata:
name: mysql-volume
spec:
containers:
- image: mysql
  name: mysql
  volumeMounts:
  - montPath: /var/lib/mysql
    name: mysql-data
  env:
    - name: MYSQL_ROOT_PASSWORD
      value: password
    - name: MYSQL_DATABASE
      value: db-acd 
    - name: MYSQL_USER
      value: acd
    - name: MYSQL_PASSWORD
      value: devops-acd
volumes:
- name: mysql-data
  hostPath:
    #Path hote
    path: /data-volume
    type: Directory

Dans ce manifeste nous définissons un Pod Kubernetes nommé mysql-volume qui utilise l'image officielle mysql. Le Pod est configuré avec un volume nommé mysql-data monté sur /var/lib/mysql, ce qui indique que les données de MySQL seront stockées dans un répertoire spécifique sur l'hôte. Les variables d'environnement définies dans le manifeste configurent les paramètres de base de données MySQL, y compris le mot de passe root, le nom de la base de données, l'utilisateur, et le mot de passe de l'utilisateur. Le volume mysql-data utilise hostPath pour lier le répertoire /data-volume sur l'hôte physique, assurant la persistance des données.

L'on va crée un repertoire "/data-volume" sur nos nodes worker1 et worker2

sudo mkdir /data-volume

kubectl apply -f mysql-volume.yml

3.2. Vérification du contenu de `/data-volume`.

ls /data-volume/

Les données du pod mysql-volume sont bien stockées sur le volume persistant /data-volume situé sur le worker1

même en supprimant notre pod, les données continuerons d'être sauvegardées

4. Gestion des volumes

4.1. Création et configuration du volume persistant (PV) avec `pv.yml`.

sudo nano pv.yml

apiVersion: v1
kind: PersistentVolume
metadata:
name: pv
labels:
  type: local
spec:
storageClassName: manual
capacity:
  storage: 5Gi
accessModes:
  - ReadWriteOnce
hostPath:
  path: "/data-pv"

Ce Persistent Volume (PV) est étiqueté comme un stockage local avec une classe de stockage manuelle spécifiée sous storageClassName: manual. Le PV est configuré avec une capacité de stockage de 5 Go et un mode d'accès ReadWriteOnce, ce qui signifie qu'il peut être monté en lecture-écriture par un seul nœud. Il utilise hostPath pour lier le chemin /data-pv sur l'hôte, destiné à stocker les données persistantes utilisées par les pods dans le cluster.

kubectl apply -f pv.yml

Le Persistent Volume est bien crée

4.2. Création du claim de volume persistant (PVC) avec `pvc.yml`.

sudo nano pvc.yml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc
spec:
storageClassName: manual
accessModes:
  - ReadWriteOnce
resources:
  requests:
    storage: 1Gi

Nous définissons ici, une demande de volume persistant PersistentVolumeClaim (PVC) dans Kubernetes. Le manifest spécifi l'utilisation de la classe de stockage manual, nous respectons ici la configuration qui a été faites pour le PV plus haut. Le PVC demande un mode d'accès ReadWriteOnce, permettant le montage du volume en lecture et écriture sur un seul nœud. Il demande également une capacité de stockage de 1 Gi. Il est utilisé pour réserver une partie de l'espace de stockage disponible dans un Persistent Volume correspondant qui remplit ces critères.

kubectl apply -f pvc.yml

PVC à été bien crée

5. Déploiement de MySQL avec stockage persistant

5.1. Rédaction du manifeste `mysql-pv.yml`.

sudo nano mysql-pv.yml

apiVersion: v1
kind: Pod
metadata:
name: mysql-pv
spec:
containers:
- image: mysql
  name: mysql
  volumeMounts:
  - mountPath: /var/lib/mysql
    name: mysql-data
  env:
    - name: MYSQL_ROOT_PASSWORD
      value: password
    - name: MYSQL_DATABASE
      value: db-acd 
    - name: MYSQL_USER
      value: acd
    - name: MYSQL_PASSWORD
      value: devops-acd
volumes:
- name: mysql-data
  persistentVolumeClaim:
    claimName: pvc

Ce manifeste permet de ployer un Pod dans Kubernetes nommé mysql-pv qui exécute un conteneur basé sur l'image officielle mysql. Le Pod est configuré pour utiliser le PersistentVolumeClaimpvc crée précédement, pour le stockage des données. Le volume est monté sur le chemin /var/lib/mysql dans le conteneur, ce qui est le répertoire standard où MySQL stocke ses données. Cette configuration assure que les données MySQL sont stockées de manière persistante et restent disponibles même si le Pod est redéployé sur un autre nœud du cluster.

5.2. Déploiement de MySQL utilisant le PVC.

kubectl apply -f mysql-pv.yml

5.3. Vérification et tests

kubectl describe pod mysql-pv

Comme on peut le voir sur la capture, le nouveau pod à été deployé sur le worker2, on peut donc se connecter sur ce worker afin de vérifier le repertoire /data-pv/

ls /data-volume

Sur le worker2, les données du pod mysql-pv sont bien stockées et sauvegardées dans le repertoire /data-volume

Documentation

Installer kubeadm sur ubuntu

Creating a Single Control-Plane Cluster with kubeadm

Kubernetes | Services Nodeport & namespace : créer un environnement isolé et exposer des pods vers l'extérieur

Carlin FONGANG — Sat, 13 Apr 2024 12:54:33 GMT

LinkedIn | GitLab | GitHub | Credly

Contexte

Ce laboratoire vise à présenter les étapes de mise en place d'un service de type NodePort sur Kubernetes.

Objectifs

Dans ce lab, nous allons créer un environnement isolé sur Kubernetes et déployer une application accessible depuis l'extérieur du cluster. Voici les étapes à suivre pour ce processus :

Création d'un Namespace : Rédigez un manifeste namespace.yml pour créer un namespace appelé production.
Déploiement d'un Pod : Créez un manifeste pod-red.yml pour déployer un pod utilisant l'image mmumshad/simple-webapp-color, avec la couleur rouge spécifiée et un label app:web.
Exposition du Pod via NodePort : Élaborez un manifeste service-nodeport-web.yml qui expose le pod sur le réseau extérieur via un service de type NodePort. Configurez ce service pour utiliser le port 30008 comme NodePort et rediriger les requêtes vers le port 8080 des pods.
Lancement et Vérification : Déployez le service et utilisez kubectl describe pour vérifier que le service a correctement identifié les deux pods sous le label app:web.
Test d'Accessibilité : Testez l'accès à l'application en ouvrant le port 30008 du nœud pour s'assurer que l'application est accessible.

1. Définition des concepts

1.1. C'est quoi namespace ?

Un namespace dans Kubernetes est une sorte de partition virtuelle au sein d'un cluster, qui permet d'isoler les groupes de ressources. Chaque namespace peut contenir des ressources (comme des pods, services, volumes, etc.) indépendamment des autres namespaces. Utiliser des namespaces permet de gérer efficacement les droits d'accès, de simplifier l'allocation des ressources, de segmenter le cluster pour différents utilisateurs ou projets, et d'organiser les ressources de manière plus structurée, facilitant ainsi la gestion et la maintenance du cluster.

1.2. Concept de Nodeport

Le service de type NodePort dans Kubernetes permet d'exposer des services sur des ports fixes des nœuds du cluster. Chaque nœud redirige automatiquement ce port fixe (NodePort) vers le port du service. Ce mécanisme rend le service accessible de l'extérieur du cluster en utilisant :. NodePort est généralement utilisé pour des applications de test ou des environnements de développement, car il offre un moyen simple et direct d'accéder aux services à travers les adresses IP des nœuds.

2. Prérequis : Liste des exigences matérielles et logicielles.

Dans notre cas, nous allons provisionner une instances EC2 s'exécutant sous Ubuntu 20.04 Focal Fossa LTS, grace au provider AWS, à partir delaquelle nous effectuerons toutes nos opérations.

Provisionner une instance EC2 sur AWS à l'aide de Terraform (recommandé)

Provisionner une instance EC2 sur AWS à l'aide d'Ansible

2. Création d'un cluster

Consultez le document Istaller kubeadm

3. Configuration initiale

3.1. Création du fichier namespace.yml pour le namespace production.

nano namespace.yml

apiVersion: v1
kind: Namespace
metadata:
  name: production

3.2. Création du namespace.

kubectl apply -f namespace.yml

Création du namespace effectuée

kubectl get namespace

Name space "production" crée

4. Déploiement des Pods

4.1. Description du fichier pod-red.yml

nano pod-red.yml

apiVersion: v1
kind: Pod
metadata:
  name: simple-webapp-color-red
  labels:
    app: web
spec:
  containers:
    - name: web
      image: mmumshad/simple-webapp-color
      ports:
        - containerPort: 8080
      env:
        - name: APP_COLOR
          value: red #définition de la couleur

4.2. Procédure pour déployer le pod dans le namespace production.

kubectl apply -f pod-red.yml -n production

Vérification de la création du pod dans le namespace définit

kubectl get pod --namespace production

ou 

kubectl get pod -n production

4.3. Description du fichier pod-blue.yml

nano pod-blue.yml

apiVersion: v1
kind: Pod
metadata:
  name: simple-webapp-color-blue
  labels:
    app: web
spec:
  containers:
    - name: web
      image: mmumshad/simple-webapp-color
      ports:
        - containerPort: 8080
      env:
        - name: APP_COLOR
          value: blue #définition de la couleur

4.4. Création du pod blue

kubectl apply -f pod-blue.yml -n production

Pod blue en cours d'exécution

5. Création du Service NodePort

5.1. Description du fichier service-nodeport-web.yml

nano service-nodeport-web.yml

apiVersion: v1
kind: Service
metadata:
  name: service-nodeport-web
spec:
  type: NodePort
  selector:
    app: web
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 8080
    nodePort: 30000

Dans ce manifest, nous définissons un service de type NodePort ici désigné par service-nodeport-web. Il est configuré pour router le trafic TCP sur le port 8080 vers le targetPort 8080 des pods étiquetés avec app: web. De plus, ce service est exposé sur chaque nœud du cluster via le nodePort 30000. Cette configuration permet au trafic externe d'accéder aux pods spécifiés via l'adresse IP de n'importe quel nœud du cluster, suivi du port 30000.

5.2. Création du service Nodeport et exposition des pods

kubectl apply -f service-nodeport-web.yml -n production

Service nodePort est bien crée

On peut vérifier les détails de notre service pour obtenir les IPs sur lesquelles il pointe

kubectl describe service -n production

6. Vérification et Tests

En entrant l'adresse IP de l'un des node du cluster, dans notre cas, celui du "node control" dans un navigateur suivi du port 3000, l'on obtiens une page du navigateur qui s'alterne.

webapp bleu

webapp red

on peut constater que l'exposition des deux applications/pods (red & blue) vers l'extérieur et le loadbalancing marchent bien, car il permet d'alterner entre les deux pages.

Documentation

Installer kubeadm sur ubuntu

Creating a Single Control-Plane Cluster with kubeadm

Kubernetes | Créez des pods et des deployments à l'aide de kubernetes

Carlin FONGANG — Fri, 12 Apr 2024 16:46:30 GMT

LinkedIn | GitLab | GitHub | Credly

Contexte

Dans ce laboratoire, nous allons explorer les étapes clés pour déployer et gérer des applications en utilisant Kubernetes et nginx.

Objectifs

Dans ce lab, nous procèderons à :

Rédaction du manifeste pod.yml : Créez un fichier pod.yml pour déployer un pod utilisant l'image mmumshad/simple-webapp-color, en spécifiant que la couleur de l'application sera rouge.
Lancement et vérification du pod : Déployez le pod et assurez-vous qu'il est correctement en cours d'exécution dans votre cluster Kubernetes.
Exposition du pod : Exposez le pod en utilisant la commande kubectl port-forward nom_du_pod 8080:8080 --address 0.0.0.0 pour rendre l'application accessible via le port 8080.
Accès à l'application : Confirmez que l'application est accessible en naviguant sur le port 8080 du nœud.
Déploiement de Nginx : Écrivez un manifeste nginx-deployment.yml pour déployer deux réplicas d'un pod Nginx, utilisant la version 1.18.0 de l'image.
Vérification du déploiement : Lancez le déploiement, vérifiez le nom des pods et confirmez que le déploiement, le ReplicaSet et la version de l'image ont été correctement créés.
Mise à jour du déploiement : Modifiez nginx-deployment.yml pour utiliser la version latest de l'image Nginx, puis appliquez la modification avec kubectl apply.
Observation des changements : Examinez les ReplicaSets actifs et l'image utilisée par le ReplicaSet en cours.
Nettoyage : Supprimez toutes les ressources créées et recréez-les en utilisant des commandes impératives pour consolider la maîtrise de Kubernetes.

En intégrant kubeadm dans notre flux de travail Kubernetes, vous simplifierons considérablement la gestion du cycle de vie de notre cluster, nous permettant ainsi de nous concentrer davantage sur le déploiement et la gestion de nos applications.

1. Définition des conceptes

1.1. C'est quoi kubeadm ?

kubeadm est un outil conçu par la communauté Kubernetes pour simplifier la mise en place et la gestion des composants fondamentaux d'un cluster Kubernetes de manière sécurisée et automatisée. Il est destiné à fournir une méthode standardisée pour la formation rapide de clusters Kubernetes.

1.2. Fonctionnalités de kubeadm

Initialisation du Cluster : kubeadm initialise les composants nécessaires pour faire fonctionner un cluster Kubernetes, y compris le serveur API, le Controller Manager et l'ordonnanceur (Scheduler). Cette étape comprend la configuration de la sécurité du cluster, la génération de certificats, et la configuration des composants de gestion du cluster.

Gestion des Tokens et de la Sécurité : kubeadm génère un token que les autres nœuds peuvent utiliser pour rejoindre le cluster de manière sécurisée. Il configure également les règles de base pour la communication sécurisée entre les nœuds du cluster.

Configuration de Réseau : Après l'initialisation, kubeadm attend que l'administrateur installe un add-on réseau avant que les nœuds ne soient prêts à exécuter des applications. Cela garantit que la communication inter-pod sur le cluster est bien établie.

Ajout de Nœuds : kubeadm fournit une commande simple pour ajouter des nœuds au cluster. Ceci est essentiel pour l'expansion du cluster.

Mise à niveau du Cluster : Avec kubeadm, la mise à niveau des composants du cluster vers de nouvelles versions est rationalisée et peut être exécutée avec des commandes simples, minimisant ainsi le risque d'erreurs humaines.

1.3. Pourquoi utiliser kubeadm ?

Simplicité : kubeadm réduit la complexité de mise en place d'un cluster Kubernetes, ce qui le rend accessible même pour ceux qui sont relativement nouveaux dans la technologie Kubernetes.

Standardisation : En utilisant kubeadm, vous suivez les meilleures pratiques et les configurations recommandées par la communauté Kubernetes, garantissant ainsi la fiabilité et la sécurité de votre cluster.

Flexibilité : kubeadm est conçu pour fonctionner bien avec les systèmes d'exploitation et les environnements d'hébergement les plus courants, ce qui en fait une solution versatile pour divers cas d'utilisation.

2. Prérequis : Liste des exigences matérielles et logicielles.

Dans notre cas, nous allons provisionner une instances EC2 s'exécutant sous Ubuntu 20.04 Focal Fossa LTS, grace au provider AWS, à partir delaquelle nous effectuerons toutes nos opérations.

Provisionner une instance EC2 sur AWS à l'aide de Terraform (recommandé)

Provisionner une instance EC2 sur AWS à l'aide d'Ansible

1. Configuration initiale

1.1. Prérequis techniques

Nous utiserons kubeadm pour ce lab, cet outil pour être déployé, nécessite : 2vCPU et 4Go de RAM minimum.

1.2. Configuration du cluster

Pour la création de notre cluster, se reférer à la documentation sur l'installation de kubeadm

2. Déploiement du Pod Simple

2.1. Création du fichier pod.yml

sudo nano pod.yml

contenu du manifest

apiVersion: v1
kind: Pod
metadata:
  name: simple-webapp-color
  labels:
    app: web
spec:
  containers:
    - name: web
      image: mmumshad/simple-webapp-color
      ports:
        - containerPort: 8080
      env:
        - name: APP_COLOR
          value: red

2.2. Déploiement du pod avec l'image mmumshad/simple-webapp-color

kubectl apply -f pod.yml

vérification des pods en cours

kubectl get pod

3. Vérification et exposition du Pod

3.1. Commandes pour lancer et vérifier l'état du pod

kubectl describe pod simple-webapp-color

Sur cette capture, on peut voir que le pod est assigné au node k8s-worker1/172.31.30.26 et le label de celui ci est app=web

3.2. Exposition du pod sur le réseau via port-forward

La commande ci-dessous permet de rediriger et d'écouter sur le port 8080 de toutes les interfaces réseau de la machine hôte, rendant ainsi accessible sur ce port le service fourni par le pod simple-webapp-color dans un cluster Kubernetes.

kubectl port-forward simple-webapp-color 8080:8080 --address 0.0.0.0

Sortie console une fois la commande passée

3.3. Suppression du pod

Pour supprimer le pod crée, de la même façon que nous l'avons lancé, nous allons utiliser la commande :

kubectl delete -f pod.yml --v=5

4. Accès et test de l'application

Pour vérifier l'exposition du pod vers l'extérieur, l'on va entrée le nom de domaine/ip public du control node dans un navigateur suivi du port 8080 qui correspond au port d'exposition.

L'application web tournant sur le pod est bien accessible via internet

Nous venons donc de déployer notre toute première application grace à kubernetes 🥳🙌

5. Déploiement de Nginx

5.1. Rédaction du manifeste nginx-deployment.yml

sudo nano nginx-deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment 
  labels:
    app: nginx
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.18.0
        ports:
        - containerPort: 80

5.2. Déploiement de Nginx

kubectl apply -f nginx-deployment.yml --v=5

5.3. Vérification des pods et des ReplicaSets

kubectl get pod
kubectl get replicaset
kubectl get deploy

on peut avoir des information sur le deployment également

 kubectl describe deploy

Pour avoir plus de détail sur les pods

kubectl describe pod nginx-deployment-54bcfc567b-nf7dm

Informations sur le premier pod

kubectl describe pod nginx-deployment-54bcfc567b-s9j8b

Comme on peut le constater, sur chacune des capture, chaque pod est hébergé sur un node distinct.

6. Mise à jour et gestion des versions

6.1. Procédure de mise à jour de l'image Nginx vers la version latest

Pour procéder à la mise à jour de Nginx vers la lastest, nous allons simplement mettre à jour notre ficher deployment

sudo nano nginx-deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment 
  labels:
    app: nginx
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

6.2. Application des modifications avec kubectl apply

kubectl apply -f nginx-deployment.yml

On observe une reconfiguration du deploiement et non pas un deploiement à part entier comme au tout début pour la version 1.18.0 de Nginx

6.3. Observation des changements dans les Replicasets

kubectl get replicaset -o wide

Apres application de la commande, on peut observer que les précédents pods tournant sous nginx:1.18.0 sont à l'arrêt tandis qu'on à deux nouveaux pods en cours d'exécution et tournant sous la version latest Nginx

Il est important de noter que ce basculement est progressif, kubernetes va commencer pas créer un à un les nouveaux pods, tant dis qu'il va supprimer progressivement les anciens pods tout en gardant en cours d'exécution le nombre de replicas définit préalablement dans le deployment, soit "2"

7. Nettoyage du cluster

7.1. Suppression des ressources créées

A présent nous allons supprimer toutes les ressources créees, et reprendre tout celà de façon impérative.

kubectl delete -f nginx-deployment.yml

suppression des ressources

7.2. Commandes pour recréer les ressources de manière impérative

7.2.1. Création du pod "simple-webapp-color"

kubectl run --image=mmumshad/simple-webapp-color \
--env="APP_COLOR=blue" \
--restart=Never \
simple-webapp-color

Le pod est bien crée

Exposition du pod à internet

kubectl port-forward simple-webapp-color 8080:8080 --address 0.0.0.0

Une fois le pod exposé, on va de nouveau consulter l'application web grace à l'ip public/domaine de l'instance faisant office de node principal.

Pour supprimer notre pod, nous entrerons la commande suivante :

kubectl delete pod simple-webapp-color

7.2.2. Création impératif du deployment

Création du deploiement avec pour image nginx:1.18.0

kubectl create deployment --image=nginx:1.18.0 nginx-deployment

Le pod à bien été lancé mais on a un seul pod au lieu de deux comme on le voudrais, pour régler ce problème, nous allons passer la commande suivante :

 kubectl scale --replicas=2 deployment/nginx-deployment

En controllant de nouveaux nos pods, on obtiens bien deux pods sous nginx:1.18.0

kubectl get deploy

Pour faire upgrade nginx, nous allons passer la commande suivante :

kubectl set image deployment/nginx-deployment nginx=nginx:latest

pour vérifier la mise à jour :

kubectl get replicasets -o wide

Nous avons mis en place un objet de type deployment de manière impérative. Cependant, pour faciliter le travail collaboratif, il est recommandé d'utiliser des manifestes qui peuvent être versionnés.

Documentation

Installer kubeadm sur ubuntu

Creating a Single Control-Plane Cluster with kubeadm

Kubernetes | Installation de Kubeadm et création d'un cluster

Carlin FONGANG — Fri, 12 Apr 2024 10:11:23 GMT

LinkedIn | GitLab | GitHub | Credly

Contexte

Ce laboratoire vise à présenter les étapes d'installation de l'outil kubeadm sur des instances ec2.

Objectifs

Dans ce lab, nous allons :

Provisionner 3 instances ec2 sur les quelles nous allons effectuer toutes nos opérations de configurations.
Effectuer les configurations nécessaires sur ces instances afin d'y installer docker et containerd sur l'ensemble des instances.
Configurer les réglages de réseau avec Calico
Gérer l'adhésion des nœuds workers au cluster principal.

En intégrant kubeadm dans notre flux de travail Kubernetes, nous simplifierons considérablement la gestion du cycle de vie de notre cluster, nous permettant ainsi de nous concentrer davantage sur le déploiement et la gestion de nos applications.

1. Définition des concepts

1.1. C'est quoi kubeadm ?

1.2. Fonctionnalités de kubeadm

Ajout de Nœuds : kubeadm fournit une commande simple pour ajouter des nœuds au cluster. Ceci est essentiel pour l'expansion du cluster.

1.3. Pourquoi utiliser kubeadm ?

Simplicité : kubeadm réduit la complexité de mise en place d'un cluster Kubernetes, ce qui le rend accessible même pour ceux qui sont relativement nouveaux dans la technologie Kubernetes.

2. Prérequis : Liste des exigences matérielles et logicielles.

Dans notre cas, nous allons provisionner une instances EC2 s'exécutant sous Ubuntu 20.04 Focal Fossa LTS, grace au provider AWS, à partir delaquelle nous effectuerons toutes nos opérations.

Provisionner une instance EC2 sur AWS à l'aide de Terraform (recommandé)

Provisionner une instance EC2 sur AWS à l'aide d'Ansible

3. Création d'un cluster

Nous allons provisionner 3 instances ec2 de type t3.medium ou avec des caractéristiques minimales (2 vCPU, 4Go de RAM)

3.1. Définition du nom d'hôte du "Control plan"

Nous allons commencer par renommer la première instance (principale)

sudo hostnamectl set-hostname k8s-control

une fois la commande entrée, on peut se déconnecter et se reconnecter de nouveau pour percevoir le changement.

k8s-Control

3.2. Définition des noms d'hôtes

Nous allons ensuite renommé les 2 autres instaces respectivement en worker1 et worker2

sudo hostnamectl set-hostname k8s-worker1

sudo hostnamectl set-hostname k8s-worker2

4. Mappage des serveurs

Depuis l'instance k8s-control, nous allons crée un mappage de l'ensemble des serveurs afin que la communication entre les différents serveurs puissent se faire via les noms d'hotes.

Nous allons éditer le fichier hosts

sudo nano /etc/hosts

dans ce fichier, nous allons rajouter les ip privés ainsi que les noms utilisateurs de l'ensemble des instances. il est absolument nécessaire d'utiliser des adresses privée à ce niveau, car les ip publiques peuvent changer après redemarrage des instances

172.31.23.252 k8s-control
172.31.30.26 k8s-worker1
172.31.30.220 k8s-worker2

Nous allons copier ces informations, sauvegarder le fichier hosts et répéter la même opération sur les deux autres serveur

Une fois ces opérations réalisées, on va se déconnecter et se reconnecter sur chacune des instances

5. Installation et configuration de Docker et Containerd

L'installation et la configuration de ces outils va se faire sur l'ensemble des instances

5.1. Confiugration de Docker Engine et containerd (valable pour toutes les instances)

Activation des modules du noyau

cat <





sudo modprobe overlay

sudo modprobe br_netfilter

Les commandes sudo modprobe overlay et sudo modprobe br_netfilter jouent un rôle essentiel dans la configuration des environnements basés sur des conteneurs, notamment pour Docker et Kubernetes. Elles chargent respectivement les modules overlay et br_netfilter dans le noyau Linux.
Module OverlayFS : OverlayFS est un système de fichiers de type union qui permet de superposer deux systèmes de fichiers différents. En contexte de conteneurisation, il est souvent utilisé pour fournir le système de fichiers de conteneurs. Cela permet à chaque conteneur d'avoir son propre système de fichiers, tout en partageant des images de base entre conteneurs, économisant ainsi de l'espace disque et augmentant l'efficacité.
Module br_netfilter : Ce module permet le filtrage de trafic réseau au niveau des ponts Linux (bridges), essentiel pour la mise en place de réseaux de conteneurs.
5.2. Paramètres "sysctl" requis par la configuration et paramètres persistent après redémarrage. (valable pour toutes les instances)
Nous allons ensuite apporter des modifications relatives au réseau
cat <




Ces commandes sont utilisées pour configurer des paramètres du noyau Linux via "sysctl", qui sont nécessaires pour le bon fonctionnement de certaines applications, dans notre cas il s'agit de Kubernetes, lorsqu'elles utilisent Docker et containerd comme runtime de conteneurs.
5.3. Application du paramettre "sysctl" lors du redemarrage système (valable pour toutes les instances)
sudo sysctl --system




Les nouvelles configurations sont rechargées
Nous pouvons poursuivre avec la configuration de docker.
5.4. Installation de Docker
Configuration du repository de Docker (valable pour toutes les instances)
sudo apt-get update && sudo apt-get install -y ca-certificates curl gnupg lsb-release apt-transport-https

Ajour de la clé GPG officiel Docker (valable pour toutes les instances)
sudo mkdir -m 0755 -p /etc/apt/keyrings

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

Configuration des dépots Docker sur la distribution linux utilisée (valable pour toutes les instances)
Ajout d'un dépôt Docker au fichier de sources de paquets APT sur un système Ubuntu
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Cette commande configure le dépôt APT pour Docker sur une machine Ubuntu. Elle crée une ligne de source de dépôt, spécifiant l'architecture de la machine (obtenue via dpkg --print-architecture), le chemin du fichier de clé GPG pour la vérification des signatures (signed-by=/etc/apt/keyrings/docker.gpg), l'URL du dépôt Docker, et la version de distribution Ubuntu correspondante (obtenue via lsb_release -cs).
Mise à jour des index de packets apt (valable pour toutes les instances)
sudo apt-get update

Installation de Docker, containerd, et Docker Compose (valable pour toutes les instances)
VERSION_STRING=5:23.0.1-1~ubuntu.20.04~focal

sudo apt-get install -y docker-ce=$VERSION_STRING docker-ce-cli=$VERSION_STRING containerd.io docker-buildx-plugin docker-compose-plugin



Docker est bien install

Ajout de l'utilisateur courant au au groupe docker (valable pour toutes les instances)
sudo usermod -aG docker $USER

Une fois cette commande entrée, se déconnecter et se reconnecter, il est alors possible d'exécuter les commandes docker passer le "sudo" au préalable
Mise en commentaire de 'disabled_plugins' dans le fichier config.toml (valable pour toutes les instances)
sudo sed -i 's/disabled_plugins/#disabled_plugins/' /etc/containerd/config.toml

Cette commande est utilisée pour commenter la ligne disabled_plugins dans le fichier de configuration de containerd. Cette opération permet d'activer les plugins qui étaient désactivés, car la suppression du préfixe "disabled_" modifie la configuration pour ne plus désactiver ces plugins. Cela est nécessaire pour assurer que certaines fonctionnalités ou dépendances de containerd soient disponibles et fonctionnelles, notamment lors de l'exécution de conteneurs Docker.
Redemarrage de containerd (valable pour toutes les instances)
sudo systemctl restart containerd

Désactivation de swap (valable pour toutes les instances)
sudo swapoff -a

6. Installation de kubeadm, kubelet, and kubectl (valable pour toutes les instances)
6.1. Installation
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.27/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

Cette opération nous permet de télécharger la clé publique de signature de paquet depuis une URL spécifique, destinée aux packages Kubernetes. Cette clé est nécessaire pour authentifier et sécuriser les téléchargements de packages Kubernetes
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.27/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list

Ajout d'une source de dépôt pour Kubernetes dans les sources APT du système. Cette opération permet à APT de vérifier l'authenticité des paquets téléchargés de ce dépôt.
sudo apt-get update && sudo apt-get install -y kubelet=1.27.0-* kubeadm=1.27.0-* kubectl=1.27.0-*

sudo apt-mark hold kubelet kubeadm kubectl

Cette commande empêche la mise à jour automatique des trois paquets, ce qui nous donne un control total sur la mise à jour de kubernetes


Installation de kubelet, kubeadm et kubectl

6.2. Initialisation du cluster et configuration des l'accès kubectl.
sudo kubeadm init --pod-network-cidr 192.168.0.0/16 --kubernetes-version 1.27.0

Cette commande est utilisée pour initialiser un cluster Kubernetes. Cette initialisation est la première étape pour configurer un cluster Kubernetes.



Les commandes suivantes configurent l'accès à notre cluster Kubernetes pour notre utilisateur courant.
mkdir -p $HOME/.kube

sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

sudo chown $(id -u):$(id -g) $HOME/.kube/config

7. Vérification du bon fonctionnement du cluster
kubectl get nodes




8. Install the Calico network add-on (Control plan)
Calico est un système de réseau et de sécurité pour conteneurs, sur un cluster Kubernetes.
Via la commande ci-dessous, Kubernetes télécharge et applique la configuration définie dans le fichier YAML qui sera téléchargé, installant ensuite Calico pour gérer le réseau, les politiques de sécurité, et d'autres fonctionnalités de réseau au sein de notre cluster.
kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.25.0/manifests/calico.yaml

Ce manifest va crée un ensemble d'objet utile pour notre réseau grace à l'outil Calico.



A présent joignons les workers au control plan
8. Génération de la commande de communication avec le "Control plan" (Control plan)
kubeadm token create --print-join-command




Cette opération nous permet de générer un nouveau token d'authentification dans notre cluster Kubernetes tout en affichant la commande complète à utiliser sur les autres nœuds qui permettra de rejoindre le cluster.
sudo kubeadm join 172.31.23.252:6443 --token 6a91sy.5al82ueyuhtep9a4 --discovery-token-ca-cert-hash sha256:f46933aa3d09c2b58f649e2ff4bc8fab2ce0123bf912efe27ad803725a0cd50a

Nous allons exécuter cette commande en sudo sur les workers


Les workers on bien rejoint le cluster
NB : vérifiez les groupes de sécurités au niveau des workers sur AWS afin de s'assurer que la communication est bien possible sur le port 6443

Vérification des nodes
kubectl get nodes




Documentation
Installer Docker sur ubuntu
Installer kubeadm sur ubuntu
Creating a Single Control-Plane Cluster with kubeadm



Ansible | Création de rôles Ansible et mise en place des rôles distant via Gitlab.
Carlin FONGANG — Sun, 07 Apr 2024 21:59:36 GMT

Carlin FONGANG | LinkedIn | GitLab | GitHub | Credly

Contexte
Notre plan d'action vise à améliorer la collaboration avec une autre équipe en transformant un playbook "monolithique" en un ensemble de rôles modulaires pour une adaptation aisée. Nous intégrerons également des playbooks de test pour faciliter l'évaluation de nos rôles, ainsi que l'intégration rapide dans d'autres processus de déploiement. De plus, nous créerons un dépôt privé pour nos rôles, permettant ainsi une gestion centralisée pour toute utilisation future. Ces mesures renforceront les workflows intégrant ces rôles comme tâches ou actions et augmenteront notre capacité à répondre aux besoins spécifiques de l'équipe.
Objectifs
Dans ce laboratoire, nous allons :

Rédiger des rôles permettant de déployer des conteneurs Docker. Cette étape favorisera une modularité accrue, offrant ainsi la flexibilité nécessaire pour une adaptation contextuelle.

Intégrer deux playbooks de tests (httpd/Apache et Wordpress via docker-compose) à nos rôles pour une intégration souple dans les processus de déploiement existants.

Provisionner une instance cible EC2 à l'aide de Terraform et configurer cette instance avec Ansible afin d'y déployer nos nouveaux playbooks en guise de test.

Établir un hébergement distant pour nos rôles, destiné à la conservation et à la gestion centralisée de ceux-ci, ce qui renforcera l'efficacité et la réutilisation des ressources au sein de notre équipe.


Ces actions permettront d'optimiser notre workflow et de répondre aux exigences spécifiques de l'équipe.
Lien vers le playbook à transformer en rôle
Prérequis
Disposer d'une machine avec ansible déjà installées.
Dans notre cas, nous allons provisionner une instances EC2 s'exécutant sous Ubuntu grace au provider AWS, à partir delaquelle nous effectuerons toutes nos opérations.
Documentation complémentaire :
Documentation Ansible
Provisionner une instance EC2 sur AWS à l'aide de Terraform
Provisionner une instance EC2 sur AWS à l'aide d'Ansible
1. Refactorisation de notre playbook initial en rôle
Rappelons que nous avons mis en place un playbook permettant de lancer un conteneur Apache consultable ici, et un autre permettant de déployer des conteneurs Wordpress conultable ici, ceci via docker-compose.
Dans la suite, nous allons transformer les différentes tâches du playbook nécessaires au déploiement d'un conteneur (par exemple Apache/httpd), en rôle. Ainsi, nous changerons le fichier de playbook de la description de ces tâches et nous ferons simplement appel aux rôles, dont nous pourrons modifier le comportement via des variables.
2. Définition des taches
Pour déployer un conteneur, il faut suivre des étapes préparatoires essentielles :

Préparer l'hôte Ansible en installant les paquets nécessaires.

Installer Terraform sur la machine Ansible pour gérer le provisionnement de l'infrastructure AWS.

Utiliser Terraform pour provisionner l'infrastructure et récupérer l'IP de l'instance créée.

Vérifier la connectivité SSH avec la nouvelle instance avant toute opération.

Installer les paquets requis, dont Docker, sur l'instance cible.

Copier le template Jinja depuis Ansible vers la machine distante.

Déployer le conteneur en utilisant le template Jinja et monter les volumes appropriés.


3. Création des différents roles
Le playbook initial dont on va s'inspirer pour réaliser nos rôles se trouve dans le repository suivant : Déployez un conteneur Apache (httpd) à l'aide d'un palybook Ansible
Afin de respecter les normes de création des rôles sous Ansible, nous allons organiser notre projet (local-role) en sous répertoires avec une nomenclature spécifique comme décrit ci-dessous :



Pour donner un peu de contexte : Dans un rôle Ansible, chaque dossier et fichier a un but spécifique pour organiser et exécuter les tâches de configuration :

tasks/main.yml : Contient les principales tâches à exécuter par le rôle.

handlers/main.yml : Définit les handlers, des tâches spéciales exécutées en réponse à d'autres tâches.

defaults/main.yml : Spécifie les valeurs par défaut des variables utilisées dans le rôle.

vars/main.yml : Stocke les variables du rôle qui ne devraient pas être modifiées par l'utilisateur.

files/ : Contient les fichiers statiques à copier sur les hôtes cibles.

templates/ : Stocke les templates Jinja2 qui seront traités et copiés sur les hôtes.

meta/main.yml : Contient les métadonnées du rôle, comme les dépendances.

tests/inventory et tests/test.yml : Utilisés pour tester le rôle.


Cette structure aide à la modularité et à la réutilisation des manifest Ansible dans un contexte de travail collaboratif.
Dans notre cas nous mettrons en place et exploiterons une partie de ces repertoires.
1. Role "setup_environment"
1.1. Définition du tasks/main.yml
Ce rôle Ansible est conçu pour mettre à jour le cache apt et installer une série de paquets essentiels sur les distributions Debian, y compris Ubuntu. Il inclut des outils et des bibliothèques couramment utilisés tels qu'unzip, Python, curl et git, en s'assurant que leur état soit présent sur la machine cible. La tâche devient effective uniquement si le système d'exploitation est identifié comme une distribution Debian, garantissant ainsi une exécution conditionnelle basée sur l'environnement du système.
Ce scipt sera décrit dans le fichier local-role/roles/setup_environment/tasks/main.yml
---
- name: Update apt cache and install packages
  ansible.builtin.apt:
    name:
      - unzip
      - python3
      - python3-pip
      - apt-transport-https
      - ca-certificates
      - curl
      - gnupg-agent
      - software-properties-common
      - wget
      - git
      - gnupg-agent
      - software-properties-common
      - wget
    state: present
    update_cache: true
  become: true
  when: ansible_os_family == "Debian"

1.2. Définition du meta/main.yml
Le fichier meta/main.yml sous Ansible sert à définir les métadonnées d'un rôle. Ces métadonnées incluent des informations telles que les dépendances du rôle (autres rôles nécessaires pour son fonctionnement), les plateformes (systèmes d'exploitation) supportées, et d'autres détails qui aident Ansible Galaxy (le répertoire de rôles Ansible) à indexer et classer le rôle. Ce fichier permet également de spécifier les versions minimales d'Ansible requises pour le rôle, facilitant ainsi la gestion des dépendances de manière plus transparente et efficace.
Dans notre cas, nous allons héberger nos rôles sur GitLab afin de les utiliser comme une sorte de "Galaxy". Il est donc nécessaire de bien décrire les fichiers meta pour nos rôles.
Le scipt ci-dessous sera décrit dans le fichier local-role/roles/setup_environment/meta/main.yml
galaxy_info:
  author: Carlin_FONGANG
  description: Update apt cache and install packages on local compute 
  company: Carlin_FONGANG

  license: MIT
  min_ansible_version: 2.16.5

  platforms:
    - name: Ubuntu
      versions:
      - focal    # Ubuntu 20.04
      - bionic   # Ubuntu 18.04
      - jammy    # Ubuntu 22.04
    - name: Debian
      versions:
      - bullseye # Debian 11
      - buster   # Debian 10
  galaxy_tags:
    - terraform
    - aws
dependencies: []

1.3. Définition du tests/test.yml
Nous pouvons mettre en palce un playbook de test pour vérfie la fiabilité de ce role
nano local-role/roles/setup_environment/tests/test.yml

- hosts: localhost
  become: true
  roles:
    - setup_environment

  tasks:
    - name: Vérifier que les paquets nécessaires sont installés
      ansible.builtin.package_facts:
        manager: auto

    - name: Tester la présence des paquets
      assert:
        that: 
          - "'unzip' in ansible_facts.packages"
          - "'python3' in ansible_facts.packages"
          - "'python3-pip' in ansible_facts.packages"
          - "'apt-transport-https' in ansible_facts.packages"
          - "'ca-certificates' in ansible_facts.packages"
          - "'curl' in ansible_facts.packages"
          - "'gnupg-agent' in ansible_facts.packages"
          - "'software-properties-common' in ansible_facts.packages"
          - "'wget' in ansible_facts.packages"
          - "'git' in ansible_facts.packages"
        fail_msg: "Un ou plusieurs paquets requis ne sont pas installés."
        success_msg: "Tous les paquets requis sont installés."

1.4. Test du playbook setup_environment
cd local-role


Test du role setup_environment

ansible-playbook roles/setup_environment/tests/test.yml -K -vvv

Cette commande exécute le playbook Ansible test.yml situé dans le répertoire roles/setup_environment/tests.
L'option -K demande à Ansible d'afficher un prompt pour saisir le mot de passe de privilège (sudo), nécessaire pour exécuter certaines tâches demandant des droits élevés.
L'option -vvv active un mode de verbosité très détaillé, offrant un aperçu approfondi du déroulement du playbook, ce qui est utile pour le débogage ou pour comprendre précisément les opérations effectuées lors de l'exécution.

Résultat du test



Paquets requis installés

L'on peut voir que le playbook de test à pu être déployé entièrement et que tous les paquets sont bien installés.
2. Role "install_terraform"
Ce rôle Ansible permet de télécharger, installer et vérifier la version prédéfinie de Terraform sur une machine ansible. Il commence par télécharger l'archive de Terraform depuis le site officiel de HashiCorp, en spécifiant la version et l'architecture désirées. Ensuite, il extrait l'archive dans /usr/local/bin pour installer Terraform. Enfin, il exécute Terraform pour vérifier l'installation et affiche la version installée, assurant ainsi que Terraform est prêt à être utilisé.
2.1. Définition du tasks/main.yml
nano local-role/roles/install_terraform/tasks/main.yml

---
- name: Download Terraform
  ansible.builtin.get_url:
    url: "https://releases.hashicorp.com/terraform/{{ terraform_version }}/terraform_{{ terraform_version }}_{{ terraform_architecture }}.zip"
    dest: "/tmp/terraform_{{ terraform_version }}_{{ terraform_architecture }}"
  become: true

- name: Unzip Terraform
  ansible.builtin.unarchive:
    src: "/tmp/terraform_{{ terraform_version }}_{{ terraform_architecture }}"
    dest: "/usr/local/bin"
    remote_src: yes
    creates: "/usr/local/bin/terraform"
  become: true

- name: Verify Terraform installation
  ansible.builtin.command: terraform version
  register: terraform_version
  changed_when: false

- name: Show Terraform version
  debug:
      msg: "Terraform version installed: {{ terraform_version.stdout }}"

2.2. Définition du defaults/main.yml
terraform_version: "1.7.5"
terraform_architecture: "linux_amd64"

Ces lignes définissent deux variables pour une utilisation avec Terraform dans le fichier de configuration tasks/main.yml.
terraform_version: "1.7.5" spécifie la version de Terraform à utiliser, tandis que terraform_architecture: "linux_amd64" indique l'architecture cible pour laquelle Terraform est destiné, dans ce cas, Linux 64 bits. Ces variables sont ensuite utilisées pour télécharger la version correcte de Terraform correspondant à ces spécifications.
2.3. Définition du meta/main.yml
Pour ce fichier, nous allons simplement reprendre le fichier décrit dans la section " 1.2. Définition du meta/main.yml"
2.4. Définition du tests/test_tf.yml
Ce playbook de test permet de valider l'installation de Terraform sur l'instance Ansible (l'instance sur laquelle nous travaillons).
nano roles/install_terraform/tests/test_tf.yml

---
- hosts: localhost
  gather_facts: false
  roles:
    - ../../install_terraform/
  tasks:
    - name: Obtenir la version de Terraform
      command: terraform -v
      register: terraform_version_output

    - name: Afficher la version de Terraform
      debug:
        msg: "La version de Terraform installée est : {{ terraform_version_output.stdout_lines[0] }}"

2.5. Test du playbook install_terraform
cd local-role


Test du role install_terraform

ansible-playbook roles/install_terraform/tests/test_tf.yml -K -vvv


Résultat du test_tf


Vérification de la version de terraform



L'on peut voir que le playbook de test à pu être déployé entièrement et que la version de Terraform souhaitez à bien été installée.
3. Role "provide_compute"
3.1. Définition du tasks/main.yml
Ce rôle Ansible effectue plusieurs tâches liées à la gestion d'une infrastructure, notamment le clonage d'un dépôt Git spécifié, l'initialisation et l'application de configurations Terraform dans un répertoire cible, et la gestion d'informations sur une instance EC2 qui sera provisionnée. Il commence par cloner un dépôt Git contenant les manifest terraform, puis utilise terraform init -reconfigure pour initialiser et terraform apply -auto-approve appliquer la configuration spécifiée. Enfin, il lit l'adresse IP de l'instance EC2 provisionnée à partir d'un fichier généré et ajoute cette information à un fichier 'hosts.yml', permettant ainsi une intégration facile aux autres opérations Ansible qui vont suivre.
---
- name: Clone repository
  ansible.builtin.git:
    repo: "{{ repo_url }}"
    dest: "{{ repo_dest }}"
    version: "{{ repo_tag }}"
    update: yes

- name: Initialize Terraform
  ansible.builtin.command:
    cmd: terraform init -reconfigure
    chdir: "{{ tf_init_apply_path }}"

- name: Apply Terraform configuration
  ansible.builtin.command:
    cmd: terraform apply -auto-approve
    chdir: "{{ tf_init_apply_path }}"

- name: Read EC2 instance IP from generated file
  ansible.builtin.include_vars:
    file: "{{ ec2_info_file_path }}"
    name: ec2_info

- name: Add EC2 instance IP to 'hosts.yml'
  ansible.builtin.lineinfile:
    path: "{{ hosts_file_path }}"
    line: "          ansible_host: {{ ec2_info.ec2_info.server_public_ip }}"
    create: yes
  delegate_to: localhost

- name: Debug ec2_info
  ansible.builtin.debug:
    var: ec2_info #

3.2. Définition du defaults/main.yml
repo_url: "https://gitlab.com/CarlinFongang-Labs/Ansible/tf-provide-target-instance.git"
repo_dest: "/tmp/tf-provide-target-instance"
repo_tag: "main"
tf_init_apply_path: "/tmp/tf-provide-target-instance/ec2_target_host"
ec2_info_file_path: "/tmp/tf-provide-target-instance/ec2_target_host/public_ip.yml"
hosts_file_path: "~/local-role/hosts.yml"

Ces variables sont configurées pour le rôle Ansible détaillé plus haut :

repo_url : URL du dépôt Git contenant la configuration Terraform.

repo_dest : Emplacement local où le dépôt sera cloné.

repo_tag : Branche ou tag du dépôt à cloner.

tf_init_apply_path : Dossier contenant les fichiers de configuration Terraform à initialiser et appliquer.

ec2_info_file_path : Chemin vers le fichier stockant l'adresse IP publique de l'instance EC2 générée.

hosts_file_path : Emplacement du fichier hosts.yml à mettre qui sera mis à jour avec l'adresse IP de l'instance EC2 une fois celle ci provisionné à l'aide de Terraform.


toutes ces variables sont ajustable dans le fichier group_vars/all.yml, selon le contexte d'utilisation
3.2. Définition du meta/main.yml
Pour ce fichier, nous allons simplement reprendre le fichier décrit dans la section " 1.2. Définition du meta/main.yml"
3.3. Définition du tests/test_provide.yml
Ce playbook de test permet de valider le bon fonctionneement du role provide_compute .
nano roles/provide_compute/tests/test_provide.yml

---
- hosts: localhost
  gather_facts: false
  roles:
    - ../../provide_compute

  tasks:
    - name: Afficher l'adresse IP de l'instance EC2
      debug:
        msg: "L'adresse IP de l'instance EC2 est : {{ ec2_info.ec2_info.server_public_ip }}"

3.4. Test du playbook provide_compute
Afin de tester ce playbook, nous aurons besoin de mettre en place un bucket "s3" pour le stockage du Remote State, et récupérer également la paire de clé de sécurité de l'utilisateur AWS.
une fois ces informations récupérées :

Exporter la paire de clés

export AWS_ACCESS_KEY_ID="AKIAQ2LRBUZA7D32KAX3"
export AWS_SECRET_ACCESS_KEY="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"

Remplacer les valeurs par ceux du compte AWS à utiliser

Créer un Bucket s3

L'usage du manifest Terraform défini par défaut dans le rôle, est conditionné par l'existence d'un bucket où sera stocké le tfstate, le nom de ce bucket est consultable dans le code Terraform - Provisionnement instance cible



Notez qu'il est également possible de forker le projet Terraform et de modifier le nom du bucket pour l'ajuster à un contexte spécifique, il faudra alors modifier la variable "repo_url" dans le fichier "group_vars/all.yml", afin de définir le nouveau dépôt du code Terraform.
Une fois ces conditions préalables remplies, on peut tester le playbook

Test du role provide_compute

ansible-playbook roles/provide_compute/tests/test_provide.yml -K -vvv


Résultat du test_provide



Instance provisionnée et ip disponible

Instance provisionnée

L'on peut voir que le playbook de test à pu être déployé entièrement et qu'une instance ec2 à été provisionnée ainsi qu'une adresse Elastic IP.
De plus ce role permet d'écrire directement l'EIP de la nouvelle instance dans le fichier hosts.yml, ce qui va être pratique par la suite pour effectuer les diverses opérations sur notre nouvelle machine distante.
4. Role "check_ssh"
4.1. Définit du tasks/main.yml
Le rôle check_ssh est conçu pour vérifier la disponibilité du service SSH sur des serveurs. Il utilise la tâche wait_for pour attendre que le port 22 (SSH) sur les hôtes spécifiés soit accessible, assurant ainsi que les serveurs sont prêts pour des connexions SSH. Cette vérification est effectuée sur tous les hôtes listés dans le groupe dynamic_hosts.
---
- name: Refresh Inventory to Ensure Latest Hosts are Used
  meta: refresh_inventory

- name: Wait for SSH to come up on the servers
  ansible.builtin.wait_for:
    host: "{{ hostvars[item].ansible_host }}"
    port: 22
    state: started
  loop: "{{ groups['dynamic_hosts'] }}"
  when: "'dynamic_hosts' in groups"

4.2. Définition du meta/main.yml
Pour ce fichier, nous allons simplement reprendre le fichier décrit dans la section "1.2. Définition du meta/main.yml"
4.3. Définition du tests/test_check_ssh.yml
Nous avons provisionné une instance ec2 dans l'étape précédente, nous allons à présent vérifier qu'il est possible de se connecter en ssh à cette instance
nano roles/check_ssh/tests/test_check_ssh.yml

---
- hosts: dynamic_hosts
  gather_facts: false
  roles:
    - ../../check_ssh
  tasks:
    - name: Afficher le message de réussite
      debug:
        msg: "Connexion ssh établie avec succes !"
      when: ansible_failed_task is undefined

4.4. Test du playbook test_check_ssh
ansible-playbook roles/check_ssh/tests/test_check_ssh.yml -K -vvv



Connexion ssh réussie

5. Role "prepare_docker"
5.1. Définit du tasks/main.yml
Ce rôle Ansible est conçu pour installer Docker et ses dépendances sur un système. Il commence par mettre à jour le cache des paquets et installer des prérequis. Ensuite, il ajoute la clé GPG officielle de Docker et installe Docker en utilisant un script récupéré depuis le site officiel de Docker. Le playbook ajoute également l'utilisateur courant au groupe Docker pour permettre l'exécution de commandes Docker sans sudo. Enfin, il assure l'installation de pip et installe Docker Compose, en vérifiant la version installée.
---
- name: Install Docker and dependencies
  ansible.builtin.apt:
    name:
      - apt-transport-https
      - ca-certificates
      - curl
      - software-properties-common
      - gnupg-agent
    state: present
    update_cache: yes

- name: Add Docker's official GPG key
  ansible.builtin.apt_key:
    url: https://download.docker.com/linux/ubuntu/gpg
    state: present
  when: ansible_os_family == "Debian"

- name: Install Docker
  ansible.builtin.shell: curl -fsSL https://get.docker.com -o get-docker.sh && sh get-docker.sh

- name: Add current user to Docker group
  ansible.builtin.user:
    name: "{{ ansible_env.SUDO_USER | default(ansible_env.USER) }}"
    groups: docker
    append: true

- name: Ensure pip is installed
  ansible.builtin.package:
    name: python3-pip
    state: present
  become: true

- name: Install Docker Compose
  block:
    - name: Download Docker Compose binary
      ansible.builtin.get_url:
        url: "https://github.com/docker/compose/releases/download/{{ docker_compose_version }}/docker-compose-{{ ansible_system }}-{{ ansible_architecture }}"
        dest: "/usr/local/bin/docker-compose"
        mode: '0755'
      become: true

    - name: Verify Docker Compose installation
      command: docker-compose --version
      register: docker_compose_version
      failed_when: docker_compose_version.rc != 0

    - name: Output Docker Compose version
      debug:
        msg: "Docker Compose version installed: {{ docker_compose_version.stdout }}"
  when: ansible_os_family == "Debian" or ansible_os_family == "RedHat"

5.2. Définition du defaults/main.yml
Dans ce fichier, nous avons déclarer la version de docker-compose à installer, la variable docker_compose_version est ajustable dans le fichier group_vars/all.yml
docker_compose_version: "1.29.2"

5.2. Définition du meta/main.yml
Pour ce fichier, nous allons simplement reprendre le fichier décrit dans la section " 1.2. Définition du meta/main.yml"
5.3. Définition du tests/test_docker_install.yml
- name: Deploy Apache container
  hosts: dynamic_hosts
  become: true
  vars_files:
    - group_vars/all.yml
  roles:
    - ../../prepare_docker

5.4. Test du playbook prepare_docker
ansible-playbook roles/prepare_docker/tests/test_docker_install.yml -K -vvv



Bonne exécution du playbook

Vérification de docker sur l'instance cible

6. Role "copy_template"
6.1. Définit du tasks/main.yml
Ce rôle utilise le module ansible.builtin.template pour copier un template de fichier web, spécifiquement index.html.j2, vers un chemin défini sur la machine distante. Il définit également les permissions du fichier cible à '0644', assurant ainsi que le fichier est lisible par tous mais modifiable uniquement par le propriétaire. Ce processus permet de personnaliser et de déployer facilement des fichiers de configuration ou des pages web sur des serveurs distants.
- name: Copy website file template
  ansible.builtin.template:
    src: index.html.j2
    dest: "{{ remote_template_path }}"
    mode: '0644'

6.2. Définition du defaults/main.yml
remote_template_path: "/home/{{ ansible_env.SUDO_USER | default(ansible_env.USER) }}/index.html" #1

6.2. Définition du meta/main.yml
Pour ce fichier, nous allons simplement reprendre le fichier décrit dans la section "1.2. Définition du meta/main.yml"
6.3. Définition du tests/test_copy.yml
nana roles/copy_template/tests/test_copy.yml

- name: Copy Template jinja on target instance
  hosts: dynamic_hosts
  become: true
  roles:
    - ../../copy_template
  tasks:
    - name: Afficher le message de réussite
      debug:
        msg: "Opération réussie !"
      when: ansible_failed_task is undefined

6.4. Test du playbook test_copy
ansible-playbook roles/copy_template/tests/test_copy.yml -K -vvv



Opération de copie réussie

En se connectant sur l'instance cible, on peut constater que le fichier est bel et bien copié


fichier index.html copié sur l'instance cible

6. Role "deploy_container"
6.1. Définit du tasks/main.yml
Ce rôle Ansible utilise le module community.docker.docker_container pour télécharger et exécuter un conteneur Docker spécifié. Il définit le nom du conteneur, l'image à utiliser, les ports à exposer, et monte un volume pour le contenu web. Le conteneur est configuré pour démarrer automatiquement et adhérer à une politique de redémarrage continue, garantissant sa disponibilité constante.
---
- name: Pull and run a Docker container
  community.docker.docker_container:
    name: "{{ container_name }}"
    image: "{{ container_image }}"
    ports: "{{ container_ports }}"
    volumes:
      - "{{ remote_template_path }}:{{ document_root }}/index.html"
    state: started
    restart_policy: always

6.2. Définition du defaults/main.yml
container_name: webapp
container_image: httpd
container_ports:
  - "80:80"
document_root: "/usr/local/apache2/htdocs" #2
remote_template_path: "/home/{{ ansible_env.SUDO_USER | default(ansible_env.USER) }}/index.html"

Ces variables sont configurées pour le rôle visant à déployer un conteneur Docker :

container_name: Identifie le nom du conteneur, ici webapp.

container_image: Spécifie l'image Docker à utiliser, dans ce cas httpd pour un serveur web Apache.

container_ports: Définit les ports à exposer, mappant le port 80 du conteneur sur le port 80 de l'hôte.

document_root: Le chemin où les fichiers du site web doivent être stockés dans le conteneur, /usr/local/apache2/htdocs étant le répertoire racine d'Apache.


ces variables sont ajustable dans le fichier group_vars/all.yml selon le contexte.
6.2. Définition du meta/main.yml
Pour ce fichier, nous allons simplement reprendre le fichier décrit dans la section " 1.2. Définition du meta/main.yml"
6.3. Définition du tests/test_deploy_container.yml
---
- name: Deploy contenair
  hosts: dynamic_hosts
  become: true
  roles:
    - ../../deploy_container
  tasks:
    - name: Afficher le message de réussite
      debug:
        msg: "Opération réussie !"
      when: ansible_failed_task is undefined

6.4. Test du playbook test_deploy_container
ansible-playbook roles/deploy_container/tests/test.yml -K -vvv



Déploiement du conteneur réussi

Conteneur en cours d'exécution

En se connectant à l'instance cible, on peut voir que le conteneur est en cours

Vérification via navigateur



L'application webApp ainsi que le Template Jinja son bien déployé

3. Définition de playbook intégrant les roles
3.1. Playbook de déploiement d'un conteneur httpd + template jinja : "deploy_httpd.yml"

Description du playbook :

---
- name: Setup environment
  hosts: localhost
  roles:
    - setup_environment

- name: Install Terraform & provide instance
  hosts: localhost
  roles:
    - install_terraform
    - provide_compute
  tasks:
    - name: Refresh Inventory to Ensure Latest Hosts are Used
      meta: refresh_inventory

- name: Verify SSH Connectivity on Dynamic Hosts
  hosts: dynamic_hosts
  gather_facts: no
  roles:
    - check_ssh

- name: Deploy Apache container
  hosts: dynamic_hosts
  become: true
  roles:
    - prepare_docker
    - copy_template
    - deploy_container

Ce playbook Ansible est structuré en plusieurs phases pour configurer un environnement, installer Terraform, provisionner une instance, vérifier la connectivité SSH aux hôtes dynamiques, et déployer un conteneur Apache. Il utilise des rôles spécifiques pour chaque étape, définis et documentés précédement. Il assure aussi la mise à jour de l'inventaire pour inclure les hôtes récemment provisionnés.

Déploiement du playbook

ansible-playbook deploy_httpd.yml -K -vvv



Le Mot de passe de l'utilisateur sudo est demandé pour l'opération

L'installation est achevé et une nouvelle adresse est renseignée dans le fichier hosts


Résultat du déploiement



Conteneur httpd et Template Jina déployé

3.2. Playbook de déploiement de conteneurs Wordpress

Description du playbook :

---
- name: Setup environment
  hosts: localhost
  roles:
    - setup_environment

- name: Install Terraform & provide instance
  hosts: localhost
  roles:
    - install_terraform
    - provide_compute
  tasks:
    - name: Refresh Inventory to Ensure Latest Hosts are Used
      meta: refresh_inventory

- name: Verify SSH Connectivity on Dynamic Hosts
  hosts: dynamic_hosts
  gather_facts: no
  roles:
    - check_ssh

- name: Deploy Wordpress
  hosts: dynamic_hosts
  become: true
  roles:
    - wordpress

Ce playbook Ansible est structuré en plusieurs phases pour configurer un environnement, installer Terraform, provisionner une instance, vérifier la connectivité SSH aux hôtes dynamiques, et déployer un conteneur Wordpress. Il utilise des rôles spécifiques pour chaque étape, définis et documentés précédement. Il assure aussi la mise à jour de l'inventaire pour inclure les hôtes récemment provisionnés.

Déploiement du playbook

ansible-galaxy install -r roles/requirements.yml -f

ansible-playbook deploy_wordpress.yml -K -vvv



Exécution du Playbook

Ajout de l'EIP de la nouvelle instance au fichier hosts


Résultat

En se connectant à l'instance cible, l'on peux intéroger les conteneur en cours d'exécution


Conteneurs Wordpress en cours d'exécution

Interface Wordpress

3. Définition de playbook intégrant les roles distant (hébergés sur gitlab)
Pour déployer de nouveaux playbooks utilisant des rôles définis précédemment, mais cette fois ci en remote, (usage semblable aux rôles sur "Ansible Galaxy"), ces rôles seront hébergés sur GitLab à l'adresse : RolesHub.
Après avoir hébergé les rôles sur GitLab, le projet sera restructuré en actualisant le fichier roles/requirement.yml avec les sources des rôles et en supprimant les sous-répertoires inutiles du dossier roles. La nouvelle structure du projet sera ainsi simplifiée.
La nouvelle strucutre du projet sera alors la suivante :


Définintion du fichier roles/requirement.yml

roles:
  - src: https://gitlab.com/CarlinFongang-Labs/Ansible/Roleshub/setup_environment.git
    scm: git
    version: "main"
    name: setup_environment

  - src: https://gitlab.com/CarlinFongang-Labs/Ansible/Roleshub/install_terraform.git
    scm: git
    version: "main"
    name: install_terraform

  - src: https://gitlab.com/CarlinFongang-Labs/Ansible/Roleshub/provide_compute.git
    scm: git
    version: "main"
    name: provide_compute

  - src: https://gitlab.com/CarlinFongang-Labs/Ansible/Roleshub/check_ssh.git
    scm: git
    version: "main"
    name: check_ssh

  - src: https://gitlab.com/CarlinFongang-Labs/Ansible/Roleshub/prepare_docker.git
    scm: git
    version: "main"
    name: prepare_docker

  - src: https://gitlab.com/CarlinFongang-Labs/Ansible/Roleshub/copy_template.git
    scm: git
    version: "main"
    name: copy_template

  - src: https://gitlab.com/CarlinFongang-Labs/Ansible/Roleshub/deploy_container.git
    scm: git
    version: "main"
    name: deploy_container

Ce fichier décrit plusieurs rôles Ansible, chacun provenant de dépôts GitLab, avec des informations sur le type de gestion de configuration (Git), la version (tous sur "main"), et leurs noms. Ces rôles couvrent diverses tâches comme la configuration de l'environnement, l'installation de Terraform, la vérification de la connectivité SSH, la préparation de Docker, la copie de modèles de site web, et le déploiement de conteneurs Docker, facilitant la gestion automatisée d'infrastructures et la réutilisabilité des roles.

Exécution du playbook

ansible-galaxy install -r roles/requirements.yml -f



ansible-playbook deploy_httpd.yml -k -vvv


Déploiement du conteneur httpd achevé

Le conteneur est en cours d'exécution

L'application est consultable depuis le navigateur

Dépôt du projet utilisant les roles en remote (roles distant sur Gitlab) : Remote Role