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는 에뮬레이션 경로를 타기 때문에 성능 저하와 런타임 변동이 큽니다.
조치
- 멀티 아키텍처 이미지를 우선 사용
- 가능한 경우
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로 설정합니다.
실전 운영 팁
podman machine set --cpus --memory --disk-size로 리소스 선조정- base image를
arm64우선으로 선택 logs보다inspect의 상태/종료코드를 먼저 확인- 로컬과 CI에 동일한 실행 스크립트를 사용
정리
M1 + Podman은 "소켓", "플랫폼", "헬스체크" 3축으로 보면 대부분 원인을 빠르게 찾을 수 있습니다.