서버와 Discourse 설치를 마이그레이션할 예정입니다.
새로운 서버에는 btrfs 파일 시스템을 사용하고 있습니다.
테스트 머신에서 몇 가지 테스트를 진행하고 있습니다. 모든 파일을 복사하고 필요한 부분(nginx, docker, discourse 자체)을 설치했습니다.
ext4 파일 시스템으로 시도해 보았을 때는 정상적으로 작동했습니다.
하지만 이제 btrfs 포맷의 파일 시스템으로 동일한 작업을 수행하면 'launcher rebuild app’을 실행할 때 다음과 같은 오류가 발생합니다:
Your Docker installation is not using a supported storage driver. If we were to proceed you may have a broken install.
overlay2 is the recommended storage driver, although zfs and aufs may work as well.
Other storage drivers are known to be problematic.
You can tell what filesystem you are using by running "docker info" and looking at the 'Storage Driver' line.
If you wish to continue anyway using your existing unsupported storage driver,
read the source code of launcher and figure out how to bypass this check.
물론, docker info 명령을 실행하면 btrfs를 사용하고 있다고 표시됩니다.
이 포럼에서 Discourse가 일부 Docker 스토리지 드라이버와 호환성 문제가 있어 재빌드를 거부한다는 내용을 읽었습니다.
btrfs 파일 시스템에서 파일을 가져올 수 있으면서도 Discourse와 호환되는 ‘overlay’ 또는 다른 드라이버로 변경하는 방법이 있을까요?
Docker를 어떻게 설정해야 할까요?
Discourse 컨테이너에만 해당 설정을 적용하고 나머지 Docker 설정은 기본값으로 유지하는 것이 가능한가요?
현재 overlay와 overlay2는 btrfs 또는 어떤 Copy on Write 파일 시스템에서도 지원되지 않으며, ext4 파티션 위에서만 사용해야 합니다.
Docker가 btrfs 위에 overlay2 드라이버를 사용하는 것을 지원하지 않으므로, 여기서는 런처 도구의 권장 사항이 사실상 유일한 선택지가 될 것입니다. 즉, Docker가 ext4로 백업되는 시스템에서 Discourse를 계속 실행하거나, launcher를 수정하여 스토리지 드라이버를 무시하고 최선의 결과를 기대하는 것입니다.
후자의 방법을 선택하시려면, 아래 launcher 스크립트의 exit 1 줄을 선호하는 텍스트 편집기로 주석 처리(줄 앞에 # 추가)하면 됩니다:
다만, "다른 스토리지 드라이버는 문제가 있는 것으로 알려져 있다"는 점을 고려하면, 그렇게 하는 것을 권장하지 않습니다.
--skip-prereqs를 사용하면 재빌드 시 여러 가지 위험을 초래하는, 언급하신 대로 많은 다른 테스트들이 건너뛰어집니다. 해당 한 줄을 주석 처리하는 것은 btrfs에서 실행하는 것과 위험성이 동일하며, 런처가 자체 업데이트 시 자동으로 병합되므로 한 번만 변경하면 거의 잊고 지낼 수 있을 것입니다.
감사합니다.
프로덕션 서버에서는 그렇게 하는 것이 걱정됩니다.
Docker 드라이버에 문제가 생겨 손상된 데이터를 기록하는 경우, 스냅샷, 백업 또는 그 밖의 것이 있어도 크래시가 발생하면 도움이 되지 않습니다.
데이터를 백업에 안전하게 유지할 수 있는 방법이 있다면 시도해 볼 수 있을 것 같습니다…
과거에 어떤 종류의 문제가 발생했나요?
하지만 요즘은 이 COW 파일 시스템이 매우 유용합니다. 스냅샷을 찍을 수 있고, 쓰기 중이나 기타 장애 발생 시 데이터가 손상되는 것을 방지할 수 있으며, 공간을 추가하거나 디바이스를 이동하는 것도 쉽습니다…
앞으로 discourse에서 이를 볼 수 있다면 좋겠습니다.
테스트를 도와드릴 수 있을 것 같습니다. 테스트 머신에서 이를 실행하고 있습니다.
문제는 런처 파일을 편집하여 지원되는 Docker 스토리지 드라이버 목록에 btrfs를 추가하면, 스크립트를 실행할 때 스크립트가 로컬에서 변경되었으므로 원격 버전(GitHub에서 가져온 것)으로 덮어쓰기 된다는 경고가 나온다는 것입니다.
이 문제를 어떻게 해결할 수 있을까요?
런처 스크립트를 수정하여 btrfs를 허용된 형식 중 하나로 포함시켰습니다.
check_prereqs 함수에서 다음 부분을 수정했습니다:
if ! $docker_path info 2> /dev/null | egrep -q 'Storage Driver: (btrfs|aufs|zfs|overlay2)$'; then
처음으로 런처를 통해 앱을 다시 빌드하려고 했을 때, 런처가 로컬에서 수정되었는지 확인하고 원본에서 파일을 계속 다운로드할 것인지 묻는 메시지가 표시되었습니다.
그래서 그대로 두었다가 다시 빌드를 수행한 후, 앱을 시작하기 위해 나중에 수정해야 했습니다.
하지만 오늘 다시 재빌드를 시도해 보니 변경 사항을 감지하긴 하지만 오류를 내지 않고 변경 사항이 유지되는 것 같습니다.
최근 런처에서 무언가가 변경되었는지, 아니면 원래 재빌드를 수행하지 않던 구버전 런처를 사용하다가 어제 업데이트를 거친 후 이제 가능해진 것인지 모르겠습니다.
현재 btrfs로 테스트하고 있으며, 모든 것이 정상적으로 작동하는 것으로 보입니다. 앱을 시작하고 중지하는 것, 백업을 수행하는 것 등 현재까지 모든 기능이 정상적으로 작동합니다.
Docker는 btrfs 파일 시스템에서 실행되고 btrfs 스토리지 드라이버를 사용한다고 감지하면 컨테이너 저장 데이터용 btrfs 서브볼륨을 생성하는 것 같습니다.
따라서 docker 명령을 통해 컨테이너를 클론하거나 스냅샷을 생성할 때 일부 최적화를 수행하는 것으로 보입니다.
하지만 이 드라이버가 어떤 방식으로든 결함이 있을지 모르겠습니다. (docker에서 실험적 드라이버로 보이지는 않고, btrfs에서 사용할 때의 경고나 조언도 찾지 못했습니다.) 그리고 btrfs 파일 시스템에서 docker를 사용할 때 overlay2 드라이버를 사용하도록 docker 설정을 변경하는 것이 더 나은 선택(가능하다면)일지 궁금합니다.
이론적으로 docker는 btrfs 파일 시스템에서 파일을 작성하고 작업을 수행할 때 btrfs의 기능을 고려하지 않고도 수행할 수 있습니다. (btrfs는 사용자 레벨의 파일 I/O 측면에서 다른 파일 시스템과 다르지 않으므로.)
btrfs docker 스토리지 드라이버를 사용하거나, btrfs 파일 시스템에서 docker를 사용할 때 overlay2 드라이버를 사용하도록 설정하는 데 대한 의견이나 경험이 있다면 환영합니다.
직접적인 경험은 없지만, btrfs 위에 overlay2 드라이버를 사용하도록 docker를 강제로 설정하는 것을 강력히 반대합니다. 이는 명시적으로 지원되지 않으며, overlay2 드라이버는 btrfs에 대해 사실일 수도, 아닐 수도 있는 파일시스템에 대한 가정을 하고 있을 수 있어 다양한 예기치 못한 결과를 초래할 가능성이 있습니다. 파일시스템 수준에서 예기치 못한 결과는 정말로 원치 않는 상황입니다.
저수준 파일시스템 작업은 docker와 btrfs 저장소 드라이버가 처리합니다. devicemapper처럼 알려진 버그가 있는 것이 아니라면, 이 조합이 성숙하고 잘 유지보수되고 있을 가능성이 높으며, 단순히 잘 작동할 가능성이 큽니다.
제가 이해한 바로는, Discourse에서 btrfs가 지원되지 않는 이유는 실패할 것이라는 기대 때문이 아니라, 사람들이 작동한다고 확신할 수 있는 충분한 정보가 부족하기 때문일 뿐입니다.
그들은 자체 서버를 btrfs로 실행할 인센티브가 없거나 부족하므로, 커뮤니티의 사람들이 프로덕션 환경에서 시도해 보고 장기간 사용 후 보고를 하는 것만이 그 정보를 얻을 수 있는 유일한 방법입니다. 아직 그런 일이 일어나지 않았으므로, 여전히 지원되지 않는 상태입니다.
앞으로 이런 상황에 처하게 된다면, launcher를 실행하기 전에 변경 사항을 초기화하고, 업데이트한 후 다시 변경 사항을 적용할 수 있습니다:
cd /var/discourse
git reset --hard
git pull
sed -i 's/Storage Driver: (/Storage Driver: (btrfs|/' launcher
./launcher rebuild app
그러면 btrfs 파일 시스템 위에 docker의 overlay2 스토리지 드라이버를 사용하려는 시도는 하지 않겠습니다. docker가 btrfs 드라이버를 사용하도록 하고, 이것이 제대로 작동하며 문제가 없기를 기대하겠습니다.
여기 Docker Storage Drivers | Learn the Different Storage drivers of Docker 에서는 이것이 SLE 리눅스에 대해 공식적으로 지원되며 권장되는 방법이라고 하고, Ubuntu에서는 권장한다고 합니다.
Debian 10과 11은 수정 없이 커널에서 btrfs를 지원하며, btrfs 파티션에서 부팅하는 것을 지원합니다(UEFI 파티션만 다른 형식이어야 합니다).
따라서 충분히 테스트되었을 것으로 추정합니다.
Rafael의 답변은 특별한 이유 없이 btrfs를 사용하지 말라는 것이 아니라는 것을 시사합니다. 문제는 devicemapper와 관련이 있었고, 아마도 btrfs나 다른 COW 시스템에 대한 관심이 많지 않았던 시기에 잘 알려진 파일 시스템을 사용하도록 요청한 것이었을 것입니다.
한 번 시도해 보겠습니다.
사용 경험을(좋든 나쁘든) 다시 보고하겠습니다.
지금은 매끄럽게 작동하며 파일 시스템 크기를 쉽게 변경하고, 장치를 추가하거나 제거하는 등의 작업이 가능하여, 기반 데이터가 정확하고 오류 없이 유지될 것이라는 확신을 줍니다.
단, docker 스토리지 드라이버가 충분히 테스트되지 않은 경우를 조심해야 하지만, SLE(오래전부터 btrfs를 기본 저장 파일 시스템으로 구현해 온 곳)에서 널리 사용되어 온 것으로 보입니다.