HN Explorer

15 comments

[ 3.5 ms ] story [ 24.4 ms ] thread
jeffasinger
This is a pretty big first step towards easily deploying highly available services on DO. Unfortunately it sounds like you won't be able to fail over to another datacenter, which is unfortunate, but understandable.
viraptor
"In order to automate the Floating IP reassignment, we must use the DigitalOcean API. This means that you need to generate a Personal Access Token (PAT)[...] Your PAT will be used in a script that will be added to both servers in your cluster, so be sure to keep it somewhere safe—as it allows full access to your DigitalOcean account—for reference."

Need to reassign IP? Store key for the whole account everywhere! Sigh...

geerlingguy
This is huge! I don't have to play the 'delete a droplet and recreate another quickly to preserve the IP address' roulette anymore.

This will allow me more control during infrastructure deployments on DigitalOcean without futzing with DNS.

IgorPartola
What? The? Fuck? What year is this? Why is this shit IPv4 only? Seriously, this is not an old feature they are working on, this is brand new stuff. Come one! On top of that, unless you created your instance today you get a dialog that tells you to add a second IPv4 address to eth0, which does not actually work on Linux. I would really love to use features like this, but, ya know, maybe test this stuff first?
2bluesc
I'm with you. It'd be nice if they handed out a proper IPv6 prefix to their droplets too. The 16 addresses or whatever it is doesn't count.

Bonus points for optionally handing out a /48 as recommended so that docker containers can be allocated /64's.

We can dream.

IgorPartola
You know what? I just realized that Vultr.com has /64's everywhere. Time to switch. [edit: I am not affiliated in any way with Vultr, was not even a customer until about 30 seconds ago].
stock_toaster 

  > Bonus points for optionally handing out a /48 as 
  > recommended so that docker containers can be allocated /64's.
A believe that currently a /48 is recommended for "larger" end networks (65K subnets), not for end systems or "home networks"[1] where a /56 is recommended.

Would docker instances each need unique subnets? I think a /56 would be sufficient (256 subnets, 4.7×10^21 addresses), maybe even "just" a /64, if docker instances could share the same subnet.

[1]: https://tools.ietf.org/html/rfc6177

Daviey
A Linux interface can happily hold multiple IP addresses using different methods. The logical one is probably using aliases, like eth0:0.
icedchai
Pretty advanced stuff.

I remember doing this 15+ years ago using some Solaris HA software (Veritas, I think.)

iheartmemcache
VAX VMS could do it ~30 years ago. IBM's AIX has had high-availability since maybe version 5 so 15-20 years on that. Not only that but every component (DB2, WebSphere) was HA ready out of the box (granted ND licenses were like 100k a server). z/OS could do it as soon as it got TCP (40? 50? years). It's the same wheel being crafted every 10 years, just with a little spackle on top. The only thing that feels new to me is the gradual application (pun not intended) of math as it migrates into CS.
sciurus
Nice that they're starting to catch up with AWS... from 2008.

https://aws.amazon.com/about-aws/whats-new/2008/03/26/announ...

IgorPartola
That's a lot like saying GameStop is catching up to Walmart. They are different products aimed at different markets. I run stuff on both right now and they both have their strengths. For example AWS just rolled out hosted ElasticSearch. Since it's a new product to me, I don't want to jump into maintaining a cluster of ES nodes in production right away. I might experiment with that on DO, but for an actual product I want to release soon AWS's option is better, even though it's about 10x more expensive.