Blog
Answers about Puppet
DevOps, Automation
Universe and Everything
Need Puppet help?
Contact Alessandro Franceschi / example42
for direct expert help on Puppet.
If solution is quick, it’s free. No obligations.
Tip of the Week 28 - Puppet and Fabric
Fabric is a remote execution tool, written in Python, which ease parallel execution and orchestration of commands on different nodes.
Why does it matter with Puppet?
Because it’s a good candidate, and not a rare choice, to trigger Puppet runs (and more) from a central location.
In PSICK, our Puppet control-repo [generator], we use it for several tasks tasks which are related to the whole Puppet code workflow, from development, to testing and deployment.
We can install Fabric, as common with Python software, using pip:
pip install fabric
Once installed we have at disposal the fab executable, which reads a file called fabfile.py to get the list of available Fabric commands.
In PSICK we gathered different fab files for different purposes in a single directory give them a look for an idea of their format. Being written in Python they can have a much more complex and flexible content.
To list the available commands in the local fabfile (or directory) we can type:
fab -l
Fabric commands can be executed locally on remote nodes. On remote nodes it uses SSH for connection. There are various ways to define the list of remote nodes where to execute a given command, the simplest one is probably to specify them directly in the command line with the -H argument followed by a comma separated list of nodes or using the :host argument:
fab <task>[:host=<hostname>][:option=value]
fab [-H <hostname>] <task>[:option=value]>
Note that there are other ways to define and group the nodes to work with, for example by using Fabric roles, refer to the official documentation for details.
Typically access to the remote node is done using SSH keys, using the local user for remote authentication, if keys are not used a password is prompted.
If local and remote users don’t match, or access to a remote node can’t be direct and requires a jump host, it’s definitively worth adding the relevant nodes in our ~/.ssh/config file, where we define for our nodes, the user to access them, the SSH key to use, eventually a jump host and so on. Syntax for SSH client file is something like:
Host mon
ProxyCommand ssh -A -x -W %h:%p bastion.aws.example.com 2> /dev/null
ForwardAgent yes
User ec2-user
Hostname 10.10.2.160
IdentityFile ~/.ssh/aws.pem
In this way we can connect to this host, with all the correct configurations, with ssh mon, or, when using Fabric, fab -H mon.
Fabric on PSICK
We mentioned PSICK and its integration with Puppet, the list of available commands is not short:
al@mule psick [development] $ fab -l
Available commands:
aws.apply [local] Run puppet apply locally using the specified role (default: aws)
aws.setup [local] Install locally the aws cli environment
aws.status [local] Show AWS resources on one or all regions
docker.purge [local] Clean up docker images and containers (CAUTION)
docker.rocker_build_role [local] WIP Rockerize a role on all or the specified image OS (data in hieradata/role/$puppetrole.yaml)
docker.setup [local] Install locally Docker (needs su privileges)
docker.status [local] Show Docker status info
docker.test_role [local] Test a role on the specified OS on a Docker image
docker.tp_build_role [local] Dockerize a role based on tp on all or the specified Docker (data in hieradata/role/$puppetrole.yaml)
facter.set_external_facts [remote] Set the given external facts in /etc/puppetlabs/facter/facts.d
facter.set_trusted_facts [remote] Set the given trusted facts in /etc/puppetlabs/puppet/csr_attributes.yaml
git.checkout_master [local] Run git checkout master on each on the installed modules
git.install_hooks [local] Install Puppet .git/hooks
git.setup_new_repo [local] Create a new repo from scratch, based on the current contents of this control-repo
git.status [local] Run git status on this repo and the installed modules
puppet.agent [remote] Run puppet agent
puppet.agent_noop [remote] Run puppet agent in noop mode
puppet.apply [remote] Run puppet apply on the deployed control-repo (uses control-repo in the environments/production dir)
puppet.apply_noop [remote] Run puppet apply in noop mode (needs to have this control-repo deployed)
puppet.check_syntax [local] Check the syntax of all .pp .erb .yaml files in the contro-repo
puppet.current_config [remote] Show currently applied version of our Puppet code
puppet.deploy_controlrepo [remote] Deploy this control repo on a node (Puppet has to be already installed)
puppet.install [remote] Install Puppet 4 on a node (for Puppet official repos)
puppet.lint [local] Run puppet-lint on all site manifests. Eventually fix them
puppet.module_generate [local] Generate a Puppet module based on skeleton
puppet.module_publish [local] Publish on GitHub and the Forge the local version of a module
puppet.remote_setup [remote] Installs on a remote node the packages needed for a puppet apply run on the control-repo
puppet.setup [local] Setup the contro-repo, installs r10k and external modules
puppet.sync_and_apply [remote] Run puppet apply on a synced copy of the local git repo (syncs and uses control-repo)
tp.clone_data [local] Add a new app name data directory under modules/tinydata, based on the specified source
tp.install [local] Install locally any tinydata knows app via tp
tp.remote_test [remote] WIP Run tp tests on remote node
vagrant.destroy [local] Destroy the specified vm
vagrant.env_status [local] Run vagrant status on all or the specified environments
vagrant.halt [local] Halt all or the specified Vagrant vm
vagrant.node_test [local] Run existing and testing Puppet code on a VM
vagrant.provision [local] Provision all or the specified vm
vagrant.reload [local] Reload all or the specified vm
vagrant.resume [local] Resume all or the specified vm
vagrant.setup [local] Install locally Vagrant and the needed plugins
vagrant.status [local] Show status of all or the specified vm
vagrant.suspend [local] Suspend all or the specified vm
vagrant.up [local] Vagrant up the specified vm
Many of these commands are executed locally (and just wrap simple shell commands present in PSICK’s bin/ directory), but there are some intended to be used on remote nodes.
For example, to install Puppet on one or more remote nodes we can run:
fab puppet.install -H host1,host2
To run puppet agent in noop mode on all the known hosts (as defined in fabiles, or in the environment):
fab puppet.agent_noop
To run puppet agent on a specific node:
fab puppet.agent -H web01.example.test
To run in apply mode the local code on a remote node (code is rsynced and then compiled on the remote node, eventual eyaml keys and first copied and then removed):.
fab puppet.sync_and_apply
Local Puppet activities with PSICK
Local commands are, generally, not ommon in Fabric, as the tools is supposed to be used for remote execution, still in PSICK there are several commands available to support us in our Puppet code workflow.
For example, to install useful git hooks for Puppet development. By default downloaded from (https://github.com/drwahl/puppet-git-hooks)[https://github.com/drwahl/puppet-git-hooks]:
fab git.install_hooks
To generate a new module based on the format of PSICK’s skeleton directory.
fab puppet.module_generate
To check the git status of the main control-repo and of each module in modules:
fab git.status
To check the syntax of all .pp .yaml .epp .erb files in our control-repo:
fab puppet.check_syntax
To publish the local version of a module in modules/ dir to Forge and GitHub (puppet-blacksmith setup and access to remote git repo required):
fab puppet.module_publish:<module_name>
To test a role (as defined in hieradata/role/$role.yaml) with Docker on different OS base images:
fab docker.test_role:<role>,<image>
fab docker.test_role:log,ubuntu-14.04
Available images are: ubuntu-12.04, ubuntu-14.04, ubuntu-14.06, centos-7, debian-7, debian-8, alpine-3.3.
These are just examples, give a look to the list of available commands for more, and use the -d argument to show a list of available arguments:
al@mule psick [development] $ fab -d docker.test_role
Displaying detailed information for task 'docker.test_role':
[local] Test a role on the specified OS on a Docker image
Arguments: puppetrole='docker_test_role', image='centos-7'
The fabfiles on PSICK are rather basic, but much more can be do, list of nodes can be automatically queried to AWS or PuppetDB, commands can be the result of more or less Python code, which may trigger remote backups, check for systems status, perform database operations, applications deployment and so on.
So, even if not strictly necessary (not even in PSICK), Fabric can be a good companion to Puppet and generally to the whole operations.
It’s usage inside a control-repo may give to it a whole new meaning, which goes further than a “simple” central repository for Puppet code and data, and may become the single place from where the whole infrastructure can be provisioned, configured, controlled, and managed.
The limit is our imagination.
Alessandro Franceschi