Search Results

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.

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 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

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.

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.

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.

Taki obrazek przywita Cię na stronę związaną z certyfikacją odnośnie HashiCorp Certified: Terraform Associate (003). Jak możemy wyczytać: Ten certyfikat jest przeznaczony dla inżynierów chmury specjalizujących się w operacjach, IT lub programowaniu, którzy znają podstawowe pojęcia i umiejętności związane z HashiCorp Terraform. Ta osoba rozumie różnicę w funkcjonalności między Terraform Cloud, Terraform Enterprise i Open Source Terraform. A zatem ten certyfikat jest potwierdzeniem umiejętności oraz tego że rozumiesz i umiesz posługiwać się terraform. Narzędziem do zarządzania infrastrukturą w kodzie... czy za pomocą kodu. Ale czy warto, czy daje to coś nam (oczywiście posiadanie certyfikatu - bo trzymanie konfiguracji w kodzie to jak najbardziej :)) - postaram się odpowiedzieć na te i inne pytania w tym artykule. Do mniejszego artykułu powstał też Vlog, jak ktoś lubi bardziej słuchać to znajdziesz go na moim kanale na YouTube. Ważność certyfikatu Warto zaznaczyć na wstępie że certyfikat jest ważny tylko przez dwa lata (24 miesiące) - tego dnia którego zdałeś egzamin pozytywnie za dwa lata dokładnie straci ważność i będziesz mógł (musiał - by posługiwać się dalej poświadczeniami w postaci certyfikatu) przystąpić do niego ponownie (Tej samej wersji egzaminu lub innej). Terraform Associate 003 zastępuję Terraform Associate 002 - oczywiście jeżeli jesteś posiadaczem jeszcze ważnego certyfikatu w wersji 002 nie musisz odnawiać go do wersji 003. Możesz zrobić to wtedy gdy 002 straci ważność. Wymagania wstępne Terraform na swojej stronie pisze o dwóch punktach jeśli chodzi o wymagania wstępne, a są nimi: Podstawowe umiejętności posługiwania się terminalem Podstawowe zrozumienie architektury on-premise i chmury Co do pierwszego punktu - jak już zainstalowałeś terraforma w celu poznania tego narzędzia i jeszcze nie myślałeś o egzaminie to ten punk masz już zaliczony. Sama instalacja nie jest jakimś mega trudnym krokiem i jest bardzo dobrze opisana w dokumentacji terraforma. Możemy jednak założyć, że jeżeli poradziłeś sobie z tym krokiem nawet z dokumentacją to podstawy terminala masz opanowane. Chyba, że polecenia które , wydawałaś w terminalu są dla Ciebie czarną magią to zapraszam do moich materiałów na kanale YouTube gdzie poruszam zagadnienia związane z terminalem. Drugi punkt jest bardziej złożony. Jak dokładnie rozumieć "Podstawowe zrozumienie architektury on-premise i chmury" - postaram się wyjaśnić w kilku punktach. Po pierwsze warto zapoznać się za jakąś chmurą dostępna publicznie (AWS, Azure, DigitalOcean, GCP - czy każdą inną). Jeżeli chodzi o rozwiązani on premise w zupełności wystarczy rozwiązanie w postaci HomeLab. Znajomość infrastruktury chmurowej też na podstawowym poziomie wystarczy. Należy zrozumieć podstawowe pojęcia związane z chmurą. Czym tak naprawdę jest chmura. Proste wyjaśnienie chmury i koncepcji za nich się kryjących jest porównanie tego do własnej wirtualizacji na swoim komputerze. Czyli współdzielenie zasobów w ramach jednego fizycznego serwera. Oczywiście w większej skali plus dodatkowe warstwy bezpieczeństwa w postaci separacji środowiska czy zasobów. Tak by Klient X nie odczytał danych Klienta Y. A i ty chmurą nie zarządzasz. Tzn zarządzasz ale nie od środka... no dobra inaczej ... Oczywiście! Chmura publiczna i on-premise to dwa różne podejścia do przechowywania danych i uruchamiania aplikacji. On-premise (lokalne): Architektura on-premise odnosi się do infrastruktury, która jest utrzymywana i zarządzana wewnątrz firmy lub organizacji. Oznacza to, że wszelkie serwery, urządzenia sieciowe, centra danych i inne zasoby są fizycznie obecne w miejscu pracy. Organizacja jest odpowiedzialna za zakup, konserwację, aktualizację i bezpieczeństwo wszystkich tych zasobów. W przypadku architektury on-premise dane są przechowywane w wewnętrznych serwerach firmy, a aplikacje są uruchamiane na lokalnych maszynach. Ten model daje pełną kontrolę nad infrastrukturą, ale wymaga dużych nakładów finansowych na zakup i utrzymanie sprzętu oraz zasobów ludzkich do zarządzania tymi zasobami. Chmura publiczna: Chmura publiczna odnosi się do modelu, w którym organizacja korzysta z usług dostarczanych przez zewnętrznego dostawcę, tzw. dostawcę chmury publicznej. Dostawca chmury publicznej utrzymuje infrastrukturę (serwery, sieci, centra danych itp.) i udostępnia ją klientom jako usługę. Klienci mogą przechowywać swoje dane i uruchamiać aplikacje w chmurze publicznej. W przypadku chmury publicznej dane są przechowywane na serwerach dostawcy chmury i są dostępne za pośrednictwem internetu. Klienci korzystają z elastyczności i skalowalności oferowanej przez dostawcę chmury publicznej, a ponoszone koszty zależą od faktycznego korzystania z zasobów. W skrócie, on-premise oznacza lokalne utrzymanie infrastruktury i przechowywanie danych na lokalnych serwerach, podczas gdy chmura publiczna oznacza korzystanie z usług dostarczanych przez zewnętrznego dostawcę chmury, gdzie dane są przechowywane na serwerach dostawcy. Po drugie - egzamin terraform nie wymaga od Ciebie bycia specjalista w danej chmurze. Jeżeli umiesz postawić maszynę wirtualną za pomocą GUI dostępnego (AWS, GCP, Azure czy DigitalOcean) i wiesz jak to działa i od czego jest zależna w ramach zasobów którymi dysponujesz w chmurze. Czyli sieć, storage, firewall w postaci Security Group czy innego rozwiązania. To ten punkt i koncept też masz opanowany w stopniu podstawowym. Ok, czas zatem przejść do samego terraforma :D Szczegóły egzaminu Dobra mamy wstępniak - porozmawiajmy teraz o kosztach samym egzaminie oraz formie jego przeprowadzenia. Format pytń Egzamin może i składa się z pytań wielokrotnego wyboru. Mamy zawsze informacje ile oczekują od nas zaznaczenia poprawnych odpowiedzi. Gdy jest to jedna prawidłowa odpowiedź, pola do zaznaczania mają kształt koła a gdy jest wielokrotna mają kształt kwadratu. Na końcu pytania jest napisane ile odpowiedzi trzeba zaznaczyć (np.: zaznacz dwie). Pytań jest dokładnie 59 i można do nich wrócić jeżeli czas pozwoli. Pytania można też oznaczyć flagą jeżeli nie damy na nie odpowiedzi lub nie jesteśmy jej do końca pewni. Pytania są wyświetlane po kolei, jednak mamy możliwość przejścia do dowolnego. W dolnej części mamy pasek nawigacji w postaci numerów pytań. Po kliknięciu przenosi nas do wskazanego. U góry za to panele nawigacyjne z przyciskami następne, poprzednie pytanie. Czas trwania Na cały egzamin od jego rozpoczęcia czyli wyświetlenia pierwszego pytania mamy dokładnie 60 minut. Co przy liczbie pytań 57 daje nam po jednej minucie na pytanie. Co w zupełności wystarcza. Oczywiście dobr ą praktyką jest że jeśli od razu nie znasz odpowiedzi na jakieś pytanie to oznacz je flaga i przejdź do następnego. Zdążysz do niego wrócić - a szkoda marnować czasu na zastanawianie się nad odpowiedzią. Aktualny czas jest cały czas widoczny w górnej części okna - wiec na bierząco jestesmy z aktualnym postępem w naszym kursie. Cena i język Koszt egzaminu to 70,50 USD - co przy obecnym kursie dolara (4,07) daje 287 zł - oczywiście ta kwota może się różnić w zależności od przeliczeń danego banku w którym posiadamy kartę oraz od samego kursu dolara. Egzamin jest prowadzony w języku angielskim, jego interfejs pytania egzaminacyjne jak i pytania od egzaminatora pilnującego przebiegu egzaminu. Format Egzamin jest realizowany przez platformę PSI na której trzeba założyć konto (można się zalogować tam za pomocą konta github jeżeli takie posiadamy). Po zalogowaniu możemy umówić, wybrać dogodny termina na zdanie egzaminu. Egzamin jest prowadzony online. I do egzaminu można przystąpić na 30 minut przed planowanym terminem, a przełożyć go możemy na dwa dni przed planowanym terminem. Egzamin odbywa się w pełni online. Weryfikacja podczas egzaminu, przebiegła sprawnie i szybko - zajęło to 10 minut. Osobiście robiłem egzamin na komputerze z rodziny Apple. I tu zalecam korzystać z laptopa. Ja sam realizowałem egzamin przy stole, ponieważ przy biurku mam dwa dodatkowe monitory które podczas egzaminu są niedozwolone oraz dużo innych rzeczy (podkładka klawiatura słuchawki i inne takie rzeczy). I tu weryfikacja przez egzaminatora była szczegółowa. Musiałem pokazać wszystkie ściany łącznie z sufitem i podłogą czy nic tam nie jest naklejone. A z racji tego że egzamin miałem przy stole (jak pokazywałem pokój - egzaminator pewnie to dostrzegł) musiałem też pokazać czy nic nie ma pod stołem na jego rogach/bokach itp. Pokazuje się też nadgarstki oraz uszy czy nie ma się tam dodatkowych urządzeń. Zegarek oczywiście musiałem zdjąć. Nie wiem jak w przypadku osób z aparatami słuchowymi czy też musiałby taki aparat wyciągnąć / zdjąć podczas egzaminu. Nie doczytałem i nie odnalazła nigdzie takiej informacji. Jednak egzamin i komunikaty z egzaminatorem są prowadzone po przez czat zatem wydaje mi się że tez taki aparat trzeba było by wyciągnąć / odłączyć. Swoja tożsamość potwierdzamy dowodem osobistym lub prawojazdami. To jest jedyny przedmiot oprócz okularów i wody który może znajdować się dodatkowo n a naszym biurku podczas trwania egzaminu. Oczywiście podczas egzaminu nikt inny nie może przebywać w pomieszczeniu w którym zdajecie egzamin oprócz was. A zatem należy znaleźć wolny pokój - lub pomieszczenie w którym na 60 minut możecie się zamknąc sami. Podczas trwania egzaminu monitoruje nas bez przerwy egzaminator. Zatem jak macie tendencje do czytania pytań na głos - lub czytania bez głosu ale poruszania ustami to zalecam tego nie robić ponieważ może to spowodować zakończenie egzaminu z wynikiem negatywnym. Możemy o tym przeczytać w zasadach przeprowadzenia egzaminu które akceptujemy. Wygląd samej aplikacji z egzaminem jest surowy - tzn bez zbędnych wodotrysków i jakiejś przyciągającej kolorystyki. Za to jest spójnie i przejrzyście. Sama aplikacja wykrywa inne aplikacje które nie powinny być uruchomione i wyłącza. Tematyka obowiązująca na egzaminie Poniżej wkleję dokładny opis ze strony terraform tak by przy tłumaczeniu nie wkradł się jakiś błąd. Oczywiście zalecam co jakiś czas sprawdzić czy wymagania na stronie terraform nie zostały zaktualizowane. Nie będę też omawiał różnic względem egzaminu 002. Na tym etapie mogę też powiedzieć że zaliczenie zaczyna się od 70% w górę zatem wynik od 70 do 100% daję Ci wynik pozytywny. https://developer.hashicorp.com/terraform/tutorials/certification-003/associate-review-003 Exam objectives Understand infrastructure as code (IaC) concepts Explain what IaC is Describe advantages of IaC patterns Understand the purpose of Terraform (vs other IaC) Explain multi-cloud and provider-agnostic benefits Explain the benefits of state Understand Terraform basics Install and version Terraform providers Describe plugin-based architecture Write Terraform configuration using multiple providers Describe how Terraform finds and fetches providers Use Terraform outside of core workflow Describe when to use terraform import to import existing infrastructure into your Terraform state Use terraform state to view Terraform state Describe when to enable verbose logging and what the outcome/value is Interact with Terraform modules Contrast and use different module source options including the public Terraform Module Registry Interact with module inputs and outputs Describe variable scope within modules/child modules Set module version Use the core Terraform workflow Describe Terraform workflow ( Write -> Plan -> Create ) Initialize a Terraform working directory (terraform init) Validate a Terraform configuration (terraform validate) Generate and review an execution plan for Terraform (terraform plan) Execute changes to infrastructure with Terraform (terraform apply) Destroy Terraform managed infrastructure (terraform destroy) Apply formatting and style adjustments to a configuration (terraform fmt) Implement and maintain state Describe default local backend Describe state locking Handle backend and cloud integration authentication methods Differentiate remote state back end options Manage resource drift and Terraform state Describe backend block and cloud integration in configuration Understand secret management in state files Read, generate, and modify configuration Demonstrate use of variables and outputs Describe secure secret injection best practice Understand the use of collection and structural types Create and differentiate resource and data configuration Use resource addressing and resource parameters to connect resources together Use HCL and Terraform functions to write configuration Describe built-in dependency management (order of execution based) Understand Terraform Cloud capabilities Explain how Terraform Cloud helps to manage infrastructure Describe how Terraform Cloud enables collaboration and governance Zacznijmy od końca - Understand Terraform Cloud capabilities. Nie opuszczał bym tego podpunktu ponieważ na moim egzaminie dostałem kilka pytań z tematyki terraform cloud. Oczywiście nie mówię, że ty dostaniesz mniej czy więcej pytań ale uważam że warto poznać to narzędzie. Terraform Cloud pozwala założyć darmowe konto na zawsze. Zatem warto spróbować skonfigurowac choć jedną swoja konfigurację i używać terraform cloud jako backendu czy też środowiska uruchomieniowego dla terraform plan, apply i destroy. Understand infrastructure as code (IaC) concepts Tu musisz sobie postawić pytanie czy umiesz wyjaśnić co to jest IaC oraz jakie są zalety infrastruktury w kodzie. Na co pozwala IaC i jakie korzyści niesie: Zarządzaj dowolną infrastrukturą - przez wielu providerów, oraz to że możemy ich ze sobą łączyć. Śledź swoją infrastrukturę - po przez VSC (git) na przykład github, gitlab czy inne tego typu narzędzia Zautomatyzuj zmiany - integracja z CI/CD Standaryzuj konfiguracje - pisanie własnych modułów Współpracować - praca poprzez git. To najważniejsze punkty - oczywiście warto zapoznać się z dokumentacją i przewodnikiem powtórkowym od Terraform Understand the purpose of Terraform (vs other IaC) HashiCorp Terraform to narzędzie infrastruktury jako kodu, które umożliwia definiowanie zasobów infrastruktury w plikach konfiguracyjnych czytelnych dla człowieka, które można wersjonować, ponownie wykorzystywać i udostępniać. Następnie możesz użyć spójnego przepływu pracy, aby bezpiecznie i wydajnie udostępniać infrastrukturę i zarządzać nią przez cały cykl jej życia. Stan jest kluczowym elementem działania narzędzia do zarządzania infrastrukturą w chmurze, Terraform. Jest niezbędny z kilku powodów: 1. Mapowanie do świata rzeczywistego: Stan umożliwia Terraformowi odwzorowanie konfiguracji na rzeczywiste zasoby w systemie zdalnym. Terraform korzysta z plików stanu, aby wiedzieć, które zasoby reprezentują konkretne obiekty w systemie zdalnym. Te mapowania są jednoznaczne - każdy obiekt zdalny jest powiązany tylko z jednym zasobem w konfiguracji. 2. Przechowywanie metadanych: Stan przechowuje metadane, takie jak zależności między zasobami. Terraform wykorzystuje te informacje do określenia kolejności działań, takich jak niszczenie zasobów. Metadane pomagają też Terraformowi określić, jakie zmiany są potrzebne do osiągnięcia pożądanej konfiguracji. 3. Poprawa wydajności: Terraform wykorzystuje stan do przechowywania wartości atrybutów zasobów, co poprawia wydajność. Dzięki temu, Terraform nie musi wysyłać zapytań do dostawcy o każdy zasób indywidualnie, co jest czasochłonne i może prowadzić do ograniczeń szybkości API. 4. Synchronizacja: W kontekście pracy zespołowej, stan umożliwia wszystkim członkom zespołu pracę na tych samych obiektach zdalnych. Za pomocą zdalnego stanu, Terraform może blokować przypadkowe jednoczesne działania różnych użytkowników, zapewniając jednolity i aktualny stan. Podsumowując, stan Terraform jest integralnym elementem zarządzania infrastrukturą, umożliwiając efektywne mapowanie, przechowywanie metadanych, poprawę wydajności i synchronizację. Bez stanu, Terraform napotkałby na złożoność i nieskuteczność w realizacji swoich funkcji. https://developer.hashicorp.com/terraform/tutorials/state/state-cli Understand Terraform basics Instalowanie i wersjonowanie dostawców Terraform Opisz architekturę opartą na wtyczkach Napisz konfigurację Terraform przy użyciu wielu dostawców Opisz, w jaki sposób Terraform wyszukuje i pobiera dostawców Use Terraform outside of core workflow Opisz, kiedy użyć terraform importdo zaimportowania istniejącej infrastruktury do stanu Terraform Służy terraform statedo przeglądania stanu Terraform Opisz, kiedy włączyć szczegółowe rejestrowanie i jaki jest wynik/wartość Interact with Terraform modules Porównaj i wykorzystuj różne opcje źródeł modułów, w tym publiczny rejestr Terraform Interakcja z wejściami i wyjściami modułu Opisz zakres zmiennych w modułach/modułach podrzędnych Ustaw wersję modułu Use the core Terraform workflow Opisz przepływ pracy Terraform ( Napisz -> Planuj -> Utwórz ) Inicjowanie katalogu roboczego Terraform ( terraform init) Sprawdź poprawność konfiguracji Terraform ( terraform validate) Wygeneruj i przejrzyj plan wykonania dla Terraform ( terraform plan) Wprowadzaj zmiany w infrastrukturze za pomocą Terraform ( terraform apply) Zniszcz zarządzaną infrastrukturę Terraform ( terraform destroy) Stosowanie korekt formatowania i stylu do konfiguracji ( terraform fmt) Implement and maintain state Opisz domyślny localbackend Opisz blokowanie stanu Obsługuj metody uwierzytelniania integracji backendu i chmury Rozróżnij opcje zaplecza stanu zdalnego Zarządzaj dryfem zasobów i stanem Terraform Opisz backendintegrację blokową i chmurową w konfiguracji Zrozumienie tajnego zarządzania plikami stanu Read, generate, and modify configuration Zademonstruj użycie zmiennych i danych wyjściowych Opisz najlepszą praktykę bezpiecznego tajnego wstrzykiwania Zrozumienie zastosowania kolekcji i typów strukturalnych Twórz i różnicuj resource oraz data konfiguruj Użyj adresowania zasobów i parametrów zasobów, aby połączyć zasoby razem Użyj funkcji HCL i Terraform do pisania konfiguracji Opisz wbudowane zarządzanie zależnościami (w oparciu o kolejność wykonywania) Jakie mogą pojawić się pytania Pytania jakie mogą się pojawią będą z zakresu powyższej listy - a oto kilka przykładowych pytań które znajdziemy na stronie terraform https://developer.hashicorp.com/terraform/tutorials/certification-003/associate-questions oczywiście znacznie więcej znajdziesz w moim kursie dostępnym na stronie https://szkolenia.cloud Jak zacząć się uczyć i skąd brać materiały do nauki. Zawsze przy nauce jakiegoś narzędzia polecam dokumentację techniczną i tak samo jest w tym przypadku: Na początek możemy zacząć tutaj: https://developer.hashicorp.com/terraform Zalecam też powtórkę które idealnie opisuje zagadnienia i odsyła do właściwych elementów w dokumentacji: https://developer.hashicorp.com/terraform/tutorials/certification-003/associate-review-003 Oraz: https://developer.hashicorp.com/terraform/tutorials/certification-003/associate-study-003 i także: https://developer.hashicorp.com/terraform/cli Oczywiście praktyczne przykłady znajdziesz na stronie terraform i w moim kursie - w jednym i drugim po zalogowaniu możesz śledzić swój progress. Następne kroki Zapoznaj się z podręcznikiem egzaminacyjnym , aby przećwiczyć wszystkie cele egzaminu. Sprawdź przykładowe pytania , aby przejrzeć format pytań egzaminacyjnych. Jeśli jesteś gotowy, aby zarejestrować się na egzamin, życzę powodzenia! Utwórz konto Kup termin egzaminu Zarejestruj się na wizytę Podejść do egzaminu Zapisz się na egzamin tutaj! Podsumowanie Czy warto podejść do egzaminu - stwierdzam że tak, jeżeli rzeczywiście chcesz ułatwić sobie pracę i ją przyśpieszyć. To poznanie terraforma pozwoli Ci na to. A zdanie egzaminu będzie swoistym uwieńczeniem i potwierdzeniem zdobytej wiedzy. Oczywiście dalsza praca i praktyka pozwoli Ci w pełni wykorzystać wiedzę. Pozdrawiam Piotr Kośka

HashiCorp Terraform 1.5 jest teraz ogólnie dostępny i zawiera nowe funkcje, takie jak konfigurowane zaimportowanie i bloki sprawdzające. Mechanizm konfigurowanego zaimportowania pozwala na dodawanie istniejących zasobów do stanu Terraforma za pomocą deklaratywnego procesu. Eliminuje to ograniczenia dotychczasowej komendy importu, umożliwia importowanie wielu zasobów naraz i eliminuje ryzyko nieoczekiwanego modyfikowania stanu. Terraform 1.5 automatycznie generuje kod dla zaimportowanych zasobów, co znacznie skraca czas potrzebny na pisaniu kodu odpowiadającego zaimportowanym zasobom. Wprowadzono nowy blok sprawdzający (check block), który umożliwia funkcjonalne sprawdzanie infrastruktury po jej wdrożeniu. Blok sprawdzający daje większą elastyczność w definiowaniu asercji w kodzie Terraformu, a także umożliwia bardziej złożone warunkowe oceny stanu infrastruktury. Blok sprawdzający działa na ostatnim etapie planu lub wdrożenia i nie zatrzymuje wykonywania. Nieudane sprawdzenia wygenerują ostrzeżenie, a nie błąd. Blok sprawdzający może zawierać jedno osadzone źródło danych ("scoped" data source). Jeśli źródło danych nie powiedzie się, błąd jest ograniczony do bloku sprawdzającego i nie zatrzymuje ogólnego wykonania Terraforma. Wraz z wersją 1.5 udostępniono również pełną dokumentację, samouczki i inne materiały, które pozwalają użytkownikom zapoznać się z nowymi funkcjami. Najważniejsze zmiany: Konfigurowane zaimportowanie umożliwia dodawanie istniejących zasobów do stanu Terraforma w sposób deklaratywny. Automatyczna generacja kodu dla zaimportowanych zasobów przyspiesza proces pisania kodu. Bloki sprawdzające umożliwiają funkcjonalne sprawdzanie stanu infrastruktury po wdrożeniu. Bloki sprawdzające mogą zawierać więcej niż jedną asercję i mogą odwoływać się do wszystkich zasobów, źródeł danych i wyników modułów w konfiguracji. Bloki sprawdzające generują ostrzeżenia, a nie błędy, w przypadku nieudanych sprawdzeń. Bloki sprawdzające mogą zawierać osadzone źródło danych, które nie powoduje zatrzymania ogólnego wykonania Terraforma w przypadku niepowodzenia. Źródło: Artykuł "Terraform 1.5 brings config-driven import and checks" autorstwa Dana Barra, opublikowany 12 czerwca https://www.hashicorp.com/blog/terraform-1-5-brings-config-driven-import-and-checks

W tym materiale pokazuję jak za pomocą Jenkins wpleść terraform i tfsec w proces CI/CD. Zapraszam do oglądania.

Zinc to stosunkowo nowa dystrybucja oparta na Ubuntu, która ma na celu zapewnienie bardziej funkcjonalnego pulpitu z lepszym wrażeniem "prosto z pudełka", bez konieczności długiego dostosowywania. Chociaż na rynku dostępnych jest wiele dystrybucji opartych na Ubuntu, każdy użytkownik ma swoje własne preferencje. Może okaże się, że polubisz Zinc bardziej niż standardowe Ubuntu? Kto wie? W każdym razie przyjrzyjmy się, co oferuje Zinc. Twórca Zinc zaznacza, że jest to projekt realizowany z pasją, więc nie należy oczekiwać, że w najbliższym czasie zastąpi on Twój obecny system produkcyjny. Zinc to remiks Ubuntu LTS, który jako domyślne środowisko graficzne wykorzystuje XFCE. Jest przeznaczony dla osób, które preferują bardziej tradycyjne doświadczenia użytkownika na pulpicie. Dlatego domyślnie nie są dołączone pakiety Snap i Flatpak, choć można je zainstalować w razie potrzeby, a w zestawie znajduje się tylko wersja .deb przeglądarki Firefox. Możesz zastanawiać się, dlaczego wybrać Zinc, skoro istnieje już oficjalny remiks Xubuntu z XFCE? Oto powód: Zinc ma kilka cech wyróżniających. Niektóre z nich to: Możliwość wyboru układów pulpitu. Domyślny ciemny motyw, zmniejszający zmęczenie wzroku. Najnowsze jądro HWE-edge od Ubuntu. Instalator Calamares zamiast Ubiquity. Wbudowany terminal "spadający" z mapowaniem na klawisz "F1". Kompresja BTRFS jako domyślna. Menedżer plików Nemo. Pierwsze wrażenia z używania Zinc są dość pozytywne, dzięki minimalistycznemu i schludnemu interfejsowi użytkownika. Przetestowana na maszynie wirtualnej dystrybucja bez problemu wykryła kartę NVIDIA, co jest miłym dodatkiem. Zamiast instalatora Ubiquity dostępnego w Ubuntu, Zinc korzysta z instalatora CALAMARES 3.2.61, który zapewnia przyjemne doświadczenie podczas instalacji. Przebieg instalacji był bezproblemowy, a pasek postępu dostarczał wystarczających informacji na temat instalacji. Chociaż opcje instalacji są takie same jak w przypadku innych smaków Ubuntu. Po pierwszym uruchomieniu Zinc, witają Cię opcje wyboru układu pulpitu, które pozwalają wybrać pomiędzy tradycyjnym stylem Ubuntu, a układem przypominającym Windows. Niewątpliwie dawanie użytkownikom takiej możliwości wyboru na starcie to świetna opcja! Poza tym, doświadczenie użytkownika na pulpicie było płynne, a monitor systemu ładnie zintegrowany z górnym panelem, pokazując ważne informacje o systemie. Co więcej, Zinc korzysta z niezawodnego jądra Linux 5.19, które zapewnia doskonałe wsparcie sprzętowe i programowe. Warto również zauważyć, że menedżerem plików nie jest tutaj Thunar, ale Nemo, popularny w systemie Linux Mint. Jeśli lubisz menedżer plików Nemo, warto wypróbować Zinc. Podsumowując, Zinc oferuje atrakcyjny pakiet z wszystkimi odpowiednimi elementami, które powinny przypaść do gustu wielu użytkownikom. Jednak z tak dużą liczbą dystrybucji opartych na Ubuntu, dla nowych użytkowników może być trudno wybrać właściwą. Najnowsza wersja, "Zinc 22.04.3", została wprowadzona w zeszłym miesiącu i wprowadza domyślną kompresję BTRFS, aplikację do wyboru układów pulpitu, szybsze zamykanie systemu i więcej. Możesz zapoznać się z informacjami o wydaniu najnowszej wersji, aby dowiedzieć się więcej na ten temat. Źródło: https://calamares.io/calamares-3.2.61-is-out/?ref=news.itsfoss.com https://teejeetech.com/2023/04/22/zinc-22-04-3/ https://teejeetech.com/tag/zinc/

Odkryto poważne zagrożenie bezpieczeństwa w jądrze systemu Linux, które może być wykorzystane przez nieuprzywilejowanych użytkowników lokalnych do zdobycia wyższych uprawnień. Problem dotyczy Netfilter nf_tables, składnika odpowiedzialnego za filtrowanie pakietów sieciowych, który akceptuje nieprawidłowe aktualizacje swojej konfiguracji. W rezultacie, nieprawidłowe zapytania przesyłane do Netfilter nf_tables mogą prowadzić do uszkodzenia jego wewnętrznego stanu, stwarzając możliwość eskalacji uprawnień. Eksperci potwierdzili obecność problemu na różnych wersjach jądra Linux, w tym na 6.3.1, które jest aktualnie uważane za stabilne. Ujawnienie luki stanowi poważne zagrożenie dla setek milionów urządzeń na całym świecie, od serwerów po inteligentne telewizory, które korzystają z systemu Linux. Badacze bezpieczeństwa opracowali exploit, który pozwala na uruchomienie powłoki systemowej z uprawnieniami administratora, co daje pełen dostęp do systemu. Kod źródłowy tego exploitu zostanie opublikowany 15 maja na liście mailingowej oss-security@...ts.openwall.com. Eksperci podkreślają, że przed opublikowaniem kodu źródłowego, należy wprowadzić stosowne łatki, aby zabezpieczyć systemy przed ewentualnymi atakami. Naprawa luki jest już dostępna w głównym repozytorium jądra Linux na stronie git.kernel.org: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=c1592a89942e9678f7d9c8030efa777c0d57edab Zalecamy wszystkim administratorom systemów opartych na jądrze Linux jak najszybsze zaktualizowanie swoich systemów do najnowszej wersji lub zastosowanie odpowiednich łatek. Warto również śledzić komunikaty od dystrybutorów i dostawców oprogramowania, aby dowiedzieć się o dostępnych rozwiązaniach dla swojego środowiska. Odkrycie tej luki bezpieczeństwa przypomina o konieczności ciągłego monitorowania i aktualizacji systemów informatycznych oraz zabezpieczania ich przed potencjalnymi atakami. W dzisiejszym dynamicznym świecie cyberbezpieczeństwa, regularne przeglądy i aktualizacje oprogramowania są kluczowe dla utrzymania bezpiecznego środowiska IT. Zródło: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-32233 https://www.openwall.com/lists/oss-security/2023/05/08/4 https://news.ycombinator.com/item?id=35879660 https://github.com/torvalds/linux/commit/c1592a89942e9678f7d9c8030efa777c0d57edab https://bugzilla.redhat.com/show_bug.cgi?id=2196105

Wstęp: W dzisiejszym dynamicznym świecie technologii, zarządzanie infrastrukturą w chmurze stało się kluczowym elementem sukcesu dla przedsiębiorstw. W miarę jak firmy coraz częściej korzystają z usług chmurowych, takich jak Amazon Web Services (AWS), istnieje potrzeba uproszczenia i automatyzacji procesów zarządzania zasobami. W tym artykule przyjrzymy się AWS Control Tower Account Factory for Terraform - potężnemu narzędziu, które pozwala na łatwe zarządzanie infrastrukturą AWS, pozwalając jednocześnie na utrzymanie standardów bezpieczeństwa i zgodności. AWS Control Tower: AWS Control Tower to usługa, która pomaga w zarządzaniu wielo knotowymi środowiskami AWS, zapewniając centralizację kontroli i zgodności. Umożliwia automatyczne wdrażanie struktur organizacyjnych oraz nadzór nad politykami, które umożliwiają zarządzanie, audytowanie i monitorowanie infrastruktury w chmurze. Account Factory: Jednym z kluczowych elementów AWS Control Tower jest Account Factory, który automatyzuje proces tworzenia i konfiguracji nowych kont AWS. Pozwala to na szybkie wdrożenie zasobów zgodnie z określonymi standardami i przyspiesza proces uruchamiania nowych projektów w organizacji. Account Factory zapewnia również integrację z innymi usługami AWS, takimi jak AWS Organizations, AWS Single Sign-On (SSO) i AWS Service Catalog, co pozwala na utrzymanie spójności i jednolitych praktyk w całej organizacji. Terraform: Terraform to popularne narzędzie do zarządzania infrastrukturą jako kodem (IaC), które pozwala na opisanie, wersjonowanie i automatyzację wdrażania zasobów chmurowych. Dzięki językowi konfiguracyjnymu HCL (HashiCorp Configuration Language), Terraform jest prosty w użyciu i utrzymaniu, a jednocześnie potężny, pozwalając na zarządzanie zarówno lokalnymi, jak i chmurowymi zasobami. O samym terraform więcej pisałem w poprzednich artykułach: https://www.technicznie-nietechniczne.pl/post/najlepsze-praktyki-w-zakresie-bezpiecze%C5%84stwa-terraform https://www.technicznie-nietechniczne.pl/post/narz%C4%99dzie-do-analizy-statycznej-infrastruktury-jako-kodu-w-terraform https://www.technicznie-nietechniczne.pl/post/terreform-pocz%C4%85tki-czysto-teoretyczne https://www.technicznie-nietechniczne.pl/post/infrastruktura-jako-kod-iaac-vpc-domain-konfiguracja-w-terraformie-naszego-%C5%9Brodowiska https://www.technicznie-nietechniczne.pl/post/zmie%C5%84my-nasz%C4%85-konfiguracj%C4%99-na-modu%C5%82-infrastruktura-jako-kod-iaac-cze%C5%9B%C4%87-2 https://www.technicznie-nietechniczne.pl/post/infrastruktura-w-kodzie-iaac-droplet-firewall-i-nasza-aplikacja-cz%C4%99%C5%9B%C4%87-6 https://www.technicznie-nietechniczne.pl/post/podstawy-terrafrom-kurs-dla-pocz%C4%85tkuj%C4%85cych https://www.technicznie-nietechniczne.pl/post/infrastruktura-w-kodzie-iaac-troch%C4%99-o-zmiennych-i-elastyczno%C5%9B%C4%87-naszego-modu%C5%82u-cz%C4%99%C5%9B%C4%87-5 https://www.technicznie-nietechniczne.pl/post/infrastruktura-w-kodzie-iaac-digital-ocean-prosty-cloud-na-start-cz%C4%99%C5%9B%C4%87-trzecia https://www.technicznie-nietechniczne.pl/post/checkov-zastosowanie-narz%C4%99dzia-do-analizy-infrastruktury-jako-kodu https://www.technicznie-nietechniczne.pl/post/infrastruktura-jako-kod-iaac-cze%C5%9B%C4%87-1 https://www.technicznie-nietechniczne.pl/post/wykorzystuj%C4%85-luki-w-%C5%9Brodowiskach-kontenerowych AWS Control Tower Account Factory for Terraform: Integracja AWS Control Tower Account Factory z Terraform pozwala na jeszcze większą automatyzację i kontrolę nad infrastrukturą chmurową. AWS Control Tower Account Factory for Terraform umożliwia tworzenie, zarządzanie i konfigurację kont AWS za pomocą kodu Terraform, co przekłada się na lepsze praktyki i większą elastyczność. Wykorzystanie AWS Control Tower Account Factory for Terraform pozwala na: Szybkie tworzenie nowych kont AWS zgodnie z określonymi standardami. Centralizację zarządzania infrastrukturą i politykami zgodności. Integrację z istniejącymi narzędziami i usługami AWS, takimi jak AWS Organizations, AWS SSO i AWS Service Catalog. Wersjonowanie i audytowanie konfiguracji infrastruktury, co pozwala na łatwiejsze rozwiązywanie problemów i utrzymanie zgodności. Automatyzację procesów zarządzania, co przekłada się na mniejsze ryzyko błędów ludzkich i niższe koszty operacyjne. Jak zacząć z AWS Control Tower Account Factory for Terraform: Aby zacząć korzystać z AWS Control Tower Account Factory for Terraform, należy wykonać następujące kroki: Zainstaluj Terraform i skonfiguruj dostęp do AWS. Skonfiguruj AWS Control Tower oraz Account Factory. Utwórz plik konfiguracyjny Terraform (np. main.tf) z odpowiednimi modułami i zasobami, które będą używane przez Account Factory. Zastosuj konfigurację Terraform, aby utworzyć i skonfigurować nowe konto AWS. Monitoruj postęp i zarządzaj infrastrukturą za pomocą AWS Control Tower. Korzyści płynące z AWS Control Tower Account Factory for Terraform: Wdrożenie AWS Control Tower Account Factory for Terraform przynosi liczne korzyści dla organizacji, w tym: Zwiększenie wydajności: Używając Terraform do zarządzania kontami AWS, zespoły mogą osiągnąć większą wydajność poprzez redukcję czasu potrzebnego na ręczne tworzenie i konfigurację zasobów. Umożliwia to również szybsze wdrażanie zmian i aktualizacji infrastruktury. Ulepszona kontrola: Centralizacja zarządzania infrastrukturą za pomocą AWS Control Tower i Terraform daje organizacjom większą kontrolę nad swoimi zasobami chmurowymi. Pozwala na monitorowanie, audytowanie i egzekwowanie polityk zgodności na wszystkich kontach AWS w ramach struktury organizacyjnej. Lepsza zgodność: Integracja z AWS Control Tower pozwala na automatyczne wdrażanie polityk zgodności na nowo utworzone konta, co minimalizuje ryzyko niezgodności wynikające z ludzkich błędów. Dzięki temu organizacje mogą lepiej przestrzegać wymogów regulacyjnych i korporacyjnych. Skalowalność: Zarówno AWS Control Tower, jak i Terraform są projektowane z myślą o skalowalności, co pozwala na łatwe zarządzanie rosnącą ilością kont i zasobów w chmurze. W miarę rozwoju organizacji, infrastruktura może być łatwo dostosowywana do zmieniających się potrzeb, bez konieczności zmiany narzędzi czy podejścia. Zmniejszenie ryzyka: Automatyzacja procesów zarządzania za pomocą AWS Control Tower Account Factory for Terraform zmniejsza ryzyko błędów ludzkich, takich jak niepoprawne konfiguracje czy niewłaściwe ustawienia bezpieczeństwa. Dzięki temu organizacje mogą skupić się na swoich kluczowych działaniach biznesowych, mając pewność, że ich infrastruktura chmurowa jest zarządzana w sposób bezpieczny i zgodny. więcej: https://docs.aws.amazon.com/controltower/latest/userguide/aft-getting-started.html https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html https://controltower.aws-management.tools/automation/aft_setup/ https://developer.hashicorp.com/terraform/tutorials/aws/aws-control-tower-aft Zakończenie: AWS Control Tower Account Factory for Terraform to potężne narzędzie, które znacząco upraszcza i automatyzuje zarządzanie infrastrukturą w chmurze. Dzięki integracji z Terraform, organizacje mogą teraz w pełni wykorzystać zalety zarządzania infrastrukturą jako kodem, jednocześnie utrzymując wysokie standardy bezpieczeństwa i zgodności. W efekcie, AWS Control Tower Account Factory for Terraform przyczynia się do osiągnięcia większej efektywności operacyjnej, niższych kosztów oraz szybszego wdrażania nowych projektów.

Dzisiaj ukazało się wydanie OBS Studio 29.1 jako pierwsza duża aktualizacja od wersji OBS Studio 29.0, wprowadzając więcej nowych funkcji oraz udoskonalając istniejące możliwości tego popularnego, otwarto źródłowego, wieloplatformowego i darmowego programu do transmisji na żywo oraz nagrywania ekranu. Najważniejsze nowości w OBS Studio 29.1 obejmują wsparcie dla transmisji AV1/HEVC przez RTMP dla YouTube, wsparcie dźwięku przestrzennego dla kart AJA, nowe opcje nagrywania dźwięku bezstratnego w formatach FLAC, ALAC i PCM (w tym z 32-bitową precyzją), a także wsparcie dla wielu ścieżek dźwiękowych w trybie Simple output recording. Twórcy programu zwracają uwagę, że ulepszony RTMP V1 rozszerza protokół RTMP o wsparcie dla nowszych kodeków wideo i HDR, które jeszcze nie zostały wdrożone. Dodatkowo, wspomnieli że transmisja AV1/HEVC przez RTMP jest obecnie wspierana i włączona tylko dla YouTube jako funkcja beta. Dla użytkowników systemu Linux, OBS Studio 29.1 znacznie poprawia wydajność przechwytywania ekranu na maszynach z dedykowanymi GPU firmy Intel, aktualizuje wejścia JACK, aby wyświetlać nazwę „OBS Studio” w celu ułatwienia identyfikacji źródła, oraz udoskonala wsparcie dla wirtualnej kamery i źródła V4L2. Aktualizacja wprowadza także nowe ustawienia, umożliwiające nagrywanie w formatach wideo MP4 i MOV, nowe opcje wyboru kodeka dźwięku dla transmisji i nagrywania, oraz opcję wczytywania do pamięci źródeł mediów używanych w Stingers. Ponadto, OBS Studio 29.1 dodaje wskaźnik wyciszenia i braku przypisania źródła dźwięku do żadnych ścieżek dźwiękowych oraz możliwość powiększania stacji dokujących przeglądarki za pomocą kombinacji klawiszy Ctrl - i + lub menu kontekstowego prawym przyciskiem myszy. To jednak nie wszystko, gdyż wydanie rozszerza wsparcie dla ścieżek napisów w źródle VLC do 1000, dodaje wsparcie HEVC i HDR dla kodeka VA-API, wprowadza wsparcie HDR dla źródeł DeckLink, poprawia podgląd miniatur YouTube i wprowadza wsparcie QVBR dla kodeków AMF. Lista ulepszeń obejmuje także wsparcie dla dowiązań symbolicznych ścieżek VST, twoloop jako domyślny kodek AAC dla FFmpeg, wsparcie CUDA dla sprzętowego dekodowania źródeł mediów, lepszą wydajność DeckLink, wsparcie Pythona 3.11 dla skryptów oraz wsparcie FDK AAC na Flatpak. OBS Studio 29.1 jest dostępne do pobrania ze strony projektu na GitHubie, gdzie można również zapoznać się z pełnymi informacjami o wydaniu i sprawdzić, co zostało naprawione w tej znaczącej aktualizacji. Aplikacja Flatpak powinna być także wkrótce dostępna na Flathub.

Google prezentuje reklamy w wynikach wyszukiwania, jednak zanim klikniesz na jedną z nich, warto się zastanowić. Cyberprzestępcy korzystają z platformy reklamowej Google Ads, aby rozpowszechniać złośliwe oprogramowanie. W rezultacie nawet na stronie z wynikami wyszukiwania Google, która wydaje się być bezpieczna, można wpaść w pułapkę. Jeśli przeoczymy podejrzane detale, możemy ściągnąć na komputer złośliwe oprogramowanie, które może doprowadzić do utraty danych i pieniędzy. Jak wygląda atak za pomocą fałszywej reklamy? Dzięki badaniom Elastic Labs dowiedzieliśmy się, jak fałszywe reklamy mogą wyglądać. Na pierwszy rzut oka nie różnią się od reklam autentycznych programów. W pośpiechu można nie zauważyć, że prowadzą do nieautentycznej strony dewelopera. W analizowanym przypadku programu AnyDesk mamy adres https://www.amydecke[.]website zamiast https://www.anydesk[.]com. Trudno przecież pamiętać wszystkie adresy stron programów. Strona, na którą prowadzi reklama, jest myląco podobna do oryginalnej strony pobierania programu AnyDesk. Osoba, która nie zwróci uwagi na adres strony, nie zorientuje się, że jest w niebezpieczeństwie. Jak można się domyślić, przycisk pobierania prowadzi do instalatora z zaskakującą zawartością. Co ciekawe, sam plik MSI wydaje się "czysty" i antywirusy nie wykrywają zagrożenia. W rzeczywistości instalowany zostaje odpowiedni program. W instalatorze znajduje się jednak podejrzany skrypt, który pobiera jeszcze bardziej podejrzaną bibliotekę DLL. W kampanii imitującej pobieranie AnyDesk specjaliści odkryli złośliwe oprogramowanie LOBSHOT. W ciągu ostatniego roku zebrano ponad 500 próbek, zawsze będących 32-bitowymi plikami bibliotek DLL o rozmiarze od 93 do 124 kB. Zagrożenie zostało odpowiednio zamaskowane, utrudniając wykrycie i usunięcie. Uważaj na swoje kryptoportfele! Głównym celem LOBSHOT jest kradzież informacji z kryptoportfeli i wykorzystywanie ich do okradania użytkowników. Malware potrafi zdobyć dane z ponad 50 portfeli kryptowalut, instalowanych jako rozszerzenia w przeglądarkach Google Chrome, Microsoft Edge i Mozilla Firefox. Dzięki modułowi hVNC (hidden Virtual Network Computing) umożliwia zdalny dostęp do zainfekowanego komputera bez zwracania na siebie uwagi. AnyDesk to nie jedyny program, który jest wykorzystywany w takich kampaniach. Analityk Will Dorman na Twitterze pokazał analogiczne kampanie z wykorzystaniem programów takich jak WinRAR, Notepad++, OBS, LibreOffice, Thunderbird, DOSBox i wiele innych. LOBSHOT nie jest również jedynym złośliwym programem, który można łatwo złapać za pomocą fałszywych reklam. Jak się chronić? Aby uniknąć pułapek reklamowych, warto zwracać uwagę na szczegóły, takie jak adres strony i nazwa dewelopera. Upewnij się, że wiesz, gdzie klikasz i czy strona, do której prowadzi reklama, jest autentyczna. W przypadku podejrzeń, najlepiej pominąć reklamę i skorzystać z oficjalnej strony programu lub usługi. Warto również zainstalować oprogramowanie antywirusowe i zawsze mieć włączoną ochronę przeglądarki. Antywirus może pomóc w wykryciu i usunięciu szkodliwego oprogramowania. Ochrona przeglądarki, tak jak na przykład blokowanie niebezpiecznych stron, może również pomóc w uniknięciu fałszywych reklam. Podsumowując, korzystanie z internetu niesie ze sobą ryzyko ataków i kradzieży danych. Ważne jest, aby zawsze zachować ostrożność i zwracać uwagę na szczegóły. W przypadku podejrzeń, lepiej zachować ostrożność i pominąć reklamę, niż potencjalnie stracić dane lub pieniądze.

Szybkie reakcje na zagrożenia to nowy rodzaj aktualizacji oprogramowania dla iPhone, iPad i Mac, który wprowadza ważne ulepszenia bezpieczeństwa między aktualizacjami. Przykładowo, dotyczy to przeglądarki internetowej Safari, stosu frameworków WebKit oraz innych kluczowych bibliotek systemowych. Szybkie reakcje na zagrożenia mogą również służyć do szybszego łagodzenia niektórych problemów związanych z bezpieczeństwem, takich jak te, które mogły zostać wykorzystane lub zgłoszone jako istniejące "w naturze". Nowe Szybkie reakcje na zagrożenia są dostarczane tylko dla najnowszej wersji iOS, iPadOS i macOS - począwszy od iOS 16.4.1, iPadOS 16.4.1 oraz macOS 13.3.1. Domyślnie urządzenie pozwala na automatyczne stosowanie Szybkich reakcji na zagrożenia i, w razie potrzeby, wyświetli monit o ponowne uruchomienie urządzenia. Aby sprawdzić ustawienia swojego urządzenia: iPhone lub iPad: Przejdź do Ustawienia > Ogólne > Aktualizacja oprogramowania > Automatyczne aktualizacje, a następnie upewnij się, że opcja "Odpowiedzi dotyczące bezpieczeństwa i pliki systemowe" jest włączona. Mac: Wybierz menu Apple > Ustawienia systemowe. Kliknij Ogólne w pasku bocznym, a następnie kliknij Aktualizacja oprogramowania po prawej stronie. Kliknij przycisk Pokaż szczegóły obok Automatycznych aktualizacji, a następnie upewnij się, że opcja "Instaluj odpowiedzi dotyczące bezpieczeństwa i pliki systemowe" jest włączona. Gdy Szybka reakcja na zagrożenia zostanie zastosowana, po numerze wersji oprogramowania pojawi się litera, jak na przykład: macOS 13.3.1 (a). Jeśli zdecydujesz się wyłączyć to ustawienie lub nie zastosować Szybkich reakcji na zagrożenia, gdy będą dostępne, urządzenie otrzyma odpowiednie poprawki lub środki zaradcze, gdy zostaną uwzględnione w kolejnej aktualizacji oprogramowania. Źródło: https://support.apple.com/en-us/HT201224

Użytkownicy Revolut muszą być czujni na niebezpieczną próbę wyłudzenia danych – ostrzega CSIRT KNF. W ekstremalnych sytuacjach, nawet dokumenty tożsamości mogą być zagrożone. Fałszywe strony banków nie są niczym nowym, jednak próba wyłudzenia danych przez podszywanie się pod fintech, takiego jak Revolut, zaskakuje. Przestępcy opracowali kampanię, w ramach której wysyłają SMS-y informujące o domniemanym ograniczeniu funkcji Revolut i potrzebie weryfikacji konta – informuje CSIRT KNF. Wiadomość zawiera link, który prowadzi na zmanipulowaną stronę Revolut, imitującą proces tworzenia konta w celu wyłudzenia danych osobowych, takich jak imię, nazwisko, numer telefonu, a nawet zdjęcie i skan paszportu. Uzyskane informacje trafiają w ręce przestępców, którzy, dysponując tak obszernym zestawem danych, mogą wyrządzić poważne szkody ofierze. Potencjalne ryzyka obejmują między innymi uzyskanie kredytów i pożyczek w instytucjach parabankowych na dane ofiary, czy też rejestrację w innych usługach finansowych. Dlatego nie dajcie się oszukać. Wszelkie konieczne operacje w Revolut można przeprowadzić za pomocą oficjalnej aplikacji. Nie ma potrzeby odwiedzania żadnych stron internetowych ani klikania w podejrzane linki. W związku z tym atakiem, warto przypomnieć o podstawowych zasadach bezpieczeństwa, które należy przestrzegać, aby uniknąć niebezpiecznych sytuacji: Zawsze sprawdzaj nadawcę wiadomości: Fałszywe wiadomości mogą pochodzić od nieznanych numerów telefonów lub podejrzanie wyglądających adresów e-mail. Zwracaj uwagę na ewentualne błędy w pisowni lub nietypowe sformułowania. Nigdy nie klikaj w linki w podejrzanych wiadomościach: Jeśli nie jesteś pewien, czy wiadomość jest autentyczna, nie otwieraj żadnych linków ani załączników. Zamiast tego skontaktuj się z dostawcą usługi bezpośrednio, korzystając z oficjalnych kanałów komunikacji. Uaktualniaj oprogramowanie i aplikacje: Regularne aktualizacje oprogramowania i aplikacji na urządzeniach pomagają naprawiać luki bezpieczeństwa, które mogą być wykorzystywane przez przestępców. Korzystaj z silnych haseł i wieloskładnikowego uwierzytelniania: Silne hasła oraz dodatkowe metody uwierzytelniania, takie jak autoryzacja dwuetapowa, mogą znacznie utrudnić dostęp do konta przez osoby niepowołane. Zachowuj ostrożność w przypadku podawania danych osobowych: Nigdy nie udostępniaj swoich danych osobowych, takich jak numer telefonu, adres e-mail czy informacje o dokumencie tożsamości, w odpowiedzi na nieznane prośby. Bądź świadomy zagrożeń: Regularnie edukuj się na temat zagrożeń związanych z cyberbezpieczeństwem, aby być świadomym aktualnych technik wykorzystywanych przez oszustów. Przestrzegając tych zasad, znacznie zmniejszysz ryzyko stania się ofiarą ataków phishingowych i innych prób wyłudzenia danych. Pamiętaj, że w przypadku wątpliwości zawsze warto skontaktować się z obsługą klienta danej usługi finansowej, korzystając z oficjalnych środków komunikacji, takich jak strona internetowa, e-mail czy telefon.

Ubuntu 23.04 - nowe warianty: co nowego? Wraz z wydaniem Ubuntu 23.04, pojawiły się nowe wersje oficjalnych społecznościowych odmian systemu. W tej edycji mamy nowicjusza w gronie: Ubuntu Cinnamon, które dołączyło do rodziny Ubuntu we wcześniejszym marcu, po kilku latach funkcjonowania jako nieoficjalny remix Ubuntu. W tym artykule przedstawiamy krótkie omówienie nowości i zmian w najpopularniejszych wariantach Ubuntu, a także linki do pobrania, aby można było samodzielnie je przetestować. Jeśli nie zaznaczono inaczej, wszystkie odmiany dziedziczą podstawowe pakiety Ubuntu, takie jak jądro Linux 6.2, aktualizowane sterowniki graficzne, aktualizacje aplikacji, odświeżone narzędzia itp. (więc nie będę ich tutaj wymieniać). Zapoznawszy się z wstępem, zanurzmy się w szczegóły! Ubuntu Cinnamon 23.04 Ubuntu Cinnamon debiutuje jako oficjalny członek rodziny Ubuntu. Z pewnością fani środowiska pulpitu Cinnamon znają ten projekt jeszcze z czasów "remixu". Osobiście, próbowałem Cinnamon na Linux Mint wcześniej i choć można by przypuszczać, że doświadczenie na Ubuntu Cinnamon będzie podobne, to jednak się różni. Ubuntu Cinnamon to zdecydowanie odrębny projekt. Niewiele (jeśli w ogóle) aplikacji Mint XApps pojawia się tu, a Ubuntu Cinnamon oferuje dobrze znane "główne" aplikacje, takie jak GIMP, gThumb, Celluloid, Gedit, Evince itd. Wizualnie, pomarańczowe akcenty Ubuntu Cinnamon świetnie komponują się z pozostałymi (domyślnie ciemnymi) elementami kolorystycznymi. Domyślna konfiguracja pulpitu spełnia oczekiwania, a wydajność jest na oczekiwanym poziomie dla Cinnamon: zwinna. Jeśli szukasz nowej odsłony Ubuntu, spróbuj tego. https://ubuntucinnamon.org/ Kubuntu 23.04 Najnowsza wersja Kubuntu, oparta na środowisku KDE, zawiera najnowsze wydanie KDE Plasma 5.27, KDE Frameworks 5.104 i KDE Gear 22.12. Podążając za macierzystym systemem, Kubuntu 23.10 używa PipeWire jako domyślnego serwera dźwięku, choć PulseAudio jest dostępne w repozytoriach. Dodatkowo, piękny odtwarzacz multimedialny Haruna zdaje się być częścią zestawu oprogramowania Kubuntu. Ponieważ wsparcie dla Waylanda w KDE wciąż się rozwija, nie zaskoczy fakt, że Xorg pozostaje preferowanym serwerem wyświetlania w Kubuntu. Sesja Wayland jest dostępna do testowania, ale nie jest jeszcze wspierana. Więcej informacji znajdziesz w oficjalnych notatkach dotyczących wydania Kubuntu 23.04 lub na stronie internetowej Kubuntu, gdzie możesz pobrać najnowszą wersję. Xubuntu 23.04 Xubuntu ma dla mnie szczególne miejsce. Świetnie działa na moim starym Chromebooku z procesorem Intel, a pulpit Xfce pozwala na skupienie się na wykonywaniu zadań. Xubuntu 23.04 zawiera znakomitą aktualizację Xfce 4.18, która między innymi wyposaża menedżer plików Thunar w edytowalny pasek narzędzi, podświetlanie plików i rekurencyjne wyszukiwanie. Pojawiło się też kilka nowych opcji panelu, w tym więcej czcionek w aplecie zegara (które sprawiają mi przyjemność podczas zabawy). Dodatkowo, Xubuntu 23.04 dostępne jest do pobrania jako nowy obraz "minimalny". Jego rozmiar jest mniejszy (tylko 1,9 GB w porównaniu do 3,25 GB głównej edycji), ponieważ zawiera mniej pakietów. Jeśli nie przepadasz za zbędnym oprogramowaniem, koniecznie sprawdź ten obraz. Możesz pobrać wydanie z serwera wydań Ubuntu. Ubuntu MATE 23.04 Ubuntu MATE 23.04 nie wprowadza istotnych zmian, co z pewnością ucieszy wiernych fanów, ceniących sobie znajomość systemu! Podobnie jak Kubuntu, Ubuntu MATE 23.04 używa PipeWire jako domyślnego serwera dźwięku. Zainstalowany jest MATE desktop 1.26.1 oraz poprawka do pakietu Ayatana Indicators. Wprowadzono kilka drobnych ulepszeń wizualnych (głównie zaktualizowane ikony), ale nowy zestaw tapet generowanych przez sztuczną inteligencję z pewnością zasługuje na uwagę - niektóre z nich są naprawdę świetne. W Ubuntu MATE 23.04 (i innych wariantach Ubuntu) Flatpak nie jest już domyślnie zainstalowany, gdyż deweloperzy zdecydowali, że snaps są preferowanym formatem pakietów dla aplikacji spoza repozytorium. Oczywiście, możesz samodzielnie zainstalować Flatpak za pomocą sudo apt install. Biorąc pod uwagę liczbę aplikacji dodanych do Flathub, warto to zrobić! Więcej szczegółów znajdziesz w notatkach dotyczących wydania Ubuntu MATE 23.04, a obrazy ISO można pobrać z serwera wydań Ubuntu. Ubuntu Budgie 23.04 Ubuntu Budgie 23.04 dostarcza Budgie desktop 10.7.1 (który również trafi do użytkowników Ubuntu Budgie 22.04 LTS). Deweloperzy zwracają uwagę, że ta wersja oferuje "ulepszone możliwości narożników" oraz "intuicyjne wsparcie dla układania" dla wejść myszy i/lub klawiatury. Nowy indeksator aplikacji ułatwia szybsze wyszukiwanie; dostępne jest nowe, osobiste menu użytkownika; powiadomienia na pulpicie teraz pojawiają się i znikają płynnie; a nowa aplikacja Budgie Screenshot jest wbudowana w pulpit (stary gnome-screenshot można zainstalować z repozytorium). Więcej informacji można znaleźć w notatkach dotyczących wydania Ubuntu Budgie 23.04 lub pobrać obraz na standardowe komputery lub, co warto zauważyć, Raspberry Pi z serwera obrazów Ubuntu. Powyższe warianty nie są jedynymi z nowymi wydaniami. Oto garść informacji o pozostałych: Lubuntu 23.04 zawiera LXQt 1.2.0 (niestety 1.3.0 nie zdążył się ukazać) i korzysta z Picom jako domyślnego kompozytora X; Ubuntu Studio 23.04 stawia na środku sceny KDE Plasma 5.27; Edubuntu 23.04 wraca do klasy po 9 latach przerwy, a teraz dystrybucja korzysta z GNOME 44. Ubuntu Unity 23.04 kontynuuje rozwój i udoskonalanie dawnego domyślnego środowiska pulpitu Ubuntu. Wersja 7.7 wprowadza wsparcie dla nowych widgetów w Dash. Jeśli jesteś fanem któregoś z wariantów, nie krępuj się: podziel się swoimi przemyśleniami na temat najnowszego wydania (wspominając o konkretnej zmianie, która Ci się podoba) w komentarzach poniżej! Jak zaktualizować Ubuntu z wersji 22.10 do 23.04 Chcesz zaktualizować Ubuntu do wersji 23.04 z 22.10? Jeśli twój system jest w pełni aktualny i masz aktywne połączenie z internetem, możesz to zrobić – a w tym wpisie przedstawiam kroki, jak to zrobić. Ubuntu 22.10 osiągnie koniec życia w lipcu, co oznacza, że użytkownicy muszą zaktualizować system do wersji 23.04, aby nadal otrzymywać aktualizacje. Nie chcesz co 6-9 miesięcy aktualizować systemu? Możesz rozważyć świeżą instalację Ubuntu 22.04 LTS, które jest wspierane do 2027 roku. W każdym razie, jesteś tutaj, bo chcesz zaktualizować system do wersji 23.04, więc przejdźmy do instrukcji. Aktualizacja do Ubuntu 23.04 jest prosta Aby zaktualizować Ubuntu do wersji 23.04, musisz spełnić wszystkie poniższe wymagania: Używasz Ubuntu 22.10 Zainstalowałeś wszystkie oczekujące aktualizacje Masz stabilne połączenie z internetem Nie można zaktualizować Ubuntu z wersji 22.04 do 23.04 bezpośrednio. Zamiast tego, musisz najpierw zaktualizować do Ubuntu 22.10, a potem zaktualizować 22.10 do 23.04. W tej sytuacji łatwiej jest pobrać Ubuntu 23.04, nagrać obraz ISO na pendrive, uruchomić z niego komputer i wykonać czystą instalację – ale wybór należy do ciebie. Aktualizacja prostym sposobem Aktualizacja z Ubuntu 22.10 do 23.04 jest bardzo prosta. Wystarczy: Zainstalować WSZYSTKIE oczekujące aktualizacje oprogramowania Kiedy twój system 22.10 następnym razem sprawdzi aktualizacje, zauważy nową wersję i zapyta, czy chcesz zaktualizować. Kliknij „aktualizuj” w oknie z aktualizacją, a następnie postępuj zgodnie z instrukcjami na ekranie (to dość proste) i wkrótce system zostanie zaktualizowany. Na koniec zrestartuj komputer. Aktualizacja z linii poleceń Jeśli nie chcesz aktualizować Ubuntu do wersji 23.04 za pomocą aplikacji GUI Software Updater, możesz postępować zgodnie z poniższymi krokami, aby zaktualizować Ubuntu 22.10 do 23.04 z linii poleceń. Aby zacząć, otwórz nowe okno Terminala i wpisz: sudo do-release-upgrade To polecenie sprawdza dostępność nowej wersji, a następnie wyświetla informacje o niej. Wystarczy nacisnąć "y", aby kontynuować. Kontynuowanie spowoduje wyłączenie PPA i repozytoriów innych firm w systemie. Lista aktualizacji pakietów jest pobierana, kompilowana i prezentowana użytkownikowi. Jeśli jesteś zadowolony z aktualizacji, możesz kontynuować. Tekst na ekranie prowadzi cię przez cały proces, ale mała rada: nie pozostawiaj urządzenia całkowicie bez opieki, ponieważ w trakcie aktualizacji możesz być poproszony o naciśnięcie "y" (zwłaszcza jeśli twój system ma dużo aktualizacji z dodatkowych repozytoriów). Gdy aktualizacja zostanie zakończona, otrzymasz informację o konieczności zrestartowania komputera – zrób to, a po ponownym uruchomieniu będziesz mógł zalogować się do Lunar Lobster! Przed aktualizacją przeczytaj to! Zrób kopię zapasową ważnych plików i folderów przed aktualizacją Ubuntu – najlepiej na innym dysku lub partycji. W ten sposób, jeśli coś pójdzie bardzo źle podczas aktualizacji, nie stracisz niczego cennego. PPA i repozytoria innych firm są wyłączane podczas aktualizacji. Musisz ręcznie je ponownie włączyć (jeśli wspierają Ubuntu 23.04) po zaktualizowaniu systemu. Jeśli tego nie zrobisz, ryzykujesz zostanie OSOBĄ, która narzeka na brak aktualizacji dla swojej ulubionej aplikacji w systemie Linux, nie zdając sobie sprawy, że to właśnie ona jest winna! Na koniec, jeśli (jak wielu) zastąpiłeś Firefox Snap wersją Deb z PPA zespołu Mozilla, MUSISZ odblokować pakiet przed aktualizacją, inaczej może się nie powieść. Dobrą wiadomością jest, że wspomniane PPA już wspiera Ubuntu 23.04, więc powinieneś być gotowy. Ostatecznie, jeśli używasz rozszerzeń GNOME, pamiętaj, że mogą jeszcze nie być kompatybilne z GNOME 44. Podsumowanie Jeśli postępowałeś zgodnie z krokami w tym wpisie, powinieneś (miejmy nadzieję!) zaktualizować Ubuntu do wersji 23.04 bez żadnych problemów. Oczywiście, zwykle najlepiej jest poczekać, aż oficjalne powiadomienie o aktualizacji się pojawi, ale jako że nie zawsze jest to natychmiastowe, a ludzie CHCĄ MIEĆ NOWĄ WERSJĘ TERAZ, ten wpis powinien pomóc.

Kryptonim dla Ubuntu 23.10 został ujawniony, a jego nazwa brzmi imponująco. Zgodnie z informacjami na Launchpad, platformie dla rozwoju Ubuntu, Ubuntu 23.10 nosi kryptonim "Mistyczny Minotaur". Ten magnetyczny tytuł może zaowocować kolejnym milowym krokiem w rozwoju... Cóż, kończą mi się słowa zaczynające się na M – ale co to oznacza? Termin 'Mistyczny' - Mantic jest przymiotnikiem odnoszącym się do wróżbiarstwa lub przepowiedni. 'Minotaur' to, jak większość z was zapewne wie, mityczne stworzenie z greckiej legendy, które ma ciało połowicznie ludzkie, połowicznie bydlęce. Razem te słowa oznaczają... Nic konkretnego. Kryptonimy Ubuntu już nie mają takiego tajemniczego przekazu, jak kiedyś. Dzisiaj są wybierane, ponieważ są zabawnie szalone ("Disco Dingo"), niewątpliwie urocze ("Kinetic Kudu") lub na granicy absurdalności ("Hirsute Hippo"). Mistyczny Minotaur może wydawać się łamać konwencję nazewnictwa opartą na ssakach, ale już wcześniej mieliśmy mityczne stworzenia, takie jak Wily Werewolf, więc nie jest to zupełnie z innej galaktyki. Ubuntu 23.10 zostanie wydane 12 października 2023 r. Więcej szczegółów na temat zawartości wydania zostanie ujawnione w nadchodzących miesiącach, w miarę jak rozwój systemu nabierze tempa, a pakiety będą sukcesywnie dodawane. Możemy jednak wysunąć kilka założeń. Nowe jądro Linuxa? To pewnik, podobnie jak aktualizowane sterowniki graficzne. Na pewno zobaczymy GNOME 45, a także dalsze udoskonalenia nowego instalatora opartego na Flutter, aby był w pełni sprawny na przyszłoroczne wydanie LTS. Jaki kryptonim wybralibyście, gdybyście mieli taką możliwość? Podzielcie się nim w komentarzach, razem z nadziejami, życzeniami i oczekiwaniami dotyczącymi nadchodzącej wersji! Źródło: https://launchpad.net/ubuntu/+series https://en.wikipedia.org/wiki/Minotaur

Ostrzeżenie: GhostToken! Nowa słabość w zabezpieczeniach Google Cloud Platform Odkryto nową lukę w Google Cloud Platform (GCP), która pozwala atakującym na modyfikację aplikacji OAuth i ukrycie jej, aby stworzyć backdoor do dowolnego konta Google. Podatność otrzymała nazwę GhostToken i umożliwia atakującym całkowite ukrycie złośliwej aplikacji przed użytkownikiem Google oraz wykorzystanie jej do pozyskania tokenów konta w celu uzyskania dostępu do danych ofiary. Astrix, firma specjalizująca się w bezpieczeństwie między aplikacyjnym, wyjaśnia, że problem pojawił się przy usuwaniu klientów OAuth, które są w rzeczywistości projektami GCP. Astrix odkrył lukę w czerwcu ubiegłego roku. Kiedy projekt GCP jest usuwany – przez właściciela lub osobę mającą odpowiednie uprawnienia – przechodzi w stan "oczekiwania na usunięcie" na 30 dni, co pozwala deweloperowi przywrócić go w razie potrzeby. Jednakże, po takim usunięciu, projekt nie jest już widoczny na stronie zarządzania aplikacjami konta Google, mimo że wciąż może mieć dostęp do tego konta. To samo dotyczy projektów GCP będących klientami OAuth. Mimo że użytkownik dostaje powiadomienie o usunięciu klienta, aplikacja wciąż ma dostęp do konta aż do jej rzeczywistego usunięcia. Astrix odkrył również, że po przywróceniu takiego klienta OAuth z trybu "oczekiwania na usunięcie", token odświeżania, utworzony przez użytkownika podczas pierwszej autoryzacji aplikacji, zostaje ponownie aktywowany. Token odświeżania może być następnie wykorzystany do pozyskania tokena dostępu do konta ofiary, co prowadzi do uzyskania dostępu do jej danych. Atakujący może wykorzystać tę lukę, tworząc lub przejmując aplikację OAuth i uzyskując dostęp do tokena odświeżania. Następnie atakujący może usunąć projekt powiązany z aplikacją, utrudniając ofierze usunięcie go z konta. W celu uzyskania dostępu do danych ofiary, atakujący przywracał projekt, korzystał z tokena odświeżania, aby uzyskać token dostępu, a potem ponownie usuwał projekt, aby ukryć aplikację i uniemożliwić jej usunięcie. "Korzystając z luki GhostToken, atakujący może ukryć złośliwą aplikację na stronie zarządzania aplikacjami konta Google ofiary. Jako że to jedyna lokalizacja, gdzie użytkownicy Google mogą przeglądać swoje aplikacje i anulować dostęp, exploit utrudnia usunięcie złośliwej aplikacji z konta Google" – zauważa Astrix. W takim scenariuszu token dostępu umożliwiałby atakującemu czytanie wiadomości e-mail ofiary, dostęp do jej plików w Google Drive i Google Photos, przeglądanie kalendarza, śledzenie lokalizacji oraz "przyznawanie dostępu do usług Google Cloud Platform" – wyjaśnia firma zajmująca się bezpieczeństwem. Google podjęło działania w celu zażegnania tego problemu w tym miesiącu, wprowadzając zmiany, które sprawiają, że aplikacje o statusie "oczekujące na usunięcie" są teraz widoczne na koncie Google użytkownika. Dzięki temu użytkownicy mogą je trwale usunąć, zabezpieczając swoje konta przed nieautoryzowanym dostępem. Źródło: https://astrix.security/ghosttoken-exploiting-gcp-application-infrastructure-to-create-invisible-unremovable-trojan-app-on-google-accounts/ https://astrix.security/astrix-discovers-0-day-vulnerability-in-google-cloud-platform/

Przygotuj się na tydzień wypełniony tak dużą ilością nauki, jak tylko możesz! Odblokowaliśmy naszą platformę umiejętności technologicznych i udostępniliśmy wszystkie ponad 7000 kursów wideo prowadzonych przez ekspertów, ponad 40 interaktywnych kursów i ponad 20 projektów tylko przez jeden tydzień. Przygotuj więc swoją strefę pracy na poważny rozwój umiejętności, ponieważ nadszedł czas, aby skorzystać z naszej platformy Umiejętności bezpłatnie od 4/24 do 4/30. Twój bezpłatny dostęp do Pluralsight Skills wygaśnie w niedzielę, 30 kwietnia o 23:59 MT - promocja jest ograniczona (jest to akcja samego portalu). https://www.pluralsight.com/offer/2023/q2-free-week?utm_source=facebook&utm_medium=paid-social&utm_campaign=upskilling-and-reskilling&utm_term=ssi-global-inform-free-week-q2-skills-2023&fbclid=IwAR3qUmEdA-jDCRzuGO-iODIba2ndORK4Yb6I5IEKYB4tcLnnHVVSlNimB04