The document provides an overview of how to build a fully automated server deployment system using open source tools such as Request Tracker, Nictool/djbdns, dhcpd, PXEboot, Httpd, a yum repository, and Puppet. Key aspects include using an asset tracker (Request Tracker) to store server information and trigger automated builds. A PXE boot script generates configuration files using data from the asset tracker. A CGI script generates customized Kickstart files which install servers. Puppet then configures and deploys applications to servers based on their roles defined in the asset tracker. The goal is to achieve repeatable, consistent server builds from bare metal to a live application server within an hour with no
Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...
Build fully automated deployment system using open source tools
1. How to build a fully automated (or nearly so) deployment system using open source tools. Russell Miller SCALE 8x 2010 (16,080, in case you were wondering) [email_address]
2.
3. The methods discussed in this talk will use only open source tools. You don't have to pay for anything I mention here unless you want to. In which case...
7. Maintained deployment system for 4,000 server environment for leading Internet Shopping Comparison company in West Los Angeles.
8. Instrumental in bringing up two datacenters of about 300 servers each from scratch for leading Internet Advertising company in Irvine, including building the entire deployment system from metal to application.
9. The second datacenter, once all the physical hardware was there, took live traffic in less than two weeks from bare metal.
16. Deploying servers manually usually mean many cycles of going back and forth with the application owners to validate. For each server. This eats up time and means bringing up servers can take up to or more than two weeks...
33. (This means that even if someone installs something you don't want them to, you can simply have it removed within 10 minutes with no manual intervention.)
43. And... puppet (cfengine or another configuration management tool will probably work, but I prefer puppet.)
44.
45. Make sure the DNS info is properly entered into your DNS server in whatever way.
46. Tell your DHCP server you want to allow the server to PXE boot. This can happen manually or automatically.
47. I prefer manually simply because if you set the server up to boot automatically – you can get into a situation where the server accidentally reboots and rebuilds itself. This tends to make app owners unhappy.
48. And.... let it install. An hour later you have a full build with no further manual intervention.
53. For example, at a minimum you'll want to put the MAC Address into the RT system. You may even want to populate DNS from an IP field. Every step of this process uses the info from RT.
54. There may be site-specific stuff you need to use. Don't be afraid to add or use it. This is only a framework.
55.
56.
57. The kickstart file is not a file at all. It is a CGI script. It goes to RT and DNS and gathers all of the information required, makes decisions on how to build the servers, and then custom generates a kickstart file.
58. It should at minimum take one argument – the RT asset ID. This is a unique identifier and allows all the information to be pulled out of the asset tracker to be used in the script.
65. The reason for this is: control. If you use external repositories, you are putting control of releases and upgrades into their hands, not yours.
66. And while Centos, Fedora, etc., are fairly good about it, they make mistakes – and you do not want your production site to go down because of someone else's mistake. It's still your fault for not taking my advice. :)
108. You could have AT automatically populate DNS using the SOAP client for nictool...
109. It's not out of the realm of possibility that you could set up a server from bare metal all the way to application deployment simply by setting the fields correctly in AT and then setting a special field using this infrastructure.