Przygotowanie środowiska

Instalacja platformy testto wymaga dwóch maszyn.

Maszyna	Rola	Kiedy potrzebna
Stacja wdrożeniowa	uruchamia instalator (Ansible), łączy się po SSH z serwerem	na czas instalacji i późniejszych aktualizacji
Serwer aplikacyjny	tu stoi platforma - wszystkie usługi, bazy i roboty RPA	stale

1. Dlaczego dwie maszyny

Instalator testto jest zestawem ról Ansible. Ansible działa bezagentowo: nie instaluje się go na serwerze docelowym, lecz uruchamia z osobnej maszyny, która łączy się z serwerem po SSH i wykonuje na nim polecenia. Serwer aplikacyjny nie musi więc mieć zainstalowanego ani Ansible, ani Pythona w konkretnej wersji - cały ten wymóg dotyczy stacji wdrożeniowej.

   Stacja wdrożeniowa                         Serwer aplikacyjny
   (Ansible, Python 3.11+)  ── SSH / 22 ──▶   (Rocky Linux 9, Docker Swarm)

Stacja wdrożeniowa nie może być tym samym serwerem

Uruchomienie instalatora na serwerze docelowym nie jest wspierane. Rola system wykonuje pełną aktualizację pakietów i restartuje maszynę w trakcie instalacji — proces Ansible uruchomiony lokalnie zostałby wtedy przerwany w połowie przebiegu.

2. Stacja wdrożeniowa

2.1. Czym może być

Dowolny komputer spełniający wymagania z sekcji 2.2 - również laptop administratora. Nie musi to być zasób stały: jest potrzebna na czas instalacji oraz później przy każdej aktualizacji platformy. Może stać wewnątrz sieci Odbiorcy.

2.2. Wymagania

Pozycja	Wymaganie
System	Linux lub macOS. Windows wyłącznie przez WSL 2 - Ansible nie działa natywnie w Windows
Python	3.11 lub nowszy
Ansible	ansible-core 2.18 lub nowszy (pakiet ansible w wersji 11.x)
Pakiety Pythona	psycopg2-binary, passlib
Kolekcje Ansible	instalowane z collections/requirements.yml w paczce
Narzędzia w PATH	openssl, dig (pakiet bind-utils / dnsutils), unzip, sshpass (gdy logowanie do serwera odbywa się hasłem)
Zasoby	2 vCPU, 2 GB RAM, 5 GB wolnego dysku

2.3. Instalacja narzędzi - Rocky Linux 9 / RHEL 9

# Python w wersji obsługiwanej przez instalator (3.11 również jest poprawne)
sudo dnf install -y python3.12

# sshpass nie występuje w repozytoriach bazowych - jest w EPEL
sudo dnf install -y epel-release
sudo dnf install -y sshpass

# pozostałe narzędzia
sudo dnf install -y openssl bind-utils unzip

Gdy polityka nie pozwala dokładać repozytorium EPEL

sshpass jest potrzebny wyłącznie przy logowaniu do serwera hasłem. Logowanie kluczem SSH usuwa ten wymóg całkowicie, a przy okazji eliminuje hasło z pliku z sekretami - patrz Instalacja platformy, sekcja 3.

2.4. Instalacja narzędzi - Ubuntu / Debian

sudo apt update
sudo apt install -y python3-venv python3-pip openssl dnsutils unzip sshpass
python3 --version   # musi pokazać 3.11 lub nowszy

2.5. Łączność stacji wdrożeniowej

Kierunek	Cel	Uwagi
Do serwera aplikacyjnego	22/TCP (SSH)	konieczne przez cały czas instalacji
Do internetu	443/TCP	wyłącznie po Ansible i kolekcje - imienna lista w Zasobach sieciowych, tabela A. Do pominięcia przy instalacji z paczki offline (sekcja 2.6)

2.6. Stacja wdrożeniowa bez dostępu do internetu

Gdy stacja nie ma dostępu do sieci zewnętrznej - również przez proxy - pobierz gotowe środowisko na dowolnej maszynie z internetem i przenieś je na tę maszynę dowolnym kanałem (nośnik, udział sieciowy):

Paczkę środowiska offline pobierzesz ze strony Historia wydań - z tabeli Linie wydań, z tego samego wiersza, co paczka instalacyjna Twojej linii.

Paczka zawiera ansible-core wraz z zależnościami oraz komplet kolekcji wymaganych przez instalator. Archiwum nie jest zabezpieczone hasłem - to publicznie dostępne pakiety open source, bez żadnych danych Twojej instalacji.

unzip testto-ansible-offline-<wersja>.zip
cd testto-ansible-offline-<wersja>
./instaluj.sh

Skrypt sam znajdzie interpreter Pythona w obsługiwanej wersji, utworzy środowisko wirtualne w ~/.venvs/ansible-testto i zainstaluje wszystko bez ani jednego połączenia z siecią. Inna lokalizacja: ./instaluj.sh /sciezka/do/venva. Wewnątrz paczki są też polecenia do wykonania ręcznie, gdyby polityka nie pozwalała uruchamiać skryptów.

Poprawny wynik kończy się linią ansible [core 2.18.19] i listą czterech kolekcji. Po tym kroku pomiń sekcję 5 Instalacji platformy - środowisko jest gotowe.

Warunek	Wymaganie
Architektura	Linux x86-64, glibc 2.17 lub nowsza (Rocky/RHEL 8+, Ubuntu 18.04+)
Python	3.11 albo 3.12 - musi być już zainstalowany na stacji
sshpass	nadal potrzebny przy logowaniu hasłem; nie ma go w paczce, bo to pakiet systemowy

Pakiety systemowe pozostają po Twojej stronie

Paczka rozwiązuje wyłącznie zależności Pythona i Ansible. Sam interpreter oraz openssl, dig, unzip i sshpass instalujesz z repozytoriów systemowych (sekcja 2.3) albo z nośnika instalacyjnego systemu.

Inna architektura niż x86-64

Pakiety binarne w paczce są skompilowane dla Linuksa x86-64. Dla ARM albo macOS poproś zespół Testto o osobny wariant.

3. Serwer aplikacyjny

Cała platforma pracuje na jednym hoście w klastrze Docker Swarm złożonym z tego jednego węzła. Roboty RPA uruchamiają się jako kontenery na tym samym serwerze, więc jego zasoby obsługują zarówno platformę, jak i wykonywane procesy.

3.1. System operacyjny

Pozycja	Wymaganie
System	Rocky Linux 9 (instalacja minimalna)
Architektura	x86-64
Stan wyjściowy	system czysty, bez zainstalowanego Dockera

Instalator sam doinstaluje silnik Docker, pakiety systemowe i zależności - nie należy przygotowywać ich wcześniej.

3.2. Zasoby sprzętowe

Zakres instalacji	vCPU	RAM	Dysk
Pełny (z centralnym logowaniem)	8	24 GB	200 GB
Bez centralnego logowania	8	16 GB	200 GB

3.3. Porty przychodzące

Port	Protokół	Przeznaczenie
443	TCP	cały ruch użytkowników i API (HTTPS)
5671	TCP	AMQPS - broker komunikatów; wymagany, gdy agent RPA pracuje na odrębnej maszynie
22	TCP	dostęp administracyjny i instalacja (SSH)
80	TCP	przekierowanie HTTP na HTTPS - port jest otwierany przy każdej instalacji

Ruch przychodzący może zostać ograniczony do sieci użytkowników (LAN / VPN) - nie jest wymagana dostępność z całego internetu.

Port 80 a Let's Encrypt

Platforma weryfikuje certyfikaty Let's Encrypt metodą TLS-ALPN po porcie 443, nie przez port 80. Port 80 służy wyłącznie przekierowaniu użytkowników wpisujących adres bez https:// i można go zamknąć - kosztem tego, że taki adres nie zadziała.

3.4. Konto i uprawnienia

Instalator loguje się na serwer jednym kontem i wykonuje wszystkie zadania przez sudo.

Pozycja	Wymaganie
Konto	zwykłe konto systemowe z prawem do sudo
Logowanie	hasłem (wymaga sshpass na stacji) albo kluczem SSH (zalecane)
sudo	bez hasła (NOPASSWD) albo hasło podane w konfiguracji instalacji

3.5. Hasło startowe od dostawcy serwera

Zmień hasło ręcznie przed instalacją

Dostawcy maszyn wirtualnych (OVH, Hetzner i inni) wysyłają hasło oznaczone jako wygasłe, które system wymusza zmienić przy pierwszym logowaniu. Ansible tego nie wykona - połączenie zakończy się błędem uwierzytelnienia, bez czytelnej przyczyny.

Przed instalacją zaloguj się na serwer ręcznie przez SSH i zmień hasło.

4. Rekordy DNS

Nazwy usług muszą wskazywać rekordem A (lub AAAA) na adres IP serwera aplikacyjnego — publiczny albo wewnętrzny, zależnie od wariantu wdrożenia. W instalacji wewnętrznej nazwy może obsługiwać wewnętrzny serwer DNS.

Nazwa	Usługa	Kiedy wymagana
dashboard.<domena>	interfejs użytkownika	zawsze
api.<domena>	API backendu	zawsze
auth.<domena>	uwierzytelnianie (Keycloak)	zawsze
amq.<domena>	broker komunikatów	zawsze
logs.<domena>	podgląd logów	przy centralnym logowaniu
s3.<domena>	magazyn plików - API	zawsze
web-s3.<domena>	magazyn plików - konsola	zawsze

Wariant z prefiksem - bez wydzielonej strefy DNS

Gdy usługi mają działać pod domeną korporacyjną bez osobnej strefy, stosujemy prefiks: testto-dashboard.firma.pl, testto-api.firma.pl i tak dalej. Zestaw nazw pozostaje ten sam, zmienia się wyłącznie schemat <prefiks><nazwa>.<domena>.

5. Certyfikat TLS

Cały ruch użytkowników odbywa się po HTTPS. Certyfikat jest też importowany do magazynów zaufania usług wewnętrznych platformy, dlatego niekompletny łańcuch uniemożliwia poprawną pracę systemu, a nie tylko wywołuje ostrzeżenie w przeglądarce.

Wariant	Kiedy stosować
Certyfikat Odbiorcy (zalecany)	instalacje wewnętrzne oraz każda instalacja bez ruchu przychodzącego z internetu
Let's Encrypt	wyłącznie gdy domena jest publiczna, a serwer osiągalny z internetu na porcie 443

Zalecany jest certyfikat wildcard *.<domena> - pokrywa wszystkie usługi i pozostaje ważny przy zmianie zakresu instalacji. Certyfikat z listą nazw (SAN) jest dopuszczalny, ale musi obejmować wszystkie nazwy z sekcji 4; brak choćby jednej uniemożliwi uruchomienie odpowiedniej usługi.

Formaty dostarczenia: PKCS#12 (.p12 / .pfx, certyfikat wraz z pośrednimi i kluczem, hasło przekazywane odrębnym kanałem) albo para plików PEM (pełny łańcuch w jednym pliku oraz osobny klucz prywatny bez hasła). Klucz RSA co najmniej 2048 bitów albo ECDSA P-256. Certyfikat główny urzędu nie jest wymagany w pliku.

Let's Encrypt nie zadziała w instalacji izolowanej

Wystawienie certyfikatu wymaga, aby serwery Let's Encrypt nawiązały połączenie zwrotne z serwerem Odbiorcy. W instalacji odciętej od internetu lub pracującej wyłącznie przez proxy jest to niemożliwe - obowiązuje wtedy certyfikat dostarczony przez Odbiorcę.

6. Poczta wychodząca

Poczta nie jest wymagana do instalacji. System wdroży się i będzie działał bez skonfigurowanego serwera poczty - wiadomości (zaproszenia użytkowników, resetowanie haseł) poczekają w kolejce i zostaną wysłane po uzupełnieniu konfiguracji i ponownym uruchomieniu playbooka.

Gdy poczta ma działać od początku, przygotuj: adres serwera przekazującego (host:port), dane uwierzytelniające (jeśli wymagane) oraz adres nadawcy.

Microsoft 365 i Google Workspace

Konta w tych usługach wymagają hasła aplikacji - uwierzytelnianie OAuth2 nie jest obsługiwane. Serwer przekazujący musi też akceptować wskazany adres nadawcy (zgodność z SPF).

7. Baza danych

Domyślnie instalator stawia własny klaster PostgreSQL na serwerze aplikacyjnym - w tym wariancie nie są potrzebne żadne dodatkowe przygotowania.

Jeżeli baza ma pracować na infrastrukturze Odbiorcy, wymagane są: PostgreSQL w wersji minimum 16, dostępne locale en_US.UTF-8, dwie bazy danych (dane aplikacji oraz uwierzytelnianie) i jednorazowy dostęp konta administracyjnego, które potrafi zakładać role i schematy. Szczegółową specyfikację przekazuje zespół Testto przed wdrożeniem.

8. Lista kontrolna

#	Pozycja	Gotowe
1	Serwer Rocky Linux 9 z zasobami wg sekcji 3.2, konto z sudo	☐
2	Hasło startowe serwera zmienione ręcznie po pierwszym logowaniu	☐
3	Ustalone, czy sudo działa bez hasła - jeśli nie, hasło przygotowane	☐
4	Stacja wdrożeniowa z Pythonem ≥ 3.11 i dostępem SSH do serwera	☐
4a	Gdy stacja jest bez internetu - pobrana paczka środowiska offline (sekcja 2.6)	☐
5	Na stacji wdrożeniowej: openssl, dig, unzip, sshpass (przy logowaniu hasłem)	☐
6	Porty przychodzące 443, 5671 i 22 otwarte na serwer	☐
7	Adresy z Zasobów sieciowych - tabela A i B - dopuszczone	☐
8	Adresy systemów docelowych robotów zebrane i dopuszczone	☐
9	Dane proxy przekazane: adres, uwierzytelnianie, certyfikat CA (jeśli dotyczy)	☐
10	Potwierdzone, że proxy nie wymaga NTLM ani Kerberos	☐
11	Certyfikat TLS dostarczony w jednym z formatów z sekcji 5	☐
12	Rekordy DNS założone i wskazujące na serwer	☐
13	Dane serwera poczty przekazane (jeśli poczta ma działać od początku)	☐
14	Wymagania PostgreSQL spełnione (jeśli baza po stronie Odbiorcy)	☐

Po odhaczeniu listy przejdź do Instalacji platformy.