I'm working on creating a suite of self-training exercises and guides (perhaps eventually a collection of videos or Slideshare presentations) covering a range of systems administration and "ops" related topics.
My plan is to prototype and present them primarily assuming that the students will create AWS accounts and work through the examples using EC2 instances and a limited set of related resources. I'll recommend that students create one base instance using some less expensive VPS provider, such as Linode, as their "home base" for most of their work, then spin up instances (mostly t1.micro, where that's possible) during each exercise, and shut them down after each work session. (The goal is to make these feasible for students financing their own professional education ... so I'll be expending extra effort into practices and exercise session designs which minimize service costs).
The plan will mostly be using free AWS Marketplace AMIs for CentOS, Debian, Ubuntu, and FreeBSD as needed. (I'll also explore alternative clouds eventually, unless Amazon Inc. comes along to sponsor my project) --- though I might create some custom AMIs based on those and post them to the Marketplace as part of my offerings.
Early lessons will emphasize the use of Python Boto (it's what I'm comfortable with so far) and some tools I'm building will help manage this infrastructure that each student creates ... and I'll be having the students use Ansible throughout most of the exercises (for session set-up and tear down of collections of instances). One suite of lessons will be on Puppet, another will cover Chef. Most of the later lessons (Hadoop, Cassandra, MongoDB, Zookeeper) will (require/assume?) that the student is building out their clusters using one of these.
This, finally, brings me to my question. (Apologies for the rambling preamble, but it feels necessary to set the context).
Last night I set up the simplest Puppet (version 3) configuration that couple possibly be useful for a student of systems administration. A pair of CentOS 6.4 instances, one as the puppetmaster, the other as a client. I wired them together using the ugly ec*.internal names (in the hosts files and configs). Then made changes (creating user, group, and ssh key entries in my site.pp manifest) and confirmed that they were working (running the puppet agent --test command on the client). Naturally the biggest obstacles were: make changes to the security group configuration, disable the default CentOS IPTables configuration, disable the SELinux enforcement mode, and fiddle with the
dns_alt_names = directive in the puppetmaster's /etc/puppet/puppet.conf. (Later I'll figure out how to properly grant the necessary SELinux permissions to the Ruby/Apache/Passenger components to re-enable SELinux).
Tonight, as I was about to pick up where I left off, it dawned on me (rather belatedly) that I really need stable IP and reverse DNS for this model. Having to reconfigure the puppet master and regenerates its PEM certificates, and those for all clients, at he beginning of each work session would be more tedious than educational (and scripting all that would have very little applicability to any normal future work environment.
So, duh, need to either allocate an Elastic IP (at least one) and request a reverse DNS entry for it ... or I need to re-work my assumption and base these exercises on a pre-requisite set of VPC set-up lessons.
For now I've just setup the EIP and entered a request for the PTR over-ride (which, by the way, seems to be conflate in Amazon's workflow with some STMP enablement request form).
I'm looking for suggestions on whether I should do this around VPC (and predicate the lessons on setting up a DNS server within that virtual network, perhaps hosted on the puppetmaster itself, at least initially) or whether I should build the lessons around using one or two generically named Elastic IPs (and possibly later segue into migrating the puppetmaster services behind HAProxy or some similar front end, as a different exercise).