I think there's a misunderstanding. In the docker-compose.yml, you specify services, and these services can use the official container images. The only thing the docker-compose actually does is define your services so you don't have to specify them each time starting a container.
this post was submitted on 08 Jun 2023
6 points (71.4% liked)
Selfhosted
40767 readers
377 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 2 years ago
MODERATORS
In Lemmy's docker install guide, they list a docker-compose with the following images:
- dessalines/lemmy for the back-end
- dessalines/lemmy-ui for the front-end
Hope this helps
Thanks! I'll definitely take a look
I've seen people posting that getting an instance up and running is difficult, so I hadn't checked it out. This looks pretty simple. Am I missing something?
I've heard that the install from scratch is hard, but that the ansible install was relatively straightforward.
As for the Docker setup, the hardest part is setting up the reverse proxy so that federation works.
I'm using the lemmy containers + lsio's SWAG as reverse proxy and it's worked flawlessly since I got it running.
I've not bit the bullet on swag yet, because nginx-proxy has worked so well for me, but it looks pretty well thought out. Maybe this is enough of a reason to figure it out.
I'm pretty salty about lsio discontinuing 32 bit arm support. I have so many pi zeros running so much stuff, and I use their containers where I can.
Why would you not want to run it in docker compose?
I don't have easy access to compose on my NAS, it's a convenience thing really.
You can run it from an image without docker-compose but I'd recommend looking into docker-compose if you're not already familiar with it. @[email protected] has the idea right that it's just a powerful installation file and can automate your docker management process rather well if you're using it a lot.
You can build a container from an image but it's obviously more hands-on. Lemmy may have additional dependencies they include in the compose file that may not be present in the image source. but starting with something like
$ docker run --pull=always --restart=unless-stopped -d -p 80:8080 -v YOUR/PATH/TO/DATA:/data --name lemmy_backend [LEMMYREPO]:latest
and configure that using proper configuration ( the links @[email protected] posted) - reference this for how to do that!
Be prepped for manual updates, though 😳
My understanding is docker-compose is just a glorified installation file where you can install multiple containers and configure their interoperability/file systems/other config stuff, whereas images are the actual installation files for that specific container.
IE I can run a docker-compose to install App X, mariadb, and (IDK some third thing) at one time, but using images I'd have to install App X, THEN mariadb, THEN mysterious third thing, haven't had enough coffee lol.
As someone who doesn't know much about this as I'm jumping in the deep end, what's the difference?
A Docker image is a read-only template that contains the instructions for building a container. A Docker compose file is a YAML file that defines a set of Docker services.
A Docker image is a static artifact that can be used to create multiple containers. A Docker compose file is a dynamic configuration file that can be used to create and manage containers at runtime.
Docker images are typically used for building and deploying applications. Docker compose files are typically used for managing and orchestrate containers.
That came out of an AI. I can deploy images more easily on my NAS, and I've worked with them in the past, so I want an official container so I can deploy it alongside all the other docker containers I have running.
That came out of an AI
is that why it doesn't quite make sense to me?
Can you make a container from the compose file?
Yes, but the benefit of an official image would be that I wouldn't have to recreate it when a new version was released, it would update itself when I reload the container.
Do you need to recreate the container? Can you update the applications in the container?
I have a container running Watchtower and it checks once a week for any updated images so I can go through and update whatever needs updating myself. IIRC there's an option to have it automatically update stuff but I don't know nearly enough yet to be comfortable with that - If something is going to break let me break it myself so I can troubleshoot it haha.
I use Portainer as a GUI docker management system, and in regards to updating I can just hit a "Recreate" button and select "re-pull image" to update them. As long as you have the containers tied to persistent data folders it just pulls the latest image and ""re-installs"" it per your docker-compose file and everything is just as you left it.
I mean, I know I don't have to recreate it when I use a normal container, but I'm not clear when using compose
Hopefully someone with knowledge can weigh in.
You can do whatever you want inside the container. If you wanted to update inside it, you can, but it's probably not worth the effort. The downtime depending on the app can be just a few seconds when you rebuild the container.
That makes sense
Think of container as a running VM. Image is the file system of the VM. The image itself is static, so when restarted alll file system changes get tossed out (you can map certain paths inside the container to other storage). A Dockerfile is a file that describes how to build the image (For example : Use an ubuntu base image, run these commands, copy this file in to this path, expose this network port, and when running the container, start this file when it boots up).
When running a container you specify which image it should run, network ports to expose to the host network, environment variables that should be set inside the container, if it has access to a gpu, mapping paths to storage and so on. You can even change the startup command.
A docker compose file is a config file that can define all those things, and define it for multiple containers, binding them together in one stack. So you could for example have a static web server, an api server, a database server, redis, and so on defined and configured via environment variables. And you could just do "docker compose up" to bring up all the parts in their own docker namespace and virtual network.
Docker Compose is just a tool to elegantly lay out containers in a stack. It's not a replacement for containers and images. If you need the image names themselves for use outside of compose like in a NAS GUI setting, they would be in the compose file.
It looks like the compose file has a link to the container with Lemmy and lemmy-ui
Did anyone try to set up a dockerized Lemmy with traefik.io as router/proxy?