3 ms·

Long story short: Docker with its insistence on magically doing all the network configuration fails to cooperate with anything that is not a Docker. A side not

by dozzie 9y ago

Long story short: Docker with its insistence on magically doing all the network configuration fails to cooperate with anything that is not a Docker. A side note, it's hilarious how Docker users are successfully insulated from networking details and thus don't understand how netfilter works, e.g. the guy who claimed that network traffic stopped going through "filter" table and instead goes through "nat" table.

brudgers 9y ago
To me, Docker has to balance creating a product that is accessible to individual developers by virtue of ease of use with exposing all the gory details of containerization. Or to put it another way, Docker has to pick a level of abstraction over containers somewhere between a black box with a power button and cgroups. The behavior just falls closer to one end of the it-is-not-a-bug-it-is-a-feature spectrum than the other. I mean Bell Labs old Unix hand levels of expertise are great, but the reality of "a good way to do it" should probably be tailored for users more toward the center of the bell curve.
- dozzie 9y ago
  The problem is that Docker hides from its users details about network configuration, the same details that the users should understand and should know about. It's just bound to fail in any scenario other than Docker authors envisoned. All in the name of assumption that the users -- programmers working with network! -- are too dumb to configure network.
  - brudgers 9y ago
    If Docker required users to be fluent in the differences between UFW and IPtables, the user base would be much smaller than it is currently.
    - dozzie 9y ago
      In other words, it's totally OK not to understand what you're working with?
      - brudgers 9y ago
        Because I can't write assembly for an i7 or demodulate 802.11N radio signals, intellectual honesty requires me to say yes.
        dozzie 9y ago
        Do you apply the same approach to other tools? You don't know how to call a compiler? Don't know how to write a set of rules for your build system? Don't know how external libraries are loaded? Because if you work with network, not understanding how to set up a NAT and port forwarding is in the same category as not knowing how module search path works in your chosen runtime. It's not several levels lower, contrary to your missed analogy.
cpuguy83 9y ago
Let me start off by saying yes it's awful that Docker is inserted at the top of the chain. This is a legacy that we'll have to work around to make work with existing rules. However, UFW is an awful iptables citizen as it assumes it is the sole owner of iptables. In general Docker does try to be a good iptables citizen and generally assume that it's not the only thing doing iptables work. The existing behavior where docker sits above everything else in iptables is unfortunate but has been around since forever and is not easy to change without breaking lots of existing installations. Please take a look at https://github.com/docker/libnetwork/pull/1675 https://github.com/docker/libnetwork/pull/1675 as at least a partial solution to this.

by dozzie 9y ago

brudgers 9y ago

To me, Docker has to balance creating a product that is accessible to individual developers by virtue of ease of use with exposing all the gory details of containerization. Or to put it another way, Docker has to pick a level of abstraction over containers somewhere between a black box with a power button and cgroups. The behavior just falls closer to one end of the it-is-not-a-bug-it-is-a-feature spectrum than the other. I mean Bell Labs old Unix hand levels of expertise are great, but the reality of "a good way to do it" should probably be tailored for users more toward the center of the bell curve.

dozzie 9y ago
The problem is that Docker hides from its users details about network configuration, the same details that the users should understand and should know about. It's just bound to fail in any scenario other than Docker authors envisoned. All in the name of assumption that the users -- programmers working with network! -- are too dumb to configure network.
- brudgers 9y ago
  If Docker required users to be fluent in the differences between UFW and IPtables, the user base would be much smaller than it is currently.
  - dozzie 9y ago
    In other words, it's totally OK not to understand what you're working with?
    - brudgers 9y ago
      Because I can't write assembly for an i7 or demodulate 802.11N radio signals, intellectual honesty requires me to say yes.
      - dozzie 9y ago
        Do you apply the same approach to other tools? You don't know how to call a compiler? Don't know how to write a set of rules for your build system? Don't know how external libraries are loaded? Because if you work with network, not understanding how to set up a NAT and port forwarding is in the same category as not knowing how module search path works in your chosen runtime. It's not several levels lower, contrary to your missed analogy.

cpuguy83 9y ago

Let me start off by saying yes it's awful that Docker is inserted at the top of the chain. This is a legacy that we'll have to work around to make work with existing rules. However, UFW is an awful iptables citizen as it assumes it is the sole owner of iptables. In general Docker does try to be a good iptables citizen and generally assume that it's not the only thing doing iptables work. The existing behavior where docker sits above everything else in iptables is unfortunate but has been around since forever and is not easy to change without breaking lots of existing installations. Please take a look at https://github.com/docker/libnetwork/pull/1675 https://github.com/docker/libnetwork/pull/1675 as at least a partial solution to this.