Toute l'actualité devOps

🌄 Linux early days ➡️ Extrait d'Actus DevOps de Juillet 2023 L'épisode complet : https://youtu.be/_j7BjVJjOlk - https://lwn.net/Articles/928581 📩 Si tu n'es pas déjà abonné, alors **abonne-toi** pour ne pas rater les prochaines vidéos. 💬 Rejoins la communauté : https://www.compagnons-devops.fr 💖 Tu peux soutenir mon travail et la communauté sur : https://soutenir.compagnons-devops.fr 🔗 Tous mes liens : https://i.mtr.bio/compagnons-devops ### Mon Jobboard 💼 Trouve ton job de rêve : https://vu.fr/jobboard-DevOps 👔 Recrute avec moi : https://vu.fr/jobboard-DevOps-recrute ### Mes antisèches 🎁 git : https://bref.lydra.fr/antisechegit 🐳 Docker : https://bref.lydra.fr/antisechedocker 🔀 Ma RoadMap DevOps : https://vu.fr/RoadmapDevOps ### Mes formations 🎓 Forge toi un état d'esprit DevOps : https://vu.fr/devops-mindset --- ### Crédits - René Ribaud : Software Engineer chez RedHat. J'aime apprendre et transmettre des connaissances sur le logiciel libre et le DevOps. Découvre le : https://lydra.fr/ea-6-le-podcasteur-rene/ | Linkedin : https://www.linkedin.com/in/ren%C3%A9-ribaud-44145137/ | Twitter : https://twitter.com/Uggla_ | Github : https://github.com/uggla | Sa présentation : https://forum.compagnons-devops.fr/t/uggla-floss-addict-architecte-si/ L'intro et la fin sont de : - Baptiste Gaillet : FullStack développeur avec une tendance DevOps au Centre Scientifique et Technique du Bâtiment, Fondateur et développeur de l'application BedFoodCoffee pour aider les personnes en difficultés. Après des études dans le son et différents métiers, il a effectué une reconversion professionnelle en 2015 pour devenir développeur (Formation diplômante dans le cadre d'un CIF). LinkedIn : https://www.linkedin.com/in/baptiste-gaillet-223832b4 | Twitter : https://twitter.com/bat79a - La musique d'intro est *"Tupac Lives"* de John Bartmann : https://pixabay.com/fr/music - La musique de fin est *"Passport"* de Purple planet : https://www.purple-planet.com/passport L'image est de redhat : https://www.redhat.com/sysadmin/sites/default/files/styles/full/public/2022-11/Ken_Thompson_Dennis_Ritchie_PDP-11_0.jpg?itok=D9Au5qnp Le montage est de Louna HO : https://www.linkedin.com/in/louna-ho-0656801b1/ 📜 Ce contenu est sous licence libre : CC BY-SA : https://creativecommons.org/licenses/by-sa/4.0/deed.fr Si tu utilises ces contenus dans une publication, merci de nous le notifier dans les commentaires. 🌐 Les Compagnons du DevOps est une initiative de Lydra : https://www.lydra.fr #DevOps #Actualités #ADOcourt #Linux

Table des matières Introduction Installation de Cosign Signatures de nos artefacts Création des clés Création de l’image Signature de l’image Récupération des informations sur la signature Vérification de la signature de l’image Attachement de la SBOM Vérification de l’attestation Plus loin Dans le billet précédent, j’avais introduit la notion de sécurisation de la chaine d’approvisionnement logiciel et surtout pourquoi il est important de la mettre en place.

Le tracing, c’est génial mais souvent sous-exploité aujourd’hui dans notre industrie. Venez découvrir pourquoi vous devez mettre des traces dans vos applications. Cet article est second article de ma série sur l'observability. Retrouvez le premier article sur les métriques ici. C’est quoi le tracing ? Le tracing est une technique permettant de suivre au sein d’un même service ET également entre services (donc dans un système distribué) le "parcours" d’une action. Exemple: Une client HTTP envoie une requête à une application appelée App A App A reçoit la requete, déclenche une autre requête vers une base de données, puis envoie également une requête HTTP à une application App B App B reçoit la requête, fait également une requête à une base de données, et renvoie une réponse à App A App A retourne la réponse au client initial On voit ici qu’une action utilisateur (la requête HTTP) a déclenché de nombreuses actions côté applicatif. Il est souvent difficile de suivre dans les systèmes d’aujourd’hui, notamment microservices, ce type d’actions. C’est là que le tracing intervient: il nous permet de suivre avec détails ce qu’il se passe sur nos systèmes. Opentelemetry est une implémentation standard du tracing. Le fait que ce soit un standard est très important. Traditionnellement les APM (cloud type Newrelic, Datadog…​) fournissaient leurs propres agents et SDK pour ce type de besoins. Avec Opentelemetry votre code applicatif n’est plus lié à un vendor particulier et donc n’est pas "lock-in". Si vous utilisez Opentelemetry pour les traces, vous aurez la possibilité de facilement changer de technologie de stockage (cloud ou on premise) sans changer votre application, notamment grâce à l’Opentelemetry collector qui est un composant pouvant recevoir et ensuite transférer les traces à différents systèmes Tout un écosystème s’est développé autour d’Opentelemetry et des traces et l’outillage aujourd’hui est très bon dans tous les langages "mainstream". Des gestionnaires de traces comme Grafana Tempo vous permettent par exemple d’avoir de très belles représentations d’une action sur un système distribué (image tiré de cet article). D’autres visualisations sont possibles comme des "services map" montrant sous forme de graphe les communications entre services. Traces et Spans On va donc générer des traces composées de spans pour suivre nos requêtes et actions. La documentation officielle d’Opentelemetry explique bien le concept que je vais résumer ici. Prenons l’exemple précédent. Il va être possible avec Opentelemetry de mesurer le temps d’exécution de chaque étape du parcours de notre action. On veut donc mesurer le temps d’exécution de la requête par le client HTTP original. Puis le temps passé dans l’application A, où l’on peut mesurer le temps de traitement de la requête HTTP par le serveur, qui sera lui même composé du temps d’exécution de la requête SQL et de l’appel HTTP à l’application B. Même chose pour l’application B où l’on mesurera le temps de traitement de la requête HTTP reçue et de la requête SQL exécutée. Voici une représentation de cela, avec le temps en abscisse: Il serait également possible de représenter cette série d’action comme un arbre: On voit ici que chaque action a comme noeud suivant l’action (ou les actions) suivante (et inversement ces actions ont comme parent l’action précédente). On pourrait également représenter l’exécution de la toute première requête HTTP (HTTP Client) en JSON: { "name": "HTTP Client", "context": { "trace_id": "0x5b8aa5a2d2c872e8321cf37308d69df2", "span_id": "0x5fb397be34d26b51" }, "start_time": "2023-08-19T17:52:58.114304Z", "end_time": "2023-08-19T17:55:98.114304Z", "parent_id": null, "attributes": { "http.route": "/foo", "http.request.method": "GET", "http.response.status_code": 200, "server.port": 443, "url.full": "https://app-a.mcorbin.fr/foo" } } En fait, ce JSON est la représentation d’une span opentelemetry. Comme dit précédemment une trace permet de suivre l’exécution d’actions liées entre elles. Une trace est tout simplement une liste de spans partageant le même trace_id. Dans cet exemple, ma span a une trace_id égale à 0x5b8aa5a2d2c872e8321cf37308d69df2. Elle a une également une span_id (0x5fb397be34d26b51, permettant de l’identifier de manière unique). Ma span a également une date de début et de fin (start_time et end_time). La span démarre avant l’exécution de l’appel HTTP, et se termine lorsque la réponse est reçue. On peut comme cela déduire le temps d’exécution total ce cette action. Vient ensuite le champ parent_id. Rappelez-vous de la représentation en arbre des actions: ici, c’est la première action à être exécutée donc la span n’a aucun parent: c’est ce qu’on appelle la root span. Viennent ensuite les attributes dont nous allons parler dans la section suivante. Spans et attributes Une span avec juste un nom (comme HTTP Client) et un temps d’exécution serait inutile: il serait impossible d’en faire quelque chose et de comprendre l’action réalisée. C’est là qu’interviennent les attributes. Dans la span représentée précédemment, les attributes seront liés à la requête HTTP réalisée: route, méthode, status de la réponse, port, url cible…​ cela permet de comprendre immédiatement la requête qui a été exécutée. Représentons maintenant la span suivante de notre arbre: le serveur HTTP recevant la requête dans l’application A: { "name": "HTTP server", "context": { "trace_id": "0x5b8aa5a2d2c872e8321cf37308d69df2", "span_id": "0x8ad397bae4d26489" }, "parent_id": "0x5fb397be34d26b51", "start_time": "2023-08-19T17:53:01.114304Z", "end_time": "2023-08-19T17:55:50.114304Z", "attributes": { "http.route": "/foo/:id", "http.request.method": "GET", "http.response.status_code": 200, "url.path": "/foo/123456", "url.scheme": "https", "server.port": 443, "server.address": "app-a.mcorbin.fr", "client.address": "10.36.1.2", "client.port": 39874 } } Regardons déjà les ID de trace et de span. Le trace_id est le même que la span HTTP CLient: en effet, les deux spans font partie de la même série d’action (de la même trace). Le span_id est par contre unique à la span. Ici, le parent_id n’est pas null: il est égal à 0x5fb397be34d26b51 qui est la valeur de la span précédente (HTTP Client). Cela est logique car c’est bien cette span qui est parente dans l’arbre. Les attributs donnent également ici des informations sur la requête HTTP reçue. On peut voir quelques similitudes avec la span HTTP Client. Conventions de nommage On a vu l’importance des attributs pour donner du contexte aux spans. Dans notre exemple du début d’article on aurait par exemple une span pour la requête SQL du service A. Cette span ressemblerait probablement à quelque chose comme: { "name": "SQL query", "context": { "trace_id": "0x5b8aa5a2d2c872e8321cf37308d69df2", "span_id": "0x1bc187ba44dc6aea" }, "parent_id": "0x5fb397be34d26b51", "start_time": "2023-08-19T17:53:08.114304Z", "end_time": "2023-08-19T17:53:49.114304Z", "attributes": { "db.name": "users", "db.statement": "SELECT id, email, password FROM users WHERE =", "db.operation": "SELECT" } } Ici les attributs seront spécifiques à SQL et nous permettent aussi de facilement identifier l’action réalisée. Il est important de standardiser les attributs. Nous allons en effet pouvoir faire des recherches sur les traces. Cela serait très difficile si un service nommait un attribute db.statement et l’autre database.statement: il faut des conventions de nommage. Le standard Opentelemetry fournit déjà une liste de noms et types d’attributs (let attributes sont typés) standards. Vous pouvez trouver cette liste ici. Tous les attributs techniques "classiques" (en lien avec des technologies comme les base de données, les cloud providers, des protocoles comme HTTP ou gRPC) sont déjà standardisés. Des librairies existent également pour construire ces attributs standards (comme la lib semconv en Golang). Il est également très important de standardiser vos attributs métiers. Avoir des attributs techniques attachés aux spans est intéressant, mais il est encore plus intéressant d’attacher du contexte métier à vos spans. Cela peut être des attributs comme <company-name>.user.id, <company-name>.organization.id ou tout autre attribut métier important. Rappelez vous que les traces sont intéressantes notamment pour découvrir des problèmes de performance: peut être allez-vous vous rendre comme que c’est toujours les requêtes venant d’un utilisateur spécifique qui sont lentes grâce à un attribut contenant son ID. Sans cet attribut, l’investigation du problème pourrait être beaucoup plus lente. Resource Il est commun dans une span d’avoir également un bloc resource contenant des attributs communs à une application: { "resources": { "service.name": "App-A", "service.version": "0.0.1" } } Ces attributs sont souvent utilisés par les base de données de traces pour stocker ensemble les spans d’un même service, car toutes les spans émises par une instance d’un service donné auront les mêmes ressources. Scope Un autre bloc présent dans une span est le bloc scope. Voici par exemple le contenu de scope pour une span émise par le package Golang otelgin, permettant d’ajouter le support d’Opentelemetry au framework Gin: { "scope": { "name": "go.opentelemetry.io/contrib/instrumentation/github.com/gin-gonic/gin/otelgin", "version": "0.42.0", "attributes": {} } } Cela permet de voir que cette span a été générée par cette librairies. La documentation officielle d’Opentelemetry explique bien cela. Status Il est également possible d’ajouter à une span un status avec un message permettant de très rapidement filtrer les spans en erreur. Une span représentant une erreur de validation de requête HTTP pourrait avoir comme status: { "status": { "message": "Invalid HTTP Body", "status": "error" } } Events, et pourquoi les traces peuvent remplacer les logs On arrive à un concept que j’adore dans le tracing: les events. On a étudié précédemment des exemples de spans représentant une action avec une date de début, une date de fin et des attributs. Il est également possible d’ajouter à une span des messages arbitraires avec un timestamp fixe associé et des attributs: ce sont les events. On peut voir un event comme un log, c’est exactement le même principe. Reprenons notre exemple de serveur HTTP recevant une requête. Il est commun d’avoir dans des handlers HTTP des logs applicatifs de ce type: logger.Infof("received request from user %s to perform action Foo", userID) logger.Infof("user %s is in trial mode", userID) // traitement de la requête logger.Infof("successfully performed action Foo for user %s", userID) Ces logs sont il est vrai de faible qualité (c’est juste pour l’exemple) mais on voit souvent ce genre de patterns avec de nombreux logs ajoutés "au cas où" et loggant toute sorte de choses en production. Mais si vous faites du tracing, ces logs peuvent complètement disparaître: L’user ID et mode peuvent être simplement attaché à la span comme un attribute Des events attachés à la span peuvent remplacer les logs Un exemple: { "name": "HTTP server", "context": { "trace_id": "0x5b8aa5a2d2c872e8321cf37308d69df2", "span_id": "0x8ad397bae4d26489" }, "parent_id": "0x5fb397be34d26b51", "start_time": "2023-08-19T17:53:01.114304Z", "end_time": "2023-08-19T17:55:50.114304Z", "attributes": { "user.mode": "trial", "user.id": " 86a7d17f-ab35-4312-88ea-9414a15e450b", "http.route": "/foo/:id", "http.request.method": "GET", "http.response.status_code": 200, "url.path": "/foo/123456", "url.scheme": "https", "server.port": 443, "server.address": "app-a.mcorbin.fr", "client.address": "10.36.1.2", "client.port": 39874 }, "events": [ { "name": "successfully performed action Foo", "timestamp": "2023-08-19T17:55:20.114304Z", "attributes": { "user.id": " 86a7d17f-ab35-4312-88ea-9414a15e450b", } } ] } Comme vous pouvez le voir, un log est devenu un event attaché à ma span et le reste des attributs (user.id et user.mode). Et ça, c’est GENIAL. Pourquoi c’est genial ? Reprécisons pourquoi le tracing est intéressant: suivre des actions entre services. Les logs sont très souvent utilisés pour ça également. Qui n’a jamais utilisé les logs pour suivre le parcours d’une requête dans une application, ou même entre applications via des recherches plus ou moins complexes ? En ayant des attributs métiers dans mes spans ET en ajoutant des events lorsque j’ai besoin d’avoir un timestamp exact associé à un message, j’ai le meilleur des deux mondes: Je bénéficie de tout l’écosystème des traces pour suivre le parcours de mes actions Je peux, une fois ma requête identifiée, avoir facilement tous les "logs" (events) associés à cette requête car ils seront tout simplement attachés aux spans? C’est un énorme gain de temps. Je n’ai pas à jongler entre différents outils pour essayer de trouver une information. Du moment que j’ai un ID de trace (ou que je peux le retrouver via une recherche sur un attribut), j’ai accès à toutes les informations sur cette trace (depuis tous mes services) d’une manière unifiée. Je n’ai plus à galérer à corréler des logs entre eux, ma trace et mes spans le font pour moi ! Je prévois dans le futur une fusion des outils de gestion de traces et de logs. Pourquoi garder les deux alors que les traces font déjà un boulot LARGEMENT meilleur tout en étant un format standard ? Je pense que si je devais reconstruire un système d’information "from scratch" aujourd’hui je: Garderai les logs pour les erreurs et certains logs très importants (type logs "légaux" à conserver). Et encore: le SDK Opentelemetry permet d’attacher des erreurs aux spans sous forme d’events donc c’est également super d’avoir les erreurs attachées aux spans. Tout le reste: des traces avec des attributs et events de qualité. Je suis sûr qu’on pourrait même faire une sorte de "log level" pour les traces, ajoutant certains events à des spans en fonction d’une configuration globale, comme un logger. Sampling Cela me permet de rebondir sur le sujet du sampling. On entend toujours dire lorsqu’on parle des traces "conserver 100 % des traces est trop coûteux en stockage car trop de volume", et donc qu’il faut faire du sampling (par exemple, ne conserver que 5 % des traces). Je ne pense pas que ce soit une bonne idée. Certains outils comme Grafana Tempo ont pour objectif de pouvoir garder 100 % des traces en les stockant sur S3 pour baisser les coûts. Mais le lien entre traces et logs est aussi important. Les logs aussi sont souvent coûteux à stocker (je vois les utilisateurs Elasticsearch sourire en lisant ça). Pourtant, des applications qui loggent comme des porcs sans que personne ne lève un sourcil ne posent aucun problème dans de nombreuses entreprises, et personne ne veut faire du sampling sur les logs car cela baisse les capacités d’investigations de problèmes. Pourquoi ne pas voir les traces comme un remplaçant des logs et donc avec un transfert des coûts depuis les logs vers les traces ? Au final, l’information est quasiment la même, les deux sont des hashmaps clé/valeur. Ne vous dites pas "j’aurai 40TB de traces en plus de mes 40TB de logs", mais plutôt "j’aurai 40TB de traces mais plus que 2TB de logs, et une meilleure capacité à investiguer des problèmes". C’est vraiment vers ça que doit pour moi se tourner l’industrie (et les gens construisant des outils de gestion de logs). Pour aller plus loin Il y a d’autres champs disponibles dans les spans. Les Links permettent de lier des spans entre elles même si elles font partie d’autres traces (donc d’avoir aussi des relations entre traces et non seulement entre spans d’une même trace). Le champ Kind permet d’ajouter une valeur spéficiant si l’émetteur est un client, un serveur, ou consumer de messages (d’une queue de message par exemple)…​ Bref, la définition des spans est vaste et le mieux est d’explorer la documentation. Propagators Les traces permettent donc de suivre entre systèmes des actions. Mais comment réaliser cela quand par exemple un client envoie un requête HTTP à un serveur, ce serveur publiant ensuite un message dans une queue de message (ou Kafka par exemple) qui sera ensuité consommé par un autre service ? Nous voulons pouvoir suivre l’action jusqu’à sa fin. C’est là que les propagators interviennent: c’est une convention pour passer des informations de tracing entre systèmes. Le plus connu est le propagator Trace context: c’est un standard du W3C. Dans le cas d’un client HTTP faisant un requête sur un serveur, les informations de la span courante côté client seront passées au serveur via un header HTTP appelé Traceparent, par exemple: Traceparent: 00-0af7651916cd43dd8448eb211c80319c-00f067aa0ba902b7-01 Le format est <version>-<trace-id>-<parent-span-id>-<flags> Le serveur récupèrera ces informations et les utilisera pour ses propres spans (notamment en mettant dans trace_id l’ID de la trace et dans parent_id l’ID de la span parente du client). Pour de l’asynchrone, pareil: les informations de la trace seront passées dans le message et récupérées par le consommateur. Quand vous utilisez Kafka, il est courant d’utiliser les headers du protocol Kafka pour cela. Il est très important de ne jamais "casser la chaine" du tracing ou alors le contexte est perdu, et votre trace incomplète. Cela demande une certaine discipline dans le code applicatif pour être sûr que le contexte est toujours passé entre fonctions et à chaque I/O. Si un service intermédiaire n’implémente pas le tracing et casse la chaine, c’est game over. Générer des métriques depuis les traces ? Pourquoi as-ton besoin de traces quand on a des métriques ? Car il n’est pas possible avec des traces brutes d’avoir une vue aggrégée du comportement d’un système. Les traces permettent d’avoir accès aux détails sur la performance d’une requête unique: cela est impossible avec des métriques type Prometheus. Les métriques fournissent des informations comme par error le nombre de requêtes par seconde sur un service, et du nombre d’erreur (error rate). Elles vont fournir aussi des quantiles pour mesurer la latence (p50, p99…​). Et c’est sur des métriques que l’on pourra définir des SLO et calculer par exemple des choses comme un error budget ou burn rate (peut être que je ferai un article sur ce sujet plus tard). Néanmoins, tout cela pourrait théoriquement être dérivé depuis les traces. Si vous gardez 100 % de vos traces, il est possible de recalculer tout ce que vous voulez depuis ces traces. L’outillage pour réaliser cela "at scale" est un peu limité pour le moment. Je montrerai dans un prochain article comment réaliser cela en utilisant Mirabelle, un outil que j’ai conçu et sur lequel je viens de rajouter le support d’Opentelemetry traces. Cela n’est pas forcément une idée nouvelle. A l’époque de protocoles comme statsd les métriques étaient dérivées d’événéments. L’industrie a ensuite changé son fusil d’épaule avec des outils comme Prometheus (et du pull pour récupérer les métriques) mais je pense que l’on va revenir dans les prochaines années à des systèmes orientés "push", basés sur Opentelemetry, et j’espère les traces. Je rêve d’un monde où j’ai juste à générer des traces pour remplacer la majorité de mes métriques et de mes logs. Conclusion Je pense que le tracing est le futur de l’observabilité. Je n’ai rien d’autre à dire pour conclure cet article ;)

📽️ Abonnez-vous : http://bit.ly/2UnOdgi 🖥️ Devenir membre VIP : https://bit.ly/3dItQU9 👂 Podcast : https://podcast.ausha.co/xavki/ Poursuivons avec la lecture de nos messages rabbitmq et notre code python. Nous allons le faire évoluer pour écrire notre lecture dans postgresql. Mais pour cela on commencera par installer un serveur postgresql avec son utilisateur, sa base de données et la configuration nécessaire pour son utilisation. Codes : https://gitlab.com/xavki/tutoriels-miniscrap #python #devops #opensource #crypto #postgresql Sommaire de plus de 1500 vidéos : - sur github : https://bit.ly/2P5x8Xj - sur gitlab : https://bit.ly/2BvYouO ➡️ ➡️ Vous voulez m'encourager likez la vidéo, commentez-là et abonnez-vous ! 😃

Comment apprendre à se servir de AWX ? comment se former ? Je vous propose en quelques vidéos de vous former à #awx et si vous le souhaitez à poursuivre par une formation #ansible. Cette playlist à vocation à vous aider à monter en compétence sur cet outils #devops. Dans cette vidéo, nous allons installer awx via docker et docker-compose. Cela ne nous empêchera pas de faire du ansible car c'est aussi par celui-ci que awx s'installe. Tutoriels ansible : https://gitlab.com/xavki/presentation-ansible-fr Sommaire de plus de 1500 vidéos : - sur github : https://bit.ly/2P5x8Xj - sur gitlab : https://bit.ly/2BvYouO ➡️ ➡️ Vous voulez m'encourager likez la vidéo, commentez-là et abonnez-vous ! 😃 📽️ Abonnez-vous : http://bit.ly/2UnOdgi 🖥️ Devenir membre VIP : https://bit.ly/3dItQU9

📽️ Abonnez-vous : http://bit.ly/2UnOdgi 🖥️ Devenir membre VIP : https://bit.ly/3dItQU9 👂 Podcast : https://podcast.ausha.co/xavki/ Après avoir produit des messages vers rabbitmq avec du code en python, nous allons le consommer. Là encore très simplement nous allons réutiliser pika et ses paramètres de connexion pour récupérer les messages des cryptos. Codes : https://gitlab.com/xavki/tutoriels-miniscrap #python #devops #opensource #crypto Sommaire de plus de 1500 vidéos : - sur github : https://bit.ly/2P5x8Xj - sur gitlab : https://bit.ly/2BvYouO ➡️ ➡️ Vous voulez m'encourager likez la vidéo, commentez-là et abonnez-vous ! 😃

Table des matières Introduction Un exemple d’attaque de la supply chain Quelles solutions pour y répondre ? Supply chain Levels for Software Artifacts Quelles attaques corrige le framework SLSA ? Et en Europe ? Conclusion Liens S’il est un sujet qui me tient à cœur, c’est bien la sécurité. Combien de fois, je vois sacrifier la sécurité au nom de la vélocité ou de la fainéantise.

📽️ Abonnez-vous : http://bit.ly/2UnOdgi 🖥️ Devenir membre VIP : https://bit.ly/3dItQU9 Comment suivre une formation dédiée à #Helm ? Je vous propose de suivre un cours complet à l'aide d'une playlist avec un niveau progressif et le plus pédagogique possible. Helm est un formidable moteur de templating pour #kubernetes. Dans ce tutoriel nous allons découvrir lescontoller WITH et RANGE. Ce sera aussi l'occasion pour nous de voir comment créer une variable dans les template GO de helm. Enfin nous verrons l'importance des scopes ou périmètre de nos values. Tutorials Helm : https://gitlab.com/xavki/tutoriels-helm-fr Sommaire de plus de 1400 vidéos : - sur github : https://bit.ly/2P5x8Xj - sur gitlab : https://bit.ly/2BvYouO ➡️ ➡️ Vous voulez m'encourager likez la vidéo, commentez-là et abonnez-vous ! 😃

🧐 Et si tu te laissais tenter par un métier qui allie passion et défis ? 👨‍💻Des technos à explorer et des défis constants à relever : Le DevOps, c'est ça ! 🦸🏼 En devenant un héros de l'ombre au cœur de ton entreprise, tu auras l'opportunité d'apporter une vision globale unique. Le DevOps est en pleine évolution, offrant de nombreuses opportunités, mais attention, il peut être stressant. C'est ce dont on va discuter aujourd'hui avec Nicolas, Mathieu et Erwan. Sommaire : 00:00 Intro 01:58 Qu'est-ce que les métiers DevOps ? Les avantages : 07:50 On s'ennuie pas 15:00 Vision métier et impact sur l'entreprise 26:40 Des applications et infra plus robustes 29:58 C'est très recherché 37:32 💼 Va voir mon Jobboard : https://vu.fr/jobboard-DevOps Les Désavantages : 38:23 Le stress 50:43 Invisible 59:01 Complexe 01:14:17 Une longue formation 01:23:45 Clôture 01:23:50 🎓 Forge toi un état d'esprit DevOps : https://vu.fr/devops-mindset 📩 Si tu n'es pas déjà abonné, alors abonnes-toi pour ne pas rater les prochaines vidéos. 💬 Rejoins la communauté des Compagnons du DevOps : https://www.compagnons-devops.fr 🔗 Tous mes liens : https://i.mtr.bio/compagnons-devops Mon Jobboard 💼 Trouve ton job de rêve : https://vu.fr/jobboard-DevOps 👔 Recrute avec moi : https://vu.fr/jobboard-DevOps-recrute Mes antisèches 🎁 git : https://bref.lydra.fr/antisechegit 🐳 Docker : https://bref.lydra.fr/antisechedocker 🔀 Ma RoadMap DevOps : https://vu.fr/RoadmapDevOps Mes formations 🎓 Forge toi un état d'esprit DevOps : https://vu.fr/devops-mindset Crédits Les podcasteurs : - Christophe Chaudier : consultant indépendant au sein du collectif Lydra. Animateur du podcast de la communauté des Compagnons du DevOps. Découvre le : https://lydra.fr/ea-3-le-podcasteur-christophe | LinkedIn : https://www.linkedin.com/in/cchaudier | Froggit : https://froggit.fr/ - Nicolas Ledez : devops chez CGWire. Il travaille dans l'IT depuis 20 ans. Il est "Schizophréne" : adminsys et développeur suivant le moment de la journée. Il paraît que ça s'appelle "devops", même si il déteste mettre ce nom sur un poste. Découvre le : https://lydra.fr/ea-8-le-podcasteur-nicolas/ | LinkedIn : https://www.linkedin.com/in/nicolasledez | Twitter : https://twitter.com/nledez | Github : https://github.com/nledez | Le reste : https://nicolas.ledez.net - Erwan Ben Soudien : DevOps chez Toucan Toco (ex Deezer, Antelink, Weborama - ex sysadmin ) - professeur vacataire à Paris XIII / IUT Creteil. Découvre le : https://lydra.fr/ea-2-le-podcasteur-erwan/ | Linkedin : https://www.linkedin.com/in/erwan-ben-souiden-8b8084152 - Mathieu Corbin : administrateur système pendant quelques années, il est maintenant SRE chez Qonto. Découvre le : https://lydra.fr/ea-7-le-podcasteur-mathieu/ | Twitter : https://twitter.com/_mcorbin | Github : https://github.com/mcorbin/ | Blog : https://mcorbin.fr L'intro et la fin sont de : - Baptiste Gaillet : FullStack développeur avec une tendance DevOps au Centre Scientifique et Technique du Bâtiment, Fondateur et développeur de l'application BedFoodCoffee pour aider les personnes en difficultés. Après des études dans le son et différents métiers, il a effectué une reconversion professionnelle en 2015 pour devenir développeur (Formation diplômante dans le cadre d'un CIF). LinkedIn : https://www.linkedin.com/in/baptiste-gaillet-223832b4 | Twitter : https://twitter.com/bat79a - La musique d'intro est *"Tupac Lives"* de John Bartmann : https://pixabay.com/fr/music - La musique de fin est *"Passport"* de Purple planet : https://www.purple-planet.com/passport Images freepik :https://www.freepik.com/free-photo/angry-businessman-yelling-laptop-home_4360411.htm https://www.freepik.com/free-photo/adult-smiling-businessman-browsing-laptop-home_4360405.htm Le montage est de Louna HO : https://www.linkedin.com/in/louna-ho-0656801b1/ 📜 Ce contenu est sous licence libre : CC BY-SA : https://creativecommons.org/licenses/by-sa/4.0/deed.fr Si tu utilises ces contenus dans une publication, merci de nous le notifier dans les commentaires. 🌐 Les Compagnons du DevOps est une initiative de Lydra : https://www.lydra.fr #Podcast #DevOps #Métiers #Pouretcontre Vidéos similaires : https://youtu.be/rMZ2-Szd-QE https://youtu.be/VihAg179M3I https://youtu.be/1d9j_Oy-SeM https://youtu.be/-5vOBrB1MI8 https://youtu.be/OO14AU3CI20 Chaînes similaires : https://www.youtube.com/channel/UCs_AZuYXi6NA9tkdbhjItHQ https://www.youtube.com/channel/UCVRJ6D343dX-x730MRP8tNw https://www.youtube.com/channel/UCM0mnsNbecIi_IAPXtHb-TA

📽️ Abonnez-vous : http://bit.ly/2UnOdgi 🖥️ Devenir membre VIP : https://bit.ly/3dItQU9 👂 Podcast : https://podcast.ausha.co/xavki/ Chef est une plate-forme open source de gestion de la configuration qui permet aux équipes informatiques de créer, déployer et gérer de manière cohérente des infrastructures et des applications à grande échelle. Chef utilise une approche déclarative pour la configuration et l'automatisation, ce qui signifie que les utilisateurs décrivent l'état souhaité de leur infrastructure dans des recettes et des modèles, puis Chef se charge d'appliquer ces configurations et de maintenir la cohérence de l'état système. La plate-forme Chef offre également des fonctionnalités avancées telles que la découverte automatique des ressources, la gestion des dépendances, la gestion des mises à jour et des correctifs, ainsi que des capacités d'orchestration pour coordonner les actions sur plusieurs nœuds. Chef est utilisé par de nombreuses entreprises pour automatiser leurs opérations informatiques, gérer la configuration des serveurs, déployer des applications et maintenir la cohérence de l'infrastructure à grande échelle. Code & Présentations : https://gitlab.com/xavki/tutoriels-chef-infra #chef #devops #opensource #linux Sommaire de plus de 1500 vidéos : - sur github : https://bit.ly/2P5x8Xj - sur gitlab : https://bit.ly/2BvYouO ➡️ ➡️ Vous voulez m'encourager likez la vidéo, commentez-là et abonnez-vous ! 😃

Table des matières Introduction Les spécifications de Wolfi OS Construction des images avec un Dockerfile On utilise apko et melange Et les vulnérabilités ? Conclusion Introduction Les concepteurs de Wolfi OS, porté par la société Chainguard se sont fixé comme objectif de produire des images de conteneurs qui répondent aux exigences de sécurité. Par exemple les images officielles ne doivent contenir aucune vulnérabilité critique connue.

Table des matières Qu’est ce que le Platform Engineering ? Retour sur le DevOps Les anti patterns du Devops Le Platform Engineering c’est… Comment démarrer ? Conclusion Après DevOps, Site Reability Engineering, voilà qu’on nous parle de Plateform Engineering. Mais de quoi s’agit-il ? Qu’est ce que le Platform Engineering ? Je vais m’appuyer sur le site de la communauté platformengineering.org Voici la définition qu’on y retrouve : “Platform engineering is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations…”