acouvreur / traefik-ondemand-service

Traefik ondemand service for the traefik ondemand plugin

Home Page:https://pilot.traefik.io/plugins/605afbdba5f67ab9a1b0e53a/containers-on-demand

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

OnDemand service for docker CE (without swarm)

jo-me opened this issue ยท comments

Hi,

I was intrigued by your idea to scale services up and down with traefik - but more from a RAM-saving perspective on my home server.

Since I use the normal docker CE I was not able to try out the plugin directly.
So I forked this service and adapted it to work with normal docker containers in a start/stop fashion as suggested here
traefik/traefik#6993 (comment)

If you (or anyone else) is interested, here is my branch for that:
https://github.com/jo-me/traefik-ondemand-service/tree/scale-single-container-without-swarm

Just clone it, docker build it and then start the container instead of the original one. Everything else (especially plugin/middleware configuration) is not changed since this is only a helper container for the ondemand plugin.

I will play around with it some more to improve the timeout handling as well as delaying the response so that no user refresh is necessary in most cases.

Cheers

Hi ! Thanks for your contribution ! Sounds interesting !

But, Swarm mode is not part of Docker EE, it is available in Docker CE. All you need to do is docker swarm init to access the swarm APIs, such as docker service.

We could actually use your code and bring basic docker containers and swarm services together. Sounds good to you ?

Yeah it could probably be merged to cover both cases. if you plan to add more service scaling logic though (to more than one container) it might get a bit convoluted. For 0 and 1 instances the docker part would have a similar interface at least.
For me it was mostly a Go exercise while achieving something super useful for my setup at the same time. I'm currently working my way up from noob to rookie on the Go ladder :-)

I quite like the idea of this helper / companion container to the plugin. It makes development a lot easier as traefik doesnt have to be restarted all the time (and is not running in dev mode). And as long as the interface between plugin and container is stable you can switch out the companion container depending on featureset, environment, container engine, etc.
I'm aware that you are planning to merge plugin and service and that is a lot easier to setup than the current version, but I wonder if that will make it less flexible.

What I'd like to improve still are the following things:

  • Replace sleep/timeouts with Timers that reset on each request. This will change the behavior from "kill x seconds after first call" to "kill x seconds after last request".
  • Delay the response until the service running in the container is actually ready to handle the request. Right now, you could wait e.g. 10 seconds after starting the container and then return "started". For many services this might be enough. This could be improved either by checking the container health checks or by repeatedly sending HEAD requests to the requested endpoint. The latter would require knowledge about the request, though, which in turn would require changes in the plugin<->service interface. This goes in the direction of "dynamic loading" what was proposed here: acouvreur/traefik-ondemand-plugin#2

I'm curious what your thoughts are about this.

Aside from that I wonder whether the configuration aspect could be simplified. I quite hate to redundantly put the serviceUrl in every middleware config. Isn't there a plugin configuration section where this could live?

๐ŸŽ‰ This issue has been resolved in version 1.0.0 ๐ŸŽ‰

The release is available on GitHub release

Your semantic-release bot ๐Ÿ“ฆ๐Ÿš€