왜 Docker인가요?

지원 자체 호스팅
1

개발자들이 왜 도커를 선택했을까요?

Linux Containers(LxC)도 있고, VM 스크립트도 있습니다. ISO 설치 프로그램을 만들 수도 있죠.
LxC는 말 그대로 컨테이너입니다.

시스템 관리자에게는 방화벽 등이 포함된 네트워크 구성이 이미 되어 있다면 이 도커는 불필요하고 무의미합니다.

리눅스를 사용하거나 보안 설정을 하는 방법을 모르는 사람들을 위한 간단한 설치 방법이라는 점은 이해합니다. 하지만 시스템 관리자가 도커를 배워야 한다는 것은 무의미합니다. LxC와 VM은 항상 도커보다 훨씬 낫습니다.

서버를 관리하는 시스템 관리자의 경우, 우리는 별도의 네트워크에서 LxC와 VM을 생성합니다. 그래서 저는 discourse를 위해 전용 VM을 만들고, 그 안에서 도커 컨테이너를 생성했습니다. -_-

이제 네트워크 안에 또 다른 네트워크가 생긴 셈입니다. 모든 것과 격리된 도커 컨테이너를 만들기 위해 전용으로 격리된 VM을 만든 것이죠. -_-

도커 없이 설치하는 가이드는 없습니다. 지원이 제공되든 아니든 상관없이요. 호스트 IP를 컨테이너에 노출하는 방법에 대한 가이드나 도움도 없습니다.

2

Discourse 개발을 시작했을 당시, 도커가 당시 가장 좋은 도구였기 때문입니다.

만약 지금 다시 개발한다면, 자체적으로 만든 launcher 명령어(도커 이미지를 빌드하고 실행하는 기능) 대신 docker-compose를 사용하는 것이 유일한 차이점일 것 같습니다.

저와 인터넷이 다른 곳에 계신 것 같습니다. 제가 보는 바로는, 5대 이상의 서버에서 소프트웨어를 관리하는 대부분의 사람들은 컨테이너를 사용하여 시스템을 관리하고 있습니다. 개발자들도 모든 구성 요소의 버전이 일관되게 유지되는지 확인하기 위해 노트북에서 컨테이너로 실행하는 경우가 점점 더 늘고 있습니다.

단일 노트북에서 Discourse/rails/ember 개발 환경을 관리하는 것조차 상당한 도전 과제입니다.

맞습니다. 도커 없이 사용할 수 있는 포럼을 원하신다면, Discourse를 사용하지 않는 것이 좋습니다.

3

Docker가 그렇게 나쁜가요?

4

저는 이에 동의합니다. 방금 Docker와 docker-compose에 대한 크래시 코스를 수강했는데, docker-compose가 100% 더 나은 방법이라고 생각합니다. Discourse가 docker-compose를 사용했다면, 포스트를 작성할 필요 없이 이 문제를 해결할 수 있었을 것입니다.

docker-compose는 launcher가 수행하는 것과 유사한 무거운 작업을 처리하지만, docker-compose를 사용하면 네트워크와 브리지를 쉽게 구성할 수 있었습니다.

동의합니다. 저도 컨테이너를 사용합니다. 순수한 LXC 컨테이너를요. 추가 소프트웨어가 필요 없습니다. 하지만 생각만큼 간단하지는 않습니다. 예를 들어, 제 서버 중 하나에는 개발자를 위한 ‘브론즈’ 패키지가 있습니다. 저렴하고 설정이 쉬운 패키지입니다. 결제가 확인되는 순간, 메인 서버는 사용자가 선택한 LXC 컨테이너 또는 VM을 생성하는 요청을 받습니다. 당연히 도메인 이름이 필요하며, 없으면 서버(LXC/VM)를 위한 커스텀 서브도메인이 발급됩니다. 또한 사용자에게 자체 네트워크를 구성하도록 요청하며, 이 네트워크는 메인 네트워크와 상호 접근이 불가능하도록 설정됩니다. 기본적으로 작은 AWS와 같은 구조입니다.

개발 목적의 랩톱에서 메인 컴퓨터 파일과 개발 파일(네트워크 포함)을 분리하기 위해 Docker는 훌륭할 것입니다.

저는 Discourse/rails/ember로 직접 개발해 본 적이 없으므로 동의하기도, 반대하기도 어렵습니다. 그것은 제 전문 분야를 벗어나며, 개발자들이 더 쉽다고 한다면 제가 모르는 것에 대해 반박할 위치가 아닙니다.

이것이 제 문제입니다. 사용 가능한 모든 포럼 소프트웨어에 대해 충분한 조사를 했고, 꽤 많은 것을 사용해 봤습니다.

제 선택지는 결국 두 포럼으로 좁혀졌습니다:

  1. Discourse
  2. Flarum

모든 측면에서 최고의 포럼 소프트웨어인 Discourse를 선택했습니다. 제 Docker 경험은 Nginx Reverse Proxy Manager를 사용한 것이 전부였기 때문입니다.

.yml 파일에 제 정보를 입력하고 docker-compose up -d만 실행하면 된다고 생각했습니다. 하지만 틀렸습니다.

현재 겪고 있는 문제는 해결될 수 있으며, 그저 해결 방법을 파악하는 데 시간이 좀 걸릴 뿐입니다.
다른 좋은 포럼 소프트웨어에 대한 모욕은 아니지만, 저는 많은 플랫폼에서 Discourse를 사용해 봤고, Discourse가 시장에 나와 있는 최고의 포럼이라고 생각합니다. 따라서 Flarum을 사용하는 것을 거부합니다.

docker-compose로의 업그레이드가 도움이 될 수 있을 것입니다 :smiley:

5

간단한 조사와 5분 가이드, 그리고 유튜브 영상을 몇 개 살펴본 결과입니다.

아니요, Docker는 전혀 나쁘지 않습니다. Docker는 개인 기기를 사용해 개발하거나 심지어 업무용 컴퓨터를 사용하는 개발자들에게 완벽합니다. 대부분의 개발자가 Linux를 메인 OS로 사용하지 않기 때문에, LXC 컨테이너를 만드는 것은 그렇게 쉬울 수 없습니다. 바로 여기서 Docker가 빛을 발합니다. Docker는 모든 주요 플랫폼을 지원하므로 개발자들이 쉽게 협업할 수 있으며, 메인 OS에서 사용되지 않아야 하는 파일들로 인해 시스템 전체를 망가뜨리지 않는다는 장점도 있습니다.

더 자세히 설명할 수도 있지만, 제 생각에 최신 docker/docker-compose는 Discourse에 완벽합니다. Discourse는 많은 이동 부품을 필요로 하므로 docker-compose를 사용하면 번들링이 비교적 쉽기 때문입니다. 그렇게 하면 문제가 발생했을 때 개발자들이 정확히 무엇을 해야 하는지 알 수 있습니다.

Discourse에 대한 아이디어가 하나 있지만, 먼저 제 설치 환경을 파악해 보겠습니다.

6

확실히 이것이 이유일까요?

7

왜 공식적으로 Docker만 지원하나요?

Rails 애플리케이션의 호스팅은 복잡합니다. 서버에 이미 Postgres, Redis, Ruby가 설치되어 있더라도 Sidekiq과 Rails 프로세스를 실행하고 모니터링하는 것, 그리고 Nginx를 구성하는 것에 대해 여전히 신경 써야 합니다. Docker를 사용하면, 완전히 최적화된 Discourse 구성이 단순한 컨테이너 형태로 제공되며, 웹 기반 GUI를 통해 버튼만 클릭하면 Discourse의 새 버전으로 업그레이드할 수 있습니다.

8

런처가 필요하지 않으며, 맞춤형 Docker Compose 설치를 구성할 수도 있지만, 상당한 작업이 필요합니다.

9

주된 목표는 격리가 아니라 배포의 용이성입니다…

컨테이너를 격리할 필요가 없습니다. 라우팅된 브리지나 내부 네트워크에 속하는 포트가 있는 브리지에서 실행할 수 있습니다. 전자(라우팅된 브리지)는 우리가 프로덕션 환경에서 실행하는 방식이며, 작동 방식을 설명하는 @mpalmer의 동영상을 참고하세요.

정말 이렇게 하려는 사람이 있다면, 지원되는 이미지에서 사용되는 모든 도구의 올바른 버전을 얻기 위해 도커파일 자체에서 수행하는 동일한 단계를 따를 수 있습니다.

가이드를 제공하지 않는 이유는 유지보수를 위해 누군가가 필요하기 때문이며, 이를 원하는 사람들의 대다수는 다음 중 하나에 해당합니다:

  • 서버에 대한 경험이 거의 없거나
  • 우리가 제공하는 것을 받아들이고 필요에 맞게 수정할 수 있는 충분한 지식을 갖추고 있습니다.

예를 들어, 런서(launcher)를 사용하여 이미지를 빌드한 후 자체 도구(예: lxc, kubernetes 등)를 통해 배포하는 사람들이 있으며, 그들에게는 잘 작동합니다.

복잡한 소프트웨어인 이 시스템의 자체 커스텀 설치 환경을 사용하는 모든 사람을 (무료로) 지원하려는 시도는 악몽이 될 것입니다.

도커는 절충안입니다. 우리의 시스템은 완벽하지 않으며, 시간이 지남에 따라 다소 성장했고, 일부 지연된 리팩토링의 고통을 분명히 느끼고 있습니다. 우리는 docker-compose가 존재하기도 전에 런서를 만들었습니다.

우리는 이를 리팩토링하거나 docker-compose로 전환할 의향이 있지만, 현재로서는 우선순위가 아닙니다.

10

Nginx Reverse Proxy가 작동하는 데 필요한 ENV 변수로 Discourse를 시작하도록 launcher를 설정하는 것은 그리 어렵지 않습니다. 대부분은 단순히 YML 파일에 ENV를 추가하거나, ./launcher start-command app 명령으로 가져온 값에 추가하면 됩니다.

docker-compose는 Discourse가 처음 시작될 때 큰 도움이 되지 않았고, 아예 존재하지 않았을 수도 있습니다.

11

나는 도커를 싫어해 (나한테 너무 쉬워서, 애들도 다 할 수 있으니 특별할 게 없어! 하품!). 그리고 그냥 공식 도커 버전 없이도 동작하도록 코드를 쓰는 대신… 도무지 모르겠어! 공식 방법도 안 돼!

12

그리고 도전적인 과제를 원하거나 이미 그 분야를 마스터한 사람들도 있습니다. 그들에게는 Docker가 더 큰 장벽이 되는데, Docker까지 다뤄야 하기 때문입니다!

13

그렇다면 왜 Docker를 사용해야 할까요?