RSS

This Week in Flynn

Flynn CTO Jonathan (@titanous) and Alex (@nobert) will be in Texas next week. If you want to learn more about Flynn, speak with the developers, or just hang out, they will be in Austin on Tuesday 2/16, Houston on Wednesday 2/17, and Dallas on Thursday 2/18. We will post more details here soon.

§ Changes

§ Enhancements

  • Cluster monitor/resurrection (#2375)

§ Bugfixes

  • host: Prevent multiple attachers to interactive jobs (#2426)
  • host: Fix displaying job ExitStatus in flynn-host inspect (#2425)
  • test: Increase the deploy timeout (#2423)
  • Test fixes (#2421)
  • Fix installer userdata (#2420)
  • installer: Ensure startScript only executes on first boot (#2419)
  • controller/scheduler: Wait for controller API to start (#2418)
  • host: Start flynn-host at boot by default (#2416)
  • docs: Move docs-nav.json from website repo (#2415)
  • util/packer: Bump libvirt start timeout (#2412)
  • test: Bump the expiry of the root manifest in the test TUF repo (#2414)
  • gitreceive: Fix passing BUILDPACK_URL via –env arg (#2413)
  • installer: Increase bootstrap timeout to 4m from 2m (#2408)

§ Stay in Touch

§ How You Can Help

This Week in Flynn

This past week the Flynn team continued work on Flynn production stability.

§ Changes

§ Enhancements

  • cli/release: adding ‘release update’ to allow tweaking existing releases (#2377)

§ Bugfixes

  • script: Revert to upstream godeb (#2401)
  • cli: Scale processes to 0 before deleting app (#2390)
  • appliance/postgres: Forcefully close connections when deleting database (#2396)
  • script: Use flynn fork of godeb (#2393)
  • script: Add keep state option to start-flynn-host (#2389)

§ Stay in Touch

§ How You Can Help

This Week in Flynn

Work on Flynn stability continues.

Flynn’s Redis appliance now has database dump and restore functionality, via flynn redis dump and flynn redis restore.

§ Changes

§ Enhancements

  • appliance/redis: add dump & restore (#2373)

§ Bugfixes

  • test: Fix race in redis test (#2384)
  • Godeps: Fix up dep tracking (#2378)
  • util/release: Add Redis image to version manifest (#2382)
  • controller: Avoid double close panic during shutdown (#2374)

§ Stay in Touch

§ How You Can Help

A Complete Platform

It’s not enough to solve deployment. Platforms need to manage databases as well.

Deployment is easy. You can start with code or a container. Buildpacks are well-known, and schedulers have come a long way in recent years. That’s why so many products and tools make it easy to deploy (and scale) stateless apps.

The work of ops doesn’t stop at deployment, so why do so many platforms?

Developers, apps, and products are still bottlenecked behind the ops team for databases unless their platform provides them.

We knew this when we started building Flynn two years ago which is why we shipped database appliances from the start. We wanted Flynn to run everything you could run on Linux, not just stateless web apps.

Database appliances are one of the most important ways Flynn makes that possible. When you tell Flynn your app needs a database, the Flynn appliance for that database automatically provisions a new database for your app.

Flynn database appliances use industry best practices by default. Many operators know how they should run databases but don’t apply those standards because of the time, costs, or complexity required. Flynn’s database appliances use best practices out of the box by default with no configuration needed. Our appliances run in a highly available configuration and automatically failover and recover.

Today Flynn includes an appliance for PostgreSQL and an alpha for Redis. We’ve started working on a MySQL appliance and should have appliances for most major open source databases by the end of the year. We’ll also standardize on an appliance framework that makes it easy for users to build appliances for their favorite or custom databases. We want these appliances to mature and become trusted in production and far easier than manual management of the same databases. We will also start to expose more tools for operators around monitoring, tuning, and granular backups soon.

Platforms can make life better for developers, operators, and the users of their products, but only if they solve the hard problems. Databases are a big challenge, but one we’re dedicated to solving.

This Week in Flynn

The Flynn Redis database appliance landed this week. It is currently single node and the data is not persistent, so it is best used for caching or development. To add a Redis database to an app, run flynn resource add redis. Flynn will provision a new Redis database and provide the connection information to your app via REDIS_HOST, REDIS_PORT, and REDIS_PASSWORD environment variables, as well as a Heroku-compatible REDIS_URL variable. You can connect to the Redis server directly via flynn redis redis-cli.

§ Changes

§ Enhancements

  • Redis Appliance (#2351)

§ Bugfixes

  • slugbuilder: Make .slugignore Heroku compatible (#2360)
  • bootstrap: Use deploy-app to launch Redis provider (#2371)
  • util/packer: Pin kernel version to work around Docker/AUFS bug (#2366)
  • test/rootfs: Increase size of sparsefile to 32GB (#2363)

§ Stay in Touch

§ How You Can Help

 RSS



Mailing List