CyberRail, qu'est ce que c'est ?

Déjà, une présentation sommaire : Cyberrail est un simulateur de réseau ferroviaire en devenir. C'est à dire qu'à son terme, il devrait permettre de simuler (c'est à dire afficher sur un écran) un réseau ferroviaire de taille moyenne (en gros, quelques chose proche de ce qui se fait en terme de diorama). Un des autres objectifs est de pouvoir piloter de façon fluide un diorama.

Qu'est ce qu'il faut pour réaliser le projet ?

  • deja, du temps. C'est un projet assez ambitieux et il ne se fera pas en deux week-ends
  • une conception. Actuellement, tout est dans ma tête : c'est un point noir qu'il faut tenter de résoudre
  • un serveur de code. Sans lui, aucune visibilité
  • un site web. idealement, cela devrait être un CMS avec éventuellement un wiki
  • un système de gestion de tâches, pour planifier ce qu'il y a à faire
  • un nom de domaine, c'est quand même plus joli qu'un trucmuche.hebergeurquelconque.com

Certains de ces éléments existent déjà, d'autres pas encore :

  • pour le temps, il faut un peu d'organisation et être dans un état apte à coder. Le boulot que j'ai chez l'intégrateur gai ne m'en laisser pas beaucoup. Actuellement en régie, je pense que ça va aller mieux.
  • la conception : pour ça, il faut des outils (pour stocker l'information de façon structurée, pour faire des schéma facile à publier, etc). Actuellement, il n'y a quasiment rien : l'information peut se trouver dans les quelques notes de conception du projet, ainsi que dans les entrées présentes ici, mais rien de centralisé et organisé). Comme dit plus haut, l'idéal, c'est un CMS : je ne vais pas faire des pages html à chaque fois que j'ai une idée.
  • un serveur de code : actuellement, j'utilise la plateforme sourceforge pour celui-ci. C'est un des rares endroits ou on peut avoir un SVN sur le net gratuit. On verra par la suite, ce n'est pas l'idéal
  • un site web. J'ai testé plusieurs solutions. Le problème est que sourcefourge n'accepte pas énormément de choses, et surtout, tous les fichiers sont publqiues, y compris les fichiers de configuration avec les mots de passe dedans, ce qui n'est pas acceptable pour moi : je dois pouvoir restreindre le site ne écriture sans pour autant faire un site complètement statique. La plupart des CMS ont besoin d'un accès à la ligne de commande pour pouvoir être installé, un simple FTP ne permettant pas ça. Je n'ai pas non plus envie d'utiliser des techniques de sioux pour arriver à mes fins : la technique d'installation doit être celle décrite par les concepteurs.
  • un système de gestion de tâche. Toute personne ayant utilisé le bugtracker de sourceforge est consciente qu'il est mauvais. Au boulot, on utilise Jira ou Poi, qui sont dans les deux cas plus utilisables.
  • un nom de domaine. J'en ai réservé un, et je me tate à en prendre un deuxième. Malheureusement, je n'ai pas trouvé de TLD me satisfaisant.

Les problèmes sont donc les suivants :

La majorité des ressources necessaires se trouvent sur sourceforge. À part le serveur SVN, le reste ne me convient pas : sourceforge, c'est quand même le bordel, et c'est pas flexible. De même, n'importe quel autre hébergeur de projets aura aussi ses limites, et je n'ai pas envie d'ouvrir un compte chez tout le monde juste pour tester alors que je sais ce que je veux. L'avantage, c'est que c'est gratuit.

Il me reste l'hébergement généraliste. De par ce que je souhaite, il me faut un truc de type serveur privé ou dédié. Ce qui veux dire que l'on va devoir passer à la caisse pour jusqu'à 300 € par an. C'est une somme, aussi, il ne faut pas se planter. Quelles sont les solutions possibles :

- l'hébergement "chez des amis". C'est toujours sympa d'avoir des amis qui te proposent ce genre de services. Il faut que je vois dans mon entourage si c'est possible. Ce n'est pas forcement évident lorsque ces amis ne sont pas à proximité (géographique ou temporelle), et en cas de problème on a rarement accès à l'administration de la machine. Et puis, la plupart des choses que je souhaite faire sont sur le port 80 ou 443 (svn + http ou svn + https, tracker, etc), et il est peut probable que je puisse administrer directement le apache... Coût : indéterminé.

- l'hébergement "à la maison". Ça peut aussi être une solution à envisager, mais ça veux dire être tributaire de la connexion ADSL et laisser la machine tourner 24h/24. Je ne suis pas sur qu'au niveau consommation électrique, cela soit intéressant. Et puis niveau débit, c'est un peu faiblar... À étudier, sachant que j'ai déja une petite machine qui pourrait faire office de serveur une fois installée. Coût : le prix de la consommation électrique (ainsi que le bruit et les éventuels problèmes matériels inévitables sachant que je n'ai pas de climatisation chez moi)

- Gandi. Gandi propose des serveurs mutualisés à partir de 7,20 €. Ça l'air très flexible, et l'idée me tenterait bien. Problème : le service n'est pas ouvert (sauf sur invitation motivée en gros). Coût : 90 € / an pour une tranche de base. Par contre, une seule tranche, c'est de la machine vraiment bas de gamme...

- OVH[1]. OVH propose des serveurs virtuels à partir de 12 € par mois (RPS I). La configuration correspond à deux tranches de gandi et OVH propose une bande passante de 100 Mbps (contre 5 chez Gandi). Par contre, il y a fort à parier que ça soit le trafic pour toutes les machines virtuelles, ce qui peut le rendre assez aléatoire. Coût : 144 € / an. Cela le rend moins chez que Gandi à machine égale.

- Amen. L'offre d'Amen correspond un serveur virtualisé aux spécifications proches de celle d'OVH, à quelques détails prêt au niveau de la machine (moins de place sur le disque et en RAM, par exemple). Coût : 144 € / an.

- 1&1. Un compromis entre Amen et OVH. Je n'ai pas vu de point susceptible de me convaincre que c'est mieux. 144 € / an (cela semble être une constante).

- Nexen (il fallait bien que je regarde) : bon, ils sont avare sur la machine virtuelle mise à disposition. En gros, c'ets 59 € HT par mois pour 1Mbps. Coût : 846 € / an. À ce prix, c'est disqualification directe.

On trouve encore plus cher pour des professionnels. Je ne m'attarderais pas dessus. Les choix sont donc les suivants :

  • prendre une "forge" : c'est gratuit, mais absolument pas flexible
  • bricoler chez moi ou chez un ami : je ne suis pas convaincu de la pérennité de la solution au meilleur coût.
  • prendre un RPS I chez OVH. Un avantage, ce n'est pas du virtualisé (une sorte de PC sans disque dur)

Je pense m'orienter vers la dernière solution. À voir.

Notes

[1] OVH ne fait pas de serveurs virtuels, mais propose des bases pour la sous-traitance.