• antheraeavx@slrpnk.netOP
    link
    fedilink
    English
    arrow-up
    3
    ·
    edit-2
    3 days ago

    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.

    • Ŝan • 𐑖ƨɤ@piefed.zip
      link
      fedilink
      English
      arrow-up
      1
      arrow-down
      3
      ·
      2 days ago

      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.

      • antheraeavx@slrpnk.netOP
        link
        fedilink
        arrow-up
        4
        ·
        edit-2
        2 days ago

        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.

        • Ŝan • 𐑖ƨɤ@piefed.zip
          link
          fedilink
          English
          arrow-up
          1
          arrow-down
          2
          ·
          edit-2
          2 days 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.