단순히 /var/discourse 디렉터리를 "tar로 압축"하여 다른 머신으로 이동하고, 압축을 해제한 후 discourse 앱을 시작할 수 없습니다.
주요 이유 중 하나는 Discourse를 빌드/부트스트랩할 때(기억이 맞다면 launcher가) 기본 Discourse 컨테이너(이미지)가 존재하는지 확인하고, 없다면 기본 discourse Docker 이미지를 가져와 해당 기본 docker 이미지를 컨테이너로 시작하기 때문입니다.
그 기본 git pull 이후, 빌드 프로세스는 또 다른 docker 이미지(앱)를 빌드합니다.
이 두 개의 docker 이미지(기본 이미지와 앱 이미지)는 /var/discourse 내부에 존재하지 않으므로, /var/discourse를 tar로 압축하는 것은 부분적인 "해결책"에 불과합니다(이 용어를 느슨하게 사용하여).
이 Discourse docker 이미지들은 docker 이미지로 빌드되며 Docker의 일부입니다. 그것들은 /var/discourse에 "존재"하는 것이 아니라, 그곳에서 빌드된 후 docker 이미지로 docker로 이동됩니다.
컨테이너 yml 파일을 편집하고 처음부터 다시 빌드하는 것이 가능할 수 있지만, 더 일반적인 방법은 다음을 저장하는 것입니다:
- 컨테이너 yml 파일(들)
- 업로드를 포함한 전체 백업
그리고 컨테이너 yammy를 편집하고, discourse-docker 저장소를 클론한 후 다시 빌드하는 것입니다.
그런 다음, 업로드를 포함한 전체 백업을 복원합니다(컨테이너의 명령줄에서).
github를 저장소로 사용하는 것은 “전체 것을 tar로 압축하는” 것과 “전체 것을” 다른 서버로 “이동하는” 오래된 unix 스타일 방식보다 더 깔끔한 해결책입니다. 그러나 "오래된 unix 방식"을 사용하더라도, 배포 디렉터리의 일부가 아닌 시스템 내 공유 라이브러리, 사용자 디렉터리의 공유 라이브러리 등이 있고, distro 루트 디렉터리에 없는 etc 파일들이 있기 때문에 이 방법은 종종 완전한 해결책을 제공하지 않습니다.
따라서, 대부분의 최신 linux 시스템에서도 우리는 apt(예를 들어 Ubuntu에서)를 사용하여 저장소를 가져옵니다. Discourse docker의 경우, 기본 컨테이너를 설정하기 위해 discourse-docker를 가져오고(빌드하고), 앱을 빌드하기 위해 다른 discourse 저장소를 가져옵니다. 따라서 /var/discourse는 (이미지를) "빌드하는 곳"이자 (데이터, 백업, 공개 정적 파일 등) "공유하는 곳"입니다.
이 요약이 조금이라도 유용했기를 바랍니다.