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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(agent): add agent support #1828

Merged
merged 70 commits into from May 6, 2018

Conversation

Projects
None yet
6 participants
@deviantony
Copy link
Member

commented Apr 22, 2018

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:

  • Must be deployed on each node of a Swarm cluster
  • Acts as a reverse proxy to the Docker API via the /var/run/docker.sock socket file on each node
  • Exposes an HTTP API (basically a reverse proxy to the Docker API)
  • Uses HTTPS with self-signed certs
  • Requires a digital signature from a Portainer instance or will reject any HTTP requests

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).

Close #461

deviantony added some commits Dec 13, 2017

Merge branch 'develop' into feat461-agent-support
Conflicts:
	app/models/docker/container.js
Merge branch 'develop' into feat461-agent-support
Conflicts:
app/docker/components/datatables/containers-datatable/containersDatatable.html
	app/docker/views/containers/edit/container.html
	app/routes.js
Merge branch 'develop' into feat461-agent-support
Conflicts:
app/docker/components/datatables/containers-datatable/containersDatatable.html
	app/docker/rest/container.js
	app/docker/rest/containerLogs.js
	app/docker/services/containerService.js
	app/docker/views/containers/edit/container.html
	app/docker/views/containers/logs/containerLogsController.js
Merge branch 'develop' into feat461-agent-support
Conflicts:
app/docker/components/datatables/containers-datatable/containersDatatable.html
	app/docker/views/containers/edit/container.html
Merge branch 'develop' into feat461-agent-support
Conflicts:
	app/docker/views/containers/logs/containerLogsController.js
Merge branch 'develop' into feat461-agent-support
Conflicts:
app/docker/components/datatables/containers-datatable/containersDatatable.html
	app/docker/helpers/infoHelper.js
	app/docker/views/dashboard/dashboard.html

deviantony added some commits Apr 25, 2018

Merge branch 'develop' into feat461-agent-support
Conflicts:
	api/bolt/migrate_dbversion8.go
	api/bolt/migrator.go
	api/http/handler/endpoint.go
	app/docker/views/volumes/create/createVolumeController.js
	app/portainer/__module.js
	app/portainer/views/endpoints/endpoints.html
	app/portainer/views/endpoints/endpointsController.js
	app/portainer/views/sidebar/sidebarController.js
@mrmachine

This comment has been minimized.

Copy link

commented May 3, 2018

@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:

Updating service foo-sandbox_gunicorn (id: q84fquyfgmwzvxiomqmjgjkl4)
image foo/foo:staging could not be accessed on a registry to record
its digest. Each node will access foo/foo:staging independently,
possibly leading to different nodes running different
versions of the image.

That matched up with what I saw in portainer earlier, that the image for the service was foo/foo:staging and did not have a sha256 digest. I happened to stumble across something (can't remember where) that said the image was missing, not found or not available, etc.

I manually pulled the image via the image page in Portainer, and my services started up. But got the same error again when deploying another stack.

Googling the error above lead me to moby/moby#34153 which suggests that I need to use --with-registry-auth with docker stack deploy ... Indeed, that did fix it when I redeployed via the command line. Now my service images have a sha256 digest and no error was reported.

I removed my portainer and portainer-agent services and deployed a portainer/portainer (stable) service to test. I removed and re-created my stack. It deployed successfully and my service images have a sha256 digest.

So I think this is a bug in the new portainer:agent-support or agent:develop code. Somehow --with-registry-auth is no longer being used when creating stacks via Portainer.

@deviantony

This comment has been minimized.

Copy link
Member Author

commented May 3, 2018

Thanks for the report, I'll investigate.
EDIT: this has been fixed.

@srbollin

This comment has been minimized.

Copy link

commented May 3, 2018

It appears current running containers are not picked up by the newly installed agent. All new containers are showing up without any issues. It looks way better to manage swarm now. Good job! Will keep you posted if I see any issues.

@srbollin

This comment has been minimized.

Copy link

commented May 4, 2018

FYI. I had just observed that containers on remote workers are not showing up in Cluster visualizer. They are visible in containers section but not in the visualizer.
image

@mrmachine

This comment has been minimized.

Copy link

commented May 4, 2018

@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.

@deviantony

This comment has been minimized.

Copy link
Member Author

commented May 4, 2018

@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 docker run on the CLI), these will not be displayed inside the cluster visualizer.

It appears current running containers are not picked up by the newly installed agent. All new containers are showing up without any issues.

@bollinenisravan are you talking about containers not showing up in the visualizer ?

@srbollin

This comment has been minimized.

Copy link

commented May 4, 2018

@deviantony Yes, I had deployed them manually and expecting the visualizer to show all containers.
My mistake, Thanks for the info, I had deployed few hundred containers through services and they appear perfectly fine through swarm visualizer.

deviantony added some commits May 4, 2018

Merge branch 'develop' into feat461-agent-support
Conflicts:
	app/docker/services/containerService.js

@deviantony deviantony merged commit 2327d69 into develop May 6, 2018

1 check passed

codeclimate Approved by Anthony Lapenna.
Details

@deviantony deviantony deleted the feat461-agent-support branch May 7, 2018

@ibnesayeed

This comment has been minimized.

Copy link
Contributor

commented May 14, 2018

@ncresswell: If someone can suggest an opensource license that allows the code to be open, but not reused for commercial means, please do let us know, we spent $ with lawyers trying to find a license that worked, but none provide any IP protections.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can鈥檛 perform that action at this time.