The interface of subdomain administration has been deeply overhauled. So far, once a domain had been added to your alwaysdata account, you were able to create subdomains pointing to a precise directory. This mechanism entailed various limitations:
- it was necessary to add the management domain beforehand, which was not particularly intuitive
- when a site can be accessed through various subdomains (www.example.org and example.org), you have to type the destination directory for each of them
- the setting-up of a subdomain is limited to its destination directory. For a few months, it has been possible, however, to ask us to activate Passenger or mod-wsgi by contacting us
- it is tedious to host several sites in one subdomain, in distinct directories
Let’s give way to “Sites”
Forget about that system, and discover the new alwaysdata administration section: Sites. Instead of handling subdomains like before, from now on what you will create will be “sites”. A site is made up of:
- one or several addresses. An “address” is a subdomain, and in addition to it at times, a path. Here are a few examples : www.example.net, example.com, forum.example.org, www.example.com/forum/
- its type. We are offering at the moment 5 types, which will be detailed below
- configuration options depending on the type
This new system offers numerous advantages:
- it is no longer necessary to add your domain beforehand. Adding a management domain is now only required when you wish to use our DNS servers
- whatever the number of addresses your site has, there is no more configuration to duplicate
- you can indicate a path in your addresses. Thus, you can have a Django application on www.example.net and a PHP application on www.example.net/blog without tampering
- you do not have to contact us any more to activate Passenger or mod_wsgi
- you can create an HTTP redirection without having to toil to create an .htaccess file
- you can share a domain with several accounts belonging to the same customer
The one-click application installing process has been integrated to this Site section: you have an Install an application button allowing you to install, like before, a WordPress, phpBB, DokuWiki… automatically. The option of deleting applications, however, has been withdrawn: as it was not intuitive enough and confusing, you will now have to delete an application you no longer need manually.
The types of sites
- Standard Apache, which corresponds to the type used so far in all subdomains. It is adapted to static files, PHP or any application using FastCGI. In case of doubt, it is the type that you should use
- Customized Apache: it will allow you to indicate your own Apache guidelines, without any limits. Be careful enough not to break anything
- Redirection: as its name shows, it will allow you to set up HTTP redirections. It is available in 3 modes: 301 (permanent), 302 (temporary) and transparent (reverse proxy)
- Ruby on Rails: you simply have to indicate your application directory and it will be deployed via Passenger. In the future, you will be able to opt for another deploying mechanism other than Passenger, for those of you who prefer other technologies (Unicorn, for instance)
- WSGI: your WSGI application will be redeployed with mod_wsgi. And the same applies in that the technology may be changed later on (hello gunicorn)
Migrating existing accounts
Subdomains have been converted automatically into sites. If you had several subdomains pointing to the same directory, we have created only one site. The names of the sites generated are not very original (Site 01, Site 02, etc.) and it is up to you to change them as you wish. Should you detect the slightest bug, in spite of all of our caution, please do contact us.
And what next?
This new interface, on which we started working a long time ago, will allow us to add new features such as HTTP caching, dedicated IPs (already available on request), SSL certificates (ditto). The statistics interface (Piwik) will also be modified for each site to have its own statistics. And above all, we will add new site types: Django (which is already running smoothly with FastCGI), Node.js, Java, Erlang…
Follow us on Twitter to take part in our next beta tests
10 Comments »
RSS feed for comments on this post. | TrackBack URL
Leave a comment
Tags
Archives
- March 2013
- November 2012
- September 2012
- June 2012
- May 2012
- March 2012
- February 2012
- January 2012
- December 2011
- November 2011
- August 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- December 2010
- October 2010
- September 2010
- August 2010
- July 2010
- June 2010
- May 2010
- April 2010
- March 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- December 2008
- November 2008
- September 2008
- August 2008
- June 2008
- May 2008
- March 2008
- February 2008
- January 2008
- November 2007
- September 2007
- August 2007


N2 Feb 28, 2012 @ 11:47 AM
Ça tombe vachement bien ! Je viens de migrer mon premier site chez Alwaysdata, je m’apprêtait tout juste à configurer le .htaccess ;p
<3
richard Feb 28, 2012 @ 11:50 AM
Great works !
Julien Breux Feb 28, 2012 @ 2:10 PM
Merveilleux. <3 Django & NodeJS.
Nicolas Steinmetz Mar 2, 2012 @ 10:07 PM
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 ?
Nicolas Steinmetz Mar 2, 2012 @ 10:17 PM
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é ?
Cyril Mar 2, 2012 @ 10:55 PM
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.
Nicolas Steinmetz Mar 3, 2012 @ 9:20 PM
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
nennogabriel Mar 5, 2012 @ 2:03 PM
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.
Klaitos Mar 16, 2012 @ 9:18 PM
Très bonne mise à jour ! Continuez ainsi
alexh Jul 27, 2012 @ 5:19 AM
ahh… Node.js… Looking forward to it
Good luck for the future deployments!