coollabsio / coolify

An open-source & self-hostable Heroku / Netlify / Vercel alternative.
https://coolify.io
Apache License 2.0
33.54k stars 1.82k forks source link

[Bug]: Cannot resolve hostname when adding multiple Remote Docker destinations #923

Closed marlon360 closed 1 year ago

marlon360 commented 1 year ago

Is there an existing issue for this?

Example public repository

coolify

Description

I added 7 remote docker destinations.

When I "servers" in the main menu, I got an overview of all my servers. Unfortunately I don't get the live data for all my servers.

I got this error multiple times (for each server): Command failed with exit code 255: ssh 141.71.200.103-remote vmstat -s ssh: Could not resolve hostname 141.71.200.103-remote: Name or service not known

Only one and sometimes two servers are responding. It is pretty random which server is responding.

Steps To Reproduce

  1. Add multiple remote docker destinations
  2. Click on "Servers" in the menu
  3. You will see several error messages

Version

3.12.17

marlon360 commented 1 year ago

@andrasbacsai Why did you add "-remote" to the IP address? When I execute the commands directly on the coolify host machine without "-remote" it works.

hyenabyte commented 1 year ago

I'm currently having this problem in both my setups as well. Interestingly it seems to be alternating between the two remote servers. If I refresh the overview sometimes the one server will work and I'll get an error for the other and sometimes its the other way around.

hyenabyte commented 1 year ago

Since #980 got merged, things are definitely running better, however I still get errors. I run a setup with 3 hosts, (1 local and 2 remote) which now runs flawless, and a setup with 4 hosts (1 local, 3 remote), which still gives errors.

{"statusCode":500,"error":"Internal Server Error","message":"Command failed with exit code 255: ssh <ip>-remote nproc --all\nssh: Could not resolve hostname <ip>-remote: Name or service not known"}

Seems to be same problem still. Maybe remotes should be handled by passing the config directly with the command, ie. ssh -i <keyfile> -h <ip> ... or use the -o flag, instead of writing to the config file. By writing to the file on each request, you risk race conditions, which is what I suspect is happening, where multiple processes will write and rewrite the file, regardless of what the other processes are doing.

Theres also the -F flag for ssh which takes a specific config file, if you want to write a config file for the hosts, this could be used to make sure each host only reads and writes to thier own file.

andrasbacsai commented 1 year ago

I'm closing this issue, because tracking features will be moved to GitHub discussions. Github issues will be only for bugs.

Version 4 is in full focus. v3 related issues will be closed, if it is not a critical bug.

Thanks for your understanding.