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'.
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
[email protected] microservices/customerGateway
└── [email protected]
##### **JHipster configuration, a `.yo-rc.json` file generated in the root folder**
{
"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": []
},
}
entityName.json files generated in the .jhipster directory
JDL entity definitions
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
[email protected]/wallet
└── [email protected]
##### **JHipster configuration, a `.yo-rc.json` file generated in the root folder**
{
"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": []
}
}
entityName.json files generated in the .jhipster directory
JDL entity definitions
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 :
To resolve this, IMO, the best would be:
jhipster docker-compose, it will generate a big docker-compose fileI 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:
For now, let's close this.
It will work for Windows... DNS makes no difference, at least I've heard no complain about it.
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:
For now, let's close this.