Working with Routes
A route maps a URL endpoint to a job instance (container) at an exposed port. The Apcera router load balances and routes requests for a given URL endpoint to the set of jobs listening for that traffic.
Supported Route Types
Apcera supports HTTP and TCP routes. HTTP routes can be served using
https protocols (assuming your cluster is configured for SSL). You can also configure a route to be HTTPS-only so that Apcera platform router automatically redirect request for a route using
http to the
http endpoint. See Enforcing HTTPS on Routes. You can also restrict client access a route by client IP address range (see Controlling Route Access by Client IP).
Applications can share route endpoints. Adding the same route endpoint to a multiple jobs will affect the proportion of traffic delivered to each job based on the routes' weights. If, for instance, both routes are created with 0% weight, then each job will get half of the traffic routed. See Route Sharing.
Enforcement of HTTPS on routes
By default, a route you define on a job can be reached either over HTTP or HTTPS (assuming your cluster is configured to handle SSL traffic). You can optionally enforce HTTPS on a route. This causes the Apcera router to automatically redirect HTTP requests to the HTTPS endpoint.
NOTE: Secure connections are terminated at the Apcera router, so jobs do not receive HTTPS traffic. Enforcing HTTPS on a route only ensures that connections to the Apcera router are made over HTTPS.
Custom SSL Certificates for Custom Domains
By default, HTTPS traffic is limited to routes on the same domain as the SSL certificate used when installing the Apcera cluster. For example, if your cluster's domain is "example.com" then you can create a secure route with
login.example.com, but not
You can optionally install your own SSL certificate and key pair for a custom domain to enable SSL traffic on that route. See Managing SSL Certificates for Custom Routes.
Sticky Session Cookies
By default, the Apcera router load balances requests evenly among all job instances using a round-robin approach. There is no guarantee that a client will connect to the same job instance on subsequent requests. You can optionally enable sticky session cookies that ensures requests are routed to the same job instance that handled the original request.
Restricting Route Access by IP Address
You can also restrict client access a route by client IP address range (see Controlling Route Access by Client IP).