Learn how to secure your web app using Ansible.
Learn how to customize your MongoDB in a dockerized setup.
Read to find out how Drupal stores stuff in the tables behind the hood.
A deep dive tutorial about Ansible.
Learn how passwords are stored in Drupal 8.
Ever wondered how Drupal 8 authenticates a user? Let’s do a deep dive and find out.
DIY Drupal hosting using DrupalVM.
DIY Drupal hosting using OpenDevShop.
DIY Drupal hosting using Aegir Project.
The meta stuff
I’ll be writing a series of posts exploring DIY drupal hosting options. Many agencies and freelancers need a workflow to manage and maintain their Drupal sites on a budget. Of course, they incur the cost of maintaining and deploying the system(at least initially) and the additional learning curve involved in using the system, but they get the following advantages:
- More control over the hosted sites. It is easy to create and deploy new environments to demo sites to clients, triage bugs, run tests etc.
- Better workflow management. Site admins can run security updates or revert/update modules and features across sites, take periodic backups, restore them and migrate sites in and out of the hosting system. This is an important factor for developers if you’re running an agency supporting lots of sites.
- Save $$$. Though having a DIY solution has its share of initial hiccups, it could save money in the long run.
There are lot of wonderful solutions, most notably Pantheon, Omega8 and Acquia Cloud. By all means, go ahead and try them out and see how they fit your use case. These posts are intended to educate about other tailor-made options which can be built and modified to fit your workflow.
TLDR; You always trade headache for money.
What to look for
With the meta stuff out of the way, I’ll elaborate here on what features I look for when shopping a DIY hosting solution. These cover 80% of the use cases needed by most organizations and/or developers. Please get in touch with me if any major use case is not listed here.
- Ability to spin off different staging and testing environments of the site quickly. Many a times, we have to quickly create a version of the site with a feature or 2 added, for demo-ing, or create a quick production replica to triage a bug. Our solution should be able to create such throwaway environments with little effort.
- dev production parity. The throwaway setups mentioned above should be as close to the production setup as possible. For instance, the throwaway setup should also have HTTPS if the production site has one. That’s how close “close” means.
- Secure. The DIY solution should have an ACL and the hosted environment should have proper protocols in place, like allowing SSH access only from trusted networks and users, firewall configuration etc. Note that this has nothing to do with the security of the site hosted on the platform. That’s a post for another day!
- truly agile. Deployment to production should be a predictable, documented and repeatable activity. This opens up the possibility of automating deployment. Once deployments stop becoming time sinks, as a consequence, frequent deployments and iterations happen. This naturally facilitates continuous delivery in our workflow.
We can have a working DIY solution with just the above essential qualities. These are other features which make the above main features easier and aid them. Some of them might be Drupal specific. These are between essential and nice-to-have, and make our DIY solution more complete.
- Extensible. I should be able to build my own custom LAMP stack if the site needs it. To elaborate, I should be able to deploy site A and site B running different versions of PHP, or one using Nginx and the other using Apache. Another example is talking to different systems. For example, every new git branching should trigger the system to create a new environment from scratch, with sensible defaults. The common thread here is, the solution should be extensible.
- Ease of installation We already inherit lot of complexity by opting for a DIY Drupal solution. Setting up one from scratch should be as smooth as possible.
- Plays well with Drupal The solution works with Drupal out of the box, with little tinkering. One example would be allowing drush usage. A good DIY solution would ideally have provision for drush site aliases. Another example, is taking into consideration the fact that Drupal isn’t a complete 12 factor app. Any platform which assumes otherwise needs a lot of tinkering to keep the lights on.
- Usability. There needs to be a commandline tool or a UI dashboard to manage the sites, maintain the system etc., despite the fact that the intended audience for this solution are mostly developers. What if your project manager wants to demo a work-in-progress feature to a client while you’re away? 😉
- Drupal 8. This goes without saying, but deserves a mention. Lot of ink has been spilled on how Drupal 8 is a radical shift in development from its predecessors. Our solution needs to take this into account to stay relevant in future.
- Support for addon services. It would be convinient if the DIY solution supports other addons commonly used for Drupal sites, like Redis, Memcached and Solr.
- Support for other frameworks/CMSes. If you are an agency/developer working on multiple frameworks, this might be the deal breaker for you. It would be great if our DIY solution supports other systems like WordPress, Rails, Symfony etc., though it is not a mandate.
Assumptions and expectations
The solutions we will be discussing are tried and tested on Linux-ish systems(more specifically, Ubuntu and flavours). There is no guarantee that this will work if you’re using Windows to build it. Also, if you are running Drupal on IIS or Microsoft SQL server, this setup won’t work for you.
With this premise, we will be walking through 3 DIY Drupal hosting setups in the subsequent posts which you can try at home!
DIY Drupal hosting series
Introduction to DIY Drupal hosting – you’re here