Search Results

VMware ogłosiło, że od 11 listopada 2024 roku ich produkty VMware Fusion i VMware Workstation będą dostępne za darmo dla użytkowników komercyjnych, edukacyjnych i prywatnych. Dotychczasowy model subskrypcyjny zostanie całkowicie wyeliminowany, a płatne wersje Pro tych narzędzi nie będą już dostępne do zakupu. Użytkownicy, którzy mają aktywne kontrakty komercyjne, będą mogli korzystać z dotychczasowego wsparcia do końca umowy. Bezpłatna wersja narzędzi będzie zawierać wszystkie funkcje znane z wersji płatnych, ale wsparcie techniczne będzie ograniczone do zasobów online, takich jak dokumentacja, artykuły w bazie wiedzy i fora społecznościowe. Nowi użytkownicy będą mieli dostęp do rozbudowanego ekosystemu wsparcia społecznościowego oraz szczegółowej dokumentacji. VMware zobowiązuje się do dalszego inwestowania w rozwój swoich produktów, zapewniania ich stabilności oraz dostarczania ulepszeń, które spełniają potrzeby szerokiego grona użytkowników. Szczegółowe informacje można znaleźć na stronie produktowej oraz w sekcji FAQ. Link: https://blogs.vmware.com/cloud-foundation/2024/11/11/vmware-fusion-and-workstation-are-now-free-for-all-users/

Hej przed nami warsztaty z proxmox - część dryga. Na pierwszej edycji było ponad 200 osób. MOże ta liczba Cię nie zachwyca ale co jak Ci powiem że wszystkie te osoby dostały na czas warsztatów laba z proxmox konfiguracją 3 node. Czyli podczas 2 godzinnych warsztatów było ponad 600 działajacych i zautomatyzowanych maszyn. Zaciekawiony to wpadaj na warsztaty zapisy ruszaja tu https://szkolenia.cloud/warsztaty-proxmox/ A warsztaty już 27.11.2024 o godzinie 17:00 i potrwają 2 godziny

Zapraszam na warsztaty z github actions gdzie wspólnie zbudujemy pipeline, który pozwoli nam zarządzać konfiguracja w chmurze z wykorzystaniem terraform. Przejdziemy przez konstrukcję jezyka yaml dla github actions i zobaczymy jak po przez odpowiednie parametry sterować konfiguracją naszego actions. Przejdziemy przez konstrukcję build, test, deploy w actions GitHub. Tak by skonfigurować naszą akcję, która pozwoli nam kontrolować nasz pipeline związany z dystrybucją naszego rozwiązania. Zapisać się można na stronie https://szkolenia.cloud/warsztaty-github-actions/ Dla uczestników wydarzenia zostanie przygotowany imienny dyplom uczestnictwa wystawiony w formie certyfikatu. Spotkanie odbędzie się 28.11.2024 o godzinie 17:00. Zapraszam na 2 godzinna zabawę z github actions na żywo.

W oczekiwaniu na kolejne warsztay z proxmox które odbęda się 13.11.2024 zapraszam na artykuł o tym jak zautomatyzować sobie konfiguracje klastra proxmox. Taka automatyzacja może nam posłużyć w przypadku tworzenia naszej testowej konfiguracji lub w przypadku gdy obecna konfiguracja ulegnie awarii i szybko będziemy musieli przystąpić do odtworzenia naszego środowiska. Zatem zaczynamy. Nudny proces instalacji proxmox Zawsze gdy musiałem instalować proxmox na nowo zastanawiałem się czy nie można byłoby ten proces jakoś zautomatyzować. Wsadzić pendrive do USB i zapomnieć o całej konfiguracji. Nie przechodzić przez nudny proces instalacji i konfiguracji czystego środowiska. Wybierania standardowych ustawień. Mówie tu o środowisku testowym gdzie testowałem różne konfiguracje raz z lepszym czy gorszym rezultatem i byłem zmuszony do przeinstalowania proxmoxa. Lub wpadł w ręce moje nowe sprzęt i chciałem na szybko zobaczyć jak będzie działał na nim proxmox za dedykowaną sprzętową wirtualizacją. I na samą myśl o ponownym procesie instalacji telepotało mną. Bo znów będę musiał podłączać mój przenośny monitor, mini klawiaturę itp itd. Zatem szukając w internecie rozwiązania trafiłem na proces automatycznej instalacji proxmoxa zwany Automated Installation . Proces ten opisywałem już w swoim poprzednim artykule zatytułowanym Proxmox automatyzacja instalacji . Który to idealnie wpasował sie w moje potrzeby. Zatem szybko tworzymy nasz specjalny plik który nazywa się answer.toml - poniżej przykład konfiguracji takiego pliku: Taki utworzony plik dodajemy do naszego iso przez narzędzie proxmox-auto-install-assistant: Wynikowy obraz wypalamy na naszym USB. To oczywiście tak szybko w skrócie, jak wspomniałem opisuje to już w swoim poprzednim artykule zatytułowanym Proxmox automatyzacja instalacji . Jednak to nie koniec automatyzacji jaka możemy zrobić. Pójdźmy dalej. Automatyzacja konfiguracji klastra proxmox. Idąc dalej tym krokiem, skoro zrobiłem już automatyczna instalację systemu i nawet zbudowałem pod to środowisko na, którym mogę prowadzić warsztaty czy po prostu testować proxmoxa to czemu nie pójść dalej. Oczywiście ty też możesz moją automatyzacje przetestować - zbudowana jest na bezie Terraform i cloud init. Kod źródłowy znajdziesz na bitbucket . Całość bazuje na zagnieżdżonej wirtualizacji i działa dość płynnie w DigitalOcean. Więc uruchamiasz usługę i płacisz za nią tyle ile używasz bez konieczności płacenie miesięcznego commitmentu. Size według moje opini optymalny do testowania to c-32-intel który kosztuje 1$ za godzinę działania. Oczywiście można znaleźć coś tańszego. Wróćmy jednak do tematy i pytania czy naszą konfigurację można zautomatyzować - pewnie że można. Musimy wybrać tylko odpowiednie narzędzie i ruszamy. Będę bazował na założeniach i poprzedniej ręcznej konfiguracji mojego klastra w maszynie wirtualnej w DigitalOcean z poprzednich warsztatów (tak nawiasem mówiąc warsztaty do obejrzenia na tej stronie ). Przypomnienie jaką mamy konfigurację dostępnych interfejsów sieciowych. Mamy bazowa konfiguracje która zrobiliśmy przez nasz plik answer. Proxmox automatyczna konfiguracja interfejsu sieciowego Na poprzednich warsztatach zaczęliśmy od podłączenia naszego klastra, jeszcze wtedy trzy osobne węzły do jednej wspólnej sieci nazwanej CLUSTERBR1. Jak taki interfejs stworzyć za pomocą polecenia CLI bez klikania w GUI? Czego będziemy potrzebować? Ogólnie da się to zrobić przez modyfikację pliku /etc/network/interfaces dodając kolejny wpis o naszym bridge interfejsie. Czyli coś takiego: Ale oczywiście nie po to pisze o automatyzacji by teraz to edytować ręcznie. Rezygnujemy z GUI ale bez przesady. Wybierzmy lepsze narzędzie niż nasz terminal CLI i edytor nano. Zatem zwalniamy mechanizm blokujący i rozpoczynamy losowanie. Dzisiejsze litery to A, N, S, I, B, L, E. Nasz tasks/main.yml z roli networking: Tasks ten jak możemy zobaczyć na początku sprawdza czy nasz katalog /etc/network istniej, a potem dodaje zdefiniowane interfejsy poprzez loop instrukcję. Jak zostanie dokonana zmiana mamy zdefiniowaną instrukcje notify w naszej konfiguracji. Do tego będziemy potrzebować handlers/main.yml z roli networking: To nic innego jak byśmy w terminalu wydali systemctl restart networking. A i warto pamiętać o przygotowaniu naszego pliku do sterowania naszymi hostami bo nie chcielibyśmy aby wszystkie miały ten sam adres IP. Zatem nasz plik z inventories/dev/host_vars/proxmox1.yml - jako przykład Uruchamiamy nasz kod w ansible do tworzenia dodatkowego interfejsu sieciowego bridge: Sprawdźmy konfiguracje logując się na naszego proxmox01 - interfejs sieciowy dodany. Proxmox automatyzacja tworzenia klastra Po skonfigurowaniu naszych interfejsów sieciowych należałoby połączyć nasze węzły w klaster dzięki któremu będą one widziane jako jedna całość. Narzędzie do zarządzania naszym klastrem to pvecm (Proxmox VE Cluster Manager). Wydając polecenie: Możemy sprawdzić czy nasz węzeł należy do jakiegoś klastra. Jak widzimy nasz węzeł nie należy do żadnego klastra. Utworzyć nasz klaster też możemy przez polecenie pvecm create. Zacznijmy od stworzenia naszego klastra. Spójrzmy na nasz plik task/main.yml z roli proxmox/proxmox_cluster_create: DemoCluster - to nazwa tworzonego naszego klastra. Oczywiście można to wyciągnąć jako zmienna i zapisać w pliku hosta. --link0 - to pierwszy link w naszej konfiguracji, max możemy ustawić 8. {{ item.address.split('/')[0] }} - odwołanie sie do adresu IP zawartego w pliku konfiguracyjnym naszego hosta w ansible. Proxmox automatyzacja dodawania węzłów Gdy mamy nasz klaster (DemoCluster) to dobrze jest dodać do niego węzły tak by było dostępne więcej zasobów w postaci CPU i RAM: Spójrzmy zatem na tasks/main.yml z roli copy_ssh_key: Zadaniem tego taska w ansiblu jest przekopiowanie pliku prywatnego SSH do węzłów proxmox02 i proxmox03. Tak by można było dodać te dwa węzły automatycznie. Musimy pamiętać, że dodając węzeł do klastra musimy się uwierzytelnić, hasłem lub kluczem. Za pomocą klucza łatwiej to zautomatyzować. Ok teraz możemy działać z naszym tasks/main.yml z roli proxmox/proxmox_cluster_add_node: Polecenie pvecm add pozwala dodać nam nasz węzeł do aktywnego wcześniej stworzonego klastra: 192.168.255.100 - to adres naszego wczesniej stworzonego DemoCluster --link0 {{ item.address.split('/')[0] }} - tu ustawiamy ze zmiennych adres naszego aktualnego węzła. --use_ssh true - dajemy informacje że będziemy korzystać podczas przyłączania naszego węzła z autoryzacji SSH --force - jak nasz węzeł będzie już istniał w tej konfiguracji to nie wyświetlaj błędu. do całości jest ładowany ssh-agent tak by użyć klucza proxmox wgranego wcześniej Limitujemy to do jednego hosta, tak by nie było problemu dodawanie dwóch węzłów w tym samym czasie. Oczywiście od strony ansible możesz to zautomatyzować przez parametr scope - który będzie limitowało operacje i wykonywał jedna po drugiej (dopiero gdy pierwszy host skończy operacje). Ponawiamy operacje na drugim hoscie wskazując poprzez opcję --limit "proxmox3" Sprawdzamy status klastra po dodaniu obu węzłów poleceniem pvecm status Tak oto mamy skonfigurowany klaster DemoProxmox z trzema węzłami. Pójdźmy dalej tym krokiem i przeprowadźmy konfigurację naszego sieciowego storage. Proxmox automatyzacja sieciowego starage Skonfigurujemy nasz storage NFS tak byśmy mogli go wykorzystać do konfiguracji naszej maszyny wirtualnej - mamy już przygotowany skrypt który to robi - potrzeba jeszcze tylko naszego network storage. Użyjemy do tego polecenia pvesm add - dodanie naszego storage nfs - typ naszego storage {{ item.name }} - nazwa pobierana z wartości zdefiniowanej w host_vars --export - exportowany udział zdalny --path - miejsce montowania w klastrze proxmox (na każdym węźle) --content - zawartość naszego storage, czyli jakie obiekty będziemy mogli tu przechowywać. NFS storage dodany. A na ostatnich warsztatach potrzebowaliśmy naszego snippet dla local. Zmodyfikujemy nasz local storage za pomocą set. Dodatkowa konfiguracja naszego pliku hosta została wzbogacona o kilka parametrów. Podsumowanie Zróbmy na koniec podsumowanie użytych narzędzi pvecm i pvesm.  W Proxmox VE są kluczowymi narzędziami wiersza poleceń, które umożliwiają zarządzanie klastrem oraz interakcję z API Proxmox. pvecm (Proxmox VE Cluster Manager) pvecm to narzędzie służące do zarządzania klastrem w Proxmox VE. Pozwala na tworzenie, konfigurowanie i monitorowanie klastra Główne funkcje pvecm: Tworzenie klastra:  Inicjalizacja nowego klastra Proxmox. Dodawanie węzłów:  Przyłączanie nowych serwerów do istniejącego klastra. Usuwanie węzłów:  Bezpieczne usuwanie węzłów z klastra. Monitorowanie:  Sprawdzanie stanu klastra i węzłów. Zarządzanie quorum:  Konfiguracja ustawień quorum dla zapewnienia spójności danych. pvesm (Proxmox VE Storage Manager) pvesm to narzędzie wiersza poleceń umożliwiające zarządzanie magazynami danych w Proxmox VE. Główne funkcje pvesm: Dodawanie magazynów:  Konfiguracja nowych magazynów, takich jak NFS, iSCSI, Ceph i inne. Usuwanie magazynów:  Usuwanie istniejących konfiguracji magazynów. Wyświetlanie magazynów:  Wyświetlanie informacji o aktualnych konfiguracjach magazynów. Zarządzanie zawartością:  Definiowanie typów danych, które mogą być przechowywane (np. obrazy maszyn, pliki ISO, kopie zapasowe). Obsługiwane typy magazynów: Directory (dir):  Lokalne katalogi na węźle Proxmox. LVM:  Magazyn oparty na Menedżerze Woluminów Logicznych. NFS:  Udziały sieciowe Network File System. iSCSI:  Sieciowy interfejs SCSI. Ceph:  Rozproszony system przechowywania danych. ZFS:  System plików i menedżer woluminów. GlusterFS:  Skalowalny system plików sieciowych. Zrozumienie plików konfiguracyjnych magazynów Proxmox VE przechowuje konfigurację magazynów w pliku /etc/pve/storage.cfg. Polecenie pvesm modyfikuje ten plik w tle. Typowe typy zawartości: • images:  Obrazy dysków maszyn wirtualnych i kontenerów. • iso:  Pliki obrazów ISO do instalacji systemów operacyjnych. • vztmpl:  Szablony dla kontenerów LXC. • backup:  Pliki kopii zapasowych tworzone przez zadania backupu Proxmox VE. • snippets:  Niestandardowe skrypty lub fragmenty kodu. Jak widzimy w tym prostym przykładzie dzięki poleceniom pvecm i pvesm możemy zarządzać naszym klastrem Proxmox. Więcej na ten temat porozmawiamy na planowanych warsztatach . Repozytorium z konfiguracja ansible dostepne tutaj .

Na ostatnich warsztatach z proxmox użyłam automatyzacji w terraform i cloud-init w celu zautomatyzowania całej konfiguracji i dostarczeniu środowiska dla słuchaczy. Pojawiły się komentarze i pytania dlaczego nie użyłem w konfiguracji ansible. Ten wpis odpowie na te pytanie. Zapraszam Automatyzacja proxmox w terraform - założenia. Moim założeniem dla pierwszych warsztatów było przygotowanie środowiska dla słuchaczy które, w sposób zautomatyzowany dostarczy środowisko labowe z proxmox. Czyli dla jednego słuchacza będzie dostępny proxmox z 3 nodami już zainstalowany i prekonfigurowany tak by każdy mogł bez konieczności instalacji przystąpić do warsztatów. Oczywiście skalowalność tu gwarantuje mi terraform. Uruchomienie jednej czy 200 maszyn wirtualnych to ta sama procedura. Bazuje na wkładzie, a poniżej jego przykład w json Jednak potrzebowałem kolejnego kroku który pozwoli mi przygotować konfigurację nie na infrastrukturze która już za pomoca terraform jest zrobiona - cały kod można znaleźć tutaj . I tutaj padł wybór że będzie to zaimplementowane dalej w terraform. Przeświadczyło za tym kilka powodów. Kontrola automatyzacji  - nie przejmuje się czyj host jest czyj, tzn w konfiguracji terraform mi to planuje, każdy użytkownik jest identyfikowany unikatową nazwą. Nazwa ta potem jest wykorzystywana dla nazwy jego hosta. Brak konieczności używania dodatkowego narzędzia takiego jak ansible . Rezygnacja z generowania artefaktu konfiguracyjnego dla ansible znacząco przyśpiesza działanie. Przeniesienie konfiguracji do cloud-init spowodowało, że konfiguracja maszyny wirtualnej (pojedynczej) rozpoczynała się już gdy tylko ona została przez API postawiona/uruchomiona. W przypadku gdybym generował artefakt i czekał na zakończenie terraform w celu przekazania do ansible proces mogłby się wydłużyć. Ponieważ ansible musiało by poczekać na zakonczenie działania przez terraform. Zarządzanie już gotową konfiguracją . Gdybym rozbił to na terraform i ansible w przypadku pojedynczych problemów musiałbym uruchomic terraform i czekać na jego zakończenie po czym ręcznie pojedynczo uruchamiać ansible dla problematycznych hostów. W moim przypadku cała operacja zamyka się w dwóch komendach, terraform state list i terraform taint na problematycznym zasobie. Cała magia pod spodem działa tak samo. Oczywiście pragnę tu zaznaczyć, że nie uważam ansible za słabe narzędzie, akurat w moim przypadku było to zbędne narzędzie i krok. Terraform taint i untaint na ratunek Cała automatyzacje mojej konfiguracji trzymam w dwóch miejscach w github jak miejsce gdzie przechowuje repozytorium i całą zawartość kodu. Drugie miejsce to narzędzie do automatyzacji. Uzywam tutaj github actions oraz dodatkowo wspomagam się Jenkins w przypadku awarii pierwszego narzędzia. Co o ironio miała już miejsce. W github actions (i jenkins) mam skonfigurowane pipeline które realizują takie zadania jak: Budowanie i konfiguracja infrastruktury (workflow terraform plan i apply) Wyświetlanie informacji o naszym stanie (terraform state list) Zwracanie wartości (terraform output) Oraz narzędzie do rekonfiguracji problematycznych zasobów (terraform taint) Tutaj skupią Twoją uwagę na przedostatnim i ostatnim punkcie konfiguracji w github actions. Terraform state - informacje o naszych zasobach. Terraform state list - polecenie to zwraca informacje o wszystkich naszych zasobach uruchomionych w terraform oraz zarządzanych przez naszą konfigurację. Spojrzmy na poniższą konfigurację github action w yaml Jest to prosta deklaracja joba który odpowiednio łączy się do naszego stanu by potem po przez komendą terraform state list wyświetlić nam informacje o wszystkich zasobach. Poniższe zdjęcie prezentuje przykład takiego outputu z tego włąsnie github actions. Wyświetlone w ten sposób informacje mogę wykorzystać w terraform taint i problematyczny zasob oznaczyć ponownie do konfiguracji. Spójrzmy na kod naszego workflow za wykorzystaniem naszego polecnia taint w konfiguracji terraform. Spójrzmy na początek mojego workflow - deklaruje w nim opcje podania wartości wejściowej co pozwala mi sterować poleceniem taint w ramach tej konfiguracji. Dzięki temu mogę sterować rekonfiguracja danego zasobu. Jak to działa w praktyce. Wykorzystanie terraform taint, untaint i state z github actions Spójrzmy na przykład, dostarczę wkład konfiguracyjny który, uruchomi mi instancje dla moich dwóch uczestników (dla większej konfiguracji to tylko efekt większej skali i dostarczenia większego wkładu). Teraz wystarczy uruchomić workflow związany z deploymentem konfiguracji: Oto jego rezultat: github actions jest uruchamiany: W międzyczasie jego działania możemy śledzić postęp naszej konfiguracji by zobaczyć jakie zasoby są tworzone modyfikowane itp. Konfiguracja zakończyła się sukcesem mamy stworzone środowisko dla dwóch uczestników (przy większej liczbie działa to dokładnie tak samo - wydłuża się jedynie czas oraz lista naszych zasobów które są uruchamiane przez terraform). Teraz by otrzymać listę wszystkich dostępnych zasobów mogę skorzystać z workflow który pozwala wyświetlić właśnie ta listę z terraform state. Uczestnicy tej konfiguracji mają swój zasób i widzimy go pod adresami: module.szkolenie.digitalocean_droplet.main["Marcin Koska"] module.szkolenie.digitalocean_droplet.main["Piotr Koska"] Dla naszego zrozumienia konfiguracji wyobraźmy sobie że użytkownik oznaczona jako Marcin Koska ma problemy ze swoją instalacją. Problemy to przez pomyłke usunął konfiguracje czy też instalacje proxmoxa w prezentowanym labie na swoim hoscie. Terraform taint pozwoli rozwiązać na problem w sposób pełni automatyczny. Wystarczy, że odwołam się do adresu użytkownika module.szkolenie.digitalocean_droplet.main["Marcin Koska"] i uruchomię workflow związany z taint Wskazujemy zasób który w tym przypadku jest problematyczny i jak widać na poniższym obrazku operacja wykonuje się prawidłowo. Podsumowanie ładnie nam prezentuje Jakie zasoby będa tworzone na nowo. Terraform i cloud-init Wykorzystanie cloud-init pozwala w tym momencie zautomatyzować cały proces. Nie muszę oczekiwać na artefakt w postaci adresu IP maszyny wirtualnej i przekazywać ją do ansible. Wszystkie operacje zaplanowane w cloud-init wykonują się samodzielnie. I po kilku minutach użytkownika wraca do zabawy z nowym środowiskiem. Ja skupiam się dalej na prezentacji a rekonfiguracja odbywa się automatycznie. A tak prezentuje się cloud-init Podsumowanie i zakończenie Jak widać konfiguracja w moim przypadku bez użycia ansible jest uzasadniona. I zmniejsza elementy interakcji z mojej strony do absolutnego minimum. Na koniec daj znać co o tym sądzisz i jakie byłoby Twoje podejście. Pozdrawiam

Pracująć z DigitalOcean możemy natknąc sie na problem, że nie uda nam się usunąć naszej sieci. Wpadniemy jak te ryby w morzu i zaplączemy się w sieć. Czy czeka nas tragiczny koniec i wylądujemy na czyimś stole, czy może uda nam się oswobodzić. Postaram się odpowiedzieć na to pytanie w tym artykule. Zapraszam Problem sieciowy w digitalocean Obecnie problem został zaobserwowany tylko w kilku regionach - możliwe że zostanie poprawiony w kolejnych iteracjach API Przyjrzyjmy się zatem naszemu kodowi w terraform: Kod dosyć prosty. Tworzy nam Sieć VPC , w tej sieci maszynę wirtualną DROPLET a maszynę wirtualną podpina do projektu PROJECT . Tak uruchomiony kod za pomocą terraform przy próbie usunięcia sieci spowoduje następujący błąd: Error: Error deleting VPC: DELETE https://api.digitalocean.com/v2/vpcs/bc1352ae-cac2-4b41-8cdd-965e3e2b55c7: 409 (request "3b534f2d-4f61-4e0b-a98f-dc282e9b7518") Can not delete VPC with members Jak ponowimy próbę usunięcia zobaczymy, że zostaje tylko sieć. Spróbujmy zatem rozwiązać problem dodając null_resorce do naszego kodu. A cały kod przedstawia się następująco: Użycie null_resorces i reguł depends_on ustawiamy nasz nowy zasób pomiędzy vpc a droplet. Można to zaobserwować generując graph. Spowoduje to, że między zakończeniem usuwania droplet a rozpoczęciem usuwania vpc będzie 4 sekundowa przestrzeń. Oczywiście można to rozbudować i dodać do modułu lub wykorzystać z modułem. Z czasem też możemy eksperymentować. Wydaje mi się że 4 sekundy jest optymalne. Więcej o dobrych praktykach czy sztuczkach związanych z terraform poczytasz w tym repozytorium

Hej w tym artykule spojrzymy na darmowe środowisko do automatyzacji dla terraforma jakim jest Terraform Cloud. Spojrzymy jak połączyć go w repozytorium git (użyję github, choć współpracuje jeszcze z bitbucket, gitlab i azure devops). Zatem zaczynamy. Założenie konta w Terraform Cloud. Zakładamy konta na stronie logowania do naszego Terraform Cloud . Konto jest darmowe i możemy na nim uruchomić do 500 zasobów w naszym stanie. Teoretycznie jeden blok to jeden zasób w naszym stanie oczywiście pamiętajmy o count i for_each, które zwielokrotniają nam bloki. Dla mini naszego labu w zupełności wystarczy. Terraform Cloud - konfiguracja konta. Po założeniu konta i pierwszym zalogowaniu będziemy proszeni o potwierdzenie adresu email na który założyliśmy konto. Po pomyślnym potwierdzeniu możemy zacząć pracę z naszym terraform cloud i utworzyć pierwszą organizacje w Terraform Cloud. Klikamy niebieski przycisk i przystępujemy do nadania nazwy dla naszej organizacji w Terraform Cloud. To tu będziemy trzymać nasze wszystkie projekty i workspace. Możemy podejść że nazwa to nazwa naszego domowego środowiska labowego lub nazwa firmy, lub jej jednostka organizacyjna. Nazwa organizacji jest unikatowa, dlatego nazwa typu test nie przejdzie ponieważ jest już zajęta. Dlatego ustawiamy coś pasującego do nas. A jak nazwa jest już zajęte to dodajemy jakiś prefix. Adres email uzupełni się na bazie tego co podaliśmy zakładając konto. Po stworzeniu organizacji będziemy mogli określić typ naszego workspace mamy trzy opcje do wyboru (my w tym artykule skupimy sie na jednej, inne omówimy w kolejnych publikacjach). My wybierzemy Version Control Workflow, ale mamy jeszcze: CLI-Driven Workflow - to rozwiązanie jest dobre kiedy chcemy polaczyć nasze Terraform Cloud z Terraform CLI. API-Driven Workflow - to rozwiązanie jest dobre gdy naszym terraform zarządzamy np z github action, jenkins itp. Nasz wybór daje nam najlepsze rozwiązanie dla osób które chcą szybko zacząc z Terraform Cloud i mieć jednocześnie mini środowisko do automatyzacji. Zatem wybieramy Version Control Workflow. Konfiguracja VCS w Terraform Cloud VCS to nasz Version Control System, w terraform cloud możemy zintegrowac go z GitHub, Bitbucket, GitLab, Azure DevOps - wybieramy swój ulubiony i konfigurujemy integrację. Jak wybrałem github. Oczywiście wcześniej musimy mieć repozytorium założone. Repozytorium może być prywatne lub publiczne z punktu widzenia terraform cloud nie ma to znaczenia. Mając nasze repo możemy zrobić integracje z naszym github. Klikamy odpowiedni przycisk z ikoną github i z listy wybieramy nasza instalacje github (ja wybrałem github.com ). Wyskoczy nam popup z akceptacją instalacji integracji z GitHub. Ustawiamy tu dostęp do wszystkich repozytoriów lub tylko wybranych. Po kliknięciu przycisku install mamy połączone nasze Terraform Cloud z GitHub. Co możemy zaobserwować w naszym interfejsie Terraform Cloud po tym że przeskoczyliśmy na krok numer 2 W oknie Choose a repository będzie lista dostępnych naszych repozytoriów do których możemy się podłączyć i połączyć je z naszym tworzonym workspace. Wybieramy i podświetlany je na fioletowo. Po kliknięciu przechodzimy już do trzeciego okna i nadajemy nazwę dla naszego workspace. Domyślnie przyjmie on nazwę naszego repozytorium. Możemy to zostawić lub zmienić jego nazwę. Ustawiamy nazwę i description tak by najlepiej opisywał nasz workspace. Rozwijamy opcje Advanced i ustawiamy nasza konfigurację Branch-based, VSC branch na main, Automatic Run triggering na Always trigger runs i Pull Request na Automatic speculative plans. Inne opcje na razie nie zaznaczam, omówimy je innym razem. Klikamy Create. Terraform Cloud set variables i start new plan Mamy nasz workspace stworzony. Teraz Terraform Cloud poprosi nas o ustawienie zmiennych lub jak będa one podane w kodzie to zostaną zaciągnięte. Je podłączyłem puste repozytorium dlatego nie mam jeszcze zmiennych terraform i mogę kliknąć Go to workspace overview - zmienne dodamy później. Wszystko co do tej pory zrobiliśmy przedstawia ten film z youtube: Terraform Cloud - dodajmy nasz kod do repozytorium. Repozytorium które używam w tym materiale jest dostępne pod tym adresem: https://github.com/TheRealMamuth/szkolenia_cloud_terraform_cloud Wspomniałem o konfiguracji naszych zmiennych - klikamy Configuration Variables i dodajemy nasze zmienne - nazwy takie same jak w pliku variables.tf Zapisujemy zmienne. Po dodaniu naszego kodu - pozostaje tylko uruchomienie naszego kodu, konfiguracji z poziomu UI naszego Terraform Cloud. W kolejnym materiale omówimy sobie automatyzacje oraz bardziej zaawansowane konfiguracje w Terraform Cloud. Zapraszam

W tym artykule odpowiem na pytania, które się pojawiły podczas warsztatów proxmox. Pytania zostały zapisane w formie tekstowej - uczestnicy warsztatów mieli miejsce gdzie mogli zadawać pytania. Zatem nie przeciągając oto te pytania i odpowiedzi. Wasze pytanie, moje odpowiedzi Pytanie nr 1: Rozproszyłem się na Sniepetach, są gdzieś dostępne skrypty których używałeś omawiając ten temat? Odpowiedź: Tak, skrypty użyte w warsztatach dostępne są na repozytorium git w bitbucket możesz sklonować lub użyć fork dla tego repozytorium. Jeżeli chodzi o Snippet dla Proxmox to po pierwsze w domyślnej konfiguracji musisz dla danego storage właczyć ta opcje ona domyślnie nie jest włączona. Zatem dla demonfs będzie to w /mnt/pve/demonfs/snippets a dla local-lvm bedzie to /var/lib/vz/snippets/ Pytanie nr 2: Upgrade wersji z pve 7 do 8 z Ceph , na co zwracać uwagę, jak się zabezpieczyć przed ewentualnych fckupem Odpowiedź: Upgrade w proxmox nigdy nie był prostym tematem. Podrzucam link do oficjalnej dokumentacji proxmox już na początku by o nim nie zapomnieć. Sam proxmox w swojej dokumentacji mówi o dwóch sposobach aktualizacji. Sposób pierwszy Sposób najdroższy w moim odczuciu ponieważ wymaga od nas bliźniaczej konfiguracji - tzn aktualizacji robimy po prostu instalująć nowsza wersję w tej samej konfiguracji i przenosimy dane na nowa instancje klastrową. Lub Tworzymy backup i na hoscie gdzie mieliśmy stara wersje instalujemy nową. Pamietajmy o backup! proxmox w swojej dokumentacji fajnie to opisuje co należy skopiować. Przedstawione są też kroki tej operacji Wykonaj kopię zapasową wszystkich maszyn wirtualnych (VM) i kontenerów na zewnętrzne urządzenie magazynujące (zobacz Kopia zapasowa i przywracanie). Wykonaj kopię zapasową wszystkich plików w katalogu /etc. Wymagane: pliki w /etc/pve, a także /etc/passwd, /etc/network/interfaces, /etc/resolv.conf oraz wszystko, co odbiega od domyślnej instalacji. Zainstaluj najnowszą wersję Proxmox VE 8.x z pliku ISO (spowoduje to usunięcie wszystkich danych na istniejącym hoście). Wyczyść pamięć podręczną przeglądarki i/lub wymuś ponowne załadowanie (CTRL + SHIFT + R, lub dla macOS ⌘ + Alt + R) interfejsu Web UI. Odtwórz klaster, jeśli dotyczy. Przywróć plik /etc/pve/storage.cfg (spowoduje to udostępnienie zewnętrznego magazynu używanego do kopii zapasowej). Przywróć konfigurację zapory sieciowej z /etc/pve/firewall/ oraz /etc/pve/nodes//host.fw (jeśli dotyczy). Przywróć wszystkie maszyny wirtualne z kopii zapasowych (zobacz Kopia zapasowa i przywracanie). Administratorzy zaznajomieni z wierszem poleceń mogą postępować zgodnie z procedurą Pomijanie kopii zapasowej i przywracania przy aktualizacji, jeśli wszystkie maszyny wirtualne i kontenery znajdują się na jednym wspólnym magazynie. Musimy pamiętać, że to nie jest proces szablonowy i trzeba indywidualnie podchodzić do każdego przypadku przygotowywując sobie checklistę, sprawdzając podwójnie wszystkie elementy. Sposób drugi Aktualizacja przez pakiety - z wykorzystaniem apt. Tutaj też należy pamiętać o backup. Pamiętajmy też by nasza obecna wersje podnieść do jak najnowszej w ramach danej wersji. Czyli jak mamy wersje 7 aktualizujemy ja do wersji 7 latest. Jak mamy na klastrze Ceph to zajrzyjmy do dokumentacji jaka wersja będzie wymagana przed aktualizacją i czy mamy ja podbić przed czy po aktualizacji. Wszystko ładnie jest opisane w danym procesie aktualizacji między wersjami Wady i zalety. Jeden i drugi sposób ma swoje wady i zalety. Elementem wspólnym jest backup w jednym jak i w drugim przypadku powinien być wykonany i przetestowany przed aktualizacją. Wady pierwszego rozwiązania to w przypadku gdy instalujemy wersję 8 na wersji 7 to tracimy dane i mamy je tylko w backup. Posiadanie dwóch redundantnych konfiguracji jest drogim rozwiązaniem i jeszcze stwarza problem sieci. - dla drugiego osobnego klastra trzeb stworzyć nowa sieć i uważać na overlap adresów sieciowych. I najważniejsze niestety nie ma magicznej różdżki czy skryptu który to za nas załatwi - musimy do tego przysiąść i sobie to rozpisać. Pytanie nr 3: czy bardzo niezalecane jest korzystanie z klastra tylko w konfiguracji dwóch hostów ? Odpowiedź: Korzystanie z klastra Proxmox w konfiguracji z tylko dwoma hostami jest ogólnie niezalecane , głównie ze względu na problemy z kworum, które mogą wpłynąć na stabilność i dostępność usług. Dlaczego kworum jest ważne? Kworum  to mechanizm, który zapewnia spójność danych w klastrze przez wymaganie większości dostępnych węzłów do podejmowania decyzji. W klastrze z dwoma węzłami większość wynosi 2, co oznacza, że jeśli jeden węzeł ulegnie awarii, klaster traci kworum i przestaje działać prawidłowo. W konfiguracji wysokiej dostępności (HA) w klastrze Proxmox liczba hostów powinna być nieparzysta (3, 5, 7 itd.), aby zapewnić prawidłowe działanie mechanizmu kworum i uniknąć problemów z dostępnością. Oto dlaczego taka liczba hostów jest zalecana: Zapewnienie kworum: Klaster HA wymaga kworum, aby podejmować decyzje dotyczące stanu klastra. Kworum oznacza, że większość hostów musi być dostępna, aby klaster mógł działać. Przy liczbie hostów 3, 5, 7 itd., zawsze można osiągnąć większość głosów nawet po utracie jednego lub kilku węzłów. Na przykład: W klastrze 3-hostowym kworum wynosi 2. Oznacza to, że klaster może dalej działać, gdy jeden host jest niedostępny. W klastrze 5-hostowym kworum wynosi 3, co pozwala na awarię dwóch hostów. W klastrze 7-hostowym kworum wynosi 4, umożliwiając utratę do trzech hostów. Unikanie sytuacji split-brain: W przypadku parzystej liczby hostów istnieje ryzyko sytuacji split-brain, gdzie część hostów uważa się za oddzielne klastry, co może prowadzić do konfliktów i utraty danych. Użycie nieparzystej liczby węzłów minimalizuje to ryzyko, ponieważ zawsze jest możliwe osiągnięcie większości głosów. Lepsze rozłożenie zasobów i odporność na awarie: Większa liczba hostów w konfiguracji nieparzystej pozwala na lepsze rozłożenie obciążenia i zapewnia większą odporność na awarie. Im więcej węzłów, tym klaster jest bardziej odporny na utratę poszczególnych hostów, co zwiększa dostępność usług. Skalowalność i przyszłe rozszerzenia: Rozbudowa klastra w sposób skalowalny jest łatwiejsza, gdy dodaje się nieparzyste liczby hostów (np. z 3 do 5, z 5 do 7), co zachowuje odpowiednią konfigurację kworum. Problemy z klastrem dwuwęzłowym: Brak tolerancji na awarie : Awaria jednego węzła powoduje utratę kworum i potencjalne zatrzymanie usług. Split-brain : W przypadku problemów z siecią oba węzły mogą działać niezależnie, prowadząc do niespójności danych. Ograniczone możliwości HA : Funkcje wysokiej dostępności (HA) są ograniczone lub wymagają dodatkowej konfiguracji. Możliwe rozwiązania: Dodanie trzeciego węzła : Nawet jeśli jest to mały serwer lub urządzenie pełniące rolę tylko głosu w kworum. Użycie qdevice (Quorum Device) : Dodatkowy serwer lub usługa, która pomaga w osiągnięciu kworum w klastrze dwuwęzłowym. Konfiguracja tie-breaker : Specjalne ustawienia, które pomagają w rozwiązywaniu konfliktów kworum, ale mogą być skomplikowane i nie zawsze niezawodne. Rekomendacje: Najlepsza praktyka : Użycie co najmniej trzech węzłów w klastrze Proxmox dla zapewnienia stabilności i pełnej funkcjonalności. Jeśli musisz użyć dwóch węzłów : Dokładnie przemyśl i skonfiguruj mechanizmy dodatkowe (np. qdevice) oraz przygotuj się na potencjalne komplikacje. Podsumowanie: Korzystanie z klastra dwu węzłowego w Proxmox nie jest zalecane ze względu na ryzyko utraty kworum i związane z tym problemy. Jeśli zależy Ci na stabilności i wysokiej dostępności, warto zainwestować w trzeci węzeł. Oczywiście w środowisku domowym mozna to zrobić na dwóch węzłach z Quorum Device. W środowiskach produkcyjnych moim zdaniem jest to mega cebula, bo często osoby decyzyjne nie rozumieją tego mechanizmu i nie wiedzą że Quorum Device nie zapewnia nam hosta na, którym uruchomimy maszyny wirtualne a jedynie hosta do decyzji w przypadku gdy mamy 2 hosty. I decydują w takim przypadku na podstawie ceny (2 nody są tansze od 3 nodów). Dlatego uważam że w środowisku produkcyjnym powinno być to jawnie omówione wpisane w draft lub plan implementacji i podpisane przez osobe decyzyjna z zaznaczeniem że rozumie wszelkie konsekwencje zastosowanego rozwiązania. Pytanie nr4: Jakie są podstawowe wymagania odnośnie postawienia Windows na proxmoxie? Ile najlepiej ramu wypadałoby mieć, bo słyszałem, że Windows jest pamięciożerny. Im więcej tym lepiej, ale odpowiedź nie jest taka prosta. Zależy głownie od tego co będziesz robił na tym windows. Ja osobiście wykorzystywałem maszynę wirtualną na proxmox z windows do świadczenia jej jako agent w Team City do budowania i kompilowania bibliotek i kodu dla naszych aplikacji (w firmie w której pracowałem). Pod spodem mieliśmy dyski NVMe (w proxmox) dla maszyny wirtualnej udostępnione przez virtio ze wskazaniem na dysk NVMe, Ramu miał 12 GB, Grafika domyślna - nie była potrzebna. CPU 1 Socket, 8 Core. I działało świetnie. A i w ustawieniach vm był w trybie host. Pytanie nr 5: Jak najlepiej robić backup wszystkich wirtualnych maszyn? Nawet jak sporo ważą to można to przenieść na dysk podpięty na sata a nie nvme? Backup można wykonywać na NFS, SMB, CIFS, local storage itp - i tak można podpiąc dysk dodatkowy na stałe lub przez USB i tam robić backup. Jednak lepszym rozwiązaniem jest wydaje mis ie cloud storage zgodny z s3 i tam wysyłanie synchronizowanie backupu. Pytanie nr 6: Czy postawienie proxmox na zewnątrz portami idzie dobrze zabezpieczyć pod kontem włamania? Zależy mi na ustawieniu proxmoxa na zewnątrz i mógłbym sterować wszystkimi maszynkami nie będąc w domu, zastanawiałem się nad vpn wireguard, ale jakie duże ryzyko wiąże się z takim rozwiązaniem? Tak można dobrze zabezpieczyć interfejs GUI proxmoxa. Najprostsza metoda to firewall przed z filtracja adresów IP. Ja bym w tym przypadku użył rozwiązania Nord VPN z dedykowanym adresem IP. Wtedy ten adres dodajesz do firewall proxmox i po sprawie. Dedykowany adres IP jest przypisywany tylko do Ciebie. Fajne rozwiązanie. Pytanie nr 7: a ja mam pytanie apropo przygotowywania tego demo-środowiska tworząc proxmoxy (poszczególne node) utworzyłeś jeden obraz, przeklikałem instalacje -> zrobiłeś template i rozrzuciłem terraformem z gotowego obrazu? czy jakas inna metoda? Odpowiedź jest prosta i banalna - autoinstaller od proxmox on to wspiera sam w sobie. Omawiam też to w moim ostatnim wpisie . W skrócie tworzymy answer plik z konfiguracją i dodajemy go do naszego instalatora. Pytanie nr 8: Czy zwiększanie ilości nodów poprawia wydajność dużo bardziej niż dokładanie OSD do istniejących nodów? OSD w CEPH uruchamia się na fizycznych dyskach wtedy ma się najlepszy performance. Czyli lepiej dodac nowy fizyczny dysk i na nim utworzyć kolejny OSD. Nie ma potrzeby dodawania nowych węzłów. Pytanie nr 9: Jeśli chodzi o FC, jaka jest możliwość podłączenia macierzy SAN do Proxmox Możliwość podłączenia jest: Sprawdzenie kompatybilności sprzętu: Upewnij się, że serwer Proxmox jest wyposażony w odpowiednie karty HBA (Host Bus Adapter) Fibre Channel, które są kompatybilne z Twoją macierzą SAN. Sprawdź, czy sterowniki dla kart HBA są poprawnie zainstalowane w systemie. Połączenie fizyczne: Podłącz kable Fibre Channel od kart HBA w serwerze Proxmox do przełącznika FC lub bezpośrednio do macierzy SAN (w zależności od topologii sieci). Pytanie nr 10: Jeśli na VM proxmox zabraknie RAM, to VM się zawiesza, jest szansa w jakiś sposób się do niej dostać, czy tylko siłowe ubicie? Może próbować opcji KVM shared memory? Aby włączyć “Kernel Same-page Merging” (KSM) dla maszyn wirtualnych w Proxmox, musisz skonfigurować odpowiednie parametry na poziomie systemu operacyjnego hosta oraz w ustawieniach maszyn wirtualnych. KSM pozwala na dzielenie wspólnej pamięci pomiędzy maszynami wirtualnymi, co może prowadzić do oszczędności pamięci RAM. Oto kroki, które należy wykonać: Włącz KSM na hoście Proxmox: Sprawdź, czy KSM jest już włączony: cat /sys/kernel/mm/ksm/run Jeśli wynik to 0, KSM jest wyłączony. Aby włączyć KSM, wykonaj: echo 1 > /sys/kernel/mm/ksm/run Opcjonalnie, możesz dostosować parametry, takie jak liczba stron do skanowania na cykl (pages_to_scan) lub interwał między cyklami skanowania (sleep_millisecs): echo 1000 > /sys/kernel/mm/ksm/pages_to_scan echo 200 > /sys/kernel/mm/ksm/sleep_millisecs Skonfiguruj maszynę wirtualną do używania KSM: Otwórz plik konfiguracyjny maszyny wirtualnej, który znajduje się w /etc/pve/qemu-server/VMID.conf, gdzie VMID to identyfikator maszyny wirtualnej. Dodaj lub zmodyfikuj linię: balloon: 1 Opcja ta włącza “Memory Ballooning”, co jest zalecane przy używaniu KSM. Automatyzacja dla grupy lub puli maszyn: Jeśli chcesz włączyć KSM dla wszystkich maszyn wirtualnych w danej grupie lub puli, możesz użyć skryptu Bash do automatycznego modyfikowania konfiguracji. Przykładowy skrypt: for VMID in $(pvesh get /cluster/resources --type vm | jq -r '.[] | select(.pool == "nazwa_puli") | .vmid'); do     qm set $VMID --balloon 1 done Ten skrypt ustawia “Memory Ballooning” dla wszystkich maszyn wirtualnych w określonej puli. Restart maszyn wirtualnych: Aby zmiany zaczęły działać, konieczne może być zrestartowanie maszyn wirtualnych. Po tych krokach KSM będzie działał dla wybranych maszyn wirtualnych, co pozwoli na lepsze wykorzystanie pamięci RAM. Pytanie nr 11: W małym biznesie jest zazwyczaj kilka-kilkanaście VM, jakś płatnik, comarch, często muszą działać 24h. Na lokalnych dyskach SSD działa to znośnie. Jaką konfigurację byś zalecił przy przejściu na Ceph aby stworzyć prawdziwe HA? Proszę nie pisz "to zależy" :) Ceph w zwirtualizowanym labie działa dość topornie, jak by było w rzeczywistości? 3 nody? 5 nodów? W każdym nodzie kilka nvme? (ile min?) Baza ceph koniecznie na osobnych dyskach? Sieć pomiędzy nodami 10Gb wydaje się wystarczająca, ale może lepiej 25Gb? W labie na którym pracowaliśmy działało to topornie dlatego że to było środowisko testowe do zabawy. Po drugie mieliśmy zagnieżdżoną wirtualizację. Udostępniony dla Ciebie lab w postaci serwera z Ubuntu już był maszyna wirtualną, na niej dopiero uruchomiliśmy proxmoxa a potem tam uruchomiliśmy maszynę wirtualną. Czyli mieliśmy tak naprawdę 3 zagnieżdżenie (tzw nesting virtualization). Dyski które tworzyliśmy też były zwirtualizowane nie były to fizyczne dyski tylko pliki. CEPH już napisałem to wcześniej najlepiej działa na fizycznych dyskach. Działa na HDD, SSD, NVMe - no i tutaj ograniczać cię już będzie interfejs. Jak wybierzesz HDD to Ceph będzie wolniejszy niż w przypadku NVMe. Ceph Storage można sprawdzić i porównać zapis fio na storage sieciowym i dedykowanym dysku. I tu im szybsza sieć tym lepiej. Musisz sprawdzić czy dyski użyte w twojej konfiguracji wykorzystają w pełni łącze. No i też należy pamiętać o przyszłej rozbudowanie czy ją planujesz. Zwiększanie liczby nodów w klastrze Ceph ma znaczący wpływ na wydajność i niezawodność systemu. Oto kilka kluczowych punktów, które warto wziąć pod uwagę: Redundancja i odporność na awarie : Zwiększenie liczby nodów zwiększa odporność klastra na awarie. Ceph rozkłada dane na różne nody, tworząc kopie (replikacje) danych. Przy większej liczbie nodów, klaster może lepiej zarządzać redundancją, co zmniejsza ryzyko utraty danych w przypadku awarii jednego z nodów. Balansowanie obciążenia : Większa liczba nodów oznacza więcej zasobów (CPU, RAM, sieć) do dyspozycji klastra. Dzięki temu Ceph może lepiej balansować obciążenie, zwłaszcza jeśli chodzi o I/O. Zwiększenie liczby nodów rozkłada operacje zapisu i odczytu na więcej dysków (OSD), co może przyspieszyć operacje w systemie. Skalowalność wydajności I/O : Ceph jest skalowalnym systemem, co oznacza, że zwiększanie liczby nodów i OSD (Object Storage Daemons) może bezpośrednio wpłynąć na zwiększenie wydajności operacji I/O. W scenariuszu z pięcioma nodami, gdzie każdy z nich posiada po jednym OSD na dysku 300 GB, system będzie miał więcej możliwości równoległego przetwarzania operacji w porównaniu do trzech nodów. Może to poprawić przepustowość (bandwidth) oraz zmniejszyć opóźnienia (latency). Efektywność przy dużej ilości danych : Przy większej liczbie nodów Ceph lepiej radzi sobie z dużą ilością danych, ponieważ dane są przechowywane i rozpraszane na większej liczbie urządzeń, co przyspiesza operacje odczytu i zapisu. Wiec jak widac to zależy od konfiguracji - więcej nie znaczy zawsze lepiej musimy pamiętać że w przypadku CEPH to zestaw naczyń połączonych i zwiększanie jednego parametru wpływa na inne parametry. Pytanie nr 12: Czasami VM od strony GUI Proxmox się tak zawiesza, że nie wiadomo czy w ogóle umarła czy może jest do odratowania. Konsola nie działa. Jest szansa w jakiś sposób się do niej dostać, czy tylko siłowe ubicie? Może próbować opcji KVM shared memory? KSM to nie jest idealne rozwiazanie. Pytanie czy zawieszanie jest spowodowane tym że uruchamiasz za dużo maszyn wirtualnych czy po stronie kodu działającego na maszynie wirtualnej. Można też spróbować ustawić połączenie do maszyny wirtualnej z poziomu tty portu szeregowego. Funkcja, której szukasz, to “Serial Console” w KVM (konsola szeregowa). Umożliwia ona połączenie się z maszyną wirtualną poprzez interfejs konsolowy za pomocą narzędzia virsh. Oto kroki, jak to skonfigurować: Skonfiguruj maszynę wirtualną do używania konsoli szeregowej: Musisz edytować plik XML definicji maszyny wirtualnej, aby dodać interfejs konsoli szeregowej. Możesz to zrobić, używając polecenia: virsh edit nazwa_maszyny W pliku XML dodaj następujący wpis w sekcji :     Skonfiguruj system operacyjny maszyny wirtualnej: Na maszynie wirtualnej musisz skonfigurować system operacyjny, aby umożliwił logowanie przez konsolę szeregową. W systemach Linux wykonaj następujące kroki: Edytuj plik /etc/default/grub i dodaj parametr dla kernela: GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0" Zaktualizuj konfigurację GRUB: sudo update-grub Skonfiguruj getty, aby nasłuchiwał na porcie szeregowym. Dodaj lub odkomentuj linię w pliku /etc/inittab lub utwórz plik /etc/systemd/system/serial-getty@ttyS0.service.d/override.conf: [Service] ExecStart= ExecStart=-/sbin/agetty --keep-baud 115200,9600 ttyS0 $TERM Połącz się z maszyną wirtualną przez virsh: Po skonfigurowaniu możesz połączyć się z konsolą szeregową używając polecenia: virsh console nazwa_maszyny W Proxmox VE, konfiguracja dostępu do konsoli szeregowej dla maszyny wirtualnej jest podobna, ale proces jest nieco uproszczony, ponieważ interfejs graficzny Proxmox ułatwia konfigurację. Oto kroki, jak skonfigurować konsolę szeregową w Proxmox: Skonfiguruj konsolę szeregową w ustawieniach maszyny wirtualnej: W interfejsie Proxmox VE, wybierz maszynę wirtualną, którą chcesz skonfigurować. Przejdź do zakładki Hardware , a następnie kliknij Add  -> Serial Port . Dodaj port szeregowy (serial0) do maszyny wirtualnej. Skonfiguruj system operacyjny maszyny wirtualnej: Jeśli maszyna wirtualna korzysta z systemu Linux, skonfiguruj ją tak, aby umożliwić logowanie przez konsolę szeregową: Edytuj plik /etc/default/grub i dodaj parametr dla kernela, np.: GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0" Zaktualizuj konfigurację GRUB: sudo update-grub Skonfiguruj getty, aby nasłuchiwał na porcie szeregowym, np. edytując lub tworząc plik /etc/systemd/system/serial-getty@ttyS0.service.d/override.conf: [Service] ExecStart= ExecStart=-/sbin/agetty --keep-baud 115200,9600 ttyS0 $TERM Połącz się z konsolą szeregową: W interfejsie webowym Proxmox VE, przejdź do zakładki Console  dla wybranej maszyny wirtualnej. Wybierz opcję Serial Terminal  z menu rozwijanego. Zostanie wyświetlona konsola szeregowa dla maszyny wirtualnej. Dzięki temu możesz uzyskać dostęp do maszyny wirtualnej przez konsolę szeregową, co jest przydatne do diagnostyki lub pracy z systemami bez interfejsu graficznego. Pytanie nr 13: Czy drbd będzie wyraźnie lepszy od ceph zakładając małą ilość OSD? W przypadku małej liczby OSD, DRBD może być lepszym wyborem niż Ceph, w zależności od specyficznych wymagań. Oto kilka kluczowych czynników do rozważenia: Replikacja danych : DRBD to rozwiązanie do replikacji blokowej, które synchronizuje dane między dwoma lub więcej węzłami w trybie aktywny-aktywny lub aktywny-pasywny. Jest bardziej wydajne przy mniejszych konfiguracjach, ponieważ wymaga mniej zasobów niż Ceph i lepiej radzi sobie z małą ilością węzłów. Ceph, z drugiej strony, jest rozproszonym systemem pamięci masowej, który osiąga większą wydajność przy większej liczbie OSD i węzłów. Skalowalność : Ceph jest projektowany z myślą o skalowalności i lepiej sprawdza się w środowiskach z większą liczbą OSD. Przy małej liczbie OSD Ceph może mieć niższą wydajność i wyższą latencję, ponieważ jego architektura rozproszona wymaga więcej metadanych i operacji kontrolnych. Zarządzanie : DRBD jest prostsze do wdrożenia i zarządzania w małych środowiskach, szczególnie tam, gdzie liczba węzłów jest ograniczona. Ceph wymaga bardziej zaawansowanej konfiguracji i monitorowania, nawet w małych środowiskach. Redundancja i dostępność : DRBD jest idealne do wysokiej dostępności w małych środowiskach, gdyż replikacja synchroniczna pozwala na szybkie przełączanie awaryjne. Ceph natomiast oferuje bardziej zaawansowane opcje odporności na awarie, takie jak erasure coding i wielopoziomowe replikowanie, które stają się bardziej efektywne przy większej liczbie OSD. Wybór między Ceph a DRBD zależy od specyfiki środowiska, wymagań dotyczących skalowalności, wydajności, redundancji, oraz zadań, jakie chcesz realizować. Oto porównanie obu rozwiązań pod kątem różnych czynników: Skalowalność Ceph : Jest zaprojektowany z myślą o dużych, skalowalnych środowiskach. Można łatwo dodawać nowe węzły i zwiększać pojemność, co sprawia, że Ceph jest idealny dla dużych infrastruktur chmurowych i centrów danych. DRBD : Lepszy w małych środowiskach lub klastrach wysokiej dostępności (HA), gdzie liczba węzłów jest ograniczona (najczęściej 2-3). Skalowanie poza małą liczbę węzłów może być trudne i mniej efektywne. Replikacja danych Ceph : Replikuje dane w sposób rozproszony na wielu węzłach, oferując wysoką dostępność i odporność na awarie. Jest w stanie automatycznie rozproszyć dane na różnych poziomach, oferując opcje replikacji i kodowania wymazywalnego (erasure coding). DRBD : Oferuje replikację synchroniczną na poziomie blokowym pomiędzy dwoma lub więcej węzłami. Replikacja jest ściśle związana z warstwą blokową, co sprawia, że jest bardziej ograniczona niż w przypadku Ceph, który ma bardziej rozbudowane mechanizmy dystrybucji danych. Wydajność Ceph : Przy większej liczbie węzłów może zapewnić wysoką wydajność dzięki rozproszonemu modelowi zapisu i odczytu. Jednak w małych konfiguracjach (2-3 węzły) może mieć większą latencję i niższą wydajność niż DRBD. DRBD : Zapewnia niską latencję i wysoką wydajność w mniejszych środowiskach, zwłaszcza przy synchronicznej replikacji. Jest lepszym wyborem, gdy priorytetem jest szybki zapis/odczyt w małym klastrze. Zarządzanie i konfiguracja Ceph : Wymaga bardziej zaawansowanej konfiguracji i jest trudniejszy w zarządzaniu, szczególnie dla mniejszych zespołów IT. Ceph jest jednak bardzo elastyczny i może oferować różne rodzaje pamięci masowej (blokową, plikową, obiektową). DRBD : Jest prostszy w konfiguracji i zarządzaniu, co sprawia, że jest łatwiejszy do wdrożenia w małych klastrach lub jako rozwiązanie do replikacji danych. Odporność na awarie Ceph : Jest bardzo odporny na awarie dzięki swojej rozproszonej architekturze. Węzły mogą się awaryjnie wyłączać, a Ceph będzie w stanie automatycznie przenosić dane i odtwarzać replikacje, aby zapewnić dostępność danych. DRBD : Oferuje wysoką dostępność na poziomie blokowym i szybkie przełączanie awaryjne (failover), ale w przypadku większych awarii wymaga ręcznego odzyskiwania danych lub przełączania. Pytanie nr 14: Ceph Monitor, po logrotate wywala błąd braku miejsca na dysku mimo dostępnej przestrzeni i trzeba go restartować, jak sobie z tym poradzić na produkcji Pytanie co wrzuca komunikat ceph monitor czy logrotate jak logrotate to moze to jest problem w samym logroate. Pytanie jak jest uruchomione natywna aplikacja czy w kontenerze? To jest dużo niewiadomych. Dlatego proszę autora o przykłady i szersze opisanie problemu - może to zrobić w sekcji komentarzy pod tym artykułem. Pytanie nr 15: Czy da sie ustawic jakis dedykowany IP klastra aby miec dostęp do GUI tylko z dedykowanego? Tak da się - możemy wystawić nasz interface GUI bezpośrednio na publicznym IP lub przez port jakiś. I w ustawieniach firewall zezwolić na komunikację z konkretnym adresem. Pytanie nr 16: Jak najlepiej zautomatyzować cały proces tworzenia klastra. Kilka dni temu przyjechał mi sprzet na ktorym chce zainstalowac wlasnie klaster proxmoxowy. Założenie jest takie ze wszystko ma byc oskryptowane, 0 klikania Auto installer, ansible, terraform, bash, cloud-init tych technologi bym użył. W kolejnej edycji labów będę to poruszał więc zapraszam do obserwowania. Pojawi się to też w moim kursie proxmox (video) i dedykowanym szkoleniu online i stacjonarnym . Pytanie nr 17: Mamy w firmie repo NFS z ISO, ale ten Repo jest read-only Proxmox nie chce go podpiac bo nie moze w nim pisac. Jest jakies obejscie? Tak, można obejść problem podłączenia repozytorium NFS jako read-only w Proxmox, stosując poniższe rozwiązania: Podłączenie jako lokalny katalog : Możesz zamontować repozytorium NFS na serwerze Proxmox jako lokalny katalog w systemie operacyjnym hosta. Montowanie można zrobić przez dodanie wpisu do /etc/fstab, np.: nfs_server:/ścieżka/do/iso /mnt/nfs/iso nfs ro 0 0 Następnie w Proxmox dodajesz katalog /mnt/nfs/iso jako zasób “Directory”. W konfiguracji zasobu wybierasz typ “ISO image”, co umożliwi dostęp do obrazów ISO w trybie read-only. Podłączenie NFS z flagą no_root_squash: Jeśli masz kontrolę nad serwerem NFS, możesz skonfigurować eksport tak, aby wyłączyć root_squash, co może rozwiązać problem dostępu do repozytorium. W pliku /etc/exports na serwerze NFS dodaj opcję no_root_squash dla danego eksportu: /ścieżka/do/iso *(ro,sync,no_root_squash) Po modyfikacji konfiguracji zrestartuj usługę NFS na serwerze. Utworzenie lokalnej kopii ISO : Alternatywnie, jeśli obrazy ISO nie są często zmieniane, można je skopiować lokalnie na serwer Proxmox i używać z lokalnej przestrzeni dyskowej. Skrypty synchronizujące mogą być używane do regularnego aktualizowania kopii lokalnej. Symboliczne linki : Możesz też utworzyć symboliczne linki w lokalnym katalogu Proxmox, które wskazują na pliki ISO na montowanym repozytorium NFS. Któraś z tych metod powinna pozwolić na podłączenie repozytorium ISO w Proxmox mimo ograniczeń read-only. Pytanie 18: Tworząc VM lepiej dawać np. 4 CPU i 1 Core czy 1 CPU i 4 Core? Jaka jest różnica? Różnica między przypisaniem zasobów wirtualnych maszyn (VM) jako 4 CPU i 1 Core a 1 CPU i 4 Core polega na sposobie, w jaki system operacyjny i hypervisor zarządzają tymi zasobami. Oto główne różnice: 4 CPU i 1 Core : Oznacza to, że maszyna wirtualna otrzymuje 4 procesory fizyczne (vCPU), z których każdy ma tylko jeden rdzeń. Taka konfiguracja może być przydatna, jeśli maszyna wirtualna uruchamia aplikacje, które lepiej działają przy większej liczbie fizycznych procesorów. Niektóre starsze systemy operacyjne i aplikacje mogą korzystać z wielu procesorów, ale niekoniecznie z wielu rdzeni na jednym procesorze. Może prowadzić do większego narzutu na hypervisorze, ponieważ musi on zarządzać większą liczbą osobnych jednostek procesora. 1 CPU i 4 Core : Oznacza to, że maszyna wirtualna otrzymuje jeden procesor, który ma cztery rdzenie. W większości nowoczesnych systemów operacyjnych i aplikacji, które są zoptymalizowane pod kątem wielowątkowości, taka konfiguracja może być bardziej efektywna. Jest to bardziej naturalna reprezentacja nowoczesnych procesorów fizycznych, gdzie jeden procesor ma wiele rdzeni. Może mieć mniejszy narzut na hypervisorze, co pozwala na bardziej efektywne zarządzanie zasobami. Kiedy wybrać którą konfigurację? Aplikacje wielowątkowe  (np. serwery baz danych, nowoczesne aplikacje serwerowe): Zazwyczaj lepiej wykorzystają konfigurację z mniejszą liczbą CPU i większą liczbą rdzeni (np. 1 CPU i 4 Core). Starsze aplikacje lub systemy operacyjne , które nie są zoptymalizowane do pracy na wielu rdzeniach, mogą lepiej działać przy konfiguracji z większą liczbą CPU (np. 4 CPU i 1 Core). W praktyce warto eksperymentować z różnymi ustawieniami, aby zobaczyć, która konfiguracja działa lepiej dla konkretnego obciążenia w danym środowisku. Podsumowanie Odpowiedź na pytania zamyka nam warsztaty w 100%. Oczywiście to tylko pierwsza część. Zapraszam do obserwowania bo już niebawem warsztaty z proxmox część druga. Dziękuje za uwagę Piotr Kośka

W prezentowanym materiale na moim kanale na temat przygotowania do automatyzacji mojego labu można było zaobserwować, że proces instalacji proxmoxa był automatyczny. Oczywiście było to jak najbardziej pożądane ponieważ przechodzenie przez instalację nawet po prostu klikając dalej... dalej... byłoby dość długim procesem. I co to za atrakcja na warsztatach przechodzić przez instalację systemu proxmox, którą można zrobić w domu i na pewno każdy adept proxmoxa ją przechodził z kilkadziesiąt razy. W przypadku mojej konfiguracji zależało mi na tym by proces był jak najbardziej bezobsługowy. Bynajmniej na początku czyli na etapie instalacji naszego proxmoxa. Dzięki takiemu podejściu mogłem przygotować środowisko labowe dla 200 osób. Gdzie każdy z uczestników miał finalnie przygotowanego proxmoxa. Cały kod dostępny jest na bitbucket w publicznym repozytorium Zacznijmy od początku - wymaganie proxmox Do uruchomienia środowiska labowego z proxmox jest nam potrzebne absolutne minimum: Maszyna fizyczna z procesorem 64 bitowym Maszyna wirtualna z procesorem 64 bitowym Można o tym poczytać w dokumentacji proxmox na temat wymagań sprzętowych - proxmox na innych architekturach nie działa. Inne parametry to kwestia wygody pracy czy dostępności domowego portfela. Oczywiście rozmawiamy tutaj o środowisku do zabawy w domowym zaciszu a nie pełnoprawnym produkcyjnym rozwiązaniu. I tu jest nasz pierwszy problem. Jak dostarczyć każdemu takie samo środowisko by mieć pewność że będzie działać one tak samo dla każdego z 200 słuchaczy i uczestników prezentowanych warsztatów. Zastosowanie bare-metal nie jest idealne bo każdy będzie miał inne. Nie każdy będzie miał 3 węzły. Ktoś przydzieli sobie 10 GB RAMu inny 2GB RAMu. I będzie a u mnie działa, a u mnie nie :(. Dlatego proces trzeba było zautomatyzować. Zatem rozwiązanie bare-metal odpada. Kontrola miała zostać po mojej stronie. Maszyna wirtualna W cloud możemy tanio uruchomić maszynę wirtualną, kosztuje ona kilka centów/groszy za działanie instancji. U wielu dostawców jestesmy rozliczany za czas uruchomienia nie za commitment. Czyli jak maszyna działa nam dwie godziny płacimy za dwie godziny. U niektórych dostawców nawet jest tak, że jak maszyna wirtualna jest wyłączona to płacimy grosze za storage używany przez nasze dane przechowywane na dyskach dostawcy. We wcześniej wspomnianej dokumentacji o wymaganiach proxmox możemy wyczytać: Proxmox VE can be installed as a guest on all common used desktop virtualization solutions as long as they support nested virtualization. Dlatego musimy sprawdzić czy nasza maszyna wirtualna jest wstanie uruchomić proxmoxa oraz wykorzystać jego potencjał. Aby sprawdzić, czy maszyna jest w stanie uruchomić Proxmox, warto zwrócić uwagę na kilka kluczowych punktów: Wsparcie dla Wirtualizacji Zagnieżdżonej (Nested Virtualization) : Sprawdź, czy maszyna obsługuje wirtualizację zagnieżdżoną. Jest to warunek niezbędny, gdyż Proxmox sam jest platformą wirtualizacji i wymaga tej funkcji do poprawnego działania jako gość w środowisku innego hypervisora. Na maszynie z procesorem Intel : użyj komendy cat /sys/module/kvm_intel/parameters/nested. Jeśli wynik to Y, wirtualizacja zagnieżdżona jest wspierana. Na maszynie z procesorem AMD : użyj komendy cat /sys/module/kvm_amd/parameters/nested. Wynik 1 oznacza wsparcie dla wirtualizacji zagnieżdżonej. Obsługa VT-x (dla Intel) lub AMD-V (dla AMD) : Jeśli masz dostęp do konfiguracji sprzętowej, upewnij się, że maszyna posiada wsparcie dla technologii wirtualizacyjnej VT-x (Intel) lub AMD-V (AMD). Można to sprawdzić w BIOS-ie lub użyć polecenia: egrep -c '(vmx|svm)' /proc/cpuinfo Wynik większy niż 0 wskazuje na wsparcie wirtualizacji sprzętowej. Na DigitalOcean nasz maszyny wirtualne uruchamiane w tym cloud wspierają zagnieżdżoną wirtualizację. I tym samy nie mówię, że inne cloudy tego nie wspierają. A wybór padł na DigitalOcean ponieważ miałem już tu inną konfigurację którą wykorzystuje do mich szkoleń. I mam tu napisane środowisko które mi to automatyzuje. Więc skupiam sie tylko na wkładzie pod proxmox, nie na konfiguracji całości. Wkład Automatyzacja w moim przypadku opiera się na terraform, który zapewnia automatyzację środowiska. W kilka sekund tworzy lub usuwa zasoby, które są opisane językiem HCL. O terraform możesz nauczyć się z moich kursów dostępnych na platformie szkoleniowej . Dodatkowo do terraform jest dodawany cloud-init zawierający instrukcje bash które konfigurują moje środowisko. Dzięki tym dwóm technologią mogłem uruchomić środowisko dla 200 słuchaczy dostarczając im prekonfigurowanego proxmoxa. Jeżeli jest ktoś zainteresowany kosztami warsztatów ile mnie to wyniosło poniżej przedstawiam dane: Koszt warsztatów. Do automatyzacji wykorzystałem github actions, który jest opłacany rocznie (48$) zatem koszt działania github action w tym jednym dniu wyniósł = 0,131 $. Gitflow uruchomiłem o godzinie 13:00 (godzinę przed warsztatami) w celu spokojnego uruchamiania się wszystkich skryptów. Sam terraform wykonywał się dokładnie 13 minut 37 sekund - dalsze 46 minut i 23 sekundy przeznaczyłem na spokojne uruchomienie się skryptów i automatyczna instalację proxmox do etapu gdzie była dostępna konfiguracja trzech nodów z dostępem do interfejsu www proxmoxa. Sam cloud-init potrzebuje między 15 - 20 minut na przygotowanie środowiska. Dlatego start o 1h wcześniej był strategicznym posunięciem. Gdzie maszyny uruchomione w końcówce konfiguracji terraform były gotowe na 13:50 - czyli 10 minut przed startem warsztatów. Warsztaty trwały 2 godziny i skończyły się o 16. Wyłączenie warsztatów i posprzątanie ich terraform zajęło 15 minut i 33 sekundy. Przyjmijmy zatem że całość trwała 4 godziny i za ten czas byłem rozliczany w digitalocean. Transfer danych był za darmo w ramach przydzielonego pakietu do maszyn wirtualnych więc tu mamy 0$. Mamy zatem 200 maszyn wirtualnych, compute jaki wykorzystałem (size tak nazywa się ten atrybut w digitalocean) to s-4vcpu-16gb-320gb-intel (4 cpu, 16GB RAM i 320 GB storage, na procesorze intel). Spójrzmy na cenę tego produktu. Cena za godzinę działania takiej maszyny wirtualnej to 0.143$. A i do całości trzeba uwzględnić testy które przeprowadzałem by sprawdzić czy całe środowisko będzie działać. Poniżej rachunek za ten miesiąc w digitalocean: Najważniejsze kluczowe pozycje to: Basic Intel Droplet - 16 GB / 4 vCPU / 320 GB SSD @ $96.00/mo ($0.14286/hr) Basic Intel Droplet - 32 GB / 8 vCPU / 640 GB SSD @ $192.00/mo ($0.28571/hr) Basic AMD Droplet - 32 GB / 8 vCPU / 400 GB SSD @ $168.00/mo ($0.25000/hr) Premium Intel Droplet - 64 GB / 32 vCPU / 400 GB SSD @ $874.00/mo ($1.30060/hr) Te pozycje brały udział w przygotowaniach do warsztatów jaki i w samych warsztatach. LP Compute Cena Ilość 1 Basic Intel Droplet - 16 GB / 4 vCPU / 320 GB SSD $0.14286/hr 434 2 Basic Intel Droplet - 32 GB / 8 vCPU / 640 GB SSD 0.28571/hr 12 3 Basic AMD Droplet - 32 GB / 8 vCPU / 400 GB SSD $0.25000/hr 2 4 Premium Intel Droplet - 64 GB / 32 vCPU / 400 GB SSD $1.30060/hr 6 Basic Intel Droplet - 16 GB / 4 vCPU / 320 GB SSD - 434 instancje, a to dlatego że raz zrobiłem testowe uruchomienie i sprawdzenia czy wszystko się postawi Basic Intel Droplet - 32 GB / 8 vCPU / 640 GB SSD i Basic AMD Droplet - 32 GB / 8 vCPU / 400 GB SSD to eksperyment, testowanie środowiska, te testy powiedziały mi że dla słuchaczy w zupełności wystarczy Basic AMD Droplet - 32 GB / 8 vCPU / 400 GB SSD. Czyli zrobiłem oszczędność rzędu 0,14285 $ na każdej instancji :) uruchomionej dla słuchacza. Premium Intel Droplet - 64 GB / 32 vCPU / 400 GB SSD - to już mój host z ktorego robiłem warsztaty i demonstrowałem działanie środowiska. Jak widać maszyna ma znacznie większe osiągi. Było to celowe zagranie. Dawało mi to pewność działania i płynność funkcjonowania warsztatów. Podsumowanie wydatków Podsumujmy teraz to. 217 osób zgłosiło chęć udziału w warsztatach i dla tylu osób były przygotowane maszyny wirtualne. 217 * 0,14286 = 31,00062$. Tą wartość należy pomnożyć przez 4h działania warsztatów co daje nam 124,00248$. Oczywiście już widzimy że w digitalocean naliczanie jest proporcjonalne ponieważ uruchomienie 434 instancji typu Basic Intel Droplet - 16 GB / 4 vCPU / 320 GB SSD kosztowało mnie 117,60$ zatem ta kwotę podzielimy na dwa. 58,8$ + 10,40$ = 69,2$ to koszt uruchomienia warsztatów. Testy wyniosły mnie 58,8$ + 4,62$ + 0,5$ = 63,92$. Całość kosztowała mnie 132,52$ co daje 0,61$ na uczestnika. Automatyzacja Oczywiście kluczowym aspektem całości była automatyzacja. Bez niej nie udałoby mi się w tak krótkim czasie uruchomić i skonfigurować 217 maszyn wirtualnych. Terraform miał za zadanie przygotować infrastrukturę. Uruchomić sieć i ją skonfigurować. Potem w tej sieci uruchomić maszynę wirtualną. przypisać do tej maszyny wirtualnej domenę z AWS route 53 Cloud-init był odpowiedzialny za konfigurację maszyny wirtualnej i uruchomienia akcji w odpowiedniej kolejności. Mieszankę tych technologii oraz efekt końcowy można było zobaczyć na warsztatach, obejrzeć na YouTube i poczytać w kodzie źródłowym Auto installer Proxmox ma mechanizmy auto instalacji , który pomógł w przygotowaniu tych warsztatów. W dokumentacji możemy poczytać o tym aby zautomatyzować ten proces musimy przygotować plik answer.toml który zawiera przykładowa konfigurację [global] keyboard = "pl" country = "pl" fqdn = "pvedemo03.example.in" mailto = "proxmox@example.in" timezone = "Europe/Warsaw" root_password = "${password}" root_ssh_keys= ["$ssh_key"] [network] source = "from-dhcp" [disk-setup] filesystem = "ext4" lvm.hdsize = 50 disk_list = ["vda"] Parametry te automatyzuja nam konfigurację - wszystkie pozycje opisane są w dokumentacji dostępnej tu , zatem pominę omawianie ich w tym artykule. Tak przygotowane pliki answer posłużyły do przygotowania obrazów, które pomogły zautomatyzować cały proces instalacji i konfiguracji proxmoxa z KVM. # Generowanie obrazu ISO dla maszyny z odpowiednim plikiem answer.toml sudo proxmox-auto-install-assistant prepare-iso "$BASE_ISO_PATH" \ --fetch-from iso \ --answer-file "$ANSWER_FILE" \ --output "$CUSTOM_ISO_PATH" a cały skrypt i jego kod dostępny jest na publicznym repo w bitbucket. Całość można obudowac w github action czy inne narzędzie CI/CD - Budowa pipeline może już w osobnym artykule opiszę. Jednak jeżeli chcesz pobawić się proxmox w cloud to poniżej masz instrukcję która pozwoli Ci uruchomić to repozytorium: Klonujemy lokalnie repozytorium . poleceniem np: git clone https://accountszkoleniacloud@bitbucket.org/szkoleniacloud/proxmox_digitalocean_terraform_configuration.git Instalujemy terraform Po instalacji przechodzi do sklonowanego repozytorium i szukamy pliku variables.tf na podstawie niego możemy zabudować nasz plik .auto.tfvars, który może wyglądać tak do_token = "TU WKLEJ WARTOŚĆ SWOJEGO TOKENA" # NADPISZ DOMYSLNE ZMIENNE PODAJC ICH NAZYW I WARTOŚCI. size = "c-32-intel" # zmieni to domyślny compute size Po utworzeniu tego pliku .auto.tfvars wystarczy wydać polecenie terraform init; terraform plan; terraform apply - po 2-3 minutach nasza maszyna wirtualna będzie dostępna. A mniej więcej po 15-20 minutach będzie zainstalowany i skonfigurowany proxmox na 3 węzłach. Przypominam że całość procesu można obejrzeć na YouTube Zapraszam do testów i po więcej wpisów i materiałów.

Witajcie. Poniższy post jest dla wszystkich którzy chcą pobawić się proxmox ale z jakieś przyczyny nie mają lub nie mogą mieć laba w domu. Poniższa konfiguracja działa w cloud na digitalocean. Tu masz dostępny link który da Ci na 60 dni 200$ do testowania chmury digitalocean. W zupełności to wystarczy by pobawić sie proxmox Automatyzacja Całość konfiguracji jest zautomatyzowana - wiec nie musisz pamiętać o tym co i jak musisz skonfigurować i usunąć by nie narażać się na dodatkowe koszty. Kod w terraform jest dostępny w repozytorium bitbucket Wystarczy sklonować poleceniem: git clone https://bitbucket.org/szkoleniacloud/proxmox_digitalocean_terraform_configuration.git I możemy przystąpić do działania. Oczywiście musimy mieć zainstalowanego terraforma i konto na digitalocean. Potrzebne bedzie nam też klucz API - zakłada sie go po stworzeniu konta w digitalocean. Tworzymy plik o nazwie .auto.tf.vars z zawartością naszego tokena do_token = "TU WKELJ SWOJ TOKEN" Potem już tylko terraform init, terraform plan i terraform apply - po zakończonej zabawie terraform destroy. Jak to działa prezentują to te dwa poniższe filmy na Youtube: Proxmox - manualna konfiguracja Proxmox - pełna automatyzacja

Garść ciekawych artykułów znalezionych w sieci z tematyki IT, DevOPS, AI, IaC,, automatyzacji oraz wszystkiego co ciekawe :) - Zapraszam Coraz więcej wrażliwych danych w github - Deweloperzy nie dbają o bezpieczeństwo? Dyski z pamięcią DNA coraz bliżej. Nadchodzi nowy standard nośników Uruchomili ChatGPT w arkuszu Excela. Plik waży 1,2 GB i każdy może go wypróbować Oni już tracą pracę przez sztuczną inteligencję. Dług technologiczny to bolączka wszystkich firm, które pracują z technologiami w mniejszym bądź większym stopniu. Zaczyna on być jednak coraz bardziej odczuwalny Orchiestracja aplikacji i cloud nigdy nie była taka prosta O tym jak z pomocą AI tworzyć fałszywe dokumenty tożsamości Self hosted własny DNS serwer - bezpieczny i szybki Kodowanie za pomocą głosu w Visual Studio Code z Copilot Voice Co może pójść nie tak przy tworzeniu gry za pomocą AI Chatbot nie chce dać Ci przepisu na kontrukcje bomby, czy receptury na nowy narkotyk - ASCII pozwala obejść ograniczenia narzucone chatbotom. GhostRace - nowa luka zagraża wszystkim architecture CPU Chcesz się zapisać i być na bierząco zapraszam https://szkolenia.cloud/devops

Hej witam w kolejnej porcji nowości oto kilka tematów które przykuły moja uwagę w poprzednim tygodniu. Zapraszam. P.S na nwesletter zapisać się możesz tu https://szkolenia.cloud/devops/ OpenTofu 1.7.0-alpha1 to nowa wersja alfa, która wprowadza szyfrowanie stanu, usunięcie bloku i poprawki kompatybilności. Jest dostępna do testów społeczności, ale nie zaleca się jej stosowania w środowiskach produkcyjnych. Użytkownicy mogą pobrać wersję i przekazać opinie poprzez formularz lub Slack OpenTofu. Ciekawe spojrzenie i przemyślenia jak AI może wpłynąć na nasze życie. Autor zdaje pytanie czy inżynierowie (programiści) są skazani na zagładę wraz z rozwojem AI Używacie wtyczek do OpenAI/ChatGPT? To uważajcie na nową formę ataku która umożliwia przestępcą pozyskanie danych czy przejęcia konta. Obecnie mocno jest tu opisywana forma skupiająca się na OpenAI i ChatGPT ale pewnie w przyszłości dowiemy się też o pluginach/wtyczkach zainfekowanych do lokalnych modeli LLM - gdzie użytkownicy znacznie częściej będą wprowadzać poufne dane - bo przecież działa lokalnie. Nowy mechanizm ulepszonej ochrony adresów URL w czasie rzeczywistym od Google - czy okaże się on lekarstwem na strony udające inna stronę i próbujące wykraść nasze dane. Jest to zmana obecnego meachnizmu który, to przechowywał listę takich url lokalnie na naszej maszynie/telefonie/tablecie. Co ciekawe powstawanie nowych stron/domen phishingowych rośnie a 60% z nich istnieje krócej niż 10 minut. Ostatnio na moim kanale na YouTube pojawił się materiał o tym jak udostępniam swoje domowe serwisy na świat tak by mieć do nich dostęp z każdego miejsca na świecie. I tak przy okazji Warto też przypomnieć o dobrych praktykach związanych z zabezpieczeniem SSH w roku 2024 Na koniec auto reklama - jeżeli szukasz szkolenia dla siebie lub Twojej organizacji z tematyki terraform i chcesz nauczyć się tego języka od podstaw to zapraszam do 4 dniowego szkolenia nażywo https://terraform.szkolenia.cloud/

W najnowszym wydaniu newslettera odkryjemy najświeższe aktualizacje i narzędzia technologiczne, od wzmocnionej bezpieczeństwa i wsparcia dla MongoDB w Postfix 3.9, przez innowacyjne możliwości Kubernetes w OpenMediaVault 7, po wprowadzenie wsparcia dla wirtualizacji i usprawnień bezpieczeństwa w Linux Kernel 6.8. Ponadto, przyjrzymy się nowym funkcjom KeePassXC 2.7.7 w zakresie importowania haseł, zagrożeniom cybernetycznym wykorzystującym emulator QEMU, a także taktykom hakerskim grupy BianLian. Zaprezentujemy również kurs generatywnej AI od Microsoftu, odkryjemy Obsidian jako narzędzie do planowania i zarządzania projektami, podzielimy się wrażeniami z NeoVim oraz nauczymy technik nigdy nie zapominania w zakresie przyswajania wiedzy. Odkryj nowości w Postfix 3.9: wsparcie dla MongoDB, ulepszone klienty MySQL/pgSQL i zwiększone bezpieczeństwo. Ta aktualizacja popularnego agenta transferu poczty wprowadza wiele istotnych ulepszeń, m.in. wsparcie dla MongoDB, elastyczniejsze ustawienia czasowe dla klientów MySQL i PostgreSQL oraz opcjonalne wsparcie dla surowych kluczy publicznych w komunikacji TLS. Przeczytaj więcej o tych zmianach, które czynią Postfix jeszcze bardziej elastycznym i bezpiecznym rozwiązaniem dla serwerów e-mail. Rozszerz możliwości swojego serwera NAS z OpenMediaVault 7 dzięki nowemu pluginowi opartemu na K3s, który wprowadza możliwości Kubernetes. Ten lekki dystrybucja Kubernetes zaprojektowana jest z myślą o prostocie i efektywności zasobów, idealna do zastosowań w obliczeniach brzegowych i urządzeniach IoT. Plugin oferuje preinstalowany cert-manager, Traefik jako kontroler Ingress, automatyczne tworzenie woluminów trwałych dla istniejących folderów udostępnionych i wbudowany dashboard Kubernetes. Linus Torvalds ogłosił wydanie jądra Linux 6.8, wprowadzając wsparcie dla wirtualizacji LAM, obsługę pamięci guest-first dla KVM, i mechanizmy naprawy systemu plików Bcachefs. Nowości obejmują także wsparcie dla procesora Broadcom BCM2712 w Raspberry Pi 5, funkcje AMD do łagodzenia interferencji w paśmie Wi-Fi, i wiele innych ulepszeń związanych z bezpieczeństwem, wydajnością oraz wsparciem sprzętowym. KeePassXC 2.7.7 przynosi nowości, jak importowanie haseł z 1Password i Bitwarden, obsługę PassKeys i USB hotplug dla interfejsu Hardware Key. Poprawia bezpieczeństwo, minimalizując ryzyko ataków przez kanały boczne i ulepsza integrację przeglądarki. Cyberprzestępcy wykorzystują emulator QEMU jako narzędzie do tunelowania, aby naruszyć sieć firmową. Atakujący użyli tego otwarto źródłowego emulatora sprzętu, aby połączyć się z infrastrukturą firmy. Jest to pierwszy znany przypadek wykorzystania QEMU w celu tunelowania, co stanowi nową strategię dywersyfikacji ataków. Badacze podkreślają, że wykorzystywanie legalnych narzędzi przez cyberprzestępców nie jest nowością, co potwierdza konieczność wielopoziomowej ochrony obejmującej niezawodną ochronę punktów końcowych i specjalistyczne rozwiązania do wykrywania i ochrony przed złożonymi i ukierunkowanymi atakami Hakerzy z grupy BianLian wykorzystują luki w oprogramowaniu JetBrains TeamCity do przeprowadzania ataków z oprogramowaniem wymuszającym okup. Wykorzystują oni specyficzne podatności, aby uzyskać początkowy dostęp do systemów, a następnie rozmieszczają złośliwe oprogramowanie i narzędzia zdalnego dostępu. Zidentyfikowane działania wskazują na zmianę taktyki grupy, która teraz skupia się na wyłącznie na ekstrakcji danych i szantażowaniu ofiar. Generatywna sztuczna inteligencja dla początkujących Bezpłatny kurs generatywnej sztucznej inteligencji firmy Microsoft podzielony na 18 lekcji. - github Jeżeli tak jak ja używasz Notion to jest dla Ciebie darmowa alternatywa. Odkryj, jak skonfigurować Obsidian do planowania treści i zarządzania projektami. Artykuł prowadzi przez instalację Obsidiana, dostosowywanie jego wyglądu i włączanie wtyczek społeczności, takich jak Templater i Tasks, aby usprawnić procesy twórcze. Znajdziesz tutaj praktyczne wskazówki, jak za pomocą szablonów i list zadań zorganizować swoje pomysły oraz projekty, sprawiając, że zarządzanie nimi staje się łatwiejsze i bardziej intuicyjne. Będąc w podróży do Warszawy i przez protesty oraz spowodowane korki miałem więcej czasu na dodatkowy rozwój i poznanie narzędzi - NeoVim Poznaj system "nigdy nie zapominania": opanowanie sztuki zatrzymywania wiedzy. Artykuł opiera się na wideo, które przedstawia techniki na efektywniejsze czytanie książek i zatrzymywanie wiedzy. Kluczowe wskazówki obejmują ponowne uczenie się czytania, koncentrację na zrozumieniu treści, wielokrotne czytanie rozdziałów, robienie notatek i zastosowanie analogowych narzędzi takich jak fiszki do przyswajania wiedzy. Całość koncentruje się na skutecznym zapamiętywaniu i wykorzystywaniu zdobytych informacji. I zapomnij o zapominaniu - brzmi jak reklama aptecznego specyfiku, lecz naprawdę warto obejrzeć materiał. Zapraszam Do newslettera można się zapisać tu https://szkolenia.cloud/devops/

Jeszcze tylko dzisiaj obowiązuje 80% zniżki na szkolenia wideo na platformie szkolenia.cloud Zanurz się w szkolenia w z wirtualizacji, kontereryzacji, automatyzacji i procesów CI/CD. Zobacz jak zautomatyzować pracę z wykorzystaniem terraform. Zapraszam. KNOW80 - to kod który da Ci zniżkę w wysokości 80% na cały koszyk i na wszystkie szkolenia wideo.

Hej, Witajcie w pierwszym newsletterze na mojej stronie. Będzie to przekrój aktualności i ciekawych materiałów na, które natrafiłem w poprzednim tygodniu biegając po internecie. Możliwe że znajdziesz coś ciekawego dla siebie lub poznasz jakieś narzędzie którego nie znałeś :). Zapraszam. P.S - a newsletter będzie pokazywał się co tydzień we wtorek :) :D Do samego newslettera można się zapisać tu: https://szkolenia.cloud/devops/ Lub na tej stronie do globalnych wiadomości i artykułów publikowanych na tej stronie :) Ponad 100 000 Zainfekowanych repozytoriów na github - W ostatnim badaniu zespół Apiiro odkrył, że ponad 100,000 repozytoriów na GitHubie zostało zainfekowanych za pomocą kampanii repo confusion. Atak, polegający na podszywaniu się pod znane i zaufane repozytoria, zagraża milionom, gdy programiści nieświadomie korzystają z zainfekowanych wersji. Złośliwe repozytoria, zawierające obciążone malware, są promowane w sieci, co prowadzi do kradzieży danych przez złośliwe oprogramowanie. Apiiro podkreśla potrzebę monitorowania kodu w celu wykrywania złośliwych ładunków i zabezpieczenia całej organizacji. Odkryj przyszłość hostowania z "Self-Hosting is Dead. Hybrid is the Way to Go". Ten porywający artykuł rzuca światło na ewolucję infrastruktury IT, przekonując, że model hybrydowy jest kluczem do zrównoważonego rozwoju, elastyczności i bezpieczeństwa w dzisiejszym cyfrowym świecie. Zanurz się w dyskusji o korzyściach płynących z połączenia chmury z lokalnymi zasobami, by zrozumieć, dlaczego hybryda dominuje na horyzoncie technologicznym. Idealna lektura dla tych, którzy szukają inspiracji do modernizacji swojej infrastruktury IT! Jak korzystać z kontenerów testowych w Jenkins CI - "Odkryj nowatorskie podejście do testowania w Jenkins CI z użyciem Testcontainers!" Ten praktyczny artykuł na blogu Docker pokazuje, jak skutecznie wykorzystać Testcontainers na Jenkins CI, zwiększając efektywność i niezawodność procesów CI/CD. Przewodnik krok po kroku wprowadza w świat dynamicznych kontenerów i Kubernetes pods jako agentów, oferując łatwe do zastosowania rozwiązania dla testów opartych na Testcontainers. To niezbędna lektura dla każdego dewelopera i specjalisty DevOps szukającego sposobów na optymalizację i automatyzację testów w środowiskach CI. Odkryj nieodkryte skarby wśród aplikacji dla Maca z "Top Free Utility Mac Apps You Aren’t Using"! Ten artykuł przewodnik po wyselekcjonowanych, darmowych narzędziach ujawnia, jak w pełni wykorzystać potencjał Twojego Maca, podnosząc produktywność i optymalizując przepływ pracy. Z aplikacjami, które mogą nie być jeszcze na Twoim radarze, ale zasługują na miejsce w Twoim arsenale narzędziowym, jest to must-read dla każdego użytkownika Maca poszukującego sposobów na ulepszenie swojego cyfrowego życia Zainspiruj swoją podróż deweloperską z "7 Best Podcasts for Newbie Devs"! Ten artykuł to brama do świata podcastów, które są idealne dla początkujących programistów, pragnących pogłębić swoją wiedzę i umiejętności. Od inspirujących historii przejścia do branży IT po techniczne dyskusje i praktyczne wskazówki – te podcasty oferują wsparcie, motywację i edukację. Niezależnie od tego, czy jesteś w trakcie nauki kodowania, czy szukasz sposobów na rozwój w swojej karierze deweloperskiej, znajdziesz coś dla siebie. To doskonały sposób, by uczyć się i rosnąć nawet wtedy, gdy jesteś w ruchu! "Odkryj, jak przekształcić setki wysłanych CV w oferty pracy z '50 Golden Tips for Landing a Tech Job in 15 Months'! Ta dogłębna analiza oferuje nieocenione wskazówki i strategie, które pomogły autorowi przejść od frustrującej poszukiwania pracy do otrzymania dwóch ofert pracy. Artykuł zawiera praktyczne porady dotyczące przygotowania do rozmów kwalifikacyjnych, optymalizacji CV, skutecznego networkingu i wykorzystania platform pracy. Niezależnie od tego, gdzie jesteś w swojej karierze technologicznej, te złote porady mogą pomóc Ci wyróżnić się na rynku pracy"​ Zapraszam Piotr "TheRealMamuth" Kośka. Miłej lektury.

Terraform w wersji 1.7.0 stable wydany - https://github.com/hashicorp/terraform/blob/v1.7.0/CHANGELOG.md warto zapoznac sie z chcnge log do tej wersji i ze wszystkimi nowiściami

🚀 Odkryj Świat Proxmox: Profesjonalny Kurs Dla Wszystkich, Którzy Chcą Zostać Ekspertami! 🌟 Hej, entuzjaści IT! Czy jesteście gotowi poszerzyć swoje horyzonty w świecie wirtualizacji? Przedstawiamy nasz flagowy kurs Proxmox, zaprojektowany z myślą o zapewnieniu Wam przewagi w dynamicznie zmieniającym się świecie technologii. 👨‍💻🌐 Dlaczego warto wybrać nasz kurs? Kompleksowe Moduły: Nasz kurs obejmuje od instalacji Proxmox, przez konfigurację, aż po zaawansowane techniki zarządzania. Dwa starannie zaplanowane moduły oferują łącznie 153 minuty intensywnego szkolenia. Wiedza od Ekspertów: Nasze lekcje są prowadzone przez doświadczonych profesjonalistów, którzy dzielą się praktycznymi wskazówkami i najlepszymi praktykami. Dostępność i Elastyczność: Ucz się w swoim tempie, gdziekolwiek jesteś, z dostępem do materiałów kursowych online. Co Zyskasz? 🔹 Solidne Fundamenty: Zrozumiesz podstawy Proxmox, co jest niezbędne dla każdego aspirującego administratora. 🔹 Zaawansowane Umiejętności: Poznasz techniki zarządzania i optymalizacji, które wyróżnią Cię na rynku pracy. 🔹 Praktyczne Doświadczenie: Nasz kurs stawia na praktyczne umiejętności, które możesz od razu zastosować w swojej pracy. Dla Kogo Jest Ten Kurs? ✅ Dla początkujących, którzy chcą wejść w świat Proxmox. ✅ Dla średnio zaawansowanych użytkowników, szukających pogłębienia wiedzy. ✅ Dla profesjonalistów IT, którzy chcą zaktualizować swoje umiejętności. 🎓 Zapisz Się Dziś! Nie przegap tej wyjątkowej okazji, aby zanurzyć się w świecie Proxmox. Zapisz się już teraz i zacznij swoją podróż do zostania ekspertem Proxmox! 👉 Kliknij Tutaj, aby dowiedzieć się więcej i zarejestrować się! Dołącz do Naszej Społeczności IT! 💬 Podziel się tym postem ze swoimi znajomymi i dołącz do naszej rosnącej społeczności entuzjastów IT. Razem możemy osiągnąć więcej! 🔥 #Proxmox #ITTraining #BecomeAnExpert #Virtualization #TechnologyEducation

Już dziś dostaliśmy funkcje zastrzegania numeru pesel. Funkcja ta ma na celu ochronic nas przed kradzieżą tożsamości. Mówiąc teraz gdy w banku, w telekomie lub innej instytucji ktoś zrobi operacje na nasze dane to po stronie tychże instytucji będzie spoczywał obowiązek na weryfikacje naszych danych oraz czy ów pesel nie jest zastrzeżony. Choć i tu musze dodać łyżkę dziekciu. Obowiązek ten bedzie dobiero nakładny od 1 czerwca 2024 - do tego czasu wszystkie instytucje mogą nie musza z tego korzystać - czyli swoisty czas na integracje systemów. Aktywacja. Funkcjonalność aktywowania zastrzeżenia będzie z poziomu internetu, osobistej wizyty w placówce pocztowej lub bankowej. Zalecam pierwszą opcje czyli internet - w moim przypadku była to strona mobywatel.gov.pl Jest też możliwość przez aplikację na telefonach - mobywatel, jednak u mnie tej opcji jeszcze nie było. I jak patrzyłem mam starsza wersje aplikacji, a nowszej na czas pisania artykułu jeszcze nie mogłem pobrać. Kroki - aktywacji online Przechodzimy na stronę https://www.gov.pl/web/gov/zastrzez-swoj-numer-pesel-lub-cofnij-zastrzezenie rozwijamy sekcje co musisz zrobić i tu mamy cały opis. Co musisz zrobić Kliknij przycisk Zastrzeż PESEL lub cofnij zastrzeżenie i zaloguj się. System przeniesie cię do mObywatel.gov.pl Wybierz sekcję Twoje dane, a następnie Rejestr zastrzeżeń PESEL. Wybierz Zastrzeż PESEL lub Cofnij zastrzeżenie. Jeśli chcesz cofnąć zastrzeżenie numeru PESEL, możesz to zrobić: bezterminowo lub określić datę i godzinę, kiedy system automatycznie zastrzeże ponownie twój numer PESEL. Jak widać to bardzo proste.

Tworzenie diagramów swojej przyszłej infrastruktury to dobry koncept. Pozwala zwizualizować wygląd naszej infrastruktury oraz łatwiej rozplanować kod gdy nasze konfiguracje w cloud powstają na przykład w terraform. Jednak jak to czesto bywa na etapie pisania kodu czy walidacji kosztów plany naszej konfiguracji się zmieniają - a szkielety infrastruktury w formie (rysunku) pozostają w niezmienionej formie lub z tylko nie wielkimi poprawkami. A co gdyby ten proces zautomtyzować - i dostarczyć gotową dokumentacje wizualną wraz z implementacją naszej infrastruktury? Narzędzie TerraVision Terravision to narzędzie wiersza poleceń (CLI), które konwertuje kod Terraform na dynamiczne, profesjonalne diagramy architektury chmury. Głównym celem Terravision jest utrzymanie aktualności najważniejszego dokumentu w projektach chmurowych - dokumentu architektury. W dobie szybkich wydań, automatycznie generowane diagramy architektury są bardziej precyzyjne niż ręcznie rysowane przez architekta chmury, które mogą już nie odzwierciedlać rzeczywistości. Terravision działa w 100% po stronie klienta, bez zależności od Terraform lub dostępu do środowiska chmurowego. Narzędzie to dynamicznie analizuje warunkowo tworzone zasoby i zmienne, generując automatyczny wizualny obraz architektury. Jest zaprojektowane jako narzędzie 'Docs as Code' (DaC), które można włączyć do pipeline'u CI/CD, aby aktualizować diagramy architektury po fazach budowania, testowania i wdrażania. W prosty sposób jak to jest przedstawione w repozytorium kodu. To czyli nasz kod w bardzo prosty sposób i szybki możemy zamienić na diagram Zalety Terravision Koszt Oszczędność na licencjach oprogramowania do tworzenia diagramów/rysunków - Terravision jest darmowe i open source Nie wymaga korzystania z zasobów chmury obciążających kosztami, działa natychmiastowo na lokalnej maszynie Regularna aktualizacja diagramów, łączenie punktów i rozmieszczanie ikon nie jest najlepszym wykorzystaniem kosztów pracowników architektury Przyspieszenie i automatyzacja Użyj plików zmiennych TF jako danych wejściowych do tworzenia wielu wariantów diagramów z tego samego kodu TF Automatyzuj tworzenie diagramów architektury, uruchamiając terravision jako część potoków CI/CD Diagramy oparte na YAML jako kod pozwalają na dodawanie do wygenerowanych diagramów dodatkowych niestandardowych etykiet i zasobów, np. zasobów niezarządzanych lub zewnętrznych systemów nieuchwyconych w kodzie TF Spójność w całej organizacji Automatyczne pobieranie modułów organizacyjnych / zewnętrznych, aby zapewnić najnowszy widok modułów Terraform Spójny projekt diagramów architektury z użyciem standardowych ikon branżowych i zatwierdzonego stylu AWS/GCP/Azure w zespołach Dokładna widoczność Diagram w czasie rzeczywistym pokazuje aktualną infrastrukturę, która dokładnie odpowiada temu, co jest wdrożone w produkcji dzisiaj Pomoc w przeglądach architektury stron trzecich, audytach, monitoringu, raportowaniu i debugowaniu stosu w sposób wizualny Kod diagramu niestandardowego i obrazy wyjściowe mogą być umieszczane w kontroli źródła/wersji dla lepszej utrzymania i odkrywalności Bezpieczeństwo Nie trzeba dawać dostępu do konta AWS lub CLI, aby rysować diagram Nie tworzy intruzywnych zasobów chmury, np. instancji skanujących lub tabel metadanych, które przedsiębiorstwa musiałyby zatwierdzić Cały kod źródłowy pozostaje w lokalnym środowisku, diagramy są generowane na twoich maszynach bez wywoływania zewnętrznych API Instalacja i Użycie Zależności dla wszystkich wersji graphviz https://graphviz.org/download/ git https://git-scm.com/downloads Szybki start Zainstaluj wszystkie zależności, jak wyżej wymieniono. Sklonuj repozytorium: git clone https://github.com/patrickchugh/terravision.git. Uzyskaj pełną ścieżkę do katalogu roboczego, wykonując cd terravision i pwd. Dodaj folder terravision do swojej zmiennej PATH, np. export PATH=$PATH:/Users/<ŚCIEŻKA DO TERRAFORM>, aby móc uruchamiać go z dowolnego miejsca. <ŚCIEŻKA DO TERRAFORM> to wynik z punktu 3. Zainstaluj wymagane biblioteki Pythona: cd terravision && pip install -r requirements.txt. Upewnij się, że skrypt pythonowy terravision jest wykonywalny: chmod +x terravision. Uruchom terravision, określając pliki źródłowe Terraform w formacie: $ terravision draw --source ~/src/my-terraform-code Dla kodu źródłowego Terraform w repozytorium Git, można również użyć formy: $ terravision draw --source https://github.com/twoje-repozytorium/terraform-examples.git Użyj znaku // dla podfolderów w repozytoriach Git, jeśli kod, który chcesz, znajduje się pod hierarchią folderów. $ terravision draw --source https://github.com/twoje-repozytorium/terraform-examples.git//mysubfolder/secondfolder/ Przykładowe Terraformy do wypróbowania Nie związane z moim projektem, ale oto kilka przykładów Terraform od osób trzecich do wypróbowania: terravision draw --source https://github.com/futurice/terraform-examples.git//aws/aws_static_site --varfile examples/variables.tfvars --show terravision draw --source https://github.com/futurice/terraform-examples.git//aws/wordpress_fargate --varfile examples/variables.tfvars --show terravision draw --source https://github.com/k-mitevski/terraform-k8s.git//01_terraform_eks --show Annotowanie wygenerowanych diagramów Żaden automatycznie wygenerowany diagram nie będzie miał wszystkich potrzebnych szczegółów, w najlepszym przypadku dostarczy 80-90% potrzebnych informacji. Aby dodać niestandardowe adnotacje, takie jak główny tytuł diagramu, dodatkowe etykiety na strzałkach lub dodatkowe zasoby utworzone poza Terraform, dołącz plik architecture.yml w folderze kodu źródłowego, a zostanie on automatycznie załadowany. Alternatywnie, określ ścieżkę do pliku z adnotacjami jako parametr dla terravision. terravision --source https://github.com/twoje-repozytorium/terraform-examples.git --annotate /Users/me/MyDocuments/annotations.yml Plik .yml to standardowy plik konfiguracyjny YAML, podobny do poniższego przykładu, z jednym lub więcej nagłówkami takimi jak title, connect, disconnect, add, remove lub update. Nazwy węzłów odpowiadają konwencjom nazw zasobów Terraform https://registry.terraform.io/providers/hashicorp/aws/latest/docs i obsługują znaki wieloznaczne. Możesz dodać niestandardową etykietę do dowolnego zasobu TF, modyfikując atrybuty zasobu i dodając atrybut label (nieistniejący w Terraform). Dla linii/połączeń możesz modyfikować atrybuty zasobu, dodając specyficzne dla terravision edge_labels, aby dodać tekst do linii połączenia z konkretnym węzłem zasobu. Zobacz poniższy przykład: format: 0.1# Main Diagram headingtitle: Serverless Wordpress Site# Draw new connection lines that are not apparent from the Terraformsconnect: aws_rds_cluster.this: - aws_ssm_parameter.db_master_user : Retrieve credentials from SSM# Remove connections between nodes that are currently showndisconnect: # Wildcards mean these disconnections apply to any cloudwatch type resource called logsaws_cloudwatch*.logs: - aws_ecs_service.this - aws_ecs_cluster.this# Delete the following nodesremove: - aws_iam_role.task_execution_role# Add the following nodesadd: aws_subnet.another_one : # Specify Terraform attributes for a resource like this cidr_block: "123.123.1.1"# Modify attributes of existing nodeupdate: aws_ecs_service.this: # Add custom labels to the connection lines that already exist between ECS->RDSedge_labels: - aws_rds_cluster.this: Database Queries# Wildcards save you listing multiple resources of the same type. This edge label is added to all CF->ACM connections.aws_cloudfront* : edge_labels: - aws_acm_certificate.this: SSL Cert# Add a custom label to a resource node. Overrides default labelaws_ecs_service.this : label: "My Custom Label" Oczywiście więcej można znaleść na stronie projektu: https://github.com/patrickchugh/terravision

Pod adresem https://cloud.google.com/blog/ znajdziesz blog Google Cloud, który oferuje różnorodne informacje, w tym wiadomości, porady oraz inspiracje mające na celu przyspieszenie transformacji cyfrowej. Oto kilka przykładów tematów, które możesz tam znaleźć: Komputacja: Artykuł o największym na świecie zadaniu dystrybucyjnego treningu dużych modeli językowych, zrealizowanym z użyciem ponad 50,000 chipów TPU v5e Google Cloud​​. Bezpieczeństwo i tożsamość: Omówienie podejścia Google Cloud do zaufania i przejrzystości w dziedzinie sztucznej inteligencji​​. AI i uczenie maszynowe: Opis trzech nowych sposobów, w jakie Duet AI może pomóc szybko wykonywać zadania w konsoli Google Cloud​​. Szkolenia i certyfikacje: Informacje o nowych sposobach rozwoju umiejętności w chmurze i identyfikacji talentów oferowanych przez Google Cloud​​. Przechowywanie danych i transfer: Wprowadzenie do Autoclass Cloud Storage, teraz dostępnego dla istniejących kubełków Cloud Storage​​. Bazy danych: Prezentacja aktualizacji Cloud SQL umożliwiającej łatwy przejście z wersji Enterprise do Enterprise Plus​​. Kontenery i Kubernetes: Prezentacja GKE Enterprise, kolejnego etapu ewolucji platform kontenerowych, które są teraz ogólnie dostępne​​. Rozwój aplikacji: Porady dotyczące budowania aplikacji Java Spring Boot w IntelliJ z pomocą Duet AI​​. Analiza danych: Omówienie zaawansowanych analizatorów tekstu i funkcji przetwarzania wstępnego w BigQuery​​. Bezpieczeństwo i tożsamość: Wskazówki dotyczące tworzenia polityki bezpieczeństwa sieciowego w Google Cloud​​. Blog ten jest bogatym źródłem informacji dla osób zainteresowanych technologią chmurową, AI, analizą danych i wieloma innymi aspektami technologii cyfrowych.