Are groups needed even for just one container ?

[accforgithubtest]

Hello there, great work on this project, looking forward to using this.

I have a few questions, which I hope you might also find useful to add to the readme, or as a separate FAQ section for clarity on how Lazytainer works -

1. Do I have to define this for each and every container even if there is no "group" of containers and just one independent container (for e.g portainer) ? It would be nice if this is optional and only needed when groups of containers need to brought up/down together ?

- "lazytainer.group.<yourGroupName>.<property>=value"

I was thinking if I could create just one default group for single containers and map them all to the same group.However would that mean all the unrelated single containers will come up together when I want to use just one of them ?
Is there a better way of doing this ?

2. In cases where multiple containers are assigned to the same group - is there any way for me to control the ordering in which the containers are brought up ? For example lets say i have [ database and app ] containers assigned to group app1 - how can I ensure that the database container comes up first before the app container ? Also, will Lazytainer take care of waiting for the db container to be up first before starting up the app container ?

3. Related but slightly different question - Does Lazytainer automatically look for the 'depends_on' in docker compose and ensure that the depends_on container is up ? And if its not then Lazytaner will bring up the dependency first before the app container ?

4. Would it possible for you to add a diagram of how Lazytainer works, what the primary configuration that drive its behavior, how it checks up/down status, how it decides to bring up the containers along with ordering /etc details ? A flowchart / sequence diagram showing the internal flow of logic will be a great resource for learning about the project.

5. For a use-case where Lazytainer is used in combination with status monitors like UptimeKuma, etc. - Is there a way to tell Lazytainer to not spin up any containers for requests from specific containers / ipaddresses / etc ? Otherwise just the requests from UptimeKuma will keep the containers on all the time. So a way to say igonore requests from specific applications from starting up a container will be very useful.

As a newcomer to Lazytainer, I think it may be useful to add another detailed example file with multiple containers showing examples of how to configure these ordering / dependencies among containers, along with combination of app+db to be up/down together, and few other single containers that can be up/down independently.

@vmorganp - Appreciate your replies / suggestions in advance !

[vmorganp]

Do I have to define this for each and every container even if there is no "group" of containers

For now, yes. I'll look into adding a sort of "default" so that this can be handled automatically without the syntax overhead

would that mean all the unrelated single containers will come up together when I want to use just one of them ?

yes.

For example lets say i have [ database and app ] containers assigned to group app1 - how can I ensure that the database container comes up first before the app container ? [...] Does Lazytainer automatically look for the 'depends_on' in docker compose

I actually don't know. I'd be curious to see how that is handled. If you get to test it, please let me know, otherwise I'll test it eventually.

Would it possible for you to add a diagram of how Lazytainer works

Probably.

Is there a way to tell Lazytainer to not spin up any containers for requests from specific containers / ipaddresses / etc?

I don't think so. Someone smarter than me could probably hack it, but it require a ton of extra code compared to what is there currently. If you want to create a PR for it, I'd be happy to approve it, but it's unlikely I'll write it myself.

I think it may be useful to add another detailed example file with multiple containers showing examples of how to configure these ordering / dependencies among containers, along with combination of app+db to be up/down together,

I agree. Once we determine what this behavior looks like I'd be happy to go in and add an example that uses it.

[accforgithubtest]

Thanks for the reply @vmorganp ! Will give Lazytainer a spin over the coming weeks and see how I go.

[accforgithubtest]

another question @vmorganp - based on this reddit link

This implies that you need to run one instance of lazytainer for each container listening to a port, correct?

Is this still the case ? From the recent examples, I assume one Lazytainer container can be used to up/down multiple different containers, as long as there is a group based separation / relation configured ?

[vmorganp]

another question @vmorganp - based on this reddit link

This implies that you need to run one instance of lazytainer for each container listening to a port, correct?

Is this still the case ? From the recent examples, I assume one Lazytainer container can be used to up/down multiple different containers, as long as there is a group based separation / relation configured ?

Correct.

[vmorganp]

I just did a quick experiment with the depends_on attribute, and it looks like if you had an app and a database container, they would come up in a healthy way, assuming same group and proper depends ons and whatnot. I'll see about getting a documented example. Is there a particular service you would like for me to do that with?

[accforgithubtest]

Thank you for checking it out ! Its great news that its working in a healthy way.

For examples - I was asking this question with mariadb and n8n in mind. Though any combination of app and db where db comes up first on wake up should be following the same.

Edit - Once I manage to get my below example working, I can help contribute with the examples with a simple PR.

[accforgithubtest]

I am trying to get started with a simple example but it looks like I am missing something either network related or ports related, as I am unable to get the requests to reach Lazytainer container.

I do notice in lazytainer logs that the labels are getting picked up, and lazytainer is also able to stop the container after the configured time (lazytainer logs below).

I have also managed to get it working with containernursery - able to reach the dozzle application ui.

Where as with Lazytainer - The request is failing when caddy seem to be attempting to send to lazytainer.

Am I missing something with ports / networking ? Keen to get this working with Lazytainer, so any suggestions is appreciated.

The error I see in caddy logs is -

ERR ts=1694201011.88857 logger=http.log.error msg=dial tcp 10.5.0.109:80: connect: connection refused request={"remote_ip":"192.168.1.10","remote_port":"54120","client_ip":"192.168.1.10","proto":"HTTP/2.0","method":"GET","host":"logs.local.host","uri":"/","headers":{"Accept-Language":["en-US,en;q=0.5"],"Sec-Ch-Ua-Mobile":["?0"],"Te":["trailers"],"User-Agent":["Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36 Edg/114.0.1788.0  uacq"],"Upgrade-Insecure-Requests":["1"],"Sec-Fetch-Site":["same-site"],"Sec-Fetch-User":["?1"],"Sec-Ch-Ua":["\"Edge\";v=\"114\", \"Chromium\";v=\"114\", \"Not=A?Brand\";v=\"24\""],"If-None-Match":["W/\"c10-rb1ovmNRTTLgreSYuaLTCwfLARY\""],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8"],"Dnt":["1"],"Sec-Fetch-Dest":["document"],"Sec-Fetch-Mode":["navigate"],"Sec-Ch-Ua-Platform":["\"macOS\""],"Accept-Encoding":["gzip, deflate, br"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"homer.local.host"}} duration=0.001106202 status=502 err_id=jy7a5qmir err_trace=reverseproxy.statusError (reverseproxy.go:1248)

The set up is -

browser -> caddy (self signed certs) -> lazytainer -> dozzle

OR

browser -> caddy (self signed certs) -> containernursery -> dozzle

Here is my docker compose -

version: "3.4"

services:

  caddy:
    image: lucaslorentz/caddy-docker-proxy:latest
    container_name: caddy
    restart: always
    environment:
      - CADDY_INGRESS_NETWORKS=default
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /certs:/certs
    ports:
      - 80:80
      - 443:443
      - 443:443/udp

  lazytainer:
    image: ghcr.io/vmorganp/lazytainer:latest
    container_name: lazytainer
    restart: always
    environment:
      - VERBOSE=false
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    ports:
      - 80
    labels:
      caddy: lazytainer.local.host
      caddy.reverse_proxy: "lazytainer"
      caddy.tls: "/certs/cert.pem /certs/certkey.pem"
      lazytainer.group.dozzle.ports: 8080
      lazytainer.group.dozzle.inactiveTimeout: 180
      lazytainer.group.dozzle.minPacketThreshold: 1
  
  containernursery:
    image: ghcr.io/itsecholot/containernursery:latest
    container_name: containernursery
    restart: always
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ${pwd}/cn/:/usr/src/app/config
    ports:
      - 80
    labels:
      caddy: containernursery.local.host
      caddy.reverse_proxy: "containernursery"
      caddy.tls: "/certs/cert.pem /certs/certkey.pem"
    depends_on:
      - caddy

  dozzle:
    image: amir20/dozzle:latest
    container_name: dozzle
    restart: always
    environment:
      - DOZZLE_NO_ANALYTICS=true
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    ports:
      - 8080
    labels:
      caddy: logs.local.host
      caddy.reverse_proxy: "lazytainer"
      # caddy.reverse_proxy: "containernursery"
      caddy.tls: "/certs/cert.pem /certs/certkey.pem"
      lazytainer.group: dozzle

Lazytainer logs -

30 / 180 seconds without an active client or sufficient traffic on running container
60 / 180 seconds without an active client or sufficient traffic on running container
90 / 180 seconds without an active client or sufficient traffic on running container
120 / 180 seconds without an active client or sufficient traffic on running container
150 / 180 seconds without an active client or sufficient traffic on running container
180 / 180 seconds without an active client or sufficient traffic on running container
INFO: 2023/09/08 19:58:15 group.go:90: stopped container  /dozzle

I run with docker compose up (not in swarm mode).

[vmorganp]

Container nursery is currently integrating with caddy, with caddy acting as your proxy.
Lazytainer is it's own proxy (doesn't currently integrate with others, like traefik, caddy, nginx, etc...)

This isn't working because your network_mode on your target container (dozzle) should be set to service:lazytainer

There might be some chain where you can put lazytainer behind a reverse proxy, but I don't know how to do it this second

[accforgithubtest]

thanks for the reply @vmorganp - that makes so much sense now, after spending a bunch of time thinking something was wrong with my compose file.

Are there any plans to make lazytainer work with other proxies in future ?
That would allow for utilizing all the benefits of having a reverse proxy (for what a reverse proxy is good at) and then allow lazytainer as a "resource manager" of sorts to help keep system resource utilization to lower levels.

[vmorganp]

Any plans to make lazytainer work with other proxies

unlikely that I'll write it, but I'd approve a PR