transfer.sh chez soi sur Docker swarm

Cet article a été publié il y a 5 ans 7 mois 12 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Transfer.sh est un site qui permet de faire du téléchargement éphémère, dans la veine de wetransfer, framadrop, dl.free.fr et d’autres que je ne connais pas mais je suis certain qu’ils sont nombreux. C’est aussi un logiciel opensource, la société DutchCoders qui l’a conçu partage le code pour que l’on puisse l’installer chez soi. Et ça tombe bien, puisque je cherche justement ce genre de service à installer sur mon cluster swarm. Mais ça s’est accompagné de quelques challenges, qui méritent un retour d’expérience.

Petit rappel sur le service

Donc, le service permet de déposer des fichiers simplement et de les partager pendant une durée de 14 jours. Sa particularité qui me plaît beaucoup, c’est la possibilité de passer un fichier via la ligne de commandes. C’est cool, ça permet d’envoyer un fichier directement depuis un serveur qui ne dispose pas forcément d’interface graphique, via curl (il y a d’ailleurs plusieurs exemples).

Et les hollandais qui l’ont écrit le maintiennent et le partagent sur Github, donc plein de bonnes raisons de s’y intéresser.

Le go c’est bien, enfin peut-être

J’adore le monde de l’open source. On peut voir des dizaines de solutions écrites dans autant de langages pour un même type de service. J’ai vu du nodejs, du php, Lufi, à la base de framadrop, est écrit en Perl, j’ai vu du Ruby… Et donc transfer.sh est écrit en Go. J’ai pas grand chose à dire sur le langage lui-même ou son utilisation dans le contexte présent, à part qu’il semble prisé des développeurs qui exploitent des applications web. Djerfy qui a commencé à taper dedans pourrait vous en parler, et les devops mouillent leur sous-vetements devant les outils d’Hashicorp qui sont majoritairement écrits en Go.

Mais comme beaucoup de soft dans le genre, les développeurs ne pensent absolument pas au fait que c’est un service et qu’on pourrait disposer d’un script quelconque plutôt que de devoir se démerder tout seul. C’est pas spécifique au langage hein, mais plutôt aux développeurs qui oublient très souvent le monde réel. Ça oblige les admins à chacun réinventer la roue dans son coin (supervisor, systemd, sysvinit, cron…), et c’est pénible.

Et Docker ?

Pareil j’ai envie de dire, si une image Docker est bien fournie pour transfer.sh, on a juste une vague ligne de commande pour le lancement en mode interactif, la « doc » tient en un petit paragraphe. Il faut commencer à fouiller le code, en particulier le Dockerfile, pour commencer à comprendre certaines choses sur l’image. Et retourner sur la documentation pour comprendre pourquoi les premières tentatives de déploiement de stack échouent sur un message foireux « no access key defined ».

En lisant le Dockerfile on voit que l’entrypoint passe des paramètres par défaut qui sont incomplets, puisque le backend de stockage sélectionné est s3 mais il faut manuellement passer les clés en environnement. Si on utilise S3 d’AWS, ce qui n’est pas mon cas. La documentation de docker compose indique qu’on peut surcharger avec la directive « entrypoint: », mais pas de bol, c’est un des rares points qui ne sont pas supportés par Socker Swarm.

La libération vient de la directive command, au début je pensais qu’il fallait repasser la commande complète mais ça ajoute juste le contenu en guise de paramètres supplémentaires à l’exécution. Donc si on veut passer --provider local --basedir /uploads au container, il fait juste le faire comme ça :

La difficulté de la personnalisation

Finalement passé les quelques écueils pour les options de lancement en mode Swarm, le service est très rapidement fonctionnel. Mais un problème apparaît alors : tout est affiché pour le domaine transfer.sh, alors que je suis sur mon domaine perso. Les exemples, les liens, sont tous formatés. Le titre du site aussi.

Il a fallu fouiller de ouf dans les issues fermées du dépôt Github pour trouver un deuxième dépôt contenant les sources HTML/CSS/JS. Et là c’est l’enfer sur terre pour comprendre comment faire fonctionner la « compilation » des fichiers front. Putain, on parle de CSS, JavaScript et HTML, comment on peut avoir besoin de compilation nom de dieu (en minuscules, rappelez-vous pourquoi) ?

D’autant que ça repose sur une tetrachiée d’outils en nodejs, javascript donc, à installer sur son poste. Je passe par une image docker Ubuntu exécutée en local pour installer tout le bordel, histoire de pas saloper mon poste, et c’est long, mais long… Je parviens quand même à comprendre comment ça fonctionne, et finit douloureusement par obtenir le fameux dossier « dist » qu’il faut ensuite déposer sur le cluster, bind-mounter et « activer » via l’option --webdir (à ajouter à command donc).

Je décide à partir de là de continuer mes personnalisations directement depuis ce fameux dossier final plutôt que souffrir avec les outils affreux. C’est chiant parce qu’il y a plein de doublons du coup, mais c’est plus simple. Surtout que j’ai pris une quantité d’alertes de paquets npm obsolètes ahurissant, c’est tellement rassurant quand on doit les lancer…

Voilà donc rapidement, si vous voulez le lancer en mode Swarm chez vous (ou simplement docker-compose), à quoi ressemble le fichier :

Quelques points noirs à traiter

Apparemment, le code est maintenu doucement, en soi c’est pas un gros problème. Il y a par contre un truc qui me gène, c’est que l’appli tourne avec l’utilisateur root. Il y a une issue à ce sujet mais apparemment ils sont pas pressés de traiter ce point. Je vais donc voir si je ne vais pas être obligé de mettre les mains dans le cambouis pour traiter le mal via un Dockerfile adapté. C’est un mal nécessaire si vous tentez de déployer ce service sur un cluster OpenShift, qui interdit l’utilisation de root.

Un autre point chiant, là j’ai pas compris pourquoi, il ne prend pas à chaud les mises à jour de contenus ou de template sans redémarrage de l’application. En soi c’est pas méchant mais ça reste pénible. Le fait est qu’une fois terminé on y touche plus trop, mais bon…