Search Results

Do przygotowania i napisania tego artykułu skłoniły mnie ostatnio zmiany na YouTube które, wpłynęły na działanie dość popularnej biblioteki youtube-dl do pobierania filmów z youtube (ale nie tylko). Zmiany w YouTube w sposobie przechowywania metadanych spowodowały, że pobranie ich stało się niemożliwe i próba pobrania ich kończyła się błędem o nie możliwości sparsowania danych w odpowiedni sposób. Kod który realizował zadanie wygląda w następujący sposób: Prosty kod który pobiera tagi z wskazanego wideo. I wspomnianego problemu bym nie napotkał gdybym nie pobierał tagów. I tu pytanie po co mi te tagi? yt-dlp rozwiązaniem problemu Zanim odpowiem na wcześniej postawione pytanie to z youtube-dl miałem już wcześniej problemy bo wersja na której, bazowałem była dość leciwa wersją biblioteki python. Pochodziła ona według numeru release z 2021. Samo pobieranie wideo i audio w dostępnych formatach na youtube-dl działało. Oczywiście dostępne formaty zależą od danego filmu spójrzmy na przykład: Wykorzystuje tu binarkę która można pobrać z youtube-dl lub ytdl-nightly . A samo pobranie jest po prostu odwołaniem się do odpowiedniego formatu. Jak interesuje nasz wideo z dźwiękiem to w youtube-dl wskazujemy dostępne formaty jako sumę np 137+140 czyli wideo w formacie 1920x1080 mp4 i audio m4a razem połączone w jeden plik. Pobranie samych tagów z poziomu binarki youtube-dl nie jest możliwe dlatego powstała potrzeba napisania prostego skryptu w python ktory zaprezentowałem powyżej. Same tagi były mi potrzebne do przygotowania wersji angielskojęzycznej filmu. Tak pobrałem film z Youtube i potem za pomocą aplikacji Captions przerabiałem go na wersję angielską i wrzucałem na drugi kanał. Tagi i inne mata dane opisowa również tłumaczyłem automatyzując cały proces do podania jedynie linku filmu. A cała magia działa się pod spodem za pomocą odpowiedniego połączenia polskiej wersji YouTube i jego odpowiednika w wersji angielskiej. Finalnie moje operacje zamykały się na jedynie opublikowaniu filmu po organoleptycznym przejrzeniu go. Binarke już dawno zastąpiłem yt-dlp nowsza wesją zgodną za youtube-dl pod względem składni. Więc tak naprawdę w systemie linux była to po prostu podmiana binarki i zmiana nazwy yt-dlp na youtube-dl by zmiana z punktu widzenia pipeline była jak najmniejsza. Pobieranie potrzebnych opisów tagów i meta tagów odbywała się w następujący sposób. Jak możemy zobaczyć pobieranie tagów realizowane jest przez skrypt: To już jego poprawiona wersja i biblioteka youtube-dl zastąpiona yt-dlp . Jak widać w jednym i drugim przypadku podmiana była dość organiczna i jedynie skupiała się na zamianie nazwy. Pobranie samego audio i zapisanie do do pliku odbywa się ze wskazaniem samego formatu audio - jak nie odniesiemy się do wariantu jakościowego formatu pobieranego. To youtube-dl lub jak przeszliśmy tak fajnie na yt-dlp pobierze nam najlepsza wersję. Z takiego audio łatwo zrobić transkrypcję za wykorzystaniem np wisper od open-ai Podsumowanie Obecnie wykorzystuje w pełni bibliotekę yt-dlp. I wygląda że zadomowi się u mnie na długo szczególnie za szybki czas rozwiązywania problemów. A ty jak wykorzystujesz wspomnianą bibliotekę? Spodobał się artykuł? podziel się nim na swoich social media - dziękuję i pozdrawiam Piotr Kośka.

W tym artykule porozmawiamy o repozytorium kodu, które pozwoli wam uruchomić i przetestować Jenkinsa w konfiguracji cloud. Całe środowisko bazuje na kodzie terraform wzbogaconego o konfigurację w cloud init. Pozwala to zautomatyzować konfigurację. Dodatkowe elementy sterujące są w plikach konfiguracyjnych json zawarte w tym repozytorium. Możesz też cała konfiguracje obejrzeć na moim kanale na youtube . Cała konfiguracja bazuje na kodzie terraform przygotowanym przezemnie tu https://bitbucket.org/szkoleniacloud/jenkins-lab-env-digitalocean/src/main/ Przechodząc do repozytorium musimy udać się do katalogu CloudConfigurations/DigitalOcean gdzie znajduje się nasz kod terraform. Pozwoli on uruchomić naszą konfigurację i dostarczyć dynamicznie środowisko do zabawy z jenkins. Środowisko takie możemy wykorzystać do nauki budowania i konfigurowania procesów CI/CD z wykorzystaniem Jenkins. Wiedzę w ten sposób zdobytą możemy przenieść na inne narzędzia CI/CD takie jak na przykład github actions , bitbucket pipeline , azure devops . Oczywiście nie jeden do jednego bo Jenkins charakteryzuje się swoją składnią dostępną w jenkinsfile . Jednak wszystko po kolei. Kod do uruchomienia Jenkins w Cloud Prezentowany kod uruchamia w chmurze digitalocean i aws konfiguracje którą, pozwala uruchomić Jenkins w konfiguracji master i slave w cloud. Na początku zanim uruchomimy nasz kod będziemy potrzebować konta w digitalocean i aws . Usługi płatne z których, będziemy korzystać to digitalocean droplet i aws route53. Cały kod uruchamiamy wydając polecenie terraform init, terraform plan, terraform apply oraz po skończonych testach terraform destroy - operacje te wydajemy w katalogu CloudConfigurations/DigitalOcean Klucze api do kont cloud w celu uruchomienia Jenkins Do korzystania z kodu będa nam potrzebne klucze api do wskazanych wyżej chmur aws i digitalocean . Klucze podamy w pliku .auto.tfvars (plik ten jest dodany w gitignore więc nie przejmuj się o przypadkowe umieszczenie ich w repozytorium). Plik wygląda w nastepującej postaci: Nasz aws_access_key i aws_secret_key wygenerujemy w konfiguracji naszego usera w serwisie IAM na koncie AWS . Wartość dla naszej zmiennej w do_token wygenerujemy logując się do naszego konta digitalocean Po wygenerowaniu kluczy API do AWS i Digitalocean dodajemy je w naszym pliku .auto.tfvars oraz uzupełniamy nasz adres email do powiadomień z let's encrypt. Wszystkie wymagane variables do wejścia do naszego kodu opisane są tu: https://bitbucket.org/szkoleniacloud/jenkins-lab-env-digitalocean/src/main/CloudConfigurations/DigitalOcean/Documentation.md Główna konfiguracja Jenkins w kodzie terraform. W konfiguracji wykorzystujemy dwa moduły które ułatwiają nam konfigurację. Jeden jest odpowiedzialny za sieć drugi za uruchomienie w tej sieci maszyny wirtualnej (dokładnie dwóch maszyn). Przeanalizujmy zatem konfiguracje tych dwóch modułów. Dzięki niemu mogę kontrolować stawiane sieci w ramach mojej konfiguracji środowiska Jenkins w cloud digitalocean . W bloku module odwołujemy się do: argumentu vpc_config gdzie możemy ustawić nazwę sieci, opis, nazwa konta, oraz drugi oktet naszej sieci. W części odpowiedzialnej za maszyny wirtualne mamy argumenty sterujące takie jak: jsonconfig - odpowiedzialny za konfigurację maszyny wirtualnej która, jest opisana w pliku json w katalogu files/json configs domain_name - nazwa naszej subdomeny / domeny w ramach której będę uruchamiać naszą konfigurację route53. vpc_uuid - tu odwołuję się do id sieci na której będę uruchamiał konfigurację (kluczem są dostępne regiony w digitalocean . user_data_file - to alternatywna konfiguracja naszego pliku cloud-init yaml gdy nie wskarzemy go w naszym pliku konfiguracyjnym json. Nasza konfiguracja w pliku json przedstawia się następująco - spójrzmy na plik: CloudConfigurations/DigitalOcean/_files/json_configs/jenkins.json W tym pliku wskazujemy parametry konfiguracyjne naszej maszyny wirtualnej takie jak: nazwa na która składają się pola user_name oraz name , obraz systemu pole image , region w którym zostanie uruchomiona maszyna wirtualna pole region (tu musimy nazwę regionu stawić taką samą jak klucz w identyfikatorze sieci) wielkość cpu i ramu w size (lista dostępnych compute na stronie digitalocean) vpc_uuid - jak chcemy uruchomić na innej sieci niż nasza user_data plik yaml z konfiguracją pochodzący z katalogu CloudConfigurations/DigitalOcean/_files/cloud-inits pola o wartości true/false takie jak: backups , ipv6, monitoring, resize_disk, droplet_agent tags - określający tagi dla maszyn wirtualnych uruchomionych phone_number - to pole odpowiada za hasło do maszyny wirtualnej gdy nie podamy klucza ssh do podłączenia. parametr ostatni agent steruje czy dodatkowy host slave ma zostać uruchomiony. Klucze publiczne które możemy dodawać do maszyn wirtualnych znajdziemy w CloudConfigurations/DigitalOcean/_files/ssh_keys/public_keys Konfigurację cloud init dla hostów Jenkins Master i slave znajdziemy w CloudConfigurations/DigitalOcean/_files/cloud-inits konfiguracja agenta przedstawia się następująco: Konfiguracja mastera w następujący sposób: Jak będziemy mieli ochotę możemy pobawić się w instalacje od zera naszego jenkinsa wtedy wybieramy plik konfiguracyjny dla naszego user_data CloudConfigurations/DigitalOcean/_files/cloud-inits/no_jenkins_docker_tf.tpl Jest też prosta konfiguracja firewall, która w razie potrzeb możemy edytować: Konfiguracja otwiera kilka portów i domyślnie śa to porty otwarte dla calego świata 0.0.0.0/0 - możemy to zmienić na własne adresy IP. Podsumowanie: W celu uruchomienia wydajemy polecenie terraform apply: Polecenie to tworzy nam Plan: 36 to add, 0 to change, 0 to destroy. Oczywiście zapraszam też do materiału wideo. Pozdrawiam Piotr Kośka.

Stwierdziłem, że zrobię porządki w mojej infrastrukturze 1.0 - tak ją nazwijmy. Wykorzystuje ją pod szkolenia, kursy i materiały wideo, które Tworzę oraz własne domowe/biznesowe konfiguracje. Głównie update dotyczy migracji z terraform state trzymanego w PostgresSQL . SQL był hostowany w lokalnej sieci. Cały pipeline miałem też napisany/stworzony na Jenkins więc było naturalnym procesem trzymać to lokalnie u siebie. Sam PostgresSQL jako remote backend spisywał się bardzo dobrze. Testowałem też wykorzystanie go jako serwisu w digitalocean jednak na dłuższą metę okazała się dość drogi - 5$ miesięcznie było zdecydowanie za drogo :) :). Tanio, taniej z terraform cloud Padło zatem na terraform cloud jako alternatywa dla PostgresSQL. Plusy jakie do mnie przemawiały to: Wersjonowanie automatyczne state z dość łatwą historią zmian do przeglądu. Łatwa integracja z GIT (Github, bitbucket, gitlab) . Automatyzacja wbudowana - tu pragnę zaznaczyć, że mamy do wyboru trzy podejścia. Pierwsze to pełna integracja z terraform cloud - gdzie finalnie apply wykonujemy tylko po stronie cloud. Opcja druga mieszana, akcje możemy wykonywać po stronie terraform cloud i lokalnie. Opcja trzecia - tylko state po stronie terraform cloud. Przy wyborze opcji pierwszej mamy mini CI/CD z kontrolą przepływu pracy z terraform i akceptacji lub pełnej automatyzacji dla naszych akcji apply. Terraform cloud - historia state Historia zmian jest naprawdę fajna widać kto co zrobił oraz masz przypisany state file do tego wydarzenia więc nawet na upartego możesz zrobić sobie diff na dwóch plikach i zobaczyć różnice. No i pełni to też rolę takiego prostego backupu. Oczywiście go nie zastępuje i warto w swoich konfiguracjach dodatkowo wdrożyć kwestie wykonania backupu. Terraform backend - tworzenie i automatyzacja. Terraform cloud jest fajny i wygodny jednak darmowa wersja posiada limit 500 zasobów. I to 500 zasobów na wszystkie resorces i data uruchomione w ramach naszego state łącznie na wszystkich workspace. Podział na workspace development, staging i production Dla tego wychodzi nieco ponad 150 zasobów per workspace. To troche mało, szczególnie że kiedyś było to bez ograniczeń. A później płacimy za godzinę działania każdego naszego zasobu powyżej. Oczywiście pierwsze 500 jest za darmo, ale po więcej szczegółów odsyłam do cennika . Jednak ja do mojego malutkiego projektu wykorzystuje terraform cloud. W którym to trzymam konfiguracje moich backendów dla innych projektów. A te backendy leżą na S3 . obecnie mam działających 36 zasobów więc daleko mi jeszcze do wspomnianego limitu. Jak go przekroczę będzie wtedy artykuł o migracji z terraform cloud do innego state backend :) S3 jako backend terraform S3 to wybór pokierowany znów cebulą, ponieważ trzymanie terraform.tfstate na platformie AWS jest bardzo tanie w porównaniu do digitalocean postgresql (zgroza 5$ mc) i naszym terraform cloud. Dodam kolejnego cebula hint że w przypadku gitlab mamy możliwość trzymania naszego state w gitlab za pomocą http backend - fajne rozwiązanie :). Wrócę jednak do S3. Powstał dość prosty kod który na podstawie poniższego wkładu: Tworzy mi konfiguracje na koncie AWS w postaci konta użytkownika AWS programistyczny access, Serwis S3 Bucket, Plus odpowiednie uprawnienia - tylko dla tego usera do jego części plików powiązanych z jego terraform state. Tak, w większości moich domowych projektów ja jestem głównym adminem i operatorem. Pomimo tego wychodzę z założenia by tworzyć usera który, ma ograniczone uprawnienia a nie że, widzi wszystko na poziomie admina. Reasumując user ma czytać i zapisywać na S3 to ma tylko takie uprawnienia i to też do swojej przestrzeni - nie pisząc i nie odczytując innych plików w S3. I tak prostym kodem terraform tworzę S3 oraz dynamoDB , które to pozwala mi przechowywać mój terraform state w bezpiecznym i kontrolowanym miejscu: Powiązanie zasobów i szczegółowy opis ich działania Kod Terraform tworzy ekosystem zarządzania stanem Terraform w chmurze AWS, obejmując zasoby S3 (do przechowywania stanu) oraz DynamoDB (do zarządzania blokadami stanu). Poniżej przedstawiam działanie poszczególnych zasobów i ich zależności. 1. random_string - Generowanie unikalnego identyfikatora Co robi:  Generuje losowy ciąg znaków, który może być użyty jako część nazwy bucketu S3. Zapewnia unikalność nazw bucketów (wymagane przez AWS, ponieważ nazwy bucketów muszą być globalnie unikalne). 2. aws_s3_bucket - Główne przechowywanie stanu Terraform Co robi:  Tworzy bucket S3, w którym przechowywany będzie plik stanu Terraform, oczywiście nie dla aktualnego kodu - ten działa na terraform cloud. To tworzy sie nasz state dla innych moich integracji. 3. aws_s3_bucket_public_access_block - Blokada publicznego dostępu Co robi:  Blokuje publiczny dostęp do bucketu, ustawiając zasady ograniczające publiczne ACL, polityki i dostęp. 4. aws_s3_bucket_versioning - Wersjonowanie bucketu Co robi:  Włącza wersjonowanie obiektów w bucket S3. Dzięki temu zmiany w pliku stanu Terraform są archiwizowane, co pozwala na przywracanie wcześniejszych wersji. Automatyczny backup to lubię :) 5. aws_s3_bucket_lifecycle_configuration - Zarządzanie cyklem życia danych Co robi:  Automatycznie usuwa starsze wersje obiektów po 10 dniach. Zmniejsza to koszty przechowywania przy zachowaniu dostępu do najnowszych danych. Cały czas mam aktualny stan plus ewentualną zmianę - w moim przypadku ta wartośc mi zupełnie wystarcza :) 6. aws_s3_object - Tworzenie struktury katalogów Co robi:  Tworzy strukturę katalogów w bucket S3 na podstawie listy projektów (local.buckets). Każdy projekt otrzymuje swój katalog, co ułatwia zarządzanie plikami stanu w środowiskach wieloprojektowych. 7. aws_s3_bucket_policy - Polityka dostępu Co robi:  Definiuje politykę dostępu do bucketu, zezwalając użytkownikowi deployer-terraform na wykonywanie operacji takich jak odczyt, zapis i usuwanie plików. 8. aws_dynamodb_table - Tabela do zarządzania blokadami Terraform Co robi:  Tworzy tabelę DynamoDB służącą do zarządzania blokadami Terraform. Każda blokada jest identyfikowana przez LockID. Powiązania między zasobami Bucket S3:  Wszystkie zasoby związane z bucketem (aws_s3_bucket_public_access_block, aws_s3_bucket_versioning, aws_s3_bucket_lifecycle_configuration, aws_s3_object, aws_s3_bucket_policy) są powiązane z aws_s3_bucket.terraform_state. DynamoDB:  aws_dynamodb_table.terraform_lock jest niezależnym zasobem, ale powiązanym z backendem Terraform jako mechanizm blokady. Użytkownik IAM:  Polityka bucketu (aws_s3_bucket_policy) umożliwia użytkownikowi deployer-terraform dostęp do zarządzania plikami stanu. Kod tworzy infrastrukturę, która umożliwia: Przechowywanie stanu Terraform w bucket S3 z wysokim poziomem bezpieczeństwa. Zarządzanie wersjami plików stanu i ich cyklem życia. Blokowanie równoczesnych modyfikacji stanu za pomocą tabeli DynamoDB. Powiązanie zasobów gwarantuje, że system jest spójny, wydajny i łatwy w utrzymaniu. A tu jeszcze szybka konfiguracja iam usera : Analiza kodu Terraform: Automatyzacja zarządzania użytkownikami IAM dla projektów Terraform Kod przedstawia konfigurację Terraform, która tworzy użytkowników IAM, przypisuje im polityki dostępu i generuje klucze dostępowe dla zarządzania zasobami Terraform. 1. Tworzenie użytkowników IAM (aws_iam_user) Co robi: Tworzy użytkowników IAM dla każdego projektu w liście local.buckets. Nazwa użytkownika:  Składa się z nazwy użytkownika dla projektu (local.buckets[count.index].user_name) i identyfikatora konta AWS, co zapewnia unikalność. Tagi:  Użytkownicy są oznaczani identyfikatorem konta oraz środowiskiem (var.enviroment) w celu łatwego zarządzania i identyfikacji. 2. Przypisywanie polityki IAM (aws_iam_user_policy) Co robi: Tworzy politykę IAM dla każdego użytkownika z uprawnieniami do zasobów S3 i DynamoDB : S3:  Użytkownicy mogą: Pobierać obiekty (s3:GetObject). Umieszczać obiekty (s3:PutObject). Listować zawartość bucketu (s3:ListBucket). Uprawnienia ograniczono do konkretnego katalogu (terraform/${local.buckets[count.index].catalog_project_name}) w bucket S3. DynamoDB:  Użytkownicy mogą: Pobierać, dodawać, aktualizować, usuwać elementy oraz opisywać tabelę (dynamodb:*Item, dynamodb:DescribeTable). Dostęp jest ograniczony do tabeli blokad Terraform (local.aws_dynamodb_lock_table). Nazwa polityki:  Zawiera nazwę projektu z listy local.buckets. 3. Tworzenie kluczy dostępowych (aws_iam_access_key) Co robi: Generuje klucz dostępu (Access Key ID) i klucz tajny (Secret Access Key) dla każdego użytkownika. Klucze są wykorzystywane do autoryzacji przez Terraform lub inne narzędzia zarządzające infrastrukturą. Przykład działania Dla listy local.buckets zawierającej dwa projekty: Terraform utworzy: 1. Dwóch użytkowników IAM: user1-{account_id} user2-{account_id} 2. Dwie polityki IAM: tf_project1 przypisaną do user1. tf_project2 przypisaną do user2. 3. Dwa zestawy kluczy dostępowych: Jeden dla user1. Drugi dla user2. Korzyści z podejścia Bezpieczeństwo: Uprawnienia są ograniczone do zasobów specyficznych dla projektu. Użytkownicy nie mają dostępu do innych katalogów w bucket S3 ani do innych tabel DynamoDB. Automatyzacja: Dynamiczne tworzenie użytkowników, polityk i kluczy na podstawie listy projektów eliminuje potrzebę ręcznego zarządzania tożsamościami. Skalowalność: Możliwość łatwego dodawania nowych projektów do local.buckets bez konieczności modyfikowania kodu. Kod tworzy dynamiczny system zarządzania dostępem do zasobów AWS dla wielu projektów Terraform. Dzięki ścisłej kontroli dostępu użytkownicy mogą zarządzać jedynie zasobami swojego projektu, co zwiększa bezpieczeństwo i porządek w środowisku AWS. Idąc dalej. Cała moja konfiguracja po przez outputs terraform zwraca oczekiwane przeze mnie informacje. W następującej postaci: Jak możemy zaobserwować dostaję konfigurację w HCL dla mojego S3 backendu którą można wykorzystać w następujący sposób: lub jako plik HCL includowany (ja tak to wykorzystuje) do konfiguracji po przez polecenie terraform init -backend-config=backend.hcl. Więcej można przeczytać na stronie dokumentacji terraform odnośnie s3 . Finalnie moja deklaracja konfiguracji backendu sprowadza się do prostego backend "s3" {}: A tutaj rezultat działania kodu i użytkownicy IAM, policy i s3 bucket Zimowe porządki na digitalocean z terraform I tak, stanąłem przed migracją moich narzędzi z jednego stanu do drugiego. Ogólnie są dwa podejścia szybkie i dłuższe. W obu nie ma znaczenia gdzie masz state (choć przy pierwszej metodzie jak masz terraform state w terraform cloud to ma to znaczenia :) - o tym w prezentowanych przykładach ). Terraform state migracja metoda 1 Pierwsza metoda jest szybka i obejmuje następujące kroki. Krok pierwszy to jeszcze na starym terraform state wykonujemy: terraform init terraform plan terraform apply I jak krok pierwszy pokaże nam 0 add, 0 change, 0 destroy - to znaczy że możemy działać Krok drugi to zmiana konfiguracji w naszym pliku na nowy state co zamyka się zazwyczaj do zmiany info o backend, czyli u mnie było to zmiana z backend "pg" na backend "s3" Krok trzeci przez polecenie terraform init które to wykryje zmianę backendu i zapyta o migrację - wybieramy odpowiedz żę chcemy dokonac migracji. Krok czwarty wydajemy polecenie terraform plan i potem terraform apply i jak pokarze 0 add, 0 change, 0 destroy to jestesmy w domu i mamy zmigrowany terraform state do nowej lokalizacji (czytaj backendu). Mała uwaga w przypadku gdy naszym starym backendem jest terraform cloud i chcemy zmienić go na inny to musimy wykorzystać metodę numer 2 ponieważ otrzymamy komunikat w konsoli, że automatyczna migracja z terraform cloud do innego backendu nie jest wspierana - cwaniacy :) Terraform state migracja metoda 2 Metoda w działaniu jest podobna, ale to my wykonujemy wszystkie operacje: Krok pierwszy - jest podobny jak w metodzie numer 1, a mianowicie na naszym starym backend wydajemy polecenia: terraform init terraform plan terraform apply I jak krok pierwszy pokaże nam 0 add, 0 change, 0 destroy - to znaczy że możemy działać Krok drugi - jeszcze jedną operację musimy wykonać na naszym starym state wydajemy polecenie: terraform state pull > backup_nasz_state_plik W ramach kroku drugiego wykonaliśmy backup naszego stanu. Jest to kopia 1:1 i jak teraz nie dodamy, nic nie wykonamy, żadnych zmian i nie usuniemy żadnego resorces i data to możemy ją otworzyć bez przeszkód. Krok trzeci zmiana konfiguracji backend - czyli backend "pg" zmieniam na backend "s3". Krok czwarty - olewam informacje o automatycznej migracji do nowego (w przypadku terraform cloud musimy olać bo dostaniemy komunikat że migracja automatyczna nie jest wspierana) Krok piąty - wydajemy terraform init z nowym backend i terraform plan. Jeżeli krok piąty pokaże nam XXX Add, 0 change, 0 destroy to znaczy że działamy już na nowym backend tylko jeszcze nie mamy danych ze starego. Krok szósty - nie wykonujemy terraform apply, tylko wracamy do polecenia terraform state: terraform state push -force /scieżka/do/pliku/z/backup Nasz backup wgra się na nowy backend. Krok siódmy - wydajemy polecenia: terraform plan terraform apply I jak krok siódmy zwróci nam 0 add, 0 change, 0 destroy to jesteśmy w domu i mamy zmigrowany nasz state. Teraz wystarczy w moich pipeline powymieniać sekrety tak byśmy mogli też w nich korzystac z naszego nowego backendu. Dlatego ja preferuje plik backend.hcl jako miejsce gdzie przekazujemy konfiguracje potrzebna do naszego terraform init. Po prostu podmieniamy jego zawartość i wszystko działa bez zmiany kodu pipeline. Terraform z Jenkins freestyle, Jenkins Pipeline, Github Actions, Bitbucket pipeline. Zacznę omawiać ten przykład od bitbucket bo tu mam prosta konfigurację modułu w terraform. Moduł ten odpowiada za tworzenie sieci w digitalocean. Geneza jego powstania jest prosta. W digitalocean można utworzyć zasoby bez VPC. Tzn nie można tak do końca bo i tak zostanie ta sieć utworzona. Tylko, że z domyślnymi parametrami takimi jak losowy adres sieci i cidr, nazwa. Co może prowadzić do bałaganu. A szczególnie jest niepożądane gdy tworzymy coś za pomocą terraform. Ponieważ tworzy nam się obiekt którym nie zarządzamy przez terraform. I po destroy zostają śmieci, które musimy usunąć ręcznie. Z racji na moje doświadczenia w pracy z digitalocean preferuje konfiguracje sieci domyślnej dla wszystkich 14 regionów. gdzie poszczególne numery odpowiadają trzeciemu oktetowi w konfiguracji sieci 10.X.Y.0/20 gdzie Y to wartości z regions - czyli 10.254.0.0/20 następny 10.254.16.0/20 i tak dalej. Oczywiście jak ktoś uważa że taka sieć jest za duża jako sieć testowa to można zmniejszyć tylko pamiętajmy że jesteśmy ograniczeni między cidr /16 a /24 Finalnie otrzymujemy taką konfigurację. Terraform i bitbucket Spójrzmy na moduł do tworzenia sieci w digitalocean dostępny pod adresem: https://bitbucket.org/helppointit/default_digitalocean_vpc/src/main/ Który to stworzył mi konfigurację sieci pokazywaną na zrzucie ekranu powyżej. Przeanalizujmy wspólnie nasze pliki terraform które razem składaja się na moduł: version.tf - tu mamy nasza podstawową deklaracje która powinna pokazać się w każdym module. Więc informacja o używanej minimalnej wersji terraform oraz wykorzystanych providerów i ich minimalnej wersji. variables.tf - tu deklaruję wejścia do modułu. Czyli będą to argumenty sterujące modułem. Dodałem też walidacje wprowadzanych danych tak by adresacja była zgodna z standardem RFC i działała tylko na regionach dostępnych w digitalocean main.tf - nasz głowny kod realizuje konfigurację i zbaerający nasze argumenty. Finalnie otrzymujemy naszą sieć na podstawie wkładu dostarczonego do modułu. outputs.tf - informacja o utworzonych sieciach Mamy jeszcze ReadMe.md , Documentations.md i katalog tests w ktorym mamy prosty scenariusz testowy. Mamy jeszcze nasz plik bitbucket-pipelines.yml a w nim konfiguracje naszego pipeline do testów automatycznych naszego modułu. Wykonania każdego commita możemy obserwować tu: https://bitbucket.org/helppointit/default_digitalocean_vpc/pipelines Zapraszam do korzystania z modułu. Terraform Jenkins freestyle jobs Spójrzmy teraz na konfigurację workflow który realizuje moj terraform init, plan, apply - czyli wdraża całą konfigurację. Workflow działa w następujący sposób : commit lub zmian w kodzie triggeruje terraform-check poprawnie zakończony terraform-check triggeruje terraform-plan poprawnie wykonany terraform plan triggeruje terraform apply terraform-check - za pomocą terraform validate i terraform fmt sprawdzam kod, czy jest poprawny i dobrze sformatowany. Oczywiście te sprawdzenia to w takiej podstawowej formie poprawności składni i dobrego formatowania według formatu kanonicznego terraform. Workflow jest wyklikany w freestyle job zatem podrzucam tylko konfiguracje bash skryptu. Który korzystając z docker i kontenera z terraform dostarcza mi narzędzie bez konieczności go instalowania. terraform-plan - tu zadaniem tego joba jest dostarczenie naszej konfiguracji, a dokładnie jego planu. Job wykona się jak poprzedni nasz check przejdzie poprawnie. Plan zapisuje do pliku który potem wykorzystuje w następnym jobie z terraform apply. W kroku tym dodatkowo też generuje za pomocą tf-summarize bardziej zwięzłe i skondensowane informacje o zaplanowanej konfiguracji. W moim odczuciu tf-summarize generuje lepsze podsumowanie niż sam terraform plan. terraform-apply - tu już pracujemy na ukierunkowanym planie z poprzedniego joba. Który jak wykona się poprawnie generuje nam tfplan. Ten plan wykorzystujemy w tym jobie Dodatkowe konfiguracje czyli: terraform output terraform state show terraform-taint terraform-untaint trivy-check terraform-output - informacja, prezentacja danych z którymi się dzielę. Na przykład informacja o adresach hostów dla moich kursantów w ramach szkolenia prowadzonego z Terraform , Jenkinsa czy Proxmox terraform-state-show - jak sa problemy z jakiś zasobem użytkownika to szybko uzyskuje dostęp do tych zasobów. A dokładnie jego nazwy i mogę ją wykorzystać w taint jobie terraform-taint - job do ponownej konfiguracji problematycznego hosta, zasobu itp. terraform-untaint - jak poprzednio tylko ściąga ten taint trivy-check - to już dodatkowa walidacja bezpieczeństwa konfiguracji z trivy . Terraform Jenkins pipeline Przełożenie tego workflow skonfigurowanego w freestyle job na konfigurację jenkinsfile z Jenkins Pipeline . Zamieniamy elementy wyklikany z poprzedniego kroku na element dostarczany w kodzie :). Terraform Github Actions pipeline Przełożenie na github actions naszego poprzedniego workflow dostepnego w Jenkins freestyle i jenkinsfile. U mnie github wykorzystuje jako backup. Czyli głównie jobami zarządza jenkins. Jak Jenkins ma awarię to triggeruje joba w github actions. Moj biznes zachowuje ciągłość a w wolnym czasie naprawiam problemy z Jenkins. Oraz dodatkowe konfiguracje które uważam że pomagają podczas pracy z terraform. Moj terraform output - informacja o wszystkich lub konkretnym naszym output wyświetlana w github actions. Terraform Lock ID - czasem lock nasz zostanie osierocony, i lokalnie nie chce mi się podłączać backendu z sekretami i ściągać blokadę. Wykorzystuje do tego joba dostarczając mu ID blokady Terraform State List - lista zasobów przydaje sie do taint lub untaint Terraform taint/untaint - czasami zdarzają się problemy z zasobami i trzeba je raz jeszcze skonfigurować więc znów warto mieć takiego joba pod ręką. Podsumowanie Migracja terraform state z jednej konfiguracji na drugi backend jest bardzo prosta. Pokazałem Ci jak ja to zrobiłem na przykładzie swoich konfiguracji. Pamiętaj że ten sposób migracji a dokładnie metodę numer 2 możemy wykorzystać do debugowania lokalnego naszego terraform - ale o tym może już w innym artykule. Na koniec TY jakiego backendu używasz najczęściej w konfiguracji? Pozdrawiam Piotr Kośka.

Zadajmy sobie pytanie czym jest wirtualizacja w świecie IT oraz do czego ją możemy wykorzystać. Jakie zalety i korzyści to nam przynosi. Co należy wiedzieć decydując się na wirtualizację serwerów. Na te i inne pytania odpowiem w poniższym artykule - zapraszam Co to jest wirtualizacja oraz maszyna wirtualna Oczywiście najprostszą odpowiedzią może być wpisanie w Google lub zadanie pytania tego w ChatGPT i uzyskamy szybko informację. Ale skoro trafiłeś na ten artykuł pozwolę sobie wyjaśnić ci czym jest wirtualizacja na bazie prostego przykładu. Wyobraźmy sobie budynek mieszkalno usługowy może on być podobny do prezentowanego poniżej przykładu. W budynku takim może mieszkać wiele rodzin, mogą być też lokale usługowe. Prywatne pomieszczenia wydzielone nazywamy lokalami, tak jak wspomniałem mogą one być mieszkalne lub usługowe. Mogą też być piwnice lub garaże, miejsca parkingowe. Do budynku podłączone są różne media jak prąd, woda, kanalizacja, dostawcy internetu, telewizji. Dostępne też są wspólne ciągi komunikacyjne takie jak klatka schodowa, pralnia, wózkownia, droga dojazdowa do garaży. Teraz nasz budynek mieszkalny zamieńmy na komputer. W środku mamy nasz CPU, RAM, DYSK, kartę sieciową, karte graficzną - to są nasze wspólne media. Możemy je podzielić na mieszkania - czyli nasze maszyny wirtualne i ograniczyć lub przydzielić im zasoby w postaci liczników czy indywidualnych umów z naszym operatorem internetowym, gazowym, itp. Wirtualizacja a wykorzystanie zasobów Deweloper gdyby miał większą działkę mógłby wybudować dla każdej rodziny osoby dom mieszkalny. Jednak dostał on działkę na której może jedynie wybudować blok wielorodzinny by odpowiedzieć na zapotrzebowanie na mieszkanie dla 100 rodzin. I tak samo działa wirtualizacją odpowiadając na nasze potrzeby optymalnego wykorzystania zasobów działających w naszej firmie w postaci środowiska IT i uruchomionych naszych konfiguracji. Przykładowo dla komputera który ma 128 GB RAMU 24 rdzeniowy CPU uruchomienie prostej strony www która codziennie będzie obsługiwała do 30 tysięcy osób było by złym wykorzystaniem zasobów. Zapewne komputer o mniejszej specyfikacji poradziłby sobie z tym zadaniem równie dobrze. Dlatego tak jak deweloper nie możemy pozyskać większej działki (dodatkowych fizycznych komputerów) by wybudować pojedyncze domy (uruchomić nasze konfigurację systemów operacyjnych). Musimy wykorzystać to co mamy by uruchomić "100 naszych różnych aplikacji". Z pomocą przychodzi nam wirtualizacja, i podobnie jak deweloper będziemy w ramach jednego bloku (komputera), wydzielać mieszkania (uruchamiać maszyny wirtualne). Wirtualizacja i maszyna wirtualna Przekładając ten przykład na nasze środowisko IT w firmie czy domu. Mamy za zadanie uruchomić w ramach dostępnego komputera dodatkowe konfiguracje naszych aplikacji, które będą działać na naszym komputerze. Patrząc na nasze aplikacje to przecież na jednym komputerze z przykładowym systemem operacyjnym z rodziny Linux jesteśmy w stanie uruchomić różne aplikacje (www, bazę danych, pocztę, komunikator, serwer logów, itp). I tu zgodza w 100%. Ale co gdy chcemy uruchomić tą sama aplikację tylko w różnych wersjach i w dodatku na tym samym porcie komunikacyjnym. Wirtualizacja rozwiązuje nam ten problem. Na przykład użytkownik domowy chce sprawdzić czy jego aplikacja będzie działać na systemie windows 12. A posiada zainstalowany system WIndows 11. Czy jest zobligowany do tego by kupić nowy komputer i tam zainstalować Windows 12 i potem uruchomić aplikację? Nie. nie musi kupować nowego komputera - na swoim systemie z Windows 11 uruchomi oprogramowanie do wirtualizacji które pozwoli mu zainstalować Windows 12. Będzie ono działać na zasobach którymi dysponuje Windows 11, a zarazem z punktu widzenia aplikacji system z Windows 12 będzie "osobnym komputerem" - bo tak naprawdę będzie maszyną wirtualną. Takie oprogramowanie które nam pomoże to osiągnąć to VirtualBox, Hyper-V, VMWare (oczywiście jest więcej - to tylko przykłady). W scenariuszu biznesowym na przykład zajdzie potrzeba zarobienia kopii zapasowej całej konfiguracji systemu operacyjnego i aplikacji działającej w systemie operacyjnym. Zrobienie kopii zapasowej i późniejsze jej odtworzenie na nowej maszynie może być problematyczne z wielu względów. Na przykład nie kompatybilność sterowników, bo sprzęt fizyczny który kupimy może bazować już na innych komponentach. Czas związany z odtworzenie i przygotowanie fizycznym naszego nowego komputera. W środowisku gdzie mamy wdrożoną wirtualizację na przykład z wykorzystaniem Proxmox możemy włączyć replikację, czy też kopie zapasową. Kopia ta wykona migawkę naszej maszyny wirtualnej. A odtworzenie takiej migawki to kilka sekund i nasze środowisko dokładnie działa tak jak w momencie zrobienia migawki. Maszyna wirtualna to tak naprawdę zbiór plików konfiguracyjnych, które symulują przykładowa dysk, ram, cpu i pozwalają uruchomić daną konfigurację. Zatem wykonanie kopii tych plików i ich odtworzenie jest znacznie prostsze i czasowo krótsze niż przygotowanie czystej konfiguracji nowego fizycznego komputera. Konfigurowanie na nowo maszyn wirtualnych też jest prostsze i możemy cały proces zautomatyzować Tworząc sobie wcześniej przygotowane obrazy z naszą docelowa konfiguracją tzw template. I wykorzystywać je w późniejszych konfiguracjach nastawionych na inne aplikacje. Oczywiście musimy pamiętać że w przypadku maszyn wirtualnych istnieją ograniczenia w postaci naszego fizycznego środowiska. Nie przydzielimy więcej miejsca niż fizycznie mamy go na dysku. RAM też może się skończyć i jak przydzielimy go za dużo źle to obliczając to nasza maszyna wirtualna się nie uruchomi. A jak operacji będzie za dużo to nasz procesor zwolni co będzie miało wpływ na inne maszyny wirtualne. Wirtualizacja – czy warto? Wirtualizacja komputerów lub serwera staje się bardziej powszechnym działaniem. Jeżeli chcesz sprawdzić, jak działa inny system operacyjny niż ten, na którym obecnie pracujesz (zakładamy, że jest to Windows) – zamiast kupować osobny komputer, za pomocą odpowiedniego oprogramowania tworzysz wirtualną maszynę, na której instalujesz dany system. Kiedy uznasz, że czas kończyć „zabawę” – usuwasz wirtualizację. To najprostszy przykład wykorzystania wirtualizacji. Co można wirtualizować Procesowi wirtualizacji można poddać: Serwer Sieć Aplikację Pamięć masową Jakie są zalety wirtualizacji? Dużą zaletą wirtualizacji jest obniżenie kosztów: Stworzenia i utrzymania sieci i infrastruktury IT Zakupu dodatkowych serwerów Serwisowania sprzętu Przeznaczasz środki na zakup jednego, wydajnego serwera zamiast kilku. Jest to duża oszczędność, gdyż każdy serwer wymaga nie tylko dostępu do sieci elektrycznej oraz sieci Internet, ale również zabezpieczeń przed spadkiem / przeciążeniem sieci energetycznej (zasilacze UPS), wymiany dysków (każdy dysk określony czas przydatności do użytku, a w przypadku dysków SSD ograniczoną ilość operacji zapisu/odczytu danych) czy kości pamięci RAM. Ponadto należy pamiętać o kopiach zapasowych dla każdego serwera, które również wymagają zasobów w postaci powierzchni dyskowej. Wprowadzenie wirtualizacji, w zależności od ilości serwerów, potrafi przynieść oszczędność nawet kilkunastu tysięcy złotych skali całego roku. Wirtualizacja umożliwia: wykorzystanie starszych aplikacji na nowym sprzęcie instalacje różnych systemów operacyjnych na komputerze, jak i serwerze. Podsumowanie Wirtualizacja to zatem technologia która, pozwala nam w ramach jednego fizycznego komputera z dowolnym systemem operacyjnym uruchomić inny system operacyjny. Na rynku można spotkać kilka rozwiązań oferujących wirtualizację. Jedne będą nadawać się tylko do zastosowań domowych , inne do biznesowych. Na pewno na uwagę zasługuje proxmox dostarczający platformę do wirtualizacji którą można uruchomić w domu i w firmie. Jak to zrobić przeczytasz na tej stronie w innych artykułach lub dowiesz się tego z szkolenie Proxmox . Zapraszam

Humble Bundle ponownie oferuje zestaw książek “Become a Python Expert” od wydawnictwa Pearson. Ten pakiet zawiera szeroki wybór e-booków, które pomogą zarówno początkującym, jak i zaawansowanym programistom opanować język Python. Oferta jest dostępna przez ograniczony czas, a część dochodów zostanie przekazana na cele charytatywne. To doskonała okazja, aby poszerzyć swoją wiedzę z zakresu programowania w Pythonie i jednocześnie wesprzeć potrzebujących. https://www.humblebundle.com/books/become-python-expert-pearson-books-encore

Hej. Przed warsztatami które odbęda się 27.11.2024 zapraszam na obejrzenie poprzedniej edycji na której skonfigurowaliśmy za pomoca terraform w cloud digitalocean nasza maszyne wirtualną. Na tej maszynie wirtualnej za pomocą KVM i zagnieżdżonej wirtualizacji uruchomiliśmy klaster proxmox 3 węzły. Na warsztatach uczestniczyło ponad 200 osób które, w tym samym czasie konfigurowały i testowały ustawienia klastra proxmox. Konfiguracja Klastra 3 węzły, Konfiguracja sieci, Konfiguracja Ceph, Konfiguracja NFS, Konfiguracja Template dla maszyny wirtualnej, Uruchomienie maszyny wirtualnej. Poniżej znajdziesz materiały do obejrzenia na platformie youtube - podzielone za wskazane na powyższej liście sekcje: Całe środowisko można uruchomić za pomocą tego kodu: https://bitbucket.org/szkoleniacloud/proxmox_digitalocean_terraform_configuration/src/main/ Terraform init, plan apply - a po zabawie destroy. W pierwszym filmie robimy wprowadzenie do naszego środowiska. W materiale drugim omawiam konfiguracje sieci i serwera DHCP skonfigurowanego na hoscie pod nasze hosty dla KVM oraz konfigurację dodatkowe bridge pod ruch wydzielony dla klastra proxmox i ceph. Tworzymy konfiguracje naszego klastra 3 wezłowego W materiale czwartym tworzymy konfiguracje CEPH w naszym klastrze proxmox i dodajemy nasze OSD na dyskach dodatkowych utworzonych z naszego skryptu. W ramach OSD tworzymy pulę która, udostępni nasz storage w ramach konfiguracji klastra. Teraz czas wykorzystać nasz klaster i uruchomić maszynę wirtualną z stworzonego i przygotowanego template w ramach konfiguracji cloud init. Dodatkowo konfigurujemy dodatkowy storage w postaci NFS - też uruchomiony w naszej automatyzacji. Finalizacja całości - nasza maszyna wirtualna z template. A na koniec sesja pytań i odpowiedzi - Zapraszam.

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.