Over the past several weeks, I've been working with three of the more well-known Docker-based local development environments that involve a Drupal focus: Docksal, DDEV, and Lando. The goal is to not only to figure out which one I prefer, but also to figure out which our two long-form online Drupal training classes should potentially standardize on.
Our classes are often comprised of folks from all different technical backgrounds, so it is important that we not only teach them tools that Drupal professionals use, but also something that folks of myriad of skill levels can easily consume. Perhaps most importantly, while the majority of our students are on Mac OS X, we still have a consistent number of students using Windows, so any solution we recommend should work similarly on all platforms.
As a Mac OS X user myself, it is important to me that I can instruct our Windows-based students without having to resort to a separate set of instructions. To that end, I have an actual Windows 10 Pro machine (not a virtual machine) that I've been using to evaluate these local development environment options.
I've decided to focus on DDEV, Lando, and Docksal because I really like the idea of Docker-based containers; being able to customize your local development environments to each project has too many advantages to ignore. Also, as one of our classes is Pantheon-focused, Lando's Pantheon integration is a very important differentiator.
I have a basic set of requirements that a local development environment should be able to handle. These requirements are probably focused more on our introductory Drupal Career Online course, but I'd like to be able to recommend the same solution for any of our courses.
- Run Composer commands (including create-project). It doesn't matter to me if this command is run on the local OS or in a container, as long as it works with a minimum of fuss. The "create-project" command can be a bit tricky on Windows - keep reading to find out why.
- Run Git commands both on the local OS and in the container.
- Be able to get up-and-running with a minimum of downloads. On Mac OS X this isn't much of an issue with Terminal, Git, and PHP preinstalled, but on Windows it is a different story.
- Be able to get up-and-running with a minimum of "extra" configuration. Granted, once you're comfortable on the command line adding something to your local PATH isn't a big deal, but for folks new-ish to the command line, it can be a significant hurdle.
- Have a Linux-based command line interface (to use commands like cd, ls, cat, etc...)
- Be able to easily (zero configuration) edit text files on the command line (nano or pico).
- Be able to modify file permissions and ownership from the command line (chown and chmod).
- Be able to run Drush, Drupal Console, and all of the other Drupal-y things that a professional developer should have.
I am very cognizant that my requirements are probably represent the lower-end of the Drupal skill-level spectrum, but I feel these requirements are a reasonable starting point.
Over the past few weeks, I think I've installed, uninstalled, and reinstalled various combinations of Lando, Docksal, and DDEV as well as various command line shells (Babun, Cmder, PuTTY, Cygwin) and the Windows Subsystem for Linux at least a dozen times on my Windows machine. All this in an effort to figure out what is the best combination of tools to satisfy the requirements. At the current moment, I'm circling around recommending Lando and Cmder on Windows (Lando requires Windows 10 Pro with Hyper-V enabled) - both are easily installed with no extra configuration necessary to get almost everything working.
With just Lando and Cmder installed almost all of the requirements are met. I can use Git to clone a site down to my local, get it up and running in Lando and get to work.
One minor issue is that Cmder doesn't come with nano nor pico for editing text files from the command line. It does come with vim, however (which we all know has a steeper learning curve). I can probably mitigate this issue with a little bit of config to have students run a command to open text files in something like Notepad++ or teach some basic vim commands.
The other issue is a bit more serious. With only Lando and Cmder installed, there's no way to run "composer create-project". While Lando makes Composer available in the container, developers don't normally create the containers until they have a code base. This is a bit of a chicken-and-egg issue:
- We need Composer to get the new code base.
- We need the Lando container to be up-and-running to get Composer.
- We need a code base before we start Lando.
- (return to step 1 above)
So, I think I know what you're thinking: just install Composer. Well, this isn't as simple as it sounds, as Composer requires PHP, and as far as I can tell, installing PHP on a Windows machine isn't super-straight-forward. Granted, if the developer already has another AMP stack on their Windows machine, the Composer install can be configured to use the php.exe installed with it.
Docksal actually has a command that allows a developer to run Composer without actually having a set of containers already initialized for the project using the "fin run-cli" command. This utilizes a standalone cli container and completely removes the need to install Composer on the local OS.
So, where does that leave us? I'm not 100% sure, but I wanted to put this out there and get some feedback. Are you a professional Drupal developer that uses Windows as your main OS? If so, what's your setup? Am I missing anything?
While I often try to steer new Drupal developers towards Mac OS X or Linux, sometimes it is not possible due to corporate policies or even just personal preference. I'd love to be able to teach a solution that provides a professional-level Drupal developer experience to Windows users.
At the Drupal Global Sprint a week or so ago I decided to dust off the old Surface Pro and do some Drupal development. I was able to install Docker and Lando, do a Composer build via Lando container and get a site up and running.
It should be noted that I was cloning down the dev 8.6 branch and not using zip or tar files from the main DO page.
I usually start by deleting the lock file, but it is advised to delete the vendor directory with the lock file before running drush qd --use-existing (Thanks to David for this command as I was using drush si prior to his suggestion and then either importing a database from a site I was previously working on or walking through the steps of setting up a new site in the web admin console).
Oh yea, and all of this was from a PowerShell Admin console...
Did you do a comparison chart based on your requirements?
Not yet, but soon...
I've been doing professional Drupal development on my Windows computer for over a decade. Also do Laravel and Symfony. My setup changes depending on client/project needs. Most of the time I develop straight in Windows. For the WAMP stack, I use Neard (https://github.com/neard/neard). If it's a project with a service or two that I need from Linux, then I'll just spin up a Docker container for those (usually Redis, but also Solr and Elasticsearch). For the more complex/involved projects, then I develop those straight in a VM. I don't use Vagrant (though I used to). I just create my own VM and use PHPStorm's deployment options.
What you may want to consider is offering straight VMs in HyperV and VirtualBox flavors. Have them do everything through that. Then you can offer a fully, pre-built environment for them and everyone will be on the same setup.
With Docker my biggest fear would be data loss. Yeah you can do volume mounts on the host system, but for Windows that means setting up a share and that could lead to problems with corporate users and the security policies of their company (I've done a lot of corporate work on Windows over the year and never seen one that allows any user to create a share).
With a VM everything is stored inside the VM (you could even do Docker in the VM). If it's a matter of being more portable, they could then just use something like GIT to sync their codebase (or a drush dump) to a github account and then pull it in on another instance on a separate machine.
I have, but at this time I'm focusing my efforts on Lando, Docksal, and Drud.
I'm a 3 platform developer (Windows, Linux, MacOS). Mainly I use Windows to code. To me, performance matter. So I won't use any docker based solutions. The slow file sync, config. There're a lot of problems afterward.
My Windows Setup:
- XAMPP (portable)
- Cmder (portable)
I actually run my custom version of ConEmu based on few Comder config. Less buggy, I don't need another exe wrapper of ConEmu. I removed the Git status hints that affect the `cd` performance. I only left the simple git branch status
You must enable clink in Cmder to get Linux alike command-line style. (also @see: https://github.com/mridgers/clink/pull/464#issuecomment-322475049. KayLeung is me also)
In the installation option, ticked install to Windows Path. Then you have a set of Linux tool:
Those fulfilled all of my daily works.
- Windows Sub-system
Only used when the command is failed to run in Windows. I seldom use it (Performance Matter). There's some tip. You can run `git.exe` understand the sub-system. You will get the same I/O performance as the Windows. In another word, by adding the `.exe`, you could take most of pipeline command from Linux to Windows sub-system.
By the way, I didn't run into any Composer issue under Windows. I've contributed to Drupal Core also. I checkout the Git branch frequently and run `composer install` :)
** Don't use single quote in Command Line since Windows doesn't support it.
I am a professional developer, I have been engaged in Drupal for over 9 years. But I could not get Doker to work on Win 10. Although I've worked all my life under Windows
I recently installed php and composer on win 10, alongside lando. I was afraid due to bad previous experiences, but it was fairly painless.
I am a fan of Docker stacks; however I will have to admit for training classes where the O/S environments vary by user machine and the proficiency users with Docker on their local setups is unknown, I opt for a Vagrant configuration with a VirtualBox VM over all else. It runs on all O/S environments (All flavors of Linux, Mac OS/X, Windows 7 through 10), and with the exception of a few minor configuration differences per O/S that can be scripted into the Vagrantfile, the user experience is pretty much the same once you get the box up and running.
DrupalVM is not a bad option but it just takes so dang long to spin it up that I usually roll my own, and install exactly what I need for whatever class I'm running....this way I can get people up and running quickly and efficiently and focus on the task at hand rather than troubleshooting developer environments for half the class.
Chocolatey is the missing piece: https://chocolatey.org/
That allows you to install PHP in a single line. And then proceed with the rest (Composer, Cmder, MySQL, Apache).
Windows is my preferred primary OS. I still use Win7 on the desktop as my primary workstation, and Win10 on my laptop. I have explored several options, always looking for a better setup, but keep returning to Ubuntu in a Hyper-V VM. It is very fast and flexible, and most of the VMs live on a dedicated server. So I don't need to worry which machine I use to access it, and it is easy to backup and snapshot before trying something new or risky. I like the Lando approach, and backed Kalabox. I never got Kalabox to work right, and Lando is clunky at times, and can be incredibly slow. I think this is largely Docker.
Another reason I prefer VMs is I don't want any of the tools installed on my local desktop. I want PHP, Composer, Node, Drush and so on to all be in the VM, so they don't effect local performance, or introduce version conflicts.
This solution might be a bit antique compared to the flashy new platform of the week, but it rock solid. PuTTy and Samba shares are my primary interface for working with the VM.
I would be very interested in solutions that leverage the Win10 Linux sub system. But I haven't had a ton of luck with it yet.
Im developing Drupal daily, and work with many multiple projects. Because of this working with docker was a pain in the ass because it used way to mutch diskspace (100+ Projects). The most performant way to deal with this mess was WSL for me and since the latest windows patch you can also fix read issues so that you can work almost at fullspeed without any vm which eats lots of ram