Les dessous de la Stormz Box

  • 15 septembre 2016
  • François
  • Ingénierie

Cela fait un an que nous avons rendu disponible la Stormz Box à nos partenaires. D'extérieur comme d'intérieur, tout avait alors changé.

Rappel

La Stormz Box est un ordinateur avec une borne wifi qui permet de faire des ateliers Stormz jusqu'à 90 appareils connectés sur un réseau local non relié à internet.

Grace à cette box il n'est pas nécessaire de se préoccuper du wifi du lieu de l'événement ni de la stabilité de la connexion. En bref, ça marche.

Le matériel

Les premières Stormz Box (2012-2015) utilisaient un ordinateur portable 12 pouces qui conditionnait la taille de la mallette. Nous embarquons désormais des Intel NUCs.

Coté wifi, nous utilisons encore et toujours les points d'accès double bande de Ruckus Wireless.

Ces deux composants sont alimentés par un transformateur 12V.

Tout cela permet de largement limiter l'encombrement et le poids de l'ensemble.

Le Logiciel

Coté logiciel, tout a changé également:

  • la façon dont les services tournent et communiquent grâce à Docker
  • les mises à jour
  • la simplification du processus de build

Dockerization

Nous avons commencé par décomposer l'ensemble des services de Stormz en conteneurs Docker.
Pourquoi Docker? Pour harmoniser la gestion de la configuration, les logs, simplifier les tests et les dépendances.

La migration vers Docker s'est faite au fur et à mesure. La première étape a été de passer notre environnement de développement de Vagrant vers Docker.

Une fois convaincu, nous nous sommes attelés à la création des images de production.

Nous avons fini par l'automatisation avec notre intégration continue qui construit nos images et les pousse sur le Hub Docker.

Mise à jour atomique

Auparavant nous avions un processus de mise à jour semi-automatisé:

  • allumer et brancher la box en ethernet sur notre réseau au bureau
  • lancer un script qui faisait la mise à jour avec ansible

Mais avec la nouvelle box, nos partenaires étant aux 4 coins du monde, il était nécessaire qu'elles soient réalisables en totale autonomie.

Les mises à jour atomique sont à la mode depuis l'arrivée de Docker. Un écosystème est en train de se créer avec CoreOS, Atomic ou encore Ubuntu Snappy.
Si Atomic utilise OSTree, CoreOS et Snappy utilisent un système à 3 partitions:

  • 2 partitions système dont une inutilisée
  • une partition de données

La mise à jour est placée sur la partition inutilisée et le système redémarre sur celle-ci. Si la mise à jour échoue au boot, le système redémarre sur l'ancienne.

Chez Stormz nous sommes plutôt Debian. Si Snappy a été envisagé, nous l'avons finalement écarté comme les autres. En effet, tous ces systèmes nécessitent d'être connecté à Internet.

Heureusement grub2 inclut tout ce qu'il faut pour faire cela d'une manière assez simple.

Notre système de build construit désormais une image complète du système que nous distribuons à nos partenaires.

Nous évitons ainsi tout problème qui pourrait arriver durant une mise à jour. Dans le pire des cas l'ancien système fonctionne toujours.

Dé-ansiblification

Nos playbooks Ansible, eux, ont eu droit à un régime sévère. Ils contenaient une foule de tâches pour stopper, mettre à jour, redémarrer et nettoyer une box. Avec le passage à des conteneurs, notre playbook de création de mise à jour se résume essentiellement à installer docker et à télécharger nos images.

Le résultat: 52 files changed, 1821 deletions(-)

Et cela n'inclut pas les rôles qui sont encore utilisé par d'autres environnements qui ne sont pas (encore) passé à Docker.

Les prochaines étapes

Nous continuons bien sûr d'améliorer la Box en simplifiant et rajoutant régulièrement de nouveaux services.

Mais nous avons aussi quelques sujets d'amélioration:

  • moderniser le monitoring: nous utilisons encore collectd, alors que nous sommes passé à InfluxDB + Telegraf sur stormz.me
  • permettre la configuration de la borne wifi
  • accélérer la création de la mise à jour et les tests
  • et bien d'autres choses encore !
Se connecter Créer un compte