> For the complete documentation index, see [llms.txt](https://etalab-entreprise.gitbook.io/api-entreprise-documentation-infra/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://etalab-entreprise.gitbook.io/api-entreprise-documentation-infra/infra-administration-et-maintenance.md). # Infra : administration et maintenance ## Installation et maintenance des serveurs L'installation et la maintenance des serveurs se fait via [Ansible](http://docs.ansible.com/) 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](http://docs.ansible.com/ansible/latest/playbooks.html) 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_*.yml`pour sirene, notre API de démonstration des donnés de l'INSEE fournies sur [data.gouv.fr](http://data.gouv.fr). Cette API se trouve en démonstration pour sa version de test sur [sirene.entreprise.api.gouv.fr](http://sirene.entreprise.api.gouv.fr). Le code source se trouve sur [github](https://github.com/sgmap/sirene_as_api). * `elk_*.yml` pour instancier les stacks elasticsearch / logstash / kibana ([ELK](/api-entreprise-documentation-infra/suite-elk.md)). * `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](https://nginx.org/en/) + [Phusion Passenger](https://www.phusionpassenger.com/) (version 5.1.8 actuellement) pour servir nos applications [Rails](http://rubyonrails.org/). Le déploiement se fait via une combinaison de [Mina](https://github.com/mina-deploy/mina) (version 1.x.x) et [Ansible](http://docs.ansible.com). ### 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*](https://www.phusionpassenger.com/library/config/nginx/reference/)*.* ### 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 => * un compte pour les campagnes et mails transactionnels avec le public =>