Tilt - Gérer l’environnement de développement comme du code

• Outil gratuit et open source d’automatisation de l’environnement de développement pour le développement de microservices basé sur Kubernetes
• Automatise le flux modification du code → surveillance des fichiers → build d’image → mise à jour du déploiement, ce qui permet de lancer l’ensemble de l’environnement avec la commande tilt up
• Centré sur Kubernetes, mais prend aussi en charge les workflows basés sur docker-compose ou des commandes locales
• Acquis par Docker en 2022, mais continue d’être maintenu et développé comme un projet open source indépendant
• Vise une gestion unifiée moderne de l’environnement de développement afin de maîtriser la complexité des microservices

---

Qu’est-ce que Tilt ?

• Les applications modernes ne sont pas un binaire unique, mais une structure où plusieurs services, bases de données et serveurs frontend interagissent via HTTP
• Tilt est un outil d’environnement de développement pour microservices qui permet de comprendre et de gérer en une fois ces composants complexes
• Il automatise les modifications de fichiers, le build des images et l’actualisation des serveurs afin d’accélérer le développement

Pour quelles équipes utiliser Tilt

• Convient aux équipes qui développent des applications basées sur des microservices
• Particulièrement utile pour les équipes qui gèrent les logs des serveurs dans de multiples fenêtres de terminal ou qui configurent leur environnement de développement avec des scripts shell complexes
• Avec la seule commande tilt up, tout le monde peut mettre en place facilement le même environnement de développement

Pourquoi se concentrer sur Kubernetes ?

• Kubernetes fournit des blocs standardisés d’exécution de serveurs comme les conteneurs, les pods et les services
• Utiliser ce standard aussi dans l’environnement de développement permet de réduire l’écart entre l’environnement de production et celui de développement
• Tilt prend aussi en charge docker-compose et les commandes locales, mais on s’attend à ce qu’à terme l’ensemble converge vers une approche centrée sur Kubernetes

Développement et avenir de Tilt

• Tilt était à l’origine une startup indépendante, avant d’être acquis par Docker en 2022
• Il reste aujourd’hui open source et continue d’être amélioré en lien avec Docker Compose et Docker Desktop
• De nouveaux projets sont également en cours de développement, avec l’objectif d’étendre les idées de Tilt à un écosystème développeur plus large

Signification du nom

• « Tilt » s’inspire de l’histoire de Don Quichotte chargeant des moulins à vent
• Le nom de l’application de démonstration, Servantes, fait référence à Cervantès, l’auteur de Don Quichotte

[GN⁺]

Avis Hacker News

• Intéressant de voir ce sujet ici. J’utilise Tilt depuis plusieurs années, mais j’ai l’impression que le rythme de développement a ralenti depuis son acquisition par Docker

  • Tilt permet de créer un environnement de développement local afin que les services s’exécutent de la même façon en production, en test et en développement
  • Le code des services a été fortement simplifié et la qualité s’est améliorée
  • Des améliorations sont particulièrement nécessaires sur la gestion des CRD (k8s_yaml n’a aucun moyen d’indiquer qu’il dépend d’une CRD, donc les appels à tilt up cassent souvent)
  • La première chose que je fais quand je démarre un nouveau projet, c’est faire en sorte que tilt up fonctionne
  • Parmi les choses que j’ai testées : des collecteurs basés sur eBPF pour la sécurité et l’observabilité, des data pipelines, le développement de charts Helm, des contrôleurs Kubernetes, etc.
  • C’est très flexible et puissant pour de nombreux types de développement

• Ce pitch me fait un peu rire

  • Les applications modernes sont composées de beaucoup trop de services. Ils sont partout et communiquent en permanence
  • Donc on a créé un outil pour faciliter la création d’encore plus de services

• Il faut toujours faire un compromis entre vitesse et exactitude

  • Si on essaie de maintenir un environnement d’intégration local, cela devient trop lent et trop coûteux
  • Le problème n’est pas Kubernetes en lui-même, mais le fait qu’à mesure que les dépendances augmentent, essayer d’exécuter localement une copie du monde entier devient de plus en plus lent
  • J’aime les environnements de développement rapides et compacts avec quelque chose comme docker-compose, ce qui permet de mocker certaines dépendances pour conserver de bonnes performances. Une fois les tests locaux passés, on utilise Kubernetes dans les autres environnements

• Je pense vraiment qu’un « environnement de développement » doit permettre d’exécuter directement les tests avec les outils natifs du langage, par exemple cargo test, bundle exec rspec, etc.

  • Si je dois lancer une VM qui exécute Kubernetes, qui elle-même exécute des conteneurs Docker pour faire tourner les tests, ça va vraiment m’énerver
  • Faire cela correctement et de manière fiable demande encore beaucoup de travail. Si l’objectif est de ne pas utiliser Docker, cela peut demander encore plus d’efforts (c’est indispensable pour exécuter les choses nativement sur macOS)
  • Il semble y avoir beaucoup d’outils dans ce domaine. J’aimerais qu’ils ne se présentent pas comme des outils pour « l’environnement de développement ». Ils ressemblent davantage à des outils pour « déployer une application sur une machine locale »

• Impossible de ne pas mentionner nix-shell : lien vers nix-shell

• Si vous voulez voir Tilt en action, nous l’utilisons dans notre dépôt open source Chroma pour exécuter une version distribuée de la base de données pour le développement et la CI. C’est vraiment chouette : après le clone, il suffit de lancer tilt up et ça fonctionne

  • lien vers Chroma

• La configuration d’un environnement local n’a jamais été le problème

  • Déployer sur un cluster unique est très simple
  • Le problème, c’est que les services que nous gérons en production sont déployés sur plusieurs régions (ou plusieurs clusters k8s)
  • Le vrai problème, c’est le débogage des applications distribuées

• Comment Tilt se compare-t-il à skaffold dev ? Nous utilisons skaffold pour cet usage, afin de développer directement dans le cluster

• J’ai brièvement essayé Tilt il y a quelque temps. J’ai aussi testé Tilt, Garden, et probablement quelques autres, puis je me suis fixé sur DevSpace

  • De mémoire, c’est celui qui s’intégrait le mieux à notre infrastructure de production existante. Pas besoin de tout réécrire différemment
  • Autrement dit, cela s’accordait bien avec notre configuration existante kustomize + k8s. Il ajoutait le port forwarding et une synchronisation rapide des fichiers vers les conteneurs en cours d’exécution. C’est vraiment tout ce que je veux. Je déteste devoir reconstruire des images à chaque changement

• En substance, n’est-ce pas simplement des dev containers ?