Jaki laptop do pracy?

Ostatnio w moim laptopie umarł dysk SSD. Ot tak, Windows rzucił bluescreen-em, a potem już się nie podniósł. Próby reanimacji na nic się zdały, podłączanie dysku do innego komputera również – w BIOSie widoczny był jedynie kontroler pamięci flash. Po dłuższym czytaniu zasobów internetu okazało się, że to wcale nierzadka przypadłość tego typu nośników i one tak po prostu mają, że potrafią nagle, bez ostrzeżenia przestać działać. No trudno – pomyślałem – ostatecznie strata niewielka, backup wszystkich istotnych danych miałem. Najbardziej szkoda mi było czasu włożonego w konfigurację środowiska developerskiego.

Do tej pory zwykłem pracować na Windowsie i wspierać się Linuxem uruchomionym w VirtualBox-ie. Do prostszych operacji oczywiście nie chciało mi się za każdym razem startować wirtualnej maszyny, więc zainstalowałem xampp-a. No ale skoro tak, to i obsługa git-a by się przydała w Windowsie. No, a jak już jest obsługa git-a, to w sumie czemu by nie pójść dalej – dołóżmy do tego wp-cli, gulp-a (więc i node.js by się przydał). Pliki przecież też wygodniej jest edytować w głównym systemie, więc i jakieś IDE, albo „fajniejszy” edytor warto byłoby zainstalować. No i oczywiście jakiś klient FTP i SSH. Ktoś może powie, że w sumie to samo trzeba zrobić na każdej platformie. To prawda, ale w tym przypadku nie dość, że robię to podwójnie (choć oczywiście do VirtualBox-a można zapisać sobie z grubsza gotowy obraz systemu), to jeszcze w Windowsie dojście do porozumienia z niektórymi narzędziami nie jest rzeczą trywialną.

Ponieważ miałem jakiś stary dysk z innego laptopa postanowiłem włożyć go w zastępstwie. Stwierdziłem też, że potrzebuję podnieść swój komputer dosyć szybko, więc zdecydowałem się tymczasowo zainstalować Ubuntu, a kiedyś w wolnej chwili wrócić do Windowsa. Zgodnie z przewidywaniem poszło sporo szybciej – wystarczyło pół godziny w konsoli żeby zainstalować prawie wszystko czego potrzebowałem do pracy. Czy zatem Linux rozwiązał wszystkie moje problemy i nie wrócę już do „złego” Windowsa? Cóż… niezupełnie.

O ile większość typowo developerskich narzędzi zainstalowałem i uruchomiłem bez najmniejszego problemu, o tyle z dodatkowymi aplikacjami do których przywykłem nie poszło już tak łatwo. Weźmy na pierwszy ogień Google Drive-a. Na dzień dzisiejszy wciąż brak oficjalnego klienta, który umożliwiałby bezproblemową synchronizację. Są oczywiście różne inne rozwiązania, ale chciałoby się, żeby to po prostu działało. Kolejnym przykładem jest Photoshop. Można spróbować go uruchomić przy pomocy WINE-a, ale nie jest to rozwiązanie idealne. Można też oczywiście pójść w kierunku Windowsa w VirtualBoxie, ale nadal wolałbym po prostu natywną aplikację na Linuxa, co raczej nie wydarzy się prędko, jeśli w ogóle. Kolejnym przykładem jest Spotify. Wprawdzie na oficjalnej stronie da się znaleźć informację na temat tego jak uruchomić klienta na Linuxie, ale towarzyszy temu notka:

Here you can find a build of Spotify for Linux. We are running this ourselves and we will try to make sure it keeps pace with its Mac and Windows siblings. However, this version is unsupported. – https://www.spotify.com/pl/download/linux/

W praktyce klient działa, ale niektóre funkcje są niedostępne – nie mogę na przykład sterować odtwarzaniem z innego urządzenia.

Nigdy nie rozumiałem dlaczego każdy developer którego spotykam (no… prawie każdy) korzysta z Mac-a. Ja na ogół miałem alergię na produkty Apple, ale chyba zaczynam się przekonywać. Oczywiście nie rozwiązałoby to problemu padniętego dysku. OSX rozwiązałby natomiast chyba wszystkie problemy konfiguracyjne, o których pisałem powyżej, choć dorzuciłby z pewnością kilka własnych. Nie przymierzam się w tej chwili do kupna komputera i prawdopodobnie stan ten nie ulegnie zmianie przez najbliższych parę lat, ale kiedy już przyjdzie czas na odświeżenie sprzętu, bardzo poważnie zastanowię się nad omijanym dotychczas Mac-iem.

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.7

Czego WordPress potrzebuje do życia?

WordPress korzysta z różnych dodatkowych modułów apache-a i PHP. Niestety w oficjalnej dokumentacji brak na ten moment informacji o tym co jest potrzebne do działania niektórych funkcjonalności. Można znaleźć w sieci opracowania na ten temat, ale mają one już ładnych kilka lat. W tej części pokażę kilka funkcjonalności WordPressa, które nie działają w naszym środowisku i powiem jak sobie z tym poradzić.

Przyjazne linki

Na początek, spróbujmy włączyć obsługę przyjaznych linków (pretty URLs). To pomaga nam uczynić adresy URL bardziej czytelnymi i przyjaznymi dla SEO naszego bloga. Zalogujmy się zatem do panelu administracyjnego, przejdźmy do zakładki Ustawienia->Bezpośrednie odnośniki (Settings->Permalinks). Tam wybierzmy którąś z wersji, która nam odpowiada. Po zapisaniu ustawień przejdźmy do strony głównej i spróbujmy kliknąć w tytuł wpisu. Ups…

Problemem w tej sytuacji jest wyłączony moduł przepisywania linków w naszym apache-u. W takim razie włączmy go:

Tak znacznie lepiej. 🙂

ec2_wordpress_permalinks2

wp_mail

W poprzedniej części pisałem o tym, że nasz WordPress nie jest w stanie wysyłać e-maili i o wtyczce pozwalającej wysyłać je za pośrednictwem SMTP. Zainstalujmy ją z naszego panelu administracyjnego. Oczywiście możemy też użyć do instalacji WP-CLI, albo wrzucać pliki ręcznie. Zanim jednak przejdziemy do instalacji samej wtyczki, doinstalujmy do PHP jeszcze jeden moduł. Nie jest on niezbędny w tej chwili, bo WordPress już od jakiegoś czasu umie sobie radzić bez niego, ale niektóre wtyczki mogą bez niego nie działać.

Zainstalujmy teraz wtyczkę Easy WP SMTP (lub inną o tej samej funkcjonalności) i skonfigurujmy ją tak samo jak konfigurowalibyśmy klienta pocztowego takiego jak Outlook czy Thunderbird.

ec2_smtp

Ta wtyczka posiada możliwość wysłania testowego e-maila, z czego warto skorzystać, żeby upewnić się, że wszystko działa jak należy. Jeśli korzystasz z innej wtyczki, która nie ma takiej funkcji, możesz spróbować na przykład zmienić hasło dla swojego użytkownika. Powinno to spowodować wysłanie wiadomości e-mail z informacją o zmianie hasła na adres przypisany do konta.

Skalowanie i kadrowanie obrazków

Kiedy do biblioteki mediów w WordPressie wrzucamy obrazek, dostajemy w efekcie z automatu kilka rozmiarów do wyboru. Dodatkowo mamy możliwość korzystania z wbudowanego, prostego edytora grafiki, który pozwala nam na przykład wykadrować obrazek. Tak przynajmniej być powinno, bo w tej chwili przy próbie włożenia obrazka do treści posta mamy do dyspozycji jedynie pełny rozmiar.

ec2_wordpress_image_size

Dzieje się tak z powodu brakującego modułu PHP o nazwie imagick. Zainstalujmy go. Przy okazji zainstalujemy też moduł GD. Wprawdzie WordPressowi wystarczy imagick, ale niektóre wtyczki mogą korzystać do obróbki grafiki właśnie z modułu GD.

Teraz po wrzuceniu nowego obrazka powinniśmy mieć możliwość skorzystania z automatycznie wygenerowanych rozmiarów, oraz korzystania z wbudowanego edytora.

ec_wordpress_image_size2

Dodatkowe moduły

Wykorzystywanym czasem w różnych wtyczkach modułem jest mcrypt. Skoro zatem jesteśmy jeszcze na etapie konfiguracji, doinstalujmy go przy okazji.

Taki zestaw rozszerzeń powinien zapewnić bezproblemowe działanie w większości przypadków.

To już właściwie wszystko w tej serii. W następnej (i ostatniej zarazem) części krótkie podsumowanie tego, co udało nam się zrobić oraz kilka końcowych uwag i wskazówek.

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

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

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