https://www.puppet.com/community logo
Join Slack
Powered by
This message was deleted.
# bolt
s
This message was deleted.
y
this one is based on my homelab setup mostly.. though now it’s opposite - my homelab setup is based on this repo 🙂
though this repo has just one plan which is mostly just 
apply()
wrapper. When you need more plans with some differences it might be better to use target vars and classify based on those vars
then you can use plan hierarchy as well to cover the differences
v
Thanks. Here is mostly the base skeleton, which is useful anyway, but I am more interested in the best practising of organising per target manifests, to have clear declaration how each target is setupped.
y
I’m using the same as in “big” puppet - roles and profiles
plans are new enough so not sure if there are any best practices yet..
v
I thought to make manifest for each target, named as target, and just apply in 1 plan
y
is there anything more than 
apply()
inside?
v
Name of target
To match target name and manifest name
y
v
Copy code
manifests
  target_1.pp
  target_2.pp
plans
  apply_all.pp
y
but again this only works in 
apply()
blocks
there is another Bolt-specific way (which will made unit testing harder) - use target vars in the inventory
e.g. add a 
role
target variable and set it to the role you’d like to bind to the target
v
Ah
y
then 
include
based on this global var
v
I want everything super clear and straightforward
y
target vars are global vars in the 
apply()
block
like ENC vars
v
Anyway looks like 1 manifest per target is okey?
y
another way is to create an classifying plan and include it before apply() so it’ll return the role for your target
as long as you’re fine with that it’s pretty ok
just write some docs so your teammates can understand how it works 🙂
v
Ye, the biggest issue that manifests should be understandable for developer, not devops
To make changes throw mrs
y
this is another reason I went the hiera classifier way - it works in the same way as in usual puppet.. but it’s a bit more complicated for newbies though 😞 your one plan per target should be easier to understand from this perspective
I’d say Hiera is easier to understand to developers as it’s just YAML
v
I don’t like yaml much, for me it’s hard readable, and puppet language is more easier to understand
y
as long as you have good enough profiles consuming their parameters from the hiera they can change things there w/o looking into the profiles code
v
Hehe, opposite thinking here 😉
y
nono, I’m on your side here
v
I will need Hiera anyway for Sensitive data, like license keys and accounts
Now they are just plane text in manifests
y
but an “average developer in the vacuum” prefers to use YAML from my experience at least 🙂
v
I have Gitlab yamls from those developers in 5k+ lines of code using bash to automate builds
😱 1
That is nightmare
Moving everything to ruby and fastlane
y
I’m working with argocd and helm charts these days.. unfortunately we have no Puppet on my current job.. so it’s my hobby now 🙂
😞 1
my teammates doesn’t see any benefits of jsonnet even.. so plain YAML with go templates is all I have around now 🙂
v
Ahh
y
so enjoy your puppet 😄
v
Thanks, I’m even not devops, but need to automate this nightmare to speedup development processes.
Is hiera-eyaml now the go-to for storing sensitive data?
y
If you have Hashicorp Vault I’d go with it.. otherwise yes, eyaml is good enough
✅ 1
but I’d use Vault as it gives some nice features like PKI also
there is vault_lookup() function in some module.. also there is vault Hiera backend. The function is easier to read (if not Deffered) but I didn’t tried it yet.. I deployed Hiera backend while ago as a POC and it was working at least 🙂
v
Looked at your project in more detail, thanks again. I think the roles and profiles system it’s a bit complicated for me. Generally, all of my nodes have one role - CI/CD machine. But some specific nodes can have different versions of software or a couple of them. One manifest per node gives a glance overview of the machine but adds redundancy and removes uniformity. However, it looks fine for the first iteration.
I’m just having one class per one node
My case for now)
Maybe you know the easiest way to set 
vault_addr
globally, not exporting the ENV variable in the console manually? https://github.com/voxpupuli/puppet-vault_lookup
y
I was exporting the VAULT_ADDR from my .zshrc usually
not sure how to export it within a Bolt plan though.. in Puppet it’s easier as you can export it in a systemd service e.g..
another option is to use some common variable with every lookup which is set to the address of your vault server.. but I don’t really like this
v
Ye
Open in Slack
PreviousNext
Powered by