sm-farm-manager is one of the most important Server Farmer management extensions, providing actual farm management scripts. Some scripts rely on other extension, mostly sm-backup-collector and sf-keys.
docker-rescan.sh - scans the whole farm for hosts with installed Docker
console.sh - either connects to given host in console mode (with enabled terminal features), or executes given command on given host
run.sh - executes given local script on given remote host (by first copying into the same place in filesystem and then executing)
execute.sh - executes given command on many hosts in the farm; user can select, which ones exactly:
-ph- physical servers-vm- virtual servers-cl- cloud instances-lxc- LXC containers-dck- Docker containers-ct- other containers-wks- workstations-prb- problematic hosts
The difference between "virtual" and "cloud" servers is the assumption, that for virtual servers, you also manage the underlying physical server. Technically, there are no differences - it's just for planning operations that require downtime.
Some real-life servers cause more problems than others. For example, servers running critical production, single-instance services, with long and/or problematic service restarts. Or with outdated operating system version, without available updates, but still needed to be run because of some particular software. Or with any other reason, for which every single operation on them (software upgrade, configuration change etc.) must be carefully planned.
You can move such hosts to "problematic" group and avoid executing normal daily tasks on them with execute.sh script.
Server Farmer was primarily written to work on "classic" physical and virtual Linux instances. Now it also fully supports LXC containers, with only a few differences in backup scheme (see sf-backup repository documentation for details).
Docker is supported in quite different way than LXC. Docker containers are treated as "passive" containers, which means that installing Server Farmer inside such containers is not supported and in most cases doesn't have any practical sense.
However, execute.sh script allows executing commands inside these containers - directly from farm manager, through parent host of each such container.
This extensions maintains a "database" consisting of a few *.hosts files located in ~/.serverfarmer/inventory directory. These files can be divided into 2 groups:
-
workstation.hosts,physical.hosts,virtual.hosts,cloud.hosts,container.hosts,lxc.hosts,problematic.hosts- lists of active hosts, which can be directly managed. -
docker.hosts- Docker hosts, on whichexecute.shshould execute commands in-dckmode (these hosts must be also included in the first group, as managed hosts).
*.hosts files are simply text files with list of hostnames, possibly including port numbers and project/customer tags (see below), one per line:
hostname1.internal:22:ourcompany:timeout
hostname2.internal::ourcompany
otherserver.domain.com:3322:customer1
Empty lines and lines starting with # character are ignored, so you can use them to better organize the contents, add comments etc.
Fields:
- hostname
- port (optional, default 22)
- tag (eg. client name)
- timeout in seconds (optional, default 60, used only by
execute.sh, ignored for Docker)
console.sh, run.sh and execute.sh scripts look for ~/.serverfarmer/hooks/ssh-accounting.sh script and execute it if exists, each time you execute command using them: before and after actual command execution.
Hook script doesn't receive the executed command or hostname, instead it only receives start or stop arguments, and the project/customer tag (ourcompany or customer1 in the above example), on which current command is executed.
Using this ~/.serverfarmer/hooks/ssh-accounting.sh script you can gather some simple statistics: how many commands are executed for each project or customer, on how many servers, how long they last etc.