Any interest in Podman?

개발
20

약 30분 정도 이 작업을 시도해 보았습니다. Podman은 명령어 호환성은 있지만 출력 형식 호환성은 없기 때문에, launcher가 출력을 파싱하려고 할 때 혼란을 겪습니다. (두 가지를 구별하는 것은 어렵지 않습니다. docker --version을 실행하면 podman version 1.0.5라고 응답하므로 이는 심각한 장애물은 아닙니다.)

docker0 네트워크 장치가 없습니다. Podman의 기본 overlay 스토리지 드라이버는 기본적으로 overlay2 구현이며 이에 별칭으로 사용되지만, 출력에는 overlay2라고 표시되지 않고 docker info 명령의 출력도 약간 다릅니다. 저는 검사를 우회하기 위해 --skip-prereqs를 사용했습니다. 공유 디렉터리는 자동으로 생성되지 않았으며, 그 이유는 조사하지 않았습니다. 계속 진행하기 위해 mkdir -p /var/discourse/shared/standalone/log/var-log를 실행했습니다. 다음으로, SELinux가 강제 모드(enforcing)로 설정되어 있지만 /var/discourse에 대해 구성되지 않은 상태에서 권한 문제를 발견했습니다.

컨테이너에 디렉터리를 볼륨 마운트하고 :z 또는 :Z를 추가하면 컨테이너 엔진이 볼륨 하위의 콘텐츠를 container_file_t로 재레이블링합니다.

podman build 문서에는 다음과 같이 나와 있습니다:

z 옵션은 두 컨테이너가 볼륨 콘텐츠를 공유한다는 것을 Podman에 알립니다. 결과적으로 Podman은 콘텐츠에 공유 콘텐츠 라벨을 붙입니다. 공유 볼륨 라벨을 사용하면 모든 컨테이너가 콘텐츠를 읽기/쓰기할 수 있습니다. Z 옵션은 콘텐츠에 비공개(비공유) 라벨을 붙이도록 Podman에 지시합니다. 현재 컨테이너만 비공개 볼륨을 사용할 수 있습니다.

이 일회용 설치 환경에서는 나중에 다시 돌아올지 모르겠지만, 일단 setenforce 0으로 설정하기로 결정했습니다. 소문자 :z를 사용하도록 volumes을 다음과 같이 변경했습니다:

volumes:
  - volume:
      host: /var/discourse/shared/standalone
      guest: /shared:z
  - volume:
      host: /var/discourse/shared/standalone/log/var-log
      guest: /var/log:z

이러한 작은 수정 사항을 통해 discourse의 부팅을 성공시켰습니다. Redis는 커널에서 투명 거대 페이지(transparent huge pages)가 지원되는 것에 대해 불만을 토로하며, 이를 비활성화하고 메모리 오버커밋 설정을 변경할 것을 제안합니다. 아마도 메가바이트 단위의 로그 출력 속에서 많은 다른 유용한 디버그 메시지가 지나갔을 것입니다!

./launcher start app
...
--restart 옵션은 지원되지 않습니다.
컨테이너 재시작에는 systemd 유닛 파일을 사용하십시오.

--restart를 사용하지 않도록 스크립트를 수정했고, start 모드에서도 --skip-prereqs가 필요하다는 것을 발견했으며, 이를 통해 마침내 docker run을 시도하게 되었습니다. 이때 다음과 같은 메시지가 나타났습니다:

./launcher start app --skip-prereqs
...
+ /usr/bin/docker run ... -e DOCKER_HOST_IP= --name app -t -p 80:80 -p 443:443 -v /var/discourse/shared/standalone:/shared:z -v /var/discourse/shared/standalone/log/var-log:/var/log:z --mac-address 02:9c:01:9b:0e:17 local_discourse/app /sbin/boot
--mac-address 옵션은 현재 지원되지 않습니다.

따라서 기본적으로 작동하지 않는다는 것은 분명합니다. docker 또는 podman 중 하나와 함께 작동하도록 launcher를 수정하는 데 얼마나 많은 작업이 필요할지 저는 알지 못합니다. 사전 요구 사항 처리는 "그저 작동(just work)"할 것이며 podman에 대한 사전 체크를 추가하는 것은 아마도 너무 어렵지 않을 것입니다. 하지만 네트워크 설정에 대한 가정이 스택 하단의 구성까지 얼마나 깊이 관여하는지 모르겠고, 이 네트워크 모드는 podman에서 단순히 지원되지 않는 것으로 보입니다.

이러한 우려를 바탕으로, launcher가 podman에서 작동하도록 만드는 작업을 수행하지 않을 계획입니다. 저는 초기 빠른 실험의 결과만을 보고하는 것입니다.

그러나 더 잘 아는 사람에게 이는 어려운 작업이 아닐 것입니다. 저는 올봄에 Fedora 29에서 수동 개발 설치로 모든 개발 작업을 수행했으며, apt-get 대신 dnf를 사용하고 일부 패키지 이름 번역과 같은 사소한 조정만 했을 뿐, docker나 podman을 전혀 사용하지 않았습니다. podman을 잘 알고 discourse 기술 스택 전체의 일반 관리도 잘 아는 사람은 이를 상대적으로 쉬운 중등도 수준의 작업으로 판단할 가능성이 높습니다. 모든 작업 내용을 알았다면, 그것이 "부패(rot)"하여 지속적인 유지보수가 필요한 유형의 작업인지 아닌지에 대해 더 나은 감을 가질 수 있었을 것입니다. 하지만… 저는 모릅니다. :roll_eyes: