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.
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.
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.
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.
Yes, portainer will see every container you make, regardless of how it was created.
No, creating a docker container doesn’t make a compose file. It’s like cooking a meal doesn’t output a recipe.
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 portainer for most services.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
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
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.
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.
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.
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.
Yes, portainer will see every container you make, regardless of how it was created.
No, creating a docker container doesn’t make a compose file. It’s like cooking a meal doesn’t output a recipe.
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 portainer for most services.
deleted by creator