Configuring apps
The following table shows the config variables used to set individual apps inside nebula (via the API):
field | type | example value | description |
---|---|---|---|
starting_ports | list of int and\or dicts | [{"85": "80"}, 443, 5555] | a list of starting ports to bind the work containers, if ints the host port & the container port will be the same value, if dict it will follow the {"host_port":"container_port"} format, note that due to JSON format if using a dict values must be passed as strings (with ""), if using ints values must not be passed as strings, mixing and matching is allowed, for example a worker server with 8 CPU's & containers_per={"cpu": 3} and starting_ports=[{"81": "80"}] will have 24 containers binding to port 81 to port 104, so your worker-node LB can bind to port 80 and redirect traffic among the container on ports 81...104 which are bounded on the host & redirect to port 80 inside the container, an HAProxy config example can be found at example-config, use [] for non |
containers_per | dict | {"server": 3} or {"cpu": 0.5} | the number of containers to run on each worker node, possible keys are {"server": int}, {instance": int} & {cpu": int/float}, server and instance are both the same and will load x number of containers on each node, cpu will load x containers per cpu on each node |
env_vars | dict | {"test1": "test123", "example": "example123"} | a dict of envvars that will be passed to each work containers, use {} for non |
docker_image | string | "registry.vidazoo.com:5000/nginx" | what docker image to run, note that it's currently not possible to set a different starting command then the one set in the container Dockerfile |
running | bool | true | true - app will run, false - stops said app |
networks | list | ["nebula", "bridge"] | the networks containers will be part of, if you wish to use "host" or "none" networks make sure that they are alone in the list (["host"] or ["none"]), a default bridge user network named "nebula" is also added in any case which is not "host" or "none", the "nebula" network can either be added explicitly (["nebula", "example-net"]) or implicitly (["example-net"]) and will also be added if an empty list is set ([]), note that aside from the default "nebula" network (& Docker default networks of "bridge", "none", "host") you will have to create what networks you wish to use manually on the worker prior to using them, the main advantage of the default "nebula" user network over the "bridge" network is that it allows container name based discovery so if you have a server with 2 containers named "con1" and "con2" you can ping from "con1" to "con2" just by using "ping con2" from inside "con1" |
volumes | list | ["/tmp:/tmp/1", "/var/tmp/:/var/tmp/1:ro"] | what volumes to mount inside the containers ,follows docker run -v syntax of host_path:container_path:ro/rw, use [] for non |
privileged | bool | false | true - app gets privileged permissions, false - no privileged permissions |
devices | list | ["/dev/usb/hiddev0:/dev/usb/hiddev0:rwm"] | what devices to grant the containers access ,follows docker run --device of host_path:container_path:ro/rwm, use [] for non |
Configuring Nebula
The following table shows the config variables used to set nebula:
conf.json variable name | envvar variable name | used in | default value | example value | type | description | required |
---|---|---|---|---|---|---|---|
basic_auth_user | BASIC_AUTH_USER | api-manager | admin | string | the basic auth user used to secure the api-manger - unless you set basic_auth_enabled=false you must configure it | no | |
basic_auth_password | BASIC_AUTH_PASSWORD | api-manager | P@ssw0rd | string | the basic auth password used to secure the api-manger - unless you set basic_auth_enabled=false you must configure it | no | |
basic_auth_enabled | BASIC_AUTH_ENABLED | api-manager | true | false | bool | defaults to true, if set to false will disable basic auth on nebula-api, setting to false is only recommended to be used if you are using an upstream LB\web server that handles the basic-auth for you instead | no |
ENV | api-manager | prod | dev | string | envvar only, defaults to "prod", if set to "dev" will use flask built-in web server on port 5000 to make devs life a tad easier, unless your developing new features to nebula or hunting down a bug in it best to not include it at all | no | |
rabbit_host | RABBIT_HOST | api-manager & worker-manager | rabbit.example.com | string | RabbitMQ host FQDN or IP | yes | |
rabbit_port | RABBIT_PORT | api-manager & worker-manager | 5672 | 5672 | int | RabbitMQ port | yes |
rabbit_user | RABBIT_USER | api-manager & worker-manager | rabbit | string | RabbitMQ user | yes | |
rabbit_password | RABBIT_PASSWORD | api-manager & worker-manager | Rabbit123 | string | RabbitMQ password | yes | |
rabbit_vhost | RABBIT_VHOST | api-manager & worker-manager | / | vhost | string | RabbitMQ vhost (without the /) | yes |
rabbit_heartbeat | RABBIT_HEARTBEAT | api-manager & worker-manager | 3600 | 3600 | int | RabbitMQ heartbeat, set to 0 to disable, be aware that setting the heartbeat below the time it takes for a command to complete might break rabbit connection & cause the worker-manager container to fail so best to set to long times ( for example 3600 seconds) | yes |
mongo_url | MONGO_URL | api-manager | mongodb://mongo_user:mongo_pass@mongo_host:27017/?ssl=true&replicaSet=mongo_replica_set&authSource=mongo_auth_schema | string | mongo URI string | yes | |
schema_name | SCHEMA_NAME | api-manager | nebula | mongo_schema | string | mongo schema name | yes |
registry_auth_user | REGISTRY_AUTH_USER | worker-manager | None | user | string | the docker registry basic auth user, if not set or set to None (the default value) Nebula will attempt to use the standard registry config file that's located inside the container "~/.docker/config.json" file path & if that's not configured will carry using no registry auth | no |
registry_auth_password | REGISTRY_AUTH_PASSWORD | worker-manager | None | P@ssw0rd | string | the docker registry basic auth password, if not set or set to None (the default value) Nebula will attempt to use the standard registry config file that's located inside the container "~/.docker/config.json" file path & if that's not configured will carry using no registry auth | no |
registry_host | REGISTRY_HOST | worker-manager | https://index.docker.io/v1/ | https://my_registry.example.com:5000 | string | the docker registry FQDN or IP | yes |
max_restart_wait_in_seconds | MAX_RESTART_WAIT_IN_SECONDS | worker-manager | 0 | 5 | int | maximum time each worker server will wait before reloading the containers in case of restart\update (minimum time hard coded to 0 and each worker server will randomly choose between the that range to spread load on rabbit\mongo) | yes |
APP_NAME | worker-manager | example-app,example-app-logging,example-app-load-balancer,yet-another-example | string | envvar only, used to set what apps run on said workers, format is a comma separated list of nebula app names | yes |
envvars take priority over variables set in the conf.json file in case both are set (the registry user & pass values can also be set by using the standard "~/.docker/config.json" file and not setting them as envvars and the Nebula config file ), it's suggested to always wrap envvars values in Quotation marks but it's only required if the envvar uses special characters (for example "mongodb://mongo_user:mongo_pass@mongo_host:27017/?ssl=true&replicaSet=mongo_replica_set&authSource=mongo_auth_schema"), some variables have defaults that will be used if they are not set as envvars and in the conf.json file.
An example config file is located at "example_conf.json" at the root folder of either the worker-manager and the api-manager github repo root folder (and inside the containers of them by extension).
The following table shows the path of each config file inside the docker containers:
container | config path inside container | example Dockerfile COPY command overwrite |
---|---|---|
api-manager | /www/conf.json | COPY conf.json /www/conf.json |
worker-manager | /worker-manager/conf.json | COPY conf.json /worker-manager/conf.json |
As the api-manager uses gunicorn as the main application web-server inside the container there is a config.py at the container root folder, consult gunicron guide if you wish to change it's parameters.