I am trying to plan my home lab to satisfy two different needs:

  1. I want a stable environment where I will put a relatively expensive NAS and maybe some other Zima boards.
  2. I also want to try new versions and configurations in an env where I can break stuff BEFORE trying things on my Production environment. I would also like to use that environment to try other things like playing with Kubernetes, Docker, Iceberg, etc. I am a backend software engineer so this is very useful to me. Besides being fun.

So, I am just trying to gather ideas on how to configure this both in terms of software and hardware.

  • Campers@lemmy.worldOP
    link
    fedilink
    arrow-up
    1
    ·
    1 day ago

    No. I really need Production to be stable because other people will be using it. And I do not want my own playing around to cause issues.

    I am really considering both @[email protected] idea of a smaller NAS from the same company and @[email protected] idea of just creating a new volume in the same NAS.

    • just_another_person@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      1 day ago

      Well the NAS itself isn’t the integration point is what I’m saying, the data is, right? So have a folder on your NAS for staging, and another for production, and make the connection to that data the integration point that is accounted for in your dotenv or whatever you’re planning on using to control this

      The only downside there is the single point of failure being the NAS, but having two separated NAS boxes by environment won’t solve for a production outage anyway because each environment still has a single point of failure even if you have two NAS.

      Just get it running as above first. Figure out that actual breaking points in your flow after using it for awhile.

    • killeronthecorner@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 day ago

      If you’re very concerned just have your prod environment and kick up test services in docker containers and test your tweaks and changes there.

      Doing this ad-hoc will be easier and more practical than trying to maintain two full environments like you’re a series B startup finding it’s feet!

      • just_another_person@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        1 day ago

        That will have a host of other issues that is not super fluid to work with while trying to maintain similar environments. Most notably the networking.

        • killeronthecorner@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 day ago

          If this causes networking issues, your setup is already too complicated to manage through a flat set of docker containers. That’s not a bad thing, this just isn’t the horse for that course so to speak.

          • just_another_person@lemmy.world
            link
            fedilink
            arrow-up
            1
            ·
            1 day ago

            Not causing network issues, but for a layman that isn’t familiar with managing multiple environments already, controlling a multi-env containerized environment is going to be a nightmare if solely just using containers as a staging environment. It doesn’t map to what his prod env (non-container) would be, and it’s not going to catch problems which would arise from his prod environment anyway if looking at from an integration standpoint.