Chmura publiczna kojarzy nam się między innymi z mocą obliczeniową, która możemy wydzierżawić od usługodawcy. Nie inaczej jest w przypadku AWSa, który również w swoim portfolio posiada usługę, o której mogliście już słyszeć, a mowa o serwerach EC2. W niniejszym artykule przybliżymy sobie czym jest owa usługa, opiszemy jej główne parametry, przedstawimy zastosowanie oraz tak jak w poprzednich wpisach przejdziemy krok po kroku proces uruchomienia serwera EC2, który będzie publicznie dostępny z internetu.
Czym jest serwer EC2 ?
Elastic Compute Cloud czyli w skrócie EC2 to nic innego jak wirtualny serwer typu VPS, który mamy możliwość uruchomić w infrastrukturze Amazon Web Services. EC2 może posłużyć m. in. jako serwer do hostowania aplikacji (serwer aplikacyjny), serwer do uruchomienia usług/narzędzi (np. instancja Jenkinsa, Gitlaba), serwer bazodanowy, bądź po prostu moc obliczeniowa wykorzystywana jako koparka kryptowalut. Uruchamiając serwer EC2 mamy możliwość wybrania maszyny z interesującymi nas parametrami, takimi jak ilość rdzeni procesor, wielkość pamięci operacyjnej, czy też przestrzeń dyskowa. Wraz z hardwarem maszyny wybieramy również system operacyjny (Linux/Windows), które jest nieodłącznym elementem EC2
Co jest potrzebne do uruchomienia serwera EC2 ?
Do uruchomienia serwera EC2 potrzebne jest przestrzeń sieciowa w AWS czyli VPC, gdyż każda instancja pracuje w ramach owej prywatnej sieci. W poprzednim artykule https://cloud-box.pl/aws-vpc-jak-utworzyc-data-center/ przeszliśmy oraz szczegółowo opisaliśmy sobie każdy z elementów VPC. Gorąco zachęcam do zapoznania się z owym artykułem, gdyż pokazane jest w nim jak przygotować sieć do uruchomienia serwerów EC2. Jeśli jednak to Cię nie przekonuje i zniechęca Cię obszerność artykuł, możesz również uruchomić serwer EC2 w ramach domyślnej sieci VPC, której komponenty są utworzone i skonfigurowane w każdym z regionów AWSa. Nie jest to jednak dobra i zalecana praktyka jeżeli planujemy robić coś więcej niż POC.
Uruchamiamy serwer EC2
Tak jak zawsze pierwszym krokiem jest zalogowanie się do konsoli AWS i wyszukanie interesującej nas usługi, tym razem jest to usługa EC2.
Na głównym dashboardzie mamy szereg funkcji związanych z wirtualnymi serwerami AWS. Z poziomu tego ekranu mamy możliwość nie tylko uruchomić serwer EC2 ale również skonfigurować Load Balancer, Auto Scaling czy też dodatkowy dysk dla naszej instancji czyli EBS. W tym artykule ograniczymy się jedynie do uruchomienia instancji EC2, pozostałe wspomniane przez mnie funkcjonalności z pewnością zostaną opisane i rozwinięte w późniejszych wpisach. Chcąc uruchomić wirtualny serwer przechodzimy do listy utworzonych instancji. Należy pamiętać, że tak samo jak VPC, serwery EC2 również są region–specific, co oznacza, że wybierając region w prawym górnym rogu, określamy lokalizację geograficzną, w której nasz serwer będzie hostowany. Ja wybrałem ten sam region, w którym wcześniej tworzyłem VPC, czyli Frankfurt.
Na ten moment lista naszych instancji jest pusta, klikamy więc Launch Instance aby przejść do wizarda, który poprowadzi nas przez proces konfiguracji serwera.
Pierwszym krokiem wizarda jest wybranie AMI czyli Amazon Machine Image. Jest to obraz systemu wirtualnego, na który składa się system operacyjny, sterowniki, zainstalowane narzędzia i oprogramowanie. Mamy tutaj możliwość wybrania spośród wielu obrazów dostarczonych przez AWS zarówno obrazy systemu Windows jak i wielu dystrybucji Linuxa. Jest też opcja skorzystania z AMI, które zostały przygotowane przez community zawierające np oprogramowanie open-source. W zakładce AWS Marketplace możemy za to znaleźć obrazy udostępniane przez firmy trzecie z zainstalowanym już autorskim oprogramowaniem owych firm, między innymi produkty SAP czy Cisco. My skorzystamy z obrazu Amazon Linux AMI 2018.03.0 (HVM) AMI, jest to przygotowany przez Amazona obraz systemu Linux (CentOS), który jest specjalnie dostosowany pod uruchamianie na nim aplikacji cloudowych. Obraz ten jest dostępny w ramach Free Tier co oznacza, że przez pierwsze 12 miesięcy korzystanie z konta AWS mamy możliwość korzystanie z serwera EC2 za darmo. Należy jednak zwrócić uwagę, że nie wszystkie obrazy i typy instalacji są dostępne w ramach Free TIer. Należy zwrócić na to uwagę przechodząc kroki wizarda. Poniżej wklejam link, z którego można dowiedzieć się więcej na temat AWS Free Tier
https://aws.amazon.com/free/?all-free-tier
Drugim krokiem wizarda jest wybranie typu instancji. Określamy na tym kroku wielkość naszego serwera czyli ilość rdzenia procesora oraz ilość pamięci operacyjnej. Serwery są pogrupowane w tak zwane rodziny. Mamy do dyspozycji wybranie spośród następujących rodzin:
- General Purpose – instancje ogólnego przeznaczenia ze zrównoważonymi parametrami. Najczęściej stosowane tam gdzie nie potrzebne jest specjalistyczne wysterowanie którejś z charakterystyk instancji np. Serwery WWW
- Compute Optimized – instancje, w których dominującym parametrem jest moc procesora. Instancje tej rodzina znajdują zastosowanie w miejscach gdzie wykonywane jest wiele obliczeń np. Transkodowanie mediów, uczeniu maszynowym, serwery gier.
- Memory Optimized – wysterowane w kierunku pamięci operacyjnej. Zostosowanie w przetwarzania dużej ilości danych w pamięci operacyjnej.
- GPU instances – rodzina instancji wykorzystująca procesory graficzne GPU do zwiększenia wydajności i przepustowości. Dedykowane do renderowania grafiki, kodowania wideo.
- Storage Optimized – instancje zoptymalizowane pod kątem pamięci dyskowej. Instancje z tej rodziny zaprojektowane są do pracy z obciążeniami które wymagają dużej ilości operacji zapisu i odczytu. Często stosowane jako instancje baz danych oraz hurtowni danych.
My do naszych zastosowań wybieramy instancje t2.micro, która jest dostępna w ramach Free Tier. Instancje typu T2 świetnie sprawdzają się jako serwery środowisk testowych. Przechodzimy do dalszego kroku klikając Configure Instance Details.
Trzeci krok wymaga od nas najwięcej konfiguracji. Idąc od góry mamy do skonfigurowania następujące parametry:
- Number of instances – liczba uruchomionych instancji. My ustawiamy jedną instancję
- Request Spot Instance – jest to opcja pozwalająca skorzystać z innego modelu płacenia za serwer niż On-demand. Instancja w trybie Spot to serwer, który może kosztować nas znacznie mniej nawet do 90%. Instancje takie uruchamiane są na niezagospodarowanej przez AWSa infrastrukturze. Wadą takich instancji jest to, że w przypadku gdy infrastruktura AWS będzie bardziej obciążona nasz instancje może zostać wyłączona w każdej chwili. Nie zaznaczamy tej opcji
- Network & Subnet – Jeśli skonfigurowaliśmy sami VPC to jest to miejsce gdzie należy je wskazać. Subnet wybieramy publiczny, czyli ten który ma bezpośredni route do IGW. Jeśli korzystamy z domyślnego VPC pozostawiamy owe opcje bez zmian.
- Auto-assign Public IP – ustawiamy jako Enabled. Dzięki tej opcji naszej instancji przypisany zostanie publiczny adres IP, który będzie osiągalny z internetu.
- Placement group – parametr umożliwiający zarządzanie rozmieszczeniem naszych instalacji w obrębie AZ. Pomijamy ten parametr ze względu na to, że uruchamiamy tylko jedną instancję.
- Capacity Reservation – możliwość rezerwacji odpowiedni ilości zasobów – również pomijamy.
- IAM Role – w tym miejscu mam możliwość przypisania roli, która ma możliwość nadania odpowiednich uprawnień naszej instancji. W przypadku gdy nasza instancja korzystałby z usługi S3 należałoby utworzyć IAM Role dla serwera EC2 i przypisać ją właśnie w tym miejscu. Jest to najlepsza praktyka nadawania uprawnień naszym instancją.
- Shutdown behavior – czy instancja ma być usuwana czy stopowana gdy będziemy ją wyłączać. Polecam zostawić stop, gdyż opcja terminate będzie oznaczać, że trwale zostaną skasowane wszystkie dane z naszej instancji w momencie jej wyłączenia
- Enable termination protection – zabezpieczenie przed omyłkowym usunięciem instancji
- Enable CloudWatch detailed monitoring – opcja ta włącza dokładniejsze metryki naszej instancji. Uwaga opcja dodatkowo płatna – zostawiamy nie zaznaczone
- Tenancy – podobnie jak z VPC również w przypadku serwera EC2 mamy możliwość uruchomienia go na dedykowanej dla nas infrastrukturze, co zapewnia stabilną pracę naszej instancji nawet w przypadku wysokiego obciążenia chmury. Pozostawiamy tą opcję z domyślną opcją “Shared” rezygnując z tej funkcjonalności, gdyż jest ona dość drogim rozwiązaniem.
- T2/T3 Unlimited – umożliwia aplikacją wykorzystanie większej możliwość CPU niż instancja ma zadeklarowane. Odznaczamy, gdyż jest to usługa również dodatkowo płatna.
- File systems – możliwość podpięcia dedykowanego file systemu w postaci usługi EFS. Taki file system może służyć jako współdzielony dysk wielu serwerów EC2.
Na powyższym zdjęciu dalsza część konfiguracji z trzeciego kroku wizarda. Tutaj istotnym parametrem jest pole User Data. W tym polu mamy możliwość wklejenia poleceń shellowych bądź skryptu, który zostanie wykonany zaraz po uruchomieniu instancji EC2. My w tym miejscu dodamy skrypt, który zainstaluje i uruchomi dla nas serwer http Apache 2.4 a następnie doda testową stronę html z naszą treścią. Poniżej treść skryptu, która należy wkleić w pole User Data
#!/bin/bash
yum update -y
yum install -y httpd24
service httpd start
chkconfig httpd on
cat <<EOF> /var/www/html/index.html
<html>
<body>
<h1> Cloud-box.pl</h1> <p> Hello world from EC2 </p>
</body> </html>
Czwartym krokiem wizarda jest konfiguracja pamięci masowej. Większość serwerów EC2 wymaga wykorzystanie EBS (Elastic Block Store) jako głównej partycji systemowej. Na tym ekranie mamy możliwość zdefiniować wielkość naszej głównej partycji, jej typ oraz również włączyć szyfrowanie naszego wolumenu. Do naszych potrzeb wystarczy w zupełności partycja o pojemności 8 GB typu General Purpose. Checkbox Delete on Termination zaznaczony mówi, że nasz EBS będzie usuwany wraz z usuniecie serwera EC2. Przechodzimy do kolejnego kroku klikając Add Tags.
W tym miejscu wizard pozwala oznaczyć naszą instalacje tagami czy meta informacjami, które w przyszłości pomogą nam przypomnieć w jakim celu dana zasób została stworzona i łatwo go odnaleźć. Przy dużej liczbie uruchomionych usług przyjęcie odpowiedniej strategii tagowania zasobów jest wręcz niezbędne. Ja dodałem dwa tagi określające cel utworzenia oraz nazwę projekt.
Jednym z ostatnich kroków jest skonfigurowanie Security Group dla instancji EC2. O SG opowiedzieliśmy już sobie w artykule, w którym tworzyliśmy VPC. Na poziomie VPC tworzyliśmy również wirtualnego firewall, który zabezpieczał ruch na poziomie podsieci (Network ACLs), drugim rodzajem zabezpieczenia są właśnie Security Groupy, gdzie mamy możliwość zdefiniowania reguł dostępu bezpośrednio przypisanych do serwera EC2. Domyślnie wszystkie porty naszej instancji są zamknięte, aby je otworzyć musimy przypisać odpowiednio skonfigurowaną Security Grupę. Tworząc SG mamy możliwość zdefiniowania jakie porty z jakich adresów IP będą otwarte. W naszym przypadku tworzymy nową SG, która będzie pozwalać na dostęp z internetu (0.0.0.0/0) na porcie HTTP (80) oraz SSH (22). Dzięki temu serwer www (apache) uruchomiony na naszej EC2 będzie dostępny z przeglądarki oraz również będziemy mieć możliwość zalogowania się do serwera za pomocą protokołu SSH. Tak utworzona Security Grupa może być przypisana do wielu serwerów EC2. AWS ostrzega nas, że taka konfiguracja nie jest bezpieczna, gdyż nasz serwer będzie publicznie dostępny dla każdego. Nie przejmujemy się tym ostrzeżeniem, gdyż w tym przypadku taki jest właśnie nasz cel.
Na ostatnim kroku wizarda widzimy pełne podsumowanie tego co udało się nam skonfigurować. Robimy szybkie review i klikamy Launch aby uruchomić serwer.
Jeszcze przed ostatecznym uruchomieniem serwera zostaniemy uraczeni ostatnim oknem dialogowym. W tym miejscu mamy możliwość utworzenia oraz pobrania publicznego klucza .pem, który pozwoli nam na zalogowanie się do serwera EC2 za pomocą SSH. Należy zapisać nasz klucz w bezpiecznym miejscu, gdyż nie będzie już innej możliwość jego pobrania.
Gotowe, konfiguracja EC2 zakończona. Teraz potrzebujemy kilku minut aż nasz instancja zostanie uruchomiona i jej status zmieni się na Running. W parametrach instancji musimy teraz odszukać dwa interesujące nas parametry Public DNS oraz Public IP. Te dwa parametry pozwolą nam dostać się do naszego serwera www uruchomionego na serwerze EC2. Po wklejeniu adresu domenowego bądź adresu IP do przeglądarki naszym oczom powinna ukazać się strona, która dodaliśmy do serwera www poprzez skrypt User data wklejony podczas konfiguracji
Jeśli w parametrach instancji pole Public DNS (IPv4) jest puste należy w konfiguracji VPC zaznaczyć opcję DNS hostnames na enabled (VPC -> Edit DNS hostnames ). Ostatnim krokiem jest sprawdzenie czy mamy możliwość zalogowania się do serwera przy użyciu SSH. W tym celu uruchamiamy terminal a następnie przechodzimy do katalogu, w którym zapisaliśmy wcześniej pobrany klucz .pem
Jeśli korzystasz z systemu operacyjnego z rodziny Unix (MacOS/Linux) możesz skorzystać z poniższej instrukcji
Na początku musimy edytować klucz aby był on wyłącznie do odczytu w tym celu zmieniamy jego prawa dostępu
chmod 400 cloud-box.pl.pem
Po tej operacji powinniśmy być już w stanie zalogować się owym kluczem wykorzystując poniższą komendę.
ssh -i cloud-box.pl.pem ec2-user@35.156.27.67 <- w tym miejscu wklej publiczne IP instancji
Domyślnym użytkownikiem dla serwerów EC2 zbudowanych z AMI Amazon Linux jest ec2-user. Możemy jednak po zalogowaniu do instancji bez problemu przełączyć się na użytkownika root.
Jeśli jednak korzystasz z systemu operacyjnego Windows odsyłam do instrukcji pod ten link
https://linuxacademy.com/guide/17385-use-putty-to-access-ec2-linux-instances-via-ssh-from-windows/
Tak oto w kilku krokach skonfigurowaliśmy i uruchomiliśmy nasz wirtualny serwer EC2 z Linuxem na pokładzie oraz z zainstalowanym serwerem www (Apache), który serwuje statyczną stronę i jest dostępny z internetu. Mając już tą wiedzę, możesz spokojnie pokusić się o zainstalowanie i serwowanie czegoś więcej niż statycznego kontentu, może to być np WordPress bądź inny aplikacji oparta o stack XAMP. Już niedługo na blogu pojawi się instrukcja jak skonfigurować serwer EC2 do tego aby deployować i uruchamiać na nim aplikację opartą o Spring Boota.
