 Cześć! Sky is not the limit, czyli ten WordPress w chmurze to dopiero początek naszej zabawy z WordPressem. Opowiem wam dzisiaj troszkę czym jest chmura, jakie są wady i zalety chmury w zderzeniu z klasycznym hostingiem i w użyciu z WordPressem, jak tego WordPressa w chmurze zainstalować, a na koniec jak tą chmurę utrzymać i przy tym wszystkim nie zwaliować. Na początek nie ma chmury, są tylko inne komputery, ale technologia zwana chmurową pozwala nam wydzielać konkretne zasoby, wydzielać ile chcemy mieć procesora, ile chcemy mieć ramu, ile chcemy mieć dysku. Ostatnio też te technologie pozwalają wydzielać siły obliczeniowe pod sztuczną inteligencję, więc nie jesteśmy tutaj ograniczeni sprzętowo, fizycznie, ogranicza nas tylko to, ile dostawca usługi pozwala nam maksymalnie użyć zasobów dla jednej, dla pojedynczej usługi. W zderzeniu z takim klasycznym hostingiem, na którym głównie teraz hostujemy WordPressa, no to przy takim klasycznym hostingu wielu użytkowników dzieli ten sam system operacyjny, więc tam są możliwe eskalacje uprawnień, tam są możliwe obciążenia samego systemu przez jednego z użytkowników. Tak samo pojedynczy server hostingowy ma ten sam adres IP, działa w tej samej sieci. W przypadku, no i płacimy za server hostingowy pewną średnią, nieważne czy tam hostujemy jeden plik, czy mamy coś bardzo obciążającego, co w ramach naszego pakietu, ale jednak działa przez większość czasu i obciąża ten hosting, płacimy tyle samo. W przypadku rozwiązania chmurowego korzystamy z tego samego fizycznego zasobu, procesora, dysku, czy czegoś innego, ale w sposób zwirtualizowany, tak jak byśmy korzystali z WPSa, z tą różnicą, że możemy sobie wybrać, czy chcemy mieć gigabyte, czy gigabyte i 100 megabyte w ramu, bo to wszystko jest bardzo elastyczne. Płacimy za te zasoby, które rezerwujemy i za te zasoby, z których korzystamy, czyli rozliczamy się tak naprawdę w większości usług chmurowych godzinowo. I przede wszystkim chmura pozwala nam się rozlokować geograficznie na całym świecie, pozwala nam tą infrastrukturę przenieść do Stanów, do Australii, do Singapuru, gdzie tylko chcemy, no ale wada jest niestety taka, że trzeba tą infrastrukturę w chmurze utrzymać, trzeba ją skonfigurować i trzeba się w tym wszystkim nie pogubić. World Press w chmurze, jakie ma wady i zalety? Przede wszystkim pierwsza zaleta najbardziej podstawowa to jest upscaling, czyli możliwość przygotowania się na promocję Karpia, czy inną akcję reklamową, na Black Fridaye, możemy tak naprawdę jednym kliknięciem sobie zwiększyć ilość ramu, czy procesora, czy tego co nam klienci najbardziej obciążą. De facto jest to realizowane poprzez load balancer, za którym dopiero jest serwer, działający na tych zasobach w chmurze, więc musimy sobie tego WordPressa na takim serwerze zainstalować. I są różne szkoły, możemy mieć tych serwerów. Wiele upscaling może polegać na tym, że dokładamy nowe serwery, może polegać na tym, że podmieniamy mniejszy serwer większym, natomiast przy spotkaniu z WordPressem trzeba pamiętać, że WordPress nie zapisuje pliki na serwerze, na dysku. Dopóki nie podepniemy dysku sieciowego, chmurowego, WordPress będzie korzystał tylko z tej jednej instancji, więc może się zdarzyć tak, że wrzucimy zdjęcie, ale tego zdjęcia nie ma, bo w tym momencie load balancer próbuje je odczytać z innego urządzenia. Tak samo wszystkie zmiany wprowadzane ręcznie w plikach na serwerach, wszystkie hotfixy, w przypadku hostowania WordPressa w chmurze, to znika przy każdej edycji naszej maszyny. I uruchamiany jest WordPress z jakiegoś obrazu, o tym oczywiście decydujemy, czy to pobieramy z gita, czy wrzucamy obraz do kerowy. Kolejna ważna rzecz przy upscalingu jest to uzależniające. Ten memny jest przypadkiem. Każdy, kto nie obniżył sobie zasobów i dostał po tym fakturę, rozumie, jaki problem robi nam upscaling. Mianowicie rezerwujemy sobie zasoby, zapominamy na miesiąc o tym, że właśnie kupiliśmy 10 razy droższe serwery. Tak, i potem przychodzi faktura od Jeffa Bezosa i się dziwimy, co się dzieje. Praca z bazami danych w usłudze chmurowej. Chmura oferuje nam, w tym przypadku chodzi tutaj o AWS-owy aurora, o AWS-ową aurorę. Generalnie chmury oferują bazy danych w modelu Read Only, czyli do zwiększania zasobności tych żonań, które tylko wysyłają dane do klientów. To jest bardzo ważna rzecz przy geolokalizacji, ponieważ jeżeli sobie postawimy nowy serwer gdzieś w Stanach, a baza nam zostanie w Polsce, każde zapytanie będzie trwało sekundę, więc możemy sobie pogorszyć sytuację, ale jeżeli zauważamy, że mamy o wiele większy ruch z innej części świata, możemy sobie postawić właśnie taką replikę bazy, która tylko odczytuje dane, a wszystkie zapisy dzieją się przez bazę główną i baza główna synchronizuje te wszystkie swoje repliki. W ogóle się tym nie przejmujemy. Storyt, czyli dysk sieciowy. U wszystkich providerów chmurowych jest to już rozwinięte do poziomu odrębnej aplikacji, gdzie wrzucamy plik i ten plik staje się obiektem, jest zapisany w bazie danych. Mamy jakieś dodatkowe informacje na temat tego pliku. Możemy sobie włączyć rewizjonowanie takiego storytu. Możemy sobie śledzić zmiany, które były przeprowadzone na plikach przez rok, dwa. Możemy sobie te pliki wygaszać po jakimś czasie. W porównaniu do FTP o wiele wygodniejsze. Przede wszystkim mamy wyszukiwarkę, przede wszystkim mamy historię plików, która może nie jest gitem, może nam nie pokazuje, co się dokładnie zmieniło, ale pokazuje nam, kto i kiedy zmienił albo próbował usunąć ten plik. I oczywiście też ta usługa może być geolokalizowana, też możemy sobie uruchomić kopię takiego baketu na drugim końcu świata. Żeby z tego korzystać w WordPressie, no niestety WordPress nie ma jeszcze sterowników do file systemów chmurowych. Musimy zainstalować wtyczkę WP offload media light. Z tej wtyczki korzystam, ją mogę polecić, innych nie znam, ale nie jest to coś popularnego jeszcze w WordPressie. W tym momencie ta wtyczka bardzo fajnie działa, na poprzednim PHP tam miała swoje czkawki. Proszę na zdjęcie. Tak wygląda przechowywanie plików, w tym wypadku w S3 AWSa, ale bardzo podobnie to wygląda też w storyju ażurowym. Możemy sobie wybrać, który z tych plików na ile czasu ma być kieszowany, możemy mu ustawić na główki, że ten ma być kieszowany przez godzinę, ten przez rok, a do tego w ogóle ucinamy dostęp z zewnątrz, więc mamy bardzo szczegółowe zarządzanie tymi plikami za pomocą storyżów chmurowych. Instalacja WordPressa w chmurze. Teraz przeważnie mamy sobie takiego gandalfa, nazywa się instalatron w wielu hostingach. Klikamy, on nam tworzy katalog, pobiera WordPressa, tworzy bazy danych, tworzy konfiguracje do tej bazy danych. Są hostingi chmurowe, w których to jest dostępne, ale oczywiście one niosą swoje ograniczenia, o nich dzisiaj nie będzie. Natomiast żeby postawić WordPressa w chmurze, musimy zainstalować nie tylko system operacyjny, ale całą infrastrukturę. Musimy poskładać cały komputer, na którym będziemy uruchamiać te usługi. To, co tutaj widzicie, te 8 kafelków, to są kategorie. To są kategorie konfiguracji, więc porozwinięciu z każdej z nich. AWS pyta o jakieś dodatkowe rzeczy, które chcemy ustawić, a to jest tylko i wyłącznie instalacja serwera obliczeniowego, na który wrzucimy pliki albo obraz z WordPressem. A skonfigurować tych rzeczy musimy troszkę więcej. Musimy skonfigurować dostęp i rolę. Musimy skonfigurować sieć. Musimy skonfigurować system operacyjny. Ilość zasobów, które przyznamy bazie danych i temu serwerowi obliczeniowemu. Jeżeli chcemy to wszystko mieć jakoś poskładane, wiedzieć, gdzie co stoi, to musimy sobie ustawić tagi. Musimy ustawić dysk sieciowy, czyli tą właśnie s3. Na koniec musimy do tego wszystkiego stworzyć użytkownika, i temu dopiero dodajemy ten dostęp i te role. W ogóle pomiędzy zasobami dostęp i rolę trzeba też przyznać między zasobami, żeby nasz serwer obliczeniowy mógł korzystać z bazy danych, mógł się z nią połączyć i żeby nasz serwer obliczeniowy mógł wysłać do storyju, komendę, usuń mi ten plik, albo dodaj mi ten plik. Do tego wszystkiego trzeba skonfigurować role. Na koniec musimy sobie skonfigurować czyli jakieś skrypty instalacyjne naszej aplikacji, no bo tak jak mówiłem na początku wrzucanie tego przez FTP nie ma racji bytu, bo ten serwer nam po chwili zniknie przy dowolnej zmianie. Jak już mamy to wszystko, no to chcemy uruchomić to na przykład z hasłem do bazy danych nietrzymanym w pliku, musimy skonfigurować zmienne środowiskowe dla konkretnego serwera. Jest przy konfiguracji takiej infrastruktury bardzo podstawowej, jest trochę pracy, mi to zajmuje około 3-4 godzin żeby to wszystko ze sobą działało. Ale tutaj nam z pomocą przychodzi terera formacja Infrastructure SE Code czyli zapis tej infrastruktury chmurowej w kodzie w plikach konfiguracyjnych i możemy to zrobić na przykład za pomocą narzędzia terraform które terraformuje czyli przekształci nam tą chmurę w coś wygodniejszego do użycia, będziemy żyli trochę jak Jetsonowie i możemy sobie zamknąć te projekty projekty, klientów jaką mamy potrzebę możemy zamknąć właśnie w modułach uruchamiać, opuszczać na ziemię wyłączać, włączać, usuwać terraform pomaga nam w zarządzaniu tym wszystkim Tak wygląda struktura katalogu której potrzebujemy do uruchomienia WordPressa właśnie w terraformie tutaj możecie zauważyć, że jest katalog z konfigiem czyli ustawiamy bazy danych, ustawiamy dysk na sieci uprawnienia użytkowników dostępu serwer obliczeniowy a potem jednym kliknięciem uruchamiamy na produkcji dużo mocniejsze zasoby a drugim kliknięciem tworzymy sobie staging który jest dokładnie tak samo skonfigurowany ale ma po prostu jest tańszy, korzysta z mniejszej ilości zasobów Tak wygląda podstawowa konfiguracja pojedynczego modułu terraformie ponieważ terraform w tym momencie jest przygotowany ma swoje konfiguracje ma gotowe paczki dla około 100 dostawców usług chmurowych więc jeżeli chcemy sobie postawić takie bardzo bazowe usługi infrastruktury to możemy to robić bez większego po prostu podajemy z którego obrazu terraform ma korzysta, dziejąc tego korzysta natomiast jeżeli sobie chcemy bardziej dostosować tą infrastrukturę to terraform też nam pozwoli ustawić różne rzeczy na przykład tutaj jest ilość miejsca na dysku rozmiar instancji bazy danych okno na backupy okno na updatey kiedy ten serwer bazodanowy może się na chwilę wyłączyć jak długo ma przechowywać logii to wszystko są zasoby to wszystko są pieniądze które wydają się śmiesznie niskie bo są ułamkami centów ale jeżeli mamy tych serwerów już trochę więcej jeżeli już to działa na wyższym obciążeniu no to te ułamki centów zmieniają się w dziesiątki tysięcy więc nie ma potrzeby utrzymywania stagingu na instancji 2xlarge która kosztuje 5 razy więcej niż small możemy sobie ten small do testów trzymać terraform pozwala nam też uniknąć sytuacji pod tytułem klikłem znikłem przy panelu czy przy korzystaniu z api chmurowego możemy się pomylić i możemy sobie jakiś zasób usunąć możemy sobie na przykład odpiąć go od sieci i on będzie ale nasz serwer obliczeniowy nie będzie się mógł połączyć z bazą danych bo już nie będą w tej samej pod sieci bo sobie wyrzuciliśmy tą pod sieć terraform pozwala tego uniknąć zabezpiecza nas przed tym korzystamy z tego normalnie z naszego komputera z naszej konsoli i terraform nie pozwoli nam wprowadzić zmian dopóki ich nie zaplanujemy terraform to framework który wprowadza te zmiany w chmurze za pomocą api chmurowego ale też wewnętrznie przygotowuje sobie kroki które będzie chciał wprowadzić więc w przypadku korzystania z terraforma najpierw musimy zaplanować zmianę infrastruktury w tym momencie terraform nam pokazuje o, zmieniasz bazę danych instancji małej na średnią i ja taką zmianę wykonam po uruchomieniu komendy terraform apply terraform sam automatycznie zacznie się tym zajmować wyobraźcie sobie że czasami terraform apply potrafi trwać ponad godzinę ponieważ tyle czasu się budują pewne instancje no i wyobraźcie sobie teraz, że musicie czekać 40 minut aż się coś zrobi żeby móc wyklikać kolejną rzecz do zmiany w infrastrukturze terraform nam te wszystkie problemy rozwiązuje pozwala nam ujarzmić tą chmurę i pozwala nam bardzo ładnie modularnie zarządzać nie mam slajdu końcowego nie promuje się, tyle ode mnie dzięki