:card_file_box: Proposal for a Swarm Mode data-model

[linkdd]

Context

In this issue: SaaShup/netbox-docker-agent#177, I mentioned a use-case for Docker Secrets, and the possibility of adding support for Docker Swarm.

In this issue, I describe a proposal for a potential data-model that could be used by the Netbox Docker Agent to setup and manage one or more Swarm clusters via Netbox.

Goals & Non-Goals

This is a very early draft, its purpose is to open the discussion, and in no way it will reflect the final data-model (if the feature is even accepted).

One of the goal is to not make breaking changes to the existing data-model (no 💥). Therefore, I will try to reuse the existing models and provide a way to interpret them in a Swarm context.

This mean that some of the features that Swarm provides (such as replicas) will not be supported by this proposal.

Proposal

1. New Netbox models

An incomplete draft of a diagram is available here: https://dbdiagram.io/d/Netbox-Docker-Plugin-Swarm-Mode-67d8dc8475d75cc844737af2

A swarm is composed of multiple Docker Hosts, some with the manager role, some with the worker role. All of them can run Docker containers, which are now called "services".

1.1 Swarm

The first new model is the Swarm itself. It contains the configuration needed to create or join the Swarm.

It contains 2 Many-To-Many relationships with the existing Host model:

• manager_nodes : for Docker Hosts that should initialize or join the swarm with the manager role
• worker_nodes : for Docker Hosts that should join the swarm with the worker role

Behaviors:

• You cannot add a worker node to a Swarm with no manager nodes
• You cannot add a node to a Swarm that is already in another Swarm
• The first manager node you add to a Swarm will initialize the Swarm, the agent on the corresponding host will populate the Swarm model instance with the result of a docker swarm inspect (a GET /swarm on the Docker Engine API), this includes the join tokens (manager and worker)
• When removing a node from a Swarm, the agent on the corresponding host will leave the Swarm (POST /swarm/leave)

1.2. Secret

Tied to a Swarm (via a foreign key), it holds as base64 the data of a secret to be injected in a service. The data should be "write only" in the Netbox interface, and never returned via API.

1.3. SecretMount

Similar to the existing Mount entity, it binds a Secret to a Container model instance.

2. Existing Netbox models

2.1. Container

If the Host this container is tied to is in a Swarm, then the container should be run as a Swarm service, with only 1 replica, and a constraint to schedule it on the node corresponding to the Docker Host.

Basically, instead of being the equivalent of a docker run, it becomes the equivalent of:

docker service create \
  --constraint "node.id == ${node_id_of_docker_host}" \
  ...

This ensures that volumes tied to a single host can still be mounted on the container.

2.2. Network

We should add a new network driver overlay. If a Docker Host belongs to a Swarm, only overlay networks should be accepted.

Conclusion

This could be a first step to integrate Swarm mode into the Netbox Docker Plugin and Agent.

What do you think?