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

✨ Support provisioning with docker-compose.yml #1

Open
linkdd opened this issue Apr 25, 2024 · 3 comments
Open

✨ Support provisioning with docker-compose.yml #1

linkdd opened this issue Apr 25, 2024 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@linkdd
Copy link

linkdd commented Apr 25, 2024

Netbox version Plugin Version Agent version Docker API Version
3.7.* 1.6.1 - -

Actual Behavior

In order to provision a complete stack, one has to create manually the registries, images, volumes, networks, and containers, 1 by 1.

This is a bit tedious, and error-prone (you could go too fast and create the container when the image has not been pulled yet 😱 ).

This is usually orchestrated via an Ansible playbook, which will make the API calls to Netbox, and has to poll the journal entries to determine when i can move on to the next step, or fail.

Such Ansible playbooks are tedious to write, maintain and debug.

Desired Behavior

A possible solution would be to support a subset of the docker-compose.yml file format.

An API endpoint would expect via POST:

  • the compose file (as YAML or JSON) as the request body
  • the docker host id as either URL Path parameter, or Query String parameter

The endpoint handler would have to:

  • create or update the Netbox entities
  • poll their journal entries to determine when to move to the next step

The "create or update" part is essential in case of failure so that already successful operations are a "No Op" in the retry.

I considered relying on Django transactions, but that would not work, as the entities would not be committed until the transaction is done, which would not trigger the Docker Agent until the end, which would not allow us to poll journal entries for the required orchestration.


To be defined:

  • the docker-compose.yml file format does not support specifying registry credentials, should we extend the file format to include them or expect registries to be already present in the Netbox?
  • how do we infer the correct registry in Netbox to use from the image field of the compose file?
@linkdd linkdd added the enhancement New feature or request label Apr 25, 2024
@linkdd
Copy link
Author

linkdd commented Apr 25, 2024

How do we infer the correct registry to use in Netbox from the image field of the compose file

https://docs.docker.com/reference/cli/docker/image/tag/#extended-description

An image tag is [HOST[:PORT]/]PATH.

When HOST is not present, it defaults to the public registry registry-1.docker.io with docker.io being the canonical name.

In Netbox, dockerhub has the following server address:

https://registry.hub.docker.com/v2

So, that would be a special case, is it the only one?

When HOST (and PORT) is present, the registry server address is:

http(s)://HOST[:PORT]/v2

For example:

Image Registry Server Address
myregistry:8080/myimage:latest https://myregistry:8080/v2/
myimage:latest https://registry.hub.docker.com/v2/
docker.io/myimage:latest https://registry.hub.docker.com/v2/

Is that correct?

@lvenier
Copy link

lvenier commented Apr 26, 2024

I would not consider registries for this feature in the initial version.

I would first modify the image entity in the plugin to make the registry as optional and defaulting a "defaulted registry" to it within the plugin through the API.
Then you would be able to implement this feature with the defaulted registry in the first version.

@linkdd
Copy link
Author

linkdd commented Apr 29, 2024

Bookmark:

Today, I discovered https://schemastore.org

The docker-compose.yml file format spec is hosted on this website (via Github) and can be found here: https://raw.githubusercontent.com/compose-spec/compose-spec/master/schema/compose-spec.json

We can use this in the new API endpoint to validate the received document reliably.

@lvenier lvenier transferred this issue from SaaShup/netbox-docker-plugin Jun 27, 2024
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

3 participants