Created
March 2, 2021 17:37
-
-
Save purpleidea/735b2ba0f274f270d7ba3670f762c12a to your computer and use it in GitHub Desktop.
automatic grouping example
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# this doesn't work of course... | |
docker:container "mgmt-nginx" { | |
volumes => { | |
"/steve" => struct{type => "volume", source => "steve",}, | |
"/tmp" => struct{type => "tmpfs",}, | |
}, | |
} | |
# but these three *could* work! | |
docker:container "mgmt-nginx" { | |
... whatever | |
} | |
docker:container:volume "mgmt-nginx:/steve" { | |
blah => struct{type => "volume", source => "steve",}, # if we did partial struct for the resource | |
# or just flatten here and it works right now... | |
type => "volume", | |
source => "steve", | |
} | |
docker:container:volume "mgmt-nginx:/tmp" { | |
blah => struct{type => "tmpfs",}, | |
type => "tmpfs", | |
} | |
# of course if we have a parameter in the above :volume resource that needed | |
# flattening again, then we could have docker:container:volume:propertyX too! | |
# and lastly, the title could be done differently as well, for example, you could also do: | |
docker:container "mgmt-nginx" { | |
... | |
} | |
docker:container:volume "whatever1" { | |
path => "/steve" | |
type => "volume", | |
source => "steve", | |
container => "mgmt-nginx", | |
} | |
docker:container:volume "whatever2" { | |
path => "/tmp" | |
type => "tmpfs", | |
container => "mgmt-nginx", | |
} | |
Why is all of this possible? Automatic grouping. I already have a large unmerged working example of this | |
methodology to build resources. You get the datastructure you want out of it. |
Totally. My example was completely contrived and meant to show you that it's possible and inspire you. The actual breakdown and how you build the resources is entirely up to you. You specify your own grouping rules so you can do it however you like.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We should be careful in this specific case to not conflate
volume
andmount
. Technically they are two discrete entities. The volume being the backing storage (some directory, a tmpfs mount, a docker volume) and the mount being where and how the volume is being mounted with additional properties like read-only and similar.I do think that the last set of resources makes more sense though, it's particularly favourable over the previous approaches