Defined Standards & Best Practices for Packs
Opened this issue · 3 comments
Hello!
While creating a couple of packs to submit to the registry I immediately noticed some areas where there were multiple ways a scenario could be handled. A few scenarios that came up:
- Application configuration files handling
- Setting up Vault configurations.
- Configuring task mounts.
For the packs I ended up creating, I ultimately decided to go with the "Provide a sane default while allowing the user to customize/override this" approach which I realized quickly could be implemented in many different ways.
Common scenarios like template blocks for configuration files, vault blocks for secrets, and custom mount configurations needed for users specific environments will pop up in nearly all packs and it would make life for both end-users and pack creators much simpler if there were some well defined guidelines for how these common scenarios should be implemented.
For example, handling vault configurations. Per the Nomad Job Specification, this block can be defined from Job level scope all the way down to individual Task level scopes. If a pack provides task(s) that allow for passing in configuration options, I think it makes sense for that package to facilitate enabling vault access as needed in the job spec so that users can securely provide those options if they choose to.
In order to provide a consistent experience across the official packs in the community, there should exist a standard way for "enabling" vault usage in a pack. This would include providing a set of standard variables declarations as well as boilerplate template (or possibly creating a predefined builtin function/template with sprig) code that should be added to the job template.
IMHO, defining, implementing and documenting these sorts of standards early on will greatly reduce the learning curve by providing concrete ways to handle some of the most common implementation details.
Just wanted to throw the idea out there and see if this was something that had been considered or is worth having a discussion about.
Thanks!
Absolutely agree that something like this would be great.
This is something that we've been discussing internally. Some of the best practices might come through in documentation, some might be added with an init command that creates helper templates for you, some might take the form of shared templates from dependent packs, and some things might be templates built into the tool itself. We're still figuring out the details. If any of those sound particularly better/worse than the other, let us know. :)
There should be some more movement on this soon.
Hi, my two cents!
I agree with everything you've both said. I would add a vars.nomad example file (a file with the variables that could be used within the pack) as almost "mandatory" in every pack. It could be created by the init command. I put it in Jenkins and InfluxDB PRs, I think that those are quite useful and they can also provide some explanation on how the app itself works.
It should be considered volume management also, and in particular when we have multiple volumes to mount. Some questions that come into my mind could be: which is the naming convention? How the preparation of the volume should be used? These things could be defined at least at docs level.
@mikenomitch another area we should probably document is licensing and source availability requirements for this registry. We've got an open PR (#55) where the application doesn't have a known source or license. (I'll probably have to close that PR if we don't get a reply back on that subject in the next little while.)