Kubernetes나 Docker를 쓰면 이미지 하나로 Pod와 컨테이너를 금방 띄울 수 있다. 번거로운 건 그 안에 들어가서 뭔가를 설치해야 할 때다. 배포판마다 쓸 수 있는 패키지 매니저가 달라서, 그 이미지가 어떤 배포판 위에 만들어졌는지부터 확인하고 거기 맞는 패키지 매니저를 찾아야 한다.
다른 사람들은 이걸 어떻게 확인하나 싶어 찾아봤지만 “내가 쓰는 리눅스의 패키지 매니저를 쉽게 확인하는 방법” 같은 글은 나오지 않았다. 결국 GPT에 물어봤다. 계속 긴 스크립트만 돌려주길래 더 간단한 방법을 몇 번 되물었고, 그 끝에 얻은 게 아래 한 줄이다.
후보 여섯 개를 한꺼번에 type에 넘긴다
type apt-get dnf yum pacman zypper apk 2>/dev/null
type은 이름을 받아서 쉘이 그 이름을 무엇으로, 어디에서 찾는지 알려주는 쉘 내장 명령이다. 이름을 여러 개 받을 수 있어서 주요 배포판의 패키지 매니저를 나열해 두면 설치된 것만 경로와 함께 나온다. 뒤의 2>/dev/null은 찾지 못한 이름에 대한 에러 출력을 버리려고 붙였다.
아래는 한 컨테이너에서 실행한 결과다.
마지막 줄의 apk is /sbin/apk가 답이다. 이 컨테이너는 Alpine 계열이고, 필요한 도구는 apk로 설치하면 된다. 배포판별 설치 명령은 포트가 열렸는지 볼 때 쓰는 nc와 ss에서 netcat을 예로 모아 두었다.
2>/dev/null을 붙였는데 not found가 찍힌 이유
결과를 다시 보면 2>/dev/null을 붙였는데도 apt-get: not found 같은 줄이 그대로 남아 있다. type이 “찾지 못했다"는 메시지를 어느 스트림에 쓰는지는 쉘마다 다르다.
bash는 이 메시지를 표준 에러로 보내므로 2>/dev/null에 걸려 설치된 패키지 매니저 한 줄만 남는다. 반면 dash 계열 쉘은 nosuchcmd: not found를 표준 출력으로 내보낸다. Alpine의 기본 쉘인 BusyBox sh도 같은 쪽이라 리다이렉션을 빠져나온 것이다.
# dash: not found가 표준 출력으로 나와 2>/dev/null에 걸리지 않는다
$ dash -c 'type nosuchcmd ls 2>/dev/null'
nosuchcmd: not found
ls is /bin/ls
# bash: not found가 표준 에러로 가서 사라진다
$ bash -c 'type nosuchcmd ls 2>/dev/null'
ls is /bin/ls
어느 쪽이든 is <경로>로 끝나는 줄만 보면 되니 쓰는 데 지장은 없다.
정석은 아닐 수 있다
배포판 자체를 확인하는 방법으로는 /etc/os-release를 읽는 쪽이 더 널리 쓰인다. ID=alpine, ID=ubuntu 같은 값으로 배포판을 알려주는 파일이다. 다만 이건 배포판 이름을 알려줄 뿐이라 거기서 패키지 매니저를 한 번 더 떠올려야 한다. 당장 설치 명령이 필요할 때는 type 한 줄이 더 빠르다.
cat /etc/os-release
정석은 아닌 것 같지만.. 더 간단한 방법이나 실무상 정석을 아는 분께서 보시게 된다면 조언 부탁드림다