Vert.x Gateway Configuration Guide
The Vert.x gateway is configured via a simple JSON file, generically referred to here as config.json
.
This guide provides a brief outline to some of the most important information that may be unique to this platform.
Annotations in the configuration file should be considered canonical.
Comments
Unlike standard JSON, you can insert comments into the configuration by using C-style // comment
syntax.
{
"foo": "bar" // This is a comment.
}
Variables
The configuration supports variable substitution (transclusion) in the form "${FOO.SOME_VARIABLE}"
; where FOO.SOME_VARIABLE
is the variable to be transcluded.
The following list defines the lookup sources and order of precedence for variable resolution.
-
JSON config’s
variables
section:{ "variables": { "FOO": { "SOME_VARIABLE": "foo" } } }
-
System properties:
-DFOO.SOME_VARIABLE="foo"
-
Environment:
export FOO.SOME_VARIABLE="foo"
A default value can be provided, which will be used if other lookup sources fail.
For example ${MAGIC_NUMBER:-8090}
will result in 8090
being set if MAGIC_NUMBER
is unresolved after the prior steps.
Registries, factories and components
To configure a registry, component or factory, set the class
to the corresponding fully qualified name of a valid implementation on the classpath.
You can pass arguments to the component using the config
section.
{
"registry": {
"class": "io.apiman.gateway.engine.es.PollCachingESRegistry", (1)
"config": {
"client": {
"client": "jest",
"protocol": "${apiman.es.protocol}", (2)
"host": "${apiman.es.host}",
"port": "${apiman.es.port}",
"initialize": true,
"username": "${apiman.es.username}",
"password": "${apiman.es.password}",
"timeout": "${apiman.es.timeout}"
}
}
}
}
1 | Fully qualified path to registry class. |
2 | Note the variables here, which will be resolved as defined in Variables. |
Verticles and scaling
To scale your gateway, you can alter the number of verticles that will be spun up per-JVM when the project is deployed by changing count
.
If you prefer, a count value of "auto"
will provide a sensible default based upon the number of cores.
{
"verticles": {
"http": { "port": 8082, "count": "auto" },
"https": { "port": 8443, "count": 1 },
"api": { "port": 8081, "count": 1 }
}
}
If you don’t want any instances of a particular verticle type, set its count
to 0
.
Which port the verticle listens on can be changed with port
.
Verticle count only defines the number of verticles deployed in a given JVM instance. How many deployments, and hence total number of verticles exist within your overall cluster is entirely up to you. |
HTTPS
Encrypted HTTPS entry-point, with TLS/SSL. Turn off by reducing count to zero. Add you keystore and truststore to the SSL section of your configuration to enable this functionality.
Endpoint
{ "endpoint": "mynode.local" }
Force the gateway to report the given gateway endpoint when it is queried by the manager. By default the gateway will inspect the request used to hit the Gateway API, and use whichever address was used to reach it as the endpoint.
SSL
The SSL section configures transport security to the gateway’s front end; that is, connections established between client app ⇋ Apiman Gateway.
"ssl": {
"keystore": {
"path": "/the/keystore/path/here.jks",
"password": "password-here"
},
"truststore": {
"path": "/the/truststore/path/here.jks",
"password": "password-here"
},
// Allowed TLS/SSL protocols for Client <-> Gateway (Server)
"allowedProtocols": "TLSv1.1, TLSv1.2"
}
The precise keystore and truststore setups to use will vary considerably depending upon your organisation and security requirements; hence, they are out of the scope of this guide.
Refer to the Java keytool reference for more information on creating keystores and truststores. |
Prefer Secure
{ "preferSecure": true }
When reporting gateway endpoints (as above), set whether to prefer reporting the secure (HTTPS) URI rather than an insecure one (HTTP). This is likely the preferred option for production deployments where transport security has been configured.