Description

This repository contains stage one bootstrapping for instances in Openstack clouds, plus stage zero bootstrapping for other environments.

Its purpose is to deploy a minimum of configuration repositories, generate Hiera configuration (if applicable) and bootstrap an instance to the point where it can either run Puppet standalone (i.e. from its own Hiera configuration) or retrieve its configuration from a Puppet master.

Organization

This repository contains a range of standardized files and directories. Please adhere to this organization when forking it to maintain compatibility with the remaining components of our bootstrapping system. All non-absolute paths in this document are relative to the repository's root directory.

bin/

This directory contains scripts and other executables used in the course of the bootstrapping process. initialize_instance includes it in its PATH variable for easy use.

initialize_instance

This is the first stage bootstrap script invoked by the Autostrap's cloud's standard user-data script (Generated by the Heat resource AS::autostrap from our heat-resources repository) and stage0/autostrap.standalone. It logs its output to /var/log/initialize_instance.log.

Its main task is to execute the bootstrapping stages found in both this repository's bootstrap.d/ subdirectory and (optionally) a project-config repository's bootstrap.d subdirectory.

bootstrap.d

This directory contains bootstrap stages to be executed by initialize_instance. Scripts are numbered to control the order they are executed in (think sysvinit styles rc.d/ directories). You may place additional bootstrapping scripts in your project-config repository

For numbering your own scripts there are two rules:

• Numbers must be written in three-digit format (e.g. '015' instead of '15')

• Multiples of 20, including '000' (e.g. '000', '020', '040') are reserved for Autostrap's use. Apart from that anything goes (just pick a number that will insert your own script between the desired Autostrap scripts.

stage0/

This directory contains bootstrapping scripts for running Autostrap in non-Openstack environments. These scripts may be used for Autostrap deployments on bare metal machines, local development VMs or other environments without EC2 style metadata/user data passing mechanisms.

Environment

initialize_instance uses the following environment variables:

• In Openstack clouds these variables are set through Heat, as properties of the AS::autostrap resource. They are templated into the user data script generated by the resource.

• The stage0/bootstrap.simple script contains defaults for all of these environment variables and will override them from its environment if they are set.

Metadata parameters

Bootstrapping behaviour is governed by the metadata parameters listed below. They are passed to an instance in various way, depending on the stage 0 bootstrapping script being used:

• On Openstack clouds they are supplied as EC2 metadata entries and passed into an instance by cloud-init.

• By using the -m option to the stage0/bootstrap.simple script (may be given multiple times and takes a = delimited key-value pair as its sole argument, e.g. -P topics='base firewall puppet-masterless').

Usage example

This usage example assumes your private git repositories' (if you have any, that is) deploy key to be in /root/deploy. It deploys base system configuration with various sane defaults, all managed using masterless Puppet.

git clone https://github.com/autostrap/bootstrap-scripts.git /opt/bootstrap-scripts
unset SSH_AUTH_SOCK
deploy_key="$(cat /root/deploy)" /opt/bootstrap-scripts/stage0/autostrap.standalone \
   -m topics="base ssh puppet-masterless" \

puppet_master

type: string (FQDN)

This parameter contains the fully qualified domain name of the puppet master, puppet agents retrieve their configuration from. This should be set on both puppet agents and the puppet master, since the puppet master itself is usually managed from the same source.

topics

Type: string (space delimited list)

This parameter is a space delimited list of configuration topics from global-config to deploy. This is commonly used for early stage bootstrapping, i.e. for getting a node to a point where it can act as a puppet agent or puppet master.