Technology · Infrastructure

Docker — from the development machine into production

Docker solves a problem every team knows: the project runs on one machine and not on the next. We containerise development environments so that the PHP version, the database and the search index are identical everywhere — and we run our own applications in containers on our Proxmox infrastructure. What Docker does not do: turn an unclear architecture into a clear one.

Standard in development and operations

What is Docker?

Containers make a setup reproducible. They do not solve an architecture problem.

What we use Docker for

In development, every project brings its own environment with it. The PHP 8 version the project requires, plus MariaDB, Redis and, where needed, Elasticsearch — described in a Compose file that lives in the repository. Anyone joining the project starts the environment and gets to work. That replaces half a day of setting up a local system, and the arguments about why a bug only appears on one machine.

In operations we use containers for our own applications: Node.js services, Python tools, interfaces between shop and ERP. The real gain is the separation by service. Database, cache and search index each run on their own, can be updated individually and do not affect one another. Classic shop and CMS installations, by contrast, we often still run on a dedicated virtual machine — more on that below.

How we work with Docker

One Compose setup per project, versioned in the Git repository, with the same services as the target environment. We build images from slim base images and pin versions instead of trusting latest — otherwise the environment changes without anyone having changed anything. Configuration comes in through environment variables; credentials do not go into the image. Databases get named volumes so that a restart does not cost data.

Building and rolling out happen through the CI pipeline: tests run in the container, the image is built, pushed to a registry and pulled onto the target machine. That target machine is usually a virtual machine in our own Proxmox cluster, on servers in Germany. Logs go outside, not into the container. And every container gets limits for memory and CPU, so that one outlier does not take its neighbour down with it.

Limits and alternatives

Containers do not solve an architecture problem. Containerise an unclear system and you have an unclear system in containers, only with more moving parts. Before we put anything into containers, we establish which services actually exist, where state lives and how data flows. Skip that step and Docker merely moves the pain from the server into the build pipeline. The second point: not every system gains from it.

Kubernetes is overkill for the vast majority of mid-sized projects. One shop, one CMS, a handful of background services — that does not need a cluster scheduler, it needs a properly sized machine. Running Kubernetes costs attention that is then missing elsewhere in the project. It starts to make sense when there really are many services to orchestrate, or when several teams deploy independently. For a single TYPO3 or Shopware installation we stay with the virtual machine, with backup and snapshot.

Frequently asked questions

Do we need Docker if our shop runs stably?

No — a shop that runs stably is no reason to containerise it. Docker pays off where several people work on the same system, where development and production drift apart, or where nobody can cleanly rebuild an installation after a few years. If your system runs, is documented and can be restored, there is no occasion for it. The benefit comes from reproducibility, not from the technology itself.

Is Docker secure enough for production?

Docker runs securely in production if the operating practice is right: current base images, pinned versions, no credentials in the image, containers without root privileges, limits for memory and CPU. What makes it insecure is habits, not the technology — images nobody has rebuilt for two years, or registry access that too many people know. We update images as part of maintenance and rebuild them through the CI pipeline.

Do we need Kubernetes if we use Docker?

No, for the vast majority of mid-sized projects Kubernetes is overkill. The cluster scheduler orchestrates many services across many machines and demands its own operational effort in return: cluster updates, networking, storage, rights management. With one shop, one CMS and a handful of background processes, that effort clearly exceeds the benefit. In such cases we run containers on a clearly sized virtual machine. Kubernetes becomes interesting when several teams deploy independently or a great many services interact.

Docker: existing system or new build?

We also take over systems that were built elsewhere — after a look at the code and the hosting.

Start a project 0441 21 21 63 0

What else we build with

Call Start a project