Docker 업데이트 중 손상된 Digital Ocean의 Discourse 설치 복구

무엇을 원하시나요?
제 Discourse 설치 환경은 3년간 완벽하게 작동해 왔습니다. Docker를 수동으로 업데이트한 후 모든 것이 깨졌습니다. 현재는 복구 모드(Recovery Mode)에서만 서버에 접근할 수 있습니다. Docker를 시작할 수 없으며, 복구 모드 대신 하드 드라이브에서 서버를 시작하면 SSH로 연결할 수 없습니다.

언제까지 완료되길 원하시나요?
Discourse가 다시 작동하도록 만들어 주세요!

2개월 전의 스냅샷은 있지만, 지난 2개월간의 데이터를 잃고 싶지는 않습니다. 또한 Docker가 고장난 직후의 스냅샷도 보유하고 있습니다.

몇 시간 전에 개발자를 고용했는데, 해당 개발자는 늦은 시간이라 프로젝트를 완료하지 못했습니다. 그러나 이 문제는 가능한 한 빨리 해결해야 합니다. 이는 운영 중인 프로덕션 사이트입니다.

그는 다음과 같이 말했습니다:

모든 표준 점검을 수행했으며, ssh는 작동 중이고 트래픽이 차단되지 않았습니다. ssh 설정을 패스워드 인증을 사용하도록 업데이트했습니다. 해야 할 일은 이 고장 발생 전에 어떤 단계가 수행되었는지 조사하고 관련 로그를 확인하는 것입니다.

이 작업을 위해 USD로 제공할 수 있는 예산은 얼마인가요?
시중 시세에 맞춰 시간당 요금으로 지불하겠습니다. 시간당 요금을 공유해 주세요.

2개의 좋아요

DM을 보냈습니다. 거기서 말했듯이, 새로운 Droplet을 빠르게 생성하는 것이 가장 빠를 수 있습니다.

3개의 좋아요

도와주셔서 정말 감사합니다, @jericson!

결국 이렇게 해결했습니다:

  1. 기존 사이트의 복구 접근 권한 확보
  2. 네트워크 드라이브 연결 (Digital Ocean Volume Block Storage)
  3. /var/discourse 파일 압축 (tar 볼 생성)
  4. 해당 파일을 네트워크 드라이브로 복사
  5. 기존 서버 종료 및 네트워크 드라이브 분리
  6. 새 서버에서 새로운 Discourse 조직 구축
  7. 네트워크 드라이브 연결
  8. 파일 압축 해제
  9. 7일 단위 백업 중 해당 시점의 백업 찾기
  10. 해당 시점으로 복구

처음에는 /var/discourse 폴더를 통째로 새 서버로 옮기려 했으나 Redis 문제(이것이 근본적인 문제였는지 확실하지는 않지만, 시스템에서 이 부분이 오류로 표시됨)에 부딪혔습니다.

다시 한번 도와주셔서 감사합니다, Jon. 감사합니다!

5개의 좋아요

설치를 정상적으로 해결하셨다니 다행입니다. 잘하셨네요 @jericson :clap: :slight_smile: :discourse:

4개의 좋아요

궁금해서 여쭤봅니다. 최근 Docker와 DigitalOcean와 관련된 업그레이드 실패 메시지가 몇 건 보이는데, 우연한 일치인가요, 아니면 DigitalOcean에서 Discourse를 운영하는 다른 관리자들도 업그레이드 시 동일한 문제를 겪게 될 공통 원인이 있는 건가요? 저도 그중 한 명이라서요. :sweat_smile:

@waffleslop @jericson 잘하셨네요. 문제를 해결하기 위해 무엇을 하셨는지 정보를 올려주셔서 감사합니다. 셀프 호스터로서 나중에 문제가 생겼을 때 그런 리소스가 있으면 항상 도움이 되거든요!

@icaria36 저는 대부분의 인스턴스를 Digital Ocean에서 사용하고 있으며, 최근 OS와 Discourse 코드베이스를 모두 업그레이드했지만 전혀 문제가 없었습니다. (이것을 게시하는 것이 불운을 부르지 않기를 바랍니다!)

2개의 좋아요

어제까지 모든 업그레이드가 매우 쉬웠다는 것을 확인해 드립니다. GUI를 통해 Docker를 업데이트했는데 잘 작동했습니다. 그 다음 다음 3개 항목을 업데이트하려고 했는데, 그중 하나(어떤 건지 기억이 나지 않음)를 먼저 눌렀습니다. 아무 반응이 없었습니다. 몇 초를 기다린 후 다른 것을 눌렀고, 그 다음 또 다른 것을 눌렀습니다. 너무 빨리 행동해서 문제를 일으킨 걸까요? 결국 콘솔에 로그인했는데 재시작이 권장된다는 메시지를 발견했고, 그래서 기기를 재부팅했습니다. 그 후로 기기가 완전히 온라인으로 돌아오지 않았습니다.

업데이트/업그레이드 중에 재부팅을 했을 수도 있는데, 이렇게 쓰면서 보니 그건 꽤 멍청한 행동인 것 같습니다!

3개의 좋아요

@waffleslop 의 서버를 가능한 한 빨리 정상적으로 가동하고 싶었기 때문에 문제의 원인을 파악하는 데 시간을 들이지 않았습니다. 저는 DigitalOcean에 호스팅된 Discourse 서버를 업그레이드하면서 문제가 없었습니다. 다만, 비표준 설치를 사용하고 있기 때문에 GUI 대신 커맨드 라인을 사용합니다.

긴 시간의 다운타임을 최소화하기 위해 몇 가지 사항을 권장합니다:

  1. 무엇이든 하기 전에 백업을 만드세요! 업데이트를 수행하기 전에 백업을 강력히 권장하는 경고가 인터페이스에 있어야 하지 않을까요? 최근 백업이 있으면 최악의 경우에도 새로운 Droplet을 구동하고 데이터를 복원할 수 있다는 안도감을 줍니다.
  2. 백업에 접근할 수 있는지 확인하세요! @waffleslop 과 저는 /var/discourse 의 사본을 새로운 Droplet으로 가져오는 방법을 파악하는 데 상당한 시간을 보냈습니다. 원래 Droplet에서 매우 이상한 일이 발생하여 파일을 새 Droplet으로 단순히 scp 명령으로 전송할 수 없었습니다. 제 개인 서버의 경우 백업을 S3에 저장하고 매일 밤 로컬 머신으로 복사합니다. 지나치게 과한 조치일까요? 아마도 그렇겠죠. 하지만 어떤 이유로든 시스템이 작동하지 않을 때 다양한 선택지를 제공해 줍니다.
  3. 가끔씩 백업을 테스트하세요. 프로덕션 서버가 다운된 상황에서는 자신이 무엇을 하고 있는지 확신을 가질 필요가 있습니다. 이상적으로는 업데이트를 수행하기 직전에 백업을 테스트하여 프로덕션에서 문제가 발생했을 경우로 돌아갈 수 있는 준비를 해두는 것이 좋습니다. 하지만 프로세스를 머릿속에 생생하게 유지하기 위해 필요한 만큼 백업을 테스트하는 것만으로도 보통 충분합니다.
  4. 두 사람의 머리가 한 사람보다 낫습니다. 이것이 제 이기적인 생각일 수도 있지만, 이러한 상황에 익숙한 누군가와 화면을 공유하며 통화를 할 수 있다면 비상 상황을 훨씬 쉽게 헤쳐 나갈 수 있습니다. 이상적으로는 커맨드 라인을 사용하는 방법을 아는 사람이 좋습니다.

백업만 잘 해두면 업그레이드를 꽤 안전하게 진행할 수 있습니다.

5개의 좋아요

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.