Skip Navigation
6 comments

  • 6 Containers for one application … And I thought the original Docker setup was annoying. Why include SSL stuff and a reverse proxy? I am pretty sure most people already have that set up.

    Edit:

    Just checked the readme in detail. They suggest rm -R’ing the Docker volumes directory to, I quote, “rm any persistent volumes”. Also manually messing with upstream data before manually creating the image again.

    I don’t see how this is any better than the original mess. It just adds more containers to the stack and gives very questionable advices.

    An “EZ-mode” for me would be one image containing all the relevant Lemmy-specific software (lemmy, lemmy_ui pictrs and maybe even the database) and needing one volume mapped to one path in the container.

    • Maybe for people who only want to host lemmy and nothing else

    • 6 Containers for one application … And I thought the original Docker setup was annoying. Why include SSL stuff and a reverse proxy? I am pretty sure most people already have that set up.

      That's because each container has a different set of responsibilities. ie. a Database container doesn't need Rust installed, the database container should not need to go down, even when you upgrade the Lemmy/LemmyUI containers.

      Second to this is how Lemmy is distributed - as multiple containers, one for the UI code and one for the backend/API, while pictrs is a completely different project to Lemmy. This is all pretty standard practice, though I agree Lemmy could probably be a single container (combining API+Frontend). The benefit of this is the face you can upgrade just the UI or API at a time, or accept UI changes before upgrading your API.

      The original mess is poorly documented, and results in inconsistent results due to how they use multiple levels of nginx reverse proxy, and the fact you need to do a bunch of configuration on top of just installing their repo.

      In the instructions, you will see I've documented a way to run other containers under Traefik, or you could run it under an existing Traefik reverse proxy installation (which is what I do!)

      It reads like you've not familiar with Traefik, or how modern stacks fit together. The amount of containers is not the issue, and building a modern service as a single container that bundles the Database and pictrs is not really even possible, or desired (since you might want to run multiple frontend containers to handle more load, and scale the backend seperately)

      Also, if you read the title above where you read the "suggestion for rm'in the volume is under "I fucked up - I want to wipe all data and start again" :) That's demonstrates where the data is stored and how to remove it completely if you want to start again - This is a common practice when developing/testing containers.

      Happy to field any further questions about it :)

      • and the fact you need to do a bunch of configuration on top of just installing their repo

        Like in your documentation, where I edit upstream files before building the container? Where's the volume? Where are the environment variables to configure Lemmy? Manually editing container files or creating directories isn't what I call "modern stacks".

        while pictrs is a completely different project to Lemmy

        ... which is only and exclusively used by Lemmy and no other application I ever heard of. So please enlighten me: What other applications use this thing?

        It reads like you’ve not familiar with Traefik

        I simply don't care about Traefik, because I already use Nginx Proxy Manager.

        Also, if you read the title above where you read the "suggestion for rm’in the volume is under “I fucked up - I want to wipe all data and start again” :)

        You're still suggest recursively removing volumes/ which is a stupid suggestion because that would also remove all non-Lemmy volumes. You should clarify that or give more precise information than "ah, just recursively remove the directory where all your container's persistent data is stored".

  • I can vouch for this, it works pretty well. Lemmy's ansible is extremely busted and this was the only I could get it to work without it fully breaking every time my server rebooted.

    Also, If it throws an error at first do this to make the initial config generator executable. Some systems might require this, some won't. Mine did. While in the base ezlemmy directory do this.

     
        
chmod +x /config/config-entrypoint.sh
6 comments