TmuxConnector
Manage multiple servers using SSH and tmux.
Features:
- work on multiple sessions in parallel
- sessions can be persisted (actually recreated) after computer restarts
- they are lost only if you delete them explicitly
- complex layouts customizable for different server groups
- issuing commands to all servers or just a selected subgroups
Quick tease
tcon start staging_config.yml -n staging -p 'all staging servers'
- crate a session (name: 'staging', description: 'all staging servers') with complex layout structure (multiple windows with (potentially) different pane layouts)
- connect to all servers
- attach to tmux session
tcon send staging 'sudo su'
- send to all servers (in 'staging' session)
sudo sucommand
tcon send staging 'top' -g 'lbs'
- send
topcommand to all loadbalancing nodes in 'staging' session
tcon send production 'tail -f /var/log/syslog' -f 'rdb'
- send
tail -f /var/log/syslogcommand to all database nodes in 'production' session
tcon send production -f 'rdb' 'C-c'
- send
Ctrl-Cto all database nodes in 'production' session (if executed after thetail -f /var/log/syslogcommand, it will exit thetail -fcommand
tcon resume s#3
- resume (recreate) 's#3' session, even after computer restart
CLI description
CLI uses docopt to parse command line options.
tcon enables establishing connections (ssh) to multiple servers and executing
commands on those servers. The sessions can be persisted (actually recreated)
even after computer restarts. Complex sessions with different layouts for
different kinds of servers can be easily created.
Usage:
tcon start <config-file> [--ssh-config=<file>]
[--session-name=<name>] [--purpose=<description>]
tcon resume <session-name>
tcon delete (<session-name> | --all)
tcon list
tcon send <session-name> (<command> | --command-file=<file>)
[--server-filter=<regex>] [--group-filter=<regex>]
[--filter=<regex>] [--verbose]
tcon --help
tcon --version
Options:
<config-file> Path to configuration file. Configuration file
describes how new session is started. YAML format.
<session-name> Name that identifies the session. Must be unique.
<command> Command to be executed on remote server[s].
<regex> String that represents valid Ruby regex.
-s --ssh-config=file Path to ssh config file [default: ~/.ssh/config].
-n --session-name=name Name of the session to be used in the tcon command.
-p --purpose=description Description of session's purpose.
--all Delete all existing sessions.
-f --server-filter=regex Filter to select a subset of the servers via
host names.
-g --group-filter=regex Filter to select a subset of the servers via
group membership.
-r --filter=regex Filter to select a subset of the servers via
host names or group membership.
Combines --server-filter and --group-filter.
-c --command-file=file File containing the list of commands to be
executed on remote server[s].
-v --verbose Report how many servers were affected by the send
command.
-h --help Show this screen.
--version Show version.
Configuration
To use this gem, you need to create a configuration file. This shouldn't be that hard and here I provide exhaustive details about configuration files.
(If there is enough interest, in future versions there could be a special command to simplify generation of configuration files. To accelerate the process, open an issue or drop me an email: << username >>@gmail.com)
Let's get to it.
The configuration file is in YAML format.
Let's say the following ssh config file that will be used:
KeepAlive yes
ServerAliveInterval 2
StrictHostKeyChecking no
UserKnownHostsFile=/dev/null
Host staging.cache-staging-1
Hostname ec2-111-42-111-42.eu-west-1.compute.amazonaws.com
Port 4242
IdentityFile /Users/ikusalic/.ssh/some-pem-file.pem
User ubuntu
Host dev.database-staging-1
<< omitted >>
Host dev.database-staging-3
<< omitted >>
Host dev.mongodb-single-replica-1
<< omitted >>
Host dev.haproxy-staging-72
<< omitted >>
Host dev.haproxy-staging-73
<< omitted >>
Host dev.nginx-staging-11
<< omitted >>
Host dev.nginx-staging-15
<< omitted >>
Host dev.node-staging-127
<< omitted >>
Host dev.node-staging-129
<< omitted >>
Host dev.node-staging-130
<< omitted >>
Host dev.node-staging-135
<< omitted >>
<< ... >>
Every configuration file needs to define at least the folowing fields: 'regex', 'regex-parts-to', 'group-by' and 'sort-by'
Here's a minimal configuration file that could be used:
regex: !ruby-regexp '^(\w+)\.(\w+)-([\w-]+)-(\d+)$'
regex-parts-to:
group-by: [1]
sort-by: [3]
And here's a 'real world' configuration file that shows of all the available options and could be use with previous ssh config file:
regex: !ruby-regexp '^(\w+)\.(\w+)-([\w-]+)-(\d+)$'
reject-regex: !ruby-regexp '-(nodes|to_ignore)-'
regex-parts-to:
group-by: [1]
sort-by: [3]
name:
regex-ignore-parts: [0, 2]
separator: '-'
prefix: 'dev--'
merge-groups:
misc: ['cache', 'db', 'mongodb']
lbs: ['haproxy', 'nginx']
layout:
default:
custom:
max-horizontal: 3
max-vertical: 3
panes-flow: vertical
group-layouts:
misc:
tmux:
layout: tiled
max-panes: 6
node:
tmux:
layout: tiled
(required) 'regex' field is the most important field. Some other field reference this one. It provides a rule on how to parse host names from ssh config file. The regex should be a valid ruby regex. (If you're not familiar with ruby regexes, consider visiting rubulator and playing around.)
All host whose host names fail the regex will be ignored.
For example if ssh config file include the following host definition:
Host dev.database-staging-1
and the following regex is used:
regex: !ruby-regexp '^(\w+)\.(\w+)-([\w-]+)-(\d+)$'
the name 'dev.database-staging-1' will be broken to 4 groups:
'dev', 'database', 'staging', 1
This regex is used for all the host names and should be designed accordingly.
The idea behind the regex is to enable sorting and grouping of hosts from regex groups extracted from host names. Those groups are used to crate meaningful layouts. I know, sounds more complex than it really is...
In (required) 'regex-parts-to' section, fields 'group-by' and 'sort-by' are referencing before mentioned 'regex' field. As their names suggest, they decide which servers constitute a group (and share layout and potentially commands) and how to sort serves in a group. Both fields can reference more than one regex group.
In the above example, for 'dev.database-staging-1' host name, a group to which the host belongs would be 2nd group, which is: 'database'.
(optional) 'reject-regex' field is used to ignore some hosts while starting a session.
(optional) field 'name' and it's (optional) subfields 'regex-ignore-parts', 'separator' and 'prefix' decide how to name the servers. If those fields are omitted, ssh host name is used instead.
Filed 'regex-ignore-parts' potentially removes some regex groups from name, 'separator' is used to separate left-over groups and it's possible to specify 'prefix' for the name.
(optional) field 'merge-groups' contains groups that should be merged (for layout purposes) together. This can be used to group a few servers that are unique in type or small in numbers. E.g. grouping different DB servers.
lbs: ['haproxy', 'nginx']
In this example two different kinds of loadbalancers are grouped together.
Note that the servers from merge groups can later be referenced with both original and merge-group name.
Finally, what's left is the (optional) layout definition:
There are 2 main ways to specify a layout for a (merge-)group:
- with option tmux, built-in tmux layouts: even-horizontal, even-vertical,
main-horizontal, main-vertical or tiled
- defines a tmux layout, option 'layout' and (optionally) maximum number of panes in one window, 'max-panes', default 9
- with option custom, custom tiled layout
- defines filed layout with maximal size of rows, 'max-vertical', and columns, 'max-vertical'. There is also an (optional) option 'panes-flow' to specify if the panes flow from left to right (horizontal - default) or from top to bottom (vertical)
If you don't specify layout, 'tmux tiled' will be used
The layouts are applied individually to any merge group and to any normal (regex) group not belonging to some merge group. If there are more servers in a group then layout allows on a single window, next window for that group is added. Servers from different groups never share a window.
Requirements
To be able to use the gem you should have ruby 1.9+ and tmux installed on a *nix (Mac OS X, Linux, ...) machine. (Windows: here be dragons)
Interaction with tmux is done via bash commands.
Minimal familiarity with tmux is required. For a start, switching between panes/windows and attaching/detaching is enough:
- detach session:
<prefix>d - attach session:
tmux attach -t <session-name> - navigate windows (next/previous):
<prefix>n&<prefix>p - navigate panes:
<prefix><arrow>
(prefix is by default C-b)
Installation
The gem provides CLI and currently it is not intended to be used as part of bigger ruby apps.
Install it with:
$ gem install tmux-connector
Installing tmux
If tmux isn't already installed, install it using your favorite mathod, e.g.:
- Linux:
apt-get install tmux - Mac OS X:
brew install tmux
Tips
SSH config files
If you plan on specifying separate ssh config file when starting session, consider adding the following lines on top:
StrictHostKeyChecking no
UserKnownHostsFile=/dev/null
That way you won't have problems with known hosts changes or with infinite questions to approve new hosts. Do this only if you understand security consequences and are sure that it is safe to do so.
Tmux configuration
Since gem uses tmux, consider configuring it for your purposes. E.g. I'm a Vim user, and so configure tmux to use Vim-like bindings to switch panes. For more information, check my dotfiles.
Contributing
- Fork it
- Create your feature branch (
git checkout -b my-new-feature) - Commit your changes (
git commit -am 'Add some feature') - Push to the branch (
git push origin my-new-feature) - Create new Pull Request
Or just mail me, mail: << username >>@gmail.com
This is my first real gem, so all your comments are more than welcome. I'd really appreciate ruby code improvements/refactoring comments or usability comments (all other are welcome too). Just drop me a line. :)
Comments, ideas or if you feel like chatting
Take a look at TODO.md file (in the repository) for ideas about additional
features in new versions.
<< username >>@gmail.com
I'd be happy to hear from you.