Docker를 사용하지 않는 설치 환경에서 이상한 문제를 추적하고 있습니다. (이 유형의 설치에 대한 지원이 제한적이거나 사실상 없다는 점은 인지하고 있으므로, 여기서 무엇이 문제일 수 있는지에 대한 힌트만 부탁드립니다. 저희 내부 패키징 팀은 ‘개발자 빌드’ 지침을 참고하여 필요한 패키지를 빌드하는 방법을 파악했습니다.) 설치 방식에 따라 문제가 발생하는 것을 확인했습니다. 인프라 팀은 Docker 기반 설치를 꺼려하고(모든 것을 직접 빌드하기를 선호합니다) 있으므로, 데이터베이스 사본을 가진 Docker 기반 및 비-Docker 기반 샌드박스 인스턴스를 실행하여 문제가 어디서 발생하는지 검증하고 있습니다. 이는 분명히 저희가 세트를 설치한 방식에서 비롯된 결과입니다.
3.3.2에서 3.3.3으로 업그레이드한 후, 영어가 아닌 언어를 사용하는 포럼 스태프 일부가 악센트 문자가 포함된 섹션의 ‘정보(About)’ 텍스트가 올바르게 인코딩되지 않는 것을 발견했습니다:
카테고리 페이지에서 변경 사항을 확인하며 해당 텍스트를 편집함으로써 이것이 동일한 텍스트임을 확인했습니다.
즉, 이는 카테고리 페이지에서 해당 텍스트를 렌더링하는 방식과 관련된 특정 문제입니다.
브라우저에서 document.characterSet을 확인해 보니 UTF-8으로 올바르게 식별되고 있습니다. 데이터베이스에서도 포맷이 UTF-8으로 표시되고 있습니다.
이 텍스트가 카테고리 페이지에서 어떻게 렌더링되는지에 대해 무엇이 다른지 알려줄 수 있는 분이 있을까요? 제 추측으로는, 시스템의 다른 텍스트에는 사용되지 않지만 이 텍스트 렌더링에 사용되는 루비(ruby) 패키지가 제대로 빌드되지 않았거나(UTF-8 지원 누락 가능성) 또는 정보 메시지 텍스트를 처리하고 잘라내는(이 경우 실제로 잘라져 있는 것을 확인했습니다. 그러나 잘라지지 않은 외부 프랑스어 포럼 링크도 동일한 코드로 평가되는 것으로 추정됩니다) 어떤 요소가 문제일 것 같습니다.
원본 categories.json을 확인해 보면, 발췌문(excerpt)에서만 오류가 나는 것을 알 수 있습니다:
"description": "Esta sección del Foro se dedica a las personas usuarias de openSUSE que forman parte de la comunidad lingüística castellana, de tal forma que dichas personas puedan consultar y participar en el foro en dicha lengua (sea el dialecto español o cualquiera de las variedades latinoamericanas, etc.).",
"description_text": "Esta sección del Foro se dedica a las personas usuarias de openSUSE que forman parte de la comunidad lingüística castellana, de tal forma que dichas personas puedan consultar y participar en el foro en dicha lengua (sea el dialecto español o cualquiera de las variedades latinoamericanas, etc.).",
"description_excerpt": "Esta sección del Foro se dedica a las personas usuarias de openSUSE que forman parte de la comunidad lingüÃstica castellana, de tal forma que dichas personas puedan consultar y participar en el foro en dicha lengua (sea el dialecto español o cualquiera de las variedades latinoamericanas, etc.).",
try.discourse.org에서 동일한 카테고리를 생성하고 categories.json을 확인하면 올바른 결과가 나옵니다:
"description": "Esta sección del Foro se dedica a las personas usuarias de openSUSE que forman parte de la comunidad lingüística castellana, de tal forma que dichas personas puedan consultar y participar en el foro en dicha lengua (sea el dialecto español o cualquiera de las variedades latinoamericanas, etc.).",
"description_text": "Esta sección del Foro se dedica a las personas usuarias de openSUSE que forman parte de la comunidad lingüística castellana, de tal forma que dichas personas puedan consultar y participar en el foro en dicha lengua (sea el dialecto español o cualquiera de las variedades latinoamericanas, etc.).",
"description_excerpt": "Esta sección del Foro se dedica a las personas usuarias de openSUSE que forman parte de la comunidad lingüística castellana, de tal forma que dichas personas puedan consultar y participar en el foro en dicha lengua (sea el dialecto español o cualquiera de las variedades latinoamericanas, etc.).",
귀하의 설치 환경에서 이 문제를 추적하기 위한 다음 단계가 무엇인지 확실하지 않지만, 발췌문을 생성하는 코드 경로에 집중하면 도움이 될 수 있습니다. 또한 이 문제가 UTF-8 인코딩이 iso-8859-1로 해석되는 과정에서 발생했다는 점을 아는 것도 중요합니다.
○ → ipython3
In [1]: 'Esta sección del Foro se dedica a las personas usuarias de openSUSE que forman parte de la comunidad lingüística castellana
...: , de tal forma que dichas personas puedan consultar y participar en el foro en dicha lengua (sea el dialecto español o cualq
...: uiera de las variedades latinoamericanas, etc.).'.encode('utf-8').decode('iso-8859-1')
Out[1]: 'Esta sección del Foro se dedica a las personas usuarias de openSUSE que forman parte de la comunidad lingüÃ\xadstica castellana, de tal forma que dichas personas puedan consultar y participar en el foro en dicha lengua (sea el dialecto español o cualquiera de las variedades latinoamericanas, etc.).'
그렇지 않을까 생각했지만, 메시지를 변경하자 업데이트가 이루어졌으므로 캐싱 문제는 아닌 것 같습니다. 인코딩이 잘못되고 있는 것 같습니다.
몇 가지 옵션을 제안했지만, 결국 인프라 팀은 빌드 서비스로 빌드된 패키지를 사용하는 쪽으로 결정했습니다. "우리는 Docker를 싫어한다"는 식의 문제는 아닌 것 같습니다(물론 podman을 사용하려는 경향이 더 클 수는 있지만), 더 정확히 말하면 현재 사용 중인 구성 관리 도구를 사용하여 모든 것을 동일한 방식으로 관리하려는 방식입니다. Docker/podman을 사용하는 일회성 설치는 그들이 사용하는 CI/CD 설정에 다른 복잡성을 더할 수 있다고 이해하고 있습니다.
결국, 저는 문제를 보고하기 위해 문제가 어디에서 비롯되었는지 파악할 수 있도록 두 개의 샌드박스를 설정했습니다. 불행히도, 이는 우리가 빌드한 방식에 문제가 있는 경우, 표준 Docker 기반 설치와 우리가 다르게 처리하고 있는 부분을 찾아내어 수정해야 함을 의미합니다.
그들이 Discourse 방식이 미친 짓이라고 생각하며 모든 것을 하나의 통합 시스템 하에서 관리하기를 정말로 원한다는 점은 이해합니다.
하지만요. 마지막으로 제가 일했던 고객 중 자신들이 좋아하는 도구를 사용하겠다고 고집했던 고객은 discourse.org 호스팅으로 이전할 수 있는 사용 가능한 백업을 만드는 데 거의 20시간의 작업 비용을 지불했습니다. 그 이전 고객은 사이트가 주에 여러 번 충돌하지 않도록 커스텀 설정을 조정하는 데 훨씬 더 많은 돈을 지불했고, 1년 후에는 discourse.org 호스팅으로 이전하는 데 또 다시 더 많은 비용을 지불했습니다.
조언에 감사드립니다. 좋은 소식은 프로덕션 시스템의 백업이 Docker화 된 설치 환경에서도 문제없이 작동한다는 점입니다(직접 테스트해 보았습니다). 따라서 Docker 기반 설치가 올바른 방향이라고 판단될 경우, 우리는 좋은 상태에 있을 것입니다. 우리는 상당량의 데이터를 보유하고 있으며(몇 년 전 vBulletin에서 Discourse로 마이그레이션했습니다) 전반적으로 잘 작동해 왔지만, 간혹 작은 문제들이 발생하기도 했습니다.
결국, 우리는 Discourse가 어떻게 작동하는지에 대해 많은 것을 배웠으므로 전반적으로 나쁜 일은 아니었습니다.
/categories.json은 정적 파일이 아니라 API 엔드포인트로 보입니다. 이는 문제를 Ruby 또는 JavaScript 중 하나로 제한하는 데 도움이 될 것 같습니다. 해당 엔드포인트의 스키마 위치는 찾았지만, Ruby에는 특히 익숙하지 않습니다(수년에 걸쳐 많은 프로그래밍 언어 경험을 쌓아왔기 때문에 코딩은 못 하더라도 대부분의 언어를 읽는 데는 문제가 없으며, 대략적인 내용은 쉽게 파악할 수 있습니다). JavaScript는 주로 브라우저에서 실행되고, Ruby는 서버에서 실행되는 것으로 보입니다(다만 nodejs도 설치되어 있으므로, 이 일반화가 정확하지 않을 수 있습니다).
/categories를 처리하는 함수를 찾으면(끝에 붙은 .json은 출력을 어떻게 포맷할지를 코드에 알려주는 것 같고, 예를 들어 /top와 /top.rss에서 비슷한 동작을 볼 수 있습니다), 코드에서 어디를 봐야 할지 좁혀질 것이며, 이는 어떤 Ruby gems(대부분 Ruby 코드일 것이라고 확신합니다)이 제대로 빌드되었는지 확인해야 하는지 알려줄 것입니다.
이것은 제가 사용자(panorain)에게 답변하면서 인용한 내용입니다. 실수로 이 문제를 발견했는데, 제 활동 내역을 확인하려 했더니 500 서버 오류가 발생했고, /logs 출력에서 lib/excerpt_parser.rb에 런타임 오류 "input string cannot be empty"가 표시되었습니다.
몇 가지 현상이 발췌 처리 과정의 어떤 부분으로 이어지는 것 같지만, 개발 스타일 설치 환경에서만 발생하는 것으로 보입니다.
Docker 기반 설치 환경에서는 오류 없이 제 활동 내역을 확인할 수 있습니다. 이상하게도, 해당 설치 환경의 데이터베이스는 최근 프로덕션 서버 백업에서 복원된 것이며, 그 프로덕션 환경에서는 문제가 존재합니다.
그래서 패키지를 내려서 다시 nokogiri 1.16을 사용하도록 했습니다. 이해가 안 되는 점은, 중복 패키징을 줄이기 위해 gem을 업데이트할 때마다 main에 관련 변경 사항이 있는지 확인하는데, 변경 사항이 없었습니다. 제가 무언가를 놓친 것이 아니라면요.
"description": "Witaj w polskiej sekcji społeczności openSUSE!",
"description_text": "Witaj w polskiej sekcji społeczności openSUSE!",
"description_excerpt": "Witaj w polskiej sekcji spoÅecznoÅci openSUSE!",
보시는 것처럼 올바른 텍스트가 두 번 있고, PrettyText.excerpt를 거칠 때만 깨집니다. main에서는 이것이 어떻게 처리되나요?
@hendersj DB의 사본으로 테스트할 수 있도록 main 패키지를 준비하고 있습니다.
[1] pry(main)> Nokogiri::VERSION
=> "1.18.2"
[2] pry(main)> t = '<div>Witaj w polskiej sekcji społeczności openSUSE!</div>'
=> "<div>Witaj w polskiej sekcji społeczności openSUSE!</div>"
[3] pry(main)> Nokogiri.HTML5(t).to_s
=> "<html><head></head><body><div>Witaj w polskiej sekcji społeczności openSUSE!</div></body></html>"
[4] pry(main)> Nokogiri.HTML5(t, encoding: Encoding::UTF_8).to_s
=> "<html><head></head><body><div>Witaj w polskiej sekcji społeczności openSUSE!</div></body></html>"
[5] pry(main)> Nokogiri.HTML5(t).to_s == Nokogiri.HTML5(t, encoding: Encoding::UTF_8).to_s
=> true
retrieve_title 함수는 외부 URL(예: YouTube)에서 제목을 추출하는 데 사용되며, 이 코드 경로에 대해 매우 정통하지는 않지만 이것이 문제의 원인이면 놀라울 것입니다.
다른 것(예: 커스텀 플러그인에서 이 함수를 사용하는 경우)을 하고 있다면,那里的 인코딩 매개변수는 가져온 리소스의 content-type 헤더에서 가져옵니다:
if !encoding && content_type = _response["content-type"]&.strip&.downcase
if content_type =~ /charset="?([a-z0-9_-]+)"?/
encoding = Regexp.last_match(1)
encoding = nil if !Encoding.list.map(&:name).map(&:downcase).include?(encoding)
end
end
max_size = max_chunk_size(uri) * 1024
title = extract_title(current, encoding)
따라서 응답하는 웹 서버가 잘못된 content-type을 보고하고 있다고 의심할 수 있습니다.
)