Precip 2.0.0

Precip 2.0.0 - Now on Ubuntu 16.04

With Precip 2 we've moved to Ubuntu 16.04, swapped from mod_php to php-fpm, added PHP 7 support, added theme-compilation tools to the box, and nearly cleared our backlog of known issues.

Upgrading

As usual, you should just need to do the following:

vagrant halt
git pull
vagrant up --provision

If you experience any weirdness in doing so, then vagrant destory -f && vagrant up.

What's New

Ubuntu 16.04

Acquia recently completed their organization-wide upgrade to Ubuntu 16.04, to pave the way for PHP7 support and other stuff. As such, it was time for us to do the same.

PHP-FPM & PHP 7

PHP-FPM is the preferred means of running FastCGI worker pools for PHP. It's good for us because it's both the way Acquia runs PHP and also the way we're running PHP 5.6 and PHP 7 concurrently.

PHP-FPM allows us to define "pools" of PHP processes with different configurations. In our case, the main difference between our pools is that one's PHP 5.6 and one is PHP 7. Eventually we'll also add one for PHP 7.1. This means we can now switch individual docroots between 5.6 and 7. How? config.rb. By default all docroots are still using PHP 5.6. If you add a new directive to config.rb it'll swap between the two. For instance:

drupal_sites = {
  "test" => {
    "host" => "test.vm",
    "path" => "test/docroot",
    "php_version" => "7.0",
  }
}

vagrant reload --provision and when it's done your test host will be running PHP 7. Want to switch it back to 5.6? Change it to "php_version" => "5.6" or just remove that line, reload and reprovision. This will let you selectively test sites vs PHP 7 without breaking ones which might still depend on 5.6.

More tools baked in

nodejs, npm, yarn, compass, suzy, etc are all now baked in. That should be all you need to build a Radix or Omega-based theme, should you not be able to build it on your Host.

Similarly, we've fixed how composer is managed, got it upgraded, and also upgraded drush to 8.x. We also fixed our vmi.* aliases, so you've got an easy way to run stuff in Precip from your Host.

A bunch of new Flags & Extras

Precip 2 brings some new flags to config.rb:

forward_ssh_agent - Set it to true if you want to forward your Host's SSH Agent to Vagrant. Good if you want to be able to clone private repos inside the box without messing around with adding private keys and setting up an agent manually.

vm_name - Set it to "some_string" if you want to run precip with a different name. Good if you want to run two instances of precip. For instance, if you want to clone Precip 2.0.0 into a new directory without blowing up an existing and working instance of Precip 1.x.

use_packaged_precip - Set it to true if you want to use our slightly-more-bootstrapped version of Precip. Tradeoff: More downloading up-front for less time spent provisioning. Helpful if you're on a network that has restrictions around pulling Keys via HKP.

shell/custom.sh - We also added this 'custom' shell script, to help you run extra stuff as a last step in provisioning. It'll automatically get pulled in if it's present, and will automatically run during the provisioning phase and will run last. This is great for doing stuff we don't necessarily want to codify in Precip, but which you may want done. For instance, if you prefer zsh over bash, you can have it install zsh, oh-my-zsh and change your shell automatically. This file isn't tracked, so feel free to add whatever changes you want.

Precip 1.1.1

Precip 1.1.1 - The Last One On Ubuntu 14.04

We're rolling out Precip 2.0. This gives you a nice tag to roll back to if you find issues with 2.0.

Precip 1.1.0

Precip 1.1.0 brings several key new fixes related to reliability.

On the Drupal front, local-settings.inc has been significantly refactored and simplified. We no longer create multiple different database includes, or create "special" includes deep within the bowels of the Vagrant Box that get included "magically". Instead our new standardized settings.php includes local-settings.inc if it exists, and local-settings.inc determines if it can use a MySQL Socket or not.

Note: Depending on how your repository is configured you may need to delete your settings.php and local-settings.inc, then vagrant destroy -f and vagrant up to clear this up. If you don't, the world won't end, you just won't necessarily be sourcing the correct files. If you experience any weirdness consider going through these steps.

In the past month several people have reported serious issues MySQL / Percona Server issues when provisioning from scratch. These issues seem to be related to an upstream issue with Percona Server, so we've swapped out Percona for MariaDB. Just like Percona, Maria is a drop-in replacement for MySQL, with similar performance improvements.

Similar to the note about settings files, you may experience weirdness migrating from Percona to MariaDB. If you have issues, zero out your MySQL Data Directory, destroy and reprovision:

vagrant ssh -c 'sudo rm -rf /var/lib/mysql/*'
vagrant destroy -f && vagrant up

This is admittedly a bit of a nuclear option, but it ensures a clear consistent state.

1.1.0 is likely our last release on Ubuntu 14.04. We'll be prepping a new Precip 2.0.0 based on 16.04 (with PHP7 available as an option) soon.

Precip 1.0.0

Precip 1.0.0 brings massive performance improvements, a few key bugfixes, and a few feature improvements we've had back-burnered for awhile.

Performance

We've done everything we can think of at this time to squeeze as much performance as possible out of Precip. Here are some perf comparisons between where we were a week ago, and where we are today:

• HTTP Throughput: Up 238%
• HTTP Processing Time: Down 71%
• Puppet Provisioning Time: Down 35% (now typically under 5 minutes)

How'd we do all this?

• We moved MySQL Storage from a directory being shared over NFS + BindFS to a Virtual Disk Image managed via the vagrant-persistent-storage Vagrant Plugin. This means MySQL is now effectively running like a native disk inside the VM and is just about as performant as we can possibly make it from a virtualized hardware perspective. Caveat: MySQL Storage is now capped to 32GB, though we could make this configurable.
• We drastically reconfigured how we customize the resources available to the VM. A ton of stuff changed, but the heavy-hitters were giving the VM half of the host’s physical CPU cores (previously capped at 2), switching from "legacy" paravirtualization to explicitly KVM, and deferring DNS resolution to the host.
• We restructured our Puppet Scripts to be Puppet-4-compatible, swapped out how PHP was being provisioned, and upgraded our base box to a new version that supports Puppet 4. Turns out Puppet 4 is faster, and we were wasting a bunch of cycles provisioning PHP poorly.

Bugfixes

In all this testing we found a couple small but important things that needed fixing. Some of these fixes conveniently and accidentally paved the way for features.

• Return a Friendly Error Message if you provision with no config.rb, and don’t fail at all if the config.rb is empty
• Completely refactor how we’re collecting hosts to be significantly less stupid and error-prone. (Note: Please never let me write "clever one-liners" in Ruby ever again.)
• Mount the sites directory tree as vagrant:www-data, and mount it 775, which allows both the vagrant and apache users to do stuff to the docroots.

New Features

Finally, we also went back and implemented some pet features we've had kicking around as ideas.

• PimpMyLog Support, accessible at precip.vm/pml. Pre-configures itself and everything during the provisioning process. Logs are still available at outside the box at /log, but now they're also being mounted and managed in such a way that PML can access them.
• Custom SSL Cert handling. Turns out Chrome doesn't cache anything correctly if you've got a self-signed cert, even if you tell Chrome to accept that cert. You can now drop SSL Cert / Key / CA files into /ssl/ and reference them in config.rb.
• Need Precip to be aware of some other manually-defined hosts in /etc/hosts? You can now configure those in config.rb so Precip can be aware of something like an external Solr server, or an API on another VM somewhere.

Experimental Stuff

Thanks to the fixes to how we're mounting the sites directory and upgrades available in Drush 7.x, we can now support Drush Aliases that interact with Vagrant like it's a true remote alias. These new @vmi aliases are being created alongside your @vm aliases and get installed via install_aliases.sh.

When you use any of these new @vmi aliases the following happens:

• Host Drush looks at your vmi.aliases.drushrc.php
• Host Drush opens an SSH connection to Vagrant, using Vagrant's auto-generated no-passphrase key
• With an SSH connection opened, Host Drush tells Guest Drush running inside Vagrant to run whatever command you asked for against the Guest’s /srv/www/site path
• Guest Drush seamlessly returns the results back to Host Drush, but Host Drush didn’t do anything to Drupal

In practice we’ve found @vmi aliases to be a bit slower compared to @vm, but they have the important bonus of not being based on a kludgy mess of hacks. The plan will be to eventually replace the @vm aliases with @vmi and drop all related messy hackery (like local-settings.inc) at that point, but for now they’re an experimental extra. Please try using them and report back.

First packaged release.

0.1.0

Swap php from Ubuntu 14.04's base (5.5) to Ondrej's 5.6 PPA