…daj pan spokój z przyśpiewkami
W poprzednim wpisie opisałem proces domowego disaster recovery. Aplikacja tam uruchomiona wstała, została w prawidłowy sposób uruchomiona, także zostały wykonane pewne testy mające na celu weryfikację, czy nie przykładam sobie lufy do potylicy.
Na przestrzeni ostatnich godzin intensywnie sprawdzałem wszystkie kwestie związane z działaniem aplikacji. Na chwilę obecną sprawdzenia wymaga:
– Pluginy w WordPress nie mogą aktualizować się za pomocą wbudowanych mechanizmów. Żebrają o dostęp do FTP (bleee).
– W WordPressie mechanizmy 2FA także są związane z odpowiednim pluginem. Zgadza się: zdechło i to.
– Self-health-test, czy jak się to tam zwie, wbudowany w WordPressa krzyczy, że nie może się dobić z pluginami do mechanizmów aktualizacji innych, niż po FTP. Hmm, czyżby to miało związek z poprzednimi punktami?
Nic śmiesznego
Istnieje takie powiedzonko w IT, które brzmi mniej więcej tak:
Ludzie dzielą się na tych, którzy robią regularnie kopie zapasowe oraz na tych, którzy będą je robić
Zatem do roboty. Masz pan kopię maszyny do wykonania. Swoją przygodę rozpocznę od utworzenia kopii zapasowej całej maszyny. Z racji, że stoi to na Proxmoxie (choć ostatnio nawet i leżało), dobrze by było rozpocząć swoją przygodę właśnie tam. Na szczęście w Proxmoxie ten mechanizm jest bardzo prosty i zbiega się do wyboru maszyny, wejścia w zakładkę Backup i kliknięcia w Backup now. Można także jakiś finezyjny opis dodać w sekcji Notes.
Dlaczego nie skupiam się na kopii jedynie kontenera z aplikacjami? Cóż. Są ku temu dwa powody: pierwszy dotyczy skali problemu. Nie będziemy działać jedynie w ramach samego systemu plików kontenera, a dłubać w uprawnieniach w /var/lib/docker/volumes, plikach DockerCompose.yml a także całkiem możliwe będzie gmeranie w bazie danych. Drugi powód jest wręcz osobisty: jestem zbyt leniwy, aby pozwolić sobie na przywracanie pojedynczych zmian. Czasami dobrze jest teleportować się do ostatniego dobrego stanu i rozpocząć przygodę ponownie.
Tymczasem w tle proces tworzenia kopii został ukończony.
Dzień świra
Należy w tym momencie zacząć działać ostrożnie. Nie to, że cała masa poprzednich kroków nie wymagała takiego podejścia, po prostu teraz potknięcie będzie całkiem bolesne. Oczywiście, że bekap, ale nie po to go robiłem, aby go niepotrzebnie przywracać.
Pierwszym krokiem, jaki wykonam, jest sprawdzenie, czego oczekuje ode mnie aplikacja. Uprawnienia do określonych lokalizacji, prawa na plikach, może jakaś specjalne, nieznane dotąd wpisy w DockerCompose.yml? Zadanie takich pytań nie jest takie absurdalne, jeśli przyznam się, że w ramach WordPressa nie przypilnowałem wersji aplikacji, robiąc deploy najnowszej wersji. To poważne niedopatrzenie, które w przypadku niektórych aplikacji (Nextcloud, ekhem…) może mieć bardzo, ale to bardzo przykre konsekwencje. W takich warunkach skup się jednak na tym, aby możliwie najmocniej trzymać się takich wersji obrazów, z jakich wcześniej korzystałeś. Pozwoli to na zachowanie jednej zmiany w jednym kroku, bez wprowadzania dodatkowych zmiennych, skupiając się na jednym problemie, bez generowania następnego. Mogłem w momencie uruchamiania nowej instancji WordPressa w pliku DockerCompose.yml wskazać na obraz, z którego korzystałem ostatnio, zamiast polegać na wersji latest, która nie była tym samym, co kilka tygodni temu. Co zabawne, baza danych ma podstawioną konkretną wersję obrazu i to pozwoliło mi uniknąć driftu z wersjami obrazów. Po prostu miałem pewność, że jeśli uprawniania w katalogu z volumenami się nie rozjadą, baza wstanie, bo taka jest właściwie idea kontenerów Docker.
Aby dokonać takiego sprawdzenia, należy mieć nadal poprzedni kontener LXC/maszynę wirtualną/poprzedni backup/cokolwiek co tam masz z aplikacją. Zanim jednak uruchomię takie środowisko, trzeba się zabezpieczyć przed zrobieniem dużego bałaganu. Poprzednia instancja ma taki sam adres IP w sieci lokalnej, jak obecna, co było celowym i leniwym działaniem. Uruchomienie maszyny z takim samym adresem IP spowoduje po prostu duży bałagan w sieci. W ustawieniach Proxmoxa wyłączę po prostu dostęp do sieci:
W tym punkcie mogę uruchomić kontener LXC i teoretycznie mogę dostać się tam konsolą w przeglądarce.
Błąd numer 1: Otóż nie do końca. Właściwie to wcale. Otóż nie mogę się tam dostać w taki sposób, bo użytkownicy są bez hasła, a logowanie się jest możliwe przy pomocy kluczy. Więc nie, nie da się. Ale i to się da ominąć.
Rozwiązanie:
Mamy działający kontener LXC bez dostępu do sieci. Powtarzam: Kontener LXC, działający. Możemy dostać się do konsoli SSH Proxmoxa i użyć narzędzia ptc, które pozwoli nam na wjazd na maszynę. Zatem: ptc enter 104:
Do nam to daje? Możemy sprawdzić, jakie kontenery Dockera sobie tam brykały (docker ps -a), co pokaże nam, jakiego obrazu użyto do startu:
Czysto teoretycznie można teraz zmusić Dockera na nowej maszynie, aby użył tego samego obrazu. W tym celu warto sprawdzić, co to za obrazy tej aplikacji mamy:
smutny-root@smutny-serwer-www:~# docker images --digests --no-trunc | grep wordpress -n
6:wordpress latest sha256:8b0ffd461bfaf8e74ab98481f45d1b2596986767faf2dc65bb47c875076f8a14 sha256:52bb3e73152ae8a92ef5a7d0589d923aa3c46538c8494b644b8cf2f5ceba2d37 9 months ago 701MB
Bingo, mamy jakieś informacje. Teraz czysto teoretycznie możemy w DockerCompose.yml wskazać, aby użyć obrazu WordPressa w wersji, której hash jest właśnie równy naszemu obrazowi. Bazując na obecnej wersji można zweryfikować poprawność takich informacji:
Więc nadal czysto teoretycznie w DockerCompose.yml można użyć:
image: wordpress@sha256:8b0ffd461bfaf8e74ab98481f45d1b25968767faf2dc65bb47c875076f8a14
Gdzie ten digest hash jest związany z uszkodzoną instancją i powinno użyć obrazu, który będzie mieć tę samą wersję WordPressa, co ujebaniec. Tutaj jednak to zakończę, bo nie to jest problemem, ten fragment jest dobrym punktem na następnego laba. Tym razem NIE przymusowego.
Koleje losu
Wracamy na poprzednie tory. Zacznę jednak od ustalenia, co tak na prawdę mam w tym momencie: jaki użytkownik, z jakim ID działa z jakimi procesami w obrębie kontenerów Dockera, a także czego oczekuje ode mnie aplikacja. Najgłupsze jest działanie na ślepo: perfekcyjna metoda na większy bałagan.
Skoro aplikacja działa w kontenerze, to procesy i inne informacje można tam znaleźć. Kontener ma swoją konsolę, można zrobić tam docker exec i wysoce prawdopodobne, że będzie tam jakiś podglądacz procesów. Pójdźmy tym tokiem.
Na obecnej instancji serwera WWW uruchomię docker exec -it wordpress_app id. W moim przypadku wskazał na działanie jako root. To niedopuszczalne. Moim punktem zaczepienia są nadal jednak uprawnienia plików, bałagan przy przenosinach. Ciepło.
W DockerCompose.yml odhashowałem linijkę: user: „1001:1001”. Następnie udałem się do katalogu /var/lib/docker/volumes/. W tym katalogu mieszkają kolejne katalogi, którym się zajmiemy. To <Nazwa_Kontenera>/_data. I teraz skup się majster, bo to ważne. Należy zmienić uprawnienia. Ty pytasz na jakie. Ja odpowiadam: na odpowiednie. Szach mat:
cd /var/lib/docker/volumes/wordpress_app
chown -R 1001:1001 _data
chmod -R 775 _data/wp-content/uploads
cd /var/lib/docker/volumes/wordpress_db
chown -R 1001:1001 _data
i teraz powrót do katalogu z DockerCompose.yml i:
docker compose down
docker compose up -d
I ma działać. Skąd numer 1001 się zapytasz?
Bo tak. Teoretycznie mogę inny UID i GID podać, np. 1003, nic się nie stanie. Ważne, aby nie trzymać tego jako root, bo to ciut za wysokie uprawnienia jak na aplikację webową.
Co ze wspomnianym wcześniej 2FA? Nic. Dodatek, który to obsługuje widnieje jako niezainstalowany. Po ręcznej instalacji dodatku, weryfikacja dwuetapowa ponownie zaczęła działać poprawnie. Nie podoba mi się to, ale trudno. Pożar ugaszony. 2FA nie zostało tak spektakularnie rozwałkowane w ramach laba.
Nie ma róży bez ognia?
Zapytasz się, dlaczego nie podejrzałem sobie uprawnień na starym kontenerze LXC? Wytłumaczenie jest całkiem proste: mogłem tam podejrzeć strukturę katalogów, ich zawartość, mogłem je spakować i wysłać, ale usterka polegała na przede wszystkim rozwalonych uprawnieniach co jest jednak całkiem mocnym uproszczeniem i spłyceniem tematu. Nadal nie debugowałem przyczyny problemu, a skupiłem się na sprzątaniu nowego środowiska.
Źródła
- obrazek Jana Pawła Adamczewskiego skopiowany z rp.pl
- screenshoty własne
- ściągawka z Dockera: https://bykowski.pl/docker-lista-komand-twoja-podreczna-sciaga/ – była w użyciu, składnia w pigułce
- https://stackoverflow.com/questions/72061882/search-docker-images-by-sha256
- https://docs.docker.com
- Pan ChatGPT, ponownie chcący wszystko zaorać
0 komentarzy