On this February I decided to participate with a project to the SUSE Hackweek.

Hack Week is the time SUSE employees experiment, innovate & learn interruption-free for a whole week! Across teams or alone, but always without limits. A SUSE tradition since 2007, Hack Week has brought together hundreds of hackers around the globe to collaborate on open source. Learn more about Hack Week here

My project has four main purposes:

  • play with the Nim programming language advanced features like templates and macros
  • experiment with container generation
  • practice Test Driven Development/Design
  • Have fun

So I decided to write a simple library that lets you describe a container image with a DSL (Domain Specific Language) that reflects the standard, declarative style standard for Dockerfile and Containerfile. The benefits of this approach are multiple: you have the compiler checking for any errors and you can use a proper programming language to add any logic you need.

Nim is a statically typed compiled systems programming language. It compiles to small native binary but can also generate javascript, see these beautiful generative art examples.

The library usage is straightforward: you can basically mix Containerfile syntax with powerful Nim language contructs: variables, loops, arrays and anything else.

import containertools

let my_app="program.py" 

let image = container:
    FROM "opensuse/leap"
    WORKDIR "/opt"
    COPY my_app my_app
    CMD @["python3", my_app]

image.save "Containerfile"
image.build  

I implemented everything using TDD (Test Driven Development/Design) and this approach made me rethink a lot of design decisions and refactoring, which maybe are evident in the source code repository history, but I loved how the incremental process of adding tests drives you towards a clean design.

The library also can work in the opposite way: you can feed it with a Dockerfile and it will check for errors or suggest some possible optimizations, but this feature is only at the early stage. Further ideas can be to check the container for secret leaks or check at runtime for issues like wrong image names or dangerous commands. We could also generate different kind of declarative files formats, as yaml for kubernetes, CI/CD workflows, and so on.

If you are curious about the inner working or want to take part in the development, feel free to get in contact.

I enjoyed HackWeek and this first Proof-of-concept implementation, looking forward to future improvements!