2. Phil Watts - Loglan Explicator
• Certified by Puppet Labs and
AWS as someone who knows
things™
• “Unofficially” a charter
Hashicorp Partner SME
• Convicted of multiple counts of
being the long winded guy
speaking at Puppet events
• Was paid off to be here today
with 14lbs of carefully
prepared Beef Brisket (get in
good with your sales engineer)
2
3. Assumptions
3
Declarative state infrastructure as code is good.
- Reduces failures due to misconfiguration
- Increases Security
- Visibility into what is configured
Auto-Scaling instances based on load is good.
- Contains cost for running infrastructure
- Addresses performance constraints
Auto-Scaling that takes 30 minutes to respond to a load spike isn’t so good.
- A scaled instance is not worth anything until it can server requests
- Less configuration on the instance speeds up time to first response
4. System Lifecycles
4
Immutable Infrastructure - Once launched, the system is never changed. When
a change is required, a new system is created to replace the previous instance.
Operationally Immutable, Application Flexible - The base system, from kernel
up to the application container never changes, but application specific
configuration and deployed data may change.
Maintained long running systems - Major configurations should be unchanged,
but system maintenance tasks would be carried out in addition to deployment
actions.
My servers are my friends. I care for them deeply. We grow together through
our journey. Please don’t hurt Bob.
5. The Golden Images
5
“Golden Image” - I repeatable machine image which requires no additional
configuration to serve it’s purpose in your application architecture.
Problems they solve:
- Preconfigured images launch very fast
- Inherently consistent relative to themselves
Problems they don’t solve:
- Creation mechanism does not need to be controlled
- Provides limited assurance for compliance concerns
- No ability to combat configuration drift
Lesson of the day: Golden Image creation and Configuration Management are not
conflicting concepts. Use CM to make your golden images, and be happy the rest of
your days.
10. Example Puppet Code
10
class SampleManifest {
file { '/etc/resolv.conf':
content => template("${module_name}/resolv.conf.erb"),
}
file { '/etc/environment':
source => "puppet:///modules/${module_name}/environment",
tag => 'provisioning',
}
}
SampleManifest.pp
11. Global Defaults to associate a tag
11
Package { tag => 'provisioning', }
This will add the provisioning tag to every Package
resource in the catalog. Of all the things you can
decide to preconfigure in an image creation, package
installation takes the longest.
Site.pp
12. Advanced Considerations:
12
This model requires either auto-signed certificates,
or the use of a previously authorized certificate to be
staged onto the temporary instance during build.
Certificates:
Auto-signing provides the easiest entry solution, however license cleanup becomes a
problem. Some automated cleanup exists in sunsetting the unused nodes, but more
aggressive cleanup requires additional instrumentation.
13. Reusable Certificate Model
13
{
"type": "file",
"source": "files/packerbuild.cert.pem",
"destination": "/tmp/packerbuild.cert.pem"
},
{
"type": "file",
"source": "files/packerbuild.private_key.pem",
"destination": "/tmp/packerbuild.private_key.pem"
},
{
"type": "shell",
"script": "scripts/puppet-install.sh"
},
1. Create an agent certificate and
private key with a known name
which will be reused.
2. Pre-classify the node into a group
which can use a provided fact to
associate the desired Role.
{
"type": "puppet-server",
"options": "--test --pluginsync --tags provisioning",
"client_cert_path": "/tmp/packerbuild.cert.pem",
"client_private_key_path": "/tmp/
packerbuild.private_key.pem",
"facter": {
"server_role": "webserver"
}
}