Developer “toss a coin to your” Dockerfile

I’ve been a witness of a discussion between Devops and developers where each of them were trying to move responsibility for Dokerfile creation to one another. Indeed, this may be not obvious responsibility segregation, especially if you’ve just started to develop containerized application. During preparation of another article about .NET Core containerization I decided that it worth to stop and clarify this topic a bit more. I tend to think that the providing of Dockerfile is the responsibility of developers, at first. But at the same time it doesn’t mean that DevOps should do nothing in regards of Dockerfile in general. In this article I’ll clarify my vision. So please continue reading if you were participating in such a debate at least once in your life. I’ll try to answer few questions which logically goes one from another.

What’s the delivery artifact?

Before the era of Docker and Kubernetes developers were delivering some binary package. EXE- or DLL-file with configuration files and satellite libraries. Applications were developed, built and tested on the same OS. This was the only option to make development environment as close as possible to production. In the era of containerization applications maybe developed on one OS and be deployed to another, for example developed on Windows and deployed to Linux. In short, Docker simplifies the process of recreating production environment on local machine. As a developer you’re still delivering some binary package, but now you need to wrap it into Dockerfile, just because it’s required by Docker engine. Dockerfile is nothing more then just deployment instructions which in the past were accompanying every distribution of binary packages.

Bearing above in mind, the delivery artifact of containerized application is still a binary package. The difference is that developer need to make sure that the application works when deployed to Docker. I don’t see any other ways to verify this, except by actually creating a Dockerfile, building an image and deploying it to a local Docker. So that at least one Dockerfile developer should create. Here I come to another question.

Should DevOps know details of assembling applications?

Time when DevOps were dealing with only one technological stack is gone. Now applications in the same company may be written on NodeJs, .NET Core, Android, MacOS including packages and deploying to different package management systems, for example NPM, NuGet, Gradle and CocoaPods. Keeping in mind that DevOps team usually is just another team of about 6 people, it’s literally overwhelming to know specific details of assembling each application. More over, with on going development it’s not possible to track all changes produced by development teams.

From the other hand, DevOps team knows precisely how all ecosystem of applications in production should work together. Such aspects as integrations, endpoints, deployment scenarios — this is what DevOps know the best. They can provide requirements for developers for their Dockerfiles, since developers may not be aware about ports and bindings inside the infrastructure. Moreover, creation of an image for production deployment may include additional configurations to reflect the actual infrastructure which developers may not know. Configuration includes such traits as port mapping, security, “sidecar”, etc. and they can be done based on images created by developers (thanks to layered architecture of Docker images).

As a bottom line

Wrapping up everything above I would suggest to treat Dockerfile as a specification for DevOps how to assemble an application. Bearing this in mind everything becomes clear.

• Developers deliver specifications of assembling their applications adhere requirements to production environment and altogether this is described in Dockerfile.
• DevOps prepare deployment scenarios creating derived Dockerfiles and deployment scripts to Kubernetes or Docker.

In the simplest scenario, Dockerfile produced by developers can be used to deploy to production if it’s written according to requirements, provided by DevOps. So that in the edge case of simplified scenario developers are responsible for creation of Dockerfile. In the real life every counterpart is responsible their own part in the development process.