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.