Generator-jhipster: docker-compose subgenerator sets port to 80, but maps 8080

[ruddell]

Overview of the issue

The monolith docker-compose.yml generated by jhipster docker-compose has conflicting configuration for ports. It maps ports 8080:8080 but also sets SERVER_PORT=80

Motivation for or Use Case

The generated configuration should work out-of-the-box

Reproduce the error

• Generate monolithic app
• Run jhipster docker-compose and choose your monolith
• Start the stack with docker-compose up -d
• App is not accessible on port 80 or port 8080
• Open docker-compose.yml and you'll see:

      - JHIPSTER_SLEEP=30
      - SERVER_PORT=80
    ports:
      - '8080:8080'

##### **Related issues** Introduced in https://github.com/jhipster/generator-jhipster/pull/10763 ##### **Suggest a Fix** @xetys will be more familiar with his goal for the new config, so hoping he'll know whether to remove `SERVER_PORT` or fix the port mapping. https://github.com/jhipster/generator-jhipster/blob/b2232acecd0c7d8a754d6eca3447237ccd3972f5/generators/docker-compose/index.js#L120-L122 ##### **JHipster Version(s)** Only affects master, this change has not been released yet. ##### **JHipster configuration**

.yo-rc.json file

{
  "generator-jhipster": {
    "promptValues": {
      "packageName": "com.mycompany.myapp",
      "nativeLanguage": "en"
    },
    "jhipsterVersion": "6.5.1",
    "applicationType": "monolith",
    "baseName": "mono",
    "packageName": "com.mycompany.myapp",
    "packageFolder": "com/mycompany/myapp",
    "serverPort": "8080",
    "authenticationType": "jwt",
    "cacheProvider": "ehcache",
    "enableHibernateCache": true,
    "websocket": false,
    "databaseType": "sql",
    "devDatabaseType": "h2Disk",
    "prodDatabaseType": "mysql",
    "searchEngine": false,
    "messageBroker": false,
    "serviceDiscoveryType": false,
    "buildTool": "maven",
    "enableSwaggerCodegen": false,
    "jwtSecretKey": "bXktc2VjcmV0LXRva2VuLXRvLWNoYW5nZS1pbi1wcm9kdWN0aW9uLWFuZC10by1rZWVwLWluLWEtc2VjdXJlLXBsYWNl",
    "clientFramework": "angularX",
    "useSass": true,
    "clientPackageManager": "npm",
    "testFrameworks": [],
    "jhiPrefix": "jhi",
    "enableTranslation": true,
    "nativeLanguage": "en",
    "languages": ["en"],
    "embeddableLaunchScript": false,
    "clientTheme": "none",
    "creationTimestamp": 1576512959792,
    "entitySuffix": "",
    "dtoSuffix": "DTO",
    "otherModules": [],
    "blueprints": []
  }
}

Browsers and Operating System

Mac, Node LTS

• [x] Checking this box is mandatory (this is just to show you read everything)

[PierreBesson]

Please don't set the port to 80, this cannot work locally on Linux for regular users as port < 1024 require root.

[pascalgrimaud]

I'm putting a bounty on this, as it needs to be fixed before the release

[jdubois]

In the commit that put port 80, I also notice that it is hard coded in the Java classes: https://github.com/jhipster/generator-jhipster/pull/10763/files#r360642259

[bradsheppard]

I can look into fixing this, although I have a few questions first:

• If we make a change such that SERVER_PORT is 8080, we would also need to switch UAA, however this will create an inconsistency between docker-compose and Kubernetes, as Kubernetes services are all on 80.
• Would potentially the best solution be to keep SERVER_PORT as 80, however switch the port mapping to 8080:80? This way in the docker compose network, things are still resolvable via their DNS (ie http://serviceName) however on the host-machine you can access the service via 8080.

[pascalgrimaud]

For now, to fix this bug quickly, I prefered to revert this PR https://github.com/jhipster/generator-jhipster/pull/10763 unfortunately: it's sad but I have no choice as I'm really short on time.

Then, you can rework the UAA part ; have a look at https://github.com/jhipster/generator-jhipster/issues/8967 and https://github.com/jhipster/generator-jhipster/issues/9027 by using the code provided in https://github.com/jhipster/generator-jhipster/pull/10763

[SudharakaP]

@pascalgrimaud : I think this issue was closed by mistake? :thinking:

EDIT: Ops, my mistake; I think you opened all the other relevant PRs. :+1:

[pascalgrimaud]

@SudharakaP : not by mistake as this issue was introduced by #10763 and as I reverted this PR, this issue is gone.

[SudharakaP]

@pascalgrimaud : My mistake; saw that just after I made the comment. :smile:

[bradsheppard]

@jdubois Do we still plan on using the "Port 80 and services with RouteDetector" solution as described in #10763. The docker-compose fix related to this issue is pretty easy, but I'm just wondering if we plan on still going ahead with assuming all services are running on port 80.

[jdubois]

@bradsheppard I didn't know that @xetys did use port 80 on purpose... I wouldn't use port 80 by default because on many OSes it will be blocked, then I trust @xetys on this part (he knows this much better than I do). The important thing for me is that we have something consistent, and have the same port in the env variable and the Docker Compose config.

[bradsheppard]

Makes sense. In that case we can probably re-introduce #10763 with a fix to the docker compose generator. Thanks for clarifying!

[xetys]

Hey guys, sorry got bit familiy busy on xmas days

It's a pity with this, as the solution would have been so easy. The hard port 80 mapping should ONLY be for microservices which are NOT exposed to docker-compose anyways. The idea behind it is just this:

If we do not use service discovery, as eureka is disabled, all forwarding calls from gateway, as well as service-to-service calls should still work for URLs like http://service-name. We don't add ports, as Ribbon and Eureka are translating these URLs properly. However, without eureka, we would need to add the ports in all URLs for these calls. AFAIK, we don't transport the port values for microservice entities, so this would be probably a huge change of the way we keep entity configuration. This problem can be solved by:

• exposing all "inner" services to port 80 in docker-compose, as we only need 80XX ports for local development
• making a similar configuration for k8s

It should not affect monolith (or any non-ui applications) at all. This was my fault, sorry for that. It's sad that we had to revert this

[pascalgrimaud]

@xetys : it has been reintroduced, with the correct fixes. It should be included in the next release if there is no regression. Thanks to @bradsheppard

@bradsheppard : don't forget to claim the bouny, although it is closed, it seems you found the correct fix