Jak skonfigurować kontrole kondycji ELB z wieloma aplikacjami działającymi na każdej instancji EC2?

W AWS chcemy używać ELB do równoważenia obciążenia wystąpień EC2, które obsługują wiele aplikacji. Idealnie chcielibyśmy mieć kontrolę stanu aplikacji.

Jednak usługi równoważenia obciążenia elastycznego AWS pozwalają obecnie na pingowanie tylko jednej lokalizacji w celu sprawdzenia kondycji.

Jaki byłby najlepszy sposób wdrożenia kontroli stanu za pomocą ELB, biorąc pod uwagę stan wielu aplikacji wdrożonych w każdej instancji EC2?

Oto dwa sposoby rozwiązania tego;

Pierwszą opcją jest dodanie kolejnej kontroli kondycji na hoście, która sprawdza poprawność kondycji i zwraca HTTP 200 do ELB, jeśli logika mówi, że chcesz utrzymać hosta w trybie online. Logika zależy oczywiście od ciebie. Wadą tego byłoby to, że jeśli aplikacja 2 zostanie pomyślnie wdrożona na niektórych hostach, wszystkie hosty nadal będą „zdrowe” i będą odbierać ruch.

Inną opcją jest użycie dodatkowego ELB dla każdej aplikacji. Możesz wskazać kilka ELB na te same instancje EC2 zaplecza, a koszt jest dość niewielki. W ten sposób możesz sprawdzać kondycję poszczególnych aplikacji i upuszczać hosty z problemami na poziomie aplikacji, zamiast podejścia typu „wszystko albo nic”.

Edycja: Pamiętaj, że jest to starsza odpowiedź i dotyczy ELB, a nie ALB. ALB obsługuje natywnie osobne cele na jednym hoście.

Można tu skorzystać z jednego ELB na aplikację.

Po pierwsze, możesz ich potrzebować, jeśli każda aplikacja jest w swojej własnej domenie i musisz obsługiwać SSL. Obecnie ELB Amazon zezwala tylko na jeden certyfikat SSL dla każdej domeny, wymagając osobnych ELB dla każdej domeny obsługującej SSL. (Certyfikaty Wildcard SSL są wyjątkiem).

Wyzwanie polega na tym, że testy kondycji ELB nie mogą obecnie być kierowane do konkretnej domeny wirtualnej hostowanej w instancji EC2. (Nie wysłano nagłówka „Host:”). Pingi zdrowia ELB zawsze przechodzą do domyślnej domeny, tak jakby załadowano adres IP dla wystąpienia EC2 w przeglądarce. Potrzebny jest więc trochę kleju, aby otrzymać kontrole kondycji w domenie domyślnej, a następnie odpowiedzieć ze statusem kondycji konkretnej aplikacji.

Oto działająca przykładowa konfiguracja, którą można dodać do serverdyrektywy Nginx . Zostałby zainstalowany na każdej instancji EC2 z równoważeniem obciążenia.

    # This goes in the `server` block noted by 'default_server', often /etc/nginx/sites-enabled/default

    # All AWS Health Checks from the ELBs arrive at the default server.
    # Forward these requests on the appropriate configuration on this host.
    location /health-check/ {
      rewrite ^/health-check/(?<domain>[a-zA-Z0-9\.]+) /api/v1/status break;
      # Lie about incoming protocol, to avoid the backend issuing a 301 redirect from insecure->secure,
      #  which would not be considered successful.
      proxy_set_header X-Forwarded-Proto 'https';
      proxy_set_header "Host" $domain;
      proxy_pass http://127.0.0.1;
    }

W ustawieniu „Sprawdzanie stanu” ELB dla „first-application.com” wybierz „HTTP” i port 80 i wprowadź ścieżkę:

/health-check/first-application.com

Przy powyższej konfiguracji Nginx działającej na hoście, żądanie zostanie odebrane w domenie domyślnej i proxy odpowiedź z konfiguracji Nginx na tym samym hoście dla https://first-application.com/api/v1/status

Przy takim podejściu nie ma konfiguracji dla aplikacji w Nginx. Tak długo, jak każda aplikacja ma unikalną nazwę domeny, musisz tylko odpowiednio skonfigurować ELB dla każdej aplikacji.

11 sierpnia 2016 r. Amazon wprowadził usługi równoważenia obciążenia aplikacji . Pozwalają one określić wiele grup docelowych, z których każda ma własny typ kontroli stanu. Jest to teraz możliwe przy użyciu jednego modułu równoważenia obciążenia!