How to run InfluxDB on Heroku?

Question

Is it possible, and if so, how? I'd like to be able to reach it from my existing Heroku infrastructure.

Will I need a Procfile? From what I understand it's just a standalone binary written in Go! so it shouldn't be that hard to deploy it, I'm just curious how to deploy it because I don't think I understand the ins and outs of Heroku deployment.

Answer 1

Heroku Dynos should not be used to deploy a database application like InfluxDB.

Dynos are ephemeral servers. Data does not persist between dyno restarts and cannot be shared with other dynos. Practically speaking, any database application deployed on a dyno is essentially useless. This is why databases on Heroku (e.g. Postgres) are all Add-ons. InfluxDB should be set up on a different platform (like, AWS EC2 or a VPS) since a Heroku Add-on is not available.

---

That said, it is possible to deploy InfluxDB to a Heroku dyno.

To get started, it is important to understand the concept of a 'slug'. Slugs are containers (similar to a Docker images) which hold everything needed to run a program on Heroku's infrastructure. To deploy InfluxDB, an InfluxDB slug needs to be created.* There are two ways to create a slug for Go libraries:

1. Create a slug directly from a Go executable as described here.**
2. Build the slug from source using the Heroku Go buildpack (explained below).

---

To build the slug from source using a buildpack, first clone the InfluxDB Github repo. Then add a Procfile at the root of the repo, which tells Heroku the command to run when the dyno starts up.

echo 'web: ./influxd' > Procfile

The Go buildpack requires all dependencies be included in the directory. Use the godep dependency tool to vendor all dependencies into the directory.

go get github.com/tools/godep
godep save

Next, commit the changes made above to the git repo.

git add -A .
git commit -m dependencies

Finally, create a new app and tell it to compile with the Go buildpack.

heroku create -b https://github.com/kr/heroku-buildpack-go.git
git push heroku master
heroku open    // Open the newly created InfluxDB instance in the browser.

Heroku will show an error page. An error will be displayed because Heroku's 'web' process type requires an app to listen for incoming requests on the port described by the $PORT environment variable, otherwise it will kill the dyno. InfluxDB's API and admin panel run on ports 8086 and 8083, respectively.

Unfortunately, InfluxDB does not allow those ports to be set from environment variables, only through the config file (/etc/config.toml). A small bash script executed before InfluxDB starts up could set the correct port in the config file before InfluxDB starts up.

Another problem, Heroku only exposes one port per dyno so the API and the admin panel cannot be exposed to the internet at the same time. A smart reverse proxy could work around that issue using Heroku's X-Forwarded-Port request header.

Bottom line, do not use Heroku dynos to run InfluxDB.

---

* This means the benefits of a standalone Go executable are lost when deploying to Heroku, since it needs to be recompiled for Heroku's stack.

** Creating a slug directly from the InfluxDB executable does not work because there is no built-in way to listen to the right port given by Heroku in the $PORT environment variable.

Answer 2

I like to think anything is possible on a Heroku node when using a custom buildpack, but there are some considerations when hosting with Heroku:

• ops, e.g. backup, monitoring (does it entail installing extra services, opening extra ports, etc - Heroku might get in the way here)
• performance, considering dyno size
• and if you need a larger dyno, cost becomes an issue. You'll get more bang for your buck when you go the IaaS route.
• other "features" of a dyno, e.g. disk ephemerality

I highly recommend hosted InfluxDB or spinning up your own on a VPS, all of which you can point your existing Heroku-based apps to. It will then help to get those instances as close together as possible (i.e. same region, or co-located if possible), presuming a need for low latency between DB and app stack.