Discussion :

[esperanto]

Bonjour

J'ai créé une petite application Ruby+Postgres que j'exploite déjà en SaaS sur un serveur dédié, pour le moment sous une forme mutualisée: chaque client a son propre "catalogue" Postgres, Apache gère des sous-domaines, mais tout ça directement sur le serveur. Dans cette configuration il est facile d'automatiser via des scripts: chaque fois qu'un client passe une commande pour une nouvelle base, un script crée le catalogue Postgres et Apache se débrouille avec les sous-domaines.

Pour des clients demandant des plus gros volumes je voudrais maintenant proposer du semi-dédié, autrement dit des VPS. J'ai déjà fait le test, mon application tient bien sur un VPS avec 2 Go de RAM. La question est de savoir si je vais pouvoir automatiser la création des VPS comme j'ai pu le faire pour les hébergements mutualisés.

Pour le moment j'ai envisagé deux solutions que je voudrais discuter ici. Si vous pensez à une troisième voie, je reste ouvert.

La première solution serait de louer un serveur dédié et de le diviser en VPS via la solution que proposent les hébergeurs (VmWare ou ProxMox)
Les questions que je me pose:
- J'ai déjà vu dans le tutoriel publié ici qu'on peut créer des templates de VPS donc les dupliquer facilement. Mais ces solutions proposent-elles une API me permettant de dupliquer un template via un script?
- Est-ce que chaque VPS aura sa propre IP ou vais-je devoir créer un système complexe de NAT? En sachant que pour utiliser mon application les utilisateurs doivent avoir un accès HTTPS mais aussi un SFTP, et peut-être même un ssh pour les plus aguerris (par contre pas d'accès direct à Postgres, à priori)
- sur un serveur dédié, puis-je de façon réaliste héberger des dizaines de VPS (en additionnant juste les quantités de RAM et de disque dur) ou y a-t-il une règle sur le nombre de CPU virtuels qu'on peut déployer en fonction des caractéristiques du CPU réel?
Si j'ai d'autres questions je reviendrai éditer plus tard.

L'autre solution à laquelle je pensais, c'est ce que les hébergeurs appellent les "packs revendeur". J'ai conscience que je sors un peu du cadre de la rubrique, mais je préfère avoir toutes les infos au même endroit.
Je n'ai pas essayé, j'ai seulement lu. Quelqu'un a déjà essayé ces packs? Est-ce qu'on peut créer son propre template de VPS ou seulement héberger les solutions proposées de base? Est-ce qu'on dispose d'une API pour intégrer leurs outils à notre propre outil e-commerce ou dois-je ensuite aller manuellement sur une interface pour créer un VPS par client?

Voilà où j'en suis pour le moment, je reste ouvert à d'autres suggestions.

[binarygirl]

Bonjour,

Puisque vous utilisez des sous-domaines, vous n'avez pas besoin d'octroyer une adresse IP à chaque client: une adresse IP peut héberger autant de noms de domaines que vous voulez. C'est déjà une bonne nouvelle.

En revanche, il n'y a pas de segmentation stricte au niveau réseau. Un client connecté en SSH avec des droits root donc par exemple pourrait sniffer du trafic d'autres clients potentiellement. Mais je pense qu'on peut résoudre ça avec des VLAN.
L'implémentation dépend du stack technologique que vous allez adopter, moi-même je n'ai pas toutes les réponses, c'est à étudier. Je vous conseille de vous rapprocher de votre hébergeur, car même si vous êtes en dédié, ils doivent avoir des solutions à vous proposer.

Vous pourriez aussi utiliser un modèle de container comme docker et exposer les services souhaités en fonction du client. Cette solution peut être plus économe que d'émuler une machine complète pour faire un VPS. Mais alors on se retrouve peut-être avec du NAT à moins que là aussi le VLAN suffise.

En tout cas, ça se résume à deux services à exposer: SSH & SFTP (port 22) et https (443). Je crois qu'on peut opter pour une solution plus minimaliste qu'un VPS mais il faut voir si ce partage de ressources physiques est compatible avec les éventuelles garanties de service et de disponibilité que vous offrez. Il faudra faire du monitoring continu et provisionner soigneusement.

[chrtophe]

Je pense que l'idée de conteneur de binarygirl est la plus adaptée, il te suffit de créer un dockerfile pour générer un conteneur pour un de tes clients. Si tu en a pas mal, ça peut être intéressant pour toi de prendre un service de kubernates managé.

[esperanto]

Merci

J'ai regardé un peu docker, en effet ça semble assez simple à déployer, la ligne de commandes est plutôt claire donc ça répond bien à ma première demande qui est de pouvoir créer/détruire un conteneur via des scripts.
Reste la question des accès réseau. Idéalement je voudrais que https://sous-domaine.domaine.com et sftp://sous-domaine.domaine.com aillent directement pointer sur le conteneur correspondant sans avoir à créer une adresse IPv4 par conteneur, et sans avoir à communiquer à l'utilisateur un numéro de port (j'ai déjà eu le cas où je déployais un serveur http sur un port non standard pour tester et des utilisateurs se sont plaints que leur proxy le bloquait pour cette raison)...
Du coup, comme le réseau est plus un problème qu'un avantage dans ce cas, quel est l'apport de docker par rapport à un environnement chrooté?
Je risque d'avoir beaucoup de conteneurs qui sont inutilisés pendant longtemps (mon application va plutôt tourner la nuit ensuite mes utilisateurs exploitent le résultat pendant la journée sans toucher au serveur). Est-ce que docker consomme beaucoup s'il y a beaucoup de serveurs mais la moitié "dorment"?
Au final je crois que dans un premier temps je vais oublier l'accès SSH et n'offrir qu'un Webdav plutôt que SFTP, de toute façon l'idée n'est pas de donner l'accès SFTP à tout le serveur mais seulement à quelques répertoires connus qui sont soit consommés soit alimentés par l'application. J'ai juste un peu peur que beaucoup d'utilisateurs ne sachent pas ce qu'est un Webdav et de devoir passer pas mal de temps à leur expliquer...
Je verrai ensuite pour tester docker en détail et peut-être aussi kubernetes
Je laisse ouvert encore un peu au cas où il y a d'autres idées qui arrivent.

[binarygirl]

Effectivement, je comprends la problématique.
Pour certains protocoles comme http(s), la redirection vers un container en fonction du sous-domaine pourrait se faire avec un proxy.
Pour d'autres protocoles comme SSH c'est plus difficile puisque SSH n'a pas le concept de virtual host: on se connecte à une adresse IP après avoir fait la résolution du nom (à moins de se connecter directement sur l'adresse IP). En revanche, il est concevable de faire de la redirection de port: donner à chaque client un sous-domaine avec son propre port associé pour le SSH.
Cela permettrait d'économiser les adresses IP qui sont une ressource rare (et facturée).

Il me semble que faire tourner un container, à configuration égale, sera toujours plus économe que d'émuler une machine Linux entière (VPS). Mais il n'y a pas de que docker pour cela. Il y aussi des solutions hybrides comme Firecracker et certaines distros comme Redhat viennent souvent avec Openshift. Donc votre environnement actuel va peut-être vous diriger vers certaines solutions plutôt que d'autres.

[chrtophe]

Pour certains protocoles comme http(s), la redirection vers un container en fonction du sous-domaine pourrait se faire avec un proxy.

Traefik à l'air de faire référence, c'est un reverse-proxy qui sera lui-même dans un conteneur.