REX : DevOps sans cloud

Ou comment Ansible m’a sauvé la vie pour monter et gérer une prod de 300 serveurs

Etienne Magro

18/11/2021

Bonjour !

Je suis :

  • Etienne Magro
  • Adepte de l’open-source
  • Auto-hébergé

Et niveau professionnel

  • Dev
  • AdminSys
  • DevOps/SRE
  • Consultant cloud open-source pour LinkByNet

Retour d’expérience

DevOps solo dans un environnement legacy

Spoiler : le guide du DevOps Solo

  • Toujours vérifier les actions des autres (et les votres)
  • Tout superviser
  • Tout scripter
  • Automatiser au maximum
  • Déléguer autant que possible

Sommaire

Contextualisation
Rappel sur Ansible
L’importance de la supervision
Exemples de délégation

Contexte

Nouveau projet

  • Progiciel web “MyGreffe”
  • Clients Greffes de tribunaux de commerces répartis en France
  • Équipe de 60 personnes

Contraintes

  • Progiciel déployé physiquement dans les locaux des clients
  • Derrière leur ligne ADSL
  • Au moins 1 release par semaine

Dans un environnement legacy

  • Forte culture de séparation dev/ops
  • SVN + build à la main
  • VMware + Windows 2008 à la main

Aux secours, on ne sait pas mettre en production

  • Personne ne sait installer le progiciel de zéro
  • Pas de compétences linux, ni automatisation

=> Bon, prenons un DevOps

Pourquoi Ansible ?

Généralités sur Ansible

Ansible est un gestionnaire de conf/installation

Objectif Aucune action manuelle en prod
Code yaml Interprété en python
Parallélisation Idempotence
Agentless Code is Law

Bonus : On peut le résumer à 3 clic dans une interface Jenkins, en absence de CI/CD

Comment fait-on l’installation ?

Manuellement

Enfin, pas totalement

Comment fait-on l’installation ?

  1. vmdk de 600Mo envoyé par les admins vmware par ADSL chez le client
    30min à 6h
  2. Création de 3 VM par les admins vmware
    15min
  3. vim inventory group_vars/client.yml && git ...
    10 min
  4. Exécution du playbook Ansible
    30min à 3h

Qu’y a-t-il dans le code Ansible ?

Installation/configuration de :

  • PostgreSQL
  • SolR
  • Tomcat
  • NFS+Samba
  • cron pour les batchs de traitements

Et aussi

  • Checks tailles VM
  • Lib externes + licences logicielles
  • Backup
  • Sécurisation
  • Supervision (NRPE local + nagios)

Architecture simplifiée

Le guide du DevOps Solo

  • Toujours vérifier les actions des autres (et les votres)
  • Tout superviser
  • Tout scripter
  • Automatiser au maximum
  • Déléguer autant que possible

Supervision

Exemple de sondes de supervision

Un peu plus de 100 sondes par environnement de prod

Supervision

  • Supervision opérationnelle
  • Supervision des actions

Supervision opérationnelle

Surveillance de la bonne santée des serveurs et appli

  • CPU
  • RAM
  • Disk
  • Sondes applicatives

Supervision opérationnelle

Surveillance des “autres”

  • Webservices partenaires
  • Certificats SSL des partenaires
  • Connexions en cours (VM et appli)
  • Serveurs VMware

Supervision des actions

Dès qu’il y a un changement, voulu ou non,
a fortiori scripté/automatique,
il faut un retour en supervision

Exemple avec une MEP

  1. app-v1.2.3 -> app-v1.2.4 se passe mal
  2. app-v1.2.3 est remise en place
  3. Une sonde de supervision doit nous indiquer
    • Que l’appli est toujours fonctionnelle
    • Que la MEP a raté (check de version)

Déléguer au maximum

  • Les déploiements en pré-prod/UAT/etc…
  • Les MEP hebdomadaires

Merci idempotence

Environnements de tests

  • Non-volatiles
  • Partagés
  • Tout le monde a les accès SSH

=> Remise d’équerre régulièrement grâce à idempotence d’Ansible

Copie-prod à la demande

Idée :
Et s’il y avait à disposition du support et des testeurs un environnement copie-prod ?

Avec 100 environnements de production différents ?

Comment peut-on faire ?

  • Installation de 10 environnements coquille vide (avec Ansible)
  • Job jenkins à la disposition des testeurs pour populer les environnements avec les backup nocturne de la production

Copieprod à la demande

Bonus

Test des backup
PRA

Délégation des MEP

Playbook livraison.yml en 2 clics dans Jenkins

- name: Téléchargement du binaire applicatif
- name: arrêt du tomcat
- name: remplacement du binaire applicatif
- name: relance du tomcat

Vous avez dit supervision ?

Supervision des actions

- name: Téléchargement du binaire applicatif
- name: Mise à jour de la sonde "version appli DOIT être v1.2.4"
- name: arrêt du tomcat
- name: remplacement du binaire applicatif
- name: relance du tomcat
- name: force check supervision

Conclusion

  • Toujours vérifier les actions des autres (et les votres)
  • Tout superviser
  • Tout scripter
  • Automatiser au maximum
  • Déléguer autant que possible

Merci pour votre écoute

Des Questions ?

https://prez.etienne-magro.fr
@EtienneMagro