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.

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é ?

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.

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).

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).

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.

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.

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).

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).

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.

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.

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...

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.

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.

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.

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.