MySQLi and Heroku – Round 2

If you liked this post, say thanks by sharing it:

Read Previous Article

Well after a comment from a reader on a previous post regarding heroku and mysqli, I set out to figure it out.  After doing some digging, the cedar stack that Heroku is currently on is really great.  You can run virtually any environment from node to emacs and beyond.  Turns out, it all revolves around buildpacks, the secret behind cedar.

The secret behind getting mysqli on heroku is actually fairly straight forward.

  1. Start with the canned php buildpack on cedar
  2. Remove unwanted things like mcrypt
  3. Build and Compile binaries with dependencies and libraries
  4. Host the files on S3
  5. Create the buildpack
  6. Finished Product: https://github.com/travstoll/heroku-buildpack-php

1.  I cloned the default buildpack for php from github: https://github.com/heroku/heroku-buildpack-php

2. Edit the binary build script to remove things like mcrypt which I didn’t need for this project.  The bash commands that I ran can be found in the readme.md file of the repo: https://github.com/travstoll/heroku-buildpack-php

3. When you create a heroku app

heroku create

there is the option of getting into the one off dyno and playing around a bit.  This tends to be very useful when creating a buildpack.  Using

heroku run bash

you can access the dyno and run the bash commands to get and compile apache and php.  Alternatively this can be done on your local machine, or on another server.  Its just as easy to use the heroku shell though.

**After this is done, you will have apache and php tarballed and ready in the /app directory of the server.  Simply scp them to somewhere for the next step (scp /app/apache username@server.com:/path/to/store)

4.  Now you need a place to host your compiled binaries that heroku can access.  I would recommend s3 since heroku is alreay hosted on amazon.  This makes it easy, cheap, and of course HA.

5.  The next step is creating the actual buildpack.

A buildpack consists of three scripts:

  • bin/detect: Determines whether to apply this buildpack to an app.
  • bin/compile: Used to perform the transformation steps on the app.
  • bin/release: Provides metadata back to the runtime.

How I did this can be found in the github repo I forked.  Essentially you point the heroku slug compiler to the pre-compiled environment, in our case, php and apache.

All you need to do at that point then is config your app to use the custom buildpack:

heroku config:set BUILDPACK_URL=https://github.com/travstoll/heroku-buildpack-php

You can then create an empty commit and push your app again to force heroku to recompile the runtime:


git commit --allow-empty -m "empty commit"

git push heroku master

Thats it.  After some playing around it really wasn’t all that hard.  A couple hours of reading documentation and playing with the one off dyno’s and here we are.  You can read more in the dev center about the buildpack api: https://devcenter.heroku.com/articles/buildpack-api

Video soon to come.

If you liked this post, say thanks by sharing it:
Posted in Heroku

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>