0

I'm trying to serve two (Openresty) Lua web applications as virtual hosts from NGINX which both require their own unique lua_package_path, but have a hard time getting the configuration right.

# Failing example.conf

http {
  lua_package_path = "/path/to/app/?.lua;;"

  server{
    listen       80;
    server_name  example.org
  }
}

http {    
  lua_package_path = "/path/to/dev_app/?.lua;;"

  server{
    listen       80;
    server_name  dev.example.org
  }
}
  1. If you define the http twice (one for each host), you will receive this error: [emerg] "http" directive is duplicate in example.conf

  2. If you define the lua_package_path inside the server block, you will receive this error: [emerg] "lua_package_path" directive is not allowed here in example.conf

  3. If you define the lua_package_path twice in a http block (which does not make any sense anyway), you will receive this error: [emerg] "lua_package_path" directive is duplicate in example.conf

What is the best practise of serving multiple (Openresty) Lua applications with their own lua_package_path, being virtual hosts on the same IP and port?

Gawin
  • 994
  • 10
  • 12

2 Answers2

3

I faced this issue several month ago. I do not recommend no use debug and release projects in the same server. For instance, you launch the one nginx application for both (debug and release) key may lead to unexpectable behaviour. But, nevertheless, you can setup:

  1. package.path = './mylib/?.lua;' .. package.path inside lua-script.
  2. You can setup your own local DEBUG = false state and manage inside the app.
  3. Obviously, use the other machine for debug. Imo, the best solution.
  4. Execute different my.release.lua or my.debug.lua file:
http {
          lua_package_path "./lua/?.lua;/etc/nginx/lua/?.lua;;";



        server{
            listen       80;
            server_name  dev.example.org;
              lua_code_cache off;


        location / {
                default_type text/html;
                content_by_lua_file './lua/my.debug.lua';
              }
        }
        server{
            listen       80;
            server_name  example.org

        location / {
                default_type text/html;
                content_by_lua_file './lua/my.release.lua';
              }
          }
        }
Vyacheslav
  • 26,359
  • 19
  • 112
  • 194
  • Thank you for your pointers, really helpful! And I totally agree on separating production and development servers in a live environment. Although in this case I have 12 virtual hosts running on my laptop and I don't feel like running 12 separates virtual servers (or NGINX processes) for that. – Gawin Sep 22 '16 at 11:28
1

Fixed it removing the lua_package_path from the NGINX configuration (since the OpenResty bundle already takes care of loading packages) and pointing my content_by_lua_file to the absolute full path of my app: /var/www/app/app.lua

# example.conf

http {

  server{
    listen       80;
    server_name  example.org

    location / {
      content_by_lua_file '/var/www/app/app.lua';
    }
  }

  server{
    listen       80;
    server_name  dev.example.org

    location / {
      content_by_lua_file '/var/www/app_dev/app.lua';
    }

  }
}

After that I included this at the top of my app.lua file:

-- app.lua

-- Get the current path of app.lua
local function script_path()
   local str = debug.getinfo(2, "S").source:sub(2)
   return str:match("(.*/)")
end

-- Add the current path to the package path
package.path = script_path() .. '?.lua;' .. package.path

-- Load the config.lua package
local config = require("config")

-- Use the config
config.env()['redis']['host']

...

This allows me to read the config.lua from the same directory as my app.lua

-- config.lua

module('config', package.seeall)

function env()
  return {
    env="development",
    redis={
      host="127.0.0.1",
      port="6379"
    }
  }
end

Using this I can now use multiple virtual hosts with their own package paths.

@Vyacheslav Thank you for the pointer to package.path = './mylib/?.lua;' .. package.path! That was really helpful! Unfortunately it also kept using the NGINX conf root instead of my application root. Even with prepending the . for the path.

Gawin
  • 994
  • 10
  • 12