53: Codez, isolez, déployez

Les liens

  • quand on perd sa clé FileVault, on pleure, on peste, on prie pour avoir une backup non chiffrée quelque part. sauf quand on a accès au code source. Un intrépide a perdu son mot de passe pour l'équivalent de FileVault sous OpenBSD mais ça ne l'a pas empêché de parcourir le code pour fabriquer son outil de brute force. Il a réussi et nous raconte tout ça sur son blog. Lien
  • Vous avez une super idée d'app ? Votre boulot vous fait chier ? Avant de tout jeter par la fenêtre, voici le deuxième lien qui vous explique comment tester le potentiel de votre idée. Lien
  • Et un nouveau malware pour OSX. Celui-ci est multi-plateforme (écrit en C++) et pique tout ce qu'il peut piquer. Le billet inclus la liste (connue) des endroits où ce trojan s'installe. Lien
  • Le télétravail, c'est pas si évident que ça. Si vous y êtes, ou que vous y pensez, voici 8 astuces pour maximiser le fait de bosser de chez soi. Dans mon cas, l'astuce a été de dédier une pièce complète de la maison au travail et d'y installer la clim. (Et oui, il fait chaud toute l'année à Tahiti) Lien
  • Et c'est trop bon poun ne pas le mentionner: Les batteries des Samsung Note 7 explosent. C'est peut être pour ça que ce mobile est water-proof, pour pouvoir le plonger dans l'eau quand il prend feu . Lien

Le sujet

Donc, Docker.

Après la longue introduction de la semaine dernière, nous allons pouvoir rentrer dans le vif du sujet.

Donc, Docker, c'est une société. Elle offre un produit basé sur une suite d'outils du noyau Linux qui permettent d'isoler un processus pour lui faire croire qu'il est le seul à tourner. Ça marche pour le réseau, les volumes, les sockets, les pid et d'autres que j'oublie.

C'est pour cela que Docker est souvent qualifié de machines virtuelles light. Ce qui n'est pas vraiment exact puisque ça reste un processus qui est exécuté dans un kernel Linux. On peut faire tourner Docker sur macOS (en utilisant d'ailleurs une machine virtuelle pour faire tourner Linux), mais on ne peut pas faire tourner un soft macOS dans Docker, puisque, encore une fois, tous les outils/programmes permettant l'isolation de chaque processus sont propres au noyau Linux.

Du coup, Docker, c'est principalement deux choses: les images et les containers. L'image, c'est la classe, le container, c'est l'objet. Pas besoin d'aller chercher plus loin. Docker encourage d'ailleurs fortement de se baser sur des images afin de faciliter la réutilisation. Une image très populaire est la busybox, qui regroupe un noyau linux et les utilitaires les plus courant en seulement 5Mo. Oui, 5Mo. On n'est pas loin de l'unikernel.

Deux autres concepts important dans Docker sont le registry et le network. Le registry, c'est l'équivalent d'un Github pour les images. On peut y pousser (pusher) ses images de façon publiques ou privés. Mais le registry étant une appli web et packagé en image Docker, il est possible de faire tourner son registry privé.

Le network est là où Docker devient intéressant. Il est possible de créer des réseaux virtuels et d'y adjoindre des containers à la volée. Petit détail: lorsque vous démarrez un container (à partir d'une image donc), vous pouvez lui donner un nom. Lorsque vous ajouter un container à un réseau, son nom de container devient son nom DNS.

Si vous définissez à l'avance que vous aurez un container nommé "webapp" et un container nommé "mysql", vous pourrez utiliser le nom d'hôte "mysql" dans la configuration de votre webapp. Vous pourrez donc à n'importe quel moment stopper ou détruire le container, le relancez en l'ajoutant au réseau virtule, avec le même nom et votre container "webapp" pourra le retrouver.

Bon, oui, on utilise un load balancer pour ce genre de chose. Et bien ça marche pareil puisqu'on fixe le nom du load balancer et qu'on le renseigne dans la configuration de la webapp.

Alors, bon, OK, c'est la théorie, mais pourquoi Docker, c'est si génial ?

En développement, ça vous permet d'avoir chaque bordel, euh, app, isolé de toutes les autres. Un peu comme une sorte de rbenv dans le système. Dans le monde iOS, c'est peu nécessaire vu qu'Apple fourni tout, mais au fur et à mesure que Swift grandit, il sera bon de ne pas trop brusquer Xcode qui est quand même très sensible. D'aileurs, Kitura, le framework web d'IBM, fournit une image Docker. Vous pouvez donc le tester avec la version de Swift qui va bien sans que votre Xcode ne voit quoi que ce soit.

En mise en production, il y a le grand avantage de construire l'image. Puisque chaque container est isolé de tout le reste, vous pouvez spécifier toutes les dépendances que vous voulez. Il est donc impossible d'avoir des problèmes de mises en production. Si cela marche sur votre machine, ça marchera en prod.

Enfin, en production, si l'app crashe, elle n'affecte rien et vous pouvez relancer un container. Vous pouvez d'ailleurs indiquer à Docker, lors de la création du container, que si ce dernier s'arrête, il doit être relancé automatiquement.

Il y a également d'autres outils comme Docker Compose ou Swarw, qui facilite la vie d'un sysadmin. Docker Compose permet de lancer plusieurs containers en spécifiant leurs inter-dépendance, alors que Swarm permet de faire de l'orchestration. C'est moins utile pour nous.

Pour conclure, mon message, pour reprendre l'intro de la semaine dernière, est qu'un dev iOS est amené à évoluer et que la meilleure évolution possible est d'aller voir à l'autre bout, dans le back-end, comment les choses se font.

Coup de bol, cela nous est maintenant beaucoup plus accessible depuis que Swift existe réellement sur Linux et que des frameworks Web tels que Perfect ou Vapor gagnent en solidité tous les jours. J'espère donc que vous n'attendrez pas pour coder une webapp en Swift packagé en image Docker. Et mine de rien, ça facilite toujours la conversation avec les admins quand ils voient qu'on connait un peu leurs problématiques.

FrenchKit

Pique de rapple, FrenchKit, c'est le 23 et 24 septembre à Paris, c'est à dire dans 12 jours ! J'espère que vous avez tous vos billets.

A vot' bon cœur m'sieur-dame

Le lien du podcast sur iTunes