[deleted]

Comments

• AMillionMonkeys@lemmy.world ⁨1⁩ ⁨year⁩ ago

  I use Portainer mainly to start / stop / restart containers without the mental load of using the command line. It works fine with Compose if you can get (or write) a yaml file for the container you’re interested in, or you can use it to pull from the repository and set everything up if you can’t. Portainer also gives you a nice, one-stop view of the current state of your containers. Basically, it can’t hurt to have it around.
  Personally, my favorite Docker management GUI is the one that comes with Synology NASes. It’s much less clunky that Portainer and iirc a little more powerful. But of course it only runs in their hardware.

  source
• Voroxpete@sh.itjust.works ⁨1⁩ ⁨year⁩ ago

  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.

  source
• muntedcrocodile@lemm.ee ⁨1⁩ ⁨year⁩ ago

  I don’t like portainer, you’ll learn more by not using it. I just set everything up using compose files and then I have a start script to start them all in case my server goes down. You can check out my setup here.

  source
• CHOPSTEEQ@lemmy.ml ⁨1⁩ ⁨year⁩ ago

  My actual professional advice: cut portainer out of your learning. Stick to compose as your only docker abstraction and you’ll be a wizard in no time. I have portainer running in my sea of self hosted apps and never use it. If you let some app generate compose files for you, or even just blindly use an app’s example compose file, you’ll never fully understand what’s happening and it’ll make things much more difficult to debug.

  4: yes, every container will show up in portainer. 5: I don’t know 6: this is one of the reasons why I personally hate piling layers onto tools. Very often someone else’s opinion does not jive with mine.

  source
• Bassman1805@lemmy.world ⁨1⁩ ⁨year⁩ ago

  4. Yes, portainer will see every container you make, regardless of how it was created.

  5. No, creating a docker container doesn’t make a compose file. It’s like cooking a meal doesn’t output a recipe.

  6. You can save the compose file(s) wherever you want, you just need to run “docker compose up” from that directory. If you make the container within portainer, I believe it stores the compose files in its own volume. Not sure about that, I keep my compose file separate from docker for most services.

  source