Skip to content

A basic Docker container manager with ipvs, systemd and CouchDb.

License

Notifications You must be signed in to change notification settings

carlanton/service-manager

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

20 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

service-manager

A basic Docker container manager with ipvs, systemd and CouchDb.

Amazing features:

  • rolling deployment of containers
  • systemd service dependencies
  • versioned service definition with CouchDb
  • simple implementation with bash

Requirements:

  • systemd
  • ipvsadm + ip_vs kernel module (available on CoreOS)
  • CouchDb
  • bash, jq, curl, ncat (also available on CoreOS)

What this is

The goal of service-manager is to run Docker containers in a way that allows rolling deployment without down-time, with zero dependencies (okay, this thing depends on CouchDb, but it can easily be re-implemented to use files on disk instead). To make this possible it uses a simple service abstraction on top of containers.

There are many other solutions for this problem (swarm, kubernetes, consul+haproxy, ...), but most of them are rather complex to operate, especially if you only have a single server.

However, if you aren't already using CouchDb, you will probably be happier with Docker Swarm :)

How it's supposed to work

The service manager is based on multi-instance systemd unit files. For a service there are two types of systemd instances: the manager instance and the runner instance.

The manager instance (my-service@manager) periodically fetches the latest service definition from CouchDb and starts a systemd instance with the document revision as instance id, for example my-service@1-62d4023616ab1e7921f74f650aab51e1. If the latest instance is already running, it will stop all other instances. The manager also creates an ipvs "virtual service" on the service address. The service address should be used to access the service.

The service instance will start a Docker container based on the service definition document, wait for it to be ready for traffic, and add it to the load balancer. When the container exits, it will be removed from the load balancer and the service stops.

Service definition

Configuration documents must be available on $COUCHDB_URL/$service_id and may look like this:

{
  "_id": "my-service",
  "_rev": "[ created by CouchDb]",
  "port": 80,
  "health_check": "http",
  "environment": {
    "THING": "xyz"
  },
  "volumes": [
    "/some-mount:/some-mount:ro"
  ],
  "nginx:latest"
}

Example systemd unit

In this example, 172.18.0.1:7001 is the service address. The service address must be unique for each service and the IP address must be a real address on the host. For local-only services it is wise to use the IP address of docker0 since other containers running in bridge mode may then access the service.

[Unit]
Description=My Service

Requires=docker.service
Wants=couchdb.service
After=docker.service couchdb.service

[Service]
Environment=COUCHDB_URL=https://127.0.0.1:5984/services
ExecStart=/opt/service-manager/launch %p %i 172.18.0.1:7001
Type=notify
TimeoutSec=infinity

[Install]
WantedBy=multi-user.target

If you want your service to depend on other service-manager-based services, you must depend on the manager instance (Wants=another-service@manager) otherwise things will break.

System unit file reference: https://www.freedesktop.org/software/systemd/man/systemd.unit.html

Example usage

  • systemctl start my-service@manager - start the manager (which in turn will start instances)

  • systemctl stop my-service@manager - stop the manager (which in turn will stop all running instances)

  • systemctl status 'my-service@* - check the status on manager and all instances.

  • ipvsadm -L -n - check the current ipvs configuration

About

A basic Docker container manager with ipvs, systemd and CouchDb.

Topics

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published