virtualbox

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:

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:

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 (https://docs.acquia.com/lightning) instead of the default one. The best practice for that road would be using composer, although I’ll leave this for a different post.

CONNECTING EVERYTHING TO ACQUIA CLOUD

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:

blt/project.yml

And add in remotes the url to AC. You’ll find this url in AC. Go to https://cloud.acquia.com, 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

Ready to go, do:

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 :-)

- Rebuild your local with the remote db:

blt sync

Equivalent to: drush sql-sync @remote @local

categorias:

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.