K-NET s.c.

Wirtualizacja KVM – przekierowanie ruchu

Wielokrotnie pisałem o mojej ulubionej wirtualizacji czyli środowisku VMware. Pomimo doświadczeń z innymi rodzajami hostów nadal uważam, że jest to naprawdę bardzo dobrze zrównoważone rozwiązanie. Drugą istotną cechą jest wsparcie techniczne, które pod postacią dokumentacji elektronicznej oraz komentarzy użytkowników jest uporządkowane i pieczołowicie utrzymywane przez samego producenta. Wszystko to sprawia, że nawet jeżeli spotka nas jakiś ezoteryczny problem to od razu wiadomo gdzie szukać rozwiązania.

Jednak jak zwykle życie wymusza często zmiany w rozwiązaniach i ostatnio zmierzyłem się z maszynami wirtualnymi KVM. Posiadając działający i w pełni skonfigurowany serwer zbudowany na bazie np. Debiana, nie ma raczej innego wyjścia chociaż można spróbować tzw. poor man virtualization czyli Virtualbox w trybie headless. Przyznam, że do tej pory mam pod opieką jeden taki wynalazek. Wracając do KVM to warto zaznaczyć, że nawet jeżeli nie lubisz konfiguracji z użyciem komend to możesz zaistalować chociażby pakiet Cockpit i uzyskać tym samym zarządzanie przez webinterface.

Niezależnie w jaki sposób będziemy korzystać z KVM warto zadbać o bezpieczeństwo konfigurując swoje węzły wirtualne w dedykowanej wirtulanej sieci za NATem. W ten sposób odetniemy możliwość bezpośredniego atakowania usług sieciowych. Z kolei na potrzeby chociażby testowania mamy wygodne rozwiązanie na kształt prywatnej sieci lokalnej z dostępem do Internetu.

Załóżmy następnie, że będziemy chcieli wystawić wybraną usługę, może to być np. serwer www na zewnątrz sieci LAN. Powinniśmy użyć mechanizmu forwardowania pakietów pod wskazany wewnętrzny adres IP, na wskazany port. Jest to powszechnie wykorzystywana metoda w wielu domowych (i nie tylko) routerach z firewallem. W tym miejscu dochodzimy do głównego wyzwania bo przecież interfejs sieciowy KVM oraz interfejs fizyczny nie są ze sobą wprost związane. Żeby przekazywać komunikację między jednym a drugim trzeba skorzystać z dodatkowej konfiguracji za pomocą iptables.

Biorąc za przykład przekazywanie ruchu do serwera www (via HTTPS) będą potrzebne dwie reguły:

iptables -t nat -I PREROUTING -p tcp -d 1.2.3.4 --dport 443 / 
-j DNAT --to-destination 10.0.0.1:443
iptables -I FORWARD -m state -d 10.0.0.1/24 /
--state NEW,RELATED,ESTABLISHED -j ACCEPT

Domyślny konfiguracja KVM NAT zapewnia regułę podobną do drugiej linijki, ale pomija stan NEW, który jest niezbędny do akceptacji połączeń przychodzących. W przykładzie 1.2.3.4 jest adresem publicznym (zewnętrznym) zaś 10.0.0.1 adresem prywatnym. Należy je zmienić według potrzeb i konfiguracji własnej sieci.

Dopiero wpisanie z linii poleceń powyższych dwóch komend pozwoli nam skomunikować się z maszyną wirtualną KVM. Jako zadanie domowe polecam sprawdzenie jak można dodoac reguły do konfiguracji tak aby nie trzeb było ich za każdym razem ręcznie podawać po starcie systemu.

MG

Tagi: iptables, KVM, Linux, wirtualizacja

vCenter Converter powraca!

VMware ogłasza powrót jednego z najpopularniejszych produktów w katalogu – vCenter Converter. Wydano nową i ulepszoną wersję produktu, kompatybilną z vSphere 7.0 i ESXi 7.0. Opublikowana wersja koncentruje się głównie na poprawie stabilności i standardów bezpieczeństwa Konwertera oraz zachowaniu istniejącej funkcjonalności.

VMware vCenter Converter zachęca do wysłania informacji o chęci dołączenia do programu vCenter Converter Beta. Można skorzystać z tej możliwości, aby wpływać na przyszły kierunek rozwoju produktu. Jeśli nie masz dostępu do społeczności Beta, wystarczy, że odwiedzisz stronę rejestracji vCenter Converter BETA i przejdziesz do wypełnienia oraz wysłania formularza.

vCenter Converter jest bezpłatnym narzędziem zapewniającym możliwość konwersji maszyn wirtualnych działających na hiperwizorach innych dostawców oraz maszyn fizycznych na maszyny wirtualne VMware. Mowa wersja vCenter Converter obsługuje konwersję rozwiązań opartych na MS Hyper-V, konwersję pomiędzy formatami wirtualnymi VMware (Workstation, Fusion) oraz rekonfigurację maszyn wirtualnych VMware. vCenter Converter wspiera wirtualne stacje robocze działające pod kontrolą systemów Windows, Linux Ubuntu, CentOS, Red Hat Enterprise Linux.

Kolejne wydania będą wzbogacać listę obsługiwanych hyperwizorów, wersji vSphere, systemów operacyjnych i wirtualnych wersji sprzętu.

Link do oryginalnego komunikatu: https://blogs.vmware.com/code/2022/09/15/vcenter-converter-is-back/

MG

Tagi: Linux, serwer, VMWare, Windows, wirtualizacja

VMware, converter, 97% error

Wirtualizacja w wydaniu VMware jest bardzo popularnym rozwiązaniem. Żeby uruchomić pełnoprawny serwer z maszynami wirtualnymi wystarczy średniej klasy sprzęt oraz konto na platformie VMware. Oprogramowanie ESXi (co prawda w ograniczeniami, które dotyczą przede wszystkim limitu rdzeni na jednostkę) jest dostępne jako wersja ewaluacyjna do pobrania. Wygodny interfejs webowy pozwala nawet niezaawansowanemu użytkownikowi na zarządzanie swoim środowiskiem.

Gdy przekonamy się do zalet wirtualizacji może pojawić się konieczność przeniesienia fizycznych serwerów do Vmware. Również w tym przypadku firma udostępnia narzędzie Vmware Standalone Converter (VCS), aby za jego pomocą automatycznie przeprowadzić proces migracji. I tutaj zaczynają się schody. Wspomniana aplikacja, która adresowana jest dla systemów Windows jest po prostu przestarzała. Owszem obsługuje większość systemów operacyjnych, ale nie wszystkie do końca prawidłowo.

Pierwsze kłopoty pojawiają się w momencie konwersji systemów linuksowych z macierzą RAID zrealizowaną programowo. Ze względu na ogólnodostępne informacje na ten temat nie skupie się dalej na tym problemie. Następne w przypadku nowszych wersji Linuksów. W artykule opisuje proces na przykładzie Debiana w wersji 10. VSC nie potrafi sobie poradzić z przeniesieniem GRUB, czyli zainstalowaniem bootloadera. Konwersja zatrzymuje się na 97% i pojawia się komunikat o błędzie.

Jest on mylący ponieważ sugeruje nieukończenie konwersji, która w rzeczywistości dobiegła do końca etapu klonowania danych i jedyną operacją niesfinalizowaną jest wspomniana wcześniej instalacja GRUB.

Możemy (a raczej powinniśmy) ręcznie naprawić sytuację. Na hoście maszyn wirtualnych wyszukujemy zduplikowany serwer (w tym przypadku jego kopie). Następnie edytujemy jego ustawienia i wskazujemy obraz ISO z wersją instalacyjną Debian 10 jako źródło dla danych w napędzie DVD. Trzeba jednak pamiętać o włączeniu opóźnienia w bootowaniu systemu (opcja ukryta w menu Edit) tak aby możliwe było wyświetlenie menu wyboru źródła systemu za pomocą klawisza ESC podczas uruchamiania maszyny.

Po starcie systemu z płyty instalacyjnej wybieramy Rescue Mode. Następnie powinniśmy uruchomić konsolę tekstową i wywołać polecenie blkid. Jest to konieczne, gdyż musimy poznać nowe identyfikatory dysków twardych UUID, które zmieniają się podczas klonowania.

Następny krok to pracowita edycja pliku /etc/fstab, aby poprawić identyfikatory, o których wspomniałem powyżej. Możemy to zrobić za pomocą edytora vi lub nano, w zależności od tego, który będzie dostępny.

W ostatnim kroku korzystamy z dwóch komend, instalując (i naprawiając przy okazji) GRUB:

grub-install /dev/sda
update-grub

W miejsce przykładowej /dev/sda powinniśmy wstawić docelową partycję dla bootloadera (prawdopodobnie w 90% przypadków nie trzeba tego zmieniać).

Ostatnią czynnością będzie ręczne zrestartowanie maszyny wirtualnej – korzystamy z funkcji ESXi. Przy odrobinie szczęścia okaże się, że jednak maszyna została przeniesiona prawidłowo.

MG

Tagi: Debian, Linux, serwer, VMWare, wirtualizacja

Portainer – aktualizacja

Portainer to jedna z najlepiej znanych i powszechnie stosowanych platform do wygodnego zarządzania kontenerami Dockera. Zamiast koncentrować się na zapamiętaniu komend linii poleceń możemy przez interfejs graficzny wyklikać praktycznie wszystko. Oczywiście, że zawsze znajdą się zwolennicy „czarnego ekranu”, przyznam że rówież często korzystam z tej metody, ale przy dużej liczbie zarządzanych kontenerów wygodniej jest po prostu skorzystać z przeglądarki.

Od czasu do czasu, w dolnym lewym rogu ekranu powitalnego Portainera pojawia się jednak informacja o dostępności nowej wersji. I w tym przypadku, nie ma już wyjścia, musimy posilić się bezpośrednio terminalem tekstowym. Poniżej zamieściłem podstawowe komendy, których użycie pozwoli zaktualizować Portainer. Oczywiście założyłem, że środowiskiem uruchomieniowym naszego Dockera jest Linux. W moim przypadku, bez wyjątku to któraś wersja pochodna z gałęzi Dabiana. Należy również wspomnieć, że jak będziemy już mieć najnowszy Portainer, to z jego poziomu możemy aktualizować inne kontenery, nie używając linii poleceń.

Zaczynamy od wpisania dwóch poleceń aby zatrzymać i usunąć kontener Portainera:

docker stop portainer
docker rm portainer

Następnie usuwamy obraz Portainera z lokalnego repozytorium:

docker images
docker rmi [IMAGE ID]

Pierwsze polecenie pokaże nam listę wszystkich obrazów. W kolejnym staramy się usunąć wybrany poprzez wskazanie jego ID.

Teraz czas na pobranie najnowszego obrazu Poratinera:

docker pull portainer/portainer-ce

I wreszcie możemy zainstalować nową wersję platformy:

docker run -d -p 8000:8000 -p 9000:9000 —name=portainer /
—restart=always -v /var/run/docker.sock:/var/run/docker.sock /
-v portainer_data:/data portainer/portainer-ce

Dobrze jest pamiętać aby nie zmieniać wartości parametru portainer_data, dzięki czemu nie stracimy ustawień konfiguracyjnych pomiędzy kolejnymi aktualizacjami.

I to wszystko. Teraz można przystąpić do testowania.

MG

Tagi: Docker, linia poleceń, Linux, Portainer, wirtualizacja

Docker, Portainer i kłopoty z OpenProject

Techniki wirtualizacji są obecnie bardzo popularne. Począwszy od tych dostępnych na wyciągnięcie ręki dla każdego użytkownika, mam na myśli VirtualBox, a skończywszy na bardziej rozbudowanych typu VMware ESXi, czy QEMU. Te ostatnie wymagają już środowiska w pełni serwerowego i trochę zaawansowanej technicznie wiedzy (ale bez przesady). Z drugiej strony prężnie rozwija się technologia kontenerów wirtualizacyjnych typu Docker. Stają się one popularne głównie w środowisku programistów (koderów i developerów) bo pozwalają w łatwy sposób instalować całe środowiska z przygotowanych obrazów. Skraca to bardzo czas rozwoju oprogramowania, bo daje do ręki skonfigurowany gotowiec jak np. LAMP czyli Linux, Apache, MySQL, PHP/Python/Perl.

W tym wpisie chciałem się właśnie skupić się na apliakcji Docker. Wynika to głównie stąd, że jakiś czas temu realizowałem projekt polegający na zainstalowaniu całego środowiska developerskiego. Składały się na nie serwer z Debianem oraz 3 kontenery: GitLab, Nextcloud i OpenProject. Można powiedzieć solidne środowisko do pracy dla programistów. Całość została uruchomiona w sieci lokalnej, a każdy z wymienionych kontenerów był dostępny pod swoim własnym adresem IP oraz wewnętrzną nazwą domenową. Przy tej okazji chciałem podzielić się dwoma spostrzeżeniami, dotyczącymi problemów, których zrozumienie i dla których przygotowanie rozwiązania bardzo ułatwiło mi opracowanie rozwiązań. Jeden będzie dosyć ogólny, drugi zaś to przykład debugowania rozwiązania i zaaplikowania specyficznej łaty. Ale po kolei.

Środowiskiem kontenerów Dockera można zarządzać oczywiście za pomocą linii komend. Jednak jako alternatywe polecam gorąco projekt o nazwie Portainer. Instalowany jako jeden z pierwszych kontenerów naszego Dockera pozwoli w dosyć prosty i elegancki sposób zarządzać całością. Zwolenników aplikacji webowych ucieszy na pewno fakt, że jest to po prostu serwer, który udostępnia interfejs przeglądarkowy. Możemy zarządzać praktycznie wszystkimi potrzebnymi modułami w tym: kontenerami, obrazami, wolumenami i sieciami. Możliwości jest dużo więcej i najlepiej jest zainstalować to oprogramowanie samemu, żeby o tym się przekonać. Tym bardziej, że jest to łatwe jak instalacja każdego kontenera w Dockerze 🙂

Drugim problemem, bardziej złożonym, okazała się isntalacja OpenProject. Chciałbym o tym wspomnieć ponieważ jest to bardzo dobry przykład na to, z jakimi problememi można się spotkać używając Dockera. Sama instalacja z oficjalnego, przygotowanego przez autorów obrazu nie nastręcza większych żadnych trudności. Zaraz po uruchomieniu wszysko działa dobrze. Jednak z czasem, gdy będziemy musieli zrestartować cały serwer, a co za tym idzie swoje kontenery również, może się okazać, że OpenProject odmawia posłuszeństwa. Zamiast głównej strony serwisu natkniemy się na informacje o niedostępności. Po przeprowadzeniu wspomnianego na początku debugowania oraz sprawdzeniu stanu samego kontenera (który zachowuje się jak najbardziej poprawnie, czyli uruchamia się i nie zgłasza żadnych błędów) okazało się, że przyczyną jest zatrzymanie się serwera Apache. Niestety ręczne uruchamianie daemona również nie pomaga. Problem jest nieco głębszy i polega na tym, że w trakcie restartu kontenera zdarza się, że nie jest usuwany plik apache2.pid, co z punktu widzenia systemu oznacza, że Apache jak najbardziej działa cały czas (co nie jest prawdą). Rozwiązanie jest dosyć proste. Plik ten należy usunąć ręcznie, czyli:

• z poziomu Portainera (omówionego akapit wcześniej) połączyć się z konsolą,
• usunąć ręcznie plik PID: rm -f /var/run/apache2/apache2.pid,
• uruchomić Apache: /etc/init.d/apache2 start.

Powyższa sztuczka pokazuje, że pomimo iż oficjalne kontenery Dockera zazwyczaj działają bez zarzutu to czasami wymagana jest głębsza wiedza i grzebanie w czeluściach obrazu.

MG

 

Tagi: Docker, komendy, konfiguracja, linia poleceń, serwer, wirtualizacja