terraform-provider-docker VS terraform-provider-docker

... and if you're an opinionated person, like me, and you value consolidated infrastructure atomicity as a whole along side locks for everything. You'd port cherry-picked helm charts as terraform modules with k2tf, and build every docker container from scratch, with forced layer invalidation to perform security updates for every image, using the docker and kubernetes providers respectively.

For the docker management, we are going to use terraform module kreuzwerker/docker. It provides us an opportunity to build and upload docker image to a docker repository.

Communication is crucial; that's why we want to keep it public, even if we receive private requests through other channels such as @gophers/terraform-provider-docker in Slack. We encourage engineers to open an issue or use the recently released discussions feature from GitHub. The code of conduct helped us set the etiquette guidelines, how we want to work together, and which tone and politeness we expect.

We all use open source projects to develop, run and evolve the software that we use both internally and at the clients who pay us for our expertise and experience. We find bugs, see the need to extend the functionality or stumble over a piece of documentation that is not fully clear and understandable. We know talented folks took precious time to design, create, maintain and evolve such open-source projects. As we are working on those projects heavily, we carve out time to make a contribution by creating bug reports and providing fixes for them; and if we see the need for a new feature, try our best to provide it. In our case, we wanted to deploy docker services into a docker swarm via terraform. As those resources were not supported at that time in 2018, we filed a colossal pull request, which led us to important learnings. We will talk about them later in detail in this post. First, let's explain how it evolved that we started maintaining this terraform provider.