Search Results

Ufanie modelom AI czy też ogólnie sztucznej inteligencji może być zgubne. To co dostaniemy powinniśmy sprawdzać i analizować by mieć w 100% pewność że otrzymujemy to co chcemy. Tylko gdzie tu automatyzacja pełna klasą która właśnie likwiduje ten czynnik ludzki. Tak ochoczo zastępowany przez AI w organizacjach. Kto próbował dodzwonić się na infolinie po rewolucji AI ten wie, że to do końca nie działa. Dzień sądu z AI - czy to już terminator W moim przykładzie przypomina mi się scena z Terminatora 3 gdzie ów terminator pod naciskiem Cathrine Bruster zmienia zdanie i idzie ratować ojca protagonistki. Ok ale do sedna. Mam sobie plik xml, ale nie byle jaki dokładnie to ten plik zawiera konfigurację mojej maszyny wirtualnej działającej na KVM w linux. XML wydobyty poleceniem: virsh dumpxml win2019 > win2019.xml A więc konfiguracja tego xml jest poprawna i napewno nie zawiera błędnych bloków które mogły by zmylić Model Językowy czy też nasze AI. Zatem poprosiłem ów model o analize tego pliku - oto moj prompt: W załączonym pliku win2019.xml przekazuję Ci konfigurację maszyny wirtualnej z windows server 2019. Maszyna wirtualna ta działa na systemie operacyjnym Linux Ubuntu 24.04 na hypervizor KVM. Polecenie użyte do ściągnięcia tej konfiguracji to virsh dumpxml win2019 > win2019.xml. Wykonaj analizę tego pliku win2019.xml i napisz mi co jest potrzebne do przeniesienia tej maszyny wirtualnej na innych host z sytemem Ubuntu 24.04. Dokładnie to jakie pliki, konfiguracje powinienem odtworzyć na nowym systemie operacyjnym w celu uruchomienia tej maszyny wirtualnej. Otrzymałem informacje że maszyna jest uruchomiona w trybie UEFI, że trzeba sprawdzić czy nie są z nia powiązane snapshoty. Dostałem pełną informację co jest mi potrzebne, na co powinienem zwrócić uwagę. Oraz zostałem poproszony o dodatkowe informacje które pomogą mi. I moja uwagę przykuła jedna informacja: A dokładnie związana z siecią: Postanowiłem że sprawdzę ów mój plik xml: Jak możemy zobaczyć całą sekcję związaną z sieci model językowy poprostu sobie zmyślił. Ok, ok - ktoś powie miałeś ujowy prompt. Ale spójrzmy na inną sytuację. Niedawno w domu miałem problemy z internetem. Dzwonie zatem na infolinie i jak się ucieszyłem że w słuchawce przywitał mnie miły głos AI. AI: Jestem wirtualnym asystentem AI w czym mogę pomóc? JA: Mam problem z usługa internet, nie działa AI: Poczekaj chwilę pozwól że sprawdzę połączenie ..... ..... AI: Zakończyłam właśnie sprawdzanie Twojego modemu. Nie wykryłam żadnych problemów z Twoim Modemem/Routerem. Czy problem nadal występuje. JA: Tak, nie działa internet AI: Dobrze - proszę odłącz modem z zasilania na 90 sekund i podłącz go ponownie, po tej operacji skontaktuj się z infolinią ponowanie. Tu nastąpiło rozłączenie - ok myślę dobrze zanim podejdę wyłącze modem odczekam te 90 sekund i włączę ponownie - to fakt trochę to potrwa lepiej nie blokować lini. Ok idę poweroff modemu, mowie idę zrobię sobie herbatę napewno będzie wtedy te 90 sekund. Herbata zrobiona idę włączyć modem. Czekam dioda sygnalizuje problem z bazą - sprawdzam faktycznie nie ma internetu. Dzwonię raz jeszcze. Dzwonie zatem na infolinie i jak się ucieszyłem że w słuchawce przywitał mnie miły głos AI. AI: Jestem wirtualnym asystentem AI w czym mogę pomóc? JA: Mam problem z usługą internet, nie działa AI: Poczekaj chwilę pozwól, że sprawdzę połączenie ...... ...... AI: Wykryto że....... AI: Twój modem niedawno został zrestartowany - proszę odczekaj chwilę nim nasze urządzenia się zsynchronizują i skontaktuj się z nami ponownie jeżeli wystąpią dalsze problemy z działaniem usługi Tu znów nastąpiło rozłączenie - hmmm sprawdzają uptime. Świetnie - ok pojdę zatem do sklepu i tak miałem iść po drobne śniadanie. Cała droga zajeła mi jakie 30 minut. Wracam do domu patrze nie mam internetu. Ok zatem dzwonię. Dzwonie zatem na infolinie i jak się ucieszyłem, że w słuchawce przywitał mnie miły głos AI. AI: Jestem wirtualnym asystentem AI w czym mogę pomóc? JA: Mam problem z usługa internet, nie działaAI: Poczekaj chwilę pozwól że sprawdzę połączenie ..... ..... AI: Zakończyłam właśnie sprawdzanie Twojego modemu. Nie wykryłam żadnych problemów z Twoim Modemem/Routerem. Czy problem nadal występuje. JA: Tak, nie działa internet AI: Dobrze - proszę odłącz modem z zasilania na 90 sekund i podłącz go ponownie, po tej operacji skontaktuj się z infolinią.... JA: Tak już to robiłem AI: Rozumiem. Proszę odłącz modem z zasilania na 90 sekund i podłącz go ponownie, po tej operacji skontaktuj się z infolinią ponownie. Tu nastąpiło rozłączenie - zostałem zdropowany WTF. Ok, wykonuje zatem operację ponownie. Odłączam modem od zasilania na 90 sekun. Robie to z zapasem na 120 sekund. Podłączam ponownie, widzę że się nie synchronizuje, sprawdzam nie mam internetu zatem dzwonię. Dzwonie zatem na infolinie i jak się ucieszyłem że w słuchawce przywitał mnie miły głos AI. AI: Jestem wirtualnym asystentem AI w czym mogę pomóc? JA: Mam problem z usługą internet, nie działa AI: Poczekaj chwilę pozwól, że sprawdzę połączenie ...... ...... AI: Wykryto że ...... ...... ...... ...... ...... ...... AI: Twój modem niedawno został zrestartowany - proszę odczekaj chwilę nim nasze urządzenia się zsynchronizują i skontaktuj się z nami ponownie jeżeli wystąpią dalsze problemy z działaniem usługi Zostałem zdropowany Zadzwoniłem raz jeszcze. Dostałęm ponownie ten komunikat że modem niedawno został uruchomiony bla bla i ponownie drop. Zjadłem śniadanie. Ok dzwonię: Dzwonie zatem na infolinie i jak się ucieszyłem, że w słuchawce przywitał mnie miły głos AI. AI: Jestem wirtualnym asystentem AI w czym mogę pomóc? JA: Mam problem z usługa internet, nie działa AI: Poczekaj chwilę pozwól że sprawdzę połączenie ..... ..... ..... ..... ..... ..... ..... AI: Zakończyłam właśnie sprawdzanie Twojego modemu. Nie wykryłam żadnych problemów z Twoim Modemem/Routerem. Czy problem nadal występuje. JA: Tak, nie działa internet, juz dzwoniłem do was w tej sprawie AI: Dobrze - proszę odłącz modem z zasilania na 90 sekund i podłącz go ponownie, po tej operacji skontaktuj się z infolinią.... JA: Tak już to robiłem, połacz mie z konsultatnet AI: Rozumiem. Proszę odłącz modem..... JA: Już to robiłęm połacz mnie z konsultatnem AI: Rozumiem. Proszę odłącz modem zasilania na 90 sekund i podłącz go ponownie, po tej operacji skontaktuj się z infolinią ponownie. Drop połączenia. Kiedy kolejny raz już zadzwoniłem od razu prosiłem o podłączenie mnie z konsultantem. Po kilku odpowiedziach, nie rozumiem i nasi konsultanci są zajęci udało dodzwonić w końcu i porozmawiać z żywą osobą. Dowiedziałem się że w moim rejonie jest awaria i zostanie usunięta do 2 godzin. Podziękowałem za informacje i z ciekawości raz jeszcze zadzwoniłem by pogadać z AI: Dzwonie zatem na infolinie i jak się ucieszyłem że w słuchawce przywitał mnie miły głos AI. AI: Jestem wirtualnym asystentem AI w czym mogę pomóc? JA: Mam problem z usługa internet, nie działa AI: Poczekaj chwilę pozwól że sprawdzę połączenie ..... ..... AI: Zakończyłam właśnie sprawdzanie Twojego modemu. Nie wykryłam żadnych problemów z Twoim Modemem/Routerem. Czy problem nadal występuje. JA: Tak, nie działa internet AI: Dobrze - proszę odłącz modem z zasilania na 90 sekund i podłącz go ponownie, po tej operacji skontaktuj się z infolinią ponownie. Zostałem zdropowany. Podsumowanie Pamietajmy że AI wdrażają ludzie który popełniają błędy i złe instrukcje mogą prowadzić do problemu. Pamietajmy też że AI lubi ściemniać, halucynować czy jak zwał tak zwał. A duże firmy jak w ticket napiszą, że nie mam problemu to nie ma problemu - nie mamy pańskiego płaszcza i co pan nam zrobi :)

Decydując się na zarządzanie infrastrukturą za pomocą Terraforma musimy wybrać czy robimy to za pomocą IaC (deklarujemy nasza infrastrukturę w kodzie), czy zamierzamy dalej robić to ręcznie. Ponieważ zmiany ręczne w miedzy czasie działania naszej infrastruktury na bazie terraforma może prowadzić do dryftu konfiguracyjnego. Ten artykuł będzie o stworzeniu modułu który, ułatwi nam zarządzanie infrastrukturą DNS w OVH. Jednocześnie ten artykuł jest reklamom kursu mojego autorstwa który, już niedługo będzie dostępny. Kurs ten jest przeznaczony dla osób które, zaczynają przygodę z terraformem i chcą podnieść rownież swoja wiedzę na temat terraform. Zatem zaczynamy. Podstawy naszego modułu do Domain OVH Zanim zaczniemy musimy ustaliś podstawy. Po pierwsze w naszym module bedziemy bazować na dwóch resorces: ovh_domain_zone_record ovh_domain_name_servers Pracując z ovh_domain_zone_record musimy zwrócić uwagę na informację którą, sam dostawca OVH umieszcza nam w tym zasobie: Warning The Change in text format feature available in the web console will update the ovh_domain_zone_record ids if you use it. Hence if you have created your records with terraform, you will get some record has been deleted errors. The workaround is to terraform import all the records with the updated ids and to stop to mix web console and terraform. Poniżej wyjaśniam dlaczego ostrzeżenie z dokumentacji providera OVH ma krytyczne znaczenie  i co dokładnie się dzieje, gdy wprowadzisz zmiany w strefie poza Terraformem , zwłaszcza przy użyciu opcji Change in text format  w panelu OVH. Dlaczego to ważne Jak Terraform „wiąże” zasoby z rzeczywistością Każdy zasób w stanie Terraform jest powiązany z konkretnym identyfikatorem (ID)  zasobu w systemie docelowym. Dla ovh_domain_zone_record provider posługuje się ID rekordu DNS nadawanym przez OVH . To ID jest kluczowe: Terraform odtwarza rzeczywistość właśnie na jego podstawie, a nie na podstawie treści rekordu (target/TTL itd.). → Gdy ID w OVH się zmieni, a stan Terraform nadal wskazuje stare ID , Terraform uważa, że „tego” zasobu już nie ma. Co robi „Change in text format” w panelu OVH To przełącznik w konsoli DNS OVH, który zmienia sposób zapisu treści (np. TXT) — m.in . cudzysłowy, łączenie/rozdzielanie na segmenty, itp. (czyli format prezentacji treści). W praktyce ta operacja może skończyć się utworzeniem nowego rekordu  po stronie OVH (z nowym ID ) zamiast „edytowaniem” istniejącego.  Sama społeczność/problemy w repo providera OVH odnotowują przypadki, w których ID rekordów DNS „zmieniały się”  po operacjach wykonanych spoza Terraformu, co prowadziło do potrzeby ręcznego dostosowania stanu (a niekiedy edycji/podmiany ID w state).  Co się stanie, jeśli zignorujesz to ostrzeżenie Plan/Apply kończy się błędami o „usuniętych” rekordach Podczas terraform plan/apply provider próbuje odczytać rekord o starym ID . Ponieważ w OVH po zmianie formatu powstał nowy rekord z nowym ID , odczyt starego ID zwróci „nie ma takiego rekordu”. Objawy: komunikaty w stylu record has been deleted  / resource not found , plan pokazuje usunięcie starego  i utworzenie nowego , mimo że treściowo rekord już istnieje w OVH (tylko z innym ID). Ryzyko duplikatów i „flappingu” konfiguracji Jeśli Terraform spróbuje „odtworzyć” rekord z configu (bo nie znalazł starego ID), a w OVH już istnieje „taki sam” rekord (tylko z nowym ID), możesz dostać: duplikaty (dwa bardzo podobne wpisy), błędy o „istniejącym już rekordzie”, „thrash” — ciągłe różnice w planie, bo panel mógł też przeformatować TXT  (np. cudzysłowy, podział na segmenty). (Dodatkowo znane są niuanse TTL w OVH: domyślny TTL bywa reprezentowany jako 0, co w niektórych wersjach providera powodowało nieoczekiwane różnice/duplikaty, jeśli pomieszać UI i Terraform. To inny, ale pokrewny objaw miksowania narzędzi.)  Niestabilne pipeline’y i incydenty CI/CD z terraform plan zaczyna regularnie failować , bo stan nie zgadza się z rzeczywistością. Dla krytycznych rekordów (np. MX/DMARC/DKIM ) błędne rekreacje/duplikaty potrafią skutkować opóźnieniami/awariami poczty  czy problemami z weryfikacjami domeny. Dlaczego samo „porównanie treści” nie wystarcza Nawet jeśli Twój HCL (np. w naszym module) tworzy ten sam  rekord (ten sam subdomain, fieldtype, target), Terraform nadal „widzi” zasób przez pryzmat ID zdalnego . Zmiana ID poza Terraformem = dryf stanu  (state drift). Dopóki nie „nauczysz” Terraformu nowego ID, plan/aplikacja będą się wykładać lub generować niechciane zmiany. To nie jest „bug w module” — to fundamentalna cecha działania Terraformu. Zalecany workflow (bezpieczny) Zasada „single source of truth” Strefą zarządzasz albo  w 100% przez Terraform, albo  ręcznie w panelu — ale nie jednym i drugim równocześnie. Zwłaszcza nie używaj  w panelu opcji Change in text format  dla rekordów zarządzanych już przez Terraform. Jeśli musisz zmienić coś w panelu (np. pilny hotfix): Zapisz, które rekordy zmieniono (panel/Historia lub API). Zaktualizuj stan Terraform  tak, aby wskazywał nowe ID  tych rekordów: najprościej: terraform import pod adres Twojego zasobu (w module adres będzie miał postać module..ovh_domain_zone_record.[...]). Składnię i użycie importu znajdziesz w oficjalnym dokumencie CLI.  jeżeli rekordów jest bardzo dużo, skorzystaj z narzędzi/skryptów do masowego importu (np. community tools generujące kod i skrypty importu na bazie API OVH).  Gdyby brakowało precyzyjnych danych o nowych ID albo import wciąż nie „siadał”, niektórzy radzą sobie przez ręczną korektę pliku stanu  (ostateczność) lub całkowitą rekreację rekordów przez Terraform (czyściutko, ale z przerwą/usunięciem istniejących wpisów). Przypadki takie są opisywane w issue trackerze providera.  Utrzymuj spójny format danych w kodzie Dla TXT trzymaj się jednego sposobu zapisu (np. zawsze cudzysłowy w JSON-ie: "\"v=spf1 ...\""), żeby uniknąć różnic formatu z UI. Unikaj „kliknięcia” Change in text format  — ta opcja potrafi wprowadzić różny layout wartości TXT (np. segmentację), co z kolei prowokuje Terraform do zmian. Szybka checklista, gdy widzisz „record has been deleted” terraform plan pokazuje, że rekord „zniknął”, ale w panelu dalej go widzisz → ID się zmieniło . Ustal nowe ID (przez API/inspekcję, narzędzia pomocnicze). terraform state rm  (jeśli chcesz odpiąć stary wpis ze stanu). terraform import  – wprowadź nowe ID do stanu.  terraform plan — plan powinien być czysty (albo pokazać już tylko merytoryczne różnice). TL;DR Nie mieszaj  panelu OVH i Terraformu dla tych samych rekordów – w szczególności nie używaj „Change in text format”  dla rekordów zarządzanych przez Terraform. To może zmienić ID  rekordu po stronie OVH.  Zmienione ID = dryf stanu  → Terraform melduje „rekord usunięty”/„stworzyć nowy” i potrafi generować duplikaty lub błędy. Jeśli już tak się stało: zrób import nowych ID  (terraform import) zamiast pozwalać Terraformowi „na ślepo” tworzyć nowe wpisy.  Dodatkowo unikaj innych rozjazdów formatu (np. TTL 0 vs domyślny TTL), bo to też potrafi powodować niechciane różnice po miksowaniu UI i code. Tworzymy nasz moduł terraform Nasz moduł będzie bazował na zasobach ovh_domain_zone_record i ovh_domain_name_servers. Pierwszy zasób pozwala na dodanie naszych rekordów w naszym DNS. Drugi pozwala na ustawienia naszych adresów serverów DNS które mogą zarządzać tą domeną - czyli możemy zrobić transfer domeny na inny zewnętrzny server który będzie zarządzał tą domeną. omówmy sobie każdy z tych zasobów. Jak działa ovh_domain_zone_record ovh_domain_zone_record to elementarny zasób do tworzenia/aktualizacji pojedynczego rekordu DNS  w strefie zarządzanej przez OVH. Najważniejsze argumenty: zone  (string, wymagany)  – nazwa strefy DNS (np. example.com ). subdomain  (string, wymagany)  – etykieta/host; może być pustym stringiem "" dla rekordu w apex (gołej domeny). fieldtype  (string, wymagany)  – typ rekordu (np. A, MX, TXT, …). target  (string, wymagany)  – wartość rekordu (format zależy od typu; np. IP/FQDN/ciąg TXT). ttl  (number, opcjonalny)  – TTL rekordu; musi być ≥ 60  (w nowszej dokumentacji SDK Pulumi dla OVH, która bazuje na tym samym API, jest to wyraźnie opisane).  Zachowania i pułapki charakterystyczne dla OVH: MX : priorytet należy podać w target , np. "10 mx1.example.com ." (to cecha API/OVH; nie ma oddzielnego pola na priorytet). TXT : trzymaj konsekwentny format (cudzysłowy), aby uniknąć „wiecznych” diffów planu. TTL : w części scenariuszy domyślny TTL bywa reprezentowany po stronie OVH jako 0, co historycznie prowadziło do duplikatów/rozjazdów, gdy miesza się panel i Terraform (opis problemu w issue providera).  Zmiany w panelu (UI) a ID rekordu : użycie w panelu opcji typu „plain text / Change in text format” może nadać rekordom nowe ID , przez co Terraform widzi „usunięto” i „trzeba utworzyć nowy”. Zalecenie: albo w 100% zarządzasz przez Terraform, albo – jeśli już zmieniono w UI – wykonujesz terraform import  z nowymi ID i nie mieszasz  narzędzi dalej. (To zachowanie jest potwierdzone na issue trackrze providera).  Jakie typy rekordów możesz dodać (OVH) OVH pozwala tworzyć standardowe rekordy DNS (zgodne z RFC) używane w praktyce. Poniżej lista z krótkim opisem i wskazówkami dot. target. (W nawiasach — co zwykle wpisujesz w target.) Adresowe / aliasy / delegacje A  – IPv4 (np. 203.0.113.10). AAAA  – IPv6 (np. 2001:db8::10). CNAME  – alias do FQDN zakończonego kropką (np. host.example.net .). NS  – delegacja do autorytatywnego serwera nazw (FQDN z kropką, np. ns1.example.net .). DNAME  – alias całej gałęzi  (deleguje wszystkie  subdomeny na nowy sufiks). OVH opisuje DNAME w swoich materiałach dla stref.  PTR  – wskazanie nazwy kanonicznej (używany gł. w strefach reverse). Poczta / usługi / tekst MX  – serwer(y) pocztowe z priorytetem  w target (np. "10 mx1.example.net ."). SRV  – lokalizator usługi; target to FQDN usługi (pozostałe parametry SRV określane są w implementacji po stronie API/providera; w praktyce w UI/CLI podajesz dodatkowe pola jak port/waga/prio). TXT  – dane tekstowe (SPF/DKIM/DMARC i inne polityki/atesty przechowuj jako TXT). OVH przewodniki konsekwentnie opisują SPF/DKIM/DMARC przez TXT .  Bezpieczeństwo / klucze / certyfikaty CAA  – autoryzacja CA (określa, które CA mogą wystawiać certy dla domeny). OVH opisuje to w kontekście rekordów strefowych.  SSHFP  – odcisk klucza SSH hosta (ułatwia weryfikację klucza). TLSA  – DANE: powiązanie certyfikatu/publicznego klucza TLS z nazwą w DNS. Telefonia / geolokalizacja / inne NAPTR  – przepisywanie nazw (VoIP/SIP itp.). LOC  – lokalizacja geograficzna (szer./dług./wys.). Uwaga o nowszych typach (HTTPS/SVCB):  społeczność OVH zgłasza chęć wsparcia HTTPS/SVCB i wynika z tego, że na dziś  (wg publicznych wątków) nie są one jeszcze obsługiwane  na serwerach nazw OVH. Planując je, licz się z ograniczeniami.  Kontekst i podstawy DNS wg OVH  – przewodniki i strony wsparcia OVH wyjaśniają ogólne typy rekordów (A/AAAA, MX, CNAME, TXT itp.) i ich zastosowania w strefie. To dobry punkt odniesienia, jeśli konfigurujesz strefę pierwszy raz lub migrujesz.  Praktyczne wskazówki do fieldtype/target FQDN-y w target  (CNAME/MX/NS/SRV/DNAME) zapisuj z kropką końcową  (np. mail.example.net .). MX : wpisuj „prio spacja host.” , np. "10 mx1.example.net .". TXT : dla poprawnego porównywania stanu używaj konsekwentnych cudzysłowów (np. "\"v=spf1 include:_ spf.google.com -all\""). TTL : trzymaj się wartości ≥ 60 (wprost wymóg w aktualnych materiałach SDK Pulumi dla OVH).  Import/stan i miksowanie narzędzi Jeśli ktoś kliknie w panelu  (np. zmiana „text format”) i rekordy dostaną nowe ID , Terraform zacznie widzieć „usunięcia/utworzenia”. Rozwiązanie: terraform import  dla dotkniętych rekordów i nie mieszać dalej  UI z IaC.  Co robi ovh_domain_name_servers Zasób służy nie do dodawania rekordów DNS w strefie , ale do ustawienia autorytatywnych serwerów nazw (NS) dla domeny w rejestrze  OVH. To operacja na poziomie rejestracji domeny , a nie samej strefy DNS. W praktyce: Wskazujesz listę nazw hostów NS , które mają obsługiwać Twoją domenę (np. dns104.ovh.net , ns104.ovh.net ). Dla własnych serwerów nazw w tej samej domenie  (tzw. child NS , np. ns1.example.com ) możesz (a często musisz) podać glue IP  (IPv4/IPv6), aby rejestr mógł je rozwiązać bez „kurzej/kanapki” zależności. To nie jest rekord A/AAAA  w strefie, tylko rekord glue  trzymany w rejestrze domeny. Wyjaśnienie, czym jest glue: „Glue record is used to define the IP address of a name server, to allow the domain to be resolved if the name server is under the same domain.”  Technicznie provider wykorzystuje endpoint /nameServers/update  OVH API — ta funkcja została dostarczona w PR implementującym ten zasób w providerze.  Kluczowe argumenty zasobu Minimalny przykład z testów providera wygląda tak: resource "ovh_domain_name_servers" "this" { domain = "example.com" server { host = "dns104.ovh.net" } server { host = "ns104.ovh.net" } } Dla child NS  (Twoje własne serwery w obrębie tej samej domeny) dodajesz ip : resource "ovh_domain_name_servers" "custom" { domain = "example.com" # własne, „child” NS z glue server { host = "ns1.example.com" ip = "192.0.2.53" } # IPv4 server { host = "ns2.example.com" ip = "2001:db8::53" } # IPv6 } To, że zasób przyjmuje bloki server { host, ip? } oraz że działa per- domain , wynika z implementacji testów i opisu PR dla tego zasobu.  Co dokładnie możesz „dodać/ustawić” z punktu widzenia OVH W ramach każdego server { ... }: host (wymagane)  – FQDN serwera nazw (np. ns1.example.com , dns104.ovh.net ). ip (opcjonalne)  – glue IPv4 lub IPv6  dla child NS  (jeśli host leży pod tą samą  domeną co domain). To nie  jest zwykły rekord A/AAAA; to wpis w rejestrze domeny (glue), używany tylko do bootstrapu rozwiązywania nazw.  Uwaga: dla TLD bywają restrykcje/specyfika  aktualizacji glue (np. wątki dot. .eu), więc gdy automat zgłasza błąd, to bywa ograniczenie po stronie rejestru/TLD, a nie Terraformu.  Import i praktyka użycia Import zasobu zwykle odbywa się po domenie  (w module bywa to indeksowane jako [0], bo zasób jest tworzony warunkowo). W Twoim przykładzie: import { to = module.zone_asdevops_cloud.ovh_domain_name_servers.this[0] id = "asdevops.cloud" } Jeśli wcześniej klikałeś w panelu  i zmieniłeś NS/glue, a chcesz wrócić do IaC, po prostu zaimportuj aktualny stan (domena ⇒ aktualne NS) i dalej zmieniaj już tylko  kodem. Dobre praktyki i ostrzeżenia (OVH) Nie mieszaj  panelu OVH i Terraformu dla tych samych  ustawień NS (analogicznie do rekordów DNS: UI potrafi zmienić identyfikatory/kształt danych i wprowadzić dryf stanu). Jeśli musisz coś zmienić „na szybko” w UI, terraform import  po fakcie i zarządzaj dalej kodem. (Ten sam motyw przewija się w dokumentacji/issue-trackerze providera).  Glue tylko gdy potrzebne:  podawaj ip dla child NS ( ns1.example.com  dla example.com ). Jeśli używasz zewnętrznych NS (np. nsX.ovh.net ), nie dodawaj glue . Wyjaśnienie sensu glue — patrz doc OVH.  Cierpliwość i TLD:  zmiany NS/glue propagują się na poziomie rejestru i mogą podlegać politykom TLD (czas, walidacje, blokady). W przypadku błędów specyficznych dla TLD (np. .eu) to może być problem po stronie rejestru .  Kiedy używać ovh_domain_name_servers, a kiedy ovh_domain_zone_record ovh_domain_name_servers  – gdy zmieniasz autorytatywne NS domeny  i ewentualnie definiujesz glue IP  dla child NS . ovh_domain_zone_record  – gdy zarządzasz rekordami w samej strefie  (A, AAAA, MX, TXT, CNAME, SRV, …). To zupełnie inny poziom (DNS content vs. delegacja). Przypominam: ustawienia NS w rejestrze nie dodają  rekordów A/AAAA w strefie — jeśli utrzymujesz własne serwery NS, musisz też zadbać  o ich rekordy A/AAAA w odpowiedniej strefie. version.tf — wymagania i provider Cel pliku:  zdefiniowanie minimalnych wersji Terraform i providera OVH, tak by moduł działał deterministycznie. Wymusza providera: terraform { required_providers { ovh = { source = "ovh/ovh" version = "2.7.0" } } required_version = ">= 1.3" } Dzięki temu: nie zaskoczą Cię breaking changes w nowszych ovh/ovh, konfiguracja jest powtarzalna w CI/CD. variables.tf — interfejs modułu (wejścia) Cel pliku:  zdefiniowanie wszystkich zmiennych, które użytkownik modułu może (lub musi) podać. Najważniejsze zmienne: zone  (string, wymagane) „Nazwa strefy DNS” – np. example.com , asdevops.cloud . To trafia wprost do zasobów tworzących rekordy i serwery nazw. records  (lista obiektów, domyślnie []) Lista rekordów DNS w HCL. Każdy element powinien mieć min.: fieldtype (np. A, CNAME, MX, TXT, NS, …), subdomain (np. "" dla apex, www dla hosta), target (adres IP / FQDN / wartość TXT itd.), ttl (liczba; 0 oznacza domyślny TTL po stronie OVH). Dodatkowe pole priority (jeśli użyjesz) służy tylko do budowy klucza unikalności  przy scalaniu – przydaje się gdy chcesz mieć kilka wpisów tego samego typu pod tym samym subdomain (np. wiele TXT). records_jsonencoded  (string, domyślnie null) Alternatywny sposób przekazania rekordów: string będący jsonencode([...]). W module ta lista jest zdekodowana i łączona  z records. domain_name_servers  (map(string), domyślnie null) Deklaratywne ustawienie serwerów nazw domeny  (na poziomie rejestru, nie strefy). Schemat: {" nsX.example.com " = "GLUE_IP"}. Klucz  = host FQDN (może mieć kropkę końcową). Wartość  = glue IP (IPv4/IPv6) lub puste (""/null) jeśli glue nie jest potrzebne. Walidacje w pliku: Klucze (hosty)  muszą być FQDN  (regex dla domeny). Wartości (IP)  muszą być null, "", IPv4  lub **IPv6.   Tu zastosowano trik z cidrhost(”${ip}/32”,0)icidrhost(”${ip}/128”,0)` by bezpiecznie zweryfikować IPv4/IPv6. Po co walidacje? Aby złapać literówki/nieprawidłowy format wcześnie  (na etapie terraform validate/plan), a nie dopiero jako błąd API OVH. locals.tf — przetwarzanie wejść (normalizacja) Cel pliku:  przygotowanie danych wejściowych do wygodnego użycia w main.tf . Definicje: servers_map = coalesce(var.domain_name_servers, {}) Zamienia null na pustą mapę {} — dzięki temu dalsze operacje są prostsze. server_list = [ for host, ip in local.servers_map : { host = host, ip = ip == "" ? null : ip } ] Normalizacja glue IP:  puste stringi "" są zamieniane na null. To ważne, bo argument ip w zasobie serwerów nazw jest opcjonalny  — jeśli jest null, zostanie pominięty  i provider nie będzie próbował ustawiać glue. Efekt końcowy to lista  obiektów {host, ip}, gotowa do iteracji. Znaczenie tych locals: „Odczulają” resztę kodu na null/puste wartości, Przygotowują dane pod czytelne for_each  w zasobach, Utrzymują rozdział odpowiedzialności: walidacja w variables.tf , normalizacja w locals.tf . main.tf  — logika i zasoby Cel pliku:  utworzenie rekordów strefy oraz ewentualnie ustawienie serwerów nazw (NS) na poziomie rejestru domeny. 1) Lokalne przetworzenie rekordów W main.tf  znajdziesz lokalne konstrukcje: locals { records = concat(var.records, try(jsondecode(var.records_jsonencoded), [])) recordsets = { for rs in local.records : "${rs.subdomain}-${rs.fieldtype}-${try(rs.priority, 0)}" => rs } } records — połączenie dwóch źródeł rekordów: HCL (records) + JSON (records_jsonencoded). try(jsondecode(...), []) zabezpiecza przed null/pustą wartością. recordsets — mapa  rekordów, gdzie kluczem  jest stabilny identyfikator : {subdomain}-{fieldtype}-{priority|0} To: zapobiega duplikatom, pozwala sterować „wieloma” TXT/MX itp. przez różną priority, daje stabilność planów i minimalizuje zmiany (for_each lubi stabilne klucze!). 2) Tworzenie rekordów DNS w strefie (content) resource "ovh_domain_zone_record" "this" { for_each = local.recordsets zone = var.zone subdomain = each.value.subdomain fieldtype = each.value.fieldtype target = each.value.target ttl = each.value.ttl } Dlaczego for_each? Bo chcesz odwzorować N rekordów  wynikających z wejść. for_each tworzy po jednym zasobie  na każdy element mapy recordsets. Dzięki temu: Terraform ma stabilne adresy zasobów  (kluczem jest Twój identyfikator), zmiany w pojedynczych rekordach nie „tasują” pozostałych, plany są przewidywalne (ta sama kolejność, brak przypadkowych rekreacji „całości”). O czym pamiętać: OVH oczekuje np. dla MX priorytetu w target : "10 mx1.example.com .", więc priority w obiekcie to tylko element klucza , nie trafia do providera. Dla CNAME/MX/NS/SRV/DNAME — target jako FQDN z kropką końcową  (np. mail.example.com .). Dla TXT — cudzysłowy ("\"v=spf1 ...\""), by uniknąć różnic formatu. 3) (Jeśli jest w tym module) Ustawianie serwerów nazw (delegacja + glue) Na podstawie locals.server_list zwykle buduje się zasób: resource "ovh_domain_name_servers" "this" { count = length(local.server_list) > 0 ? 1 : 0 domain = var.zone dynamic "server" { for_each = local.server_list content { host = server.value.host ip = server.value.ip # null → argument pominięty (opcjonalny) } } } count  warunkowo tworzy zasób tylko wtedy, gdy faktycznie podałeś jakiekolwiek serwery nazw. dynamic "server"  iteruje po przygotowanej liście {host, ip}. Jeśli ip = null, provider pominie glue (co jest poprawne dla zewnętrznych NS, np. dns10.ovh.net ). To jest inna warstwa niż rekordy strefy : zmieniasz autorytatywne NS domeny  w rejestrze. Uwaga: w Twoim main.tf  widziałem punktowe fragmenty i komentarze; powyżej pokazuję pełną, kanoniczną formę, zgodną z tym jak przygotowują dane locals.tf  i jakie walidacje są w variables.tf . Jak pliki się łączą (przepływ danych) Użytkownik  podaje wartości w module (np. zone, records, records_jsonencoded, domain_name_servers). variables.tf  — przyjmuje te dane, waliduje  (FQDN, IP), ustawia domyślne ([], null). locals.tf  — normalizuje  dane dla NS: null → {}, "" → null (dla glue), buduje server_list pod wygodną iterację. main.tf : scala rekordy  (records + records_jsonencoded → locals.records), buduje kluczowaną mapę  recordsets → stabilne ID dla for_each, tworzy N × ovh_domain_zone_record  (content), opcjonalnie  tworzy ovh_domain_name_servers  z dynamicznymi server blokami (delegacja/glue). version.tf  — zapewnia, że wszystko wyżej działa na spójnych wersjach narzędzi. Dlaczego for_each (i klucze) są tak ważne for_each + stabilny klucz  ("${subdomain}-${fieldtype}-${try(priority,0)}") gwarantują: Idempotencję : Terraform rozpoznaje „który rekord jest który” po Twoim kluczu , więc nie „przemapowuje” przypadkowo zasobów, Minimalny diff : zmiana jednego wpisu nie powoduje rekreacji pozostałych, Możliwość wielu rekordów  tego samego typu pod tym samym subdomain (np. kilka TXT) — rozróżniasz je przez priority w kluczu (to tylko identyfikator w module; do OVH idzie target z właściwą treścią). Gdyby użyć count i listy, każde przesunięcie elementu w liście mogłoby wywołać kaskadę rekreacji. Mapa + for_each eliminuje ten problem. Podsumowanie ról version.tf  — „kontrola wersji”: trzyma nas na właściwych wersjach Terraform i providera. variables.tf  — „API modułu”: definicje wejść + walidacje (FQDN/IP) dla bezpieczeństwa. locals.tf  — „adapter”: normalizacja danych do prostego, powtarzalnego kształtu (listy {host, ip}). main.tf  — „silnik”: scala i deduplikuje rekordy (records + records_jsonencoded → recordsets), tworzy rekordy strefy z for_each, opcjonalnie ustawia serwery nazw domeny (delegacja/glue) w trybie deklaratywnym. Podsumowanie Cały moduł odnajdziesz pod adresem https://bitbucket.org/helppointit/tfm-ovh-dns-zone/src/main/ Wykorzystanie modułu z przykładem możesz obejrzeć tu: Tak jak pisałem cały artykuł jest mała reklamą mojego kursu który, jest dostępny do zakupu na stronie https://grupadm.pl/kursy/terraform/ Zapraszam. Piotr Kośka

Możliwość pracy zdalnej to bez wątpienia mega plus ale też pewne wyzwanie by zawsze mieć stabilny i bezpieczny internet. W tym artykule pozwól że pokaże Ci moje wybór rozwiązania i konfiguracji która, sprawdza się w moim przypadku. Dając mi poczucie bezpieczeństwa oraz pewna automatyzacje konfiguracji. Zapraszam zatem do lektury. Unifi UniFi Express 7 Moim głównym założeniem w przypadku mobilnego routera jest możliwość podpięcia go do internetu kablowego (operator w danym miejscu często RJ45) jak i mobilnego (LTE, Starlink inne tego typu). Zarządzanie ma być proste i zdalne. A Najlepiej jak będzie zintegrowane z Unifi Site Manager, dzięki temu nie musze pamietać adresu IP routera bo mam konsole zdalna oraz aplikacje przez internet. Zatem podło na rozwiązanie od Unifi a dokładnie model UX7 z jednym portem WAN i LAN (niestety nie mam on opcji multi WAN - jednak nie jest ona mi potrzeba w rozwiązaniu mobilnym). Poniżej obrazek pokazujący wymiary urządzenia. Jak widzimy wymiary urządzenia też są małe. Zatem mieści mi się on w plecaku z laptopem. Zanim przejdę do medium w postaci internetu zobaczmy moją konfigurację która zapewnia mi sprawne i bezpieczne połączenie. Spójrzmy na konfigurację Unifi Network Application dostępnego na tym urządzeniu. Unifi konfiguracja Na początku informacja z jakiej wersji Unifi OS jak i Network Application korzystam, ponieważ trzeba mieć świadomość, że interfejs lub umiejscowienie pozycji może się zmienić i zawsze dobrze zajrzeć do aktualnej wersji dokumentacji technicznej unifi. Pamiętajcie też że nie wszystkie modele Unifi mają tą samą wersje interfejsu. Informacja o wersji unifiOS i network application Networks Moje urządzenie będzie służyć nie tylko na dostarczaniu internetu dla moich urządzeń ale też mam za zadanie odseparować moje domowe urządzenia od tych które służą mi do pracy. Spójrzmy zatem na konfiguracje specjalnie do tego stworzonych sieci. Jakie role spełniają te sieci: Default - to sieć menadżmentowa do urządzeń podłączanych do mojego unifii, ap, switch itp. Ogólnie w przypadku mojego zestawu mobilnego nie zakładam takich dodatkowych urządzeń (Ewentualnie AP). Dlatego tez sieć jest ograniczona do tylko 5 podłączonych urządzeń. Sieć ta dostępna jest tylko po kablu - brak rozgłaszania po wifi. KoskaMobile - sieć dla moich "domowych" urządzeń, tu wszystkie urządzenia domyślnie wychodzą VPN. WorkMobile - sieć dla urządzeń powiązanych z moimi klientami / pracą. Tu zazwyczaj VPN mam dostarczane na urządzeniach. Ewentualnie jak nie mam wtedy robie konfigurację która pozwala mi ruch rzucić przez VPN. Konfiguracji VPN dla urządzeń WORK klientów zdradzać nie będę, za to uchylę rąbka tajemnicy dla sieci KoskaMobile. Konfiguracje VPN mam za pomocą NordVPN. By dodać ją do naszego urządzenia z Unifii Network Application musimy pobrać konfiguracje profilu ovpn. Możemy to zrobić na naszym koncie po przejściu w ustawienia NordVPN. Mamy tu do wyboru serwery standardowe z podziałem na IKEv2/IPSec, UDP i TCP, serwery P2P oraz obfusecated. Odrazu zaznaczę że ten artykuł nie jest sponsorowany a wybór na NordVPN padł po wieloletnich testach welu dostawców VPN. Zatem moja konfiguracja wygląda następująco. Pobieram profil UDP w celu zagwarantowania jak najszybszej prędkości internetu po serwerze VPN. Oczywiście konfiguracje robie dla serwerów zlokalizowanych w tym państwie w którym aktualnie się znajduje w celu zagwarantowania jak najlepszej prędkości. Przykład konfiguracji openvpn na NordVPN Pobieram plik konfiguracyjny interesujący mnie dla protokołu UDP importuje go do konfiguracji. Nazwę użytkownika i hasło do konfiguracji potrzebne w interfejsie pobieramy rownież na stronie NordVPN (Jest to inny user name i password niż ten do konta nordvpn). Import pliku NordVPN W konfiguracji profilu klienta VPN ustawiłem dodatkowo w opcji Device Wizard informacje o tym że cały ruch z sieci KoskaMobile ma przechodzić przez ten profil VPN z konfiguracją Kill Switch. Opcja Kill Switch w przypadku nie dostępności VPN nie puści mojego ruchu sieciowego. Dzięki temu mam pewność, że zawsze mój ruch jest szyfrowany. Widok widocznych profili VPN Po zapisaniu mogę podejrzeć status mojego VPN czy działa oraz jaki ruch przez niego aktualnie przechodzi. Tak jak wspomniałem VPN ten służy tylko do i puszcza urządzenia "domowe". Mój laptop telefon. Wszystkie inne urządzenia które mają VPN dostarczany w systemie przechodzą przez sieć z aliasem WORK (alias ten będzie też używany w sieci wifi, konfiguracjach itp tak by łatwo identyfikować konkretną konfigurację dla danej sieci). Teraz wykonam test prędkości bez VPN i z VPN na testowym łączu by zobaczyć różnicę. W teście wykorzystam aplikację speed test na iPhona. Urządzenie które, bierze udział w teście to iPhone 11 Pro Max (jakby ktoś pytał). Ustawienia serwerów do których będzie wykonywany speed test ustawie na takie same. Prędkość łącza w mojej lokalizacji to 50/50 Mbps - oczywiście bez gwarancji prędkości więc musimy również ten czynnik brać pod uwagę. Oto wyniki przeprowadzonego testu: Speed test bez VPN Speed test z VPN Test z Speedtest w aplikacji na iPhone wygląda obiecująco są pewne różnice jadnak wygląda to spoko. Pamietajmy że to konfiguracja z VPN over UDP. Finalny test zrobie na końcu mojej konfiguracji. Wspomniałem że w moim Unifii steruję odpowiednio konfiguracją która, przekazuje cały mój ruch z danej sieci do VPN. W przypadku braku VPN moje urządzenia nie powinny łączyć się z internetem. Tak to powinno działać z zaznaczoną opcja KILL SWITCH. Powinno to tak działać ale w aktualnej wersji Unifi jest błąd i trzeba to zrobić dodatkową konfiguracją Można to uzyskać po przez konfigurację Policy-Base Routes i NAT. Spójrzmy zatem na tą konfigurację (Dodatkow w międzyczasie pojawiła się aktualizacja oprogramowania Unifi: UniFi OS 4.3.9 i Network 9.4.19 - te wersje nadal mają błąd, że przy braku VPN - status odłączony - ruch jest puszczany przez default WAN, i KILL SWITCH nie działa ): Policy type: Policy-Base Route NordVPNKoskaMobile jak widać na poniższych zdjęciach kieruje ruch z sieci KoskaMobile do PLNordVPN z funkcja KILL SWITCH. Jednak przy VPN w trybie Pause nasz ruch jest kierowany na WAN domyślny. Osobiście nie wiem czy to błąd czy świadome działanie twórców. Powiem tyle, że wcześniej to działało a w obecnej wersji nie działa i jest potrzebna dodatkowa konfiguracja. Ta dodatkowa konfiguracja wymaga od nas stworzenia reguły NAT dla mojej sieci KoskaMobile. Poniżej znajdziemy konfigurację. Typ NAT ustawiony na SRC. NAT pozwala nam wskazać źródłowy translowany adres IP. Ja w swojej konfiguracji wskazuje inny adres IP niż mojej bramy - 8.8.8.8 nigdy nie będzie adresem bramy w sieci lokalnej więc tak naprawdę może być każdy adres IP z po za sieci prywatnej. Dalej konfiguracja wskazuje że dotyczy ona tylko i wyłącznie sieci KoskaMobile. Teraz po takiej konfiguracji mogę przetestować działanie mojego VPN oraz zachowanie mojego Unifi w przypadku jego braku (status Pause) W ramach testu mam dwie opcje: Pierwsza - ustawiam interface VPN w tryb Pause Druga - edytuje interfejs VPN i zmieniam nazwę użytkownika co bedzie symulowac problem z połączeniem. Teraz gdy ustawiliśmy kontrolowany problem na interfejsie VPN może sprawdzić czy internet działa. Wykorzystam do tego speed test (Dodatkowo wyłaczyłem pakiety mobilne by telefon nie przełączył sie na zapasowy internet). Jak możemy zobaczyć brak internetu na naszym urządzeniu w tym przypadku to dobry znak. Ponieważ moja reguła NAT działa. Dobrze skoro mam przetestowane nie działanie internetu przy braku VPN - to teraz zobaczmy czy po włączeniu profilu VPN połączenie internetowe będzie działać. Po włączeniu profilu VPN obserwuje reakcję speed test na telefonie, i jak możemy zobaczyć aplikacja zgłasza dostęp do internetu. Na stronie nordvpn.com możemy sprawdzić nasz status czy nasz internet przechodzi przez NordVPN servery. Status CHRONIONY na zielono potwierdza nam działanie naszego połączenia przez VPN. Obecnie przy braku działania KILL SWITCH to jedyna opcja na dostarczenie działania konfiguracji w ten sposób. Spójrzmy teraz finalnie na konfiguracje mojej sieci KoskaMobile Poszczególne opcje omawiałem już w osobnym wpisie . Dlatego skupię się na nie omawianych oraz tych kluczowych opcjach które, wpływają na moją konfigurację. Patrząc od góry - sieć KoskaMobile podpinam do nowej Zony, dzięki temu będę mogł bardziej kontrolować daną sieć w sekcji firewall itp. Protokół IPv4 - tylko on będzie używany w mojej konfiguracji. Gateway IP/Subnet - wyłączam ponieważ 254 urządzenia w tej sieci będą i to tak jest za dużo. W cześci Advanced włączam opcję izolowania tej sieci KoskaMobile od innych sieci dostępnych w ramach konfiguracji Unifi. Będzie to można zobaczyć w sekcji zone w dalszej części tego wpisu. Oczywiście izolacja jest tylko w ramach innych sieci, urządzenia pomiędzy sobą w sieci KoskaMobile będą się komunikować. W DNS servers ustawiłem odpowiednie serwery DNS: Europejski DNS Cloudflare - z filtracją malware Szwajcaria Google Oczywiście w tej konfiguracji zależy mi głownie na animowości względem operatora w danym hotelu/miejscu używania mojego mobilnego routera. Konfiguracja dla sieci WorkMobile jest identyczna jeżeli chodzi o ustawienia w interfejsie Unifi dla sekcji Networks. WiFi Tak jak w przypadku Networks moje sieci podzieliłem na dwie osobne do urządzeń "domowych" i urządzeń "klienckich". Tak samo mam w przypadku WiFi. Spójrzmy teraz wspólnie na konfiguracje moich dwóch sieci wifi. Na prezentowanym screen nie pokazałem tylko dwóch pierwszych pozycji która odnosi się do nazwy sieci oraz jego hasła. Nastepujące opcje przedstawiają się: Network - tu wskazujemy na sieć która, ma być dostępna w ramach tego WiFi. U mnie będzie to sieć KoskaMobile (Warto tu zaznaczyć, że nazwa sieci i WiFi nie musza być takie same) Broadcasting APs - wskazanie na jakich urządzeniach ma być rozgłaszane nasze wifi. W moim przypadku mam tylko UX7 więc domyślnie jest na ALL - czyli wszystkich. W sekcji Advanced mamy Private Pre-Shared Keys - Ustawienie to dla WPA2 pozwala włączyć dodatkowe hasło wymagane podczas połączenia. Dodatkowo ta opcja jest wspierana tylko w 2.4 i 5GHz. Hotspot - Pozwala włączyć funkcje hotspot i captive portal, przydatne np dla gości. U mnie ta opcja nie jest potrzebna. Enhanced IoT Connectivity - przełączenie wifi na 2.4 GHz by ułatwić komunikacje urządzeniom IoT. Ja czesto w moich konfiguracjach dla urządzeń IoT konfiguruje osobna sieć tak by tylko tam mogły się one łączyć. W moim przypadku nie będzie to potrzebne. WiFi Band - tu możemy ustawić dodatkowe częstotliwości 2.4, 5 i 6 GHz. Włączenie wszystkich może wpłynąć na zasięg działania wifi. Tą opcje traktuje jako dynamiczną w zależności jak daleko są moje urządzenia od nadajnika wifi urządzenia UX7. MLO - Nowa funkcja Wi-Fi 7. Pozwala urządzeniu łączyć się jednocześnie z kilkoma pasmami (np. 5 GHz i 6 GHz), aby zwiększyć wydajność i niezawodność. Na razie raczej eksperymentalne, bo wymaga klientów obsługujących Wi-Fi 7. Band Steering - Mechanizm, który „zachęca” urządzenia zdolne do pracy w 5 GHz, żeby nie łączyły się z wolniejszym 2.4 GHz. Dzięki temu odciąża się pasmo 2.4 GHz dla starszych / IoT urządzeń i poprawia wydajność sieci. Tą opcję w mojej konfiguracji włączam. Multicast and Broadcast Control - Ogranicza lub filtruje ruch typu broadcast/multicast w Wi-Fi (np. rozgłaszanie nazw w sieci, discovery). Może poprawić wydajność przy dużej liczbie klientów, bo tego typu pakiety są kosztowne w sieciach bezprzewodowych. Multicast Enhancement - Funkcja optymalizująca multicast, konwertuje multicast do unicast. Przydatne np. przy streamingu TV po Wi-Fi albo przy urządzeniach korzystających z SSDP/AirPlay/Chromecast. Hide WiFi Name - Ukrywa nazwę sieci (SSID). Urządzenia nadal mogą się łączyć, ale trzeba ręcznie wpisać nazwę sieci. Minimalny zysk w bezpieczeństwie (łatwe do wykrycia specjalistycznym oprogramowaniem). Częściej powoduje problemy z podłączaniem urządzeń. Client Device Isolation - Blokuje komunikację między klientami w tej samej sieci Wi-Fi (mogą rozmawiać tylko z internetem, a nie między sobą). Przydatne np. w hotelach, szkołach, biurach otwartych. Zabezpiecza przed podsłuchiwaniem w LAN-ie. W moim przypadku chcem by urządzenia w tej sieci się komunikowały. Proxy ARP - Funkcja optymalizująca routing pakietów ARP w sieci Wi-Fi. Przydaje się w dużych, złożonych sieciach. Dla domowego użytku zwykle niepotrzebna. BSS Transition - Pozwala punktowi dostępowemu „podpowiedzieć” klientowi, żeby przełączył się na inny AP o lepszym sygnale. Ułatwia roaming w sieciach z wieloma AP (np. UniFi w dużym domu lub biurze). UAPSD - Tryb oszczędzania energii dla urządzeń klienckich (szczególnie VoIP i mobilnych). Może poprawić żywotność baterii np. telefonów i słuchawek Wi-Fi, ale czasem powoduje opóźnienia, lepiej ostrożnie z tą opcją. Fast Roaming - Przyspiesza proces przełączania się klientów między AP (roaming). Ważne np. dla rozmów VoIP po Wi-Fi czy wideo rozmów w ruchu. Nie wszystkie starsze urządzenia to wspierają – czasem trzeba wyłączyć. U siebie narazie z tego korzystam i eksperymentuje. WiFi Speed Limit - Możliwość ustawienia maksymalnej prędkości dla klientów Wi-Fi. Przydatne w sieciach gościnnych lub publicznych, żeby ktoś nie zapchał całego łącza. W mojej konfiguracji opcja będzie włączona w sieci dla urządzeń domowych by urządzenia w sieci WORK miały większa prędkość. 802.11 DTIM Period - (DTIM = Delivery Traffic Indication Message) – mówi klientom Wi-Fi, jak często mają się wybudzać, żeby sprawdzić, czy są dla nich dane multicast/broadcast. Krótki DTIM → lepsza responsywność, ale gorsza bateria (np. telefony). Długi DTIM → oszczędzanie energii, ale możliwe opóźnienia w notyfikacjach push. Minimum Data Rate Control - Pozwala ustawić minimalną prędkość (modulację) dla klientów. Dzięki temu bardzo stare urządzenia działające na niskich prędkościach nie spowalniają całej sieci. W praktyce w sieciach domowych można ustawić np. 12 Mbps minimum, żeby wyciąć najstarsze tryby 1–2 Mbps. MAC Address Filter - Pozwala ograniczyć dostęp do Wi-Fi tylko dla urządzeń o określonych adresach MAC (biała/czarna lista). W praktyce daje podstawową kontrolę dostępu, ale łatwo obejść (adres MAC można podmienić). Lepiej traktować jako dodatkowe zabezpieczenie, a nie główne. RADIUS MAC Authentication - Rozszerzenie filtrowania MAC o integrację z serwerem RADIUS. Urządzenie próbujące się połączyć jest uwierzytelniane po adresie MAC w bazie RADIUS. Stosowane głównie w sieciach firmowych, gdzie RADIUS już obsługuje logikę dostępu (np. różne VLAN-y, różne polityki). Security Protocol - Wybór standardu zabezpieczeń Wi-Fi: WPA2 – starszy, nadal szeroko kompatybilny. WPA3 – nowszy, bezpieczniejszy, ale część starszych urządzeń (IoT, drukarki, starsze telefony) może się nie łączyć. WPA2/WPA3 mixed – tryb mieszany dla kompatybilności. Najlepiej używać WPA3 wszędzie, gdzie to możliwe, a jeśli masz dużo starszych urządzeń, najlepiej zostawić tryb mieszany. PMF - Chroni ramki zarządzające Wi-Fi (np. deauth/disconnect) przed podszywaniem się. Required – pełne bezpieczeństwo, ale może rozłączać starsze urządzenia. Optional – ochrona dla nowszych klientów, starsze mogą działać bez niej. Disabled – brak ochrony. Wraz z WPA3 jest wymuszona ochrona PMF, co może sprawiać kłopoty IoT. Group Rekey Interval - Określa, jak często zmieniany jest klucz szyfrujący dla transmisji multicast/broadcast w danym SSID. Standardowo ustawione na 3600 sekund (1h). Krótszy czas → lepsze bezpieczeństwo. Dłuższy czas → mniejsze obciążenie CPU/AP i klientów. SAE Anti-clogging - Dotyczy WPA3-SAE (Simultaneous Authentication of Equals) – nowego sposobu logowania. Zapobiega atakom typu DoS (clogging attack), gdzie napastnik wysyła lawinę fałszywych prób logowania. Limit ustawiany liczbowo → ile prób AP może przyjąć, zanim odrzuci nowe sesje. SAE Sync Time - Też związane z WPA3-SAE. Określa czas synchronizacji parametrów kryptograficznych między klientem a AP. Wartość w sekundach → jak długo AP ma czekać, zanim odrzuci nieudaną próbę logowania. Zostawia się zwykle na domyślnej wartości. WiFi Blackout Scheduler - Umożliwia ustawienie harmonogramu wyłączania Wi-Fi dla danego SSID. Przykłady użycia: wyłączenie sieci gościnnej w nocy, ograniczenie Wi-Fi dla dzieci w określonych godzinach, oszczędzanie energii w firmie poza godzinami pracy. Poniżej w formie zdjęciowej prezentuje swoje ustawiania - między siecią Work a Home jest tylko różnica w izolacji urządzeń połączonych do jednego wifi. W sieci WORK nie komunikują się one między sobą. Dodatkowe opcje w ustawieniach ogólnych wifi które tez warto włączyć to: Default WiFi Speeds - Określa domyślny profil prędkości dla AP: Maximum Speed – AP korzysta z najszerszych kanałów i najwyższych możliwych parametrów, żeby zapewnić maksymalną przepustowość. Conservative – bardziej ostrożne ustawienia, zwykle węższe kanały, mniej zakłóceń, większa stabilność w środowiskach z dużą liczbą sieci. Custom – ręczna konfiguracja szerokości kanałów i ustawień prędkości. W domu najczęściej wybiera się Maximum Speed, a w biurach z wieloma AP – Conservative. Channel Width (MHz) - Decyduje o szerokości kanału radiowego: 2.4 GHz → 20 lub 40 MHz (zwykle lepiej 20 MHz, bo mniej zakłóceń). 5 GHz → 20 / 40 / 80 / 160 MHz. Najczęściej stosuje się 80 MHz – kompromis między prędkością a stabilnością. 6 GHz (Wi-Fi 6E) → do 320 MHz (najszersze pasmo, największe prędkości, ale krótszy zasięg). Im szerszy kanał, tym większa prędkość, ale też większe ryzyko zakłóceń. Extended 5 GHz Spectrum (DFS) - DFS = Dynamic Frequency Selection. Pozwala używać dodatkowych kanałów 5 GHz, które normalnie są zarezerwowane dla radarów (np. pogodowych, lotniczych). Daje więcej wolnych kanałów, ale gdy AP wykryje radar, musi zmienić kanał → chwilowa przerwa w sieci. Daily Spectrum Optimizer - Automatyczna optymalizacja wyboru kanałów raz dziennie. Tu ustawione na 6 AM – AP o tej godzinie analizuje otoczenie i wybiera najlepsze kanały. Przydatne w środowiskach z dużą liczbą sieci Wi-Fi, gdzie zakłócenia się zmieniają. 5 GHz Roaming Assistant- Pomaga klientom szybciej przełączać się między AP w paśmie 5 GHz. Działa przez ustawienie progu sygnału (Threshold dBm). Jeśli klient spadnie poniżej tej wartości, AP „wypycha” go, żeby połączył się z innym, bliższym AP. Bardzo dobre w biurach i dużych domach, ale może rozłączać urządzenia IoT, które nie radzą sobie z roamingiem. Wireless Meshing - Pozwala AP łączyć się między sobą bez kabli, używając Wi-Fi jako backhaulu. Przydatne tam, gdzie nie można doprowadzić przewodów Ethernet. Obniża trochę wydajność, bo pasmo dzielone jest między klientów a połączenie AP-AP. Mesh Monitor - Narzędzie monitorujące stan połączeń Mesh. Możesz ustawić, czy AP ma się łączyć przez bramę (Gateway) czy używać własnego adresu (Custom IP) jako punktu odniesienia do testów i monitoringu. Przydatne do diagnozowania problemów w sieci Mesh. UniFi Auto-Link - Automatyczne wykrywanie i łączenie nowych urządzeń UniFi w sieci. Upraszcza dodawanie nowych AP, switchy i innych elementów ekosystemu. WiFiman Support - Integracja z aplikacją WiFiman (narzędzie Ubiquiti do testowania sieci). Dzięki temu możesz łatwo sprawdzać prędkości, zasięg i jakość sygnału przy użyciu telefonu z aplikacją WiFiman. Wspomniana tu też aplikacja WiFiman daje nam też kilka przydatnych informacji i to z punktu naszego docelowego urządzenia które, łączy się do naszej sieci. Warto tą aplikację doinstalować i przeprowadzić testy naszej sieci takie jak speedtest , wydajność wifi, ustawiania radio, oraz channel health oraz jakie urządzenia są podłączone do naszej sieci. Internet Ktoś mogłby się zapytać dlaczego teraz omawiam ta sekcja w konfiguracji Unifi. Przecież powinna ona być najważniejsza. I tak jest, jest ona ustawiona na DHCP więc tu z dużo konfiguracji nie ma :) - choć można para elementów ustawić. Patrząc od góry mamy ustawienie portu na którym mamy INTERNET (w tym urządzeniu możemy tylko ustawić go na porcie 2 - ale w innych mamy możliwość wyboru lyb ustawienia kilka WAN) W sekcji Advanced mamy: Expected ISP Speeds - Możesz wpisać prędkości pobierania (Download) i wysyłania (Upload), jakie deklaruje Twój dostawca. Nie ogranicza to realnie łącza, ale służy m.in. do raportów i mechanizmów QoS (np. Smart Queues). VLAN ID - Pozwala przypisać połączenie WAN do konkretnego VLAN-u (wymagane u niektórych ISP, np. światłowodowych). MAC Address Clone - Zmienia adres MAC interfejsu WAN na wybrany (często potrzebne, jeśli ISP przypisał usługę do konkretnego MAC-a). Smart Queues - Włącza kolejkowanie QoS (Quality of Service) – priorytetyzuje ruch, żeby poprawić płynność np. VoIP, gier online, streamingu. Może zmniejszyć maksymalną prędkość, bo wymaga dodatkowej mocy obliczeniowej. IGMP Proxy - Obsługuje protokół IGMP używany przez telewizję IPTV. Jeśli Twój ISP wymaga tego do dekodera TV, musisz włączyć. UPnP - Automatyczne otwieranie portów w routerze na żądanie aplikacji (np. gier, VoIP). Wygodne, ale potencjalnie niebezpieczne – lepiej wyłączyć w sieciach firmowych. Dynamic DNS - Możesz powiązać zmienne IP od ISP z domeną (np. moja-siec.ddns.net). Dzięki temu możesz łączyć się z siecią po nazwie, nawet jeśli IP się zmienia. IPv4 Connection - rodzaj naszego połączenia internetowego. U mnie to będzie DHCPv4 DHCP Client Options - Możliwość wysyłania dodatkowych opcji DHCP do ISP. DNS Server - ustawiam tu własne skierowane na CloudFlare. IPv6 Configuration - brak w mojej konfiguracji. PO zapisaniu możemy jeszcze włączyć speedtest automatyczny z pewną powtarzalnością. Warto tu odrazu powiedzieć że pomimo tego że teoretycznie port 1 wyświetla się jako WAN. To nie można go użyć. Jego użycie powoduje że router głupieje. (Trzeba zapoznać się z lista modeli które wspierają multi wan Dodatkowe konfiguracje security i podsumowanie W sekcji security warto włączyć blokadę regionów z którymi nie chcielibyśmy się komunikować. W konfiguracji Zone warto zrobić osobny profil dla każdej z sieci. O tych profilach i konfiguracji zone porozmawiamy sobie już w innym moim wpisie, ponieważ w przypadku tej konfiguracji i mobilnego wykorzystania tego urządzenia konfiguracja zone nie jest rozbudowana. Zapraszam zatem do kolejnego materiału już nie w krótce.

Kupując urządzenia Unifi szczególnie tzw Cloud Gateway - albo może inaczej router. Nabywamy urządzenie które, da nam dostęp do internetu w naszym domu, firmie. Podłączenie jest mega proste, producent też zadbał o przyjazny "Wizard" wprowadzenie do pierwszego podłączenia. I gdy posiadamy ze sobą smartforn z androidem lub iOS to tak naprawdę nie potrzebujemy nawet dostępu do interfejsu www naszego Routera (Cloud Gateway) i zastanawiania się jaki adres IP ma nasze urządzenie. W tym materiale przejdę do omówienia według mnie jaka konfiguracja powinna być zrobiona na początek tak by jak najlepiej zabezpieczyć nasze urządzenie (P.S - w żaden sposób nie twierdzę że domyślne ustawiania są niebezpieczne tylko mamy pewne ograniczenia jeżeli je pozostawimy takimi jakie są) - zatem zaczynamy. Unifi Network Application - ustawienia sieci. Omawiany model to UniFi Express UX - wersja oprogramowania Unifi OS 4.0.12, Network 9.0.114 Po zalogowaniu się do naszego panelu - czy to z poziomu, przeglądarki (mobilnego interfejsu) i lokalnego adresu, czy to z poziomu globalnego site manager przechodzimy do ustawień naszego urządzenia. Choć interfejs jest spójny dla urządzeń unifi, to mogą być pewne różnice w ustawieniach czy funkcjach. Pewne modele mogę nie mieć pełnej gamy zabezpieczeń. W tym artykule omawiam interfejs Unifi Express UX. W dolnej cześci klikamy ikonę trybiku - po najechaniu w dymku pokaże się napis SETTINGS. W pionowym menu mamy opcje WIFI , NETWORK , INTERNET , VPN , Security , Routing , Profiles , System , Control Plane , Admin & Users - mu skupimy się na Opcji NETWORKS . Po kliknięciu w Networks wyświetli nam się panel zarządzania/dodawania/usuwania sieci. Na początku mamy sieć Default (domyślną) - warto zmienić jej nazwę. Sieć domyślna ma też pewne ograniczenia i o tym za chwilę. Sieć domyślna będzie wyświetlana w górnej części. Ja jej nazwę zmieniłem na Nawrolski. Będą tu też wyświetlane inne sieci. Ustawieniami w sekcji poniżej czyli MULTICAST SETTINGS zajmiemy się poźniej. Kliknijmy zatem naszą sieć (na nazwę) i wejdziemy do ustawień danej sieci. W przyszłości jak będziesz miał więcej skonfigurowanych sieci - ich edycja odbywa się po przez kliknięcie w nazwę. A usuwanie po przez kliknięcie napisu MANAGE pod nazwami sieci. Przycisk ten uaktywnia się dopiero jak mamy więcej niż jedną sieć (Domyślnej nie można usunąć). Kliknijmy zatem na nazwę naszej sieci (na starcie ona u Ciebie nazywa się Default). Otworzy nam się panel ustawień naszej sieci. W górnej cześci mamy: Możliwość zmiany nazwy (Zalecam to zrobić). W sekcji PROTOCOL - mamy możliwość konfiguracji naszej sieci wewnętrznej w wersji IPv4 i IPv6 (zalecam wyłączyć IPv6 jeżeli nie używasz w swojej wewnętrznej sieci protokołu IPv6). Warto tu zaznaczyć że te ustawienia dotyczą sieci wewnętrznej/lokalnej i nie ma znaczenie ustawienie naszego protokołu w sekcji INTERNET . Nawet gdy masz od dostawczy publiczne adresy IPv6. nie ma potrzeby włączania ich wewnątrz sieci w konfiguracji NETWORKS W sekcji GATEWAY IP/SUBNET - warto odznaczyć opcję Auto-Scale Network. Oczywiście jeżeli chcemy samodzielnie sterować rozmiarem naszej sieci. Opcje ta powoduje że w przypadku gdy zabraknie nam wolnych adresów IP dla naszej lokalnej sieci, to pula naszej sieci się przeskaluje. Odznaczenie tej opcji spowoduje że będziemy mogli sterować naszą maską (CIDR) z przedziału od 30 do 8. Jeżeli nie wiesz co to jest to liczba 24 pozwoli Ci na podłączenie do sieci 254 urządzeń. Im większa tym niej będzie tych urządzeń. A im mniejsza tym więcej. W tabeli poniżej tego ustawienia mamy informacje o naszym serwerze DHCP (rozdzielanych adresach), naszej bramie, adresie broadcast, dostępnych IP, oraz o naszym adresie subnet mask. Sekcja ADVANCED MANUAL (na jej ustawienia wpływa sekcja omawiana w punkcie 3 - ja punk trzeci odznaczyłem opcje Auto-Scale Network (jest wyłączona)) - mamy możliwość ustawienia: Guest Network - nie można tego ustawić na sieci domyślnej (omówimy to po dodaniu dodatkowej sieci) Isolate Network - nie można tego ustawić na sieci domyślnej (omówimy to po dodaniu dodatkowej sieci) allow internet access - opcja zaznaczona, ja odznaczam tą opcję dla sieci która ma nie mieć dostępu do internetu, ma pełnić rolę swoistego backendu np dla baz danych. Zastosowań może być kilka - często tą opcje wiąże z ustawieniami w proxmox ( o tym już w innym artykule). Content Filtering - Ta opcja według mnie troche słabo działa. Bo np ustawienia Family blokuje komentarze na YouTube ale już stron pornograficznych nie. Jeszcze testuję to opcję i więcej o niej w osobnym artykule - osobiście zalecam na ustawienie WORK. IGMP Snooping - pozwala przełączać multicast bardziej inteligentnie, dostarczając go tylko do tych urządzeń, które go potrzebują. Warto to włączyć. Multicast DNS - to ustawienie dotyczy mechanizmu wykrywania usług w sieci (Bonjour). Co robi: włącza przekazywanie/odbijanie ruchu mDNS między wybranymi sieciami/VLAN-ami, żeby urządzenia IoT mogły się odnaleźć, nawet jeśli są w różnych podsieciach. Warto tą oczje wyłaczyc jeżeli nie planujemy np umieszczać drukarki w innej sieci niż będą nasze urządzenia które będa z tej drukarki korzystały. Resztę ustawień omówimy sobie przy konfiguracji innych sieci - zapiszmy nasze ustawienia. Po zapisaniu i zmianie nazwy nasza sieć jest widoczna pod inna nazwą. Kliknijmy teraz w dolnej cześci pod nazwami naszych sieci opcję NEW VIRTUAL NETWORK i dodajmy nową sieć. Warto tu odrazu zaznaczyć że nowe wirtualne sieci będą działały gdy: Będziemy mieli inne urządzenia od Unifi (switch, przełączniki, AP, itp) Inne urządzenia od innych wendorów obsługujące VLANY. Unifi Network Application - tworzymy VLANy Po kliknięciu NEW VIRTUAL NETWORK - mamy możliwość dodania nowej wirtualnej sieci (nowy VLAN) otwiera nam się okno dokładnie takie samo jak w przypadku naszej sieci domyślnej. Mamy możliwość konfiguracji naszej nowej sieci. I jest to ważne by dodać taką sieć. I tu też ważny element, sieć domyślna to VLAN 1 - vlan domyślny. Nową sieć którą dodam nazwę WORK - to sieć na wszelkie moje sprzęty dla firm z którymi współpracuję. Z racji że pracuję zdalnie na moim mobilnym Unifi oraz domowym (wszędzie tam gdzie ja zarządzam siecią - np u rodziców) tworze taką sieć. I tam dodaje moje urządzenia powiązane z pracą. Ustawiam odpowiedni adres IP sieci (tak by nie kolidował ze wszystkimi moimi sieciami w ramach moich lokalizacji - warto o tym pomyśleć jeżeli planujemy VPN Site Manager). Wyłączam opcję auto-scale network zmieniam adresację i zmniejszam maskę - wystarczy mi w zupełności maska 28 - w której będę mogł wykorzystać 13 adresów IP - co zatem idzie podłączyć też 13 urządzeń. Tworząc nowa sieć wirtualna musimy ją oznaczyć - oprócz unikatowej nazwy warto też ustawić właściwy VLAN ID - Default (sieć domyślna ma ID 1 - nie można go zmienić) dla naszej nowej sieci możemy wybrać. I ważne by był unikatowy. Zaznaczam Opcję Isolate Network tak by urządzenia w tej sieci nie widziały innych sieci (dostęp ten będę musiał skonfigurować w Firewall, jak taka opcja będzie mi potrzebna) w ramach tej samej sieci nasze urządzenia będą się widziały. Warto tu zaznaczyć że wszystkie sieci wirtualne w Unifi domyślnie są dostępne miedzy innymi wirtualnymi sieciami. Zatem uważam e warto tą opcję zaznaczyć jeżeli będziemy mieli więcej niż jedną wirtualną sieć. Pozycja DHCP : Ustawiam DHCP Mode na server - jeżeli planujesz dodawać konfigurację IP automatycznie. DHCP Range ustawiam opcje dynamicznego przydzielania IP na odpowiedni zakres dzieląc pulę dostępnych IP na manualne i przydzielane z DHCP. Tu ustawiam pule tak by kilka adresów było możliwe do przydzielenia ręcznie. W pod opcji DHCP Guarding ustawiam zaufany adres DHCP. Chroni to przed Rogue DHCP / DHCP spoofing , Przejęcie ruchu / MITM przez DHCP , Awarie i „znikający internet” przez przypadkowo włączony DHCP . Zaraz pod DHCP Range mamy opcję DHCP Service Management i warto tutaj też ustawić kilka opcji: NTP server - przyjmuje tylko wartości IP, zatem zalecane jest postawić lokalny server NTP i na niego ustawić adresy IP. Lub alternatywnie rozwiązać adresy IP np tempus1.gum.gov.pl i tempus2.gum.gov.pl i wpisać ich adresy IP. jeżeli w twojej sieci nie jest ważna synchronizacja czasu to możemy pominąć tą opcje. Network Boot - Można określić server PXE jak mamy np bootowane systemy z sieci Time offset - przesuniecie czasu względem NTP podawane w sekundach. Option 43 - vendor-specific information. W UniFi służy do poinformowania urządzeń UniFi (AP, switche, itp.) o adresie kontrolera/UniFi Network Application, żeby mogły się automatycznie „adoptować”, zwłaszcza gdy są w innym VLAN/podsieci (L3). WPAD URL - automatyczna konfiguracja przeglądarek/systemu do korzystania z proxy/filtra www bez ręcznego ustawiania. TFTP Server - podaje klientom adres serwera TFTP do pobrania konfiguracji/obrazu. Ping Conflict Detection - Przed przydzieleniem adresu z puli bramka wysyła ICMP ping (echo request) do kandydata IP. Jeśli ktoś odpowie → adres uznaje za zajęty/konfliktowy i nie jest wydawany. Jeśli nikt nie odpowie → serwer wydaje dzierżawę temu klientowi. To jest dodatkowa warstwa ponad wbudowane sprawdzanie konfliktów (ARP/Gratuitous ARP) w bramkach UniFi. Default Gateway - warto dla każdej sieci ustawić na auto, wtedy unifi będzie pełnił role bramy. Jeżeli masz w sieci dodatkowe urządzenie które pełni role bramy możesz wskazać tutaj jego adres IP. DNS Server - warto zmienić ta opcję, pozostawiając auto - będziemy mieli takie adresy DNS jakie są skonfigurowane na naszym interfasie INTERNET. Czyli prawdopodobnie operatora. Serwerów DNS jest dużo i warto im się przyjrzeć. U mnie wybór padł na: Publiczne serwery DNS w Polsce NASK / DNS.PL (oficjalny operator domen .pl) Primary: 193.59.201.26 Secondary: 193.59.201.27 Bardzo zaufane, bo zarządzane przez NASK (państwową instytucję odpowiedzialną za rejestr .pl). Międzynarodowe, szybkie i bezpieczne DNS-y (też działają świetnie w PL) Cloudflare (1.1.1.1) – bardzo szybki i nastawiony na prywatność 1.1.1.1 1.0.0.1 Wersja z filtrowaniem malware: 1.1.1.2 i 1.0.0.2 Wersja z filtrowaniem malware + treści dla dorosłych: 1.1.1.3 i 1.0.0.3 Google Public DNS – bardzo stabilne i szybkie 8.8.8.8 8.8.4.4 Quad9 (Szwajcaria, nacisk na bezpieczeństwo) 9.9.9.9 149.112.112.112 Domyślnie blokuje złośliwe domeny (chroni przed phishingiem i malware). Które wybrać? Najbezpieczniejsze (ochrona przed phishingiem/malware): Quad9 lub Cloudflare z końcówką .2 / .3 Najbardziej prywatne: Cloudflare (deklarują, że nie logują długoterminowo) Najbardziej oficjalne w PL: NASK (DNS.PL) Najbardziej uniwersalne: Google DNS (jeśli zależy na niezawodności i prostocie) W Lease Time deklarujemy w przez jaki czas adres IP będzie zarezerwowany i wykorzystywany dla danego urządzenia. Domain name pozwala zdefiniować FQDN które będą funkcjonować w ramach naszej konfiguracji Unifi/Routera (czyli lokalne nazwy FQDN) Custom DHCP Options - to dodatkowe opcje oprócz tych powyżej wymienionych które można ustawić w naszym DHCP i automatycznie dodatkowo konfiguraowac naszych klientów - pełna lista tych opcji dostępna jest tu: https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml#options Podsumowanie To był przegląd opcji które ustawiam w moich sieciach którymi zarządzam przez Unifi. Oczywiście to nie wszystko i w kolejnym artykule poruszymy kolejne opcje konfiguracji. Do usłyszenia

Podnieś swoje kompetencje Liderskie wraz z Humble - właśnie wczoraj wpadła paczka wideo kursów dla wszystkich co chcą podszkolić swoje zdolności liderskie. Za 20 kursów wideo (po angielsku) zapłacisz 17,18 Euro - to minimalna kwota która, daje Ci możliwość zdobycia 20 kursów Link: https://www.humblebundle.com/software/leadership-and-project-management-in-software-development-workplace-software Podnieś swoje umiejętności zarządzania projektami i przywództwa dzięki temu kompleksowemu pakietowi kursów Packt. Śledź postępy swojego zespołu, poznaj najlepsze praktyki cyberbezpieczeństwa i szybko analizuj cenne dane dzięki kursom takim jak The Complete Project Management Fundamentals Course , Data Science, Analytics, & AI for Business & the Real World , Risk Management for Cyber ​​Security Managers i nie tylko! Uzyskaj fachową poradę i wiedzę, których szukasz, i pomóż wesprzeć Alzheimer's Research UK dzięki zakupowi! Oto lista kursów dostępnych w pakiecie Humble Bundle dotyczącym przywództwa i zarządzania projektami w rozwoju oprogramowania: The Complete Project Management Fundamentals Course The Simplest Guide™ to Project Management and PMI-PMP Certification Exam The Complete Product Management Fundamentals Course Data Science, Analytics, and AI for Business and the Real World™ Risk Management for Cyber Security Managers Project Management Best Practices using Agile and Scrum AI Strategy for Business Leaders and Managers with ChatGPT, ML and DL strategy Agile Product Owner Level 2 - Comprehensive Certification Guide and Mock Exams Agile Scrum Master Level 2 - Comprehensive Certification Guide and Mock Exams Program Manager Essentials - Become a Program Manager Agile Scrum Master Level 1 - Certification Prep and Mock Exams Agile Product Owner Level 1 - Certification Prep with Mock Exams Scrum Advanced - Software Development and Program Management Product Management Certification with Agile Product Owner and Scrum Agile Project Management Expert Leadership and Management in Agile Project Management: Building Core Competencies Change Management Crash Course: Change Management 101 Resource Management with Oracle Primavera P6 PPM Professional The Ultimate Guide for Product Management Essentials Driving Business Success with ChatGPT - A Comprehensive Guide Cena pakietu: co najmniej €17.18 za wszystkie 20 kursów. Cenę dotacji możemy też ustawić według własnych upodobań

27 stycznia ukazały się aktualizacje dla urządzeń Apple. Oczywiście zalecam aktualizację tak by mieć zaktualizowany system operacyjnych dla iPhone czy MacBooka (Lub też innych urządzeń aplikacji) Pełne zmiany i liste tych zmian dla wszystkich produktów znajdziesz: https://support.apple.com/en-us/100100 Bardziej szczegółowe informacje dla iOS 18.3 i iPadOS 18.3 znajdziesz: https://support.apple.com/en-us/122066 Dla macOS Sequoia 15.3 https://support.apple.com/en-us/122068 Aktualizacje security zostały wypuszczone też dla starszych wersji systemu macOS warto zatem zaktualizować swój sprzęt

Hej. W mojej domowej sieci nadszedł ten czas że trzeba było już wymienić niewspierane urządzenie sieciowe jakim był RV325/RV320 od Cisco. Wybór padł na Dream MAchine SE od Ubiquiti. Przegląd konfiguracyjny oraz mój dość nietypowy montaż zaprezentowałem na materiale wideo - dostępny na YouTube. Zapraszam do oglądania oraz do komentarzu w celu zainicjalizowania wymiany spostrzeżeń i opinii :)

Na Humble znajdziesz pakiet kursów o AWS. Za 25 euro 18 kursów i dodatkowo możesz wesprzeć walkę z Alzheimerem. Kursy są w formie wideo (angielski). Tematyka: Snowflake AWS Solution Architect Associate S3 Deep Dive AWS CDK DynamoDB Lambda RDS i znacznie więcej. Link: https://www.humblebundle.com/software/aws-cloud-engineer-accelerator-from-zero-to-certified-packt-software

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

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

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

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

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

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

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

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

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

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

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

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