53fd1d27b1
Subcommands * merge 'resolve-profiles' and 'make-amis' into 'amis' * rename 'update-releases' to 'release-yaml' * rename 'gen-release-readme' to 'release-readme' * rename 'prune-amis' to 'prune' * reorder to match the usual workflow * use argparse mutually-exclusive group where appropriate * use argparse 'metavar' and 'nargs' for more salient help release * can now specify multiple AMIs on command line * add explicit '--private' argument * if no '--private', '--public', or '--allow-account' is specified, default to propagate the source AMI's permissions to its copies * move 'iter_regions' and 'get*image' methods out of ReleaseAMIs class because they're also used elsewhere * 'update_image_permissions' resets perms before adding new perms * pending_copy loop, reports on everything in progress, waits 3m before reporting on everything again, and then waits 30s between reports * pending_copy also notes when a copy has completed (and only queues for pending_perms if they need adjustment) Releases class * used by release-yaml and prune subcommands * caches region client objects for later use (by prune) * loads images from region - either from a profile or "unknown" (no profile tag) * builds the releases object - now structured release -> build (instead of build -> release) ReleasesReadme * works with new releases object format * improve sorting and selection of latest per version per-build AMIs * empty cell if a region doesn't happen to have a build AMI there PruneAMIs * rename 'version' level to 'end-of-life' * add 'UNKNOWN' pruning level * works, even if you don't want to --use-broker * --keep N - keeps an additional N AMIs that would otherwise have been purged per build * --defer-eol DAYS - give EOL AMIs a grace period past their official EOL date * no AMI deletion happens unless --no-pretend arg is provided * improve pruning criteria scan and candidate selection Co-authored-by: Jake Buchholz <jake@jakesys.net> |
||
|---|---|---|
| profiles | ||
| releases | ||
| scripts | ||
| .gitignore | ||
| LICENSE.txt | ||
| README.md | ||
| README_BROKER.md | ||
| packer.conf | ||
README.md
Alpine Linux EC2 AMI Builder
NOTE: This is not an official AWS or Alpine project. This is community built and supported.
Pre-Built AMIs
To get started with one of our pre-built minimalist AMIs, please refer to the README in the releases subdirectory.
Alternately, with the right filters, you can query the EC2 API to programmatically
find our most recent AMIs. For example, using the aws command line tool...
aws ec2 describe-images \
--output text \
--filters \
Name=owner-id,Values=538276064493 \
Name=name,Values='alpine-ami-*' \
Name=state,Values=available \
Name=tag:profile_build,Values=v3_10-x86_64 \
--query 'max_by(Images[], &CreationDate).ImageId'
...will list the latest AMI id from our collection of 'v3_10-x86_64' builds. Refer to the AWS CLI Command Reference for describe-images for more details.
Custom AMIs
Using the scripts and configuration in this project, you can build your own custom Alpine Linux AMIs. If you experience any problems building custom AMIs, please open an issue and include as much detailed information as possible.
Build Requirements
- Packer >= 1.4.1
- Python 3.x (3.7 is known to work)
- an AWS account with an existing subnet in an AWS Virtual Private Cloud
Profile Configuration
Target profile config files reside in the profiles subdirectory, where you will also find the config we use for our pre-built AMIs. Refer to the README in that subdirectory for more details and information about how AMI profile configs work.
AWS Credentials
These scripts use the boto3 library to interact with AWS, enabling you to
provide your AWS account credentials in a number of different ways. see the
offical boto3 documentation's section on
configuring credentials
for more details. Please note that these scripts do not implement the first
two methods on the list.
Building AMIs
To build all build targets in a target profile, simply...
./scripts/builder.py amis <profile>
You can also build specfic build targets within a profile:
./scripts/builder.py amis <profile> <build1> <build2> ...
Before each build, new Alpine Linux releases are detected and the version's core profile is updated.
If there's already an AMI with the same name as the profile build's, that build will be skipped and the process moves on to build the other profile's build targets (if any).
After each successful build, releases/<profile>.yaml is updated with the
build's details, including (most importantly) the ids of the AMI artifacts that
were built.
Additional information about using your custom AMIs can be found in the README in the releases subdirectory.
Pruning AMIs
Every now and then, you may want to clean up old AMIs from your EC2 account and
your profile's releases/<profile>.yaml. There are three different levels of
pruning:
revision- keep only the latest revision for each releaserelease- keep only the latest release for each versionversion- remove any end-of-life versions
To prune a profile (or optionally one build target of a profile)...
./scripts/builder.py prune-amis <profile> [<build>]
Any AMIs in the account which are "unknown" (to the profile/build target, at least) will be called out as such, but will not be pruned.
Updating the Release README
This make target updates the releases README, primarily for updating the list of our pre-built AMIs. This may-or-may-not be useful for other target profiles.
./scripts/builder.py gen-release-readme <profile>
Cleaning up the Build Environment
The build process is careful to place all temporary files in the build
subdirectory. Remove the temporary build subdirectory, which contains the
resolved profile and Packer configs, the Python virtual environment, and other
temporary build-related artifacts.
Caveats
- New Alpine Linux versions are currently not auto-detected and added as a core version profile; this process is, at the moment, still a manual task.