Running a minimum of 3 servers is just a recommendation, you can run Flynn on a single server (many people do), but then you obviously don't benefit from the HA properties.
16 karma · joined August 13, 2014
For example, Flynn comes with PostgreSQL, MariaDB and MongoDB appliances which are deployed in a highly available, fault tolerant configuration with sane defaults: https://flynn.io/docs/databases.
Through the use of buildpacks, it is also straight forward to deploy applications written in many popular languages and frameworks without being intimately acquainted with how to containerise those types of applications (e.g deploying a Ruby on Rails app on JRuby: https://flynn.io/docs/languages/ruby).
You also get things like full cluster backups (including all your data), simple git / docker / tarball based deployments, log aggregation, release rollbacks, domain / path based routing, service discovery, and many more!
Flynn auto-heals after node restarts (and if it doesn't that is first and foremost a bug we need to fix), but also has a cluster monitor service which brings services back online automatically, and as a last gasp there is `flynn-host fix` for manual intervention.
Flynn has node promotion / demotion so you can totally do rolling upgrades (users have reported they do this with a modified CloudFormation stack for example). There is also a built-in updater to update to a more recent version of Flynn.
> Flynn doesn't seem to offer a metrics stream, only logs
Something I think should be built-in, but there are many off the shelf solutions which can be deployed to Flynn as apps.
> Flynn builds apps from source, so not sure how that works for compiled Java/Go, or anything you'd run with a binary buildpack
Flynn has built-in buildpacks but also supports running custom buildpacks (see https://flynn.io/docs/apps#buildpacks). If you just want to deploy binaries, you can either:
- use the inline buildpack: https://github.com/kr/heroku-buildpack-inline - deploy a tarball: https://github.com/flynn/flynn/issues/306#issuecomment-23321... - deploy a Docker image: https://flynn.io/docs/docker
> I couldn't find anything about role-based access control in Flynn, something Cloud Foundry has (which can be backed by LDAP for enterprises)
Flynn does not currently have strict access control, but work is very much on the way, see our security improvements project: https://github.com/flynn/flynn/projects/1.
> Flynn only appears to route HTTP traffic, so no TCP routing for IoT workloads
Flynn supports TCP routes, although it does not seem to be documented very well: https://flynn.io/docs/cli#route
NFS support is not currently implemented, but we have a clear plan and it is on our upcoming roadmap: https://github.com/flynn/flynn/issues/1521
> Is it possible to store objects in something similar to S3 (for example using Minio)?
Flynn has a built-in blobstore for storing files and supports multiple storage backends: PostgreSQL Large Objects (default), Amazon S3, Google Cloud Storage and Azure Storage (to be released into stable next week), see https://flynn.io/docs/production#blobstore-backend.
I highly suspect many of the bugs you encountered have been fixed, and we make it a priority to investigate and fix reported bugs as quickly as possible, so if you end up giving Flynn a try again let us know if you have issues and we'll fix them.
As for updating, the in-place updater still has some kinks but the backup / restore route is fully tested and is reliable (see https://flynn.io/docs/production#updating).
Flynn does self-heal after node reboots, so if that is not working for you then it is a bug we need to fix.
When you do have issues it would be really helpful to us and other users if you could open a GitHub issue or come and chat to us in IRC (#flynn on Freenode) so we can fix any bugs you are encountering. I fully understand you just want to be concentrating on building your product, this is why we are building Flynn!