This document provides high level processes for a simple environment upgrade from Engine Yard Gentoo 2009 to Engine Yard Gentoo 12.11 (stable-v2 to stable-v4). It supports the recent addition of the latest generation AWS instance types such as AWS M3, AWS C3 and AWS C4.
This is a minimally complicated upgrade, and can be applied to Rails and PHP environments. It does not include instructions for custom Chef. For more complex upgrades, see Upgrade from Engine Yard Gentoo 2009 (stable-v2) to 12.11 (stable-v4) with Custom Chef.
Tip: Use the tools and documentation (which are linked-to in the process steps) to save time.
Get started with Engine Yard Gentoo upgrade
- Upgrade your environment from Engine Yard Gentoo 2009 (stable-v2) to 12.11 (stable-v4)
- More information
- This article assumes you have an existing Engine Yard Gentoo 2009 (stable-v2) environment.
- Your application must be able to use the component versions as described in the Engine Yard Gentoo 12.11 Tech Stack.
- If your app uses database versions less than MySQL 5.5 and PostgreSQL 9.2, you need to upgrade your database as part of the upgrade. Test the database upgrade in your development environment before proceeding with the stack upgrade.
- You must use 64-bit instances (32-bit instances are not supported on the Engine Yard Gentoo 12.11 (stable-v4) distribution).
Upgrade your environment from Engine Yard Gentoo 2009 (stable-v2) to 12.11 (stable-v4)
To upgrade from stable-v2 to stable-v4
- Snapshot your current environment.
- Create a copy of your environment.
- Select the new instance types, stable-v4 stack and MySQL 5.6 database.
- Backup your database by SSHing into your stable-v2 database instance and follow the On-Demand instructions.
- From the stable-v2 environment download your database backup.
- From the stable-v2 database instance transfer the backup to your v4 database instance and restore.
Note: When you're logged into the `deploy` account, you do not need to enter the MySQL password so the command will look like
gunzip < [filename] | mysql [dbname].
- Verify that your application is working as expected.
If you must retain the EIP, swap the IP address from your old to new environment.
By default, the swap IP tool automatically puts both environments into maintenance mode during the swap; it takes them out of maintenance mode after (unless there is an error).
- Perform a sanity test on your new environment with the restored data.
You might have these questions about upgrades.
Do I need to do all this for weekly cookbook / stack upgrades?
No; minor weekly upgrades have the same upgrade process as usual: Click Upgrade on your environment.
What if the database version is not supported in the new stack?
In this case, it is recommended to use a fresh volume when booting the database rather than a snapshot. Another workaround is to uncheck the "lock minor version control" check box in "edit environment".