I think the question should not be about dockware, but more “Why is DOCKER better instead of installing it locally”. And there are lots of different reasons.
We all know the problems when we need different PHP versions for different projects.
And then we also want to switch multiple times a day. Unfortunately, there’s not only PHP, we have npm, node, composer and way way more.
Although it’s possible to use systems to prepare different versions for your current project setup, it would still mean it’s installed locally. It can work, but it can also create side effects and go wrong. For me, having a prepared and isolated environment just feels better somehow.
With Docker images you have the benefit that everything is isolated and prepared inside that special container for your project. While 1 project might use PHP 8.0, the other one has PHP 7.4. And on your developer machine, you might not even have a PHP version installed. So this is indeed the power. We have a world full of dynamic possibilities without needing anything locally installed.
When we face services like Elastic, Redis, RabbitMQ and more - do you really want to install and run these locally? I doubt so.
Instead we prefer having the option of just adding a service to a specific client setup and just run it, instead of installing it first. So you build your architecture based on ready-to-use services, and keep your host system clean.
When it comes to dockware, which is based on Docker, we try to bring the experience to the next level. While we always aim for sticking to standards as good as possible and being transparent when it comes to using things like Docker itself, we try to remove the hassle of common troubles when developing with Shopware, and for Shopware. We focus on a good developer experience and lots of use cases, such as plug and play scenarios for developers, requirement engineers and testers. Also on topics like “easy coding” for shops and plugins, as well as CI/CD pipelines with dockware.
Dockware has different images for different use cases.
Maybe you just want to play around with Shopware if you are a project manager, requirements engineer or even merchant? You probably don’t have the expertise to install everything you need for Shopware locally, right? But what you are able to do is, to install Docker and run that 1 single command to have any Shopware 6 version running.
Or maybe you want to develop things and you require specific tools like PHP, NodeJS, npm and more?! Everything you need for Shopware is already prepared in our images, and you can even switch things like PHP versions, also at runtime while you code.
You can either launch any Shopware version, completely pre-installed and ready to use, or easily install your own Shopware instance.
Once up and running (within minutes), we try to do our best when it comes to developer experience. According to other developers, things like the XDebug experience are really great, because it just works. When it comes to using the watchers in Shopware, it’s also very easy. You just expose the ports and use our make commands that wrap a few things for you ;).
So I think dockware might indeed be the better decision if you don’t want to think about how to install a Shopware instance in a specific environment. You just use it.
Yes, that’s true! We use the approach of containerizing apps, one of the things that makes Docker images so great.
Every image, at least the ones that contain a Shopware, has everything already installed and prepared while building the image. This means, when you try to start a new container from such a pre-built image, the container will only boot, and not install things, which usually takes just a few seconds. Afterwards you have a working Shopware instance up and running. Easy and fast.
For us, it was just a boring task in the end, to always run that “psh install” command over and over again. So we thought let’s get rid of it and move it to the building phase of the image instead of doing it after starting a container.
But I think the most interesting thing is, what is happening during build time.
When dockware (or the previous internal images) were born, they had no Shopware installed at all. Instead they were used as that perfect environment for developing with Shopware. Still, it was frustrating to maintain all these different images that include different PHP versions, Node versions, XDebug and more. That was when the Docker Generator, now called “ORCA” was invented. So that, and other tools, help us to make sure that our images really work in the end.
You can think of it like this.
With “ORCA”, all these different Dockerfiles are generated based on the TWIG framework. That allows us to handle templates, use blocks to customize specific versions like “dockware/dev”, “dockware/play” and also use variables to bring some dynamic values in. The compiled result is then just a plain Dockerfile and its required configurations. So this helps us to get rid of the maintaining work across all these, over 250 images by now.
They are then, of course, being built inside an automated combination of pipelines in Github and CircleCI. It’s always possible to build the images with plain Docker build commands on your own for your current system, but on CircleCI we also focus on different architectures to also provide versions for the Mac M1s.
However, before really pushing it to Docker Hub we still need to make sure that every single image works. For this, we have different testing tools.
“SVRUnit”, a self made server unit testing framework, helps us to test our Linux Docker system against expected criteria and behavior. Is the XDebug version correct and enabled? Do we have the required PHP extensions installed? All these things are automatically tested, just like with Unit Tests. And as soon as these requirements are met, we even run a Cypress Test Suite to ensure the functionality of the installed Shopware version within the browser.
Only then, we push the images to Docker Hub for our growing community with over 1 Million downloads by now.
