Renoir Boulanger Un geek social et Linuxien de nature

Ce billet n’est qu’un simple «link dump» pour retrouver parmi plusieurs notes éparpillés. Je compte éventuellement publier la totalité de mon travail dans des projets publics sur GitHub une fois la boucle complétée. Le tout sans fournir les données privés, évidemment.

Faire le saut vers l’automatisation demande beaucoup de préparation et je prends le temps de publier ici quelques bouts de code que j’ai écrits pour compléter la tâche.

Au final, mon projet permettra de déployer un site qui s’appuie sur un cluster MariaDB, Memcached, une stack LAMP («prefork») lorsqu’on a pas le choix, une stack [HHVM/php5-fpm, Python, nodejs] app servers pour le reste servi par un frontend NGINX. Mes scripts vont déployer une série d’applications web avec toutes les dépendances qui les adaptent géré dans leur propre «git repo» parent. Dans mon cas, ce sera: WordPress, MediaWiki, Discourse, et quelques autres.

Requis

• Instantiation à partir de commandes nova du terminal, crée une nouvelle VM mise à jour et son nom définit son rôle dans le réseau interne
• Les VMs sont uniquement accessible par un Jump box (i.e. réseau interne seulement)
• Un système regarde si un répertoire clone git à eu des changements sur la branche «master», lance un événement si c’est le cas
• Chaque machine sont construites à partir d’une VM minimale. Dans ce cas-ci; Ubuntu 14.04 LTS
• Système doit s’assurer que TOUTES les mises à jour sont appliqués régulièrement
• Système doit s’assurer que ses services interne sont fonctionnels
• Dans le cas d’une situation où une VM atteint le seuil critique OOM, la VM redémarre automatiquement
• Le nom de la VM décrit son rôle, et les scripts d’installation installent les requis qui y sont affectés
• Les configurations utilisent les détails (e.g. adresses IP privés et publiques) de chaque pool (e.g. redis, memcache, mariadb) et ajuste automatiquement les configurations dans chaque application
• … etc.

Bouts de code

• Installation automatisée d’un cluster MariaDB avec réplication SSL
• Configuration SSH pour accéder aux VMs du réseau interne
• Vérifier si un git repo a changé, j’ai prévu faire un “salt-call” qui trigger un événement Salt Reactor pour lancer un build run
• Configuration Monit pour s’assurer que les services «sont up and running»
• Installer automatiquement une VM enregistrée au salt-master via Salt Reactor. Le nom de la VM déclare son rôle, le reste se fait tout seul (incomplet mais un début)
• Installer des plugins WordPress à partir des repos Git/SVN/Fichiers Zip
• Installation automatique d’un salt-master et des dépendances de build
• Définir le rôle d’une VM basé sur son nom + TLD (e.g. redis-sessions.production.wpdn)
• Vérifier avec l’origine d’un clone git s’il y a des changements upstream, lancer un événement si c’est le cas
• Automatiser des commands selon certains événemnts dans un cluster géré par Salt
• Automatiser l’installation d’un salt master basé uniquement sur une série de git repos et d’un bootstrapper script
• Automatiser les backups ElasticSearch
• Système pour s’assurer que tous les services son fonctionnels, comment tester s’ils fonctionnent et comment les redémarrer avec Monit

Billets inspirants sur le sujet

• There will be no reliable cloud (part 1), part 2, part 3
• The missing piece operating systems for “Web Scale” Cloud Apps
• Why an X (VM) “instance” isn’t a server
• Simplifying cloud reliability