A way to DevSecOps – Épisode HS

On va essayer d’aller droit au but dans ce nouvel épisode en faisant un résumé très rapide des épisodes précédents.

Épisodes de référence : Épisode 1, Épisode 2, Épisode 3, Épisode 4, Épisode 5, Épisode 6, Épisode 7.

Kubernetes

• K8S, K3S, K0S, Kubespray, etc : le choix est vaste.
• Un choix logique ??? (voir les commentaires) mais qui peut faire peur, mais n’est pas forcément plus difficile ou complexe qu’un autre orchestrateur même dans des besoins de scalabilité faible. Mais ce n’est pas la réponse à tout non plus, il faut juste comprendre et adapter ses choix.
• Une difficulté parfois à debugger en live, surtout si les conteneurs sont redémarrés en permanence (CrashLoopBackOff).
• Bien penser aux technologies de stockage et de partage de la donnée entre les nœuds, c’est le point de départ. Malheureusement les technologies sont nombreuses, et il faut valider le choix en environnement de production. J’ai testé rapidement Longhorn sur ce blog.
• Il faut penser au départ à la sauvegarde et inclure pour chaque application (manifests / charts) la politique de sauvegarde que l’on veut appliquer.
• Réseau : Je n’ai pas encore abordé ce point, j’essaierai de faire un article là dessus. Mais c’est un choix important, aujourd’hui je me dirigerais vraisemblablement vers Calico.

ArgoCD

• GitOps, un paradigme sympatique…
• Un choix vraiment judicieux (et le premier à faire), surtout pour déployer ses charts Helm, c’est un couple qui fonctionne bien.
• Ne pas essayer de déployer ArgoCD avec ArgoCD, ou comment se couper la patte en plein déploiement :D. Logique mais dans mon élan de rationalisation, j’ai testé… et j’ai fail.
• Les charts d’ArgoCD ne fonctionnent pas très bien avec la version 3 de Helm.
• Il est possible de définir un « template » pour se connecter à un repo git (avec des credentials specifiques pour un site donné), cela permet de ne pas créer autant de credentials que de dépôts.
• Permet d’avoir une vision sur les objets Kubernetes déployés, et un tableau de bord convainquant. Portainer fait très bien le taff depuis la version 2. Et pour ceux qui veulent un IDE, il y a Lens.

OpenEBS

• Compatible avec les fonctionnalité Restic de Velero.
• Facile à déployer avec Helm.

Velero

• Facile à déployer en ligne de commande.
• CLI pratique pour vérifier et contrôler les sauvegardes.
• Avec Restic obligation d’annoter les pods avec le stockage que l’on veut sauvegarder, mais facile à faire au niveau de la définition des « deployment » Kubernetes.

Prometheus / Loki / Grafana

• Pour une supervision basique c’est amplement suffisant (et reste léger), je n’ai pas encore passé beaucoup de temps au peaufinage des paramètres, mais ça va venir…

Traefik

• Je n’ai pas encore suffisamment approfondi le sujet, mais c’est un excellent compagnon pour permettre d’accéder à ses applications.
• La documentation manque parfois de clarté, mais ça s’améliore au fur et à mesure des releases, et la communauté est assez forte autour de ce produit. On s’y perd facilement entre le YAML, TOML, Kubernetes, etc…

• Traefik Pilot permet d’avoir une vision globale sur toutes les instances Traefik à monitorer.

Le futur…

Il y a certainement des étapes que j’ai passé rapidement, et des trucs que j’oublie, si vous voulez réagir pas de problème, je suis là pour apprendre (en commentaire ou sur twitter). Merci d’avance de votre contribution :-D)