Que vous débutiez l'implémentation de votre programme de sécurité ou que vous souhaitiez le renforcer,
démontrez des pratiques de sécurité de première ordre et établir de la confiance, et plus important que jamais.
VENTA automatise votre mise en conformité sur ISO 27001, SOC2 et une vingtaine d'autres standards en vous permettant d'économiser du temps et de l'argent,
mais aussi de construire un sople de confiance solide avec vos clients.
Aussi, vous serez en mesure de rationaliser vos revues de sécurité en automatisant vos questionnaires et en démontrant rapidement votre posture de sécurité avec un trust center directement accessible à vos clients.
Plus de 7000 clients, comme Conto, Alain ou Pigment, utilisent VENTA pour gérer leurs activités de risques et de sécurité en temps réel.
Obtenez 1000$ de réduction en vous rendant sur venta.com.se-tech.
Bienvenue chers compagnons sur Radio DevOps, la balle de diffusion des compagnons du DevOps.
Si c'est la première fois que tu nous écoutes, abonne-toi pour ne pas rater les futurs épisodes. C'est parti !
Bienvenue dans ce nouvel épisode en solo.
Alors la première chose que je voudrais vous dire c'est à grand merci parce qu'il y a déjà eu plus de 1000 téléchargements du podcast, tout épisode confondu, donc ça c'est plus super encourageant pour nous parce qu'on a commencé que au mois de janvier et on va très vite vers les 2000 téléchargements.
Mais c'est pas pour ça que j'ai décidé de faire cet épisode en solo.
Ce mois-ci on a vu pourquoi est-ce que c'était important de faire l'infrastructure à SCOD et comment bien débuter.
Mais, enfin qu'on commence à faire de l'infrastructure à SCOD, il y a énormément de questions qui arrivent et notamment qu'est-ce qu'on fait des configurations ?
Est-ce qu'on les met dans les dépôts de l'application ?
Est-ce qu'on les met dans les dépôts de l'infrat ?
Est-ce qu'on les met ailleurs ?
Quoi qu'il arrive ?
Et quelle que soit la décision qu'on prend, on s'aperçoit très vite que Gith devient notre point central.
Donc Gith c'est là où vraiment tout va se passer.
C'est la fondation sur laquelle va se baser notre système d'information.
Et là, quand on pense à Gith, quand on passe à l'infrastructure, ce qui se passe quand on passe à l'infrastructure à SCOD c'est que très vite on s'aperçoit qu'il ne faut pas passer de commande pour changer l'état de l'infrastructure.
Il ne faut pas se connecter au SSH sur les serveurs.
Il ne faut pas lancer de commande CUBE CTL si vous êtes sur Kubernetes.
Ça c'est un des 10 points des 12 facteurs.
C'est le 10ème point pour être exact.
Je vous mettrai le lien en description.
D'ailleurs, tout ce dont je vais parler dans ce podcast et tout ce qu'on aborde dans tous les podcasts, je vous mets des liens dans les descriptions.
Donc aller voir les descriptions c'est souvent intéressant.
Du coup ce qu'on ne veut pas c'est des déploiements manuels.
On veut des déploiements immuables.
J'ai déjà parlé de l'immuabilité, des images immuables, mais là on veut un déploiement immuable.
On veut que le déploiement, quel que soit ce qu'on fait sur notre code, on veut qu'il passe.
Donc si on ne fait pas de déploiements manuels, on a moins de risques d'erreur.
Et c'est en cela que le concept de GitOps peut nous aider.
GitOps s'est apparu avec l'avènement de Kubernetes.
C'est Alexi Richardson qui en a parlé la première fois à la cloud native common en mai 2017.
Alexi Richardson c'est le CEO de Waveworks et il disait qu'en fait GitOps,
c'est tout ce qui concerne pousser du code mais pas des conteneurs.
Ce qui se cache là derrière c'est que l'idée c'est que Git va devenir notre seule source de vérité.
Git c'est le seul endroit où on opère.
Git c'est par là que va passer notre déploiement continu.
Et ce qu'on veut en fait c'est que chaque merge request validée correspond à un déploiement.
Et du coup dans l'idée de GitOps, tous les changements qu'on va faire sur le code,
ils sont observables et vérifiables parce qu'en effet on peut faire des diffs.
La convergence entre ce qui est versionné dans Git et ce qui va tourner sur notre infrastructure
est très important.
En gros ce qu'on a décrit dans Git, notre infrastructure c'est la même qui va tourner.
A chaque fois qu'on va faire des modifications dans Git,
on va déployer et les déploiements vont se retrouver sur l'infrastructure.
Donc constamment on a la même chose.
Et si on veut vérifier qu'il n'y ait pas de différence, on met en place un monitoring pour ça.
Git a beaucoup d'avantage puisque du coup chaque merge request ou pool request en fonction de la plateforme que vous utilisez
va demander une modif.
Cette modif va être vérifiée et relue par d'autres membres de votre équipe.
Et on va pouvoir suivre les évolution comme ça grâce à l'historique de Git.
Et on peut grâce à GitOps et à l'infrastructure AsCode revenir en arrière.
Il suffit alors de créer un comite qui annule les dernières modifications si par exemple il y a eu une erreur.
Si il y a une régression, on peut faire ça.
On peut le faire sur le code de l'application, donc on peut le faire sur le code de l'infrastructure.
On peut avoir aussi une intégration continue et un déploiement continue simplifié.
Et surtout grâce à cette philosophie-là, la philosophie GitOps, on peut gérer les permissions avec le serveur Git.
On peut gérer la permission de qui a le droit de comité, qui a le droit d'emerger et donc qui a le droit de faire des revues de code.
Alors là on peut se poser la question de quelle bonne pratique on doit mettre en place si on veut passer à GitOps.
En fait ce qu'il faut bien se dire c'est que dans cette philosophie-là et dans l'infrastructure AsCode,
tous les environnements sont décrits de façon déclarative.
Il n'y a pas une branche par environnement.
Tout est sur la même branche.
C'est vraiment très important, ça veut dire que vous n'avez pas de branche préprode,
vous n'avez pas de branche prode, tout est sur la même branche.
Ça veut dire que, et ce que je vous conseille de faire,
c'est de tout mettre sur la branche master et de pas avoir plusieurs branches.
Par contre il y a plusieurs endroits dans votre dépôt où vous vous décrivez les différences entre les environnements.
Et donc GitOps, il y a deux stratégies qui ont été théorisées.
La stratégie du push, donc ça c'est plutôt une approche traditionnelle
où c'est nous qui allons pousser, plutôt ces Git qui va pousser les modifications dans l'infrastructure.
C'est le déploiement continu et la pipeline du déploiement continu qui va pousser et mettre un jour l'infra en fonction du code.
Ça c'est la méthode traditionnelle, je vous conseille de commencer par celle-là.
Ensuite la méthode un peu plus avancée et qui est très adaptée à Kubernetes pour le coup
parce que dans Kubernetes il y a des opérateurs qui permettent de faire ça, c'est la méthode du pool.
En gros, une fois qu'on a poussé notre code dans Git, qu'on a mergé,
c'est l'infrastructure elle-même qui va être notifiée du changement
et qui va autogérer ce qui tourne par rapport à ce que contient le dépôt Git.
C'est à dire que l'infrastructure elle-même va se modifier.
Évidemment il faut écrire des opérateurs,
ou alors il y a des opérateurs qui exigent déjà pour ça, pour Kubernetes.
Si jamais vous êtes sur le cloud, il va falloir créer tout ce qu'il faut pour aller lire les dépots Git
et appliquer les modifications sur votre infrastructure.
Mais c'est possible.
Comment est-ce qu'on va s'y prendre ?
Alors comme je vous l'ai dit, la première chose à faire c'est de se mettre dans l'idée qu'on va décrire l'infrastructure de façon déclarative
pour chaque environnement dans la même branche.
Et ce qu'il faut se dire, c'est que tout changement sur l'infrastructure devra passer par Git.
Tout changement devra passer par une merge request.
Ça veut dire que si vous ajoutez une base de données, si vous ajoutez un nouveau service,
eh ben ça va passer par une merge request qui va être relue par vos collègues et qui va être accepté.
Et à ce moment-là, la pipeline va se déclencher et l'infrastructure va évoluer.
Pour ça, il faut créer des mécanismes qui remont des alertes en cas de désynchronisation.
Parce que si vous modifiez votre code, vous voulez être sûr qu'en fait, l'infrastructure qui est en face, elle soit bien à jour.
Donc pour ça, il faut la monitorer.
Il faut mettre en place des outils de supervision et un mécanisme de remontée d'alerte.
La troisième chose, c'est que chaque comite, il doit être idempotant.
Ça veut dire que l'opération qui est faite dans le comite, il doit avoir les mêmes effets,
il est même zéfait qu'on l'applique une ou plusieurs fois.
Ça veut dire que si vous rejouez le comite, 2 fois, 3 fois, 4 fois, 10 fois,
vous devez avoir le même résultat.
C'est hyper important.
Ça veut dire que l'outil que vous allez choisir pour gérer votre infrastructure, il doit être idempotant.
C'est pour ça qu'en fait, on conseille plutôt en cible et terraforme, parce qu'en théorie, ils sont idempotants.
Enfin, la quatrième chose à avoir en tête, c'est que chaque retour arrière, il doit faire l'objet d'un comite, d'un nouveau comite.
C'est-à-dire que vous ne devez pas enlever le comite précédent.
Non, non, vous devez ajouter un nouveau comite qui fait un retour arrière.
Vous pouvez faire ça avec les comites rivertes.
C'est assez facile.
Vous pouvez aussi utiliser les tags de guides, c'est-à-dire rejouer un tag précédent pour revenir à l'état de l'application.
C'est aussi possible.
Ce qu'il faut bien dire, c'est que dans GitHub, s'il y a 4 fondamentaux à avoir en tête.
Le premier, c'est la convergence.
La convergence, c'est qu'en gros, on garantit l'alignement entre la description qui est d'enguite et l'état de votre affraie structure.
Je l'ai déjà dit, mais les deux doivent être convergents.
Les deux doivent avoir le même état.
L'état doit correspondre à ce que vous avez d'enguite.
Ensuite, le deuxième fondament est l'idempotence.
L'idempotence, comme je vous l'ai dit, c'est qu'une opération, elle doit avoir les mêmes effets qu'on applique une ou plusieurs fois.
Le troisième fondement, c'est le déterminisme.
En gros, on définit explicitement ce qu'on veut dans le code.
Et c'est ça qui va être déployé sur l'infrastructure.
Et enfin, le quatrième point, c'est l'automatisation qui va garantir une vérification perpétuelle de ce qu'on a mis d'enguite.
Il faut que la mise à jour soit programmée et gérée par votre intégration continue par un opérateur Kubernetes parce que vous voulez, mais il faut que ce soit automatisé.
Donc pour aller plus loin, je vous ai mis pas mal de liens dans la description.
J'espère que ce petit point un peu théorique vous aura aidé.
Si vous avez des questions, n'hésitez pas à les poser sur question.compagnontiradevops.fr.
Le lien est en description.
Et puis j'aborderai les sujets que vous m'avez suggérés.
Et si vous avez besoin de conseils, si vous voulez en discuter aussi, vous pouvez venir sur le forum des compagnons de DevOps.
Et si vous n'êtes pas inscrits, inscrivez-vous à la communauté et on en discute dans le forum pour savoir comment chaque personne fait.
A bientôt !
Merci d'avoir écouté Radio DevOps.
La balle aux diffusions des compagnons de DevOps est produite par l'IDRA.
Si l'épisode t'a plu, note le plus la note sera élevée et plus il sera mis en avant dans les applications.
Tu peux aussi le partager, cela nous aidera à le diffuser et à rendre le mouvement beaucoup plus visible.
Si tu es en vuit de discuter du mouvement, le plus simple c'est que tu rejoins de la communauté des compagnons de DevOps.
Le lien est en description.
A bientôt !