Generator-jhipster: Microservice port conflict at localhost

Created on 30 Apr 2020  ·  12Comments  ·  Source: jhipster/generator-jhipster

Not sure it's a bug or a 'feature'
ERROR: for customergateway-postgresql Cannot start service customergateway-postgresql: b'driver failed programming external connectivity on endpoint docker_customergateway-postgresql_1 (7e89d2b724f17888bd1097ac2dd3acda2abcbaee5f0641a8361dca01da1d2495): Bind for 0.0.0.0:5432 failed: port is already allocated'
An attempt to create a simple microservice app with the same DB type. It can be easily solved by setup DB ports for each microservice in JDL. Or even better do not use localhost at all! Use just hostnames like
customergateway-postgresql:5432 instead of
localhost:5432
I this case ports will never collide for services also it's obvious by name 'which-is-which'.

area area should go to module microservice

Most helpful comment

I had a look at https://hub.docker.com/r/strm/dnsmasq/ and indeed, it could be a solution.
But not sure it will work well for users with Windows.

Then, after thinking more about this feature request, I don't think we will change something in our main generator-jhipster as the change is trivial and can be done in less than 30sec.

Adding a new option would be overkill, and we'll have to do the same think for all database, all other services, and maintain it.

What can be done are:

  • a new module for using strm/dnsmasq -> feel free to code your own module and maintain it. I'll be happy to test and play with it
  • add a new tips at https://www.jhipster.tech/tips/

For now, let's close this.

All 12 comments

I've seen this happen when you already have PostgreSQL running on your machine. If you stop the process first, it should work.

On Apr 30, 2020, at 02:41, Maksim Muruev notifications@github.com wrote:


Not sure it's a bug or a 'feature'
ERROR: for customergateway-postgresql Cannot start service customergateway-postgresql: b'driver failed programming external connectivity on endpoint docker_customergateway-postgresql_1 (7e89d2b724f17888bd1097ac2dd3acda2abcbaee5f0641a8361dca01da1d2495): Bind for 0.0.0.0:5432 failed: port is already allocated'
An attempt to create a simple microservice app with the same DB type. It can be easily solved by setup DB ports for each microservice in JDL. Or even better do not use localhost at all! Use just hostnames like
customergateway-postgresql:5432 instead of
localhost:5432
I this case ports will never collide for services also it's obvious by name 'which-is-which'.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

@mmuruev : can you provide all information asked in the template plz ? just use jhipster info in each microservice

Just to be sure about your config.
Then, I will be able to provide a solution if it's the same config I have in my projects

INFO! Using JHipster version installed locally in current project's node_modules
00h00m00s 0/0: : INFO! Executing jhipster:info
INFO! Options: from-cli: true
Welcome to the JHipster Information Sub-Generator

JHipster Version(s)
[email protected] microservices/customerGateway
└── [email protected] 

##### **JHipster configuration, a `.yo-rc.json` file generated in the root folder**
.yo-rc.json file
{
"generator-jhipster": {
"authenticationType": "jwt",
"cacheProvider": "hazelcast",
"clientFramework": "react",
"serverPort": "8080",
"serviceDiscoveryType": "eureka",
"skipUserManagement": false,
"baseName": "customerGateway",
"buildTool": "gradle",
"databaseType": "sql",
"devDatabaseType": "h2Disk",
"enableHibernateCache": true,
"enableSwaggerCodegen": false,
"enableTranslation": true,
"jhiPrefix": "jhi",
"languages": ["en", "ru"],
"messageBroker": "kafka",
"nativeLanguage": "en",
"prodDatabaseType": "postgresql",
"searchEngine": false,
"skipClient": false,
"testFrameworks": ["protractor", "gatling", "cucumber"],
"websocket": false,
"applicationType": "gateway",
"useSass": true,
"jhipsterVersion": "6.8.0",
"creationTimestamp": 1588234200215,
"skipServer": false,
"clientPackageManager": "npm",
"clientTheme": "none",
"clientThemeVariant": "",
"embeddableLaunchScript": false,
"entitySuffix": "",
"dtoSuffix": "DTO",
"otherModules": [],
"blueprints": []
},
}

JDL for the Entity configuration(s) entityName.json files generated in the .jhipster directory


JDL entity definitions


Environment and Tools

java version "14.0.1" 2020-04-14
Java(TM) SE Runtime Environment (build 14.0.1+7)
Java HotSpot(TM) 64-Bit Server VM (build 14.0.1+7, mixed mode, sharing)

git version 2.25.1

node: v13.12.0

npm: 6.14.4

yeoman: 3.1.1

yarn: 0.32+git

Docker version 19.03.6, build 369ce74a3c

docker-compose version 1.22.0, build f46880fe

INFO! Congratulations, JHipster execution is complete!

INFO! Using JHipster version installed locally in current project's node_modules
00h00m00s 0/0: : INFO! Executing jhipster:info
INFO! Options: from-cli: true
Welcome to the JHipster Information Sub-Generator

JHipster Version(s)
[email protected]/wallet
└── [email protected] 

##### **JHipster configuration, a `.yo-rc.json` file generated in the root folder**
.yo-rc.json file
{
"generator-jhipster": {
"authenticationType": "jwt",
"cacheProvider": "hazelcast",
"serverPort": "8081",
"serviceDiscoveryType": "eureka",
"skipUserManagement": true,
"baseName": "wallet",
"buildTool": "gradle",
"databaseType": "sql",
"devDatabaseType": "postgresql",
"enableHibernateCache": true,
"enableSwaggerCodegen": true,
"enableTranslation": true,
"jhiPrefix": "jhi",
"languages": ["en", "ru"],
"messageBroker": "kafka",
"nativeLanguage": "en",
"prodDatabaseType": "postgresql",
"searchEngine": false,
"skipClient": true,
"testFrameworks": ["gatling", "cucumber"],
"websocket": false,
"applicationType": "microservice",
"clientPackageManager": "npm",
"dtoSuffix": "DTO",
"jhipsterVersion": "6.8.0",
"creationTimestamp": 1588234200215,
"embeddableLaunchScript": false,
"entitySuffix": "",
"otherModules": [],
"blueprints": []
}
}

JDL for the Entity configuration(s) entityName.json files generated in the .jhipster directory


JDL entity definitions


Environment and Tools

java version "14.0.1" 2020-04-14
Java(TM) SE Runtime Environment (build 14.0.1+7)
Java HotSpot(TM) 64-Bit Server VM (build 14.0.1+7, mixed mode, sharing)

git version 2.25.1

node: v13.12.0

npm: 6.14.4

yeoman: 3.1.1

yarn: 0.32+git

Docker version 19.03.6, build 369ce74a3c

docker-compose version 1.22.0, build f46880fe

INFO! Congratulations, JHipster execution is complete!

I've seen this happen when you already have PostgreSQL running on your machine. If you stop the process first, it should work.

But this is wrong! I should not put everything on one DB server! And also it blocks docker-compose app run. I understand how to fix it but, I'm talking about how to avoid and improve such cases. I have no local (at host) psql server. All instances from the docker.

@mmuruev :

  • with dev profile, you shouldn't have problem as your gateway uses h2disk and your microservice psql
  • you can have problem with prod profile as you need to start each psql (1 for gateway, 1 microservice)

To resolve this, IMO, the best would be:

  • create a separate project, use jhipster docker-compose, it will generate a big docker-compose file
  • clean all app, keep only database and services
  • expose port, differently for psql, 5432, then 5433, 5434 etc
  • then, change the default port of psql in appropriate microservice

I think it's the best solution because when I start to dev, I launch this big docker-compose, instead of thinking about which services inside each microservices (consul, keycloak, kafka, psql etc etc)

Then, I don't think we should include your feature in main generator, as we will need to do the same for all databases, store the config in yo-rc.json, add the option in JDL, maybe change all config in docker-compose, heroku, gcp, openshift, aws etc etc...
Too much work for 1 or 2 minutes with sub generator docker-compose

Hope my solution will help you

Well, choose another DB type isn't the solution here. I'll use another service with psql for tests also.
jhipster docker-compose actually fails to create

microservices/docker-compose
❯ jh docker-compose
INFO! Using JHipster version installed globally
00h00m00s 0/0: : INFO! Executing jhipster:docker-compose
INFO! Options: from-cli: true
✔ Docker is installed
? Which *type* of application would you like to deploy? Microservice application
? Which *type* of gateway would you like to use? JHipster gateway based on Netflix Zuul
? Enter the root directory where your gateway(s) and microservices are located ../customerGateway
>> No microservice or gateway found

expose port, differently for psql, 5432, then 5433, 5434 etc

Yes, I've mentioned this, but issue that after changes I cant use JDL anymore because it overwrites such change in docker-compose files and even worse make a commit! so I even can't see it git status easily to make mistake here.

The feature makes hosts more self-described by name, and not so big change. Probably worth it? After all, you shouldn't do it in one big change.

I didn't suggest to change DB. I mentioned h2disk because it's the config in your gateway.

About docker compose sub generator, use the path where there are other folders of microservices, not inside a specific one. Maybe just ../ ?

Unless you use the side by side approach for your project, you have to check every single file you changed. So you can add another file like psql.yml instead of using postgresql.yml for example.

About hostname, if I understand well, it won't work immediatly. You need to add the hostname in /etc/hosts otherwise it won't work.

Even with full path no success. I used an approach from documentation side by side actually. No, you should not modify your hosts file.. if you up dns-masq container. It will handle this all for you. We are using it and it really convenient and you can forget about modify something in the system especially with sudo !

But this is wrong! I should not put everything on one DB server!

Why @mmuruev?
It's only in dev and you can have several databases hosted by one single containerized db server.
So isolation is preserved and you optimize your ressources on your dev PC, it looks like a a good compromise to me.

@gmarziou Maybe but can be other issues because of this. Anyway, if this is the way .. docker-compose not aware of it and still crashing.

I had a look at https://hub.docker.com/r/strm/dnsmasq/ and indeed, it could be a solution.
But not sure it will work well for users with Windows.

Then, after thinking more about this feature request, I don't think we will change something in our main generator-jhipster as the change is trivial and can be done in less than 30sec.

Adding a new option would be overkill, and we'll have to do the same think for all database, all other services, and maintain it.

What can be done are:

  • a new module for using strm/dnsmasq -> feel free to code your own module and maintain it. I'll be happy to test and play with it
  • add a new tips at https://www.jhipster.tech/tips/

For now, let's close this.

It will work for Windows... DNS makes no difference, at least I've heard no complain about it.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

edvjacek picture edvjacek  ·  3Comments

chegola picture chegola  ·  4Comments

frantzynicolas picture frantzynicolas  ·  3Comments

dronavallisaikrishna picture dronavallisaikrishna  ·  3Comments

SudharakaP picture SudharakaP  ·  3Comments