We're going to pick up from where we left off yesterday in this second piece, taking a more detailed look into service configuration and how we enable port mapping to connect traffic from inside your container with the outside world.
Is there anybody there?
The purpose of a service inside your application is to be able to respond to web queries from the internet. With container-based architecture, to make your services running inside these containers available to resources outside the container, you need to provide a 'bridge' from inside to the outside world. And this doesn't just relate to HTTP traffic - it also covers web sockets, DB containers or custom TCP/UDP traffic.
Code running inside a container listens to a specific port and by default, a standard setup for a web server will listen to port 80 for HTTP and 443 for HTTPS traffic. All applications listen to these ports so site visitors don’t need to enter port numbers into their browsers. Here's a list of default ports used by different programming frameworks or application servers:
Container Port Mapping
You can use the Container Port Mapping feature in Cloud 66 to create your ports map. It's a simple to use yet flexible feature that supports common TCP protocols like HTTP and HTTPS as well as custom TCP and UDP traffic.
Port options allow you to specify the ports definitions for your service, comprising of a CONTAINER_PORT:HTTP_PORT:HTTPS_PORT list. It's worth noting that the HTTP_PORT and HTTPS_PORT fields are optional, and it's possible to have HTTPS without HTTP if you wish and vice-versa. You can do this by including the colons, but leaving that corresponding port number blank. You can also define multiple port definition triplets for a single service, such as:
services:
<service_name>:
ports: ["3000:80:443", "4000::8443", "5000"]
Mapping ports inside and outside
In the above example, the application is listening on port 3000 in the container, and that port is exposed via HTTP on port 80, and HTTPS on port 443. Port 4000 inside the container is also available on port 8443 externally, and port 5000 in the container is available locally on the server.
If you are using a service.yml file to configure your services, you can use the following format to specify the ports: InsidePort:HTTP_Port:HTTPS_Port:
services:
my_service:
ports: ["3000:80:443"]
This syntax allows you to tell Cloud 66 that you don’t want the service to be available on HTTPS only:
services:
my_service:
ports: ["3000::443"]
You can omit the HTTPS port by dropping the last part:
services:
my_service:
ports: ["3000:80"]
These HTTP/HTTPS ports are available from outside the server, and any traffic to these ports will be redirected to any containers running this service. During scaling, any containers running this service will get traffic distributed to them in a round robin fashion.
If your application doesn't serve HTTP traffic (like a database) you can map the ports by specifying the protocol (TCP or UDP), along with the ports it listens to inside the container, to the port you'd like it to be available publicly.
An example: a service that listens on port 5454 on UDP, where we'd like to make it available to the outside world on port 111::
services:
my_service:
ports:
- container: 5454
udp: 111
For further information on all Container Port Mapping features, see our Service Network Settings help page. There's lots more content like this on our Community site and you can also join in on our Cloud 66 Slack channel.
Thanks and happy coding.