Introduction
OVH is a french company that provides cheap virtual instances. I've selected a VPS, a Virtual Private Server, on
Ubuntu 13.10. Its price is less than 2€ per month.
In this tutorial, I'll expose my way of using these instances using a powerful
DevOps tool named
Saltstack. With a single command, I can ping all the instances that I manage, ensure that all the servers run my latest
NGINX configuration, etc, ... Everything is done from my Mac at home. It is reproducible. Therefore on risky configuration settings, I can recreate a virtual machine reproducing an existing environment (as described in my previous articles:
Virtualize your servers and
Fill up your servers automatically with goodies), checking my new configuration before applying it on a production server.
Note : For the story, I'm a simple customer of OVH. I don't own any share in this company. This is not an advertisement for their service. I only share it as they provide a good service and as VPS may be used to deploy almost any kind of software that you need. This tutorial could be applied to other cloud service.
Installing Saltstack master on my personal computer
Installation of
Saltstack is done on OSX with
Homebrew:
brew install saltstack
Now, we are going to increase the opened sockets capacity of OSX:
sudo launchctl limit maxfiles 4096 8192
When installed from
Homebrew,
Saltstack doesn't come with the default configuration files. Theses files are described in the
Saltstack documentation pages:
21.6. Configuration file examples.
Saltstack expects to see at least 2 files,
master and
minion into the uncreated
/etc/salt directory. Let's fix that:
sudo mkdir /etc/salt
And copy the content of
master and
minion into this freshly created directory.
Before customizing your
master file, you should know your IP address in the LAN. Here's a simple command that analyse your current configuration (note that I've setup it as an alias in my personal
dotfiles as
ips command).
ifconfig -a | perl -nle'/(\d+\.\d+\.\d+\.\d+)/ && print $1'
Now edit the
/etc/master file to reflects the opened sockets capacity and as I dont' like sudoing each time I have to launch a command, add your username to the allowed users (here it's
PEM, of course):
max_open_files: 8192
user: PEM
interface: 192.168.1.30
file_roots:
base:
- /Users/PEM/Projects/SolutionsM3/DevOps/states
pillar_roots:
base:
- /Users/PEM/Projects/SolutionsM3/DevOps/pillar
Note that I've setup my
Saltstack master so that its all the formulas that I deploy are stored in my personal directory. This allows me to modify every deployed configuration and save them with
Git once I've finished working on them. This is what DevOps is for: your infrastructure and administration as simple script files with formulas reproducible, idempotent, evolving, without connecting manually to every servers each time you need to adjust a simple variable.
Prepare your SSH configuration
First, I ensure that I can connect myself to my VPS without password. I don't like sudoing nor I don't like being asked for password when my security has been tightened.
OVH sets up an
OpenSSH server on all the instances. OSX comes already bundled with
OpenSSH, the client and the server. Though, there is one step that you need to do, if you haven't done it before : generating your personal SSH keychain. This is done with a simple bundled command:
ssh-keygen
This command generate the following files in your home directory:
/Users/PEM/.ssh
├── id_rsa
├── id_rsa.pub
└── known_hosts
We are going to authorize ourselves on our VPS with your public key:
cat ~/.ssh/id_rsa.pub | ssh root@vpsXXXXX.ovh.neta 'cat >> .ssh/authorized_keys'
Where
XXXXX is the VPS's number that
OVH has provided you.
Now connect yourself to your VPS using a simple ssh command and without password anymore:
ssh root@vpsXXXXX.ovh.net
Declaring your VPS as a minion
Normally, your
Saltstack master should be visible from your minions, the distant servers that you need to manage. Using this configuration,
Saltstack is able to handle thousands of servers in the blink of an eye by relying on secured AES tunnel relying on
ZeroMQ.
But in my case, I'm on my personal Mac, at home, thus, in my LAN. Even if I modify my gateway, my ISP may change my IP whenever it wants it. I could setup a DynDNS service but each time I'll travel to another one location, I would be forced to set it up again. Thankfully, last year,
Saltstack added an SSH transportation capabilities. It's a bit slower but it is as powerful as a real master / minion configuration using
ZeroMQ. All you have to do is to create a list (a roster) of the servers that you want to manage in your
/etc/salt/roster file with this info:
vpsXXXXX:
host: vpsXXXXX.ovh.net
Now, whenever I want to check by a ping all my servers, I use a single command:
salt-ssh '*' test.ping
If I want to target a specific one:
salt-ssh 'vpsXXXXX' test.ping
With simple naming scheme, I'm able to achieve deployment of a specific package on a specific group of servers. Nifty.
We install remotely the appropriate Saltstack packages on every server:
salt-ssh '*' -r 'apt-get install -y salt-minion'
A simple example
Deploying the
tree command on all my servers or checking that it has already been deployed from the comfort of my coach is done like this. In my DevOps project, I've set up 2 files:
├── pillar
└── states
├── top.sls
└── tree.sls
The
states/top.sls file declare all the available formulas that I want to apply on every servers. In this simple example it contains only a basic rule to install the
tree command:
base:
'*':
- tree
And for the
states/tree.sls file, just a simple call to the
Saltstack's module
pkg, which is able to handle almost every Linux packaging tools that I've been playing with:
tree:
pkg:
- installed
Time for the installation. As the
Saltstack's state are idempotent, I can run this command every time I want. It will only execute it where it is required:
tree:
salt-ssh '*' -c /etc/salt state.highstate
With this installation, I'm capable of checking the tree of files exposed by
NGINX on all my servers with a single command:
salt-ssh '*' -r 'tree /var/www'
