ey-deploy
We’ve been listening to your feedback here on the Engine Yard Cloud and we’ve heard that the current web deploy is not optimal. People like to see the deploy steps as they happen. not wait until the end to go through the logs to see what went wrong. It is also clear that running the full set of chef recipes every time you deploy is doing a lot of redundant work and taking a lot of time each deploy. So I say down and came up with a new deployment strategy that meets these needs and makes deploying to our cloud a much nicer experience. So today I am releasing a beta of our new git deployment strategy for you to use. This new system is 100% backwards and forwards compatible with the current web deploy. If you have a server already deployed you can start using this new system right on top of it with a few minutes of setup.
So here is the steps needed to get a new git push based deploy up and running on your cloud system. Let’s assume that you have an environment called ‘production’ with an ip address of 123.123.123.123 and a unix user called ‘deploy’ with an application attached called ‘railsapp’. In the instructions below please replace these items with the correct info for your own setup.
Once you have a server fully up and running, follow these steps:
-
SSH into each of the servers in your cluster, or just the single server if you have only one and run the following commands:
$ sudo gem install ey-deploy --source http://gems.engineyard.com
Successfully installed ey-deploy-0.0.7
1 gem installed
$ sudo ey-deploy-install
engineyard git hooks installed
Now back on your local machine,
cd railsapp
git remote add production [email protected]:/data/railsapp/shared/cached-copy
# NOTE make sure to replace ‘deploy’ with the username you created for this env # NOTE also make sure to change the ip address to the address of your app master # NOTE also make sure to replace ‘railsapp’ in the path with the name of your own application
If you have only one server then you can go ahead and deploy new code like this:
$ git commit -m "made some changes"
$ git push production master
If you have a cluster of servers you need to setup an ssh keypair named ‘internal’ for them to use to talk to each other.
$ cd ~/.ssh
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/ez/.ssh/id_rsa): internal
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/ez/.ssh/internal.
Your public key has been saved in /Users/ez/.ssh/foo.pub.
The key fingerprint is:
79:40:8a:18:84:ff:96:39:c7:3a:3d:f2:e9:20:a1:ea [email protected]
The key's randomart image is:
+--[ RSA 2048]----+
| oo . |
|. o . o |
| .. . . . |
| . o |
| .. + S . |
| . .* o . |
|. ...= |
|. .+.o. |
|oE =+. |
+-----------------+
Now you need to put the ssh keys in place on your servers. Run the following command once for each server in your cluster.
$ cd ~/.ssh
# do this for each server in your cluster
$ cat internal.pub | ssh deploy@server "cat >> ~/.ssh/authorized_keys && chmod 0600 ~/.ssh/authorized_keys"
$ cat internal | ssh deploy@server "cat > ~/.ssh/internal && chmod 0600 ~/.ssh/internal"
Once you have those keys in place you can start deploying to your cluster via git push. A few things to keep in mind with this new strategy. Your cluster does not run a git server, so you will still keep the canonical git repo on github or on your own git server somewhere. You can push any branch you want but you will always push to master on the far end as that is the branch that will get deployed on the server. But pushing another branch form your local repo to the remote master will work fine.
Thats it! you are now deploying with git directly to your instances. Please give this a try and give me some feedback! I’m hoping to hear from you if you use this new deploy strategy. You can reach me by responding to this post or email me at [email protected].