This originally began as a utility to fully automate the creation of CentOS-based AMIs. However, it now includes the ability to create a basic IAAS environment for teams working in AWS. It will install an Ansible-based provisioning server that configures new machines to use FreeIPA for authentication, DNS, etc. In addition, servers are registered with Foreman to centralize configuration management and reporting.
The application uses the AWS-SDK and uses its configuration options for defining regions, credentials, etc. Assuming you have credentials stored in ~/.aws/credentials, you probably just need to specify AWS_REGION and AWS_PROFILE. Read the AWS documentation for more guidance.
export AWS_REGION=us-gov-west-1 export AWS_PROFILE=dpp
Each of the three modes of operation spin up a temporary machine and will clean up resources following successful execution. At the start of each run, a private key will be printed. It is suggested that you copy that key in the event of execution failure. It will allow you to log into the temporary VM and troubleshoot.
You need to make the cloud-init image first. That’s the image that will be used to install any intial VMs such as basic infrastructure and the provisioning server. Once those resources are in place you can provision VMs using the prov-client AMI.
This AMI can be created using a recent Amazon Linux AMI as the base. It’s not the fastest AMI in the world and isn’t well suited for IAAS usage. One reason is that an SE Linux relabel is performed on the initial boot. It includes puppet agent 4.x, ipa client, and SCAP software. SCAP remediation has not been performed.
Sample Usage is provided below
ami-builder --subnet subnet-fcfbcd88 --ami ami-7cb1091d --name "Centos 7.3 cloud-init" cloud-init --newuser booz-user
ami-builder --subnet subnet-fcfbcd88 --ami ami-ab79c2ca --user booz-user prov-server --server-rpm provision-server-0.1.4-1.git.14.dce166bNone.x86_64.rpm --client-rpm provision-client-0.1.4-1.git.14.dce166bNone.x86_64.rpm --domain new.gfclab.com --realm NEW.GFCLAB.COM --password mysecret
Cloud init is fine, but it’s often better to have an external server configure a new machine that have it configure itself. You don’t want users provide cloud-init data directly because it can be complex and/or they can break things. Third-party tools can speak to AWS on your behalf. Foreman is OK in this role, but we found that it didn’t provide enough flexibility. Creating new profiles for each OS, machine size, or networking configuration was too hard. Instead we create an AMI with a small client that phones home to a provisioning server at launch. The provision server provides an SSH key and proceeds to use Ansible for machine configuration. Ansible running on a dedicated server centralizing updates, protects credentials, and supports more orchestration options that cloud-init.
Additional steps are performed on this AMI to accelerate start up. Such as SCAP-based hardening and an SE Linux relabel. Enabling the relabel requires the use of VM that’s running SE Linux to bootstrap. Amazon Linux AMIs do not. However, you can use the cloud-init image created previously or a RHEL image.
ami-builder --subnet subnet-fcfbcd88 --ami ami-ab79c2ca --name "Centos 7.3 prov-client" --user booz-user prov-client --rpm provision-client-0.1.4-1.git.14.dce166bNone.x86_64.rpm --server 172.31.32.198
Most of the work is performed with three BASH scripts, ami.sh, server.sh and ami-iaas.sh, for cloud-init, prov-server, and prov-client respectively. You made need to modify these for your environment. This is particularly true for offline installations where the yum repos will need to point to local copies of the required RPMS.