-
Notifications
You must be signed in to change notification settings - Fork 8
Description
| Netbox version | Plugin Version | Agent version | Docker API Version |
|---|---|---|---|
| 4.1 | 3.1 | 1.6 | 1.47 |
Context
Let's say you have a service distributed as a Docker image. That service exposes a public HTTP API (for users) and a private HTTP API (for management). The management API can provide endpoints for metric collection, garbage collection, backup/restore, or any other operation that might be needed to manage the service.
You don't want to expose the management API port to the host, for security reasons.
The Docker image contains nothing else than the static binary of your service (most Golang or Rust application can be distributed using FROM scratch in the Dockerfile).
Yet, you still need to run cURL against the management API. So what you do is:
docker run \
--rm -it \
--network my-service-network \
curlimages/curl -X POST http://my-service-container:8080/management/collect-garbage
By running a container in the same network, you can access the management API without exposing the API port. Said container is then automatically removed once it exits.
Some operations require running on a schedule, so what you do is put the above command in a crontab.
Feature Request
The above use case require SSH access to the Docker host, so that the system operator can perform the required commands, and setup the schedules.
Having this information stored in Netbox could greatly help describe and manage the actual infrastructure. The agent could then use this information to carry out the tasks itself, without requiring the operator to ever connect manually to the host via SSH.
Also, let's not forget that managing ACLs at the Netbox level might be simpler than managing user accounts, passwords/RSA keys, password/key rotation, etc... at the SSH level.
Proposal
- a new model
JobTemplateto describe how to run the oneshot container. - a new model
JobScheduleto describe when to automatically run aJobTemplate - a new model
Jobto represent the result of a job execution - a button in the
JobTemplateview to schedule the job immediately
erDiagram
HOST
REGISTRY ||--o{ HOST : "belongs to"
IMAGE ||--o{ HOST : "belongs to"
IMAGE ||--o{ REGISTRY : "was pulled via"
NETWORK ||--o{ HOST : "belongs to"
VOLUME ||--o{ HOST : "belongs to"
JOBT ||--o{ IMAGE : "uses"
JOBT ||--o{ NETWORK : "uses"
JOBT ||--o{ PORT : "exposes"
JOBT ||--o{ VOLUME : "mounts"
JOBT ||--o{ BIND : "mounts"
JOBT ||--o{ DEVICE : "uses"
JOBT["Job Template"] {
string name
string command "Overrides the CMD of the Dockerfile"
keypairs env
keypairs labels
}
JOBS["Job Schedule"] {
string schedule "crontab format"
}
JOBS ||--o{ JOBT : "runs"
JOB["Job Result"] {
boolean pending
timestamp startedAt
timestamp(nullable) completedAt
integer exitCode
text stdout-stderr
}
JOBT ||--|| JOB : "creates on run"
From this data model, 2 scenarios can be implemented:
- the Netbox plugin creates the
Jobinstance, the agent is notified via webhook of theJobinstances - the Netbox plugin does not do anything with the
Jobmodel, the agent is notified via webhook of theJobTemplateandJobScheduleinstances and creates in Netbox theJobinstance
In the scenario 1, the Netbox would be in charge of the automatic scheduling. But in scenario 2, it would be the agent.