Jeden projekt Packer, trzy szablony Proxmox
2 minute read
Na początku zawsze wygląda to niewinnie.
Jedna maszyna testowa. Potem druga. Potem dochodzi inna dystrybucja. A na końcu masz:
- kilka katalogów,
- kilka „lekko” różnych konfiguracji,
- provisioning kopiowany metodą copy–paste,
- i zero pewności, czy te maszyny naprawdę są takie same.
Ten projekt powstał dokładnie z tego powodu — żeby przestać rzeźbić każdą maszynę osobno.
Co to w ogóle robi?
W skrócie:
projekt Packer → wiele szablonów VM na Proxmox
- może budować AlmaLinux 10,
- może budować Ubuntu,
- może budować Alpine,
Jak to jest podzielone (bez bólu głowy)
Żeby nie robić jednego wielkiego potwora, projekt jest rozbity logicznie na repozytoria:
Każde repo wygląda bardzo podobnie — dzięki temu wiesz, gdzie czego szukać, niezależnie od dystrybucji.
Jak to działa – krok po kroku
1. Packer łączy się z Proxmox
Na starcie Packer:
- łączy się z API Proxmox,
- tworzy tymczasową maszynę,
- podpina ISO instalacyjne.
Dane dostępowe nie są w kodzie — są pobierane z Vaulta.
2. Automatyczna instalacja systemu
Zamiast klikać instalator ręcznie:
- AlmaLinux używa kickstarta,
- Ubuntu będzie używać autoinstall,
- Alpine używa setup-alpine.
Packer:
- uruchamia mały serwer HTTP,
- podaje instalatorowi adres pliku konfiguracyjnego,
- instalacja leci sama, bez żadnych pytań.
Efekt? Zawsze ten sam system, zainstalowany w ten sam sposób.
3. Provisioning po instalacji
Gdy system już się uruchomi, Packer:
- loguje się po SSH,
- dodaje klucz publiczny,
- ustawia sudo bez hasła,
- uruchamia jeden wspólny skrypt provisioningowy.
Ten skrypt:
- aktualizuje system,
- instaluje
qemu-guest-agent, - opcjonalnie instaluje rzeczy typu
sssd/realmd, - włącza potrzebne usługi.
To jest jedno miejsce, w którym utrzymujesz „bazową konfigurację” VM.
4. Zapis jako template
Na końcu:
- maszyna jest wyłączana,
- zapisywana jako template w Proxmox,
- gotowa do klonowania.
Bez ręcznego sprzątania. Bez „czy ja o czymś nie zapomniałem?”.
Gdzie są różnice między systemami?
I tu jest najważniejsza część.
Różnice nie są w logice, tylko w danych:
- inny plik instalacyjny,
- inny plik
pkrvars, - czasem inne domyślne zasoby.
Cała reszta:
- Vault,
- sieć,
- provisioning,
- standardy bezpieczeństwa,
pozostaje taka sama.
Jak się tego używa?
Dla pojedynczego systemu:
packer init .
packer fmt -var-file=pkrvars/alma-10.hcl .
packer validate -var-file=pkrvars/alma-10.hcl .
packer build -var-file=pkrvars/alma-10.hcl .
Albo wszystko naraz:
bash scripts/packer_build.bash
Skrypt sam przechodzi po wszystkich profilach.
Co mi to realnie daje?
Najważniejsze rzeczy w praktyce:
- koniec z ręcznym klikaniem instalatorów
- koniec z różnymi „prawie takimi samymi” VM
- jedno miejsce na zmiany
- łatwa integracja z CI/CD
- łatwe dodanie kolejnej dystrybucji
To nie jest projekt „na pokaz”. To jest narzędzie, które faktycznie upraszcza życie, gdy masz więcej niż jedną maszynę.