10 ms·

I'm curious about any compelling reasons I should use something like Dokku or Flynn if I already prefer to manage my own infra with something like Ansible or Sa

I'm curious about any compelling reasons I should use something like Dokku or Flynn if I already prefer to manage my own infra with something like Ansible or Salt. Serious question, not a sarcastic rhetorical remark about this type of tool :)

mbreedlove 10y ago
I have a really extensive Ansible playbook for setting up my stack; nginx with extra modules, postgres, redis, and others like fail2ban. It all targets CentOS and also configures SELinux when appropriate. It all works well, until I want to do something that doesn't fit the mold that I've put myself in. For example, I wanted to get off Google Analytics and try out Piwik, which uses PHP and requires MySQL, Postgres isn't supported. It would have been really difficult to write out a bunch of Ansible config for PHP and MySQL, both technologies I'm not familiar with and don't know their best practices. So, I'm still using Google analytics. A similar story happened when I wanted to host a Tor relay. The allure of just pointing Dokku/Flynn to a pre-made Dockerfile for Piwik/Tor/ownCloud/etc. is pretty compelling. It let's me mix and match technologies without feeling like I'm polluting my server with a bunch of random services and tech. Containerization provides just enough separation to make me happy. I'm not sure if Dokku or Flynn is the golden goose I'm after, but it seems like a step in the right direction. I still use Ansible to do basic provisioning like users and SSH keys, setting up Fail2ban, and installing Dokku.
- mcescalante 10y ago
  Hearing your workflow/tooling is handy and I may borrow an idea or two while playing around, thanks for writing this up :)
josegonzalez 10y ago
Probably user experience. If you've nailed that with your own infra and made it easy to manage the lifecycle of services for your developers, then there isn't really any need to "reinvent the wheel". Infrastructure doesn't stop working just because there isn't any docker in it.
Titanous 10y ago
Great question! We designed Flynn to solve a bunch of the common problems around running apps in production. This means that we're working full-time just on the automation and stability of your production environment. As you grow and scale, Flynn will scale with you and provide integrated features without any additional effort. Here's an incomplete list of things that Flynn provides out of the box: - Automatic high availability. Everything in Flynn is highly available, as long as you are running three or more servers. Additionally, it's designed to fail gracefully, so even if there's a network partition or some hosts fail, everything will keep working if at all possible. - git push deployment, after installing Flynn you can run `flynn create && git push flynn master` and your app will be automatically built and deployed. - Polyglot apps. Want to deploy a Phoenix app written in Elixir? You can do that just by specifying the appropriate buildpack. Everything else works exactly the same. - Zero-downtime deployment with release management and easy rollbacks. If a new version or configuration variable causes the app to crash at boot, Flynn will automatically detect this and stop the deploy before any traffic hits it. Deploying new versions of the application does not cause user-visible downtime. - Easy app configuration. `flynn env set FOO=bar` rolls out a new immutable release with the configuration change. You don't have to edit any files, and you can roll it back later with `flynn release rollback`. - Built-in HA databases. `flynn resource add postgres` configures your app with a PostgreSQL database in a cluster that is highly available and already configured with replication and safe automatic failovers. You can do the same to get a MySQL or MongoDB database. - Automatic load balancing and TLS. Flynn automatically load balances HTTP and TCP traffic, and supports HTTP/2 out of the box. You can add a TLS certificate with a single command, and all changes to the routing configuration happen immediately without restarts or downtime. Want to send a subpath to a different app? You can do that in a single command. I could go on and on like this, but you probably get the idea. Of course, it's probably possible to build every feature of Flynn that you want using your configuration management tool of choice, but that would be a huge amount of time not spent developing the actual applications that you want to deploy with it.
- jacques_chester 10y ago
  I work on Cloud Foundry, a competing system. Flynn is unarguably ahead in certain features (and vice versa, in my biased opinion). I agree with the thrust of your comment here: rolling your own PaaS is hard. Just plain old hard. There's so much, so damn much that you wind up having to do. Before I worked on CF I worked in Pivotal Labs. I got to see various custom home-grown PaaSes. Some were brilliant. Some were terrible. Every single one of them was a millstone. A lot of people don't realise it yet, but the Linux of our time has been written -- in the sense that nobody writes an operating system if they're not in the OS business. I don't know if it's going to be Cloud Foundry, or Flynn, or OpenShift or some mix of these, but we have already passed the point at which it makes rational engineering sense for the 99% of engineers to build their own. Disclosure: I work for Pivotal, the majority donor of engineering effort to Cloud Foundry.

mbreedlove 10y ago

I have a really extensive Ansible playbook for setting up my stack; nginx with extra modules, postgres, redis, and others like fail2ban. It all targets CentOS and also configures SELinux when appropriate. It all works well, until I want to do something that doesn't fit the mold that I've put myself in. For example, I wanted to get off Google Analytics and try out Piwik, which uses PHP and requires MySQL, Postgres isn't supported. It would have been really difficult to write out a bunch of Ansible config for PHP and MySQL, both technologies I'm not familiar with and don't know their best practices. So, I'm still using Google analytics. A similar story happened when I wanted to host a Tor relay. The allure of just pointing Dokku/Flynn to a pre-made Dockerfile for Piwik/Tor/ownCloud/etc. is pretty compelling. It let's me mix and match technologies without feeling like I'm polluting my server with a bunch of random services and tech. Containerization provides just enough separation to make me happy. I'm not sure if Dokku or Flynn is the golden goose I'm after, but it seems like a step in the right direction. I still use Ansible to do basic provisioning like users and SSH keys, setting up Fail2ban, and installing Dokku.

mcescalante 10y ago
Hearing your workflow/tooling is handy and I may borrow an idea or two while playing around, thanks for writing this up :)

josegonzalez 10y ago

Probably user experience. If you've nailed that with your own infra and made it easy to manage the lifecycle of services for your developers, then there isn't really any need to "reinvent the wheel". Infrastructure doesn't stop working just because there isn't any docker in it.

Titanous 10y ago

Great question! We designed Flynn to solve a bunch of the common problems around running apps in production. This means that we're working full-time just on the automation and stability of your production environment. As you grow and scale, Flynn will scale with you and provide integrated features without any additional effort. Here's an incomplete list of things that Flynn provides out of the box: - Automatic high availability. Everything in Flynn is highly available, as long as you are running three or more servers. Additionally, it's designed to fail gracefully, so even if there's a network partition or some hosts fail, everything will keep working if at all possible. - git push deployment, after installing Flynn you can run `flynn create && git push flynn master` and your app will be automatically built and deployed. - Polyglot apps. Want to deploy a Phoenix app written in Elixir? You can do that just by specifying the appropriate buildpack. Everything else works exactly the same. - Zero-downtime deployment with release management and easy rollbacks. If a new version or configuration variable causes the app to crash at boot, Flynn will automatically detect this and stop the deploy before any traffic hits it. Deploying new versions of the application does not cause user-visible downtime. - Easy app configuration. `flynn env set FOO=bar` rolls out a new immutable release with the configuration change. You don't have to edit any files, and you can roll it back later with `flynn release rollback`. - Built-in HA databases. `flynn resource add postgres` configures your app with a PostgreSQL database in a cluster that is highly available and already configured with replication and safe automatic failovers. You can do the same to get a MySQL or MongoDB database. - Automatic load balancing and TLS. Flynn automatically load balances HTTP and TCP traffic, and supports HTTP/2 out of the box. You can add a TLS certificate with a single command, and all changes to the routing configuration happen immediately without restarts or downtime. Want to send a subpath to a different app? You can do that in a single command. I could go on and on like this, but you probably get the idea. Of course, it's probably possible to build every feature of Flynn that you want using your configuration management tool of choice, but that would be a huge amount of time not spent developing the actual applications that you want to deploy with it.

jacques_chester 10y ago
I work on Cloud Foundry, a competing system. Flynn is unarguably ahead in certain features (and vice versa, in my biased opinion). I agree with the thrust of your comment here: rolling your own PaaS is hard. Just plain old hard. There's so much, so damn much that you wind up having to do. Before I worked on CF I worked in Pivotal Labs. I got to see various custom home-grown PaaSes. Some were brilliant. Some were terrible. Every single one of them was a millstone. A lot of people don't realise it yet, but the Linux of our time has been written -- in the sense that nobody writes an operating system if they're not in the OS business. I don't know if it's going to be Cloud Foundry, or Flynn, or OpenShift or some mix of these, but we have already passed the point at which it makes rational engineering sense for the 99% of engineers to build their own. Disclosure: I work for Pivotal, the majority donor of engineering effort to Cloud Foundry.