Challenge: who am i and what do i do

[Alex Demitri]

Hi guys - i am fairly new to puppet and i am trying to figure out ways to implement it in my organization to make good use of it. One thing we thought would be useful to better our deployment process, is to add a mechanism that would have a vanilla server getting installed on a VM, boot up, check into puppet and figure out these three questions:

1) Where am I?

    - in what Datacenter/Availability zone am I? Based on that, what syslog servers do i have to use, NTP servers, etc..

2) Who am I?

    - what server am i? What files do i need for basic functions?

3) What am I supposed to do?

    - based on what server I am, what am i supposed to do? do i have to run Tomcat? Apache? And if yes, where are my configuration files?

In short, find a holistic way for a system to come up to speed by itself. I already thought of using meaningful hostnames for the roles of the servers but that does not work well in the cloud...

Thoughts? 

Thanks!

Alex

[Andy Taylor]

I'd recommend checking out Razor:

https://github.com/puppetlabs/razor-server/wiki

Although as far as I'm aware it's not production ready yet.

[Sebastian Otaegui]

Can you pass that information to the instances using cloud-init / user-data?

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/19eb33ce-cf76-43b4-abef-a6b17dad568f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Those who do not understand Unix are condemned to reinvent it, poorly.
Any sufficiently recent Microsoft OS contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Unix.

[Atom Powers]

DHCP + CMDB + ENC will get you there. (Foreman is an easy CMDB for Puppet.)

DHCP answers "Where am I?" and "Who am I?"

CMDB + ENC answers "What am I supposed to do?"

--

You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/16a1cb0c-ab6d-4578-a221-482a86d05130%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Perfection is just a word I use occasionally with mustard.
--Atom Powers--

[Ramin K]

When we provision machines the system passes a few flags that do the
equivalent of

sudo FACTER_role=frontend puppet agent --environment stage --certname
fe34.usw1.example.com

role is a custom fact that needs to be set the first time as shown
above. Puppet does the Hiera lookup based on $role and $env with
$certname or nodename as the final arbiter. That's as much config as we
need, but no reason you couldn't add various ec2 facts to the hierarchy.

Ramin

[Martijn]

We use the Cloud-init system built into Ubuntu for our Amazon VPC instances. When starting a new instance we pass it User-data which contains commands in Cloud-config format that sets the hostname and domain, adds the puppetlabs repo, updates the package cache, installs puppet and enters some values such as the certname and servername in the puppet.conf file.

#cloud-config
manage_etc_hosts: true
hostname: <hostname>
fqdn: <hostname>.example.com
apt_sources:
 - source: "deb http://apt.puppetlabs.com $RELEASE main dependencies"
   keyid: 4BD6EC30
   filename: puppetlabs.list
apt_update: true
apt_upgrade: true
packages:
 - puppet
puppet:
  conf:
    agent:
      server: "puppet.example.com"
      certname: "%i.<hostname>.us-east-1.vpc.aws"

The %i is automatically replaced with the instance-id. Our deployment is small enough 10-20 instances) that for us the certname contains enough information to identify the machine. You can easily extend this to put some custom facts {1} on the machine, like DC, AZ, which Puppet would receive automatically from Facter on every run. In fact, I'm working on that. Search Google for "cloud-init facter" and you'll get the idea.

A role {2} is then assigned to the new host via an ENC (e.g. queue_worker, solr_server or webserver_drupal). Each role lists a number of profiles {3} that describe the actual services needed (e.g. php55, apache, ntp, logstash_shipper, etc.). For example, the ntp_client profile uses the ntp module and values from Hiera to set up NTP. Check out the roles-profiles pattern if you're not familiar, which is becoming a standard design in Puppet-land.

Use Hiera to configure your modules depending on those facts, things like which NTP-servers should the ntp module use, to which RabbitMQ server should Logstash send its logs, which PHP-modules does this platform require, etc.

The Extending Puppet book explains the details better than I can, but hopefully this helped you on the way. The main thing in bootstrapping for us was using User-Data and Cloud-init to get things rolling. The remainder is standard Puppet stuff (i.e. Facter, Hiera, Puppet).

Regards, Martijn


Op dinsdag 26 augustus 2014 21:41:01 UTC+2 schreef Alex Demitri:

[Brian Wilkins]

We do the same thing as Ramin. Essentially have a custom role fact that is based on hostname. After initial "check-in" with the puppetmaster, the agent knows it role and is provisioned as such. We use the role/profile design pattern.

[Jason Antman]

Agreed with Atom...

I generally think that this method is backwards. The system shouldn't tell Puppet what it wants to be; Puppet (possibly fed by some external data source(s)) should tell the system what to be. Sure, in some very large environments with a small number of possible configurations, the other way around will work. But why do something like tie your entire CM system to a hostname convention?

-Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAF-H%3DOm_0G3-VWnnjK5F6VD-rwQd8mtfQbnnkR_VKb0uYrmssQ%40mail.gmail.com.

[jcbollinger]

On Thursday, September 4, 2014 5:50:43 PM UTC-5, Jason Antman wrote:

Agreed with Atom...

I generally think that this method is backwards. The system shouldn't tell Puppet what it wants to be; Puppet (possibly fed by some external data source(s)) should tell the system what to be.

+1

 

Sure, in some very large environments with a small number of possible configurations, the other way around will work. But why do something like tie your entire CM system to a hostname convention?

And since that data has to be recorded *somewhere*, why disperse it among the nodes and trust them to feed it back rightly?  Moreover, supposing you use Puppet's default hostname-as-certname scheme, why semi-permanently bind each node to be a particular kind of machine, as encoding that information in its certname would do?


John