Ce que Kubernetes m'a appris sur le développement

Pourquoi la gestion des politiques était la clé pour comprendre Kubernetes et le pipeline DevOps.

En tant que développeur full-stack, en particulier développeur front-end, les technologies DevOps et la façon dont les développeurs DevOps pensent ont toujours été un mystère pour moi. Lorsque l'entreprise pour laquelle je travaille a lancé une nouvelle application d'interface de ligne de commande (CLI) appelée Gatekeeper, j'ai plongé dans le monde de DevOps et de Kubernetes, et ce que j'ai appris s'est avéré très précieux. J'ai maintenant une bien meilleure compréhension de Kubernetes et du pipeline DevOps, et je peux mieux expliquer comment notre application CLI les prend en charge tous les deux.

Voici mon histoire.

Sur moi

Je m'appelle Noaa Barki. Je suis développeur full-stack depuis plus de cinq ans et je travaille dans une entreprise fantastique appelée Datree, où nous aidons les développeurs et les ingénieurs DevOps à empêcher les erreurs de configuration de Kubernetes (K8) d'atteindre la production.

Comprendre le problème

Imaginez ceci : vous avez eu une longue semaine, mais c'est vendredi maintenant et vous rêvez paisiblement, prêt pour un long week-end. Cependant, votre week-end arrive plus tôt que prévu, car à 03h46, vous vous réveillez au son de votre téléphone après 15 appels manqués du travail. Apparemment, vous avez oublié d'ajouter une limite de mémoire dans l'un des déploiements, ce qui a provoqué une fuite de mémoire dans l'un des conteneurs, ce qui a entraîné un manque de mémoire sur tous les nœuds Kubernetes.

Comment cela a-t-il pu arriver? Votre équipe DevOps a déployé beaucoup d'efforts pour sensibiliser les développeurs aux K8 et à l'importance de la limite de mémoire.

Pour éviter de tels accidents, vous devez définir les exigences d'une solution idéale et rechercher des plates-formes et des bibliothèques qui permettent d'éviter que des erreurs de configuration n'affectent votre cluster. Les exigences réelles peuvent différer en fonction de votre infrastructure, mais voici un bon exemple :

Appliquer les restrictions de stratégie sur le développement : un moyen d'appliquer des restrictions avant qu'elles n'appliquent des ressources au cluster.
Activer la gestion des restrictions : Gestion flexible des restrictions dans un endroit dédié dans toute l'organisation, ce qui permet aux administrateurs d'avoir un contrôle total sur tous leurs systèmes.
Éduquer sur les meilleures pratiques : Libérez l'équipe DevOps du besoin constant d'examiner, de clôturer et de pérenniser tous les pièges possibles sur tous les cas d'utilisation actuels et futurs qui font partie de l'auto-déploiement.

Travailler en tant que développeur consiste avant tout à résoudre des problèmes réels, mais parfois le contexte fait toute la différence. Vous devez d’abord comprendre comment un problème survient avant de pouvoir le résoudre efficacement.

Pourquoi les organisations adoptent-elles les K8 ?
Quel est le rôle de l’ingénieur DevOps ?
Et surtout, pour qui est-ce que je développe mon application ?

Qui sont les ingénieurs DevOps ?

Au départ, je connaissais très peu de choses sur les ingénieurs DevOps et presque rien sur leur technologie, en particulier Kubernetes. J'ai lu, recherché et interviewé mes amis DevOps sur leur travail et leurs responsabilités. J'ai posé des questions comme :

Quels sont vos objectifs quotidiens ?
Qui sont vos clients ?
A quoi ressemblent vos journées ?

Cela m'a pris du temps, mais après quelques mois, j'ai enfin trouvé la réponse ou, pour être honnête, le courage de faire l'expérience du travail DevOps.

Étonnamment, ce qui nous a le plus aidé a été de reconnaître que nous pensons simplement en des termes différents. Les ingénieurs DevOps doivent faire un zoom arrière dans leur esprit. Ils commencent par le plus petit composant d'application, puis évoluent et s'appuient sur celui-ci, comme un oignon.

Les développeurs, en revanche, peuvent partir du même composant d'application, mais ils sont habitués à penser dans la direction opposée : du niveau élevé aux bits et octets du logiciel. Les développeurs éliminent les couches (du serveur au service, en passant par la fonction, la variable et son allocation de mémoire) jusqu'à atteindre le plus petit composant. Chacun travaille du côté opposé du pipeline, mais nous travaillons tous les deux sur le même pipeline.

Cela m'a amené à me demander : et si la solution se trouvait quelque part le long du pipeline, quelque chose que les deux parties peuvent intégrer ?

La question de savoir si la solution devrait faire partie du pipeline m'a amené à réfléchir à ce que DevOps et les développeurs pourraient avoir d'autre en commun. J'ai réfléchi à mes flux de travail en tant que développeur et je les ai comparés aux flux de travail des développeurs DevOps jusqu'à ce que tout d'un coup, cela me frappe :

Nous avons tous des politiques.

Pourquoi vous ne pouvez pas toujours compter sur OPA

Les développeurs et les ingénieurs ont tous des normes et des bonnes pratiques que nous essayons de maintenir pour être plus confiants dans notre travail. En tant que développeur, j'utilise des principes de code SOLIDE et propre, des tests unitaires et des tests d'intégration, et j'essaie d'apprendre toutes les meilleures pratiques de chaque technologie que j'utilise.

Un matin, j'ai demandé à mon PDG : « En tant qu'ingénieur DevOps, quelles sont vos politiques ? Qu'utilisez-vous pour créer et gérer vos politiques ? Il m'a regardé dans les yeux et a dit un mot : « OPA ».

Qu’est-ce que l’OPA ?

OPA, acronyme de Open Policy Agent, est comme un super moteur. Vous pouvez y écrire toutes vos politiques, puis l'exécuter avec chaque entrée pour vérifier si elle viole des politiques et, si oui, de quelle manière. L'idée principale derrière OPA est la capacité de dissocier la logique de prise de décision politique de l'utilisation de l'application des politiques.

Supposons que vous travailliez dans une architecture multiservices. Vous devrez peut-être prendre des décisions politiques, par exemple, lorsque ce microservice reçoit une demande d'API (comme une autorisation). Cette logique est basée sur des règles prédites dans votre organisation, donc, dans ce cas, vous pouvez décharger et unifier toute votre logique décisionnelle vers un service dédié : OPA.

Comment utiliser l'OPA

Intégrer avec OPA : Si vos services sont écrits en Go, vous pouvez intégrer OPA en tant que package dans votre projet. Sinon, vous pouvez déployer OPA en tant que démon au niveau de l'hôte.
Écrivez et stockez vos politiques : Pour définir vos politiques dans OPA, vous devez les rédiger dans Rego et les envoyer à OPA. De cette façon, chaque fois que vous utilisez OPA pour l’application de politiques, OPA interrogera les entrées par rapport à ces politiques.
Demander une évaluation de la politique : lorsque votre application doit prendre une décision politique, elle enverra une requête de requête API en utilisant JSON, contenant toutes les données requises via HTTP.

Quand l'OPA ne suffit pas

Comme vous pouvez le constater, OPA répond au besoin de gestion et d'application des politiques au sein d'une organisation, car il s'agit d'un excellent outil basé sur des utilitaires et fournit une magnifique solution d'infrastructure. Cependant, OPA nécessite également beaucoup de travail et de configuration, généralement trop pour une entreprise en pleine croissance intensive.

En ce qui concerne les politiques des K8, OPA n'est pas adapté aux petites équipes, car les ingénieurs DevOps peuvent encore passer trop de temps à résoudre les urgences. L'utilisation d'OPA n'est pas toujours le meilleur moyen d'appliquer les politiques K8, mais enquêter sur cette question m'a donné une idée de ce que sont les politiques dans le monde DevOps.

Utilisation de ConfTest : presque là !

ConfTest vous permet d'écrire des tests pour n'importe quel fichier structuré et est spécialement conçu pour être utilisé avec des tests CI ou locaux. Vous pouvez le considérer comme une bibliothèque de tests unitaires pour les fichiers structurés. ConfTest est construit sur OPA.

L'objectif principal de ConfTest est sa commande test :

$déploiement de test de concours.yaml

Cela accepte le chemin des fichiers que vous souhaitez tester, puis évalue toutes les stratégies sur ces fichiers. Par défaut, toutes les politiques (tests unitaires) doivent être placées dans un répertoire appelé politique, mais vous pouvez remplacer cela. Puisqu'il est construit sur OPA, les politiques doivent également être rédigées en Rego.

De plus, ConfTest offre la possibilité de pousser et d'extraire des politiques de n'importe quel registre Open Container Initiative (OCI) (tel que Dockerhub, Quay.io et autres).

Le problème avec ConfTest

À première vue, ConfTest semble être la solution parfaite. Vous n'avez pas besoin de déployer un service comme OPA, mais la possibilité d'extraire et de pousser des registres OCI signifie que vous pouvez unifier vos politiques dans des espaces dédiés et donc obtenir plus de contrôle. Le véritable pouvoir de ConfTest réside dans son utilisation dans le processus CI, ce qui rend la maintenance de K8 plus claire pour les développeurs habitués à tester leur code et à s'y intégrer en permanence.

Malheureusement, ConfTest n'offre pas suffisamment de puissance de gestion des politiques. Unifier les politiques dans un endroit dédié ne suffit pas. Que se passe-t-il si vous souhaitez exécuter un groupe de politiques sur un service et un autre sur un autre service ? Vous auriez toujours besoin d'un moyen d'exploiter les tests dans le processus CI tout en regroupant les politiques.

L'étude de ConfTest m'a fait réaliser que le véritable problème n'est pas seulement d'appliquer ce que vous allez pousser au cluster pour le moment, mais aussi ce que vous pouvez ou pourriez pousser demain. C'est comme les tests unitaires ; il existe pour vous garantir que toute modification actuelle ou future du code ne nuira pas à la production existante. Vous avez besoin d’une solution qui appliquera les politiques du futur et du passé.

DevOps, Kubernetes et moi

Maintenant que j’ai exclu d’autres méthodes d’application des politiques, il est temps de passer à l’aventure suivante et de commencer à étudier Kubernetes.

Si vous êtes un développeur et que vous souhaitez partir à l'aventure K8 avec moi, j'ai trois conseils que j'aimerais partager avec vous.

K8 pour les développeurs : conseils et directives

En savoir plus sur CI/CD : Si vous souhaitez commencer à en apprendre davantage sur les K8, il est essentiel de savoir ce qui se passe exactement dans le pipeline CI/CD, les différences entre CI et CD et pourquoi, enfin et surtout. , votre entreprise l'utilise du tout. J'ai commencé avec le plus petit composant que je pensais comprendre (un de nos microservices) et j'ai dessiné un graphique avec toutes les ressources et les environnements qui y sont connectés. J'ai écrit tout ce qui se passe depuis le moment où je valide mon code jusqu'à ce qu'il apparaisse comme par magie dans mon environnement de production.
Découvrez votre plate-forme : l'utilisation de Kubernetes nécessite beaucoup de travail de configuration qui n'est peut-être pas lié à Kubernetes lui-même. Vous devez comprendre comment fonctionne votre plateforme, quelles ressources vous utilisez et dont vous avez besoin, et comment elles sont connectées du point de vue du réseau.
Comprendre le déploiement : le déploiement est probablement l'expression la plus courante que j'ai entendue dans DevOps, mais de quoi s'agit-il réellement ? Est-ce une ressource Kubernetes ? Un processus? Un artefact ? Dans Kubernetes, le déploiement désigne « l'état de mon application ».

Ce qui m'a le plus intéressé, cependant, c'est l'application CLI que j'ai mentionnée plus tôt, Gatekeeper. La découverte d'OPA Gatekeeper m'a appris la nécessité d'acquérir une visibilité et de suivre toutes les politiques, en identifiant ce qui n'est pas conforme, puis en prenant des mesures pour corriger les choses. En plus de mon article sur Gatekeeper, je recommande également de lire la documentation de Gatekeeper.

Mon mantra personnel

Le sentiment d'accomplissement que procure la fourniture d'une solution utilisant la technologie avec créativité et ingéniosité est la raison pour laquelle je suis développeur. Notre travail en tant que développeurs ne consiste pas à écrire du code mais à résoudre des problèmes réels. Tous les bogues ne valent pas la peine d'être résolus, toutes les fonctionnalités ne valent pas la peine d'être codées et tout le code désordonné ne vaut pas la peine d'être refactorisé. Le code doit avoir un but : sinon, il ne devrait pas être écrit du tout.