Czasem trzeba zrobić rolling restart w klastrze Elasticsearch - wymienić sprzęt, zaktualizować wersję lub przenieść shardy na nowy węzeł. Bez odpowiedniego przygotowania proces może trwać długo i generować dużo niepotrzebnego ruchu.
Poniżej opisuję, co robię, żeby przyspieszyć restart i ograniczyć ruch shardów.

Wyłączanie alokacji shardów podczas restartu

Żeby uniknąć niekontrolowanego przemieszczania shardów w trakcie restartu węzła, wyłączam alokację replik. Klaster wtedy nie zaczyna od razu przesuwać danych, co pozwala na kontrolowany proces restartu.

PUT _cluster/settings 
{
  "persistent": {    "cluster.routing.allocation.enable": "primaries"  }
}

Po zakończeniu restartu przywracam domyślne ustawienie:

PUT _cluster/settings
{
  "persistent": {    "cluster.routing.allocation.enable": null  }
}

Opóźnienie reakcji klastra (delayed timeout)

Domyślnie Elasticsearch od razu po utracie węzła zaczyna rebalansować shardy, co generuje zbędny ruch, jeśli węzeł szybko wróci. Zwiększam timeout, żeby dać czas na ewentualny powrót węzła.

PUT _all/_settings {  "index.unassigned.node_left.delayed_timeout": "5m"}

Flush przed restartem

Wykonuję flush, żeby zapisać segmenty na dysk i przyspieszyć późniejsze odzyskiwanie shardów.

POST /_flush

Restart node po node

Restart wykonuję pojedynczo dla każdego węzła:

1. Wyłączam alokację shardów (patrz wyżej)
2. Robię flush
3. Restartuję węzeł
4. Przywracam alokację shardów (null)
5. Czekam na status klastra green
6. Powtarzam dla kolejnego węzła

Tuning recovery shardów

Jeśli infrastruktura pozwala, zwiększam liczbę równoczesnych recovery i limit przepustowości, żeby skrócić czas odtwarzania shardów.

PUT _cluster/settings 
{  
  "persistent": {
    "cluster.routing.allocation.node_concurrent_recoveries": 15,
    "indices.recovery.max_bytes_per_sec": "2000mb"  
  }
}

Puppet przez lata był jednym z filarów automatyzacji i konfiguracji w dużych środowiskach IT. W 2022 roku projekt został przejęty przez firmę Perforce, a pod koniec 2024 roku ogłoszono poważne zmiany w sposobie dystrybucji i licencjonowania.

Najważniejsze z nich to:

• od 2025 roku oficjalne binarki Puppet są dostępne wyłącznie w prywatnym repozytorium Perforce,
• aby z nich korzystać, trzeba zaakceptować nową licencję,
• darmowa wersja pozwala na zarządzanie maksymalnie 25 węzłami (agentami) - powyżej tego progu konieczna jest komercyjna umowa,

kod źródłowy pozostaje otwarty (Apache 2.0), ale tempo publicznych aktualizacji jest wolniejsze niż dotychczas.

Limit 25 węzłów może brzmieć jak coś akceptowalnego dla małych środowisk, ale w praktyce nie wystarczy niemal nikomu - nawet niewielkie firmy łatwo przekraczają tę liczbę, licząc serwery produkcyjne, stagingowe, bazy danych czy load balancery.

OpenVox - społecznościowa odpowiedź na zmiany

W odpowiedzi na nowe zasady licencjonowania powstał fork o nazwie OpenVox, prowadzony przez społeczność Vox Pupuli. Projekt ma na celu utrzymanie otwartej, dostępnej dla wszystkich wersji Puppet, wraz z gotowymi binarkami i bez ograniczeń liczby węzłów.

Trzeba jednak pamiętać, że korzystanie z forka wiąże się z pewnym ryzykiem:

• projekt może zostać porzucony w dowolnym momencie,
• tempo rozwoju i wydawania poprawek może być wolniejsze,
• nie ma gwarancji takiej stabilności i testów, jak w produkcie wspieranym przez firmę,
• mogą pojawić się problemy z kompatybilnością w przyszłości,
• liczba dostępnych modułów i integracji może być mniejsza niż w oryginale.

Dla niektórych organizacji OpenVox może być atrakcyjną opcją, ale w większych, krytycznych środowiskach trzeba dokładnie ocenić, czy ryzyko jest akceptowalne.

Jakie są inne alternatywy dla Puppet?

Jeżeli Puppet w nowym modelu licencyjnym nie spełnia Twoich wymagań, na rynku wciąż jest kilka dojrzałych narzędzi do automatyzacji konfiguracji:

• Ansible - w pełni open source, bez ograniczeń liczby hostów. Bardzo popularny w DevOpsach i CI/CD, konfiguracje pisane w YAML. Jest on agentless, przez co nie jest do konca alternatywą dla puppeta,
• Chef - projekt open source w teorii, ale darmowy tylko w określonych przypadkach: użytek osobisty, non-profit w określonych ramach, lub organizacje kontrybuujące do Chef OSS. W każdej innej sytuacji wymagana jest komercyjna licencja,
• SaltStack (Salt) - otwarte narzędzie przejęte przez VMware, działające w trybie master/minion lub agentless. Wersja OSS nie ma limitów liczby węzłów, wersja komercyjna dodaje GUI i integracje klasy enterprise.

Co to oznacza dla nas

Zmiany w Puppet to jasny sygnał, że nawet długoletnie projekty open source mogą w pewnym momencie zmienić swój model biznesowy. Dla większości firm limit 25 węzłów to realna przeszkoda, wymuszająca dodatkowe koszty lub migrację na inne rozwiązanie.

Warto więc już teraz przyjrzeć się alternatywom - czy to w formie forka OpenVox, czy przejścia na inne narzędzia takie jak Ansible, SaltStack czy Chef - i ocenić, które z nich najlepiej odpowiadają na potrzeby naszej infrastruktury.

W świecie Kubernetes, zarządzanie rosnącą liczbą aplikacji i ich konfiguracjami staje się wyzwaniem. Tradycyjne podejścia często prowadzą do powielania konfiguracji i trudności w utrzymaniu spójności w różnych środowiskach (staging i production). Właśnie tutaj z pomocą przychodzi wzorzec App-of-Apps (aplikacja aplikacji) w ArgoCD, który pozwala na skalowalne zarządzanie całym ekosystemem aplikacji z jednego, centralnego miejsca.

Wzorzec ArgoCD App-of-Apps polega na tym, że jedna, główna aplikacja (parent application) zarządza cyklem życia wielu innych aplikacji (child applications). Zamiast konfigurować każdą aplikację z osobna, definiujemy je wszystkie w jednej, nadrzędnej aplikacji, która następnie synchronizuje i monitoruje ich stan. To kluczowy element podejścia GitOps z ArgoCD.

Architektura i struktura katalogów dla GitOps z ArgoCD

Aby w pełni wykorzystać wzorzec App-of-Apps, kluczowa jest przemyślana struktura katalogów w repozytorium Git. Umożliwia ona spójne definiowanie konfiguracji dla różnych środowisk.

.
├── app-of-apps
│   ├── values-production.yaml  # Globalne wartości dla produkcji
│   └── values-staging.yaml     # Globalne wartości dla stagingu
├── apps
│   ├── cert-manager
│   │   ├── Chart.yaml          # Definicja Helm chart dla cert-manager
│   │   ├── values-production.yaml # Wartości dla produkcji
│   │   └── values-staging.yaml    # Wartości dla stagingu
│   └── fluent-bit
│       ├── Chart.yaml          # Definicja Helm chart dla fluent-bit
│       ├── values-production.yaml # Wartości dla produkcji
│       └── values-staging.yaml    # Wartości dla stagingu

W tej strukturze:

• app-of-apps: Katalog zawiera główne pliki values.yaml dla każdego środowiska. Te pliki kontrolują, które aplikacje i z jakimi parametrami mają zostać wdrożone w danym środowisku.
• apps: Katalog, w którym znajdują się definicje (w moim przypadku Helm Charts) każdej z aplikacji (child applications). Każda aplikacja ma swój własny podkatalog z plikiem Chart.yaml i specyficznymi plikami values.yaml dla różnych środowisk.

Konfiguracja Helm Chart jako zależności

W naszym przykładzie, cert-manager jest wdrażany jako Helm Chart, ale zamiast kopiować cały kod, definiujemy go jako zależność (dependencies) w pliku Chart.yaml:

apiVersion: v2
name: cert-manager
description: Helm chart for cert-manager
type: application
version: 0.1.0
appVersion: 1.0.0
dependencies:
  - name: cert-manager
    alias: certmanager
    version: 1.16.2
    repository: https://charts.jetstack.io

Dzięki temu podejściu, nasza główna aplikacja ArgoCD instaluje cert-managera z oficjalnego repozytorium Jetstack. My natomiast, w pliku values-production.yaml, możemy łatwo dostosować jego konfigurację za pomocą aliasu certmanager:

certmanager:
  namespace: cert-manager
  crds:
    enabled: true
  replicaCount: 2
  podDisruptionBudget:
    enabled: true

To bardzo elastyczne zarządzanie aplikacjami, ponieważ pozwala na dostosowanie konfiguracji zewnętrznego charta bez modyfikowania go bezpośrednio, a jednocześnie utrzymanie wszystkich specyficznych dla środowiska parametrów w jednym miejscu.

Podsumowanie i korzyści

Używanie wzorca App-of-Apps w ArgoCD, w połączeniu z dobrze zorganizowaną strukturą katalogów, przynosi liczne korzyści dla Twojego zarządzania infrastrukturą:

• Standaryzacja: Konfiguracje dla różnych środowisk są spójne i łatwe do zarządzania.
• Łatwość zarządzania: Zmiany wprowadzane są w jednym miejscu, co minimalizuje błędy.
• Skalowalność: Dodawanie nowych aplikacji jest proste.
• Automatyzacja: ArgoCD automatycznie wykrywa i wdraża zmiany, zapewniając spójność stanu klastra.

Kubernetes 1.33 to kamień milowy, który znacząco podnosi elastyczność i bezpieczeństwo platformy. Kluczowe nowości to stabilne, natywne kontenery sidecar, które upraszczają złożone architektury, oraz funkcja in-place Pod resize, umożliwiająca zmianę alokacji zasobów (CPU i pamięci) w działających kontenerach bez konieczności ich restartu. Dodatkowo, domyślnie włączone przestrzenie nazw użytkowników podnoszą poziom izolacji, czyniąc Kubernetes jeszcze potężniejszym narzędziem dla każdego dewelopera i administratora.

1. Kubernetes 1.33 – Ewolucja, a nie rewolucja

Kubernetes nie przestaje się rozwijać, a każda nowa wersja to krok w stronę doskonalszej orkiestracji kontenerów. Wersja 1.33, najnowsze wydanie, skupia się na ewolucji platformy, dostarczając funkcji, na które społeczność czekała od dawna. W artykule przybliżamy dwie najważniejsze nowości, które mogą zmienić sposób projektowania i zarządzania aplikacjami w chmurze.

2. Natywne kontenery sidecar: Prostsze zarządzanie złożonymi architekturami

Wzorzec sidecar, polegający na umieszczaniu dodatkowych kontenerów pomocniczych (np. do logowania czy monitorowania) obok głównej aplikacji w tym samym Podzie, zawsze był popularny. Jednak jego implementacja w starszych wersjach Kubernetes bywała problematyczna.

Jak to działało wcześniej? Wcześniej, gdy startował Pod, nie było gwarancji kolejności uruchamiania kontenerów. Często zdarzało się, że główny kontener startował przed sidecarem. Prowadziło to do nieprzewidywalnych zachowań i błędów, szczególnie podczas rolowania wdrożeń, ponieważ aplikacja mogła próbować komunikować się z sidecarem, który jeszcze nie był gotowy. Wymagało to stosowania skomplikowanych mechanizmów i skryptów, aby wymusić poprawną kolejność.

Jak to działa teraz w Kubernetes 1.33? Dzięki natywnemu wsparciu dla sidecarów, proces został całkowicie zmieniony. Kubernetes implementuje sidecary jako specjalną klasę init containers z restartPolicy: Always. To gwarantuje, że:

1. Najpierw startują sidecary i muszą być gotowe.
2. Dopiero później startuje główny kontener aplikacji.
3. Sidecary działają przez cały cykl życia Podu i kończą działanie dopiero po głównym kontenerze.

Ta fundamentalna zmiana w cyklu życia Podu eliminuje wcześniejsze problemy i sprawia, że złożone architektury z sidecarami są o wiele bardziej niezawodne i łatwiejsze w utrzymaniu.

3. Zmiana rozmiaru Podów w miejscu (in-place Pod resize): Elastyczność bez przestojów

Dotychczas, zmiana zasobów (CPU lub pamięci RAM) w działającym kontenerze wymagała jego restartu/rolloutu. Było to szczególnie uciążliwe dla aplikacji stanowych (sts), gdzie przerwa w działaniu jest niepożądana, lub problematyczna.

W Kubernetes 1.33 ten problem zostaje rozwiązany dzięki funkcji in-place Pod resize.

Jak to działa?

Zamiast restartować Pod, możesz teraz dynamicznie zmienić alokację zasobów dla działającego kontenera. Nowa funkcja pozwala na modyfikację pola spec.containers[*].resources w specyfikacji Podu, które teraz reprezentuje pożądane zasoby.

Aby dokonać takiej zmiany, możesz użyć nowego sub-zasobu resize za pomocą kubectl:

kubectl edit pod <pod-name> --subresource resize

Kubelet na węźle hostującym Pod próbuje dostosować zasoby w locie. Status operacji jest widoczny w status.containerStatuses[*].resources, co daje pełny wgląd w postępy.

Dlaczego in-place Pod resize to game-changer?

Ta funkcja ma kluczowe znaczenie, zwłaszcza dla aplikacji stanowych (StatefulSets), gdzie zachowanie ciągłości działania i stanu jest priorytetem. Zmiana zasobów nie wymaga restartu, co jest kluczowe dla aplikacji wrażliwych na przerwy. Oprócz tego:

• Zwiększona wydajność: Możesz dostosowywać zasoby do rzeczywistego obciążenia, co prowadzi do oszczędności i lepszego wykorzystania zasobów klastra.
• Szybsze skalowanie: Możliwość szybkiego zwiększenia zasobów na start, a następnie ich zmniejszenia (tzw. vertical autoscaling), to ogromna korzyść dla aplikacji o zmiennym profilu obciążenia.

4. Inne istotne zmiany: Domyślne User Namespaces

Kubernetes 1.33 domyślnie włącza przestrzenie nazw użytkowników (User Namespaces). To kolejny ważny krok w kierunku poprawy bezpieczeństwa. Funkcja ta pozwala na uruchamianie procesów wewnątrz kontenera z niższymi uprawnieniami niż te na poziomie systemu hosta. Dzięki temu, nawet w przypadku luki w zabezpieczeniach kontenera, ryzyko eskalacji uprawnień na poziomie systemu jest mniejsz.

5. Podsumowanie

Kubernetes 1.33 dostarcza kluczowych usprawnień, które podnoszą jakość i efektywność pracy z kontenerami. Stabilne sidecary upraszczają zarządzanie złożonymi aplikacjami, a dynamiczna zmiana rozmiaru Podów daje niezrównaną elastyczność, szczególnie w przypadku aplikacji stanowych (sts).

W świecie rosnącego natężenia ruchu automatycznego (botów) i ataków DDoS staje się niezbędne wprowadzenie inteligentnych filtrów już na warstwie L7. W tym wpisie opiszę, jak dzięki prostemu skryptowi w Lua oraz mechanizmom HAProxy zbudowałem jedną z wielu warstw ochrony backendów przed nieporządanym ruchem.

Koncepcja rozwiązania

1. Wykrywanie „sesji” per IP w oparciu o cookie
   - Każda unikalna wartość ciasteczka (__Secure-app_session) to jedna sesja,
   - każde żądanie bez ciasteczka to tzw. „no-cookie” request.
2. Limit 150 sesji/IP w oknie 120 s
   - Po przekroczeniu tej wartości IP zostaje oznaczone jako podejrzane.
3. Akcja po przekroczeniu
   - Przekierowanie do backendu z kolejką (queue), lub drop requestu.

Skrypt Lua: szczegóły działania

Poniżej pełny kod skryptu, wraz z opisem:

-- Globalna tabela do przechowywania stanu per IP
local ip_unique_sessions = {}
local last_cleanup = os.time()

-- Funkcja czyszcząca – resetuje całą strukturę co 120 sekund
local function cleanup()
    local now = os.time()
    if now - last_cleanup >= 120 then
        ip_unique_sessions = {}
        last_cleanup = now
    end
end

-- Escapowanie znaków specjalnych w nazwie ciasteczka
local function escape_pattern(text)
    return text:gsub("([^%w])", "%%%1")
end

-- Wyciąganie wartości cookie z nagłówka
local function get_cookie_value(cookie_header, cookie_name)
    if not cookie_header then
        return nil
    end
    local pattern = escape_pattern(cookie_name) .. "=([^;]+)"
    return cookie_header:match(pattern)
end

-- Główna funkcja sprawdzająca limit
function check_rate_limit(txn)
    -- 1) Czyszczenie przestarzałych danych
    cleanup()

    -- 2) Pobranie IP i nagłówka Cookie
    local client_ip  = txn.f:src() or "unknown"
    local cookie_hdr = txn.f:hdr("Cookie")

    -- 3) Wyciągnięcie wartości ciasteczka
    local cookie_val = get_cookie_value(cookie_hdr, "__Secure-app_session")

    -- 4) Inicjalizacja struktury, jeśli nowe IP
    if not ip_unique_sessions[client_ip] then
        ip_unique_sessions[client_ip] = {
            cookie    = {},   -- set dla unikalnych wartości cookies
            no_cookie = 0     -- licznik requestów bez ciasteczka
        }
    end

    -- 5) Aktualizacja stanu: cookie vs no_cookie
    if cookie_val then
        ip_unique_sessions[client_ip].cookie[cookie_val] = true
    else
        ip_unique_sessions[client_ip].no_cookie = ip_unique_sessions[client_ip].no_cookie + 1
    end

    -- 6) Zliczanie „sesji”
    local count = 0
    for _ in pairs(ip_unique_sessions[client_ip].cookie) do
        count = count + 1
    end
    count = count + ip_unique_sessions[client_ip].no_cookie

    -- 7) Decyzja o przekroczeniu limitu
    if count > 150 then
        return "true"
    else
        return "false"
    end
end

-- Rejestracja funkcji jako sample-fetch „rate_limit”
core.register_fetches("rate_limit", check_rate_limit)

Omówienie krok po kroku

1. Zmienne globalne
   - ip_unique_sessions: pusty słownik, kluczem jest IP, wartością tabela z podkluczami cookie (set) i no_cookie (licznik).
   - last_cleanup: znacznik czasu ostatniego pełnego resetu.
2. cleanup()
   - Wywoływane przy każdym sprawdzeniu – czyści cały stan, jeśli od ostatniego resetu minęło ≥120 s.
   - Zapobiega niekontrolowanemu wzrostowi zużycia pamięci.
3. escape_pattern(text)
   - Zamienia znaki specjalne w nazwie ciasteczka na escaped (%), by string.match traktował je dosłownie. Dzięki temu nazwy z podkreśleniami, myślnikami czy kropkami są bezpieczne.
4. get_cookie_value(cookie_header, cookie_name)
   - Przy braku nagłówka Cookie od razu zwraca nil.
   - Buduje wzorzec: <nazwa>=([^;]+) i zwraca pierwszy dopasowany fragment (wartość ciasteczka).
5. Inicjalizacja struktury
   - Dla każdego nowego IP tworzymy tabelę z pustym setem ciasteczek i licznikiem 0.
6. Aktualizacja stanu
   - Jeśli ciasteczko istnieje: dodajemy jego wartość do setu (unikalność gwarantowana),
   - jeśli nie: inkrementujemy no_cookie.
7. Zliczanie i próg
   - Sumujemy liczbę kluczy w cookie + wartość no_cookie.
   - Porównujemy z progiem (150); w razie przekroczenia zwracamy "true".

Konfiguracja HAProxy

Konfiguracja haproxy może wyglądać następująco:

# Zaladowanie skryptu
lua-load /opt/implix/haproxy/ddos_rate_limit.lua

# Sprawdzenie rate_limit, z pominięciem whitelisty
http-request set-var(req.rate_limit_exceeded) lua.rate_limit if !{ src -f /etc/haproxy/whitelist.txt }

# Ustawienie ddos_rate_exceeded na true jeżeli ip przekroczyło limit
acl ddos_rate_exceeded var(req.rate_limit_exceeded) -m str true

# Kierowanie do kolejkującego backendu
use_backend fpm-queue-backend if ddos_rate_exceeded

# Można też zdropować takie połączenie
# http-request deny if ddos_rate_exceeded

W moim przypadku podejrzany ruch trafia na backend z kolejką, gdzie takie żądania czekają na obsłużenie.

Jakie mogą być inne podejścia do obsługi takich połączeń?

• deny - bezpośredni zakończenie połączenia z dowolnym kodem http,
• silent-drop - zamyka połączenie po stronie HAProxy bez żadnej odpowiedzi ani komunikatu do klienta,
• tarpid - podobne do silent dropa, z tą różnicą że połączenie jest przetrzymywane przez socket haproxy.

Podsumowanie

HAProxy dzięki skryptom Lua otwiera przed nami niemal nieograniczone możliwości zaawansowanej konfiguracji i zarządzania ruchem. Pokazany wyżej przykład to jedynie wierzchołek góry lodowej – za pomocą Lua możesz zbudować własny, w pełni programowalny load balancer, implementować niestandardowe algorytmy routingu, walidować czy modyfikować nagłówki w locie, a nawet integrować się z zewnętrznymi systemami. To elastyczne podejście pozwala dostosować HAProxy dokładnie do potrzeb Twojej infrastruktury i łatwo rozwijać go o kolejne mechanizmy ochrony czy optymalizacji.

Dziś opiszę, jak zintegrować Terraform z GitLab CI/CD, aby stworzyć wydajny i niezawodny proces GitOps.

Po co Terraform i GitOps?

Terraform pozwala opisywać infrastrukturę jako kod (IaC). Dzięki temu możesz ją wersjonować, łatwo powielać i audytować. GitOps dodaje do tego proces CI/CD, w którym każda zmiana w kodzie jest automatycznie wdrażana, eliminując ręczne modyfikacje i minimalizując ryzyko błędów. Trzymanie stanu w gitlabi pomoże też uniknąć potencjalnych problemów i konfliktów.

Struktura GitLab CI/CD

Nasze CI/CD podzielimy na trzy główne etapy: init, plan i apply. Dodatkowo, stan Terraform (tzw. State) przechowamy bezpiecznie w GitLab, co uprości zarządzanie i wyeliminuje potencjalne problemy z przechowywaniem stanu w różnych miejscach.

Poniżej przedstawiam, jak powinien wyglądać plik .gitlab-ci.yml:

stages:
  - validate
  - plan
  - apply

variables:
  TF_ADDRESS: "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}"
  STATES: "terraform/state/${TF_STATE_NAME}"
  TERRAFORM_INIT: "terraform init \
                  -backend-config=address=${TF_ADDRESS}/${STATES} \
                  -backend-config=lock_address=${TF_ADDRESS}/${STATES}/lock \
                  -backend-config=unlock_address=${TF_ADDRESS}/${STATES}/lock \
                  -backend-config=username=${TF_USERNAME} \
                  -backend-config=password=${TF_PASSWORD} \
                  -backend-config=lock_method=POST \
                  -backend-config=unlock_method=DELETE \
                  -backend-config=retry_wait_min=5"
  TF_STATE_NAME: "nazwa-projektu"
  
.terraform-base:
  image:
    name: "registry.gitlab.com/gitlab-org/terraform-images/stable:latest"
  before_script:
    - eval $TERRAFORM_INIT

validate:
  stage: validate
  extends:
    - .terraform-base
  script:
    - terraform validate

plan:
  stage: plan
  extends:
    - .terraform-base
  script:
    - terraform plan -out=plan.tf
  artifacts:
    paths:
      - plan.tf

apply:
  stage: apply
  extends:
    - .terraform-base
  script:
    - terraform apply -input=false plan.tf
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: manual

Sam pipline prezentuje się następująco:

Skąd wziąć zmienne?

• CI_API_V4_URL i CI_PROJECT_ID: Te zmienne zawierają adres URL do API oraz unikalny identyfikator projektu (np. CI_API_V4_URL=https://git.example.com/api/v4/
  CI_PROJECT_ID=210),
• TF_STATE_NAME: dowolna nazwa stanu, która będzie widoczna w gitalabie,
• TF_USERNAME i TF_PASSWORD: Te zmienne są kluczowe do uwierzytelniania w API GitLab, aby potok mógł bezpiecznie zarządzać stanem Terraform. Najbezpieczniej jest stworzyć Project Access Token lub Personal Access Token z odpowiednimi uprawnieniami (zakres api), a następnie zapisać go jako zmienną środowiskową w ustawieniach CI/CD projektu w GitLab.

Podsumowanie

Integracja Terraform z GitLab CI/CD daje nam potężne narzędzie do zarządzania infrastrukturą w sposób w pełni zautomatyzowany, bezpieczny i zgodny z najlepszymi praktykami GitOps. Taki proces pozwala na szybsze i bardziej niezawodne wdrażanie, minimalizując błędy i zapewniając pełną transparentność zmian.

Dzięki nowej konteneryzacji Apple (ogłoszonej podczas WWDC 2025) możesz teraz bezproblemowo uruchomić Kali Linux bezpośrednio na swoim Macu z Apple Silicon. To idealne rozwiązanie dla tych, którzy chcą szybko testować narzędzia bezpieczeństwa bez konieczności stawiania pełnej maszyny wirtualnej.

1. Co to jest Apple Container?

Apple Container to nowy framework wprowadzony w macOS Sequoia, umożliwiający izolowane uruchamianie dystrybucji Linuksa na sprzęcie Apple Silicon. Działa to podobnie do WSL2 na Windows, ale w pełni zintegrowane z ekosystemem Apple.

Kluczowe zalety:

• Lekka wirtualizacja z natywnym wsparciem dla Apple Silicon
• Integracja z narzędziem Homebrew
• Obsługa standardowego formatu kontenerów Docker

2. Przygotowanie środowiska

Wymagania

• macOS Sequoia (15.x) z Apple Silicon (M1/M2/M3)
• Zainstalowany Homebrew

Instalacja kontenerów Apple

Otwórz Terminal

Zainstaluj CLI kontenerów:
brew install --cask container

Uruchom usługę systemową kontenera:
container system start

3. Uruchomienie Kali Linux w kontenerze

Po przygotowaniu frameworka możesz od razu odpalić obraz Kali Linux z DockerHub:
container run --rm -it kalilinux/kali-rolling

Wyjaśnienie parametrów:

• --rm – usuwa kontener po zamknięciu
• -it – interaktywna sesja terminalowa
• kalilinux/kali-rolling – oficjalny obraz Kali Linux

Montowanie woluminów

Aby uzyskać dostęp do plików z macOS wewnątrz kontenera:

container run --rm -it \
--volume $(pwd):/mnt \
--workdir /mnt \
docker.io/kalilinux/kali-rolling:latest

• --volume $(pwd):/mnt – montuje aktualny katalog do /mnt
• --workdir /mnt – ustawia katalog roboczy w kontenerze

4. Ograniczenia i znane problemy

Chociaż uruchamianie Kali Linux w kontenerze to duży krok naprzód, warto pamiętać o kilku ograniczeniach:

1. Tylko Apple Silicon – kontenery działają wyłącznie na procesorach M1/M2/M3.
2. Brak przejścia sprzętowego – niektóre narzędzia pentestingowe wymagające bezpośredniego dostępu do urządzeń USB czy GPU mogą nie działać.
3. Wczesna faza rozwoju – framework może mieć błędy, które będą eliminowane w kolejnych aktualizacjach macOS Sequoia.

5. Dlaczego warto?

• 🚀 Szybkie wdrożenie: kilka poleceń wystarczy, by mieć działający Kali Linux.
• 🔒 Bezpieczeństwo: izolacja kontenera minimalizuje ryzyko wpływu na system hosta.
• 💻 Wydajność: lekka wirtualizacja daje niemal natywne osiągi.
• 🔄 Aktualność: korzystasz z najnowszego obrazu kali-rolling.

6. Podsumowanie

Uruchomienie Kali Linux w kontenerze na macOS to prosty sposób na rozszerzenie swojego środowiska pentestowego bez konieczności instalowania pełnej maszyny wirtualnej. Dzięki nowemu frameworkowi Apple Container na Sequoia, użytkownicy Apple Silicon zyskują dostęp do pełnej gamy narzędzi Kali w zaledwie kilka minut.

Jeśli zależy Ci na wykorzystaniu pełni możliwości HAProxy, w tym najnowszych funkcji takich jak obsługa protokołu QUIC, często konieczna jest kompilacja z kodu źródłowego. Domyślne pakiety HAProxy dostępne w oficjalnych repozytoriach systemów (np. przez apt install haproxy) zazwyczaj nie zawierają wsparcia dla QUIC, ponieważ wymaga to użycia niestandardowej biblioteki OpenSSL. Co więcej, obsługa QUIC jest często dostępna w wersjach komercyjnych (HAProxy Enterprise), dlatego ręczna kompilacja jest najlepszym sposobem, aby uzyskać tę funkcjonalność w wersji darmowej.

W tym poradniku pokażę, jak skompilować HAProxy w wersji 3.2.3 na systemie Debian 12, używając OpenSSL z obsługą QUIC. Cały proces podzielimy na dwa główne etapy: kompilację OpenSSL, a następnie kompilację HAProxy.

Etap 1: Kompilacja i instalacja OpenSSL z QUIC

Zaczynamy od przygotowania OpenSSL z obsługą protokołu QUIC. Domyślna wersja OpenSSL w systemie Debian nie obsługuje tej funkcji, dlatego musimy skompilować ją ręcznie.

Instalacja niezbędnych narzędzi

Zanim zaczniemy, upewnij się, że masz zainstalowane podstawowe narzędzia do kompilacji oraz biblioteki deweloperskie, które będą nam potrzebne do skompilowania HAProxy (Lua, PCRE2).Bash

sudo apt install make build-essential liblua5.4-dev libpcre2-dev

Pobranie i dekompresja OpenSSL

Pobierzemy wersję OpenSSL z gałęzi quictls, która została zmodyfikowana, aby wspierać QUIC.Bash

wget https://github.com/quictls/openssl/archive/refs/tags/opernssl-3.1.5-quic1.tar.gz
tar zxvf opernssl-3.1.5-quic1.tar.gz
cd opernssl-3.1.5-quic1

Konfiguracja i kompilacja OpenSSL

Teraz skonfigurujemy i skompilujemy OpenSSL. Użyjemy wielu opcji, aby zapewnić optymalizację, bezpieczeństwo oraz obsługę QUIC (enable-tls1_3). Instalacja docelowo znajdzie się w katalogu /opt/quictls, aby nie kolidowała z systemową wersją OpenSSL.Bash

OPENSSL_OPTS="enable-tls1_3 \
    -g -O3 -fstack-protector-strong -Wformat -Werror=format-security \
    -DOPENSSL_TLS_SECURITY_LEVEL=2 -DOPENSSL_USE_NODELETE -DL_ENDIAN \
    -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 \
    -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m \
    -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DMD5_ASM \
    -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM \
    -DX448_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 \
"
./config --libdir=lib --prefix=/opt/quictls $OPENSSL_OPTS
make -j $(nproc)
make install -j $(nproc)

Weryfikacja instalacji OpenSSL

Sprawdźmy, czy nowa wersja OpenSSL została poprawnie zainstalowana i obsługuje QUIC.Bash

/opt/quictls/bin/openssl version

Oczekiwana odpowiedź powinna wyglądać tak: OpenSSL 3.1.5+quic 30 Jan 2024 (Library: OpenSSL 3.1.5+quic 30 Jan 2024)

Etap 2: Kompilacja HAProxy 3.2.3

Teraz, gdy mamy gotowy OpenSSL z QUIC, możemy przejść do kompilacji HAProxy, która go wykorzysta.

Pobranie i dekompresja HAProxy

Pobierz najnowszą stabilną wersję HAProxy 3.2.3 ze strony projektu.Bash

wget http://www.haproxy.org/download/3.2/src/haproxy-3.2.3.tar.gz
tar zxf haproxy-3.2.3.tar.gz
cd haproxy-3.2.3

Konfiguracja i kompilacja HAProxy

W tej sekcji skompilujemy HAProxy, wskazując mu ścieżki do naszego niestandardowego OpenSSL. Musimy również włączyć wsparcie dla QUIC, Lua, PCRE2 oraz innych przydatnych funkcji.Bash

HAPROXY_CFLAGS="-O3 -g -Wall -Wextra -Wundef -Wdeclaration-after-statement -Wfatal-errors -Wtype-limits -Wshift-negative-value -Wshift-overflow=2 -Wduplicated-cond -Wnull-dereference -fwrapv -Wno-address-of-packed-member -Wno-unused-label -Wno-sign-compare -Wno-unused-parameter -Wno-clobbered -Wno-missing-field-initializers -Wno-cast-function-type -Wno-string-plus-int -Wno-atomic-alignment"
HAPROXY_OPTS="TARGET=linux-glibc \
    USE_PCRE2=1 USE_PCRE2_JIT=1 \
    USE_PCRE= USE_PCRE_JIT= \
    USE_GETADDRINFO=1 \
    USE_OPENSSL=1 USE_LIBCRYPT=1 \
    USE_LUA=1 \
    USE_PROMEX=1 \
    USE_QUIC=1 \
    USE_EPOLL=1 \
    USE_THREAD=1 \
    USE_NS=1 \
    USE_SLZ=1 USE_ZLIB= \
    LUA_LIB_NAME=lua5.4 \
"
echo "/opt/quictls/lib" > /etc/ld.so.conf.d/quictls.conf && ldconfig
make -j $(nproc) $HAPROXY_OPTS CFLAGS="$HAPROXY_CFLAGS" LDFLAGS="$HAPROXY_LDFLAGS" SSL_INC=/opt/quictls/include SSL_LIB=/opt/quictls/lib all admin/halog/halog

Ważna uwaga: Komenda echo "/opt/quictls/lib" > /etc/ld.so.conf.d/quictls.conf && ldconfig dodaje ścieżkę do naszych nowo skompilowanych bibliotek OpenSSL do globalnej konfiguracji systemu. To kluczowy krok, który pozwala HAProxy (i innym programom) znaleźć biblioteki SSL/TLS.

Instalacja HAProxy

Po udanej kompilacji, zainstaluj binarkę HAProxy w domyślnej lokalizacji.Bash

sudo make -j $(nproc) install-bin

Gratulacje! Właśnie skompilowałeś HAProxy w wersji 3.2.3 z pełnym wsparciem dla protokołu QUIC na Debianie 12. Teraz możesz skonfigurować HAProxy, aby wykorzystać jego nowe możliwości w Twoim środowisku.

Jeżeli chcemy użyć ingressa z ArgoCD zetkniemy się z problemem pętli redirectów

curl -I https://argo.michal.kuzdzal.pl
HTTP/2 307
date: Sat, 06 Aug 2022 20:25:02 GMT
content-type: text/html; charset=utf-8
location: https://argo.michal.kuzdzal.pl/

Dzieje się tak ponieważ backend ArgoCD oczekuje, że sam nawiąże połączenie TLS, w innym przypadku zawsze przekierowuje połączenie na HTTPS.

Najprostszym sposobem jest wyłączenie przekierowań:

kubectl edit deployments.apps argocd-server -n argocd

W polu command dodajemy opcję insecure:

      - command:
        - argocd-server
        - --insecure

Tworzymy na nowo poda:

kubectl scale -n argocd deployment/argocd-server --replicas=0 && kubectl scale -n argocd deployment/argocd-server --replicas=1

Po tym zabiegu wszystko powinno już działać:

curl -I https://argo.michal.kuzdzal.pl
HTTP/2 200
date: Sat, 06 Aug 2022 20:50:51 GMT
content-type: text/html; charset=utf-8
content-length: 788
accept-ranges: bytes
content-security-policy: frame-ancestors 'self';
x-frame-options: sameorigin
x-xss-protection: 1
strict-transport-security: max-age=15724800; includeSubDomains

Czasami w ansiblu może zajść potrzeba żeby "pociąć" jakąś zmienną.
Jako że ansible == python, to możemy skorzystać z formatowania jinja2.

Przykładowo aby oddzielić samą nazwę użytkownika od maila ze zmiennej AWX awx_user_name:

{{ awx_user_name.split('@')[0] | lower }}

Linki

Jinja.

Czasem jest taka potrzeba uruchomienia jakiegoś lokalnego skryptu/programu na zdalnym hoście. Jeżeli nie chcemy kopiować i umieszczać na hoście tego skryptu możemy użyć ssh:

ssh user@host python3 < script.py

Natomiast jeżeli chcemy uruchomić skrypt z dodatkowymi parametrami:

ssh user@host python3 -u - --parametr arg1 < script.py

Oczywiście nic nie stoi na przeszkodzie aby odpalić w ten sposób każdy inny skrypt bashowy, pearlowy itp.

Czasami jest potrzeba przekazania zmiennej env pomiędzy różnymi stagami pipelina. Od wersji 13 gitlaba możemy do tego użyć wbudowanego mechanizmu inherit environment variables. Zapisujemy naszą wartość w pliku .env i przekazujemy ją za pomocą mechanizmu artifacts:

build:
  stage: build
  script:
    - echo "COMMIT=true" >> build.env
  artifacts:
    reports:
      dotenv: build.env

deploy:
  stage: test
  script:
    - echo "$COMMIT"

Linki

Inherit environment variables.

Terraform, numer jeden jeżeli chodzi o IaC (Infrastructure as Code). W bardzo przyjemny sposób można zarządzać infrastrukturą cloudową jak i on-premise.
W tym przypadku opiszę pokrótce jak deployować virtualną maszynę w LXD.

Konfiguracja

Mamy mało kodu, więc tworzymy wszystko w jednym pliku main.tf:

terraform {
  required_providers {
    lxd = {
      source = "terraform-lxd/lxd"
    }
  }
}

provider "lxd" {
  generate_client_certificates = true
  accept_remote_certificate    = true

  lxd_remote {
    name     = "lxd-1"
    scheme   = "https"
    address  = "lxd.kuzdzal.pl"
    port     = "8443"
    default  = true
  }
}

resource "lxd_container" "worker" {
  count     = 3
  remote    = "lxd-1"
  name      = "k8s-${count.index}"
  image     = "ubuntu:20.04"
  ephemeral = false
  type      = "virtual-machine"
  config = {
    "user.access_interface" = "enp5s0"
  }
  limits    = {
    "memory" = "8GB"
    "cpu" = 4
  }
  profiles = ["default"]
  device {
      name       = "root"
      properties = {
          "path" = "/"
          "pool" = "pool_nvme"
          "size" = "25GB"
      }
      type       = "disk"
  }
}

output "droplet_ip_addresses" {
  value = {
    for droplet in lxd_container.worker:
    droplet.name => droplet.ipv4_address
  }
}

Uruchomienie

Inicjalizacja, czyli pobranie wszystkich wymaganych pluginów (w tym przypadku tylko lxd), zsetupowanie i na końcu zniszczenie zasobów:

~ terraform init
~ terraform apply -auto-approve
~ terraform destroy -auto-approve

Linki

Terraform lxd.

Varnish, świetny serwer cache'u umożliwiający bardzo zaawansowaną konfigurację. Większość serwerów cdn dostępnych w internecie wykorzystuje właśnie varnisha na backendzie do serwowania statycznych danych. Osobiście użyłem go jako front przed ghostem, o którego de facto oparty jest ten blog.

Pliki konfiguracyjne

Konfiguracja samego varnisha default.vcl:

vcl 4.0;

backend default {
  .host = "blog-mk:2368";
}

sub vcl_recv {
  if (req.url ~ "/(admin|p|ghost)/") {
           return (pass);
  }
  unset req.http.cookie;
}

sub vcl_backend_response {
    if (beresp.http.content-type ~ "text/plain|text/css|application/json|application/x-javascript|text/xml|application/xml|application/xml+rss|text/javascript") {
        set beresp.do_gzip = true;
        set beresp.http.cache-control = "public, max-age=1209600";
    }
    set beresp.ttl = 1w;
}

Deployment varnish-dep.yaml:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: blog-varnish-dep
  labels:
    app: blog-varnish
spec:
  replicas: 1
  selector:
    matchLabels:
      app: blog-varnish
  template:
    metadata:
      labels:
        app: blog-varnish
    spec:
      containers:
      - name: varnish
        image: varnish:6.4
        imagePullPolicy: Always
        ports:
        - containerPort: 80
        volumeMounts:
        - mountPath: /etc/varnish/default.vcl
          name: varnish-config
          subPath: default.vcl
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 3
          periodSeconds: 3
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 5
      volumes:
      - name: varnish-config
        configMap:
          name: varnish-config
          items:
            - key: default.vcl
              path: default.vcl

Service varnish-svc.yaml:

---
kind: Service
apiVersion: v1
metadata:
  name: varnish-svc
spec:
  selector:
    app: blog-varnish
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

Ingress varnish-ing.yaml:

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: public
  name: blog-stage
spec:
  rules:
  - host: michal.kuzdzal.pl
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: varnish-svc
            port:
              number: 80

Deploy

kubectl create configmap varnish-config --from-file=default.vcl -n blog-stage
kubectl apply -f varnish-ing.yaml -f varnish-svc.yaml -f varnish-dep.yaml

Podsumowanie

W moim przypadku zastosowanie varnisha zwiększyło możliwości przetwarzania req/s mojego clustra prawie dziesięciokrotnie. Wszystko oparte jest tutaj o dosyć słabe wydajnościowo free-tier z oracle-cloud'a. Natomiast jeżeli połączymy całość z cloudflarem, to można uzyskać więcej niż zadawalające rezultaty.

Linki

Varnish,
Oracle free-tier.

Domyślnym ingressem w k3s jest traefik. Osobiście wolne korzystać z nginx'a więc opiszę pokrótce jak zdeploywać go w clustrze k3s'a.

Instalacja k3s

Zaczniemy od instalacji samego k3s z wyłączonym traefikiem:

curl -sfL https://get.k3s.io | sh -s - --disable traefik

Deploy nginx ingress

Z zainstalowanym 'clustrem' jesteśmy gotowi do instalacji nginx ingress:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/baremetal/deploy.yaml

Zmieniamy network na lokalny aby wystawić ingress na 'zewnątrz':

cat > ingress.yaml <<EOF 
spec:
  template:
    spec:
      hostNetwork: true
EOF

kubectl patch deployment ingress-nginx-controller -n ingress-nginx --patch "$(cat ingress.yaml)"

Testy deploy'u

W tym momencie na localhoscie powinniśmy mieć już wystawiony porty http/s. Możemy to sprawdzić curlem:

➜  ~ curl https://localhost -k
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>

Deploy przykładowego nginxa

Utwórzmy zatem przykładowy deployment i wystawmy go za pomocą ingressu:

cat > deploy.yaml <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      # manage pods with the label app: nginx
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-svc
            port:
              number: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  ports:
    - name: http
      port: 80
  selector:
    app: nginx
EOF

kubectl apply -f deploy.yaml

Ważne tutaj jest dodanie w ingress'ie kubernetes.io/ingress.class: nginx. Inaczej nasz ingress nie wystawi naszego servicu.
Jeżeli nie chcemy tego robić musimy wyedytować naszą ingressclass i ustawić go jako default:

kubectl edit ingressclass nginx
  annotations:
    ingressclass.kubernetes.io/is-default-class: "true"

Linki

Nginx ingress