Build & Deploy time Service Configuration - meetup notes
Daniel Silverstone
daniel.silverstone at codethink.co.uk
Fri Feb 6 13:01:36 GMT 2015
Hi all,
Here is a brief writeup of the discussion we had at the meetup regarding the
configuration of services at build and deploy time. They're fairly
brain-dumpy, so I apologise if they're not completely coherent. I'm hoping
that initially others present at the talk might chime in and correct them and
that we can then discuss the value or otherwise of the approaches before
selecting one to implement.
The BoF was centred around the concept that we need to communicate some amount
of structured configuration data from the build phase of components of the
system into the configuration phase of the system. We briefly outlined two
possible approaches to this, and then gave a basic example so that everyone at
the talk was able to consider the proposal and decide if they thought it
worthwhile to produce. Finally we discussed possible follow-on work which
would arise from this, and possible technologies it could enable going forward.
All of this I shall attempt to reproduce in summary for below:
Approach 1:
Structured data in the definitions files themselves. This data would be:
* Structured as YAML
* Not validatable by morph tooling (at least at first)
* Provided in some way to the configure, build and install phases of the
component build process.
* Provided in some manner to the configuration phase, perhaps by widening
the API of the configuration phase to include the fully resolved declaration
of the top level components being configured.
Pros:
* Declarative approach matches our general ideals
* Structured data *could* later be subjected to validation of some kind
* Only need to read the definitions to understand the configuration data.
Cons:
* Not all configuration which might be good to manage in this way is easily
and usefully represented as YAML
* Widened interface with configuration/build/installation of components and
with the configuration phase extensions themselves increases the amount
of documentation and complexity in replacing any given part.
Approach 2:
Structured data (if needed) installed into particular filesystem locations by
components as they are built, and processed during integration scripts or
configuration extensions.
* Structured in whatever way suits the data
* Not validatable by morph tooling (and unlikely to ever be easily validated)
* Provided by the component build process as part of the binary artifacts
* Accessible to later integration scripts as well as the configuration phase.
Pros:
* More flexible
* Accesible at integration time as well as configuration time, which might make
for more usability (e.g. ensuring certain users or groups are present in the
/etc/ files during builds for things which use getent rather than allowing
configuration via flags or the environment).
* Does not increase the set of APIs needing to be defined by the build tooling.
Cons:
* Defers such API definition to the definitions repository internal structuring
increasing potential for 'everyone does it differently'
* Harder to write formal validation for the data
* No possibility of standardised manner for overriding elements of the
configuration of one component from another.
Example:
We came up with an example using a combination of users/groups (which are
getent databases) and sudoers (which is not)
The example we came up with was:
sudo.def:
...
groups:
- name: sudo
id: dynamic
...
httpd.def:
...
groups:
- name: www-data
id: 33
some webapp.def:
users:
- name: mywebapp
id: dynamic
groups:
- sudo
- www-data
sudoers:
- Cmnd_Alias WEBOPERATION = /usr/lib/mywebapp/magical-secured-rootly-helper
- mywebapp ALL=(root) NOPASSWD:WEBOPERATION
Extensions:
At least two people present were interested in extending the configuration
phase in a way which allowed it to create partial data in the configured
file-system and then store configuration data for instantiation orchestration
at a later time. (E.g. using privately calculated uids/gids for local test,
specific ones for a shared dev-env, different ones for shared-test, and
different again for production, all from the same binary artifacts generated by
the write phase of deployment).
Conclusions:
Everyone agreed that it was worthwhile producing this kind of configuration
data and the general consensus was that while the second approach was more
flexible overall, the first approach would likely be acceptable and we could
extend the availability of configuration data to the component in question and
all components build-depending on it.
Throwing it open to the list:
Firstly, if I have misremembered or forgotten anything from the BoF, could
others who were present please correct/augment the above.
Secondly, if this strikes anyone as interesting, comments, suggestions, etc
should be provided on this thread.
We propose to hold off on implementing this until we are ready to specify it as
part of version 1 of the new definitions format, (or perhaps even later than
that) -- see the thread about declarative definitions if you want to help
that happen sooner.
Many thanks for all those who attended that particular BoF, I found it very
interesting to hear about your ideas and I was gratified that noone at the
meetup decided to suggest this was unnecessary.
I look forward to seeing other writeups and to hearing from anyone on the above
points.
Regards,
Daniel.
--
Daniel Silverstone http://www.codethink.co.uk/
Software Engineer GPG 4096/R Key Id: 3CCE BABE 206C 3B69
More information about the baserock-dev
mailing list