Help with setting up Sablier with Traefic Plugin

[tam481]

Hi
I love the idea of Sablier.

I need help with getting it to work with Traefik

The main question I have is about the plugin for Traefik: do you use the plugin in place of the Sablier container or alongside it?

Here is my Traefik static config:

experimental:
  plugins:
    sablier:
      moduleName: "github.com/acouvreur/sablier"
      version: "v1.2.0"

This is the dynamic config file:

http:
  middlewares:
    sablier:
      plugin:
        sablierUrl: http://sablier:10000  # The sablier URL service, must be reachable from the Traefik instance
        names: ytapp-svc               # Comma separated names of containers/services/deployments etc.
        sessionDuration: 1m               # The session duration after which containers/services/deployments instances are shutdown
        # You can only use one strategy at a time
        # To do so, only declare `dynamic` or `blocking`

        # Dynamic strategy, provides the waiting webui
        dynamic:
          displayName: My Title       # (Optional) Defaults to the middleware name
          showDetails: true           # (Optional) Set to true or false to show details specifcally for this middleware, unset to use Sablier server defaults
          theme: hacker-terminal      # (Optional) The theme to use
          refreshFrequency: 5s        # (Optional) The loading page refresh frequency

        # Blocking strategy, waits until services are up and running
        # but will not wait more than `timeout`
        # blocking: 
        #   timeout: 1m

ytapp-svc is the name of the service for the container I want to shutdown when not in use. This is the config part in the dynamic configuration file for Traefik:

routers:
  ytapp-rtr:
    rule: "Host(`ytapp.domain.lan`)"
    entryPoints:
      - "web-ep"
    middlewares:
      - sablier@file
    service: "ytapp-svc"

services:
    ytapp-svc:
      loadBalancer:
        servers:
        - url: "http://ytapp:7442"

Traefik shows "sablier@file" under HTTP Middlewares with its status as "Success"

Assuming you only need the plugin, I set up the above and added sablier@file as the middleware for the http router for ytapp but when I start it both the Middleware and the app show "plugin: invalid configuration: no configuration or too many plugin definition"

Please help.

[tam481]

Just wanted to ask that I looked at the e2e examples and I am even more confused because they seem to show that you need both the plugin and the container which begs the question: what is the point of the plugin if you're using the container as well?

Also,
image: acouvreur/sablier:local as the image for the container does not work. When you start the container it generates the following error "Error response from daemon: manifest for acouvreur/sablier:local not found: manifest unknown: manifest unknown"

[acouvreur]

Hello @tam481 !

So basically, Sablier is an API first. You can read a few things about it here: https://github.com/acouvreur/sablier#api

But this will not be the common use case for everybody. More than that, I think few people would like to manually hit the API to start a container.

So in order to automatically start containers by name, reverse proxies integrations are being built. These middleware do the API calls to Sablier instead of you.

So you'd need the container Sablier, you can use the version you want, I'd recommand you to use the latest stable version, which at this point is 1.2.0. So use acouvreur/sablier:1.2.0.

And then to load your middleware with the same version to your Traefik instance.

"plugin: invalid configuration: no configuration or too many plugin definition"

I'm not sure if it's on Sablier middleware ends for this issue, I look it up more closely later.

Is this more clear to you?

[tam481]

Thank you so much @acouvreur for making the time to explain how this works. That makes things a lot clearer now.

In essence the Sablier container does the work of starting and stopping containers.

The plugin intercepts requests to the shutdown container via Traefik, for example, and sends the relevant API calls to the Sablier container to start the container the user is trying to access. This is why you need both. One to do the actual work and the other to effectively send the commands that tell Sablier which container to start.

In terms of configuration, I've set up a sablier.yaml file as follows:

provider:
  # Provider to use to manage containers (docker, swarm, kubernetes)
  name: docker 
server:
  # The server port to use
  port: 10000 
  # The base path for the API
  base-path: /
storage:
  # File path to save the state (default stateless)
  file: /data/state.json
sessions:
  # The default session duration (default 5m)
  default-duration: 5m
  # The expiration checking interval. 
  # Higher duration gives less stress on CPU. 
  # If you only use sessions of 1h, setting this to 5m is a good trade-off.
  expiration-interval: 20s
logging:
  level: info
strategy:
  dynamic:
    # Custom themes folder, will load all .html files recursively (default empty)
    custom-themes-path:
    # Show instances details by default in waiting UI
    show-details-by-default: true
    # Default theme used for dynamic strategy (default "hacker-terminal")
    default-theme: shuffle
    # Default refresh frequency in the HTML page for dynamic strategy
    default-refresh-frequency: 5s
  blocking:
    # Default timeout used for blocking strategy (default 1m)
    default-timeout: 1m

I have more questions, if I may:

• Where should the configuration be? Do I need to configure both the container and the plugin with the plugin via the Traefik dynamic config file and the container via its own yaml file?
• How do I configure the containers to use the Sablier middleware?
• I noticed that in the configurations for the plugin, there is "Display Name" option. Shouldn't this be the name of the container that you are trying to access?
• Is it important to specify the "names" of containers to be started and shutdown by Sablier?
• Is this how Sablier knows which containers it can shutdown? Like the question above, shouldn't this be any container that uses the Sablier middleware anyway?

Thank you for looking into the config error in my original post.

[acouvreur]

Where should the configuration be? Do I need to configure both the container and the plugin with the plugin via the Traefik dynamic config file and the container via its own yaml file?

There is configuration of the Sablier API, which is described here: https://github.com/acouvreur/sablier#configuration

And there is the configuration per middleware for Traefik which is described here https://github.com/acouvreur/sablier/blob/main/plugins/traefik/README.md#installation

So you need to configure the Sablier API and the middlewares. But note that the sablier API configuration is just about default values. So if you'd use your middleware without the theme explicitly, it would default to the one configured in Sablier.

So your middleware configuration is just specifications about the behavior against the Sablier API from the middleware.

How do I configure the containers to use the Sablier middleware?

You have quick example here: https://github.com/acouvreur/sablier/blob/main/plugins/traefik/README.md#traefik-with-docker-classic

Note that the versions are a bit outdated, but you can safely use the latest 1.2.0. (v1.2.0 for the middleware and 1.2.0 for the docker image)

I'll fix that later in https://github.com/acouvreur/sablier/issues/99

Is it important to specify the "names" of containers to be started and shutdown by Sablier?

So basically, one middleware can trigger multiple containers to shutdown, and unfortunately, from the middleare itself from traefik, there is no way to know the actual name of the container, thus needing to specify the name of the container your attaching the labels to... I know it sounds like duplication, but it's actually a limitation, which I might change later using other kinds of labels. See https://github.com/acouvreur/sablier/issues/123

Is this how Sablier knows which containers it can shutdown? Like the question above, shouldn't this be any container that uses the Sablier middleware anyway?

Yes, it's how Sablier knows which container to shutdown, it basically do a "docker stop <container_name>" for each names

[tam481]

I've just tried using labels attached to the Sablier container and I can now see two middlewares in Traefik (dynamic@docker and blocking@docker)
I then changed the Traefik dynamic config file for the container ytapp and specified dynamic@docker as the Middleware and it seemed to work in that when I tried to access the container while it was shutdown, I got a transition page although it wasn't using the "shuffle" theme that I had specified but it started the container.

However, a few minutes later the Sablier container exited and shutdown. I checked the docker logs for the Sablier container and found:
time="2023-01-15T18:11:35Z" level=info msg="shutting down gracefully, press Ctrl+C again to force"
time="2023-01-15T18:11:35Z" level=info msg="server exiting"

The Middlewares in Traefik disappeared and the container is showing an error which is understandable as the Middleware it is supposed to use is no longer available.

Is this some sort of bug or am I missing something? I suspect I messed up somewhere as I don't know how the Traefik Plugin is being used as it looks like I'm using the Sablier container directly.

[acouvreur]

You should be using only one middleware for one service, at least for getting started.

This example should be good enough for a fresh start, https://github.com/acouvreur/sablier/blob/main/plugins/traefik/README.md#traefik-with-docker-classic

Use version v1.2.0 for middleware and 1.2.0 for acouvreur/sablier

I believe you must have referenced the sablier containers name to be shutdown, so it might have shutdown itself lol

[tam481]

I see what I did. I did specify "sablier" in the docker-compose labels section for Sablier. I assumed that was the name of the Sablier container.

traefik.http.middlewares.dynamic.plugin.sablier.names=sablier

There seems to be inconsistencies though, looking at the example you kindly referenced, it looks like Sablier will only use the strategy and theme settings if specified in the docker-compose label and not in the config yaml file but will happily use the port from the config file.
Also, it would be nice to be able to specify the container names in the Traefik dynamic configs file so that I don't have to recreate or restart the Sablier container every time.

Also, if I don't use docker labels and instead rely on the config yaml file and the Traefik dynamic configs, the Middleware does not work at all. I get the "plugin: invalid configuration: no configuration or too many plugin definition" error.

I'm slowly getting there and I don't know if the above observations are valid or just my lack of understanding but I'm really grateful for your help.

[tandy-1000]

I ran into this too, this seems to have stemmed from a mistake in the example config, where the plugin name, sabier, should be specified as a level below plugin.

This is the dynamic config file:

http:
  middlewares:
    sablier:
      plugin:
        sablierUrl: http://sablier:10000  # The sablier URL service, must be reachable from the Traefik instance
        names: ytapp-svc               # Comma separated names of containers/services/deployments etc.
        sessionDuration: 1m               # The session duration after which containers/services/deployments instances are shutdown
        # You can only use one strategy at a time
        # To do so, only declare `dynamic` or `blocking`

        # Dynamic strategy, provides the waiting webui
        dynamic:
          displayName: My Title       # (Optional) Defaults to the middleware name
          showDetails: true           # (Optional) Set to true or false to show details specifcally for this middleware, unset to use Sablier server defaults
          theme: hacker-terminal      # (Optional) The theme to use
          refreshFrequency: 5s        # (Optional) The loading page refresh frequency

        # Blocking strategy, waits until services are up and running
        # but will not wait more than `timeout`
        # blocking: 
        #   timeout: 1m