TechAN sur TechAN
http://techan.fr/
fr-FRMrRaph_Copyright (c) 2016, TechAN; all rights reserved.Thu, 06 Sep 2018 19:18:39 UTCUn composant HomeAssistant pour suivre sa facture AWS
http://techan.fr/composant-homeassistant-pour-suivre-sa-facture-aws.html
Thu, 06 Sep 2018 19:18:39 UTCMrRaph_http://techan.fr/composant-homeassistant-pour-suivre-sa-facture-aws.html<p>HomeAssistant est un hub domotique logiciel Open Source. Il permet d’interfacer une très grande quantité d’appareils domotiques entre eux. Il peut également être interfacé avec un Google Home ou une enceinte Echo.</p>
<p>Un des avantages de cette plateforme est son ouverture, il suffit de savoir coder en Python et l’ajout de fonctionnalités supplémentaires devient un jeu d’enfant.</p>
<p>J’ai créé un composant tout bête qui permet de récupérer le montant de se facture AWS. La valeur est la somme depuis le premier jour du mois.</p>
<p><img src="http://techan.fr/images/2018/09/aws_bill.png" alt="Facture AWS" /></p>
<p>Le code de ce composant se trouve <a href="https://raw.githubusercontent.com/MrRaph/homeassistant/master/custom_components/sensor/awsbill.py">ici</a>.</p>
<p>Le script Python doit être placé dans l’arborescence <code>custom_components/sensor</code> situé au même niveau que le fichier <code>configuration.yaml</code>.</p>
<p>Une fois le script en place, il vous faudra ajouter les lignes suivantes dans votre configuration HomeAssistant.</p>
<pre><code>sensor:
- platform: awsbill
username: !secret accesskey
password: !secret secretkey
</code></pre>
<p>Ou <code>username</code> est votre ACCESS_KEY AWS et <code>password</code> est votre SECRET KEY AWS.</p>
Le VPN On-Demand iOS, votre préservatif numérique
http://techan.fr/le-vpn-on-demand-ios-votre-preservatif-numerique.html
Sun, 26 Nov 2017 12:18:39 UTCMrRaph_http://techan.fr/le-vpn-on-demand-ios-votre-preservatif-numerique.html
<p>La protection de la vie numérique se résument souvent pour beaucoup à mettre un code sur un appareil - ordinateur ou mobile - et ne va souvent pas bien plus loin.</p>
<p>On s’accroche à notre vie privée mais dans le même temps on se connecte aux réseaux wifi ouverts proposés dans les restaurants, les bars, les gares … Sans se douter une seconde que ces réseaux ouverts laissent les mains libres aux gens mal intentionnés pouvant intercepter les données que l’on reçoit ou que l’on envoie.</p>
<p>Dans le même esprit mais plus insoupçonné, les réseaux mobiles 3G ou 4G sont également des réseaux ouverts. Certes les attaques sur ces réseaux ne sont pas aussi aisées que sur des Wifi ouverts mais le risque existe. D’autre part, les données que vous consommez sur les réseaux mobiles transitent par des serveurs de votre opérateur.</p>
<p>Bref, la vie numérique est un peu comme la vraie vie, mieux vaut sortir couvert. Un des préservatifs numérique s’appelle un VPN (Virtual Private Network). Le VPN est un programme auquel un appareil informatique peut se connecter. Une fois cette connexion effectuée, l’appareil et le serveur VPN sont reliés par une espèce de tunnel informatique par lequel les données transiteront. Les données sont chiffrées dans tout le tunnel, elles ressortent ensuite à la fin du tunnel et continuent leur route sur Internet. Un peu comme le tunnel sous la manche qui évite les turbulences de la Manche. Le VPN permet de sécuriser les échanges sur des réseaux non sûrs.</p>
<p>Il est possible d’utiliser un VPN sur les appareils mobiles. Mais c’est souvent fastidieux, en effet souvent il faut que l’utilisateur pense à initier la connexion au VPN, il arrive qu’il se déconnecte…</p>
<p>Depuis la version 8, iOS supporte le VPN on Demand, il s’agit d’un mécanisme qui permet de spécifier des réseaux Wifi sûrs. iOS se chargera ensuite automatiquement de mettre ne place le VPN lorsque l’on est pas sur un réseau sûr ou de l’enlever lorsque l’on se connecte à un Wifi sûr - maison, travail, …</p>
<p>Il existe des applications qui font tout cela pour vous, et qui vous fournissent le serveur VPN nécessaire - comme l’excellent <a href="https://itunes.apple.com/fr/app/tunnelbear-vpn/id564842283?mt=8&at=1001lsQf">TunnelBear VPN - TunnelBear, Inc. (500 Mo de VPN gratuit par mois)</a>. Le revers de la médaille c’est qu’il faut passer à la caisse, souvent via un abonnement mensuel, pour bénificier de leurs services.</p>
<h2 id="pré-requis">Pré-requis</h2>
<p>Il y a quelques prérequis avant de se lancer dans le VPN à la demande.</p>
<p>Dans un premier temps, il faut un serveur OpenVPN fonctionnel. Ceci ne sera pas couvert dans cet article, mais son installation est assez simple avec Docker (voir <a href="http://techan.fr/protegez-votre-vie-privee-avec-openvpn-sur-docker.html">Protégez votre vie privée avec OpenVPN sur Docker</a>)</p>
<p>Il vous faudra une configuration cliente pour vous connecter à ce serveur OpenVPN, dans la suite de cet article, cette configuration sera nommée <code>config-client.ovpn</code>.</p>
<p>Il faudra que Ruby soit installé sur le poste que vous utiliserez pour la suite de ce guide et que la gem <code>ovpnmcgen.rb</code> soit installée. Pour installer cette gem, il suffit d’utiliser la commande suivante :</p>
<pre><code>gem install ovpnmcgen.rb
</code></pre>
<p>Il faudra également que l’application <a href="https://itunes.apple.com/fr/app/openvpn-connect/id590379981?mt=8&at=1001lsQf">OpenVPN Connect - OpenVPN Technologies (Gratuite)</a> soit installée sur votre appareil iOS afin qu’il puisse se connecter au serveur OpenVPN.</p>
<h2 id="modification-de-la-configuration-openvpn">Modification de la configuration OpenVPN</h2>
<p>Ouvrez le fichier votre fichier de configuration OpenVPN dans votre éditeur de texte préféré et vérifiez les points suivants.</p>
<p>Si votre configuration embarque les certificats, il faudra les sortir. Ces certificats sont englobés dans les balises suivantes dans la configuration OpenVPN :</p>
<ul>
<li><ca> : Sortez le contenu de cette balise dans un fichier nommé <code>ca.crt</code></li>
<li><key> : Sortez le contenu de cette balise dans un fichier nommé <code>cert.key</code></li>
<li><cert> : Sortez le contenu de cette balise dans un fichier nommé <code>cert.crt</code></li>
<li><tls-auth> : Sortez le contenu de cette balise dans un fichier nommé <code>tls.key</code></li>
</ul>
<p>Supprimez ensuite les blocs ``</p>
<p>Il se peut également que les certificats soient stockés en dehors de votre configuration, dans ce cas, vous n’avez rien de plus à faire que de bien repérer les noms des différents fichiers.</p>
<pre><code>client
nobind
dev tun
remote-cert-tls server
remote <vpn.example.net> 1194 udp
key-direction 1
redirect-gateway def1
</code></pre>
<h2 id="génération-du-certificat-p12">Génération du certificat .p12</h2>
<p>Afin de pouvoir utiliser les certificats dans une configuration à la demande, il faut les convertir dans le format .p12, c’est ce que nous allons faire avec la commande suivante.</p>
<p>Pensez bien à remplacer les <code><name></code> et <code><device></code> par vos informations, par exemple <code><moi></code> et <code><iphone></code>, ainsi que <code>vpn.example.net</code> par le nom d’hôte de votre serveur OpenVPN.</p>
<pre><code>openssl pkcs12 -export -out ./certificate.p12 \
-inkey cert.key -in cert.crt \
-passout pass:p12passphrase -name <name>-<device>@vpn.example.net
</code></pre>
<h2 id="génération-et-installation-d-un-profile-on-demand">Génération et installation d’un profile On Demand</h2>
<p>Pensez bien à remplacer les <code><name></code> et <code><device></code> par vos informations, par exemple <code><moi></code> et <code><iphone></code>, ainsi que <code>vpn.example.net</code> par le nom d’hôte de votre serveur OpenVPN.</p>
<pre><code>ovpnmcgen.rb gen -c .ovpnmcgen.rb.yml --ovpnconfigfile config-client.ovpn \
--security-level paranoid --cafile ./ca.crt --tafile ./tls.key \
--host vpn.example.net --p12file ./certificate.p12 --p12pass p12passphrase \
<name> <device> -o config-ondemand.mobileconfig
</code></pre>
<p>L’installation profile généré est très simple, envoyé le fichier <code>config-ondemand.mobileconfig</code> sur votre iPhone et ouvrez le. Suivez ensuite les instructions à l’écran en acceptant les avertissements et le tour sera joué.</p>
macOS, résoudre le problème des icônes d'application manquants
http://techan.fr/macos-resoudre-icones-dapplication-manquants.html
Sun, 01 Oct 2017 14:46:12 +0100MrRaph_http://techan.fr/macos-resoudre-icones-dapplication-manquants.html
<p>Parfois, il arrive que les icônes d’application disparaissent sur macOS, ce n’est pas très grave, mais cela peut vite devenir pénible. Il devient en effet vite compliqué d’identifier les applications lorsque l’on a des icônes toutes identiques comme ceci.</p>
<p><img src="http://techan.fr/images/2017/10/macos_bad_icon.png" alt="Icônes moches" /></p>
<p>On peut également constater des icônes manquantes dans le dossier Applications du Mac, la méthode de résolution sera identique.</p>
<h1 id="macos-résoudre-le-problème-des-icônes-d-application-manquants">macOS, résoudre le problème des icônes d’application manquants</h1>
<p>Il existe toute fois un moyen de résoudre ceci, via le Terminal. Il s’agit en fait d’un cache qui perd les pédalles. La commande que nous passerons dans le Terminal permet de le remettre d’aplomb.</p>
<p>Voici ladite commande :</p>
<pre><code>/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -seed
</code></pre>
<p>Si toute fois cette commande ne suffisait pas, il faut forcer un rechargement du Dock avec la commande suivante.</p>
<pre><code>killall Dock
</code></pre>
<p>Ceci devrait faire rentrer les choses dans l’ordre. Si une ou deux applications se montrent récalcitrantes après ces deux commandes, il suffira de le retirer et de le remettre dans le Dock.</p>
Quelques clefs de registres bien utiles ...
http://techan.fr/quelques-clefs-de-registre-bien-utiles.html
Sat, 03 Jun 2017 14:46:12 +0100MrRaph_http://techan.fr/quelques-clefs-de-registre-bien-utiles.html
<p>Dans le <a href="http://techan.fr/secourir-un-windows-sans-acces-a-sa-console">précédent article</a>, j’expliquait comme secourir un Windows pour lequel aucun accès classique n’est disponible. Dans cet article, je vais décrire quelques clefs de registre qui pourraient vous être bien utiles pour dépanner un serveur Windows via sa base de registre.</p>
<h1 id="désactiver-le-shutdown-event-tracker">Désactiver le “Shutdown Event Tracker”</h1>
<p>Le “Shutdown Event Tracker”, c’est cette délicieuse pop-up qui vous empêche d’arrêter ou de redémarrer votre serveur Windows en vous posant des questions sur la raison de cet arrêt. Cette fonctionalité peut devenir gênante si vous envoyez une de vos VMs telle qu’elle chez AWS par exemple. Vous ne pourrez pas alors éteindre votre Windows “proprement” car cette chose bloquera l’arrêt du système.</p>
<p><img src="http://techan.fr/images/2017/06/Windows_Shutdown_Event_Tracker.png" alt="La pop-up diabolique ..." /></p>
<p>Pour désactiver ceci, il faut ajouter la clef <code>HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Reliability</code> si elle n’existe pas déjà sur votre système. Ensuite, il faut créer un DWORD nommé <code>ShutdownReasonOn</code> et lui mettre la valeur <code>0</code>.</p>
<h1 id="paramètrer-une-interface-réseau-pour-utiliser-le-dhcp">Paramètrer une interface réseau pour utiliser le DHCP</h1>
<p>De la même façon, si vous n’arrivez pas à vous connecter à votre VM, c’est peut être que l’adresse IP qu’elle tente d’utiliser n’est pas - plus - correcte. Vous voudrez alors sans doute la mettre en DHCP pour qu’elle récupère une adresse IP correcte dans votre réseau. Il est également possible de faire cela via le registre, en positionnant les clefs suivantes.</p>
<p>Vous devrez faire cela pour chaque interface que vous voudrez mettre en DHCP, notez qu’il est assez aisé de les identifier car les IP fixes sont configurées dans des clefs voisines de celles que l’on va éditer.</p>
<p>Dans <code>regedit</code>, rendez-vous dans la clef <code>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\{Adapter}\Parameters\Tcpip</code>, cherchez la clef qui s’appelle <code>EnableDHCP</code>, ou créez la si elle n’existe pas, il s’agit d’un <code>DWORD</code>. La valeur <code>0</code> signifie que le DHCP est désactivé pour cette interface, la valeur <code>1</code> signifie au contraire qu’il est activé.</p>
<h1 id="activer-l-autologon-sur-windows">Activer l’AutoLogon sur Windows</h1>
<p>L’AutoLogon représente une faille de sécurité, mais ceci peut être nécessaire de manière temporaire pour réparer une machine. Je m’en suis servi pour installer un programme en utilisant le dossier “Start Up” de l’administrateur pour lequel j’avais configuré l’AutoLogon.</p>
<p>Une nouvelle fois, ouvrez <code>regedit</code>. Rendez-vous dans cette clef <code>HKLM\Software\Microsoft\Windows NT\CurrentVersion\winlogon</code> et cherchez la clef <code>AutoAdminLogon</code>. Si elle n’existe pas, créez la. Si la valeur de cette clef est <code>1</code>, la connexion automatique est activé, sinon si la valeur est <code>0</code>, elle est désactivée.</p>
<p>Il va falloir également positionner deux autres clefs pour que ceci fonctionne. Dans un premier temps, il faut ajouter la clef <code>DefaultUserName</code>, toujours sous <code>HKLM\Software\Microsoft\Windows NT\CurrentVersion\winlogon</code>, il s’agit d’une clef de type <code>String</code>, ça valeur sera le nom du compte qui va se connecter automatiquement. Ensuite, il faut ajouter une autre <code>String</code> nommé <code>DefaultPassword</code> qui elle aura pour valeur le mot de passe du compte sépcifié dans la clef <code>DefaultUserName</code>.</p>
<p>Si le compte qui doit se connecter automatiquement est un compte AD, alors il faudra ajouter une troisième clef de type <code>String</code>, nommée <code>DefaultDomainName</code> dont la valeur sera le nom du domaine auquel appartient le compte <code>DefaultUserName</code>.</p>
<h1 id="sources">Sources</h1>
<ul>
<li><a href="https://4sysops.com/archives/how-to-disable-the-shutdown-event-tracker-in-windows-server-2008-r2/">4sysops - How to disable the Shutdown Event Tracker in Windows Server 2008 R2 (Anglais)</a></li>
<li><a href="http://www.pctools.com/guides/registry/detail/270/">pctools - Set DHCP (Anglais)</a></li>
<li><a href="http://www.tomsitpro.com/articles/windows_server_2008-administration,2-105-3.html">tomsitpro - AutoLogon sur Windows</a></li>
</ul>
Secourir un Windows sans accès à sa console
http://techan.fr/secourir-un-windows-sans-acces-a-sa-console.html
Sat, 03 Jun 2017 11:46:12 +0100MrRaph_http://techan.fr/secourir-un-windows-sans-acces-a-sa-console.html
<h1 id="tl-dr">TL;DR</h1>
<p>Vous n’avez pas le temps de lire ma prose ? Qu’à cela ne tienne ! Voici les étapes à suivre pour opérer votre Windows malade à coeur ouvert.</p>
<ul>
<li>Retirer le disque C: malade de sa VM</li>
<li>Connecter le disque C: malade sur un autre Windows</li>
<li>Charger le <code>hive</code> que vous souhaitez éditer avec la commande : <code>reg load HKLM\<Nom à votre convenance> d:\Windows\System32\config\SYSTEM</code></li>
<li>Editer le registre avec <code>regedit</code></li>
<li>Décharger le <code>hive</code> malade avec la commande : <code>reg unload HKLM\<Nom à votre convenance></code></li>
<li>Déconnecter proprement le disque malade de l’instance de secours et le reconnecter à l’instance malade</li>
<li>Essayer de démarrer le Windows malade</li>
</ul>
<h1 id="ah-windows">Ah … Windows !</h1>
<p>Dans le petit des SysOps, il y a des opérations de secours que l’on aime bien et d’autres qui nous rebutent … Dans celles qui me plaisent, je citerais par exemple “les premiers secours à Linux en danger” ou encore “faire repartir un serveur Linux à grands coups de défibrilateur”. Par contre, celles qui me rebutent incluent presque tout le temps un serveur Windows … En effet, dès que l’on parle de Windows rien n’est vraiment simple. Dès que l’on doit faire des choses un petit peu pointues, il faut sortir l’éditeur de registre et là, les ennuis commencent …</p>
<p>Ceci est d’autant plus compliqué si l’on n’a pas un accès direct à la machine à sauver. Par exemple, vous avez envoyé votre super serveur “kifaitou” chez AWS, il démarre et tout, vous voyez la belle page vous invitant à vous connecter, mais impossible de l’attaquer à distance par RDP.</p>
<p><img src="http://techan.fr/images/2017/06/Windows_ecran_connexion_inaccessible.png" alt="Oh, un écran de connexion inaccessible ..." /></p>
<p>Ah oui, car chez AWS, vous pouvez voir des copie d’écran de la console de votre instance, mais vous ne pouvez pas en prendre le contrôle.</p>
<p><img src="http://techan.fr/images/2017/06/AWS_afficher_console_instance.png" alt="Afficher une copie d'écran de la console d'une instance AWS" /></p>
<p>Alors, elle en est ou la frustration là !?! :)</p>
<h1 id="chirurgie-à-coeur-ouvert">Chirurgie à coeur ouvert</h1>
<p><em>Note :</em> <em>Avant de réaliser les opérations ci-dessous, assurez vous d’avoir une sauvegarde récente du disque malade, ou mieux, faites en une tout de suite !</em></p>
<p>Aller, on se détend, il existe une astuce pour opérer notre Windows défaillant ! J’ai pris l’exemple d’AWS mais cette astuce fonctionnera avec n’importe quel serveur Windows, pour peu que vous puissiez présenter son disque C: à un autre serveur Windows.</p>
<p>Tout d’abord, éteignez l’instance malade, si vous avez d’autre Windows fonctionnel, créez une autre instance Windows. Lorsque le grand malade est arrêté, détachez son disque C: et branchez le sur le Windows valide. Bien évidement, il faudra le monter sur un disque autre que C: sur l’instance valide, sinon on tourne en rond ! Dans mon cas, je l’ai présenté sur le disque D: de mon Windows de secours.</p>
<p>Nous allons maintenant pouvoir charger le registre de notre Windows malade dans celui du Windows de secours. Ainsi nous pourrons éditer le registre malade comme si nous éditions le registre valide. Cette opération de chargement de registre se fait dans un <code>cmd.exe</code> lancé en administrateur, avec la commande suivante.</p>
<pre><code>C:> reg load HKLM\<Nom à votre convenance> d:\Windows\System32\config\SYSTEM
</code></pre>
<p>Cette commande va charger le registre <code>SYSTEM</code> de notre Windows malade à l’emplacement <code>HKEY_LOCAL_MACHINE\<Nom à votre convenance></code>. Vous pouvez faire cela avec chacun des <code>hive</code> présent dans le dossier <code>d:\Windows\System32\config\</code>.</p>
<p><img src="http://techan.fr/images/2017/06/Windows_load_hive.png" alt="Charger Hive malade" /></p>
<p>Maintenant, nous pouvons éditer cette partie de registre malade dans <code>regedit</code> ! :)</p>
<p><img src="http://techan.fr/images/2017/06/Windows_edit_loaded_hive.png" alt="Edition du hive malade" /></p>
<p>Lorsque vos modifications sont terminées, il faut décharger le <code>hive</code> malade du registre de notre Windows valide. Ceci se fait, toujours dans un <code>cmd.exe</code> administrateur, avec la commande suivante.</p>
<pre><code>C:> reg unload HKLM\<Nom à votre convenance>
</code></pre>
<p><img src="http://techan.fr/images/2017/06/Windows_unload_hive.png" alt="Décharger Hive malade" /></p>
<p>Il ne vous reste plus qu’à débrancher proprement le disque malade, le remonter sur le Windows malade et voir si votre modification à porté ses fruits… Et recommencer si celà n’est pas le cas :p</p>
<p>Bonne chance et bon courage !!</p>
<p>Voici <a href="http://techan.fr/quelques-clefs-de-registre-bien-utiles">quelques clefs de registres bien utiles …</a>.</p>
Utiliser Lambda et ServerLess pour creer un stopinator AWS - Partie 3
http://techan.fr/utiliser-lambda-et-serverless-pour-creer-un-stopinator-aws-part-iii.html
Tue, 16 May 2017 20:46:12 +0100MrRaph_http://techan.fr/utiliser-lambda-et-serverless-pour-creer-un-stopinator-aws-part-iii.html
<h1 id="résumé-des-épisodes-précédents">Résumé des épisodes précédents</h1>
<p>Dans la <a href="http://techan.fr/utiliser-lambda-et-serverless-pour-creer-un-stopinator-aws-part-ii/">partie 2</a> nous avons configuré le framework ServerLess et nous avons créé notre fonction Lambda. nous allons maintenant voir comment configurer la plateforme Lambda avec le framework Serverless et nous déploierons notre fonction.</p>
<p><em>Note :</em> Tous les codes présentés dans cette suite d’articles <a href="https://github.com/MrRaph/article-stopinator">sont disponible dans ce dépôt GitHub</a>.</p>
<h1 id="la-configuration-de-notre-projet-avec-serverless">La configuration de notre projet avec Serverless</h1>
<p>Toute la configuration de notre projet, c’est à dire tout ce qui est nécessaire à la bonne exécution de notre fonction Lambda, se trouve simplifiée par le framework Serverless. Ce dernier nous permet de régler tous les points dans un fichier de configuration unique : <code>serverless.yml</code>. Dans ce fichier nous allons décrire comment ServerLess va se connecter à notre compte AWS pour gérer les déploiements de notre code, mais aussi la façon dont les fonctions seront appelées, les droits IAM nécessaires, etc …</p>
<h2 id="configuration-générale-du-projet">Configuration générale du projet</h2>
<p>Cette partie de la configuration regroupe toutes les informations générales de votre projet comme son nom, et les paramètres généraux du projet.
Je vais décrire le contenu du fichier <code>serverless.yml</code> par partie, vous pouvez le retrouver dans son intégralité <a href="https://github.com/MrRaph/article-stopinator">dans ce dépot GutHub</a>.</p>
<p>La ligne <code>service</code> documente le nom de votre projet.</p>
<pre><code>service: Stopinator
</code></pre>
<p>Le bloc <code>provider</code> décrit chez quel fournisseur d’InfoNuagique le projet sera déployé. Dans notre cas, cela sera AWS. Nous décrivons également les caractérisques de base de notre fonction Lambda dans ce bloc.</p>
<pre><code>provider:
name: aws
runtime: python2.7
region: eu-west-1
profile: profileName1
cfLogs: false
</code></pre>
<ul>
<li><code>runtime</code> décrit le langage de programation que nous allons Utiliser</li>
<li><code>region</code> précise la région - au sens AWS - dans laquelle le projet sera déployé, dans notre cas l’Irelande.</li>
<li><code>profile</code> reçoit le nom que l’on a donné aux informations de connexion à AWS dans la <a href="http://techan.fr/utiliser-lambda-et-serverless-pour-creer-un-stopinator-aws-part-i/">première partie</a>.</li>
<li><p><code>cfLogs</code> permet de désactiver les logs de la fonction Lambda, ceci permet de faire des économies dans notre cas. Ces logs peuvent être nécessaires pour débuger les projets.</p>
<p>iamRoleStatements:
- Effect: “Allow”
Action:
- “ec2:DescribeInstances”
- “ec2:StopInstances”
Resource: “*”</p></li>
</ul>
<p>Le bloc <code>iamRoleStatements</code> permet d’ajouter des permissions supplémentaires à notre fonction Lambda. Elle en a besoin pour récupérer des informations sur les instances EC2 et pour pouvoir les éteindre.</p>
<p>Nous allons maintenant configurer les fonctions à proprement parler !</p>
<pre><code> functions:
doStop:
handler: handler.doStop
description: Stops instances
runtime: python2.7
memorySize: 128 # optional, default is 1024
timeout: 60 # optional, default is 6
</code></pre>
<p>Nous déclarons notre fonction <code>doStop</code> le bloc <code>functions</code>. Le handler est le “chemin” que Lambda va utiliser pour lancer la fonction, il est constitué du nom du fichier dans lequel la fonction est présente - sans son extension - et du nom de la fonction, le tout séparé par un point. Le paramètre <code>memorySize</code> décrit la mémoire maximale dont pourra disposer la fonctioner, il s’agit d’un des éléments définissant le prix que vous allez payer en utilsant cette fonction Lambda. Le paramètre <code>timeout</code> quant à lui définit le temps d’exécution maximale de la fonction, il a également un impact sur le prix que vous coûteront les exécutions des fonctions Lambda. Si le <code>timeout</code> est dépassé, Lambda met fin à l’exécution de la fonction. Il ne peut pas exéder 300 secondes.</p>
<p>Avec ces paramètres, la fonction serait fonctionnelle, mais il nous faut un moyen de l’exécuter tous les soirs, afin d’éteindre les instances que les étourdis ont oubliées ! :p Nous allons pour cela utiliser un évennement CloudWatch. CloudWatch est un service AWS permettant de monitorer des ressources, il propose également une fonction d’envoie d’évennements.</p>
<pre><code> events:
- schedule:
name: DEVEveningShutDownEC2
description: 'Shut down DEV EC2 at 19:50 PM'
rate: cron(50 17 ? * 2-6 *) # AWS CloudWatch Events time are in UTC !
enabled: true
input:
ENV: DEV
</code></pre>
<p>Ce bloc <code>events</code> ajouté à notre fonction défini un évennement planifié du lundi au vendredi inclus à 19h50 - attention les heures sont au format UTC dans CloudWatch. Cet évennement passera également un argument <code>ENV</code> à notre fonction avec la valeur <code>DEV</code>. Ce dernier est utilisé par notre fonction pour filtrer les instances qui portent ce tag avec cette valeur via la ligne suivante.</p>
<pre><code>for instance in filterInstances(event['ENV'], 'stopped'):
</code></pre>
<h1 id="déployons-notre-fonction">Déployons notre fonction !</h1>
<p>Vous allez maintenant pouvoir admirer toutes la puissance de ServerLess, pour déployer le projet chez AWS, nous utilisons la commande suivante.</p>
<pre><code>$ serverless deploy
</code></pre>
<p><img src="http://techan.fr/images/2017/05/Lambda_Stopinator_Serverless_deploy.png" alt="Déploiement de la fonction avec ServerLess" /></p>
<p>Cette commande sera la même si vous souhaitez pousser des modifications faites à votre fonction, ServerLess saura quels éléments modifier et ajustera son template CloudFormation en fonction. Comme beaucoup de processus d’automatisation autours d’AWS, ServerLess se base en effet sur CloudFormation, il s’agit d’un outil fort pratique permettant de définir des piles d’éléments et de les déployer chez AWS. Ces piles sont définies dans des <code>templates</code>, l’outil garanti que chaque exécution fournira toujours le même résultat, à condition bien sûr que le template ne change pas !</p>
<h1 id="quelques-autres-fonctionalités-sympa-de-serverless">Quelques autres fonctionalités sympa de ServerLess</h1>
<h2 id="métriques-sur-l-exécution-de-la-lambda">Métriques sur l’exécution de la Lambda</h2>
<p>ServerLess permet facilement de récupérer quelques métriques simples sur l’exécution des projets qu’il gère. Voici comment récupérer ces statistiques depuis le 1er Mai 2017.</p>
<pre><code>$ serverless metrics --startTime 2017-05-01
</code></pre>
<p><img src="http://techan.fr/images/2017/05/Lambda_Stopinator_Serverless_metrics.png" alt="ServerLess Lambda métriques sur le mois de Mai" /></p>
<h2 id="invoquer-la-fonction-lambda-depuis-son-poste-de-travail">Invoquer la fonction Lambda depuis son poste de travail</h2>
<p>Il est également possible avec ServerLess d’invoquer sa fonction Lambda depuis son poste de travail. Ceci évite une laborieuse opération via la console Web d’AWS. Ceci se fait avec la commande suivante.</p>
<pre><code>$ serverless invoke -f doStop -d '{"ENV": "DEV"}'
</code></pre>
<p><img src="http://techan.fr/images/2017/05/Lambda_Stopinator_Serverless_invoke.png" alt="Invoquer une fonction Lambda avec ServerLess" /></p>
<p><em>Note 1 :</em> Il faut bien sûr passer les arguments nécessaires à l’exécution de la fonction via l’option <code>-d</code></p>
<p><em>Note 2 :</em> Ceci vous est facturé comme une exécution normale de la fonction étant donné que cette exécution à bel et bien lieux chez AWS. Il est par contre possible de faire des tests exclusivement en local en utilisant la commande <code>serverless invoke local</code>.</p>
<h2 id="supprimer-une-projet">Supprimer une projet</h2>
<p>ServerLess simplifie également la suppression complète d’un projet de votre compte AWS. Ceci se réalise avec la commande suivante.</p>
<pre><code>$ serverless remove
</code></pre>
<p><img src="http://techan.fr/images/2017/05/Lambda_Stopinator_Serverless_remove.png" alt="Supprimer le projet avec ServerLess" /></p>
<h1 id="et-voilà">Et voilà !</h1>
<p>Notre fonction est en place chez AWS et planifiée tous les soirs. La chasse au gaspi peut commencer !</p>
<p><a href="http://techan.fr/utiliser-lambda-et-serverless-pour-creer-un-stopinator-aws-part-ii/"><< Épisode Précédent</a></p>
<p><em>Note :</em> Tous les codes présentés dans cette suite d’articles <a href="https://github.com/MrRaph/article-stopinator">sont disponible dans ce dépôt GitHub</a>.</p>
Utiliser Lambda et ServerLess pour creer un stopinator AWS - Partie 2
http://techan.fr/utiliser-lambda-et-serverless-pour-creer-un-stopinator-aws-part-ii.html
Sun, 07 May 2017 21:17:12 +0100MrRaph_http://techan.fr/utiliser-lambda-et-serverless-pour-creer-un-stopinator-aws-part-ii.html
<h1 id="résumé-des-épisodes-précédents">Résumé des épisodes précédents</h1>
<p>Dans la <a href="http://techan.fr/utiliser-lambda-et-serverless-pour-creer-un-stopinator-aws-part-i/">partie 1</a> nous avons vu les différents composants qui seront utilisés par notre <em>stopinator</em>. Nous allons maintenant nous pencher sur les deux éléments clefs de ce projet, l’utilistion du framework <a href="http://www.serverless.com/">Serverless</a> et la création de notre fonction Lambda.</p>
<p><em>Note :</em> Tous les codes présentés dans cette suite d’articles <a href="https://github.com/MrRaph/article-stopinator">sont disponible dans ce dépôt GitHub</a>.</p>
<h1 id="le-framework-serverless-http-www-serverless-com">Le framework <a href="http://www.serverless.com/">Serverless</a></h1>
<h2 id="installation">Installation</h2>
<p>L’installation du framework est relativement simple, elle nécessite toute fois que <a href="node.js">Node.js</a> soit installé sur votre poste. Ceci n’est pas couvert dans cette suite d’article.</p>
<p>Une fois <a href="node.js">Node.js</a> installé sur votre poste, l’installation de <a href="http://www.serverless.com/">Serverless</a> est très simple, il suffit de lancer la commande suivante.</p>
<pre><code>npm install -g serverless
</code></pre>
<p>Il est maintenant temps de passer à la configuration du framework.</p>
<h2 id="configuration">Configuration</h2>
<p>La configuration principale de <a href="http://www.serverless.com/">Serverless</a> est liée à la configuration de la <a href="https://aws.amazon.com/fr/cli/">ligne de commande AWS</a> - que je vous conseille fortement d’<a href="http://docs.aws.amazon.com/fr_fr/cli/latest/userguide/installing.html">installer</a>. <a href="http://www.serverless.com/">Serverless</a> va se servir des informations de connexion que vous aurez configuré pour utiliser <a href="https://aws.amazon.com/fr/cli/">la ligne de commande AWS</a>.</p>
<p>Assurez-vous que vous disposez d’une paire <em>Acces Key</em>, <em>Secret Key</em> créée depuis la console AWS. Si vous n’en avez pas, <a href="http://docs.aws.amazon.com/fr_fr/general/latest/gr/managing-aws-access-keys.html">leur création est documentée ici par AWS</a>.</p>
<p>Une vidéo expliquant la configuration de informations de connexion pour Serverless est disponible sur la chaine Youtube du projet.</p>
<div style="position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;">
<iframe src="//www.youtube.com/embed/HSd9uYj2LJA" style="position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;" allowfullscreen title="YouTube Video"></iframe>
</div>
<h3 id="si-vous-avez-installé-la-ligne-de-commande-aws">Si vous avez installé la ligne de commande AWS</h3>
<p>Si vous avez déjà installé la CLI AWS, alors vous avez probablement déjà configuré l’authentification à votre compte. Vous pouvez vérifier cela en regardant le contenu des fichiers suivants (en fonction de l’OS que vous utilisez) :</p>
<ul>
<li>~/.aws/credentials (Linux / macOS)</li>
<li>C:\Users\USERNAME .aws\credentials (Windows)</li>
</ul>
<p>Si vous n’avez pas encore configuré la CLI pour vous connecter à votre compte AWS, il faut utiliser la commande <code>aws configure</code>. Cette dernière vous demandera les informations nécessaires à la connexion à votre compte AWS et renseignera le fichier <code>.aws/credentials</code>. Ceci est documenté <a href="http://docs.aws.amazon.com/fr_fr/cli/latest/userguide/cli-chap-getting-started.html">ici</a>.</p>
<p>Vous pourrez ensuite utiliser ces informations de connexion avec <a href="http://www.serverless.com/">Serverless</a>.</p>
<h3 id="si-vous-n-avez-pas-installé-la-ligne-de-commande-aws">Si vous n’avez pas installé la ligne de commande AWS</h3>
<p><a href="http://www.serverless.com/">Serverless</a> propose un moyen de configurer l’accès à votre compte via sa propre ligne de commande. Ceci ce fait via la ligne de commande suivante.</p>
<pre><code>serverless config credentials --provider aws --key <Access Key> --secret <Secret Key>
</code></pre>
<p>La configuration complète du framework est documentée <a href="https://github.com/serverless/serverless/blob/master/docs/providers/aws/guide/credentials.md">ici</a>.</p>
<h3 id="identifier-le-nom-du-profile-aws">Identifier le nom du profile AWS</h3>
<p>Pour utiliser les informations d’identification AWS configurée dans les paragraphes précédents, il faut que vous connaissiez le nom du profile associé à la paire <em>Acces Key</em>, <em>Secret Key</em> que vous souhaitez utiliser. Pour cela, il faut aller voir dans le fichier <code>.aws/credentials</code>.</p>
<pre><code>[profileName1]
aws_access_key_id=***************
aws_secret_access_key=***************
[profileName2]
aws_access_key_id=***************
aws_secret_access_key=***************
</code></pre>
<p>Dans l’exemple ci-dessus, deux profiles sont configurés, l’un s’appelant <code>profileName1</code> et l’autre <code>profileName2</code>. Dans la suite de cet article, j’utiliserai en exemple le profile <code>profileName1</code>.</p>
<h2 id="création-du-service">Création du service</h2>
<p>Nous voilà maintenant dans le coeur du problème ! Nous allons créer un projet avec le framework Serverless. Ce projet va nous permettre de déployer et de configurer notre fonction Lambda sans même ouvrir la console web AWS.</p>
<p>La création du service, est très simple, elle revient à exécuter la commande suivante.</p>
<pre><code>serverless create --template aws-python --path Stopinator
</code></pre>
<p><img src="http://techan.fr/images/2017/05/serverles_create_service.png" alt="Création du service avec Serverless" /></p>
<p>Cette commande va créer le dossier “<em>Stopinator</em>” ainsi que deux fichiers :</p>
<ul>
<li>handler.py</li>
<li>serverless.yml</li>
</ul>
<p>Le premier fichier - <code>handler.py</code> - contiendra le code de la fonction Lambda du <em>stopinator</em> et le second - <code>serverless.yml</code> - contiendra lui la configuration de cette fonction et tous ses à-côtés. Il faudra en effet configurer l’event <em>CloudWatch</em> qui va déclencher son exécution. Il faudra également qu’il contienne les éléments de configuration <em>IAM</em> pour que notre fonction puisse agir sur les instances EC2.</p>
<h1 id="créons-notre-fonction-lambda">Créons notre fonction Lambda</h1>
<p><em><em>Note :</em></em> <em><a href="https://raw.githubusercontent.com/MrRaph/article-stopinator/master/handler.py">Le code complet de la fonction est disponible ici</a>.</em></p>
<p>Le coeur de notre fonction Lambda va se situer dans le fichier <code>handler.py</code>. Nous allons remplacer la fonction existante dans ce fichier, la fonction <code>hello</code> qui s’y trouve a été créée par le framework Serverless lors de la création du service. Nous allons donc remplacer cette fonction <code>hello</code>par le code suivant.</p>
<pre><code>def doStop(event, context):
response = "doStop"
for instance in filterInstances(event['ENV'], 'running'):
instance.stop()
return response
</code></pre>
<p>Cette fonction prend deux paramètres - <code>event</code> et <code>context</code> - par défaut pour les fonctions Lambda. Elle appelle ensuite la fonction <code>filterInstances</code> à laquelle elle passe un paramètre <code>ENV</code> qu’elle a elle même reçue via les paramètres de la fonction Lambda et un paramètre contenant l’état souhaiter des instances à traiter. Dans ce cas, les instances sur lesquelles nous souhaitons agir sont celles qui sont en cours d’exécution, nous passons donc l’état <code>running</code>. Puis elle boucle sur chaque instance retournée par cette dernière fonction et stoppe l’instance concernée.</p>
<p>Nous allons également ajouter le code de la fonction <code>filterInstances</code> à la fin du fichier <code>handler.py</code>.</p>
<pre><code>def filterInstances(env, state):
filters = [
{'Name':'tag:Environment', 'Values':[ env ]},
{'Name': 'instance-state-name', 'Values': [ state ]}
]
allInstances = ec2.instances.filter(Filters=filters)
return allInstances
</code></pre>
<p>Cette fonction va filtrer les instances en fonction de leur environnement et de leur état actuel puis retourner cette liste d’instance.</p>
<h1 id="la-suite-au-prochain-épisode">La suite au prochain épisode !</h1>
<p>Maintenant nous avons configuré le framework Serverless, nous avons créé notre fonction Lambda, bref, nous sommes prêt à <em>stopiner</em> !! Dans la troisième partie, nous mettrons le tout en musique !</p>
<p><a href="http://techan.fr/utiliser-lambda-et-serverless-pour-creer-un-stopinator-aws-part-i/"><< Épisode Précédent</a> <a href="http://techan.fr/utiliser-lambda-et-serverless-pour-creer-un-stopinator-aws-part-i/">Épisode Suivant >></a></p>
<p><em>Note :</em> Tous les codes présentés dans cette suite d’articles <a href="https://github.com/MrRaph/article-stopinator">sont disponible dans ce dépôt GitHub</a>.</p>
Utiliser Lambda et ServerLess pour creer un stopinator AWS - Partie 1
http://techan.fr/utiliser-lambda-et-serverless-pour-creer-un-stopinator-aws-part-i.html
Thu, 04 May 2017 18:46:12 +0100MrRaph_http://techan.fr/utiliser-lambda-et-serverless-pour-creer-un-stopinator-aws-part-i.html
<h1 id="un-stopina-quoi">Un stopina…QUOI ?</h1>
<p>Un <em>stopinator</em> est un programme permettant d’arrêter - de <em>stopiner</em> :p - des machines, ou n’importe quoi en fait. Ceci est très utilisé lorsque l’on souhaite alléger sa facture auprès de son fournisseur de services dans le nuage. Ces fournisseurs - comme <a href="https://aws.amazon.com/fr/what-is-aws/">AWS</a> pour ne citer que lui - font en général payer les ressources consommées à l’heure. On peut facilement imaginer des plans visant à éteindre les ressources qui ne sont pas utiles la nuit par exemple et les rallumer le matin lorsque les gens reviennent au travail. Ceci permet d’économiser facilement de l’argent.</p>
<p>Dans le contexte <a href="https://aws.amazon.com/fr/what-is-aws/">AWS</a> dont je vais parler dans cet article, les choses sont relativement simple car l’API mis à disposition d’Amazon est très bien fournie et permet de faire beaucoup de chose en CLI - ligne de commandes - de plus, les nombreux SDK disponibles sont également très complets. J’utiliserai le SDK Python dans le cadre de cette suite d’article, il s’appelle <a href="https://aws.amazon.com/fr/sdk-for-python/">Boto3</a>.</p>
<p>Il y a plusieurs manières de mettre en place des <em>stopinators</em>. On peut, par exemple, utiliser une instance qui sera elle toujours allumée, peut être une passerelle ou autre, et lui ajouter une tâche planifiée qui va aller éteindre d’autres ressources. Dans le cadre de cet article, je vais décrire la mise en place d’un processus un peu plus évolué utilisant une fonction <a href="https://aws.amazon.com/fr/lambda/details/">Lambda</a> et des règles <a href="https://aws.amazon.com/fr/cloudwatch/details/">CloudWatch</a>.</p>
<h1 id="heu-et-lambda-késako">Heu … Et Lambda ? Késako ?</h1>
<p><a href="https://aws.amazon.com/fr/lambda/details/">Lambda</a> fait partie de l’offre <a href="https://aws.amazon.com/fr/products/compute/"><em>Compute</em> d’AWS</a>. Cette offre <em>Compute</em> est pour la plupart des gens limitée aux instances <a href="https://aws.amazon.com/fr/ec2/">EC2</a>, les VMs qu’AWS héberge dans son nuage. Mais il existe d’autres produits AWS qui permettent de réaliser des traitements dans le nuage, je veux parler d’<a href="https://aws.amazon.com/fr/ecs/">ECS</a>, la plateforme d’hébergement de containers proposée par Amazon et … de <a href="https://aws.amazon.com/fr/lambda/details/">Lambda</a> bien sûr !</p>
<p><a href="https://aws.amazon.com/fr/lambda/details/">Lambda</a> est une plateforme de <em>FaaS</em> - pour les IT-psters - ou plus simplement, une plateforme <em><a href="http://www.serverless.com/">Serverless</a></em>.</p>
<blockquote>
<p>Non mais attends … “<em><a href="http://www.serverless.com/">Serverless</a></em>” ça veut dire “<em>sans serveurs</em>” comment on peut faire du “computing” “<em>sans serveurs</em>” ?</p>
</blockquote>
<p>Et bien, là est toute la force et la magie de <a href="https://aws.amazon.com/fr/lambda/details/">Lambda</a> ! Amazon garde jalousement le secret sur la manière dont cette plateforme fonctionne, mais elle peut rapidement votre façon de voire les infrastructures informatiques.</p>
<p>Le principe derrière <a href="https://aws.amazon.com/fr/lambda/details/">Lambda</a> est simple, et peut être résumé en quelques étapes :</p>
<ul>
<li>Vous écrivez une fonctions dans un langage supporté.</li>
<li>Vous mettez en place un événement qui va déclencher son exécution.</li>
<li>Vous sortez les Pop-Corn et vous admirez !</li>
</ul>
<p>Actuellement, les langages supportés par <a href="https://aws.amazon.com/fr/lambda/details/">Lambda</a> sont : <code>Node.js</code>, <code>Python</code>, <code>Java</code> et <code>C#</code>.</p>
<p>La cerise sur le gateau, c’est qu’avec <a href="https://aws.amazon.com/fr/lambda/details/">Lambda</a>, vous ne payez que ce que l’exécution de votre fonction consomme. Alors que les instances EC2 sont facturées à l’heure - toute heure entamée est due bien sûr - les fonctions Lambda elles ne coûte que le nombre de secondes pendant lesquelles elles ont été exécutées sur la plateforme AWS.</p>
<p>Par ailleurs le <em>Free Tier</em> de Lambda est très intéressant. Le <em>Free Tier</em> représente un quota d’utilisation qu’Amazon vous offre, il en existe un pour une grande majorité de services AWS - n’est pas limité dans le temps ! En effet, une grande majorité des <em>Free Tiers</em> sont limité à un an à partir de la création du compte AWS. Celui de Lambda est disponible à vie et il est relativement confortable - 400 000 Go-secondes par mois ! Pour exemple, ce <em>Free Tier</em> permet de faire tourner, de manière continue, une fonction Lambda - configurée pour utiliser jusqu’à 128 Mo de mémoire - pendant 3 200 000 secondes, soit 888 heures ou 37 jours tous les mois.</p>
<h1 id="et-maintenant-parlons-de-serverless-http-www-serverless-com">Et maintenant, parlons de <a href="http://www.serverless.com/">Serverless</a></h1>
<p><a href="https://serverless.com">Serverless</a> est un framework fourni par AWS pour déployer des fonctions Lambda sur AWS. Dans les faits, ce framework sait également parler avec Azure, mais ceci est un autre débat - :p - !</p>
<p>La force de ce framework est de simplifier grandement le déploiement des fonctions Lambda. Ce processus n’est pas si simple lorsqu’il faut le réaliser à la main. Tout d’abord, il faut déjà télécharger toutes les librairies nécessaires au projet et les zipper avec les sources des fonctions Lambda, uploader le tout sur S3 et configurer la fonction. <a href="https://serverless.com">Serverless</a> gère tout cela à votre place.</p>
<p>Il est également capable de créer toutes sortes d’autres composants AWS en lien avec votre/vos fonction(s) Lambda. Dans l’exemple que nous allons traiter, je vais me servir de <a href="https://serverless.com">Serverless</a> pour créer les programmations de l’exécution de mon <em>stopinator</em> avec des règle CloudWatch. Il va aussi prendre se charger de la création du rôle IAM - la briques AWS qui gère les autorisations - qui sera associé à notre Lamdba afin qu’elle ai les droits nécessaires pour agir sur les instances EC2.</p>
<p>Le framework permet également de simplifier grandement les tests de fonctions Lambda, que ce soit en local ou sur la plateforme AWS.</p>
<h1 id="bon-maintenant-qu-on-connait-tout-cela-à-quoi-va-ressembler-le-stopinator">Bon, maintenant qu’on connait tout cela, à quoi va ressembler le STOPINATOR ?</h1>
<p>Et bien, cela ressemblera à cela !</p>
<p><img src="http://techan.fr/images/2017/05/Lambda_Stopinator.png" alt="Schéma du Stopinator Lambda" /></p>
<p>On voit ici les deux déclencheurs CloudWatch qui vont provoquer l’exécution de la fonction Lambda. On remarque que notre fonction aura besoin de permissions IAM spécifiques pour pouvoir interagir avec les instances EC2. De l’autre côté de la fonction Lambda, on voit qu’elle va interagir avec l’API EC2 et non avec les instances elles mêmes.</p>
<p>Dans un premier temps, la fonction va filter les instances pour ne cibler que celles qu’elle est chargée d’éteindre ou d’allumer. Puis dans un second temps, elle envoie ses instructions à l’API EC2 pour éteindre ou allumer les instances EC2. Ce sont ces trois actions - décrire, démarrer, éteindre des instances EC2 - qui nécessitent des autorisations IAM.</p>
<h1 id="la-suite-au-prochain-épisode">La suite au prochain épisode !</h1>
<p>Dans la seconde partie, nous verrons comment configurer le framework <a href="http://www.serverless.com/">Serverless</a> pour notre cas d’usage. Nous créerons également la fonction Lambda qui sera utilisée pour <em>stopiner</em> nos instances.</p>
<p><a href="http://techan.fr/utiliser-lambda-et-serverless-pour-creer-un-stopinator-aws-part-ii/">>> Épisode Suivant</a></p>
<p><em>Note :</em> Tous les codes présentés dans cette suite d’articles <a href="https://github.com/MrRaph/article-stopinator">sont disponible dans ce dépôt GitHub</a>.</p>
SuSE Manager : Impossible de démarrer un minion Salt
http://techan.fr/suse-manager-impossible-de-lancer-le-minion-salt.html
Tue, 07 Mar 2017 18:46:12 +0100MrRaph_http://techan.fr/suse-manager-impossible-de-lancer-le-minion-salt.html
<p>SuSE Manager est une solution de gestion de parc de machines SuSE et RedHat proposée par SuSE. Cette solution s’articule entre autres autour de Spacewalk - une solution open source également utilisée par RedHat - et de Salt. Salt est un outil de gestion de configuration, cet outil représente une alternative à Ansible, Puppet ou Chief. Salt permet de déployer des programmes et leur configuration sur une machine ou sur un groupe de machines. Cela permet de s’assurer que toutes les machines sont configurées de la même façon.</p>
<h1 id="salt-et-le-suse-manager">Salt et le SuSE Manager</h1>
<p>SuSE à choisi Salt pour son outil SuSE Manager. Salt permet au SuSE Manager de réaliser des actions de configuration internes, mais il est également accessible aux administrateurs de la solution. Cela permet d’ajouter encore plus de souplesse dans l’administration des systèmes.</p>
<p>Salt fonctionne en mode client/serveur, le serveur étant dans ce cas le SuSE Manager. Les clients sont toutes les machines rattachées au SuSE Manager. Les client s’appellent des “minions” dans le monde Salt.</p>
<h2 id="ajout-d-une-machine-dans-le-suse-manager">Ajout d’une machine dans le SuSE Manager</h2>
<p>L’ajout d’une machine dans le SuSE Manager requiert la création d’un dépôt “bootstrap” en avance de phase, cecin’eet ps documenté ici.</p>
<p>Sur la machine cliente que l’on souhaite ajouter au SuSE Manager, on ajoute ce fameux dépôt “bootstrap” à Zypper puis ont rafraîchi la liste des paquets.</p>
<pre><code> zypper ar -f http://smgr.susemgr.com/pub repositories/sle/12/0/bootstrap \
bootstraprepo
zypper ref
</code></pre>
<p>Lorsque ceci est fait, on peut installer le minion.</p>
<pre><code> zypper in salt-minion
</code></pre>
<p>Maintenant, il ne reste plus qu’à configurer le serveur maître dans la configuration du minion,
ceci se fait dans le fichier ˋ/etc/salt/minionˋ. Ensuite, nous pouvons démarrer le minion avec la commande suivante.</p>
<pre><code> systemctl start salt-minion
</code></pre>
<h2 id="erreur">Erreur !!!</h2>
<p>Dans mon cas, j’ai installé le SuSE Manager sur une SuSE SLES 12 SP1 et mon minion est une SuSE SLES 12. Je rencontre l’erreur suivante lorsque le minion essayé de démarrer.</p>
<pre><code>2017-03-01 16:26:08,333 [salt.scripts ][ERROR ][7628] No module named certifi
</code></pre>
<p>Il manque visiblement le module Python ˋcertifiˋ dans le dépôt bootstrap et dans les dépôts de base. Ceci empêchera le minion de fonctionner. Pour cela, j’ai téléchargé le paquet ˋpython-certifi` pour openSuSE et j’ai reconstruit le dépôt bootstrap.</p>
<h2 id="correction">Correction !</h2>
<p>Toutes les étapes pour ce faire sont les suivantes, elle sont à exécuter sur le SuSE Manager.</p>
<pre><code>cd /srv/www/htdocs/pub/repositories/sle/12/0/bootstrap
wget ftp://ftp.pbone.net/mirror/ftp5.gwdg.de/pub/opensuse/repositories/devel:/languages:/python/openSUSE_12.3/noarch/python-certifi-14.05.14-3.1.noarch.rpm
mgr-create-bootstrap-repo -c SLE-12-x86_64
</code></pre>
<p>la dernière commande reconstruit le dépôt bootstrap.</p>
<p>Maintenant que le dépôt bootstrap contient la dépendance manquante, retournons sur la machine minion et recommençons.</p>
<p>Nous allons rafraichir la liste des paquets dans les dépôts et installer la librairie manquante.</p>
<pre><code>zypper ref
zypper in python-certifi
</code></pre>
<p>Mainteant, il suffit de relancer le minion Salt !</p>
<pre><code> systemctl restart salt-minion
</code></pre>
Un relais SMTP dans Docker en moins de 5 minutes !
http://techan.fr/un-relais-smtp-dans-docker-en-moins-de-5-minutes.html
Tue, 14 Feb 2017 18:46:12 +0100MrRaph_http://techan.fr/un-relais-smtp-dans-docker-en-moins-de-5-minutes.html
<p>Vous avez un domaine, un site web, mais pas de serveur de mail ? Ou vous possèdez pleiiiiins de domaines dans lesquels vous utilisez quelques adresses mail que vous souhaiteriez unifier vers une seule ? Ou comme moi, vous hébergiez vos mails et vous souhaitez revenir simplement vers l’un des services de messagerie bien connus, tout cela sans forcément prendre le temps de migrer toutes les adresses mails de tous les comptes que vous avez sur l’Internet entier et sans perdre de mails ? Et bien c’est possible, et je vais vous expliquer comment faire.</p>
<p>Je pars du principe que vous avez :
* un nom de domaine
* une machine avec une IP publique
* [Docker]() installé sur cette machine</p>
<p>Aller, 5 minutes montre en main, lancez le chronomètre !</p>
<h1 id="5-minutes-pour-créer-un-relais-smtp-c-est-possible">5 minutes pour créer un relais SMTP, c’est possible !</h1>
<p>Tout d’abord, nosu allons exporter une variable dans laquelle nous configurons l’adresse source et celle vers laquelle rediriger le courrier. Dans l’exemple ci-dessous, on redirigerait tous les mails arrivant pour <code>[email protected]</code> vers l’adresse <code>[email protected]</code>. Simple non ?</p>
<pre><code>export SMF_CONFIG='[email protected]:[email protected]'
</code></pre>
<p>Vous voulez rediriger les messages des toutes adresses mail d’un domaine vers une adresse spécifique ? C’est aussi simple que cela :</p>
<pre><code>export SMF_CONFIG='@testo.com:[email protected]'
</code></pre>
<p>Vous avez positionné la variable avec succès ? Maintenant, démarrons le container et adminirons le travail.</p>
<pre><code>docker run -e SMF_CONFIG="$SMF_CONFIG" -p 25:25 zixia/simple-mail-forwarder
</code></pre>
<p>Et voilà ! :-)</p>
<p>Vous devriez avoir mis moins de 5 minutes pour faire cela ! Bon j’ai quelque peu triché, maintenant, il vous faudra configurer votre DNS pour que les mails arrivent vers votre relais !</p>
<h1 id="créons-un-service-pour-cela">Créons un service pour cela</h1>
<p>En bonus, voici un script qui permet de créer un service pour cela, histoire d’être tranquile :-)</p>
<pre><code>#!/bin/bash
export SMF_CONFIG='@testo.com:[email protected]'
docker service create --replicas 1 \
--restart-condition any --name smtp-relay \
--publish 25:25 \
--env SMF_CONFIG="$SMF_CONFIG" \
zixia/simple-mail-forwarder
</code></pre>
Chasse à l'espace perdu avec Docker, gare aux volumes !
http://techan.fr/docker-chasse-a-lespace-perdu-gare-aux-volumes.html
Sat, 11 Feb 2017 15:46:12 +0100MrRaph_http://techan.fr/docker-chasse-a-lespace-perdu-gare-aux-volumes.html
<p>Il n’est pas rare de constater que l’espace disque consommé par Docker dans ses dossiers internes - par défaut sur Linux : <code>/var/lib/docker</code> - augmente régulièrement, parfois jusqu’à la saturation du file system. Si disque contenant le dossier <code>/var/lib/docker</code> venait à être plein, il serait alors impossible de démarrer de nouveaux containers, de télécharger de nouvelles images. Il se pourrait même que certains containers arrêtent de fonctionner. J’ai déjà été confronté plusieurs fois à des cas dans lesquels il était difficile d’identifier la source de la surconsommation d’espace disque. Voici quelques pistes pour la trouver et libérer de l’espace disque.</p>
<p>Nous verrons ici que la façon dont vous écrivez vos Dockerfile peut avoir un impact fort sur la taille que consommera le container - parfois à votre insue - sur le disque local de l’hôte.</p>
<h1 id="le-ménage-dans-les-containers-et-les-images">Le ménage dans les containers et les images</h1>
<p>Le premier reflexe est de faire le ménage dans les containers arrêtés - attention, il sont parfois nécassires ! - et dans les images non utilisées. Ceci peut être une manière simple et rapide de libérer quelques giga octets. Il faut toute fois noter, que si Docker affiche qu’une image pèse 1,88 GB ni signifie pas forcément que la suppression de cette image libèrera effectivement 1,88 GB. Si vous avez téléchargé plusieurs versions de cette image alors une grande partie de cette taille totale sera partagée par toutes les versions. Docker ne télécharge pas les choses deux fois, il est capable de factoriser des éléments - calques - partagés par plusieurs images.</p>
<p><img src="http://techan.fr/images/2017/02/docker_volumes_images.png" alt="Poids images Docker" /></p>
<p>Pour en savoir plus sur la façon de faire du ménage automatiquement dans les containers et les images non utilisés, lisez <a href="http://techan.fr/faites-du-menage-dans-docker-avec-docker-gc/">Faites du ménage dans Docker avec docker-gc</a>.</p>
<h1 id="et-maintenant-les-volumes">Et maintenant, les volumes !</h1>
<p>Vous avez déjà purgé tout ce que vous pouviez dans les containers et les images qui trainaient sur vos hôtes Docker, mais la quantité d’espace inutilisée vous semble toujours trop importante ? Alors vous avez peut être des volumes à purger également !</p>
<p>Nous tout d’abord voir comment lister les volumes Docker présents sur votre hôte. Il faut utiliser la commande <code>docker volume ls</code> pour les faire apparaître.</p>
<p><img src="http://techan.fr/images/2017/02/docker_volumes_ls.png" alt="Lister les volumes Docker" /></p>
<p>Docker n’est pas très bavard lorsqu’il liste les volumes, il n’affiche que les identifiant de ces derniers et le driver utilisé par chacun d’eux. Tous les volumes dont le driver est <code>local</code> sont stockés, par défaut, dans le dossier <code>/var/lib/docker/volumes</code>.</p>
<p><img src="http://techan.fr/images/2017/02/docker_volumes_taille_dossier.png" alt="Taille des volumes Docker" /></p>
<p>Dans mon cas, la taille occupée par ces volumes dans le dossier <code>/var/lib/docker</code> reste raisonnable, mais j’ai parfois vu des cas ou ces volumes occupaient preque 40 Go sur le disque.</p>
<h2 id="les-volumes-fantômes">Les volumes “fantômes”</h2>
<p>Ce que j’appelle des “volumes fantômes” sont des volumes que Docker créer car vous le lui avez demandé mais que vous n’utilisez pas. Dans un Dockerfile, il existe une clause <code>VOLUME</code> qui permet de déclarer des éléments qui seront traités de manière spéciale au niveau stockage. Cela peut être le dossier dans lequel vos utilisateurs vos uploader leur avatar, le dossier dans lequel l’application dans le container va générer vos factures, cela peut être n’importe quel dossier. Mais attention !! Il est facile de déclarer des volumes, mais si l’on en déclare trop, cela deviendra vite impactant !</p>
<p>Voyons, en image, un exemple qui va créer un “volume fantôme”.</p>
<p><img src="http://techan.fr/images/2017/02/docker_volumes.png" alt="La recette pour créer des volumes fantômes" /></p>
<p>Dans cet exemple, nous avons défini que le dossier <code>/data</code> du container serait un volume. Puis, dans le fichier <code>docker-compose.yml</code> nous définissons l’utilisation d’un volume sur le dossier <code>/data/app</code>. Or, le dossier que nous utilisons comme un volume dans le container <em>n’est pas celui qui a été défini dans le Dockerfile</em>.</p>
<p>Voici ce qui va se passer lors du démarrage du container. Docker va effectivement monter le dossier <code>/data/app</code> de l’hôte sur le dossier <code>/data/app</code> du container, comme attendu. Par contre, il va également créer un volume dans le dossier <code>/var/lib/docker/volumes</code>, il va ensuite copier le contenu du dossier <code>/data</code> du container dans ce nouveau volume et le monter.</p>
<p>Le container fonctionnera comme attendu, mais si dans votre image, le dossier <code>/data</code> contient - beaucoup - de données, ces dernières seront copiées dans un nouveau volume “fantôme” à chaque fois que vous démarrerez un nouveau container de cette manière. En plus de vous pénaliser en terme d’occupation d’espace disque, ceci peut également ralentir le démarrage des container à cause de la copie des données entre le container et le volume “fantôme”.</p>
<h2 id="solutionner-le-problème">Solutionner le problème</h2>
<p>La solution à ce problème est simple, il suffit de valider que chaque volume définit dans vos Dockerfile est bien utilisé ensuite lorsque vous démarrez vos containers - que ce soit avec <code>docker-compose</code> ou toute autre méthode.</p>
<p>Vous pouvez également purger les volumes “fantômes” présents sur votre hôtes en utilisant le petit script ci-dessous. Ceci vous permettra de purger les volumes et de gagner de l’espace disque. Vous pouvez le plannifier afin de purger régulièrement les volumes “fantômes” jusqu’à ce que tous vos Dockerfile soient corrigés.</p>
<pre><code>#!/bin/bash
for vol in $(docker volume ls | awk '{print $2}' | grep -v VOLUME)
do
docker volume rm $vol
done
</code></pre>
<p>L’utilisation de ce script n’est pas dangereuse pour les containers car la commande <code>docker volume rm</code> ne supprimera des volumes en cours d’utilisation par des containers.</p>
Utiliser les Health Checks avec Docker 1.12
http://techan.fr/utiliser-les-healthchecks-avec-docker-1.12.html
Tue, 24 Jan 2017 08:00:59 +0100MrRaph_http://techan.fr/utiliser-les-healthchecks-avec-docker-1.12.html
<h1 id="la-surveillance-du-processus-principal-c-est-bien-mais">La surveillance du processus principal c’est bien mais …</h1>
<p>Les “<a href="https://docs.docker.com/engine/reference/builder/#/healthcheck">Health Checks</a>” ont été introduits dans le monde Docker avec la version 1.12, ils répondent à un manque flagrant dans cet environnement de “containérisation” : la surveillance des processus dans les containers. Historiquement, Docker surveillait uniquement le processus “principal” des ses containers, c’est à dire le processus définit dans les instructions <code>CMD</code> ou <code>ENTRYPOINT</code> des Dockerfiles. On constatait alors qu’un container mourait lorsque le daemon Docker ne détectait plus ce processus principal. En gros, c’est un peu comme surveiller si la bouteille d’huile d’olive n’est pas fendue pour surveiller la quantité d’huile qu’elle contient.</p>
<p>Ce mécanisme est toujours présent malgré l’arrivée des “<a href="https://docs.docker.com/engine/reference/builder/#/healthcheck">Health Checks</a>”, mais ces derniers enrichissent les possibilité de validation de la santé d’un container. Prenons un exemple simple, vous avez une image dans laquelle vous lancez un serveur web qui servira un site statique - oui, l’exemple n’est pas innocent :p. Le processus principal des containers engendrés par cette image sera sans doute le serveur web lui même, disons NGinx. Il est possible que dans certains cas, sous une forte charge par exemple, le processus NGinx soit bien présent dans le container mais que le serveur web ne soit pas au mieux de sa forme et que donc, le site réponde mal.</p>
<p># Les Health Checks apportent des possibiltés supplémentaires plus poussées !</p>
<p>Dans ce type de cas, il est intéressant de tester si le serveur web répond réellement ou si le processus fait de la figuration. Avec l’arrivée des “<a href="https://docs.docker.com/engine/reference/builder/#/healthcheck">Health Checks</a>”, il est maintenant possible de déléguer ce type de validation directement à Docker.</p>
<p>Les “Health Checks” peuvent être définis dans le Dockerfile afin que chaque container créé à partir de l’image ainsi définie implémente ces validations. Ils peuvent également être définis au lancement d’un container, ils ne seront dans ce cas valable que pour le container démarré de cette façon.</p>
<h2 id="définition-des-health-checks-dans-un-dockerfile">Définition des Health Checks dans un Dockerfile</h2>
<p>Voici la commande à ajouter dans un Dockerfile pour ajouter des validations de bonne santé.</p>
<pre><code>HEALTHCHECK [OPTIONS] CMD command (check container health by running a command inside the container)
HEALTHCHECK NONE (disable any healthcheck inherited from the base image)
</code></pre>
<p>En plus de la commande de validation, qui est obligatoire, il est possible de jouer sur différents paramètres concernants la réalisation et la validation des tests de santé.</p>
<pre><code>--interval=DURATION (default: 30s)
--timeout=DURATION (default: 30s)
--retries=N (default: 3)
</code></pre>
<p>Voici un exemple de Dockerfile très simple qui utilise un test de bonne santé qui valide que le serveur web NGinx répond toujours en HTTP. Petite remarque bête, on est obligé d’installer <code>curl</code> sinon le test serait forcément en erreur !</p>
<pre><code>FROM nginx:latest
RUN DEBIAN_FRONTEND=noninteractive apt-get update && \
DEBIAN_FRONTEND=noninteractive apt-get install -y curl && \
rm -rf /var/lib/apt/lists/* && \
ADD ./site /var/wwww
ADD sites-enabled/www.techan.fr.conf /etc/nginx/sites-enabled/www.techan.fr.conf
HEALTHCHECK CMD curl --fail http://localhost/ || exit 1
EXPOSE 80 443
CMD ["nginx", "-g", "daemon off;"]
</code></pre>
<p>Voici ce qu’affiche Docker lorsque l’on liste les container qui sont en cours d’exécution. On peut voir la nouvelle information <code>(healthy)</code> affichée à côté du statut du container.</p>
<pre><code>root@docker-machine-1:~# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
6aea82cf2942 mrraph/blog "nginx -g 'daemon ..." 22 hours ago Up 22 hours (healthy) 80/tcp, 443/tcp, 8080/tcp techan-prod.2.jb5h3e8ce30vjiohxuy1ry7bk
</code></pre>
<p>On peut également interroger Docker pour avoir directement le statut du Health Check avec la commande ci-dessous.</p>
<pre><code>docker inspect --format='{{.State.Health.Status}}' techan-prod.2.jb5h3e8ce30vjiohxuy1ry7bk
healthy
</code></pre>
<h2 id="définir-un-health-check-au-lancement-d-un-container">Définir un Health Check au lancement d’un container</h2>
<p>Il est également possible de définir les paramètres de Health Check au démarrage d’un container. Ces paramètres ne seront alors valables que pendant la durée de vie du container.</p>
<p>Si l’on reprend l’exemple précédent, voici à quoi ressemblerait la commande pour démarrer le container avec le même test de bonne santé.</p>
<pre><code>$ docker run --name=test -d \
--health-cmd='curl --fail http://localhost/ || exit 1' \
--health-interval=2s \
mrraph/blog
</code></pre>
<p>Cette méthode permet de valider que le test fonctionne comme attendu.</p>
<p># Sources</p>
<ul>
<li><a href="https://docs.docker.com/engine/reference/builder/#/healthcheck">Health Checks : Documentation Docker (Anglais)</a></li>
</ul>
Un microservice pour recuperer les IP d'un service Swarm
http://techan.fr/un-microservice-pour-recuperer-les-ip-dun-service-swarm.html
Mon, 16 Jan 2017 09:00:29 +0100MrRaph_http://techan.fr/un-microservice-pour-recuperer-les-ip-dun-service-swarm.html
<p>Ce week-end, je me suis mis en tête de créer un outil qui me permettrait simplement de récupérer les IP d’un service Swarm (lire: <a href="http://techan.fr/creer-des-services-avec-docker-1-12/">Créer des services avec Docker 1.12</a>). C’est à dire, la vIP de ce service, ça c’est facile, mais également les IP de tous les containers composants ce service. Ce besoin m’est apparu car j’ai activé de statistiques dans mes containers Nginx - je décrirai cela dans un article futur. Le problème que je rencontrais était de pouvoir simplement interroger chaque container Nginx pour récupérer ses statistiques d’utilisation. Ceci peut paraître trivial, mais lorsque l’on utilise les services du Swarm Mode, on se retrouve toujours en train d’interroger la vIP du service et on n’interroge ainsi qu’un seul container sans pouvoir simplement spécifier celui que l’on veut.</p>
<p>J’ai donc écrit ce week-end un petit micro service - <a href="https://github.com/MrRaph/api-docker-service-ips"><code>api-docker-service-ips</code></a> - qui me permet de récupérer les IP des containers composant mon service.</p>
<h1 id="le-micro-service-api-docker-service-ips">Le micro service api-docker-service-ips</h1>
<p>Ceci est un micro service écrit en Python avec <a href="http://flask.pocoo.org/">Flask</a> et <a href="http://www.flaskapi.org/">Flask API</a> fournissant une API permettant de récupérer les IP affectées par Docker à un service donné.</p>
<p>Lorsqu’un service est créé dans un cluster Docker utilisant le Swarm Mode, chaque container du-dit service dispose d’une IP qui lui est propre. Ceci ne change pas par rapport à la création classique d’un container. La nouveauté c’est que le Swarm Mode ajoute une vIP et un load balancer en amont de ces containers.</p>
<p>Les adresses IP générées ne sont pas simples à récupérer et ça se complique encore lorsque l’on souhaite les utiliser dans un script ou un micro service. C’est pourquoi j’ai créé ce petit micro service ! :)</p>
<p># Fonctionnement</p>
<p>Ce micro service utilise la librairie <a href="http://www.dnspython.org/">dnspython</a> pour résoudre de manière inverse les noms DNS créés par le Swarm Mode et attachés au service et à ses containers.</p>
<p>Le micro service retourne un object JSON contenant les correspondances en utilisant la forme suivante.</p>
<pre><code>{
'service': name,
'ip': addresses,
'tasks': tasks,
'error': ''
}
</code></pre>
<p><code>name</code> est le nom du service étudié, <code>addresses</code> est un tableau contenant les vIPs du service et <code>tasks</code> est un tableau contenant les IPs des containers. <code>error</code> contient une valeur non vide que quand quelque chose de passe mal.</p>
<h1 id="utilisation">Utilisation</h1>
<p>Tout d’abord, voyons comment récupérer ce micro service.</p>
<p>## Installation</p>
<p>Pour utiliser cet outil, vous avez deux possibilité, soit de le construire depuis les sources - <code>docker build ...</code> - soit de récupérer directement l’image construite depuis le dépôt Git.</p>
<h3 id="build-manuel">Build manuel</h3>
<p>Afin de construire l’image par vous même, vous devrez dans un premier temps, clone le dépôt Git.</p>
<pre><code>git clone https://github.com/MrRaph/api-docker.git
</code></pre>
<p>Puis lancer la construction de l’image Docker</p>
<pre><code>cd api-docker/service-ips
docker build -t mrraph/api-docker:service-ips .
</code></pre>
<h3 id="utilisation-de-l-image-docker">Utilisation de l’image Docker</h3>
<p>Pour utiliser directement l’image Docker éxistant dans le repo, rien de plus simple, il suffit d’utiliser la commande ci-dessous.</p>
<pre><code>docker pull mrraph/api-docker:service-ips
</code></pre>
<p>## Création du service</p>
<p>Maintenant que vous disposez de l’image dans votre infrastructure, il faut créer un service avec. Pour cela, voici la commande à utiliser.</p>
<pre><code>docker service create --replicas 1 --network web \
--restart-condition any --name api-docker-service-ips \
mrraph/api-docker:service-ips
</code></pre>
<p>Ceci va créer un service avec un seul container dans votre cluster Swarm, vous pouvez bien entendu ajouter plus de container en changeant la valeur sur paramètre <code>--replicas</code> ou en utilisant la commande <code>docker service scale api-docker-service-ips=<nombre de containers souhaité></code></p>
<h1 id="récupérer-les-ips-avec-l-outil">Récupérer les IPs avec l’outil</h1>
<p>Rentrons maintenant dans le vif du sujet, voici comment utiliser l’outil api-docker-service-ips pour récupérer les ips d’un service.</p>
<p>### Récupérer la vIP d’un service</p>
<p>Pour récupérer la vIP d’un service, l’outil api-docker-service-ips expose une URL de la forme : <a href="http://127.0.0.1:5000/docker/service/<service_name>/ip">http://127.0.0.1:5000/docker/service/<service_name>/ip</a></p>
<p>Voici un exemple d’utilisation pour récupérer la vIP du service <code>api-docker-service-ips</code> :</p>
<pre><code>curl -X GET http://api-docker-service-ips:5000/docker/service/api-docker-service-ips/ip
{"ip": ["10.0.0.9"], "tasks": ["10.0.0.19"], "service": "api-docker-service-ips", "error": ""}
</code></pre>
<p>### Récupérer les IP des containers d’un service</p>
<p>Pour récupérer les IP des containers d’un service, l’outil api-docker-service-ips expose une URL de la forme : <a href="http://127.0.0.1:5000/docker/service/<service_name>/tasks/ip">http://127.0.0.1:5000:5000/docker/service/<service_name>/tasks/ip</a></p>
<p>Voici un exemple d’utilisation pour récupérer les IP des containers du service <code>api-docker-service-ips</code> :</p>
<pre><code>curl -X GET http://api-docker-service-ips:5000/docker/service/api-docker-service-ips/tasks/ip
{"tasks": ["10.0.0.19"], "service": "api-docker-service-ips", "error": ""}
</code></pre>
<h1 id="sources">Sources</h1>
<ul>
<li><a href="https://github.com/MrRaph/api-docker-service-ips"> GitHub <code>api-docker-service-ips</code></a></li>
<li><a href="https://hub.docker.com/r/mrraph/api-docker-service-ips/">Docker Hub <code>mrraph/api-docker-service-ips</code></a></li>
</ul>
Mettre un container Docker à l'heure !
http://techan.fr/mettre-un-container-docker-a-lheure.html
Wed, 11 Jan 2017 00:00:00 UTCMrRaph_http://techan.fr/mettre-un-container-docker-a-lheure.html<p>Vous en avez marre des container Docker qui indiquent toujours la mauvaise heure ? Cela fausse vos statistiques ? Cela impacte vos cron ? Et bien voici la solution à ce problème ! Il vous suffit d’ajouter ces lignes dans vos Dockerfile !</p>
<pre><code>ENV TZ=America/Los_Angeles
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
</code></pre>
<p>Et voilà ! Adieu la frustration ! :-)</p>
Construire des images Docker du bout du doigt
http://techan.fr/construire-des-images-docker-du-bout-du-doigt.html
Tue, 10 Jan 2017 00:00:00 UTCMrRaph_http://techan.fr/construire-des-images-docker-du-bout-du-doigt.html
<p>Je décrivais il y a quelques jours <a href="http://techan.fr/2017-sera-lannee-de-lautomatisation">comment j’ai automatisé le déploiement de mon blog</a> en utilisant <a href="https://gohugo.io/">Hugo</a>, le <a href="https://hub.docker.com">Docker Hub</a> et quelques outils personnalisés. J’ai écrit un article il y a quelques temps de cela pour expliquer comment <a href="http://techan.fr/publier-automatiquement-sur-facebook-les-nouveaux-posts-dans-hugo">poster automatiquement les nouveaux articles sur les réseaux sociaux</a>.</p>
<p>Jusqu’à présent, le blog était reconstruit à chaque fois que je faisait un commit dans le dépôt Git. C’est pratique mais parfois cela ajoute un petit peu de lourdeur, en effet, il fait quelques minutes pour que l’image soit construite. Par ailleurs j’ai remarqué qu’à un instant T je ne pouvais avoir que deux constructions en même temps pour une image donnée sur le <a href="https://hub.docker.com">Docker Hub</a>, une en cours de construction, l’autre en file d’attente.</p>
<h1 id="le-problème">Le problème</h1>
<p>Ce comportement m’était problématique surtout lorsque je dois modifier des éléments de style sur le site. Ces modifications m’amènent à faire des commit fréquents et attendre que l’image soit construite pour valider le résultat, modifier de nouveau si je ne suis pas satisfait, attendre de nouveau. Des que deux push sont déjà en cours de construction dans le <a href="https://hub.docker.com">Docker Hub</a>, les suivants sont ignorés par ce dernier tant qu’il n’y a pas de place disponible dans la file.</p>
<p>Afin de simplifier et accélérer le processus de développement et d’écriture de nouveau contenu, j’ai donc désactivé la fonctionnalité de construction automatique lorsqu’un push est réalisé dans Git.</p>
<p>Ceci se passe dans le <a href="https://hub.docker.com">Docker Hub</a>, plus précisément dans les “Build Settings”.</p>
<p><img src="http://techan.fr/images/2017/01/docker_hub_disable_auto_builds.jpeg" alt="Docker Hub désactiver les builds automatiques" /></p>
<h1 id="la-nouvelle-solution">La nouvelle solution !</h1>
<p>La nouvelle solution que j’utilise est un “build trigger”, cela consiste en une API que l’on appelle avec un token et un payload JSON. Ce dernier permet de spécifier la branche GitHub à partie de laquelle construire l’image.</p>
<p>L’activation du “build trigger” se fait également dans les “Build Sertings”.</p>
<p><img src="http://techan.fr/images/2017/01/docker_hub_build_triggers.jpeg" alt="Docker Hub activer le build trigger" /></p>
<p>Notez bien l’URL que vous donne le <a href="https://hub.docker.com">Docker Hub</a>, elle va servir dans <a href="https://ifttt.com">IFTTT</a>.</p>
<p>Et maintenant, <a href="https://ifttt.com">IFTTT</a> arrive de nouveau sur le devant de la scène. La plateforme permet de déclencher des actions lors d’un tap sur un bouton virtuel.</p>
<p>Le déclencheur est donc le service “Button Widget” et le service déclenché est le désormais incontournable service “Maker” !</p>
<p><img src="http://techan.fr/images/2017/01/ifttt_button_maker.jpeg" alt="IFTTT service Bouton et Maker" /></p>
<p>L’utilisation du service Maker se fait comme décrit dans l’image suivante.</p>
<p><img src="http://techan.fr/images/2017/01/ifttt_button_push_to_trigger_build.png" alt="Recette IFTTT pour déclencher le build" /></p>
<p>Tout d’abord, on renseigne l’URL que l’on a récupérer dans les “Build Settings” de notre repository Docker. On spécifie ensuite les caractéristiques de l’appel HTTP, il s’agira d’une requête POST et le type de données sera <code>application/json</code>. Dans le body de le requête, on va donner des paramètres qui permettront au <a href="https://hub.docker.com">Docker Hub</a> de choisir la bonne branche de le dépôt GitHub.</p>
<pre><code>{"source_type": "Branch," "source_name": "next"}
</code></pre>
<p>Avec cette ligne, je demande au <a href="https://hub.docker.com">Docker Hub</a> d’utiliser la branche ‘next’ de mon dépôt.</p>
<p>Il ne nous reste plus qu’une toute petite étape, sur notre iPhone cette fois, ajouter un petit widget pour lancer le build des images. Pour cela, il faudra que vous ayez installé l’<a href="https://itunes.apple.com/fr/app/ifttt/id660944635?mt=8&at=1001lsQf" style="display:inline-block;overflow:hidden;background:url(//linkmaker.itunes.apple.com/assets/shared/badges/fr-fr/appstore-lrg.svg) no-repeat;width:135px;height:40px;background-size:contain;">app IFTTT</a>
<a href="https://itunes.apple.com/fr/app/ifttt/id660944635?mt=8&at=1001lsQf">app IFTTT</a></p>
<p><img src="http://techan.fr/images/2017/01/ifttt_widget_build.jpeg" alt="iOS widget IFTTT pour déclencher le build" /></p>