Automated workflow tool failing to open port in CI pipeline

Other Questions N8n
1

I’m having trouble with an automated workflow tool in our CI pipeline. It works fine on our local machines but fails when we run it on the cloud-based runner. The error message suggests a connection problem:

ConnectionError: HTTPConnectionPool(host='localhost', port=1234): Max retries exceeded with url: /api/v1/credentials (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f3d28e3d810>: Failed to establish a new connection: [Errno 111] Connection refused'))

Here’s a simplified version of our Docker setup:

workflow-tool:
  image: workflow-tool/latest
  ports:
    - '1234:1234'
  environment:
    - TOOL_HOST=workflow-tool:1234
    - TOOL_PORT=1234
    - TOOL_PROTOCOL=http
    - NODE_ENV=production
    - DB_TYPE=postgres
    - DB_PREFIX=wf_
    - DB_NAME=workflow
  volumes:
    - ./config:/home/user/.config
    - ./data:/data

We’re trying to access this service using Python’s requests library in our FastAPI app. Any ideas on what might be causing this issue in the CI environment? The Docker setup is identical, and we reset environment variables in our test script.

Update:
I’ve narrowed down the problem to this:

curl --fail http://localhost:7070 || exit 1
curl --fail http://localhost:1234/api/v1/docs/ || exit 1

The first curl works, but the second fails with ‘Connection refused’. I’ve tried different ports too. Any suggestions?

2

I’ve faced similar issues with CI pipelines and containerized services. From your description, it sounds like the problem might be related to how the CI environment handles networking between containers.

In CI environments, ‘localhost’ often refers to the runner itself, not your Docker container. Try replacing ‘localhost’ with the service name in your Docker Compose file. So instead of ‘http://localhost:1234’, use ‘http://workflow-tool:1234’.

Also, ensure your CI runner waits for the service to be fully up before running tests. Sometimes, services take longer to start in CI environments. You could add a small delay or, better yet, implement a health check.

Lastly, double-check your firewall settings in the CI environment. Some CI providers have strict default rules that might be blocking certain ports.

If none of these work, you might need to dig deeper into your CI provider’s documentation about how they handle Docker networking. Each provider can have slightly different setups.

3

u checked logs in ci? sometimes the container isnt even launching properly. also, make sure it binds to 0.0.0.0 instead of 127.0.0.1. if still failing, maybe a ci proxy or firewall is blockin port 1234?

4

Based on your update, it seems the issue is specifically with the workflow tool’s port 1234. This suggests a problem with how the container is exposing its ports in the CI environment.

First, ensure your CI config is actually running the Docker setup you’ve shown. Some CI systems require explicit commands to start Docker services.

Next, try using ‘docker ps’ in your CI logs to verify the container is running and the port is correctly mapped. If it’s not, there might be a port conflict in the CI environment.

Consider using Docker’s ‘host’ network mode for testing. This bypasses Docker’s network isolation:

workflow-tool:
  network_mode: host

If that works, it confirms a Docker networking issue. You might then need to adjust your CI’s network settings or how your tests access the container.

Lastly, check if your workflow tool has any startup logs. It might be failing to bind to the port for some reason, which wouldn’t be apparent from outside the container.