Using with EC2 (and auto-scaling)

[Oliver Beattie]

Hi there,

I am trying to setup a "cluster" on Amazon EC2, using auto-scaling. I currently have it working so that when the instances are started, they generate a CSR, which is automatically signed by the server if it's valid by a cron job I setup to run every minute.

However, where does one go from there? I suppose now the nodes need to be somehow registered on the puppet master so they can receive the correct configuration, but I'm unsure how to do this. I've read several articles which involve essentially creating a script which modifies the manifest, but is there a better way than this?

I'm fairly new to Puppet, so my other question would be how does one classify instances into "roles" or similar — for instance, if I am bringing up a webserver, can I just add it to a "webserver" group and it will be configured as such?

Any pointers would be very much appreciated :)

—Oliver

[David Kavanagh]

One way is to pass a "role" in via user data which gets written to a
file (like /etc/role) and then have a custom fact that reads that.
Then, your scripts can key off that to apply the classes for that node
type.

David

> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/AkY-XzhqaWwJ.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>

[Mark Stanislav]

On Jul 21, 2011, at 5:56 AM, Oliver Beattie wrote:

Hi there,

I am trying to setup a "cluster" on Amazon EC2, using auto-scaling. I currently have it working so that when the instances are started, they generate a CSR, which is automatically signed by the server if it's valid by a cron job I setup to run every minute.

Fair enough, this is a way I've gone prior as well.

However, where does one go from there? I suppose now the nodes need to be somehow registered on the puppet master so they can receive the correct configuration, but I'm unsure how to do this. I've read several articles which involve essentially creating a script which modifies the manifest, but is there a better way than this?

I'm fairly new to Puppet, so my other question would be how does one classify instances into "roles" or similar — for instance, if I am bringing up a webserver, can I just add it to a "webserver" group and it will be configured as such?

One way I've gone about this and presented about is using EC2 'Security Groups' to define roles for your nodes and then using EC2 facter facts, initialize modules to load based on their defined role in your manifests.

-Mark

Any pointers would be very much appreciated :)

—Oliver

[John Fieber]

On Jul 21, 2011, at 2:56 AM, Oliver Beattie wrote:

> I am trying to setup a "cluster" on Amazon EC2, using auto-scaling. I currently have it working so that when the instances are started, they generate a CSR, which is automatically signed by the server if it's valid by a cron job I setup to run every minute.
>
> However, where does one go from there? I suppose now the nodes need to be somehow registered on the puppet master so they can receive the correct configuration, but I'm unsure how to do this. I've read several articles which involve essentially creating a script which modifies the manifest, but is there a better way than this?

I use instance userdata to configure puppet (via ubuntu cloudinit) and set an explicit certname, in the form:

<instance_id>-<puppetclass>-<environment>

The server uses a a node classifier that fabricates the node spec from that.

Another option would to inject EC2 facts via facter so the client can report, say, what the security groups are, or other metadata, and have the puppet rules decide on based on that from a common EC2 instance puppet class. I came up with the certname approach before figuring out extending facter with ec2 facts, and it is working well enough that I'm not compelled to change at this point. If I were starting from scratch I'm not sure which would make more sense.

-john

[Dan Carley]

On 21 July 2011 16:41, John Fieber <j...@ursamaris.org> wrote:

I use instance userdata to configure puppet (via ubuntu cloudinit) and set an explicit certname, in the form:

 <instance_id>-<puppetclass>-<environment>

The server uses a a node classifier that fabricates the node spec from that.

 

Similarly I've used a port of cloud-init baked into a minimal CentOS AMI. Vanity hostname (under our own zone), location of the Puppet master, environment and some misc stuff are defined as YAML in the instance's user-data.

The stock cloud-init modules set the machine's hostname and populate "puppet.conf" from user-data on boot, amongst other things. A custom route53 module registers a CNAME for the instance's vanity hostname, pointing to Amazon's split horizon record. If the instance reboots then it updates DNS with it's new dynamic address.

Those vanity hostnames then serve as static records which can be used for Puppet certs and nodes in manifests. Not ideal, but seems to work pretty well.

[Ryan Conway]

The approach I've used is similar - automatically sign new CSRs so
that new nodes can be added without human interaction.

In order to then apply a configuration to the node, the hostnames for
my machines all conform to a pattern, which I then match against a
regular expression in the node manifest.

For example, instead of this:

node 'mywebapp1.domain' { include webapp }
node 'mywebapp2.domain' { include webapp }
node 'mydatabase.domain' { include database }

You can do this:

node /mywebapp*/ { include webapp }
node /mydatabase*/ { include database }

All my servers conform to a common pattern with the project, the type
of node, and a timestamp to ensure uniqueness.

Hope that helps!