I believe the problem is that adding portainer to HA makes the installation unsupported/unhealthy.
There used to be an official portainer add-on but it was removed because it allowed users to add containers outside of the authorized supervisor interface. Which the devs do everything they can to prevent because it causes some users to request additional support if it causes any issues.
I don’t know if the un-offucial Portainer add-on has the same result.
But what is the problem of having the installation marked as unsupported?
Unsupported = you can’t file a bug report on Github, it will be closed immediately.
But that is not the problem, if Supervisor detects a portainer docker (not an add-on), your system is marked as unhealthy , and you can’t install updates.
That sounds too drastic indeed. I wonder how Supervisor manages to detect Portainer. Maybe it’s simple to avoid its detection.
Have you searched to see if the docker container that you want to add via Portainer has been made into a Home Assistant add-on? They’re basically the same thing, as I understand it. I’ve found a lot of the ones that I was going to install that way in various people’s add-on repositories. That might be a better approach.
Maybe we are talking about different situations, but in my case this simply is not true.
In my Docker stack I have a Portainer container that happily co-exists next to the normal HA containers, and I can do HA (core) updates as I want. Updates of the other HA containers (e.g. Supervisor) are internally managed and done automatically. Sure my HA install is flagged as unsupported, but apart from an obscure entry in a log somewhere it does not affect me in the least.
Why on earth would running other containers be a problem to HA??
I for instance have a container in my Docker stack that hosts an Apache web server, that I use to upload photos to when triggered by my security cameras. It has nothing (read, nothing) to do with HA, except for sharing the same host, and yet according to your definition it is not allowed.
Everything that Portainer does I can also do from the command line using Docker commands. Portainer is merely a UI interface to make things more visual. Yet I don’t hear you complain about SSH. Or the option to just plug in a keyboard and screen to the host, for that matter.
Sounds like you should be running containered install instead of supervised. Supervisor attempts to manage containers on the system. Of course it’s going to interfere with containers you add. That’s what it does. Either you control your containers using containered install or supervisor does with the supervised install. There’s no happy medium. One or the other.
Not sure I agree with that.
In my Docker stack I have the normal HA containers (homeassistant, hassio_supervisor, hassio_dns, hassio_cli, hassio_observer, hassio_audio, …), as well as others like Portainer, Apache, Grafana, TasmoAdmin etc. Supervisor may have attempted to, but has never managed to interfere with any of these non-HA containers. “Interfering” is therefore not necessarily what it does. Or have to do for that matter, because everything runs quite stable in the years up to now. And that “of course it’s going to interfere” sounds more like a developer choice than an unavoidable technical given. That’s what this WTH is about.
Supervisor manages custom addons (containers) that it’s not aware of. It most certainly looks at all containers in the system. So whether you “agree” with it or not, it’s doing that.
The difference is portainer’s job is identical to supervisor. The job of that particular piece of software is to manage docker on your system. That’s supervisor’s job. If you have two docker managers on your system then your system is unhealthy.
SSH has more jobs then that. In fact you have to jump through some hoops to even get docker access in that addon. It’s mostly about non-docker related things (ha CLI, editing files, making scripts to use in shell commands, etc.) All sorts of miscellaneous tasks. Host access is similar. Yes that has access to docker but it also is where you go to get to the system logs, to reset your password if you forgot, to use the HA CLI, etc. Its intended purpose is ok so it doesn’t inherently mark the system as unhealthy.
Of course as you note you can also use the docker CLI in those places and therefore break the system. Hence why supervisor has a whole bunch of checks. For example, if supervisor sees containers running in docker which were not started by it then it marks the system as unsupported. It does not matter how you ran them (docker CLI, docker compose, portainer, etc.).
The docker cli can also be used to change lots of other things about docker. Anything you change about docker via the docker CLI (or via any other mechanism besides asking Supervisor to do it) is unsupported. Some of them will will immediately mark the system as unsupported/unhealthy, some will completely crash the system since supervisor is unprepared for it, some may appear to be supported simply because it hasn’t caused an issue yet. There’s too many things people can do in docker for the HA team to create checks for so in general checks are added as things come up in issues.
portainer is top tier garbage.
they aboslutely will not do anything to allow you to configure it so that you don’t need to login before using portainer.
I suspect this is to satisify certain investors, since this change occured when it went from opensource to freemium with enterprise tier.
If you’re serious about “orchestrating” anything to do with docker, you’d be using Rancher or ArgoCD/Flux.