7 ms·

What I don't like about Docker is that it spews stuff all over the place. After installation, it is constantly running. As can be seen by: ps aux | grep d

• loloquwowndueo 3y ago
  Systemd-nspawn or LXD/Incus are also alternatives. LXD user experience is pretty good.
  • leosanchez 3y ago
    I liked LXD from the limited time I spent on it. Do you know any resources to learn it a bit more in depth ?
    • Grimburger 3y ago
      Reading this makes me concerned as someone who loves LXD, because when you reflect on it there's not really that much for newcomers besides some blog posts or a "fail and ask on the forums" model which clearly isn't optimal for some learning styles. It's a probably a misstep by the linux containers ecosystem, I do hope Incus can improve on this.
      • goku12 3y ago
        LXD official online documentation (now hosted by Canonical) is the sole resource I needed to set it up and use it. The CLI concepts and commands are designed well enough and is intuitive. The only outside resource I had to read was for some privileged containers running K8s inside.
  • bongobingo1 3y ago
    I feel like LXD shot them selves in the foot with terminology. When ever I got interested I would get confused between LXC and LXD and lxc the command (part of LXD) and lxd the command. Now its even muddier with Canonical ... taking back (?) LXD. Throw in the alternative vision (LX* containers are more like persistent VMs than ephemeral containers) and a lack of `<container-engine> pull app` and all that entails re: DevX and DeployX, it always felt like a mountain to get going.
    • goku12 3y ago
      The team behind Incus (the fork of LXD) is working on that problem. They have decided on unambiguous names and have even rearranged some commands to make it consistent and clear.
    • rascul 3y ago
      > `<container-engine> pull app` Is quite doable with lxc. An application container can be built and shared. It doesn't appear to be typically done, though.
• unmole 3y ago
  Depending on what you need, either podman or systemd-nspawn.
• pierrelf 3y ago
  Have you tried podman? I've been quite happy using it on my fedora laptop, seems less finicky than Docker and their compose plugin has gotten much closer to docker-compose
  • usr1106 3y ago
    podman is pretty good. However, it is more secure than docker by default, so with more complicated images benefiting from docker's "containers do not contain" properties things tend to break.
• salzig 3y ago
  Even VM will need an IP-address-space shared with the host so you can access them. That’s not a docker/container problem. Btw, you‘re able to configure the Ip-space to use by passing an argument to the daemon or change it in daemon.json.
  • indigo945 3y ago
    Most VM hypervisors allow the creation of virtual networks that are only visible to the VMs on the network, not to the host. The connection of the host to the virtual network is an extra step involving a TAP driver that translates between the host OS and the hypervisor process. Obviously, the virtual networks themselves, when the TAP driver is not loaded, are not going to mess with the host's routing configuration like a (normal, rootful) docker deployment would, by virtue of being invisible to the host's networking stack. Also, yes, it is a docker problem in particular. Linux has a solution for virtualizing networking for a subset of processes only: network namespaces. Docker doesn't use them by default, but can be taught to do so with the rootless kit. All rootless container engines use them by default.
  • guerby 3y ago
    ssh user@fe80::xxx%tapvm as long as ipv6 link local are not disabled the fe80 addresses work nicely :)
• indigo945 3y ago
  Podman is probably close to what you want. It runs "daemonless" - while no containers are running, podman doesn't have a running process either. Also, as long as the containers are run in rootless mode, podman creates no virtual network interfaces. Rootless Podman makes use of network namespaces instead to separate the processes in the container from the host network. Processes on the host cannot see Podman's network namespaces and therefore are completely unaffected by any IP configuration therein.
  • irusensei 3y ago
    I find Podman frustrating at times because of how strict is with ACLs, UID maps and its integrations with SELINUX. I've had a chown/chmod -R of my own home folder (for migration purposes) cripple all podman (AND toolbox) related stuff for my user. All in all its a great program and IMO even better than docker but It would be great if people try to make it sound like its a 1:1 comparison to Docker because it has its trade offs.
    • pjmlp 3y ago
      Security is a pain, however cleaning up after the fact is even worse.
    • deleted 3y ago
      [deleted]
    • amluto 3y ago
      I would argue that the selinux and uid issues with podman are selinux and posix DAC’s fault. Selinux is neat but is IMO conceptually wrong in a container world. UIDs and are barely better. At most, these mechanisms should confirm that the container as a whole has a given permission, and that’s it. (Seriously, the major clouds have deprecated per-object permissions on their object stores. IMO they are right to have done so.)
    • nicce 3y ago
      It might feel frustrating, but there is a great reason. It gives you a more secure environment. When Docker just "works", you are unaware of the fact that you have given more permissions than app might actually need, increasing the attack vector. Podman's use of SELinux prevents and mitigates many of these issues what you will have if somone targets your app.
• fiddlerwoaroof 3y ago
  It’s a steep learning curve, but I find nix basically solves all the parts of these problems for me that I want solved (without things like network namespaces that just make life harder) and it’s easy to turn a working nix build into a container for deployment.
  • mongol 3y ago
    I don't think Nix solves security concerns as well as other distributions do. It excels in most ways but this is the weakest point.
    • k8svet 3y ago
      Nix isn't an OS and NixOS does "security concerns" just as well as any other distro. I'm really struggling to understand what you mean. Nix itself doesn't have any runtime sandboxing, but that's no different than using distro packages on any other distro. Meanwhile you can still use Flatpaks, docker, podman, kvm/libvirt, etc, just like on any distro.
      • endgame 3y ago
        As great as Nix is, a security update to something like glibc will necessitate a rebuild of the entire universe as a necessary consequence of its "immutable, hashed inputs" model. Guix has a feature called "grafts" that avoids some of this pain, but compromises the purity of the functional packaging model to do so.
        • SkyMarshal 3y ago
          But Nix rebuilds are cheap and fast, what’s the problem?
          • ochoseis 3y ago
            Plus they can be easily cached so you only ever have to do it once, and the result is available to your whole fleet.
• m90 3y ago
  The ICE Wifi is using very exotic IPs for their gateway here, so this is not really Docker's fault. For reference, this can be worked around by deleting your Docker networks, logging in and recreating the networks, which should pose no problems on a dev machine.
  • pseg134 3y ago
    Why would docker even need to be running if no containers are running? It is 100% dockers fault, it is a bad design choice.
    • usr1106 3y ago
      That's an irrelevant argument. Why should the grandparent not be able to use a container on the train?
      • goku12 3y ago
        It's not that irrelevant, considering that podman managed to solve both problems - necessity of a daemon and keeping the default network namespace clean. That said, I don't want to take away the credit of Docker being the pioneers in their field (yes it existed before. But it wasn't this popular).
        • insanitybit 3y ago
          Isn't Podman only able to do this because of user namespaces, which are a very recent addition to Linux? I wonder how Podman will do, if that's the case, now that user namespaces are being turned off by default due to their security implications.
          • goku12 3y ago
            I always thought containerization - including docker - was the result of Linux namespaces (more so than even cgroups). Checking again, Linux namespaces were introduced in 2002. Docker was released more than a decade later - in 2013. I believe that Docker always used namespaces - that's how they achieved process isolation. But they didn't use it to its full potential initially - including network namespaces and pods.
• cabirum 3y ago
  Disable the docker.service unit but don't disable docker.sock. Docker won't be running at startup but will transparently start on first invokation. Configure daemon address pools in case they conflict/intersect with real network addresses.
• usr1106 3y ago
  The root cause is the ridiculously small private address space in IPv4. Conflicts have a non-negligible probability. You might even want to use a container on the train, so the daemon is not the root cause of problems in this case. Using IPv6 would have reduced the probability a lot. But the excuse for the last 20 years has been, why bother with learning something new as long as "it works for me"... (I don't claim I would do differently.)
  • mort96 3y ago
    I mean the "excuse" as you call it is more, "why bother with learning something which doesn't work when I could use the thing which works, even if it's imperfect". I'd bet the train wifi doesn't support IPv6.
  • belthesar 3y ago
    I won't address the IPv6 landmine here, because that is its own can of worms, and there are plenty of real, legitimate criticisms for not adopting it. That aside, while I do agree that small private IPv4 space availability is a real concern, I'd also argue that Docker choosing to make the default network size a /16 compounds this problem significantly. I've never had a workflow where a Docker network needed more than a /24, and most could get away with a /26 or /27 without it being considered an aggressive limitation of IP space. Assigning the default Docker network size to something much more reasonable for a development context would do wonders for limiting collisions like this in the first place.
  • mccoyc 3y ago
    I agree. It absolutely is IPv4. Hosts could use DHCPv6 with prefix delegation (DHCPv6-PD), and use that delegated /64 for its internal Docker bridge and get rid of NAT. And yes, you can still have your Netfilters stateful packet filtering in place! People are going through so much pain because they won't embrace the tools IPv6 gives you! This solution is 20 years old. God help you if your network is actually using 172.17.0.0/16. grumble grumble get off my lawn, kids.
• wkat4242 3y ago
  If you're not bound to Linux, FreeBSD's jails are excellent.
• lijok 3y ago
  I find this take so interesting. Here's a tool so faultless your biggest gripe with it is some obscure interaction 99.99% of people wont even be aware of, and you want to replace the tool because of it. This would be the equivalent of me buying a great car and disliking the fact that when you pull the carpets up there's a hard to reach clip that needs to be undone, so I decide to sell it and get a different car. I see this happen with all great tools. It irons out all the important kinks, and people still find some obscure reason to fault the tool enough to switch. (To be clear, I am aware Docker has issues beyond what GP is dealing with) (Apologies for the strong tone of the comment, it's not intended, but could not find a better way to word it)
  • NhanH 3y ago
    That is not an obscure issue. The common manifestation is breaking iptables rule (with expose port) and messing up software firewall has caused a lot of wasted hours and security issues.
    • insanitybit 3y ago
      And yet the example they chose was "It broke wifi on a train's shitty network"
      • codetrotter 3y ago
        Docker uses 172.17.0.0/16 subnet range by default. There is nothing shitty about the network on the train for also using this same IP address range. https://en.wikipedia.org/wiki/Private_network https://en.wikipedia.org/wiki/Private_network 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 You might be used to seeing addresses from 192.168.0.0/24 and 192.168.1.0/24 in home networks, and addresses from 10.x.y.0/24 in corporate internal networks. But all of 172.16.0.0/12 has exactly the same kind of purpose as do 10.0.0.0/8 and 192.168.0.0/16. The people that set up the network on the train did nothing wrong for using a subnet of 172.16.0.0/12.
        • justin_oaks 3y ago
• spandextwins 3y ago
  That would be a pickac error.
• deleted 3y ago
  [deleted]
• webstrand 3y ago
  I ran into the same issue. I've mapped docker to the 0.0.0.0/8 subnet which nobody uses. And before that I was using the 169.254.0.0/16 subnet which I've never actually needed for its real purpose.
• nunez 3y ago
  dockerd should be the only process running if no other containers are running. You can also have containers use host-mode networking (share's the host's NICs instead of using bridged networking via virtual NICs) if local IP address pollution is a concern. Kata is just a container runtime. Depending on how they implement their network and storage drivers, functionality should be mostly the same.
• throwawaaarrgh 3y ago
  > So I am looking for a cleaner container solution You need to understand what containers are first. Containers are not one thing. They are an amalgam of different OS primitives designed to give you the maximum flexibility, control, and isolation for an application environment. When you say Docker is "cluttering" your system with processes, you mean the daemon that is used to start and manage containers on your system. There are alternative container systems that don't use a daemon, and can run rootless, but they have some tradeoffs. They are also not nearly as portable or easy to use as Docker, as a whole. Yes, it "occupies" IP space, by default. You can disable or reconfigure the networking aspect of container solutions, to either use a different subnet, or just use the host's native networking. But then you won't get network isolation for your containerized app, and you will probably complain that you can only run one process on a given port at a time, and without a firewall, people on the train will be attacking your containerized apps. > So I am looking for a cleaner container solution. There isn't such a thing as clean software. People like to generalize like this, but what it usually means when they say "clean" is "I want it to be magic, as simple as possible, do everything I could ever want, and to not have to think about it". Which is wanting to have your cake and eat it too. Either it does everything for you and it's complex, or you have to get your hands a little dirty and it's simple. > One that feels more like a Linux tool that keeps the system intact Point in case: you want it to maintain the system for you.. Docker does that. The end result is what you call "clutter". > and only runs when it runs. You want a rootless daemonless container frontend, like Podman. Good luck getting it to work... Don't @ me when you find out it's a lot of extra effort that doesn't give you anything better than Docker did. Kata containers is for service providers. Nobody really needs that level of isolation on their laptops.
  • smarkov 3y ago
    > and without a firewall, people on the train will be attacking your containerized apps. I was surprised when I learned this but Docker by default bypasses UFW and potentially other firewalls relying on iptables. https://blog.viktorpetersson.com/2014/11/03/the-dangers-of-ufw-docker.html https://blog.viktorpetersson.com/2014/11/03/the-dangers-of-u...
• olddustytrail 3y ago
  It doesn't "spew stuff all over the place". Docker runs as a service. It's like complaining that after you install nginx it's constantly running. And it occupies port 80! Yeah, that's the service you installed. Stop the service if you don't want it running.