DevOps avec des VM

• Contexte
• Architecture initiale
• La création d'un livrable
• La création des VM
• Le déploiement de l'application
• Que manque-t'il?
• L'incontournable zone d'hébergement

Contexte

Nous allons voir en pratique comment se passe le déploiement d'une application as code sur des VM Linux en déployant :

• PostgreSQL avec l'extension PostGIS pour stocker des données géographiques.
• GeoServer pour diffuser ces données en WMS et WFS.

Nous appellerons le système résultant GeoStack (afin d'avoir un nompour le dépôt dédié au déploiement : geostack-deploy).

Architecture initiale

Nous commencerons par l'architecture triviale suivante :

Nous en étudierons les limites par la suite.

La création d'un livrable (1/4)

Ne pas construire l'application en PRODUCTION

La création d'un livrable (2/4)

Produire et stocker un livrable à déployer

Pour le déploiement d'une application en PRODUCTION, il est important de :

• Tagger une version au niveau du gestionnaire de code source (ex : v0.1.0).
• Produire un livrable pour cette version du code.
• Stocker ce livrable.
• Déployer en PRODUCTION un livrable stocké en lieu sûr.

(c.f. Les 12 facteurs - V. Assemblez, publiez, exécutez)

Ce principe n'interdit pas de déployer en continu une version correspondant à la branche principale dans un environnement de DEV.

La création d'un livrable (3/4)

Packager sa propre application

La création d'un livrable (4/4)

Choisir des services déjà empaquetés

Dans le cas présent, nous avons cette chance :

• PostgreSQL met à disposition des binaires pour différents systèmes. Nous avons même un dépôt APT qui permettra d'utiliser apt-get install et apt-get upgrade
• GeoServer met lui aussi à disposition des livrables prêts à l'emploi.

La création des VM (1/5)

La variété des API

La création des VM (2/5)

Terraform

Pour gérer une infrastructure "as code" en production sans programmer les appels à ces API, nous pourrons nous appuyer sur Terraform qui apporte :

• Un langage déclaratif pour la création des ressources (machine virtuelle, réseau,...)
• Le support d'un grand nombre de fournisseurs dont :
  • Les clouds publics : AWS, Azure, Google Cloud Platform,...
  • Les clouds privés : vsphere, openstack,...

Nous nous contenterons dans un premier temps d'inspecter un exemple de création de VM Google Cloud avec Terraform : google_compute_instance.

La création des VM (3/5)

Vagrant (1/3)

Pour ce cours, nous allons plutôt utiliser Vagrant qui est lui aussi développé par HashiCorp et qui est l'équivalent de Terraform pour les environnements de développement.

La création des VM (4/5)

Vagrant (2/3)

Nous utilisons le dépôt mborne/vagrantbox pour créer des VM décrites dans un fichier Vagrantfile avec une commande (vagrant up) :

La création des VM (5/5)

Vagrant (3/3)

Nous soulignerons que :

• La principale difficulté traitée dans le dépôt mborne/vagrantbox est l'utilisation optionnelle d'un proxy sortant avec le plugin vagrant-proxyconf.
• Une annexe Vagrant explique comment créer ses propres Vagrantfile.
• Vagrant est aussi pratique pour créer une VM de DEV Linux avec un environnement graphique (apt-get install ubuntu-desktop)
• Nous créons ici des VM VirtualBox mais Vagrant supporte d'autres hyperviseurs (ex : KVM)
• Il existe un dépôt public d'image de VM pour vagrant.

Le déploiement de l'application

Principe

Nous avons avec Vagrant et Terraform des outils capables de créer nos VM as code.

Le déploiement de l'application

Les outils de gestion de configuration

Les outils de gestion de configuration sont les plus adaptés pour installer et configurer nos applications. Les plus connus sont :

• Ansible
• Chef
• Puppet

Le déploiement de l'application

Le choix d'Ansible

Nous allons nous appuyer sur Ansible qui est une solution :

• Libre, OpenSource et référencée dans le SILL (1)
• Basée sur l'utilisation du format YAML
• Implémentée en Python
• Permettant l'utilisation d'un orchestrateur de déploiement (ex : AWX, Jenkins, GitLab-CI,...) sans l'imposer.

(1) https://code.gouv.fr/sill - Socle interministériel de logiciels libres (qui est par ailleurs une excellente source de veille).

Le déploiement de l'application

Les principaux exécutables d'Ansible

Nous trouverons plusieurs exécutable avec Ansible :

• ansible qui permettra par exemple de lancer une commande sur les machines d'un inventaire.
• ansible-playbook qui sera utilisée pour traiter un ensemble de tâches décrites au format YAML.
• ansible-galaxy qui permettra de télécharger des rôles partagés pour construire vos playbooks (voir galaxy.ansible.com).
• ansible-vault qui permettra de chiffrer des secrets.

Le déploiement de l'application

Le principe de fonctionnement d'Ansible

sudo apt-get update
sudo apt-get install nginx

- name: Install nginx
  apt:
    name: nginx
    state: present
    update_cache: yes

Le déploiement de l'application

Le déploiement de GeoStack avec Ansible!

Présenter proprement les concepts d'Ansible demanderait plusieurs séances.

L'idée de ce cours n'étant pas de former à la rédaction de script Ansible, nous allons plutôt découvrir Ansible à l'aide des exemples suivants :

• mborne/vagrantbox - Ansible - QuickStart qui applique un post-traitement après création des VM vagrantbox.
• mborne/geostack-deploy qui assure le déploiement de GeoStack avec Ansible.

Nous utiliserons la procédure d'installation de Ansible dans l'annexe correspondante qui pointe des ressources utiles pour ceux qui souhaiteront approfondir.

Le déploiement de l'application

Conclusion sur Ansible (1/2)

Nous mémoriserons que Ansible permet de décrire as code le déploiement d'une application avec un fichier YAML qui sera exploitable comme suit :

# déploiement en QUALIF
ansible-playbook -i inventory/qualif playbooks/mon-application.yml

Le déploiement de l'application

Conclusion sur Ansible (2/2)

Nous insisterons sur l'apport de Ansible pour :

• Faciliter la rédaction et la maintenance des déploiements (YAML et nombreux modules disponibles rendant les procédures lisibles même sans connaissance d'Ansible).
• Gérer des paramètres en fonction des environnements (notamment par rapport à des scripts install-geoserver.sh)
• Permettre la réutilisation de scripts de déploiements complet (téléchargement de rôles avec ansible-galaxy, composition de playbook à partir de rôles,...)
• Traiter des actions uniquement en cas de changement (ex : éviter des redémarrages inutiles)

Le déploiement de l'application

Processus résultant

Que manque-t'il?

La sécurité! (1/2)

Nous ne pourrions pas procéder ainsi avec des VM exposées sur internet :

• Nos VM seraient rapidement la cible des nombreux bots qui scannent le web (voir extrait de logs illustrant ces attaques sur SSH)
• Nous finirions sur https://www.shodan.io

Que manque-t'il?

La sécurité! (2/2)

Il faudrait à minima :

• Configurer un pare-feu local (par exemple avec ufw)
• Configurer fail2ban pour bloquer les attaques par force brute sur SSH
• Blinder la configuration des VM ( c.f. dev-sec.io - DevSec Hardening Framework )
• ...

Nous noterons l'existence d'une alternative à fail2ban : CrowdSec où les IP suspectes sont partagées. Nous nous assurerons de respecter le RGPD avec ce type d'outil.

Que manque-t'il?

L'incontournable reverse proxy (1/2)

Il conviendrait aussi à minima de passer sur une architecture du type suivant en ajoutant un reverse proxy ("lb") :

Que manque-t'il?

L'incontournable reverse proxy (2/2)

Avec un reverse proxy, nous pourrions par exemple :

• Exposer publiquement les seuls services WMS et WFS de GeoServer (/wms, /wfs)
• Exposer l'interface d'administration de GeoServer (/geoserver) avec un filtrage par IP.

Que manque-t'il?

La mise en oeuvre de HTTPS

Que manque-t'il?

L'observabilité

Pour pouvoir exploiter ces deux composants, il faudrait :

• Configurer la centralisation des logs
• Configurer un système de supervision

Que manque-t'il?

Les sauvegardes (1/2)

En l'état, si l'une de nos machines vient à s'embraser : Les données sont perdues. Il serait donc important d'adopter une stratégie de sauvegarde et plusieurs options sont possibles :

• S'appuyer sur des mécanismes de snapshot de VM ou de leurs volumes.
• Exporter et externaliser régulièrement les seules données de l'application par exemple en créant une archive avec :
  • Une sauvegarde de la base PostgreSQL (pg_dump)
  • Les fichiers de GeoServer (GEOSERVER_DATA_DIR).

Voir Back up and restore GitLab où la commande gitlab-backup create permet de générer une sauvegarde de la base et des dépôts.

Que manque-t'il?

Les sauvegardes (2/2)

Nous soulignerons qu'une approche basée sur l'export des seules données sera préférable à l'approche par snapshot :

• Elle facilitera les tests de restauration hors production et les migrations (les snapshots incluants des éléments de configuration)
• Elle garantira la cohérence des sauvegardes (synchroniser les sauvegardes de 2 VM est délicat).
• Il sera plus simple de vérifier qu'une sauvegarde n'est pas corrompue (chose plus délicate avec des snapshots)

Que manque-t'il?

Les sauvegardes incrémentales

Avec des volumétries importantes, une approche incrémentale sera possible et intéressante. Nous pourrons en effet nous donner la capacité de remonter dans le temps en nous appuyant par exemple sur :

• rclone et les mécanismes de versionning sur S3.
• restic (1)

(1) Nous trouverons une intégration de celui-ci dans Velero qui permet de sauvegarder des clusters Kubernetes.

Que manque-t'il?

La résilience (1/2)

Pour les systèmes critiques ou avec des volumétries importantes, il ne sera pas acceptable de devoir attendre la fin d'une restauration de sauvegarde complète pour que le système redémarre suite à un problème (1).

A ce titre, nous pourrions mettre en oeuvre de mécanismes de redondance au niveau des composants GeoStack avec des stratégies de réplication propres à chaque application :

• PostgreSQL - High Availability, Load Balancing, and Replication
• GeoServer - Clustering GeoServer

(1) Voir Chaos_Monkey et les variantes (Chaos Gorilla, Chaos Kong) pour les tests correspondants imaginés par Netflix.

Que manque-t'il?

La résilience (2/2)

Nous soulignerons que l'exercice est loin d'être trivial avec GeoServer et PostgreSQL services et comprendrons mieux pourquoi certains services sont conçus pour répondre nativement à cette problématique (ElasticSearch, Cassandra, etcd,...)

Que manque-t'il?

Un DevOps capable de traiter tous ces sujets...

Voici une illustration du profil DevOps capable pour traiter tous ces sujets :

L'incontournable zone d'hébergement

La nécessité de traiter globalement ces problèmes

En réalité, il est illusoire d'espérer traiter de manière homogène ces problématiques au niveau de chaque application. Traiter ces problématiques de manière efficace demandera la mise en place d'un cadre pour l'accueil des applications.

Les déploiements seront donc généralement réalisés dans une zone d'hébergement (1) prévue pour l'accueil des applications.

(1) Le nom variera en fonction des organisations et solutions d'hébergement : Landing zone (AWS), socle technique d'exploitation,...

L'incontournable zone d'hébergement

Les principaux composants

L'incontournable zone d'hébergement

Le délicat recours à une équipe dédiée... (1/3)

Pour faire face à la complexité et à la diversité des sujets, nous conviendrons qu'il sera difficile d'éviter de recourir à des équipes dédiées pour la construction et l'exploitation de la zone d'hébergement.

Nous soulignerons qu'il sera alors possible de préciser les rôles des DEV et des OPS avec par exemple :

• Des PlatDev et PlatOps en charge des composants de la zone d'hébergement
• Des AppDev et AppOps en charge des applications métiers

L'incontournable zone d'hébergement

Le délicat recours à une équipe dédiée... (2/3)

Toutefois, nous noterons que le recours à une équipe dédiée ramène au problème d'origine adressé par DevOps : La séparation entre les équipes en charge des applications et les équipes en charge de la zone d'hébergement.

Il conviendra de s'assurer que le cadre technique et la méthode de travail permettent l'automatisation des déploiements dans de bonnes conditions :

• La nécessité de recourir à un ticket pour configurer un seul élément (ex : ajouter une VM derrière le LoadBalancer) suffira à plomber les efforts d'automatisation.
• Le moindre comportement inattendu sera source de problèmes de cohabitation entre les équipes applicatives et celle en charge de la zone d'hébergement.

L'incontournable zone d'hébergement

Le délicat recours à une équipe dédiée... (3/3)

Poser un cadre "as code" et être précis sur les responsabilités (1) et les demandes sera incontournable :

• Avec "je veux des mises à jour régulière", l'équipe en charge de la zone d'hébergement ajoutera potentiellement en bonus un rm -rf /etc/apt/sources.list.d/* pour reconfigurer ses seuls dépôts.
• Avec "je veux une exécution régulière de apt-get update && apt-get upgrade -y", il y aura moins de place pour la fantaisie.

(1) En pratique, nous pourrons lister les différentes actions à traiter (créer les VM, installer et configurer l'antivirus, mettre à jour les paquets systèmes, installer les applications,...) et préciser qui traite, qui valide, qui est consulté et qui est informé à l'aide d'une matrice RACI.

L'incontournable zone d'hébergement

Docker et Kubernetes à la rescousse

Nous verrons par la suite comment :

• Les conteneurs solutionnent le problème de partage de responsabilité au niveau des VM en embarquant les dépendances des applications dans les images (1).
• Kubernetes traite ce problème à l'échelle d'une zone d'hébergement par exemple en cloisonnant les applications (concept Namespace) et en permettant aux équipes applicatives de spécifier les URL externes (concept Ingress pour la configuration du LoadBalancer).

(1) Nous passerons sous silence la possibilité de fournir l'image d'une VM applicative complète avec un outil tel Packer voire un simple fichier cloud-init.