Jérémy Jeanson's blog
chasseur de bugs depuis .net 1.0

Ces dernières années, le DevOps est monté en puissance. Nombre d’éditeurs l’on comprit, et tentent de s’octroyer une part du gâteau en ajoutant des fonctionnalités de déploiement continu dans leurs produits.

Pour illustrer cet article, j’ai choisi deux produits qui illustrent bien les tendances du marché :

• Rancher : un outil d’administration de clusters Kuberntes.
• Keel : un orchestrateur de mises à jour de conteneurs.

Ces deux outils offrent la possibilité d’automatiser le déploiement d’application dans Kubernetes :

• Rancher : via les composants GitOps de Fleet.
• Keel : via des Webhooks sur les registres d'images.

L’un va donc s’intéresser à notre code, l’autre au produit de celui-ci. Les deux approches sont donc bien différentes. Partir sur un produit ou l’autre pour installer des conteneurs en continu n’est pas un choix à faire à la légère.

Comment établir un lien avec Azure DevOps ?

Azure DevOps étant parfaitement en mesure de travailler avec des Webhooks et d’héberger des repository Git, l’interfaçage avec Rancher ou Keel n’est qu’une affaire de configuration.

Rien qui ne soit très compliqué. Mais cela prend un peu de temps, et doit être documenté pour rester fonctionnel en cas de migration (changement de cluster, de serveur Azure DevOps Server).

Mais est-ce bien utile ?

Avant d’utiliser un outil, je prends toujours le temps de me demander si cela est véritable utile. Que gagne-t-on véritable à passer de Azure Release Manager à une autre solution pour le déploiement ?

Via Release Manager, Azure DevOps dispose de pipelines pour gérer les tests d’intégrations, le delivery dans un registre et le déploiement. Release Manager permet aussi d’avoir un visuel rapide de ses environnements (dates, branches, commit) et sait faire le lien entre un déploiement et les workitems utilisés pour le suivi du projet.

Au vu des capacités de Release Manager, j’ai beaucoup de mal à légitimer l’usage d’une solution tierce.

Exemple :

Conclusion

Ce n’est pas parce qu’un outil existe qu’il faut l’utiliser.

Si vous disposez déjà d’Azure DevOps, il est très facile d’y associer des solutions tierces. Mais ce n’est pas pour autant utile. Et cela n’améliorera pas forcément votre expérience.

Chaque outil peut avoir son intérêt dans une démarche DevOps. Il faut juste trouver les usages les plus intéressants :

• Rancher : je préfère l’utiliser pour piloter et déléguer l’administration de cluster kubernetes.
• Keel : sa capacité à automatiser des pulls d’images en fait la solution idéale pour mettre à jour les conteneurs dépendant d'images fournies par des tiers (et son cluster).