Browse Source

Amazon Linux package versioning notes

Resolves #6.
Thanos Baskous 4 years ago
1 changed files with 3 additions and 0 deletions
  1. 3

+ 3
- 0 View File

@@ -615,6 +615,9 @@ We cover security basics first, since configuring user accounts is something you
* As systems become larger, it common to have more complex AMI management, such as a multi-stage AMI creation process in which few (ideally one) common base AMIs are infrequently regenerated when components that are common to all deployed services are updated and then a more frequently run “service-level” AMI generation process that includes installation and possibly configuration of application-specific software.
* More thinking on AMI creation strategies [here](
* Use tools like [Packer]( to simplify and automate AMI creation.
* By [default](, instances based on Amazon Linux AMIs are configured point to 'latest' versions of packages in Amazon's package repository. This means that the package versions that get installed are not locked and it is possible for changes, including breaking ones, to appear when applying updates in the future. If you bake your AMIs with updates already applied, this is unlikely to cause problems in running services whose instances are based on those AMIs - breaks will appear at the earlier AMI-baking stage of your build process, and will need to be fixed or worked around before new AMIs can be generated.
* There is a ["lock on launch"]( feature that allows you to configure Amazon Linux instances to target the repository of a particular major version of the Amazon Linux AMI, reducing the likelihood that breaks caused by Amazon-initiated package version changes will occur at package install time but at the cost of not having updated packages get automatically installed by future update runs. Pairing use of the "lock on launch" feature with a process to advance the Amazon Linux AMI at your discretion can give you tighter control over update behaviors and timings.

## EBS