ADMIN
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Virtualization<br />
Package Your Scripts<br />
deb, so you can install, run arbitrary<br />
tests, and repeatedly verify that your<br />
cloud scripts are stable before they<br />
hit the live environment. And you<br />
should!<br />
When everything is stable, upload to<br />
S3, which you might want to script<br />
as well:<br />
Figure 1: Creating a new script.<br />
scripts via a web interface (Figure 2).<br />
If you have a team working on your<br />
cloud hosting, you can even start using<br />
standard code management, such<br />
as Git or SVN, to version your cloud<br />
environment’s bootup and configuration<br />
scripts.<br />
A second event script, which is called<br />
each time the IP address changes,<br />
would typically update Dynamic DNS<br />
with a one-liner (you’ll need to set up<br />
your Dynamic DNS account first):<br />
curl 'http://www.dnsmadeeasy.com/ U<br />
servlet/updateip?username= U<br />
myuser&password=mypassword&id= U<br />
99999999&ip=123.231.123.231'<br />
Once you’ve placed this code in the<br />
script on‐ip‐address‐changed.sh, simply<br />
package it up into your .deb file,<br />
upload it to S3 again, and start a new<br />
instance. With this approach, testing<br />
small changes takes a little longer, but<br />
because the scripts are all in a .deb,<br />
Figure 2: Adding a script.<br />
you can test them more easily outside<br />
the cloud.<br />
The Package in Production<br />
Everything thus far might feel a bit<br />
heavy-handed. I put a lot of effort<br />
into getting a short script up onto a<br />
cloud instance. But suppose you have<br />
a running server farm, and you need<br />
to update some scripts across the<br />
farm.<br />
Several cloud services let you edit<br />
scripts via a web interface, which is<br />
fine up to a point, but beyond a few<br />
lines, you will start pining for Emacs<br />
or your favorite editor. A custom .deb<br />
package makes it easy to create and<br />
test the script on local machines or a<br />
development cloud before uploading<br />
the final version to the production<br />
environment.<br />
Installing the script on instances is<br />
simply a matter of deb ‐i myserver.<br />
s3cmd put myserver.deb U<br />
s3://mybucket/myserver.deb<br />
Then, all you need is a corresponding<br />
script to run on your instances. Create<br />
a new script in Scalr or RightScale<br />
that downloads and installs the latest<br />
version:<br />
wget ‐O myserver.deb U<br />
http://mybucket.s3.amazonaws.com/ U<br />
myserver.deb<br />
deb ‐i myserver.deb<br />
The ability to test server configuration<br />
in the cloud, for the cloud, is really<br />
important.<br />
If you’ve been running nice chunky<br />
servers for years, you wouldn’t make<br />
changes to them unless you were 100<br />
percent sure, but with cloud computing,<br />
you can prototype your configurations<br />
and settle your nerves before<br />
putting things live.<br />
When your cloud is running, you will<br />
want every opportunity to test the<br />
scripts, so being able to install, run,<br />
and test them on any instances is<br />
valuable.<br />
After Installation: Uninstall<br />
So far, Debian packages might just<br />
look like glorified tarballs, so why<br />
not just tar up your scripts? Well …<br />
they’re better than that. Two hooks<br />
are provided: post-install and preuninstall.<br />
Once your Debian package’s<br />
files have been copied to the<br />
filesystem, the post-install script,<br />
./DEBIAN/postinst, is run, and when<br />
you uninstall, Debian removes your<br />
files before running ./DEBIAN/prerm.<br />
With these scripts, you can install<br />
software, start services, and call a<br />
monitoring system to tell it exactly<br />
what’s going on with the new instance.<br />
For example, open ./DEBIAN/postinst<br />
and add something like:<br />
50 Admin 01 www.admin-magazine.com
Change language