Originally called Site Controller (sitectl) and is Pronounced "Cuddle".
insert logo of a squid/cuttlefish cuddling a server
A Monolithic Repository of Composable Ansible Roles for building an SRE Operations Platform.
Originally built by the BlueBox Cloud team to install the infrastructure required to build and support Openstack Clouds using Ursula it quickly grew into a larger project for enabling SRE Operations both in the Datacenter and in the Cloud.
Like Ursula, Ursula Cuttle uses the ursula-cli ( installed via requirements.txt ) for running Ansible on specific environments.
For a rough idea of how Blue Box uses Cuttle by building Central and Remote sites tethered together with IPSEC VPNs check out architecture.md.
You will see a number of example Ansible Inventories in envs/example/ that
show Cuttle being used to build infrastructure to solve a number of problems.
envs/example/sitecontroller shows close to a full deployment, whereas
envs/example/mirror or envs/example/elk to build just specific components.
All of these environments can easily be deployed in Vagrant by using the ursula-cli
(see Example Usage ).
See docs/deploy_2fa_secured_bastion.md for a fairly comprensive document on deploying a secure ( 2fa, console logging, RBAC) Bastion.
See CONTRIBUTORS.md for the original team.
The official git repository of Site Controller is https://github.com/IBM/cuttle. If you have cloned this from somewhere else, may god have mercy on your soul.
We follow the standard github workflow of Fork -> Branch -> PR -> Test -> Review -> Merge.
The Site Controller Core team is working to put together guidance on contributing and governance now that it is an opensource proect.
# clone this repo
$ git clone [email protected]:ibm/cuttle.git
# install pip, hopefully your system has it already
# install virtualenv
$ pip install virtualenv
# create a new virtualenv so python is happy
$ virtualenv --no-site-packages --no-wheel ~/<username>/venv
# activate your new venv like normal
$ source ~/<username>/venv/bin/activate
# install ursula-cli, the correct version of ansible, and all other deps
$ cd cuttle
$ pip install -r requirements.txt
# run ansible using ursula-cli; or ansible-playbook, if that's how you roll
$ ursula envs/example/<your env> site.yml
# decactivate your virtualenv when you are done
$ deactivate
Vagrant is our preferred Development/Testing framework.
ursula-cli understands how to interact with vagrant using the --provisioner flag:
$ ursula --provisioner=vagrant envs/example/sitecontroller bastion.yml
$ ursula --provisioner=vagrant envs/example/sitecontroller site.yml
your inventory must have a heat_stack.yml and a optional vars_heat.yml in order for this to work
You can also test in Openstack with Heat Orchestration. First, grab your stackrc file from Openstack Horizon:
Project > Compute > Access & Security > Download OpenStack RC File
Ensure your ssh-agent is running, then source your stackrc and run the play:
$ source <username>-openrc.sh
$ ursula --ursula-forward --provisioner=heat envs/example/sitecontroller site.yml
Add argument --ursula-debug for verbose output.
$ docker run \
--name proxy -p 3128:3128 \
-v $(pwd)/tmp/cache:/var/cache/squid3 \
-d jpetazzo/squid-in-a-can
then set the following in your inventory (vagrant.yml in envs/example/*/)
env_vars:
http_proxy: "http://10.0.2.2:3128"
https_proxy: "http://10.0.2.2:3128"
no_proxy: localhost,127.0.0.0/8,10.0.0.0/8,172.0.0.0/8
To actually deploy an environment you would use ursula-cli like so:
$ ursula ../sitecontroller-envs/sjc01 bastion.yml
$ ursula ../sitecontroller-envs/sjc01 site.yml
# targetted runs using any ansible-playbook option
$ ursula ../ursula-infra-envs/sjc01 site.yml --tags openid_proxy