Bienvenue sur IndexError.

Ici vous pouvez poser des questions sur Python et le Framework Django.

Mais aussi sur les technos front comme React, Angular, Typescript et Javascript en général.

Consultez la FAQ pour améliorer vos chances d'avoir des réponses à vos questions.

Spawner des API HTTP à la demande

+2 votes

Je développe une bibliothèque de robotique que j'utilise sur des robots réels et simulés. L'accès au contrôle du robot peut se faire soit en python soit avec une api HTTP actuellement servie par Tornado en utilisant Bottle.
Pour compliquer la chose, la lib python fait tourner pas une mais deux api HTTP, l'une communiquant à un visualisateur JS, et l'autre à une interface de programmation par block (en js aussi).

un magnifique schéma de mon application

Afin de permettre à n'importe qui sans installer Python sur sa machine (et des grosses lib scientifiques comme scipy et numpy) d'utiliser les robots simulés, je souhaiterai mettre en place un système qui spawn une instance de mon robot virtuel à la demande avec un accès public.

Je voudrais que l'utilisateur se connecte sur http://URL/get/id reçoive un id temporaire (appelons le random_id) et qu'il puisse ensuite commander le robot simulé via http://URL/simu/radom_id/

En explorant les solutions possible, j'ai trouvé Beaker qui peut être utilisé en midleware afin de gérer des sessions d'une app comme Flask.
Dans mon cas cela me semble compliqué à utiliser car je n'ai pas une mais deux api, et que je comprends mal comment Beaker pourrait re-instancier un robot à chaque nouvelle session.

J'essaie de trouver des choses avec docker, qui permettrait à partir d'une API rest d’appeler une image (correspondant au gros bloc de mon schéma) et de router mes deux serveurs sur une URL dynamique (le random_id), mais je ne trouve rien de concluant.

J'ai l'impression que c'est un problème assez banal, je n'ai peut être pas les bon mots clés... Avez vous des idées ?

demandé 21-Jan-2016 par showok (212 points)
edité 21-Jan-2016 par foxmask

du but en blanc, pour la "tuyauterie", j'aurai dit "crossbar + autobahn|js et/ou autobahn|python"

L'utiliser n'implique pas de toucher à son API Rest. Ca plug/fait se parler, des composants entre eux, à travers le réseau ou pas selon les besoins.

J'essaie de trouver des choses avec docker, qui permettrait à partir
d'une API rest d’appeler une image (correspondant au gros bloc de mon
schéma) et de router mes deux serveurs sur une URL dynamique (le
random_id), mais je ne trouve rien de concluant.

Peux-tu développer ce point? Car avec un docker, t'auras rien à installer, juste un

// j'oublie exprès les option de docker pour pas faire trop compliquer
docker run monModule

Et ça devrait rouler comme sur des roulettes, sur linux out of the box, et sur windows/mac via une VM pour y faire tourner le docker.

Si tu configure bien ton dockerfile (le truc qui te dit quoi faire dans ton conteneur, par ex lancer tel et tel serveur à tel et tel port, installer ça et ça ...) ça a l'air d'une solution portable, out of the box qui ne devrait pas poser de problème

L'idée est d'avoir un container instancié pour chaque utilisateur.
En configurant mon docker file je décris en dur vers quelle url je veux router mon container ; moi je voudrais router dynamiquement mon container vers un URL avec un random_id temporaire dépendant de chaque utilisateur, et qu'à la fin de la session le container soit détruit.
C'est possible de le faire, mais je vois mal comment rester simple.

Heu, ce ne sont que des urls, pourquoi creer un container par user? Avec le random_id, on peut bien savoir quel user demande quel action du robot non?!

Ds tous les cas, que tu pourrais faire, c'est permettre a tes users de s'inscrire via un formulaire web. Stocker les infos relatives au user (entre autre, le fameux ramdom_id), et une fois ces infos stockées,
- demarrer un noveau container
- boostrap ce nouveau container en y installant le necessaire + le robot
- recuperer les urls liées a ce container et les envoyer au user

Pour scripter la creation de nouveau containers, il existe tellement de maniere de faire qu'on en perd son latin. La plus simple etant pr moi, python-lxc pr manipuler des containers lxc via python (oui, je prefere lxc a docker).

Si j'ai le temps, peut etre que je reviendrai avec un code ecrit fait juste pr le POC. En attendant, voici un lien et en voila un autre pr mieux comprendre de quoi je parle

Un container par user car chaque user doit avoir son propre simulateur, indépendant des autres.
Merci pour les liens.

1 Réponse

+4 votes
 
Meilleure réponse

tmpnb.org fait à peu près ce que je souhaite pour des notebook jupyter un utilisant docker. Je pense que je vais simplement modifier les images pour l'adapter à mes besoins.

Leur schéma est plus clair que le mien, pour ceux que ça pourrait intéresser
tmpnb

Merci de votre aide !

répondu 21-Jan-2016 par showok (212 points)

Et pour tes conteneurs, l'idéal est d'utiliser les images baseimage ou alpine pour réduire leur taille.

@DoubleNain Le problème est que toutes les images minuscules comme alpine n'ont pas glibc ce qui empêche d'installer miniconda.
la plus petite image avec glibc est debian:jessie.

EDIT: en installant glib sur alpine on gagne en place quand même. Voir l'exemple de c12e/alpine-miniconda.

...