W pierwszej części opisałem jak stworzyć podstawową sieć i konfigurację single VM w celu uruchomienia Wordpressa. Dzisiaj będziemy kontunuować projekt aby stworzyć oddzielną VM z frontend'em. Pozwoli nam to zabezpieczyć strukturę danych od awarii.
Zmiana w apache2.conf i uruchomienie ModRewrite
Najpier poprawmy dla HTaccessów w configu Apache. Edytujemy plik apache2.conf i zamieniamy fragment:
sudo a2enmod rewritesudo nano /etc/apache2/apache2.conf Zmieniamy fragment: Options Indexes FollowSymLinks AllowOverride None Require all granted Na: Options Indexes FollowSymLinks AllowOverride All Require all granted
Zmieniamy dodatkowo konfiguracje domyślną
sudo nano /etc/apache2/sites-available/000-default.confDopisujemy fragment między: <VirtualHost *:80> <Directory /var/www/html> Options Indexes FollowSymLinks MultiViews AllowOverride All Require all granted
</Directory>
Restartujemy usługę:
sudo service apache2 restart
Kopiowanie plików do Blob:
W moim artykule opisuje podstawowe funkcje AzCopy v8 do kopiowania plików na Blob Storage Azure. Jak to zrobić, zapoznaj sięz instrucją: [link].
Zakładam prze podstawowe kopiowanie już działa.
Tworzymy dwa konternery:
Przygotowałem specjlany krótki skrypt w Bashu do ułatwienia kopiowania plików z i do Storage:
#!/bin/bash # A simple Azure Storage example script export AZURE_STORAGE_ACCOUNT="https://YOUR_STORAGE.blob.core.windows.net/" export AZURE_STORAGE_ACCESS_KEY="YOUR_KEY1" # Local -> storage l2s() { azcopy \ --source ${1} \ --destination ${AZURE_STORAGE_ACCOUNT}${2} \ --dest-key $AZURE_STORAGE_ACCESS_KEY \ ${*:3} }# storage -> local s2l() { azcopy \ --source ${AZURE_STORAGE_ACCOUNT}${1} \ --destination ${2} \ --source-key ${AZURE_STORAGE_ACCESS_KEY} \ ${*:3} } echo case "$1" in l2s) l2s ${*:2} ;; s2l) s2l ${*:2} ;; *) echo "Usage: $0 {l2s|s2l}" >&2 exit 1 ;; esac
Teraz wystarczy uruchomić polecenia:
./home/azureuser/scriptds_copy.sh l2s /var/www/html/wp-content/uploads/ wp-upload/uploads/ --recursive --exclude-older ./home/azureuser/scriptds_copy.sh l2s /var/www/html/ wp-all-files/ --recursive --exclude-older
Wszystkie dane mamy na Blobie:
Ustawiamy w Cronie aktualizację plików w stronę do Storage:
sudo nano /etc/crontabDopisujemy do Crona pozycje: */5 * * * * root /home/azureuser/scriptds_copy.sh l2s /var/www/html/ wp-all-files/ --recursive --exclude-older */1 * * * * root /home/azureuser/scriptds_copy.sh l2s /var/www/html/wp-content/uploads/ wp-upload/uploads/ --recursive --exclude-older
Tworzymy Snapshoot dysku MasterWP:
Przechodzimy krok po kroku z VM.
Krok 1
Krok 2
Krok 3
Brawo. Masz gotowy obraz dysku do nowej instancji - frontendu.
Tworzymy drugą maszynę VM z Frontendem
Ta maszyna będzie kopiowac dane z Storage i uruchamiać fornt-end. Wszystkie zmiany które będą na masterWP, po 2 minatach będą kopiowane na tą maszynę.
Tworzymy Dysk z Snapshoota a następnie VM:
Krok 1
Krok 2
Krok 3
Krok 4
Konfiguracja instancji VM frontendWP master
Po uruchomieniu instacji, logujemy się na nią, i zmieniamy plik crontab. Musimy dopisać aby kopiował dane Storage -> Local
sudo nano /etc/crontabUsuwamy dotychczasowe nasze pozycje do Crona pozycje, i dodajemy nową.: */1 * * * * root /home/azureuser/scriptds_copy.sh s2l wp-all-files/ /var/www/html/ --recursive --exclude-older
Dla testu usuń pliki:
rm -r /var/www/html/
Po minucie pliki powinny wrócić.
Rozdzielamy DNS na admina i frontend
Pierwszą rzeczą jest uruchomienie nowej strefy DNS. Założyłem dwa rekordy:
Zmieniamy ustawienia Wordpressa
Od tej pory, mamy oddzielny VM na panel adminstratora i zarządzanie aktualizacjami WP.
Odzielny VM z frontendem dla użytkowników. W razie awarii jednej strony, nie zostaniemy pozbawieni usług.
Nastepnym krokiem będzie uruchomienie CDNa na uplowane pliki i uruchomienie auto scalingu aby uniknąć przeciażenia witryny.