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
[–] 3 points 1 month ago (12 children)

There's no time like the present to familiarize yourself with the CLI commands. Docker's pretty basic. Less is more.

  • permalink
  • fedilink
  • source
  • hideshow 12 child 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
  • [–] 4 points 1 month ago (3 children)

    i can manage my lab entirely by cli just fine.

    i also like having it visually on a gui

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

    I understand a GUI can be nice to look at, but it can also be a security risk. More permissions, more attack surface. It's largely an unnecessary addition. But you do you. It's not my box. I'm trying to migrate from docker to rootless podman. It's been on my to-do list for quite awhile. There's only so much segregating you can do with a rootful daemon.

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

    You can run rootless Podman with Portainer, I do too. Or used to, before ditching Portainer.

    Can you elaborate on the ways a home lab is less secure if it runs a container management GUI? I'm open to learning more about it. What additional permissions does a GUI inherently require?

    Most companies I worked at used OpenShift in production, and I do not think it was considered an attack vector more than any other components of the ecosystem were. I would be surprised if this was a major factor when it came to security incidents.

    I don't think that container privilege escalation vulnerabilities are correlated to the use of a GUI. To me, it is not a significant (or otherwise unique) risk. Even less so when we're talking about a home lab that is only accessible via a VPN.

    Now, is it unnecessary? Sure, but then so is running Jellyfin or lighting a scented candle.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 1 month ago

    Well, I learned something new. I didn't know Portainer supported Podman. I guess it shouldn't be that surprising, Cockpit does as well.

    Any time you're giving software access to your system you're increasing attack surface. Even with podman, if you're running containers properly, the containers have separate users, so your management system is most likely going to need root access. Or at the very least a common group which makes the segregation a moot point.

    This topic is always going to be highly personal. Some care, some do not. If you're only running a media server, then who cares if it's all lost, but if you're also hosting all your photos, sensitive documents, etc... It becomes a huge risk for everything to mingle with root access. I can't imagine anyone would want a third party hanging out behind their firewall regardless.

  • permalink
  • fedilink
  • source
  • parent