마이크, 안녕. 기본적으로 ./launcher bootstrap를 사용해 이미지를 빌드한 후 리포지토리에 푸시하고, ./launcher start-cmd를 사용해 Docker에 전달해야 하는 ENV 변수가 무엇인지 확인하는 방식으로 진행하면 돼.
이런 가이드가 존재하지 않는 이유는, 기초적인 이해조차 없는 사람들이 이 가이드를 찾아봐도 내용을 이해하지 못하고, 결국 그들이 유일한 정답이라고 생각하는 시스템에서 인그레스(ingress)가 어떻게 작동하는지에 대한 튜토리얼을 요구하기 때문이야.
미쳤다고 생각할 수도 있지만, 어쩌면 우리가 특정한 방식으로 일을 해온 데에는 이유가 있다는 것을 몸소 증명해 주는 사례가 아닐까요? 
제이, 고마워. 그 정도는 나도 알아냈어. 마침내 제대로 작동하게 만들었어.
문제의 일부는 이 방식이 다른 모든 도커 이미지들과는 정반대라는 거야. 플러그 앤 플레이(Plug and Play)라고 할 만큼 간단하지는 않아. 더 많이 조립하고, 끼우고, 그다음에야 작동하는 방식이지.
말했듯이, 런처는 그 용도에는 아름답고 신뢰할 만한 도구야.
매우 긍정적인 점은 웹 전용 빌드가 정말 잘 작동한다는 거야. 내 스웜에서는 초고속이고, 빌드 서버를 가지고 있어서 업데이트도 가능해.
시간이 나면 내 스웜에서 웹 기반 도커 이미지 빌드를 허용하는 빌드 서버를 탐색해 볼 거야.
시도해 봤지만 기대에 못 미쳤던 것들…
좋아 - 고마워.
마이크.
우리는 이른바 ‘선도자의 불리함(First Mover Disadvantage)’을 겪었습니다 
이 런처 스크립트는 docker-compose, docker-swarm, kubernetes 같은 것들이 존재하기도 전에 만들어졌고, 여전히 잘 작동합니다. 다른 시스템으로 전환할 만한 결정적인 이유가 없습니다. 이러한 시스템들이 가진 ‘장점’은 Discourse 셀프호스팅의 1위 사용자층인 클라우드 VPS 기반의 예산형 설치 환경에서는 장점이 되지 않기 때문입니다.
오! 늘 궁금했거든요. 마지막으로 확인했을 때, Ubuntu에서 docker-compose를 설치하는 것은 별도의 단계가 필요했어요. 마치 사람들이 사용하지 못하게 막아놓은 것 같더라고요. 윈도우(혹은 Mac?)를 사용하는 사람들을 제외하고는 말이죠.
개발 팀의 공식 응답으로 이런 이야기를 듣니 다소 서운합니다. 결국, 문서화되지 않은 프로덕션 환경에서의 Discourse 실행 과정을 알아내지 못할 정도로 능력이 부족하다면, 아마도 Discourse를 프로덕션에서 실행하지 말아야 한다는 뜻이겠네요.
아쉽게도 우리 모두가 광범위한 DevOps 경험을 가진 것은 아닙니다.
@Mike_Sutton 나도 당신과 같은 생각입니다. 지난 몇 주간 이 문제를 해결하기 위해 포럼을 열심히 읽어왔습니다. 문제를 해결하는 방법에 대한 영상을 제작하셨나요?
그렇게 하면 될까요? DB 마이그레이션은 어떻게 처리하나요?
이 시나리오에서는 새 컨테이너 이미지를 빌드하는 동안 bootstrap이 마이그레이션을 수행하도록 합니다.
@lucasbasquerotto 님, 안녕하세요.
네, Discourse Docker 이미지를 저장소로 push하고, 아래 토론에서 언급된 것처럼 /var/discourse의 나머지 부분을 아카이브로 처리할 수 있습니다. 하지만 이는 효율적인 방법이 아니며 공식적으로 지원되지 않습니다. 최근 이 과정을 완전히 테스트해 보았습니다:
하지만 이 경우 bootstrap 단계는 프로덕션 머신에서 수행되어야 합니다. 제가 아는 한, 이는 컨테이너 레지스트리에 기본 이미지를 푸시하는 목적을 무색하게 만듭니다(이는 프로덕션에서 이미지를 bootstrap하지 않기 위한 의도였기 때문이며, DB 마이그레이션 단계나 유사한 작업을 실행하는 경우는 예외일 수 있습니다).
제가 호스팅하는 비(Discourse) 사이트에서는 보통 flyway를 사용하여 DB 마이그레이션을 실행하고, Redis 캐시 비우기 등 다른 작업도 수행하지만, 외부 서비스에 의존하는 업데이트(예: HTTPS 인증서 업데이트)나 코드베이스 변경(이미지 내에서 패키지, 라이브러리 등과 같이 정적으로 유지되는 것)과 같은 다른 집약적인 프로세스는 실행하지 않습니다. 인증서 업데이트는 첫 번째 경우를 제외하고는 cronjob으로 수행하면 됩니다. Discourse는 rake를 사용하는데 이는 문제가 없지만, gem 설치, 자산 생성, maxmind DB 업데이트 및 기타 서비스(예: 서비스가 다운되어 있거나 API가 변경되면 재빌드 단계가 깨질 수 있음. 이는 드물지만 발생할 수 있음)와 같은 다른 작업도 수행합니다.
물론 Discourse가 그렇게 해야 한다고 주장하는 것은 아닙니다. 하지만 CI 환경에서 이미지를 생성하고, 스테이징/프로덕션 서버에서 DB 마이그레이션 단계와 환경 변수 정의만 수행하는 방식이 제가 기대하는 바이며, WordPress, MediaWiki, RocketChat 등 다른 소프트웨어로는 쉽게 달성할 수 있습니다. Discourse는 포럼 소프트웨어 중 최고라고 생각하며(IMO), 그들이 그렇게 하는 데에는 좋은 이유가 있을 수 있지만, 현재로서는 재빌드 과정에서 문제가 발생하지 않기를 바라며 두통을 피하기 위해 표준 설치(또는 멀티컨테이너 설치)만 사용할 것입니다.
bootstrap은 스테이징 및 프로덕션 환경 모두에서 사용할 기본 이미지를 생성하기 위해 CI 환경이 아니라 프로덕션 환경에서 수행되어야 하는 것으로 보입니다. 게다가, **표준 설치가 아니라는 것은 큰 경고 신호(red flag)**이며, 소프트웨어가 업데이트를 받으면서 미래에 두통을 유발할 수 있습니다.
마이크, 안녕?
결국 프로세스를 문서로 정리했어? 영상도 보면 좋겠다.
감사합니다.