curl and rest api sound good.
Could it be possible to have an option to have access to the docker socket on a particular host (read-only if there is some security issues) ? (ie -v /var/run/docker.sock:/var/run/docker.sock:ro). It is needed for nginx-proxy.
Yes we make a special option for local add-ons and it need to be activate per addon for user are aware that he run a add-on that can affect negative to hole system.
Why does the nginx-proxy need access to the Docker socket?
To be able to detect containers events (start/stop), read the virtualhost environment variable if it is set on the container and reload nginx with the new configuration if needed.
The use case for the environment variable on home assistant container is to be able to proxyfy it with the nginx proxy container. Another option would be to have the proxy configuration for homeassistant in an option. Perhaps it could also be done for all the containers, which would solve the socket problem. It would not be an automatic proxy container anymore, but it the case of hass.io it is not such a problem
Iām still a bit confused why these things are needed to setup nginx ?
The nginx proxy container whose link I had given is an auto configured proxy. It watch for container events, look for some specific environment variable in the other containers and configure the proxy accordingly. But Iām thinking itās a bit overkill for Hass.io. Iam also thinking that the socket is used to discover exposed ports which is needed for the proxy configuration.
Sorry, I didnāt see that link.
I agree that itās overkill for Hass.io, at least at this point. Weāre still early and trying to figure out the best approach on getting a sustainable ecosystem of add-ons bootstrapped. Our #1 focus is to keep it very simple for the end-user and to some extend to the developers.
I think we should stay on Initial idea of hass.io and work with our addon concept for handing stuff. That give Aware that we not brake stuff on user device
The socket is also used by the configuration generator to find container ip and expose port to set up the reverse proxy, which allow not to publicly expose those ports but only the proxy. For simplicity sake, Iām going to stay with publicly expose ports if socket access is not doable.
EDIT : Iāve done some tests and it seems that docker block networking between containers, even with publicly exposed ports. From the host I can wget the homeassitant index
wget http://X.X.X.X:8123 --2017-05-18 12:22:28-- http://X.X.X.X:8123/ Connecting to X.X.X.X:8123... connected. HTTP request sent, awaiting response... 200 OK Length: 4720 (4.6K) [text/html] Saving to: āindex.htmlā
If I try the same command from a container
wget http://X.X.X.X:8123 Connecting to X.X.X.X:8123 (X.X.X.X:8123) wget: error getting response
What is the needed configuration to be able to access the others container from an addon ?
docker run --rm -ti homeassistant/armhf-addon-nginx_proxy bash
starting version 3.2.1
bash-4.3# wget http://172.17.0.1:8123
Connecting to 172.17.0.1:8123 (172.17.0.1:8123)
index.html
versus
docker run --rm -ti bestlibre/armhf-mopidy bash
starting version 3.2.2
bash-4.3# wget http://172.17.0.1:8123
Connecting to 172.17.0.1:8123 (172.17.0.1:8123)
wget: error getting response
Nothing, 172.17.0.1 should work out of the box, since hass listen to 0.0.0.0
https://github.com/danielperna84/hassio-addons work in same way
Do you have adapt our base images?
No, Iām using FROM %%BASE_IMAGE%% with the script from hassio build repo.
EDIT : After removing the upgrade line from the dockerfile, wget is working from the container.
Which update line? Good to know, can you add a comment to dock about that?
This line :
&& apk upgrade --no-cache --available \
As I was working on a nginx_proxy with multiple vhost support, I was thinking that external port configuration could be a nice improvement. It could be needed if multiple addons publish the same ports and you want to proxify them. I donāt have an immediate need for that, but it could become necessary if the number of addons available increase.
The ability to choose the āhostā network mode would be welcome.
Iām trying to build an add-on for homebridge (which rely on avahi/zeroconf and needs to be on the same network as the userās iPhone) and I donāt think Iāll find a workaround.
If itās already possible, please point me in the right direction (Iām pretty new to Docker).
I will look to it so you can finish you add-on with 0.32
Thanks, it works! Iāll post my homebridge add-on in the forum as soon as I find out why npm fails when pre-building the Docker images.