Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
feat(agent): add agent support #1828
It's finally here !
This PR introduces the ability to connect a Portainer instance to a Portainer agent (closed-source software).
The purpose of the agent is to work around a Docker API limitation. When using the Docker API to manage a Docker environment, the user interactions with specific resources (containers, networks, volumes and images) are limited to these available on the node targeted by the Docker API request.
With the introduction of Docker Swarm mode allowing to create Docker node clusters, some cluster aware resources were added as well: services, tasks, configs and secrets.
This means that you can query for the list of service or inspect a task inside any node on the cluster as long as you're executing the Docker API request on a manager node.
Containers, networks, volumes and images are node specific resources, not cluster aware. If you want to get the list of all the volumes available on the node number 3 inside your cluster, you need to execute the request to query the volumes on that specific node.
The agent purpose aims to solve that issue and make the containers, networks, volumes and images resources cluster aware while keeping the Docker API request format.
This means that you only need to execute one Docker API request to retrieve all the volumes inside your cluster for example.
The final goal is, as always, to bring a better Docker UX when managing Swarm clusters :-)
Some technical details about the agent:
Temporary instructions to use the agent are available here: https://gist.github.com/deviantony/a332e874756af8b7c8e009b9df1a5c8a
These instructions will be part of our official documentation once this PR is merged and the agent is released (only the development build is available at the moment).
@deviantony This is amazing, and thanks very much for all the hard work. I've been testing this, and roped in a few co-workers to test today also. I think we've found a bug.
When I attempt to deploy a stack which needs private images from the default (Docker Cloud/Hub) registry, those services using private images get stuck in a startup loop.
No service logs are available, and no task logs are available. Tasks are typically gone by the time I can even click into them.
A clue came when attempting to deploy the stack via CLI, where I got:
That matched up with what I saw in portainer earlier, that the
I manually pulled the image via the
Googling the error above lead me to moby/moby#34153 which suggests that I need to use
I removed my
So I think this is a bug in the new
@bollinenisravan Are you expecting to see containers, or services in the cluster visualizer? I can see all my services (standalone and created via stacks) across the whole cluster in the visualizer. I can't see standalone containers that are running on each node. These containers in my case are Docker for AWS "system" containers that are started by the OS, and I suspect they the cluster visualiser is only intended to show swarm services.
@bollinenisravan @mrmachine The cluster visualizer will only show the tasks that are available in your cluster, that is, a task is a container created by a service.
If you deployed containers manually inside your cluster (either via the container creation inside Portainer or
@bollinenisravan are you talking about containers not showing up in the visualizer ?
May 6, 2018
1 check passed
referenced this pull request
May 6, 2018
I am not a lawyer, but trying to toss in some of my understanding around it. If the reuse of the code in commercial software is intended to be prohibited then GPL variants might be helpful. Also, there is a more permissive license, BSD+Patent that allows inclusion of patents. Alternatively, one can create a custom license (or modify existing to add necessary clauses) and distribute the software as desired.