L’interface d’administration des sous-domaines a été profondément remaniée. Jusqu’à présent, une fois un domaine ajouté à votre compte alwaysdata, vous pouviez créer des sous-domaines pointant vers un répertoire précis. Ce mécanisme souffre de nombreuses limitations :
- il est nécessaire d’ajouter préalablement le domaine en gestion, ce qui n’est pas particulièrement intuitif ;
- lorsqu’un site est accessible par plusieurs sous-domaines (www.example.org et example.org), il faut saisir le répertoire de destination pour chacun d’eux ;
- la configuration d’un sous-domaine est limitée à son répertoire de destination. Depuis quelques mois, il est toutefois possible de nous demander d’activer Passenger ou mod_wsgi en nous contactant ;
- il est fastidieux d’héberger plusieurs sites sur un même sous-domaine, dans des répertoires distincts.
Place aux « sites »
Oubliez ce système et découvrez la nouvelle section de l’administration alwaysdata : les Sites. Au lieu de manipuler des sous-domaines comme auparavant, c’est désormais des « sites » que vous créez. Un site est constitué de :
- une ou plusieurs adresses. Une adresse, c’est un sous-domaine plus, éventuellement, un chemin. Voici quelques exemples : www.example.net, example.com, forum.example.org, www.example.com/forum/ ;
- un type. Nous proposons à l’heure actuelle 5 types, détaillés plus bas ;
- des options de configuration qui dépendent du type.
Les avantages de ce nouveau système sont nombreux :
- il n’est plus nécessaire d’ajouter préalablement votre domaine. L’ajout d’un domaine en gestion n’est désormais requise que lorsque vous souhaitez utiliser nos serveurs DNS ;
- quel que soit le nombre d’adresses de votre site, il n’y a plus de configuration à dupliquer ;
- vous pouvez préciser un chemin dans vos adresses. Vous pouvez ainsi avoir une application Django sur www.example.net et une application PHP sur www.example.net/blog sans avoir à bidouiller ;
- il n’est plus nécessaire de nous contacter pour activer Passenger ou mod_wsgi ;
- vous pouvez créer une redirection HTTP sans avoir à créer laborieusement un .htaccess ;
- vous pouvez partager un domaine au sein de plusieurs comptes appartenant à un même client.
L’installation d’applications en 1 clic a été intégré à cette section Sites : vous avez un bouton Installer une application qui vous permet d’installer, comme auparavant, un WordPress, phpBB, DokuWiki… de manière automatique. La suppression des applications a toutefois été retirée : peu intuitive et prêtant à confusion, vous devrez désormais supprimer manuellement une application dont vous n’avez plus besoin.
Types de sites
Nous proposons, pour démarrer, 5 types :
- Apache standard : correspond au type utilisé jusqu’à présent sur l’ensemble des sous-domaines. Il convient pour les fichiers statiques, PHP ou toute application utilisant FastCGI. En cas de doute, c’est le type que vous devrez utiliser ;
- Apache personnalisé : vous permet d’indiquer vos propres directives Apache, sans aucune limite. Attention à ne rien casser :) ;
- Redirection : comme son nom l’indique, vous permet de mettre en place des redirections HTTP. 3 modes sont possibles : 301 (permanent), 302 (temporaire) et transparent (reverse proxy) ;
- Ruby on Rails : indiquez simplement le répertoire de votre application Rails, elle sera déployée via Passenger. À l’avenir, il sera possible d’opter pour un autre mécanisme de déploiement que Passenger, pour ceux qui préfèrent d’autres technologies (Unicorn, par exemple) ;
- WSGI : votre application WSGI sera déployée avec mod_wsgi. Même chose, la technologie pourra être changée plus tard (hello gunicorn).
Migration des comptes existants
Les sous-domaines existants ont été convertis automatiquement en sites. Si vous aviez plusieurs sous-domaines pointant vers un même répertoire, nous n’avons créé qu’un seul site. Les noms des sites générés sont peu originaux (Site 01, Site 02, etc.), libre à vous de les modifier à votre guise. Si malgré toutes nos précautions vous constatez la moindre anomalie, contactez-nous.
Et ensuite…
Cette nouvelle interface, sur laquelle nous avons commencé à travailler il y a longtemps, va nous permettre d’ajouter de nombreuses fonctionnalités : cache HTTP, IP dédiées (déjà disponibles sur demande), certificats SSL (idem). L’interface de statistiques (Piwik) sera également modifiée pour que chaque site ait ses propres statistiques. Surtout, de nouveaux types de sites vont être ajoutés : Django (qui tourne déjà parfaitement en FastCGI), Node.js, Java, Erlang…
Suivez notre Twitter pour participer aux prochains beta tests :)
Ça tombe vachement bien ! Je viens de migrer mon premier site chez Alwaysdata, je m’apprêtait tout juste à configurer le .htaccess ;p
<3
Great works !
Merveilleux. <3 Django & NodeJS.
Pour WSGI, est-ce que ça veut dire qu’il va être possible d’avoir à la racine du (sous-)domaine une application utilisant wsgi et rendre accessible un répertoire de ce (sous-)domaine sans passer par wsgi ? Ou faut-il passer par du apache personnalisé ?
Ex : test.mondomaine.tld est une appli wsgi. test.mondomaine.tld/blog lui qui est un simple export html est accessible ?
Je me réponds à moi-même, non pour le mode « wsgi » simple.
En lisant la conf apache, on voit un numéro associé à WSGIProcessGroup qu’on retrouche en début de fichier dans la variable WSGIDaemonProcess. Si on fait un apache personnalisé, comment on sait quelle nouvelle valeur on doit mettre si on utilise du WSGI customisé ?
Mixer WSGI et PHP (ou autre), oui c’est possible. C’est le principe : chaque « site » est installé sur un sous-domaine + path, et tourne indépendemment des autres. D’ailleurs si vous regardez le sites.conf généré, il n’y a pas de magie : on a un Alias sur /blog (dans votre exemple), et mod_wsgi s’occupe de /.
Concernant le WSGIProcessGroup, le numéro est simplement celui de votre ID de site, mais c’est censé être opaque. Pourquoi vouloir le réutiliser de toute façon ? Mettez n’importe quelle autre valeur dans vos propres WSGIProcessGroup.
Dernière chose, ce nouveau système n’en est encore qu’à ses débuts, on va étoffer tout ça (et corriger les bugs remontés). En l’occurrence, on utilise mod_wsgi pour le moment, mais on va rapidement utiliser gunicorn à la place. Enfin, pas à la place : on pourra continuer à utiliser mod_wsgi si on veut, mais gunicorn sera plus puissant et sera utilisé par défaut.
Ahhhh ok, je vois l’idée sur les sites. J’avais raté cet aspect puissant…
Bon j’ai un bug a priori quand même, je passe par le support :)
So Nice!!
I’m exciting with an idea to deploy django using only ftp and don’t need to access throug ssh to configure fastcgi.
Congratulations guys, you have best hosting I ever saw.
Très bonne mise à jour ! Continuez ainsi :)
ahh… Node.js… Looking forward to it :)
Good luck for the future deployments !