Strona Główna / Blog

8 Kroków Do Wdrożenia Aplikacji W Amazon Web Services

Sebastian Nowak

Sebastian Nowak

Wdrożenie Aplikacji w Amazon Web Services

Witajcie w pierwszej części krótkiej serii na temat wdrożenia w chmurze AWS. W niniejszym artykule opiszę jeden ze znanych mi sposobów na automatyczny deployment aplikacji w grupie auto skalowalnej, jak również poza nią.

Na potrzeby tekstu, zakładam że mamy już działającą przynajmniej jedną instancję EC2 wraz z grupą auto skalowalną i odpowiednim launch configiem. Na komputerze roboczym również posiadamy system z rodziny *nix (Linux, OS X, BSD, itp)

Plan jest taki:

  • Korzystamy z repozytorium systemu kontroli wersji GIT
  • Gałąź master posłuży nam jako wersja przeznaczona na produkcję
  • Na produkcji korzystamy z serwera www (nginx), dzięki któremu będziemy serwować naszą „skomplikowaną” aplikację w postaci index.html z kilkoma „fajerwerkami”
  • Całość będziemy przechowywać w buckecie na S3, z którego nasze instancje EC2 będą pobierać archiwum plików


Opisywany sposób wymaga użycia systemu Linux, zatem wykorzystam dystrybucję Ubuntu w wersji 14.04 LTS:

Deployment_w_AWS

Krok Pierwszy

Tworzymy bucket S3, w którym będziemy trzymać aplikacje gotowe do wrzucenia na produkcję:

Deployment w AWS 02

Trzeba pamiętać o tym, że przestrzeń nazw dla bucketów jest współdzielona między użytkownikami, dlatego też polecam stosowanie konwencji domenowej np: deployment.chmurowisko.pl. Nie musimy się martwić katalogiem projektu, zostanie on utworzony automatycznie podczas wysyłania plików.

Krok Drugi

Z menu w prawym górnym rogu ekranu (nazwa naszego użytkownika) wybieramy “Security Credentials”:

Deployment w AWS 03

Następnie przechodzimy do sekcji Access Keys, gdzie tworzymy nowy klucz:

Deployment w AWS 04

Uwaga: Istotnym jest aby odczytać/pobrać klucz zaraz po utworzeniu, gdyż po zakończeniu tego procesu nie będzie możliwości ponownego zobaczenia jego tajnej części! W razie zamknięcia okna, najlepiej usunąć klucz i wygenerować nowy.

Bezpieczeństwo: W powyższych krokach założyłem, że nie korzystamy z kont dostępowych z wykorzystaniem IAM i tworzymy klucze dla głównego użytkownika konta AWS, który posiada wszystkie uprawnienia. Najbezpieczniej byłoby utworzyć dedykowanych użytkowników i określić dla nich konkretny poziom uprawnień do S3.

Krok Trzeci

Logujemy się na serwer i instalujemy pakiet AWS CLI:

Na lokalnym komputerze powtarzamy czynność:

Klient AWS posłuży nam do wysyłania i pobierania danych z S3 z wykorzystaniem kluczy dostępowych. Powinniśmy teraz utworzyć konfigurację programu. W tym celu możemy skorzystać z wbudowanego konfiguratora.

Na EC2 (na potrzeby tego artykułu konfigurację utworzymy dla użytkownika root) uruchamiamy:

Na komputerze lokalnym:

Podajemy kolejno klucz dostępowy oraz klucz tajny. Następie odpowiedni region, zależnie od tego w którym posiadamy usługi oraz format, który może pozostać “None”.

Informacja: Listę regionów dla S3 znajdziesz tutaj

Program utworzy konfigurację w domyślnym katalogu użytkownika:

Informacja: Dlaczego root na EC2? Dlatego, że w systemie może wszystko a na tym właśnie opiera się koncepcja deploymentu, który musi mieć dostęp do plików i katalogów, nadać im odpowiednie prawa, uruchomić/zrestartować określone usługi.

Aby przetestować poprawność konfiguracji możemy wylistować zwartość naszego S3:

Więcej o korzystaniu z S3 w AWS CLI znajdziesz tutaj.

Krok Czwarty

Teraz, gdy już mamy działającego klienta S3 na serwerze i lokalnym komputerze, możemy przystąpić do napisania skryptów obsługujących deployment. Potrzebujemy ich do synchronizacji danych z bucketem oraz do konfiguracji aplikacji gdy uruchamia się nowy serwer w naszej grupie auto skalowalnej. Oto link do repozytorium GitHub.

Znajdziesz tam konfigurację serwera nginx, prostą stronę WWW, źródła skryptów do obsługi S3 jak również skrypt instalacyjny. Zapraszam do zapoznania się z zawartością. Pliki powłoki zawierają komentarze opisujące wykonywane czynności.

Uwaga: Konfiguracja nginx, którą zastosowałem, zakłada że nie posiadamy drugiego domyślnego serwera wirtualnego dla wpólnego interfejsu. Przyjrzyj się Twojej konfiguracji i dostosuj ją odpowiednio. W przypadku, gdy posiadasz świeżą instalację nginx usuń dowiązanie symboliczne do domyślnego pliku:

Krok Piąty

Aby zainstalować nasz projekt i uruchomić aplikację potrzebujemy dokonać odpowiedniej konfiguracji instancji, tak aby podczas staru systemu automatycznie uruchomił się proces deploymentu. Jednym ze sposobów jest dopisanie paru linijek do pliku:

Jest on uruchamiany na końcu procesu boot’owania systemu Linux. Oto jego zawartość (znajdziesz ją również w repozytorium):

Skrypt zostanie uruchomiony z prawami użytkownika root, pobierze skrypt setup.sh i go wykona. Setup ściągnie archiwum aplikacji, rozpakuje je, utworzy odpowiednie katalogi, nada uprawnienia, utworzy dowiązania symboliczne do najnowszej wersji projektu i wstawi informacje o instancji do wybranych plików.

Plik /etc/rc.local należy zmodyfikować bezpośrednio na instancji EC2, ponieważ za chwilę utworzymy obraz (AMI) serwera. Skrypt wykona się za każdym razem gdy maszyna będzie startować, czy to dzięki polityce skalowania, czy też ręcznie w konsekwencji naszych działań.

Krok Szósty

Utworzymy teraz obraz naszej instancji EC2, tak zwane AMI.

Nim jednak się tym zajmiemy, upewnijmy się, że wszystko co do tej pory wykonaliśmy działa jak należy. Wykonajmy zatem, na lokalnym komputerze:

Po zakończeniu przesyłania, na EC2:

Rezultatem powyższego powinno być uruchomienie procesu deploymentu. Jeżeli coś poszło nie tak, to teraz mamy szansę to naprawić studiując poprzednie kroki :)

Aby utworzyc obraz instancji zaznaczamy ją na liście i z menu ACTION wybieramy Image -> Create image:

Deployment_w_AWS_05

W oknie nazywamy odpowiednio nasz obraz i klikamy “Create image”:

Deployment_w_AWS_06

Instancja otrzyma polecenie restartu a AWS rozpocznie proces tworzenia obrazu:

Deployment_w_AWS_07

Należy uzbroić się w cierpliwość, zależnie od wielkości dysku jaki wybraliśmy może to potrwać kilka/kilkanaście minut. Proponuję aby poczekać do czasu aż obraz zostanie utworzony a następnie zterminować działanie instancji:

Deployment_w_AWS_08

Możemy teraz przystąpić do utworzenia konfiguracji dla grupy auto-skalowalnej. Jako, że nasza aplikacja będzie serwować stronę WWW, schowamy ją za Load Balancerem, zatem przechodzimy do sekcji EC2 -> Load Balancers i klikamy w “Create Load Balancer”:

Deployment_w_AWS_09

Nazywamy ELB (Elastic Load Balancer) według uznania i przechodzimy dalej:

Deployment_w_AWS_10

Dalsza konfiguracja może pozostać nie zmieniona:

Deployment_w_AWS_11

Wybieramy security grupę dla VPC/EC2 i klikamy na Continue.

Deployment_w_AWS_13

Pamiętajmy, aby security grupa umożliwiała dostęp do odpowiedniego portu dla naszych usług. W tym przypadku port 80, na który trafiać będą żądania z Load Balancera.

Na liście instancji EC2 nie dodajemy nic i przechodzimy dalej:

Deployment_w_AWS_14

Możemy otagować tworzoną usługę lub pozostawić pola puste:

Deployment_w_AWS_15

Na koniec powinno to wyglądać mniej więcej tak:

Deployment_w_AWS_16

Klik w “Create” i nasz Load Balancer powstaje do życia. Kliknijmy teraz na jego nazwę i skopiujmy do schowka wartość “DNS Name”:

Deployment_w_AWS_17

Krok Siódmy

Do poprawnego działania grupy auto-skalowalnej potrzebna jest konfiguracja uruchomieniowa. Przejdźmy więc do jej utworzenia:

Deployment_w_AWS_18

Po zapoznaniu się z procesem klikamy dalej:

Deployment_w_AWS_19

Z listy dostępnych AMI wybieramy własne i nasz świeży obaz:

Deployment_w_AWS_20

Następnie decydujemy się na rodzaj instancji, tutaj wykrzystam darmową instancję t2.micro:

Deployment_w_AWS_21

Po raz kolejny nazywamy usługę po naszemu i przechodzimy dalej:

Deployment_w_AWS_22

Zależnie od potrzeb ustalamy wielkość dysku dla serwera, ja zostawiłem maksymalne dla darmowej instancji 30GB:

Deployment_w_AWS_23

Teraz istotna rzecz, wybór grupy bezpieczeństwa oraz upewnienie się, że port 80 jest dostępny dla wszystkich lub przynajmniej dla Load Balancera:

Deployment_w_AWS_24

Na koniec ukaże się widok podsumowania, gdzie możemy przejrzeć wszystkie ustawienia i nacisnąć “Create launch configuration”.

Dodatkowo pojawi się okno z potwierdzeniem wyboru klucza SSH:

Deployment_w_AWS_25

Krok Ósmy

Po zakończeniu tworzenia konfiguracji uruchomieniowej automatycznie pojawi się kreator ustawień skalowania. Nazywamy grupę po swojemu, wybieramy podsieci VPC (o ile korzystamy), rozwijamy zakładkę “Advanced Details” gdzie włączamy obsługę Load Balancera, wybieramy uprzednio utworzonego i korzystami z opcji “monitorowania zdrowia” na podstawie danych z EC2:

Deployment_w_AWS_26

Nie będziemy zajmować się teraz sposobami na zarządzanie skalowaniem, więc na następnym ekranie zostawiamy domyślne zaznaczenie i klikamy “Review”, poczym na ekranie podsumowania wybieramy “Create Auto Scaling group”

Potwierdzenie utworzenia grupy pozwoli nam dostać sie do ich listy:

Deployment_w_AWS_27

Na liście grup powinniśmy po chwili zobaczyć zmianę dotyczącą ilości uruchomionych instancji EC2 dla wybranej konfiguracji:

Deployment_w_AWS_28

Przejdźmy do listy ELB i sprawdźmy co się tam dzieje:

Deployment_w_AWS_29

Jak widać powstała jedna instancja, została przypięta do Load Balancera, przeszła pomyślnie kontrolę stanu zdrowia i jest gotowa do pracy. Teraz możemy skorzystać ze schowka, do którego skopiowaliśmy adres hosta ELB. Otwórzmy nowe okno przeglądarki i sprawdźmy czy działa:

Deployment_w_AWS_30

Zgodnie z opisem w źródle sprawdzmy czy ID instancji zgadza się z faktycznym:

Deployment_w_AWS_31

Deployment_w_AWS_32

Dodatkowo zobaczmy jaki nagłówek zwraca nginx:

Deployment_w_AWS_33

Wszystko się zgadza? Gratulacje!

No dobrze, jak teraz sprawdzić co wydarzy się w przypadku skalowania? Najprościej będzie gdy wyedytujemy maksymalną liczbę instancji w konfiguracji grupy auto-skalowalnej:

Deployment_w_AWS_34

Deployment_w_AWS_35

Po wybraniu “Save” i kilku sekundach powinna pojawić się dodatkowa instancja w naszej grupie i zostać, podobnie jak pierwsza, przypięta do ELB:

Deployment_w_AWS_36

Deployment_w_AWS_37

Od teraz gdy będziemy odświeżać stronę aplikacji powinniśmy zauważyć zmieniające się dane zależnie, na którą z instancji trafimy:

Deployment_w_AWS_31Powyższy opis stanowi zlepek praktycznych doświadczeń podczas pracy z AWS oraz lektury.

Więcej na temat rozwiązań stosowanych w chmurze AWS możecie poczytać w powiązanych artykułach w powyższym serwisie.

Dołącz do listy mailingowej!

Dołącz do naszego newslettera

Staramy się wysyłać tylko wartościowe informacje, np. co miesiąc dostaniesz spis najważniejszych nowości z chmur Azure, AWS i GCP, z krótkimi opisami i linkami.