41
Portainer 3.0 is coming, and here's what it means for you — Portainer (portainer.io)
submitted 1 month ago by to c/selfhosting@slrpnk.net
29 comments fedilink hide all child comments
 

Portainer is changing to a mostly AI and kubernetes supported app.

you are viewing a single comment's thread
view the rest of the comments
[–] [S] 10 points 1 month ago* (last edited 1 month ago) (7 children)

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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 3 points 1 month ago (5 children)

    That and common task automation, like updating containers. Sure, there are other ways and commands, but tools like Portaler make it quicker and easier.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] -4 points 1 month ago (4 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] [S] 3 points 1 month ago* (last edited 1 month ago) (3 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] -4 points 1 month ago (2 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] [S] 4 points 1 month ago* (last edited 1 month ago) (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] -3 points 1 month ago*

    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.

  • permalink
  • fedilink
  • source
  • parent