-
Notifications
You must be signed in to change notification settings - Fork 524
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pubsys: add SSM parameter publishing #1060
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,30 @@ | ||
# Parameter templates | ||
|
||
Files in this directory contain template strings that are used to generate SSM parameter names and values. | ||
You can pass a different directory to `pubsys` to use a different set of parameters. | ||
|
||
The directory is expected to contain a file named `defaults.toml` with a table entry per parameter, like this: | ||
|
||
``` | ||
[[parameter]] | ||
name = "{variant}/{arch}/{image_version}/image_id" | ||
value = "{image_id}" | ||
``` | ||
|
||
The `name` and `value` can contain template variables that will be replaced with information from the current build and from the AMI registered from that build. | ||
|
||
The available variables include: | ||
* `variant`, for example "aws-k8s-1.17" | ||
* `arch`, for example "x86_64" | ||
* `image_id`, for example "ami-0123456789abcdef0" | ||
* `image_name`, for example "bottlerocket-aws-k8s-1.17-x86_64-v0.5.0-e0ddf1b" | ||
* `image_version`, for example "0.5.0-e0ddf1b" | ||
* `region`, for example "us-west-2" | ||
|
||
# Overrides | ||
|
||
You can also add or override parameters that are specific to `variant` or `arch`. | ||
To do so, create a directory named "variant" or "arch" inside parameters directory, and create a file named after the specific variant or arch for which you want overrides. | ||
|
||
For example, to add extra parameters just for the "aarch64" architecture, create `arch/aarch64.toml`. | ||
Inside you can put the same types of `[[parameter]]` declarations that you see in `defaults.toml`, but they'll only be applied for `aarch64` builds. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,7 @@ | ||
[[parameter]] | ||
name = "{variant}/{arch}/{image_version}/image_id" | ||
value = "{image_id}" | ||
|
||
[[parameter]] | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Don't we have one of these for There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For |
||
name = "{variant}/{arch}/{image_version}/image_version" | ||
value = "{image_version}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The path to the ssm policy is not specified in Infra.toml?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, though we could consider moving it, and there's also some separate discussion about combining some of our configuration sources...
The way we were thinking about the configuration sources is that the Makefile would have default values/paths for things that should work for most people and rarely need to change; Infra.toml would have user-specific settings that rarely need to change; parameters handle things that always need to be specified or frequently change; and JSON files as a "runtime store" for things that change each time, like the AMI IDs.