Infra : administration et maintenance

Installation et maintenance des serveurs

L'installation et la maintenance des serveurs se fait via Ansible actuellement en version 2.3.1.0. Ces versions sont régulièrement mises à jour. Les connexions par mot de passe étant proscrites sur le serveur, seules sont autorisées les clés publiques des développeurs.euses. Celles ci sont sont insérées dans le $HOME/.ssh/authorized_keys des users définis sur les machines.

Ansible se base sur python, il en faut donc une version d'installée en local. Nul besoin d'installer python sur le serveur car Ansible transmet par ssh les commandes à exécuter sur le serveur. L'exécution d'un playbook ansible qu'il soit de maintenance ou d'installation est complexe, il faut se référer à la documentation. Il faut néanmoins garder à l'esprit certaines choses

• Le playbook utilise le shell défini pour l'utilisateur de connexion dans /etc/passwd en version non interactive. Les shells non interactifs ne chargent pas au démarrage certains fichiers réservés aux shells interactifs. Par exemple pour nous qui utilisons zsh, les fichiers .zshrc ne sont pas exécutés, notamment les modifications de la variable d'environnement PATH source potentielle de beaucoup d'incompréhensions. A cet effet, les instructions de chargement de rbenv sont contenues dans le fichier .zlogin installé par notre script d'installation de serveur.

• L'utilisation d'escalades de privilèges peut se baser sur sudo programme qui n'est pas de base installé sur toutes les distributions linux. Ubuntu 16.04 le comporte de base. L'option --ask-sudo-pass est intéressante à consulter dans la documentation Ansible. Le fait d'utiliser sudo fait que certaines variables d'environnement shell ne sont pas nécessairement les mêmes, par exemple, la variable PATH diffère si l'option secure_path est activée par défaut dans /etc/sudoers . Ainsi certains utilitaires peuvent subitement ne plus être trouvés car le PATH n'est pas le même. Attention donc.

• Les variables d'environnement peuvent être changées pour tout playbook / rôle ou même instruction atomique en spécifiants dans le dictionnaire optionnel vars l'entrée environment comme un dictionnaire des variables d'environnement shell que l'on souhaite manipuler.

• On peut restreindre l'exécution d'un playbook à un certains nombre de machines ou ne lancer que certaines opérations contenues dans ceux-ci. Par exemple : ansible-playbook boostrap_new_server.yml -i inventories/hosts -t rbenv --limit production va lancer le playbook en lui indiquant les hosts potentiellement ciblables de inventories/hosts , liste potentielle que l'on va filtrer en restreignant aux machines du groupe de machines production. Les instructions Ansible ne seront alors exécutées que si elles sont taggées par rbenv

Ces précautions d'usage étant dites, nous pouvons maintenant parler des playbooks proprement dits :

• boostrap_new_server.yml sert à installer un serveur quel qu'il soit avec le minimum pour nos besoins (utilisateur de déploiement, utilitaires type tmux, configuration shell, clés de connexion des développeurs.peuses etc.)

• siade_*.yml ou * est le type d'environnement (sandbox, staging, production) pour siade, le coeur applicatif nous permettant de servir nos API.

• sirene_*.ymlpour sirene, notre API de démonstration des donnés de l'INSEE fournies sur data.gouv.fr. Cette API se trouve en démonstration pour sa version de test sur sirene.entreprise.api.gouv.fr. Le code source se trouve sur github.

• elk_*.yml pour instancier les stacks elasticsearch / logstash / kibana (ELK).

• munin.yml outil de monitoring système pour prévenir les défaillances et lancer l'alerte en cas de seuil critique pour tout un tas de paramètres (taux de remplissage de disque dur, mémoire vive utilisée, traffic etc.)

• watchdoge_*.yml déploiement de l'outil de ping Watchdoge

Maintenance applicative

Nous utilisons une combinaison Nginx + Phusion Passenger (version 5.1.8 actuellement) pour servir nos applications Rails. Le déploiement se fait via une combinaison de Mina (version 1.x.x) et Ansible.

Nginx

On ne présente plus Nginx. C'est le rival d'Apache.

Passenger

Phusion Passenger permet de servir les applications Rails de manière industrielle. Il est

• utilisé dans sa version de plug-in dans Nginx, mais existe aussi en version standalone ou intégrable dans apache avec moults options avancées de compilation si nécessaire.

• open source dans sa version gratuite que nous utilisons. La version entreprise payante supporte le multi threading

• a comme rivaux principaux Puma qui gère le multi threading nativement (et permet des combinaisons JRuby on Rails pour Rails version 4.x.x) et Unicorn qui est mono thread

• très bien documenté

passenger-status et démarrage / reboot de passenger ou d'une application

Comme nous l'utilisons comme plug-in, la gestion de son boot, load, restart etc. est intimement liée à la gestion du service nginx. Comme celui-ci se lance normalement au démarrage du serveur, on n'a pas à se soucier du redémarrage de passenger. Toutefois, attention, passenger peut être utilisé de manière "lazy", i.e ne pas avoir de processus lancé par nginx tant que celui-ci ne sert pas de site requérant le plug-in passenger d'actif (visible dans les configurations de /etc/nginx/sites-enabled/*.conf sous la forme d'une directive spécifique passenger_enabled on). Il faut donc parfois lancer un curl ou une requête navigateur pour déclencher le lancement de passenger. On pourra vérifier son état de marche grâce à la commande passenger-status et redémarrer une application qu'il sert via passenger-config restart-app.

passenger_ruby

Dans la configuration nginx on peut indiquer via la directive passenger_ruby quel ruby utiliser pour notre application. On peut en spécifier des différents en fonction des applications et ainsi supporter du multi versions de ruby . Par défaut passenger utilisera le premier ruby trouvé dans le PATH

Les interactions de passenger avec l'environnement, ruby et nginx sont décrites plus en détails dans sa documentation.

Ruby / Rbenv

Ahhh Ruby. En l'an de grâce 2017 et comme toutes les années de grâce précédentes il n'existe pas de packaging satisfaisant installable via la bien aimée commande apt-get . On utilise donc un logiciel pour gérer les installations, pour nous c'est rbenv. Il permet l'installation de plusieurs versions de ruby, d'en définir une par défaut, et d'exécuter le bon ruby en fonctions de fichiers .ruby-version ou de variables d'environnement. Comme toutes les solutions logicielles du type rbenv nécessite d'accoler certains éléments à la variable d'environnement PATH pour être détecter et fonctionner.

Notre rôle ruby pour Ansible installe donc rbenv et pratique quelques menues opérations telles que l'installation de librairies nécessaires à l'installation de gems qui se compilent. L'installation de rbenv se fait via un rôle Ansible publié sur Ansible Galaxy. Ansible Galaxy répertorie des rôles et permet de les partager, les référencer et les inclure de n'importe où facilement. Un rôle est d'abord installé en local puis il est prêt à l'emploi des autres rôles / playbooks Ansible.

Il existe beaucoup d'options consultables dans la documentation.

Alertes de monitoring par mail

Les alertes levées par nos outils de monitoring peuvent dans certains cas déclencher l'envoi d'un email. On utilise un compte mailjet pour envoyer ces emails. Il faut bien faire attention à activer l'option de tracking d'ouverture des emails pour bien se rendre compte de la situation.

Voici la liste des services de monitoring et leurs emails

Mailjet utilise un système api key public et api key secret classique. Nous utilisons ces credentials pour l'envoi de nos emails automatique et passons par leur site pour les campagnes a destination de nos utilisateurs et utilisatrices abonné.e.s.

Actuellement nous utilisons 2 comptes :

• un compte pour les mails d'admin serveur pur => [e-mail]

• un compte pour les campagnes et mails transactionnels avec le public => [e-mail]