5 ms·

Show HN: Wormhole – A smart proxy that connects docker containers

48 points by vishvananda 12y ago

coderzach 12y ago
This is great! I've been thinking about the problems this solves a lot, and this seems really on the mark.
- vishvananda 12y ago
  Thanks, author here. I've been thinking about what we need to simplify distributed applications for the past few years, and we really need reusable components[1]. Anything we can do to make containers more consistent and easier to build is important. [1] https://medium.com/@vishvananda/standard-components-not-standard-containers-c30567f23da6 https://medium.com/@vishvananda/standard-components-not-stan...
  - walterbell 12y ago
    Is the IPSEC implementation based on existing code?
    - vishvananda 12y ago
      The ipsec implementation just configures ipsec in the kernel using a go netlink library[1]. It is similar to how it would be accomplished using iproute2 via `ip xfrm policy` and `ip xfrm state`. [1] https://github.com/vishvananda/netlink https://github.com/vishvananda/netlink
contingencies 12y ago
I applaud the exploration, though the author appears to class everything outside of the container as a 'communications layer' and vaguely ascribe knowledge of the credentials and processes necessary to facilitate orchestration, configuration management, etc. across multiple containers to this area. This is not solving the problem, only hand-waving it elsewhere. The potential use of a container-initiated networking event (socket open) to trigger responses at the infrastructure-level is the key architectural novelty here. This is essentially a suggestion for 'implicit infrastructure' as opposed to 'explicit infrastructure'; with all of the benefits and drawbacks you would expect from such a paradigm shift. Personally I believe that the implicit paradigm is mostly useful in specific, relatively controlled use cases, such as service testing or behavioral profiling prior to live deployment. More thoughts on the same: http://stani.sh/walter/pfcts http://stani.sh/walter/pfcts
- CMCDragonkai 12y ago
  What do you mean by implicit vs explicit?
  - contingencies 12y ago
    Explicit infrastructure is that which is completely specified and instantiated and ahead of use. This would include resource allocation and security policy for computational, storage and networking infrastructure. Building infrastructure in the pre-cloud/pre-virt era generally necessitated this approach. Implicit infrastructure is constructed reactively, over time, in response to evolving stimuli but also based upon dependencies or requirements specified or assumed. For instance, today this occurs in automated scale-out on some cloud systems. The author describes a conceptually similar (from the infrastructure specification and management standpoint) mode of operation here by suggesting the creation of new nodes in response to socket opens (networking events) on individual containers. Ultimately, in the latter case you are giving up some degree of control and known state in favour of flexibility. This makes sense for some scenarios, but greatly complicates things in others. Both are valid but the viable domain of the latter is more limited.
    - CMCDragonkai 12y ago
      I understand, that sounds very close to what I've been working on, a functionally reactive infrastructure that is configured with constraint based logic DSL that starts from QoS constraints. The QoS constraints allows one to specify goals, and allow infrastructure to be built up implicitly. I've read some of the stuff on your website, it's very closely aligned to what I'm working on. We should talk in more detail.
      - contingencies 12y ago
        Sure thing, send me an email.
    - vishvananda 12y ago
      FWIW I agree that reactive infrastructure is fairly limited in scope. The traditional model of infrastructure is everything running in a single server. If your unit of deployment is a vm, then orchestration, service discovery, security policy must be done within the vm image or via a configuration management system. If your unit of deployment is a container, then these pieces can be done outside of the container system. A standard interface for the way the container communicates with the outside world allows these systems to be shared and reused and perhaps one day standardized.

48 points by vishvananda 12y ago

coderzach 12y ago

This is great! I've been thinking about the problems this solves a lot, and this seems really on the mark.

vishvananda 12y ago
Thanks, author here. I've been thinking about what we need to simplify distributed applications for the past few years, and we really need reusable components[1]. Anything we can do to make containers more consistent and easier to build is important. [1] https://medium.com/@vishvananda/standard-components-not-standard-containers-c30567f23da6 https://medium.com/@vishvananda/standard-components-not-stan...
- walterbell 12y ago
  Is the IPSEC implementation based on existing code?
  - vishvananda 12y ago
    The ipsec implementation just configures ipsec in the kernel using a go netlink library[1]. It is similar to how it would be accomplished using iproute2 via `ip xfrm policy` and `ip xfrm state`. [1] https://github.com/vishvananda/netlink https://github.com/vishvananda/netlink

contingencies 12y ago

I applaud the exploration, though the author appears to class everything outside of the container as a 'communications layer' and vaguely ascribe knowledge of the credentials and processes necessary to facilitate orchestration, configuration management, etc. across multiple containers to this area. This is not solving the problem, only hand-waving it elsewhere. The potential use of a container-initiated networking event (socket open) to trigger responses at the infrastructure-level is the key architectural novelty here. This is essentially a suggestion for 'implicit infrastructure' as opposed to 'explicit infrastructure'; with all of the benefits and drawbacks you would expect from such a paradigm shift. Personally I believe that the implicit paradigm is mostly useful in specific, relatively controlled use cases, such as service testing or behavioral profiling prior to live deployment. More thoughts on the same: http://stani.sh/walter/pfcts http://stani.sh/walter/pfcts

CMCDragonkai 12y ago
What do you mean by implicit vs explicit?
- contingencies 12y ago
  Explicit infrastructure is that which is completely specified and instantiated and ahead of use. This would include resource allocation and security policy for computational, storage and networking infrastructure. Building infrastructure in the pre-cloud/pre-virt era generally necessitated this approach. Implicit infrastructure is constructed reactively, over time, in response to evolving stimuli but also based upon dependencies or requirements specified or assumed. For instance, today this occurs in automated scale-out on some cloud systems. The author describes a conceptually similar (from the infrastructure specification and management standpoint) mode of operation here by suggesting the creation of new nodes in response to socket opens (networking events) on individual containers. Ultimately, in the latter case you are giving up some degree of control and known state in favour of flexibility. This makes sense for some scenarios, but greatly complicates things in others. Both are valid but the viable domain of the latter is more limited.
  - CMCDragonkai 12y ago
    I understand, that sounds very close to what I've been working on, a functionally reactive infrastructure that is configured with constraint based logic DSL that starts from QoS constraints. The QoS constraints allows one to specify goals, and allow infrastructure to be built up implicitly. I've read some of the stuff on your website, it's very closely aligned to what I'm working on. We should talk in more detail.
    - contingencies 12y ago
      Sure thing, send me an email.
  - vishvananda 12y ago
    FWIW I agree that reactive infrastructure is fairly limited in scope. The traditional model of infrastructure is everything running in a single server. If your unit of deployment is a vm, then orchestration, service discovery, security policy must be done within the vm image or via a configuration management system. If your unit of deployment is a container, then these pieces can be done outside of the container system. A standard interface for the way the container communicates with the outside world allows these systems to be shared and reused and perhaps one day standardized.