Container name requirements (or bug not restarting correct container)

[patricknelson]

I had some confusion initially getting this setup since I had multiple containers and, at first, it worked, but after adding a new container (or restarting) suddenly it stopped working.

Of my 3 containers, I already had an explicit relationship defined between livereload and my other container to restart (e.g. proxy in my case) by giving them both container_name’s. However, even though I explicitly defined proxy as the container to restart in RELOAD_CONTAINER, the wrong container was getting restarted (e.g. php in this case). It didn’t start respecting my explicit RELOAD_CONTAINER=proxy until after I also provided a container_name to the php container as well.

So to me this is either:

1. A bug and RELOAD_CONTAINER isn’t respected until all containers have names or
2. Requires a little more documentation indicating that all containers must have names before it can work properly.

[apogiatzis]

Thanks for reporting this! Sounds like a bug to me, I will try to look into it.

Maybe alternatively you can try RELOAD_LABEL instead if RELOAD_CONTAINER is not behaving properly.

[patricknelson]

Ok great, I'll try that out.

Another great alternative would maybe be to use labels themselves as a way to flag one or multiple containers as candidates. So, instead of assertively saying from the livereloader perspective "Reload [x] container" you could on the container side flag it as being reloadable, e.g.

  my-service:
    image: nginx:latest
    volumes:
      - some:volume
    labels:
      # Array syntax (with empty value)
      - "com.livereloader.reloadable"
      # Dictionary syntax
      com.livereloader.reloadable: true

[patricknelson]

p.s. This has become indispensable for me right now, since it allows me to dig into the depths of a complex NGINX configuration without having to constantly manually restart the server and have built upon it with even more complex dynamic capabilities at startup via envsubst and rsync in my entrypoint (rsync only when in development environment).

So it's great to have a solution that, at a low level, is capable of restarting the entire container external to the container itself (i.e. docker-compose) instead of writing an esoteric reload/restart service that (at a low level) would vary from production in your entrypoint, similar to a lot of the other solutions that I've seen written about for node.js using things like nodemon and etc.

So, thanks for your pioneering work on this! 👍