[NE PAS MERGER, WIP] PR expérimentale de conversion GTFS vers GeoJSON à la volée

[thbar]

Je réalise une première PR à ne pas merger, dont le but est simplement de voir si on parvient à lancer le programme qui nous intéresse (https://github.com/rust-transit/gtfs-to-geojson) sur CleverCloud, à l'intérieur de Docker, et via le processus Elixir principal.

Pour l'instant:

• je compile le binaire Rust à la volée (on fera à terme une image Docker avec tous les binaires qui nous intéressent)
• je lance directement le binaire via une URL du backoffice
• je permets de passer une URL de GTFS, et je recrache l'output (STDOUT) comme body HTTP

Ca ne fonctionne pas en l'état (exit code 1), je suis en train d'ajouter du logging pour comprendre, voir si c'est lié à MuonTrap (dont j'ai lu qu'il pouvait rencontrer des soucis avec Docker) ou autre chose, et trouver petit à petit un moyen de lancer cela.

À terme il faudra avoir les binaires disponibles, avoir un contrôle de la mémoire idéalement (ou au moins une idée de la charge mémoire max, en benchmarkant les GTFS existant), et isoler le processus sur une instance dédiée afin de ne pas crasher le site.

Commandes locales

docker build -t localtest .
docker run -dp 8080:8080 localtest

[thbar]

À ce stade j'ai eu une erreur (exit code 1). J'ai eu l'idée d'aller me logger en SSH, et lancer la commande via iex -S mix, puis de lancer MuonTrap.cmd. Le binaire n'est pas trouvé alors qu'il est là.

Même chose directement dans le shell bash.

Je pense qu'il y a sûrement un souci d'architecture ou de librairie dynamique non trouvée:

# file gtfs-geojson
gtfs-geojson: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=eee5a5732eefb2fd22515ccebd436ac85e33004a, stripped

Si je fais idem avec un autre binaire déjà installé et qui fonctionne, on voit des références différentes:

# file /usr/bin/gcc
/usr/bin/gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, stripped

Je remarque :

• /lib64/ld-linux-x86-64.so.2 n'existe pas sur le serveur
• le serveur est en Linux 5.12.19+ (et gtfs-geojson cible Linux 3.2.0)

Je vais plancher sur ces points, et notamment travailler en local dans Docker pour reproduire ce point et voir si je peux trouver quelque chose de simple pour avancer.

[thbar]

Je tente de basculer la distribution de l'étape de construction du binaire rust sur alpine (comme Elixir) pour régler le "not found". Je tombe sur un autre problème lié à alpine et proc-macro-hack:

#8 54.44    Compiling crc32fast v1.2.0
#8 54.46    Compiling openssl-probe v0.1.4
#8 54.50    Compiling tower-service v0.3.0
#8 54.52    Compiling encoding_rs v0.8.24
#8 54.61 error: aborting due to previous error
#8 54.61 
#8 54.62 error: could not compile `proc-macro-hack`
#8 54.62 
#8 54.62 To learn more, run the command again with --verbose.
#8 54.62 warning: build failed, waiting for other jobs to finish...
#8 55.53 error: build failed

Pour des soucis similaires, voir:

• Build fails with can't find crate for proc_macro on musl target dtolnay/proc-macro-hack#6
• cannot produce proc-macro when --target is set on musl host toolchain rust-lang/cargo#7563

[thbar]

J'ai fait une bascule temporaire sur une image "ubuntu focal" et j'ai pu requêter une conversion faite en direct

(nécessite un login via le backoffice en l'état, pour protéger la config)
https://prochainement-transport.cleverapps.io/backoffice/labs-convert-gtfs-to-geojson?input=https://zenbus.net/gtfs/static/download.zip?dataset=tignes

[fchabouis]

La PR nous a appris ce qu'elle devait nous apprendre, elle sera découpée en plusieurs PR indépendantes.