Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🗃️ Job & CronJob #176

Open
linkdd opened this issue Dec 20, 2024 · 0 comments
Open

🗃️ Job & CronJob #176

linkdd opened this issue Dec 20, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@linkdd
Copy link
Collaborator

linkdd commented Dec 20, 2024

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 JobTemplate to describe how to run the oneshot container.
  • a new model JobSchedule to describe when to automatically run a JobTemplate
  • a new model Job to represent the result of a job execution
  • a button in the JobTemplate view 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"
Loading

From this data model, 2 scenarios can be implemented:

  1. the Netbox plugin creates the Job instance, the agent is notified via webhook of the Job instances
  2. the Netbox plugin does not do anything with the Job model, the agent is notified via webhook of the JobTemplate and JobSchedule instances and creates in Netbox the Job instance

In the scenario 1, the Netbox would be in charge of the automatic scheduling. But in scenario 2, it would be the agent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant