WeScale était à Devoxx France, la conférence des développeurs qui se tenait du 21 au 23 avril la semaine dernière. Parmi les grandes tendances que nous en retiendrons :
Au-delà de ces grandes tendances, nous vous donnons ici nos retours sur les conférences qui ont retenu notre attention.
Emile Vauge a présenté un reverse proxy HTTP qu’il développe (en Go) depuis Septembre 2015 et qui gagne en popularité très rapidement : Traefik. L’émergence des micro-services et des conteneurs change les besoins en terme de configurabilité.
Contrairement aux solutions traditionnelles, Traefik gère une configuration dynamique en s’appuyant sur les APIs d’orchestrateurs (Docker Swarm, Mesos Marathon…) ou les annuaires de services (Etcd, Consul, Zookeeper…) pour récupérer la liste des backends.
Traefik offre des fonctionnalités alléchantes :
Si vous souhaitez vous faire un avis sur ce projet, sachez qu’il existe une image Docker officielle :
docker run traefik
Pour l’instant, d’après les tests menés par le projet, Traefik atteint environ 85% des performances d’un Nginx. Pour les adeptes de Kubernetes, notez que le support de Ingress est en cours de rédaction.
Il est complexe et chronophage de maintenir un assemblage de jobs Jenkins qui composent un pipeline de continuous delivery. Partant de ce constat, les ingénieurs de Cloudbees se sont lancés dans le développement de Jenkins 2.
La grande nouveauté de cette version est l’apparition de “Pipeline”. Il s’agit d’un DSL en Groovy, permettant de décrire les étapes d’un build. Les scripts DSL que vous réalisez sur Jenkins sont versionnables dans un SCM. Il est également possible
de positionner un fichier Pipeline à la racine de vos projets, pour automatiser la création de jobs dédiés à chaque branche de votre SCM.
Pour améliorer la fiabilité des builds, ils sont réalisés dans des images Docker de build, qui peuvent être buildées, récupérées et déployées à partir du DSL.
L’arrivée de Pipeline rapproche Jenkins des stratégies adoptées par Travis ou Gitlab-CI.
De nos jours, le mouvement DevOps prend de plus en plus d’ampleur, mais quid de la sécurité ? La sécurité n’est pas un métier d’Ops, encore moins de Dev tout comme le métier des hackers n’est pas de développer des applications.
Notre société est en plein changement :
Tout va beaucoup plus vite et la sécurité est de moins en moins au cœur des préoccupations aujourd’hui. Les images Docker, par exemple, sont utilisées en grand nombre sans qu’une attention particulière soit portée à leur composition et les potentielles vulnérabilités qui en découlent. Il en est de même avec les images Amazon fournies par la communauté.
Les applications, elles, ont un temps d’itération trop court pour demander un audit à chaque version. Toutes ces problématiques lèvent une question intéressante : L’avenir du DevOps ne serait-il pas le DevOpsSec ?
Github a présenté son organisation, ses processus de développement et de mise en production. Avec plus de 40 déploiements par semaine et des développeurs aux quatre coins du monde, la communication est cruciale pour garantir une bonne stabilité en production tout en conservant souplesse et traçabilité.
Pour y arriver, Github utilise massivement la communication asynchrone au travers de nombreuses chatrooms Slack, et en encourageant fortement ses collaborateurs à l’utiliser à toutes les étapes du développement, de la conception jusqu’à la mise en production. Les équipes de développement sont organisées en “features teams” qui travaillent sur des portions généralement ciblées de la base de code, ce qui leur permet de limiter les conflits. Les pull-requests sont créées également dès le début du développement des fonctionnalités, et la discussion sur la façon de procéder est enclenchée sur Slack, ce qui offrira la possibilité à de futurs collègues de retrouver les origines de certains choix de designs qui sont traditionnellement tranchés autour de la machine à café.
Pour déployer, les développeurs s’adressent à hubot, un bot présent sur toutes les chatrooms. Une fois qu’un certain nombre de vérifications ont été effectuées, les demandes de déploiement sont ajoutées à la file d’attente pour éviter les conflits. Ensuite, Hubot effectue les mises en production, vérifie l’état du service, remonte des graphes et des logs, met à jour les “issues” dans github… L’avantage est encore une fois d’apporter de la visibilité à des personnes qui ne sont pas directement impliquées pour leur permettre de réagir le cas échéant.
Même si Devoxx est une conférence issue de la communauté des développeurs, les sujets abordés sont riches et tout le monde y trouve de quoi se nourrir l’esprit. Nous avons passé de très bons moments, autant en conférence qu’à échanger avec des techniciens passionnés. On espère vous y (re)voir l’année prochaine !