Home
Everything you've read on the 'Net is true.

Encourage experimentation with Docksal

Site Loading

'Deliberate experimentation is more important than deliberate practice in a rapidly changing world.'

https://medium.com/the-mission/forget-about-the-10-000-hour-rule-7b7a39343523

How often is one's choice of drupal module simply the first one that worked?

Or how often might the developers with a single copy of the current WIP, and if something breaks, everything grinds to a halt for them?

And how often is that site design (I'm not talking about visuals or graphics) the only option ever really offered to the team or the client?

Seeing some developers struggle with a single instance of drupal on their laptop doesn't bode well for the idea of a fluid development process where the developer is in control of their workspace and not a slave to a few scripts copied from a google doc.

Enter Docksal

https://docksal.io/

Docksal is a docker environment for websites including but not limited to Drupal 8, 7 and Wordpress and Magento.

Of course this solution is not for every team, but I think a tech lead should be aware of the deficits in their team, and help compensate. The advantage of all the team being able to use and support an agreed environment (even if one chooses not to use it) should be self-evident.

With Wamp or Mamp I find the database servers become cluttered and often the apache configs become unwieldy and of course it doesn't solve the 'it works on my machine' issue, since there is an infinite number of configurations.

DrupalVM, I find is impenetrable: large and monolithic, offers little, and so easy to break. (If a folder already exists during a rebuild, the process will fall over).

It's almost like a choice between:

(a) multiple - easy to install sites - but crazy - The Wamp way

or

(b) One site installation at a time - but sane (if brittle) - The DrupalVM way

Docksal offers the third option

(c) multiple sites with sane configuration, ta da!

But that's not all.

 

Simple, Zero Configuration

On the other hand Docksal is efficient, robust, requires minimum to no configuration and you can have several running at once allowing you to switch between different projects or different iterations or prototypes.

To convert an existing Rrupal site, simply add a .docksal to the root of your project and type

fin up

I add a docksal.env file so I can change the project name (and url).

# This is a shared configuration file that is intended to be stored in the project repo.
# To override a variable locally:
# - create .docksal/docksal-local.env file and local variable overrides there
# - add .docksal/docksal-local.env to .gitignore

# Use the default Docksal stack
DOCKSAL_STACK=default

# Lock images versions for LAMP services
# This will prevent images from being updated when Docksal is updated
WEB_IMAGE='docksal/web:2.0-apache2.4'
DB_IMAGE='docksal/db:1.1-mysql-5.6'
CLI_IMAGE='docksal/cli:1.3-php7'

# Docksal configuration.
VIRTUAL_HOST=emc23.docksal <-- the only thing needs to change
DOCROOT=docroot

# MySQL settings.
# MySQL will be exposed on a random port. Use "fin ps" to check the port.
# To have a static MySQL port assigned, copy the line below into the .docksal/docksal-local.env file
# and replace the host port "0" with a unique host port number (e.g. MYSQL_PORT_MAPPING='33061:3306')
MYSQL_PORT_MAPPING='0:3306'

# Enable/disable xdebug
# To override locally, copy the two lines below into .docksal/docksal-local.env and adjust as necessary
XDEBUG_ENABLED=0

If you only have one site, then you don't even need this file.

Compare and Contrast

This allows me have multiple sites, one with groups for example, another with organic groups, or what about media versus images when it comes to UX, cropping, and browsers?

What happens if you install a module and it breaks your site? Is it the module or a conflict? Solution spin up a fresh site in moments and install the new module. Laboratory conditions ftw!

By having several prototypes one can look at config files etc and have a better chance at deducing 'what goes where'.

Encourage investigation of new Drupal tools

Out of the box docksal supports

  • Apache Solr
  • Behat
  • Blackfire
  • Drupal Console
  • Drush
  • MailHog
  • Memcached
  • ngrok
  • PHP Code Sniffer
  • SASS and Compass
  • Varnish
  • Xdebug

'Docksal comes preloaded with common Drupal development tools like Drush and Drupal Console, as well as php tools like Composer, PHP Code Sniffer, and php-cli. It also comes with node, npm, ruby, bundler, and python. There is built-in support for Apache Solr, Varnish, Memcache, Selenium, and Behat. And since services are containerized with Docker, any other service needed for a project can be added.'

from docker.io

paragraph
File folder locations
File Locations

Encourage Bash Scripting

I use Docksal with inbuilt support for Drush and Drupal console. Using the fin command one can use drush and console within the docker container. I have found this an excellent (and  gentle) introduction to bash scripts and drush.

Here I've placed some drush commands like cim alongside a simple script for downloading the site files :files-download

paragraph
fin drush sql-sync @prod  @emc23.docksal

By placing my drush aliases and docksal scripts on a per project basis I can minimise bloat and potential security risks. Meanwhile I'll copy the commands I use across at the beginning of each project.

This simple script downloads the site to local using rsync


#!/usr/bin/env bash

source ${DOCKSAL_PATH}/.docksal/command-settings

cd ${DOCROOT_PATH}

rsync -rvz --exclude 'js' --exclude 'css' --exclude 'php' --exclude 'ctools' --progress --size-only myrepo@myrepo.com:/app/web/sites/default/files/. sites/default/files/

It is executed by

fin files-download

Consistency

Having a consistent process across the team will allow for quicker fault finding and a deeper understanding of the options available for experimentation. When discussing these processes "But I use X" is not really helpful.

Is there someone on your team struggling with owning their drupal sites? An "each to their own" mentality is fine if everyone in the team is experienced, and you're hitting your deadlines with ease. But if that's not the case having a well trodden path will help the developer catch up.

You return to a project after six months. No problem, hit the url (if you can remember the project name)

http://emc23.docksal  <-- docksal will recognise the url extension.

Docksal will wake up all the containers, kickstart your mysql etc. (warning: it won't necessarily add your ssh keys. So if these are required you need to find your project folder and fin up as usual) and you can continue were you left off.

 

The database user is always called user and password user. NOTE: change host from localhost to db if you are using something like adminer. This is already done for you in settings.php

$databases['default']['default'] = array (
  'database' => 'default',
  'username' => 'user',
  'password' => 'user',
  'prefix' => '',
  'host' => 'db',
  'port' => '3306',
  'namespace' => 'Drupal\\Core\\Database\\Driver\\mysql',
  'driver' => 'mysql',
);

Closing

There are some great tools out there for developing in Drupal, but it can be overwhelming. A collective team effort to adopt docksal will empower your team to gently go even further beyond docksal.

The ultimate goal is a team that regularly shares and updates their drush and docksal scripts.

 

What Next?

I'm available for work and want to help your company introduce docksal to your workflow. Email via  http://emc23.com/contact

Published Tuesday, February 27, 2018