훌륭합니다. 아니요, 그거면 완벽할 것 같아요. 다시 한번 감사합니다. 정말 감사드립니다.
1개의 좋아요
지금은 ./discourse-setup --two-container 명령어를 사용합니다.
방금 바로 예상대로 작동했습니다 
2개의 좋아요
잘 짚어주셨네요! 그걸 쉽게 파악할 수 있게끔 메시지가 출력되었나요?
이들이 변경된 이후로 이 주제를 정리해 두고 싶었습니다.
1개의 좋아요
네, 정말 도움이 되었습니다. 감사합니다.
2개의 좋아요
기존 “컨테이너 링크” 방식을 커스텀 네트워크를 통해 두 컨테이너를 연결하는 적절한 설정으로 마이그레이션할 계획이 있나요?
"링크"는 레거시 기능이며, Docker 문서에 따르면 향후 제거될 수 있습니다.
1개의 좋아요
좋은 생각이네요.
누군가 먼저 하지 않는 한, 네트워크와 / 또는 소켓(어차피 일부는 이 방식을 선호하죠)으로 전환하기 위한 PR을 만들고, 기존 설정을 새 구성으로 변환하는 방법을 안내하는 howto를 작성해 보겠습니다.
5개의 좋아요
@pfaffman 시간이 되셨을지 모르겠지만, 혹시 하신 거라면 여기에 링크를 걸어주실 수 있을까요? 
3개의 좋아요
이 명령어 끝에 && ./launcher cleanup을 추가해야 할까요?
2개 컨테이너 설치 방식으로 전환한 후, 오래된 이미지로 인해 사용 가능한 저장소가 금방 가득 차는 것을 발견했습니다.
1개의 좋아요
저는 제 가이드에서 확실히 그렇게 추천합니다… 많은 분들이 DO 드롭렛 같은 작은 시스템에 배포하는데, 제가 도운 분들 중에는 공간이 어디에 쓰이는지 정확히 인지하지 못했던 분들도 있었습니다.
2개의 좋아요
@pfaffman, 안녕하세요,
몇日前 AWS EC2에 컨테이너 하나만 설치했는데, 그때는 모든 것이 정상적으로 작동했습니다. 하지만 지금 정확히 두 컨테이너 구성이 필요합니다. web_only는 EC2에, data는 AWS RDS(PostgreSQL 15.3, 포트 5432 => 다른 버전을 선택할 수 없고, 데이터베이스에 DB_NAME 매개변수가 없음)에 배치해야 합니다. Redis 클러스터로는 AWS ElastiCache를 사용해 보았지만, 결국 data.yml에 기존 템플릿에 대한 링크를 남겼습니다:
#- "templates/postgres.template.yml"
- "templates/redis.template.yml"
data와 web_only를 성공적으로 부트스트랩한 후에도 웹페이지를 열 수 없습니다. “이 사이트에는 액세스할 수 없음”
DNS 레코드나 AWS 보안 그룹(웹 및 데이터베이스용 방화벽)의 액세스 설정을 변경하지 않았습니다.
Successfully bootstrapped, to startup use ./launcher start data
root@ip-172-31-3-68:/var/discourse# ./launcher start data
x86_64 arch detected.
+ /usr/bin/docker run --shm-size=512m -d --restart=always -e LANG=en_US.UTF-8 -e LC_ALL=en_US.UTF-8 -e LANGUAGE=en_US.UTF-8 -h ip-172-31-3-68-data -e DOCKER_HOST_IP=172.17.0.1 --name data -t -v /var/discourse/shared/data:/shared -v /var/discourse/shared/data/log/var-log:/var/log --mac-address <...> local_discourse/data /sbin/boot
27b66e577d250e4178f5e145c9962be7b5f2d905cfacd233d3d2278e7b83aa93
Successfully bootstrapped, to startup use ./launcher start web_only
root@ip-172-31-3-68:/var/discourse# ./launcher start web_only
x86_64 arch detected.
+ /usr/bin/docker run --shm-size=512m --link data:data -d --restart=always -e LANG=en_US.UTF-8 -e RAILS_ENV=production -e UNICORN_WORKERS=2 -e UNICORN_SIDEKIQS=1 -e RUBY_GC_HEAP_GROWTH_MAX_SLOTS=40000 -e RUBY_GC_HEAP_INIT_SLOTS=400000 -e RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=1.5 -e DISCOURSE_DB_SOCKET= -e DISCOURSE_DB_HOST=database-discourse.<..>.rds.amazonaws.com -e DISCOURSE_DB_PORT= -e LETSENCRYPT_DIR=/shared/letsencrypt -e DISCOURSE_FORCE_HTTPS=true -e LC_ALL=en_US.UTF-8 -e LANGUAGE=en_US.UTF-8 -e DISCOURSE_HOSTNAME=talk.furtherium.com -e DISCOURSE_DEVELOPER_EMAILS=hello@furtherium.com -e DISCOURSE_SMTP_ADDRESS=email-smtp.us-east-2.amazonaws.com -e DISCOURSE_SMTP_PORT=587 -e DISCOURSE_SMTP_USER_NAME=A<...>S -e DISCOURSE_SMTP_PASSWORD=B<...>M -e DISCOURSE_NOTIFICATION_EMAIL=noreply@talk.furtherium.com -e LETSENCRYPT_ACCOUNT_EMAIL=me@example.com -e DISCOURSE_DB_NAME= -e DISCOURSE_DB_USERNAME=postgres -e DISCOURSE_DB_PASSWORD=7<...>1 -e DISCOURSE_REDIS_HOST=data -h ip-172-31-3-68-web-only -e DOCKER_HOST_IP=172.17.0.1 --name web_only -t -p 80:80 -p 443:443 -v /var/discourse/shared/web-only:/shared -v /var/discourse/shared/web-only/log/var-log:/var/log --mac-address <...> local_discourse/web_only /sbin/boot
1233f1c660eb7cecc48d2a840aae037b46ecfd7afe029ef89b2e686b136b9886
- SSH를 통해 telnet으로 데이터베이스 연결을 확인했습니다 - 정상(OK)
- AWS RDS 대시보드에서 데이터베이스 연결을 확인할 수 있습니다
- 인스턴스를 3회 재시작했습니다
- 오류 없이 rebuild를 3~4회 실행했습니다
- 활성 컨테이너와 이미지 목록을 확인하고 불필요한 항목을 정리했습니다
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
1233f1c660eb local_discourse/web_only "/sbin/boot" 18 minutes ago Up 18 minutes 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp web_only
27b66e577d25 local_discourse/data "/sbin/boot" 47 minutes ago Up 47 minutes data
그 외에 무엇을 더 해볼 수 있을까요? 노력과 시간을 내어 주셔서 감사합니다!
그렇지 않습니다. 웹 컨테이너만 있으면 되고, Postgres와 Redis 템플릿은 삭제하면 됩니다. Elasticache는 제 생각에 터무니없이 비싸므로, 단일 호스트를 사용하는 경우 EC2에서 실행할 수 있습니다.
기존 app.yml에 환경 변수를 추가하고 불필요한 템플릿을 삭제하기만 하면 됩니다. 최근 이 사이트가 PG15로 실행되고 있다는 소식을 들었으니, 그 정도는 문제없을 것입니다.
답변해 주셔서 감사합니다, Jay (@pfaffman). 다음 사항들을 명확히 하고 싶습니다:
- 단일 컨테이너용 app.yml 설치를 사용하고, 데이터베이스와 redis 관련 줄들을 주석 처리해야 하는가요? 또한 app.yml의 ENV 필드에도 AWS의 원격 데이터베이스를 위한 줄들(DB_USER 등 - 현재 web_only와 동일하게)을 추가해야 하는가요?
- 아니면 그대로 두되, 데이터 컨테이너를 중지하고 web-only만 유지하는 것이 나은가요?
- ElastiCache를 사용하지 않는 경우, “templates/redis.template.yml” 줄을 그대로 두어야 하는가요?
표준 구성에서 2컨테이너 구성으로 전환하는 과정은 거의 순조로웠습니다. yml 파일에서 몇 가지 공백이 누락되어 로컬라이제이션 문제가 있는 것처럼 보이게 했기 때문에(사실은 전혀 관련이 없었지만) 꽤 많은 시간을 낭비했는데, 이건 제 실수였습니다.
하지만 포럼을 실행했을 때 완전히 비어 있는 새 포럼 상태였습니다. S3에 최신 백업이 있어서 쉽게 해결할 수 있었지만, 왜 이런 일이 발생했는지 궁금합니다 — 혹시 추측이 있으신가요?
완전히 새로운 2컨테이너 구성을 설치한 후 백업에서 복원하는 경로를 선택하면 시간을 절약할 수 있을 것 같습니다. 아니면 아닐 수도 있는데, 어쨌든 yml 파일을 편집해야 하기 때문입니다. 최소한 플러그인 추가, 이메일 설정 수정, maxmind 설정 등은 해야 하니까요.
1개의 좋아요
[위 게시물과 무관]
두 개의 컨테이너를 사용하는 구성의 장점이 무엇일지 궁금합니다. 왜 일반적인 단일 컨테이너를 사용하지 않는 것일까요?
업그레이드나 플러그인 설치 시 재빌드를 하는 동안 포럼이 오프라인 상태가 되지 않도록 하기 위한 것이라고 생각합니다.
2개의 좋아요
제 경우에는 이미 짧은 다운타임이 언급되어 있습니다. 또한 저는 적어도 주 1회 이상 자주 업그레이드를 하므로, 제 환경은 버그에 걸리기 쉽습니다 — 자주 그런 일은 아니지만, 그래도 가끔은 발생하죠.
원인이 플러그인인 경우 — 이 경우도 자주 있는 일은 아니고, 대부분 어떤 컴포넌트의 문제입니다 — 문제의 원인을 찾아 해결하는 데 3~4회 정도가 걸립니다. 그리고 한 번의 과정에 30분 정도가 걸린다면, 제 포럼이 작고 취미로 운영되는 곳이지만, 다운타임이 좀 너무 길어집니다.
그리고 세 번째 이유는, 제가 그럴 수 있었기 때문입니다.
2개의 좋아요
재빌드(Rebuild)가 실패해서 사이트가 다운되면 매우 스트레스를 받습니다. 기본적으로 즉각적인(때로는 장기간에 걸친) 주의가 요구되며, 문제를 해결하거나 우회책을 찾아야 합니다. 전혀 즐겁지 않습니다!!!
두 컨테이너 설치 방식은 이러한 상황을 단순한 불편함으로 바꿔줍니다. 그리고 근본적인 문제는 보통 제 일정에 맞춰 처리할 수 있습니다. 또한, 그 시점에는 문제를 일으킨 원인이 이미 해결된 경우가 많습니다.
stable을 사용한다면 아마 신경 쓰지 않을 것 같습니다. 하지만 tests-passed를 사용하면서 엣지에 더 가까운 환경에서 운영하다 보니, 재빌드/업데이트 시 부여되는 견고성(resilience) 때문에 그 가치는 매우 큽니다.
2개의 좋아요
아, 알겠습니다. 설명해 주셔서 감사합니다!
내가 그걸 올렸다는 걸 완전히 잊고 있었네요!
1개의 좋아요
좋은 튜토리얼이네요. 새 서버를 만들고 백업을 생성한 뒤 복구하는 데 걸리는 시간은 고작 5분뿐입니다. 그리고 ./discourse-setup --two-container를 실행하면 됩니다.
감사합니다.
2개의 좋아요
기존 서버의 데이터베이스가 정상적인 상태에서 변환을 진행할 때, 왜 이 단계가 필요한지 설명해 주실 수 있나요?
마이그레이션 직전에 안전한 오프사이트 백업을 만드는 것이 좋은 관행이라는 것은 이해하지만, 왜 다운로드까지 해야 하는지 궁금합니다.
2개의 좋아요