Zarządzanie instancjami EC2

Transkrypt

1 Zarządzanie instancjami EC2 Celem zajęć jest zaznajomienie się ze sposobami definiowania instancji EC2 za pomocą obrazów (AMI), używaniem tych obrazów oraz zarządzaniem samymi instancjami z poziomu konsoli webowej AWS. Dodatkowo, poznamy instancje EC2 jako docelowe miejsce uruchamiania aplikacji i skonfigurujemy odpowiednie środowisko. Na zakończenie laboratorium należy wyłączyć wszystkie uruchomione instancje EC2. Instancje EC2 to podstawowe jednostki obliczeniowe w chmurze Amazon. Reprezentują one logiczny komputer z zainstalowanym systemem operacyjnym oraz posiadającym określone zasoby sprzętowe oraz sieciowe. Właściciel instancji, użytkownik AWS, może samodzielnie nią zarządzać oraz ponosi koszty jej działania. Koszty zależne są przede wszystkim od typu instancji określającego jej pojemność obliczeniową (moc obliczeniowa, ilość pamięci, dostępna przepustowość sieci) oraz od czasu jej działania. Oprócz tego możliwe są dodatkowe koszty wynikające z opłat licencyjnych uruchomionego oprogramowania systemowego oraz aplikacji. Konfiguracja i uruchamianie instancji Do konsoli AWS należy zalogować się używając adresu URL i imiennych danych dostępowych podanych przez prowadzącego. Proszę zwrócić uwagę, aby w przeglądarce nie były włączone funkcje zapamiętywania haseł. Widok konsoli po poprawnym zalogowaniu widoczny jest poniżej: strona 1 (10)

2 Pierwszym krokiem jest uruchomienie instancji EC2 poprzez AMI (Amazon Machine Image): Widok gotowych obrazów widoczny jest na kolejnej ilustracji. Ograniczmy się do darmowego zakresu: Możemy także zapoznać się z gotowymi obrazami dostępnymi w Amazon Marketplace i wspólnotowymi (community). Wybór systemu operacyjnego instancji jest drugorzędny, ponieważ na potrzeby zajęć wystarczy, że będzie na nim działał serwer aplikacji (np. Apache Tomcat). Dostępne są obrazy, na których serwer aplikacji jest już zainstalowany, jednak my przeprowadzimy instalację samodzielnie. Wybieramy AMI z Amazon Linux (pierwszy na liście) i na następnym ekranie zachowujemy zaznaczony wybór micro (instancje micro są darmowe przez pierwszy rok użytkowania w zakresie 750 godzin miesięcznie). strona 2 (10)

3 Przechodzimy do następnego ekranu zawierającego konfigurację szczegółów instancji: Nie zmieniające żadnych ustawień przechodzimy do kolejnego ekranu, pozwalającego na konfigurację mechanizmów magazynowania (dysków twardych). Tu także nie musimy niczego zmieniać: Kolejny krok to tagowanie instancji nadajmy jej po prostu rozpoznawalną nazwę: Na kolejnym ekranie (Security Group) konfigurujemy możliwości dostępu do instancji (firewall). Na zajęciach laboratoryjnych nie będziemy się skupiać na rzeczywistych aspektach bezpieczeństwa, umożliwimy natomiast podstawowe usługi, z których będziemy korzystać: SSH (port 22), ICMP (dowolny port dla ping), TCP (domyślny port 8080 dla HTTP, z którego korzysta Tomcat). strona 3 (10)

4 Ostatni krok sprawdzenie konfiguracji instancji i uruchomienie jej (przycisk Review and Launch). Jeżeli chcemy, zgadzamy się na sugestię użycia SSD (zamiast dysku fizycznego) do uruchamiania instancji: Zauważmy, że konsola AWS ostrzega, że nasza instancja jest otwarta na świat, co w produkcyjnych systemach jest raczej niezalecane. Ale na potrzeby ćwiczeń laboratoryjnych będzie to całkiem akceptowalne i ułatwiające nam pracę. Sprawdźmy też, czy na pewno mieścimy się w darmowym zakresie konfiguracji (ilustracja na następnej stronie). Sprawdźmy uważnie ustawione opcje konfiguracyjne i możemy w końcu uruchomić naszą nową instancję (Launch). strona 4 (10)

5 Ale to nie wszystko musimy posiadać parę kluczy pozwalających na zdalny dostęp do naszej instancji. Tworzymy nową parę, nazywając ją swoim imieniem i nazwiskiem: Utworzony plik.pem (nasze klucze prywatny i publiczny) będzie dostępny tylko w tej chwili, dlatego po pobraniu musimy zachować go w bezpiecznej lokalizacji (np. , prywatny dysk sieciowy), inaczej utracimy do niej dostęp. I w końcu uruchamiamy instancję jeżeli wszystko się udało, powinniśmy zobaczyć następujący ekran: strona 5 (10)

6 Sprawdźmy teraz uruchomione instancje EC2 i odnajdźmy naszą: Wybierzmy instancję i sprawdźmy jej status oraz monitorowanie: Używając publicznego adresu IP i nazwy domenowej (zakładka Description) możemy sprawdzić jej dostępność dla świata (na przykład prze ping): Wszystko działa? Publiczny IP i publiczna nazwa domenowa instancji przy bieżących ustawieniach będą zmieniać się przy każdym uruchomieniu instancji. Checkpoint 1: 5 pkt. strona 6 (10)

7 Połączenie z instancją przez SSH Potrzebne oprogramowanie (Java i Tomcat) zainstalujemy logując się do uruchomionej instancji przez SSH popularny klient dla systemów MS Windows to PuTTY. Używając publicznego IP/nazwy domenowej instancji logujemy się jako ec2-user. Aby było to możliwe, musimy użyć pobranego wcześniej klucza prywatnego (z pliku.pem). Jeżeli używamy wbudowanego klienta SSH (na przykład pod Linuksem), plik.pem wskazujemy następującym poleceniem: $ ssh -i /sciezka/do/pliku.pem ec2-user@<publiczny IP lub nazwa domenowa> Jeżeli korzystamy z PuTTY, musimy postarać się trochę bardziej. Przede wszystkim musimy wyciągnąć klucz prywatny (.ppk) z pliku pary kluczy (.pem) poprzez PuTTYgen: Wskazujemy plik.pem przez przycisk Load i podajemy zabezpieczające go hasło (passphrase), a następnie zapisujemy wyekstrahowany klucz prywatny (Save private key) z rozszerzeniem.ppk. Kiedy mamy już klucz prywatny, uruchamiamy PuTTY. W kategorii Connection/Data w polu Autologin username podajemy ec2-user. Dalej, w Connection/SSH/Auth podajemy ścieżkę do klucza prywatnego (.ppk) jako Private key for authentication. Wreszcie, w kategorii Session podajemy nazwę hosta (publiczny IP lub nazwa domenowa instancji), rozpoznawalną dla nas nazwę sesji i zapisujemy sesję, żebyśmy mogli z niej ponownie skorzystać: Uruchamiamy sesję przez Open. strona 7 (10)

8 Po poprawnym zalogowaniu (z dowolnego klienta) nasza instancja powita nas poprzez: _ ) _ ( / \ Amazon Linux AMI 18 package(s) needed for security, out of 42 available Run "sudo yum update" to apply all updates. [ec2-user@ip ~]$ Instalujemy ewentualne aktualizacje przez (zauważmy, że nasz użytkownik ma prawa roota): sudo yum update Instalacja Javy Java powinna być dostępna w naszym obrazie, sprawdźmy to przez $ echo $JAVA_HOME Powinniśmy zobaczyć ścieżkę: /usr/lib/jvm/jre I jeszcze zainstalowana wersja: $ java -version java version "1.7.0_71" OpenJDK Runtime Environment (amzn amzn1-x86_64 u71-b14) OpenJDK 64-Bit Server VM (build b04, mixed mode) Czyli wszystko w porządku. Instalacja Tomcata Sprawdzamy, czy dostępny jest Tomcat w wersji 7: $ yum info tomcat7 Wczytane wtyczki: priorities, update-motd, upgrade-helper Dostępne pakiety Nazwa : tomcat7 Architektura : noarch Wersja : Wydanie : 1.6.amzn1 Rozmiar : 93 k Repozytorium : amzn-updates/latest Podsumowanie : Apache Servlet/JSP Engine, RI for Servlet 3.0/JSP 2.2 API Adres URL : Licencja : ASL 2.0 Opis : Tomcat is the servlet container that is used in the official Reference : Implementation for the Java Servlet and JavaServer Pages technologies. : The Java Servlet and JavaServer Pages specifications are developed by : Sun under the Java Community Process. : : Tomcat is developed in an open and participatory environment and : released under the Apache Software License version 2.0. Tomcat is intended : to be a collaboration of the best-of-breed developers from around the world. Instalujemy go: $ sudo yum install tomcat7 Gdybyśmy potrzebowali skonfigurować Tomcata inaczej niż wersję domyślną, wystarczy użyć: strona 8 (10)

9 $ sudoedit /etc/tomcat7/tomcat7.conf Nam jednak powinny wystarczyć ustawienia domyślne. Uruchamiamy więc Tomcata jako usługę (service): $ sudo service tomcat7 start Starting tomcat7: [ OK ] Oczywiście, w miarę potrzeby, zatrzymujemy ją poprzez $ sudo service tomcat7 stop Czas na próbę połączenia z przeglądarki (Tomcat musi być uruchomiony), pamiętając, że domyślny port to 8080 (o ile nie zmieniliśmy go w konfiguracji). Czyli URL, na którym będzie widoczny Tomcat naszej instancji to IP lub nazwa domenowa>:8080. Ponieważ obecnie nie są zainstalowane żadne aplikacje ( goły Tomcat), powinniśmy otrzymać odpowiedź 404 (not found), ale będzie to oznaczało, że Tomcat działa. Doinstalujmy więc gotowe aplikacje Tomcata (m.in. administracyjną, przykłady, dokumentację): $ sudo yum install tomcat7-webapps tomcat7-docs-webapp tomcat7-admin-webapps W przeglądarce powinniśmy teraz zobaczyć stronę powitalną Tomcata: Jeżeli nie widzimy tej strony, sprawdźmy, czy Tomcat rzeczywiście jest uruchomiony i czy nasłuchuje na porcie 8080: $ sudo fuser -v -n tcp 8080 UŻYTKOWNIK PID DOSTĘP POLECENIE 8080/tcp: tomcat <pid> F... java Na koniec pozostaje jeszcze dodanie uruchamiania Tomcata do startu systemu (podczas uruchamiania instancji): $ sudo chkconfig --level 345 tomcat7 on strona 9 (10)

10 I sprawdzenie, czy polecenie zostało wykonane poprawnie: $ chkconfig --list grep tomcat tomcat7 0:wyłączone 5:włączone 6:wyłączone 1:wyłączone 2:wyłączone 3:włączone 4:włączone Checkpoint 2: 5 pkt. Zarządzanie instancją Powróćmy do konsoli webowej AWS i zobaczmy monitoring naszej instancji powinien być już widoczny ruch na poszczególnych wykresach: Zatrzymujemy instancję (lista Actions lub menu kontekstowe instancji), co kończy ćwiczenie laboratoryjne: Na zakończenie laboratorium należy wyłączyć wszystkie uruchomione instancje EC2. Checkpoint 3: 1 pkt. strona 10 (10)