Instalacja za proxy
Dokument dotyczy instalacji, w których maszyny nie mają bezpośredniego dostępu do internetu i cały ruch wychodzący musi przechodzić przez proxy HTTP. Platforma obsługuje ten wariant w całości - zarówno na etapie instalacji, jak i w pracy bieżącej robotów.
Proxy dotyczy dwóch maszyn, nie jednej
Stacja wdrożeniowa i serwer aplikacyjny konfigurują proxy osobno i inaczej:
- stacja wdrożeniowa - zmienne środowiskowe powłoki, ustawiane ręcznie przed utworzeniem środowiska Ansible (sekcja 2),
- serwer aplikacyjny - pola w plikach konfiguracyjnych paczki; instalator sam rozprowadza je po wszystkich komponentach (sekcja 3).
Pominięcie pierwszej z nich jest najczęstszym błędem: instalacja zatrzymuje się przy
pip install ansible, zanim playbook w ogóle wystartuje.
1. Informacje do zebrania przed instalacją
1.1. Adres i uwierzytelnianie
| Pozycja | Przykład | Uwagi |
|---|---|---|
| Adres proxy | http://proxy.firma.local:3128 |
adres i port |
| Uwierzytelnianie | login i hasło | patrz ograniczenie poniżej |
Obsługiwane są wyłącznie proxy otwarte albo z metodą Basic
Metody NTLM oraz Kerberos/Negotiate nie są obsługiwane - nie wspierają ich narzędzia instalujące biblioteki Pythona, z których korzystają zarówno instalator, jak i roboty.
Jeżeli proxy Odbiorcy wymaga NTLM lub Kerberos, konieczne jest konto techniczne z uwierzytelnianiem Basic albo wyłączenie uwierzytelniania dla adresów IP stacji wdrożeniowej i serwera aplikacyjnego.
Poświadczenia podaje się w adresie: http://uzytkownik:haslo@proxy.firma.local:3128.
Znaki specjalne w haśle należy zakodować procentowo (@ jako %40, : jako %3A).
1.2. Inspekcja TLS i certyfikat CA
Gdy proxy rozszywa ruch HTTPS
Jeżeli proxy podmienia certyfikaty serwerów na własne, potrzebny jest plik
certyfikatu CA Odbiorcy w formacie PEM - rozszerzenie .crt lub .pem, zawartość
zaczynająca się od -----BEGIN CERTIFICATE-----.
Bez tego pliku instalacja przerwie się przy pobieraniu pierwszych pakietów, a roboty nie pobiorą swoich zależności.
Jak sprawdzić, czy proxy rozszywa ruch - z serwera aplikacyjnego:
openssl s_client -connect quay.io:443 -proxy proxy.firma.local:3128 </dev/null 2>/dev/null \
| openssl x509 -noout -issuer
Wystawca inny niż publiczny urząd certyfikacji oznacza inspekcję TLS.
Prosimy też rozstrzygnąć, czy ruch robotów do systemów docelowych ma być rozszywany. Przy inspekcji administrator proxy widzi pełne adresy URL wraz z parametrami zapytań, co przy procesach przetwarzających dane wrażliwe może wymagać wyłączenia tych domen z inspekcji.
1.3. Zasoby wewnętrzne z pominięciem proxy
Instalator automatycznie wyłącza z proxy komunikację wewnętrzną platformy - nie trzeba jej zgłaszać. Zgłoś natomiast dodatkowe zasoby wewnętrzne, do których platforma ma sięgać bezpośrednio: wewnętrzny rejestr obrazów, lustro PyPI, zewnętrzny serwer bazy danych.
1.4. Lista adresów do dopuszczenia
Komplet adresów, które muszą być dozwolone po stronie proxy, zawiera dokument Zasoby pobierane z sieci - z podziałem na stację wdrożeniową (tabela A), instalację serwera (tabela B) i pracę bieżącą (tabela C).
2. Stacja wdrożeniowa za proxy
Zmienne ustaw przed utworzeniem środowiska Ansible. Jeśli środowisko powstało już bez nich i instalacja się nie powiodła, usuń je i utwórz ponownie:
rm -rf ~/.venvs/ansible-testto
2.1. Zmienne środowiskowe
export https_proxy=http://proxy.firma.local:3128
export http_proxy=http://proxy.firma.local:3128
Przy inspekcji TLS dodatkowo wskaż certyfikat CA - inaczej pip i ansible-galaxy
przerwą na weryfikacji certyfikatu:
export REQUESTS_CA_BUNDLE=/sciezka/do/proxy-ca.crt
export PIP_CERT=/sciezka/do/proxy-ca.crt
Dopiero teraz utwórz środowisko wg Instalacji platformy, sekcja 5.
Zmienne obowiązują tylko w bieżącej powłoce
Po zamknięciu terminala trzeba je ustawić ponownie - dotyczy to również późniejszych
aktualizacji, gdy będziesz instalować kolekcje dla nowego wydania. Wygodnie jest zapisać
je w pliku i wczytywać przez source.
Zmienne powłoki nie wystarczą serwerowi
Ustawienie https_proxy w powłoce stacji wdrożeniowej nie przenosi się na serwer
aplikacyjny. Konfigurację serwera opisuje sekcja 3 - obie są potrzebne.
2.2. Alternatywa: środowisko z paczki offline
Zamiast przepuszczać stację wdrożeniową przez proxy, można pobrać gotowe środowisko na
maszynie z dostępem do internetu i przenieść je na stację - wtedy pip i ansible-galaxy
nie łączą się z niczym. Opis: Przygotowanie środowiska,
sekcja 2.6.
Wariant wart rozważenia zwłaszcza przy proxy z inspekcją TLS - usuwa cały problem certyfikatu CA po stronie stacji wdrożeniowej. Konfiguracja proxy dla serwera aplikacyjnego (sekcja 3) pozostaje wtedy bez zmian.
2.3. Adresy wymagane przez stację wdrożeniową
| Adres | Po co |
|---|---|
pypi.org, files.pythonhosted.org |
pip install ansible |
galaxy.ansible.com |
ansible-galaxy collection install |
3. Konfiguracja instalacji
Wszystkie pola znajdują się w inventories/klient/group_vars/all/all.yml, w sekcji
Wyjście do internetu.
| Pole | Wartość | Kiedy |
|---|---|---|
proxy_http_url |
http://[uzytkownik:haslo@]proxy.firma.local:3128 |
zawsze w tym wariancie |
proxy_ca_cert_file |
nazwa pliku CA w inventories/klient/ssl/ |
gdy proxy rozszywa TLS |
proxy_no_proxy_extra |
lista hostów po przecinku | gdy są dodatkowe zasoby wewnętrzne |
pip_index_url |
adres wewnętrznego indeksu pakietów Pythona | gdy Odbiorca prowadzi własne lustro PyPI |
pip_trusted_host |
host indeksu | gdy indeks wystawiony po HTTP |
Puste proxy_http_url oznacza ruch wychodzący wprost, z pominięciem proxy.
3.1. Certyfikat CA
Plik wgrywasz do inventories/klient/ssl/, a jego nazwę wpisujesz w proxy_ca_cert_file:
inventories/klient/ssl/proxy-ca.crt
Instalator umieszcza go na serwerze w dwóch miejscach: jako kotwicę w magazynie zaufania
systemu operacyjnego (dzięki czemu działa dnf, pip i pobieranie obrazów) oraz jako
osobny plik montowany do kontenerów robotów. Certyfikat jest dokładany do istniejącego
magazynu zaufania, nie zastępuje go - publiczne urzędy certyfikacji nadal działają.
Plik, który nie jest certyfikatem PEM, przechodzi po cichu
Plik w złym formacie zostanie skopiowany bez ostrzeżenia, a magazyn zaufania po prostu
go pominie - objawem będzie dopiero błąd weryfikacji certyfikatu w połowie instalacji.
Playbook preflight.yml wykrywa to zawczasu; uruchom go przed instalacją.
Kontrola ręczna:
openssl x509 -in inventories/klient/ssl/proxy-ca.crt -noout -subject -dates
3.2. Wyjątki od proxy
Lista wbudowana obejmuje adresy lokalne, nazwy usług wewnętrznych platformy oraz domenę
instalacji wraz z subdomenami. proxy_no_proxy_extra dopisuje do niej kolejne pozycje:
proxy_no_proxy_extra: "nexus.klient.local,pgsql.klient.local"
To ustawienie jest krytyczne, a nie kosmetyczne
Aplikacja wykonawcza robotów honoruje zmienne proxy także dla połączeń do magazynu plików i brokera komunikatów. Gdyby te adresy nie znalazły się na liście wyjątków, ruch wewnętrzny platformy trafiłby do proxy Odbiorcy - roboty przestałyby działać, a przy inspekcji TLS administrator proxy widziałby treść przetwarzanych danych biznesowych.
4. Co instalator robi z tymi ustawieniami
Warto wiedzieć, bo wyjaśnia, dlaczego jedno ustawienie w pliku wystarcza dla całej platformy.
| Komponent | Sposób przekazania proxy |
|---|---|
Menedżer pakietów systemu (dnf) |
wpis w konfiguracji menedżera - nie czyta zmiennych środowiskowych |
| Silnik Docker | konfiguracja usługi systemowej; wszystkie pobrania obrazów wychodzą stąd, także pobranie obrazu robota w trakcie pracy |
| Zadania instalatora pobierające pliki i biblioteki | zmienne środowiskowe zadania |
| Kontener robota RPA | zmienne przekazywane przez komponent zarządzający przy każdym uruchomieniu procesu |
| Usługi platformy (baza, broker, magazyn plików, uwierzytelnianie) | nie wymagają proxy - komunikują się wyłącznie wewnątrz serwera |
Certyfikat CA w kontenerze robota
Aplikacja wykonawcza dokłada certyfikat CA do własnego magazynu zaufania przy starcie i ustawia go dla wszystkich używanych bibliotek - pobierania zależności, automatyzacji przeglądarki i komunikacji z magazynem plików.
5. Weryfikacja
Przed instalacją - playbook sprawdzający, który niczego nie zmienia:
~/.venvs/ansible-testto/bin/ansible-playbook preflight.yml
Kontroluje m.in. format adresu proxy, osiągalność proxy z serwera aplikacyjnego oraz to, czy wskazany plik CA jest w ogóle certyfikatem.
Kontrola ręczna z serwera aplikacyjnego - czy proxy przepuszcza wymagane adresy:
for host in quay.io download.docker.com releases.hashicorp.com pypi.org; do
printf '%-28s ' "$host"
curl -s -o /dev/null -w '%{http_code}\n' \
--proxy http://proxy.firma.local:3128 "https://$host/"
done
Kod inny niż 000 oznacza, że połączenie doszło do celu - także 401 czy 403, bo
serwery odpowiadają tak na żądanie bez poświadczeń. 000 oznacza zablokowanie przez proxy
albo błąd weryfikacji certyfikatu.
6. Najczęstsze problemy
| Objaw | Przyczyna |
|---|---|
pip nie pobiera nic mimo ustawionego https_proxy |
brak REQUESTS_CA_BUNDLE i PIP_CERT przy proxy rozszywającym TLS - sekcja 2.1 |
instalacja przerywa się na pierwszym dnf |
certyfikat CA nieustawiony albo w złym formacie - sekcja 3.1 |
| pobieranie obrazów przerywa się na weryfikacji certyfikatu | jak wyżej; magazyn zaufania systemu obsługuje też silnik Docker |
407 Proxy Authentication Required |
brak poświadczeń w adresie proxy albo proxy wymaga NTLM/Kerberos - sekcja 1.1 |
| instalacja przechodzi, ale roboty nie startują | brak adresów z tabeli C w dozwolonych na proxy - Zasoby sieciowe |
| roboty nie widzą magazynu plików lub brokera | ruch wewnętrzny trafia do proxy - sprawdź proxy_no_proxy_extra, sekcja 3.2 |
| certyfikat Let's Encrypt nie zostaje wystawiony | Let's Encrypt wymaga połączenia zwrotnego z internetu; w instalacji za proxy obowiązuje certyfikat Odbiorcy |