플러그인 클리너

커스터마이징 플러그인
1
:information_source: 요약 삭제된 플러그인 때문에 데이터베이스에 남아 있는 고립된 잔여 데이터를 안전하게 스캔, 감사 및 정리합니다.
:hammer_and_wrench: 저장소 링크 GitHub - canbekcan/discourse-plugin-cleaner · GitHub
:open_book: 설치 가이드 Discourse에 플러그인 설치하는 방법
:computer: 코딩 Vibe Coding - Gemini

기능

Discourse 플러그인을 삭제하면 데이터베이스에 숨겨진 데이터가 남아 있는 경우가 많습니다. 시간이 지나면 이러한 '잔여 데이터’가 데이터베이스를 지저분하게 만들고 사이트 유지보수를 복잡하게 만들 수 있습니다. Discourse Plugin Cleaner는 이러한 고립된 데이터를 안전하게 식별하고 제거하도록 설계된 포괄적인 관리 도구입니다.

주요 기능:

  • 심층 스캔: 사용자, 토픽, 게시물, 카테고리, 그룹의 커스텀 필드, 플러그인 설정, 테마, 배지, API 키, 웹훅, 태그 그룹, 업로드 등 여러 데이터베이스 테이블을 스캔합니다.
  • 안전 감사 모드 (자동 삭제 없음): 이 플러그인은 사용자가 조치를 취할 때까지 순수한 감사 도구로만 작동합니다. 데이터는 절대 자동으로 삭제되지 않습니다. 삭제하려는 항목을 수동으로 선택하고 확인해야 합니다.
  • 리스크 평가: 감지된 항목에 ‘리스크 수준’(Critical, High, Medium, Low, OK)을 자동으로 부여하여 관리자가 무엇을 안전하게 삭제할 수 있는지 판단할 수 있도록 돕습니다.
  • 버전 히스토리 추적: 부팅 시 설치된 플러그인의 스냅샷을 생성합니다. 플러그인이 제거되면 상태 변경을 기록하여 어떤 플러그인이 언제 삭제되었는지에 대한 역사적 기록을 만듭니다.
  • 현대적인 관리자 인터페이스: Ember strict-mode 구성 요소를 사용하여 구축된 세련되고 직관적인 대시보드를 제공하여 Discourse 관리자 인터페이스에 원활하게 통합됩니다.

설정

이 플러그인은 적절한 기본값으로开箱即用(바로 사용 가능)합니다. 플러그인을 사용하려면:

  1. 대시보드 접근: Discourse 관리자 대시보드로 이동합니다. 사이드바의 플러그인 섹션에서 Plugin Cleaner를 클릭합니다.
  2. 스캔 실행: “심층 스캔 실행” 버튼을 클릭합니다. 시스템이 데이터베이스를 조회하고 발견된 모든 고립된 데이터에 대한 실시간 보고서를 생성합니다.
  3. 이슈 검토: 범주별 탭(커스텀 필드, 플러그인 설정 등)을 살펴봅니다. Risk(리스크)와 Status(상태) 열에 주의를 기울이세요.
  4. 선택 및 정리: 제거하려는 고립된 항목 옆의 체크박스를 선택합니다.
  5. 삭제 확인: **“선택 항목 삭제”**를 클릭합니다. 데이터가 영구적으로 삭제되기 전에 최종 확인 경고가 표시됩니다. 모든 삭제 작업은 보안 감사를 위해 Discourse 스태프 액션 로그에 자동으로 기록됩니다.

(업로드 관련 참고: 고립된 업로드가 발견되면 서버 콘솔에서 rake uploads:clean을 실행하여 디스크 공간을 물리적으로 확보하도록 안내합니다).

설정

사이트 설정을 통해 스캐너의 엄격도를 사용자 지정할 수 있습니다.

이름 설명
plugin_cleaner_orphan_threshold 커스텀 필드가 ‘고립된’ 것으로 간주될 수 있는 최대 레코드 수입니다. 커스텀 필드의 레코드 수가 이 임계값보다 적으면 검토 대상이 됩니다. (기본값: 5, 최소: 1, 최대: 100)
plugin_cleaner_stale_api_key_days API 키가 스캐너에 의해 stale/고립된 것으로 플래깅되기 전에 사용하지 않아야 하는 일수입니다. (기본값: 90일, 최소: 7, 최대: 365)
plugin_cleaner_stale_upload_days 링크가 끊어진 업로드가 고립된 것으로 플래깅되기 전에 존재할 수 있는 일수입니다. (기본값: 30일, 최소: 1, 최대: 365)

(참고: 이 프로젝트는 Discourse 플러그인이 어떻게 작동하는지 이해하기 위한 것입니다)

2개의 좋아요
2

좋은 의도네요.

몇 가지 도전과제가 있습니다:

  • 많은 우수한 플러그인들은 자체 테이블을 생성하고 관리합니다. 현재 코드를 살펴본 결과, 이 부분을 아직 고려하지 않은 것 같지 않나요?

    • 플러그인을 제거하면 마이그레이션도 함께 사라진다는 점이 문제입니다.
    • 플러그인이 핵심 테이블의 데이터를 변경하는 경우(예: 레코드 추가)는 어떻게 하나요? 데이터 탐색 쿼리나 더 투명하지 않은 작업 등이 해당될 수 있습니다.

  • 특정 플러그인을 "정화"하려는 사용자가 아닌 일반 사용자가 커스텀 필드를 삭제하는 것을 방지하는 방식을 찾지 못했습니다. 사용자가 직접 해당 필드를 식별하도록 의존하고 있나요? 핵심에 포함된 커스텀 필드 삭제를 차단하는 것뿐인가요?

그리고 이 점과 관련하여:

이 부분은 다소 위험해 보입니다. 핵심 업그레이드 시 새로운 필드가 추가되는데 이를 목록에 포함하지 않았다면, 명시적으로 나열하지 않은 새로운 핵심 필드를 삭제하는 위험을 감수하게 되는 것 아닌가요?

어쨌든 개발에 행운을 빕니다. 분명히 흥미로운 추가 기능입니다.

8개의 좋아요
3

이러한 플러그인이 필요한 것을 삭제하여 데이터베이스가 손상된 상태로 남을 확률은 0보다 큽니다. 삭제되지 않고 남은 테이블이 문제를 일으킨 사례는 기억나지 않습니다.

7개의 좋아요
4

해당 테이블에 코어 디스코urs 테이블을 참조하는 외래 키가 있는 경우를 제외합니다. 이 경우 해당 테이블의 데이터 삭제가 방지될 수 있습니다.

그러나 이 문제는 다른 도구를 통해 신뢰할 수 있게 감지할 수 있는 문제가 아닙니다. 이러한 관계를 생성하는 플러그인은 외래 키를 생성하지 않거나, 디스코urs가 설치에서 플러그인이 사라졌을 때 이를 "해제"할 수 있는 방법을 플러그인이 등록할 수 있는 방법을 제공해야 합니다.

3개의 좋아요