has anyone tried to deploy the docker image to azure? I saw there is some official documentation for AWS but I have a $150 azure credit per month and if I can figure out how to deploy the docker image to azure container apps I can get another server going.
I haven’t used azure but if you use the ansible installation method, it will install everything into an instance (whatever they are called in azure, the typical computer virtual machines).
But you need a public domain name to get let’s encrypt certificates to work. So you should buy a domain name and point it at your instance first.
If you have that, the ansible install will set everything up, and run stuff inside docker for you.
I’m actually considering doing an instance on gcp cloud run, just because my main work is in gcp and it’s a pretty decent way to run containers.
I’m thinking I might do a build of the image per the doco via GitHub actions and push the image into artifact registry (GCP service)…
If you get this working can you make a write-up on how? I’d like to do this as well.
For sure. Shouldn’t be too hard just need to sit down and spend a good block of time on it.
I’ll probably use a bit of either pulumi or terraform, if that’s ok!
My job is all on Azure, but only in their SaaS offerings so I’m not too familiar with container apps. Definitely interested, I might experiment with it.
You can use Lemmy-Ansible to install Lemmy into whatever Azure provides. Be it containers, VMs, or native hardware.
Can someone explain to me what’s the point in having a lot of small instances of something like Lemmy?
I’m very familiar with Azure, and looking at the docker-compose file and AWS setup, it’s very straightforward to setup a simple instance on Azure container apps. How much it costs you will highly depend on what you want to do with it and how you expect it to be used.
Like, how much traffic are you expecting?
The idea of having several instances is an architecture choice. Instead of having all the users and content served by a single monolith, the users and the content are spread around several instances that then talk to one another in the process called federation to serve that content for other instances.
This spread out architecture allows for lesser hosting costs per instance and if an instance goes down it does not mean the entire service goes down as a whole. You may experience technical difficulties on one instance while the rest are completely fine, just unable to get stuff out of the instance. Additionally, it allows for easier moderation as moderators (admins?) are instance specific. You don’t have to moderate the whole of Lemmy, keeping your own house clean is enough. This means you are likely to have a higher ratio of mods per users with more instances, which leads to better quality in moderation work. Then if some other instance is not behaving, stop federating from them to yours.
And then some. I hope this at least explains some of the design choices at fediverse?
Thanks for the reply. If you don’t mind, I still have few questions.
I understand the value of a distributed architecture and federation. What I wasn’t sure about is the value of tons (thousands? hundreds of thousands? millions?) of small instances vs few hundred or thousand large ones.
This spread out architecture allows for lesser hosting costs per instance and if an instance goes down it does not mean the entire service goes down as a whole.
It seems that federation would put more pressure on all popular instances, no? the more popular an instance, the more likely others to want to federate with it, the more work it needs to do to push data, the more calls, etc. I understand that relays could spread out the load, but you’re just pushing the problem one more level. I already see wildly different numbers of comments on the same thread between the different instances depending on the home vs federated, with low usage (talking about <100 comments). It seems to take a long time for things to sync, and some comments don’t seem to sync.
And while sure, your own personal instance of Lemmy might be up and fine, if the popular instances you federate with are down, you’re essentially cut off still, right?
Additionally, it allows for easier moderation as moderators (admins?) are instance specific. You don’t have to moderate the whole of Lemmy, keeping your own house clean is enough.
You have to moderate any instance you allow to federate with still, right? Like either you lock down which instances you want to federate with (have an allowlist) or you block abusive instances (have a denylist) either way it’s a lot of management still. More flexible, for sure, but not exactly a walk in the park, right?
I think you sort of answer your own question when you wonder what the value of having tons of smaller instances versus a smaller number of larger ones as you discuss the stress of federation from the larger instances soon after. Similarly if content is split between multiple instances any single one going down is going to be less noticeable.
As for moderation, everything does not federate everywhere at once, there needs to be some interaction between the instances first (like subscriptions to communities) for things to really start transferring over. Yes, moderation will still take work, but you don’t have to address the entire fediverse at once.
As for
I already see wildly different numbers of comments on the same thread between the different instances depending on the home vs federated, with low usage (talking about <100 comments). It seems to take a long time for things to sync, and some comments don’t seem to sync.
I cannot say I would have explored the effects, so I can’t really comment on the topic. If the delays are significant and there’s straight up things not getting federated, that’d be an issue and should be fixed by the maintainers. Lemmy remains relatively new.
I think you sort of answer your own question when you wonder what the value of having tons of smaller instances versus a smaller number of larger ones as you discuss the stress of federation from the larger instances soon after.
I’m not sure I have. I was saying you must have/will end up with few large instances PERIOD. There is just no way around it. Otherwise you have a discovery/usability problem. Absolutely 0 non-techies will setup their own Lemmy instance. It’s not even reasonable to assume they could. All I do for work is setup cloud deployments of applications and build tools to maintain and monitor them, and I have 0 interest in setting up a Lemmy or Mastodon instance. I like Mastodon in theory, if the main instance maintainers shit the bed, create an account on another instance. But I’m not setting up my own instance.
For example, I’m into woodworking, selfhosting, programming, and cooking. I’m not setting an instance for any of that. I just want to know what are the popular instances that have woodworking, programming, and cooking communities and just subscribe to them. I’m not gonna go looking for hundreds of small instances all over the internet, nor am I gonna host my own.
As for moderation, everything does not federate everywhere at once, there needs to be some interaction between the instances first (like subscriptions to communities) for things to really start transferring over. Yes, moderation will still take work, but you don’t have to address the entire fediverse at once.
Yes, that makes sense if the problematic aspects of another instance is just their content or culture. Like if there is a say ultra-religious instance, or a toxic incel instance, or a Nazi instance, etc. Sure, you never federate with them and you never have to worry about their culture.
This doesn’t work for spammers/malicious actors instances though. As a spammer or malicious actor, all I have to do is setup dozens and dozens of random instances that are just constantly spamming every instance that’s on a list somewhere. Forcing it to federate with my spam instances and putting load on them. As a bad actor, I actively come to you, not the other way around.
Then you’re back to the allowlist, which breaks the “federation” idea in general or introduce a lot more mod/support cost needing to manually allow each instance that you “think” is not spam/malicious.
So finally in that a world of few inevitable large instances, and hundreds of thousands of small ones that are all polling/pushing activity to the big ones, that’s just significantly more load on the system as a whole. There is no magic around cache, latency, inconsistency, slowness, etc except to be on the instance where you want to converse with people.
I tried googling for how ActivityPub scales to see if there is some write up and this came up for example https://lucumr.pocoo.org/2022/11/14/scaling-mastodon/
from that article:
One thing seems relatively certain: if Mastodon wants to host a sizable community where some people have followers from most other instances, then the size of an individual instance will matter a lot and I’m pretty sure that the only sensible approach will be to either not permit small instances to participate at all, or for those to come with some other restrictions that will require special handling.
Many developers don’t want to accept the problem of back-pressure. (A topic I wrote about quite a bit incidentally). Unfortunately some bad servers can really break you, and you will have to avoid federating to them. In general too many small servers will likely cause issues for very popular accounts on popular servers.
I’ve been trying to setup a working instance using container apps, web apps for containers and ACI, but it remains finicky. Do you know of a bicep or deployment script that does this properly?
Did you get anywhere with this? I’ve got it all setup in Container Apps (deployed using Terraform Cloud). I’ve having some issues getting it working though - I think it’s something to do with the reverse proxy setup. I’m happy to share the code once I get it into a bit of a better state.
deleted by creator
