ci: include additional AMI build resources #668
Conversation
|
The |
| - Sid: "keypairDecrypt" | ||
| Effect: Allow | ||
| Action: | ||
| - kms:Decrypt | ||
| Resource: !Sub "arn:${AWS::Partition}:kms:${AWS::Region}:${AWS::AccountId}:alias/aws/ssm" |
There was a problem hiding this comment.
Was this policy invoked during testing? kms:Decrypt did not work for me when I tried using aliases.
There was a problem hiding this comment.
Yes! This was used by both ensure-key-pair and create-image-ami scripts when managing the /infra/ami-build/instance/key-pair parameter (which is a SecureString).
tools/infra/stacks/hack/deploy-stack
Outdated
| @@ -0,0 +1,193 @@ | |||
| #!/usr/bin/env bash | |||
| ## | |||
| ## deploy-stack - Simplified 'cfn deploy' interface prioritizing iterative use | |||
There was a problem hiding this comment.
Awesome! Thanks for making this.
There was a problem hiding this comment.
Heh, you're welcome to use it! I've been cherry picking it where I've wanted to use it though I don't intend to commit this to the repository at this time. This lives on a pushed branch and probably could stand to be put in a Draft PR - if for nothing more than a symbol for discussion about larger stack orchestration and coordination.
| variables: | ||
| BUILD_IMAGE_ROOT: thar-x86_64-aws-k8s.img.lz4 | ||
| BUILD_IMAGE_DATA: thar-x86_64-aws-k8s-data.img.lz4 |
There was a problem hiding this comment.
Would it be better if we define these environment variables for the CodeBuild project instead of here in the buildspec?
There was a problem hiding this comment.
There was no rhyme or reason to these being place here this way, this is crumbs from me working through the last bit of duct taping needed to wire up the step. I've since moved these all into the Build Project definition. Read on for my thoughts here.
I think that we should use the Build Project to hold the variables as its near but not the lowest priority location referenced for environment variables at build time. This leaves some room for migrating project configuration by shifting variables higher up (to maintain an override) or lower (to help smooth over transitions of variables or their values). I'm basing this opinion entirely on the docs, which suggest that this is how the variables are sourced and given priority:
If an environment variable with the same name is defined in multiple places, the value is determined as follows:
The value in the start build operation call takes highest precedence. You can add or override environment variables when you create a build. For more information, see Run a Build in CodeBuild.
The value in the build project definition takes next precedence. You can add environment variables at the project level when you create or edit a project. For more information, see Create a Build Project in CodeBuild and Change a Build Project's Settings in CodeBuild .
The value in the build spec declaration takes lowest precedence.
from the build spec reference documentation
This would mean that for Pipeline driven builds, we have the follow ordering (highest preference first):
- Pipeline Action-Specified Environment Variables
- Backing-CodeBuild-Project Environment Variables
- Backing-CodeBuild-Project's Buildspec Environment Variables (in
buildspec.ymlor inlined)
So if that's the order, then I would say, yes - I think we should be using the Build Project to define our SOP-mode variables and use the other slots as needed in operations.
jahkeup
force-pushed
the
ami-build-support
branch
from
f740a46
to
8ea19a8
Compare
| TimeoutInMinutes: 30 | ||
| Source: | ||
| Type: CODEPIPELINE | ||
| BuildSpec: !Sub | |
There was a problem hiding this comment.
Hey, this isn't supposed to be here, will remove.
amiize.sh is required by `create-image-ami` for turning images in on-disk raw filesystem image form into AMIs. Embedding amiize.sh allows the stage to be decoupled from the input top level sources at runtime, depending only on the builder environment to run against a set of disk images as inputs. Signed-off-by: Jacob Vallejo <[email protected]>
jahkeup
force-pushed
the
ami-build-support
branch
from
8ea19a8
to
2ae0bde
Compare
jahkeup
force-pushed
the
ami-build-support
branch
from
2ae0bde
to
be9e275
Compare
Issue #, if available:
#624
Description of changes:
This adds
amiize.shto the container image for use in the builder environment (in the pipeline's build projects). The build depends on the availability of the permissions as set in the cloudformation template which limits the process to, roughly speaking, "create only" actions.By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.