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.
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.
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.
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.
deleted by creator
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.
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.