Search Results

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

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

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

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

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

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

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

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

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

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

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

Hej. Osoby które należą do grupy LinuxPL na Facebook znają mnie właśnie z tej grupy gdzie dzielę się na niej informacjami i artykułami o rożnych technologiach z tematyki Linux, OpenSuorce, Automatyzacji, Konteneryzacji i Wirtualizacji. Zostały dodane nowe grupy tematyczne w celu ułatwienia aspektu dzielenia się wiedzą, oto dostępne grupy tematyczne: Od Zera do Bohatera - Od Zera do Bohatera - Grupa dla użytkowników początkujących - tematyka szeroka Linux, Automatyzacja, CI/CD, Windows Ogólnie o IT. GCP PL - GCP PL - Google Cloud Computing - Grupa dla pasjonatów rozwiązania Cloud od Google. www.facebook.com/groups/gcppl/ Azure PL - Azure PL - Grupa dla użytkowników rozwiązań cloud Azure. www.facebook.com/groups/azurepl/ AWS PL - AWS PL - Grupa dla Użytkowników rozwiązań Cloud od Amazona. www.facebook.com/groups/awspl/ Automatyzacja zadań w IT - Automatyzacja w IT - procesy CI/CD, zapytania o systemy Jenkins, TeamCity, Github acction, bash, ansible i podobne. www.facebook.com/groups/automatyzacjaitpl/ Cloud - Cloud PL - chmura publiczna i prywatna - Temty związane z chmura publiczna i prywatną. www.facebook.com/groups/cloudpl/ Digital Ocean PL - DigitalOcean PL - Wszystko o Digital Ocean. Konfiguracje rozwiązania itp. www.facebook.com/groups/digitaloceanpl/ Terraform PL - Terraform PL - O terraformie po polsku. Automatyzujesz konfiguracje chmury, to grupa dla Ciebie. www.facebook.com/groups/terraformpl/ Proxmox PL - PROXMOX PL - o popularnej wirtualizacji po polsku. Konfiguracje, how to, rożne triki. www.facebook.com/groups/proxmoxpl/ Ansible PL - Ansible PL - jedno z lepszych (moim zdaniem ) narzędzi jeżeli chodzi o automatyzacje konfiguracji na systemach operacyjnych. www.facebook.com/groups/ansiblepl/ Jeżeli należysz do Grupy LinuxPL - twoje zgłoszenie do wyżej wymienionych grup zostanie przyznane automatycznie. Zapraszam.

Hej to drugi wpis o moim klastrze proxmox. Składa się on z trzech węzłów bare metalowych hostów i jednego hosta NAS Synology. W całej tej konfiguracji NAS Synology pełni rolę dysku sieciowego oraz swoisty poligon dla testów network storage. O pełnej specyfikacji moich urządzeń poczytać możesz w pierwszej części serii proxmox. [Zdjęcie klastra proxmox] [Zdjęcie Synology] Powyżej te dwa zdjęcia prezentują mój klaster. Tak jak wspomniałem projekt jest mocno "chałupniczy". Nie mam dedykowanego jednego miejsca w domu gdzie mógłbym umieścić te wszystkie urządzenia. Jednak gdybym miał go rozrysować, rozrysował bym to w ten sposób. Jak możemy zobaczyć mój klaster składa się z trzech węzłów na których działa lokalny storage w postaci LVM (przestrzeń dla obrazów ISO) i LVM-Thin (przestrzeń dla maszyn wirtualnych). Sieciowo jest dostępny Storage w postaci NFS i SMB dostępne z serwera NAS z RAID 5. Gdybym miał pokazać jak widoczne są te przestrzenie to one widoczne są na poziomie klastra. Nasz rysunek zmienił by się troszkę i teraz wyglądałby tak: Widzimy teraz że oprócz przestrzeni dyskowej lokalnej mamy też przestrzeń dyskową sieciowa która jest dostępna na poziomie klastra a zatem jest dostępna dla wszystkich węzłów w klastrze. W poprzednim materiale umieszczając ISO w lokalnym storage ten ISO nie był dostepny dla innego węzłą. Zatem poprawie to i przerobie ta konfigurację. Usuńmy nasze ISO i wygrajmy je na nasz dysk sieciowy. Oczywiście tylko musze dodać możliwość dodawania iso na tym storage, a robi się to w ten sposób. Przechodząc do menu klastra w moim przypadku jest to Datacenter (HomeProxmox) potem na Storage -> Add i z listy rozwijanej wybieramy NFS. W konfiguracji NFS ustawiam nazwę (unikatową w skali całego klastra dla pola ID). Serwer adres nfs.koska.in (zmień na swój). Export - jak uda Ci się podłączyć do serwera NFS ustawi się automatycznie lub będziesz miał listę do wyboru jeżeli będzie kilka przestrzeni NFS. W content ustawiamy co będzie mógł przechowywać nasz dodany storage. Ja tu zaznaczyłem wszystko a możemy się ograniczyć tylko do ISO i backup. W środowiskach produkcyjnych i wielo użytkownikowych zalecanie jest ograniczać nie tyle co dostęp ale także content jaki mogą zawierać nasze storage. W polu nodes możesz wybrać jakie węzły będą korzystać z tego storage (domyslnie jest to all). Możesz tu wskazać które węzły mają dostęp - u mnie to wszystkie dostęp uzyskają. Zatem uzupełniłem już moją kolekcję ISO w proxmox :) - czy nie jest imponująca (żart). A tak na serio to wgrywałem je pojedynczo z każdego węzła (tak wiem że można to zrobić z command line) ale chciałem sprawdzić jak zachowa się właśnie proxmox a dokładnie API gdy będę je męczył z jednego węzła. Wgrywanie kilku obrazów z jednego węzła powodowało błąd importu ISO. A logi a w zasadzie Taski - bo tak się to w proxmox nazywa można przeglądać na danym węźle z poziomu tego węzła - jego menu potem Task History i szukamy naszego wpisu :) I powoli dochodzimy do tego właśnie w jaki sposób zachować funkcjonalność naszego klastra. Sam klaster dział jednak proxmox nie zapewnia VIP IP dla interfejsu WWW GUI który by pływał między węzłami dając dostęp do klastra. Innymi słowy mówiąc: Gdy pve01.koska.in jest niedostepny to nie dostanę się do klastra. Pozostają mi dwa nastepne adresy pve02.koska.in oraz pve03.koska.in. I tu przechodzimy do jednej z ważniejszych rzeczy jakie trzeba zrozumieć na początku pracy z proxmox w wersji kluster - czy może inaczej z włączonym klastrem. Proxmox - Korum w klastrze proxmox W klastrze Proxmox, jeden z węzłów pełni rolę "master". Główną rolą mastera jest koordynowanie dostępu do współdzielonych zasobów i zarządzanie metadanymi klastra. Jednak warto zaznaczyć, że wszystkie węzły w klastrze Proxmox są równorzędne w sensie, że każdy węzeł może wykonywać operacje VM (maszyny wirtualne) i CT (kontenery), niezależnie od tego, czy są masterem. Jeśli master umiera lub jest niedostępny, inny węzeł może przejąć rolę mastera. Wybór nowego mastera jest oparty na systemie głosowania między węzłami. Oto jak to działa: Wybór Mastera: Proxmox używa protokołu korum do zarządzania klastrem. Kiedy master jest niedostępny, pozostałe węzły rozpoczynają proces wyboru nowego mastera. Węzeł z najniższym ID jest wybierany jako nowy master, pod warunkiem że może uzyskać większość głosów w klastrze. Większość: Aby węzeł mógł zostać masterem, musi uzyskać większość głosów. W klastrze 3-wezłowym oznacza to, że muszą być co najmniej 2 działające węzły, w tym węzeł, który próbuje zostać masterem. Jeśli tylko jeden węzeł jest online, nie będzie mógł uzyskać większości i klastrowe operacje zarządzania nie będą możliwe do przeprowadzenia. Zmiana Mastera: Jeśli oryginalny master zostanie przywrócony online po tym, jak nowy master został wybrany, stary master stanie się zwykłym węzłem i nowy master będzie nadal pełnił swoją rolę. W praktyce oznacza to, że w klastrze 3-wezłowym można tolerować awarię jednego węzła i klastrowe operacje zarządzania nadal będą możliwe. Jeśli jednak dwa węzły staną się niedostępne, klastrowe operacje zarządzania zostaną zawieszone do momentu przywrócenia przynajmniej jednego z tych węzłów. Czemu zatem nie cztery? To pytanie moglibyśmy porównać do sytuacji w aktualnych wyborach do sejmu i senatu. Niby dodając jednego hosta więcej do mojej puli mogłabym wygrać ilościowo ale przegrałbym większościowo. Po prostu tej większości bym nie uzyskał. W klastrze Proxmox opartym na większej liczbie węzłów, zasady wyboru mastera i wymagania dotyczące większości głosów nadal obowiązują, ale matematyka zmienia się w zależności od liczby węzłów. Proxmox używa protokołu korum opartego na głosowaniu, który determinuje, czy klastrowe operacje zarządzania są możliwe. Oto jak to działa w klastrach o różnej liczbie węzłów: Klaster 4-węzłowy: Wymagana większość: 3 z 4 węzłów. Możesz tolerować awarię jednego węzła i nadal mieć możliwość wykonywania klastrowych operacji zarządzania. Czyli taniej wychodzi wersja 3 węzłowa - dalej więcej niż jedna awaria węzła powoduje utratę większości. Klaster 5-węzłowy: Wymagana większość: 3 z 5 węzłów. Możesz tolerować awarię dwóch węzłów i nadal mieć możliwość wykonywania klastrowych operacji zarządzania. Dla klastrowych systemów o większej liczbie węzłów: Wymagana większość to połowa liczby węzłów plus jeden. Na przykład w klastrze 6-węzłowym potrzebujesz 4 węzłów (3+1) dla większości, a w klastrze 10-węzłowym potrzebujesz 6 węzłów (5+1) dla większości. Można tolerować awarię `(n/2) - 1` węzłów, gdzie `n` to liczba węzłów w klastrze, i nadal mieć możliwość wykonywania klastrowych operacji zarządzania. Co ważne, dodanie dodatkowych węzłów do klastra zwiększa odporność na awarie, ale jednocześnie zwiększa wymagania dotyczące ilości węzłów potrzebnych do osiągnięcia większości. Podczas projektowania i konfigurowania klastra warto zastanowić się nad liczbą węzłów w kontekście wymagań dotyczących dostępności i tolerancji na awarie. W wielu przypadkach klaster z nieparzystą liczbą węzłów jest bardziej odporny na awarie niż klaster o podobnej, parzystej liczbie węzłów. Zatem konfiguracja trzy węzłowa jest najtańsza wersją dająca namiastkę HA w klastrze :). Zobrazuje to: Kiedy nasz węzeł przestaje być dostępny tracimy dostęp do jego zasobów. Jednak przy konfiguracji trzy węzłowej moje dwa węzły pve01.koska.in oraz pve02.koska.in mogą dalej działą i zapewnić funkcjonowanie klastra na czas wymiany / naprawy węzła pve03.koska.in. I tu rodzi się następujący pytanie skoro klaster działa na dwóch węzłach to dlaczego nie ustawić go i nie zainstalować właśnie na dwóch. To konfiguracja z która spotkamy się przy dodanu jednego hosta więcej do naszej konfiguracji. W przypadku czterech węzłów awaria dwóch nie daje tej większość. Uzyskujemy ją dopiero przy pięciu. Jednak co tracimy przy klastrze który nie ma większości? I czy możemy dalej funkcjonować z takim klastrem? Tak, klaster Proxmox może działać bez wymaganej większości węzłów, ale istnieją pewne ograniczenia w jego funkcjonalności w takim scenariuszu. Po pierwsze, pojęcie "większość" w kontekście klastra odnosi się do koncepcji kworum. W systemach rozproszonych kworum to minimalna liczba węzłów, które muszą być dostępne i komunikować się ze sobą, aby podejmować decyzje na poziomie klastra. Oto dlaczego jest to ważne: Unikanie podziału mózgu (split-brain): Jeśli dwa węzły w klastrze tracą ze sobą komunikację, oba mogą próbować przejąć odpowiedzialność za zasoby klastra. Może to prowadzić do sytuacji, w której oba węzły uważają się za "mistrza" i próbują zarządzać zasobami niezależnie. Jeśli klaster wymaga kworum (większości) do działania, zapobiega to potencjalnym konfliktom i problemom spowodowanym przez podział mózgu. Integralność danych: W przypadku rozproszonych systemów plików czy rozwiązaniach do przechowywania danych, kworum zapewnia, że zmiany w danych są akceptowane tylko wtedy, gdy większość węzłów je potwierdzi. Zabezpiecza to przed potencjalnymi niezgodnościami w danych. Gdy klaster Proxmox działa bez wymaganej większości węzłów: Brak możliwości zarządzania klastrem: Jeśli klaster traci kworum, nie będziesz mógł dokonywać zmian na poziomie klastra, takich jak migracje maszyn wirtualnych czy zmiany w konfiguracji klastra. Węzły działają niezależnie: Chociaż węzły będą nadal działać i obsługiwać lokalnie uruchomione maszyny wirtualne lub kontenery, nie będą one w stanie komunikować się z resztą klastra ani wykonywać operacji klastrowych. Możliwość wystąpienia problemów z integralnością danych: W scenariuszach, w których klaster używa rozproszonych systemów przechowywania, takich jak Ceph, brak kworum może wpłynąć na integralność i dostępność danych. Podsumowując, chociaż klaster Proxmox może działać bez wymaganej większości węzłów, jest to stan, który należy unikać. Kworum jest kluczowym elementem zapewniającym spójność i stabilność w systemach rozproszonych. Jeśli klaster traci kworum, najlepiej jest jak najszybciej przywrócić wymaganą większość węzłów do działania. Proxmox - Klaster HA(hahahaha) Czyli w obecnej konfiguracji jestem na dobrej drodze do zachowania HA w klastrze proxmox. Trzeba tylko ogarnąć przeskakiwanie mojej maszyny wirtualnej na któryś z węzłów w przypadku braku dostępności jednego z nich. Proxmox - konfiguracja maszyny wirtualnej Zróbmy to - czas na uruchomienie naszej "pierwszej" maszyny wirtualnej w klastrze proxmox. Zobaczmy jakie mamy możliwości. Doprowadźmy do ziszczenia przedstawionego powyżej scenariusza. Scenariusz zatem zakłada, że stworze maszynę wirtualną (na dowolnym węźle w klastrze). W przypadku braku dostępności tego węzła na którym działa maszyna wirtualna, ta maszyna wirtualna zostanie przeniesiona na jeden z dwóch węzłów. Sprawdźmy jaki mamy storage w naszym klastrze: LVM (local) i LVM-Thin dostępny na każdym węźle. Samba i NFS dostępny z poziomu klastra. Wczytując się w mechanizmy HA i replikacje storage w postaci LVM (obie wersje) nie jest on dobrym rozwiązaniem. Mechanizm HA zrobi migracje maszyny wirtualnej na wskazany host pod warunkiem, że węzeł na którym, jest uruchomiona maszyna wirtualna będzie dostępny w czasie przenosin. Co znacznie utrudnia wystąpienie nieplanowanych awarii. Mechanizm replikacji działa wyłącznie dla ZFS. Dlatego też trzeba dodać nasz storage typu ZFS. Storage ZFS W mojej konfiguracji każdego węzła, posiadam jeden dysk gdzie jest zainstalowany system operacyjny PROXMOX i dwa wspomniane wyżej lokalne storage. Na drugim dysku nie mam jeszcze danych i wykorzystam go częściowo na ZFS oraz na directory storage w celu przechowywania tymczasowego backup. Konfiguracja przedstawia się następująco: Dyski które mamy dostępne (podłączone są do naszego węzła) zawsze będą dostępne z poziomu danego węzła. W tym przypadku będzie przykład z pve01.koska.in (Operacje jednak wykonam na wszystkich węzłach). Mam dostępne dwa dyski. Pierwszy zawiera system, drugi mogę go wykorzystać na mój storage. Zaznaczam dysk który chcę użyć (W moim przykładzie jest to /dev/sda). Klikam w górnej części menu WIPE DISK (UWAGA: Usunie wszystkie informacje o partycjach - upewnij się, że nie masz tam danych ważnych dla Ciebie) i usuwań znajdujące się tam dane. W tym przypadku partition layout. Teraz mogę przejść do konfiguracji mojego dysku. Na moim hoście pve01. Z menu węzła wybieram host pve01 i klikam z górnego menu shell. I przechodzę do terminala gdzie wydaje polecenie fdisk dla wybranego dysku (/dev/sda) i tworzę partycje według potrzeb. Jedną o pojemności 130 GB a druga o pojemności około 100 GB. Operacje powtarzam na każdym węźle - pve02 i pve03. Finalny rezultat jak u mnie to wyglada na każdym hoscie pveX prezentuje poniżej (zaznaczone na zielono). Po utworzeniu partycji w mojej konfiguracji na mniejszej z nich zrobię taki lokalny backup. Tworzę w pierwszej kolejności Director na mniejszej partycji, będzie on zawierał backup na lokalne operacje. Operacje będę znów powtarzał na wszystkich hostach od pve01 do pve03. Wchodzę w menu węzła klikając na jego nazwę -> Disks -> Directory -> Create Directory Konfiguracja wygląda następująco. Directory będę tworzył na partycji /dev/sda2 z filesystem ext4. Nazwą dla Directory będzie słowo backup. Widzimy też, że nie mamy konfiguracji do wskazania kilku węzłów jak to miało miejsce przy NFS i SMB. Dlatego musimy zapamiętać, że ten storage będzie dostępny jedynie lokalnie na danym host. Storage o nazwie backup tworzę dodatkowo też na pve02 i pve03. Utworzony poprawnie Storage Directory pokaże nam się na liście w podglądzie w tym samym miejscu gdzie go dodaliśmy. Directory "backup" będę wykorzystywał w roli temporary backup dla danego hosta, ale będzie też mógł przechowywać innego rodzaj kontent według zaprezentowanej listy. Storage Director Backup po dodaniu go na wszystkich hostach będzie widoczny w całym klastrze. Pomimo że jest widoczny w całym klastrze jak ma to miejsce z NFS oraz SMB. To należy pamiętać że jest on tylko lokalnym storage dostępnym na danym węźle. Teraz przystąpmy do stworzenia Storage ZFS. Tu też operacje będziemy musieli wykonać na wszystkich hostach w klastrze. Klikamy na Host, przechodzimy do menu węzła potem Disks -> ZFS -> Create ZFS Wybieramy nazwę dla naszego ZFS oraz wskazujemy device na którym ma działać, ustawiamy kompresję i tworzymy nasz Storage ZFS. (Dodatkowo jak mielibyśmy tu na przykład kilka fizycznych dysków z partycjami ZFS, to moglibyśmy skonfigurować RAID dla naszej konfiguracji) Operacje powtarzamy w celu uzyskania ZFS_STORAGE na każdym węźle w proxmox odpowiednio dla pve02 i pve03. Gdy już mamy nasz ZFS_STORAGE na każdym węźle możemy przystąpić do konfiguracji ZFS z poziomu naszego klastra. Da nam to możliwość replikacji danych pomiędzy hosty w naszym klastrze. Dodajemy nasz ZFS z poziomu klastra. Przechodzimy do menu klastra -> Storage -> Add -> ZFS Nazwa musi być inna od już używanych jak dla każdego ID Storage. Zatem użyje nazwę zfs. Dodatkowo dla rozróżnienia tych Storage w widoku klastra można by pokusić się o label w postaci _local_ i _replica_, ale to już zostawiam do indywidualnego nazewnictwa. Po stworzeniu takiego storage z poziomu klastra zobaczymy, że on jest on dostępny na wszystkich hostach. Jednak możemy zobaczyć że nie jest typu SHARED jak to mam miejsce przy SMB i NFS. W przeciwieństwie do NFS i SMB, co to oznacza? Zatrzymajmy się tutaj na chwile by wytłumaczyć znaczenia tej opcji. Wcześniej jak dodaliśmy SMB i NFS z poziomu menu klastra to nasz storage dodał się automatycznie na wszystkie węzły i ustawił się na status shared. Co oznacza że zasób jest niezależny od węzła i jest udostępnia z innego zasobu. To po prostu osobny serwer z usługami NFS i Samba. Dlaczego w przypadku dodania ZFS tak się nie dzieje? Tu musimy popatrzeć na nasze mechanizmy HA i replikacja. W kontekście Proxmox, HA (High Availability) oraz replikacja to dwa kluczowe pojęcia związane z zapewnieniem ciągłości działania i ochrony danych: HA (High Availability) - Wysoka dostępność: Jest to mechanizm, który zapewnia automatyczne uruchamianie maszyn wirtualnych lub kontenerów na innym węźle w przypadku awarii jednego z węzłów w klastrze Proxmox. Celem HA jest minimalizowanie przestojów i zapewnienie, że zasoby są dostępne nawet w przypadku awarii jednego z węzłów. Proxmox VE korzysta z mechanizmu "Proxmox Cluster file system (pmxcfs)", który umożliwia synchronizację konfiguracji między węzłami klastra. W połączeniu z innymi narzędziami, takimi jak Corosync i Pacemaker, Proxmox jest w stanie monitorować węzły i usługi, a następnie reagować na awarie. Replikacja: Jest to proces tworzenia kopii danych w czasie rzeczywistym (lub niemal w czasie rzeczywistym) z jednej lokalizacji do innej. W kontekście Proxmox, replikacja często odnosi się do replikacji dysków maszyn wirtualnych lub kontenerów. Dzięki temu, w przypadku awarii jednego z dysków lub węzłów, dane są nadal dostępne w innej lokalizacji. Proxmox oferuje replikację na poziomie bloków, co pozwala na szybką i skuteczną synchronizację danych między węzłami. Replikacja jest często używana razem z HA, aby zapewnić zarówno dostępność usług, jak i ochronę danych. Zatem zauważamy, że w przypadku SMB i NFS replikacją będzie po prostu "backup". Ponieważ replikację zapewniana jest już po stronie serwera Synology NAS. Proxmox w tym przypadku nie bierze udziału W przypadku ZFS, to my musimy zapewnić replikację by nasze HA funkcjonowało. Może zobaczmy to na konkretnym przykładzie naszych maszyn wirtualnych z różnym storage. Tworzymy naszą maszynę wirtualną z poziomu węzła z menu kontekstowego Lub belki z przyciskami funkcyjnymi z prawej strony ekranu po kliknięciu na dany host. Ustawiamy nasze maszyny wirtualne dla ZFS NFS i SMB (czyli łącznie trzy maszyny wirtualne). O nazwach ubuntu-zfs, ubuntu-nfs i ubuntu-smb. Ja dodam jeszcze jedną maszynę wirtualną w celu wykonania testów wydajnościowych. Niech to będzie Ubuntu - wybieramy ISO z naszego storage gdzie przechowujemy nasz obrazy systemów opercyjnych. Ustawienie Systemowe - można się wzorować lub ustawić własne. Konfiguracja dysku - dodam malutki dysk 32GB. W zupełności to wystarczy. To tu też decydujemy gdzie wyląduje nasz dysk. Dlatego warto zwrócić tu uwagę na pozycję STORAGE. Dla każdej VM ustawiamy inny. CPU - według uznania (lub możliwości naszego węzła). RAM - tak z umiarem :) Sieci. Jeszcze za dużo o sieci nie rozmawialiśmy, a więc ustawmy domyślny bridge interface. Na końcu otrzymamy podsumowanie naszych ustawień. Możemy ustawić też start nasze maszyny wirtualnej zaraz po konfiguracji. Jak nic nie będziemy zmieniać/dodawać. A tak u mnie prezentują się moje trzy maszyny wirtualne. Ubuntu-zfs, ubuntu-nfs, ubuntu-smb. Wszystkie uruchomiłem na jednym hoście. Za chwileczkę ogarniemy ich lokalizację w HA. Możemy przejść do konfiguracji naszego HA i replica w klaster proxmox. W tym celu przechodzimy do ustawień HA z poziomu menu klastra (To tu ustawia się konfigurację HA). Nasz rysunek teraz z działającymi maszynami wirtualnymi prezentuje się następująco. Widzimy wyraźnie gdzie znajduje sie jaka maszyna wirtualna oraz jak wygląda nasza konfiguracja storage. Z tym rysunkiem w głowie przejdźmy do ustawień HA w Klastrze HA - jego konfiguracje robimy na poziomie klastra. Z menu klastra wybieramy HA -> Groups to tu będziemy mogli stworzyć nasze grupy decyzyjne HA Kliknijmy create by spojrzeć na konfigurację. W oknie Create HA Group możemy ustawić nasz HA ID: czyli nazwę, oraz wskazać węzły na których nasza grupa będzie operować. Możemy też określić Priority Awaryjności naszego klastra. Czyli gdzie ma wylądować nasza maszyna wirtualna. Im wyższa wartość, to ten host będzie wybierany jako pierwszy. Ja wcześniej już przygotowałem swoje grupy HA. W nazwie znalazły się prefixy dla storage. Zatem HA-nfs jest przypisane do ubuntu-nfs, HA-smb do ubuntu-smb a HA-zfs do ubuntu-zfs. Mamy też informacje gdzie i w jakiej kolejności powinna być uruchamiane nasze maszyny wirtualne: I dla ubuntu-zfs będzie to: pve01 potem pve03 na końcu pve02 dla ubuntu-smb będzie to: pve02 na końcu pve03 (bez pve01) dla ubuntu-nfs będzie to: pve02 na końcu pve01 (bez pve03) W samym menu HA możemy podejrzeć sobie Czy nasze kworum jest OK oraz który, węzeł akurat pełni role mastera (main). A poniżej możemy ustawić nasze HA dla naszych zasobów poprzez przycisk Add. Ścieżka będzie zatem menu klastra -> HA -> Add. W Add Resource: Container/Virtual Machine na liście VM pokażą się wszystkie maszyny bez ustawionego HA. Jak nie ma jakiejś maszyny tu na liście to znaczy, że ma już ustawione HA Wskazujemy zasób poprzez jego ID i wybieramy grupę oraz określamy stan jaki oczekujemy. Możemy też określić liczbę restartów i relocate. Gdy mamy już dodane nasze HA do zasobów pokazują się na liście gdzie możemy łatwo zidentyfikować jaki zasób do jakiego HA jest przypisany. Po zastosowaniu HA widzimy jak nasze maszyny przygotowywane są do rozłożenia po klastrze. Nasze dwie maszyny wirtualne przeskakują na host pve02 tak jak to określiliśmy w konfiguracji HA Groups. Nasz schemat poniżej to przedstawia. maszyna smb i nfs ma storage shared wiec migracja jest tylko samych metadanych. Po ukończonej migracji nasze maszyny wirtualne teraz tak są rozłożone na klastrze. Widzimy to też w GUI PROXMOX Możemy to zweryfikować na podstawie naszych ustawień HA grupy. W przypadku storage sieciowego shared HA w zupełności wystarczy. Bo przenoszone są tylko metadane - nasz dysk jest na innym serwerze który, to udostępnia go dla naszego proxmox. Inaczej jest w przypadku ZFS storage. Wymusimy przeniesienie w konfiguracji HA. Po zmianie kolejności i ustawieniu pve03 z najwyższym priorytetem zaobserwujemy ze rozpoczyna się nasza migracja. Nasza maszyna wirtualna z ID 100 jest przenoszona na pve03 wraz z danymi. Dzieje się tak ponieważ ZFS z założenia nie jest zasobem shared tylko lokalnym. (W obrazku widnieje błąd w postaci oznaczenia dysku w dolnej czesci) Podczas procesu migracji dane zobaczymy na obu hostach pve01 i pve02. (W obrazku widnieje błąd w postaci oznaczenia dysku w dolnej czesci) Zobaczymy ten proces na liście zadań proxmox Pomimo migracji nasza maszyna jest nadal dostępna i możemy na niej działać. To proxmox pilnuje by dane były we właściwym miejscu. Po zakończonej migracji dysk dla naszej VMki o ID 100 będzie tylko i wyłącznie na pve03. Jednak w przypadku naszego storage klastrowego ZFS możemy zapewnić replikację. Jest to alternatywa dla braku NFS lub SMB w naszej konfiguracji. Przechodzimy do naszej maszyny wirtualnej i konfigurujemy replikacje ustawiając ją na hosty w których nie ma naszej maszyny wirtualnej - czyli w tym przypadku będzie to pve01 i pve02. Ustawiamy Target na pve01 (potem na pve02) konfigurujemy nasz Schedule: co 15 minut (w ramach testu). Dla pve02 - musimy zrobić osobno dla każdego hosta. Dla pve03 nie zrobimy ale jak maszyna przeskoczy na inny host to ten na którym będzie zmieni się w konfiguracji replikacji na ten na którym był. Ustawienie replikacji będzie widoczne w naszych zadaniach replikacyjnych na liscie wraz z widocznym statusem. Teraz możemy zaobserwować że nasz dysk pojawia się na innych hostach (pve01 i pve02) Jest to replika naszego dysku - która może posłużyć jako restore point po awarii któregoś z węzłów. Zabawy nadszedł czas - symulacja awarii w klastrze proxmox Czas na zabawę. Zróbmy awarię, konfigurację trzeba przetestować. Na pierwszy ogień maszyny z SMB i NFS. Wyłączymy nasz węzeł proxmox pve02. Po chwili nasz status page wykryje problem. I zacznie się migracja, przepraszam wróć przełączaniem naszego HA. Z bazy danych proxmox odnośnie metadanych dla naszych maszyn wirtualnych zostanie uruchomiona VM na innych dostępnych hostach ubuntu-smb i ubuntu-nfs. Dyski oczywiście pobierane są ze Storage sieciowego więc tu dane są bezpieczne. Tak to wygląda po przełączeniu HA w przypadku awarii pve02. Ok włączamy nasz host z powrotem i gdy będzie dostępny nasz HA znów zadziała tylko że tym razem maszyny zostaną przeniesione poprzednie swoje miejsce według HA groups Maszyny 101 i 102 wracają na swoje miejsce. ZFS replica i HA - proxmox klaster By to zadziałało tak samo w przypadku naszego zfs to musimy mieć aktywne obie opcje replica i HA groups. Replika musi być wykonana dla wszystkich miejsc ustawionych w replicas. Jeżeli nie wykonała się na czas z powodu awarii lub jeszcze nie została uruchomiona zawsze możemy ją uruchomić na żądanie. Musimy poczekać na wszystkie wykonania. Teraz jestesmy pewni że nasz HA groups i replica zadziała w przypadku awarii. Widzimy że nasza VMka 100 cały ten czas działała ma uptime 43 minuty (a przeszła dwie migracje w międzyczasie). Czas zatem na awarie numer dwa - teraz pve01 bedzie niedostępny. Host z naszą maszyną ubuntu-zfs (ID 100) Kiedy nasz host będzie niedostępny proxmox - przeniesie naszą maszynę i uruchomi ją na podstawie zreplikowane dysku. W mojej konfiguracji trace tylko 15 minut (to czas ustawionego scheduler dla replica danych pomiędzy węzłami). Proxmox przeniósł maszynę i odpala ja na bazie naszego dysku z ostatniej repliki. Oczywiście maszyny w tym przypadku zaliczyła restart. Którego nie da się uniknąc w przypadku awarii niekontrolowanej węzła. Pokazałem Ci działanie HA w sposób kontrolowany i nie kontrolowany. Wiesz już też jak działa replica. W tym wpisie to już koniec w kolejnym przeprowadzimy parę testów wydajnościowych, jakieś bardziej realne scenariusze. Zajmę się też backupem oraz automatyzacją w wykonaniu Ansible i Terraform. Przydał by się też monitoring :) Zapraszam.

Proxmox to platforma przeznaczona do wirtualizacji i konteneryzacji zasobów które, mamy uruchomione na naszych maszynach baremetal. W tym artykule przyjrzymy się takiej konfiguracji w moim labie domowym (jednak łatwo to potem przenieść na większą skalę). W artykule tym biorą udział 4 hosty na których zbudujemy klaster. Jeden host nasz gość specjalny zostanie na razie ukryty w tej konfiguracji i ujawnię go w trakcie artykułu :). Środowisko proxmox Zatem spójrzmy na moje środowisko dostępne w domowym "laboratorium" w którym to będę przeprowadzał operację uruchomienia klastra proxmox składającego się z trzech nodów (węzłów). Klaster ten wykorzystuje do tworzenia moich materiałów na youtube i komercyjnych szkoleń. Węzły (nody) - proxmox specyfikacja. Dla osób, które lubią parametry i dokładne szczegóły przedstawię rezultat polecenia hwinfo ze wszystkich trzech węzłów mojego klastra proxmox: Węzeł pierwszy (pve01) - dwa dyski SSD po 230 GB / 8GB RAM root@pve01:~# hwinfo --short cpu: Intel(R) Core(TM) i5-7260U CPU @ 2.20GHz, 3400 MHz Intel(R) Core(TM) i5-7260U CPU @ 2.20GHz, 3400 MHz Intel(R) Core(TM) i5-7260U CPU @ 2.20GHz, 3400 MHz Intel(R) Core(TM) i5-7260U CPU @ 2.20GHz, 3400 MHz graphics card: Intel Iris Plus Graphics 640 storage: Intel Sunrise Point-LP SATA Controller [AHCI mode] Kingston Technology Company U-SNS8154P3 NVMe SSD network: wlp58s0 Intel Wireless 8265 / 8275 eno1 Intel Ethernet Connection (4) I219-V enx00e04c6804df Realtek RTL8153 Gigabit Ethernet Adapter network interface: lo Loopback network interface eno1 Ethernet network interface vmbr0 Ethernet network interface enx00e04c6804df Ethernet network interface wlp58s0 Ethernet network interface disk: /dev/nvme0n1 Kingston Technology Company U-SNS8154P3 NVMe SSD /dev/sdb SYNOLOGY Storage /dev/sda Samsung SSD 860 partition: /dev/nvme0n1p1 Partition /dev/nvme0n1p2 Partition /dev/nvme0n1p3 Partition /dev/sda1 Partition /dev/sda2 Partition usb controller: Intel JHL6340 Thunderbolt 3 USB 3.1 Controller (C step) [Alpine Ridge 2C 2016] Intel Sunrise Point-LP USB 3.0 xHCI Controller bios: BIOS bridge: Intel Sunrise Point-LP PCI Express Root Port #1 Intel Sunrise Point LPC Controller/eSPI Controller Intel JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] Intel Sunrise Point-LP PCI Express Root Port #8 Intel Sunrise Point-LP PCI Express Root Port #6 Intel JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] Intel Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers Intel JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] Intel Sunrise Point-LP PCI Express Root Port #9 Intel JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] hub: Linux Foundation 2.0 root hub VIA USB2.0 Hub Linux Foundation 3.0 root hub Linux Foundation 2.0 root hub VIA USB3.0 Hub Linux Foundation 3.0 root hub memory: Main Memory unknown: FPU DMA controller PIC Keyboard controller PS/2 Controller Realtek RTS5229 PCI Express Card Reader Intel Sunrise Point-LP PMC Intel Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model Intel Sunrise Point-LP CSME HECI #1 Intel Sunrise Point-LP Thermal subsystem Intel Sunrise Point-LP SMBus Węzeł drugi (pve02) - wa dyski SSD po 230 GB / 8GB RAM root@pve02:~# hwinfo --short cpu: Intel(R) Core(TM) i5-7260U CPU @ 2.20GHz, 3400 MHz Intel(R) Core(TM) i5-7260U CPU @ 2.20GHz, 3400 MHz Intel(R) Core(TM) i5-7260U CPU @ 2.20GHz, 3400 MHz Intel(R) Core(TM) i5-7260U CPU @ 2.20GHz, 3400 MHz graphics card: Intel Iris Plus Graphics 640 storage: Intel Sunrise Point-LP SATA Controller [AHCI mode] network: wlp58s0 Intel Wireless 8265 / 8275 eno1 Intel Ethernet Connection (4) I219-V enx00e04c680f23 Realtek RTL8153 Gigabit Ethernet Adapter network interface: wlp58s0 Ethernet network interface eno1 Ethernet network interface vmbr0 Ethernet network interface enx00e04c680f23 Ethernet network interface lo Loopback network interface disk: /dev/sdb WDC WDS240G2G0B- /dev/sdc SYNOLOGY Storage /dev/sda KINGSTON SV300S3 partition: /dev/sdb1 Partition /dev/sdb2 Partition /dev/sda1 Partition /dev/sda2 Partition /dev/sda3 Partition usb controller: Intel JHL6340 Thunderbolt 3 USB 3.1 Controller (C step) [Alpine Ridge 2C 2016] Intel Sunrise Point-LP USB 3.0 xHCI Controller bios: BIOS bridge: Intel Sunrise Point-LP PCI Express Root Port #1 Intel Sunrise Point LPC Controller/eSPI Controller Intel JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] Intel Sunrise Point-LP PCI Express Root Port #8 Intel Sunrise Point-LP PCI Express Root Port #6 Intel JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] Intel Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers Intel JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] Intel JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] hub: Linux Foundation 2.0 root hub VIA VL813 Hub Linux Foundation 3.0 root hub Linux Foundation 2.0 root hub VIA VL813 Hub Linux Foundation 3.0 root hub memory: Main Memory unknown: FPU DMA controller PIC Keyboard controller PS/2 Controller Realtek RTS5229 PCI Express Card Reader Intel Sunrise Point-LP PMC Intel Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model Intel Sunrise Point-LP CSME HECI #1 Intel Sunrise Point-LP Thermal subsystem Intel Sunrise Point-LP SMBus Węzeł trzeci (pve03) - wa dyski SSD po 230 GB / 8GB RAM root@pve03:~# hwinfo --short cpu: Intel(R) Core(TM) i5-7260U CPU @ 2.20GHz, 3400 MHz Intel(R) Core(TM) i5-7260U CPU @ 2.20GHz, 3400 MHz Intel(R) Core(TM) i5-7260U CPU @ 2.20GHz, 3400 MHz Intel(R) Core(TM) i5-7260U CPU @ 2.20GHz, 3400 MHz graphics card: Intel Iris Plus Graphics 640 sound: Intel Sunrise Point-LP HD Audio storage: Intel Sunrise Point-LP SATA Controller [AHCI mode] network: wlp58s0 Intel Wireless 8265 / 8275 eno1 Intel Ethernet Connection (4) I219-V enx00e04c680432 Realtek RTL8153 Gigabit Ethernet Adapter network interface: eno1 Ethernet network interface wlp58s0 Ethernet network interface vmbr0 Ethernet network interface enx00e04c680432 Ethernet network interface lo Loopback network interface disk: /dev/sdb WDC WDS240G2G0B- /dev/sdc SYNOLOGY Storage /dev/sda Samsung SSD 860 partition: /dev/sdb1 Partition /dev/sdb2 Partition /dev/sda1 Partition /dev/sda2 Partition /dev/sda3 Partition usb controller: Intel JHL6340 Thunderbolt 3 USB 3.1 Controller (C step) [Alpine Ridge 2C 2016] Intel Sunrise Point-LP USB 3.0 xHCI Controller bios: BIOS bridge: Intel Sunrise Point-LP PCI Express Root Port #1 Intel Sunrise Point LPC Controller/eSPI Controller Intel JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] Intel Sunrise Point-LP PCI Express Root Port #8 Intel Sunrise Point-LP PCI Express Root Port #6 Intel JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] Intel Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers Intel JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] Intel JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] hub: Linux Foundation 2.0 root hub VIA USB2.0 Hub Linux Foundation 3.0 root hub Linux Foundation 2.0 root hub VIA USB3.0 Hub Linux Foundation 3.0 root hub memory: Main Memory bluetooth: Intel Bluetooth wireless interface unknown: FPU DMA controller PIC Keyboard controller PS/2 Controller Realtek RTS5229 PCI Express Card Reader Intel Sunrise Point-LP PMC Intel Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model Intel Sunrise Point-LP CSME HECI #1 Intel Sunrise Point-LP Thermal subsystem Intel Sunrise Point-LP SMBus Jak można wyczytać z tej krótkiej specyfikacji nie są to jakieś mega mocne maszyny, rzekłbym takie w sam raz na domowe "laboratorium" pod wirtualizację. Sa to trzy komputerki wyglądem bardzo zbliżone do tego https://www.x-kom.pl/p/475883-nettop-mini-pc-intel-nuc-i7-8559u-25sata-m2-box.html Ja w tym przypadku poszukałem tańszych odpowiedników na allegro - kości ram i dyski zakupiłem osobno, a w większości z zasobów prywatnych uzupełniłem braki by konfiguracja była w miarę identyczna. Dodatkowy storage (przestrzeń dyskowa) w postaci serwera synology w celu zagwarantowania pewnego rodzaju HA - ale o tym jeszcze sobie porozmawiamy w tym artykule i jak to możemy zapewnić w naszym klastrze. Instalacja proxmox Proces instalacji jest prosty. Najważniejszą konfiguracje robi się już na działającym serwerze więc sprowadza on się do przeklikania naszego instalatora gdzie wybieramy kartę sieciową dla naszego głównego połączenia (main), adres IP, usera, hasło. Oczywiście będę operację instalacji wykonywał na trzech hostach - pve01, pve02 i pve03. Na początek po zbootowaniu naszego obrazu z nośnika USB / ISO przywita nas panel wyboru instalacji w trybie graficznym lub tekstowym (gdybyś miał problemy z wyświetlaniem grafiki przejdź do instalacji w trybie tekstowym) Jeżeli podczas instalacji, już na samym początku pojawi się okno o braku akceleracji maszyn wirtualnych, sprawdź czy w bios masz włączoną tą opcję. Po prostu przerwij instalację i sprawdź ustawienia BIOS. Kontynuacja z tym komunikatem będzie oznaczała brak prawdziwej wirtualizacji - jedynie emulacja z qemu i konteneryzacja z LXC/LXD Kolejnym krokiem jest wybór dysku na którym zainstaluję się system operacyjny jakim jest proxmox. Po kliknięciu w options możemy bardziej skonfigurować podział naszego dysku. Ja tu unikam tworzenia jakich macierzy i tym podobne ponieważ HA będzie gwarantować mi klaster proxmox sam w sobie. Popsicle / Stracenie jednego węzła nie będzie u mnie bardzo obciążające. Jednak jeżeli zamierzasz produkcyjnie wykorzystywać proxmox warto skonfigurować i zainstalować go na konfiguracji RAID Możemy ustawić takie parametry jak hdsize, swapsize maxroot minfree i mazvz Po konfiguracji naszego dysku dla systemu ustawiamy lokacja i czas aktualny dla naszego komputera / systemu operacyjnego - względem własnej lokalizacji. Ustawiamy hasło dla naszego użytkownika root oraz podajemy adres email. Po konfiguracji naszego usera przechodzimy do ustawień sieciowych. Tu należy zwrócić uwagę na nasze ustawienia. Ja w swoje konfiguracji posiadam dwie karty sieciowe. Wybieramy właściwą i sprawdźmy ustawienia. Wbrew pozorom nie są one ustawieniami z DHCP. Zdarzyło mi się, że miałem tu mix ustawień z dwóch różnych sieci. Dlatego warto sprawdzić czy wartości są prawidłowe. By potem uniknąć grzebania w plikach konfiguracyjnych systemu operacyjnego. Po akceptacji ustawień sieci mamy swoiste podsumowanie, oraz opcję automatycznego restartu po instalacji. Po kliknięciu INSTALL proces instalacji zaczyna się i może zająć od kilku do kilkunastu minut. Po procesie instalacji mamy komunikat o zakończeniu instalacji i wizard odczega 10 sekund po czym automatycznie zrestartuje komputer. Tutaj musimy być uważni by po komunikacie wyciągnąć nośnik USB/ISO Jak nasz system już się uruchomi przywita nas komunikatem na jakim adresie IP jest dostępny nasz panel dla naszego proxmox. Logujemy się do panelu akceptując połączenie w naszej przeglądarce internetowej Uwierzytelnianie mamy na poziomie PAM Linux a zatem login i hasło to nasz użytkownik root oraz hasło które podaliśmy podczas instalacji. Po zalogowaniu może pokazać się komunikat o braku subskrypcji na proxmox. Możemy ten komunikat zignorować i później zakupić licencje proxmox Oto nasz panel proxmox do zarządzania serwerem lub naszym klastrem. Jak zalogujemy się do każdego z naszych trzech węzłów, to przywita nas podobny obraz. Proxmox w pojedynczej instalacji, zaraz świeżo po wyciągnięciu ISO juz działa w jednym klastrze o nazwie datacenter. Dlatego moje trzy węzły będą miały domyślny klaster jedno węzłowy a tylko będą różnić się nazwą naszego hosta. Po kliknięciu też na nazwę zmieni się nasze menu z menu klastra na menu hosta Menu naszego klastra - zaraz po instalacji jest to klaster jednowęzłowy (bez HA) Menu ustawień naszego węzła Konfiguracja klastra proxmox Ok przystąpmy zatem do konfiguracji naszego klastra i węzłów proxmox. Dodajmy certyfikat jeżeli posiadasz. Ja dodam dla mojej domeny *.koska.in przechodzę do menu wezła i klikam SYSTEM -> CERTIFICATE a potem w oknie UPLOAD CUSTOM CERTIFICATE Dodajemy nasz certyfikat po przez wklejenie lub otwarcie odpowiedniego pliku z certyfikatem i kluczem. Certyfikat został załadowany co potwierdza nasz panel Przejdźmy teraz do ustawień sieciowych - ja mam dodatkowa kartę sieciowa któa jest podłaczona do sieci 192.168.1.0/24 a zatem dokonfiguruje mostek sieciowy dla tej karty. Klikamy na Menu naszego węzła SYSTEM -> NETWORK a potem na liście interfejsów klikamy przycisk CREATE i z listy wybieramy LINUX BRIDGE W konfiguracji naszego LINUX BRIDGE ustawiamy name według konwencji w proxmox nadajemy adres IPv4/CIDR, gateway pozostawiam pusty bo mam juz jedna kartę z ustawionym GW. Wskazuje na koniec BRIDGE PORTS, czyli nazwę mojego interfejsu na podstawie którego stworze LINUX BRIDGE Po ustawieniu mojego LINUX BRIDGE nie pozostaje mi nic innego jak zaakceptować konfigurację poprzez przycisk APPLY CONFIGURATION Po akceptacji naszej konfiguracji zobaczymy że nasz nowy interfejs jest ACTIVE z statusem YES zarówno bridge jak i wcześniejsza karta sieciowa. Tworzymy klaster proxmox Możemy stworzyć nasz klaster proxmox - wybieramy dowolny węzeł który nam za inicjalizuje klaster. Ja wybrałem host pve01 (ale można wybrać dowolny). Przechodzimy do menu klastra i tam szukamy opcji CLUSTER. Klikamy na przycisk CREATE CLUSTER Nadajemy nazwę dla naszego klastra oraz wybieramy karty sieciowe na podstawie których będzie się komunikował nasz klaster z innymi węzłami Po kliknięciu w create czekamy na komunikat TASK OK i możemy zamknąc okno. Lub przejrzeć STATUS klastra i inicjalizacje naszej konfiguracji Po zamknięciu okna możemy wyświetlić CLUSTER JOIN INFORMATION - ta informacje pomożem nam połaczyć inne węzły do naszego klastra. Kopiujemy te informacje i przechodzimy do pve02 a potem pve03 Na pve02 przechodzimy do menu klastra DATACENTER -> CLUSTER i wybieramy przycisk JOIN CLUSTER W oknie JOIN CLUSTER podajemy wymagane informacje oraz podajemy hasło do naszego klastra z hosta na którym wykonywaliśmy inicjalizację. Po wypełnieniu klikamy JOIN HOMEPROXMOX - w moim przypadku (u Ciebie ta nazwa będzie zależna od nazwy klastra jaką wybrałeś) Po kliknieciu JOIN ... pokaże się okno informujące nas o całym procesie połączeniowym. Jeżeli po przejściu na status pokaze nam sie Connection error - to oznaka że nasze ustawiania się przeładował i my musimy nasz panel odświeżyć Po przeładowaniu strony możemy sobie zobaczyć że teraz na DATACENTER zawiera nazwę naszego klastra i widzimy też nasze węzły uczestniczące w klastrze. To koniec inicjalizacji naszego klastra. Zajmijmy się teraz konfiguracja naszego Storage tego lokalnego jak i sieciowego. Zobaczmy jakie mamy opcje storage w naszym klastrze proxmox. Klaster Proxmox - nasz storage Z pewnych ograniczeń związanych z moim środowiskiem domowego laboratorium nie przetestuję wszystkich rodzajów storage w proxmox ale uważam że dam dobre overview na ustawienia i możliwości konfiguracji naszego data storage. Proxmox plus synology - na pierwszy ogień NFS, SMB W mojej konfiguracji wykorzystam serwer NAS synology, dla osób lubiących parametry przedstawiam specyfikację konfiguracji mojego NAS synology: Storage w synology to dyski o pojemności 1.8T, łącznie 5 dysków. Co daje przestrzeń o pojemności 7.3 TB. W zupełności wystarczy to na domowy backup, kilka lokalnych maszyn wirtualnych oraz storage dla innych maszyn wirtualnych. Zobaczymy jaki storage sieciowy mamy do dyspozycji w proxmox, i powiem jest ich trochę sporo i każdy znajdzie coś dla siebie. Skonfigurujemy zatem najbardziej popularne i chyba dostępne w każdym domowym lab czyli SAMBA i NFS. Będziemy potrzebować osobnego usera tak by śledzić logi naszego połączenia z proxmox i w łatwiejszy sposób wychwycić jakiekolwiek błędy konfiguracyjne. Tworzymy odpowiednie foldery współdzielone gdzie będziemy osobno przechowywać dane dla VM po protokole SMB i NFS. Pamiętajmy o odpowiednim nadaniu uprawnień tak byśmy mogli się połączyć Tak samo dla NFS jak i SMB Oczywiście samo obsługa SAMBY musi być włączona na naszym serwerze synology NFS rownież - nie zapomnijmy o tym tak by niepotrzebnie nie debugować problemów z połączeniem z powodu braku usługi Dlaczego w klastrze proxmox w ogóle potrzebny nam storage taki jak wspomniany wyżej NFS i SMB. Niech jako prosty przykład posłuży chociażby nasz obraz ISO z Ubuntu. Jeżeli wgramy go na storage który mamy do dyspozycji od samego początku i zwie się on local. To ISO z instalatorem naszego Ubuntu będzie dostępne tylko dla tego węzła na którym to wgram - w tym przypadku będzie to pve01.koska.in. Przesyłamy ISO z naszego lokalnego komputera (mamy też możliwość wskazania url - jakby nasz lokalny komputer znajdował się w innej lokalizacji niż nasz klaster) To po przesłaniu pliku ISO gdy przejdziemy do innego węzła na nasz storage local zobaczymy, że tego ISO tam nie ma i akcję musimy powtórzyć dla wszystkich węzłów. Więc dodajmy w konfiguracji nasz SMB i NFS. Zanim to zrobię przygotuję sobie FQDN nfs.koska.in oraz smb.koska.in w celu łatwiejszej konfiguracji i unikania podawania adresów IP. W tym celu wykorzystam moja konfigurację w terraform do zarządzania strefą koska.in. Dokonam zmian w pliku konfiguracyjnym i całość prześlę do GIT. Git jest monitorowany przez Jenkins do którego jest podpięty pipeline który wykona mi odpowiednie testy i wdroży zmianę automatycznie, bez mojej ingerencji. Oczywiście w każdej chwili mogę zweryfikować status moich zmian w danym jobie. W tym przypadku moje dwa rekordy zostały dodane, plus też jeden skasowałem. Oczywiście usunięcie była tu świadome i zbiegło się z moją operacją dodnia nfs.koska.in oraz smb.koska.in. Zweryfikuję czy moj host widzi już te zmiany. I jak widać wszystko jest ok zatem mogę przejść do konfiguracji. Operacja dodania już sama w sobie jest prosta - dodawanie NFS. Uzupełniamy odpowiednio ID, server, export i content - w tym przypadku nfs będzie zawierał tylko dyski kontenerów i maszyn wirtualnych. Podobna konfiguracja jest w SMB. Uzupełniam wszystkie wymagane pola i zapisuję konfigurację. Storage dodany na poziomie Klastra Home Proxmox jak widzimy został dodany poprawnie i jest widziany przez wszystkie klastry. W tym wpisie to wszystko. W kolejnej części zajmiemy się innymi rodzajami storage, uruchomieniem maszyny wirtualnej, backup i replikacji oraz zautomatyzujmy nasz klaster, tak by za dużo w nim nie klikać. Pozdrawiam

Czym jest awx-operator awx-operator to operator Kubernetes stworzony, aby ułatwić wdrażanie, konfigurację i zarządzanie instancjami AWX na klastrach Kubernetes. AWX jest otwartoźródłową wersją Ansible Tower, narzędziem zaprojektowanym do zarządzania i uruchamiania zadań w Ansible w skali korporacyjnej. Główne funkcje awx-operator Automatyczne wdrażanie: Pozwala na łatwe wdrożenie AWX w klastrze Kubernetes za pomocą jednego polecenia. Konfiguracja: Operator umożliwia dostosowywanie różnych aspektów instancji AWX, takich jak ilość zasobów, konfiguracja baz danych czy dostęp do zewnętrznych systemów magazynowania. Automatyczne aktualizacje: Dzięki operatorowi, aktualizacja AWX może odbywać się płynnie, bez konieczności manualnej interwencji. Zarządzanie stanem: Operator dba o to, aby instancje AWX działały poprawnie i były w odpowiednim stanie. Monitoruję, czy wszystkie komponenty działają poprawnie i podejmuje odpowiednie działania w przypadku problemów. Zastosowanie awx-operator Uproszczenie zarządzania: Dzięki awx-operator, administracja wieloma instancjami AWX w klastrze Kubernetes staje się prostsza. Integracja z chmurą: Możliwość uruchamiania AWX na platformach typu Kubernetes ułatwia integrację z popularnymi usługami chmurowymi. Skalowalność: Korzystanie z Kubernetes w połączeniu z awx-operator pozwala na łatwe skalowanie instancji AWX, zarówno w górę, jak i w dół, w zależności od aktualnych potrzeb. AWX - czym jest AWX to otwartoźródłowa wersja Ansible Tower. Jest to narzędzie webowe zaprojektowane do zarządzania i uruchamiania zadań w Ansible. Ansible to popularne narzędzie do automatyzacji, służące do konfiguracji systemów, wdrażania aplikacji oraz zarządzania orkiestracją. AWX stanowi "kontrolne centrum dowodzenia" dla Ansible, umożliwiające zarządzanie playbookami, zmiennymi, inwentarzami i dostępnymi hostami w centralny i uporządkowany sposób. Kluczowe funkcje AWX Interfejs Użytkownika: AWX oferuje graficzny interfejs użytkownika, który umożliwia łatwe zarządzanie i monitorowanie zadań Ansible. Rest API: Oprócz interfejsu użytkownika, AWX udostępnia RESTful API, co ułatwia integrację z innymi narzędziami i skryptami. Planowanie Zadań: AWX pozwala na planowanie uruchamiania playbooków Ansible w określonych terminach lub cyklicznie. Zarządzanie Inwentarzem: Możesz definiować i grupować hosty, na których będą uruchamiane zadania, oraz synchronizować inwentarze z różnymi źródłami, takimi jak AWS, Google Cloud czy Azure. Role-Based Access Control (RBAC): AWX umożliwia definiowanie uprawnień na podstawie ról, dzięki czemu można precyzyjnie kontrolować, kto ma dostęp do określonych zasobów i jakie akcje może wykonywać. Zarządzanie Credentialem: Bezpieczne przechowywanie i zarządzanie danymi uwierzytelniającymi, które są używane podczas uruchamiania playbooków. Wizualizacje: AWX dostarcza wizualizacje w postaci diagramów i statystyk, umożliwiające szybki wgląd w status operacji oraz historię uruchomień. Integracja z systemami powiadomień: Możliwość wysyłania powiadomień na różne kanały, takie jak e-mail, Slack czy nawet webhooki, w odpowiedzi na różne zdarzenia w systemie. Zastosowanie AWX Centralne zarządzanie konfiguracją: Zarządzaj konfiguracją różnych systemów i aplikacji z jednego centralnego miejsca. Automatyzacja zadań IT: Automatyzuj rutynowe zadania, takie jak wdrażanie oprogramowania, zarządzanie użytkownikami czy aktualizacje systemowe. Orkiestracja wielostanowiskowa: Koordynuj działania pomiędzy różnymi środowiskami i platformami. Integracja z innymi narzędziami DevOps: Dzięki REST API, AWX może być łatwo zintegrowany z narzędziami takimi jak Jenkins, GitLab czy Jira. Konfiguracja AWX-operatora Przystąpmy zatem do konfiguracji naszego awx-operatora. Na początek potrzeba nam klastra kubernetes. Możesz wykorzystać dowolny. Jeżeli nie masz klastra kubernetes skonfigurowanego możemy skorzystać z docker-desktop i włączyć funkcje kubernetes na platformie docker. Docker desktop Zatem pobieramy naszą platformę docker desktop instalujemy naszą aplikację i po jej uruchomieniu włączmy funkcje kubernetes - jak to zrobić przedstawiają obrazki poniżej. Przechodzimy do ustawień aplikacji docker desktop, a potem w ustawieniach przechodzimy w sekcje kubernetes i włączamy nas engine k8s Zaznaczamy funkcje Enable Kubernetes i restartujemy klaster po przez Apply & restart - kubernetes zaczyna się uruchamiać zajmie to kilkadziesiąt sekund. Po uruchomieniu kubernetesa w docker sprawdzamy działanie naszego polecenia kubectl (jeżeli nie masz tego polecenia to zobacz jak go zainstalować z oficjalnej dokumentacji o instalacji kubectl) Wydajemy polecenie kubectl version: $ kubectl version WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short. Use --output=yaml|json to get the full version. Client Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.2", GitCommit:"7f6f68fdabc4df88cfea2dcf9a19b2b830f1e647", GitTreeState:"clean", BuildDate:"2023-05-17T14:20:07Z", GoVersion:"go1.20.4", Compiler:"gc", Platform:"linux/amd64"} Kustomize Version: v5.0.1 Unable to connect to the server: dial tcp: lookup k3s1.koska.in on 192.168.64.1:53: no such host I jeżeli tak ja ja masz kilka kontekstów konfiguracyjnych kubernetes to musimy zmienić kontekst pracy z naszym klastrem dla polecenia kubectl - robimy to za pomocą polecania: kubectl config use-context docker-desktop Na obrazku powyżej widać aktualna wersję uzywana umnie oraz kontekst na jaki mam ustawione polecenie kubectl - takie wyśietlenie dale shell zsh z nakładka oh my zsh Oczywiście mozna sprawdzic to poleceniem kubectl config get-contexts Na koniec sprawdźmy czy działa nasz klaster poleceniem kubectl get nodes -> i powinniśmy otrzymać coś takiego: $ kubectl get nodes NAME STATUS ROLES AGE VERSION docker-desktop Ready control-plane 28m v1.27.2 UWAGI: Nie musimy korzystać z docker-desktop i kubernetesa w nim. Możemy skorzystać z platformy minikube, w dokumentacji awx-operator znajdziemy instrukcje jak przygotować klaster minikube. Plan naszej konfiguracji Na początku musimy się zastanowić gdzie będziemy trzymać naszą bazę danych postgresql dla naszego AWX - mamy do wyboru w klastrze kubernetes (awx-operator stawia i robi to za nasz przy czystej instalacji) lub na osobnym serwerze - dedykowana instancja (nie zarządzana przez awx-operator). W przypadku drugiej konfiguracji mamy to opisane w dokumentacji związanej z konfiguracja bazy danych Ja w tym wpisie pójdę druga drogą, pierwsza po prostu pomija konfiguracja secretu dla bazy danych. Przygotowanie pliku kustomization.yaml Na początek musimy przygotować nasz plik kustomization.yaml (możemy bazować na tym dostępnym w instrukcji podstawowej instalacji) plik u mnie przedstawia się następująco: apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - github.com/ansible/awx-operator/config/default?ref=2.7.0 images: - name: quay.io/ansible/awx-operator newTag: 2.7.0 namespace: default Ten kod przedstawia plik `Kustomization`, który jest częścią narzędzia `kustomize` używanego do dostosowywania zasobów Kubernetes. Pozwala on na tworzenie wielowarstwowych konfiguracji na bazie istniejących zasobów, bez konieczności modyfikowania oryginalnych plików YAML. Rozbijmy ten konkretny plik `Kustomization` na poszczególne sekcje: apiVersion i kind: - `apiVersion`: Określa wersję API, z którą jest zgodny ten plik. W tym przypadku używana jest wersja `v1beta1` związana z `kustomize.config.k8s.io`. - `kind`: Określa typ obiektu. W tym przypadku jest to `Kustomization`, co wskazuje, że jest to plik konfiguracyjny dla `kustomize`. resources: - W tej sekcji określono zasoby, które mają być uwzględnione w procesie dostosowywania. - W tym przypadku zasób jest pobierany z repozytorium GitHub (`github.com/ansible/awx-operator`). Szczególnie korzysta z konfiguracji znajdującej się w katalogu `config/default` w odniesieniu do tagu `ref=2.7.0`. images: - Ta sekcja pozwala na modyfikację obrazów używanych w zasobach. Możliwe jest podmienienie nazwy obrazu, tagu lub repozytorium. - W tym przypadku obraz `quay.io/ansible/awx-operator` jest modyfikowany tak, aby używać tagu `2.7.0`. namespace: - Określa przestrzeń nazw, w której mają zostać wdrożone zasoby. W tym przypadku jest to przestrzeń nazw `default`. Możemy zatem wydać polecenie kubectl apply -k . które uruchomi nam nasza konfigurację: $ kubectl apply -k . Warning: resource namespaces/default is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically. namespace/default configured customresourcedefinition.apiextensions.k8s.io/awxbackups.awx.ansible.com created customresourcedefinition.apiextensions.k8s.io/awxrestores.awx.ansible.com created customresourcedefinition.apiextensions.k8s.io/awxs.awx.ansible.com created serviceaccount/awx-operator-controller-manager created role.rbac.authorization.k8s.io/awx-operator-awx-manager-role created role.rbac.authorization.k8s.io/awx-operator-leader-election-role created clusterrole.rbac.authorization.k8s.io/awx-operator-metrics-reader created clusterrole.rbac.authorization.k8s.io/awx-operator-proxy-role created rolebinding.rbac.authorization.k8s.io/awx-operator-awx-manager-rolebinding created rolebinding.rbac.authorization.k8s.io/awx-operator-leader-election-rolebinding created clusterrolebinding.rbac.authorization.k8s.io/awx-operator-proxy-rolebinding created configmap/awx-operator-awx-manager-config created service/awx-operator-controller-manager-metrics-service created deployment.apps/awx-operator-controller-manager created Ostrzeżenie: W wyniku pojawiło się ostrzeżenie dotyczące zasobu namespaces/default. Mówi ono o braku anotacji kubectl.kubernetes.io/last-applied-configuration, która jest wymagana przez kubectl apply. Ostrzeżenie sugeruje, że powinieneś używać polecenia kubectl apply tylko na zasobach utworzonych deklaratywnie przez kubectl create --save-config lub kubectl apply. Brakująca anotacja zostanie dodana automatycznie. Zasoby: namespace/default configured: Przestrzeń nazw default została skonfigurowana. Słowo kluczowe "configured" wskazuje, że zasób istniał wcześniej i został zmodyfikowany, a nie stworzony od nowa. customresourcedefinition.apiextensions.k8s.io/... created: Trzy Custom Resource Definitions (CRD) dla awxbackups, awxrestores i awxs zostały utworzone. CRD pozwala na dodanie własnych zasobów do API Kubernetes. serviceaccount/awx-operator-controller-manager created: Utworzono ServiceAccount o nazwie awx-operator-controller-manager. Role i ClusterRole (role.rbac.authorization.k8s.io/... i clusterrole.rbac.authorization.k8s.io/... created): Utworzono różne role i clusterrole, które definiują zestaw uprawnień na zasoby w klastrze. RoleBindings i ClusterRoleBindings (rolebinding.rbac.authorization.k8s.io/... i clusterrolebinding.rbac.authorization.k8s.io/... created): Utworzono rolebindings i clusterrolebindings, które przypisują określone role do użytkowników lub grup. configmap/awx-operator-awx-manager-config created: Utworzono ConfigMap, który przechowuje konfigurację dla managera AWX. service/awx-operator-controller-manager-metrics-service created: Utworzono usługę (Service) służącą do zbierania metryk z kontrolera awx-operator-controller-manager. deployment.apps/awx-operator-controller-manager created: Utworzono Deployment dla kontrolera awx-operator-controller-manager, który definiuje i kontroluje instancje aplikacji. Między czasie możemy sprawdzić czy konfiguracja ta stworzyła i działają nasze pody, poleceniem kubectl get pods $ kubectl get pods NAME READY STATUS RESTARTS AGE awx-operator-controller-manager-54fd9bc446-zl562 0/2 ContainerCreating 0 21s Jak nasze pody dla awx będą ze statusem running wtedy możemy sprawdzić dodatkowo logi dla naszego deployment i zobaczyć czy wszystko z naszym deployment jest ok. $ kubectl logs -f deployments/awx-operator-controller-manager -c awx-manager {"level":"info","ts":"2023-10-25T08:53:13Z","logger":"cmd","msg":"Version","Go Version":"go1.19.11","GOOS":"linux","GOARCH":"amd64","ansible-operator":"v1.31.0","commit":"e67da35ef4fff3e471a208904b2a142b27ae32b1"} {"level":"info","ts":"2023-10-25T08:53:13Z","logger":"cmd","msg":"Watching single namespace.","Namespace":"default"} {"level":"info","ts":"2023-10-25T08:53:13Z","logger":"controller-runtime.metrics","msg":"Metrics server is starting to listen","addr":"127.0.0.1:8080"} {"level":"info","ts":"2023-10-25T08:53:13Z","logger":"watches","msg":"Environment variable not set; using default value","envVar":"ANSIBLE_VERBOSITY_AWX_AWX_ANSIBLE_COM","default":2} {"level":"info","ts":"2023-10-25T08:53:13Z","logger":"watches","msg":"Environment variable not set; using default value","envVar":"ANSIBLE_VERBOSITY_AWXBACKUP_AWX_ANSIBLE_COM","default":2} {"level":"info","ts":"2023-10-25T08:53:13Z","logger":"watches","msg":"Environment variable not set; using default value","envVar":"ANSIBLE_VERBOSITY_AWXRESTORE_AWX_ANSIBLE_COM","default":2} {"level":"info","ts":"2023-10-25T08:53:13Z","logger":"ansible-controller","msg":"Watching resource","Options.Group":"awx.ansible.com","Options.Version":"v1beta1","Options.Kind":"AWX"} {"level":"info","ts":"2023-10-25T08:53:13Z","logger":"ansible-controller","msg":"Watching resource","Options.Group":"awx.ansible.com","Options.Version":"v1beta1","Options.Kind":"AWXBackup"} {"level":"info","ts":"2023-10-25T08:53:13Z","logger":"ansible-controller","msg":"Watching resource","Options.Group":"awx.ansible.com","Options.Version":"v1beta1","Options.Kind":"AWXRestore"} {"level":"info","ts":"2023-10-25T08:53:13Z","logger":"proxy","msg":"Starting to serve","Address":"127.0.0.1:8888"} {"level":"info","ts":"2023-10-25T08:53:13Z","logger":"apiserver","msg":"Starting to serve metrics listener","Address":"localhost:5050"} {"level":"info","ts":"2023-10-25T08:53:13Z","msg":"Starting server","path":"/metrics","kind":"metrics","addr":"127.0.0.1:8080"} awx.yml W tym samym katalogu gdzie stworzyliśmy nasz plik kustomization.yaml tworzymy nasz plik awx.yml zawierający konfiguracje naszego serwisu awx: --- apiVersion: awx.ansible.com/v1beta1 kind: AWX metadata: name: awx spec: service_type: NodePort service_labels: | environment: production hostname: ansible.koska.in postgres_configuration_secret: awx-postgres-configuration ingress_type: none ipv6_disabled: true db.yml Tworzymy nasz plik konfiguracyjny z konfiguracja polaczenia do naszej bazy danych --- apiVersion: v1 kind: Secret metadata: name: awx-postgres-configuration namespace: default stringData: host: port: "" database: username: password: "" sslmode: disable type: unmanaged type: Opaque Nasza baza danych W celu udawania zewnętrznego hosta z bazą danych postawie moja baze danych postgresql w kontenerze z wykorzystaniem docker-compose.yml: services: # postgres server db: image: postgres:13.9 restart: always environment: POSTGRES_PASSWORD: example ports: - 5432:5432 Uruchommy naszą bazę danych. W katalogu z plikiem docker-compose.yml wydajemy komende docker compose up -d Jak możemy zobaczyć wszystko się udało - nasz baza danych została postawiona i uruchomiona. Oczywiście w konfiguracji docker-compose brakuje pewnych parametrów związanych z zachowaniem danych. Jednak w ramach tego testu pozwoliłem sobie je pominąć - nie zależy mi na zachowaniu danych w tym akurat przypadku. Pozostaje nam dodać naszą bazę danych z której będzie korzystał AWX, logujemy sie do kontenera z terminala lub przez docker desktop. W przypadku terminala będzie to polecenie: $ docker compose exec -it "db" bash Znajdziemy się teraz w kontenerze i wydajmy komendę w celu stworzenia bazy danych. createdb -U postgres -h 127.0.0.1 awxdb Mamy stworzoną bazę danych. Możemy pobrać pgadmin i sprawdzić działanie naszej bazy oraz czy dodatkowa baza została utworzona. Mamy potwierdzone że serwer bazy danych działa i mamy stworzona bazę danych teraz powróćmy do naszego pliku db.yml i uzupełnijmy nasze brakujące dane. Uzupełniamy db.yml Nasz plik musimy uzupełnic o nastepujace dane: host: port: "" database: username: password: "" Port znamy jest to 5432, database to awxdb, username i password wykorzystamy domyślne zdefiniowane w docker compose. Pozostaje nam zatem adres IP. Sprawdźmy zatem jak nasz klaster w przypadku konfiguracji docker desktop widzi sieci. Posłużymy się podem uruchomionym na naszym klastrze, uruchomimy go za pomoca naszego pliku konfiguracyjnego ubuntu-pod.yml: apiVersion: v1 kind: Pod metadata: name: ubuntu-pod namespace: default spec: containers: - name: ubuntu-container image: ubuntu:latest command: - sleep - "infinity" Wydajemy polecenie: $ kubectl apply -f ubuntu-pod.yml A potem łączymy się do naszego poda $ kubectl exec -n default -it ubuntu-pod -- /bin/bash I wydajemy zestaw komend: apt update ping apt install iputils-ping telnet ping or Adres IP_NODE_CLUSETR możemy zdobyć z polecania: $ kubectl get nodes -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME docker-desktop Ready control-plane 3h24m v1.27.2 172.31.255.3 Docker Desktop 5.15.90.1-microsoft-standard-WSL2 docker://24.0.6 Jak ktoś nie ufa ping można jeszcze uruchomić telnet ( or ) Zatem mamy wszystkie informacje. Możemy uzupełnić nasz db.yml --- apiVersion: v1 kind: Secret metadata: name: awx-postgres-configuration namespace: default stringData: host: 192.168.79.146 port: "5432" database: awxdb username: postgres password: "example" sslmode: disable type: unmanaged type: Opaque Dodajemy sekrety Do naszej pierwotnej konfiguracji kustomization.yaml dodajemy dodatkowa linijkę z naszym plikiem db.yml ... resources: - github.com/ansible/awx-operator/config/default?ref=2.7.0 - db.yml ... Zmiany zapisujemy i uruchamiamy nasze polecenie kubectl apply -k . ... secret/awx-postgres-configuration created ... kubectl poinformuje nas o tym że sekret został dodany / stworzony. Teraz dodajemy nasz awx.yml do kustomization.yaml ... resources: - github.com/ansible/awx-operator/config/default?ref=2.7.0 - db.yml - awx.yml ... Zmiany zapisujemy i uruchamiamy nasze polecenie kubectl apply -k . Po wydaniu polecenia możemy od razu wskoczyć w logi naszego awx-menagera $ kubectl logs -f deployments/awx-operator-controller-manager -c awx-manager Warto podczas działania uruchamiania naszych podów i konfiguracji potrzeć czy jakie dane przechodzą do naszego postgres. Z poziomu kubectl możemy sprawdzić nasze pody czy mają odpowiedni status: kubectl get pods -l "app.kubernetes.io/managed-by=awx-operator" Oraz na jakim porcie działa nasza aplikacja: kubectl get svc -l "app.kubernetes.io/managed-by=awx-operator" Hasło do naszego panelu możemy pobrać z polecenia: kubectl get secret awx-admin-password -o jsonpath="{.data.password}" | base64 --decode ; echo Mamy nasz panel i możemy się zalogować - oczywiscie to tylko testowa konfiguracja ale na jej bazie możemy już planować nasze wdrożenia. A w tym artykule to już wszystko. Zapraszam do kolejnych wpisów.

Apple udostępnił aktualizację łatająca luki bezpieczeństwa: https://support.apple.com/en-us/HT213982 https://support.apple.com/en-us/HT201222 udostępniono też aktualizacje w linii 16 oraz 15 (tutaj wspierany jest np. iPhone 6s, który wyszedł w 2015 roku!) W iOS 17.1 załatano aż trzy podatności umożliwiające na wykonanie kodu w OS, po wejściu na zainfekowaną stronę: Impact: Processing web content may lead to arbitrary code execution Data wydania: 25 października 2023 1. Kontakty - Wpływ: Aplikacja może uzyskać dostęp do wrażliwych danych użytkownika. - Opis: Poprawiono prywatność danych dziennika. 2. CoreAnimation - Wpływ: Aplikacja może spowodować odmowę usługi (denial-of-service). - Opis: Poprawiono zarządzanie pamięcią. 3. Find My - Wpływ: Aplikacja może odczytać wrażliwe informacje o lokalizacji. - Opis: Poprawiono zarządzanie pamięcią podręczną. 4. ImageIO - Wpływ: Przetwarzanie obrazu może prowadzić do ujawnienia pamięci procesu. - Opis: Poprawiono zarządzanie pamięcią. 5. IOTextEncryptionFamily - Wpływ: Aplikacja może wykonywać dowolny kod z uprawnieniami jądra. - Opis: Poprawiono zarządzanie pamięcią. 6. Kernel - Wpływ: Atakujący może omijać zabezpieczenia pamięci jądra. - Opis: Poprawiono zarządzanie pamięcią. 7. Mail Drafts - Wpływ: Funkcja "Hide My Email" może zostać nieoczekiwanie wyłączona. - Opis: Poprawiono zarządzanie stanem. 8. mDNSResponder - Wpływ: Urządzenie można śledzić za pomocą adresu MAC Wi-Fi. - Opis: Usunięto podatny kod. 9. Passkeys - Wpływ: Atakujący może uzyskać dostęp do kluczy bez uwierzytelniania. - Opis: Poprawiono sprawdzanie. 10. Photos - Wpływ: Zdjęcia w ukrytym albumie mogą być przeglądane bez uwierzytelniania. - Opis: Poprawiono zarządzanie stanem. 11. Pro Res - Wpływ: Aplikacja może wykonywać dowolny kod z uprawnieniami jądra. - Opis: Poprawiono zarządzanie pamięcią. 12. Siri - Wpływ: Atakujący z fizycznym dostępem może używać Siri do uzyskiwania wrażliwych danych użytkownika. - Opis: Ograniczono opcje dostępne na zablokowanym urządzeniu. 13. Status Bar - Wpływ: Urządzenie może nieustannie nie blokować się. - Opis: Poprawiono zarządzanie interfejsem użytkownika. 14. Weather - Wpływ: Aplikacja może uzyskać dostęp do wrażliwych danych użytkownika. - Opis: Poprawiono prywatność danych dziennika. 15. WebKit (różne błędy) - Wpływ: Przetwarzanie treści internetowych może prowadzić do wykonywania dowolnego kodu lub odmowy usługi. - Opis: Poprawiono zarządzanie pamięcią, usunięto błędy logiczne i poprawiono sprawdzanie. Uwaga: Wszystkie powyższe aktualizacje są dostępne dla modeli iPhone XS i nowszych oraz różnych modeli iPad Pro, iPad Air, iPad oraz iPad mini. Zalecamy instalację tych aktualizacji, aby zapewnić bezpieczeństwo i ochronę swoich urządzeń Apple.

Wśród narzędzi CI/CD Jenkins jest jednym z najpopularniejszych i darmowych narzędzi dostępnych w wielu organizacja i procesach devops. Jedni go kochają inni nienawidzą. Sam artykuł nie jest o tym czy to narzędzie jest popularne czy też nie, ale każdy sie zemną zgodzi że jest idelnym toolsetem do nauki procesów CI/CD oraz do automatyzacji zadań. Pierwszy projekt w jenkins Kluczem do każdej konfiguracji jest dobre rozplanowanie tego co chcemy uzyskać i co mamy ustawić / skonfigurować. Weźmy rozdzielmy na czynniki pierwsze konfiguracje z tego materiału - Terraform w procesach CI/CD w postaci grafu Prosty przepływ składający się z 5 jobów z których w łatwy sposób wyróżnić 3 główne od których zależy cała logika. Logika w tym przypadku przekładająca się na konfigurację w claud za pomocą IaC narzędzia jakim jest terraform. I choć długo podobały mi się projekty zwane "Freestyle project", które swoją prostotą powodują że łatwiej nam wejść w skórę devopsa i skonfigurować taki projekt to mają one pewną wadę. Spójrzmy na te 5 poszczególnych jobów. Mają one na pierwszy rzut oka jeden wspólny kod git, jednak jak możemy zobaczyć musimy go w każdym jobie podawać osobno i konfigurować. Dostarcza to dodatkowej pracy. A i może spowodować to, że przy n-tej próbie wpisywania i uzupełniania tych danych możemy zrobić literówkę. I wcale tu nie chodzi o jakieś generalizowanie czy też zniechęcenie do tego rodzaju projektów czy też konstrukcji własnych procesów CI/CD własnie w ten sposób. A gdyby tak tą całą konfiguracje przekształcic w kod i zapisać za pomocą pliku tekstowego i przechowywać ją w git. Znacząco by to ułatwiło konfiguracje i pracę z takim pipelinem / projektem. Jenkins pipeline projekt By sprostać temu zadaniu spójrzmy na pipeline syntax dostępnym w dokumentacji Jenkins do pipeline. Na podstawie zgromadzonej tu dokumentacji możemy stworzyć prosty zarys naszego projektu. Spójrzmy najpierw na prostą konstrukcje, która nam wszystko wytłumaczy: Podnajmy analizie ten "pseudo kod": agent any: Wskazuje, że ten potok może być uruchamiany na dowolnym agencie dostępnym w środowisku Jenkins. stage('Build'): Etap ten ma za zadanie kompilację kodu źródłowego. Po pomyślnej kompilacji, artefakty z budowy są przenoszone w pożądaną lokalizację. stage('Test'): W tym etapie najpierw sprawdza się, czy artefakty są obecne we właściwej lokalizacji. Następnie dane testowe są ładowane do bazy danych. Wykonuje się testy. Kontynuacja następuje tylko w przypadku, gdy testy zostaną zakończone pomyślnie. stage('Deploy'): W etapie tym pobierany jest przetestowany kod, który następnie jest wdrażany na produkcję. Spójrzmy raz jeszcze na nasz graf tak by zobaczyć czy uda nam się dostrzec te elementy w naszej konfiguracji: Wyodrębniłem trzy kroki: Krok pierwszy to nasz build - czyli pobieranie kody z repozytorium git w kontekście naszego joba czyli naszej deklaracji w jenkins pepline. Krok drugi tu zbiorczo nasze test: validate, security, plan, graph - z diagramu tez widzimy że nasze security i graph nie jest istotne z punktu przepływy pracy naszego joba. Ich rezultat nie wpływa na nasz pipeline (jeżeli podąrzamy za zielona linią). Krok trzeci nasz deploy - czyli w tym przypadku apply, który to już publikuje nasze zmiany w stanie terraform i na naszym cloud. Przedstawmy to w postaci pseudokodu: node: Pseudo-kod ten jest zapisany w starszym stylu deklaratywnnych pipeline'ów Jenkins. Używa on słowa kluczowego `node`, co oznacza, że wszystkie etapy i kroki wewnątrz tego bloku będą wykonywane na jednym agentcie Jenkins. stage('Build'): W tym etapie wydaje się, że kod z repozytorium git jest klonowany. Następnie następuje inicjalizacja środowiska Terraform poprzez komendę `terraform init`. stage('Test'): Etap testowania rozpoczyna się od sprawdzenia poprawności składniowych i błędów w konfiguracji za pomocą `terraform validate`. Następnie jest tworzony plan działania (bez rzeczywistego stosowania zmian) za pomocą `terraform plan`. Warunek if: Sprawdza się status bieżącej kompilacji (`currentBuild.currentResult`). Jeśli wynik bieżącej kompilacji to 'SUCCESS', oznacza to, że etapy 'Build' i 'Test' zakończyły się pomyślnie i można przejść do etapu 'Deploy'. stage('Deploy'): W tym etapie rzeczywiste zmiany są stosowane w środowisku za pomocą `terraform apply`. Jest to prosta definicja pipeline, która wykorzystuje narzędzie Terraform do budowy, testowania i wdrażania infrastruktury jako kod (Infrastructure as Code, IaC). Kluczowe etapy obejmują inicjalizację Terraform, walidację, planowanie i zastosowanie zmian w infrastrukturze. Aby ten pseudo-kod mógł być używany w rzeczywistym środowisku, muszę zastąpić komentarze rzeczywistymi poleceniami i skryptami, które będą realizować te działania. Warto również dodać obsługę błędów i ewentualne notyfikacje w przypadku niepowodzenia któregokolwiek z kroków. Ja jeszcze dodatkowo rozbije DEPLOY na osobny Jenkinspepline. I powstaną mi dwa joby Jenkins pepline które, nazwe plan i apply. Skąd ten jenkins pipeline Można zadać pytanie skąd zatem brać tą konfigurację - nauka składni może być barierą wejścia która, bardziej przekonuje nas do freestyle projekt niż minusy stosowania właśnie powtórzeń i powieleń. Możemy skorzystać z generatora który, jest dostępny i wbudowany w Jenkins. Pomoże on nam skonfigurować nasz kod który, jest potrzebny do działania z Jenkins pepline. Aby wejsść w generator do nazwy naszego projektu należy dopisać po "/" fraze "pipeline-syntax/" - dla przykładu https://jenkins.koska.in/job/HomeEnv/job/Terraform/job/testo/pipeline-syntax/ Albo w konfiguracji naszego Jenkins pipline job przejść do sekcji Configuration i kikamy Pipeline Syntax I z pomocą składni Jenkins pipeline uda nam się złożyć naszą konfigurację. Oczywiście musimy pamiętać o dodaniu naszych sekretów itp tak by nasza konfiguracja kodu była bezpieczna i nie powodowała wycieku danych: Oto szczegółowa analiza dostarczonego kodu Jenkins pipeline: Agent: Pipeline jest wykonywany na agencie z etykietą `terraform`. W przypadku braku dostępności agenta, Jenkins będzie próbować ponownie do 5 razy. Etap 'Clean workspace': Wysyła powiadomienie do Slacka o rozpoczęciu tego etapu. Czyszczenie przestrzeni roboczej za pomocą komendy `cleanWs()`. Etap 'Repo Clone': Wysyła powiadomienie do Slacka o rozpoczęciu tego etapu. Klonuje repozytorium git z określonej konfiguracji (z gałęzi 'main'). Etap 'terraform init': Wysyła powiadomienie do Slacka o rozpoczęciu tego etapu. Inicjalizuje Terraform z konfiguracją backendu. Etap 'terraform validate': Wysyła powiadomienie do Slacka o rozpoczęciu tego etapu. Sprawdza poprawność składni konfiguracji Terraform za pomocą `terraform validate`. Etap 'terraform plan': Wysyła powiadomienie do Slacka o rozpoczęciu tego etapu. Uruchamia `terraform plan` z uwzględnieniem różnych zmiennych. Sprawdza wynik w poszukiwaniu określonych błędów i wysyła powiadomienia na Discord w przypadku wykrycia. Sekcja 'post': W zależności od wyniku wykonania pipeline, wykonuje różne kroki, takie jak archiwizacja artefaktów i wysyłanie powiadomień do Slacka o statusie. Powiadomienia są dostosowane do różnych stanów wyników, takich jak `success`, `regression`, `fixed`, `aborted`, `unstable` i `unsuccessful`. Pipeline ten skupia się na operacjach związanych z Terraform, takich jak inicjalizacja, walidacja i planowanie. Ważnym aspektem jest również komunikacja z zespołem poprzez powiadomienia na Slacka oraz w przypadku błędów na Discord. Teraz z apply pójdzie nam jeszcze łatwiej: Analizując dostarczony kod, możemy zidentyfikować kilka różnic i nowych funkcjonalności w porównaniu do poprzedniej wersji: Options: - W kodzie dodano sekcję `options`, która umożliwia stosowanie globalnych opcji dla całego pipeline. Tutaj wykorzystano `timestamps()`, co sprawia, że każdy log z tego pipeline będzie zawierał znacznik czasu, ułatwiając analizę logów. Etap "copy plan.file": - Ten etap służy do kopiowania artefaktów z innego projektu/buildu w Jenkinsie. Specjalnie kopiuje plik `plan.file` z projektu o nazwie `WorkEnv/TerraformWorkEnv/work-familmed-terraform-prod/terraform-plan`. Opcja `fingerprintArtifacts: true` oznacza, że Jenkins będzie śledzić i zapisywać metadane dla skopiowanych artefaktów, co może być przydatne w celach audytu. Etap "terraform apply": - W tym etapie następuje faktyczne zastosowanie planu infrastruktury terraform. Najpierw jest inicjalizacja terraform z odpowiednią konfiguracją backendu (poprzednio omówione). Następnie, używając flagi `-auto-approve`, automatycznie zatwierdza się zmiany zaproponowane przez terraform bez potrzeby ręcznej interwencji. Wykorzystuje to wcześniej skopiowany plik `plan.file`. Post: - Sekcja `post` i jej działanie pozostały takie same, jak w poprzedniej wersji kodu, i zostały już omówione w poprzedniej analizie. Obejmuje ona różne akcje, które mają zostać wykonane po zakończeniu wszystkich etapów, w zależności od wyniku pipeline (np. zawsze wysyłać wiadomość na Slack, archiwizować artefakty po udanej kompilacji itp.). Podsumowując, ten kod Jenkins pipeline koncentruje się na pobieraniu i aplikowaniu planu terraform, zapewniając odpowiednie powiadomienia na Slack oraz archiwizację niezbędnych artefaktów. Obejmuje także znaczniki czasu dla wszystkich logów dzięki globalnej opcji `timestamps()`. Względem poprzedniej wersji kodu brakuje etapów związanych z walidacją i planowaniem terraform, co sugeruje, że ten pipeline jest prawdopodobnie kontynuacją lub dopełnieniem procesu rozpoczętego w poprzednim kodzie. Spójrzmy teraz na nasz stage view. Jak poprzednio (mój podział w freestyle) tu też widzimy podział na etapy. A sama konfiguracja naszego projektu polega jedynie na wskazaniu gdzie szukać naszego kodu w jakim repozytorium + plus konfiguracja credential Oczywiście konfiguracji w naszym jenkins pepline jest więcej i możemy bardziej wymyślne konfiguracje tu układać. Jednak w tym wpisie to wszystko. Pozdrawiam i do usłyszenie.

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

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

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