Comment on Should I move to Docker?

• MostlyGibberish@lemm.ee ⁨11⁩ ⁨months⁩ ago

  One of the things I like about containers is how central the IaC methodology is. There are certainly tools to codify VMs, but with Docker, right out of the gate, you’ll be defining your containers through a Dockerfile, or docker-compose.yml, or whatever other orchestration platform. With a VM, I’m always tempted to just make on the fly config changes directly on the box, since it’s so heavy to rebuild them, but with containers, I’m more driven to properly update the container definition and then rebuild the container. Because of that, you have an inherent backup that you can easily push to a remote git server or something similar. Maybe that’s not as much of a benefit if you have a good system already, but containers make it easier imo.

  source

  • Dyskolos@lemmy.zip ⁨11⁩ ⁨months⁩ ago

    Actually only tried a docker container once tbh. Haven’t put much time into it and was kinda forced to do. So, if I got you right, I do define the container with like nic-setup or ip or ram/cpu/usage and that’s it? And the configuration of the app in the container? is that IN the container or applied “onto it” for easy rebuild-purpose? Right now I just have a ton of (big) backups of all VMs. If I screw up, I’m going back to this morning. Takes like 2 minutes tops. Would I even see a benefit of docker? besides saving much overhead of cours.

    source

    • felbane@lemmy.world ⁨10⁩ ⁨months⁩ ago

      You don’t actually have to care about defining IP, cpu/ram reservations, etc. Your docker-compose file just defines the applications you want and a port mapping or two, and that’s it.

      Example:

      ---
      version: "2.1"
      services:
        adguardhome-sync:
          image: lscr.io/linuxserver/adguardhome-sync:latest
          container_name: adguardhome-sync
          environment:
            - CONFIGFILE=/config/adguardhome-sync.yaml
          volumes:
            - /my/appdata/config:/config
          ports:
            - 8080:8080
          restart:
            - unless-stopped
      

      That’s it, you run docker-compose up and the container starts, reads your config from your config folder, and exposes port 8080 to the rest of your network.

      source

      • Dyskolos@lemmy.zip ⁨10⁩ ⁨months⁩ ago

        Oh… But that means I need another server with a reverse-proxy to actually reach it by domain/ip? Luckily caddy already runs fine 😊

        Thanks man!

        source

        • -> View More Comments
• SpaceCadet@feddit.nl ⁨11⁩ ⁨months⁩ ago

  what would I gain from docker or other containers?

  Reproducability.

  Once you’ve built the Dockerfile or compose file for your container, it’s trivial to spin it up on another machine later. It’s no longer bound to the specific VM and OS configuration you’ve built your service on top of and you can easily migrate containers or move them around.

  source

  • Dyskolos@lemmy.zip ⁨10⁩ ⁨months⁩ ago

    But that’s possible with a vm too. Or am I missing something here?

    source

    • twei@feddit.de ⁨10⁩ ⁨months⁩ ago

      If you update your OS, it could happen that a changed dependency breaks your app. This wouldn’t happen with docker, as every dependency is shipped with the application in the container.

      source

      • Dyskolos@lemmy.zip ⁨10⁩ ⁨months⁩ ago

        Ah okay. So it’s like an escape from dependancy-hell… Thanks.

        source
    • uzay@infosec.pub ⁨10⁩ ⁨months⁩ ago

      Apart from the dependency stuff, what you need to migrate when you use docker-compose is just a text file and the volumes that hold the data. No full VMs that contain entire systems because all that stuff is just recreated automatically in seconds on the new machine.

      source

      • Dyskolos@lemmy.zip ⁨10⁩ ⁨months⁩ ago

        Ok, that does save a lot of overhead and space. Does it impact performance compared to a vm?

        source

        • -> View More Comments
• pete_the_cat@lemmy.world ⁨10⁩ ⁨months⁩ ago

  VMs have a ton of overhead compared to Docker. VMs replicate everything in the computer while Docker just uses the host for everything, except it sandboxes the apps.

  In theory, VMs are far more secure since they’re almost entirely isolated from the host system (assuming you don’t have any of the host’s filesystems attached), they are also OS agnostic whereas Docker is limited to the OS it runs on.

  source

  • Dyskolos@lemmy.zip ⁨10⁩ ⁨months⁩ ago

    Ah ok thanks, the security-aspect is indeed important to me. So I shouldn’t really use it for critical things. Especially those with external access.

    source

    • pete_the_cat@lemmy.world ⁨10⁩ ⁨months⁩ ago

      Docker is still secure, it’s just less secure than Virtualization. It’s like a standard door knob lock (the twist/push button kind) vs a deadbolt. Both will keep 90% of bad-actors out but those who really want to get in can based on how high the security is.

      source
• criticalimpact@lemm.ee ⁨11⁩ ⁨months⁩ ago

  Saves time, minimal compatibility, portability and you can update with 2 commands There’s really no reason not to use docker

  source

  • Dyskolos@lemmy.zip ⁨11⁩ ⁨months⁩ ago

    But I can’t really tinker IN the docker-image, right? It’s maintained elsewhere and I just get what i got. But with way less tinkering? Do I have control over the amount/percentage of resources a container uses? And could I just freeze a container, move it to another physical server and continue it there? So it would be worth the time to learn everything about docker for my “just” 10 VMs to replace in the long run?

    source

    • xcjs@programming.dev ⁨11⁩ ⁨months⁩ ago

      You can tinker in the image in a variety of ways, but make sure to preserve your state outside the container in some way:

      1. Extend the image you want to use with a custom Docker file
      2. Execute an interactive shell session, example docker exec -it containerName /bin/bash
      3. Replace or expose filesystem resources using host or volume mounts.

      Yes, you set a variety of resources constraints, including but not limited to processor and memory utilization.

      There’s no reason to “freeze” a container, but if your state is in a host or volume mount, destroy the container, migrate your data, and resume it with a run command or docker-compose file. Different terminology and concept, but same result.

      It may be worth it if you want to free up overhead used by virtual machines on your host, store your state more centrally, and/or represent your infrastructure as a docker-compose file or set of docker-compose files.

      source

      • Dyskolos@lemmy.zip ⁨10⁩ ⁨months⁩ ago

        Hm. That doesn’t really sound bad. Thanks man, I guess I will take some time to read into it. Currently on proxmox, but AFAIK it does containers too.

        source

        • -> View More Comments