Zarządzanie szablonami kontenerów (CT Templates)
Zanim przystąpimy do tworzenia kontenerów LXC musimy mieć w którymś z naszych datastorów przechowujących szablony kontenerów (CT Templates) odpowiednie szablony. Największą bazą gotowych szablonów systemów, aplikacji i usług jest strona https://www.turnkeylinux.org/
Wgrywanie nowych szablonów z linii komend
W moim przypadku obrazy iso oraz szablony kontenerów nie są przechowywane na domyślnym datastore o nazwie local tylko na NFS-owym udziale o nazwie isostore-01
# wyświetlenie dostępnych do ściągnięcia szablonów pveam available ... turnkeylinux debian-11-turnkey-ansible_17.1-1_amd64.tar.gz turnkeylinux debian-11-turnkey-wordpress_17.1-1_amd64.tar.gz ... # ściągnięcie do lokalnego storage isostore-01 Container templates pveam download isostore-01 debian-11-turnkey-wordpress_17.1-1_amd64.tar.gz # wyświetlenie listy dostępnych lokalnie szablonów kontenerów pveam list isostore-01 NAME SIZE isostore-01:vztmpl/alpine-3.16-default_20220622_amd64.tar.xz 2.42MB isostore-01:vztmpl/debian-11-turnkey-wordpress_17.1-1_amd64.tar.gz 320.30MB
Wgrywanie nowych szablonów z konsoli GUI
Wchodzimy w zawartość datastore isostore-01 i wybieramy zakładkę CT Templates. Po wybraniu interesującego nas szablonu wciskamy przycisk Download.
Utworzenie kontenera LXC z Debian 11 z konsoli GUI Proxmox
Utworzenie kontenera LXC z Debian 11 z konsoli serwera Proxmox
pct create 135 isostore-01:vztmpl/debian-11-standard_11.6-1_amd64.tar.zst --storage datastore-01 --hostname debianlxc --password 1234abcd --unprivileged 0 -cores 2 --memory 4096 --net0 name=eth0,bridge=vmbr0,ip=192.168.8.35/24,gw=192.168.8.1
lub przy użyciu polecenia pvesh
pvesh create /nodes/pve/lxc \
-vmid 135 \
-ostemplate isostore-01:vztmpl/debian-11-standard_11.6-1_amd64.tar.zst \
-cores 2 -cpuunits 1024 \
-memory 4096 -swap 128 \
-unprivileged 0 \
-hostname debianlxc.netapps.ovh \
-net1 name=eth0,ip=192.168.8.39/24,bridge=vmbr0 \
-rootfs datastore-01:10 \
-description "Kontener testowy" \
-onboot 1
Dodatkowe właściwości kontenera LXC (Features)
Nesting – Zagnieżdżanie w kontenerach LXC Proxmox odnosi się do możliwości uruchamiania kontenerów LXC w kontenerach LXC. Ta funkcja umożliwia tworzenie hierarchicznej struktury kontenerów, w której każdy kontener pełni rolę hosta dla dodatkowych kontenerów. Po włączeniu zagnieżdżania możesz utworzyć kontener w kontenerze, a ten wewnętrzny kontener może również uruchamiać własny zestaw kontenerów LXC. To zagnieżdżanie można wykonać na wielu poziomach, tworząc zagnieżdżoną architekturę kontenera. Zagnieżdżanie kontenerów LXC może być przydatne w niektórych scenariuszach, takich jak: Testowanie i programowanie: w kontenerach można tworzyć izolowane środowiska do celów testowania i programowania. Każdy zagnieżdżony kontener może mieć własną konfigurację sieci, stos oprogramowania i konfiguracje, zapewniając kontrolowane środowisko do testowania różnych scenariuszy.
NFS, SMB/CIFS – Proxmox obsługuje zarówno NFS, jak i SMB/CIFS do udostępniania plików między systemem hosta a kontenerami LXC. Konfigurując udziały NFS lub SMB/CIFS na hoście, możesz następnie zamontować te udziały w kontenerach LXC. Pozwala to na udostępnianie plików i katalogów między hostem a kontenerami, umożliwiając wymianę danych i współpracę. Udostępnianie plików przy użyciu NFS lub SMB/CIFS może być szczególnie przydatne w scenariuszach, w których konieczne jest udostępnianie wspólnych danych lub plików konfiguracyjnych wielu kontenerom LXC lub gdy chcesz uzyskać dostęp do plików przechowywanych w systemie hosta z poziomu kontenerów.
FUSE – Instalując moduł jądra FUSE w systemie hosta i włączając obsługę FUSE w konfiguracji kontenera LXC, możesz montować systemy plików oparte na FUSE wewnątrz kontenerów.Niektóre przykłady systemów plików opartych na FUSE obejmują: SSHFS (system plików SSH): SSHFS umożliwia zamontowanie zdalnego katalogu przez połączenie SSH, dzięki czemu jest dostępny tak, jakby był katalogiem lokalnym. Dzięki obsłudze FUSE w kontenerach LXC możesz montować zdalne katalogi za pomocą SSHFS w kontenerach, umożliwiając łatwy dostęp do zdalnych plików i katalogów. NTFS-3G: NTFS-3G to sterownik systemu plików oparty na FUSE, który zapewnia dostęp do odczytu i zapisu partycji NTFS w systemach Linux. Włączając obsługę FUSE w kontenerach LXC, możesz montować i uzyskiwać dostęp do partycji NTFS w kontenerach, umożliwiając pracę z urządzeniami pamięci masowej sformatowanymi w systemie NTFS. EncFS: EncFS to zaszyfrowany system plików, który zapewnia przejrzyste szyfrowanie plików i katalogów. Dzięki obsłudze FUSE możesz używać EncFS w kontenerach LXC do tworzenia zaszyfrowanych katalogów i bezpiecznego przechowywania poufnych danych.
# aktualizacja systemu apt update && apt upgrade # instalacja klienta NFS dla Ubuntu/Debian apt install nfs-common # instalacja klienta SMB/CIFS dla Ubuntu/Debian apt install smbclient cifs-utils # instalacja SSHFS dla Ubuntu/Debian apt install sshfs
Zdalne logowanie root-a do kontenera
# z konsoli Proxmox GUI w menu Console kontenera po zalogowaniu się na użytkownika root nano /etc/ssh/sshd_config PermitRootLogin yes # restart usługi SSHD service sshd restart
Ustawienia strefy czasowej kontenera
dpkg-reconfigure tzdata # wskazujemy Europe - Warsaw Current default time zone: 'Europe/Warsaw' Local time is now: Mon May 29 12:31:53 CEST 2023. Universal Time is now: Mon May 29 10:31:53 UTC 2023.
Przydział zasobów CPU do kontenera LXC
<CPU_UNITS>: Wartość jednostek procesora do przydzielenia do kontenera. Jednostki procesora określają względny udział kontenera w zasobach procesora hosta. Wyższe wartości oznaczają wyższy priorytet. Wartość domyślna to 1024.
<CPU_LIMIT>: Limit procesora do ustawienia dla kontenera. Ta wartość reprezentuje maksymalny procent zasobów procesora, z których może korzystać kontener. Na przykład wartość 50 oznacza, że kontener jest ograniczony do użycia 50% pojedynczego rdzenia procesora.
„CPU Unit” odpowiada cpu.share (domyślnie 1024) i musi to mieć względny priorytet bieżącej maszyny wirtualnej/kontenera w stosunku do reszty (priorytet jest nadawany przez mój cpu.share podzielony między sumę wszystkie udziały procesora). „limit procesora” ma związek z maksymalnym wykorzystaniem fizycznych rdzeni procesora (w czasie działania), jakie może uzyskać maszyna wirtualna lub kontener, ale NIE JEST to cfs_period_us. Zamiast tego jest powiązany z ilorazem (cfs_quota_us / cfs_period_us) zdefiniowanym jako parametr „cpulimit” w KVM. „cfs_period_us to długość okresu w mikrosekundach” lub okno kontroli przepustowości procesora, zwykle jest to 100 000 lub 100 ms (nie konfigurowalne w PVE). Z drugiej strony cfs_quota_us to „całkowity dostępny czas działania w okresie” (również w mikrosekundach) lub liczba mikrosekund, które maszyna wirtualna/kontener może wykorzystać w tym oknie (licząc wszystkie procesory). Na przykład, jeśli cfs_period_us=100000 i cfs_quote_us=200000, oznacza to, że maszyna wirtualna/kontener będzie w stanie uzyskać 100% z 2 procesorów w każdym okresie 100 ms, więc iloraz wyniesie 2,0 (200%).
Oprócz liczby rdzeni wirtualnych możesz skonfigurować, ile zasobów może uzyskać maszyna wirtualna w stosunku do czasu procesora hosta, a także w stosunku do innych maszyn wirtualnych. Dzięki opcji cpulimit („Czas procesora hosta”) możesz ograniczyć czas procesora, jaki cała maszyna wirtualna może wykorzystać na hoście. Jest to wartość zmiennoprzecinkowa reprezentująca czas procesora w procentach, więc 1,0 jest równe 100%, 2,5 do 250% i tak dalej. Gdyby pojedynczy proces w pełni wykorzystywał jeden rdzeń, zużywałby 100% czasu procesora. Jeśli maszyna wirtualna z czterema rdzeniami w pełni wykorzystuje wszystkie swoje rdzenie, teoretycznie wykorzystałaby 400%. W rzeczywistości użycie może być nawet nieco większe, ponieważ QEMU może mieć dodatkowe wątki dla urządzeń peryferyjnych VM oprócz rdzeni vCPU. To ustawienie może być przydatne, jeśli maszyna wirtualna ma mieć wiele procesorów wirtualnych, ponieważ uruchamia kilka procesów równolegle, ale maszyna wirtualna jako całość nie powinna być w stanie uruchomić wszystkich procesorów wirtualnych na 100% w tym samym czasie. Używając konkretnego przykładu: powiedzmy, że mamy maszynę wirtualną, która skorzystałaby na posiadaniu 8 procesorów wirtualnych, ale w żadnym momencie wszystkie te 8 rdzeni nie powinny działać z pełnym obciążeniem – ponieważ spowodowałoby to takie przeciążenie serwera, że inne maszyny wirtualne i CT dostałyby się do mniej procesora. Ustawiliśmy więc limit cpulimit na 4,0 (= 400%). Jeśli wszystkie rdzenie wykonują tę samą ciężką pracę, wszystkie otrzymają 50% rzeczywistego czasu procesora rdzeni hosta. Ale gdyby tylko 4 działały, nadal mogłyby uzyskać prawie 100% prawdziwego rdzenia.
Drugie ustawienie ograniczenia zasobów procesora, jednostki cpuunits (obecnie często nazywane udziałami procesora lub wagą procesora), kontroluje, ile czasu procesora otrzymuje maszyna wirtualna w porównaniu z innymi uruchomionymi maszynami wirtualnymi. Jest to waga względna, która domyślnie wynosi 100 (lub 1024, jeśli host używa starszej wersji cgroup v1). Jeśli zwiększysz to dla maszyny wirtualnej, program planujący nada jej priorytet w porównaniu z innymi maszynami wirtualnymi o mniejszej wadze. Na przykład, jeśli maszyna wirtualna 100 ustawiła domyślną wartość 100, a maszynę wirtualną 200 zmieniono na 200, ta ostatnia maszyna wirtualna 200 otrzyma dwukrotnie większą przepustowość procesora niż pierwsza maszyna wirtualna 100.
Zarządzanie kontenerem z linii komend
Więcej informacji na temat dostępnych poleceń do zarządzania kontenerem LXC w Proxmox: https://pve.proxmox.com/wiki/Linux_Container. Testowy kontener z Debian 11 o nazwie debianlxc ma id 135.
# lista dostępnych kontenerów
pct list
VMID Status Lock Name
135 running debianlxc
136 running certbot
# start i stop oraz restart kontenera
pct start 135
pct stop 135
pct reboot 135
# ubicie zawieszonego kontenera
pct kill 135
#lub gdyby nie chciało zadziałać to z konsoli serwera Proxmox, gdzie 135 to id kontenera
ps aux | grep "/usr/bin/lxc-start -F -n 135" | grep -v grep | awk '{print $2}' | xargs kill -9
# zmiana nazwy kontenera LXC
pct set 135 --hostname newhostname
# zmiana w locie liczby rdzeni dla kontenera LXC
pct set 135 --cores 4
# zmiana w locie dostępnej ilości pamięci dla kontenera LXC
pct set 135 --memory 2048
# zmiana w locie dostępnej ilości SWAP dla kontenera LXC
pct set 135 --swap 4096
# zmiana w locie cpu units i cpu limit
pct set 135 --cpuunits 1024 --cpulimit 50
# wejście do kontenera
pct enter 135
# wykonanie polecenie w kontenerze z poziomu konsoli serwera Proxmox
pct exec 135 apt update && apt upgrade
# zmiana rozmiaru dysku podstawowego kontenera
pct resize 135 rootfs 10G
Rozwiązanie problemu bardzo długiego logowania na konsoli w kontenerze
systemctl mask systemd-logind
