WordPress na platformie Amazon AWS EC2 – cz.8

Podsumowanie serii

W tym cyklu wpisów za cel postawiłem sobie przekazanie informacji na temat tego, jak uruchomić WordPressa na platformie AWS EC2. Chciałem bardzo zachować balans pomiędzy jak najdokładniejszym przekazaniem tego co i dlaczego dzieje się w każdym kroku, a zwięzłością prezentowanych informacji. Czy mi się to udało? Mam nadzieję, że dostanę od Ciebie jakąś informację zwrotną w postaci komentarza. Postaram się wziąć pod uwagę Twoją opinię przy publikacji kolejnych wpisów.

Co udało się zrobić?

  • Uruchomiliśmy nową instancję EC2
  • Wykonaliśmy podstawową konfigurację naszego systemu
  • Porozmawialiśmy chwilę o bezpieczeństwie
  • Zainstalowaliśmy Apache-a, PHP-FPM i MySQL
  • Wspomnieliśmy o WP-CLI, stworzyliśmy nową bazę MySQL i zainstalowaliśmy WordPress-a.
  • Zobaczyliśmy co i dlaczego nie działa oraz naprawiliśmy występujące problemy.

To całkiem sporo! 🙂
Muszę jednak powiedzieć, że ten cykl pominął wiele kwestii. Nie rozmawialiśmy o dalszej optymalizacji, nie poruszyliśmy tematu kopii zapasowych, czyli backup-ów, wersjonowania, a o temat bezpieczeństwa zaledwie się otarliśmy. Jeśli uruchomiony w ten sposób system chcemy wykorzystać produkcyjnie, to przed nami jeszcze trochę pracy, ale to wykracza już poza zakres tego cyklu, dlatego nie będę dalej rozwijał tego tematu. Poniżej przedstawiam listę haseł do wygooglowania. Tak jak pisałem we wstępie: jeśli po przeczytaniu tej serii wiesz jak można zrobić coś lepiej, albo masz inną opinię na jakiś temat, to zostaw swój komentarz! Ja też cały czas się uczę i chętnie skorzystam z Twojego punktu widzenia! 🙂

Wesołego blogowania. 🙂

Do poczytania / wygooglowania:

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

WordPress na platformie Amazon AWS EC2 – cz.5

Apache, PHP, MySQL

Do uruchomienia wordpressa będziemy potrzebować kilku dodatkowych narzędzi. Po pierwsze musimy zainstalować serwer, który będzie oczekiwał na żądania z przeglądarek użytkowników i zwracał im gotowe strony. W tej roli wystąpi Apache. Ponieważ wordpress napisany jest w PHP, potrzebujemy zainstalować interpreter tego języka. Na koniec konieczna jest instalacja serwera baz danych bez której nasz blog nie będzie działał. WordPress zaprojektowany jest aby współdziałać z MySQL, dlatego też taką bazę musimy zainstalować.

Instalacja Apache

W celu zainstalowania apache-a musimy połączyć się z naszą instancją przez SSH, a następnie wykonać następujące polecenie:

sudo apt-get update && sudo apt-get install apache2

Tak jak opisywałem w poprzedniej części sudo apt-get update spowoduje pobranie informacji o najnowszych dostępnych wersjach pakietów z repozytorium ubuntu. Operator && oznacza: „jeśli polecenie po lewej stronie wykona się poprawnie wykonaj polecenie po prawej stronie”. Część sudo apt-get install apache2 uruchamia instalację pakietu apache2.

Po tej operacji wpisanie w przeglądarce adresu IP naszego serwera, powinno dać nam taki wynik jak poniżej, co oznacza, że nasz serwer działa. 🙂

ec2_apache

Przed przejściem dalej warto upewnić się, że nasz apache używa modułu mpm-events, a nie mpm-prefork. Jest to podyktowane wydajnością. U mnie ten moduł był domyślnie zainstalowany i włączony po instalacji apache-a. Możesz to sprawdzić przy pomocy komendy, która wypisze wszystkie aktywne moduły:

sudo apache2ctl -M

W razie potrzeby możesz doinstalować ten moduł:

sudo apt-get install apache2-mpm-event
sudo a2enmod mpm_event
sudo service apache2 restart

Instalacja PHP

W repozytorium ubuntu 14.04 najnowsza wersja PHP nosi numer 5.5.9. Jeśli chcielibyśmy zainstalować nowszą wersję, np. 5.6.x konieczne będzie skorzystanie z dodatkowych repozytoriów.

Przejdźmy zatem do instalacji. Tak jak zaznaczyłem na początku tej serii, będę chciał skorzystać z PHP5-FPM. Wybór ten podyktowany jest głównie wydajnością. Tutaj można przeczytać porównanie mod_php i php-fpm. Wydajemy polecenie:

sudo apt-get install php5-fpm

Żeby taka instalacja PHP chciała współpracować z apachem musimy doinstalować do niego dodatkowy moduł. Ze względu na zawiłości licencyjne, jest on dostępny w repozytorium multiverse, które domyślnie jest wyłączone, więc najpierw musimy je włączyć. O różnicach między repozytoriami można poczytać tutaj. Otwórzmy w ulubionym edytorze tekstowym plik /etc/apt/sources.list (ja korzystam z nano)…

sudo nano /etc/apt/sources.list

… i odkomentujmy odpowiednie linijki (adresy URL mogą różnić się w zależności od regionu):

ec2_sources

Po zapisaniu zmian w pliku możemy już wydać polecenia:

sudo apt-get update
sudo apt-get install libapache2-mod-fastcgi

Po instalacji moduł powinien zostać automatycznie włączony, a apache zrestartowany.

ec2_fcgi

Jeśli tak się jednak nie stało, zawsze możemy przeprowadzić aktywację modułu i restart serwera ręcznie wydając następujące polecenia:

sudo a2enmod fastcgi
sudo service apache2 restart

UWAGA!
Jeśli miałeś wcześniej zainstalowane mod_php, musisz je wyłączyć. Możesz to zrobić w analogiczny sposób:

sudo a2dismod php5
sudo service apache2 restart

Przed nami jeszcze odrobina konfiguracji. Zakładam, że na naszej instancji będzie uruchomiona tylko jedna witryna, zatem przedstawiona poniżej konfiguracja jest prawdopodobnie najprostszą z możliwych. Zacznijmy od włączenia jeszcze dwóch modułów, które będą nam potrzebne:

sudo a2enmod alias actions
sudo service apache2 restart

Teraz musimy stworzyć plik konfiguracyjny, który powie apache-owi co powinien zrobić z plikami PHP. Wszystkie pliki konfiguracyjne przechowywane są w folderze /etc/apache2/conf-available, dlatego tam też stworzymy nasz plik. Ja nazwę go php5-fpm.conf. Możemy to zrobić na przykład przy pomocy nano:

sudo nano /etc/apache2/conf-available/php5-fpm.conf

Następnie umieszczamy w nim następują treść:

Krótkie wyjaśnienie dla chętnych 🙂
IfModule sprawdza czy moduł jest aktywny i jeśli jest, wykonuje polecenia zawarte w bloku.
AddHandler powoduje, że dla podanych rozszerzeń plików wykonywana będzie zadana akcja – w tym przypadku dla plików .php, wykonana zostanie akcja „php5-fcgi”.
Action definiuje program do którego zostanie przesłane żądanie, kiedy zostanie wykonana akcja – w tym przypadku dla akcji php5-fcgi żądanie zostanie skierowane na ścieżkę /php5-fcgi
Alias służy do mapowania ścieżek – w tym przypadku definiujemy, że ścieżka /php5-fcgi z poprzedniej linijki, to tak naprawdę /usr/lib/cgi-bin/php5-fcgi
FastCgiExternalServer wskazuje w jaki sposób obsłużyć plik, który złapaliśmy powyższymi linijkami – w tym przypadku zostanie on wykonany przez serwer nasłuchujący na gnieździe unixowym na ścieżce /var/run/php5-fpm.sock. Ta ścieżka jest zdefiniowana w pliku konfiguracyjnym php-fpm. Możesz to sprawdzić – znajdziesz go tutaj: /etc/php5/fpm/pool.d/www.conf. Opcja -pass-header daje nam możliwość przekazania do skryptu nagłówków HTTP, które normalnie nie zostałyby przekazane, np. ujętego w powyższej konfiguracji nagłówka Authorization.
Directory określa ścieżkę, którą obejmą ustawienia zdefiniowane w bloku
Require all granted pozwala na odczyt lokalizacji przez wszystkich – musimy dodać tą linijkę, w innym wypadku zamiast efektów działania dowolnego skryptu PHP zobaczymy w przeglądarce odmowę dostępu.

Nie pozostało nam nic innego, jak zapisać konfigurację, włączyć ją i przetestować czy wszystko działa. Zapisujemy plik, wychodzimy z edytora, wydajemy polecenia:

sudo a2enconf php5-fpm
sudo service apache2 reload

Teraz utwórzmy plik php, dzięki któremu przetestujemy to, co do tej pory zrobiliśmy. Domyślna konfiguracja apache-a kieruje nas na ścieżkę /var/www/html, więc tam też utworzymy nasz plik:

sudo nano /var/www/html/info.php

o treści:

Po zapisaniu pliku przechodzimy pod adres naszego serwera – w moim przypadku będzie to: http://52.29.70.252/info.php. Powinniśmy zobaczyć znajomą stronę PHP Info. 🙂

ec2_phpinfo

Instalacja MySQL

Teraz będzie już z górki. Uruchamiamy instalację serwera MySQL i modułu php, który będzie używany do komunikacji z bazą danych. Wydajemy polecenie:

sudo apt-get install mysql-server php5-mysql

W trakcie instalacji zostaniemy poproszeni o utworzenie hasła dla głównego użytkownika (root) naszej bazy danych. Możemy je wprowadzić teraz, albo zostawić pole hasła puste. Za chwilę wrócimy do tego kroku.

Po zakończonej instalacji uruchamiamy skrypt, który przygotuje do działania naszą bazę, między innymi stworzy odpowiednią strukturę folderów.

sudo mysql_install_db

Na koniec uruchamiamy skrypt, który przeprowadzi nas przez kilka kroków prowadzących do lepszego zabezpieczenia naszego serwera.

sudo mysql_secure_installation

W pierwszym kroku zostaniemy zapytani o aktualne hasło dla użytkownika root. Jeśli ustawiliśmy je podczas instalacji, wpiszmy je teraz. Jeśli nie, naciskamy po prostu enter.

Drugi krok to ustawienie hasła roota. Jeśli mamy już hasło, w tym kroku możemy je zmienić.

Krok trzeci pozwala nam na usunięcie anonimowego użytkownika, czyli możliwości logowania się bez faktycznego posiadania konta. Oczywiście usuwamy.

W kroku czwartym możemy określić, że użytkownik root może zalogować się tylko z komputera, na którym uruchomiony jest serwer (localhost). Potwierdzamy wyłącznie zdalnego logowania.

W kroku piątym możemy usunąć bazę ‚test’, która domyślnie jest utworzona na etapie instalacji i jest dostępna dla wszystkich. Potwierdzamy chęć usunięcia.

Ostatnim etapem jest przeładowanie tabeli uprawnień. Potwierdzamy.

Uff… Dobrnęliśmy do końca. Mamy już prawie wszystko, czego potrzebujemy do uruchomienia naszego wordpressa. Do zobaczenia w następnym odcinku. 🙂

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

WordPress na platformie Amazon AWS EC2 – cz.4

Jak uczynić naszą instancję bezpieczniejszą?

Informacje tutaj zawarte nie są z pewnością kompendium wiedzy na temat bezpieczeństwa i nie taki też miał być cel tego artykułu. Chcę jednak pokazać kilka podstawowych czynności, które uważam za pewne minimum w kontekście bezpieczeństwa naszego Linuxa. Muszę podkreślić, że to Ty masz pełną kontrolę nad swoją instancją i to do Ciebie należy zadbanie o bezpieczeństwo przechowywanych przez Ciebie danych, oraz bezpieczeństwo osób, które będą odwiedzać Twoją stronę. Zdecydowanie zachęcam do zdobywania wiedzy w temacie administracji serwerem.

Aktualizacje

Jedną z najistotniejszych czynności jest regularna aktualizacja systemu i zainstalowanego oprogramowania. Niestety błędy zdarzają się wszędzie (głośny przykład błędu w bibliotece OpenSSL z 2014 roku), dlatego powinniśmy jak najszybciej instalować wszelkie pojawiające się aktualizacje bezpieczeństwa. Zanim ruszymy dalej, upewnijmy się zatem, że nasz system jest aktualny.

Niektórzy zauważyli pewnie, że po zalogowaniu na naszą instancję, zostaliśmy przywitani takim (liczby mogą się różnić) komunikatem:

ec2_updates

Oznacza to ni mniej, ni więcej jak to, że od czasu wydania tej wersji dystrybucji pojawiło się „trochę” różnych aktualizacji, z czego w moim przypadku 56 to aktualizacje bezpieczeństwa. Naprawmy to zatem. 🙂

Na początek wydajemy polecenie:

sudo apt-get update

W ten sposób upewniamy się, że system „wie” o wszystkich aktualizacjach, które powinien zainstalować. W tym momencie nic jeszcze nie jest instalowane. Pobierane są jedynie informacje o możliwych zmianach.

Następnie możemy wydać polecenie:

sudo apt-get upgrade

lub

sudo apt-get dist-upgrade

Jest pomiędzy nimi zasadnicza różnica. W pierwszym przypadku zaktualizowane zostaną jedynie pakiety już zainstalowane. Często jednak jest tak, że jeden pakiet zależy w jakiś sposób od innych. Jeśli nowsza wersja już zainstalowanego oprogramowania zależy od pakietu z którego wcześniej nie korzystała i nie jest on obecny w systemie, aktualizacja danego pakietu nie dojdzie do skutku. Wszystkie informacje o problemach zostaną wypisane w konsoli.

W przypadku drugiego polecenia zależności rozwiązywane są automatycznie i różne pakiety mogą zostać usunięte lub doinstalowane. W chwili obecnej nie ma to dla nas wielkiego znaczenia, bowiem maszyna przed chwilą została uruchomiona i do niczego jej jeszcze nie używamy. Kiedy jednak uruchomimy już serwer www, bazę danych i nasza strona będzie dostępna publicznie, nie chcielibyśmy, aby po wykonaniu aktualizacji nagle coś przestało działać. Nie oznacza to oczywiście, że mamy nie aktualizować naszego systemu. Oznacza to jedynie, że zawsze musimy wiedzieć co i dlaczego robimy. Jako pewnego rodzaju zabezpieczenie warto rozważyć uruchomienie środowiska stage-owego i przetestowanie modyfikacji na nim, zanim zdecydujemy się na aktualizację środowiska produkcyjnego, tym bardziej że duplikacja instancji EC2 jest bardzo prosta.

Co bardziej dociekliwi zauważyli pewnie, że pomimo zainstalowania wszystkich aktualizacji, OpenSSL o którym wspominałem przed chwilą pozostał w wersji 1.0.1f czyli teoretycznie podatnej na atak HeartBleed. Jest to jednak nieprawda. Wersja ta została załatana przez opiekunów Ubuntu w dniu upublicznienia podatności. Więcej informacji tutaj.

Na koniec tej części warto zrestartować naszą maszynę:

sudo reboot

Po wydaniu tego polecenia nasze połączenie zostanie przerwane. Odczekajmy minutę lub dwie i spróbujmy połączyć się ponownie.

Zmiana domyślnego portu usługi SSH

Warto rozważyć zmianę domyślnego portu SSH z 22 na jakiś inny losowy numer powyżej 1023. Wiele botów używanych do ataków automatycznych poszukując otwartego portu SSH ogranicza się do sprawdzenia domyślnego portu dla tej usługi. Nie ograniczy to wszystkich prób włamania, ale odsieje przynajmniej część z nich. Zmiany portu możemy dokonać w pliku konfiguracyjnym usługi SSH. Musimy edytować go jako użytkownik uprzywilejowany, wydajemy więc polecenie:

sudo nano /etc/ssh/sshd_config

Oczywiście zamiast nano można użyć swojego ulubionego edytora tekstu. 🙂

Odszukujemy w pliku linijkę

Port 22

i zmieniamy wartość portu na jakąś inną wartość, np.

Port 56321

ec2_custom_ssh_2

Zapisujemy zmiany (w nano naciskając ctrl+O i potwierdzając enterem), a następnie zamykamy edytor (w nano ctrl+X). Pozostało nam teraz zrestartować SSH przy pomocy polecenia:

sudo service ssh restart

Nasze aktualne połączenie nie zostanie zerwane, ale od tej chwili każde nowe połączenie do naszego serwera musi odbywać się na porcie wpisanym do pliku konfiguracyjnego. Zanim będzie to możliwe, musimy otworzyć ten port na naszym firewallu. Wracamy więc do przeglądarki i panelu zarządzania EC2.

W grupie „Network & Security” odnajdujemy zakładkę „Security Groups”, a następnie klikając na naszą grupę prawym przyciskiem myszy wybieramy opcję „Edit inbound rules”. Teraz w miejsce SSH wybieramy „Custom TCP Rule” i podajemy numer wybranego wcześniej portu, zatwierdzając na końcu zmiany przyciskiem „Save”.

ec2_custom_ssh

Powinno być już możliwe nawiązanie nowego połączenia. Jeśli łączymy się z konsoli musimy dodać parametr „-p” i dopisać po nim numer portu, a więc w moim przypadku będzie to:

ssh -i ~/.ssh/test1-keys.pem ubuntu@52.29.70.252 -p 56321

Jeśli łączymy się przy pomocy putty na liście zapisanych połączeń wybierzmy odpowiednie, wczytajmy ustawienia przy pomocy przycisku „load”, zmieńmy numer portu i ponownie zapiszmy profil połączenia.

ec2_custom_ssh_3

Podsumowanie

Po tej części nasz system jest w pełni aktualny, a SSH działa na innym niż domyślny porcie. Tak jak wspominałem nie gwarantuje to oczywiście 100% bezpieczeństwa i warto zainteresować się różnymi narzędziami, które mogą nam pomóc w „utwardzaniu” (hardening) naszego systemu, oraz w wykrywaniu potencjalnych zagrożeń. W następnej części przejdziemy do instalacji oprogramowania niezbędnego do działania naszej maszyny w charakterze serwera www.

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

WordPress na platformie Amazon AWS EC2 – cz.3

Jak dostać się do mojej instancji, czyli ciąg dalszy konfiguracji

W poprzednim odcinku uruchomiliśmy naszą wirtualną maszynę, pora obejrzeć ją „od środka”. W tej części przypiszemy jej Elastic IP, czyli publiczny adres pod którym maszyna będzie osiągalna przez internet. Podłączymy się także przez SSH używając pobranego uprzednio klucza prywatnego.

Jak przypisać Elastic IP

Każda uruchomiona przez nas instancja ma „w pakiecie” możliwość przypisania jej jednego publicznego IP. Taki adres jest przypisany bezpośrednio do naszego konta i możemy go odpinać i podpinać do różnych instancji wedle potrzeb. Jedna maszyna może mieć też wiele publicznych adresów IP jeśli z jakiegoś względu potrzebujemy takiej konfiguracji. W ten sposób przypisany adres jest zarezerwowany dla nas, dopóki nie zdecydujemy się oddać go do puli wolnych adresów. Teoretycznie nasza instancja już w trakcie uruchomienia ma nadany publiczny adres, jednak nie jest on w żaden sposób związany z naszym kontem i w przypadku zatrzymania maszyny zostaje on uwolniony, a po ponownym uruchomieniu nadawany jest nowy adres.

W przypadku serwera www zdecydowanie chcemy, aby nasz adres był stały, raz na zawsze taki sam, a w przypadku potrzeby rozwoju i przeniesienia się na mocniejszą instancję, aby była możliwość łatwego przepięcia tego samego adresu na nową maszynę. Na szczęście proces ten jest banalnie prosty. 🙂

W naszym panelu zarządzania EC2 odnajdujemy po lewej stronie zakładkę „Elastic IPs” i przechodzimy do niej. Tam klikamy przycisk Allocate New Adress i potwierdzamy nasz wybór.

ec2_elastic_ip

Następnie klikamy na prawym przyciskiem myszy na naszym IP i wybieramy akcję „Associate Address”. Możemy też zaznaczyć nasze IP i wybrać tą opcję z górnego, rozwijanego menu „Actions”. Po kliknięciu w pole Instance powinna nam się wyświetlić lista dostępnych maszyn, z której możemy wybrać naszą nowo utworzoną instancję lub wyszukać ją po wcześniej przypisanym tagu „Name”. Po wybraniu instancji klikamy przycisk „Associate”.

ec2_elastic_ip2

Po przejściu do listy instancji powinniśmy zobaczyć, że nowy adres został faktycznie nadany naszej maszynie.

 Łączymy się przez SSH

Przyszedł czas, żeby w końcu zalogować się do konsoli naszego serwera.

Linux / Mac

Jeśli pracujesz na Linuxie lub Mac-u dodaj po prostu pobrany klucz do swojego folderu .ssh w katalogu domowym, np. tak:

mv /sciezka/do/twojego/klucza.pem ~/.ssh

Jeśli nie masz takiego folderu, utwórz go wydając polecenie:

mkdir ~/.ssh

Klucz prywatny powinien mieć bardzo restrykcyjne ustawienia uprawnień dostępu. Ustawmy je zatem na 400 (dostępne tylko do odczytu tylko przez właściciela pliku).

chmod 400 ~/.ssh/twoj_klucz.pem

W tej chwili powinno być już możliwe podłączenie się do Twojej instancji. Domyślną nazwą użytkownika dla dystrybucji Ubuntu jest… ubuntu. W moim przypadku pobrany klucz prywatny znajduje się w pliku test1-keys.pem w folderze .ssh, a adres IP mojego serwera to 52.29.70.252. Wydaję więc następujące polecenie:

ssh -i ~/.ssh/test1-keys.pem ubuntu@52.29.70.252

Zapisałem wcześniej odcisk klucza pobrany z logów serwera, więc mogę zweryfikować teraz, czy na pewno łączę się ze swoją instancją. Jeśli tak, potwierdzam chęć połączenia. Od tej chwili mój komputer „zna” już moją wirtualną maszynę i przy każdym kolejnym połączeniu nie będzie konieczne ponowne porównywanie „odcisku”. Jeśli wszystko poszło dobrze, to właśnie zalogowałeś się do swojej instancji. Gratulacje! 🙂

ec2_ssh_login

Windows

Jeśli pracujesz na Windowsie, konieczne będzie skorzystanie z dodatkowych narzędzi. Przede wszystkim Windows nie obsługuje SSH (choć być może niedługo coś zmieni się w tej materii – więcej informacji tutaj). Ja jako klienta SSH używam i polecam fantastycznego PuTTY. Dodatkowo niestety nie możemy wykorzystać klucza prywatnego w takiej postaci w jakiej go pobraliśmy – konieczne będzie przerobienie go na format obsługiwany przez PuTTY przy pomocy narzędzia PuTTYgen, do pobrania stąd.

Otwieramy PuTTYgen i wczytujemy pobrany wcześniej klucz klikając przycisk „Load”. Następnie zapisujemy klucz prywatny przyciskiem Save private key. Zostaniemy zapytani czy na pewno chcemy zapisać klucz prywatny, który nie jest chroniony żadnym hasłem. Na zabezpieczanie kluczy hasłem poglądy są różne. Tutaj można poczytać ciekawą dyskusję na ten temat. Każdy musi podjąć tą decyzję samodzielnie, ja nadmienię jedynie, że jeśli klucz nie jest zabezpieczony hasłem (przy czym powinno być to mocne hasło) to potencjalny włamywacz po odczytaniu pliku z kluczem może dostać się do waszej instancji. Ja na potrzeby tego tutoriala nie dodaję hasła do swojego klucza.

ec2_puttygen

Gdzie zapisać utworzony w ten sposób klucz? Ja poszedłem drogą „linuksową” i w katalogu swojego użytkownika stworzyłem folder .ssh, ale może być to dowolne inne miejsce. Należy jednak pamiętać o tym, że jeśli komputer współdzielimy z innymi osobami, warto umieścić klucz w miejscu niedostępnym dla innych użytkowników.

Pozostało nam użyć PuTTY do zalogowania się do naszej maszyny. Nazwa użytkownika w dystrybucji Ubuntu to domyślnie ubuntu, a adres mojego serwera to 52.29.70.252 W polu Host Name wpisuję zatem ubuntu@52.29.70.252. Następnie rozwijam z lewej strony gałąź SSH, a w niej klikam na zakładkę „Auth”. Dodaję plik z moim wygenerowanym przed chwilą kluczem prywatnym.

ec2_putty

Pozostało mi zapisać ustawienia tej sesji, aby nie musieć wprowadzać tego samego w przyszłości.

ec2_putty2

Po kliknięciu przycisku Open powinniśmy dostać monit informujący, że komputer do którego próbujemy się podłączyć nie jest znany. Jeśli zapisaliśmy wcześniej „odciski” kluczy, możemy zweryfikować czy są one zgodne. Jeśli tak, potwierdzamy chęć połączenia i po chwili powinniśmy być już zalogowani na naszej wirtualnej maszynie. Przy następnym połączeniu weryfikacja nie będzie już konieczna. Gratulacje! 🙂

ec2_ssh_login_win

Podsumowanie

Mamy więc ustanowione połączenie SSH z naszą instancją EC2. Jesteśmy zatem coraz bliżej uruchomienia naszego wordpressa. W następnej części zajmiemy się odrobinkę konfiguracją naszego serwera, aby korzystanie z niego było bezpieczniejsze.

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

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

WordPress na platformie Amazon AWS EC2 – cz.1

Wstęp

Tym wpisem rozpoczynam cykl artykułów dotyczących uruchomienia WordPressa na platformie EC2 Amazonu. Będę starał się opisywać krok po kroku co i dlaczego robię. Wszystkie sugestie dotyczące tego jak można coś zrobić lepiej lub szybciej są bardzo mile widziane, w końcu człowiek uczy się całe życie. Zapraszam do komentowania. 🙂

Założenia

Większość osób prawdopodobnie ma zestaw narzędzi, których lubi używać. Jedni wolą taką dystrybucję linuksa, drudzy inną. Jedni wolą apache-a, drudzy nginx-a. Nie będę się z tym spierać, nie uważam też, że któreś rozwiązanie jest obiektywnie najlepsze we wszystkich przypadkach. Ja zamierzam użyć:

  • Ubuntu 14.04 Server (w czasie pisania tego tekstu jest to najświeższa wersja LTS)
  • Apache2
  • PHP-FPM
  • MySQL

Zakładam, że masz już swoje konto Amazon AWS, więc przejdę od razu do pierwszego kroku, czyli uruchomienia instancji EC2.

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