I find it interesting how you had to declare a DNS server for federation to work. I played a bit with Docker Lemmy but I ran into weird Docker networking issues when trying to get it to talk to my mail server, which is in another docker container on a seperate VM. I just couldn’t get them to talk to each other!
I ended up building Lemmy from scratch, which was painful given the state of documentation, but somehow more workable than that Docker quirk I encountered. It’s still a mistery to me how to solve that one, though it’s probably just my lack of experience with Docker, I generally prefer setting things up the old fashioned way.
I’m very much just learning this afternoon both how to run and instance, and how to use it.
From the logs, I think what was happening is that a request would come in from a federated instance which basically says “Hi, I’m from server X, please can we do federate stuff”, then the lemmy server tries to resolve the hostname X so it can say hi back. If DNS isn’t working that message back fails and then the whole federation bit fails.
Adding DNS explicitly resolves that.
Googling docker and DNS shows this isn’t just me, and I’ve run into this before.
If you’re running different docker instances on different VMs, then unless you put them into a swarm explicitly, you need to allow each out to the local network and to talk to each other. You’d need to fix the firewalls and DNS on both because they won’t share a docker network. AFAIK, anyway. I’m not a docker expert.
I find Docker a mixed bag, it vastly simplifies some things, but then it complicates others.
Yes the bit that gets me is having the whole Docker networking layer with its own firewalls and rules, on top of host networking. Whatever was happening, Lemmy was not hitting the host or router firewalls at all. So maybe it was a Docker permissions thing, I really don’t know.
Then you have to worry about performance and how Docker handles assigned resources, this post was very interesting in this respect: https://lemmy.world/post/920294 (the bit on solutions).
Then again, it’s so much more straightforward to deploy Lemmy with Docker, none of this is a real problem unless you’re a big/public instance.
I suspect that’s less a Docker issue, and more to do with the code itself. Any code that’s synchonous or serial in nature (eg. including a lot of web-calls to remote resources like federated sites) is going to max out due to IO or network latency long before saturating CPU, and becomes a natural target for horizontal scaling.
I’d be surprised if that’s a pure Docker thing vs just Lemmy code in general. But, I don’t have sufficient hardware to test on to prove that out.
Hey, great write-up, thanks for sharing!
I find it interesting how you had to declare a DNS server for federation to work. I played a bit with Docker Lemmy but I ran into weird Docker networking issues when trying to get it to talk to my mail server, which is in another docker container on a seperate VM. I just couldn’t get them to talk to each other!
I ended up building Lemmy from scratch, which was painful given the state of documentation, but somehow more workable than that Docker quirk I encountered. It’s still a mistery to me how to solve that one, though it’s probably just my lack of experience with Docker, I generally prefer setting things up the old fashioned way.
Thank you.
I’m very much just learning this afternoon both how to run and instance, and how to use it.
From the logs, I think what was happening is that a request would come in from a federated instance which basically says “Hi, I’m from server X, please can we do federate stuff”, then the lemmy server tries to resolve the hostname X so it can say hi back. If DNS isn’t working that message back fails and then the whole federation bit fails.
Adding DNS explicitly resolves that.
Googling docker and DNS shows this isn’t just me, and I’ve run into this before.
If you’re running different docker instances on different VMs, then unless you put them into a swarm explicitly, you need to allow each out to the local network and to talk to each other. You’d need to fix the firewalls and DNS on both because they won’t share a docker network. AFAIK, anyway. I’m not a docker expert.
I find Docker a mixed bag, it vastly simplifies some things, but then it complicates others.
Yes the bit that gets me is having the whole Docker networking layer with its own firewalls and rules, on top of host networking. Whatever was happening, Lemmy was not hitting the host or router firewalls at all. So maybe it was a Docker permissions thing, I really don’t know.
Then you have to worry about performance and how Docker handles assigned resources, this post was very interesting in this respect: https://lemmy.world/post/920294 (the bit on solutions).
Then again, it’s so much more straightforward to deploy Lemmy with Docker, none of this is a real problem unless you’re a big/public instance.
I suspect that’s less a Docker issue, and more to do with the code itself. Any code that’s synchonous or serial in nature (eg. including a lot of web-calls to remote resources like federated sites) is going to max out due to IO or network latency long before saturating CPU, and becomes a natural target for horizontal scaling.
I’d be surprised if that’s a pure Docker thing vs just Lemmy code in general. But, I don’t have sufficient hardware to test on to prove that out.
That makes sense, I think you may be on the money there.