AFPY : Vous reprendrez bien un peu de python ?

4 mars 2013 Durée de lecture : 4 minutes

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

Diecutter

Templates as a service

Rémy Hubscher, novapost

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 ?

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

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

aucun intérêt

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

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

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

Contexte :

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 :

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 :

uWSGI :

Avez-vous écrit une réponse à ce contenu ? Donnez-moi l'URL concernée :