Thinking about every implementation I found until now and trying to think in a way to not add any overhead in the apps I look to these implementations:

• Lazytainer

  • based on the traffic (bad)
  • only uses socks (good)
  • don't support user interface (bad)
  • don't need to change the proxy (good)
  • low resources consuption (good)
  • no overhead added to traffic (good)

• sablier

  • based on the access (good)
  • only uses socks (good)
  • support user interface (good)
  • need to change the proxy (bad)
  • low resources consuption (good)
  • overhead added to traffic (bad)

• ContainerNursery

  • based on the access (good)
  • only uses socks (good)
  • support user interface (good)
  • need small change in proxy (ok)
  • low resources consuption (good)
  • overhead added to traffic (bad)

• expected solution

  • based on the access (good)
  • only uses socks (good)
  • support user interface (good)
  • minimal change in proxy (good)
  • low resources consuption (good)
  • no overhead added to traffic (good)

For me the best solution will be:

This is what every service want to do.

The main problem is how is made, the best solution need to.

• Change the proxy pass on-the-fly to point to the service using the reverse proxy API
  • No overhead by plugin or a fake reverse proxy in the front
• Check using the sock
  • Skip this part because works great
• After put to Sleep
  • Change the proxy pass on-the-fly again to point to the frontend
  • The frontend when accessed call the API of service to wake the container
  • After wake happens: Change the proxy pass on-the-fly to point to the service

All this means:

• Have a API to start the container to the consumed by frontend
  • https://sleep.example.com/api/wake/CONTAINER
  • https://sleep.example.com/api/read/CONTAINER

The container have a public port for frontend that call the API in client-side and the server-side uses the sock to start the container and a the same container have a service to stop the container based on access, but how we know if have access without put a service behind the service? Based on traffic route used to redirect the traffic of a container by another

Step-by-step:

1. Start point

services:
  proxy:
    image: caddy
    ports:
      - "80:80"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
    labels:
      - sablier.enable=true
      - sablier.proxy=caddy
      - ... more configuration
      - sablier.group.whoami=true

  whoami:
    image: containous/whoami
    expose:
      - 80
    labels:
      - sablier.enable=true
      - sablier.group.whoami=true
      - sablier.group.domain=whoami.example.com

  sablier:
    image: acouvreur/sablier
    expose:
      - 80
    environment:
      - PROVIDER_NAME=docker
    volumes:
      - '/var/run/docker.sock:/var/run/docker.sock'

whoami.example.com {
    reverse_proxy whoami:80
}
sleep.example.com {
    reverse_proxy sablier:80
}

2. After no access for some time, the service change the reverse proxy and reload

whoami.example.com {
    reverse_proxy sablier:80
}

3. User acess the whoami.example.com and open the wait page, the client-side call sleep.example.com/api/wake/whoami.example.com based on label configured.

4. Service change the service again to original service after the container wake:

whoami.example.com {
    reverse_proxy whoami:80
}

5. Client-side receive the return from api that service was changed with success and the page refresh.

The main point is make the provider and implementation that change the reverse proxy without add no overhead. The only complexity is make sure the proxy is changed in the fancy way that not impact other services.