Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Separation of concerns
- Service Packages bring their own minimal viable configuration
- Application Packages bring their additional dependencies (if needed)
- Host Configuration brings fine-tuning (if needed)
Reduce host-specific configuration, or: "Dont repeat yourself (or your configuration)"
Modularized Configuration Snippets
*.yaml files in
/etc/yadt.conf.d/ get merged
Structure of Host Configuration
- dictionary of dictionaries, aka map of maps
services: fooservice: ... settings: foo: bar
Rules for Merging Snippets
Dictionaries get merged (recursivly).
Lists gets concatenated.
Scalars get overwritten (order of files matters here).
Let's configure a host with a spring webapp. We want the webapp to run in the tomcat container, and tomcat itself will run behind a httpd webserver so that it can bind to port 80. We'll have the following packages installed at least :
- A tomcat package, which should bring a snippet with
- An httpd package, which should bring a snippet with
- A tomcat-with-httpd package, which should require both the tomcat and the httpd package, install some config to connect them and bring a snippet with
services: httpd: needs_services: [tomcat]
- A my-webapp package with the actual webapp. This package only needs to require tomcat-with-httpd and will probably bring some additional config for httpd and/or tomcat. It can also modify the existing service definition, e.g. to declare which is the front service:
services: httpd: is_frontservice: true
The merged result would look like this:
services: httpd: is_frontservice: true needs_services: [tomcat] tomcat:
- Alternatively, the tomcat service might be located on a different machine. In this case, you can use the following syntax to specify a remote service:
services: httpd: is_frontservice: true needs_services: ["service://webserver/tomcat"]