Dropwhale 2.0 RC2
For the last few months I've been working on a rewrite of Dropwhale, my Docker-based testing harness for Drupal 8 modules. While I didn't intend to spend most of my weekend on it, I'm pleased with the progress it's made.
The improvements
The first, and perhaps biggest change is that it's now based on Nginx and PHP-FPM. I've wanted to switch to Nginx for some time now, but it's been difficult for me to make the transition from Apache. I spent several weekends and evenings teaching myself the differences and reading tutorial after tutorial to use it as a web front end for Drupal. Since Dropwhale is for development purposes, the scalability improvements provided by LEMP aren't necessary. I hope it will at least consume less memory than Apache.
Secondly, and as of today, Dropwhale has a new configuration system. Instead of modifying a Docker override file, there's now the dropwhale.settings file. Whereas before you had to edit key statements in docker-compose.override.yml and preserve Docker's YML format, dropwhale.settings is much simpler. Each setting is just a KEY=value pair, each on its own line. As a bonus, the settings file is fully commented, with explanations and reasonable defaults for each setting.
Dropwhale is also leveraging several newer features of Docker. The docker-compose.yml file is now using the 2.0 format, making it simpler and easier to read. It also brings transparent virtual networking support for better inter-container connectivity.
Several of the supporting script files (start.sh, stop.sh, reset.sh, etc.) were improved for better performance and user experience. Internally, Dropwhale now uses a more nuanced build system. After doing a git pull on Drupal core, the web root is recreated fresh. Your module is then added to the modules directory via a symlink. This prevents the build process from deleting your repository accidentally. Hopefully this will also prevent Docker "volumeception" if you decide to mount the Drupal installation directory as a volume for debugging purposes.
Also all the containers are now based on Alpine Linux, rather than Debian. This reduced the size of Dropwhale containers by a factor of three. This means it takes up less space on your disk, and it's faster to download and start up Dropwhale for the first time.
Known critical issues
There are currently two known critical issues.
The first causes some Simpletests to fail in odd ways. I haven't figured out why this happens. I even had a core maintainer look at it for hours and he was also perplexed. It appears to have something to do with the Nginx configuration, but I don't know how or what. For the moment, I've been ignoring it, hoping to stumble across a solution, or have someone much more experienced point out what in the hell I'm doing wrong.
The second bug is due to a recent change in Drupal Console. I suspect the installation method changed over the weekend, resulting in Console being nonfunctional. Since it's installed by the upstream container, I suspect the proper fix will involve a PR to Wodby's container.
What's next?
Right now, Dropwhale uses shell scripts to do all its internal building and other processes. The scripts are beginning to be rather complex, and I'm starting to wonder if I should switch to a configuration management tool such as Ansible. I've been going back and forth on this one for a while. In the past, the reliance on basic shell scripts meant that Dropwhale was hackable, allowing others to easily understand and modify the testing framework. As the scripts become more and more complicated, however, it's starting to become difficult for me to manage it. I use Ansible everyday on the job, so it seems like a natural fit to leverage it here. The problem is that this comes at an expense in size. Some basic experiments add some 70MB to the PHP container. That doesn't sound like much, but it's frustrating after all the effort to reduce the size of the containers.
I also have been wondering if it's time for me to put together a site for Dropwhale. At present, it only has the Github page. There's no custom domain, not even a site on Github.io. It's hard to encourage others to use Dropwhale without a nice page to advertise it to The Weekly Drop and the like. The problem is, my time and money are limited. While a domain wouldn't cost much, I don't know if I'd have the time in the next month to put it together. An alternative idea would be to make a projects section on deninet.com, but that also feels like burying the lede.
If you have any input, you can @ me on Twitter, or on Dropwhale's Github page.
