I wanted to share some of the tips and tricks that I've picked up when starting to use Dev Cloud. If you don't know Dev Cloud, its a Drupal specific web hosting system. As I wrote in my previous article about it, its a cool system and its working out well for us so far. If you are interested to use it, I think I can save you some time trying to figure out all the details.
In this part, I'll go over getting your site installed and restricting access to the development environments.
Previous article - Acquia's Dev Cloud web platform - my first impressions
Installing like a pro -
How to use git to get your site up and running
One of my few criticisms of the Dev Cloud system is about the first step, setting up the site. I've already passed on these issues to Acquia support and I've gotten feedback about some clever changes being made already which address most of my issues.
The Install page in the Dev Cloud administration section shows two options, deploy a distribution and import a site. Neither of these were what I needed. If you have a brand new site, you probably could import the site. There is a 100mb limitation on the archive file (a php configuration upload restriction), and since I was migrating an existing site which has a bunch of files this wouldn't work for me.
My goal was to
- clone the git repository
- copy my code into the repo
- commit my code and push it to the server
- move the site files over to the server
To me, this seems the "right" way to deploy to Dev Cloud. If I was writing a hosting methodology for a large organization this is how I would do it, since it gives us a single way to handle both new site deploys and large existing site migrations.
Unfortunately, there isn't a step by step walk-through of this git commit style of installing in the Acquia documentation at the moment. I had to read the Develop documentation to piece together the steps I needed to take in order to install this way. The documentation is detailed though so I was able to put together what I needed and it only took me about an hour to get everything working. I'd consider myself good with server administration - I'm not sure if a beginner would have the patience to look around for the way to do this. I've had feedback from Acquia that making it more clear how to start this way is on their radar.
Details for deploying with this method
You can follow the Develop help pages for the most part. After you clone your site repository, commit your site to the master branch, without your site files. Chose the master branch to be the DEV branch on the Workflow page. I'll explain branches and workflow in my next post.
The next step is to get you files up to the site. The files directory is mounted into the codebase so you need to know where to move them to. This can be found on the Files and Logs administration page. It will probably be /mnt/files/YOURSITENAME.dev/files. Use scp to get your site's files onto the server, and from this point on you will be able to move files between workflow stages with the drag-and-drop tool on the Workflow page in the Dev Cloud administration interface.
Your developers may later want to get files to their local development workstations. There are a few ways to do this, but I don't think that giving them shell access to the server is the right way. There are a number of mechanisms for this, which we can discuss later.
Control who is getting to your development sites
Don't let them index your development sites
If you are like me, you don't want people just poking around your development work, especially if you are in a highly competitive market. I'm also pretty sure that you don't want to have crawlers also indexing your development content - it can potentially hurt your results ranking and visitors who click on development links might be shocked at the state of your web site!
You get three environments for each site on a Dev Cloud server. These are called DEV, TEST, and PROD. For most projects, its important to restrict access to DEV and TEST. We chose to do this with the shield module, though the secure site module is also a viable alternative. We chose shield because it is a simpler module that does exactly what we required.
Since we want this restriction on DEV and TEST, but we want PROD (the live server) to be publicly accessible, we added this snippet to the settings.php file which causes the shield module to not block access if it detects its on PROD.
-
/*
-
* On PROD, remove restricted access provided by shield module.
-
* Applies to DEV and TEST to prevent crawlers and roving eyes from seeing our dev sites.
-
*/
-
$conf['shield_user'] = '';
-
$conf['shield_pass'] = '';
-
}
Yes, it would be better to fully disable the module which would be trivially easy if you never deploy a new database to PROD (which is proper workflow practice). Since we don't have any public user generated Drupal content on our site we sometimes deploy new features from TEST to PROD via database instead of making features and upgrade scripts (read: cheat) and because we have relatively low traffic, the overhead of the module on PROD is inconsequential.
Shield needs a slight alteration to work properly on Dev Cloud since it uses FastCGI. You can either add a line to .htaccess or patch the Shield module. Leaving modules unchanged and overriding in custom modules or the theme layer makes upgrades a lot easier, so we chose to do this in .htaccess, inside <IfModule mod_rewrite.c>.
-
RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
Thanks to Acquia support for telling me about this simple fix for shield on FastCGI based servers like Dev Cloud. Peter Bull, who actually solved the issue on drupal.org, responded to my low priority support ticket in under two hours. The patch mentioned can be found at http://drupal.org/node/1343750.
Avoid duplicate content at the default domains
When you set up your site on Dev Cloud, there are some default domains set up for you so you can immediately access the server, even if you don't have your own domain registered yet. These will be like
- [AQUIASITENAME]dev.devcloud.acquia-sites.com
- [AQUIASITENAME]test.devcloud.acquia-sites.com
- [AQUIASITENAME].devcloud.acquia-sites.com
Obviously it isn't good practice to have your site available at these addresses after you are running. Once you have your own domain and subdomains set up to properly point at the server, you should make these defaults redirect to your own domain names. The snippet below assumes you use the subdomains dev.* and test*. Add this to .htaccess inside the <IfModule mod_rewrite.c> directive, replacing ACQUIASITENAME with the name of the site in the Dev Cloud control panel (check the Domains page for the exact names, if you don't know them).
-
RewriteCond %{HTTP_HOST} ^AQUIASITENAMEdev.devcloud.acquia-sites.com$ [NC]
-
RewriteRule ^(.*)$ http://dev.yoursite.com/$1 [L,R=301]
-
RewriteCond %{HTTP_HOST} ^AQUIASITENAME.devcloud.acquia-sites.com$ [NC]
-
RewriteRule ^(.*)$ http://test.yoursite.com/$1 [L,R=301]
-
RewriteCond %{HTTP_HOST} ^AQUIASITENAME.devcloud.acquia-sites.com$ [NC]
-
RewriteRule ^(.*)$ http://yoursite.com/$1 [L,R=301]
Adjust your site name as needed. With this in .htaccess, anyone who somehow manages to try to visit your site via the Acquia defaults will get a permanent redirect to your proper domain. I could imagine that this might be a useful feature to offer on the Domains page, perhaps a checkbox to disable the defaults or a select box to make them redirect to a domain the user added.
Ready to start
These tips should help you to get your site up on Dev Cloud and make sure that only the people you want on the development sites can get in.
In the next part, I'll write about the development workflow we're using. I will also discuss how to manage branch access and how to make sure that your developers can get to files and databases in a secure way, which also applies not just to Dev Cloud but to any web development.
Previous article - Acquia's Dev Cloud web platform - my first impressions
