404 오류시 HAProxy URL 재 작성

첫 번째 파일이 없을 때 HAProxy를 다른 백엔드에 다시 쓰는 방법? 필요한 것은 errorloc리디렉션 대신 다시 작성하는 것이므로 클라이언트는 리디렉션을 인식하지 못합니다.

우리는 정적 파일을위한 리버스 프록시와 웹 서버의로드 밸런싱을 염두에두고 NginX를 염두에두고 응용 프로그램을 개발했습니다. 응용 프로그램은 쿠키를 기반으로 고정 세션이 필요한 Opa 프레임 워크를 기반으로합니다. NginX와 HAproxy 모두에서 지원됩니다. 문제가되는 애플리케이션 기능은 동적 컨텐츠 생성입니다. 필요시 이미지를 생성하지만 생성 후 디스크에 저장되며 결정적인 경로를 사용하여 정적으로 액세스 할 수 있습니다.

문제는 NginX로 쉽게 해결되었습니다. 파일이 누락 된 경우 (아직 생성되지 않은 경우에만) 로컬 파일을 읽고로드 밸런싱 된 백엔드를 사용하려고합니다.

server {
  server_name wkaliszu.pl;
  location /thumb {
    root /path_on_disk/to_cached_content;
    expires 7d;
    # try to access already generated content
    try_files $uri @wkaliszu;
  }
  location / {
    # reverse proxy to the application
    [...]
  }
  location @wkaliszu {
    # reverse proxy to the application
    [...]
  }
}

서버가 마이그레이션되었으며 이제 웹 서버가 아니며이 기능을 지원하지 않는 부하 분산을 위해 HAPproxy를 사용합니다. 이제 클라이언트가 리소스에 액세스하려고 할 때마다 동적 소프트웨어 생성이 수행되어 훨씬 느리고 리소스가 낭비됩니다. 첫 번째 (정적 파일에 대한 간단한 캐싱 웹 서버)가 오류 404로 실패한 경우 다음 백엔드를 사용할 수 있으면 좋을 것입니다. 그러나 간단한 방법은 없습니다. /thumb정적 파일을 읽으려고 시도하고 새로운 HTTP 헤더로 HAproxy에 다시 쓰는 NginX로 리디렉션 하면 마음에 들지만 더 나은 것을 찾고 싶습니다.

nginx haproxy

— 마르신 스 코르 츠키
소스

백엔드 애플리케이션 서버는 어떤 앱 스택을 사용합니까?

— jeffatrackaid

HAProxy의 백엔드가 작동 또는 작동 중지 상태입니다.

백엔드의 상태를 확인하는 여러 가지 방법이 있지만 요청 기반 추적을 제공하는 방법은 없습니다. 요청이 실패하면 해당 백엔드가 작동 중지 된 것으로 표시되거나 작동 중지 된 것으로 간주됩니다.

요청별로 요청을 라우팅하는 Nginx 설정과는 매우 다른 논리입니다.

여기에 몇 가지 옵션이 있습니다.

캐싱 프록시로서의 Nginx
정적 컨텐츠에 Apps 서버 사용
CDN 사용

캐싱 프록시

HAProxy에서는 ACL을 사용하여 정적 컨텐츠 요청을 특정 백엔드로 라우트합니다. 이러한 백엔드 노드는 캐싱 프록시와 함께 nginx를 실행합니다. nginx에 파일이 캐시되어 있으면 파일을 제공합니다. 그렇지 않으면 백엔드를 호출합니다.

정적 컨텐츠에 앱 서버 사용

앱 서버가 정적 컨텐츠를 효율적으로 제공하는 경우 요청을 haproxy로 분할하지 않아도됩니다. 모든 요청을 애플리케이션 백엔드로 보내십시오. 가능한 경우 정적 컨텐츠를 제공하고 요청을 백엔드로 보내지 않을 경우 로직을 빌드하십시오.

CDN 옵션

정적 컨텐츠에 전용 도메인을 사용할 수 있으면 CDN을 사용할 수 있습니다. CDN에서는 응용 프로그램 노드에 대한 소스 URL을 가리 킵니다. 그런 다음 CDN 레벨에서 캐싱을 제어 할 수 있습니다. 이것은 CDN 제공자가 처리하는 것을 제외하고는 위의 Nginx 캐싱과 유사합니다.

— jeffatrackaid
소스