[Feature Request] add Traefik #160
Comments
|
+1 From next week I will have time. I've already planned several weeks ago to add traefik support to be able to proxy ports other than HTTP. |
|
I have some working prototype in a docker compose file which can do the following things:
Please guys check it. Have to discuss how can be integrated to current templates - @Slyke ? |
|
I had no idea what Traefik was until I Googled it and landed on this docs page. I worked in data-comms at one point in my career so I think I have a reasonable handle on the problem Traefik is solving. My initial reaction was "wow" and "cool", along with amazement at the time and effort you must have put in to getting it to work. I have no wish to detract from your achievement or to come across as the resident "Mr Negative" but, on reflection, I'm can't say that I'm convinced that the problem being solved is one that the average IOTstack user is likely to have. My between-the-lines reading of the Discord discussions and GitHub issues is that the average IOTstack user has a small home network to which they are steadily adding IoT devices and for which a single RPi serves as their data concentrator. To the extent that the average IOTstack user looks outwards beyond their home network, it seems to be for services like Cayenne or LoRaWAN. To the extent that the average IOTstack user looks inwards from beyond their home network, it seems to be for remote access solutions like WireGuard. BUT, I accept that I may be:
On number 3 in that list, if you thought that the compelling IOTstack use case would be immediately apparent upon seeing your When I look at your exemplar
What worries me about increasing the complexity of There's also the question of the ability of most IOTstackers to test changes they want to propose in PRs for compatibility with Traefik. I look at all that extra detail and, honestly, it gives me the heebies. How should the average IOTstacker approach the problem of developing a new container or making a substantial change to an existing container?
Absent a compelling use case and/or evidence of widespread demand, my two cents is that I think Traefik support is a probably a niche requirement rather than mainstream. Instead of trying to bolt it into SensorsIot/IOTstack, it might be more appropriate to fork a separate repo for those who want Traefik support. A separate community of interest would have the capability and motivation to test changes made to the upstream SensorsIot/IOTstack, augment those changes where necessary to make them "Traefik compatible", and decide when to put changes into production. However, nobody put me in charge of anything so this is all just one person's opinion. I'll be very interested to see how other people react, and whether they have any ideas on how to manage the increased complexity if Traefik support comes into the current repo. |
|
I tend to always generilaze problems, and use to be not care how long the generated codes are. The reason in my work I'm using meta models and transformations, so for me programming is a tool to create and convert models. Thats the reason I like this project - easy to manage abstract logics - and if you see there are repeating patterns what have to be set in traefik. Maybe it can be generalized more, but I spent 2-3 hours to achive that state, I have no reason to make more abstract, because for me enouh to make templates. As a matter of fact not a big deal if this compexity is not suitable for this project, I'm managing my own version, my goal is a tool which helps me, and its a big plus if anyone can learn or get some inspirations from my solutions. My IOTStack is a sandbox where I can test things without big consequences. For me more important how easy to access services than the length or complexity of configuration. As I see most of the user don't care about details, only wanna use services which required for their projects. With a good generator they haven't understand the underlying logic. With some good wizard some variations can be configured automatically. Is there DYNS? Allow access from remote - As I see there is PiHole which I think more complex and can cause more damage for local-net (multiple DHCP / routing problem for example) I think this solution seems complex but the result is very simple. I think most of the users does not have clue how the generator / menu itself works, so the complxity there I think does not matter - maybe I'm wrong. Maybe the problem itself does not exists for most of the users, but there was a topic inside of my PR (this solution is more general and has more feature - #21 . Originally my intention was not about to solve the external access of my services, but to resolve port hell. I'm unable to. memorize 10 ports for 10 service - and I have more than 100 devices at home, mqtt, bluetooth, zigbee and wifi, so I need that the DNS names of devices and services be easly managed. I need that I have a central unit which have be completely replaced in 5 minutes - so if something goes wrong, with this solution I can move most of services to a cloud provider (except zigbee) - my wife kills if something goes wrong :) SSO was another thing, I don't wanna make user management per service, and I had lot of experience SAML / SSO authentication in recent times. So if there are some user interesting, I can make the documentation / template / generator mods. And about the templates. I have an idea, these whole bunch of container management can be done without compose, with a docker image which can have the configurator and can modelling the images as a box and the links between the services as lines over a web frontend - like how portainer manages container (over mounted unix socket) - but it is not a fork, its a new system and its about service orchestration. |
|
Hi, i think this project could benefit from that. I use nginx as reverse proxy to have it all available under my local domain. I think traefik is a great enhancement. The complexity for users is already given with the port hassle, i don't think normal users will take a deeper look at the docker-compose.yml or create a compose-override.yml but if they do they're not normal users and could take responsibility of the yaml files. normal users run menu.sh create the stack and run it and if it works great. jm2c |
|
Has there been any progress on that matter ? |
|
I was pointed here from #410. That full monty Traeffik configuration looks nice but is much more (both feature wise and complexity wise) than I for one would need.
|
|
I think it's time to support HTTPS with proper certificates. There are multiple issues and Discord mentions about scenarios needing this. Both linuxserver/swag and Treafik are able to provide it. I would even consider providing it by default instead of something users have to explicitly add?
Traefik adds a bit of docker-compose.yml verbosity by way of the labels, which you may just ignore if not using Traefik. Your example seems pretty comprehensive, but I'd add the DuckDNS acme provider.
I think SSO integrations should be left as a documented user-options or as a completely separate service, not included by default. Keep it as simple as possible. All services should be able to present their own password prompts or the network is secured and no passwords are even wanted. Note: Nextcloud also has web service integration endpoint URLs that must be open and without SSO interference. Maybe we could add two mutually exclusive Treafik-services; one with SSO and one without it.
It would be easy, true. Just add support for service specific overrides. e.g. But is it worth the additional complexity? I would say it isn't. I feel it would be better to add the labels directly to all service.yml files as needed or use a static configuration.
Yup, it's a valid concern. But maybe a not a too large sacrifice for having all relevant configuration for a service in one place? Maybe even a benefit.
The Traefik stuff being there will remind them that it too needs to be tested. I feel this is a benefit. Instead of labels, Traefik also support file based configurations. This would be a static configuration listing all possible services. For unreachable/uninstalled services Traefik will just reply "Bad gateway". |
|
Hi, tl;dr my proposal for a traefik container
I also missed traefik in this stack. I came from a rasperry pi kubernetes cluster (microk8s) and used traefik a lot and can contribute a little / can create a pull request. For me, the distributed data level (longhorn) was not stable enough and the performance was rather bad, so I'm keeping my hands off Kubernets on RasperryPis for the time being. I spent quite a lot of money on the Raspberry Pis, so I don't want to replace the hardware with ordinary arm/x64 servers at the moment. In kubernetes the nicest configuration option of traefik is via custom resource definitions - traefik monitors these resources in every (configured) namespaces and automatically restarts - so every seperate project can just create their needs. But in this project it doesn't work. In my opinion, the best approach is the infrastructure-as-code approach via YAML configuration. It can be easily backed up and restored. In my case I used Traefik for the following features:
Due to the many configuration options, I would specify as little as necessary and provide Traefik almost naked. (no sso and so on). I prefer to see interesting use cases and examples documented. However, I am thinking about already providing the following things:
Are you interested in a pull request? Kind regards, |
It would be good to add the so called Traefik
The text was updated successfully, but these errors were encountered: