Skip to content

Latest commit

 

History

History
285 lines (209 loc) · 11.7 KB

readme.md

File metadata and controls

285 lines (209 loc) · 11.7 KB
Raw

Heroku Buildpack: NGINX

This is Belly's fork of ryandotsmith/nginx-buildpack. Here's what is different:

  • Moved the port variable configuration to a file that can be included in any nginx config file. This is helpful for breaking a large config file into multiple files and still being able to achieve a variable port number (necessary for Heroku). 9c1528a
  • Upgraded nginx to version 1.9.4 & added openssl support. Belly's requirements dictate that our proxy support SSL, so we added it, also upgraded to the latest nginx, since we were recompiling it anyway. 8233318, 0176e38, bfacddd
  • Added start-nginx-solo. The original buildpack expected that you were proxying a request to some app running within the same dyno. This isn't necessary for Belly's use case, so the solo option was added to remove some of the moving parts. f14698e, b19c940
  • Added a configurable domain name option b010d13, 001259a

Recompile nginx

In order to recompile nginx, you need to build it on the target system that it will be running on. In this case we want to build it for cedar-14. Here's how to do it:

  1. Make a local directory for the app that will be used to do the compiling and git init it:
mkdir nginx-builder
cd nginx-builder
git init .
  1. Next, create an app on Heroku for your target stack using the multi buildpack.
heroku create --org belly --buildpack https://github.com/ddollar/heroku-buildpack-multi.git --stack cedar-14

Creating infinite-wave-4795... done, stack is cedar-14
Buildpack set. Next release on infinite-wave-4795 will use https://github.com/ddollar/heroku-buildpack-multi.git.
https://infinite-wave-4795.herokuapp.com/ | https://git.heroku.com/infinite-wave-4795.git
Git remote heroku added
  1. Add the ruby and nginx buildpacks to the .buildpacks file.
echo 'https://codon-buildpacks.s3.amazonaws.com/buildpacks/heroku/ruby.tgz' >> .buildpacks
echo 'https://github.com/bellycard/nginx-buildpack.git' >> .buildpacks
  1. Add a Gemfile. (doesn't really matter what is in there, it just needs a Gemfile to boot)
echo "source 'https://rubygems.org'" >> Gemfile
echo "gem 'unicorn'" >> Gemfile
bundle install
  1. Create a Procfile in your local directory to tell the app what to do when it starts up. build_nginx.sh is the compiler script. So when the dyno boots it will just start to compile right away.
echo 'web: scripts/build_nginx.sh' >> Procfile
  1. Commit those files locally:
git add Procfile Gemfile Gemfile.lock .buildpacks
git commit -m "Added Procfile, Gemfile & buildpacks"
  1. Start tailing the logs in a separate terminal and deploy the app, then immediately scale to a performance L dyno:
heroku logs --tail

git push heroku master
heroku ps:scale web=1:performance-l

  1. If all goes well, the compiler will kick off and you will see output in the logs. This will take some time, so go grab some coffee.

  2. Once the compiler is done the logs will just output a .. From there you can go to your browser and get the built binary.

heroku open

The compiled binary will be in /nginx/sbin/nginx.

  1. Once you have the file, copy it to the bin directory in the nginx-buildpack repo under the appropriate stack name nginx-cedar-14. You can delete the temporary app created on Heroku.

Update - March 2020

To recompile Nginx for a new Heroku stack version, make a new branch from this compile brach, for example compile-heroku-18.

Then update the Nginx version (and OpenSSL version if needed) in this file bin/compile_from_source.sh (see this commit)

NGINX_VERSION=${NGINX_VERSION-1.16.1}
PCRE_VERSION=${PCRE_VERSION-8.38}
HEADERS_MORE_VERSION=${HEADERS_MORE_VERSION-0.23}
OPEN_SSL_VERSION=${OPEN_SSL_VERSION-1.1.1}

Then use this new branch as buildpack on Heroku instead of the master branch on step 3 (see the steps above).

https://github.com/bellycard/nginx-buildpack#compile-heroku-18

Note: The compiled binary will be in the root path of the application (step 9, see the steps above).

-- original readme below --

Heroku Buildpack: NGINX

Nginx-buildpack vendors NGINX inside a dyno and connects NGINX to an app server via UNIX domain sockets.

Motivation

Some application servers (e.g. Ruby's Unicorn) halt progress when dealing with network I/O. Heroku's Cedar routing stack buffers only the headers of inbound requests. (The Cedar router will buffer the headers and body of a response up to 1MB) Thus, the Heroku router engages the dyno during the entire body transfer –from the client to dyno. For applications servers with blocking I/O, the latency per request will be degraded by the content transfer. By using NGINX in front of the application server, we can eliminate a great deal of transfer time from the application server. In addition to making request body transfers more efficient, all other I/O should be improved since the application server need only communicate with a UNIX socket on localhost. Basically, for webservers that are not designed for efficient, non-blocking I/O, we will benefit from having NGINX to handle all I/O operations.

Versions

  • Buildpack Version: 0.4
  • NGINX Version: 1.5.7

Requirements

  • Your webserver listens to the socket at /tmp/nginx.socket.
  • You touch /tmp/app-initialized when you are ready for traffic.
  • You can start your web server with a shell command.

Features

  • Unified NXNG/App Server logs.
  • L2met friendly NGINX log format.
  • Heroku request ids embedded in NGINX logs.
  • Crashes dyno if NGINX or App server crashes. Safety first.
  • Language/App Server agnostic.
  • Customizable NGINX config.
  • Application coordinated dyno starts.

Logging

NGINX will output the following style of logs:

measure.nginx.service=0.007 request_id=e2c79e86b3260b9c703756ec93f8a66d

You can correlate this id with your Heroku router logs:

at=info method=GET path=/ host=salty-earth-7125.herokuapp.com request_id=e2c79e86b3260b9c703756ec93f8a66d fwd="67.180.77.184" dyno=web.1 connect=1ms service=8ms status=200 bytes=21

Language/App Server Agnostic

Nginx-buildpack provides a command named bin/start-nginx this command takes another command as an argument. You must pass your app server's startup command to start-nginx.

For example, to get NGINX and Unicorn up and running:

$ cat Procfile
web: bin/start-nginx bundle exec unicorn -c config/unicorn.rb

Setting the Worker Processes

You can configure NGINX's worker_processes directive via the NGINX_WORKERS environment variable.

For example, to set your NGINX_WORKERS to 8 on a PX dyno:

$ heroku config:set NGINX_WORKERS=8

Customizable NGINX Config

You can provide your own NGINX config by creating a file named nginx.conf.erb in the config directory of your app. Start by copying the buildpack's default config file.

Customizable NGINX Compile Options

See scripts/build_nginx.sh for the build steps. Configuring is as easy as changing the "./configure" options.

Application/Dyno coordination

The buildpack will not start NGINX until a file has been written to /tmp/app-initialized. Since NGINX binds to the dyno's $PORT and since the $PORT determines if the app can receive traffic, you can delay NGINX accepting traffic until your application is ready to handle it. The examples below show how/when you should write the file when working with Unicorn.

Setup

Here are 2 setup examples. One example for a new app, another for an existing app. In both cases, we are working with ruby & unicorn. Keep in mind that this buildpack is not ruby specific.

Existing App

Update Buildpacks

$ heroku config:set BUILDPACK_URL=https://github.com/ddollar/heroku-buildpack-multi.git
$ echo 'https://github.com/ryandotsmith/nginx-buildpack.git' >> .buildpacks
$ echo 'https://codon-buildpacks.s3.amazonaws.com/buildpacks/heroku/ruby.tgz' >> .buildpacks
$ git add .buildpacks
$ git commit -m 'Add multi-buildpack'

Update Procfile:

web: bin/start-nginx bundle exec unicorn -c config/unicorn.rb

$ git add Procfile
$ git commit -m 'Update procfile for NGINX buildpack'

Update Unicorn Config

require 'fileutils'
listen '/tmp/nginx.socket'
before_fork do |server,worker|
  FileUtils.touch('/tmp/app-initialized')
end
$ git add config/unicorn.rb
$ git commit -m 'Update unicorn config to listen on NGINX socket.'

Deploy Changes

$ git push heroku master

New App

$ mkdir myapp; cd myapp
$ git init

Gemfile

source 'https://rubygems.org'
gem 'unicorn'

config.ru

run Proc.new {[200,{'Content-Type' => 'text/plain'}, ["hello world"]]}

config/unicorn.rb

require 'fileutils'
preload_app true
timeout 5
worker_processes 4
listen '/tmp/nginx.socket', backlog: 1024

before_fork do |server,worker|
  FileUtils.touch('/tmp/app-initialized')
end

Install Gems

$ bundle install

Create Procfile

web: bin/start-nginx bundle exec unicorn -c config/unicorn.rb

Create & Push Heroku App:

$ heroku create --buildpack https://github.com/ddollar/heroku-buildpack-multi.git
$ echo 'https://codon-buildpacks.s3.amazonaws.com/buildpacks/heroku/ruby.tgz' >> .buildpacks
$ echo 'https://github.com/ryandotsmith/nginx-buildpack.git' >> .buildpacks
$ git add .
$ git commit -am "init"
$ git push heroku master
$ heroku logs -t

Visit App

$ heroku open

License

Copyright (c) 2013 Ryan R. Smith Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.