There are a lot of different ways to configure containers running on Kubernetes: Environment variablesConfig mapsVolumes shared across multiple podsArguments passed to scheduled podsetc. Those alternatives fit a specific context, with specific requirements. For example, none of them allow you to clone a Git repository before the container starts. It would be possible to design that feature into the image itself. Yet, that would introduce coupling, and defeat the Single Responsibility principl
It seems pretty popular right now to bash widespread software design practices, e.g. dependency injection, frameworks, annotations, etc. While there are some downsides of adopting those practices, I believe there are more benefits. In that post, I’d like to address those points, and come up with arguments in favor.
Last week, I wrote on how to design a generic Docker image for Maven-based auto-executable webapps. The designed build file has 3 different stages: checkout from Github, build with Maven and execute with Java. The Maven build stage takes quite a long time, mostly due to: Executing testsDownloading dependencies Tests can be executed earlier in the build chain - then skipped for Docker, this post will focus on speeding up the download of the dependencies. Let’s check each option in turn.
Since the Docker 'revolution', I’ve been interested in creating a Dockefile for Spring applications. I’m far from an ardent practitioner, but the principle of creating the Dockerfile is dead simple. As in Java - or probably any programming language, however, while it’s easy to achieve something that works, it’s much harder to create something that works well.