Introduction
I’m using containers for my day-to-day job more and more. Yes, containers are great, but containers are not a silver bullet. You still have to update them on regular basis. When you just have your application that is running on top of a runtime, it’s easy, you update the FROM and case closed. But what about when you have several dependencies included? This is the goal of this tiny project. How do you keep your container image fully up to date?
How is it working?
Like all my new Powershell projects, I’m using the Sampler module to build, test and publish my ideas. This time, the goal isn’t to publish a new module into the Powershell gallery but more to generate an artefact (Dockerfile), build a new Docker image from it and publish it to a container registry.
Functions
I’ve created few private helper functions to fetch the latest stable release of:
Finally, there is the New-DockerFileFromTemplate function which, based on a Docker Template file, generates the new Dockerfile with dynamic string replacement. In other words, if you want to add/remove a new software in your container image, you have to modify the template.
Tasks
To help me to interact with Docker (of course you need the docker engine installed on the runner), I’ve created few tasks located under the generateDockerFile.build.ps1 file. For now, a lot of parameters are hardcoded for my need, I may change that in the future.
Build
The last part is the build.yaml file that is used to orchestrate the automation.
The main idea is to build the PS module as usual with public/private functions, test the module with the Pester framework to validate the module is working properly, generate a new dockerfile and then publish a new image to my Github container registry.
Github Action is used to check out the code and generate a new Docker image. As you can see, thanks to Sampler, the job is small:
Logs
If we now check the Github Action logs, we can see that Sampler take care of the bootstrap:
Then Sampler will build the module and run the tests:
If everything goes well, the next step will be to connect to the container registry and build the image:
Conclusion
I’m not saying I will do this for all my projects, but some people maybe be interested in the process of keeping the generated image up to date from a cron job or another tipe of event. In addition, I’m using the same process (that I don’t explain here) to patch a generated image with Copacetic and Trivy before exposing it to my end user.
I hope this article has been useful, see you in the next one.
Cheers