Hey everyone, I’m having a weird issue with our CI setup. We’re using a workflow automation tool in our Docker configuration, and it’s causing problems in our GitHub Actions pipeline. Locally on our Macs the service works fine, but within the CI environment, we face a connection error that resembles the following:
ConnectionError: HTTPConnectionPool(host='localhost', port=1234): Max retries exceeded with url: /api/v1/creds (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f3d28e3d810>: Failed to establish a new connection: [Errno 111] Connection refused'))
Below is a snippet from our Docker configuration file:
automation_tool:
image: some-automation-image
ports:
- "1234:1234"
environment:
- TOOL_HOST=automation_tool:1234
- TOOL_PORT=1234
- TOOL_PROTOCOL=http
- NODE_ENV=production
- DB_TYPE=postgres
- DB_PREFIX=tool_
- DB_NAME=automationdb
volumes:
- ./DOCKER/tool/data:/home/user/.tool
- ./DOCKER/tool/files:/files
Our FastAPI application communicates with this service using Python’s requests library. Does anyone have ideas as to why it functions correctly on local machines but not during CI runs? The Docker setup is identical and our test script resets the environment files before running. I’ve simplified the test case to the following commands:
curl --fail http://localhost:8080 || exit 1
curl --fail http://localhost:1234/api/v1/docs/ || exit 1
While the first command passes, the second fails with a ‘Connection refused’ error. We’ve even experimented with switching ports. Any insights would be greatly appreciated!
I’ve encountered similar issues in our CI pipeline before. The problem might be related to how Docker networking works in CI environments versus local machines.
In CI, the services are often running in separate containers or even separate hosts, so ‘localhost’ may not refer to the same network as it does on your local machine.
Try replacing ‘localhost’ with the service name in your CI configuration. For example, use ‘http://automation_tool:1234’ instead of ‘http://localhost:1234’. This tells Docker to use its internal DNS to resolve the service name.
Also, ensure your CI environment waits for the automation tool to be fully up before running tests. Sometimes services take longer to start in CI. You can add a simple health check or sleep command before running your tests.
Lastly, double-check that your CI environment’s firewall settings aren’t blocking the port. Some CI providers have strict default security policies that might need adjusting.
Hope this helps! Let me know if you need any clarification on these points.
It appears the issue lies in how Docker networking operates within CI environments. Unlike your local setup, CI often uses isolated containers or separate hosts, causing ‘localhost’ to reference a different network.
To resolve this, modify your CI configuration to use the service name instead of ‘localhost’. For instance, replace ‘http://localhost:1234’ with ‘http://automation_tool:1234’. This instructs Docker to utilize its internal DNS for service name resolution.
Additionally, ensure your CI pipeline allows sufficient time for the automation tool to fully initialize before test execution. Implement a health check or introduce a brief delay prior to running tests.
Lastly, verify your CI environment’s network settings. Some providers implement strict security policies by default, potentially blocking specific ports. You may need to adjust these settings to allow the necessary connections.
hey spinninggalaxy, sounds like a tricky one! have u tried using the service name instead of localhost in ur CI config? like ‘http://automation_tool:1234’. also make sure the automation tool is fully up b4 running tests - maybe add a quick health check. good luck troubleshooting!