TechAN

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 ?

Il n’est pas rare de constater que l’espace disque consommé par Docker dans ses dossiers internes - par défaut sur Linux : /var/lib/docker - augmente régulièrement, parfois jusqu’à la saturation du file system. Si disque contenant le dossier /var/lib/docker 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.

La surveillance du processus principal c’est bien mais … Les “Health Checks” 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 CMD ou ENTRYPOINT des Dockerfiles. On constatait alors qu’un container mourait lorsque le daemon Docker ne détectait plus ce processus principal.

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: Créer des services avec Docker 1.12). 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.

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 ! ENV TZ=America/Los_Angeles RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone Et voilà ! Adieu la frustration ! :-)

Je décrivais il y a quelques jours comment j’ai automatisé le déploiement de mon blog en utilisant Hugo, le Docker Hub et quelques outils personnalisés. J’ai écrit un article il y a quelques temps de cela pour expliquer comment poster automatiquement les nouveaux articles sur les réseaux sociaux. 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.

Les constatations En ce début d’année, vous aurez peut être remarqué quelques changements sur mon blog. J’ai en effet pris la décision de ne plus utiliser Ghost ce moteur de blog m’a pourtant donné satisfaction, il est rapide et efficace. Mais il souffre encore de pas mal de manques … Dans un premier temps, Ghost nécessitait une base de données, alors certes on peut l’utiliser avec une base SQLite mais étant donné le nombre d’heures passées à écrire mes articles, je préférais être sûr, et j’avais opté pour MySQL.

Depuis mainteant presque huit mois, je n’utilises plus qu’Ubuntu pour mes besoins professionels. Bon, je l’avoue tout de suite, j’ai quand même une VM Windows pour certains besoins - client VPN exotiques, applications très spécifiques, … J’ai réussi à trouver une solution satisfaisante pour tous mes besoins. Je travaille sur un poste Lenovo, autant dire que je n’utilise pas le pavé tactile, en fait, je n’utilise ces choses que sur mon Mac.

Docker à la fâcheuse tendance de laisser trainer ses jouets un peu partout, notamment les containers qui ont crashés, qui n’ont pas démarrés et les images qui ne sont pas liées à des containers. Ce mécanisme est intéressant pour débugger, savoir pourquoi les containers n’ont pas démarrés, pour mon application fonctionnait avec une ancienne version de l’image mais pas avec la nouvelle. Bref, dans un environnement de développement, ce bazare est important, en production également mais dans une moindre mesure.