Add Traefik

[kageurufu]

https://traefik.io/traefik/

Traefik is a incredibly customizable reverse proxy, including support for auto-mapping other docker containers. I use a traefik.toml like follows, to auto map all containers to subdomains

All access is already controlled at my WAF, so I'm leaving authentication to the user

[api]
  dashboard = true
  insecure = true

[entryPoints]
  [entryPoints.web]
    address = ":80"

  [entryPoints.websecure]
    address = ":443"

[http.routers.traefik]
  rule = "Host(`traefik.my.domain.tld`)"
  service = "api@internal"

[providers.docker]  # Set up docker discovery
  defaultRule = "Host(`{{ .Name }}.my.domain.tld`)"

The cmd_arguments used are a minimum to get traefik to expose a dashboard and discover docker containers.

To ease and accelerate the PR submission, please use the template below to provide all requested information.
You can find guidelines on which docker image to use in the Rockstor's documentation,
as well as examples of proper formatting in other rock-ons (here
and here)

Fixes # .

General information on project

This pull request proposes to add a new rock-on for the following project:

• name:
• website:
• description:

Information on docker image

• docker image:
• is an official docker image available for this project?:

Checklist

• Passes JSONlint validation
• Entry added to root.json in alphabetical order (for new rock-on only)
• "description" object lists and links to the docker image used
• "description" object provides information on the image's particularities (advantage over another existing rock-on for the same project, for instance)
• "website" object links to project's main website

[FroggyFlox]

Hi @kageurufu,

First of all, sorry for the delay in having a look at your PR. This is actually one that I have been having on my mind for a very long time but never really got the opportunity to try. Having a Rock-on for Traefik is actually the reason why I wanted to have an implementation for Docker labels (rockstor/rockstor-core#1999) and Docker networks (rockstor/rockstor-core#2207).

The reason I was always interested in Traefik is its simplicity and flexibility to dynamically add a new service under it, but it's also the reason why it always overwhelmed me a little bit as there are 2 or 3 ways to do everything. While this is always a good thing for a standard system, it actually can also complicate things quite a bit in the context of Rock-ons and Rockstor. Indeed, as we always try to make "complex" task as simple as they can be for the user, it does offer some challenges here. I still need to wrap my head around these so I will lay out some of my thoughts below, hoping it'll help me get a better grasp of potential solutions, and also use your experience with Traefik to resolve some blockades.

All access is already controlled at my WAF, so I'm leaving authentication to the user

This is actually one of the main points of discussion for me. Indeed, leaving the api = insecure like that is the simplest way and still secure it seems in a situation like yours where you still seem to protect it through other means, but I feel that in our case we should find a way to not use that setting. If I'm correct, it does mean we would need to have the user create credentials and place them in the .toml or .yml file, though. If you have experience with this, is that the best alternative? I still need to look up exactly how we could best have the user do this easily.

If I'm correct, the dynamic configuration can be achieved either by labels on containers, and/or in a dedicated .toml/.yml file. As these do not seem to be mutually exclusive and a configuration by the user, we should indeed let that out of the Rock-on definition, I believe. What I'm wondering about is the static configuration. I can think of the following for each of the three ways we have at our disposal:

1. .toml/.yml: advantage is that it is entirely up to the user to choose what to put in it, so it would be as good as the user wants it to be for them. The main disadvantage is that the user would have to create a file and manually set the config settings, which can be daunting (it is for me, who haven't yet tried to do it, for instance).
2. command arguments like you did: does not require the user to provide a static configuration file, so it would be running out-of-the-box for the user. Downside is that it would not be configurable for them.
3. Environment variables: would allow for user configuration while allowing them not to manually create a file. The user would still need to know what settings to choose, though, and it might also be quite complicated if we have a lot of environment variables. We also would have to choose what environment variables open to customization.

I think I personally favor option 2 above, as it would be the most turn-key solution for the user, while allowing for configuration in a dynamic file.

I would also prefer to disable traefik by defaults on all containers and let the user pick the one to be routed by traefik using Docker labels as not everybody would like to have all their containers taken care of by traefik, I believe.

@kageurufu , let me know if any of this makes sense to you and what you think of it; it could very well be that I'm completely wrong about any of these settings as I haven't really tried to use Traefik yet and am thus still a bit unclear on how to actually configure it properly.

[phillxnet]

@kageurufu and @FroggyFlox & @Hooverdan96 this pr has awaited a question from @FroggyFlox for over a year now. If there is now no longer any interest I propose that we close this. It can always be re-opened as folks get time/attention in this area.

[phillxnet]

@kageurufu and @FroggyFlox & @Hooverdan96 this pr has awaited a question from @FroggyFlox for over a year now. If there is now no longer any interest I propose that we close this. It can always be re-opened as folks get time/attention in this area.

Closing as above prior comment and we now also need a rebase to further assess this Rock-on.
Much appreciation to @kageurufu and @FroggyFlox for the work already put in here. Do please re-open if there is still interests in this Rock-on. But it will need to be re-based on current master to be assessed further.