Load balancer with hostname
Exposing non-HTTP-based services to the internet
Release will automatically handle services that are HTTP-based and generate hostnames for the backend services. But not all services are HTTP: many services listen for other types of traffic, like TCP or UDP traffic.
In order to expose a non-HTTP service to the internet, you will need to define a
node_port. A node_port requires both a target_port and a port number.target_port: This is the port on the pod that the request gets sent to internally. Your application needs to be listening for network requests on this port for the service to work.port: The specified port within the cluster that exposes the service externally. The service is visible on this port, and other pods and services will send requests to this port to reach the service.- Release doesn't define a fixed
NodePortin Kubernetes, which allows Kubernetes to allocate a random port from the host node. However, for external communications, the fixed port is applied to the load balancer. This allows services that run on the same port number to coexist with other applications on the same physical nodes without conflict.
Once you have defined a
node_port for your service, you can define a hostname. Release uses variable interpolation for env_id and domain.Here is an example of exposing a Minecraft service to the internet:
services:
- name: minecraft
image: dustyspace/docker-minecraft-server/minecraft
has_repo: true
ports:
- type: node_port
target_port: '25565'
port: '25565'
loadbalancer: true
hostname: minecraft-${env_id}-${domain}
The Minecraft service listens on port 25565, creates a load balancer, and generates a hostname.
The code below is an example of exposing a postgres database service to the internet:
services:
- name: db
image: postgres:9.4
ports:
- type: node_port
target_port: '5432'
port: '5432'
loadbalancer: true
hostname: postgres-db-${env_id}-${domain}
Last modified 3mo ago