Closed hasufell closed 4 years ago
Thanks for bringing this limitation up.
Normally, bitlbee
runs bound to localhost
but I understand your concern: if you run bitlbee
somewhere, someone can sniff the traffic in between.
IMHO, it should be only one daemon per container. This means that stunnel
must live in a separate container. Then, everything must be glued together in a docker network
(that can be automated in a docker-compose
).
Added-value of this approach: the user can select whether they want to connect via TLS or not.
I can address this issue in the future: in the meanwhile, I will be happy to review any PR you may want to open in this direction.
IMHO, it should be only one daemon per container.
I don't generally share this philosophy. It makes setups needlessly complicated. The reasons you want to separate things in different containers are:
It is quite easy to run a multi-daemon docker container with supervisord and have a startup configuration for that. stunnel is small and has almost zero config/overhead.
And: I don't use docker-compose for anything on my server. It doesn't integrate well with other specialized approaches to spawn and control containers.
It is quite easy to run a multi-daemon docker container with supervisord and have a startup configuration for that. stunnel is small and has almost zero config/overhead.
This is debatable, because:
supervisord
) in the bitlbee
containerstunnel
toosupervisord
restart policy - what happens if stunnel
crashes?stunnel
requires an update, we need to rebuild bitlbee
and its plugins (and the other way around)I prefer providing a separate container for stunnel
and package everything into an easily deployable solution with docker-compose
: if someone wants to have TLS termination for bitlbee
, it is enough to link it to bitlbee
.
Speaking of which, can you suggest an alternative to docker-compose
for this kind of requirement?
We would need to add a dependency (supervisord) in the bitlbee container
Yes, which is simpler than docker-compose with all of its complexity.
We need to deal with supervisord restart policy - what happens if stunnel crashes?
With containers, you have the same problem.
Updates: if stunnel requires an update, we need to rebuild bitlbee and its plugins (and the other way around)
If you want to optimise build times, you can use layers for this.
if someone wants to have TLS termination for bitlbee, it is enough to link it to bitlbee.
Well, you're adding configuration complexity while it could simply just be a command line switch in the entrypoint that enables stunnel.
Speaking of which, can you suggest an alternative to docker-compose for this kind of requirement?
No, I don't really use docker-compose much. The only containers I have separately are front-proxies and mysql containers. Those have reasons to be separate. And I don't need docker-compose for that.
But you could indeed argue this is outside of the scope of this Dockerfile and might as well be a separate Dockerfile that derives from this.
We need to deal with supervisord restart policy - what happens if stunnel crashes?
With containers, you have the same problem.
Not really: it depends on how supervisord handles a process termination and the policy to restart a service.
This issue has been fixed in https://github.com/mbologna/docker-bitlbee/commit/f11fce3f4afb380c9d009f519199e48deb4d22bb, tested and pushed to master Thanks for bringing this up, and enjoy TLS terminated bitlbee!
Not really: it depends on how supervisord handles a process termination and the policy to restart a service.
Yes, you're just trading supervisord with docker-compose. Both have restart policies.
Thanks for bringing this up, and enjoy TLS terminated bitlbee!
Interesting work! I'm using a derived Dockerfile, however.
Seems there is no support for connecting to bitlbee over an stunnel.