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: > > 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 > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/2466b012-5fc6-426e-b256-c6f309530c32%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
