• HOME
  • INTEGRATIONS
  • SDKS
  • GUIDES
  • API DOCS
No results for ""
EXPAND ALL
CLOSE
launchdarkly.com

EDIT ON GITHUB

Using the Lua SDK with NGINX

Read time: 1 minute
Last edited: Jul 27, 2020

Overview

This guide explains how to use our Lua server-side SDK with the NGINX OpenResty framework.

OpenResty extends NGINX with LuaJIT, enabling complex control of NGINX functionality. The OpenResty framework has substantial commercial adoption.

Find a basic Dockerized app in our GitHub repository at hello-nginx.

Prerequisites

To complete this guide, you must have the following prerequisites:

  • Basic working knowledge of the LaunchDarkly Lua server-side SDK
  • Basic working knowledge of the LaunchDarkly C/C++ server-side SDK

The C server-side SDK is required because the Lua server-side SDK is implemented via foreign function interface.

Preparing the Lua server-side SDK

Make the source of the Lua SDK accessible to OpenRESTY. You can control imports with the lua_package_path directive.

For example:

1http {
2 lua_package_path ";;/usr/local/openresty/nginx/scripts/?.lua;";
3 ...
4}

Preparing the C/C++ server-side SDK

Make the source of the C/C++ server-side SDK accessible to the dynamic linker. The most convenient way to do this is to install the binary system-wide at /usr/lib/libldserverapi.so.

Configuring OpenSSL with OpenResty
OpenResty handles OpenSSL in specific ways. You may need to build the SDK from scratch instead of using our release artifacts in order to make OpenSSL work correctly.

Ensuring correct initialization

The most important part of effective SDK usage is managing the lifetime of clients correctly. Because NGINX utilizes process based concurrency, multiple clients initiate. If you accidentally initiate a client per request the application will be substantially slower, as the SDK has to download a fresh ruleset from LaunchDarkly.

Initialize each NGINX worker process exactly once for ideal operations. You can do this with the init_worker_by_lua_file directive. This directive executes a script when a process is freshly spawned. Client initialization should reside in this script. In the example below, this file is called shared.lua.

Here is an example of initialization logic:

1local ld = require("launchdarkly_server_sdk")
2local os = require("os")
3
4local config = {
5 key = os.getenv("LD_SDK_KEY")
6}
7
8return ld.clientInit(config, 1000)

Later we can use the result of this initialization process in other directives.

1local ld = require("launchdarkly_server_sdk")
2local client = require("shared")
3local os = require("os")
4
5local user = ld.makeUser({
6 key = "abc"
7})
8
9if client:boolVariation(user, "YOUR_FLAG_KEY", false) then
10 ngx.say("<p>feature launched</p>")
11else
12 ngx.say("<p>feature not launched</p>")
13end

Example: Feature flagged reverse proxy

This reverse proxy example demonstrates more complex interaction between multiple NGINX directives. You can use a reverse proxy to route traffic to multiple applications.

The example follows:

1location / {
2 set $proxy_host "";
3
4 rewrite_by_lua_block {
5 local ld = require("launchdarkly_server_sdk")
6 local client = require("shared")
7
8 local user = ld.makeUser({
9 key = "abc"
10 })
11
12 ngx.var.proxy_host = client:stringVariation(user, "YOUR_FLAG_KEY", "10.0.0.0")
13 }
14
15 proxy_pass https://$proxy_host$uri;
16 proxy_set_header Host $proxy_host;
17 proxy_set_header X-Forwarded-For $remote_addr;
18}