# Projet DevOps

## Vue d'ensemble et objectifs

Ce projet vise à la réalisation d'une infrastructure d'hébergement web en haute-disponibilité avec les méthodes et outils vus durant le cursus.

Durant ce projet, vous aurez à :

* mettre en place, configurer et connecter des outils entre eux,
* planifier et organiser vos ressources et votre équipe,
* écrire du code et de la documentation
* livrer et présenter votre travail.

Vous croiserez aussi des composants système et réseaux que vous n'avez peut-être pas vu ou utilisé jusque là. Il faudra alors vous renseigner par vous-mêmes sur leur fonctionnement et leur intégration dans le projet.

## Partie I : provisionning automatisé sur une infrastructure classique

Mots-cléfs : `linux`, `réseau`, `provisionning`, `ansible`, `puppet`, `monitoring`

### Préparation de l'infrastructure

Dans un premier dépot Git, écrire le code shell, Vagrant ou Terraform (avec l'hébergeur de votre choix), permettant de :

* Monter une infrastructure avec 5 serveurs
* Mettre en réseau ces 5 serveurs sur un même réseau interne virtuel (ex: via un _vRack_)
* Chacun de ces serveurs doit posséder deux cartes réseaux :
* `eth0`: lui donnera accès à internet,
* `eth1`: lui donnera accès à un réseau interne entre les serveurs
* Prenez soin de bien désactiver le DHCP fourni par défaut sur ce réseau virtuel.

### Provisionning

Ecrivez une configuration Ansible ou Puppet pour faire automatiquement les actions suivantes :

#### Configuration réseau

* Installer DNSmasq sur l'un des serveurs (on l'appellera par la suite `s0.infra`).
* Coté DHCP:
* ce serveur attribuera aux autres serveurs des IP sur le réseau `192.168.50.0/24` en fonction de leur adresse MAC sur `eth1` (service DHCP)
* ce serveur ne DOIT PAS fournir de gateway pour la route par défaut
* Coté DNS:
* ce serveur attribuera également un nom de domaine (ex: `s0.infra`, `s1.infra`, etc.) aux autres machines.
* Ce serveur relaiera les requêtes vers `1.1.1.1` (DNS Cloudflare) pour les domaines qu'il ne connait pas
* Remplir le `/etc/resolv.conf` de toutes les machines pour qu'elles utilisent `s0.infra` comme serveur DNS principal

#### Installation des services

* Installer _Apache 2_ + _PHP 7_ sur `s1.infra` et `s2.infra`
* Ce service devra écouter sur le port 80 sur `eth0`
* Installer _HAproxy_ sur `s0.infra`
* Ce service devra écouter sur le port 80 sur `eth0` et rediriger alternativement (round-robin) vers le port 80 de `s1.infra` et `s2.infra` (ses back-ends)
* Si l'un des back-ends devient indisponible, il doit etre écarté de la redirection
* Installer _MariaDB_ sur `s3.infra`
* Installer _NFS Server_ sur `s4.infra`
* Ce serveur NFS partagera le dossier `/home/data` sur le réseau interne
* Ce dossier sera monté sur `/mnt/nfs` depuis `s1.infra` et `s2.infra`

### Déploiement de deux sites wordpress

* Téléchargez, installer et configurez automatiquement trois sites wordpress sur les serveurs web.
* Ils devront être accessible aussi bien de `s1.infra` que de `s2.infra`
* Ils devront répondre pour les noms de domaines suivants :
* devops.com
* devsec.com
* devsecops.com

__Note:__ Pensez à bien configurer le `/etc/hosts` de votre machine de test (windows, linux, etc.) pour que ces noms redirigent vers l'IP externe de votre machine `s0.infra`

## Partie II : sur une infrastructure "Cloud"

Mots-cléfs : `docker`, `déploiement continu`, `kubernetes`

### Préparation des images

Le travail se fera dans un dépots Git distinct du premier.

Nous allons chercher à créer une image pour le service _Dolibarr_.

Pour chaque service, écrire les scripts et configuration (`Dockerfile`, `docker-compose.yml`, etc.) permettant de :

* créer une image docker
* vérifier son bon fonctionnement
* pousser cette image en ligne sur DockerHub.

Notez que cette image:

* doit être basées sur Debian Buster 64 bits
* doit intégrer Apache2 et PHP 7 et les modules nécessaires à Dolibarr
* dépend d'un container MariaDB indépendant pour fonctionner

### Préparation de l'infrastructure

Créer un cluster Kubernetes avec 3 noeuds

* soit sur un opérateur Cloud de votre choix (Digital Ocean, Linode, OVH, Azure, AWS, GCP, etc)
* soit installé _on-premises_ (pour les plus motivés)
* sur des serveurs VPS
* ou sur des VM Vagrant

__Attention:__ la version _on-premises_ sera plus compliquée à gérer pour le load-balancing.

### Déploiement

Ecrire la configuration Kubernetes permettant de déployer le services suivants :

* _MariaDB_
* sur une seule réplique ;
* avec les bons volumes pour sauver les données et la configuration de l'application ;
* _Dolibarr_
* sur 2 répliques
* paramétré pour se connecter sur MariaDB ;
* avec les bons volumes pour sauver les données et la configuration de l'application ;
* un _load balancer_ permettra de balancer les requêtes entrantes d'une réplique à l'autre (round-robin).

### Déploiement continu

Utiliser un outil de déploiement continu (Jenkins, Travis, CircleCI, Gitlab-CI, etc) connecté à votre dépot Git de telle sorte que
* chaque `git push` déclanche le _rebuild_ des images concernées ;
* si le build de l'image réussi, alors la nouvelle version de l'image est déployée sur votre cluster.

## Points Bonus

* Mise en place d'un systeme de monitoring pour surveiller l'état de santé de vos serveur ou de vos services
* Utilisation d'outils DevOps qui n'ont pas été vus dans le cadre du cursus (ex: Terraform ou Packer)
* Automatisation de vos démonstrations
* Documentation de votre procédure de test pour valider chaque étape

## Méthodologie

### Organisation

Le projet sera réalisé en équipes de deux ou trois personnes.

Vous vous organiserez pour distribuer les taches afin que tout le monde participe aux deux parties du projet.

L'utilisation d'un outil de gestion de projet (gitlab, trello, etc.) sera fortement apprécié.

Note: à trois, donnez-vous à fond pour faire quelques élements bonus également.

### Suivi et questions

Vous pouvez envoyer un email avec vos questions à [e-mail]. Ce mail devra indiquer `[DEVOPS FITEC] QUESTION` dans le titre.

Une réponse sera fournie lors de la prochaine journée de suivi/accompagnement de projet.

### Rendu du projet

Le rendu sera fait par l'envoi d'un email, à destination de [e-mail]. Ce mail devra indiquer `[DEVOPS FITEC] RENDU FINAL` dans le titre.

Cet email listera les membres de votre groupe (nom, prénom & email)

Il devra également fournir les liens vers vos deux dépots GIT publics (distincts pour chaque partie).

Chaque dépot GIT contiendra un fichier `README.md` qui documentera votre démarche et expliquera étape par étape comment utiliser vos scripts pour obtenir l'infrastructure demandée dans ce projet.

### Soutenance

Durant la soutenance vous présenterez au jury le projet, ses enjeux et l'apport votre travail.

Vous expliquerez plus particulierement votre démarche de travail, l'organisation du projet et les différents points techniques (avec schéma, documentation, etc.)

Vous ferez la démonstration du bon fonctionnement de chacune des infrastructures que vous avez conçu. Le détail des démonstration attendues est précisé ci-dessous.

Vous pouvez utiliser un support de présentation (ex: diaporama).

#### Démonstration pour la Partie I

* Détruire les machines `s1.infra` dans votre l'infrastructure
* Montrer que les sites wordpress fonctionnent toujours et que le load-balancer redirige vers le seul serveur applicatif en fonctionnement
* Détruire ensuite `s0.infra` et `s2.infra` dans votre l'infrastructure
* Montrer que les sites wordpress ne fonctionnent plus)
* Re-déployez automatiquement avec vos scripts (ansible, puppet, etc.)
* Vous devez obtenir une infrastructure identique à la première fois.
* Vos données et votre site doivent être toujours fonctionnels

#### Démonstration pour la Partie II

* Détruire l'un des pods de Dolibarr
* Montrer que le service continue à fonctionner
* Montrer que la seconde réplique du Pod est revenue

:thumbsup: