Expose all services at well-known ports

[joeshelton-wagento]

Currently, the web entrypoints are mapped to well-known ports, 80 and 443. But the other services like DB and Redis are exposed on random ports. I propose that all services be exposed on well-known ports to enhance user-friendliness. And additionally add a build option for not exposing any ports that would best accommodate extensibility and customization of ports in an override file.

[keithbentrup]

The ports are already exposed. You would just map them to your desired local ports. Ideally, we don't map them for everyone by default in the generated docker-compose.yml file because not everyone has the same use case. If fact, I think we should actually move some of the existing default port mappings from the generated docker-compose.yml because it's already limiting in a couple ways (1. hinders multiple stacks 2. interferes with existing local services) and doesn't account for how docker-compose yaml files inherit the ports key (cumulative, not overriding).

A simple, sample reusable docker-compose.override.yml placed in the dist/ dir and mapped in composer.json to /docker-compose.override.yml will accomplish the desired result. It also provides the added benefit of a clear point of further extension for end users.

# contents of proposed static file: docker-compose.override.yml 
# (OR docker-compose.override.yml.sample if desired. see comments below)

version: '2.1'
services:
  web:
    ports:
      - 80:80
  tls:
    ports:
      - 443:443
  db:
    ports:
      - 3306:3306
  redis:
    ports:
      - 6379:6379

I'm for further discussing what's the right "default". Should this be docker-compose.override.yml or docker-compose.override.yml.sample? Should the content only have the web and tls ports mapped, and have db & redis (and others) commented out ready for the user to uncomment if desired.

However, I really don't think default port mappings belong "locked" in php code that's much harder to for a casual user to extend/fork, undo, or customize to their desired use cases. The service names are not going to change nor are the standard port mappings, so this should be a simple static file that's intended (but not necessarily required) to be modified by the end user with intelligent defaults that account for 1) how docker-compose inheritance works 2) the current most common use case 3) not limiting to a wider audience with a variety of uses.

[joeshelton-wagento]

I like the idea of a sample override file. It would help to guide new users along the correct path to customization. Could that be introduced as a separate issue? For the short term, I'd like to resolve the inconsistency in the port mapping scheme using the build tool. We can use docker:build to generate a configuration that accommodates the two port schemes that have been proposed. One that is a functional and familiar default. Another that is ideal for customization.

[YPyltiai]

I guess we all need to meet for a grooming session to discuss this one and general approach to make it work for everyone.

As I see it, we could add some option as --custom-ports to skip hard-coding ports and allow for customization. By default we could add the default ports though to cover most use cases (I guess this is most common one if you don't run many projects at once). At the same time we can deprecate other arguments like the one exposing db ports, since it will become redundant at this point.

What are your thoughts on the above ^ ?

Edit: and if you use --custom-ports, bundling sample override as well.

[keithbentrup]

@joeshelton-wagento What I'm proposing can be used by you and your team right now. Go to your app dir and just curl -O https://gist.githubusercontent.com/keithbentrup/8a29a39681365fcf1290ffd3b20404da/raw/ef6ee3cf2d6a6a67baf68a7bc697b97e9dd970ba/docker-compose.override.yml That's it. docker-compose will automatically pick it up because of the filename. Instant gratification. No further changes need to be made. We don't need to write code that has good reasons (listed above) to be undone/removed eventually.

[joeshelton-wagento]

I'm familiar with how override files work. A method of customization is not at the heart of the issue. My issue is that currently the build tool configures ports inconsistently, with web services exposed at well-known ports 80 and 443. And all other services exposed at random ports. I believe people will benefit from consistency here.

[shiftedreality]

@magento export issue to Jira MCLOUD as Task

[slavvka]

@magento export issue to Jira project MCLOUD as Task

[magento-engcom-team]

✅ Jira issue (https://jira.corp.magento.com/browse/MCLOUD-6425) is successfully created for this issue.