Il y a cinq ans, les grandes entreprises achetaient des serveurs, les amortissaient sur trois ans et espéraient les utiliser deux ans de plus. Aujourd’hui, pour de plus en plus d’entreprises, les serveurs sont une commodité. Il ne faut plus cinq semaines2 pour en avoir un nouveau : on en crée trois le matin en un clic et on les détruit en fin de journée — ou même, ils se lancent automatiquement en cas de pic de charge et s’éteignent tout seul dès qu’ils ne sont plus nécessaires.
Nous devons donc faire du bon boulot et ne pas déployer n’importe quoi sans réfléchir. Cela passe par des pull-requests et revues de code systématiques, des tests automatisés, de l’intégration continue, …
Les sysadmins configurent les serveurs avec Ansible, avec quelques dizaines de milliers de lignes de playbooks.
Nous tournons à plusieurs dizaines de déploiements par jour, tous à l’initiative d’un développeur, sans jamais attendre de validation managériale ou subir un processus de ce type.
Notre vision est d’être hébergé en quasi-totalité dans un cloud public et d’utiliser des services managés lorsque c’est possible. Nous sommes prêt à adapter nos applications pour exploiter un service managé ou des fonctionnalités dont nous ne disposions pas on-prem, comme le dimensionnement à la demande. Nous voulons cependant conserver ce qui marche bien : les processus agiles, les pull-requests, les tests automatisés et l’intégration continue, le déploiement par chaque développeur lorsqu’il le souhaite, le monitoring et l’alerting couvrant une énorme surface… Et aussi la fiabilité à laquelle nos clients sont habitués.
Pour résumer, l’équipe DevOps existe pour apporter de l’expertise et investir du temps. Elle a pour but ultime de se rendre inutile20, une fois les outils en place et les équipes de développement formées.
les services managés par notre fournisseur de Cloud Public. Au lieu de louer des machines sur lesquelles nous installerions un serveur de base de données (qu’il nous faudra tenir à jour et administrer), nous préférons louer un service « base de données » et confier la responsabilité de sa gestion à notre fournisseur.
Nous visons donc à exploiter la souplesse du Cloud pour les services. Nous espérons ainsi gagner en performances (dimensionnement à la demande ou automatique) et en disponibilité (un développeur qui a besoin d’un service ou veut en tester un autre clique sur un bouton et voilà).
Un cluster regroupe l’ensemble des machines avec lesquelles Kubernetes travaille. Un node est une machine, souvent virtuelle, qui fait partie du cluster. Un cluster est composé de master nodes où tournent les fonctionnalités internes de Kubernetes et de worker nodes où s’exécutent vos applications. Un pod est la plus petite unité que vous manipulez avec Kubernetes. Votre application tourne, sous forme d’un ou plusieurs containers, dans un pod. Pour répondre à la charge ou améliorer la disponibilité, plusieurs replicas du pod peuvent être créés. Un HorizontalPodAutoscaler ou HPA contrôle dynamiquement le nombre de replicas d’un pod, souvent en fonction de leur consommation CPU. Un service expose un pod sur le réseau — qu’il s’agisse du réseau interne au cluster ou d’Internet.