1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
|
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@<IP>
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@<IP>
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.
|
