hi all, I’ve recently got to know LSIO and all of its incredibly well-maintained containers.
I have seen a lot of guides on a lot of things, but I’m still a bit confused about how it works regarding a well-oiled default multi-container setup.
since auto-torrenting features seem to be the most pulled docker containers from LSIO, this is a great test case to ask for help.
I can see there are plenty of containers, popular and well used, e.g.:
rtorrent/rutorrent
sonarr, radarr, etc.
portainer
letsencrypt
duckdns
reverse-proxy-confs
but is there a docker-compose scheme that ties all of these together?
that would require not only a docker-compose yaml file with the basic networking and ports already setup, but also a minimalist draft of config files for each of the applications.
I would be happy to have more experienced users link further reading material or guides, or even Discourse topics that I could not uncover in my search, and so on.
once again: considering that all of this is extremely popular, I’m sure someone somewhere has developed a template repository that, leveraging on the LinuxServer ecosystem, provides a great starting point for newcomers.
I hope my request is clear! thanks.
All of our images have compose yaml snippets and all you need to do is copy/paste them into the same yaml file (except for the first two lines, version and services that should only appear once at the top of the yaml)
That’s all
And better yet, if you’re gonna be reverse proxying them, you can forego port mappings in all apps except for letsencrypt, since letsencrypt will access them internally through the docker network and via host mapped port
right, but then lots of things should be configured manually in config files, or through the appropriate GUIs, right? like all the reverse proxy configurations.
I will definitely start experimenting with the obvious solutions of stacking them up and trying to make them play nice with each other, but I’m sure there is a better way.
I would love a guide that tries to explain the implications of each choice.
examples:
why is a multicontainer approach better for the job, as opposed to a monocontainer? I understand it’s more aligned with the philosophy of docker, but what are the effective implications?
how is the security of all this? I’m still naively confused by root permissions and (potentially) putting a root process to listen on the web (portainer?).
You’ve already found an example so why not use that?
We won’t provide an all in one guide nor will we recommend a third parties guide. We already provide enough documentation/examples on how to get each container up and running then any additional information on configuration is provided by the upstream app’s documentation.
Sure, just play around. Once you figure out how the mappings work, it will seem pretty easy and straightforward.
Most reverse proxy configs in letsencrypt require a simple file rename to activate and they work out of the box. Same compose yaml will result in all containers being on the same custom docker network, so they’ll connect to each other directly via container name as dns host name. All that will work like magic.
thanks, but I’ve already read everything you have linked, like the same-compose-same-network feature.
(I’ll still choose your post as a solution so as to help out others with similar questions.)
there are plenty of things still obscure, but I guess I’ll have to think about it and try it out.
(does every container have root access to my full machine, like portainer?
can I setup letsencrypt locally in a VM without a DNS record?
is it okay to allow unsecure traffic between the containers and encrypt only from the actual external interface outwards? what’s the attack surface?)
Your questions are more about docker as a service (or letsencrypt service) and not related to our images. A guide like you initially asked for would not cover those anyway.
no, containers are sandboxed and only have access to whatever you give them access to through docker arguments
no, and I don’t know why you’d want to. If you want local reverse proxy, you can use the plain nginx container
yes, the traffic would go through the internal docker network and would only be accessed by the containers on that network. You can go wild and set up different networks where only one service and letsencrypt would be a part of each.
most obvious is nginx inside the letsencrypt container, which would respond to requests on port 443 (and maybe 80). It has fail2ban built in with a jail set for http auth by default
there are many other attack surfaces but those are all beyond the scope of what we provide
!