WordPress na platformie Amazon AWS EC2 – cz.6

Instalacja WordPress-a

W tej części zajmiemy się instalacją samego WordPress-a na wstępnie skonfigurowanym środowisku. Ja użyję w tym celu WP-CLI, czyli narzędzia służącego do zarządzania wordpressem z poziomu linii poleceń. Jest to bardzo wygodne narzędzie, jeśli jeszcze nie miałeś okazji się z nim zetknąć, to bardzo polecam!

W tej części zakładam, że posiadasz domenę pod którą będziesz chciał uruchomić swojego wordpressa. Konieczne będzie wpisanie do rekordu A Twojej domeny, adresu IP Twojej instancji. Pamiętaj, że taka zmiana może być widoczna dopiero po kilku, a nawet kilkunastu godzinach. Jeśli masz wątpliwości dotyczące tego jak przeprowadzić ten proces, skontaktuj się z usługodawcą u którego utrzymujesz domenę.

Apache Virtual Host

Na dobry początek pogrzebiemy jeszcze odrobinę w konfiguracji. W tej chwili nasz serwer skonfigurowany jest w taki sposób, że cały ruch kierowany jest do folderu /var/www/html. Możemy to jednak zmienić konfigurując tzw. wirtualny host. W ten sposób bazując na różnych kryteriach, możemy kierować osoby trafiające do naszej maszyny w różne miejsca. Najpopularniejszym sposobem rozstrzygania gdzie powinna trafić osoba konkretna osoba, jest adres strony wpisany w pasku przeglądarki. Możemy zatem dodać nową konfigurację dla naszej strony na wordpressie. Ja użyję domeny wordpress.marchel.it. Tworzymy plik konfiguracyjny (nazwa jest dowolna, ale musi kończyć się na .conf):

sudo nano /etc/apache2/sites-available/wordpress-marchel-it.conf

i uzupełniamy go następującą treścią:

O co tu chodzi?
VirtualHost otwiera blok w którym definiujemy wszystkie opcje dotyczące naszego wirtualnego hosta. Symbol gwiazdki oznacza, że sprawdzane są połączenia ze wszystkich adresów IP jakie ma przypisane serwer (w naszym przypadku jest to tylko jedno publiczne IP, ale może być ich wiele). Dwukropek jest separatorem, a liczba 80 to port dla usługi HTTP, na którym serwer oczekuje połączeń.
ServerName służy do identyfikacji że właśnie o ten wirtualny host pyta przeglądarka, zatem będzie to po prostu nasza domena.
ServerAlias daje nam możliwość zdefiniowania dodatkowych nazw naszego serwera. W powyższym przykładzie dodałem przedrostek www, dzięki czemu osoba które wpisze w przeglądarce adres z takim przedrostkiem, również trafi na odpowiednią stronę.
DocumentRoot służy do określenia głównego katalogu naszej strony. Ja wymyśliłem sobie ścieżkę /var/www/wordpress-marchel-it/public_html. Ścieżka to oczywiście musi istnieć, dlatego utwórzmy ją i nadajmy jej odpowiednie uprawnienia:

Pierwsze dwie linijki to oczywiście utworzenie folderów. W linijce trzeciej zmieniamy właściciela folderu public_html na www-data i przypisujemy ten folder do grupy www-data. Właścicielem plików musi być użytkownik, z prawami którego uruchamiane są skrypty PHP (w naszym przypadku www-data) – w innym przypadku nie będziemy mogli bezpośrednio instalować na przykład wtyczek.

Uwaga!
Jeśli uruchamiasz na jednym serwerze więcej niż jedną stronę, takie ustawienia mogą być potencjalnie niebezpieczne! W takim przypadku dla każdej aplikacji powinien zostać utworzony nowy użytkownik, z prawami którego będzie ona uruchamiana.

Ostatnia linijka to zmiana uprawnień folderu – możliwe do odczytu, zapisu i wykonywania dla właściciela i grupy.

Directory otwiera blok, w którym będziemy mogli skonfigurować różne opcje, dla podanej ścieżki.
Options daje nam możliwość włączenia lub wyłączenia dodatkowych funkcjonalności serwera. W tym przypadku wyłączamy opcję indeksowania katalogów – jeśli jakiś katalog nie ma pliku index, to jego zawartość nie zostanie wylistowania, zamiast tego zostanie zwrócony błąd 403 – dostęp zabroniony. Dodatkowo ustawiamy możliwość „podążania” za linkami symbolicznymi co będzie nam potrzebne do korzystania z przyjaznych linków (pretty urls) w wordpressie.
AllowOverride All daje możliwość nadpisywania ustawień serwera przy pomocy plików .htaccess, z czego WordPress korzysta.
Require All Granted pozwala wszystkim na dostęp do folderu, czego oczywiście potrzebujemy, jeśli chcemy opublikować stronę internetową.

Możemy zapisać tak utworzony plik. Za chwilkę do niego wrócimy.

Instalacja PHP-CLI oraz WP-CLI

Zainstalowana przez nas w poprzednim odcinku wersja PHP działa tylko przy współpracy z serwerem WWW. Nie mamy możliwości „ręcznego” wykonywania skryptów z konsoli. Ponieważ WP-CLI napisany jest w PHP, musimy zapewnić mu środowisko, w którym będzie mógł działać. Tym razem nie będzie żmudnej konfiguracji, ot po prostu jedna linijka:

sudo apt-get install php5-cli

Świetnie! Teraz pobierzmy WP-CLI, postępując zgodnie z instrukcją na stronie projektu. Warto przejść najpierw do swojego katalogu domowego, jeśli jesteśmy aktualnie w innej lokalizacji (można to zrobić wydając polecenie cd ~/)

Upewnijmy się, czy działa:

Teraz warto byłoby uczynić WP-CLI dostępne globalnie, dlatego musimy nadać mu uprawnienia do wykonywania oraz przenieść do folderu, który figuruje w zmiennej PATH.

Teraz wydanie polecenia wp --info powinno zwrócić taki sam wynik.

Utworzenie nowej bazy MySQL

Ostatnim krokiem przed przystąpieniem do instalacji samego wordpressa, jest utworzenie pustej bazy danych, z której nasz blog będzie korzystać. Zróbmy to zatem. Musimy zalogować się jako root do naszego serwera mysql. Robimy to wydając polecenie:

Co oznacza, że logujemy się jako root i zostaniemy zapytani o hasło, które wcześniej zdefiniowaliśmy w procesie instalacji.

Następnie wykonujemy 3 zapytania SQL:

Pierwsze tworzy bazę danych o nazwie db_name i kodowaniu utf8mb4. Bardzo dobre wytłumaczenie zawiłości tematu kodowania znaków można znaleźć tutaj.

Drugie przyznaje wszystkie uprawnienia do zarządzania bazą db_name użytkownikowi user_name, który autoryzuje się hasłem password. Jeśli taki użytkownik nie istnieje, zostanie utworzony.

Trzecie przeładowuje uprawnienia, tak dla pewności.

Następnie wychodzimy z konsoli mysql prostym poleceniem exit.

Czas na WordPress-a

Doszliśmy w końcu do momentu, o który przecież głównie chodzi w całym tym cyklu, czyli do instalacji WordPress-a. Tak jak wspomniałem wyżej użyjemy w tym celu WP-CLI. Mamy już utworzony folder, w którym znajdzie się nasza instalacja, więc przejdźmy do niego, w moim przypadku znajduje się on w /var/www/wordpress-marchel-it/public_html:

Teraz musimy pobrać pliki wordpressa:

Jeśli chcielibyśmy bliżej zapoznać się z jakimś poleceniem, możemy poprzedzić je słówkiem help, na przykład wp help core, czy wp help core download. W przypadku powyższego polecenia zostanie pobrana najnowsza wersja WordPress-a z pakietem językowym en_US. Jeśli chcielibyśmy pobrać inną wersję językową (na przykład Polską) możemy dodać parametr –locale=pl_PL

Teraz musimy wygenerować plik wp-config.php, w którym znajdą się między innymi dane dostępowe do utworzonej przed chwilą bazy danych. Musimy więc podać co najmniej nazwę bazy danych, nazwę użytkownika oraz hasło. Domyślnie dla tabel zostanie użyty prefix „wp_”, ale oczywiście możemy to zmodyfikować dodając odpowiednie argumenty.

Oczywiście w miejsce powyższych wartości należy podać te, które zostały użyte podczas tworzenia bazy.

Pozostało nam przeprowadzić proces instalacji, który utworzy tabele w bazie danych i ustawi dla nas kilka wartości, takich jak tytuł strony itp.

W polu URL podajemy adres pod jakim nasz blog będzie osiągalny – dla mnie jest to wordpress.marchel.it.
title to tytuł naszej witryny. Jeśli pojawią się w nim spacje musimy zamknąć go w cudzysłowach.
admin_user to pole w którym ustalamy jak będzie nazywał się nasz użytkownik.
admin_password ustala hasło dla użytkownika
admin_email to adres email, z którego korzysta wordpress dla celów administracyjnych.

W trakcie instalacji prawdopodobnie pojawiła się następująca informacja:

sh: 1: /usr/sbin/sendmail: not found

Oznacza to tylko tyle, że program służący do wysyłania wiadomości email nie jest zainstalowany w naszym systemie. Nie będę w tym tutorialu omawiać konfiguracji działania poczty w domyślny dla WordPress-a sposób. Zamiast tego proponuję użyć jednej z dostępnych wtyczek, pozwalających wysyłać pocztę za pośrednictwem protokołu SMTP. Ja korzystam z Easy WP SMTP. Konfiguracja sprowadza się do wpisania loginu i hasła dla naszego użytkownika poczty, oraz serwera przez który ma się odbywać komunikacja i sposobu szyfrowania tej komunikacji. Dokładnie to samo robimy konfigurując Outlooka, czy Thunderbirda.

Wszystko jest już gotowe. Zostało nam zatem włączyć konfigurację, którą przygotowaliśmy w pierwszym punkcie tej części i odwiedzić stronę w przeglądarce. 🙂

ec2_wordpress

Super! Udało nam się uruchomić WordPressa. W następnej części pokażę, że chociaż na pierwszy rzut oka wszystko jest w porządku, to jednak kilka rzeczy nie działa jeszcze tak jak powinno. Zajmiemy się też rozwiązaniem tych problemów.

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

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

  1. Mam pytanie. Po nadaniu chmod 770 katalogowi public_html nie mogłem nawet do niego wejść, a żeby uruchomić tam WP za pomocą WP-CLI musiałem zmienić prawa na 777. Tak powinno być czy to ja mam coś źle?

    1. Spróbuj dodać swojego użytkownika do grupy www-data. Rzeczywiście nie opisałem tego kroku w tutorialu, dopiszę to w wolnej chwili. Możesz to zrobić wydając polecenie:
      sudo usermod -a -G www-data twoj_login

      Żeby zmiany zaczęły obowiązywać prawdopodobnie będziesz musiał się wylogować i zalogować ponownie. Daj znać czy to pomogło. 🙂

      Pozdrawiam serdecznie! 🙂

      1. Tak, teraz działa dobrze. Dzięki! 🙂

        Tak w ogóle to super poradnik. Fajnie by było gdybyś napisał dalszą część o hardeningu i o stawianiu kilku stron na jednej instancji 🙂

        Masz doświadczenie z EC2? Czy ta najmniejsza instancja t2.micro nada się do kilku małych stron wordressowych, jak myślisz?

        1. Dzięki za dobre słowo. 🙂
          Tak, planowałem napisać jeszcze parę uzupełniających postów, ale pewnie raczej w formie pojedynczych artykułów niż konkretnego cyklu.
          Tak naprawdę ciężko odpowiedzieć na pytanie dotyczące tego ile jest w stanie uciągnąć jedna instancja micro. Pytanie jakiego ruchu się spodziewasz łącznie i na ile obciążające dla serwera będą te strony – czy na przykład nie będziesz w locie chciał obrabiać filmików wysyłanych przez użytkowników, albo coś w tym rodzaju. Tutaj http://hipsterdevblog.com/blog/2014/12/19/how-far-can-you-go-with-haproxy-and-a-t2-dot-micro/ jest jakiś test pokazujący ile jest w stanie udźwignąć t2.micro. Wprawdzie zastosowanie jest odrobinę inne, ale mimo wszystko jakieś wnioski można z tego wyciągnąć. 🙂
          Możesz też spróbować sam to przetestować którymś z tych (lub podobnych) narzędzi: http://codecondo.com/load-test-website-apps-online/

          Jeśli zdecydujesz się na robienie testów samodzielnie, to daj znać jakie otrzymałeś rezultaty. Sam jestem ciekaw! 🙂

Dodaj komentarz

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