Notes on setting up sandbox for Ansible-managed services. WARNING: Sandboxing support is WIP and support varies from playbook to playbook. Same applies to infrastructure for hosting sandboxes. This document is intended to collect useful approach and try to establish the best practices, while avoiding early toolset lock-in. Generally, there're 3 approaches to hosting a sandbox: 1. "Pre-existing" sandbox host. This can be a physical box, but most likely a cloud host somewhere. 2. A fully isolated VM run locally. 3. A system container run locally. The basic requirement is availability of a complete system available via SSH. Then the basic dichotomy is remote vs local system. A remote system can be just anything, and it is assumed that setup of such system is outside the scope of this document. However, for locally run sandbox, this document provides recipes for some known approaches. Note that a container solution can be either application or system level. Oftentimes, there's no strict separation between the two approaches, and given enough effort, application-level system can be made to run almost complete system. "Enough effort" is a keyword here though, and this docoument tries to set up for quick and easy sandboxing, so application containers are not considered here (e.g. Docker, which largely leans towards application-level containers). Another thing to note that the whole sandboxing/containerization area is in flux and rapidly changes. That means that particular toolset may require fairly recent (oftentimes specific) OS and dependnet package versions, and there may be drastic, sometime not backwards compatible, changes in toolsets themselves. Both of these are just extra reasons why we should avoid tool lock-in at this stage and try to maintain solutions adhering to different criteria (e.g. most performant/efficient on resources vs the most compatible with wide OS/hw versions vs easy to install/use). Common requirements ------------------- 1. Sandbox-to-be should be accessible via SSH, as mentioned above. 2. Generally, sandbox should have an own IP address, instead of being accessible via port forwarding on localhost (some tools support/have that as default). Choice 1: Vagrant ----------------- Vagrant is a VM manager, with particular attention on using VMs for development/testing. Vagrant supports multiple VM backends, and had incompatible changes between original version supporting only VirtualBox VM and later versions. Ubuntu 14.04LTS still ships "original" version, which means docs/problem solutions found on the Internet will likely not work with OS version, and with deeper digging, older information can be found, but with some things broken (like original OS image links are all likely broken). At the same time, Vagrant itself kind of tries to speculatively maintain backwards compatibility (e.g. config format in later versions changes, but older is still supported). Approach: it's recommended to install the latest version from Vagrant web site, but the config is in Ubuntu-compatible format, and compatibility with Ubuntu version is maintained on the best-effort basis. To bring up a Vagrant sandbox, there's Vagrantfile in the top-level dir of this repository. Ideally, after you have installed VirtualBox and Vagrant, just running "vagrant up" should bring up a sandbox VM, downloading an OS image on first run. And that would be a common problem vector - that OS image location is changed again, and new location needs to be researched (that can happen only with Ubuntu version, a way to fix is to install the latest vendor version). You will need to look up an IP address of a sandbox in Vagrantfile. To login: ssh vagrant@ Choice 2: LXC ------------- Linux Containers (LXC) is a system-centric container. Ubuntu 14.04LTS ships with complete, working, and supported LXC version (apt-get install lxc). To create a sandbox (not started automatically): lxc-create -t ubuntu-cloud -n my-sandbox -- --auth-key ~/.ssh/id_dsa.pub where --auth-key argument is your SSH public key to be installed into a sandbox, so you can login afterwards. To start a sandbox: lxc-start -n my-sandbox To find out IP address of the sandbox: lxc-info -n my-sandbox To login use private key counterpart of pubkey you used during "lxc-create": ssh ubuntu@ After sandbox bring-up ---------------------- Make sure that you can login to a sandbox manually and that there're no stale hostkeys which preclude such login (which may be cached by SSH for previous sandboxes which shared the same IP). You may want to add an /etc/hosts alias for sandbox IP. (But let's try to make sure that this step is optional and Ansible playbooks can work with just an IP address). Running a playbook against sandbox ---------------------------------- Consult READMEs for individual services for now. Guidelines and best practices to be collected later.