Re: [Sks-devel] Operational question for all
On 2018-03-14 at 01:26 -0400, Jeremy T. Bouse wrote: > First of all the cluster is in a private subnet with no direct > internet so it gets NAT'd outbound from an IP address that would not > match the inbound IP address to be used. Membership tests from your peers would reject this. >As I understand it the gossip port (11370/tcp) is not > HTTP based so it couldn't go through an ALB (application) and would need > to be pass-thru so that would mean NLB (network) or ELB (classic). The > HKP port (11371/tcp) could still be ran through any LB but since you can > only have a container configured to join one LB that would likely mean > needing to use an ELB so I could perform pass-thru for gossip and > HTTP/HTTPS for HKP port wheere the NLB would just pass-thru both to the > container. Oh eww, I'd missed that ECS containers can only be in one LB. That's ... horrible. How about using IPv6 and peering IPv6-only? As long as you don't set the v6 gateway to egress-only, and if you set the networking mode to `awsvpc` then you get ENIs on each task ... though I'm not seeing a way to attach a persistent ENI to get fixed addresses. It might be worth considering dynamic DNS which is updated every time a task is started or stopped, so that you peer with a changing set of IPv6 addresses? Or wait to see what Amazon announce in their EKS tech talk on Monday, to see if their EKS will be flexible enough that a Kubernetes service definition could be rigged up which lets you use the same IP for inbound and outbound? -Phil ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Operational question for all
> On 14 Mar 2018, at 07:26 , Jeremy T. Bousewrote: > > I've been running my SKS cluster under Docker for awhile now and my > current Docker cluster is currently Tango Uniform it would appear (hence > sks.undergrid.net being offline still). I've got an ECS (Docker-based) > cluster already running and operational in AWS that I could move the > service over to however the issue that has kept me from doing so is the > operational difference it would incur. Looking to get some opinions and > see if I'm overthinking it or if I'd be good to go. > > First of all the cluster is in a private subnet with no direct > internet so it gets NAT'd outbound from an IP address that would not > match the inbound IP address to be used. From what I’ve seen thus far, the gossipping/recon coming from an IP that’s not resolving from those names in the membership file, gets ignored. That might be a version 2 feature request: have peers authenticated not based on IP, but pub/private keys --- Hendrik Visage HeViS.Co Systems Pty Ltd T/A Envisage Systems / Envisage Cloud Solutions +27-84-612-5345 or +27-21-945-1192 hvis...@envisage.co.za signature.asc Description: Message signed with OpenPGP ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] Operational question for all
I've been running my SKS cluster under Docker for awhile now and my current Docker cluster is currently Tango Uniform it would appear (hence sks.undergrid.net being offline still). I've got an ECS (Docker-based) cluster already running and operational in AWS that I could move the service over to however the issue that has kept me from doing so is the operational difference it would incur. Looking to get some opinions and see if I'm overthinking it or if I'd be good to go. First of all the cluster is in a private subnet with no direct internet so it gets NAT'd outbound from an IP address that would not match the inbound IP address to be used. Second is the fact that because of it being in a private subnet I'd have to use a LB (ELB or NLB given the multiple ports required and only about to apply to one LB for all) in a public subnet. The way AWS does their LB it doesn't necessarily have a static IP address as they may change it for DDoS prevention but my hostnames would be able to resolve to IP addresses using Route53 ALIAS records. As I understand it the gossip port (11370/tcp) is not HTTP based so it couldn't go through an ALB (application) and would need to be pass-thru so that would mean NLB (network) or ELB (classic). The HKP port (11371/tcp) could still be ran through any LB but since you can only have a container configured to join one LB that would likely mean needing to use an ELB so I could perform pass-thru for gossip and HTTP/HTTPS for HKP port wheere the NLB would just pass-thru both to the container. The other likely result of this move would be I'd go from actually have 2 nodes running to only 1 node but it would be able to restart immediately if it crashed. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel