Podman + M1 환경 트러블슈팅

Table of Contents

한 줄 요약

M1에서 Podman 문제는 컨테이너 명령보다 podman machine 상태와 아키텍처(arm64/amd64)를 먼저 확인해야 빠르게 풀립니다.

진단 시작점

1podman machine list
2podman info
3podman ps -a
  • podman info 실패: 앱 디버깅 전에 machine부터 복구
  • podman ps -a의 Exited, Restarting 확인

이슈 1: Podman socket 연결 실패

증상

  • Error: unable to connect to Podman socket
  • CLI가 응답 없이 멈춘 것처럼 보임

조치

1podman machine stop
2podman machine start
3podman system connection list
4podman info

지속 재발 시 machine 재생성이 가장 확실합니다.

1podman machine rm -f
2podman machine init
3podman machine start

이슈 2: amd64 이미지에서 느림/비정상 종료

원인

Apple Silicon에서 linux/amd64는 에뮬레이션 경로를 타기 때문에 성능 저하와 런타임 변동이 큽니다.

조치

  1. 멀티 아키텍처 이미지를 우선 사용
  2. 가능한 경우 linux/arm64 명시
1podman run --platform linux/arm64 -it --rm nginx:latest

이슈 3: compose 일부 서비스만 재시작 루프

흔한 원인

  • healthcheck 실패
  • 볼륨 마운트 권한 불일치
  • x86 전용 바이너리 의존

확인 순서

1podman compose ps
2podman compose logs --tail=200 <service-name>
3podman inspect <container-name> --format '{{.State.Status}} {{.State.ExitCode}} {{.State.Error}}'

ExitCode와 최초 예외 스택을 보면 원인을 빠르게 좁힐 수 있습니다.

이슈 4: 포트는 publish됐는데 접속 실패

macOS에서는 VM 포워딩을 거치므로 포트 충돌과 앱 바인딩 주소를 같이 봐야 합니다.

1lsof -iTCP:8080 -sTCP:LISTEN
2podman port <container>

컨테이너 내부 앱이 127.0.0.1에만 바인딩되면 외부 접근이 안 됩니다. 서버 바인딩은 0.0.0.0로 설정합니다.

실전 운영 팁

  1. podman machine set --cpus --memory --disk-size로 리소스 선조정
  2. base image를 arm64 우선으로 선택
  3. logs보다 inspect의 상태/종료코드를 먼저 확인
  4. 로컬과 CI에 동일한 실행 스크립트를 사용

정리

M1 + Podman은 "소켓", "플랫폼", "헬스체크" 3축으로 보면 대부분 원인을 빠르게 찾을 수 있습니다.