This repository contains stage one bootstrapping for instances in Syseleven's Openstack cloud, 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.

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.

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.

This is the first stage bootstrap script invoked by the Syseleven Openstack cloud's standard user-data script (Heat resource sys11::cloudstrap::v4 and later) and stage0/cloudstrap.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.

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 Syseleven's use. Apart from that anything goes (just pick a number that will insert your own script between the desired Syseleven scripts.

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

initialize_instance uses the following environment variables:

• In the Syseleven Openstack cloud these variables are set through Heat, as properties of the sys11::cloudstrap::v4 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.

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:

• In Syseleven's Openstack cloud 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 sys11_topics='base firewall puppet-masterless').

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

git clone https://github.com/syseleven/bootstrap-scripts.git /opt/bootstrap-scripts
unset SSH_AUTH_SOCK
deploy_key="$(cat /root/deploy)" /opt/bootstrap-scripts/stage0/cloudstrap.standalone \
   -m sys11_topics="base firewall ssh sensu-server puppet-masterless" \
   -m nodetype="mysensuserver"

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.

Type: string (space delimited list)

This parameter is a space delimited list of configuration topics from sys11-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.