Wymagania sprzętowe EZD RP i instalacja on-premise — serwer, system i sieć
EZD RP można uruchomić na dwa sposoby: w publicznej chmurze SaaS, gdzie infrastrukturą zajmuje się operator, albo na własnych serwerach urzędu (on-premise). Ten artykuł dotyczy drugiego wariantu — co trzeba mieć, żeby system w ogóle wstał, i gdzie najczęściej potykają się administratorzy. Zestawienie opiera się na instrukcjach NASK i ustaleniach z oficjalnego forum EZD RP; stan na październik 2026 r.
Zanim kupisz serwer: czy on-premise ma sens?
NASK nie rekomenduje instalacji on-premise w małych jednostkach i odsyła je do usługi SaaS, bezpłatnej dla uprawnionych podmiotów. Powód jest prosty: EZD RP działa na Kubernetesie, a nawet minimalne środowisko wymaga zasobów i kompetencji, których mała gmina czy szkoła zwykle nie ma. Oficjalnej instalacji bez Kubernetesa (np. na samym Dockerze) nie ma. Porównanie modeli opisujemy na stronie EZD RP w chmurze — model SaaS.
On-premise wybiera się zwykle wtedy, gdy urząd ma własny zespół IT, polityka bezpieczeństwa wymaga trzymania danych u siebie albo potrzebne są integracje, których w chmurze nie da się zrobić.
Wymagania sprzętowe
| Środowisko | CPU | RAM | Dysk | Uwagi |
|---|---|---|---|---|
| testowe (kilka osób) | min. 16 vCPU | min. 28–32 GB | min. 100 GB | z obniżonymi zasobami podów w instalatorze |
| produkcyjne, wariant 3-maszynowy | łącznie ok. 24 vCPU | łącznie ok. 64 GB | min. ok. 100 GB na maszynę + dane | serwer aplikacyjny (master/Rancher) ok. 16 vCPU, bazy ok. 6 vCPU, NFS 2 vCPU / 4 GB |
Trzy rzeczy, które zaskakują najczęściej:
- Kubernetes nie „pożycza” zasobów. Liczy się suma zasobów zarezerwowanych przez wszystkie usługi, a nie faktyczne zużycie. Jeśli rezerwacje przekraczają to, co ma serwer, część usług po prostu nie wystartuje, a instalacja kończy się przekroczeniem czasu.
- Procesor musi obsługiwać instrukcje AVX i architekturę amd64. Na starszych Xeonach część komponentów nie wstaje.
- Na dane trzeba zostawić zapas. Oficjalnych danych o przyroście dla EZD RP nie ma. Dla porównania: w EZD PUW urząd z 70 pracownikami po 7 latach miał ok. 52 GB w bazie i ok. 235 GB plików.
System operacyjny i oprogramowanie
- Ubuntu Server 24.04 + RKE2 — rekomendacja NASK od kwietnia 2026 r. Wcześniej wspierane było wyłącznie Ubuntu 22.04. Debian i RHEL sprawiały na forum problemy.
- Rancher do zarządzania klastrem i Helm do instalacji aplikacji. Repozytorium paczek EZD RP jest publiczne od 2025 r. (
git.eadministracja.nask.pl) — stare repozytorium na wniosek i z białą listą adresów IP jest nieaktualne. Instancje, które nadal na nie wskazują, przestają dostawać aktualizacje. - Bazy danych (PostgreSQL, Redis, RabbitMQ) instaluje się playbookami Ansible dostarczonymi przez NASK, uruchamianymi z serwera aplikacyjnego.
- Repozytorium plików — NFS albo magazyn zgodny z S3.
Sieć, domena i certyfikat
- Domena: system używa stałych nazw hostów (m.in.
ezdrp-web,kuip-web,sso-idp,kuip-api) w poddomenie urzędu, np.ezd.urzad.pl. Instalacja na samym adresie IP praktycznie nie działa. - Certyfikat wildcard dla dokładnie tej poddomeny, z kluczem prywatnym bez hasła. Certyfikat CA musi być zaufany na wszystkich stacjach roboczych.
- DNS dla wszystkich hostów systemu.
- Poczta SMTP — bez niej nie da się ustawić haseł użytkowników.
- Firewall i UTM: jeśli urządzenie brzegowe robi inspekcję SSL (np. FortiGate), trzeba zrobić wyjątek dla repozytorium NASK. Statyczna lista dozwolonych domen zwykle się nie sprawdza.
- Czas: synchronizacja NTP na serwerach i stacjach. Kilka minut różnicy wystarczy, żeby logowanie się zawieszało.
Instalacja krok po kroku
- Przygotowanie maszyn — Ubuntu, aktualizacje, NTP, DNS, certyfikat, konto SMTP. Wszystkie hasła do komponentów tylko z liter i cyfr — znaki specjalne psują konfigurację baz, kolejki i poczty.
- Klaster RKE2 i Rancher — instalacja według instrukcji NASK, import klastra do Ranchera, ustawienie domyślnej klasy magazynu danych.
- NFS — udział dla serwera aplikacyjnego; po instalacji należy zaostrzyć uprawnienia udziału.
- Bazy danych — playbook Ansible z serwera aplikacyjnego; log z instalacji zawiera hasła baz, więc trzeba go zabezpieczyć.
- Repozytorium i dostęp do obrazów — dodanie repozytorium Helm NASK i danych dostępowych do rejestru obrazów.
- Instalacja aplikacji — formularz w Rancherze: domena bazowa, połączenia do baz, poczta. Domyślny limit czasu instalacji bywa za krótki — warto go wydłużyć.
- Pierwsze uruchomienie — logowanie kontem root, założenie i aktywacja podmiotu, import struktury organizacyjnej, użytkowników i JRWA.
- Stacje robocze — zaufany certyfikat CA, NASK Desk (do edycji i podpisu dokumentów), test w kilku przeglądarkach.
- Kopie zapasowe — etcd, bazy danych i repozytorium plików, a w praktyce także migawki maszyn wirtualnych. Odtworzenie trzeba przetestować, zanim system pójdzie na produkcję.
Wymagania dla stanowisk pracy — skanerów, drukarek etykiet i czytników kodów — opisujemy osobno w artykule Sprzęt do EZD RP na stanowisku kancelaryjnym.
Najczęstsze problemy po instalacji
| Objaw | Najczęstsza przyczyna |
|---|---|
| biały ekran albo „kręcące się kropki” przy logowaniu | certyfikat (niezaufany CA, zła poddomena), brak wpisu DNS albo różnica czasu |
| usługi w stanie oczekiwania, instalacja przerwana po czasie | za mało CPU lub RAM względem rezerwacji usług |
| część komponentów nie startuje mimo zasobów | procesor bez AVX |
| brak aktualizacji w Rancherze | stary adres repozytorium |
| błędy po aktualizacji | pominięta dedykowana instrukcja NASK dla danego skoku wersji |
Utrzymanie — o czym pamiętać po starcie
- Aktualizacje: wersja po wersji, z backupem i testem na środowisku testowym. Przed niektórymi skokami NASK publikuje osobne instrukcje — przy przejściu z wersji 26.103 na nowsze trzeba było np. wcześniej włączyć „Nowe zadania” dla każdego podmiotu, inaczej znikała zawartość części widoków.
- Certyfikaty: wewnętrzny certyfikat klastra RKE2 wygasa po roku i trzeba go odnowić; osobno pilnuje się odnowienia certyfikatu wildcard.
- Ręczne zmiany konfiguracji mogą nie przetrwać aktualizacji — warto je notować.
- Wersje on-premise pojawiają się później niż w chmurze NASK i nie każda wersja trafia do publicznego repozytorium.
Najczęstsze pytania
Jakie są minimalne wymagania sprzętowe EZD RP? Dla środowiska testowego NASK podawał minimum ok. 16 vCPU, 28–32 GB RAM i 100 GB dysku. Produkcyjny wariant z trzema maszynami to łącznie ok. 24 vCPU i 64 GB RAM. Procesor musi obsługiwać AVX.
Czy EZD RP da się zainstalować na Windows Server? Nie. System działa na Linuksie (rekomendowane Ubuntu Server 24.04) w klastrze Kubernetes RKE2. Windows jest potrzebny na stacjach roboczych, bo tam działa NASK Desk.
Czy mała gmina potrzebuje własnego serwera? Zwykle nie. NASK nie rekomenduje on-premise dla małych jednostek i poleca publiczną chmurę SaaS. Wtedy urząd potrzebuje tylko dobrego łącza, stałego publicznego adresu IP i przygotowanych stanowisk pracy.
Ile trwa instalacja? Sama instalacja na przygotowanych maszynach to zwykle kilka dni pracy doświadczonego administratora. Dłużej trwa przygotowanie: domena, certyfikat, sieć, bazy, a potem konfiguracja podmiotu i import danych.
Potrzebujesz pomocy przy instalacji albo chcesz porównać koszt on-premise z chmurą? Napisz do nas albo zacznij od audytu przedwdrożeniowego.
Źródła: instrukcje instalacji EZD RP w podręczniku użytkownika; Wymagania i rekomendacje EZD RP — gov.pl; odpowiedzi zespołu EZD RP i doświadczenia administratorów na oficjalnym forum EZD RP (2024–2026). Wymagania zmieniają się z kolejnymi wersjami — przed zakupem sprzętu sprawdź aktualną instrukcję NASK.
Potrzebujesz porozmawiać o szczegółach wdrożenia w Twojej jednostce?
