Eggmonster is a configuration focused deployment tool.
The Eggmonster Server
Eggmonster runs a server that is responsible for managing the configuration. The server versions changes to the configuration and understand the format of the config in order to start/stop/kill the applications defined in the config. The config format is a YAML file.
In addition to the main eggmonster server, there are two other services that are run. The eggmonster cheeseshop and emi server.
The cheeseshop provides a repository for eggmonster to resolve dependencies against using setuptools. The emi server is how the running applications keep a connection open to the main eggmonster server. The main server accepts commands and uses the config in order to triggers events for the emi server. The emi server then sends the commands and updated config to the respective processes running on the cluster nodes.
A client for the eggmonster server must run the monster_launchd client. This client connects to the eggmonster (em) server and sends its hostname. The em server then decides whether or not it has an application defined in the config and sends the launchd process instructions on what application to run. The launchd process then launches an emi process which makes a connection directly to the emi server. In this way the moster server is able to report what configured processes are up and running.
The emi process when starting up an application uses setuptools to find the entry point and handle dependencies. The entry point defines the function to call that will run the server and provides any configuration details to the application. It also manually finds and tries to resolve any dependencies via the defined em cheeseshop. When it installs the dependencies, it uses the -m or multiversion flag in order to allow multiple versions of the library to be installed.
The em command
Eggmonster provides a command line tool called em that communicates with the eggmonster server. It allows updating the config and sending signals (term, kill) to the specific processes. The command utilizes a grep friendly syntax. For example:
em status | grep foo.service | em term
This would send a term signal to any service running with "foo.service" in the status. For example here are the steps to update the config and push out a new release.
em edit -n # this opens up $EDITOR with the config # make changes, save and close em status # this prints the list of services running with their # uptime. Services marked with a [*] mean the config changed and the # changes have not been applied em status | grep foo | grep [*] | em restart --delay=20 --killafter=30
This last command searches for "foo" which is most likely the application name and then greps for "[*]" which indicates the current config hasn't been applied. The em restart command is then called signifying that the selected processes be restarted one after another, sending a kill signal 30 seconds after term signal was sent if the process was still up. The "--delay" flag says to make sure the process is up for 20 seconds before moving on to the next one.