From 7640de339b86ab436ed7da8f69565f0966536b49 Mon Sep 17 00:00:00 2001 From: Thanos Baskous Date: Mon, 18 Jul 2016 22:23:54 -0700 Subject: [PATCH 1/2] Amazon Linux package versioning notes Resolves #6. --- README.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/README.md b/README.md index 035609b..5f849bc 100644 --- a/README.md +++ b/README.md @@ -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](http://techblog.netflix.com/2013/03/ami-creation-with-aminator.html). * Use tools like [Packer](https://packer.io/) to simplify and automate AMI creation. +* By [default](https://aws.amazon.com/amazon-linux-ami/faqs/#lock), 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"](https://aws.amazon.com/amazon-linux-ami/faqs/#lock) 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 From 8b42f0bf05c592dd4ca967ed702e96cba1b6bfbb Mon Sep 17 00:00:00 2001 From: Thanos Baskous Date: Tue, 19 Jul 2016 20:01:51 -0700 Subject: [PATCH 2/2] Combined Amazon Linux bullets, fixed punctuation. --- README.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/README.md b/README.md index 5f849bc..634fd40 100644 --- a/README.md +++ b/README.md @@ -615,8 +615,7 @@ 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](http://techblog.netflix.com/2013/03/ami-creation-with-aminator.html). * Use tools like [Packer](https://packer.io/) to simplify and automate AMI creation. -* By [default](https://aws.amazon.com/amazon-linux-ami/faqs/#lock), 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"](https://aws.amazon.com/amazon-linux-ami/faqs/#lock) 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. +* By [default](https://aws.amazon.com/amazon-linux-ami/faqs/#lock), 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.