The problem is how to set up a new instance with so that it will load it's config from a particular class
Let me try and explain the problem I think you are trying to address
What I am trying to answer here
You have an existing script that sets up EC2 virtual hosts on AWS using the aws-puppet module. This module calls AWS API to actually make EC2 virtual hosts. But they only contain configuration that is "built in" to the AMI file that is used in the API call. A typical AMI file might be a Centos base image. Further configuration is possible at this phase via a "user data script". But let's assume this a shell script, difficult to test and maintain and so not containing complex setup
So further configuration, install of packages and setup is needed. In order to make this setup happen, there is a second phase of activity from puppet, using entirely different manifests (that are not detailed in the question)
This second phase is controlled by the new EC2 virtual hosts attaching to the puppet master in their own right. So what I am assuming you are doing is:
- phase 1, making EC2 hosts
- phase 2, when they are up config themselves from puppet
Basic Answer using roles
Here some ideas of how to make this scenario with two phase configuration of the EC2 hosts work
At create time make a custom fact "role". Make a file in
/etc/facter/facts.d/role.yaml like this
role: webserver
This can be setup as the instance is made by adding a command like this to a User Data script
echo 'role: webserver' > /etc/facter/facts.d/role.yaml
As long as this "role" is setup before puppet starts up it will work fine.
I am assuming that you have a set of modules with manifests and maybe files subdirectories in the module path with the same name as the role
Next, alter your site.pp to say something like
include "$role"
And the init.pp from the module will kick in and do the right thing, install packages, configure files etc!
This idea is explained in more detail here https://puppetlabs.com/presentations/designing-puppet-rolesprofiles-pattern
Another Approach
The above is a really crude way of doing it which I haven't tested! Our setup has roles but loads them via hiera configuration.
The heira configuration looks somewhat like this
---
:backends:
- yaml
:hierarchy:
- role/%{::role}
- global
:yaml:
:datadir: /etc/puppet/environments/production/hiera
Then I might have a /etc/puppet/environments/production/hiera/role/webserver.yaml file which says
classes:
- webserver
- yum_repos
- logstash
- java8
And the end of the site.pp says
hiera_include('classes')
Which loads all the relevant "classes" definitions from the modules_include files
This has the advantage that multiple classes can be loaded by each role with much less duplication of code
The "global" part of the yaml configuration is intended for classes that are loaded by everything in your environment, for example admin user ssh keys
defined type example
Here is an example of how you might use a defined type as a wrapper around ec2_instance to pass the "myrole" into the template. I have not tested this, I don't have the aws puppet stuff installed
define my_instance(
$ensure = present,
$region = 'us-west-2',
$image_id = 'ami-f0091d91',
$instance_type = 't2.micro',
$key_name= 'mykey',
$security_groups = ['provision-sg'],
$myrole = 'webserver'
)
{
ec2_instance { $title :
ensure => $ensure,
name => $title,
region => $region,
image_id => $image_id,
instance_type => $instance_type,
key_name => $key,
security_groups => $security_groups,
user_data => template('configure.erb'),
}
}
$instance_data={
'backend' =>
{
ensure => present,
name => 'backend',
region => 'us-west-2',
image_id => 'ami-f0091d91',
instance_type => 't2.micro',
key_name => 'mykey',
security_groups => ['provision-sg'],
myrole => 'voodooswamp'
},
'webfront'=>
{
ensure => present,
region => 'us-west-2',
image_id => 'ami-f0091d91',
instance_type => 't2.micro',
key_name => 'mykey',
security_groups => ['provision-sg'],
myrole => 'humanfly'
}
}
create_resources(my_instance, $instance_data)