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.