How do the different containers work?

[Yeastdonkey]

Hello! I'm self-taught with docker and self-hosting, and this is the first project I've looked into deploying that has multiple containers running the same image for different purposes. I've seen projects that run multiple different containers before, and I understand why this project uses multiple images (postgres, redis, etc.), but I was trying to figure out the point of running multiple containers with only certain parts of the image enabled in each. Not to say it's pointless or anything like that; I just wanted to learn. I see how each subservice is use from this comment, but was just wondering why the processes aren't all activated inside one container. Is it for scalability? I appreciate any help!

[mrjoshuap]

@Yeastdonkey I’m not an expert either, but generally speaking, there are a few functional containers involved.

Given the nature of this project, the decision was likely made to separate workloads into containers. This allows for independent development of web (web), transcoding (celery_worker), notifications (celery_short), and so on. It also enables independent scaling of these components.

I assume you're referring to the environment variables:

      ENABLE_UWSGI: 'no'
      ENABLE_NGINX: 'no'
      ENABLE_CELERY_SHORT: 'no'
      ENABLE_CELERY_LONG: 'no'
      ENABLE_CELERY_BEAT: 'no'

Since mediacms is in a single unit, i.e. this Git repository in a single container image, enabling different parts (like celery_short and celery_long) using environmental “Feature Flags,” we can use that single container image to run different components of the overall architecture, as represented above.

While it’s technically possible to run a single container and enable all the necessary features, it’s usually not worth it. If you make a simple change, you’ll likely need to restart every component. That said, since I much prefer this micro services approach, I've not investigated if there would be any significant roadblocks to running it all in a single container; I'd assume it'd be like a normal single system install with extra steps.

I'll give you an recent example... I have been working on utilizing hardware encoding on Rockchip arm64. It's been a lot of troubleshooting the celery_worker for failed transcoding and other things. Every change I need to make to transcoding is a real quick restart of just the celery_worker container. Since the other components are unaffected, browsing and playback are not impacted. However, important to me is that I don't have to wait for every unaffected component to restart to test one little thing on the affected code.

Hope that helps.