Wdrażanie ręczne a Amazon Elastic Beanstalk

Jakie korzyści uzyskujemy dzięki zastosowaniu Elastic Beanstalk w porównaniu z ręcznym tworzeniem instancji EC2 oraz konfigurowaniem serwera Tomcat i wdrażaniem itp. Dla typowej aplikacji internetowej Java. Czy równoważenie obciążenia, monitorowanie i automatyczne skalowanie to jedyne zalety?

Załóżmy, że dla mojej aplikacji internetowej korzystającej z bazy danych zainstalowałem bazę danych w samej instancji EC2. Kiedy nastąpi automatyczne skalowanie, czy baza danych zostanie utworzona w nowo utworzonej instancji, czy też będzie uzyskiwać dostęp do bazy danych utworzonej przeze mnie w instancji głównej ... Jeśli utworzy tylko replikę podczas automatycznego skalowania, w jaki sposób nastąpi synchronizacja danych między instancjami?

Wszystkie rzeczy, o których wspomniałeś, takie jak równoważenie obciążenia, monitorowanie i automatyczne skalowanie, są zdecydowanie zaletami.

Trzeba jednak pomyśleć o tym w ten sposób: w prawdziwej platformie jako usłudze (PAAS) celem jest oddzielenie aplikacji od platformy. Jako programista martwisz się tylko o swoją aplikację. Platforma jest „wynajęta”. „Instancje” platformy są automatycznie aktualizowane, administrowane, skalowane, równoważone itp. Za Ciebie. Po prostu przesyłasz plik WAR i po prostu działa (przynajmniej teoretycznie).

Samo EC2 nie jest PAAS. Bardziej przypomina IAAS ( Infrastructure as a Service ). Nadal musisz dbać o instancje serwerów, instalować na nich oprogramowanie, aktualizować je itp.

Elastic Beanstalk to system PAAS. Podobnie jak App Engine i Azure, wśród wielu innych.

W prawdziwym systemie PAAS DBMS jest oddzielnym komponentem od serwera (serwerów) aplikacji internetowych. Powód jest oczywisty: DBMS nie może być prawdopodobnie zainstalowany na instancjach, które są używane przez serwer aplikacji, ponieważ w miarę tworzenia i niszczenia instancji na podstawie Twojego ruchu, DBMS zostałby utracony! Posiadanie DBMS i serwera aplikacji na tej samej maszynie / instancji nie jest i tak ogólnie dobrym pomysłem.

W systemie PAAS DBMS jest oddzielną usługą. W przypadku Amazon byłby to Amazon RDS . Podobnie jak w przypadku Elastic Beanstalk, gdzie nie musisz martwić się o serwer aplikacji i po prostu przesyłasz plik WAR, dzięki RDS nie musisz martwić się o DBMS i po prostu wdrażasz swoje bazy danych.

Elastic Beanstalk i RDS współpracują ze sobą bardzo dobrze, zwłaszcza gdy są wdrożone w tej samej strefie dostępności, gdzie opóźnienia byłyby bardzo niskie.

Wreszcie, użycie Elastic Beanstalk nie kosztuje nic więcej niż wdrożone zasoby (instancje EC2 i load balancer). Jednak RDS nie jest tani i na pewno byłby droższy niż użycie jednej instancji EC2 zarówno dla serwera aplikacji, jak i dla DBMS.

Elastic Beanstalk to coś więcej niż tylko równoważenie obciążenia, monitorowanie i skalowanie automatyczne.

1) Zarządza wersjami aplikacji, przechowując różne wersje aplikacji i zarządzając nimi, umożliwiając łatwe przełączanie się między różnymi wersjami aplikacji.

2) Posiada koncepcję „środowisk” dla każdej aplikacji, co umożliwia wdrażanie różnych wersji aplikacji w każdym środowisku. Jest to przydatne na przykład, jeśli chcesz skonfigurować oddzielne środowiska QA i DEV i chcesz łatwo wdrożyć najpierw kompilację w DEV, a następnie wdrożyć tę samą wersję aplikacji w QA, gdy zespół QA jest gotowy do następnej kompilacji.

3) Przekazuje ważne właściwości konfiguracyjne kontenera (na przykład ustawienia pamięci Tomcat) do konsoli Elastic Beanstalk i interfejsu API. Dzięki temu można łatwo zapisać ustawienia i kopiować je między środowiskami.

4) Przeglądaj pliki dziennika aplikacji za pośrednictwem konsoli i automatycznie przewijaj i archiwizuj pliki dziennika do S3. (Trzeba przyznać, że ta funkcja jest obecnie trochę słaba).

Miałem aplikację wdrożoną zarówno w dedykowanym środowisku EC2 (Nginx i Gunicorn), jak i środowisku Beanstalk (CentOS i Apache2).

Moje spostrzeżenia:

• BeanStalk to Paas. Ręczne tworzenie instancji EC2 (IAAS) przypomina robienie wszystkiego od zera, ale masz pełną kontrolę.

• BeanStalk jest domyślnie wyposażony w CentOS i Apache (Httpd). Możesz wybrać system operacyjny w dedykowanej instancji.

• Te rzeczy, które się dla mnie liczyły,

  • W środowisku Beanstalk pojawiło się wiele błędów 504.
  • Trudno było debugować, gdy nastąpiła awaria serwera BeanStalk, ponieważ logi również nie pojawiały się i nie mogły ssh do komputera. To jest bardzo ważne.
  • Instalowanie / konfigurowanie narzędzi takich jak Celery, Redis (trzeba uruchomić inny port) itp.,. w dedykowanym przypadku jest o wiele łatwiejsze.

• W moim przypadku musiałem przeskalować serwer w górę (Beanstalk), aby uruchomić instalację niektórych pakietów (np. Pandoc). Te rzeczy są prostsze w Ubuntu.

• Skalowanie jest znacznie łatwiejsze w BeanStalk. Klonowanie serwerów jest proste w BeanStalk.

• Wziąłem mikro w obu przypadkach (dedykowany i Beanstalk). Czułem, że dedykowana mikro instancja była lepsza.

• Zautomatyzowane wdrażanie w Beanstalk. Musiałem napisać skrypty, aby zautomatyzować to samo, co jest w porządku, ponieważ jest to tylko raz.