4 ms·

> I think you could reimplement [some random part of what Docker does] easily yourself with a small shell script and some calls to mount; but I haven't bothered

> I think you could reimplement [some random part of what Docker does] easily yourself with a small shell script and some calls to mount; but I haven't bothered. Exactly.

majewsky 8y ago
Bonus round: > For most purposes, the main interesting thing that Docker containers provide is isolated networking. [...] What else prevents applications from using ports? The firewall that you already have installed on your server. Again, pointless abstraction to address already-solved problems. Comically missing the point.
- geggam 8y ago
  until you realize the firewall is the same iptables that you use to isolate the network in docker containers
  - ecnahc515 8y ago
    Not at all. IP tables is used to route traffic between containers, yes, but the isolation is done by network namespaces.
    - geggam 8y ago
      Interesting... so you create a network and isolate it from the rest of the network ? How do your applications serve traffic ? Or... you create a network with namespaces and use iptables aka the firewall to network that to the other networks you created with namespaces ? Think about it logically... when you use TCP you share the connections... your namespace isolation is exposed by the very thing that firewalls it... make sense ?
nazka 8y ago
I remember seeing that here actually. Docker in 100 lines of code. https://github.com/p8952/bocker https://github.com/p8952/bocker
catern 8y ago
This time around, everyone keeps excerpting this sentence. I guess what people are making of this sentence is, "but I haven't bothered [to reimplement this functionality, even though it would be useful, since then I'd have to maintain it, and I haven't yet needed it]". If that's what the sentence meant, then that would certainly be a good argument that Docker is useful: it provides the missing pieces that no-one else has bothered to implement yet. Unfortunately that's not what I meant when I wrote the sentence, and I think a more accurate reading is transparently obvious if you actually quote the sentence with context. The very next sentence describes my preferred way to get this functionality that Docker provides. The real reading of the sentence is "but I haven't bothered [to reimplement this functionality, because it would be useless to do so when there are perfectly good existing ways to get this functionality]". Quoting people out of context is a great way to get punchy soundbites, but not a good way to reach mutual understanding. I'll excerpt the entire section below: > Now, it's true that Docker uses layering to be efficient in terms of disk space and time to build new containers. It defaults to using AUFS to do this.7 I think you could reimplement it easily yourself with a small shell script and some calls to mount; but I haven't bothered. > Personally, I just use man 8 btrfs-subvolume. btrfs is a copy on write filesystem which can instantly make space-efficient copies of filesystem trees in "subvolumes", which the user sees as just regular directories. > You can build a stock Ubuntu filesystem tree into a subvolume with btrfs subvolume create /srv/trees/ubuntu && debootstrap trusty /srv/trees/ubuntu/. Then, when you want to build a new container with specific software, you just copy that subvolume and perform your modifications on the copy; that is, btrfs subvolume snapshot /srv/trees/debian /srv/containers/webapp and work on /srv/containers/webapp. If you want to copy those modifications, you just take another snapshot. > This is arguably better, because there's no need to maintain a lot of state about the mount layerings and set them up again on reboot. Your container filesystem just sits there in a volume waiting for you to start it. > Naturally, if you don't like btrfs for some reason, you're perfectly able to use zfs, OverlayFS, AUFS, or whatever; no need to have a "storage driver" implemented just to do some simple copy-on-write or layering operations.

> I think you could reimplement [some random part of what Docker does] easily yourself with a small shell script and some calls to mount; but I haven't bothered. Exactly.

majewsky 8y ago

Bonus round: > For most purposes, the main interesting thing that Docker containers provide is isolated networking. [...] What else prevents applications from using ports? The firewall that you already have installed on your server. Again, pointless abstraction to address already-solved problems. Comically missing the point.

geggam 8y ago
until you realize the firewall is the same iptables that you use to isolate the network in docker containers
- ecnahc515 8y ago
  Not at all. IP tables is used to route traffic between containers, yes, but the isolation is done by network namespaces.
  - geggam 8y ago
    Interesting... so you create a network and isolate it from the rest of the network ? How do your applications serve traffic ? Or... you create a network with namespaces and use iptables aka the firewall to network that to the other networks you created with namespaces ? Think about it logically... when you use TCP you share the connections... your namespace isolation is exposed by the very thing that firewalls it... make sense ?

nazka 8y ago

I remember seeing that here actually. Docker in 100 lines of code. https://github.com/p8952/bocker https://github.com/p8952/bocker

catern 8y ago

This time around, everyone keeps excerpting this sentence. I guess what people are making of this sentence is, "but I haven't bothered [to reimplement this functionality, even though it would be useful, since then I'd have to maintain it, and I haven't yet needed it]". If that's what the sentence meant, then that would certainly be a good argument that Docker is useful: it provides the missing pieces that no-one else has bothered to implement yet. Unfortunately that's not what I meant when I wrote the sentence, and I think a more accurate reading is transparently obvious if you actually quote the sentence with context. The very next sentence describes my preferred way to get this functionality that Docker provides. The real reading of the sentence is "but I haven't bothered [to reimplement this functionality, because it would be useless to do so when there are perfectly good existing ways to get this functionality]". Quoting people out of context is a great way to get punchy soundbites, but not a good way to reach mutual understanding. I'll excerpt the entire section below: > Now, it's true that Docker uses layering to be efficient in terms of disk space and time to build new containers. It defaults to using AUFS to do this.7 I think you could reimplement it easily yourself with a small shell script and some calls to mount; but I haven't bothered. > Personally, I just use man 8 btrfs-subvolume. btrfs is a copy on write filesystem which can instantly make space-efficient copies of filesystem trees in "subvolumes", which the user sees as just regular directories. > You can build a stock Ubuntu filesystem tree into a subvolume with btrfs subvolume create /srv/trees/ubuntu && debootstrap trusty /srv/trees/ubuntu/. Then, when you want to build a new container with specific software, you just copy that subvolume and perform your modifications on the copy; that is, btrfs subvolume snapshot /srv/trees/debian /srv/containers/webapp and work on /srv/containers/webapp. If you want to copy those modifications, you just take another snapshot. > This is arguably better, because there's no need to maintain a lot of state about the mount layerings and set them up again on reboot. Your container filesystem just sits there in a volume waiting for you to start it. > Naturally, if you don't like btrfs for some reason, you're perfectly able to use zfs, OverlayFS, AUFS, or whatever; no need to have a "storage driver" implemented just to do some simple copy-on-write or layering operations.