4 ms·
Slightly related, in everything I see that allows adding secrets or env vars as code, they seem to prefer a list of objects instead of a key value pair for thes
by figmert 2y ago
Slightly related, in everything I see that allows adding secrets or env vars as code, they seem to prefer a list of objects instead of a key value pair for these. Does anyone know why this is? I know in some cases you can add additional values, but this seems easily solved by dynamically determining what the value is.
I'd much rather write:
env:
key: value
instead of
env:
- name: key
value: value
- xena 2y agoThe reason they do that is because then you can do things like extract envvar values from secrets.
- mdaniel 2y agoPedantically, there's nothing stopping them from doing it the way CFN does it: dispatching on the value's type: env: AWS_REGION: us-east-1 AWS_SECRET_ACCESS_KEY: valueFrom: ... CFN even goes as far as having two ways to pull off that stunt, magic prefixes and objects Properties: ImageId: !Ref MyAwesomeAmi # or ImageId: Ref: MyAwesomeAmi # or cursed "{{resolve" syntax ImageId: !Join - '' - - '{{resolve:ssm:/aws/service/bottlerocket/aws-k8s-' - Ref: EksVersion - '/x86_64/latest/image_id}}' # which ends up being "ImageId: '{{resolve:ssm:/aws/service/bottlerocket/aws-k8s-1.31/x86_64/latest/image_id}}'" and then *that* gets replaced by the CFN service at provisioning time
- deleted 2y ago[deleted]