Puppet with Amazon AWS I

Puppet

Puppet is produced by Puppet Labs, founded by Luke Kanies in 2005. It is written in Ruby.

Puppet arguably enjoys the biggest share among the big 4: Puppet, Chef, Ansible, Salt.

Most configuration tools (shell or Perl script) are imperative or procedural. They describe how things should be done rather than the desired end state-for example, most custom scripts used to manage configuration would be considered imperative.

However, Puppet uses a declarative language. Puppet just declares what the state of their hosts should be: what packages should be installed, what services should be running, and so on. With Puppet, the system administrator doesn't care how this state is achieved-that's Puppet's problem. Instead, we abstract our host's configuration into resources.

The following tutorials on Puppet will be focused on the puppet using Amazon AWS. We'll make two instances of puppet: master and agent. After setting up Puppet in an agent/master configuration, we run very simple HelloWorld config via Puppet manifests.

Puppet is usually deployed in a simple client-server model. The server is called a Puppet master, the Puppet client software is called an agent, and the host itself is defined as a node.

The Puppet master runs as a daemon on a host and contains the configuration required for the specific environment. The Puppet agents connect to the Puppet master through an encrypted and authenticated connection using standard SSL, and retrieve or pull any configuration to be applied.

Importantly, if the Puppet agent has no configuration available or already has the required configuration, Puppet will do nothing. Puppet will only make changes to our environment if they are required. This property is called idempotency and is a key feature of Puppet.

The usual practice is to run Puppet as a daemon and have it periodically check with the master to confirm that its configuration is up-to-date or to retrieve any new configuration. By default, the Puppet agent will check the master for new or changed configuration once every 30 minutes. We can configure this period to suit our needs.

We need to create our key pair so that we can connect to our Amazon EC2 instances. Public AMI (Amazon Machine Image) instances use a public/private key pair to log in rather than a password. The public key half of this pair is embedded in our instance, allowing us to use the private key to log in securely without a password. After we create our own AMIs, we can choose other mechanisms to securely log in to our new instances. In this step we will use AWS Management Console to create a key pair.

To generate a key pair:

1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
   
2. In the top navigation bar, in the region selector, choose the region.
3. In the left navigation pane, under Network and Security, click Key Pairs.
4. Click Create Key Pair.
5. Type 'bogo_puppet' in the new Key pair name box, and then click Yes.
   
   
6. Download the private key file, which is named bogo_puppet.pem, and keep it in a safe place. We will need it to access any instances that we launch with this key pair.
7. Note:
   If we lose the key pair, we cannot connect to our Amazon EC2 instances.





Creating security groups









We add some ports: 22(SSH), 80(HTTP), 8140(Puppet):








Ubuntu 14.04 Utopic cloud image

Let's go to https://cloud-images.ubuntu.com/utopic/current/.







Select us-east-1 and 64 bit ebs and Launch:













We can see our instances are currently running, and we need to name them:





To ssh to those instances, we need the following information:






EC2 Instance Lifecycle

By working with Amazon EC2 to manage our instances from the moment we launch them through their termination.

The following illustration represents the transitions between instance states. Notice that we can't stop and start an instance store-backed instance.



Picture from Instance Lifecycle.




When we launch an instance, it enters the pending state. The instance type that we specified at launch determines the hardware of the host computer for our instance. We use the Amazon Machine Image (AMI) we specified at launch to boot the instance. After the instance is ready for us, it enters the running state. We can connect to our running instance and use it the way that we'd use a computer sitting in front of us.

As soon as our instance starts to boot, we're billed for each hour or partial hour that we keep the instance running (even if the instance remains idle and we don't connect to it).

If our instance fails a status check or is not running our applications as expected, and if the root volume of our instance is an Amazon EBS volume, we can stop and start our instance to try to fix the problem.

When we stop our instance, it enters the stopping state, and then the stopped state. While our instance is in the stopped state, we can modify certain attributes of the instance, including the instance type.

When we start our instance, it enters the pending state, and the instance is moved to a new host computer. Therefore, when we stop and start our instance, we'll lose any data on the instance store volumes on the previous host computer.

If our instance is running in EC2-Classic, it receives a new private IP address, which means that an Elastic IP address (EIP) associated with the private IP address is no longer associated with our instance. If our instance is running in EC2-VPC, it retains its private IP address, which means that an EIP associated with the private IP address or network interface is still associated with our instance.

For more info, please visit Instance Lifecycle.




Puppet

8. Puppet with Amazon AWS I - Puppet accounts
9. Puppet with Amazon AWS II (ssh & puppetmaster/puppet install)
10. Puppet with Amazon AWS III - Puppet running Hello World
11. Puppet Code Basics - Terminology
12. Puppet with Amazon AWS on CentOS 7 (I) - Master setup on EC2
13. Puppet with Amazon AWS on CentOS 7 (II) - Configuring a Puppet Master Server with Passenger and Apache
14. Puppet master /agent ubuntu 14.04 install on EC2 nodes
15. Puppet master post install tasks - master's names and certificates setup,
16. Puppet agent post install tasks - configure agent, hostnames, and sign request
17. EC2 Puppet master/agent basic tasks - main manifest with a file resource/module and immediate execution on an agent node
18. Setting up puppet master and agent with simple scripts on EC2 / remote install from desktop
19. EC2 Puppet - Install lamp with a manifest ('puppet apply')
20. EC2 Puppet - Install lamp with a module
21. Puppet variable scope
22. Puppet packages, services, and files
23. Puppet packages, services, and files II with nginx
24. Puppet templates
25. Puppet creating and managing user accounts with SSH access
26. Puppet Locking user accounts & deploying sudoers file
27. Puppet exec resource
28. Puppet classes and modules
29. Puppet Forge modules
30. Puppet Express
31. Puppet Express 2
32. Puppet 4 : Changes
33. Puppet --configprint
34. Puppet with Docker
35. Puppet 6.0.2 install on Ubuntu 18.04