Search Results
Znaleziono 142 elementy dla „”
- Proxmox warsztaty part 2
Hej przed nami warsztaty z proxmox - część dryga. Na pierwszej edycji było ponad 200 osób. MOże ta liczba Cię nie zachwyca ale co jak Ci powiem że wszystkie te osoby dostały na czas warsztatów laba z proxmox konfiguracją 3 node. Czyli podczas 2 godzinnych warsztatów było ponad 600 działajacych i zautomatyzowanych maszyn. Zaciekawiony to wpadaj na warsztaty zapisy ruszaja tu https://szkolenia.cloud/warsztaty-proxmox/ A warsztaty juz 13.11.2024 o godzinie 14:00 i potrwają 2 godziny
- Q&A do warsztatów z proxmox
W tym artykule odpowiem na pytania, które się pojawiły podczas warsztatów proxmox. Pytania zostały zapisane w formie tekstowej - uczestnicy warsztatów mieli miejsce gdzie mogli zadawać pytania. Zatem nie przeciągając oto te pytania i odpowiedzi. Wasze pytanie, moje odpowiedzi Pytanie nr 1: Rozproszyłem się na Sniepetach, są gdzieś dostępne skrypty których używałeś omawiając ten temat? Odpowiedź: Tak, skrypty użyte w warsztatach dostępne są na repozytorium git w bitbucket możesz sklonować lub użyć fork dla tego repozytorium. Jeżeli chodzi o Snippet dla Proxmox to po pierwsze w domyślnej konfiguracji musisz dla danego storage właczyć ta opcje ona domyślnie nie jest włączona. Zatem dla demonfs będzie to w /mnt/pve/demonfs/snippets a dla local-lvm bedzie to /var/lib/vz/snippets/ Pytanie nr 2: Upgrade wersji z pve 7 do 8 z Ceph , na co zwracać uwagę, jak się zabezpieczyć przed ewentualnych fckupem Odpowiedź: Upgrade w proxmox nigdy nie był prostym tematem. Podrzucam link do oficjalnej dokumentacji proxmox już na początku by o nim nie zapomnieć. Sam proxmox w swojej dokumentacji mówi o dwóch sposobach aktualizacji. Sposób pierwszy Sposób najdroższy w moim odczuciu ponieważ wymaga od nas bliźniaczej konfiguracji - tzn aktualizacji robimy po prostu instalująć nowsza wersję w tej samej konfiguracji i przenosimy dane na nowa instancje klastrową. Lub Tworzymy backup i na hoscie gdzie mieliśmy stara wersje instalujemy nową. Pamietajmy o backup! proxmox w swojej dokumentacji fajnie to opisuje co należy skopiować. Przedstawione są też kroki tej operacji Wykonaj kopię zapasową wszystkich maszyn wirtualnych (VM) i kontenerów na zewnętrzne urządzenie magazynujące (zobacz Kopia zapasowa i przywracanie). Wykonaj kopię zapasową wszystkich plików w katalogu /etc. Wymagane: pliki w /etc/pve, a także /etc/passwd, /etc/network/interfaces, /etc/resolv.conf oraz wszystko, co odbiega od domyślnej instalacji. Zainstaluj najnowszą wersję Proxmox VE 8.x z pliku ISO (spowoduje to usunięcie wszystkich danych na istniejącym hoście). Wyczyść pamięć podręczną przeglądarki i/lub wymuś ponowne załadowanie (CTRL + SHIFT + R, lub dla macOS ⌘ + Alt + R) interfejsu Web UI. Odtwórz klaster, jeśli dotyczy. Przywróć plik /etc/pve/storage.cfg (spowoduje to udostępnienie zewnętrznego magazynu używanego do kopii zapasowej). Przywróć konfigurację zapory sieciowej z /etc/pve/firewall/ oraz /etc/pve/nodes//host.fw (jeśli dotyczy). Przywróć wszystkie maszyny wirtualne z kopii zapasowych (zobacz Kopia zapasowa i przywracanie). Administratorzy zaznajomieni z wierszem poleceń mogą postępować zgodnie z procedurą Pomijanie kopii zapasowej i przywracania przy aktualizacji, jeśli wszystkie maszyny wirtualne i kontenery znajdują się na jednym wspólnym magazynie. Musimy pamiętać, że to nie jest proces szablonowy i trzeba indywidualnie podchodzić do każdego przypadku przygotowywując sobie checklistę, sprawdzając podwójnie wszystkie elementy. Sposób drugi Aktualizacja przez pakiety - z wykorzystaniem apt. Tutaj też należy pamiętać o backup. Pamiętajmy też by nasza obecna wersje podnieść do jak najnowszej w ramach danej wersji. Czyli jak mamy wersje 7 aktualizujemy ja do wersji 7 latest. Jak mamy na klastrze Ceph to zajrzyjmy do dokumentacji jaka wersja będzie wymagana przed aktualizacją i czy mamy ja podbić przed czy po aktualizacji. Wszystko ładnie jest opisane w danym procesie aktualizacji między wersjami Wady i zalety. Jeden i drugi sposób ma swoje wady i zalety. Elementem wspólnym jest backup w jednym jak i w drugim przypadku powinien być wykonany i przetestowany przed aktualizacją. Wady pierwszego rozwiązania to w przypadku gdy instalujemy wersję 8 na wersji 7 to tracimy dane i mamy je tylko w backup. Posiadanie dwóch redundantnych konfiguracji jest drogim rozwiązaniem i jeszcze stwarza problem sieci. - dla drugiego osobnego klastra trzeb stworzyć nowa sieć i uważać na overlap adresów sieciowych. I najważniejsze niestety nie ma magicznej różdżki czy skryptu który to za nas załatwi - musimy do tego przysiąść i sobie to rozpisać. Pytanie nr 3: czy bardzo niezalecane jest korzystanie z klastra tylko w konfiguracji dwóch hostów ? Odpowiedź: Korzystanie z klastra Proxmox w konfiguracji z tylko dwoma hostami jest ogólnie niezalecane , głównie ze względu na problemy z kworum, które mogą wpłynąć na stabilność i dostępność usług. Dlaczego kworum jest ważne? Kworum to mechanizm, który zapewnia spójność danych w klastrze przez wymaganie większości dostępnych węzłów do podejmowania decyzji. W klastrze z dwoma węzłami większość wynosi 2, co oznacza, że jeśli jeden węzeł ulegnie awarii, klaster traci kworum i przestaje działać prawidłowo. W konfiguracji wysokiej dostępności (HA) w klastrze Proxmox liczba hostów powinna być nieparzysta (3, 5, 7 itd.), aby zapewnić prawidłowe działanie mechanizmu kworum i uniknąć problemów z dostępnością. Oto dlaczego taka liczba hostów jest zalecana: Zapewnienie kworum: Klaster HA wymaga kworum, aby podejmować decyzje dotyczące stanu klastra. Kworum oznacza, że większość hostów musi być dostępna, aby klaster mógł działać. Przy liczbie hostów 3, 5, 7 itd., zawsze można osiągnąć większość głosów nawet po utracie jednego lub kilku węzłów. Na przykład: W klastrze 3-hostowym kworum wynosi 2. Oznacza to, że klaster może dalej działać, gdy jeden host jest niedostępny. W klastrze 5-hostowym kworum wynosi 3, co pozwala na awarię dwóch hostów. W klastrze 7-hostowym kworum wynosi 4, umożliwiając utratę do trzech hostów. Unikanie sytuacji split-brain: W przypadku parzystej liczby hostów istnieje ryzyko sytuacji split-brain, gdzie część hostów uważa się za oddzielne klastry, co może prowadzić do konfliktów i utraty danych. Użycie nieparzystej liczby węzłów minimalizuje to ryzyko, ponieważ zawsze jest możliwe osiągnięcie większości głosów. Lepsze rozłożenie zasobów i odporność na awarie: Większa liczba hostów w konfiguracji nieparzystej pozwala na lepsze rozłożenie obciążenia i zapewnia większą odporność na awarie. Im więcej węzłów, tym klaster jest bardziej odporny na utratę poszczególnych hostów, co zwiększa dostępność usług. Skalowalność i przyszłe rozszerzenia: Rozbudowa klastra w sposób skalowalny jest łatwiejsza, gdy dodaje się nieparzyste liczby hostów (np. z 3 do 5, z 5 do 7), co zachowuje odpowiednią konfigurację kworum. Problemy z klastrem dwuwęzłowym: Brak tolerancji na awarie : Awaria jednego węzła powoduje utratę kworum i potencjalne zatrzymanie usług. Split-brain : W przypadku problemów z siecią oba węzły mogą działać niezależnie, prowadząc do niespójności danych. Ograniczone możliwości HA : Funkcje wysokiej dostępności (HA) są ograniczone lub wymagają dodatkowej konfiguracji. Możliwe rozwiązania: Dodanie trzeciego węzła : Nawet jeśli jest to mały serwer lub urządzenie pełniące rolę tylko głosu w kworum. Użycie qdevice (Quorum Device) : Dodatkowy serwer lub usługa, która pomaga w osiągnięciu kworum w klastrze dwuwęzłowym. Konfiguracja tie-breaker : Specjalne ustawienia, które pomagają w rozwiązywaniu konfliktów kworum, ale mogą być skomplikowane i nie zawsze niezawodne. Rekomendacje: Najlepsza praktyka : Użycie co najmniej trzech węzłów w klastrze Proxmox dla zapewnienia stabilności i pełnej funkcjonalności. Jeśli musisz użyć dwóch węzłów : Dokładnie przemyśl i skonfiguruj mechanizmy dodatkowe (np. qdevice) oraz przygotuj się na potencjalne komplikacje. Podsumowanie: Korzystanie z klastra dwu węzłowego w Proxmox nie jest zalecane ze względu na ryzyko utraty kworum i związane z tym problemy. Jeśli zależy Ci na stabilności i wysokiej dostępności, warto zainwestować w trzeci węzeł. Oczywiście w środowisku domowym mozna to zrobić na dwóch węzłach z Quorum Device. W środowiskach produkcyjnych moim zdaniem jest to mega cebula, bo często osoby decyzyjne nie rozumieją tego mechanizmu i nie wiedzą że Quorum Device nie zapewnia nam hosta na, którym uruchomimy maszyny wirtualne a jedynie hosta do decyzji w przypadku gdy mamy 2 hosty. I decydują w takim przypadku na podstawie ceny (2 nody są tansze od 3 nodów). Dlatego uważam że w środowisku produkcyjnym powinno być to jawnie omówione wpisane w draft lub plan implementacji i podpisane przez osobe decyzyjna z zaznaczeniem że rozumie wszelkie konsekwencje zastosowanego rozwiązania. Pytanie nr4: Jakie są podstawowe wymagania odnośnie postawienia Windows na proxmoxie? Ile najlepiej ramu wypadałoby mieć, bo słyszałem, że Windows jest pamięciożerny. Im więcej tym lepiej, ale odpowiedź nie jest taka prosta. Zależy głownie od tego co będziesz robił na tym windows. Ja osobiście wykorzystywałem maszynę wirtualną na proxmox z windows do świadczenia jej jako agent w Team City do budowania i kompilowania bibliotek i kodu dla naszych aplikacji (w firmie w której pracowałem). Pod spodem mieliśmy dyski NVMe (w proxmox) dla maszyny wirtualnej udostępnione przez virtio ze wskazaniem na dysk NVMe, Ramu miał 12 GB, Grafika domyślna - nie była potrzebna. CPU 1 Socket, 8 Core. I działało świetnie. A i w ustawieniach vm był w trybie host. Pytanie nr 5: Jak najlepiej robić backup wszystkich wirtualnych maszyn? Nawet jak sporo ważą to można to przenieść na dysk podpięty na sata a nie nvme? Backup można wykonywać na NFS, SMB, CIFS, local storage itp - i tak można podpiąc dysk dodatkowy na stałe lub przez USB i tam robić backup. Jednak lepszym rozwiązaniem jest wydaje mis ie cloud storage zgodny z s3 i tam wysyłanie synchronizowanie backupu. Pytanie nr 6: Czy postawienie proxmox na zewnątrz portami idzie dobrze zabezpieczyć pod kontem włamania? Zależy mi na ustawieniu proxmoxa na zewnątrz i mógłbym sterować wszystkimi maszynkami nie będąc w domu, zastanawiałem się nad vpn wireguard, ale jakie duże ryzyko wiąże się z takim rozwiązaniem? Tak można dobrze zabezpieczyć interfejs GUI proxmoxa. Najprostsza metoda to firewall przed z filtracja adresów IP. Ja bym w tym przypadku użył rozwiązania Nord VPN z dedykowanym adresem IP. Wtedy ten adres dodajesz do firewall proxmox i po sprawie. Dedykowany adres IP jest przypisywany tylko do Ciebie. Fajne rozwiązanie. Pytanie nr 7: a ja mam pytanie apropo przygotowywania tego demo-środowiska tworząc proxmoxy (poszczególne node) utworzyłeś jeden obraz, przeklikałem instalacje -> zrobiłeś template i rozrzuciłem terraformem z gotowego obrazu? czy jakas inna metoda? Odpowiedź jest prosta i banalna - autoinstaller od proxmox on to wspiera sam w sobie. Omawiam też to w moim ostatnim wpisie . W skrócie tworzymy answer plik z konfiguracją i dodajemy go do naszego instalatora. Pytanie nr 8: Czy zwiększanie ilości nodów poprawia wydajność dużo bardziej niż dokładanie OSD do istniejących nodów? OSD w CEPH uruchamia się na fizycznych dyskach wtedy ma się najlepszy performance. Czyli lepiej dodac nowy fizyczny dysk i na nim utworzyć kolejny OSD. Nie ma potrzeby dodawania nowych węzłów. Pytanie nr 9: Jeśli chodzi o FC, jaka jest możliwość podłączenia macierzy SAN do Proxmox Możliwość podłączenia jest: Sprawdzenie kompatybilności sprzętu: Upewnij się, że serwer Proxmox jest wyposażony w odpowiednie karty HBA (Host Bus Adapter) Fibre Channel, które są kompatybilne z Twoją macierzą SAN. Sprawdź, czy sterowniki dla kart HBA są poprawnie zainstalowane w systemie. Połączenie fizyczne: Podłącz kable Fibre Channel od kart HBA w serwerze Proxmox do przełącznika FC lub bezpośrednio do macierzy SAN (w zależności od topologii sieci). Pytanie nr 10: Jeśli na VM proxmox zabraknie RAM, to VM się zawiesza, jest szansa w jakiś sposób się do niej dostać, czy tylko siłowe ubicie? Może próbować opcji KVM shared memory? Aby włączyć “Kernel Same-page Merging” (KSM) dla maszyn wirtualnych w Proxmox, musisz skonfigurować odpowiednie parametry na poziomie systemu operacyjnego hosta oraz w ustawieniach maszyn wirtualnych. KSM pozwala na dzielenie wspólnej pamięci pomiędzy maszynami wirtualnymi, co może prowadzić do oszczędności pamięci RAM. Oto kroki, które należy wykonać: Włącz KSM na hoście Proxmox: Sprawdź, czy KSM jest już włączony: cat /sys/kernel/mm/ksm/run Jeśli wynik to 0, KSM jest wyłączony. Aby włączyć KSM, wykonaj: echo 1 > /sys/kernel/mm/ksm/run Opcjonalnie, możesz dostosować parametry, takie jak liczba stron do skanowania na cykl (pages_to_scan) lub interwał między cyklami skanowania (sleep_millisecs): echo 1000 > /sys/kernel/mm/ksm/pages_to_scan echo 200 > /sys/kernel/mm/ksm/sleep_millisecs Skonfiguruj maszynę wirtualną do używania KSM: Otwórz plik konfiguracyjny maszyny wirtualnej, który znajduje się w /etc/pve/qemu-server/VMID.conf, gdzie VMID to identyfikator maszyny wirtualnej. Dodaj lub zmodyfikuj linię: balloon: 1 Opcja ta włącza “Memory Ballooning”, co jest zalecane przy używaniu KSM. Automatyzacja dla grupy lub puli maszyn: Jeśli chcesz włączyć KSM dla wszystkich maszyn wirtualnych w danej grupie lub puli, możesz użyć skryptu Bash do automatycznego modyfikowania konfiguracji. Przykładowy skrypt: for VMID in $(pvesh get /cluster/resources --type vm | jq -r '.[] | select(.pool == "nazwa_puli") | .vmid'); do qm set $VMID --balloon 1 done Ten skrypt ustawia “Memory Ballooning” dla wszystkich maszyn wirtualnych w określonej puli. Restart maszyn wirtualnych: Aby zmiany zaczęły działać, konieczne może być zrestartowanie maszyn wirtualnych. Po tych krokach KSM będzie działał dla wybranych maszyn wirtualnych, co pozwoli na lepsze wykorzystanie pamięci RAM. Pytanie nr 11: W małym biznesie jest zazwyczaj kilka-kilkanaście VM, jakś płatnik, comarch, często muszą działać 24h. Na lokalnych dyskach SSD działa to znośnie. Jaką konfigurację byś zalecił przy przejściu na Ceph aby stworzyć prawdziwe HA? Proszę nie pisz "to zależy" :) Ceph w zwirtualizowanym labie działa dość topornie, jak by było w rzeczywistości? 3 nody? 5 nodów? W każdym nodzie kilka nvme? (ile min?) Baza ceph koniecznie na osobnych dyskach? Sieć pomiędzy nodami 10Gb wydaje się wystarczająca, ale może lepiej 25Gb? W labie na którym pracowaliśmy działało to topornie dlatego że to było środowisko testowe do zabawy. Po drugie mieliśmy zagnieżdżoną wirtualizację. Udostępniony dla Ciebie lab w postaci serwera z Ubuntu już był maszyna wirtualną, na niej dopiero uruchomiliśmy proxmoxa a potem tam uruchomiliśmy maszynę wirtualną. Czyli mieliśmy tak naprawdę 3 zagnieżdżenie (tzw nesting virtualization). Dyski które tworzyliśmy też były zwirtualizowane nie były to fizyczne dyski tylko pliki. CEPH już napisałem to wcześniej najlepiej działa na fizycznych dyskach. Działa na HDD, SSD, NVMe - no i tutaj ograniczać cię już będzie interfejs. Jak wybierzesz HDD to Ceph będzie wolniejszy niż w przypadku NVMe. Ceph Storage można sprawdzić i porównać zapis fio na storage sieciowym i dedykowanym dysku. I tu im szybsza sieć tym lepiej. Musisz sprawdzić czy dyski użyte w twojej konfiguracji wykorzystają w pełni łącze. No i też należy pamiętać o przyszłej rozbudowanie czy ją planujesz. Zwiększanie liczby nodów w klastrze Ceph ma znaczący wpływ na wydajność i niezawodność systemu. Oto kilka kluczowych punktów, które warto wziąć pod uwagę: Redundancja i odporność na awarie : Zwiększenie liczby nodów zwiększa odporność klastra na awarie. Ceph rozkłada dane na różne nody, tworząc kopie (replikacje) danych. Przy większej liczbie nodów, klaster może lepiej zarządzać redundancją, co zmniejsza ryzyko utraty danych w przypadku awarii jednego z nodów. Balansowanie obciążenia : Większa liczba nodów oznacza więcej zasobów (CPU, RAM, sieć) do dyspozycji klastra. Dzięki temu Ceph może lepiej balansować obciążenie, zwłaszcza jeśli chodzi o I/O. Zwiększenie liczby nodów rozkłada operacje zapisu i odczytu na więcej dysków (OSD), co może przyspieszyć operacje w systemie. Skalowalność wydajności I/O : Ceph jest skalowalnym systemem, co oznacza, że zwiększanie liczby nodów i OSD (Object Storage Daemons) może bezpośrednio wpłynąć na zwiększenie wydajności operacji I/O. W scenariuszu z pięcioma nodami, gdzie każdy z nich posiada po jednym OSD na dysku 300 GB, system będzie miał więcej możliwości równoległego przetwarzania operacji w porównaniu do trzech nodów. Może to poprawić przepustowość (bandwidth) oraz zmniejszyć opóźnienia (latency). Efektywność przy dużej ilości danych : Przy większej liczbie nodów Ceph lepiej radzi sobie z dużą ilością danych, ponieważ dane są przechowywane i rozpraszane na większej liczbie urządzeń, co przyspiesza operacje odczytu i zapisu. Wiec jak widac to zależy od konfiguracji - więcej nie znaczy zawsze lepiej musimy pamiętać że w przypadku CEPH to zestaw naczyń połączonych i zwiększanie jednego parametru wpływa na inne parametry. Pytanie nr 12: Czasami VM od strony GUI Proxmox się tak zawiesza, że nie wiadomo czy w ogóle umarła czy może jest do odratowania. Konsola nie działa. Jest szansa w jakiś sposób się do niej dostać, czy tylko siłowe ubicie? Może próbować opcji KVM shared memory? KSM to nie jest idealne rozwiazanie. Pytanie czy zawieszanie jest spowodowane tym że uruchamiasz za dużo maszyn wirtualnych czy po stronie kodu działającego na maszynie wirtualnej. Można też spróbować ustawić połączenie do maszyny wirtualnej z poziomu tty portu szeregowego. Funkcja, której szukasz, to “Serial Console” w KVM (konsola szeregowa). Umożliwia ona połączenie się z maszyną wirtualną poprzez interfejs konsolowy za pomocą narzędzia virsh. Oto kroki, jak to skonfigurować: Skonfiguruj maszynę wirtualną do używania konsoli szeregowej: Musisz edytować plik XML definicji maszyny wirtualnej, aby dodać interfejs konsoli szeregowej. Możesz to zrobić, używając polecenia: virsh edit nazwa_maszyny W pliku XML dodaj następujący wpis w sekcji : Skonfiguruj system operacyjny maszyny wirtualnej: Na maszynie wirtualnej musisz skonfigurować system operacyjny, aby umożliwił logowanie przez konsolę szeregową. W systemach Linux wykonaj następujące kroki: Edytuj plik /etc/default/grub i dodaj parametr dla kernela: GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0" Zaktualizuj konfigurację GRUB: sudo update-grub Skonfiguruj getty, aby nasłuchiwał na porcie szeregowym. Dodaj lub odkomentuj linię w pliku /etc/inittab lub utwórz plik /etc/systemd/system/serial-getty@ttyS0.service.d/override.conf: [Service] ExecStart= ExecStart=-/sbin/agetty --keep-baud 115200,9600 ttyS0 $TERM Połącz się z maszyną wirtualną przez virsh: Po skonfigurowaniu możesz połączyć się z konsolą szeregową używając polecenia: virsh console nazwa_maszyny W Proxmox VE, konfiguracja dostępu do konsoli szeregowej dla maszyny wirtualnej jest podobna, ale proces jest nieco uproszczony, ponieważ interfejs graficzny Proxmox ułatwia konfigurację. Oto kroki, jak skonfigurować konsolę szeregową w Proxmox: Skonfiguruj konsolę szeregową w ustawieniach maszyny wirtualnej: W interfejsie Proxmox VE, wybierz maszynę wirtualną, którą chcesz skonfigurować. Przejdź do zakładki Hardware , a następnie kliknij Add -> Serial Port . Dodaj port szeregowy (serial0) do maszyny wirtualnej. Skonfiguruj system operacyjny maszyny wirtualnej: Jeśli maszyna wirtualna korzysta z systemu Linux, skonfiguruj ją tak, aby umożliwić logowanie przez konsolę szeregową: Edytuj plik /etc/default/grub i dodaj parametr dla kernela, np.: GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0" Zaktualizuj konfigurację GRUB: sudo update-grub Skonfiguruj getty, aby nasłuchiwał na porcie szeregowym, np. edytując lub tworząc plik /etc/systemd/system/serial-getty@ttyS0.service.d/override.conf: [Service] ExecStart= ExecStart=-/sbin/agetty --keep-baud 115200,9600 ttyS0 $TERM Połącz się z konsolą szeregową: W interfejsie webowym Proxmox VE, przejdź do zakładki Console dla wybranej maszyny wirtualnej. Wybierz opcję Serial Terminal z menu rozwijanego. Zostanie wyświetlona konsola szeregowa dla maszyny wirtualnej. Dzięki temu możesz uzyskać dostęp do maszyny wirtualnej przez konsolę szeregową, co jest przydatne do diagnostyki lub pracy z systemami bez interfejsu graficznego. Pytanie nr 13: Czy drbd będzie wyraźnie lepszy od ceph zakładając małą ilość OSD? W przypadku małej liczby OSD, DRBD może być lepszym wyborem niż Ceph, w zależności od specyficznych wymagań. Oto kilka kluczowych czynników do rozważenia: Replikacja danych : DRBD to rozwiązanie do replikacji blokowej, które synchronizuje dane między dwoma lub więcej węzłami w trybie aktywny-aktywny lub aktywny-pasywny. Jest bardziej wydajne przy mniejszych konfiguracjach, ponieważ wymaga mniej zasobów niż Ceph i lepiej radzi sobie z małą ilością węzłów. Ceph, z drugiej strony, jest rozproszonym systemem pamięci masowej, który osiąga większą wydajność przy większej liczbie OSD i węzłów. Skalowalność : Ceph jest projektowany z myślą o skalowalności i lepiej sprawdza się w środowiskach z większą liczbą OSD. Przy małej liczbie OSD Ceph może mieć niższą wydajność i wyższą latencję, ponieważ jego architektura rozproszona wymaga więcej metadanych i operacji kontrolnych. Zarządzanie : DRBD jest prostsze do wdrożenia i zarządzania w małych środowiskach, szczególnie tam, gdzie liczba węzłów jest ograniczona. Ceph wymaga bardziej zaawansowanej konfiguracji i monitorowania, nawet w małych środowiskach. Redundancja i dostępność : DRBD jest idealne do wysokiej dostępności w małych środowiskach, gdyż replikacja synchroniczna pozwala na szybkie przełączanie awaryjne. Ceph natomiast oferuje bardziej zaawansowane opcje odporności na awarie, takie jak erasure coding i wielopoziomowe replikowanie, które stają się bardziej efektywne przy większej liczbie OSD. Wybór między Ceph a DRBD zależy od specyfiki środowiska, wymagań dotyczących skalowalności, wydajności, redundancji, oraz zadań, jakie chcesz realizować. Oto porównanie obu rozwiązań pod kątem różnych czynników: Skalowalność Ceph : Jest zaprojektowany z myślą o dużych, skalowalnych środowiskach. Można łatwo dodawać nowe węzły i zwiększać pojemność, co sprawia, że Ceph jest idealny dla dużych infrastruktur chmurowych i centrów danych. DRBD : Lepszy w małych środowiskach lub klastrach wysokiej dostępności (HA), gdzie liczba węzłów jest ograniczona (najczęściej 2-3). Skalowanie poza małą liczbę węzłów może być trudne i mniej efektywne. Replikacja danych Ceph : Replikuje dane w sposób rozproszony na wielu węzłach, oferując wysoką dostępność i odporność na awarie. Jest w stanie automatycznie rozproszyć dane na różnych poziomach, oferując opcje replikacji i kodowania wymazywalnego (erasure coding). DRBD : Oferuje replikację synchroniczną na poziomie blokowym pomiędzy dwoma lub więcej węzłami. Replikacja jest ściśle związana z warstwą blokową, co sprawia, że jest bardziej ograniczona niż w przypadku Ceph, który ma bardziej rozbudowane mechanizmy dystrybucji danych. Wydajność Ceph : Przy większej liczbie węzłów może zapewnić wysoką wydajność dzięki rozproszonemu modelowi zapisu i odczytu. Jednak w małych konfiguracjach (2-3 węzły) może mieć większą latencję i niższą wydajność niż DRBD. DRBD : Zapewnia niską latencję i wysoką wydajność w mniejszych środowiskach, zwłaszcza przy synchronicznej replikacji. Jest lepszym wyborem, gdy priorytetem jest szybki zapis/odczyt w małym klastrze. Zarządzanie i konfiguracja Ceph : Wymaga bardziej zaawansowanej konfiguracji i jest trudniejszy w zarządzaniu, szczególnie dla mniejszych zespołów IT. Ceph jest jednak bardzo elastyczny i może oferować różne rodzaje pamięci masowej (blokową, plikową, obiektową). DRBD : Jest prostszy w konfiguracji i zarządzaniu, co sprawia, że jest łatwiejszy do wdrożenia w małych klastrach lub jako rozwiązanie do replikacji danych. Odporność na awarie Ceph : Jest bardzo odporny na awarie dzięki swojej rozproszonej architekturze. Węzły mogą się awaryjnie wyłączać, a Ceph będzie w stanie automatycznie przenosić dane i odtwarzać replikacje, aby zapewnić dostępność danych. DRBD : Oferuje wysoką dostępność na poziomie blokowym i szybkie przełączanie awaryjne (failover), ale w przypadku większych awarii wymaga ręcznego odzyskiwania danych lub przełączania. Pytanie nr 14: Ceph Monitor, po logrotate wywala błąd braku miejsca na dysku mimo dostępnej przestrzeni i trzeba go restartować, jak sobie z tym poradzić na produkcji Pytanie co wrzuca komunikat ceph monitor czy logrotate jak logrotate to moze to jest problem w samym logroate. Pytanie jak jest uruchomione natywna aplikacja czy w kontenerze? To jest dużo niewiadomych. Dlatego proszę autora o przykłady i szersze opisanie problemu - może to zrobić w sekcji komentarzy pod tym artykułem. Pytanie nr 15: Czy da sie ustawic jakis dedykowany IP klastra aby miec dostęp do GUI tylko z dedykowanego? Tak da się - możemy wystawić nasz interface GUI bezpośrednio na publicznym IP lub przez port jakiś. I w ustawieniach firewall zezwolić na komunikację z konkretnym adresem. Pytanie nr 16: Jak najlepiej zautomatyzować cały proces tworzenia klastra. Kilka dni temu przyjechał mi sprzet na ktorym chce zainstalowac wlasnie klaster proxmoxowy. Założenie jest takie ze wszystko ma byc oskryptowane, 0 klikania Auto installer, ansible, terraform, bash, cloud-init tych technologi bym użył. W kolejnej edycji labów będę to poruszał więc zapraszam do obserwowania. Pojawi się to też w moim kursie proxmox (video) i dedykowanym szkoleniu online i stacjonarnym . Pytanie nr 17: Mamy w firmie repo NFS z ISO, ale ten Repo jest read-only Proxmox nie chce go podpiac bo nie moze w nim pisac. Jest jakies obejscie? Tak, można obejść problem podłączenia repozytorium NFS jako read-only w Proxmox, stosując poniższe rozwiązania: Podłączenie jako lokalny katalog : Możesz zamontować repozytorium NFS na serwerze Proxmox jako lokalny katalog w systemie operacyjnym hosta. Montowanie można zrobić przez dodanie wpisu do /etc/fstab, np.: nfs_server:/ścieżka/do/iso /mnt/nfs/iso nfs ro 0 0 Następnie w Proxmox dodajesz katalog /mnt/nfs/iso jako zasób “Directory”. W konfiguracji zasobu wybierasz typ “ISO image”, co umożliwi dostęp do obrazów ISO w trybie read-only. Podłączenie NFS z flagą no_root_squash: Jeśli masz kontrolę nad serwerem NFS, możesz skonfigurować eksport tak, aby wyłączyć root_squash, co może rozwiązać problem dostępu do repozytorium. W pliku /etc/exports na serwerze NFS dodaj opcję no_root_squash dla danego eksportu: /ścieżka/do/iso *(ro,sync,no_root_squash) Po modyfikacji konfiguracji zrestartuj usługę NFS na serwerze. Utworzenie lokalnej kopii ISO : Alternatywnie, jeśli obrazy ISO nie są często zmieniane, można je skopiować lokalnie na serwer Proxmox i używać z lokalnej przestrzeni dyskowej. Skrypty synchronizujące mogą być używane do regularnego aktualizowania kopii lokalnej. Symboliczne linki : Możesz też utworzyć symboliczne linki w lokalnym katalogu Proxmox, które wskazują na pliki ISO na montowanym repozytorium NFS. Któraś z tych metod powinna pozwolić na podłączenie repozytorium ISO w Proxmox mimo ograniczeń read-only. Pytanie 18: Tworząc VM lepiej dawać np. 4 CPU i 1 Core czy 1 CPU i 4 Core? Jaka jest różnica? Różnica między przypisaniem zasobów wirtualnych maszyn (VM) jako 4 CPU i 1 Core a 1 CPU i 4 Core polega na sposobie, w jaki system operacyjny i hypervisor zarządzają tymi zasobami. Oto główne różnice: 4 CPU i 1 Core : Oznacza to, że maszyna wirtualna otrzymuje 4 procesory fizyczne (vCPU), z których każdy ma tylko jeden rdzeń. Taka konfiguracja może być przydatna, jeśli maszyna wirtualna uruchamia aplikacje, które lepiej działają przy większej liczbie fizycznych procesorów. Niektóre starsze systemy operacyjne i aplikacje mogą korzystać z wielu procesorów, ale niekoniecznie z wielu rdzeni na jednym procesorze. Może prowadzić do większego narzutu na hypervisorze, ponieważ musi on zarządzać większą liczbą osobnych jednostek procesora. 1 CPU i 4 Core : Oznacza to, że maszyna wirtualna otrzymuje jeden procesor, który ma cztery rdzenie. W większości nowoczesnych systemów operacyjnych i aplikacji, które są zoptymalizowane pod kątem wielowątkowości, taka konfiguracja może być bardziej efektywna. Jest to bardziej naturalna reprezentacja nowoczesnych procesorów fizycznych, gdzie jeden procesor ma wiele rdzeni. Może mieć mniejszy narzut na hypervisorze, co pozwala na bardziej efektywne zarządzanie zasobami. Kiedy wybrać którą konfigurację? Aplikacje wielowątkowe (np. serwery baz danych, nowoczesne aplikacje serwerowe): Zazwyczaj lepiej wykorzystają konfigurację z mniejszą liczbą CPU i większą liczbą rdzeni (np. 1 CPU i 4 Core). Starsze aplikacje lub systemy operacyjne , które nie są zoptymalizowane do pracy na wielu rdzeniach, mogą lepiej działać przy konfiguracji z większą liczbą CPU (np. 4 CPU i 1 Core). W praktyce warto eksperymentować z różnymi ustawieniami, aby zobaczyć, która konfiguracja działa lepiej dla konkretnego obciążenia w danym środowisku. Podsumowanie Odpowiedź na pytania zamyka nam warsztaty w 100%. Oczywiście to tylko pierwsza część. Zapraszam do obserwowania bo już niebawem warsztaty z proxmox część druga. Dziękuje za uwagę Piotr Kośka
- Proxmox automatyzacja instalacji
W prezentowanym materiale na moim kanale na temat przygotowania do automatyzacji mojego labu można było zaobserwować, że proces instalacji proxmoxa był automatyczny. Oczywiście było to jak najbardziej pożądane ponieważ przechodzenie przez instalację nawet po prostu klikając dalej... dalej... byłoby dość długim procesem. I co to za atrakcja na warsztatach przechodzić przez instalację systemu proxmox, którą można zrobić w domu i na pewno każdy adept proxmoxa ją przechodził z kilkadziesiąt razy. W przypadku mojej konfiguracji zależało mi na tym by proces był jak najbardziej bezobsługowy. Bynajmniej na początku czyli na etapie instalacji naszego proxmoxa. Dzięki takiemu podejściu mogłem przygotować środowisko labowe dla 200 osób. Gdzie każdy z uczestników miał finalnie przygotowanego proxmoxa. Cały kod dostępny jest na bitbucket w publicznym repozytorium Zacznijmy od początku - wymaganie proxmox Do uruchomienia środowiska labowego z proxmox jest nam potrzebne absolutne minimum: Maszyna fizyczna z procesorem 64 bitowym Maszyna wirtualna z procesorem 64 bitowym Można o tym poczytać w dokumentacji proxmox na temat wymagań sprzętowych - proxmox na innych architekturach nie działa. Inne parametry to kwestia wygody pracy czy dostępności domowego portfela. Oczywiście rozmawiamy tutaj o środowisku do zabawy w domowym zaciszu a nie pełnoprawnym produkcyjnym rozwiązaniu. I tu jest nasz pierwszy problem. Jak dostarczyć każdemu takie samo środowisko by mieć pewność że będzie działać one tak samo dla każdego z 200 słuchaczy i uczestników prezentowanych warsztatów. Zastosowanie bare-metal nie jest idealne bo każdy będzie miał inne. Nie każdy będzie miał 3 węzły. Ktoś przydzieli sobie 10 GB RAMu inny 2GB RAMu. I będzie a u mnie działa, a u mnie nie :(. Dlatego proces trzeba było zautomatyzować. Zatem rozwiązanie bare-metal odpada. Kontrola miała zostać po mojej stronie. Maszyna wirtualna W cloud możemy tanio uruchomić maszynę wirtualną, kosztuje ona kilka centów/groszy za działanie instancji. U wielu dostawców jestesmy rozliczany za czas uruchomienia nie za commitment. Czyli jak maszyna działa nam dwie godziny płacimy za dwie godziny. U niektórych dostawców nawet jest tak, że jak maszyna wirtualna jest wyłączona to płacimy grosze za storage używany przez nasze dane przechowywane na dyskach dostawcy. We wcześniej wspomnianej dokumentacji o wymaganiach proxmox możemy wyczytać: Proxmox VE can be installed as a guest on all common used desktop virtualization solutions as long as they support nested virtualization. Dlatego musimy sprawdzić czy nasza maszyna wirtualna jest wstanie uruchomić proxmoxa oraz wykorzystać jego potencjał. Aby sprawdzić, czy maszyna jest w stanie uruchomić Proxmox, warto zwrócić uwagę na kilka kluczowych punktów: Wsparcie dla Wirtualizacji Zagnieżdżonej (Nested Virtualization) : Sprawdź, czy maszyna obsługuje wirtualizację zagnieżdżoną. Jest to warunek niezbędny, gdyż Proxmox sam jest platformą wirtualizacji i wymaga tej funkcji do poprawnego działania jako gość w środowisku innego hypervisora. Na maszynie z procesorem Intel : użyj komendy cat /sys/module/kvm_intel/parameters/nested. Jeśli wynik to Y, wirtualizacja zagnieżdżona jest wspierana. Na maszynie z procesorem AMD : użyj komendy cat /sys/module/kvm_amd/parameters/nested. Wynik 1 oznacza wsparcie dla wirtualizacji zagnieżdżonej. Obsługa VT-x (dla Intel) lub AMD-V (dla AMD) : Jeśli masz dostęp do konfiguracji sprzętowej, upewnij się, że maszyna posiada wsparcie dla technologii wirtualizacyjnej VT-x (Intel) lub AMD-V (AMD). Można to sprawdzić w BIOS-ie lub użyć polecenia: egrep -c '(vmx|svm)' /proc/cpuinfo Wynik większy niż 0 wskazuje na wsparcie wirtualizacji sprzętowej. Na DigitalOcean nasz maszyny wirtualne uruchamiane w tym cloud wspierają zagnieżdżoną wirtualizację. I tym samy nie mówię, że inne cloudy tego nie wspierają. A wybór padł na DigitalOcean ponieważ miałem już tu inną konfigurację którą wykorzystuje do mich szkoleń. I mam tu napisane środowisko które mi to automatyzuje. Więc skupiam sie tylko na wkładzie pod proxmox, nie na konfiguracji całości. Wkład Automatyzacja w moim przypadku opiera się na terraform, który zapewnia automatyzację środowiska. W kilka sekund tworzy lub usuwa zasoby, które są opisane językiem HCL. O terraform możesz nauczyć się z moich kursów dostępnych na platformie szkoleniowej . Dodatkowo do terraform jest dodawany cloud-init zawierający instrukcje bash które konfigurują moje środowisko. Dzięki tym dwóm technologią mogłem uruchomić środowisko dla 200 słuchaczy dostarczając im prekonfigurowanego proxmoxa. Jeżeli jest ktoś zainteresowany kosztami warsztatów ile mnie to wyniosło poniżej przedstawiam dane: Koszt warsztatów. Do automatyzacji wykorzystałem github actions, który jest opłacany rocznie (48$) zatem koszt działania github action w tym jednym dniu wyniósł = 0,131 $. Gitflow uruchomiłem o godzinie 13:00 (godzinę przed warsztatami) w celu spokojnego uruchamiania się wszystkich skryptów. Sam terraform wykonywał się dokładnie 13 minut 37 sekund - dalsze 46 minut i 23 sekundy przeznaczyłem na spokojne uruchomienie się skryptów i automatyczna instalację proxmox do etapu gdzie była dostępna konfiguracja trzech nodów z dostępem do interfejsu www proxmoxa. Sam cloud-init potrzebuje między 15 - 20 minut na przygotowanie środowiska. Dlatego start o 1h wcześniej był strategicznym posunięciem. Gdzie maszyny uruchomione w końcówce konfiguracji terraform były gotowe na 13:50 - czyli 10 minut przed startem warsztatów. Warsztaty trwały 2 godziny i skończyły się o 16. Wyłączenie warsztatów i posprzątanie ich terraform zajęło 15 minut i 33 sekundy. Przyjmijmy zatem że całość trwała 4 godziny i za ten czas byłem rozliczany w digitalocean. Transfer danych był za darmo w ramach przydzielonego pakietu do maszyn wirtualnych więc tu mamy 0$. Mamy zatem 200 maszyn wirtualnych, compute jaki wykorzystałem (size tak nazywa się ten atrybut w digitalocean) to s-4vcpu-16gb-320gb-intel (4 cpu, 16GB RAM i 320 GB storage, na procesorze intel). Spójrzmy na cenę tego produktu. Cena za godzinę działania takiej maszyny wirtualnej to 0.143$. A i do całości trzeba uwzględnić testy które przeprowadzałem by sprawdzić czy całe środowisko będzie działać. Poniżej rachunek za ten miesiąc w digitalocean: Najważniejsze kluczowe pozycje to: Basic Intel Droplet - 16 GB / 4 vCPU / 320 GB SSD @ $96.00/mo ($0.14286/hr) Basic Intel Droplet - 32 GB / 8 vCPU / 640 GB SSD @ $192.00/mo ($0.28571/hr) Basic AMD Droplet - 32 GB / 8 vCPU / 400 GB SSD @ $168.00/mo ($0.25000/hr) Premium Intel Droplet - 64 GB / 32 vCPU / 400 GB SSD @ $874.00/mo ($1.30060/hr) Te pozycje brały udział w przygotowaniach do warsztatów jaki i w samych warsztatach. LP Compute Cena Ilość 1 Basic Intel Droplet - 16 GB / 4 vCPU / 320 GB SSD $0.14286/hr 434 2 Basic Intel Droplet - 32 GB / 8 vCPU / 640 GB SSD 0.28571/hr 12 3 Basic AMD Droplet - 32 GB / 8 vCPU / 400 GB SSD $0.25000/hr 2 4 Premium Intel Droplet - 64 GB / 32 vCPU / 400 GB SSD $1.30060/hr 6 Basic Intel Droplet - 16 GB / 4 vCPU / 320 GB SSD - 434 instancje, a to dlatego że raz zrobiłem testowe uruchomienie i sprawdzenia czy wszystko się postawi Basic Intel Droplet - 32 GB / 8 vCPU / 640 GB SSD i Basic AMD Droplet - 32 GB / 8 vCPU / 400 GB SSD to eksperyment, testowanie środowiska, te testy powiedziały mi że dla słuchaczy w zupełności wystarczy Basic AMD Droplet - 32 GB / 8 vCPU / 400 GB SSD. Czyli zrobiłem oszczędność rzędu 0,14285 $ na każdej instancji :) uruchomionej dla słuchacza. Premium Intel Droplet - 64 GB / 32 vCPU / 400 GB SSD - to już mój host z ktorego robiłem warsztaty i demonstrowałem działanie środowiska. Jak widać maszyna ma znacznie większe osiągi. Było to celowe zagranie. Dawało mi to pewność działania i płynność funkcjonowania warsztatów. Podsumowanie wydatków Podsumujmy teraz to. 217 osób zgłosiło chęć udziału w warsztatach i dla tylu osób były przygotowane maszyny wirtualne. 217 * 0,14286 = 31,00062$. Tą wartość należy pomnożyć przez 4h działania warsztatów co daje nam 124,00248$. Oczywiście już widzimy że w digitalocean naliczanie jest proporcjonalne ponieważ uruchomienie 434 instancji typu Basic Intel Droplet - 16 GB / 4 vCPU / 320 GB SSD kosztowało mnie 117,60$ zatem ta kwotę podzielimy na dwa. 58,8$ + 10,40$ = 69,2$ to koszt uruchomienia warsztatów. Testy wyniosły mnie 58,8$ + 4,62$ + 0,5$ = 63,92$. Całość kosztowała mnie 132,52$ co daje 0,61$ na uczestnika. Automatyzacja Oczywiście kluczowym aspektem całości była automatyzacja. Bez niej nie udałoby mi się w tak krótkim czasie uruchomić i skonfigurować 217 maszyn wirtualnych. Terraform miał za zadanie przygotować infrastrukturę. Uruchomić sieć i ją skonfigurować. Potem w tej sieci uruchomić maszynę wirtualną. przypisać do tej maszyny wirtualnej domenę z AWS route 53 Cloud-init był odpowiedzialny za konfigurację maszyny wirtualnej i uruchomienia akcji w odpowiedniej kolejności. Mieszankę tych technologii oraz efekt końcowy można było zobaczyć na warsztatach, obejrzeć na YouTube i poczytać w kodzie źródłowym Auto installer Proxmox ma mechanizmy auto instalacji , który pomógł w przygotowaniu tych warsztatów. W dokumentacji możemy poczytać o tym aby zautomatyzować ten proces musimy przygotować plik answer.toml który zawiera przykładowa konfigurację [global] keyboard = "pl" country = "pl" fqdn = "pvedemo03.example.in" mailto = "proxmox@example.in" timezone = "Europe/Warsaw" root_password = "${password}" root_ssh_keys= ["$ssh_key"] [network] source = "from-dhcp" [disk-setup] filesystem = "ext4" lvm.hdsize = 50 disk_list = ["vda"] Parametry te automatyzuja nam konfigurację - wszystkie pozycje opisane są w dokumentacji dostępnej tu , zatem pominę omawianie ich w tym artykule. Tak przygotowane pliki answer posłużyły do przygotowania obrazów, które pomogły zautomatyzować cały proces instalacji i konfiguracji proxmoxa z KVM. # Generowanie obrazu ISO dla maszyny z odpowiednim plikiem answer.toml sudo proxmox-auto-install-assistant prepare-iso "$BASE_ISO_PATH" \ --fetch-from iso \ --answer-file "$ANSWER_FILE" \ --output "$CUSTOM_ISO_PATH" a cały skrypt i jego kod dostępny jest na publicznym repo w bitbucket. Całość można obudowac w github action czy inne narzędzie CI/CD - Budowa pipeline może już w osobnym artykule opiszę. Jednak jeżeli chcesz pobawić się proxmox w cloud to poniżej masz instrukcję która pozwoli Ci uruchomić to repozytorium: Klonujemy lokalnie repozytorium . poleceniem np: git clone https://accountszkoleniacloud@bitbucket.org/szkoleniacloud/proxmox_digitalocean_terraform_configuration.git Instalujemy terraform Po instalacji przechodzi do sklonowanego repozytorium i szukamy pliku variables.tf na podstawie niego możemy zabudować nasz plik .auto.tfvars, który może wyglądać tak do_token = "TU WKLEJ WARTOŚĆ SWOJEGO TOKENA" # NADPISZ DOMYSLNE ZMIENNE PODAJC ICH NAZYW I WARTOŚCI. size = "c-32-intel" # zmieni to domyślny compute size Po utworzeniu tego pliku .auto.tfvars wystarczy wydać polecenie terraform init; terraform plan; terraform apply - po 2-3 minutach nasza maszyna wirtualna będzie dostępna. A mniej więcej po 15-20 minutach będzie zainstalowany i skonfigurowany proxmox na 3 węzłach. Przypominam że całość procesu można obejrzeć na YouTube Zapraszam do testów i po więcej wpisów i materiałów.
- Proxmox - przygotuj sobie laba adhoc
Witajcie. Poniższy post jest dla wszystkich którzy chcą pobawić się proxmox ale z jakieś przyczyny nie mają lub nie mogą mieć laba w domu. Poniższa konfiguracja działa w cloud na digitalocean. Tu masz dostępny link który da Ci na 60 dni 200$ do testowania chmury digitalocean. W zupełności to wystarczy by pobawić sie proxmox Automatyzacja Całość konfiguracji jest zautomatyzowana - wiec nie musisz pamiętać o tym co i jak musisz skonfigurować i usunąć by nie narażać się na dodatkowe koszty. Kod w terraform jest dostępny w repozytorium bitbucket Wystarczy sklonować poleceniem: git clone https://bitbucket.org/szkoleniacloud/proxmox_digitalocean_terraform_configuration.git I możemy przystąpić do działania. Oczywiście musimy mieć zainstalowanego terraforma i konto na digitalocean. Potrzebne bedzie nam też klucz API - zakłada sie go po stworzeniu konta w digitalocean. Tworzymy plik o nazwie .auto.tf.vars z zawartością naszego tokena do_token = "TU WKELJ SWOJ TOKEN" Potem już tylko terraform init, terraform plan i terraform apply - po zakończonej zabawie terraform destroy. Jak to działa prezentują to te dwa poniższe filmy na Youtube: Proxmox - manualna konfiguracja Proxmox - pełna automatyzacja
- DevOps news 2024-04-02
Garść ciekawych artykułów znalezionych w sieci z tematyki IT, DevOPS, AI, IaC,, automatyzacji oraz wszystkiego co ciekawe :) - Zapraszam Coraz więcej wrażliwych danych w github - Deweloperzy nie dbają o bezpieczeństwo? Dyski z pamięcią DNA coraz bliżej. Nadchodzi nowy standard nośników Uruchomili ChatGPT w arkuszu Excela. Plik waży 1,2 GB i każdy może go wypróbować Oni już tracą pracę przez sztuczną inteligencję. Dług technologiczny to bolączka wszystkich firm, które pracują z technologiami w mniejszym bądź większym stopniu. Zaczyna on być jednak coraz bardziej odczuwalny Orchiestracja aplikacji i cloud nigdy nie była taka prosta O tym jak z pomocą AI tworzyć fałszywe dokumenty tożsamości Self hosted własny DNS serwer - bezpieczny i szybki Kodowanie za pomocą głosu w Visual Studio Code z Copilot Voice Co może pójść nie tak przy tworzeniu gry za pomocą AI Chatbot nie chce dać Ci przepisu na kontrukcje bomby, czy receptury na nowy narkotyk - ASCII pozwala obejść ograniczenia narzucone chatbotom. GhostRace - nowa luka zagraża wszystkim architecture CPU Chcesz się zapisać i być na bierząco zapraszam https://szkolenia.cloud/devops
- DevOps Newsletter 2024-03-19
Hej witam w kolejnej porcji nowości oto kilka tematów które przykuły moja uwagę w poprzednim tygodniu. Zapraszam. P.S na nwesletter zapisać się możesz tu https://szkolenia.cloud/devops/ OpenTofu 1.7.0-alpha1 to nowa wersja alfa, która wprowadza szyfrowanie stanu, usunięcie bloku i poprawki kompatybilności. Jest dostępna do testów społeczności, ale nie zaleca się jej stosowania w środowiskach produkcyjnych. Użytkownicy mogą pobrać wersję i przekazać opinie poprzez formularz lub Slack OpenTofu. Ciekawe spojrzenie i przemyślenia jak AI może wpłynąć na nasze życie. Autor zdaje pytanie czy inżynierowie (programiści) są skazani na zagładę wraz z rozwojem AI Używacie wtyczek do OpenAI/ChatGPT? To uważajcie na nową formę ataku która umożliwia przestępcą pozyskanie danych czy przejęcia konta. Obecnie mocno jest tu opisywana forma skupiająca się na OpenAI i ChatGPT ale pewnie w przyszłości dowiemy się też o pluginach/wtyczkach zainfekowanych do lokalnych modeli LLM - gdzie użytkownicy znacznie częściej będą wprowadzać poufne dane - bo przecież działa lokalnie. Nowy mechanizm ulepszonej ochrony adresów URL w czasie rzeczywistym od Google - czy okaże się on lekarstwem na strony udające inna stronę i próbujące wykraść nasze dane. Jest to zmana obecnego meachnizmu który, to przechowywał listę takich url lokalnie na naszej maszynie/telefonie/tablecie. Co ciekawe powstawanie nowych stron/domen phishingowych rośnie a 60% z nich istnieje krócej niż 10 minut. Ostatnio na moim kanale na YouTube pojawił się materiał o tym jak udostępniam swoje domowe serwisy na świat tak by mieć do nich dostęp z każdego miejsca na świecie. I tak przy okazji Warto też przypomnieć o dobrych praktykach związanych z zabezpieczeniem SSH w roku 2024 Na koniec auto reklama - jeżeli szukasz szkolenia dla siebie lub Twojej organizacji z tematyki terraform i chcesz nauczyć się tego języka od podstaw to zapraszam do 4 dniowego szkolenia nażywo https://terraform.szkolenia.cloud/
- DevOps news i nie tylko 2024-03-12
W najnowszym wydaniu newslettera odkryjemy najświeższe aktualizacje i narzędzia technologiczne, od wzmocnionej bezpieczeństwa i wsparcia dla MongoDB w Postfix 3.9, przez innowacyjne możliwości Kubernetes w OpenMediaVault 7, po wprowadzenie wsparcia dla wirtualizacji i usprawnień bezpieczeństwa w Linux Kernel 6.8. Ponadto, przyjrzymy się nowym funkcjom KeePassXC 2.7.7 w zakresie importowania haseł, zagrożeniom cybernetycznym wykorzystującym emulator QEMU, a także taktykom hakerskim grupy BianLian. Zaprezentujemy również kurs generatywnej AI od Microsoftu, odkryjemy Obsidian jako narzędzie do planowania i zarządzania projektami, podzielimy się wrażeniami z NeoVim oraz nauczymy technik nigdy nie zapominania w zakresie przyswajania wiedzy. Odkryj nowości w Postfix 3.9: wsparcie dla MongoDB, ulepszone klienty MySQL/pgSQL i zwiększone bezpieczeństwo. Ta aktualizacja popularnego agenta transferu poczty wprowadza wiele istotnych ulepszeń, m.in. wsparcie dla MongoDB, elastyczniejsze ustawienia czasowe dla klientów MySQL i PostgreSQL oraz opcjonalne wsparcie dla surowych kluczy publicznych w komunikacji TLS. Przeczytaj więcej o tych zmianach, które czynią Postfix jeszcze bardziej elastycznym i bezpiecznym rozwiązaniem dla serwerów e-mail. Rozszerz możliwości swojego serwera NAS z OpenMediaVault 7 dzięki nowemu pluginowi opartemu na K3s, który wprowadza możliwości Kubernetes. Ten lekki dystrybucja Kubernetes zaprojektowana jest z myślą o prostocie i efektywności zasobów, idealna do zastosowań w obliczeniach brzegowych i urządzeniach IoT. Plugin oferuje preinstalowany cert-manager, Traefik jako kontroler Ingress, automatyczne tworzenie woluminów trwałych dla istniejących folderów udostępnionych i wbudowany dashboard Kubernetes. Linus Torvalds ogłosił wydanie jądra Linux 6.8, wprowadzając wsparcie dla wirtualizacji LAM, obsługę pamięci guest-first dla KVM, i mechanizmy naprawy systemu plików Bcachefs. Nowości obejmują także wsparcie dla procesora Broadcom BCM2712 w Raspberry Pi 5, funkcje AMD do łagodzenia interferencji w paśmie Wi-Fi, i wiele innych ulepszeń związanych z bezpieczeństwem, wydajnością oraz wsparciem sprzętowym. KeePassXC 2.7.7 przynosi nowości, jak importowanie haseł z 1Password i Bitwarden, obsługę PassKeys i USB hotplug dla interfejsu Hardware Key. Poprawia bezpieczeństwo, minimalizując ryzyko ataków przez kanały boczne i ulepsza integrację przeglądarki. Cyberprzestępcy wykorzystują emulator QEMU jako narzędzie do tunelowania, aby naruszyć sieć firmową. Atakujący użyli tego otwarto źródłowego emulatora sprzętu, aby połączyć się z infrastrukturą firmy. Jest to pierwszy znany przypadek wykorzystania QEMU w celu tunelowania, co stanowi nową strategię dywersyfikacji ataków. Badacze podkreślają, że wykorzystywanie legalnych narzędzi przez cyberprzestępców nie jest nowością, co potwierdza konieczność wielopoziomowej ochrony obejmującej niezawodną ochronę punktów końcowych i specjalistyczne rozwiązania do wykrywania i ochrony przed złożonymi i ukierunkowanymi atakami Hakerzy z grupy BianLian wykorzystują luki w oprogramowaniu JetBrains TeamCity do przeprowadzania ataków z oprogramowaniem wymuszającym okup. Wykorzystują oni specyficzne podatności, aby uzyskać początkowy dostęp do systemów, a następnie rozmieszczają złośliwe oprogramowanie i narzędzia zdalnego dostępu. Zidentyfikowane działania wskazują na zmianę taktyki grupy, która teraz skupia się na wyłącznie na ekstrakcji danych i szantażowaniu ofiar. Generatywna sztuczna inteligencja dla początkujących Bezpłatny kurs generatywnej sztucznej inteligencji firmy Microsoft podzielony na 18 lekcji. - github Jeżeli tak jak ja używasz Notion to jest dla Ciebie darmowa alternatywa. Odkryj, jak skonfigurować Obsidian do planowania treści i zarządzania projektami. Artykuł prowadzi przez instalację Obsidiana, dostosowywanie jego wyglądu i włączanie wtyczek społeczności, takich jak Templater i Tasks, aby usprawnić procesy twórcze. Znajdziesz tutaj praktyczne wskazówki, jak za pomocą szablonów i list zadań zorganizować swoje pomysły oraz projekty, sprawiając, że zarządzanie nimi staje się łatwiejsze i bardziej intuicyjne. Będąc w podróży do Warszawy i przez protesty oraz spowodowane korki miałem więcej czasu na dodatkowy rozwój i poznanie narzędzi - NeoVim Poznaj system "nigdy nie zapominania": opanowanie sztuki zatrzymywania wiedzy. Artykuł opiera się na wideo, które przedstawia techniki na efektywniejsze czytanie książek i zatrzymywanie wiedzy. Kluczowe wskazówki obejmują ponowne uczenie się czytania, koncentrację na zrozumieniu treści, wielokrotne czytanie rozdziałów, robienie notatek i zastosowanie analogowych narzędzi takich jak fiszki do przyswajania wiedzy. Całość koncentruje się na skutecznym zapamiętywaniu i wykorzystywaniu zdobytych informacji. I zapomnij o zapominaniu - brzmi jak reklama aptecznego specyfiku, lecz naprawdę warto obejrzeć materiał. Zapraszam Do newslettera można się zapisać tu https://szkolenia.cloud/devops/
- 80% zniżki na szkolenia.cloud
Jeszcze tylko dzisiaj obowiązuje 80% zniżki na szkolenia wideo na platformie szkolenia.cloud Zanurz się w szkolenia w z wirtualizacji, kontereryzacji, automatyzacji i procesów CI/CD. Zobacz jak zautomatyzować pracę z wykorzystaniem terraform. Zapraszam. KNOW80 - to kod który da Ci zniżkę w wysokości 80% na cały koszyk i na wszystkie szkolenia wideo.
- DevOps News i nie tylko - 2024-03-04
Hej, Witajcie w pierwszym newsletterze na mojej stronie. Będzie to przekrój aktualności i ciekawych materiałów na, które natrafiłem w poprzednim tygodniu biegając po internecie. Możliwe że znajdziesz coś ciekawego dla siebie lub poznasz jakieś narzędzie którego nie znałeś :). Zapraszam. P.S - a newsletter będzie pokazywał się co tydzień we wtorek :) :D Do samego newslettera można się zapisać tu: https://szkolenia.cloud/devops/ Lub na tej stronie do globalnych wiadomości i artykułów publikowanych na tej stronie :) Ponad 100 000 Zainfekowanych repozytoriów na github - W ostatnim badaniu zespół Apiiro odkrył, że ponad 100,000 repozytoriów na GitHubie zostało zainfekowanych za pomocą kampanii repo confusion. Atak, polegający na podszywaniu się pod znane i zaufane repozytoria, zagraża milionom, gdy programiści nieświadomie korzystają z zainfekowanych wersji. Złośliwe repozytoria, zawierające obciążone malware, są promowane w sieci, co prowadzi do kradzieży danych przez złośliwe oprogramowanie. Apiiro podkreśla potrzebę monitorowania kodu w celu wykrywania złośliwych ładunków i zabezpieczenia całej organizacji. Odkryj przyszłość hostowania z "Self-Hosting is Dead. Hybrid is the Way to Go". Ten porywający artykuł rzuca światło na ewolucję infrastruktury IT, przekonując, że model hybrydowy jest kluczem do zrównoważonego rozwoju, elastyczności i bezpieczeństwa w dzisiejszym cyfrowym świecie. Zanurz się w dyskusji o korzyściach płynących z połączenia chmury z lokalnymi zasobami, by zrozumieć, dlaczego hybryda dominuje na horyzoncie technologicznym. Idealna lektura dla tych, którzy szukają inspiracji do modernizacji swojej infrastruktury IT! Jak korzystać z kontenerów testowych w Jenkins CI - "Odkryj nowatorskie podejście do testowania w Jenkins CI z użyciem Testcontainers!" Ten praktyczny artykuł na blogu Docker pokazuje, jak skutecznie wykorzystać Testcontainers na Jenkins CI, zwiększając efektywność i niezawodność procesów CI/CD. Przewodnik krok po kroku wprowadza w świat dynamicznych kontenerów i Kubernetes pods jako agentów, oferując łatwe do zastosowania rozwiązania dla testów opartych na Testcontainers. To niezbędna lektura dla każdego dewelopera i specjalisty DevOps szukającego sposobów na optymalizację i automatyzację testów w środowiskach CI. Odkryj nieodkryte skarby wśród aplikacji dla Maca z "Top Free Utility Mac Apps You Aren’t Using"! Ten artykuł przewodnik po wyselekcjonowanych, darmowych narzędziach ujawnia, jak w pełni wykorzystać potencjał Twojego Maca, podnosząc produktywność i optymalizując przepływ pracy. Z aplikacjami, które mogą nie być jeszcze na Twoim radarze, ale zasługują na miejsce w Twoim arsenale narzędziowym, jest to must-read dla każdego użytkownika Maca poszukującego sposobów na ulepszenie swojego cyfrowego życia Zainspiruj swoją podróż deweloperską z "7 Best Podcasts for Newbie Devs"! Ten artykuł to brama do świata podcastów, które są idealne dla początkujących programistów, pragnących pogłębić swoją wiedzę i umiejętności. Od inspirujących historii przejścia do branży IT po techniczne dyskusje i praktyczne wskazówki – te podcasty oferują wsparcie, motywację i edukację. Niezależnie od tego, czy jesteś w trakcie nauki kodowania, czy szukasz sposobów na rozwój w swojej karierze deweloperskiej, znajdziesz coś dla siebie. To doskonały sposób, by uczyć się i rosnąć nawet wtedy, gdy jesteś w ruchu! "Odkryj, jak przekształcić setki wysłanych CV w oferty pracy z '50 Golden Tips for Landing a Tech Job in 15 Months'! Ta dogłębna analiza oferuje nieocenione wskazówki i strategie, które pomogły autorowi przejść od frustrującej poszukiwania pracy do otrzymania dwóch ofert pracy. Artykuł zawiera praktyczne porady dotyczące przygotowania do rozmów kwalifikacyjnych, optymalizacji CV, skutecznego networkingu i wykorzystania platform pracy. Niezależnie od tego, gdzie jesteś w swojej karierze technologicznej, te złote porady mogą pomóc Ci wyróżnić się na rynku pracy" Zapraszam Piotr "TheRealMamuth" Kośka. Miłej lektury.
- Terraform 1.7.0 stable
Terraform w wersji 1.7.0 stable wydany - https://github.com/hashicorp/terraform/blob/v1.7.0/CHANGELOG.md warto zapoznac sie z chcnge log do tej wersji i ze wszystkimi nowiściami
- Kurs Proxmox dostepny
🚀 Odkryj Świat Proxmox: Profesjonalny Kurs Dla Wszystkich, Którzy Chcą Zostać Ekspertami! 🌟 Hej, entuzjaści IT! Czy jesteście gotowi poszerzyć swoje horyzonty w świecie wirtualizacji? Przedstawiamy nasz flagowy kurs Proxmox, zaprojektowany z myślą o zapewnieniu Wam przewagi w dynamicznie zmieniającym się świecie technologii. 👨💻🌐 Dlaczego warto wybrać nasz kurs? Kompleksowe Moduły: Nasz kurs obejmuje od instalacji Proxmox, przez konfigurację, aż po zaawansowane techniki zarządzania. Dwa starannie zaplanowane moduły oferują łącznie 153 minuty intensywnego szkolenia. Wiedza od Ekspertów: Nasze lekcje są prowadzone przez doświadczonych profesjonalistów, którzy dzielą się praktycznymi wskazówkami i najlepszymi praktykami. Dostępność i Elastyczność: Ucz się w swoim tempie, gdziekolwiek jesteś, z dostępem do materiałów kursowych online. Co Zyskasz? 🔹 Solidne Fundamenty: Zrozumiesz podstawy Proxmox, co jest niezbędne dla każdego aspirującego administratora. 🔹 Zaawansowane Umiejętności: Poznasz techniki zarządzania i optymalizacji, które wyróżnią Cię na rynku pracy. 🔹 Praktyczne Doświadczenie: Nasz kurs stawia na praktyczne umiejętności, które możesz od razu zastosować w swojej pracy. Dla Kogo Jest Ten Kurs? ✅ Dla początkujących, którzy chcą wejść w świat Proxmox. ✅ Dla średnio zaawansowanych użytkowników, szukających pogłębienia wiedzy. ✅ Dla profesjonalistów IT, którzy chcą zaktualizować swoje umiejętności. 🎓 Zapisz Się Dziś! Nie przegap tej wyjątkowej okazji, aby zanurzyć się w świecie Proxmox. Zapisz się już teraz i zacznij swoją podróż do zostania ekspertem Proxmox! 👉 Kliknij Tutaj, aby dowiedzieć się więcej i zarejestrować się! Dołącz do Naszej Społeczności IT! 💬 Podziel się tym postem ze swoimi znajomymi i dołącz do naszej rosnącej społeczności entuzjastów IT. Razem możemy osiągnąć więcej! 🔥 #Proxmox #ITTraining #BecomeAnExpert #Virtualization #TechnologyEducation
- Zastrzeganie numery PESEL - można już od dziś! - nie zwlekaj
Już dziś dostaliśmy funkcje zastrzegania numeru pesel. Funkcja ta ma na celu ochronic nas przed kradzieżą tożsamości. Mówiąc teraz gdy w banku, w telekomie lub innej instytucji ktoś zrobi operacje na nasze dane to po stronie tychże instytucji będzie spoczywał obowiązek na weryfikacje naszych danych oraz czy ów pesel nie jest zastrzeżony. Choć i tu musze dodać łyżkę dziekciu. Obowiązek ten bedzie dobiero nakładny od 1 czerwca 2024 - do tego czasu wszystkie instytucje mogą nie musza z tego korzystać - czyli swoisty czas na integracje systemów. Aktywacja. Funkcjonalność aktywowania zastrzeżenia będzie z poziomu internetu, osobistej wizyty w placówce pocztowej lub bankowej. Zalecam pierwszą opcje czyli internet - w moim przypadku była to strona mobywatel.gov.pl Jest też możliwość przez aplikację na telefonach - mobywatel, jednak u mnie tej opcji jeszcze nie było. I jak patrzyłem mam starsza wersje aplikacji, a nowszej na czas pisania artykułu jeszcze nie mogłem pobrać. Kroki - aktywacji online Przechodzimy na stronę https://www.gov.pl/web/gov/zastrzez-swoj-numer-pesel-lub-cofnij-zastrzezenie rozwijamy sekcje co musisz zrobić i tu mamy cały opis. Co musisz zrobić Kliknij przycisk Zastrzeż PESEL lub cofnij zastrzeżenie i zaloguj się. System przeniesie cię do mObywatel.gov.pl Wybierz sekcję Twoje dane, a następnie Rejestr zastrzeżeń PESEL. Wybierz Zastrzeż PESEL lub Cofnij zastrzeżenie. Jeśli chcesz cofnąć zastrzeżenie numeru PESEL, możesz to zrobić: bezterminowo lub określić datę i godzinę, kiedy system automatycznie zastrzeże ponownie twój numer PESEL. Jak widać to bardzo proste.
- Automatyzacja tworzenia diagramów infrastruktury.
Tworzenie diagramów swojej przyszłej infrastruktury to dobry koncept. Pozwala zwizualizować wygląd naszej infrastruktury oraz łatwiej rozplanować kod gdy nasze konfiguracje w cloud powstają na przykład w terraform. Jednak jak to czesto bywa na etapie pisania kodu czy walidacji kosztów plany naszej konfiguracji się zmieniają - a szkielety infrastruktury w formie (rysunku) pozostają w niezmienionej formie lub z tylko nie wielkimi poprawkami. A co gdyby ten proces zautomtyzować - i dostarczyć gotową dokumentacje wizualną wraz z implementacją naszej infrastruktury? Narzędzie TerraVision Terravision to narzędzie wiersza poleceń (CLI), które konwertuje kod Terraform na dynamiczne, profesjonalne diagramy architektury chmury. Głównym celem Terravision jest utrzymanie aktualności najważniejszego dokumentu w projektach chmurowych - dokumentu architektury. W dobie szybkich wydań, automatycznie generowane diagramy architektury są bardziej precyzyjne niż ręcznie rysowane przez architekta chmury, które mogą już nie odzwierciedlać rzeczywistości. Terravision działa w 100% po stronie klienta, bez zależności od Terraform lub dostępu do środowiska chmurowego. Narzędzie to dynamicznie analizuje warunkowo tworzone zasoby i zmienne, generując automatyczny wizualny obraz architektury. Jest zaprojektowane jako narzędzie 'Docs as Code' (DaC), które można włączyć do pipeline'u CI/CD, aby aktualizować diagramy architektury po fazach budowania, testowania i wdrażania. W prosty sposób jak to jest przedstawione w repozytorium kodu. To czyli nasz kod w bardzo prosty sposób i szybki możemy zamienić na diagram Zalety Terravision Koszt Oszczędność na licencjach oprogramowania do tworzenia diagramów/rysunków - Terravision jest darmowe i open source Nie wymaga korzystania z zasobów chmury obciążających kosztami, działa natychmiastowo na lokalnej maszynie Regularna aktualizacja diagramów, łączenie punktów i rozmieszczanie ikon nie jest najlepszym wykorzystaniem kosztów pracowników architektury Przyspieszenie i automatyzacja Użyj plików zmiennych TF jako danych wejściowych do tworzenia wielu wariantów diagramów z tego samego kodu TF Automatyzuj tworzenie diagramów architektury, uruchamiając terravision jako część potoków CI/CD Diagramy oparte na YAML jako kod pozwalają na dodawanie do wygenerowanych diagramów dodatkowych niestandardowych etykiet i zasobów, np. zasobów niezarządzanych lub zewnętrznych systemów nieuchwyconych w kodzie TF Spójność w całej organizacji Automatyczne pobieranie modułów organizacyjnych / zewnętrznych, aby zapewnić najnowszy widok modułów Terraform Spójny projekt diagramów architektury z użyciem standardowych ikon branżowych i zatwierdzonego stylu AWS/GCP/Azure w zespołach Dokładna widoczność Diagram w czasie rzeczywistym pokazuje aktualną infrastrukturę, która dokładnie odpowiada temu, co jest wdrożone w produkcji dzisiaj Pomoc w przeglądach architektury stron trzecich, audytach, monitoringu, raportowaniu i debugowaniu stosu w sposób wizualny Kod diagramu niestandardowego i obrazy wyjściowe mogą być umieszczane w kontroli źródła/wersji dla lepszej utrzymania i odkrywalności Bezpieczeństwo Nie trzeba dawać dostępu do konta AWS lub CLI, aby rysować diagram Nie tworzy intruzywnych zasobów chmury, np. instancji skanujących lub tabel metadanych, które przedsiębiorstwa musiałyby zatwierdzić Cały kod źródłowy pozostaje w lokalnym środowisku, diagramy są generowane na twoich maszynach bez wywoływania zewnętrznych API Instalacja i Użycie Zależności dla wszystkich wersji graphviz https://graphviz.org/download/ git https://git-scm.com/downloads Szybki start Zainstaluj wszystkie zależności, jak wyżej wymieniono. Sklonuj repozytorium: git clone https://github.com/patrickchugh/terravision.git. Uzyskaj pełną ścieżkę do katalogu roboczego, wykonując cd terravision i pwd. Dodaj folder terravision do swojej zmiennej PATH, np. export PATH=$PATH:/Users/<ŚCIEŻKA DO TERRAFORM>, aby móc uruchamiać go z dowolnego miejsca. <ŚCIEŻKA DO TERRAFORM> to wynik z punktu 3. Zainstaluj wymagane biblioteki Pythona: cd terravision && pip install -r requirements.txt. Upewnij się, że skrypt pythonowy terravision jest wykonywalny: chmod +x terravision. Uruchom terravision, określając pliki źródłowe Terraform w formacie: $ terravision draw --source ~/src/my-terraform-code Dla kodu źródłowego Terraform w repozytorium Git, można również użyć formy: $ terravision draw --source https://github.com/twoje-repozytorium/terraform-examples.git Użyj znaku // dla podfolderów w repozytoriach Git, jeśli kod, który chcesz, znajduje się pod hierarchią folderów. $ terravision draw --source https://github.com/twoje-repozytorium/terraform-examples.git//mysubfolder/secondfolder/ Przykładowe Terraformy do wypróbowania Nie związane z moim projektem, ale oto kilka przykładów Terraform od osób trzecich do wypróbowania: terravision draw --source https://github.com/futurice/terraform-examples.git//aws/aws_static_site --varfile examples/variables.tfvars --show terravision draw --source https://github.com/futurice/terraform-examples.git//aws/wordpress_fargate --varfile examples/variables.tfvars --show terravision draw --source https://github.com/k-mitevski/terraform-k8s.git//01_terraform_eks --show Annotowanie wygenerowanych diagramów Żaden automatycznie wygenerowany diagram nie będzie miał wszystkich potrzebnych szczegółów, w najlepszym przypadku dostarczy 80-90% potrzebnych informacji. Aby dodać niestandardowe adnotacje, takie jak główny tytuł diagramu, dodatkowe etykiety na strzałkach lub dodatkowe zasoby utworzone poza Terraform, dołącz plik architecture.yml w folderze kodu źródłowego, a zostanie on automatycznie załadowany. Alternatywnie, określ ścieżkę do pliku z adnotacjami jako parametr dla terravision. terravision --source https://github.com/twoje-repozytorium/terraform-examples.git --annotate /Users/me/MyDocuments/annotations.yml Plik .yml to standardowy plik konfiguracyjny YAML, podobny do poniższego przykładu, z jednym lub więcej nagłówkami takimi jak title, connect, disconnect, add, remove lub update. Nazwy węzłów odpowiadają konwencjom nazw zasobów Terraform https://registry.terraform.io/providers/hashicorp/aws/latest/docs i obsługują znaki wieloznaczne. Możesz dodać niestandardową etykietę do dowolnego zasobu TF, modyfikując atrybuty zasobu i dodając atrybut label (nieistniejący w Terraform). Dla linii/połączeń możesz modyfikować atrybuty zasobu, dodając specyficzne dla terravision edge_labels, aby dodać tekst do linii połączenia z konkretnym węzłem zasobu. Zobacz poniższy przykład: format: 0.1# Main Diagram headingtitle: Serverless Wordpress Site# Draw new connection lines that are not apparent from the Terraformsconnect: aws_rds_cluster.this: - aws_ssm_parameter.db_master_user : Retrieve credentials from SSM# Remove connections between nodes that are currently showndisconnect: # Wildcards mean these disconnections apply to any cloudwatch type resource called logsaws_cloudwatch*.logs: - aws_ecs_service.this - aws_ecs_cluster.this# Delete the following nodesremove: - aws_iam_role.task_execution_role# Add the following nodesadd: aws_subnet.another_one : # Specify Terraform attributes for a resource like this cidr_block: "123.123.1.1"# Modify attributes of existing nodeupdate: aws_ecs_service.this: # Add custom labels to the connection lines that already exist between ECS->RDSedge_labels: - aws_rds_cluster.this: Database Queries# Wildcards save you listing multiple resources of the same type. This edge label is added to all CF->ACM connections.aws_cloudfront* : edge_labels: - aws_acm_certificate.this: SSL Cert# Add a custom label to a resource node. Overrides default labelaws_ecs_service.this : label: "My Custom Label" Oczywiście więcej można znaleść na stronie projektu: https://github.com/patrickchugh/terravision
- Google Blog - nowości w tematyce Cloud
Pod adresem https://cloud.google.com/blog/ znajdziesz blog Google Cloud, który oferuje różnorodne informacje, w tym wiadomości, porady oraz inspiracje mające na celu przyspieszenie transformacji cyfrowej. Oto kilka przykładów tematów, które możesz tam znaleźć: Komputacja: Artykuł o największym na świecie zadaniu dystrybucyjnego treningu dużych modeli językowych, zrealizowanym z użyciem ponad 50,000 chipów TPU v5e Google Cloud. Bezpieczeństwo i tożsamość: Omówienie podejścia Google Cloud do zaufania i przejrzystości w dziedzinie sztucznej inteligencji. AI i uczenie maszynowe: Opis trzech nowych sposobów, w jakie Duet AI może pomóc szybko wykonywać zadania w konsoli Google Cloud. Szkolenia i certyfikacje: Informacje o nowych sposobach rozwoju umiejętności w chmurze i identyfikacji talentów oferowanych przez Google Cloud. Przechowywanie danych i transfer: Wprowadzenie do Autoclass Cloud Storage, teraz dostępnego dla istniejących kubełków Cloud Storage. Bazy danych: Prezentacja aktualizacji Cloud SQL umożliwiającej łatwy przejście z wersji Enterprise do Enterprise Plus. Kontenery i Kubernetes: Prezentacja GKE Enterprise, kolejnego etapu ewolucji platform kontenerowych, które są teraz ogólnie dostępne. Rozwój aplikacji: Porady dotyczące budowania aplikacji Java Spring Boot w IntelliJ z pomocą Duet AI. Analiza danych: Omówienie zaawansowanych analizatorów tekstu i funkcji przetwarzania wstępnego w BigQuery. Bezpieczeństwo i tożsamość: Wskazówki dotyczące tworzenia polityki bezpieczeństwa sieciowego w Google Cloud. Blog ten jest bogatym źródłem informacji dla osób zainteresowanych technologią chmurową, AI, analizą danych i wieloma innymi aspektami technologii cyfrowych.
- Nowe Grupy tematyczne na FaceBook
Hej. Osoby które należą do grupy LinuxPL na Facebook znają mnie właśnie z tej grupy gdzie dzielę się na niej informacjami i artykułami o rożnych technologiach z tematyki Linux, OpenSuorce, Automatyzacji, Konteneryzacji i Wirtualizacji. Zostały dodane nowe grupy tematyczne w celu ułatwienia aspektu dzielenia się wiedzą, oto dostępne grupy tematyczne: Od Zera do Bohatera - Od Zera do Bohatera - Grupa dla użytkowników początkujących - tematyka szeroka Linux, Automatyzacja, CI/CD, Windows Ogólnie o IT. GCP PL - GCP PL - Google Cloud Computing - Grupa dla pasjonatów rozwiązania Cloud od Google. www.facebook.com/groups/gcppl/ Azure PL - Azure PL - Grupa dla użytkowników rozwiązań cloud Azure. www.facebook.com/groups/azurepl/ AWS PL - AWS PL - Grupa dla Użytkowników rozwiązań Cloud od Amazona. www.facebook.com/groups/awspl/ Automatyzacja zadań w IT - Automatyzacja w IT - procesy CI/CD, zapytania o systemy Jenkins, TeamCity, Github acction, bash, ansible i podobne. www.facebook.com/groups/automatyzacjaitpl/ Cloud - Cloud PL - chmura publiczna i prywatna - Temty związane z chmura publiczna i prywatną. www.facebook.com/groups/cloudpl/ Digital Ocean PL - DigitalOcean PL - Wszystko o Digital Ocean. Konfiguracje rozwiązania itp. www.facebook.com/groups/digitaloceanpl/ Terraform PL - Terraform PL - O terraformie po polsku. Automatyzujesz konfiguracje chmury, to grupa dla Ciebie. www.facebook.com/groups/terraformpl/ Proxmox PL - PROXMOX PL - o popularnej wirtualizacji po polsku. Konfiguracje, how to, rożne triki. www.facebook.com/groups/proxmoxpl/ Ansible PL - Ansible PL - jedno z lepszych (moim zdaniem ) narzędzi jeżeli chodzi o automatyzacje konfiguracji na systemach operacyjnych. www.facebook.com/groups/ansiblepl/ Jeżeli należysz do Grupy LinuxPL - twoje zgłoszenie do wyżej wymienionych grup zostanie przyznane automatycznie. Zapraszam.
- Proxmox - trzy węzły, dwa wirtualne hosty i jeden klaster - część druga (part 2)
Hej to drugi wpis o moim klastrze proxmox. Składa się on z trzech węzłów bare metalowych hostów i jednego hosta NAS Synology. W całej tej konfiguracji NAS Synology pełni rolę dysku sieciowego oraz swoisty poligon dla testów network storage. O pełnej specyfikacji moich urządzeń poczytać możesz w pierwszej części serii proxmox. [Zdjęcie klastra proxmox] [Zdjęcie Synology] Powyżej te dwa zdjęcia prezentują mój klaster. Tak jak wspomniałem projekt jest mocno "chałupniczy". Nie mam dedykowanego jednego miejsca w domu gdzie mógłbym umieścić te wszystkie urządzenia. Jednak gdybym miał go rozrysować, rozrysował bym to w ten sposób. Jak możemy zobaczyć mój klaster składa się z trzech węzłów na których działa lokalny storage w postaci LVM (przestrzeń dla obrazów ISO) i LVM-Thin (przestrzeń dla maszyn wirtualnych). Sieciowo jest dostępny Storage w postaci NFS i SMB dostępne z serwera NAS z RAID 5. Gdybym miał pokazać jak widoczne są te przestrzenie to one widoczne są na poziomie klastra. Nasz rysunek zmienił by się troszkę i teraz wyglądałby tak: Widzimy teraz że oprócz przestrzeni dyskowej lokalnej mamy też przestrzeń dyskową sieciowa która jest dostępna na poziomie klastra a zatem jest dostępna dla wszystkich węzłów w klastrze. W poprzednim materiale umieszczając ISO w lokalnym storage ten ISO nie był dostepny dla innego węzłą. Zatem poprawie to i przerobie ta konfigurację. Usuńmy nasze ISO i wygrajmy je na nasz dysk sieciowy. Oczywiście tylko musze dodać możliwość dodawania iso na tym storage, a robi się to w ten sposób. Przechodząc do menu klastra w moim przypadku jest to Datacenter (HomeProxmox) potem na Storage -> Add i z listy rozwijanej wybieramy NFS. W konfiguracji NFS ustawiam nazwę (unikatową w skali całego klastra dla pola ID). Serwer adres nfs.koska.in (zmień na swój). Export - jak uda Ci się podłączyć do serwera NFS ustawi się automatycznie lub będziesz miał listę do wyboru jeżeli będzie kilka przestrzeni NFS. W content ustawiamy co będzie mógł przechowywać nasz dodany storage. Ja tu zaznaczyłem wszystko a możemy się ograniczyć tylko do ISO i backup. W środowiskach produkcyjnych i wielo użytkownikowych zalecanie jest ograniczać nie tyle co dostęp ale także content jaki mogą zawierać nasze storage. W polu nodes możesz wybrać jakie węzły będą korzystać z tego storage (domyslnie jest to all). Możesz tu wskazać które węzły mają dostęp - u mnie to wszystkie dostęp uzyskają. Zatem uzupełniłem już moją kolekcję ISO w proxmox :) - czy nie jest imponująca (żart). A tak na serio to wgrywałem je pojedynczo z każdego węzła (tak wiem że można to zrobić z command line) ale chciałem sprawdzić jak zachowa się właśnie proxmox a dokładnie API gdy będę je męczył z jednego węzła. Wgrywanie kilku obrazów z jednego węzła powodowało błąd importu ISO. A logi a w zasadzie Taski - bo tak się to w proxmox nazywa można przeglądać na danym węźle z poziomu tego węzła - jego menu potem Task History i szukamy naszego wpisu :) I powoli dochodzimy do tego właśnie w jaki sposób zachować funkcjonalność naszego klastra. Sam klaster dział jednak proxmox nie zapewnia VIP IP dla interfejsu WWW GUI który by pływał między węzłami dając dostęp do klastra. Innymi słowy mówiąc: Gdy pve01.koska.in jest niedostepny to nie dostanę się do klastra. Pozostają mi dwa nastepne adresy pve02.koska.in oraz pve03.koska.in. I tu przechodzimy do jednej z ważniejszych rzeczy jakie trzeba zrozumieć na początku pracy z proxmox w wersji kluster - czy może inaczej z włączonym klastrem. Proxmox - Korum w klastrze proxmox W klastrze Proxmox, jeden z węzłów pełni rolę "master". Główną rolą mastera jest koordynowanie dostępu do współdzielonych zasobów i zarządzanie metadanymi klastra. Jednak warto zaznaczyć, że wszystkie węzły w klastrze Proxmox są równorzędne w sensie, że każdy węzeł może wykonywać operacje VM (maszyny wirtualne) i CT (kontenery), niezależnie od tego, czy są masterem. Jeśli master umiera lub jest niedostępny, inny węzeł może przejąć rolę mastera. Wybór nowego mastera jest oparty na systemie głosowania między węzłami. Oto jak to działa: Wybór Mastera: Proxmox używa protokołu korum do zarządzania klastrem. Kiedy master jest niedostępny, pozostałe węzły rozpoczynają proces wyboru nowego mastera. Węzeł z najniższym ID jest wybierany jako nowy master, pod warunkiem że może uzyskać większość głosów w klastrze. Większość: Aby węzeł mógł zostać masterem, musi uzyskać większość głosów. W klastrze 3-wezłowym oznacza to, że muszą być co najmniej 2 działające węzły, w tym węzeł, który próbuje zostać masterem. Jeśli tylko jeden węzeł jest online, nie będzie mógł uzyskać większości i klastrowe operacje zarządzania nie będą możliwe do przeprowadzenia. Zmiana Mastera: Jeśli oryginalny master zostanie przywrócony online po tym, jak nowy master został wybrany, stary master stanie się zwykłym węzłem i nowy master będzie nadal pełnił swoją rolę. W praktyce oznacza to, że w klastrze 3-wezłowym można tolerować awarię jednego węzła i klastrowe operacje zarządzania nadal będą możliwe. Jeśli jednak dwa węzły staną się niedostępne, klastrowe operacje zarządzania zostaną zawieszone do momentu przywrócenia przynajmniej jednego z tych węzłów. Czemu zatem nie cztery? To pytanie moglibyśmy porównać do sytuacji w aktualnych wyborach do sejmu i senatu. Niby dodając jednego hosta więcej do mojej puli mogłabym wygrać ilościowo ale przegrałbym większościowo. Po prostu tej większości bym nie uzyskał. W klastrze Proxmox opartym na większej liczbie węzłów, zasady wyboru mastera i wymagania dotyczące większości głosów nadal obowiązują, ale matematyka zmienia się w zależności od liczby węzłów. Proxmox używa protokołu korum opartego na głosowaniu, który determinuje, czy klastrowe operacje zarządzania są możliwe. Oto jak to działa w klastrach o różnej liczbie węzłów: Klaster 4-węzłowy: Wymagana większość: 3 z 4 węzłów. Możesz tolerować awarię jednego węzła i nadal mieć możliwość wykonywania klastrowych operacji zarządzania. Czyli taniej wychodzi wersja 3 węzłowa - dalej więcej niż jedna awaria węzła powoduje utratę większości. Klaster 5-węzłowy: Wymagana większość: 3 z 5 węzłów. Możesz tolerować awarię dwóch węzłów i nadal mieć możliwość wykonywania klastrowych operacji zarządzania. Dla klastrowych systemów o większej liczbie węzłów: Wymagana większość to połowa liczby węzłów plus jeden. Na przykład w klastrze 6-węzłowym potrzebujesz 4 węzłów (3+1) dla większości, a w klastrze 10-węzłowym potrzebujesz 6 węzłów (5+1) dla większości. Można tolerować awarię `(n/2) - 1` węzłów, gdzie `n` to liczba węzłów w klastrze, i nadal mieć możliwość wykonywania klastrowych operacji zarządzania. Co ważne, dodanie dodatkowych węzłów do klastra zwiększa odporność na awarie, ale jednocześnie zwiększa wymagania dotyczące ilości węzłów potrzebnych do osiągnięcia większości. Podczas projektowania i konfigurowania klastra warto zastanowić się nad liczbą węzłów w kontekście wymagań dotyczących dostępności i tolerancji na awarie. W wielu przypadkach klaster z nieparzystą liczbą węzłów jest bardziej odporny na awarie niż klaster o podobnej, parzystej liczbie węzłów. Zatem konfiguracja trzy węzłowa jest najtańsza wersją dająca namiastkę HA w klastrze :). Zobrazuje to: Kiedy nasz węzeł przestaje być dostępny tracimy dostęp do jego zasobów. Jednak przy konfiguracji trzy węzłowej moje dwa węzły pve01.koska.in oraz pve02.koska.in mogą dalej działą i zapewnić funkcjonowanie klastra na czas wymiany / naprawy węzła pve03.koska.in. I tu rodzi się następujący pytanie skoro klaster działa na dwóch węzłach to dlaczego nie ustawić go i nie zainstalować właśnie na dwóch. To konfiguracja z która spotkamy się przy dodanu jednego hosta więcej do naszej konfiguracji. W przypadku czterech węzłów awaria dwóch nie daje tej większość. Uzyskujemy ją dopiero przy pięciu. Jednak co tracimy przy klastrze który nie ma większości? I czy możemy dalej funkcjonować z takim klastrem? Tak, klaster Proxmox może działać bez wymaganej większości węzłów, ale istnieją pewne ograniczenia w jego funkcjonalności w takim scenariuszu. Po pierwsze, pojęcie "większość" w kontekście klastra odnosi się do koncepcji kworum. W systemach rozproszonych kworum to minimalna liczba węzłów, które muszą być dostępne i komunikować się ze sobą, aby podejmować decyzje na poziomie klastra. Oto dlaczego jest to ważne: Unikanie podziału mózgu (split-brain): Jeśli dwa węzły w klastrze tracą ze sobą komunikację, oba mogą próbować przejąć odpowiedzialność za zasoby klastra. Może to prowadzić do sytuacji, w której oba węzły uważają się za "mistrza" i próbują zarządzać zasobami niezależnie. Jeśli klaster wymaga kworum (większości) do działania, zapobiega to potencjalnym konfliktom i problemom spowodowanym przez podział mózgu. Integralność danych: W przypadku rozproszonych systemów plików czy rozwiązaniach do przechowywania danych, kworum zapewnia, że zmiany w danych są akceptowane tylko wtedy, gdy większość węzłów je potwierdzi. Zabezpiecza to przed potencjalnymi niezgodnościami w danych. Gdy klaster Proxmox działa bez wymaganej większości węzłów: Brak możliwości zarządzania klastrem: Jeśli klaster traci kworum, nie będziesz mógł dokonywać zmian na poziomie klastra, takich jak migracje maszyn wirtualnych czy zmiany w konfiguracji klastra. Węzły działają niezależnie: Chociaż węzły będą nadal działać i obsługiwać lokalnie uruchomione maszyny wirtualne lub kontenery, nie będą one w stanie komunikować się z resztą klastra ani wykonywać operacji klastrowych. Możliwość wystąpienia problemów z integralnością danych: W scenariuszach, w których klaster używa rozproszonych systemów przechowywania, takich jak Ceph, brak kworum może wpłynąć na integralność i dostępność danych. Podsumowując, chociaż klaster Proxmox może działać bez wymaganej większości węzłów, jest to stan, który należy unikać. Kworum jest kluczowym elementem zapewniającym spójność i stabilność w systemach rozproszonych. Jeśli klaster traci kworum, najlepiej jest jak najszybciej przywrócić wymaganą większość węzłów do działania. Proxmox - Klaster HA(hahahaha) Czyli w obecnej konfiguracji jestem na dobrej drodze do zachowania HA w klastrze proxmox. Trzeba tylko ogarnąć przeskakiwanie mojej maszyny wirtualnej na któryś z węzłów w przypadku braku dostępności jednego z nich. Proxmox - konfiguracja maszyny wirtualnej Zróbmy to - czas na uruchomienie naszej "pierwszej" maszyny wirtualnej w klastrze proxmox. Zobaczmy jakie mamy możliwości. Doprowadźmy do ziszczenia przedstawionego powyżej scenariusza. Scenariusz zatem zakłada, że stworze maszynę wirtualną (na dowolnym węźle w klastrze). W przypadku braku dostępności tego węzła na którym działa maszyna wirtualna, ta maszyna wirtualna zostanie przeniesiona na jeden z dwóch węzłów. Sprawdźmy jaki mamy storage w naszym klastrze: LVM (local) i LVM-Thin dostępny na każdym węźle. Samba i NFS dostępny z poziomu klastra. Wczytując się w mechanizmy HA i replikacje storage w postaci LVM (obie wersje) nie jest on dobrym rozwiązaniem. Mechanizm HA zrobi migracje maszyny wirtualnej na wskazany host pod warunkiem, że węzeł na którym, jest uruchomiona maszyna wirtualna będzie dostępny w czasie przenosin. Co znacznie utrudnia wystąpienie nieplanowanych awarii. Mechanizm replikacji działa wyłącznie dla ZFS. Dlatego też trzeba dodać nasz storage typu ZFS. Storage ZFS W mojej konfiguracji każdego węzła, posiadam jeden dysk gdzie jest zainstalowany system operacyjny PROXMOX i dwa wspomniane wyżej lokalne storage. Na drugim dysku nie mam jeszcze danych i wykorzystam go częściowo na ZFS oraz na directory storage w celu przechowywania tymczasowego backup. Konfiguracja przedstawia się następująco: Dyski które mamy dostępne (podłączone są do naszego węzła) zawsze będą dostępne z poziomu danego węzła. W tym przypadku będzie przykład z pve01.koska.in (Operacje jednak wykonam na wszystkich węzłach). Mam dostępne dwa dyski. Pierwszy zawiera system, drugi mogę go wykorzystać na mój storage. Zaznaczam dysk który chcę użyć (W moim przykładzie jest to /dev/sda). Klikam w górnej części menu WIPE DISK (UWAGA: Usunie wszystkie informacje o partycjach - upewnij się, że nie masz tam danych ważnych dla Ciebie) i usuwań znajdujące się tam dane. W tym przypadku partition layout. Teraz mogę przejść do konfiguracji mojego dysku. Na moim hoście pve01. Z menu węzła wybieram host pve01 i klikam z górnego menu shell. I przechodzę do terminala gdzie wydaje polecenie fdisk dla wybranego dysku (/dev/sda) i tworzę partycje według potrzeb. Jedną o pojemności 130 GB a druga o pojemności około 100 GB. Operacje powtarzam na każdym węźle - pve02 i pve03. Finalny rezultat jak u mnie to wyglada na każdym hoscie pveX prezentuje poniżej (zaznaczone na zielono). Po utworzeniu partycji w mojej konfiguracji na mniejszej z nich zrobię taki lokalny backup. Tworzę w pierwszej kolejności Director na mniejszej partycji, będzie on zawierał backup na lokalne operacje. Operacje będę znów powtarzał na wszystkich hostach od pve01 do pve03. Wchodzę w menu węzła klikając na jego nazwę -> Disks -> Directory -> Create Directory Konfiguracja wygląda następująco. Directory będę tworzył na partycji /dev/sda2 z filesystem ext4. Nazwą dla Directory będzie słowo backup. Widzimy też, że nie mamy konfiguracji do wskazania kilku węzłów jak to miało miejsce przy NFS i SMB. Dlatego musimy zapamiętać, że ten storage będzie dostępny jedynie lokalnie na danym host. Storage o nazwie backup tworzę dodatkowo też na pve02 i pve03. Utworzony poprawnie Storage Directory pokaże nam się na liście w podglądzie w tym samym miejscu gdzie go dodaliśmy. Directory "backup" będę wykorzystywał w roli temporary backup dla danego hosta, ale będzie też mógł przechowywać innego rodzaj kontent według zaprezentowanej listy. Storage Director Backup po dodaniu go na wszystkich hostach będzie widoczny w całym klastrze. Pomimo że jest widoczny w całym klastrze jak ma to miejsce z NFS oraz SMB. To należy pamiętać że jest on tylko lokalnym storage dostępnym na danym węźle. Teraz przystąpmy do stworzenia Storage ZFS. Tu też operacje będziemy musieli wykonać na wszystkich hostach w klastrze. Klikamy na Host, przechodzimy do menu węzła potem Disks -> ZFS -> Create ZFS Wybieramy nazwę dla naszego ZFS oraz wskazujemy device na którym ma działać, ustawiamy kompresję i tworzymy nasz Storage ZFS. (Dodatkowo jak mielibyśmy tu na przykład kilka fizycznych dysków z partycjami ZFS, to moglibyśmy skonfigurować RAID dla naszej konfiguracji) Operacje powtarzamy w celu uzyskania ZFS_STORAGE na każdym węźle w proxmox odpowiednio dla pve02 i pve03. Gdy już mamy nasz ZFS_STORAGE na każdym węźle możemy przystąpić do konfiguracji ZFS z poziomu naszego klastra. Da nam to możliwość replikacji danych pomiędzy hosty w naszym klastrze. Dodajemy nasz ZFS z poziomu klastra. Przechodzimy do menu klastra -> Storage -> Add -> ZFS Nazwa musi być inna od już używanych jak dla każdego ID Storage. Zatem użyje nazwę zfs. Dodatkowo dla rozróżnienia tych Storage w widoku klastra można by pokusić się o label w postaci _local_ i _replica_, ale to już zostawiam do indywidualnego nazewnictwa. Po stworzeniu takiego storage z poziomu klastra zobaczymy, że on jest on dostępny na wszystkich hostach. Jednak możemy zobaczyć że nie jest typu SHARED jak to mam miejsce przy SMB i NFS. W przeciwieństwie do NFS i SMB, co to oznacza? Zatrzymajmy się tutaj na chwile by wytłumaczyć znaczenia tej opcji. Wcześniej jak dodaliśmy SMB i NFS z poziomu menu klastra to nasz storage dodał się automatycznie na wszystkie węzły i ustawił się na status shared. Co oznacza że zasób jest niezależny od węzła i jest udostępnia z innego zasobu. To po prostu osobny serwer z usługami NFS i Samba. Dlaczego w przypadku dodania ZFS tak się nie dzieje? Tu musimy popatrzeć na nasze mechanizmy HA i replikacja. W kontekście Proxmox, HA (High Availability) oraz replikacja to dwa kluczowe pojęcia związane z zapewnieniem ciągłości działania i ochrony danych: HA (High Availability) - Wysoka dostępność: Jest to mechanizm, który zapewnia automatyczne uruchamianie maszyn wirtualnych lub kontenerów na innym węźle w przypadku awarii jednego z węzłów w klastrze Proxmox. Celem HA jest minimalizowanie przestojów i zapewnienie, że zasoby są dostępne nawet w przypadku awarii jednego z węzłów. Proxmox VE korzysta z mechanizmu "Proxmox Cluster file system (pmxcfs)", który umożliwia synchronizację konfiguracji między węzłami klastra. W połączeniu z innymi narzędziami, takimi jak Corosync i Pacemaker, Proxmox jest w stanie monitorować węzły i usługi, a następnie reagować na awarie. Replikacja: Jest to proces tworzenia kopii danych w czasie rzeczywistym (lub niemal w czasie rzeczywistym) z jednej lokalizacji do innej. W kontekście Proxmox, replikacja często odnosi się do replikacji dysków maszyn wirtualnych lub kontenerów. Dzięki temu, w przypadku awarii jednego z dysków lub węzłów, dane są nadal dostępne w innej lokalizacji. Proxmox oferuje replikację na poziomie bloków, co pozwala na szybką i skuteczną synchronizację danych między węzłami. Replikacja jest często używana razem z HA, aby zapewnić zarówno dostępność usług, jak i ochronę danych. Zatem zauważamy, że w przypadku SMB i NFS replikacją będzie po prostu "backup". Ponieważ replikację zapewniana jest już po stronie serwera Synology NAS. Proxmox w tym przypadku nie bierze udziału W przypadku ZFS, to my musimy zapewnić replikację by nasze HA funkcjonowało. Może zobaczmy to na konkretnym przykładzie naszych maszyn wirtualnych z różnym storage. Tworzymy naszą maszynę wirtualną z poziomu węzła z menu kontekstowego Lub belki z przyciskami funkcyjnymi z prawej strony ekranu po kliknięciu na dany host. Ustawiamy nasze maszyny wirtualne dla ZFS NFS i SMB (czyli łącznie trzy maszyny wirtualne). O nazwach ubuntu-zfs, ubuntu-nfs i ubuntu-smb. Ja dodam jeszcze jedną maszynę wirtualną w celu wykonania testów wydajnościowych. Niech to będzie Ubuntu - wybieramy ISO z naszego storage gdzie przechowujemy nasz obrazy systemów opercyjnych. Ustawienie Systemowe - można się wzorować lub ustawić własne. Konfiguracja dysku - dodam malutki dysk 32GB. W zupełności to wystarczy. To tu też decydujemy gdzie wyląduje nasz dysk. Dlatego warto zwrócić tu uwagę na pozycję STORAGE. Dla każdej VM ustawiamy inny. CPU - według uznania (lub możliwości naszego węzła). RAM - tak z umiarem :) Sieci. Jeszcze za dużo o sieci nie rozmawialiśmy, a więc ustawmy domyślny bridge interface. Na końcu otrzymamy podsumowanie naszych ustawień. Możemy ustawić też start nasze maszyny wirtualnej zaraz po konfiguracji. Jak nic nie będziemy zmieniać/dodawać. A tak u mnie prezentują się moje trzy maszyny wirtualne. Ubuntu-zfs, ubuntu-nfs, ubuntu-smb. Wszystkie uruchomiłem na jednym hoście. Za chwileczkę ogarniemy ich lokalizację w HA. Możemy przejść do konfiguracji naszego HA i replica w klaster proxmox. W tym celu przechodzimy do ustawień HA z poziomu menu klastra (To tu ustawia się konfigurację HA). Nasz rysunek teraz z działającymi maszynami wirtualnymi prezentuje się następująco. Widzimy wyraźnie gdzie znajduje sie jaka maszyna wirtualna oraz jak wygląda nasza konfiguracja storage. Z tym rysunkiem w głowie przejdźmy do ustawień HA w Klastrze HA - jego konfiguracje robimy na poziomie klastra. Z menu klastra wybieramy HA -> Groups to tu będziemy mogli stworzyć nasze grupy decyzyjne HA Kliknijmy create by spojrzeć na konfigurację. W oknie Create HA Group możemy ustawić nasz HA ID: czyli nazwę, oraz wskazać węzły na których nasza grupa będzie operować. Możemy też określić Priority Awaryjności naszego klastra. Czyli gdzie ma wylądować nasza maszyna wirtualna. Im wyższa wartość, to ten host będzie wybierany jako pierwszy. Ja wcześniej już przygotowałem swoje grupy HA. W nazwie znalazły się prefixy dla storage. Zatem HA-nfs jest przypisane do ubuntu-nfs, HA-smb do ubuntu-smb a HA-zfs do ubuntu-zfs. Mamy też informacje gdzie i w jakiej kolejności powinna być uruchamiane nasze maszyny wirtualne: I dla ubuntu-zfs będzie to: pve01 potem pve03 na końcu pve02 dla ubuntu-smb będzie to: pve02 na końcu pve03 (bez pve01) dla ubuntu-nfs będzie to: pve02 na końcu pve01 (bez pve03) W samym menu HA możemy podejrzeć sobie Czy nasze kworum jest OK oraz który, węzeł akurat pełni role mastera (main). A poniżej możemy ustawić nasze HA dla naszych zasobów poprzez przycisk Add. Ścieżka będzie zatem menu klastra -> HA -> Add. W Add Resource: Container/Virtual Machine na liście VM pokażą się wszystkie maszyny bez ustawionego HA. Jak nie ma jakiejś maszyny tu na liście to znaczy, że ma już ustawione HA Wskazujemy zasób poprzez jego ID i wybieramy grupę oraz określamy stan jaki oczekujemy. Możemy też określić liczbę restartów i relocate. Gdy mamy już dodane nasze HA do zasobów pokazują się na liście gdzie możemy łatwo zidentyfikować jaki zasób do jakiego HA jest przypisany. Po zastosowaniu HA widzimy jak nasze maszyny przygotowywane są do rozłożenia po klastrze. Nasze dwie maszyny wirtualne przeskakują na host pve02 tak jak to określiliśmy w konfiguracji HA Groups. Nasz schemat poniżej to przedstawia. maszyna smb i nfs ma storage shared wiec migracja jest tylko samych metadanych. Po ukończonej migracji nasze maszyny wirtualne teraz tak są rozłożone na klastrze. Widzimy to też w GUI PROXMOX Możemy to zweryfikować na podstawie naszych ustawień HA grupy. W przypadku storage sieciowego shared HA w zupełności wystarczy. Bo przenoszone są tylko metadane - nasz dysk jest na innym serwerze który, to udostępnia go dla naszego proxmox. Inaczej jest w przypadku ZFS storage. Wymusimy przeniesienie w konfiguracji HA. Po zmianie kolejności i ustawieniu pve03 z najwyższym priorytetem zaobserwujemy ze rozpoczyna się nasza migracja. Nasza maszyna wirtualna z ID 100 jest przenoszona na pve03 wraz z danymi. Dzieje się tak ponieważ ZFS z założenia nie jest zasobem shared tylko lokalnym. (W obrazku widnieje błąd w postaci oznaczenia dysku w dolnej czesci) Podczas procesu migracji dane zobaczymy na obu hostach pve01 i pve02. (W obrazku widnieje błąd w postaci oznaczenia dysku w dolnej czesci) Zobaczymy ten proces na liście zadań proxmox Pomimo migracji nasza maszyna jest nadal dostępna i możemy na niej działać. To proxmox pilnuje by dane były we właściwym miejscu. Po zakończonej migracji dysk dla naszej VMki o ID 100 będzie tylko i wyłącznie na pve03. Jednak w przypadku naszego storage klastrowego ZFS możemy zapewnić replikację. Jest to alternatywa dla braku NFS lub SMB w naszej konfiguracji. Przechodzimy do naszej maszyny wirtualnej i konfigurujemy replikacje ustawiając ją na hosty w których nie ma naszej maszyny wirtualnej - czyli w tym przypadku będzie to pve01 i pve02. Ustawiamy Target na pve01 (potem na pve02) konfigurujemy nasz Schedule: co 15 minut (w ramach testu). Dla pve02 - musimy zrobić osobno dla każdego hosta. Dla pve03 nie zrobimy ale jak maszyna przeskoczy na inny host to ten na którym będzie zmieni się w konfiguracji replikacji na ten na którym był. Ustawienie replikacji będzie widoczne w naszych zadaniach replikacyjnych na liscie wraz z widocznym statusem. Teraz możemy zaobserwować że nasz dysk pojawia się na innych hostach (pve01 i pve02) Jest to replika naszego dysku - która może posłużyć jako restore point po awarii któregoś z węzłów. Zabawy nadszedł czas - symulacja awarii w klastrze proxmox Czas na zabawę. Zróbmy awarię, konfigurację trzeba przetestować. Na pierwszy ogień maszyny z SMB i NFS. Wyłączymy nasz węzeł proxmox pve02. Po chwili nasz status page wykryje problem. I zacznie się migracja, przepraszam wróć przełączaniem naszego HA. Z bazy danych proxmox odnośnie metadanych dla naszych maszyn wirtualnych zostanie uruchomiona VM na innych dostępnych hostach ubuntu-smb i ubuntu-nfs. Dyski oczywiście pobierane są ze Storage sieciowego więc tu dane są bezpieczne. Tak to wygląda po przełączeniu HA w przypadku awarii pve02. Ok włączamy nasz host z powrotem i gdy będzie dostępny nasz HA znów zadziała tylko że tym razem maszyny zostaną przeniesione poprzednie swoje miejsce według HA groups Maszyny 101 i 102 wracają na swoje miejsce. ZFS replica i HA - proxmox klaster By to zadziałało tak samo w przypadku naszego zfs to musimy mieć aktywne obie opcje replica i HA groups. Replika musi być wykonana dla wszystkich miejsc ustawionych w replicas. Jeżeli nie wykonała się na czas z powodu awarii lub jeszcze nie została uruchomiona zawsze możemy ją uruchomić na żądanie. Musimy poczekać na wszystkie wykonania. Teraz jestesmy pewni że nasz HA groups i replica zadziała w przypadku awarii. Widzimy że nasza VMka 100 cały ten czas działała ma uptime 43 minuty (a przeszła dwie migracje w międzyczasie). Czas zatem na awarie numer dwa - teraz pve01 bedzie niedostępny. Host z naszą maszyną ubuntu-zfs (ID 100) Kiedy nasz host będzie niedostępny proxmox - przeniesie naszą maszynę i uruchomi ją na podstawie zreplikowane dysku. W mojej konfiguracji trace tylko 15 minut (to czas ustawionego scheduler dla replica danych pomiędzy węzłami). Proxmox przeniósł maszynę i odpala ja na bazie naszego dysku z ostatniej repliki. Oczywiście maszyny w tym przypadku zaliczyła restart. Którego nie da się uniknąc w przypadku awarii niekontrolowanej węzła. Pokazałem Ci działanie HA w sposób kontrolowany i nie kontrolowany. Wiesz już też jak działa replica. W tym wpisie to już koniec w kolejnym przeprowadzimy parę testów wydajnościowych, jakieś bardziej realne scenariusze. Zajmę się też backupem oraz automatyzacją w wykonaniu Ansible i Terraform. Przydał by się też monitoring :) Zapraszam.
- Proxmox - rozwiązania enterprise i home klastra wirtualizacji - część pierwsza (part 1).
Proxmox to platforma przeznaczona do wirtualizacji i konteneryzacji zasobów które, mamy uruchomione na naszych maszynach baremetal. W tym artykule przyjrzymy się takiej konfiguracji w moim labie domowym (jednak łatwo to potem przenieść na większą skalę). W artykule tym biorą udział 4 hosty na których zbudujemy klaster. Jeden host nasz gość specjalny zostanie na razie ukryty w tej konfiguracji i ujawnię go w trakcie artykułu :). Środowisko proxmox Zatem spójrzmy na moje środowisko dostępne w domowym "laboratorium" w którym to będę przeprowadzał operację uruchomienia klastra proxmox składającego się z trzech nodów (węzłów). Klaster ten wykorzystuje do tworzenia moich materiałów na youtube i komercyjnych szkoleń. Węzły (nody) - proxmox specyfikacja. Dla osób, które lubią parametry i dokładne szczegóły przedstawię rezultat polecenia hwinfo ze wszystkich trzech węzłów mojego klastra proxmox: Węzeł pierwszy (pve01) - dwa dyski SSD po 230 GB / 8GB RAM root@pve01:~# hwinfo --short cpu: Intel(R) Core(TM) i5-7260U CPU @ 2.20GHz, 3400 MHz Intel(R) Core(TM) i5-7260U CPU @ 2.20GHz, 3400 MHz Intel(R) Core(TM) i5-7260U CPU @ 2.20GHz, 3400 MHz Intel(R) Core(TM) i5-7260U CPU @ 2.20GHz, 3400 MHz graphics card: Intel Iris Plus Graphics 640 storage: Intel Sunrise Point-LP SATA Controller [AHCI mode] Kingston Technology Company U-SNS8154P3 NVMe SSD network: wlp58s0 Intel Wireless 8265 / 8275 eno1 Intel Ethernet Connection (4) I219-V enx00e04c6804df Realtek RTL8153 Gigabit Ethernet Adapter network interface: lo Loopback network interface eno1 Ethernet network interface vmbr0 Ethernet network interface enx00e04c6804df Ethernet network interface wlp58s0 Ethernet network interface disk: /dev/nvme0n1 Kingston Technology Company U-SNS8154P3 NVMe SSD /dev/sdb SYNOLOGY Storage /dev/sda Samsung SSD 860 partition: /dev/nvme0n1p1 Partition /dev/nvme0n1p2 Partition /dev/nvme0n1p3 Partition /dev/sda1 Partition /dev/sda2 Partition usb controller: Intel JHL6340 Thunderbolt 3 USB 3.1 Controller (C step) [Alpine Ridge 2C 2016] Intel Sunrise Point-LP USB 3.0 xHCI Controller bios: BIOS bridge: Intel Sunrise Point-LP PCI Express Root Port #1 Intel Sunrise Point LPC Controller/eSPI Controller Intel JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] Intel Sunrise Point-LP PCI Express Root Port #8 Intel Sunrise Point-LP PCI Express Root Port #6 Intel JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] Intel Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers Intel JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] Intel Sunrise Point-LP PCI Express Root Port #9 Intel JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] hub: Linux Foundation 2.0 root hub VIA USB2.0 Hub Linux Foundation 3.0 root hub Linux Foundation 2.0 root hub VIA USB3.0 Hub Linux Foundation 3.0 root hub memory: Main Memory unknown: FPU DMA controller PIC Keyboard controller PS/2 Controller Realtek RTS5229 PCI Express Card Reader Intel Sunrise Point-LP PMC Intel Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model Intel Sunrise Point-LP CSME HECI #1 Intel Sunrise Point-LP Thermal subsystem Intel Sunrise Point-LP SMBus Węzeł drugi (pve02) - wa dyski SSD po 230 GB / 8GB RAM root@pve02:~# hwinfo --short cpu: Intel(R) Core(TM) i5-7260U CPU @ 2.20GHz, 3400 MHz Intel(R) Core(TM) i5-7260U CPU @ 2.20GHz, 3400 MHz Intel(R) Core(TM) i5-7260U CPU @ 2.20GHz, 3400 MHz Intel(R) Core(TM) i5-7260U CPU @ 2.20GHz, 3400 MHz graphics card: Intel Iris Plus Graphics 640 storage: Intel Sunrise Point-LP SATA Controller [AHCI mode] network: wlp58s0 Intel Wireless 8265 / 8275 eno1 Intel Ethernet Connection (4) I219-V enx00e04c680f23 Realtek RTL8153 Gigabit Ethernet Adapter network interface: wlp58s0 Ethernet network interface eno1 Ethernet network interface vmbr0 Ethernet network interface enx00e04c680f23 Ethernet network interface lo Loopback network interface disk: /dev/sdb WDC WDS240G2G0B- /dev/sdc SYNOLOGY Storage /dev/sda KINGSTON SV300S3 partition: /dev/sdb1 Partition /dev/sdb2 Partition /dev/sda1 Partition /dev/sda2 Partition /dev/sda3 Partition usb controller: Intel JHL6340 Thunderbolt 3 USB 3.1 Controller (C step) [Alpine Ridge 2C 2016] Intel Sunrise Point-LP USB 3.0 xHCI Controller bios: BIOS bridge: Intel Sunrise Point-LP PCI Express Root Port #1 Intel Sunrise Point LPC Controller/eSPI Controller Intel JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] Intel Sunrise Point-LP PCI Express Root Port #8 Intel Sunrise Point-LP PCI Express Root Port #6 Intel JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] Intel Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers Intel JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] Intel JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] hub: Linux Foundation 2.0 root hub VIA VL813 Hub Linux Foundation 3.0 root hub Linux Foundation 2.0 root hub VIA VL813 Hub Linux Foundation 3.0 root hub memory: Main Memory unknown: FPU DMA controller PIC Keyboard controller PS/2 Controller Realtek RTS5229 PCI Express Card Reader Intel Sunrise Point-LP PMC Intel Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model Intel Sunrise Point-LP CSME HECI #1 Intel Sunrise Point-LP Thermal subsystem Intel Sunrise Point-LP SMBus Węzeł trzeci (pve03) - wa dyski SSD po 230 GB / 8GB RAM root@pve03:~# hwinfo --short cpu: Intel(R) Core(TM) i5-7260U CPU @ 2.20GHz, 3400 MHz Intel(R) Core(TM) i5-7260U CPU @ 2.20GHz, 3400 MHz Intel(R) Core(TM) i5-7260U CPU @ 2.20GHz, 3400 MHz Intel(R) Core(TM) i5-7260U CPU @ 2.20GHz, 3400 MHz graphics card: Intel Iris Plus Graphics 640 sound: Intel Sunrise Point-LP HD Audio storage: Intel Sunrise Point-LP SATA Controller [AHCI mode] network: wlp58s0 Intel Wireless 8265 / 8275 eno1 Intel Ethernet Connection (4) I219-V enx00e04c680432 Realtek RTL8153 Gigabit Ethernet Adapter network interface: eno1 Ethernet network interface wlp58s0 Ethernet network interface vmbr0 Ethernet network interface enx00e04c680432 Ethernet network interface lo Loopback network interface disk: /dev/sdb WDC WDS240G2G0B- /dev/sdc SYNOLOGY Storage /dev/sda Samsung SSD 860 partition: /dev/sdb1 Partition /dev/sdb2 Partition /dev/sda1 Partition /dev/sda2 Partition /dev/sda3 Partition usb controller: Intel JHL6340 Thunderbolt 3 USB 3.1 Controller (C step) [Alpine Ridge 2C 2016] Intel Sunrise Point-LP USB 3.0 xHCI Controller bios: BIOS bridge: Intel Sunrise Point-LP PCI Express Root Port #1 Intel Sunrise Point LPC Controller/eSPI Controller Intel JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] Intel Sunrise Point-LP PCI Express Root Port #8 Intel Sunrise Point-LP PCI Express Root Port #6 Intel JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] Intel Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers Intel JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] Intel JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] hub: Linux Foundation 2.0 root hub VIA USB2.0 Hub Linux Foundation 3.0 root hub Linux Foundation 2.0 root hub VIA USB3.0 Hub Linux Foundation 3.0 root hub memory: Main Memory bluetooth: Intel Bluetooth wireless interface unknown: FPU DMA controller PIC Keyboard controller PS/2 Controller Realtek RTS5229 PCI Express Card Reader Intel Sunrise Point-LP PMC Intel Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model Intel Sunrise Point-LP CSME HECI #1 Intel Sunrise Point-LP Thermal subsystem Intel Sunrise Point-LP SMBus Jak można wyczytać z tej krótkiej specyfikacji nie są to jakieś mega mocne maszyny, rzekłbym takie w sam raz na domowe "laboratorium" pod wirtualizację. Sa to trzy komputerki wyglądem bardzo zbliżone do tego https://www.x-kom.pl/p/475883-nettop-mini-pc-intel-nuc-i7-8559u-25sata-m2-box.html Ja w tym przypadku poszukałem tańszych odpowiedników na allegro - kości ram i dyski zakupiłem osobno, a w większości z zasobów prywatnych uzupełniłem braki by konfiguracja była w miarę identyczna. Dodatkowy storage (przestrzeń dyskowa) w postaci serwera synology w celu zagwarantowania pewnego rodzaju HA - ale o tym jeszcze sobie porozmawiamy w tym artykule i jak to możemy zapewnić w naszym klastrze. Instalacja proxmox Proces instalacji jest prosty. Najważniejszą konfiguracje robi się już na działającym serwerze więc sprowadza on się do przeklikania naszego instalatora gdzie wybieramy kartę sieciową dla naszego głównego połączenia (main), adres IP, usera, hasło. Oczywiście będę operację instalacji wykonywał na trzech hostach - pve01, pve02 i pve03. Na początek po zbootowaniu naszego obrazu z nośnika USB / ISO przywita nas panel wyboru instalacji w trybie graficznym lub tekstowym (gdybyś miał problemy z wyświetlaniem grafiki przejdź do instalacji w trybie tekstowym) Jeżeli podczas instalacji, już na samym początku pojawi się okno o braku akceleracji maszyn wirtualnych, sprawdź czy w bios masz włączoną tą opcję. Po prostu przerwij instalację i sprawdź ustawienia BIOS. Kontynuacja z tym komunikatem będzie oznaczała brak prawdziwej wirtualizacji - jedynie emulacja z qemu i konteneryzacja z LXC/LXD Kolejnym krokiem jest wybór dysku na którym zainstaluję się system operacyjny jakim jest proxmox. Po kliknięciu w options możemy bardziej skonfigurować podział naszego dysku. Ja tu unikam tworzenia jakich macierzy i tym podobne ponieważ HA będzie gwarantować mi klaster proxmox sam w sobie. Popsicle / Stracenie jednego węzła nie będzie u mnie bardzo obciążające. Jednak jeżeli zamierzasz produkcyjnie wykorzystywać proxmox warto skonfigurować i zainstalować go na konfiguracji RAID Możemy ustawić takie parametry jak hdsize, swapsize maxroot minfree i mazvz Po konfiguracji naszego dysku dla systemu ustawiamy lokacja i czas aktualny dla naszego komputera / systemu operacyjnego - względem własnej lokalizacji. Ustawiamy hasło dla naszego użytkownika root oraz podajemy adres email. Po konfiguracji naszego usera przechodzimy do ustawień sieciowych. Tu należy zwrócić uwagę na nasze ustawienia. Ja w swoje konfiguracji posiadam dwie karty sieciowe. Wybieramy właściwą i sprawdźmy ustawienia. Wbrew pozorom nie są one ustawieniami z DHCP. Zdarzyło mi się, że miałem tu mix ustawień z dwóch różnych sieci. Dlatego warto sprawdzić czy wartości są prawidłowe. By potem uniknąć grzebania w plikach konfiguracyjnych systemu operacyjnego. Po akceptacji ustawień sieci mamy swoiste podsumowanie, oraz opcję automatycznego restartu po instalacji. Po kliknięciu INSTALL proces instalacji zaczyna się i może zająć od kilku do kilkunastu minut. Po procesie instalacji mamy komunikat o zakończeniu instalacji i wizard odczega 10 sekund po czym automatycznie zrestartuje komputer. Tutaj musimy być uważni by po komunikacie wyciągnąć nośnik USB/ISO Jak nasz system już się uruchomi przywita nas komunikatem na jakim adresie IP jest dostępny nasz panel dla naszego proxmox. Logujemy się do panelu akceptując połączenie w naszej przeglądarce internetowej Uwierzytelnianie mamy na poziomie PAM Linux a zatem login i hasło to nasz użytkownik root oraz hasło które podaliśmy podczas instalacji. Po zalogowaniu może pokazać się komunikat o braku subskrypcji na proxmox. Możemy ten komunikat zignorować i później zakupić licencje proxmox Oto nasz panel proxmox do zarządzania serwerem lub naszym klastrem. Jak zalogujemy się do każdego z naszych trzech węzłów, to przywita nas podobny obraz. Proxmox w pojedynczej instalacji, zaraz świeżo po wyciągnięciu ISO juz działa w jednym klastrze o nazwie datacenter. Dlatego moje trzy węzły będą miały domyślny klaster jedno węzłowy a tylko będą różnić się nazwą naszego hosta. Po kliknięciu też na nazwę zmieni się nasze menu z menu klastra na menu hosta Menu naszego klastra - zaraz po instalacji jest to klaster jednowęzłowy (bez HA) Menu ustawień naszego węzła Konfiguracja klastra proxmox Ok przystąpmy zatem do konfiguracji naszego klastra i węzłów proxmox. Dodajmy certyfikat jeżeli posiadasz. Ja dodam dla mojej domeny *.koska.in przechodzę do menu wezła i klikam SYSTEM -> CERTIFICATE a potem w oknie UPLOAD CUSTOM CERTIFICATE Dodajemy nasz certyfikat po przez wklejenie lub otwarcie odpowiedniego pliku z certyfikatem i kluczem. Certyfikat został załadowany co potwierdza nasz panel Przejdźmy teraz do ustawień sieciowych - ja mam dodatkowa kartę sieciowa któa jest podłaczona do sieci 192.168.1.0/24 a zatem dokonfiguruje mostek sieciowy dla tej karty. Klikamy na Menu naszego węzła SYSTEM -> NETWORK a potem na liście interfejsów klikamy przycisk CREATE i z listy wybieramy LINUX BRIDGE W konfiguracji naszego LINUX BRIDGE ustawiamy name według konwencji w proxmox nadajemy adres IPv4/CIDR, gateway pozostawiam pusty bo mam juz jedna kartę z ustawionym GW. Wskazuje na koniec BRIDGE PORTS, czyli nazwę mojego interfejsu na podstawie którego stworze LINUX BRIDGE Po ustawieniu mojego LINUX BRIDGE nie pozostaje mi nic innego jak zaakceptować konfigurację poprzez przycisk APPLY CONFIGURATION Po akceptacji naszej konfiguracji zobaczymy że nasz nowy interfejs jest ACTIVE z statusem YES zarówno bridge jak i wcześniejsza karta sieciowa. Tworzymy klaster proxmox Możemy stworzyć nasz klaster proxmox - wybieramy dowolny węzeł który nam za inicjalizuje klaster. Ja wybrałem host pve01 (ale można wybrać dowolny). Przechodzimy do menu klastra i tam szukamy opcji CLUSTER. Klikamy na przycisk CREATE CLUSTER Nadajemy nazwę dla naszego klastra oraz wybieramy karty sieciowe na podstawie których będzie się komunikował nasz klaster z innymi węzłami Po kliknięciu w create czekamy na komunikat TASK OK i możemy zamknąc okno. Lub przejrzeć STATUS klastra i inicjalizacje naszej konfiguracji Po zamknięciu okna możemy wyświetlić CLUSTER JOIN INFORMATION - ta informacje pomożem nam połaczyć inne węzły do naszego klastra. Kopiujemy te informacje i przechodzimy do pve02 a potem pve03 Na pve02 przechodzimy do menu klastra DATACENTER -> CLUSTER i wybieramy przycisk JOIN CLUSTER W oknie JOIN CLUSTER podajemy wymagane informacje oraz podajemy hasło do naszego klastra z hosta na którym wykonywaliśmy inicjalizację. Po wypełnieniu klikamy JOIN HOMEPROXMOX - w moim przypadku (u Ciebie ta nazwa będzie zależna od nazwy klastra jaką wybrałeś) Po kliknieciu JOIN ... pokaże się okno informujące nas o całym procesie połączeniowym. Jeżeli po przejściu na status pokaze nam sie Connection error - to oznaka że nasze ustawiania się przeładował i my musimy nasz panel odświeżyć Po przeładowaniu strony możemy sobie zobaczyć że teraz na DATACENTER zawiera nazwę naszego klastra i widzimy też nasze węzły uczestniczące w klastrze. To koniec inicjalizacji naszego klastra. Zajmijmy się teraz konfiguracja naszego Storage tego lokalnego jak i sieciowego. Zobaczmy jakie mamy opcje storage w naszym klastrze proxmox. Klaster Proxmox - nasz storage Z pewnych ograniczeń związanych z moim środowiskiem domowego laboratorium nie przetestuję wszystkich rodzajów storage w proxmox ale uważam że dam dobre overview na ustawienia i możliwości konfiguracji naszego data storage. Proxmox plus synology - na pierwszy ogień NFS, SMB W mojej konfiguracji wykorzystam serwer NAS synology, dla osób lubiących parametry przedstawiam specyfikację konfiguracji mojego NAS synology: Storage w synology to dyski o pojemności 1.8T, łącznie 5 dysków. Co daje przestrzeń o pojemności 7.3 TB. W zupełności wystarczy to na domowy backup, kilka lokalnych maszyn wirtualnych oraz storage dla innych maszyn wirtualnych. Zobaczymy jaki storage sieciowy mamy do dyspozycji w proxmox, i powiem jest ich trochę sporo i każdy znajdzie coś dla siebie. Skonfigurujemy zatem najbardziej popularne i chyba dostępne w każdym domowym lab czyli SAMBA i NFS. Będziemy potrzebować osobnego usera tak by śledzić logi naszego połączenia z proxmox i w łatwiejszy sposób wychwycić jakiekolwiek błędy konfiguracyjne. Tworzymy odpowiednie foldery współdzielone gdzie będziemy osobno przechowywać dane dla VM po protokole SMB i NFS. Pamiętajmy o odpowiednim nadaniu uprawnień tak byśmy mogli się połączyć Tak samo dla NFS jak i SMB Oczywiście samo obsługa SAMBY musi być włączona na naszym serwerze synology NFS rownież - nie zapomnijmy o tym tak by niepotrzebnie nie debugować problemów z połączeniem z powodu braku usługi Dlaczego w klastrze proxmox w ogóle potrzebny nam storage taki jak wspomniany wyżej NFS i SMB. Niech jako prosty przykład posłuży chociażby nasz obraz ISO z Ubuntu. Jeżeli wgramy go na storage który mamy do dyspozycji od samego początku i zwie się on local. To ISO z instalatorem naszego Ubuntu będzie dostępne tylko dla tego węzła na którym to wgram - w tym przypadku będzie to pve01.koska.in. Przesyłamy ISO z naszego lokalnego komputera (mamy też możliwość wskazania url - jakby nasz lokalny komputer znajdował się w innej lokalizacji niż nasz klaster) To po przesłaniu pliku ISO gdy przejdziemy do innego węzła na nasz storage local zobaczymy, że tego ISO tam nie ma i akcję musimy powtórzyć dla wszystkich węzłów. Więc dodajmy w konfiguracji nasz SMB i NFS. Zanim to zrobię przygotuję sobie FQDN nfs.koska.in oraz smb.koska.in w celu łatwiejszej konfiguracji i unikania podawania adresów IP. W tym celu wykorzystam moja konfigurację w terraform do zarządzania strefą koska.in. Dokonam zmian w pliku konfiguracyjnym i całość prześlę do GIT. Git jest monitorowany przez Jenkins do którego jest podpięty pipeline który wykona mi odpowiednie testy i wdroży zmianę automatycznie, bez mojej ingerencji. Oczywiście w każdej chwili mogę zweryfikować status moich zmian w danym jobie. W tym przypadku moje dwa rekordy zostały dodane, plus też jeden skasowałem. Oczywiście usunięcie była tu świadome i zbiegło się z moją operacją dodnia nfs.koska.in oraz smb.koska.in. Zweryfikuję czy moj host widzi już te zmiany. I jak widać wszystko jest ok zatem mogę przejść do konfiguracji. Operacja dodania już sama w sobie jest prosta - dodawanie NFS. Uzupełniamy odpowiednio ID, server, export i content - w tym przypadku nfs będzie zawierał tylko dyski kontenerów i maszyn wirtualnych. Podobna konfiguracja jest w SMB. Uzupełniam wszystkie wymagane pola i zapisuję konfigurację. Storage dodany na poziomie Klastra Home Proxmox jak widzimy został dodany poprawnie i jest widziany przez wszystkie klastry. W tym wpisie to wszystko. W kolejnej części zajmiemy się innymi rodzajami storage, uruchomieniem maszyny wirtualnej, backup i replikacji oraz zautomatyzujmy nasz klaster, tak by za dużo w nim nie klikać. Pozdrawiam
- AWX-operator - Instalacja i testowanie w docker desktop, kubernetes
Czym jest awx-operator awx-operator to operator Kubernetes stworzony, aby ułatwić wdrażanie, konfigurację i zarządzanie instancjami AWX na klastrach Kubernetes. AWX jest otwartoźródłową wersją Ansible Tower, narzędziem zaprojektowanym do zarządzania i uruchamiania zadań w Ansible w skali korporacyjnej. Główne funkcje awx-operator Automatyczne wdrażanie: Pozwala na łatwe wdrożenie AWX w klastrze Kubernetes za pomocą jednego polecenia. Konfiguracja: Operator umożliwia dostosowywanie różnych aspektów instancji AWX, takich jak ilość zasobów, konfiguracja baz danych czy dostęp do zewnętrznych systemów magazynowania. Automatyczne aktualizacje: Dzięki operatorowi, aktualizacja AWX może odbywać się płynnie, bez konieczności manualnej interwencji. Zarządzanie stanem: Operator dba o to, aby instancje AWX działały poprawnie i były w odpowiednim stanie. Monitoruję, czy wszystkie komponenty działają poprawnie i podejmuje odpowiednie działania w przypadku problemów. Zastosowanie awx-operator Uproszczenie zarządzania: Dzięki awx-operator, administracja wieloma instancjami AWX w klastrze Kubernetes staje się prostsza. Integracja z chmurą: Możliwość uruchamiania AWX na platformach typu Kubernetes ułatwia integrację z popularnymi usługami chmurowymi. Skalowalność: Korzystanie z Kubernetes w połączeniu z awx-operator pozwala na łatwe skalowanie instancji AWX, zarówno w górę, jak i w dół, w zależności od aktualnych potrzeb. AWX - czym jest AWX to otwartoźródłowa wersja Ansible Tower. Jest to narzędzie webowe zaprojektowane do zarządzania i uruchamiania zadań w Ansible. Ansible to popularne narzędzie do automatyzacji, służące do konfiguracji systemów, wdrażania aplikacji oraz zarządzania orkiestracją. AWX stanowi "kontrolne centrum dowodzenia" dla Ansible, umożliwiające zarządzanie playbookami, zmiennymi, inwentarzami i dostępnymi hostami w centralny i uporządkowany sposób. Kluczowe funkcje AWX Interfejs Użytkownika: AWX oferuje graficzny interfejs użytkownika, który umożliwia łatwe zarządzanie i monitorowanie zadań Ansible. Rest API: Oprócz interfejsu użytkownika, AWX udostępnia RESTful API, co ułatwia integrację z innymi narzędziami i skryptami. Planowanie Zadań: AWX pozwala na planowanie uruchamiania playbooków Ansible w określonych terminach lub cyklicznie. Zarządzanie Inwentarzem: Możesz definiować i grupować hosty, na których będą uruchamiane zadania, oraz synchronizować inwentarze z różnymi źródłami, takimi jak AWS, Google Cloud czy Azure. Role-Based Access Control (RBAC): AWX umożliwia definiowanie uprawnień na podstawie ról, dzięki czemu można precyzyjnie kontrolować, kto ma dostęp do określonych zasobów i jakie akcje może wykonywać. Zarządzanie Credentialem: Bezpieczne przechowywanie i zarządzanie danymi uwierzytelniającymi, które są używane podczas uruchamiania playbooków. Wizualizacje: AWX dostarcza wizualizacje w postaci diagramów i statystyk, umożliwiające szybki wgląd w status operacji oraz historię uruchomień. Integracja z systemami powiadomień: Możliwość wysyłania powiadomień na różne kanały, takie jak e-mail, Slack czy nawet webhooki, w odpowiedzi na różne zdarzenia w systemie. Zastosowanie AWX Centralne zarządzanie konfiguracją: Zarządzaj konfiguracją różnych systemów i aplikacji z jednego centralnego miejsca. Automatyzacja zadań IT: Automatyzuj rutynowe zadania, takie jak wdrażanie oprogramowania, zarządzanie użytkownikami czy aktualizacje systemowe. Orkiestracja wielostanowiskowa: Koordynuj działania pomiędzy różnymi środowiskami i platformami. Integracja z innymi narzędziami DevOps: Dzięki REST API, AWX może być łatwo zintegrowany z narzędziami takimi jak Jenkins, GitLab czy Jira. Konfiguracja AWX-operatora Przystąpmy zatem do konfiguracji naszego awx-operatora. Na początek potrzeba nam klastra kubernetes. Możesz wykorzystać dowolny. Jeżeli nie masz klastra kubernetes skonfigurowanego możemy skorzystać z docker-desktop i włączyć funkcje kubernetes na platformie docker. Docker desktop Zatem pobieramy naszą platformę docker desktop instalujemy naszą aplikację i po jej uruchomieniu włączmy funkcje kubernetes - jak to zrobić przedstawiają obrazki poniżej. Przechodzimy do ustawień aplikacji docker desktop, a potem w ustawieniach przechodzimy w sekcje kubernetes i włączamy nas engine k8s Zaznaczamy funkcje Enable Kubernetes i restartujemy klaster po przez Apply & restart - kubernetes zaczyna się uruchamiać zajmie to kilkadziesiąt sekund. Po uruchomieniu kubernetesa w docker sprawdzamy działanie naszego polecenia kubectl (jeżeli nie masz tego polecenia to zobacz jak go zainstalować z oficjalnej dokumentacji o instalacji kubectl) Wydajemy polecenie kubectl version: $ kubectl version WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short. Use --output=yaml|json to get the full version. Client Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.2", GitCommit:"7f6f68fdabc4df88cfea2dcf9a19b2b830f1e647", GitTreeState:"clean", BuildDate:"2023-05-17T14:20:07Z", GoVersion:"go1.20.4", Compiler:"gc", Platform:"linux/amd64"} Kustomize Version: v5.0.1 Unable to connect to the server: dial tcp: lookup k3s1.koska.in on 192.168.64.1:53: no such host I jeżeli tak ja ja masz kilka kontekstów konfiguracyjnych kubernetes to musimy zmienić kontekst pracy z naszym klastrem dla polecenia kubectl - robimy to za pomocą polecania: kubectl config use-context docker-desktop Na obrazku powyżej widać aktualna wersję uzywana umnie oraz kontekst na jaki mam ustawione polecenie kubectl - takie wyśietlenie dale shell zsh z nakładka oh my zsh Oczywiście mozna sprawdzic to poleceniem kubectl config get-contexts Na koniec sprawdźmy czy działa nasz klaster poleceniem kubectl get nodes -> i powinniśmy otrzymać coś takiego: $ kubectl get nodes NAME STATUS ROLES AGE VERSION docker-desktop Ready control-plane 28m v1.27.2 UWAGI: Nie musimy korzystać z docker-desktop i kubernetesa w nim. Możemy skorzystać z platformy minikube, w dokumentacji awx-operator znajdziemy instrukcje jak przygotować klaster minikube. Plan naszej konfiguracji Na początku musimy się zastanowić gdzie będziemy trzymać naszą bazę danych postgresql dla naszego AWX - mamy do wyboru w klastrze kubernetes (awx-operator stawia i robi to za nasz przy czystej instalacji) lub na osobnym serwerze - dedykowana instancja (nie zarządzana przez awx-operator). W przypadku drugiej konfiguracji mamy to opisane w dokumentacji związanej z konfiguracja bazy danych Ja w tym wpisie pójdę druga drogą, pierwsza po prostu pomija konfiguracja secretu dla bazy danych. Przygotowanie pliku kustomization.yaml Na początek musimy przygotować nasz plik kustomization.yaml (możemy bazować na tym dostępnym w instrukcji podstawowej instalacji) plik u mnie przedstawia się następująco: apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - github.com/ansible/awx-operator/config/default?ref=2.7.0 images: - name: quay.io/ansible/awx-operator newTag: 2.7.0 namespace: default Ten kod przedstawia plik `Kustomization`, który jest częścią narzędzia `kustomize` używanego do dostosowywania zasobów Kubernetes. Pozwala on na tworzenie wielowarstwowych konfiguracji na bazie istniejących zasobów, bez konieczności modyfikowania oryginalnych plików YAML. Rozbijmy ten konkretny plik `Kustomization` na poszczególne sekcje: apiVersion i kind: - `apiVersion`: Określa wersję API, z którą jest zgodny ten plik. W tym przypadku używana jest wersja `v1beta1` związana z `kustomize.config.k8s.io`. - `kind`: Określa typ obiektu. W tym przypadku jest to `Kustomization`, co wskazuje, że jest to plik konfiguracyjny dla `kustomize`. resources: - W tej sekcji określono zasoby, które mają być uwzględnione w procesie dostosowywania. - W tym przypadku zasób jest pobierany z repozytorium GitHub (`github.com/ansible/awx-operator`). Szczególnie korzysta z konfiguracji znajdującej się w katalogu `config/default` w odniesieniu do tagu `ref=2.7.0`. images: - Ta sekcja pozwala na modyfikację obrazów używanych w zasobach. Możliwe jest podmienienie nazwy obrazu, tagu lub repozytorium. - W tym przypadku obraz `quay.io/ansible/awx-operator` jest modyfikowany tak, aby używać tagu `2.7.0`. namespace: - Określa przestrzeń nazw, w której mają zostać wdrożone zasoby. W tym przypadku jest to przestrzeń nazw `default`. Możemy zatem wydać polecenie kubectl apply -k . które uruchomi nam nasza konfigurację: $ kubectl apply -k . Warning: resource namespaces/default is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically. namespace/default configured customresourcedefinition.apiextensions.k8s.io/awxbackups.awx.ansible.com created customresourcedefinition.apiextensions.k8s.io/awxrestores.awx.ansible.com created customresourcedefinition.apiextensions.k8s.io/awxs.awx.ansible.com created serviceaccount/awx-operator-controller-manager created role.rbac.authorization.k8s.io/awx-operator-awx-manager-role created role.rbac.authorization.k8s.io/awx-operator-leader-election-role created clusterrole.rbac.authorization.k8s.io/awx-operator-metrics-reader created clusterrole.rbac.authorization.k8s.io/awx-operator-proxy-role created rolebinding.rbac.authorization.k8s.io/awx-operator-awx-manager-rolebinding created rolebinding.rbac.authorization.k8s.io/awx-operator-leader-election-rolebinding created clusterrolebinding.rbac.authorization.k8s.io/awx-operator-proxy-rolebinding created configmap/awx-operator-awx-manager-config created service/awx-operator-controller-manager-metrics-service created deployment.apps/awx-operator-controller-manager created Ostrzeżenie: W wyniku pojawiło się ostrzeżenie dotyczące zasobu namespaces/default. Mówi ono o braku anotacji kubectl.kubernetes.io/last-applied-configuration, która jest wymagana przez kubectl apply. Ostrzeżenie sugeruje, że powinieneś używać polecenia kubectl apply tylko na zasobach utworzonych deklaratywnie przez kubectl create --save-config lub kubectl apply. Brakująca anotacja zostanie dodana automatycznie. Zasoby: namespace/default configured: Przestrzeń nazw default została skonfigurowana. Słowo kluczowe "configured" wskazuje, że zasób istniał wcześniej i został zmodyfikowany, a nie stworzony od nowa. customresourcedefinition.apiextensions.k8s.io/... created: Trzy Custom Resource Definitions (CRD) dla awxbackups, awxrestores i awxs zostały utworzone. CRD pozwala na dodanie własnych zasobów do API Kubernetes. serviceaccount/awx-operator-controller-manager created: Utworzono ServiceAccount o nazwie awx-operator-controller-manager. Role i ClusterRole (role.rbac.authorization.k8s.io/... i clusterrole.rbac.authorization.k8s.io/... created): Utworzono różne role i clusterrole, które definiują zestaw uprawnień na zasoby w klastrze. RoleBindings i ClusterRoleBindings (rolebinding.rbac.authorization.k8s.io/... i clusterrolebinding.rbac.authorization.k8s.io/... created): Utworzono rolebindings i clusterrolebindings, które przypisują określone role do użytkowników lub grup. configmap/awx-operator-awx-manager-config created: Utworzono ConfigMap, który przechowuje konfigurację dla managera AWX. service/awx-operator-controller-manager-metrics-service created: Utworzono usługę (Service) służącą do zbierania metryk z kontrolera awx-operator-controller-manager. deployment.apps/awx-operator-controller-manager created: Utworzono Deployment dla kontrolera awx-operator-controller-manager, który definiuje i kontroluje instancje aplikacji. Między czasie możemy sprawdzić czy konfiguracja ta stworzyła i działają nasze pody, poleceniem kubectl get pods $ kubectl get pods NAME READY STATUS RESTARTS AGE awx-operator-controller-manager-54fd9bc446-zl562 0/2 ContainerCreating 0 21s Jak nasze pody dla awx będą ze statusem running wtedy możemy sprawdzić dodatkowo logi dla naszego deployment i zobaczyć czy wszystko z naszym deployment jest ok. $ kubectl logs -f deployments/awx-operator-controller-manager -c awx-manager {"level":"info","ts":"2023-10-25T08:53:13Z","logger":"cmd","msg":"Version","Go Version":"go1.19.11","GOOS":"linux","GOARCH":"amd64","ansible-operator":"v1.31.0","commit":"e67da35ef4fff3e471a208904b2a142b27ae32b1"} {"level":"info","ts":"2023-10-25T08:53:13Z","logger":"cmd","msg":"Watching single namespace.","Namespace":"default"} {"level":"info","ts":"2023-10-25T08:53:13Z","logger":"controller-runtime.metrics","msg":"Metrics server is starting to listen","addr":"127.0.0.1:8080"} {"level":"info","ts":"2023-10-25T08:53:13Z","logger":"watches","msg":"Environment variable not set; using default value","envVar":"ANSIBLE_VERBOSITY_AWX_AWX_ANSIBLE_COM","default":2} {"level":"info","ts":"2023-10-25T08:53:13Z","logger":"watches","msg":"Environment variable not set; using default value","envVar":"ANSIBLE_VERBOSITY_AWXBACKUP_AWX_ANSIBLE_COM","default":2} {"level":"info","ts":"2023-10-25T08:53:13Z","logger":"watches","msg":"Environment variable not set; using default value","envVar":"ANSIBLE_VERBOSITY_AWXRESTORE_AWX_ANSIBLE_COM","default":2} {"level":"info","ts":"2023-10-25T08:53:13Z","logger":"ansible-controller","msg":"Watching resource","Options.Group":"awx.ansible.com","Options.Version":"v1beta1","Options.Kind":"AWX"} {"level":"info","ts":"2023-10-25T08:53:13Z","logger":"ansible-controller","msg":"Watching resource","Options.Group":"awx.ansible.com","Options.Version":"v1beta1","Options.Kind":"AWXBackup"} {"level":"info","ts":"2023-10-25T08:53:13Z","logger":"ansible-controller","msg":"Watching resource","Options.Group":"awx.ansible.com","Options.Version":"v1beta1","Options.Kind":"AWXRestore"} {"level":"info","ts":"2023-10-25T08:53:13Z","logger":"proxy","msg":"Starting to serve","Address":"127.0.0.1:8888"} {"level":"info","ts":"2023-10-25T08:53:13Z","logger":"apiserver","msg":"Starting to serve metrics listener","Address":"localhost:5050"} {"level":"info","ts":"2023-10-25T08:53:13Z","msg":"Starting server","path":"/metrics","kind":"metrics","addr":"127.0.0.1:8080"} awx.yml W tym samym katalogu gdzie stworzyliśmy nasz plik kustomization.yaml tworzymy nasz plik awx.yml zawierający konfiguracje naszego serwisu awx: --- apiVersion: awx.ansible.com/v1beta1 kind: AWX metadata: name: awx spec: service_type: NodePort service_labels: | environment: production hostname: ansible.koska.in postgres_configuration_secret: awx-postgres-configuration ingress_type: none ipv6_disabled: true db.yml Tworzymy nasz plik konfiguracyjny z konfiguracja polaczenia do naszej bazy danych --- apiVersion: v1 kind: Secret metadata: name: awx-postgres-configuration namespace: default stringData: host: port: "" database: username: password: "" sslmode: disable type: unmanaged type: Opaque Nasza baza danych W celu udawania zewnętrznego hosta z bazą danych postawie moja baze danych postgresql w kontenerze z wykorzystaniem docker-compose.yml: services: # postgres server db: image: postgres:13.9 restart: always environment: POSTGRES_PASSWORD: example ports: - 5432:5432 Uruchommy naszą bazę danych. W katalogu z plikiem docker-compose.yml wydajemy komende docker compose up -d Jak możemy zobaczyć wszystko się udało - nasz baza danych została postawiona i uruchomiona. Oczywiście w konfiguracji docker-compose brakuje pewnych parametrów związanych z zachowaniem danych. Jednak w ramach tego testu pozwoliłem sobie je pominąć - nie zależy mi na zachowaniu danych w tym akurat przypadku. Pozostaje nam dodać naszą bazę danych z której będzie korzystał AWX, logujemy sie do kontenera z terminala lub przez docker desktop. W przypadku terminala będzie to polecenie: $ docker compose exec -it "db" bash Znajdziemy się teraz w kontenerze i wydajmy komendę w celu stworzenia bazy danych. createdb -U postgres -h 127.0.0.1 awxdb Mamy stworzoną bazę danych. Możemy pobrać pgadmin i sprawdzić działanie naszej bazy oraz czy dodatkowa baza została utworzona. Mamy potwierdzone że serwer bazy danych działa i mamy stworzona bazę danych teraz powróćmy do naszego pliku db.yml i uzupełnijmy nasze brakujące dane. Uzupełniamy db.yml Nasz plik musimy uzupełnic o nastepujace dane: host: port: "" database: username: password: "" Port znamy jest to 5432, database to awxdb, username i password wykorzystamy domyślne zdefiniowane w docker compose. Pozostaje nam zatem adres IP. Sprawdźmy zatem jak nasz klaster w przypadku konfiguracji docker desktop widzi sieci. Posłużymy się podem uruchomionym na naszym klastrze, uruchomimy go za pomoca naszego pliku konfiguracyjnego ubuntu-pod.yml: apiVersion: v1 kind: Pod metadata: name: ubuntu-pod namespace: default spec: containers: - name: ubuntu-container image: ubuntu:latest command: - sleep - "infinity" Wydajemy polecenie: $ kubectl apply -f ubuntu-pod.yml A potem łączymy się do naszego poda $ kubectl exec -n default -it ubuntu-pod -- /bin/bash I wydajemy zestaw komend: apt update ping apt install iputils-ping telnet ping or Adres IP_NODE_CLUSETR możemy zdobyć z polecania: $ kubectl get nodes -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME docker-desktop Ready control-plane 3h24m v1.27.2 172.31.255.3 Docker Desktop 5.15.90.1-microsoft-standard-WSL2 docker://24.0.6 Jak ktoś nie ufa ping można jeszcze uruchomić telnet ( or ) Zatem mamy wszystkie informacje. Możemy uzupełnić nasz db.yml --- apiVersion: v1 kind: Secret metadata: name: awx-postgres-configuration namespace: default stringData: host: 192.168.79.146 port: "5432" database: awxdb username: postgres password: "example" sslmode: disable type: unmanaged type: Opaque Dodajemy sekrety Do naszej pierwotnej konfiguracji kustomization.yaml dodajemy dodatkowa linijkę z naszym plikiem db.yml ... resources: - github.com/ansible/awx-operator/config/default?ref=2.7.0 - db.yml ... Zmiany zapisujemy i uruchamiamy nasze polecenie kubectl apply -k . ... secret/awx-postgres-configuration created ... kubectl poinformuje nas o tym że sekret został dodany / stworzony. Teraz dodajemy nasz awx.yml do kustomization.yaml ... resources: - github.com/ansible/awx-operator/config/default?ref=2.7.0 - db.yml - awx.yml ... Zmiany zapisujemy i uruchamiamy nasze polecenie kubectl apply -k . Po wydaniu polecenia możemy od razu wskoczyć w logi naszego awx-menagera $ kubectl logs -f deployments/awx-operator-controller-manager -c awx-manager Warto podczas działania uruchamiania naszych podów i konfiguracji potrzeć czy jakie dane przechodzą do naszego postgres. Z poziomu kubectl możemy sprawdzić nasze pody czy mają odpowiedni status: kubectl get pods -l "app.kubernetes.io/managed-by=awx-operator" Oraz na jakim porcie działa nasza aplikacja: kubectl get svc -l "app.kubernetes.io/managed-by=awx-operator" Hasło do naszego panelu możemy pobrać z polecenia: kubectl get secret awx-admin-password -o jsonpath="{.data.password}" | base64 --decode ; echo Mamy nasz panel i możemy się zalogować - oczywiscie to tylko testowa konfiguracja ale na jej bazie możemy już planować nasze wdrożenia. A w tym artykule to już wszystko. Zapraszam do kolejnych wpisów.
- Podsumowanie Aktualizacji Bezpieczeństwa iOS 17.1 i iPadOS 17.1:
Apple udostępnił aktualizację łatająca luki bezpieczeństwa: https://support.apple.com/en-us/HT213982 https://support.apple.com/en-us/HT201222 udostępniono też aktualizacje w linii 16 oraz 15 (tutaj wspierany jest np. iPhone 6s, który wyszedł w 2015 roku!) W iOS 17.1 załatano aż trzy podatności umożliwiające na wykonanie kodu w OS, po wejściu na zainfekowaną stronę: Impact: Processing web content may lead to arbitrary code execution Data wydania: 25 października 2023 1. Kontakty - Wpływ: Aplikacja może uzyskać dostęp do wrażliwych danych użytkownika. - Opis: Poprawiono prywatność danych dziennika. 2. CoreAnimation - Wpływ: Aplikacja może spowodować odmowę usługi (denial-of-service). - Opis: Poprawiono zarządzanie pamięcią. 3. Find My - Wpływ: Aplikacja może odczytać wrażliwe informacje o lokalizacji. - Opis: Poprawiono zarządzanie pamięcią podręczną. 4. ImageIO - Wpływ: Przetwarzanie obrazu może prowadzić do ujawnienia pamięci procesu. - Opis: Poprawiono zarządzanie pamięcią. 5. IOTextEncryptionFamily - Wpływ: Aplikacja może wykonywać dowolny kod z uprawnieniami jądra. - Opis: Poprawiono zarządzanie pamięcią. 6. Kernel - Wpływ: Atakujący może omijać zabezpieczenia pamięci jądra. - Opis: Poprawiono zarządzanie pamięcią. 7. Mail Drafts - Wpływ: Funkcja "Hide My Email" może zostać nieoczekiwanie wyłączona. - Opis: Poprawiono zarządzanie stanem. 8. mDNSResponder - Wpływ: Urządzenie można śledzić za pomocą adresu MAC Wi-Fi. - Opis: Usunięto podatny kod. 9. Passkeys - Wpływ: Atakujący może uzyskać dostęp do kluczy bez uwierzytelniania. - Opis: Poprawiono sprawdzanie. 10. Photos - Wpływ: Zdjęcia w ukrytym albumie mogą być przeglądane bez uwierzytelniania. - Opis: Poprawiono zarządzanie stanem. 11. Pro Res - Wpływ: Aplikacja może wykonywać dowolny kod z uprawnieniami jądra. - Opis: Poprawiono zarządzanie pamięcią. 12. Siri - Wpływ: Atakujący z fizycznym dostępem może używać Siri do uzyskiwania wrażliwych danych użytkownika. - Opis: Ograniczono opcje dostępne na zablokowanym urządzeniu. 13. Status Bar - Wpływ: Urządzenie może nieustannie nie blokować się. - Opis: Poprawiono zarządzanie interfejsem użytkownika. 14. Weather - Wpływ: Aplikacja może uzyskać dostęp do wrażliwych danych użytkownika. - Opis: Poprawiono prywatność danych dziennika. 15. WebKit (różne błędy) - Wpływ: Przetwarzanie treści internetowych może prowadzić do wykonywania dowolnego kodu lub odmowy usługi. - Opis: Poprawiono zarządzanie pamięcią, usunięto błędy logiczne i poprawiono sprawdzanie. Uwaga: Wszystkie powyższe aktualizacje są dostępne dla modeli iPhone XS i nowszych oraz różnych modeli iPad Pro, iPad Air, iPad oraz iPad mini. Zalecamy instalację tych aktualizacji, aby zapewnić bezpieczeństwo i ochronę swoich urządzeń Apple.
- Jenkins pipeline - Iac w CI/CD
Wśród narzędzi CI/CD Jenkins jest jednym z najpopularniejszych i darmowych narzędzi dostępnych w wielu organizacja i procesach devops. Jedni go kochają inni nienawidzą. Sam artykuł nie jest o tym czy to narzędzie jest popularne czy też nie, ale każdy sie zemną zgodzi że jest idelnym toolsetem do nauki procesów CI/CD oraz do automatyzacji zadań. Pierwszy projekt w jenkins Kluczem do każdej konfiguracji jest dobre rozplanowanie tego co chcemy uzyskać i co mamy ustawić / skonfigurować. Weźmy rozdzielmy na czynniki pierwsze konfiguracje z tego materiału - Terraform w procesach CI/CD w postaci grafu Prosty przepływ składający się z 5 jobów z których w łatwy sposób wyróżnić 3 główne od których zależy cała logika. Logika w tym przypadku przekładająca się na konfigurację w claud za pomocą IaC narzędzia jakim jest terraform. I choć długo podobały mi się projekty zwane "Freestyle project", które swoją prostotą powodują że łatwiej nam wejść w skórę devopsa i skonfigurować taki projekt to mają one pewną wadę. Spójrzmy na te 5 poszczególnych jobów. Mają one na pierwszy rzut oka jeden wspólny kod git, jednak jak możemy zobaczyć musimy go w każdym jobie podawać osobno i konfigurować. Dostarcza to dodatkowej pracy. A i może spowodować to, że przy n-tej próbie wpisywania i uzupełniania tych danych możemy zrobić literówkę. I wcale tu nie chodzi o jakieś generalizowanie czy też zniechęcenie do tego rodzaju projektów czy też konstrukcji własnych procesów CI/CD własnie w ten sposób. A gdyby tak tą całą konfiguracje przekształcic w kod i zapisać za pomocą pliku tekstowego i przechowywać ją w git. Znacząco by to ułatwiło konfiguracje i pracę z takim pipelinem / projektem. Jenkins pipeline projekt By sprostać temu zadaniu spójrzmy na pipeline syntax dostępnym w dokumentacji Jenkins do pipeline. Na podstawie zgromadzonej tu dokumentacji możemy stworzyć prosty zarys naszego projektu. Spójrzmy najpierw na prostą konstrukcje, która nam wszystko wytłumaczy: Podnajmy analizie ten "pseudo kod": agent any: Wskazuje, że ten potok może być uruchamiany na dowolnym agencie dostępnym w środowisku Jenkins. stage('Build'): Etap ten ma za zadanie kompilację kodu źródłowego. Po pomyślnej kompilacji, artefakty z budowy są przenoszone w pożądaną lokalizację. stage('Test'): W tym etapie najpierw sprawdza się, czy artefakty są obecne we właściwej lokalizacji. Następnie dane testowe są ładowane do bazy danych. Wykonuje się testy. Kontynuacja następuje tylko w przypadku, gdy testy zostaną zakończone pomyślnie. stage('Deploy'): W etapie tym pobierany jest przetestowany kod, który następnie jest wdrażany na produkcję. Spójrzmy raz jeszcze na nasz graf tak by zobaczyć czy uda nam się dostrzec te elementy w naszej konfiguracji: Wyodrębniłem trzy kroki: Krok pierwszy to nasz build - czyli pobieranie kody z repozytorium git w kontekście naszego joba czyli naszej deklaracji w jenkins pepline. Krok drugi tu zbiorczo nasze test: validate, security, plan, graph - z diagramu tez widzimy że nasze security i graph nie jest istotne z punktu przepływy pracy naszego joba. Ich rezultat nie wpływa na nasz pipeline (jeżeli podąrzamy za zielona linią). Krok trzeci nasz deploy - czyli w tym przypadku apply, który to już publikuje nasze zmiany w stanie terraform i na naszym cloud. Przedstawmy to w postaci pseudokodu: node: Pseudo-kod ten jest zapisany w starszym stylu deklaratywnnych pipeline'ów Jenkins. Używa on słowa kluczowego `node`, co oznacza, że wszystkie etapy i kroki wewnątrz tego bloku będą wykonywane na jednym agentcie Jenkins. stage('Build'): W tym etapie wydaje się, że kod z repozytorium git jest klonowany. Następnie następuje inicjalizacja środowiska Terraform poprzez komendę `terraform init`. stage('Test'): Etap testowania rozpoczyna się od sprawdzenia poprawności składniowych i błędów w konfiguracji za pomocą `terraform validate`. Następnie jest tworzony plan działania (bez rzeczywistego stosowania zmian) za pomocą `terraform plan`. Warunek if: Sprawdza się status bieżącej kompilacji (`currentBuild.currentResult`). Jeśli wynik bieżącej kompilacji to 'SUCCESS', oznacza to, że etapy 'Build' i 'Test' zakończyły się pomyślnie i można przejść do etapu 'Deploy'. stage('Deploy'): W tym etapie rzeczywiste zmiany są stosowane w środowisku za pomocą `terraform apply`. Jest to prosta definicja pipeline, która wykorzystuje narzędzie Terraform do budowy, testowania i wdrażania infrastruktury jako kod (Infrastructure as Code, IaC). Kluczowe etapy obejmują inicjalizację Terraform, walidację, planowanie i zastosowanie zmian w infrastrukturze. Aby ten pseudo-kod mógł być używany w rzeczywistym środowisku, muszę zastąpić komentarze rzeczywistymi poleceniami i skryptami, które będą realizować te działania. Warto również dodać obsługę błędów i ewentualne notyfikacje w przypadku niepowodzenia któregokolwiek z kroków. Ja jeszcze dodatkowo rozbije DEPLOY na osobny Jenkinspepline. I powstaną mi dwa joby Jenkins pepline które, nazwe plan i apply. Skąd ten jenkins pipeline Można zadać pytanie skąd zatem brać tą konfigurację - nauka składni może być barierą wejścia która, bardziej przekonuje nas do freestyle projekt niż minusy stosowania właśnie powtórzeń i powieleń. Możemy skorzystać z generatora który, jest dostępny i wbudowany w Jenkins. Pomoże on nam skonfigurować nasz kod który, jest potrzebny do działania z Jenkins pepline. Aby wejsść w generator do nazwy naszego projektu należy dopisać po "/" fraze "pipeline-syntax/" - dla przykładu https://jenkins.koska.in/job/HomeEnv/job/Terraform/job/testo/pipeline-syntax/ Albo w konfiguracji naszego Jenkins pipline job przejść do sekcji Configuration i kikamy Pipeline Syntax I z pomocą składni Jenkins pipeline uda nam się złożyć naszą konfigurację. Oczywiście musimy pamiętać o dodaniu naszych sekretów itp tak by nasza konfiguracja kodu była bezpieczna i nie powodowała wycieku danych: Oto szczegółowa analiza dostarczonego kodu Jenkins pipeline: Agent: Pipeline jest wykonywany na agencie z etykietą `terraform`. W przypadku braku dostępności agenta, Jenkins będzie próbować ponownie do 5 razy. Etap 'Clean workspace': Wysyła powiadomienie do Slacka o rozpoczęciu tego etapu. Czyszczenie przestrzeni roboczej za pomocą komendy `cleanWs()`. Etap 'Repo Clone': Wysyła powiadomienie do Slacka o rozpoczęciu tego etapu. Klonuje repozytorium git z określonej konfiguracji (z gałęzi 'main'). Etap 'terraform init': Wysyła powiadomienie do Slacka o rozpoczęciu tego etapu. Inicjalizuje Terraform z konfiguracją backendu. Etap 'terraform validate': Wysyła powiadomienie do Slacka o rozpoczęciu tego etapu. Sprawdza poprawność składni konfiguracji Terraform za pomocą `terraform validate`. Etap 'terraform plan': Wysyła powiadomienie do Slacka o rozpoczęciu tego etapu. Uruchamia `terraform plan` z uwzględnieniem różnych zmiennych. Sprawdza wynik w poszukiwaniu określonych błędów i wysyła powiadomienia na Discord w przypadku wykrycia. Sekcja 'post': W zależności od wyniku wykonania pipeline, wykonuje różne kroki, takie jak archiwizacja artefaktów i wysyłanie powiadomień do Slacka o statusie. Powiadomienia są dostosowane do różnych stanów wyników, takich jak `success`, `regression`, `fixed`, `aborted`, `unstable` i `unsuccessful`. Pipeline ten skupia się na operacjach związanych z Terraform, takich jak inicjalizacja, walidacja i planowanie. Ważnym aspektem jest również komunikacja z zespołem poprzez powiadomienia na Slacka oraz w przypadku błędów na Discord. Teraz z apply pójdzie nam jeszcze łatwiej: Analizując dostarczony kod, możemy zidentyfikować kilka różnic i nowych funkcjonalności w porównaniu do poprzedniej wersji: Options: - W kodzie dodano sekcję `options`, która umożliwia stosowanie globalnych opcji dla całego pipeline. Tutaj wykorzystano `timestamps()`, co sprawia, że każdy log z tego pipeline będzie zawierał znacznik czasu, ułatwiając analizę logów. Etap "copy plan.file": - Ten etap służy do kopiowania artefaktów z innego projektu/buildu w Jenkinsie. Specjalnie kopiuje plik `plan.file` z projektu o nazwie `WorkEnv/TerraformWorkEnv/work-familmed-terraform-prod/terraform-plan`. Opcja `fingerprintArtifacts: true` oznacza, że Jenkins będzie śledzić i zapisywać metadane dla skopiowanych artefaktów, co może być przydatne w celach audytu. Etap "terraform apply": - W tym etapie następuje faktyczne zastosowanie planu infrastruktury terraform. Najpierw jest inicjalizacja terraform z odpowiednią konfiguracją backendu (poprzednio omówione). Następnie, używając flagi `-auto-approve`, automatycznie zatwierdza się zmiany zaproponowane przez terraform bez potrzeby ręcznej interwencji. Wykorzystuje to wcześniej skopiowany plik `plan.file`. Post: - Sekcja `post` i jej działanie pozostały takie same, jak w poprzedniej wersji kodu, i zostały już omówione w poprzedniej analizie. Obejmuje ona różne akcje, które mają zostać wykonane po zakończeniu wszystkich etapów, w zależności od wyniku pipeline (np. zawsze wysyłać wiadomość na Slack, archiwizować artefakty po udanej kompilacji itp.). Podsumowując, ten kod Jenkins pipeline koncentruje się na pobieraniu i aplikowaniu planu terraform, zapewniając odpowiednie powiadomienia na Slack oraz archiwizację niezbędnych artefaktów. Obejmuje także znaczniki czasu dla wszystkich logów dzięki globalnej opcji `timestamps()`. Względem poprzedniej wersji kodu brakuje etapów związanych z walidacją i planowaniem terraform, co sugeruje, że ten pipeline jest prawdopodobnie kontynuacją lub dopełnieniem procesu rozpoczętego w poprzednim kodzie. Spójrzmy teraz na nasz stage view. Jak poprzednio (mój podział w freestyle) tu też widzimy podział na etapy. A sama konfiguracja naszego projektu polega jedynie na wskazaniu gdzie szukać naszego kodu w jakim repozytorium + plus konfiguracja credential Oczywiście konfiguracji w naszym jenkins pepline jest więcej i możemy bardziej wymyślne konfiguracje tu układać. Jednak w tym wpisie to wszystko. Pozdrawiam i do usłyszenie.