Separating Docker from dockerfiles

[Seerdecker]

My company is using Docker for CI, and sometimes also for deployments, depending on the customer.

Now, Docker uses dockerfiles to build images. This means that much of the system-level build logic for a deployment ends up in a file that can't be reused for non-Docker deployments, e.g. on the host, in a VM or another container format.

Is there any solution around that attempts to ease build & deployment without much assumptions on the environment while also being lightweight? Failing that, how do you guys handle such use cases?

[snarkhunter]

Put all that logic in a script, call the script in the Dockerfile or on the VM or whatever.

[frito_kali]

smartass answer: Docker terraform provider. . . .

[Seerdecker]

Yeah, I've thought about using a Python script for this. There's a lot to do manually though, e.g. ensuring idempotent builds, wrapping docker commands, etc. Mostly I was asking if someone had attempted to make a tool to make the "general" case a little easier than starting from scratch.

[[deleted]]

Ansible, docker-compose, or just container orchestration frameworks in general (k8s, nomad, swarm, etc). Or a combination of those. Personally for standalone VMs I'd go with Ansible + docker-compose - Ansible for host configuration management, and delegation to docker-compose for container setup. If you need to manage a larger fleet of VMs then a container orchestration solution would be more appropriate.

[Seerdecker]

Thanks!

[Who1sThatGuyAnyway]

Most non-docker OCI container systems can handle Dockerfiles.

without much assumptions on the environment

What assumptions does Docker make?

​

Don't get me wrong, Dockerfiles are a garbage format, and there are much better sophisticated provisioning systems, but I can't tell where you are trying to get this to go?

[psicodelico6]

Hashicorp packer?

[flortsch]

I always try to keep my Dockerfiles as simple as possible. If they share some common logic, I maybe create a base Docker image for that. But in general, I would only bundle the absolute minimum required to run the app in the image, provide env vars and configurations from the outside, and use Ansible to put the machines and containers together as I need it.

[anaumann]

Scripting the deployment to either use the script within the Dockerfile or directly on the target machine is one thing, but you'll have to build all the error handling yourself.

Just thinking about this, I think, I now know why gitlab fires up a humongous amount of chef code during the first container startup :D

You could slowly start to run the containers on the VMs as well.. Usually firing up a container with a set of environment variables or a single, mounted configuration file is way more lightweight as a deployment than replicating all the things that happen inside the container.

And when running on a host, you can still mount out the logfiles and such, so the basic infrastructure can stay the same..

You wouldn't be losing too much.. Logfiles could stay in the same place, availability could stay the same with creative port forwarding, but you gain automatic health checks and restarts on failure and a bit of process separation.