Acquia BLT short Drupal8 howto

Working with vm’s makes everything simpler and easier. Easy to reproduce bugs, easy to reproduce features between environments and, most importantly, between developers.

In the past I’ve been working with different solutions, custom mainly, based on puppet, ansible…. Until I arrived to Acquia. Local environments as it happens is a recurrent topic on every team, a clear pattern… and when there is a pattern, you can write something to save some time to those lazy developers ;-). Enter BLT (Pronounced BOLT).
BLT is basically an environment that has everything ready for fast developer on-boarding, easy deployment on different environments (dev, staging, prod, … and of course, local), but also for quick automation of repetitive tasks, like rebuilding your sites, pulling databases...
Configuring BLT is very straightforward, but it will take some reading from you. Keep reading for a TL;DR version:
First, install the requirements:
In Mac it is very easy to do it simply following the brew requirements.
brew tap caskroom/cask

brew install php56 git composer ansible drush

brew cask install virtualbox vagrant
Once this is installed you have blt in your command line:
  blt --version
That’s it, you are ready.
Note: for other operating systems please visit:
Once we have all the tools installed in our computer we can start building apps. It couldn’t be simpler:
    composer create-project --no-interaction acquia/blt-project MY_PROJECT
That will create a base directory from which you can start building your Drupal app. First thing I’d do is moving this to your git repo, i.e. GitHub:
  $ git add .

  $ git commit -m "BLT-00 first commit."

  $ git remote add origin

  $ git push -u origin master
Now, let’s move inside the repo and start doing the magic. Let’s initialise the vm (I am assuming here that we’ll be working on a virtual machine):
  blt vm
It will ask if you want to install Drupalvm, to which we’ll say yes, and afterwards if we want to boot it. Yes again.
At the end of the process you should see a green message like this one:
"Drupal VM booted successfully. Please use vagrant commands to interact with your VM from now on.”
Your vm is ready. Last stop, install a site:
  # Since blt 9.x, you have to do this from inside the vm, so:
  vagrant ssh 
  blt setup
This will install a default Drupal 8 site in docroot. You could put your custom site here, or for example install lighting ( instead of the default one. The best practice for that road would be using composer, although I’ll leave this for a different post.
Now, next step you need is to actually connect your new vm to your Acquia Cloud (AC) environments. You have to do this drush level and BLT level, drush to be able to execute drush against the environments, BLT to be able to sync the databases, build artifacts, etc…
First bit, BLT settings. Edit:
And add in remotes the url to AC. You’ll find this url in AC. Go to, select your application and, in the list of environments, you’ll see on top right an icon called “Application Information”. Click and the first url is what you need. IE: [email protected]:YOUR-APP.git
Your yml file will look like this:

  default_branch: master


   - '[email protected]:lightningalex.git'
Lastly, your drush settings. Go to your AC profile page:
Select Credentials and, after confirming your password, you should see 'Drush integration’ in the new page. Download and place the hidden files in your $HOME.
Time to deploy your stuff to Acquia Cloud (or theoretically any other host provider). First thing, you’ll need to add your ssh keys to Acquia Cloud, just:
If you don't have any ssh keys yet there are some good short tutorials out there, it shouldn't take you more than 10 minutes to generate a new ones.
Ready to go, do:
blt deploy -Ddeploy.commitMsg='BLT-000: Deployment test' -Ddeploy.branch='master-build'
Answer ‘y’ to create a tag, return for the default commit message, and write your tag (i.e.: 1.0.3-build)
If your keys are good to go you should see some magic happening, and your artefact being deployed to the Acquia Cloud remote server. Now simply go to Acquia Cloud, select the tag that you have just created and deploy it in your environment. 
All done… although now I am thinking on changing the title of the article… not that short after all :-)
Bonus: Some commands
- Rebuild your local with the remote db:
blt sync
Equivalent to: drush sql-sync @remote @local

Apache not sending changes in js and css (virtual box)

I am using a solution of vbox (virtual box) and shared folders in our windows work environment (yes, unfortunatelly, but the IT team is in his right to decide which machines we have to use).

Everytime the vbox start, it mounts "automagically" one of the shared folders in the linux host (centos and archlinux, one day I will explain why). So then, apache has all what he needs in /var/www/html/ (simply mounted with "mount /var/www/html") (see automatically mount directories in vbox).

So far, everything was working fine... until I started to make small changes in small files. Absolutely surprising because when I deleted the complete code in the css or js file, for example, and I updated the browser, the screen appeared white, so everything seemed ok. But not at all, dealing with small changes, like adding a line in your css simply add no effect, the change is here, but seems that Apache or the browser didn't like it, simply it was being ignored.

After a while struggling about the browsers cache and even restarting the virtual box I finally decided to dig into Google.

I found the problem in the frankooh blog and it seems that it is a vbox problem, exactly a vboxsf problem with Apache.

The solution is simple, go to you apache configuration (in centos /etc/http/conf/httpd.conf) and uncomment the line:

EnableSendfile Off

After restarting Apache all the changes were sended to the browser without problems, even the small ones.

PS: be carefull with case sensitive off != Off 

Automatically mount directories in centos / virtualbox

If you try to mount a shared folder in centos, runing under a virtual box, you'll probably have problems trying to fix this directory, mounting automatically each time the system reboots.

In any other distribution, like ubuntu, you just have to go to your /etc/fstab and add this line:

varhtml                 /var/www/html   vboxsf  defaults        0 0

The problem is centos is that when the system arrives to this line, the vboxsf module has not been loaded yet.

The solution is quite simple, execute a mount command when everything has been loaded. This can be done in /etc/rc.local:

mount  /var/www/html

Your fstab must give information about this directory (like you've seen in mine), or use the large version of mount command.

As you can read in rc.local:

This script will be executed *after* all the other init scripts.

So, there is probably a better way to do this, but this one does the trick too :-).