Stable release of Flynn – open-source container deployment | Hacker News Reader

Stable release of Flynn – open-source container deployment

flynn.io

79 pointsgregwebs22 comments

Flynn CTO here, happy to answer any questions about Flynn. This is the first release in our stable channel with an update path, we'll be releasing weekly from now on.

It may not be "production ready" for everyone, though please try it out and let us know how it goes.

If you're in SF, please come to our meetup in Tuesday and we can talk in person: https://www.eventbrite.com/e/flynn-stable-sf-meetup-tickets-...

Any plans to support C#/ASP.NET? If you haven't seen it yet, ASP.NET nVext will ship with native support for Linux/OS X and is much more package-oriented so it would lend itself pretty well to Flynn. It's still in beta, but I think they're planning a full release in Q1 2016.

https://github.com/aspnet/home

No current plans, but if there's enough demand for it we'd be quite happy to implement it (or accept a contribution!). Please file a feature request on GitHub if you'd like to see it in Flynn: https://github.com/flynn/flynn/issues/new

Edited to add: It looks like there is already a buildpack for ASP.NET 5 (uses Mono) that's worth a try: https://github.com/heroku/dotnet-buildpack

I noticed you removed etcd recently in favor of running raft internally. I have a couple of questions:

1) Why did you remove etcd? 2) Why use the hashicorp raft implementation[1] over the coreos raft implementation[2]?

[1] https://github.com/hashicorp/raft [2] https://github.com/coreos/etcd/tree/master/raft

We didn't really need all the features of etcd, this change is part of a longer term plan to only use Raft for leader election and service metadata with service instances propagated using cluster gossip. We also ran into some issues with etcd that were very hard to diagnose, and the developer who worked on the project was familiar with and confident in the Hashicorp package.

Does it support zero downtime deployment?

Yes, absolutely. We do a rolling deployment of new app instances, requests are not dropped.

Sounds great, will check out the documentation and try to hook it into our CD system, thanks for the update.

Flynn looks very exciting, congrats! I am having trouble figuring out what the minimal and recommended setups would be across providers. And what exactly happens when I issue scale commands? I'm looking to get an idea of costs to compare different providers, but also to compare against running on heroku. Thanks!

Thanks!

Minimum high availability setup would be three nodes with 1GB of memory each, more memory if you're using a heavier application framework like Rails.

When you run a scale command Flynn creates new application containers that are balanced across the cluster, so if you scaled to six instances with three hosts in the cluster, you'd end up with two instances on each of the three hosts.

How would you compare/contrast Flynn to OpenShift 3?

http://www.openshift.org/#v3

Congrats on the release, looks like a great platform for my use case (an app with a series of microservices, each of which needs to scale independently and for which requests are usually long running).

I do have a question re: Flynn's router. The router README [1] states that it uses a random load balancing algorithm. I worry that at scale it would exhibit issues similar to what Heroku's "routing mesh" has (had?) as explained in [2], namely that some nodes would sit idle while others simultaneously let requests build up in their queue, hurting overall latency and reducing the marginal value of each additional node.

Any chance of something like HAProxy's leastconn algorithm landing in Flynn's router to mitigate this type of worry?

[1] https://github.com/flynn/flynn/tree/master/router

[2] http://genius.com/James-somers-herokus-ugly-secret-annotated

Great question! We're aware of the Heroku issues, and they don't fully apply in our case. We currently do not have any queues in the router other than the kernel's accept queue. All incoming connections are assigned a goroutine immediately and the requests are proxied back to service instances without queuing. So if your application instances can handle concurrent requests, the performance impact of random load balancing should not be huge.

We are absolutely open to implementing other balancing algorithms, including least connections. The one caveat is that at any time multiple routers will be in operation and we're not going to do extensive coordination between them, so the balancing will never be perfect.

Got it, makes complete sense. Thanks for the direct answer.

A bit more info on the app I'm thinking of testing with Flynn: each instance has a single dedicated resource (actually a psuedo terminal sitting on top of a command line tool). Any given instance is incapable of handling requests concurrently, they queue up at the instance. So the app's concurrency model relies on smart load balancing at the router itself. I've got HAProxy playing this role, but have done a bit of a hack job juggling the containers which implement the various microservices.

I'll give Flynn a go to see if the simplicity it gives me in managing my deployment is worth the routing tradeoff for now, but I would definitely love to see Flynn's router adapted as you describe.

@Titanous, fantastic project.

Could you elaborate what differentiates Flynn from something like Tutum?

Thanks! Tutum is a proprietary SaaS product that provides a web UI for Docker. Flynn is a full-featured open source platform, you don't need to think about containers, just your app.

1) Is this tool the same as Docker Swarm?

2) Has the code been security-audited?

3) Can I use this as a combination of Puppet/Chef + Swarm?

Lastly, who is this tool for? The guy running his 1 VPS or the startup running their 50 AWS medium instances?

> 1) Is this tool the same as Docker Swarm?

No, it is much higher level. You could think of it as open source Heroku, apps are deployed using buildpacks and a PostgreSQL cluster is included.

> 2) Has the code been security-audited?

Not yet. We've been focusing on stability, work on internal security will be starting soon. You can expose ports 80/443 to the Internet, but shouldn't run untrusted code on it. See here for more details: https://flynn.io/docs/security

> 3) Can I use this as a combination of Puppet/Chef + Swarm?

For most use cases it would replace those tools.

> Lastly, who is this tool for? The guy running his 1 VPS or the startup running their 50 AWS medium instances?

All of the above, though we recommend at least three instances for high availability and haven't tested large clusters yet.

From the manual install section, there's a note about initializing the cluster, along with a reference to:

https://discovery.flynn.io/clusters/53e8402e-030f-4861-95ba-...

Does this mean one has to jump through hoops to install flynn on a set of devices that are networked to each other, but cut off from the Internet?

You can specify the host IPs explicitly instead of using the discovery service. The current snag for isolated clusters is that stock buildpacks require internet access to download languages and frameworks. We'll solve this, but some additional work is necessary.

Am I correct to assume this will break the discovery service if we override with host IPs?

The discovery URL is only used for bootstrapping, nothing will break if you specify IPs instead. They are interchangeable.

Reply on news.ycombinator.com