Faire tourner tus en production
En 2013, nous nous sommes donné pour mission de rendre le monde un peu meilleur en réglant le problème du téléversement de fichiers pour tout le monde. Pour cela, nous avons développé un protocole ouvert de téléversement fiable de fichiers, appelé tus. La route a été longue, semée de revers et de jalons, mais aujourd’hui, nous célébrons la prise en charge complète de tus par l’API de Transloadit. Nous progressons déjà bien dans la mise à jour de tous nos SDK afin qu’ils prennent eux aussi en charge tus. Nous sommes ravis de pouvoir offrir ses capacités robustes d’ingestion de contenu à tous nos clients.
Tout le monde ne bénéficie pas d’une connexion internet rapide et stable. Même dans les pays développés, les gens subissent souvent de mauvaises connexions, par exemple en train, en descendant à la cave, ou lorsqu’ils vivent dans des zones plus rurales. Un Wi-Fi capricieux est aussi une source fréquente de problèmes. Et lorsque l’utilisateur de votre application téléverse une vidéo de 100 MB et que sa connexion lâche après 90 MB, c’est sans doute assez frustrant pour lui ôter toute envie de recommencer le téléversement depuis le début.
Une mauvaise qualité de connexion nuit à l’image de votre application, et vous risquez de recevoir une frustration qui devrait en réalité viser les opérateurs réseau ou les sources d’interférences Wi-Fi.
Ce problème s’aggrave de jour en jour : de meilleurs appareils photo sortent et font exploser la taille des fichiers, tandis que la fiabilité des connexions réseau reste la même.
La solution à un problème courant
Avec tus, ce problème appartient au passé. Nous ne pouvons pas réparer les mauvaises connexions réseau, mais nous pouvons faire en sorte que les téléversements reprennent automatiquement exactement là où ils se sont interrompus. Si tout se passe bien, l’utilisateur final ne remarquera probablement même pas l’interruption. Le site web ou l’application téléverse immédiatement les octets restants, et l’utilisateur n’est pas interrompu dans son élan.
La reprise des téléversements de fichiers est possible depuis un certain temps, mais il n’a jamais existé de standard ouvert pour cela, ce qui a donné naissance à mille projets d’une semaine, incompatibles entre eux et fonctionnant à peine. Lorsque nous avons décidé d’agir sur la fiabilité du téléversement de fichiers, nous ne voulions pas devenir l’un de ces projets. Nous savions que concevoir un nouveau protocole ne serait pas facile, mais c’était selon nous la seule bonne voie à suivre – alors nous nous sommes lancés.
Les difficultés en chemin
Nous avons mis tout notre cœur dans ce protocole et beaucoup travaillé. Nous nous sommes heurtés à des murs, notre moral en a pris un coup, et nous avons même parfois complètement arrêté d’y travailler. Mais nous avons toujours repris des forces et essayé de nouvelles approches. Marius mérite tout particulièrement d’être salué pour nous avoir sortis d’une situation difficile. En tant que chef de projet, il a supervisé les retours d’ingénieurs de Vimeo, Google, Yahoo, ZeroMQ et Node.js, et a décidé en grande partie de ce qui devait être inclus et de ce qui devait être laissé de côté.
Après toutes ces difficultés, ce fut un immense soulagement de pouvoir enfin procéder à la publication de tus 1.0. Nous avons immédiatement constaté une hausse de l’implication de la communauté et de nombreuses implémentations de tus dans les langages de programmation préférés de chacun. Avec la v1.0, les développeurs pouvaient désormais avoir la certitude que leur composant fonctionnerait de manière fiable avec d’autres composants tus pendant des années. Les meilleures implémentations de la communauté sont depuis devenues des implémentations officiellement prises en charge, hébergées sous notre toit commun à l’adresse https://github.com/tus/. Ce sont des bibliothèques que n’importe quel développeur peut désormais simplement intégrer à son application pour améliorer la vitesse et la fiabilité des transferts.
Voir la communauté tus grandir au fil du temps a été un vrai plaisir et, par exemple, l’adoption de tus par Vimeo a aussi été une grande victoire pour le projet. Leur soutien a été tout simplement formidable, tant sous forme d’idées que de contributions de code.
Aujourd’hui, nous célébrons donc le fait d’avoir aussi doté notre propre API des capacités de reprise des téléversements de fichiers de tus. En réalité, nous avons opté pour un lancement en douceur et avons progressivement fait passer davantage d’utilisateurs à tus lorsque c’était possible. Quelques mois et un demi-pétaoctet (soit 500 millions de photos) plus tard, des utilisateurs finaux du monde entier profitent d’un téléversement de fichiers fiable grâce à tus, sans même s’en apercevoir. Tout « fonctionne, tout simplement », même les plus grosses vidéos de chats survivent à une descente à la cave. Et c’est ainsi que les choses doivent être : si vous le remarquez, c’est que nous avons échoué.
Prise en charge côté client
Si vous êtes déjà client de Transloadit, il y a de fortes chances que votre logiciel ne communique pas directement avec notre API, mais que vous utilisiez plutôt l’un de nos SDK. Avec un SDK, vous profitez de nos bonnes pratiques dès le départ et vous évitez d’écrire du code passe-partout dans votre langage de programmation. La bonne nouvelle, c’est que bon nombre de nos SDK prennent en charge tus. Voici une liste mise à jour automatiquement (n’hésitez donc pas à revenir la consulter à tout moment) :
| Plateforme | SDK | Prise en charge de tus |
|---|---|---|
| Android | SDK Android | Oui |
| Navigateurs | Navigateurs | Oui |
| Convex | Convex | Oui |
| cURL | cURL | Non |
| Go | SDK Go | Non |
| Java | SDK Java | Oui |
| Agents | Serveur MCP | Oui |
| Navigateurs anciens | Formulaire multipart | Non |
| Node.js | SDK Node.js | Oui |
| PHP | SDK PHP | Non |
| Python | SDK Python | Oui |
| Ruby | SDK Ruby | Non |
| Terraform | Terraform | Non applicable |
| iOS & macOS | TransloaditKit | Oui |
| Zapier | Intégration Zapier | Oui |
Si vous utilisez l’un des SDK qui prennent déjà en charge tus, vous avez de la chance ! Il vous suffit de passer à la dernière version majeure, et la reprise des téléversements de fichiers sera activée par défaut. Pour nos autres SDK, nous travaillons à déployer progressivement la prise en charge de tus sur l’ensemble de la gamme, alors restez à l’écoute. Si vous êtes un développeur qui souhaite s’impliquer dans tus ou dans l’amélioration de nos SDK, n’hésitez pas à nous contacter, car nous serions ravis de discuter de vos idées d’amélioration.
Côté client et navigateur, il convient de saluer tout particulièrement le solide travail de fiabilité réalisé par notre équipe Uppy. En plus de prendre entièrement en charge tus, elle a aussi créé un plugin qui vous permet de reprendre les téléversements de fichiers après un plantage du navigateur. Nous sommes fiers de dire que ce sont deux premières dans le secteur !
Les rouages 🔩
Cette section décrit notre infrastructure au moment de la publication en 2017, et non notre architecture de déploiement actuelle. Le tableau des SDK ci-dessus reflète la documentation actuelle.
L’essentiel du travail a porté sur le protocole lui-même et sur la mise au point de ses implémentations avec la communauté. Une fois ces éléments bien en place, il a été assez simple de brancher tus sur notre service existant d’encodage et de téléversement.
Nous faisons tourner un serveur tusd standard sur toutes nos machines
qui traitent les téléversements, aux côtés de notre logiciel de réception existant.
HAProxy redirige toute requête adressée à /resumable/*
vers l’instance tusd qui tourne sur la machine concernée.
Tout SDK compatible avec tus crée une Assembly comme
d’habitude, mais au lieu de téléverser immédiatement, l’Assembly
renvoie un point de terminaison tus /resumable/ qui accepte les téléversements.
Lors du téléversement vers ce point de terminaison tus, le SDK joint l’emplacement unique de
l’Assembly sous forme de métadonnées. Chaque fois qu’un
téléversement se termine, un hook tusd se déclenche et interprète ces métadonnées pour trouver
l’Assembly et l’informer qu’un téléversement est terminé.
L’encodage de ce fichier peut alors déjà commencer, même si d’autres téléversements sont encore en
cours. Le SDK indique aussi combien de téléversements sont attendus, afin que
l’Assembly sache quand elle a terminé et doit vous notifier
les résultats de l’encodage.
Pour que tout tourne sans accroc, nous nous appuyons sur le bon vieux Upstart (pas très différent de
notre façon de faire en 2009) ainsi
que sur le point de terminaison /metrics exposé par tusd. Ce point de
terminaison fournit les chiffres que notre système de mise à l’échelle automatique utilise pour
lancer ou arrêter des instances EC2 selon que la charge augmente ou diminue. Nous envoyons aussi ces
métriques à Librato afin de surveiller de près la santé de nos
processus et d’être informés de tout problème :
Comme nous prévoyons de migrer une bonne partie de notre infrastructure vers
Kubernetes, il est encourageant de savoir que le point de
terminaison /metrics de tusd est déjà compatible avec leur solution de
supervision de référence : Prometheus. Autre élément qui
aidera ceux qui souhaitent déployer des réseaux d’ingestion de contenu de pointe sur Kubernetes ou
sur des plateformes similaires adaptées à Docker (comme Nomad, Swarm, Mesos, etc.) : nous
travaillons à la publication d’une
image Docker officielle _/tusd. Nous
réfléchissons à la possibilité qu’un Kubernetes Operator destiné à
faire tourner un réseau de distribution et d’ingestion de contenu devienne un troisième grand projet
open source complémentaire, après tus et Uppy. Contactez-nous si vous
souhaitez échanger des idées à ce sujet.
Si vous souhaitez faire tourner vous-même des serveurs tus, mais que tous ces conteneurs et serveurs dédiés ne sont pas pour vous, sachez qu’il existe aussi de nombreuses autres implémentations, par exemple pour Node.js, Ruby, PHP, Python, etc., que vous pouvez utiliser avec votre serveur web existant. Il suffit d’ajouter un peu de code à votre application existante. Toutes les implémentations sont sous licence MIT (c’est-à-dire gratuites et libres à tous points de vue), cela ne vous coûtera donc que quelques minutes de votre temps.
En conclusion
Lorsque nous avons parlé de tus pour la première fois en 2013, nous nous attendions soit à échouer rapidement et lourdement, soit à réussir en moins d’un an. Il s’avère que vouloir bien faire les choses n’est pas forcément le chemin le plus court ni celui de la moindre résistance.
« Ça a pris beaucoup de temps, mais je sais qu’un changement va venir »
— Sam Cooke
Vous imaginez sans doute à quel point nous nous réjouissons de voir enfin ces investissements open source de long terme prendre vie, arrivés à une maturité suffisante pour la production et prêts à servir, non seulement au bénéfice de nos clients, mais aussi pour redéfinir un écosystème dont nous ne sommes qu’une toute petite partie.
Merci de nous avoir suivis jusqu’au bout, nous espérons que l’attente en valait la peine !
Si vous souhaitez en savoir plus ou nous aider à améliorer le téléversement de fichiers pour tout le monde, rendez-vous sur tus.io et uppy.io. Comme toujours, vos avis sont également les bienvenus via notre page d’assistance ou sur HN/Reddit.