You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
From this data model, 2 scenarios can be implemented:
the Netbox plugin creates the Job instance, the agent is notified via webhook of the Job instances
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.
The text was updated successfully, but these errors were encountered:
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:
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
JobTemplate
to describe how to run the oneshot container.JobSchedule
to describe when to automatically run aJobTemplate
Job
to represent the result of a job executionJobTemplate
view to schedule the job immediatelyFrom this data model, 2 scenarios can be implemented:
Job
instance, the agent is notified via webhook of theJob
instancesJob
model, the agent is notified via webhook of theJobTemplate
andJobSchedule
instances and creates in Netbox theJob
instanceIn the scenario 1, the Netbox would be in charge of the automatic scheduling. But in scenario 2, it would be the agent.
The text was updated successfully, but these errors were encountered: