Découverte : Trellis

Un vent de fraicheur souffle depuis environ deux ans sur la manière de créer des images Docker : Trellis. Kesako ? C’est un outil d’intégration et déploiement continu…portable. Le principe de Trellis est de permettre de définir des Dockerfiles ainsi que les pipelines d’intégration et déploiement en Typescript et de les exécuter absolument n’importe où. Des prérequis ? Evidemment il y a quelques prérequis à l’utilisation d’un tel outil : - deno, le runtime javascript/typescript base sur javascript version 8 et sur Rust et disponible depuis Mai 2018, - docker, evidemment, - Et…c’est tout.

Plus ou moins inutile donc forcément indispensable : OnLogs

J’ai eu l’information assez récemment provenant de l’application mobile DevOps Tools avec laquelle j’effectue une grande partie de ma veille technologique. La notification est arrivée il y a quelques jours mais avec l’actualité de fin d’année relativement chargée, dont les nouveautés les plus fraiches des Cloud Provider, du monde des conteneurs et de la cybersécurité, je n’ai pas pris le temps de vous le présenter. Pour celles et ceux qui connaissent Docker et son CLI, visionner les logs est un jeu d’enfants…Après tout, avec la commande docker logs <container_name>, on peut afficher les logs sans trop de difficultés.

Des nouvelles du Cloud...pour la fin d'année

L’actualité du monde de l’IT a été relativement chargée en ce mois de Décembre, je vous propose de revenir sur quelques unes des annonces les plus impactantes. Quelques doses de cybersécurité Le Webzine Security nous rapporte que l’administration américaine des transports (la TSA) a annoncé que les aéroports internationals d’Albany et de Syracuse (Tous deux dans l’état de New York) ont implémentés une technologie de validation des identités à l’aide de la reconnaissance faciale.

Data Management avec Apache NIFI

Une fois n’est pas coutume, au lieu d’aborder des sujets de type Cloud, Devops, retour d’expérience de conférences, de cybersécurité, etc…Cet article aura pour objet la Data. Non, je ne vais pas aborder le concept des Datalake mais plutôt le volet software et outillage du sujet. Chez un client, j’ai eu la possibilité de découvrir une technologie liée au domaine de la Data, à savoir Apache NIFI. Il s’avère que c’est un outil de gestion de flux de données permettant de les gérer et de les automatiser entre plusieurs systèmes à l’aide d’une interface graphique très épurée.

Des nouvelles du Cloud...

Cela faisait près de trois ans que je n’avais publié un article sur les nouveautés toutes fraiche provenant des Cloud Providers, je me suis dit que ce mois-ci, cela pouvait être une bonne occasion de réittérer l’expérience car l’actualité a été relativement riche et mouvementé de ce côté là. Commençons par Azure. Suite à l’évolution des technologies et des normes réglementaires, Microsoft a pris la decision de supprimer la prise en charge du chiffrement TLS dans les version 1.0 et 1.1.

Retour d'expérience IDM Europe 2023 (Utrecht)

Voici un article que j’aurais dû publier l’an dernier, en effet, Whitehall Media m’avait invité à l’événement de 2022 (avec un code d’accès réutilisable pour toutes les autres conférences) et je n’avais pas eu le temps de vous proposer un retour d’expérience sur le sujet. Initialement je pensais que ce type de conférence axé sur des retours d’expériences d’entreprises clientes de solutions autour des sujets IAM (Identity Access Management), PIM (Privileged Identity Management), PAM (Privileged Access Management), mais il s’avère que les intervenants sont relativement hétéroclytes puisque l’on y retrouve des acteurs du marché de l’Identity Management, tels que PingIdentity, Okta, BeyondTrust, SailPoint ainsi que des acteurs provenant d’autres domaines, tels que ABN AMRO Bank, les laboratoires ROCHE, Vodafone (cette année) ou Swisscom, Jumbo Supermarket ou Firmenich (l’an dernier).

Le hack - Retour d'expérience du salon parisien

Suite à la Toulouse Hacking Convention que j’avais particulièrement apprécié pour son côté technique d’un niveau assez relevé, j’ai eu envie de participer au salon Le Hack se déroulant, cette fois-ci, à la Cité des Sciences et de l’Industrie à Paris. Le fait que SQUAD proposait des invitations à leurs employés fut une bonne occasion d’y aller. Loin de moi l’idée de revenir sur les événements assez chaotiques de ce week-end, qui pourraient même faire l’objet d’un film à grand suspense, je vais plutôt revenir sur les conférences auxquelles j’ai pu assister.

Un petit tour de Packer...

Cela faisait très longtemps que je n’avais pas publié d’article sur Packer, et pour cause…Je n’y avais plus touché depuis 2019, bien que mon dernier article sur le sujet date de 2016. Loin de moi l’idée de vous proposer un article de type lab, au contraire ce sera plutôt un retour d’expérience de l’outil. Packer ? Distribué par Hashicorp, au même titre que Terraform, Vault, Vagrant ou Consul, Packer fait partie des technologies qui sont devenues des standards en ce qui concerne les outils orientés DevOps relatif à l’infrastructure et à la création de machines virtuelles à l’aide d’un fichier de configuration.

Le Labo #38 | Un peu d'intimité pour Terraform

Au départ, l’idée derrière Terraform était de provisionner des infrastructures Cloud en ayant un accès à la registry officielle de Hashicorp. Puis ils ont changé leur fusil d’épaule en se disant que, peut-être, certains avaient besoin de plus de flexibilité dans l’utilisation de leur outil préféré et souhaitaient se passer de la registry officielle et provisionner une ressource avec le provider sur leur disque dur. Mais et pour ceux qui évoluaient en environnement complètement fermé et sécurisé ?

Retour sur la Toulouse Hacking Convention

Retour sur deux jours de conférences Le salon Toulouse Hacking Convention s’est tenu sur deux jours, les 20 et 21 Avril 2023 dans le cadre de l’auditorium Marthe Condat, au sein de l’Université Paul Sabatier de Toulouse. Lors des quinze sessions, entre rétro ingénierie physique, hacking de matériel, démonstrations techniques et retours d’expériences relatifs à certaines situations rencontrées sur le terrain. Bien que j’ai pu assiter à toutes les conférences…excepté à celle d’Axelle Apvrille (pour cause de bouchons sur la route), je ne vais pas revenir sur toutes mais uniquement sur celles qui m’ont le plus marquées.

Le Labo #37 | Provisionning de bases SQL avec Liquibase et ArgoCD

Je viens de réaliser que mon tout dernier article date de Juin 2021…presque un an sans publier quoi que ce soit, ça fait long. Quoi qu’il en soit, cet article a pour objectif d’expliquer comment déployer et provisionner des bases de données SQL avec Liquibase et ArgoCD en mode job. Avant d’entrer dans la technique, je vais commencer pour expliquer le contexte ainsi que quelques points de détail techniques. On pourrait croire qu’il n’y a rien de plus simple que de de provisionner une base de données sur un serveur SQL…après tout, il suffit d’exécuter un script SQL pour créer un utilisateur, son mot de passe, lui octroyer des droits sur une base et créer la base en question.

Le Labo #36 | Un petit tour du côté du framework Operator

Framework Operator et déploiement de Thanos et Prometheus sur Kubernetes Il y a environ deux ans, j’avais publié un article autour de Thanos et d’un stockage sur Google Cloud Storage relativement simple car il n’était pas du tout question de Prometheus Operator et de sa configuration ni de Kubernetes. Cette fois-ci, je vais aller plus loin en abordant les thématiques citées précédemment (à savoir Prometheus Operator et Kubernetes), mais également les exporters et comment les connecter à notre Prometheus, le tout dans un environnement multi-custer…sans oublier les certificats TLS.

En route vers la certification **Certified Kubernetes Security Specialist** - 1ere partie

Au lieu d’un seul article global sur la préparation d’une certification, comme j’ai pu vous le proposer par le passé, je vais initier une série d’articles décrivant chaque aspect pour lesquels vous serez censés être intérrogés (si vous souhaitez la passer). Les sujets ci-dessous sont au programme : - Cluster Setup, - Cluster Hardening, - System Hardening, - Microservices Vulnerabilities, - Supply Chain Security, - Monitoring, Logging and Runtime Security. Ce premier article se focalisera sur le premier aspect, à savoir Cluster Setup, et traitera de plusieurs points tels que : - Les Network Security Policies, - CIS Benchmark afin de vérifier le niveau de securité de configuration de chaque composant de Kubernetes, - La sécurisation des Ingress Controllers, - La protection meta-données des Nodes, - L’usage de l’UI de Kubernetes et sa securisation, - La vérification des binaires avant déploiement.

Review de la conférence Paris Containers Day 2021

Le Paris Containers Day est un événement organisé par Wescale et Publicis Sapient (Anciennement Xebia) depuis 2016 et orienté Conteneurs et Orchestration. Malgré le contexte sanitaire mondial, et bien qu’ils l’aient, à l’origine, lancé en physique sur Paris. L’événement a finalement pris la forme virtuelle, à l’instar d’autres conférences telle que l’AWS Re:Invent. De plus, contrairement aux précédentes éditions qui se déroulaient sur une seule journée, celle-ci prend place sur deux après-midi.

Le Labo #35 | Une approche FinOps sur Google Cloud avec les Cloud Functions

Cela faisait longtemps que je n’avais pas publié d’article et cette fois-ci, j’ai décidé de m’atteler à un sujet que je n’avais encore jamais abordé : Le FinOps. J’imagine que la gestion des coûts est un sujet que nombreux d’entre vous ont approché de près ou de loin que ce soit personellement ou lors des différents projets sur lesquels vous avez pu évoluer au sein de vos clients. De mon côté, à part pour mon blog…je n’ai pas vraiment eu à m’en soucier, même si j’ai toujours eu à coeur de gérer des workloads comme si je devais les payer moi-même (donc en reduisant au maximum l’impact financier).

Le Labo #34 | Hardening d'instances Consul et Vault et déploiement sur Kubernetes

J’avais une grande hésitation sur le titre…et puis j’ai voulu faire un peu d’humour en remplacant PLS par TLS…mais ce ne fait pas le même effet (j’en suis bien conscient). Dans l’article précédent j’avais continué mon exploration de Vault en vous proposant un moyen relativement simple de remplacer le Secret Manager de Kubernetes par un cluster Vault externe…et d’après les quelques retours que j’ai eu sur LinkedIn, vous avez apprécié. Par conséquent, j’ai décidé d’explorer un peu plus le sujet en proposant, cette fois-ci, une approche plus orientée sécurité en ajoutant le chiffrement des communications entre Consul et Vault via TLS.

Le Labo #33 | Kubernetes invite Vault à danser

Je sais que le titre de cet article est un tantinet putaclic et j’assume complètement, néanmoins je continue à travailler sur deux technologies qui m’attirent énormément…il s’agit de Kubernetes et Vault. Dans mon article précédent, il s’agissait plus ou moins d’une découverte de Vault - bien qu’intégrer l’auto-unseal, l’observabilité et l’authentification LDAP à un cluster Vault ne soit pas, à proprement parler, un article de découverte…il permettait de poser quelques base sur le sujet (Notament autour de la création d’un cluster).

Le Labo #32 | Vault dans tout ses états

Il y a quelques mois, suite au passage de la certification Hashicorp Terraform Associate j’ai eu envie de préparer celle sur Vault pour plusieurs raisons : - L’aspect sécurité m’intéresse fortement, - Parce que je suis un grand fan des projets Hashicorp depuis ma découverte de Terraform il a près de cinq ans. Cependant je n’avais pas pu me lancer dedans car je préparais également deux autres certifications (que j’ai obtenu par la suite).

November News from the Clouds

AWS Ce mois-ci, nous avons assisté à plusieurs événements : Les lancements de deux nouvelles régions : - Zurich, - Hyberabad. Et de nouveaux services : - Nitro Enclaves (qui est l’équivalent des Confidential VMs ou des Confidential Instances disponibles respectivement sur Google Cloud et Azure) et les certificats SSL qui leur seront associés via Amazon Certificate Manager. - OpsCenter : une intégration de CloudWatch dans AWS System Manager qui nous permettra d’effectuer des aggrégations d’événements, d’alertes et d’incidents dans un seul et même dashboard.

News from the Clouds #2

Azure Je n’avais pas encore abordé cette information dans le précedent article sur les nouveautés du Cloud de Microsoft. Mais voici une information intéressante sur les Confidential Containers Nodes, des workers Kubernetes du même type que les Confidential Instances sur Google Cloud, disponible depuis le début du mois d’Octobre 2020 en Preview. Un article de Forbes est revenu sur les effets de la panne massive des services Azure et Microsoft 365 survenue en début du mois d’Octobre.

News from the Clouds #1

Review des nouveautés des fournisseurs de services Cloud Azure, AWS et Google Cloud. AWS AWS Transcribe - 15 Septembre 2020 Dorénavant ce service supporte la fonctionnalité Automatic Language Identification. AWS Transcribe est un service de reconnaissance vocale automatique qui a évolué depuis sa création avec la prise en charge de 31 langues dont 6 en temps réel. Un cas d’utilisation populaire de ce service est la transcription des appels clients permettant aux entreprises d’effectuer des analyses à l’aide de techniques de traitement de langage naturel.

Le Labo #31 | Serveur RDS et Autoscaling des Session Hosts

A l’origine A l’origine, le composant RDS s’appelait Terminal Services et était principalement destiné aux réseaux locaux ou régionaux offrant de meilleures latences que sur un réseau bien plus large. Qu’est-ce que Terminal Server? Il s’agit d’un composant destiné à une architecture de client léger où les applications (incluant selon les cas le bureau Windows) sont rendues disponibles à l’aide d’un terminal client à distance. Ce type de technologie à évolué avec le temps et a tout d’abord été introduit sous Windows NT 4.0, amélioré sous Windows 2000 puis Windows 2003 pour devenir Remote Desktop Services dès Windows 2008.

Le Labo #30 | Ejabberd et l'autoscaling sur AWS

A l’origine Je vais vous avouer que lorsque l’on m’a demandé si je connaissais le protocole XMPP, j’avais un doute mais je me suis renseigné avant de répondre. Et c’est à ce moment que ça m’est revenu (en parcourant les résultats proposés par Google): Jabber est basé sur le protocole XMPP. Pour la petite anecdote, j’ai évolué pendant plusieurs années pour un fournisseur de services Cloud Européen dans lequel nous utilisions Jabber pour communiquer entre les différentes équipes (Italie, France, Europe de l’est).

La certification Kubernetes Administrator - CKA

Intro Depuis le début de l’année, j’enchaine les certifications sur des technologies avec lesquelles j’ai beaucoup travaillé, mention spéciale à Terraform et Azure…Mais il y en a une avec laquelle j’ai travaillé il y a quelques années et qui m’a vraiment donné des sueurs froides, il s’agit de Kubernetes. Ma compagne s’en souvient encore, je n’arrêtais pas d’en parler parce que je n’arrivais pas à faire fonctionner un déploiement, un service, ou n’importe quel autre objet disponible dans l’API.

La certification Google Associate Cloud Engineer

Intro Suite à mes passages de certifications Azure et AWS, je me suis dit : “Pourquoi ne pas se lancer sur le troisième ?”, d’autant plus que j’avais également travaillé sur ce Provider par le passé. Tout comme AWS, Google propose deux niveaux de certifications et contrairement aux deux autres, Kubernetes a une très grande place parmis les sujets abordés…Ce qui est une très bonne préparation pour la certification suivante (Kubernetes Certified Administrator).

La certification Hashicorp terraform Associate

Intro Depuis le temps que la communauté Terraform l’attendait, Hashicorp l’a enfin sortie : La certification Terraform. Certes, ils en ont sorti deux (avec Vault…que je passerai avec plaisir). Je ne suis peut être pas un early adopter, j’ai commencé à jouer avec vers 2016 (la première release doit être de 2014, je crois). Le but de cet article est de partager mon expérience et le maximum de conseils possible afin d’être vraiment prêt le jour J.

News from Google Cloud Platform

Du nouveau sur Google Cloud Platform, depuis 18h trois nouvelles sont tombées : Nouvelle région : Las Vegas Parmi les régions déjà disponible depuis longtemps, une nouvelle vient de faire son apparition aux Etats-Unis. Ce qui porte au nombre de quatre dans l’Ouest des Etats-Unis et au nombre de sept au niveau national. Une nouvelle région comprenant trois zones et donnant, evidemment, accès à tous les services disponible sur la plateforme.

Les opérateurs ternaires

Intro Mais qu’est-ce qu’il dit le monsieur ? Cela doit certainement être la question à 10000 € que vous vous posez après avoir lu le titre de l’article…Et je vais voir avouer qu’après en avoir vu ça dans une conversation sur Slack je me suis dis la même chose. Dit comme ça Opérateurs Ternaire, ça à l’air étrange, ça sonne un peu comme du chinois pour ceux qui, un peu comme moi, ne sont pas très familiarisés avec le développement applicatif.

La certification Azure Solution Architect Expert

Intro Dans le cadre de mon travail sur les trois Cloud Providers les mieux implantés sur le marché, j’ai pu passer une première certification : AWS Solution Architect Associate. Et puis j’ai réalisé qu’il me serait aussi très utile de passer la certification correspondante chez Microsoft, afin de valoriser mon expérience d’un an et demi à travailler avec ce Cloud Provider lors d’une mission précédente. Cependant je me suis aperçu qu’ils ne proposaient pas de version dite Associate à moins de ne passer qu’un seul des deux examens…Mais n’en passer qu’un seul ne donne pas la certification.

AWS EC2 Image Builder

Le service EC2 - Service phare parmi la galaxie de services proposés par AWS - bénéficie de tout un écosystème de fonctionnalités répondant à de nombreux besoins grâce au marketplace sur lequel nous pouvons retrouver des AMI - Amazon Machine Images - fonctionnelles proposées par des acteurs phare du marché, tels que : - NetApp - Dell - Bitnami - Citrix - Plesk - OpenVPN Il y en a tellement que je pourrais pas tous les citer, mais sachez tout de même que si vous avez un besoin particulier, une AMI est disponible pour y répondre.

Comparatif de solutions de monitoring

Les solutions de monitoring les plus souvent citées sont très souvent Opensource et gratuites. Nous avons à faire à Prometheus/Grafana/node_exporter/AlertManager d’un côté et à Telegraf/InfluxDB/Chronograf/Kapacitor qui fonctionnent de manière totalement différentes. Le premier fonctionne en PULL (les métriques sont tirées par Prometheus depuis les serveurs) et le second fonctionne en PUSH (les métriques sont envoyées par les serveurs monitorés). Dans les deux cas, les serveurs à monitorer devront être configurés pour qu’ils sachent exactement quels données envoyer…Et où les envoyer.

Le Labo #29 | Thanos et Prometheus / Google Cloud Store

Il y a quelques mois, j’avais publié un article de présentation sur Thanos. Après autant de temps, j’ai décidé d’explorer un peu plus la technologie en l’associant avec un storage de type S3 sur Google Cloud. Et le fait qu’en début de semaine c’était le Google Cloud Summit n’a rien à voir là-dedans. Pre-requis Obviously…parmi les prérequis, il y a : - un compte de service + un projet sur google cloud - Prometheus - Thanos - 3 VMs Sur deux d’entre-elles seront installé Promtheus et Thanos, ce dernier ne sera démarré qu’en mode sidecar.

Tester son infrastructure avec Inspec

Inspec est un outil de test venant de la même équipe à l’origine de Chef et Habitat et partage au moins un point commun : c’est en Ruby. N’ayant jamais essayé les autres outils, je ne me lancerai sur de la comparaison entre Chef et Ansible/Salstack (je l’ai fais avec Puppet, mais parce que j’ai déjà joué avec). Pour en revenir à Inspec, celui-ci permet d’effectuer des tests de compliance sur des infrastructures cloud, bien qu’il permette également d’effectuer des tests sur des serveurs classique (sur des conteneurs, ça fonctionne aussi).

Le Labo #28 | Smart Monitoring

L’idée de départ était de monter une infrastructure disposant de fonctions de self-healing, en gros à chaque incident recensé devait correspondre une notification ainsi qu’une réaction automatique d’un outil de CI/CD. A l’aide d’outils tels que Prometheus, AlertManager, Slack et Jenkins, j’ai pu travailler sur ce type d’infrastructure…Par contre, je ne pense pas que ce soit limité à Slack (notifications) et Jenkins (Job CI/CD), je vous laisse tester avec d’autres outils.

Thanos...sans l'Infinity Glove

Désolé pour la petite référence à Marvel mais c’est assez rare de croiser des outils de monitoring ayant le nom d’un Bad Guy de la maison d’édition en question (surtout depuis que c’est devenu une Disney Princess - C’est pour le Troll, je sais, c’était gratuit). Pour en revenir au sujet, Thanos est sorti il y a quelques mois (en Septembre, pour être exact)…l’outil est très jeune mais déjà très prometteur.

Le Labo #27 | Monitoring et Service Discovery

Il y a quelques années, quatre (pour être précis), j’avais travaillé sur un article sur le sujet Service Discovery sans pour autant aller vraiment très loin…En l’occurence, j’avais juste ajouté la fonctionnalité en question à un cluster Serf. Entre temps, Serf a été abandonné par Hashicorp au profit de Nomad (l’alternative plus ou moins crédible à Kubernetes, Openshift et Kontena, malgré sa relative jeunesse). Depuis, j’ai eu le temps de me pencher un peu plus sur le sujet.

Le Labo #26 | Deployer sur Openstack via Terraform, Jenkins et Ansible

Pour une fois, je ne vais pas aborder le déploiement sur DigitalOcean, Azure ou même Google Cloud…Non, c’est fois ci, ce sera Openstack. Mais pas n’importe comment, ce sera toujours avec Terraform et sur plusieurs environnements différents impliquant donc plusieurs fichiers de variables différents. Je n’avais pas encore démontré l’utilisation des dépendances implicites ou d’utilisations de l’instruction lookup pour ittérer sur les listes de variables…Mais assez de tricotage/brodage, passons à l’action proprement dite.

Un CMF avec Strapi

Un CMF ? Kesako ? Tout le monde connait les CMS, ou Content Managment System, et il en existe vraiment tout plein comme, par exemple : - Magento : boutique en ligne - Wordpress : Que l’on ne présente plus…et qui est une usine à gaz - Drupal - PrestaShop Il y en a pour tout les goûts et certains sont tellement populaire qu’ils disposent aussi bien d’une communauté professionnelle reconnue que d’une communauté d’utilisateurs lambda (comme vous et moi).

La gestion des API avec Gravitee

Les APIs vous dites ? Ah…les micro services, toute cette hype récente autour des API proposées par des micro services qui communiquent entre eux lors de développement de gros projets, qu’ils soient internes ou externes. A l’origine, les projets étaient monolithique et plus le nombre de ligne de code grossissait, plus ça pouvait devenir compliqué à débugger lorsqu’un glitch apparaissait lors d’un déploiement de l’application en question (et souvent…ça partait directement en production à l’époque).

Ansible - les inventaires dynamiques

Je ne vais pas revenir sur ce qu’est Ansible, vous savez tous ce que c’est (j’espère…sinon je peux vous suggérer de faire un tour sur le site officiel). Par contre, il y a un moyen de rendre l’utilisation d’Ansible plus fun (je n’ai pas trouvé d’autres mot) à l’aide des inventaires dynamiques. Qu’est-ce que cela implique ? Gestion dynamique des hosts via un simple script En fait, dans le cas de Vagrant oui…mais en ce qui concerne OpenStack et Azure, ce n’est pas vraiment le cas puisqu’il faut aussi exporter quelques variables d’environnement.

Google Skaffold

Bonjour à tous ceux qui me lisent. Il est très rare que je fasse la pub d’un outil qui vient à peine de naître, mais dans le cas de Skaffold, je dirais que ça vaut le détour. Oublions donc le nom bizarre (qui signifie échaffaud dans la langue de Shaskespear), attardons nous plutôt sur ses fonctionnalités. Qu’est-ce ? Skaffold est un outils de CD en ligne de commande s’intégrant directement dans Kubernetes…Entendons CD non pas continuous deployment mais continuous development.

Comparatif Entre SaltStack, Ansible et Puppet

Alors oui, je sais…Certais vont crier au troll bien velu venant des montagnes. Certains vont se souvenir que je travaille sur Saltstack depuis un peu plus d’un an et demi…Mais ce sont ceux là même qui ont oublié que je fais parti des early adopters d’Ansible (quand Tower et Galaxy n’était pas encore sorti). Lors d’une de mes missions, j’ai pu aussi travailler sur Puppet…deux semaines, pas vraiment suffisant pour maîtriser la technologie, mais assez pour me faire une idée du manque de ‘naturel’ de la syntaxe (si je compare à Ansible et à SaltStack).

Le Labo #25 | Déploiement automatisé d'une instance Jenkins

Dans l’univers DevOps, l’intégration continue (ou CI pour les intimes) s’est imposée en tant que pratique à part entière dans l’optique de construire un projet de manière la plus agile possible, en vérifiant le code à chaque étape et en détectant les éventuelles régressions. L’intérêt de cette pratique repose souvent sur la mise en place d’une brique logicielle permettant l’automatisation des tâches de compilation, les tests unitaires et fonctionnels, la validation produit ainsi que les tests de performance.

Le Labo #24 | Une image Docker...sans Dockerfile

Quoi de plus basique pour un utilisateur de Docker que de créer une image ? En général, on utilise un Dockerfile pour cela, mais il est tout à fait possible d’explorer d’autres voies : docker commit : créer l’image docker à partir d’un conteneur pré-existant et personnalisé Salt + dockerng : créer une image docker à l’aide de Saltstack C’est cette dernière voie que nous allons expliquer dans cet article. Le principe Le principe général du module docker pour saltstack est l’utilisation de l’API de Docker à l’aide de la couche Salt qui, elle, gère tout ce qui est pillarisation, templates, runners, modules, etc… Selon ce mode de fonctionnement, il devient même possible de générer des Dockerfile (ce qui ne sera pas le but) ou de créer des images propres et prêtes à l’emploi.

Le Labo #23 | Vagrant, Kubernetes, Docker et Salt

Lors de mon précédent article, je faisais un tour d’horizon de Kubernetes, comment l’installer, créer un cluster rapidement et déployer un Service et deux Pods de base en faisant en sorte que la résolution de noms fonctionne. Au bureau…je me suis littéralement arraché les cheveux jusqu’a finir par comprendre (tout en travaillant sur d’autres projets). L’idée de cet article est de : - Déployer des VM à l'aide de **Vagrant** - Créer un cluster des ces VM grâce à **Kubernetes** - Configurer une connexion à un **Docker Private Registry** - Déployer des conteneurs **Docker** sur ce cluster - Déployer des applications dans les conteneurs à l'aide de **Salt** 1ere étape: Vagrant Je pourrais aussi déployer les VM à l’aide de Terraform, ca n’aurait aucune incidence sur le résultat final…ce serait même plus simple.

Le Labo #22 | Kubernetes - Joies et bonheurs

Avant de commencer Pas de jaloux…bientôt, je me lancerais sur un article autour de Docker Swarm. Après un article, il y a quelques mois sur Nomad, je me suis dis qu’il fallait que je fasse un nouveau tour d’horizon sur Kubernetes pour plusieurs raisons : Il me semble que la technologie est bien plus mature que Nomad et Swarm Il est compatible avec de nombreux Network Overlay Contrairement à ce que l’on peut penser…il est extremement simple a configurer Le déploiement et la maintenance d’un cluster de conteneurs est quasi automatisée Ce qu’il nous faut Dans ce labo, je vais avoir besoin de plusieurs serveurs : Docker Private Registry (au bureau je suis sur Nexus, mais ca fonctionne avec n’importe lequel…pour peu qu’il y ait de lauthentification par mot de passe) Plusieurs serveurs Kubernetes, 1 maître et plusieurs minions Docker Weave Net Installation de Kubernetes L’installation de l’outil en elle même est extrêmement simple, et se compose de 4 commandes parmi les suivantes : cat <<EOF > /etc/yum.repos.d/kubernetes.repo [kubernetes] name=Kubernetes baseurl=http://yum.kubernetes.io/repos/kubernetes-el7-x86_64 enabled=1 gpgcheck=1 repo_gpgcheck=1 gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg EOF yum install -y docker kubelet kubeadm kubectl kubernetes-cni systemctl enable docker && systemctl start docker systemctl enable kubelet && systemctl start kubelet Par contre, ce que je ne peux que vous suggérer, c’est de désinstaller firewalld et de le remplacer par iptables : systemct stop firewall; systemctl disable firewalld; yum remove -y firewall; yum install -y iptable*; systemctl enable iptables; systemctl start iptables Je vous suggère aussi de vérifier toutes les règles d’iptables et de supprimer celles qui commencent par reject (normalement, vous devrier en voir deux - une pour INPUT et la seconde pour FORWARD), cela évitera que vos nodes se fassent refoulent par le master au moment du kubeadm join.

Le Labo #21 | A la chasse aux démons

Avant de commencer Il est vrai que le titre peut laisser songeur quant à mon intention. Non, il n’y a rien de religieux….Mon blog n’a pour sujet que l’informatique. Dans ce billet, je vais aborder la démonisation (ou daemonization) d’application à l’aide de Salt via des states et des pillars. Si vous recherchez des formules relatives à l’installation de ces applications, vous en trouverez plein sur internet. Ce qu’il nous faut Dans ce labo, je vais avoir besoin de plusieurs serveurs : Un serveur Salt Deux serveurs sur lequel seront installés Logstash et Elasticsearch ainsi que Salt-Minion Les serveurs sur lesquels seront installés logstash et Elasticsearch seront équipés de CentOs 6 et CentOs 7, j’expliquerais pourquoi plus tard.

Le Labo #20 | A la découverte de Nomad

Pour commencer A un mois de Nöel…ca fait un peu plus de 4 mois que je n’avais rien publié…et je n’avais pas le temps de préparer d’article (ni d’inspiration). C’est alors que l’on m’a proposé de travailler sur de l’orchestration de conteneurs. Et…j’ai pensé à vous. Petit Historique de Nomad Le développement de Nomad a débuté en Juin 2015, en compagnie de Otto (projet qui fut simplement abandonné quelques mois avant la release de Nomad).

Le Labo #19 | La stack ELK et SaltStack

Formattage de logs de SaltStack (Master et Minion) à l’aide de la stack ELK Avant de commencer Lors de mon dernier lab, je m’étais lancé sur de l’automatisation de création de conteneur Docker à l’aide de SaltStack et rappelant que les logs d’érreur, bien que facilement compréhensible par un humain, pouvaient devenir assez indigeste. J’avais même évoqué la stack ELK comme éventualité pour formatter ces journaux de logs. Voici donc le résultat de deux semaines de travail et de nombreuses tentatives pour trouver une solution au problèmes rencontrés.

Le Labo #18 | Jouons avec Docker et SaltStack (update 12/09/2016)

Pour commencer… Cela fait un mois depuis mon dernier article et je commençais aussi à trouver le temps assez long. En fait, au dela de chercher une idée d’article pertinente pour vous, je travaillais d’arrache pieds à trouver des solutions sur les tâches qui m’ont été confiées. Tout cela pour dire que mes articles les plus récents m’ont été très utile…et celui-la aura pour objectif d’expliquer comment provisionner des conteneurs Docker à l’aide d’un outil de Config Management et j’ai décidé d’utiliser SaltStack au lieu d’Ansible (pour lequel j’avais déjà publier quelques articles).

Hugo...en prod (sur Ubuntu 16.04)

Petite introduction Pourquoi refaire un article concernant mon blog ? J’avais juste envie de trouver une autre voie que celle prise initialement…et me passer d’un conteneur Docker pas vraiment sécurisé. Donc, j’ai cherché un moyen de démoniser Hugo mais ca ne semblait pas possible. Donc, j’ai continué à chercher et je suis tombé sur une voie détournée : Hugo derrière Nginx et c’est cela que je vais présenter dans cet article.

Le Labo #17 | Packer, Terraform & Docker

Petite introduction Il y a quelque mois, je me lançais sur un projet “né sous la douche” (véridique…l’idée m’est venue un matin alors que je prenais ma douche) nommé “Powershell Docker Deployment” et consistait en du déploiement de conteneurs Docker sur des hôtes linux via un script en Powershell. Le pire, c’est que ça fonctionnait très bien…Mais, il faut dire que Terraform le fait aussi bien. Ce sera justement l’objet de ce labo : le déploiement de conteneurs Docker via Terraform.

Le Labo #16 - 3eme partie | Suite de l'initiation à Vagrant

Suite de l’initiation à Vagrant Pour ce nouveau Lab, j’ai souhaité me concentrer sur le provisioning des VM générées grâce à Vagrant. Ayant le choix des outils, j’avais fais le choix de commencer par Ansible puis je me suis concentré sur Salt (j’aurais peut être la chance de travailler avec cette technologie à l’avenir). Comment démarrer ? Le Vagrantfile Ayant déjà créé et téléchargé ma première image lors de mes deux premiers Lab sur Vagrant, je vais juste le modifier afin d’y intégrer le nouveau type de provisioner.

Le Labo #16 - 2eme partie | Suite de l'initiation à Vagrant

Suite de l’initiation à Vagrant Pour ce nouveau Lab, j’ai souhaité me concentrer sur le provisioning des VM générées grâce à Vagrant. Ayant le choix des outils, j’ai préféré commencer par Ansible pour une raison extrêmement simple : C’est celui que je connais le mieux. Par contre, après ce lab j’irais faire un tour du côté de Puppet et de Salt. Comment démarrer ? Le Vagrantfile Ayant déjà créé et téléchargé ma première image lors de mon premier Lab sur Vagrant.

Le Labo #16 - 1ere partie | Initiation à Vagrant

Initiation à Vagrant Pour ce nouveau Labo, je vais vous proposer une petite initiation à Vagrant. Vagrant est un outil que j’avais survolé lorsque j’avais publié la liste des outils de l’écosystème Hashicorp et, depuis, je n’avais rien publié à ce sujet… Mais, tout comme Terraform et Packer, je vais réparer cet oubli. Cet article est une simple initiation durant laquelle je vais juste déployer trois conteneurs vierge. Comment démarrer ?

Le Labo #15 - 3eme partie | Industrialisation d'infrastructure Cloud sur AWS

Industrialisation d’infrastructure Cloud sur AWS - 3eme partie Petite introduction Après avoir créé ma première image (Wouhouuuuu, alleluia…) sur la plateforme Cloud d’AWS à l’aide de Packer et d’Ansible, je vais en générer une nouvelle. Cette fois-ci, au lieu d’utiliser Ansible, je vais opter pour Puppet. Ayant déjà utilisé ce dernier dans le cadre d’un de mes derniers lab (le Lab #14 - avec Jenkins et Gitlab), l’expérience engrangée me servira aussi durant celui-ci.

Le Labo #15 - 2nde partie | Industrialisation d'infrastructure Cloud sur AWS

Industrialisation d’infrastructure Cloud sur AWS - 2nde partie Petite introduction Je continue mon tour d’horizon des outils existants d’industrialisation/orchestration d’infrastructure Cloud. Après avoir fais un tour du côté de DigitalOcean à l’aide de Terraform, Je continue l’aventure du côté d’Amazon. Après avoir expliqué la création du template pour Packer, c’est au tour des playbook d’Ansible. Avant d’aller plus loin Dans l’article précédent, j’avais évoqué le déploiement de serveurs LDAP, Web, MySQL et Docker Registry.

Le Labo #15 - 1ère partie | Industrialisation d'infrastructure Cloud sur AWS

Industrialisation d’infrastructure Cloud sur AWS - 1ère partie Petite introduction Je continue mon tour d’horizon des outils existants d’industrialisation/orchestration d’infrastructure Cloud. Après avoir fais un tour du côté de DigitalOcean à l’aide de Terraform, Je continue l’aventure du côté d’Amazon. Bien que cette plateforme propose un outils similaire à Visual Cloud, proposé par ArubaCloud, et nommé Cloud Formation, ce n’est pas celui là que je vais utiliser. Non pas que je n’ai pas trouvé comment l’utiliser…après tout, la création d’un fichier JSON décrivant chaque aspects des serveurs à créer est assez simple…mais je préfère laisser cela à Quicklabs et à d’autres organismes de formation.

Le Labo #14 | Intégration Continue - Jenkins/Puppet/Gitlab

Intégration Continue - Jenkins/Puppet/Gitlab Petite introduction Lors d’un de mes labos précédent, j’avais fais connaissance avec Gitlab-CI qui, à l’aide de Gitlab permet de bénéficier d’un environnement de déploiement continue unifié. Ce sur quoi j’ai travaillé ici est adaptable sur Gitlab-CI/Gitlab. C’est tout d’abord un environnement Puppet masterless dont les recettes Puppet sont stockées dans des dépots Gitlab, dont chaque nouveau commit fera l’objet d’un démarrage de tâche sur chaque agent Puppet.

Le Labo #13 2/2 | Provisionning d'infrastructure à l'aide de Terraform

Provisionning d’infrastructure à l’aide de Terraform - 2eme partie Petite introduction J’avais déjà effectué un premier essai avec Terraform, sur mon compte Digital Ocean, dans le but de déployer un dizaine de serveurs…sans aller très loin. C’est à dire utiliser un outil de Configuration Management tel que Puppet, Ansible, Chef ou n’importe quel autre Provisionner évoqué dans la documentation officielle pour déployer des paquets de manière totalement automatisée. Dans cet article, il sera question d’Ansible.

Le Labo #13 1/2 | Provisionning d'infrastructure à l'aide de Terraform

Provisionning d’infrastructure à l’aide de Terraform - 1ère partie Petite introduction Il y a plusieurs mois, j’avais fais un tour d’horizon de Terraform mais je n’avais jamais rien tenté dans ce sens là…tout simplement parce que ce n’est pas compatible avec l’infrastructure Cloud de mon ancien employeur : ArubaCloud. Entre temps, je me suis ouvert plusieurs comptes chez plusieurs Cloud Providers pour étudier leur API et développer un script (en Python)effectuant plus ou moins le même travail que Terraform.

Le Labo #12 2/2 | Docker Trusted Registry

Docker Trusted Registry De quoi avons nous besoin ? Afin de faire fonctionner un Docker Registry aux côté d’un serveur LDAP, les éléments suivants seront nécessaires : Un serveur LDAP (biensûr), l’UCP (Universal Control Plane), Le Docker Trusted Registry L’installation et la configuration du serveur LDAP a été décrite dans l’article précédent. Dans celui-ci, nous nous concentrerons uniquement sur l’installation et la configuration de l’UCP et du Docker Trusted Registry. The Docker Registry Comment l’installer ?

Le Labo #12 1/2 | Docker Trusted Registry #1 - Le serveur LDAP

Le serveur OPENLDAP Qu’est-ce qu’un serveur LDAP ? A la base, LDAP (Lightweight Directory Access Protocol) est un protocole. Cependant, il a évolué pour représenter une norme pour les systèmes d’annuaires, incluant un modèle de données, un modèle de nommage, un modèle fonctionnel basé sur le protocole LDAP, un modèle de sécurité et un modèle de réplication Si vous souhaitez tout savoir sur sur le protocole LDAP, je vous suggère la page Wikipedia correspondante.

Le Labo #11 | Gitlab - Intégration Continue

Qu’est ce que Gitlab ? Au départ, Gitlab est une simple plateforme de versionning, tout comme peut l’être BitBucket, Github ou bien Git. Il permet : de gérer des dépôts Git ainsi que les utilisateurs et leurs droits d’accès aux dépôts l’authentification peut utiliser deux facteurs et la connexion à un annuaire LDAP4 de gérer l’accès par branche à un dépôt4 d’effectuer des examens de code et renforcer la collaboration avec les demandes de fusion que chaque projet puisse avoir un outil de ticket et un wiki.

Powershell vs Python | Parser du JSON

Je me suis lancé sur Powershell il y a un peu moins de 3 ans pour un projet en rapport avec du provisionning d’instances Cloud avec l’API d’ArubaCloud…et par la suite, je me suis demandé si il n’était pas possible de faire de même avec d’autres API…tel que celle de DigitalOcean, par exemple. Mais dans le même laps de temps, j’ai joué un peu avec Python. Certes, Python et Powershell sont complètement différents.

Powershell #6 | Intéractions avec VirtualBox

Powershell…c’est bon, mangez-en ! Concernant Powershell, je ne suis plus vraiment un novice en la matière…je vous invite à consulter mon Github et découvrir mon projet actuel. Mais, je n’avais pas encoré tenté d’intéragir avec VirtualBox. J’ai trouvé quelques commandes qui peuvent être utiles, sans passer par vboxmanage (sinon, c’est presque de la triche). On commence par démarrer VirtualBox avec la commande suivante : $vbox = New-Object -ComObject “VirtualBox.virtualBox” Pour lister les VM existantes : $vbox.Machines Cette commande va lister toutes les VM, qu’elles soient allumées ou non.

Le Labo #10 | Rkt - Installation et premier conteneur

Qu’est-ce que Rkt ? Ca, c’est la très très bonne question. Rkt, ou Rocket, est un système de conteneur proche de Docker développé par l’équipe derrière CoreOS. La création d’un conteneur Rkt peut se faire à l’aide des images disponible sur Docker Hub ou à l’aide des images propres à Rkt. Rkt peut s’installer partout, il suffit juste de télécharger l’archive et de la décompresser. Par contre, et c’est là que ça devient intéressant, Rkt semble être plus sécurisé que Docker par un principe d’isolation plus poussé et de séparation des privilèges entre les utilisateurs de l’hôtes et de ceux des conteneurs.

Powershell #5 - Silent Download and Install

Suite de la série d’articles sur Powershell publiés la semaine dernière (et parce que, à la base, je suis un Windowsien), voici un petit trick bien utile pour ceux qui veulent télécharger un fichier exécutable sans avoir à ouvrir de navigateur…en gros : pour faire comme nos amis linuxiens en ligne de commande. Par contre, il faut connaître l’URL de la ressource, sinon ça ne sert à rien (Captain Obvious…) Il nous faudra, tout d’abord, le script suivant à intégrer dans le vôtre (Ce n’est pas le mien, je l’ai juste trouvé sur le web et je le trouve bien pratique) : function Install-MSIFile { [CmdletBinding()] Param( [parameter(mandatory=$true,ValueFromPipeline=$true,ValueFromPipelinebyPropertyName=$true)][ValidateNotNullorEmpty()][string]$msiFile, [parameter()][ValidateNotNullorEmpty()][string]$targetDir ) if (!(Test-Path $msiFile)){ throw "Path to the MSI File $($msiFile) is invalid.

Powershell #1

Les variables Une variable est un objet permettant de stocker des données. Une variable peut tout aussi bien contenir des données textes, chiffres, xml, tableau, etc. Une variable commence toujours par le signe “$”. les types de données Types Description [int] Chiffre (32 bits) [long] Chiffre (64 bits) [string] Texte [char] Caractère signé [8 bits] [byte] Caractère non-signé (8 bits) [bool] Booléen (oui/non) [decimal] Valeur décimale (128 bits) [single] Nombre

Powershell #2

Les commandes Les commandes sont composées de deux éléments : le verbe et le nom Exemple : Get-Service Pour obtenir la liste des commandes disponible pour Powershell, tapez “Get-Command” et la liste de toutes les commandes, incluant les alias s’affichera. Chaque commandes dispose de paramètres obligatoires ou non, ceux permettant d’expliciter le resultat recherché à l’aide de la commande, par exemple : Get-Command -name “ssh“ Les commandes suivantes seront très

Powershell #3

Les fichiers XML Il est important de savoir que Powershell peut générer à la volée du fichier XML et traiter ces mêmes fichiers très facilement en utilisant le type de fichier XML. La génération de fichier XML Pour générer un fichier XML, il faut entrer une série de commandes permettant de définir le nom du fichier, de créer le document, d’écrire dans le document les informations nécessaires et, enfin, de le clôturer : Définir le nom du fichier $filePath = "c:\command.xml" Créer le document New-Object System.XMl.XmlTextWriter($filePath,$Null) Ecrire dans le document $xmlWriter.WriteRaw (Cette commande permet de créer du contenu totalement personnalisé comme du XML SOAP) Finaliser le document $xmlWriter.Finalize $xmlWriter.Close() Par exemple : $filePath = "c:\command.xml" $XmlWriter = New-Object System.XMl.XmlTextWriter($filePath,$Null) $xmlWriter.WriteRaw("$XMLheader") $XmlWriter.WriteRaw("$XMLBody") $XmlWriter.WriteRaw("</soapenv:Envelope>") $xmlWriter.Finalize $xmlWriter.Close() Dans cet exemple, deux variables contenant le header et le body du fichier xml, cela permet de n’avoir qu’un seul fichier “command.xml” à créer et, donc, avoir une plus grand flxibilité et un code un peu plus léger que si le fichier xml devait être généré a chaque fois que c’était nécessaire.

Powershell #4

Les boucles Ces blocs de codes sont destinés à réaliser plusieurs itérations d’un même ensemble d’instructions. Ils ont toutefois besoin d’une directive stipulant les conditions de sortie, sous peine d’écrire une boucle sans fin. La boucle for est une instruction relativement basique et rarement utilisée en raison de son caractère arbitraire. Sa structure est la suivante : for ( valeur de départ ; test ou condition ; incrément / nombre d’itération } par exemple, le code suivant affiche les chiffres de 1 à 5 : for ($i=1; $i -le 5; $i++) {Write-Host $i} Obtenez plus d’informations via : help about_for La boucle foreach est une instruction très fréquemment utilisée en langage Powershell.

Le Labo #9 | Déploiement automatisé et surveillance de microservices

Introduction Dans de précédents articles, nous avions abordé les technologies suivantes : Docker Weave Consul Ansible Ces technologies permettent de créer des micro-services et de surveiller leur bon fonctionnement. Ceci s’inscit dans une démarche ‘DevOps’, lorsque du code permet, comme nous allons le démontrer, de créer toute une infrastructure fonctionnelle. Nous allons effectuer les tâches suivantes : Description des conteneurs à déployer dans un fichier utilisable par docker-compose, Déploiement d’un réseau pour conteneurs Docker à l’aide de Weave, Déploiement des conteneurs puis installation des paquets automatisée à l’aide d’Ansible, Découverte et surveillance des services à l’aide de Consul Avant d’aller plus loin… Nous allons avoir besoin des éléments suivants : 1 serveurs : mida-dockh1 - Ubuntu - (IP : 81.2.243.226) Docker-Compose, Weave, Consul et Ansible installés sur le serveur mida-dockh1 Docker - Préparation et déploiement L’image docker Dans cet exercice, nous allons utiliser l’image docker rastasheep/ubuntu-ssh:14.04.

Le Labo #8 | Ajout d'une fonction de Service discovery au cluster Serf

Introduction Dans de précédents documents, nous avions abordé Serf, un outil de clustering, ainsi que Consul, un outil de Service Discovery. Dans ce document, nous allons observer l’ajout des fonctionnalités de Consul à l’environnement dans lequel Serf est fonctionnel, dans un environnement hétérogène composé de trois serveurs sur lesquels sont installés deux systèmes d’exploitation différents : Windows et Linux. Avant d’aller plus loin… Nous allons avoir besoin des éléments suivants : 3 serveurs : mida-dockh1 - Ubuntu - (IP : 81.2.243.226), mida-dockh2 - Ubuntu - (IP : 81.2.244.156) et mida-dockh3 - Windows - (IP : 81.2.245.130) Serf installé sur chaque serveurs Consul installé sur chaque serveurs Installation de Consul Sur Linux : Télécharger l’archive : wget https://releases.hashicorp.com/consul/0.6.0/consul_0.6.0_linux_amd64.zip Décompresser l’archive : unzip consul_0.6.0_linux_amd64.zip -d /usr/local/bin/consul Déclarer le chemin de Consul : echo "PATH=$PATH:/usr/local/bin/consul" >> .bashrc && exec bash Vérifier l’installation : consul Sur Windows : Télécharger l’archive : https://releases.hashicorp.com/consul/0.6.0/consul_0.6.0_windows_amd64.zip Puis Décompresser l’archive Démarrer Consul Sur mida-dockh1 Nous allons démarrer le serveur Consul Serf sur mida-dockh1 à l’aide des commandes suivantes : Générer la clé de cryptage : consul keygen créer le dossier de configuration de Consul : mkdir consul Démarrer le serveur Consul en mode bootstrap : consul agent -server -advertise=81.2.243.226 -bootstrap -data-dir=consul -dc=dc3 -encrypt=[clé] Le terminal affichera ce qui suit : ==> WARNING: Bootstrap mode enabled!

Le Labo #7 | Création d'un cluster à l'aide de Serf

Introduction Dans un précédent document, nous avions abordé Serf, un outil décentralisé de Service Discovery et d’orchestration. Dans ce document, nous allons observer le fonctionnement de Serf dans un environnement hétérogène composé de trois serveurs sur lesquels sont installés deux systèmes d’exploitation différents : Windows et Linux. Avant d’aller plus loin… Nous allons avoir besoin des éléments suivants : 3 serveurs : mida-dockh1 - Ubuntu - (IP : 81.2.243.226), mida-dockh2 - Ubuntu - (IP : 81.2.244.156) et mida-dockh3 - Windows - (IP : 81.2.245.130) Serf installé sur chaque serveurs Installation de Serf Sur Linux : Télécharger l’archive : wget https://releases.hashicorp.com/serf/0.6.4/serf_0.6.4_linux_amd64.zip Installer Unzip : apt-get install -y unzip Décompresser l’archive : unzip serf_0.6.4_linux_amd64.zip -d /usr/local/bin/serf Déclarer le chemin de Serf : echo "PATH=$PATH:/usr/local/bin/serf" >> .bashrc && exec bash Vérifier l’installation : serf Sur Windows : Télécharger l’archive : https://releases.hashicorp.com/serf/0.6.4/serf_0.6.4_windows_amd64.zip Puis Décompresser l’archive Créer le cluster Serf Démarrage de Serf sur mida-dockh1 Nous allons démarrer le premier noeud Serf sur mida-dockh1 à l’aide de la commande suivante : serf agent -node=**mida-dockh1** -bind=81.2.243.226:7496 -profile=wan & Le terminal affichera ce qui suit : ==> Starting Serf agent...

Terraform - présentation et Installation

Qu’est-ce que Terraform ? Terraform est un outil pour la construction, la modification et le versioning infrastructure. Grâce aux fichiers de configuration, Terraform génère un plan d’exécution décrivant les tâches à effectuer pour atteindre l’état désiré, puis exécute le tout pour construire l’infrastructure décrite. Comment l’installer ? Pour l’installer, il suffit de taper les commandes suivantes : Télécharger l’archive : wget https://releases.hashicorp.com/terraform/0.6.8/terraform_0.6.8_linux_amd64.zip Décompresser l’archive : unzip terraform_0.6.8_linux_amd64.zip -d /usr/local/bin/terraform Déclarer le chemin de Terraform : echo "PATH=$PATH:/usr/local/bin/terraform" >> .bashrc && exec bash Vérifier l’installation : terraform Les commandes de Terraform Terraform Dispose des commandes suivantes : apply : Démarre la construction ou la modification de l’infrastructure terraform apply [OPTIONS] [dir-or-plan] -backup=[path] | -input=true | -no-color | -parallelism=n | -refresh=true | -state=[path] | -state-out=[path] | var [variables] | -var-file= | -target=[resource] destroy : Détruit l’infrastructure éxistante terraform destroy [OPTIONS] [DIR] -force | -target get : Télécharge et installe les modules nécessaires terraform get [OPTIONS] [DIR] -update graph : Crée un graphique visuel des ressources terraform graph [OPTIONS] [DIR] -draw-cycles | -module-depth=n | -verbose terraform peut générer des images à l’aide de la commande suivante : `terraform graph | dot -Tpng > [nom_du_fichier].png init : Initialise la configuration Terraform depuis un module terraform init [OPTIONS] source [DIR] -backend= : Sépcifie le type de backend parmi Atlas (par défaut), Consul, S3 ou HTTP.

Consul - présentation et Installation

Qu’est-ce que Consul ? Consul est un outil de découverte de service, distribué et hautement disponible. C’est également un datastore de type clé/valeur permettant le stockage d’élément de configuration, ainsi qu’un système de supervision de service. Tout comme Serf, Consul s’installe sous la forme d’un agent. Cet agent est chargé d’enregistrer les services, de répondre aux requêtes, de collecter des informations du cluster, etc… S’exécutant sur chaque noeud du cluster, il peut fonctionner en mode client ou serveur.

Serf - Présentation et Installation

Qu’est-ce que Serf ? Serf est un outil de création de cluster comprenant également des fonctionnalités de haute disponibilité et de détection de pannes. Serf Utilise le protocole de gossip, celui-ci permet la communication entre machine inspiré par la forme de bavardage dans les réseaux sociaux, tels que Twitter ou Facebook, car cela rend la résolution de de problème plus rapide et plus efficace. Comment l’installer ? Pour l’installer, il suffit de taper les commandes suivantes : Télécharger l’archive : wget https://releases.hashicorp.com/serf/0.6.4/serf_0.6.4_linux_amd64.zip Décompresser l’archive : unzip serf_0.6.4_linux_amd64.zip -d /usr/local/bin/serf Déclarer le chemin de Serf : echo "PATH=$PATH:/usr/local/bin/serf" >> .bashrc && exec bash Vérifier l’installation : serf Les commandes de Serf Serf Dispose des commandes suivantes, chacune de ces commandes disposent des options rpc-addr et rpc-auth, celles ci ne sont pas obligatoires : agent : Démarre l’agent Serf -bind : L’adresse sur laquelle Serf va utiliser pour communiquer avec les autres agents.

Le Labo #6 | Packer, Docker et Go

Introduction Dans le précédent document, nous avions effectué une rapide présentation des fonctionnalités de Packer et des différentes clés nécessaires à la création de templates. Dans celui-ci, nous allons observer comment faire fonctionner Packer, Go et Docker ensemble. Le “Builder” Docker Le driver Docker de Packer permet de créer des images et conteneurs Docker sans utiliser de Dockerfile. De cette façon, Packer peut provisioner des conteneurs à l’aide scripts ou de systèmes de gestion de configurations (tels que Chef ou Ansible) de la même manière qu’un serveur physique.

Packer - Présentation et Installation

Qu’est que Packer ? Packer est Open-Source. C’est un outil de création de création d’images ou de conteneurs identiques à partir d’un fichier de configuration unique. Il est pricnipalement utilisé pour automatiser la création d’images disposant d’un système d’exploitation et de logiciels particuliers en encourageant l’utilisation de framework tels que Puppet, Chef ou Ansible et peut être utilisé sur différentes plateforme, telles que Vagrant ou Docker. Comment l’installer ? Pour l’installer, il suffit de taper les commandes suivantes : Télécharger l’archive : wget https://releases.hashicorp.com/packer/0.8.6/packer_0.8.6_linux_amd64.zip Décompresser l’archive : unzip packer_0.8.6_linux_amd64.zip -d /usr/local/bin/packer Déclarer le chemin de Packer : echo "PATH=$PATH:/usr/local/bin/packer" >> .bashrc && exec bash Vérifier l’installation : packer Les commandes de Packer Packer est un outil en ligne de commande.

Le Labo #5 | Mon Blog, avec Docker, Go et Hugo

Pourquoi ? Ca ne paraît pas comme ça, mais ce blog est en fait un conteneur Docker. Wordpress me semblait beaucoup trop, je n’avais pas besoin d’une usine à gaz pour un simple blog, il me fallait quelque chose de plus simple et réactif. Pour cela, j’ai trouvé Hugo. Hugo est tout simple, une commande pour créer le site, une autre pour démarrer le serveur, pas besoin d’installer Apache, Nginx ou cherokee…pas besoin non plus d’une base de données…juste des pages à ajouter dans un dossier et elles s’affichent dans le navigateur.

Vagrant - Présentation et Installation

1 - Qu’est-ce que Vagrant ? Vagrant est un logiciel libre et open-source pour la création et la configuration des environnements de développement virtuel. A l’origine lié à VirtualBox, il est maintenant compatible avec d’autres environnements de virtualisation tels que VMware, Amazon EC2 et Docker. De plus, il est écrit en Ruby mais compatible avec de nombreux langages tels que PHP, Python, Java, etc… 2 - Comment l’installer ? Vagrant peut être installé de deux façons différentes : via les sources disponibles sur le site de Vagrant >Pour installer via les sources, soyez certains que les deux paquets suivants sont déjà installés : dpkg-dev virtualbox-dkms Ensuite, téléchargez le paquet “deb” ou “rpm” depuis le site officiel : wget https://dl.bintray.com/mitchellh/vagrant/vagrant_[version].[extension .deb ou .rpm] Ensuite, installez le paquet avec la commande suivante : Debian/Ubuntu : dpkg -i vagrant[version].deb CentOS : rpm -iv vagrant[version].rpm Via RubyGems gem install vagrant 3 - Comment l’utiliser ?

Hashicorp | Présentation de l'écosystème

Qu’est-ce que l’écosystème d’Hashicorp ? L’écosystème d’Hashicorp se compose des applications suivantes : Vagrant : Virtualisation Packer : Automatisation de création d’image Serf : Clustering Consul : Service Discovery Terraform : Outil de construction, de modification et de versioning d’infrastructure. Vault : Gestion de clé/mot de passe/certificats Comment installer chaque outils ? Vagrant Ensuite, téléchargez le paquet “deb” ou “rpm” depuis le site officiel : wget https://dl.bintray.com/mitchellh/vagrant/vagrant_[version].[extension .deb ou .rpm]

Le Labo #4 | Déploiement de conteneurs Docker automatisé sur plusieurs hôtes

1 - Introduction Dans un précédent tutoriel, nous avions abordé la création d’un cluster sur deux niveaux à l’aide de deux hôtes, ainsi que Swarm pour relier les hôtes, Weave pour la partie réseau entre les conteneurs et Zookeeper pour la gestion du cluster de conteneurs. Dans celui ci, nous aborderons le déploiement automatisé de conteneurs Docker sur plusieurs hôtes à l’aide de Docker, Weave, Swarm et Ansible. 2 - Avant d’aller plus loin… Nous allons avoir besoin des éléments suivants : 3 serveurs linux (CentOS/Ubuntu) 64bits : mida-clm1 (IP 81.2.240.198), mida-clm2 (IP 81.2.248.101) et mida-cls1 (IP 80.10.243.100) Ansible : Automatisation de configuration Docker : Gestion de conteneur Docker Compose: Orchestration de déploiement de conteneurs Swarm : Gestion de cluster de l’écosystème Docker Weave : Gestion du réseau Docker Weave Scope : Mappage, détection et surveillance de conteneurs Docker 3 - Installation des outils nécessaires Afin d’installer les outils nécessaires à ce cas pratique, nous allons lancer les commandes suivantes sur mida-dockh1 : Installation de Ansible : apt-get install software-properties-common -y add-apt-repository ppa:ansible/ansible apt-get update -y apt-get install ansible phyton-pip -y pip install paramiko PyYAML Jinja2 httplib2 six Puis les commandes suivantes sur chaque hôtes : Installation de Docker (sur les 3 hôtes) : curl -sSL https://get.docker.com/ | sh Installation de docker Swarm (sur les 3 hôtes) : docker pull swarm:latest Installation de Weave (sur les 3 hôtes) : curl -L git.io/weave -o /usr/local/bin/weave chmod a+x /usr/local/bin/weave Installation de Weave Scope (sur les 3 hôtes) : wget -O scope git.io/scope && cp scope /usr/local/bin/ chmod a+x /usr/local/bin/scope 4 - Configuration des outils Génération de clé ssh et copie de la clé sur les noeuds esclaves ssh-keygen -t rsa ssh-copy-id -i ~/.ssh/id_rsa.pub root@mida-clm2 && ssh-copy-id -i ~/.ssh/id_rsa.pub root@mida-cls1 Pour connexion ssh sans mot de passe sur le noeud maître : cat ~/.ssh/id_rsa.pub » ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys Configuration d’Ansible Nous allons commencer par ajouter les hôtes dans le fichier /etc/ansible/hosts : mida-clm1 mida-clm2 mida-cls1 Ansi que dans le fichier /etc/hosts : 81.2.240.198 mida-clm1 81.2.248.101 mida-clm2 80.10.243.100 mida-cls1 Configuration de Docker Afin de pouvoir monter notre cluster Swarm et Weave, nous allons devoir le port d’écoute 2375 sur les trois serveurs à l’aide de la ligne suivant dans le fichier /etc/default/docker : DOCKER_OPTS="-H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock" Configuration de Swarm Generer le token : docker run swarm create Démarrer Swarm Manager : docker run swarm manage -H tcp://81.2.240.198:2375 token://eff2e1fb0660f82dd4d69ca639d514ca Ajout des serveurs au cluster Swarm : Sur mida-clm1 : docker run swarm join --addr=81.2.240.198:2375 token://eff2e1fb0660f82dd4d69ca639d514ca Sur mida-clm2 : docker run swarm join --addr=81.2.248.101:2375 token://eff2e1fb0660f82dd4d69ca639d514ca Sur mida-cls1 : docker run swarm join --addr=80.10.240.100:2375 token://eff2e1fb0660f82dd4d69ca639d514ca Configuration de Weave Scope Pour celui-ci, nous avons juste besoin de le démarrer, sur les trois hôtes, à l’aide de la commande suivante : scope launch scope1:4030 mida-clm1:4030 mida-clm2:4030 mida-clms1:4030 Une fois démarré, le terminal affichera le message suivant : Weave Scope is reachable at the following URL(s): * http://[adresse IP de l'hôte]:4040 Configuration de Weave Net Nous allons démarrer Weave sur chaque hôtes à l’aide de la commande suivante : Sur mida-clm1 : weave launch --init-peer-count 3 puis weave connect mida-clm2 et enfin weave connect mida-cls1 Sur mida-clm2 : weave launch --init-peer-count 3 Sur mida-cls1 : weave launch --init-peer-count 3 A l’aide de la commande weave status connections nous pourrons vérifier que chaque hôtes est bien lié.

Le Labo #3 | Cluster Zookeeper Dockerisé

1 - Introduction Dans un précédent tutoriel, nous avions abordé la création d’un cluster Hadoop multinode réalisé à l’aide de deux conteneurs Docker utilisant les fonctionnalités de Weave pour la partie réseau. Dans ce tutoriel, nous allons créer un cluster Zookeeper à l’aide de plusieurs conteneurs Docker, le tout orchestré par Swarm. 2 - Avant d’aller plus loin… Nous allons avoir besoin des éléments suivants : 2 serveurs linux (CentOS/Ubuntu) 64bits : mida-clm1 (IP 81.2.240.198) et mida-clm2 (IP 81.2.248.101) Docker : Gestion de conteneur Swarm : Gestion de cluster de conteneurs Docker Weave : Gestion du réseau Docker Zookeeper : Gestionnaire de cluster de l’écosystème Hadoop/Mesos 3 - Configuration des deux serveurs hôtes Installation des outils nécessaires sur les deux serveurs Installation de Docker Dans le premier document relatif à Docker, nous avions observé l’installation de ce logiciel.

Le Labo #2 | Cluster Hadoop multinodes Dockerisé

1 - Introduction Après avoir présenté les fonctionnalités de Docker et Weave, nous allons vous présenter un cas pratique de création de Cluster Hadoop dockerisé. 2 - Avant d’aller plus loin… Avant toutes choses, nous avons besoin d’un serveur linux 64bits (CentOS ou Ubuntu), à jour (Kernel 3.8 iédalement). 3 - Configuration de la machine hôte Installation des outils nécessaires Installation et configuration de Docker Dans le premier document relatif à Docker, nous avions observé l’installation de ce logiciel.

Hbase - Installation de type 'Fully Distributed'

1 - Qu’est-ce que HBase ? HBase est un système de gestion de base de données non-relationnelles distribué, écrit en Java, disposant d’un stockage structuré pour les grandes tables. HBase est un sous-projet d’Hadoop, un framework d’architecture distribuée. La base de données HBase s’installe généralement sur le système de fichiers HDFS d’Hadoop pour faciliter la distribution. Cet article fait suite à celui traitant d’un cluster Hadoop en mode “Haute Disponibilité et à Basculement Automatique”, il reprend les mêmes éléments, à savoir Zookeeper, Java et Hadoop.

Hadoop - Cluster | High Availability & Auto Failover

1 - Qu’est-ce que Hadoop ? Hadoop est un framework destiné à faciliter la création d’applications distribuées et échelonnables permettant aux applications de travailler avec de nombreux noeuds et des données de grandes tailles. Dans le premier document, nous avions étudié un cas de cluster Hadoop ne comprenant que deux noeuds, un maître et un esclave. Dans celui-ci, nous allons nous concentrer sur un cluster disposant des fonctions “Haute disponibilité” et “Basculement de charge automatique”, grâce à l’utilisation de zookeeper.

Hadoop - Cluster | High Availability & Manual Failover

1 - Qu’est-ce que Hadoop ? Hadoop est un framework destiné à faciliter la création d’applications distribuées et échelonnables permettant aux applications de travailler avec de nombreux noeuds et des données de grandes tailles. Dans le précédent document, nous avions étudié un cas de cluster Hadoop ne comprenant que deux noeuds, un maître et un esclave. Dans celui-ci, nous allons nous pencher sur un cluster disposant de plusieurs noeux maîtres. 2 - Contexte initial Nous avons déployé les serveurs suivants, installé Java et Hadoop sur chacun d’eux : - mida-clmaster1 : 192.168.1.1 - CentOS 7 - mida-clslave1 : 192.168.1.50 - CentOS 7 3 - Situation finale Hadoop sera installé de la manière suivante : Les noeuds maîtres disposeront des rôles suivants : Namenode, Secondary Namenode, Resource Manager Le noeud esclave disposera des rôles suivants : Datanode Node Manager 4 - Comment installer et configurer Hadoop dans cet environnement.

Hadoop - Cluster multinode

1 - Qu’est-ce que Hadoop ? Hadoop est un framework destiné à faciliter la création d’applications distribuées et échelonnables permettant aux applications de travailler avec de nombreux noeuds et des données de grandes tailles. 2 - Contexte initial Nous avons déployé les serveurs suivants : - clmaster1 : 192.168.1.1 - CentOS 7 - clslave1 : 192.168.1.50 - CentOS 7 3 - Situation finale Hadoop sera installé de la manière suivante : Le noeud maître disposera des rôles suivants : Namenode, Secondary Namenode, Resource Manager Le noeud esclave disposera du rôle suivant : Datanode Node Manager 4 - Comment installer Hadoop dans cet environnement ?

Le Labo #1 | Déploiement automatique de paquets dans un conteneur

1 - Introduction Dans de précédents documents, nous avons abordé les thématiques Ansible et Docker en détail, en exposant chaque éléments indispensable à leur utilisation. Dans ce document, nous allons déployer des conteneurs à l’aide de Ansible. 2 - Avant d’aller plus loin Durant ce cas pratique, nous aurons à disposition les éléments suivants deux serveurs linux de distributions différentes organisées ainsi : - Un serveur Ansible - Un serveur Docker, 1 conteneur 3 - Déroulement du cas pratique Création de la clé SSH Dans notre cas, il faudra copier la clé publique sur le serveur docker ainsi que sur le (ou les) conteneur(s) à l’aide des commandes suivantes : ssh-keygen : Pour créer la clé publique ssh-copy-id -i /root/.ssh/[nom du fichier].pub [utilisateur]@[alias du serveur] : Pour copier la clé publique sur le serveur Docker Déployer le conteneur Nous allons déployer un conteneur dans lequel il n’y aura que SSH d’installé, prenons par exemple rastasheep/ubuntu-sshd et lançons la commande suivante : docker run -d -P -p 80:50000 --name [Nom du conteneur] rastasheep/ubuntu-sshd:14.04 -v /root/.ssh/[nom du ficher].pub Pour connaître le port ssh utilisé par ce conteneur, tapez la commande suivante : docker port [nom du conteneur] 22 le fichier d’inventaire d’ansible Ce fichier sert d’inventaire des ressources sur lesquelles Ansible peut déployer les paquets logiciels spécifiés dans les playbooks.

A propos..de moi

Experience From Nov 2020 | SQUAD | Nantes DevOps Cloud Architect and Consultant Manager Orange | From Dec 2023 - Technical architecture documentation for projects Naval Group | Feb 2023 | July 2023 - Terraform : Modules (VMware Vsphere, Cisco IOSXE, Netbox) code base and Private Registry - Packer : OS-Factory and Private Registry - Packer : Packer Environment Tool : An utility to change on the fly the version of Packer installed on any server - Gitlab-CI : Code review and evolution for the Continuous Delivery an Continuous Intergration pipelines - Technical documentation Nickel Bank | July 2021 | Dec 2022 - Terraform : Code Review and evolution - Observability : Thanos / Grafana stack / Prometheus / Logstash - SQL Delivery : Liquibase / ArgoCD - Apigee-X : PoC with IaC deployment - Technical documentation GIE IRIS - Systeme U | Dec 2020 - June 2021 - Vault : PoC, documentation and acculturation - Terraform : Code Review and evolution - Kubernetes/Rancher : Application deployment - Observability May 2020 - Nov 2020 | Sfeir | Nantes Cloud Architect Internal: - Terraform, Ansible and Kubernetes trainer - DevOps for internal projects : Jarvis - Internal Chatbot for room booking Oct 2019 - May 2020 | Ippon | Paris Cloud System Engineer Engie Digital - Cloud Deployment Automation on AWS Platform (Terraform, Packer, Jenkins) - Terraform Workshop and toolkit creation/migration - Scrum Method - Technical documentation and Demos Jan 2018 - Oct 2019 | Uniware | Neuilly-sur-Seine Infrastructure System Engineer Carrefour Working on digital transformation for Carrefour on many critical projects.

Mesos - Installation et configuration

Mesos - installation et configuration 1 - Qu’est-ce que Mesos ? Apache Mesos est un outil Open Source de gestion de cluster. Il permet de mettre les ressources en commun tout en isolant les applications/framework à l’aide d’API de gestion de ressources et de planification. Les applications/framework possibles sont les suivants : Marathon, Chronos, Hadoop, Spark, etc… 2 - Comment l’installer ? Il est possible de l’installer depuis les sources disponible sur le site du projet ou depuis les dépots des distrubtions linux.

Docker - les outils Compose et Swarm

1 - Introduction Docker est un logiciel Open Source permettant de gérer des conteneurs. Contrairement à la virtualisation classique comprenant un système hôte sur lequel il est possible d’installer tout ce qui le serait sur un système classique, les conteneurs contiennent au maximum, que les applications/bibliothèques. Dans le premier tutoriel, nous avions abordé uniquement l’installation de Docker sur les systèmes Linux et Windows. Dans le suivant, nous nous sommes concentrés sur les commandes de base de Docker.

Docker - Les Dockerfiles

1 - Introduction Docker est un logiciel Open Source permettant de gérer des conteneurs. Contrairement à la virtualisation classique comprenant un système hôte sur lequel il est possible d’installer tout ce qui le serait sur un système classique, les conteneurs contiennent au maximum, que les applications/bibliothèques. Dans le premier tutoriel, nous avions abordé uniquement l’installation de Docker sur les systèmes Linux et Windows. Dans le suivant, nous nous sommes concentrés sur les commandes de base de Docker.

Docker - Gestion du réseau avec Weave

1 - Qu’est ce que Weave ? Weave est un logiciel composé de trois fonctions optimisées pour la visualisation et la communication des application créées à l’aide de Docker. Grâce à des outils et protocoles connus, weave fourni une topologie réseau réseau permettant aux applications conteneurisées de communiquer entre elles de manière rapide et efficace. 2 - Avant d’aller plus loin… Avant d’installer Weave, vous devrez installer un serveur doté des caractéristiques suivantes : Kernel Linux 3.8 (au minimum) Docker 1.3.1 (au minimum) 3 - Comment l’installer ?

Docker - Les commandes de base

1 - Introduction Docker est un logiciel Open Source permettant de gérer des conteneurs. Contrairement à la virtualisation classique comprenant un système hôte sur lequel il est possible d’installer tout ce qui le serait sur un système classique, les conteneurs contiennent au maximum, que les applications/bibliothèques. Dans le précédent tutoriel, nous avions abordé uniquement l’installation de Docker sur les systèmes Linux et Windows. Dans celui-ci, nous allons nous concentrer sur les commandes de base de Docker.

Docker - Installation

1 - Qu’est ce Docker ? Docker est un logiciel Open Source permettant de gérer des conteneurs. Contrairement à la virtualisation classique comprenant un système hôte sur lequel il est possible d’installer tout ce qui le serait sur un système classique, les conteneurs contiennent au maximum, que les applications/bibliothèques. Un container s’appuie sur le système d’exploitation de l’hôte pour fonctionner. Il s’agit de simuler un ensemble applicatif au sein de l’OS de l’hôte, cela de façon isolée au sein d’un container.

Ansible - Les playbooks, notions avancées

1 - Qu’est-ce que Ansible ? Ansible est une plate-forme logicielle libre pour la configuration et la gestion des ordinateurs quicombine le déploiement de logiciels et services, l’exécution de tâches ad-hoc, et la gestion de configuration. De plus, Ansible ne nécessite pas d’installation de client sur les serveurs ciblés, la communication entre le serveur et les noeuds est rendue possible par connexion SSH sécurisée. Dans les précédents documents, nous avions abordé uniquement l’installation et la configuration d’Ansible ainsi que les notions de bases d’un playbook.

Ansible - Les playbooks, notions de base

1 - Qu’est-ce que Ansible ? Ansible est une plate-forme logicielle libre pour la configuration et la gestion des ordinateurs quicombine le déploiement de logiciels et services, l’exécution de tâches ad-hoc, et la gestion de configuration. De plus, Ansible ne nécessite pas d’installation de client sur les serveurs ciblés, la communication entre le serveur et les noeuds est rendue possible par connexion SSH sécurisée. Dans le précédent document, nous avions abordé uniquement l’installation et la configuration d’Ansible, dans celui-ci nous alons aborder les notions de bases d’un playbook.

Ansible - Installation et configuration

1 - Qu’est-ce que Ansible ? Ansible est une plate-forme logicielle libre pour la configuration et la gestion des ordinateurs qui combine le déploiement de logiciels et services, l’exécution de tâches ad-hoc, et la gestion de configuration. De plus, Ansible ne nécessite pas d’installation de client sur les serveurs ciblés, la communication entre le serveur et les noeuds est rendue possible par connexion SSH sécurisée. 2 - Comment l’installer ? Il y a trois manières d’installer Ansible sur votre système : Depuis les sources Via les dépôts à l’aide de l’outil “pip” 2.1 - Installation depuis les sources Pour commencer, il faut télécharger l’archive sur Git à l’aide de la commande suivante : git clone git://github.com/ansible/ansible.git --recursive Rendez-vous ensuite dans le dossier : cd ./ansible tapez ensuite la commande suivante : source ./hacking/env-setup (ajoutez l’option “-q” afin de supprimer les avertissements/erreurs qui pourraient survenir).