Comment définir le gitops ? Pourquoi est-il autant adopté ? Mais est-il vraiment novateur ?

De nos jours le terme OPS est utilisé et abusé parfois. On connait bien sûr le devops, le devsecops ou encore le noops, le dataops, le netops, le finops… Alors le gitops rejoint-il cette tendance ?

OPS pour opérateurs en français. Très bien cette définition est assez vaste, ramenons cela un peu à l’IT et ce qui fait émerger ce thème à savoir le devops. On parle donc d’un côté d’une approche et d’un univers les développeurs où le besoin et de développer de nouvelles choses (features…). Et de l’autre finalement le monde de la production qui doit répondre à des problématiques différentes à savoir rendre un service avec un certain niveau d’exigences (le développement à lui aussi ces exigences et parfois celles-ci sont aussi conjointes).

Et l’un ne va pas s’en l’autre il faut le rappeler.

Le devops a donc émergé par l’opposition durant des années entre ces deux mondes avec parfois une vraie rupture ou plutôt un fort clivage. Rendant parfois le quotidien délicat au sein des entreprises. Le devops, parfois sous forme de philosophie ou encore sous forme de poste spécifique, a su faire évoluer les mentalités et faire bouger les lignes. Actuellement on peut considérer les blocages sont plus rares. Dorénavant le devops repose surtout plus une stack technologique permettant d’aider à déployer les services (ou microservices) avec facilité jusqu’en production.

Et le gitops dans tout ça ???

Git la source de vérité dans le travail du quotidien

Dans le monde du développement, cela fait des années que git est la référence. Les process de plus en plus élaborés permettent d’assurer un travail coordonné en équipe (gitflow etc…). Git permet donc :

• de versionner
• de commenter
• de travailler à plusieurs
• de valider

Bref l’outil est sans contester le meilleur outil de versionning du marché lancé par Linus Torvalds. Ensuite sont venus des interfaces graphiques qui ont décuplées les fonctions de cet outil et autour de cet outil (github, gitlab…).

Et depuis quelques années, les ops (sysadmin, ingénieurs réseau…) l’utilisent de plus en plus au quotidien. En effet, l’infrastructure as code prend le pas sur les infrastructures mise en place un peu plus à la main sans éléments descriptifs.

Dans le gitops, on retiendra une chose essentielle, le dépôt git doit être la source de vérité… et on doit faire en sorte que ça le soit et forcer à ce que ça le reste (dans les pratiques mais aussi dans le développement du code).

Et le gitops est arrivé…

Clairement, cela fait bientôt 10 ans (voir plus) que les ops utilisent Git pour concevoir leurs infrastructures. Peut être avec une place un peu plus minime qu’avant et avec des process moins élaborés comme l’a connu le monde du développement.

Du coup, depuis plus de 10 ans et l’arrivée des outil d’infra as code (eh oui ça date pas d’aujourd’hui non plus), petit à petit ces ops ce sont mis à versionner et élaborer de manières de plus en plus profondes leurs infrastructures avec git.

Deux tendances s’en dégagent :

• le mode push : dans ce cas on utilise une machine pour pousser les configurations d’infrastructures à distance
• le mode pull : là il s’agit de tirer les informations du dépôt git avec “des agents” présents directement dans l’infrastructure en question. Et ce point c’est accentué avec l’émergence de kubernetes.

Donc on synchronise notre infrastructure avec le dépôt git à l’aide d’outils d’infra as code :

• puppet
• saltstack
• chef
• capistrano
• ansible
• flux
• argocd…

L’effet mode de gitops ?

Le terme gitops émerge ces dernières années alors que la pratique date de bien avant cela. Donc oui on peut considérer que l’on surfe une fois de plus sur cette mode de mettre une fois de plus ce suffixe tellement buzzword.

Néanmoins, ce terme vient mettre un mot sur une pratique… qui ne disposait pas tout à fait de mot… Si ce n’est de l’infra as code qui finalement reflète assez bien ce qui est fait. Le gitops spécifie l’outil de versionning utilisé finalement.

Les gros avantages du gitops

S’il devait être un objectif ultime en matière de gitops, ce serait de faire en sorte q’un ops n’aille plus sur les machines. Voir plus, que les clefs ssh d’utilisateurs ne soient plus à déployer. Un doux rêve mais qui donne l’orientation de la marche à se donner.

Ainsi, après avoir mis au point l’outil d’infra as code adapté, l’ops ne devrait avoir à modifier que le code et le pousser sur la branche git adaptée.

Donc peu importe le terme ce qui compte c’est cette pratique qui est très intéressante et à développer pour aller de plus en plus en profondeur l’infra as code.

Vous aimez ces thématiques ? venez nombreux et abonnez-vous à la chaine xavki !!

L’article Gitops, qu’est-ce que c’est ? est apparu en premier sur Xavki.

Kubernetes est pleinement dans cette mouvance. D’ailleurs, le nombre de technologies ou d’outils rattachés à celui est presque affolant. Tous les jours de nouveaux outils, régulièrement de nouveaux concepts émergent également. Bref on en a jamais fini avec kubernetes. D’ailleurs l’une des forces d’un bon devops, c’est de savoir aussi attendre et faire le bon choix parmi cette forêt d’outils qui demain n’existeront plus pour certains.

Apprendre par le bon bout…

K8S pour les intimes commence déjà par docker et les principes de conteneurisation. Je vous invite à découvrir docker via la chaine xavki si vous le souhaitez. Certes kubernetes tente de se détacher de ce “conteneur runtime” mais néanmoins pour apprendre se focaliser sur docker est plutôt une bonne approche.

Mais k8s se comprend avant de s’apprendre avec de nombreux concepts et définitions. Il faut imaginer déjà que k8s est un orchestrateur de conteneurs mais c’est aussi une grosse couche logique sur les conteneurs, leurs réseaux, le stockage et le dns qui va avec.

Dans cette introduction, si vous avez du mal à imaginer kubernetes, je vous propose de vous le présenter avec simplicité.

Kubernetes vient d’ailleurs du grec et signifie timonier. On peut le comprendre car il est à la tête de ce magistral porte conteneurs.

Avec kub vous allez pouvoir bénéficier de nombreuses fonctions avancées et rares, que ne fournissent pas forcément les autres orchestrateurs de conteneurs :

• autoguérisson
• autoscaling
• versionning
• rolling update
• sécurisation des communication entre les conteneurs par différentes couches
• gestion de la persistence de la donnée…

Mais attention ces grands pouvoirs nécessitent une grande responsabilité comme on dit. La responsabilité de celui qui manage le paquebot. Le moindre grain de sable dans cette horlogerie et c’est le trou noir compte tenu du rôle central de l’outil. Courage donc aux sysadmins et aux devops face à ce challenge.

C’est aussi pour cela que beaucoup de choix s’orientent vers des solutions plus ou moins managés :

• les solutions cloud : GKE, EKS…
• les managers : rancher…

Bref c’est une aventure et on peut même simplifier en indiquant que c’est un vrai outil de virtualisation avec les responsabilités qui vont avec (et les ressources et le temps).

On ne va pas vers kubernetes pour se faire plaisir, il faut y trouver un réel intérêt sur de nombreux facteurs. On ne le fait pas pour faire comme les autres ou parce que c’est la techno du moment.

De nouvelles notions et définitions dans kubernetes

Kubernetes fait partie des technologies embarquant le plus de concepts je trouve. Intellectuellement c’est très intéressant mais c’est aussi une charge.

En voici quelques unes :

Le Pod

Inévitable, il peut regrouper un ou plusieurs conteneurs. C’est la couche logique par excellence qui va permettre une total abstraction avec l’échelon inférieur le conteneur.

Le pod contient les applicatifs, il peut être plus ou moins éphémères suivant sont types. Vous pouvez associer avec lui un applicatif et une tâche ponctuelle nécessaire pour son installation. Il peut être scallé up ou down pour soutenir la charge etc…

Les services

On pourrait les rapprocher à l’exposition des pods mais en même temps il joue une sorte de fonction de dns. L’idée est de sécuriser et permettre l’accès aux pods ayant la même fonction.

Avec eux vous pourrez en quelque sorte exposer vos conteneurs ou à l’opposé les barricader. Si les pods d’un même applicatif sont distribués sur différents noeuds, il aura la charge de fournir comment accéder à ces pods (ip port…). Il permet également de faire du dns au sein du cluster kub.

Le replicaset

Résumons-le simplement à la gestion du nombre de pods.

Le deployment

Un autre échelon très important qui englobe les replicasets et les pods. Il permet notamment de gérer la santé des pods et leur scaling suivant certaines règles. Un deployment va permettre de créer des pods suivant un template de pods. Idéal pour l’instanciation.

Les statefulsets

On peut les résumer à des deployments avec les mêmes fonctions auxquels on ajouter des facilités pour gérer la persistence de la data qui est attachée aux pods. Idéal pour les bases de données essentiellement.

Bon courage à tous mais le plaisir est au rendez-vous si vous ne brûlez pas les étapes.

L’article Tutorials pour débuter avec Kubernetes est apparu en premier sur Xavki.

Mon plaisir c’est de vous voir venir et revenir sur cette chaine. Et pour cela vous proposer du contenu intéressant. J’évite de faire le buzz si ce n’est de prendre des technologies à la mode dans le monde du devops.

Les dernières technologies auront été : kvm, traefik, ELK, terraform, prometheus et grafana… et j’en ai pas fini avec elles.

Alors ce top 10 de la chaine xavki ? car je suis bien incapable de dresser un top 10 à l’échelle du web il y a tellement de choix et de bons contenus.

Voici donc les vidéos les plus consultées pour le mois d’août et je vous en dis mon ressenti.

1. Docker : Premier Pas

C’est la vidéo la plus vu mais pour autant j’en suis d’autant plus déçu. Paradoxal non ? en effet, elle fait partie des premières vidéos et son son est très mauvais. Mon approche pédagogique n’est pas encore là non plus . Alors pourquoi elle marche ? docker est recherché et les tutorials en français introduisant cette technologie n’était pas si courante à l’époque. Du coup elle s’est faite sa place avec ses likes.

2. Traefik, l’introduction

Autant l’introduction à docker m’a pas forcément apporté un énorme plaisir, autant que ce genre de vidéo marche me fait plaisir. Pourquoi ? une technologie française qui marche fort en ce moment, un besoin d’en parler et le réelle sentiment que vous recherchez ce genre d’informations.

Traefik est une technologie que j’adore en ce moment pour son dynamisme et ce qu’il l’entoure. D’ailleurs je crois que je suis traefik ambassador même si je n’en ai pas réellement le niveau.

3. Kubernetes, présentation des tutorials de la chaine

Cette playlist fait partie de mes tops formations. Je peux réellement avoir le sentiment de vous faire converger vers des niveaux un peu plus pointus à chauqe fois et c’est quelque chose que j’apprécie. Bien sûr Kubernetes est à la mode et ça aide mais présenter la simple liste des vidéos à venir n’est pas forcément quelque chose de recherché. Mais c’est déjà un pas vers la formation. Comprendre et découvrir un plan de formation c’ets déjà se former à mon sens.

4. Gitlab, oui c’est recherché

Dans cette vidéo j’ai tenté de survoler et présenter les opportunités apportées par Gitlab. Un formidable outil qui a tendance à créer une forte dépendance. Petite société qui a su se faire une place parmi les très grand parmi les sociétés côtées boursières américaines. La petite société a bien évoluée autour de l’automatisation du déploiement de votre code applicatif mais pas forcément. Ils ont su intégré des technos tendances et inévitables comme : grafana, terraform, kubernetes???

5. Jenkins peut être ce qui me représente le plus…

Une vidéo simple, un peu sans prétention qui vous présente jenkins. Jenkins est un acteur historique dans le domaine du scheduling. Malgré son ancienneté, il est encore présent parmis les leaders. Et surtout sa communauté abondante rend cet outil ultra-polyvalent dans des domaines variés : déploiement, datas, infrastructure…

J’aime vraiment beaucoup ce côté polyvalent et discret mais toujours présent ce qui en démontre sa robustesse et son efficacité.

A vous de me dire à travers les commentaires dans les vidéos, les pouces bleus ou rouges, ce que vous pensez de tout cela.

Même si j’ai des regrets sur les vidéos réalisées au début de la chaine xavki, il faut l’accepter. On vient d’où l’on vient et l’on évolue. D’ailleurs il me semble plus intéressant d’évoluer et de comprendre ce process d’évolution que de déjà tout connaître sans évoluer.

Allé je vous laisse apprécier ou pas tout cela. Vous abonner ou non… voir même devenir membre VIP. A vous de voir appréciez, votre liberté de choix.

L’article Top5 des vidéos devops en août 2020 !!! est apparu en premier sur Xavki.

Vagrant c’est l’outil que je vous invite de découvrir. Un très bon outil comme hashicorp sait le faire même si ce n’est pas son produit phare. Dans notre cas nous allons le coupler à virtualbox, un système de virtualisation assez commun à de nombreux systèmes d’exploitation.

Comment allons nous penser celà ? retrouvons cela en vidéo.

L’article Travailler son côté devops sur son laptop est apparu en premier sur Xavki.

Mais un devops doit aussi être adepte de certaines méthodes de travail (agile, scrum…). Gitflow fait partie des méthodes de développement à cheval entre l’utilisation d’un outil technique comme git et l’organisation d’une équipe (ou de plusieurs).

Avec GitFLow, vous organisez le travail en équipe pour développer et bien sûr en utilisant git. Le principe est simple, utiliser plusieurs branches pour symboliser les différentes étapes majeures du développement (que ce soit des outils applicatifs métiers ou encore des outils d’infrastructures).

Git flow est souvent représenté par le schéma suivant :

Chaque ligne représente une branche :

• features : les branches de développement “individuelles”
• develop : la branche dans laquelle les développeurs mergent leur travail quand il estime qu’il est réalisé (éventuellement via merge request)
• release : il s’agit de la branche à partir de laquelle on va estimer si la version est bonne (à l’issue de tests…)
• master : ou branche de production
• hotfix : dans le cas d’une nécessité de correction rapide suite à incident

Gitflow consiste donc à organiser le processus de développement et avancer dans ce process via des merges.

L’article Un peu de gitflow dans votre CI/CD est apparu en premier sur Xavki.

Sur le papier, certains imaginent le devops comme un MacGyver qui va être capable de faire du dev et de l’ops. Concrètement et au vue des précédents articles et vidéos que j’ai publié vous pouvez vous douter que mon point de vue est un peu différent. En outre, le cloud fait partie e ces outils mais n’est pas impératif.

Rappelons-le, le devops est là pour automatiser et organiser les déploiements pour permettre d’itérer trsè facilement les nouvelles versions de vos services.

Les schedulers ou ordonnanceurs de tâches sont donc inévitables :

• Jenkins : mon préféré car il repose sur la fondation Apache, possède une grande communauté et est totalement gratuit
• Gitlab : allie à la fois l’organisation des équipes, les déploiements et le code, il n’y a pas plus complet sauf qu’une partie repose sur la version d’entreprise payante
• Rundeck : outil gratuit mais moins complet et un peu moins adapté à l’élaboration de pipeline
• CircleCI : très bon outil assez complet mais avec une version payant à partir d’un certain niveau d’utilisation

Les orchestrateurs pour compléter les ordonnanceurs de tâches :

• Ansible : de loins mon préféré par sa simplicité et dans un contexte de pipeline de déploiement d’applicatif, simple en python à base de ssh
• Puppet : plus adapté à de la gestion globale d’une infrastructure
• Chef : un peu plus complexe et plus adapté à une gestion d’une infra

Les outils de tests :

• Jmeter : là encore mon préféré issue de la fondation Apache avec une large communauté et gratuit surtout
• Postman : idéal pour tester des API mais les fonctions les plus intéressantes sont dans la version payante
• JUnit : pour les tests unitaires du langage Java il existe dans tous les langages ce genre de librairie

Le monitoring, la collecte de métriques ou de logs :

• prometheus : une base de données timeseries qui scrappe les routes qui lui sont données. Peut être rendu dynamique avec Consul ou le DNS par exemple. N2cessite des exporter pour afficher les métriques sur des routes au format openmetrics.
• influxdb : une autre base timeseries qui ne scrape pas mais permet une bonne rétention des métriques (sur la durée, à la différence de prometheus).
• zabbix : très bon outil complet de monitoring et collecte de métriques, fonctionne avec des agents.
• munin/nagios : solution similaire à zabbix
• grafana : incontournable pour visualiser des métriques et créer des alertes
• elasticsearch/logstash/kibana : la triplette la plus puissante en matière de cllecte de logs et de leur analyse sous différentes formes.
• Netdata : pour disposer de la plupart des métriques de votre machines, s’installe en une simple ligne de commande.

En matière d’organisation de dépôt l’inévitable gitflow qui permet d’organiser ses branches git pour collaborer facilement en équipe tout en ayant une construction robuste d’outils de production.

Les bases de données, en avoir quelques notions :

• postgresql
• elasticsearch
• cassandra
• mariadb
• sqlite

L’article Ingénieur Devops : sa boite à outils est apparu en premier sur Xavki.

Eh oui le besoin actuel est de pousser le plus rapidement possible en production avec des risques limités. Mieux il s’agit de mettre en place des processus qui permettront de s’améliorer par l’erreur. Certaines sociétés comme Netflix ont même placé au cœur de leur infrastructure la nécessité de les éprouver fortement avec des chaos monkey. Il s’agit de fermé tomber des serveurs, des datacenters voir des zones entières à la manière où un singe arracherait les fils dans vos baies.

L’organisation est donc un point clef de la réussite en plus de la transformation technologique.

Pour revenir sur les microservices, ils permettent de passer d’une organisation horizontale à une organisation verticale. Le mode horizontal rassemblait dans une même équipe les sysadmin puis dans une autre les développeurs etc. Avec un système vertical par microservices une team est construite avec chaque corps de métier dont le but sera de produire une nouvelle version de l’application avec des évolutions courtes en terme de délais (les sprints).

L’article Le déploiement applicatif qui se reconstruit est apparu en premier sur Xavki.

Avant le devops ?

Sysadmin versus developpeurs lol. C’est souvent le résumé qu’en font certaines personnes. Un clivage entre deux modes de pensées certes mais avec des raisons justifiées des deux côtés (il n’est pas question de jeter la pierre à l’un ou à l’autre) :

• developpeur : on te demande de faire preuve d’innovation, d’aller toujours plus vite et d’inventer de nouvelles solutions
• sysadmin : ta tâche est ardue pour permettre de maintenir une plateforme dans un état de production avec une stabilité infaillible bien souvent contre tous

Bref un problème que n’ont pas souvent réussis à résoudre les managers car finalement les objectifs doivent tous être réalisés. C’est ainsi qu’est né le devops mi-sysadmin mi-dev. Mais finalement est-ce vraiment bien cela dont on attend de lui ?

Automatiser les déploiements

En partie oui mais pas seulement. D’un point de vue organisation, il est là pour mettre de l’huile dans les rouages, établir des process pour accélérer les choses. En revanche d’un point de vue technique, il est là pour automatiser la mise en production des appplications ou services (micro souvent).

Dans ma vidéo, je fais le parallèle avec l’industrie automobile et ses chaînes de production. Pour l’informatique, c’est l’émergence du déploiement automatisé. L’objectif principal étant de livrer toujours plus vite en limitant les risques. C’est aussi ce que nous allons apprendre au fur et à mesure des vidéos.

J’irai même plus loin. Cloud ou pas cloud, docker ou pas, le devops est omniprésent et ne dépend pas de ces technologies. Sa fonction est d’automatiser les mises en production peu importe le support. Une fois que l’on a compris cela on a déjà fait un grand pas.

Avec cette automatisation vient la standardisation. Et dans notre domaine cela ne fait pas de mal et donnera surement un bon coup de main aux administrateurs systèmes qui ont souvent perdus l’écoute et que l’on ne comprend plus dans leur posture.

Ainsi donc suivant les environnements, le devops pourra être une culture (certaines entreprises vont jusque changer tous les intitulés de leurs sysadmins en devops) ou un poste spécifique. Mais finalement, il faudra mettre tout le monde autour de la table pour parler de l’automatisation du déploiement des applicatifs.

L’article Définition du devops : entre technique et histoire est apparu en premier sur Xavki.

Voici donc quelques technologies de l’ingénieur devops que vous allez découvrir et utiliser dans cette série :

• vagrant
• virtualbox
• jenkins
• ansible
• jenkins
• docker
• gitlab
• gitflow

Cet ensemble de technologies va vous plaire j’en suis sûr. Et surtout vous n’aurez nul besoin d’internet pour lancer votre infrastructure.

Voici donc la présentation de ce projet en vidéo.

Bien sûr abonnez vous à la chaîne et/ou au blog pour ne pas manquer les prochaines présentations.

L’article Formez vous et créez votre propre pipeline devops !!! est apparu en premier sur Xavki.