• 0 Posts
  • 14 Comments
Joined 2 years ago
cake
Cake day: July 7th, 2023

help-circle


  • Your specific questions have already been answered elsewhere in this thread, but I just want to add my usual plea to not use Portainer.

    I’ve spent a lot of time with Portainer, both in my homelab and at work, and in both environments I eventually replaced it with Dockge, which is far superior, both for experienced users and newbies.

    Basically, the problem with Portainer is that it wants you to be in an exclusive relationship with it. For example, if you create containers from the command like like you described, Portainer only has very limited control over them. Dockge, on the other hand, is very comfortable switching back and forth between command line and UI. In Portainer when you do create your compose files from the UI, it then becomes very difficult to interact with them from the command line. Dockge doesn’t give a shit, and keeps all the files in an easy location you choose.

    Dockge will also do what you described in 5) take a docker command and turn it into a compose file. And it gives you much better feedback when you screw up. All in all its just a better experience.




  • There’s no good answer to that because it depends entirely on what you’re running. In a magical world where every open source project always uses the latest versions of everything while also maintaining extensive backwards compatibility, it would never be a problem. And I would finally get my unicorn and rainbows would cure cancer.

    In practice, containers provide a layer of insurance that it just makes no sense to go without.


  • Personally, I always like to use containers when possible. Keep in mind that unlike virts, containers have very minimal overhead. So there really is no practical cost to using them, and they provide better (though not perfect) security and some amount of sandboxing for every application.

    Containers mean that you never have to worry about whether your VM is running the right versions of certain libraries. You never have to be afraid of breaking your setup by running a software update. They’re simpler, more robust and more reliable. There are almost no practical arguments against using them.

    And if you’re running multiple services the advantages only multiply because now you no longer have to worry about running a bespoke environment for each service just to avoid conflicts.







  • The practical limit to the number of containers you can run on one system is in the high hundreds or more thousands, depending on how you configure some things, and your available hardware. It’s certainly more than you’ll even use unless you get into some auto-scaling swarm config stuff.

    The issue is more about resource limits, and access to shared resources. I’d start by trying to figure out if there are certain specific containers that don’t play well together. Bring your setup online slowly, one container at a time, and take note of when things start to get funky. Then start testing combinations of those specific containers. See if there’s one you can remove from the mix that suddenly makes things more stable.