Vous reprendrez bien un peu de python ?

Pour cet épisode, nous nous concentrerons sur python dans l’administration système / devops.

Diecutter

Templates as a service

Rémy Hubscher, novapost

https://github.com/novagile/diecutter

• configurer toutes les briques logicielles par environnement
• pas de client : tout par HTTP
• peut rendre un fichier ou une arborescence (fichier zip)
• différent de PasteScript : très compliqué, utilise le moteur de templates Cheetah
• différent de Chef, Puppet ou Salt : “overkill”
• utilise une API REST, petite, pas besoin de client spécifique
• pas de validation des templates pour le moment (voir daybed)
• templates jinja2
• un cousin possible : augeas ?

Chut

Gael Pasgrimaud

• avoir le pipe du shell unix dans python
• existe déjà un équivalent, le paquet sh, mail l’API est horrible
• les commandes sont lazy
• ne marche pas sous windows car utilise les pipe unix
• commandes pour ssh, par exemple ssh.ls. ne remplace pas fabric qui fait bcp mieux sur ce sujet
• voit les commades disponibles dans le PATH
• est une surcouche de subprocess

Deploiement d’une application python dans AWS et Amazon Elastic Beanstalk

Olivier Hervieu, tinyclues

• Elastic Beanstalk (EB) : Paas, équivalent à Heroku ou Google App Engine
• prérequis pour déployer sous EB : python + git + ruby + AWS Beanstalk client package
• fichier requirements.txt installe les dépendances dans un virtualenv
• MEP : git aws.push
• pour une configuration plus fine, il y a le répertoire .ebextensions
• .ebextensions permet d’installer des packages (yum, gem, apt), créer des users, lancer des commandes
• différence entre les commands (lancées dans l’OS) et les container_commands (lancées dans le virtualenv)
• ajout de 3 namespaces (variables d’environnement) pour configurer - a la Heroku

confman

Laurent Bachelier

aucun intérêt

AdminKit: Manage system configurations easily

Frederic Lepied, eNovance

• outil qui resseble à puppet ou cfengine, mais qui existait avant puppet
• devops tool 100% python
• configurer/gérer des machines sous linux
• maintient la configuraiotn de ces machines
• pas de distribution des fichiers (contrairement à puppet) : c’est à l’admin sys de décider (package système, git, web…)
• 1 fichier pour décrire tout le parc de machines à l’aide de rôles
• réutilisation des rôles (ex: apache)
• templates jinja2
• pas de démon : utiliser cron

modoboa

Antoine Nguyen

• anciennement MailNG
• gestion d’un serveur mail simplement avec IHM simplifiée
• console d’admin
• console Amavis : filtrage des mails
• stats graphiques (parser de logs postfix)
• webmail simple
• filtrage des mails (avec sieve)
• il faut installer postfix/amavis à la main
• possibilité de faire des plugins, archi modulaire

Cobbler, un outil de déploiement de machines via PXE / ISO

Matthieu Cerda

• gestionnaire de parc de machines physiques ou virtuelles avec PXE (protocole de démarrage par le réseau)
• utilisé par Fedora et Cannonical
• facile a étendre (ajout de rubber en 10 minutes)
• belle démo efficace
• vocabulaire trop admin sys pour que je comprenne

Je configure mes serveurs avec Fabric et Fabtools

Ronan Amicel

• surcouche par dessus fabric
• ensemble de primitives pour fabric : création d’utilisateurs, gestion des fichiers, package système
• fabtools.require : déclaratif et idem-potent à la Chef
• trés bonne présentation : donne envie de jeter puppet, car très simple à utiliser

Retour d’éxpérience d’utilisation de python dans un rôle de DevOps chez jib.li

Chakib Benziane (@sp4ke)

Contexte :

• application web
• intégrée aux réseaux sociaux (Facebook OpenGraph)
• développée en mode agile
• technos :ngnix + MongoDB + Github + fabric + AWS + gevent + zmq + celery

En local, les incontournables :

• virtualenv + pip
• pythonhomebrew (le rvm de python) pour créer et activer facilement des virtualenv avec des versions différentes de python
• bonne pratique pip : option –download-cache=CACHE pour éviter de tout télécharger sur le net à chaque fois
• bonne pratique pip : versionner ses paquets (pip freeze)
• bonne pratique pip : possibilité de préciser un repo git pour avoiir une version plus récente que sur pypi

Les raisons du choix de MongoDB :

• schemaless, pas de migration
• format BSON
• dict python -> JSON facilement
• superbe API pymongo

Déploiement agile :

• de nombreuses features nécessitent un environnement similaire à la prod mais difficiles à mettre en place (OAuth, celery)
• git co -b feature
• fab push
• branche up sur feature.dev.com
• git merge master
• deploy en prod

Solution :

• ngnix
• github
• fabric
• uWSGI (fait par des admin)

uWSGI :

• permet de construire une stack de dev
• load balancing
• routage (avec FastRouter)
• emperor : déploiement massif multi app