WordPress na platformie Amazon AWS EC2 – cz.2

Jak uruchomić instancję EC2

Zaczynamy oczywiście od zalogowania się do konsoli AWS pod adresem: https://console.aws.amazon.com/console/home.

Po zalogowaniu w prawym górnym rogu warto wybrać w jakim regionie chcemy aktualnie operować. Najlepiej wybrać region geograficznie najbliższy miejscu, z którego spodziewamy się najwięcej ruchu. Dla Polski będzie to któryś z regionów europejskich, ja zdecydowałem się na Frankfurt. Następnie przechodzimy do panelu zarządzania usługą EC2, a w nim kliamy przycisk „Launch Instance”. Zostaniemy przeniesieni do kreatora dzięki któremu skonfigurujemy i uruchomimy nasz wirtualny serwer.

aws_console

Krok 1 – Wybór obrazu systemu (AMI)

Instancje działają w oparciu o Amazon Machine Image (AMI) czyli gotowe obrazy systemu. Do wyboru jest wiele różnych obrazów, niektóre nawet z preinstalowanym środowiskiem dla wordpressa i samym wordpressem. Warto zajrzeć do zakładek AWS Marketplace oraz Community AMIs, choćby po to żeby zobaczyć jak dużo różnych „gotowców” mamy do dyspozycji. Ja wybieram czysty obraz systemu w zakładce Quick Start. Tak jak pisałem w poprzedniej części tej serii, będę opierać się na dystrybucji Ubuntu Server 14.04 LTS (w czasie pisania tego tekstu jest to najświeższa wersja LTS).

ec2_wizard_step1

Krok 2 – Wybór typu instancji

Ponieważ po rejestracji nowego konta możemy przez rok za darmo korzystać z instancji t2.micro, na takiej też skupię się w tym tutorialu. Warto jednak zdawać sobie sprawę z ograniczeń jakie to za sobą niesie – jeśli spodziewamy się większego ruchu na naszym blogu, warto rozważyć uruchomienie mocniejszej instancji. Dokładną specyfikację i charakterystykę różnych typów wirtualnych serwerów dostępnych w usłudze AWS EC2 można znaleźć tutaj, a cennik tutaj.

Po wybraniu odpowiedniej opcji klikamy przycisk „Next: Configure Instance”.

ec2_wizard_step2

Krok 3 – Szczegółowe ustawienia

O ile to Twój pierwszy serwer, prawdopodobnie większość domyślnych opcji będzie dla Ciebie idealna. Nie będę omawiać każdego punktu z osobna – część opcji (jak na przykład ilość instancji) jest oczywista, część potrzebna jedynie w konkretnych okolicznościach i wykracza poza zakres tego cyklu. Chciałbym wspomnieć jedynie o dwóch opcjach, których znaczenie warto znać:

„Shutdown behavior” – wskazuje na sposób w jaki nasza maszyna zachowa się po wydaniu jej polecenia np.

sudo shutdown -h now

W przypadku ustawienia opcji „stop” instancja zostanie zatrzymana i będzie możliwe jej wznowienie w takim samym stanie w jakim została wyłączona w dowolnym momencie później. W czasie kiedy serwer „stoi” nie są naliczane opłaty za jego wykorzystanie – nie zużywa godzin pracy. Wznowienie może nastąpić zarówno po kilku minutach, tygodniach jak i miesiącach – nie ma to znaczenia.

W przypadku ustawienia opcji „terminate” instancja zostanie trwale usunięta. Zważywszy, że nasza maszyna pełnić będzie rolę serwera www raczej nie chcielibyśmy aby taka sytuacja się wydarzyła.

Druga opcja o której warto wspomnieć to „Enable termination protection”. Możemy manipulować stanem naszej instancji nie tylko po zalogowaniu się na nią przez SSH, ale również przykładowo z panelu sterowania w konsoli AWS. Tam możemy w każdej chwili usunąć naszą wirtualną maszynę. Aby zatem zapewnić sobie dodatkową warstwę ochrony przed przypadkowym usunięciem instancji warto zaznaczyć tę opcję.

ec2_wizard_step3

Krok 4 – Przestrzeń dyskowa

Żeby nasza maszyna mogła działać, potrzebna jest przestrzeń dyskowa, w której znajdzie się system i wszystkie nasze dane, np. pliki WordPressa. Domyślne ustawienie daje nam 8GB pamięci w ramach jednej partycji. W ramach bezpłatnego rocznego pakietu możemy użyć do 30GB przestrzeni, więc nic nie stoi na przeszkodzie aby zwiększyć ilość pamięci jeśli jest taka potrzeba. Możemy to zrobić także później, ale będzie wiązało się to z potrzebą wyłączenia serwera na kilka minut. Możemy też oczywiście dołożyć drugi i kolejne „dyski” żeby dla przykładu na jednym trzymać system, a na drugim bazę danych.

Ważną opcją jest opcja „Delete on Termination”. Ponieważ dyski z których korzystamy są wirtualne, możemy je stosunkowo łatwo odpinać i podpinać do poszczególnych instancji. W związku z tym nie zawsze chcemy, aby razem z usunięciem maszyny zostały usunięte nasze dane. W takim przypadku możemy odznaczyć omawianą opcję. Ponieważ jednak w poprzednim kroku upewniłem się, że nie usunę swojej instancji przypadkowo, zostawię tą opcję zaznaczoną. Nie chcę zachowywać wirtualnego dysku z systemem, a dane wordpressa łatwo mogę przenieść na inny dysk zanim ostatecznie usunę instancję. Gdybym w przyszłości zmienił zdanie, mogę zmienić tę opcję zgodnie z instrukcją opisaną tutaj.

Podsumowując: zostawiam wartości domyślne i przechodzę dalej.

ec2_wizard_step4

Krok 5 – Tagi

W tym kroku nie chodzi o nic innego jak o organizację. W przypadku pojedynczej instancji nie ma to wielkiego znaczenia. Kiedy jednak zarządzamy dużą ilością wirtualnych serwerów, tagi przydają się, aby łatwo odszukiwać zasoby, których szukamy (bo nie tylko wirtualne maszyny możemy tagować). Tagi tworzymy w postaci par klucz – wartość i możemy ich przypisać maksymalnie 10 dla każdego zasobu. Dla przykładu możemy nazwać nasz serwer w sposób, który będzie dla nas czytelny w przyszłości. Ja na potrzeby tego tutoriala otaguje swoją maszynę nazwą Test1.

ec2_wizard_step5

Krok 6 – Konfiguracja firewalla

W tym kroku ustawiamy reguły dla ruchu przychodzącego. Z punktu widzenia bezpieczeństwa jest bardzo ważne, aby otworzyć tylko te porty, które są nam niezbędne do działania. Ponieważ nasza instancja pełnić będzie rolę serwera www potrzebujemy otworzyć porty dla komunikacji HTTP i HTTPS. Dodatkowo chcielibyśmy móc zarządzać zdalnie naszym serwerem, a więc musimy otworzyć port również dla usługi SSH. Jeśli mamy stały adres IP lub będziemy łączyć się do serwera zawsze z jakiejś określonej puli adresowej (np. poprzez firmowy VPN), warto ograniczyć dostęp do SSH tylko dla naszego adresu / puli. Ponieważ moje domowe IP jest zmienne, zostawiam port 22 otwarty globalnie.

Ja nazwałem swoją grupę www-open-ssh, bo jest to nazwa która dosyć dobrze wskazuje na to, jakie reguły definiuje grupa. Można użyć dowolnej nazwy. Polskie znaki są niedozwolone (w opisie również).

ec2_wizard_step6

 

Krok 7 – Podsumowanie

Tak oto doszliśmy do ekranu podsumowania. Możemy jeszcze raz przejrzeć szczegóły konfiguracji. Jeśli jesteśmy zadowoleni ze wszystkich ustawień klikamy przycisk „Launch” i… prawie gotowe. 🙂 Zostało nam wygenerowanie pary kluczy, które posłużą nam do logowania się przez SSH zamiast hasła, co na ogół powinno być dużo bezpieczniejszą opcją. Musimy w jakiś sposób nazwać parę kluczy, które zostaną dla nas utworzone. Może to być dowolna nazwa. Dla mnie będzie to test1-keys. Po wpisaniu nazwy klikamy „Download Key Pair”. Zostanie pobrany klucz prywatny z nowo wygenerowanej pary, a klucz publiczny automatycznie dodany do naszej instancji. Jest jedyny moment, w którym możemy pobrać ten klucz. Nie będzie możliwości ponownego pobrania go później. Teraz możemy już kliknąć „Launch Instances”.

ec2_wizard_keys

Jeśli wszystko pójdzie dobrze, po przejściu do listy instancji w naszym panelu zarządzania powinniśmy zobaczyć działającą wirtualną maszynę.
Gratulacje! 🙂

Ostatnia rzecz którą warto zrobić, to pobranie „odcisków” kluczy SSH. Jeśli jesteśmy pewni, że nasz komputer jest bezpieczny i sieć, z której będziemy łączyć się do naszej instancji po raz pierwszy, jest bezpieczna, możemy pominąć ten krok. Nie kosztuje to jednak dużo wysiłku i dla pewności możemy to zrobić. Klikamy prawym przyciskiem na naszą instancję i z gałęzi „Instance Settings” wybieramy pozycję „Get System Log”.

ec2_wizard_keys_fingerprints_2

Pojawi nam się popup ze zrzutem komunikatów z konsoli naszej maszyny. Jeśli okienko jest puste oznacza to, że maszyna jeszcze nie wystartowała i musimy dać jej chwilę. Pierwsze uruchomienie trwa kilka minut. Na samym dole powinniśmy zobaczyć taką sekcję:

ec2_wizard_keys_fingerprints

Zapiszmy gdzieś te odciski kluczy, przydadzą się za chwilę podczas pierwszego logowania przez SSH. Zapraszam do kolejnej części.

Część 1
Część 3
Część 4
Część 5
Część 6
Część 7
Część 8

2 myśli na temat “WordPress na platformie Amazon AWS EC2 – cz.2”

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *