Mark Dastmalchi-Round

Mark Dastmalchi-Round

I’m a DevOps architect, musician, animal lover and all-round geek. If it’s got shiny lights on it, makes loud noises or purrs/wags its tail when you stroke it, I’m all for it. When I’m not writing code or fiddling with computers for a living, I produce my own music and provide the low-end rumble for my band in West Sussex.

Tiller 0.7.0 and simpler configuration files

Updated:

Note : This page may contain outdated information and/or broken links; some of the formatting may be mangled due to the many different code-bases this site has been through in over 20 years; my opinions may have changed etc. etc.

Yesterday, I released Tiller 0.7.0, and as you might imagine with a version “bump” from the 0.6.x series, there’s a few changes. Some of it is internal stuff that you’ll probably only notice if you’re building your own plugins for Tiller, but there is a fairly big new feature for end users: Single-file configuration.

Recently, when I’ve written some documentation or examples on how to use Tiller, I’ve been struck at how I had to create several files in different directories just to illustrate a simple point. This approach has some benefits when dealing with larger configurations or inherited Dockerfiles, but for simple jobs it’s a little unwieldy.

Take for instance my JSON walkthrough example as a case-in-point: You have to create 3 different files (4 if you include the template) before you can get started. Instead, with the new format common.yaml, we can put everything apart from the template content in a single file:

1
2
3
4
5
6
7
8
9
10
11

data_sources: [ 'defaults', 'file', 'environment_json' ]
template_sources: [ 'file' ]

defaults:
	global:
  		default_value: 'This is a default global value that may be replaced'

environments: 
	development:
		json_template.erb:
  			target: 'parsed_template.txt'

I’m sure you’ll agree that makes things much easier to read and follow!

Admittedly, for complex environments you may well want to keep the “one file per environment” approach - particularly if you have a base Docker container with a standard common.yaml that all your other containers inherit. For that reason, Tiller will continue to support both methods and I have no intention of removing support for “old style” configuration. So don’t think of the way things used to be done as deprecated in anyway, it’s just that there’s now a new approach that may make your life easier :)

As always, I welcome all feedback, bug reports & feature requests - just leave a comment on this blog, email me, or open a ticket on the GitHub issues page.

Comments

You May Also Enjoy

Amiga Systems Programming in 2023

If you ever get a chance to look through the classic Amiga OS source-code still floating around some murky corners of the internet, it is a thing of beauty and astonishing capabilities. It’s an inspirational piece of computing history with unmatched capabilities for the time. Remember, this was all on a computer released in the 1980s with 512Kb memory, a 7Mhz 68000 16-bit CPU, and a single floppy drive with 880Kb storage. On these limited specs, AmigaOS provided a pre-empt...

Haiku Package Management

I’ve long since been a die-hard BeOS fan and have been running the open-source recreation Haiku for many years. I think it’s interesting to explore the “alternative OS” world and consider some great ideas that for whatever reason never caught on elsewhere. The way Haiku handles package management and its alternative approach to an “immutable system” is one of those ideas I find really cool.

A Splinter In Your Mind

Earlier this year, I finally discovered as an adult that I am “on the spectrum” with what used to be called Asperger’s Syndrome. The diagnosis helped make sense of a lot things and has given me a greater insight into my “way of being in the world”. Whilst there are times I struggle with things that neuro-typical people usually find easy, or I find some situations draining, the condition has also brought me many positives which often get overlooked when talking about Autis...

DevOps for the Sinclair Spectrum - Part 4

In Part 3 I covered the backend server processes and protocols, CI/CD pipelines and unit tests I used to build the TNFS site. In this (much shorter) part, I’d like to take a step back from the hardcore geekery, and wrap up with my thoughts on the whole thing.