lucaslorentz
commented
3 years ago Hey Flavio,
That's a very good idea and would indeed be a nice evolution for this project.
I think the same concept could be applied outside the container world as well. Some time ago I wanted to make caddy discover and auto-configure Azure App Services. One blocker I found was that Azure has a limit of 15 labels per App Service. Maybe you should double-check if such limits exist on ECS.
Do you have any design in mind?
I guess we can introduce the concept of configuration providers and define an interface they must implement.
Then the core code of this project will just:
- loop through all configuration providers and retrieve its generated Caddyfile
- merge all provided Caddyfiles into a final one
- apply the configuration to all caddy nodes
- have some utilities to do Caddyfile manipulation and labels to Caddyfile conversion
All the existing docker related code would be moved into a "docker provider".
Then it will be much easier to introduce an ECS provider.
And maybe another provider for Podman: https://github.com/lucaslorentz/caddy-docker-proxy/issues/196
And probably this could go in a separate provider as well: https://github.com/lucaslorentz/caddy-docker-proxy/blob/master/plugin/generator/generator.go#L71
Would you like to work on this? I've been working on another pet project, don't know when I will switch my focus to this.
rupertbg
I love Swarm, but in some production projects I am using Amazon ECS because of costs and it is working very well (to be honest, I think they inspired their design over Swarm - even some concepts are the same, as "Service" and "Tasks" ;)
In AWS we don't have a service as configurable for HTTP as Caddy is, so I was thinking about creating a "caddy-docker-proxy" that could run on ECS and listen to events from ECS containers with the same labels as in this project and configure Caddy accordingly. This way I could be as happy with ECS as we are used to be with caddy-docker-proxy in our Swarm clusters!
This kind of abstraction of "docker listeners" would expand this project to work even with Azure, K8S or other container cluster providers.
I know this would offend a lot the current codebase, but the patterns will be roughly the same. Is there any interest in working in this direction for caddy-docker-proxy?