6 ms·

Does anyone else just bind Docker containers to specific ports and/or group of ports on the same interface thereby not needing to care about what IP address eac

Does anyone else just bind Docker containers to specific ports and/or group of ports on the same interface thereby not needing to care about what IP address each container thinks it is?

KirinDave 12y ago
That only makes sense in small deployments where you aren't multihomed. What's frustrating is that I don't think Docker currently has an elegant way to make you not care if the remote service is local or not. What'd be interesting is if there was a special tun interface for that kind of communication and you could bind that to local containers or just dump the traffic back onto your LAN, NAT'd to a remote host.
- opendais 12y ago
  Eh, I think it makes sense for any service/app setup where every server with docker containers has an identical quantity of services running on it, when the server is healthy. At that point, you aren't really doing anything different than you were before with managing servers & load balancing. I don't care if I have 1 app server or 10,000 app servers as long as they are functionally identical and interchangeable. One of them loses a container? Restart the container. That fails? Kill the instance and rebuild.
  - KirinDave 12y ago
    It seems rare to me that there are systems in normal app deployment where there is NO remote shared state between app (and therefore physical) nodes. Given that, your production deploy will almost always have at least a few datacenter-local remote resources. Besides compute and indexing farms, what sort of deploys demonstrate that pattern?
    - opendais 12y ago
      I don't use Docker for anything that stores state. I store it in a separate pool of servers that are solely for database nodes. At which point, I'm back to the "Service Discovery does not require a Docker-aware design." I think the issue here is I'm used to different assumptions than other people. I virtualize application/service containers. I don't virtualize the datastores but run those on bare metal whenever possible. So it goes LB -> pool of docker containers -> Database Cluster(s). The database cluster(s) are known in advance and are restored to the same DNS location when they are revived/moved/transferred. [e.g. I have a cluster of 5 DB servers, they are always something like galera1-servicegroup through galera5-servicegroup, or whatever]

Does anyone else just bind Docker containers to specific ports and/or group of ports on the same interface thereby not needing to care about what IP address each container thinks it is?

KirinDave 12y ago

That only makes sense in small deployments where you aren't multihomed. What's frustrating is that I don't think Docker currently has an elegant way to make you not care if the remote service is local or not. What'd be interesting is if there was a special tun interface for that kind of communication and you could bind that to local containers or just dump the traffic back onto your LAN, NAT'd to a remote host.

opendais 12y ago
Eh, I think it makes sense for any service/app setup where every server with docker containers has an identical quantity of services running on it, when the server is healthy. At that point, you aren't really doing anything different than you were before with managing servers & load balancing. I don't care if I have 1 app server or 10,000 app servers as long as they are functionally identical and interchangeable. One of them loses a container? Restart the container. That fails? Kill the instance and rebuild.
- KirinDave 12y ago
  It seems rare to me that there are systems in normal app deployment where there is NO remote shared state between app (and therefore physical) nodes. Given that, your production deploy will almost always have at least a few datacenter-local remote resources. Besides compute and indexing farms, what sort of deploys demonstrate that pattern?
  - opendais 12y ago
    I don't use Docker for anything that stores state. I store it in a separate pool of servers that are solely for database nodes. At which point, I'm back to the "Service Discovery does not require a Docker-aware design." I think the issue here is I'm used to different assumptions than other people. I virtualize application/service containers. I don't virtualize the datastores but run those on bare metal whenever possible. So it goes LB -> pool of docker containers -> Database Cluster(s). The database cluster(s) are known in advance and are restored to the same DNS location when they are revived/moved/transferred. [e.g. I have a cluster of 5 DB servers, they are always something like galera1-servicegroup through galera5-servicegroup, or whatever]