Adding internal option to ports.mode

What is the problem you're trying to solve While working on an experiment to create a Helm chart that can consume a Compose file as its values and convert it into k8s manifests, I ran into an interesting problem. When using Docker Compose or Swarm, all container-to-container communications were supported without additional configuration for each exposed port; only ports exposed on the host and external to the cluster needed to be defined. However, in other orchestration environments, this automatic ability to use ports isn't guaranteed. In Kubernetes, Service objects have to be created to support pod-to-pod communication. This then means all exposed ports for a container/port need to be explicilty defined.

But, there are varying levels of "exposure", including pod-to-pod (ClusterIP), host (NodePort), and cluster (LoadBalancer). While not quite as versed with ECS's service discovery mechanisms, I imagine similar situations where a task's ports are exposed only internally (using SRV records) versus being exposed publicly via a load balancer and target groups.

Current limitations of the spec Looking at the current ports.mode spec, it doesn't cover enough of the potential use cases. With the two existing supported modes, I see them mapping as the following:

• The host option indicates "publishing a host port on each node". In the case of a k8s deployment, this feels like a NodePort-based Service.
• The ingress option indicates "a port to be load balanced". In Swarm, this meant it was added to the ingress network, letting it be more accessible to the exterior of the cluster. When mapping to Kubernetes, this feels like a LoadBalancer service.

Looking at these options, the only thing that is missing is the ability to specify a port is for internal use only.

Proposed solution I'd like to propose adding a third option named internal, in which the intent is to expose the port only internally to other pods/containers in the cluster/orchestration environment. This option has no need in Swarm-based deploys (since all exposed ports are available automatically without configuration), but would support the creation of ClusterIP Services in Kubernetes and Route53-based service discovery in ECS.

imho we should keep ports.mode as a legacy attribute and better express such things by routing rules (see https://github.com/compose-spec/compose-spec/issues/111)

I'd be cool with that idea if the routing rules is general enough to support use cases in which 1) the routing is internal-only and 2) applications are non-HTTP based. I ran into these situations when trying to create Service objects mappings for things like databases, redis caches, etc, which the typical ingress/routing rules doesn't quite work for.

@mikesir87 I had the same sensation when going from Swarm to Kubernetes or pure ECS. Swarm really nailed this problem in a seamless way :) Maybe we can use AppMesh (ECS) for solving this aligned with #111.