Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

[FAQ] HW3 with act: the postgres service is "healthy" but the API dies with "connection refused" on localhost:5432

Đã đóng Phù hợp với người mới
  • Có gì không ổn?
#415 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

@github-actions đang làm issue này rồi.

Từ ngày 24/9/2026.

  • #416 của @github-actions — đang mở

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
75/100
Loại issue
Tài liệu
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
docker, postgresql, python
Lĩnh vực
ci-cd, devops, documentation

Hướng nghiên cứu

Issue này nói về việc cấu hình một workflow CI để chạy cục bộ với act. Câu trả lời giải thích sự khác biệt về mạng giữa GitHub Actions và act, đồng thời cung cấp một giải pháp có tham số hóa. Để xác minh, người ta nên kiểm tra tệp workflow trong kho lưu trữ khóa học, hiểu định nghĩa vùng chứa dịch vụ và kiểm tra bản sửa lỗi bằng cách chạy act với biến được cung cấp. Trạng thái 'done' đạt được khi API có thể kết nối với PostgreSQL cả cục bộ với act và trên GitHub Actions.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

faq-proposal
Course

ai-dev-tools-zoomcamp

Question

In Homework 3 (module 03) the assignment tells you to run your CI workflow
locally with act. My workflow starts a postgres:16 service container
with a pg_isready healthcheck, and act prints container health … is healthy. But when the job boots the Agent Relay API with
RELAY_DATABASE_URL=postgresql+psycopg://relay:relay@localhost:5432/relay,
it crashes:

text

psycopg.OperationalError: connection failed: connection to server at
"127.0.0.1", port 5432 failed: Connection refused
The identical workflow passes on GitHub Actions. Why does localhost work
there but not under act, and what hostname should I use?
Answer

Because GitHub and act place service containers in different networks:

GitHub Actions publishes service ports on the job runner's loopback, so
localhost:5432 is correct there.
act runs each service as a separate container on a user-defined docker
network shared with the job container. Nothing is published on the job's
loopback; the service is reachable by its service name (the key under
services:), resolved by docker's embedded DNS. Under act the host is
postgres, not localhost. The giveaway is the error text itself: it
retries ::1 and 127.0.0.1 — loopback — while the healthy service sits
one hop away on the act network.
Fix that is correct in BOTH worlds — parameterise the host with a per-runner
default (vars is legal in step env and, unlike env, in job-level if):

YAML


jobs:
  test:
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_USER: relay
          POSTGRES_PASSWORD: relay
          POSTGRES_DB: relay
        options: >-
          --health-cmd "pg_isready -U relay -d relay"
          --health-interval 3s --health-timeout 3s --health-retries 10
    steps:
      - name: boot api against postgres
        env:
          RELAY_DATABASE_URL: >-
            postgresql+psycopg://relay:relay@${{ vars.DB_HOST || 'localhost' }}:5432/relay
        run: |
          uv run uvicorn main:app --port 8005 &
          ...

Locally: act … --var DB_HOST=postgres. On GitHub vars.DB_HOST is unset, the
expression falls back to localhost, and the workflow is unchanged.

Sanity checks: docker network inspect <act-…-test-network> lists both
containers; getent hosts postgres resolves inside the job container; and a
service that is healthy in act's log yet "refused" from the job is always
this networking difference, never a bad healthcheck.

Checklist
  • I have searched existing FAQs and this question is not already answered
  • The answer provides accurate, helpful information
  • I have included any relevant code examples or links
Ngôn ngữ chính
Python
Star
7
Fork
20
Merge trung bình
7 ngày 9 giờ
Pull request đã merge (30 ngày)
8

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của DataTalksClub/faq

Tất cả issue của DataTalksClub/faq

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.