This new version adds commands and options that will help new and experienced users get the most out of Engine Yard deployment. A new initialization command will document your ey.yml file, so you can be more confident with our defaults and your options. Support for new ey.yml options will customize your deployments. An enhanced server listing command provides you with the scripting power you need to access your servers how you want.
These improvements are available to CLI users and web users that upgrade through the CLI or enable the feature on the web.
It's standard practice to explain how to install gems, so here you go:
gem install engineyard
# or
sudo gem install engineyard # if needed
This should work on most systems. You may need to put "sudo" in front of the command if your gems are owned by your system.
First, make sure you upgrade your engineyard gem as described above. If you never use the CLI, you can skip this.
The web deploy form will use the same deploy system version as the most recent successful deploy. Running an engineyard gem CLI deploy with the newest version will make that environment use that same version in the web deploy form.
Upgrading without running a deploy from the CLI requires you to enable the version in our Early Access features system. From the web interface, find the Tools dropdown menu at the top of the page. Select Early Access and then find the Serverside Deploy Version 2.3 option and enable it.
The new ey init command is used to initialize your repository for deployment to Engine Yard. Running ey init writes a file called ey.yml into your config/ directory (or if you don't have one, the root of your repository). This file gets added to your repository and is loaded during on your servers during deploy.
If you already have an ey.yml file, ey init will update your existing file, while also backing up the old file to ey.yml.backup. The init command will read the existing ey.yml file and write the options you've specified into the newly generated ey.yml file. The advantage is that your existing ey.yml file will be marked up with a bunch of helpful comments that explain each option in detail.
The ey.yml configuration file provides many options for customizing the deploy action. But, just because you have a bunch of options available, that doesn't mean you should turn them all on. I appreciate that you want to try every line of code in the deploy system, but you probably won't need most of these options at first. Some of them are provided to give you a way to avoid running some optimization we've made. Others allow applications with unuasual behavior to function properly.
If you set any of the following options to false, that dependency manager will be skipped even if it normally would have been detected and run. This is useful for applications that use package.json for development time stuff, but not for production.
bundler: # true or false, default is "detect"
composer: # true or false, default is "detect"
npm: # true or false, default is "detect"
If you set them to true, the usual detection command won't be run. There's not a huge advantage to this, but it seemed like the right thing to do.
This option also lays the ground work for disabling bundler on a per deploy basis to shorten deploy time. I hope to get this feature rolled out for real in the future, but I know there are smart and eager developers out there that will figure out how to make use of this ability today.
Other customer have requested increased control when connecting to instances. We've found over the years that it can be quite difficult to provide exactly the sort of ssh interface that everyone can use. We've tried spawning terminal sessions, running in tmux or screen, and using many different tools. At this point we've decided to better enable you to use whatever tools you like.
The standard output of ey servers will give you a nicely formatted server list that you can use for your own reference. If you use the -s or -S options, you'll get output that is easier for a script to pull apart. The -Su option is particularly useful for bash scripts.
$ ey servers -e env -Su
deploy@host1.com
deploy@host2.com
deploy@host3.com
$ for s in `ey servers -e env -Su`; do ssh $s; done
Let us know if you've found a particularly useful way to use this command.
Last, the new EXPERIMENTAL restart_groups option.
Please be cautious if you use this. If you intend to use it in production, try it at a low traffic time during a planned maintenance window. You may need to adapt your development style to support some of the side effects of running two versions of your application at the same time.
restart_groups: # default is 1. 2 or more will trigger th behavior.
We've received customer requests for the ability to do rolling deploys. This option breaks all your application servers into a number of "restart groups". Each of these groups will restart in parallel, but the first group is allowed to finish restarting before the next group begins. This can help app servers that usually can't restart without maintenance pages or downtime. The application can stay up and serving traffic while the other servers restart. This may also help high load applications deal with response time spikes during server restarts.
Important caveats (why I'm calling this option experimental)
- Two different version of your application will be serving traffic at the same time, possibly even alternating between servers running old and new code.
- Deploys will take longer, and could potentially fail with half of the servers running new code and the other half running old.
- Deploy hooks, migrations, and actions that don't expect old code to be hitting them could fail intermittently.
- It's very new. There may be things that I haven't thought of here that could break your application.
That said, I think this is a very cool option that will greatly benefit the right applications. I'd love to hear about your successes or failures with this new option. Just be safe out there.