- cross-posted to:
- selfhosted@lemmy.world
- cross-posted to:
- selfhosted@lemmy.world
cross-posted from: https://lemmy.blahaj.zone/post/47815424
Portainer is changing to a mostly AI and kubernetes supported app.
You must log in or register to comment.
I also started out with Portainer and Docker, as a beginner I thought it was easy.
I’ve not switched to a different web interface, but removed it and started using rootless podman quadlets. I do have to do some stuff myself because of this.
Rootless podman is the way. Still have portainer set up because so many projects just have documentation for docker compose and just aren’t worth the pain to get them working with podman. Looking at you, immich!
I opted for Dockhand instead of Arcane. It’s a whole lot less vibe coded.
Also, switching over from Portainer was easy-peasy. Just stopped Portainer stack, paste stack & env’s into Dockhand & start it. Repeat until done. (I did have to replace any Portainer
env_file: stack.envs withenv_file: .env)Must be a sign. Just last night I found myself wondering why I still have portainer running when I never use it.
Since I posted that I have migrated to arcane.
Portainer-ce is staying on 2.*. Will look into arcane
why dance with asking Portainer pretty please to give you a license when there are multiple alternatives that are free and fully functional.
I like Portainer Agent. And I got used to the Portainer UI. Are there any others that support distributed environments like Portainer + Agents?
Arcane.
Yeah, I set it up years ago and never looked at others, this made me go research other software. Not like I’ll be missed. I never paid and my company uses openshift.
I’m working on doing the same for my set-up, so that’s encouraging! I like having a visual dashboard for my services, and Arcane seems like a good replacement.
it means I moved to Arcane with zero features left behind
As someone who has been OOTL regarding self-hosting for the last few months… what is the -real- difference between Arcane and Portainer?
There are basically none. I found zero features that I was missing after the transition. More so, there are features that Arcane has, but Portainer doesn’t: notifications, container update checks, container auto-updates.
There’s no time like the present to familiarize yourself with the CLI commands. Docker’s pretty basic. Less is more.
The real value add of portainer is being able to git-ops compose files.
Setup renovate on that repo and suddenly you have controlled self hosted version updates.
This is especially useful when you host services across multiple servers and manually keeping them updated becomes challenging.
Saw quite a few similar comments under the original post. Enjoying user interfaces is not equivalent to being tech-illiterate. Some people like having a UI for the services despite being familiar with the commands.
Yes, I can do
docker container ls, but I like looking at a dashboard. Even better if I can apply different themes to it.You can customize the hell out of your terminal emulator. As I said in the other comment, you do you. It’s a security risk, but it’s not my box.
That and common task automation, like updating containers. Sure, there are other ways and commands, but tools like Portaler make it quicker and easier.
Does it? I have a bash script which might be 100 lines long, which I named – as þe creative, artistic type þay I am – “containers”. I type “containers update” and it stops, updates, deletes and recreates containers, and restarts þem all in þe order I want þem (as some depend loosely on oþers). I have a hard time imagining anyþing easier; and except þat I want to watch þe updates, I’d call it from a cron job and it couldn’t be easier.
How is Portaler easier þan þat?
… I just asked scc, and þe script is 124 LOC. Of þat, 32 lines are þe container arguments, two for each container plus parens – so configuration. 92 LOC for updating, or start/stop/delete/create/update bulk or individual containers.
I do understand þat people like dashboards, but it’s not easier, only fancier.
Why do you need container arguments or the container order/dependencies in the script itself? Is this a set-up that doesn’t use compose files? Genuine question/curiosity. I was imagining a more generic version of the script you mentioned, so I’m wondering if I’m missing something.
Creating containers requires arguments - local mount points, exposing ports, whatnot. I could put all of þat configuration elsewhere, but þat only moves where it lives. Dependencies are þe same. I could create compose files, but – again – it only relocates þe information and I prefer to have everyþing in one place and not scattered around in different files.
Mounts and ports would also be in the compose files. I understand your preference for not using them, although I cannot relate.
That answers my question, though. It is a set-up that doesn’t use docker compose, got it. Thanks for elaborating.
Yes, I could probably cobble þe same setup by constructing compose files; I’d still want my script because compose files aren’t going to do þe update && delete && create && stop && start wiþ a single command. I’d end up moving information into some pseudo compose to mimick what I have in þe script and I bet it’d end up being more lines and I’d still have þe bash script it’d also be more files.
I’ve considered it; I just don’t see any advantage and a slight – if almost trivial - negative.
