RSS Feed

Jak przenosić kontener LXC na inny serwer lub/i hyperwizor

Kwiecień 5, 2019 by 0verlord

Podstawy podstaw

Przenoszenie kontenera na inny serwer 1:1 jest bardzo proste, chociaż należy pamiętać o kilku detalach, które mogą spowodować, że całą robotę będzie trzeba powtórzyć…

Jeżeli tu jesteś, to na pewno wiesz, jak się tworzy kontenery, jak je startuje i gdzie się znajdują fizycznie na dysku. W telegraficznym skrócie omówię je na przykładzie Debiana

Fizycznie katalog z kontenerami są w /var/lib/lxc.Czyli zakładając, że nasz kontener do przeniesienia nazywa się kontener, będzie znajdował się w /var/lib/lxc/kontener. Należy przenieść całą zawartość tego katalogu. Najlepiej, żeby docelowy katalog nazywał się tak samo, wtedy nie trzeba będzie poprawiać ścieżki w pliku konfiguracyjnym (config).

Mogłoby się wydawać, że ponieważ kontener to zwykłe pliki, wystarczy je po prostu skopiować. Czyli zachowujemy ownera, grupa i uprawnienia plików i wszystko gra.

System i spółka

Nie do końca – jeżeli użyjemy rsynca, domyślnie zostanie wykonane mapowanie nazwy usera na jego uid na docelowym systemie. Czyli jeżeli mamy na hoście źródłowym usera zenek o id 555, a na docelowym też istnieje user zenek tylko ma uid 777 – zostanie to przeniesione i uid/gid odpowiednio zmieniony. O ile dla normalnych userów to nie problem, ale w przypadku userów systemowych możemy mieć problem. Nagle się okaże, że właścicielem spoola MTA będzie ktoś zupełnie inny, i nasz kontekst zacznie losowo (nie) działać.

Szczególnie wyraźnie widać to na przykładzie baz danych. W zależności od kolejności instalacji i historii kontenera, uid i gid usera postgres będą inne. Po przekopiowaniu tak po prostu, na docelowym systemie ownerem clustra będzie zupełnie ktoś inny, najczęściej nie mający uprawnień do plików.

No to przenosimy

Dla zupełnie niecierpliwych gotowe polecenie na hoście docelowym, na który kopiujemy kontener

rsync --progress --verbose --exclude '*.log' -Havz -S --numeric-ids  -e "ssh -p 2222" root@serwer_źródłowy:/var/lib/lxc/kontener /var/lib/lxc/kontener

Omówienie dłuższe: –progress i –verbose pokażą co się dzieje, -e podaje parametry od ssh. Oczywiście dla loginu na roota trzeba albo włączyć logowanie po haśle, albo wrzucić klucz.

Kluczowe jest –numeric-ids ta opcja wyłącza mapowanie nazwy na uida/gida. Przerzucane są pliki z takim uidem i gidem jak na hoście źródłowym i nic nie jest przepisywane. Zasadniczo

-Havz przerzuci pliki, uprawnienia symlinki, device’y i ogólnie wszystko dokładnie tak, jak to jest na kontenerze.

S (inaczej –sparse) – ta opcja jest przydatna do przerzucania plików typu sparse czyli takich, które to mają mniejszą objętość na dysku niż faktycznie pokazuje ich zajętość. Np. taki przyrastający plik vhd, niby ma 80gb, ale w zależności od różnych rzeczy – może mieć mniej). Opcja szczególnie przydatna przy przerzucaniu baz ldapowych (np. Zimbra takie posiada – plik „zajmuje” 80GB ale faktycznie ma np. 190MB, przy standardowym kopiowaniu przekopiujemy jego maksymalną pojemność, a nie faktyczną)

–exclude , oczywiste wykluczenie, tutaj plików kończących się na .log, chociaż powinno też być *.log.gz, żeby niepotrzebnie nie przerzucać nieistotnych plików. Można używać wiele razy.

Na koniec

Ostatnia uwaga to poprawki w pliku config. Należy się upewnić, że po przerzuceniu będą nam się zgadzały ścieżki w szczególności lxc.rootfs, oraz urządzenie zapewniające sieć, np. numerek bridge’a. Jeżeli wszystko jest – lxc-start -n podniesie kontener. Trzeba też pamiętać, żeby na źródłowym usunąć wpis z autostartem (lxc.start.auto). Szczególnie jeżeli migrujemy kontenery na inny serwer w tym samym lanie. Poziom katastrofy z tego wynikającej jest na prawdę interesujący 😉


Brak komentarzy »

No comments yet.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

70 − = sixty two