commit | c064b29e84e706a5ce9d014f7496f2c56de0df0b | [log] [tgz] |
---|---|---|
author | Chetan Mehrotra <chetanm@apache.org> | Mon Jul 29 17:24:01 2019 +0530 |
committer | GitHub <noreply@github.com> | Mon Jul 29 17:24:01 2019 +0530 |
tree | 678b1d51d717e3cda726deabb2aa83d27f0c216e | |
parent | add9e6fcb2a9ec71a1c266f67ef7586203c9f135 [diff] |
Enable overriding the backend url to enable standalone mode (#347) * Fix broken building by updating the opm version * Enable override of backend url via env * Run code scan before installing deps * run busted in test directory * Update ngx var also * Use nightly tag for controller and invoker docker images * Make script executable * Terminate early in case of error in scan * Reorder steps * Add EOL
A performant API Gateway based on Openresty and NGINX.
This project is currently considered beta stage, Large swaths of code or APIs may change.
docker run -p 80:80 -p <managedurl_port>:8080 -p 9000:9000 \ -e PUBLIC_MANAGEDURL_HOST=<managedurl_host> \ -e PUBLIC_MANAGEDURL_PORT=<managedurl_port> \ -e REDIS_HOST=<redis_host> \ -e REDIS_PORT=<redis_port> \ -e REDIS_PASS=<redis_pass> \ openwhisk/apigateway:latest
(Optional) The redis password can be passed in encrypted using the aes-256-cbc
encryption algorithm. To do so, pass in the following environment variables, in addition to the encrypted password:
DECRYPT_REDIS_PASS=true
ENCRYPTION_KEY=<32 Byte hex string that was used for encryption>
ENCRYPTION_IV=<16 Byte hex string that was used for encryption>
The Gateway can sync its configuration with a remote folder in the cloud such as Amazon S3, Google Cloud Storage, IBM Cloud Object Storage, Dropbox, and many others. The configuration is monitored for changes, and when a file is changed, the Gateway is reloaded automatically. This is very useful to gracefully update the Gateway on the fly, without impacting the active traffic; if the new configuration is invalid, the Gateway doesn't break, running with the last known valid configuration.
This feature is enabled by configuring a few environment variables:
REMOTE_CONFIG
- the location where the configuration should be synced from. I.e. s3://api-gateway-config
. The remote location is synced into is /etc/api-gateway
. The default configuration is found in this project's root folder.REMOTE_CONFIG_SYNC_INTERVAL
- how often to check for changes in the remote location. The default value is 10s
REMOTE_CONFIG_RELOAD_CMD
- which command to execute in order to reload the Gateway. The default value is: api-gateway -s reload
Syncing is done through rclone sync. rclone
has a rich set of options such as what to exclude when syncing, or what to include. An important configuration is --config
, pointing to the config file in /root/.config/rclone/rclone.conf
. The Gateway should be started with /root/.config/rclone
folder mounted so that rclone.conf
is present. To generate a new rclone
configuration simply execute:
docker run -ti --rm --entrypoint=rclone -v `pwd`/rclone/:/root/.config/rclone/ openwhisk/apigateway config
This runs an interactive rclone config
command and stores the resulted configuration in ./rclone/rclone.conf
file.
To test this locally, simulate a remote folder using a local location, by mounting it in /tmp
folder as follows:
docker run -ti --rm -p 80:80 \ -v `pwd`:/tmp/api-gateway-local -e REMOTE_CONFIG="/tmp/api-gateway-local" \ -e REDIS_HOST=redis_host -e REDIS_PORT=redis_port openwhisk/apigateway
Then make changes to any configuration file ( i.e. api-gateway.conf
), save it, then watch as the Gateway reloads the updated configuration automatically.
To build the docker image locally use:
make docker
To Run the Docker image
make docker-run PUBLIC_MANAGEDURL_HOST=<mangedurl_host> PUBLIC_MANAGEDURL_PORT=<managedurl_port> \ REDIS_HOST=<redis_host> REDIS_PORT=<redis_port> REDIS_PASS=<redis_pass>
First install the necessary dependencies:
make test-build
Then, run the unit tests:
make test-run
Apache OpenWhisk API Gateway is an effort undergoing incubation at The Apache Software Foundation (ASF), sponsored by the Apache Incubator. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.