external/og-aws
1
0
Fork 0
mirror of https://github.com/nickpoida/og-aws.git synced 2025-02-15 03:11:57 +00:00
Code Issues Releases Wiki Activity

address cloud-init directly

Browse source
This commit is contained in:
Brad Campbell 2017-07-25 20:41:37 -04:00
parent a5b397cf58
commit 6aa3f06fe8
1 changed files with 18 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

19
README.md
View file

@ -885,7 +885,24 @@ AMIs
### AMI Gotchas and Limitations ### AMI Gotchas and Limitations
- 🔸**Amazon Linux package versions:** [By default](https://aws.amazon.com/amazon-linux-ami/faqs/#lock), instances based on Amazon Linux AMIs are configured point to the 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. - 🔸**Amazon Linux package versions:** [By default](https://aws.amazon.com/amazon-linux-ami/faqs/#lock), instances based on Amazon Linux AMIs are configured point to the 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.
- **Password-based SSH:** If you are enabling password-based SSH auth by changing `sshd_config` files (e.g. toggling `PasswordAuthentication yes`) and then creating AMIs, review this [AWS forum post](https://forums.aws.amazon.com/message.jspa?messageID=467331) first. The byline here is to make sure that you're also changing relevant cloud-init settings prior to creating the AMI. - **Cloud-Init Defaults:** Oftentimes users create AMIs after performing customizations (albeit manually or via some tool such as Packer or Ansible). If you're not careful to alter cloud-init settings that correspond to the system service (e.g. sshd, etc.) you've customized, you may find that your changes are no longer in effect after booting your new AMI for the first time, as cloud-init has overwritten them. Locations of these files vary by distro, and here's where to find them:
- Amazon Linux 2017.03.1:
- `/etc/cloud/cloud.cfg`
- `/etc/cloud/cloud.cfg.d/`
- `00_defaults.cfg`
- `05_logging.cfg`
- `10_aws_yumvars.cfg`
- RHEL7, SLES12, CentOS6.5
- `/etc/cloud/cloud.cfg`
- `/etc/cloud/cloud.cfg.d/`
- `05_logging.cfg`
- Ubuntu 14.04, Ubuntu 16.04
- `/etc/cloud/cloud.cfg`
- `/etc/cloud/cloud.cfg.d/`
- `05_logging.conf`
- `90_dpkg.conf`
By the names of some of the files, the services they touch are obvious: dpkg, yum, etc. But some settings are more subtle, such as security settings and templatings for `/etc/hosts`.
Auto Scaling Auto Scaling
------------ ------------