Za firmowym proxy

Wiele sieci fabrycznych i korporacyjnych dociera do internetu wyłącznie przez firmowe proxy HTTP (na przykład proxy Squid na porcie 3128). IronFlock Appliance instaluje się i działa w takiej konfiguracji bez problemów — podajesz swoje proxy w poleceniu instalacyjnym, a ironflock appliance install konfiguruje za ciebie całą resztę.

Ta strona zakłada, że host Appliance nie ma ustawionych żadnych zmiennych środowiskowych proxy — proxy podajesz jawnie. Wyjaśnia, co instalacja obsługuje automatycznie, oraz jeden dodatkowy krok potrzebny dla proxy przechwytujących TLS.

To jest uzupełnienie poświęcone proxy dla sekcji Konfiguracja zapory sieciowej w przewodniku po Appliance. Te same punkty końcowe IronFlock muszą być osiągalne — różnica polega na tym, że tutaj dociera się do nich przez twoje proxy.

Dlaczego proxy wymaga uwagi

Obrazy platformy IronFlock są pobierane przez demona Docker — usługę działającą w tle z własną konfiguracją sieciową, niezależną od twojej powłoki. Nawet na hoście, który poza tym dociera do internetu przez proxy, demon o nim nie wie, dopóki nie zostanie mu to jawnie wskazane. Pozostawiony bez konfiguracji próbuje łączyć się bezpośrednio, sieć go blokuje, a instalacja zatrzymuje się na kroku logowania z przekroczeniem czasu:

Error response from daemon: Get "https://instance-registry.ironflock.com/v2/":
net/http: request canceled while waiting for connection (Client.Timeout exceeded)

Co instalacja obsługuje za ciebie

Gdy podasz proxy w poleceniu instalacyjnym, ironflock appliance install konfiguruje za ciebie demona Docker i agenta urządzenia hosta — przechowuje ustawienia proxy w /etc/ironflock/proxy.env, który może odczytać tylko root, kieruje Docker i agenta do tego pliku i restartuje Docker, aby mógł dotrzeć do rejestru IronFlock. Ten krok jest:

• Bezobsługowy — proxy podajesz raz (zobacz poniżej); instalacja zapisuje konfigurację i restartuje za ciebie Docker, bez ręcznej konfiguracji demona.
• Całkowicie pomijany, gdy proxy nie zostanie podane — instalacje z bezpośrednim dostępem do internetu nie są tym dotknięte.

Instalacja kieruje też przez proxy własne połączenie Appliance z chmurą — walidację licencji oraz łącze zdalnego zarządzania, które pozwala dotrzeć do twojej instancji z ironflock.com. Zapisuje twoje proxy w centralnym pliku konfiguracyjnym Appliance, /opt/ironflock/.env, a platforma używa go automatycznie. Każda późniejsza aktualizacja je zachowuje (zobacz Późniejsza zmiana lub usunięcie proxy). Aby Appliance pojawił się online, nie jest potrzebna żadna osobna konfiguracja.

Uruchamianie instalacji za proxy

Proxy jest potrzebne w dwóch miejscach: skrypt instalacyjny potrzebuje go, aby pobrać ironflock, a ironflock appliance install potrzebuje go, aby skonfigurować Docker. Ustaw adres URL proxy raz, przekaż go do curl za pomocą --proxy i do skryptu instalacyjnego jako zmienne środowiskowe, a następnie do ironflock appliance install za pomocą --http-proxy / --https-proxy:

# Twoje firmowe proxy — edytuj tę linię
PROXY="http://proxy.your-company.com:3128"
 
curl -fsSL --proxy "$PROXY" https://instance-registry.ironflock.com/dl/cli/install.sh \
  | sudo env HTTP_PROXY="$PROXY" HTTPS_PROXY="$PROXY" bash
 
sudo ironflock appliance install --license-file license.txt \
  --http-proxy "$PROXY" --https-proxy "$PROXY"

Zastąp adres URL proxy własnym, a license.txt plikiem, który zawiera twój Instance Key (zobacz Instalacja). Jeśli twoje proxy wymaga logowania, zobacz Uwierzytelnianie w proxy: hasło nie trafia do adresu URL.

Flagi proxy polecenia ironflock appliance install:

sudo nie przekazuje zmiennych proxy twojej powłoki do ironflock, dlatego podaj proxy flagami. Pozostałe flagi polecenia opisuje sekcja ironflock appliance install.

Ruch lokalny zawsze omija proxy

Nie musisz zarządzać NO_PROXY ręcznie. Instalacja zawsze pozostawia localhost, 127.0.0.1 oraz własny adres hosta Appliance poza proxy (wszystko, co przekażesz za pomocą --no-proxy, jest zachowywane i scalane). Gwarantuje to, że do lokalnego app store i rejestru Appliance dociera się bezpośrednio, nigdy kierując ruch na zewnątrz przez firmowe proxy.

Uwierzytelnianie w proxy

Jeśli twoje proxy wymaga logowania, nadaj Appliance własne konto usługi zamiast konta konkretnej osoby. Jego ruch pojawia się wtedy w logach proxy pod nazwą, którą kontroluje twój zespół sieciowy: może on ograniczyć, do czego to konto ma dostęp, a także je wyłączyć lub zmienić jego hasło bez ingerowania w czyjekolwiek osobiste dane logowania. To strona proxy zagadnienia opisanego w sekcji Tożsamość sieciowa hostów IronFlock.

• Obsługiwane: uwierzytelnianie Basic. Podaj użytkownika w adresie URL proxy, a hasło za pomocą --proxy-password-file, pliku, który zawiera je w jednym wierszu (albo /dev/stdin). ironflock odrzuca adres URL proxy zawierający hasło, ponieważ każdy użytkownik hosta może odczytać wiersze poleceń. Appliance przechowuje hasło w plikach, które może odczytać tylko root, więc potem możesz usunąć ten plik:

  sudo ironflock appliance install --license-file license.txt \
    --https-proxy "http://[email protected]:3128" \
    --proxy-password-file proxy-password.txt

• Jeszcze nieobsługiwane: uwierzytelnianie zintegrowane z systemem Windows (Kerberos, NTLM). Jeśli twoje proxy nie akceptuje niczego innego, poproś zespół sieciowy o dopuszczenie konta usługi z uwierzytelnianiem Basic albo o wpuszczanie adresu Appliance bez uwierzytelniania jako nazwanego hosta.

Co przekazać zespołowi sieciowemu na temat ruchu:

• Trafia on wyłącznie do punktów końcowych z listy w sekcji Konfiguracja zapory sieciowej, przez HTTPS na porcie 443. Przekaźnik e-mail na porcie 2525 nigdy nie korzysta z proxy.
• Łącze zdalnego zarządzania z cbw.ironflock.com to długotrwałe połączenie WebSocket z ruchem keep-alive co kilka sekund. Jeśli proxy zrywa długotrwałe połączenia po określonym czasie, Appliance sam łączy się ponownie w ciągu kilku sekund, ale zdalni użytkownicy mogą za każdym razem zauważyć krótką przerwę — tam, gdzie to możliwe, wyłącz to połączenie z limitów czasu życia połączeń.

Późniejsza zmiana lub usunięcie proxy

Proxy jest zapisywane w centralnym pliku konfiguracyjnym Appliance, /opt/ironflock/.env, a każda aktualizacja je zachowuje. Aby je zmienić na zainstalowanym Appliance, użyj ironflock appliance configure. Polecenie stosuje ustawienia w demonie Docker, usługach platformy i agencie urządzenia, a Appliance restartuje tylko wtedy, gdy coś się zmieniło:

# Przełącz na inne proxy
sudo ironflock appliance configure --https-proxy "http://proxy2.your-company.com:3128"
 
# Zmień hosty, które omijają proxy
sudo ironflock appliance configure --no-proxy "buildserver.corp.example.com"

Każde ustawienie jest niezależne: ustawienie, którego nie podasz, zachowuje to, co ma Appliance, więc przekazanie samego --https-proxy pozostawia twoją istniejącą listę NO_PROXY nietkniętą.

Aby usunąć proxy — na przykład po przeniesieniu Appliance do sieci z bezpośrednim dostępem do internetu — przekaż puste proxy:

sudo ironflock appliance configure --http-proxy "" --https-proxy ""

Konfiguracja proxy zostaje ponownie usunięta z demona Docker i agenta urządzenia, a Appliance wraca do połączeń bezpośrednich. Twoja lista NO_PROXY jest zachowywana na wypadek późniejszego ponownego włączenia.

Proxy wymagającego logowania nie da się dziś ustawić przez configure: ironflock appliance configure nie przyjmuje hasła proxy. Tylko ironflock appliance install przyjmuje --proxy-password-file. Uruchomione na zainstalowanym Appliance, appliance install doprowadza go do podanych opcji i zachowuje jego sekrety i ustawienia (Ponowne uruchomienie), więc może ustawić nowe proxy z hasłem:

sudo ironflock appliance install --version <version> \
  --https-proxy "http://[email protected]:3128" \
  --proxy-password-file proxy-password.txt

W --version podaj wersję, na której działa Appliance (pokazuje ją ironflock status); bez tej flagi uruchomienie aktualizuje też Appliance do najnowszego wydania jego kanału. Zainstalowany Appliance zachowuje swój Instance Key, więc uruchomienie nie potrzebuje --license-file.

Urządzenia brzegowe

Wszystko powyższe odnosi się w równym stopniu do urządzeń brzegowych podłączanych za pomocą ironflock agent install. Przyjmuje ono te same flagi proxy — przekaż proxy przy jego uruchamianiu, a poprowadzi przez nie swoje pobierania (menedżer pakietów, instalacja Dockera, pobranie agenta), demona Docker oraz agenta urządzenia:

sudo ironflock agent install -c mydevice.flock \
  --http-proxy "$PROXY" --https-proxy "$PROXY"

Skrypt instalacyjny pobierający ironflock działa przed nim, więc przekaż proxy także temu krokowi. sudo domyślnie nie przekazuje zmiennych proxy z Twojej powłoki, więc podaj je jawnie i przekaż flagi proxy do ironflock agent install:

curl -fsSL --proxy "$PROXY" https://instance-registry.ironflock.com/dl/cli/install.sh \
  | sudo env HTTP_PROXY="$PROXY" HTTPS_PROXY="$PROXY" bash -s -- agent install -c mydevice.flock \
      --http-proxy "$PROXY" --https-proxy "$PROXY"

Jeśli urządzenie pobiera obrazy aplikacji z lokalnego app store Appliance, a nie z chmury, dodaj host tego rejestru za pomocą --no-proxy, aby te pobrania pozostały w sieci lokalnej.

Jeśli proxy wymaga logowania, na urządzeniu hasło nie trafia do adresu URL proxy. ironflock odrzuca flagę proxy, której adres URL zawiera hasło, ponieważ każdy użytkownik urządzenia może odczytać wiersze poleceń. Podaj użytkownika w adresie URL, a hasło umieść w pliku, który zawiera je w jednym wierszu:

sudo ironflock agent install -c mydevice.flock \
  --https-proxy "http://[email protected]:3128" \
  --proxy-password-file proxy-password.txt

Urządzenie przechowuje hasło w /etc/ironflock/proxy.env, pliku, który może odczytać tylko root, więc swój plik z hasłem możesz potem usunąć.

Na urządzeniach z systemem Windows agent działa jako usługa systemu Windows. Przekaż proxy instalatorowi usługi — obejmuje ono połączenie z platformą oraz automatyczne aktualizacje agenta:

.\device-agent.exe service install -config .\myaccount_myproject_mydevice.flock -proxy "http://proxy.example.com:3128"

Które hosty omijają proxy

NO_PROXY działa na nazwę hosta, z którą łączy się klient, nigdy na adres, na który ta nazwa się rozwiązuje. Appliance, do którego urządzenie sięga po nazwie — czyli każdy appliance w trybie domeny, zobacz Interfejsy aplikacji i HTTPS — musi zatem zostać wymieniony wprost. W przeciwnym razie agent kieruje połączenie z lokalnym appliance przez firmowe proxy, a ponieważ większość proxy odmawia trasowania z powrotem do sieci wewnętrznej, urządzenie nigdy nie pojawia się online.

Instalator ustala to na podstawie własnego pliku .flock urządzenia. Obok localhost i 127.0.0.1 dodaje domenę appliance — zarówno w postaci zwykłej, jak i z kropką na początku — oraz każdy host rejestru, z którym łączy się bez TLS. Urządzenia chmurowe nie dostają nic poza dwoma wpisami loopback, ponieważ ich punkty końcowe są publiczne i proxy rzeczywiście jest im potrzebne.

Wszystko inne, czego wymaga Twoja instalacja, podajesz w -no-proxy, odpowiedniku flagi --no-proxy polecenia ironflock agent install:

.\device-agent.exe service install -config .\myaccount_myproject_mydevice.flock `
  -proxy "http://proxy.example.com:3128" `
  -no-proxy "buildserver.corp.example,10.0.0.0/8"

Późniejsza zmiana ustawień

Wynik zapisywany jest do %ProgramData%\IronFlock\DeviceAgent\proxy.env i od tej chwili to ten plik jest rozstrzygający:

HTTP_PROXY=http://proxy.example.com:3128
HTTPS_PROXY=http://proxy.example.com:3128
NO_PROXY=localhost,127.0.0.1,appliance.corp.example,.appliance.corp.example

Zmodyfikuj go i uruchom ponownie .\device-agent.exe service install, aby zastosować zmianę. Późniejsza instalacja nigdy nie nadpisuje tego pliku, a service uninstall zachowuje katalog agenta — Twoje ustawienia przetrwają więc cykl odinstalowania i instalacji, którego wymaga ponowna instalacja usługi. Użyj -force-proxy, aby celowo zastąpić plik wartościami z flag.

Na urządzeniach z systemem Windows zainstalowanych przed agentem 1.4.0 folderem nadal jest %ProgramData%\IronFlock\Reagent, dopóki agent nie przeniesie urządzenia do nowego układu.

Usuń wpis, jeśli ta lokalizacja sięga do appliance przez proxy. Oba warianty występują naprawdę: appliance w tej samej sieci zakładowej jest osiągany bezpośrednio, natomiast hostowany centralnie bywa dostępny wyłącznie przez firmowe proxy. Instalator nie potrafi ich rozróżnić, dlatego zapisuje hosty dosłownie — usuń te, które nie dotyczą Twojej sieci.

Docker konfiguruje się osobno

Docker Desktop nie czyta ani proxy.env, ani środowiska usługi. Obrazy pobiera demon Dockera, który ma własne ustawienia w Settings → Resources → Proxies, wraz z własną listą wykluczeń — a ta również potrzebuje hosta appliance. Proxy poprawione po stronie agenta nie naprawia docker pull.

Urządzenia z Linuksem

ironflock agent install przyjmuje --no-proxy bezpośrednio, więc appliance można wskazać już podczas instalacji:

sudo ironflock agent install -c mydevice.flock \
  --http-proxy "$PROXY" --https-proxy "$PROXY" \
  --no-proxy "appliance.corp.example.com"

localhost, 127.0.0.1 i ::1 zawsze omijają proxy. To samo dotyczy serwera aktualizacji wskazanego w pliku .flock urządzenia, gdy nie jest on hostem chmury IronFlock, co ma miejsce w przypadku urządzeń podłączonych do Appliance.

Ustawienia są przechowywane w /etc/ironflock/proxy.env, pliku, który może odczytać tylko root. Docker i agent urządzenia pobierają je stamtąd. Aby później je zmienić, użyj ironflock agent configure. Każda podana flaga zastępuje swoje ustawienie, a pozostałe zostają bez zmian:

# Zmień hosty, które omijają proxy
sudo ironflock agent configure --no-proxy "appliance.corp.example.com,buildserver.corp.example"
 
# Przełącz urządzenie na inne proxy
sudo ironflock agent configure --https-proxy "http://proxy2.your-company.com:3128"
 
# Odłącz urządzenie od proxy
sudo ironflock agent configure --remove-proxy

Polecenie pokazuje ustawienia przed zmianą i po niej. Aby zaczęły obowiązywać, Docker musi się zrestartować, co na chwilę zatrzymuje aplikacje na urządzeniu, dlatego polecenie najpierw pyta. Zmienna proxy w twoim własnym drop-inie systemd (systemctl edit) przestaje działać, gdy plik ustawień ustawia tę samą zmienną; polecenie ostrzega przed takim drop-inem. Szczegóły opisuje sekcja ironflock agent configure.

Urządzenia skonfigurowane przed pojawieniem się ironflock przechowują proxy w drop-inie systemd o nazwie http-proxy.conf, gdzie może je odczytać każdy użytkownik urządzenia, łącznie z hasłem. Pierwsze uruchomienie ironflock agent configure przenosi te ustawienia do /etc/ironflock/proxy.env.

Na urządzeniach zainstalowanych przed październikiem 2026 jednostka nadal nazywa się reagent.service (z katalogiem drop-inów reagent.service.d), dopóki agent nie przeniesie urządzenia do nowego układu.

Proxy przechwytujące TLS (firmowy urząd certyfikacji)

Wiele firmowych proxy inspekcjonuje ruch HTTPS, ponownie podpisując go firmowym urzędem certyfikacji (CA). W takim przypadku skonfigurowanie proxy jest konieczne, ale niewystarczające — host Appliance musi również ufać temu CA, w przeciwnym razie każde połączenie z chmurą (pobieranie obrazów, walidacja licencji, łącze zarządzania) zostanie odrzucone.

Zainstaluj CA raz, w systemowym magazynie zaufania hosta. Appliance montuje ten magazyn zaufania we wszystkich swoich kontenerach, więc Docker i każda usługa IronFlock uwzględniają CA — nie ma nic do skonfigurowania na poziomie pojedynczego kontenera czy usługi. Ponieważ kontenery odczytują go przy uruchomieniu, zrestartuj stos po dodaniu lub zmianie CA (krok 3 poniżej).

1. Uzyskaj firmowy CA

Poproś swój zespół sieciowy o główny CA „inspekcji SSL” / „przechwytywania TLS” proxy — ten sam certyfikat, który jest już wdrożony na zarządzanych maszynach firmowych — w postaci pliku .crt. To najczystsze źródło.

Zainstaluj wystawiający CA, a nie certyfikat pojedynczego hosta. Częstym błędem jest zapisanie ponownie podpisanego przez proxy certyfikatu dla jednego hosta (np. tylko instance-registry.ironflock.com). Sprawia to, że działa tylko ten jeden host, a wszystkie pozostałe hosty w chmurze nadal zawodzą. Potrzebujesz CA, który podpisuje te certyfikaty.

Jeśli nie możesz uzyskać pliku bezpośrednio, ale proxy prezentuje swój pełny łańcuch, możesz wyodrębnić CA z połączenia — zastąp <PROXY_HOST>:<PROXY_PORT> swoim proxy:

# Przechwyć łańcuch, jeden PEM na certyfikat. c1 to liść danego hosta (pomiń go);
# c2..cN to firmowy łańcuch CA do zaufania.
echo quit | openssl s_client -connect instance-registry.ironflock.com:443 \
  -proxy <PROXY_HOST>:<PROXY_PORT> -showcerts 2>/dev/null \
  | awk '/BEGIN CERTIFICATE/{n++; c=1} c{print > ("/tmp/proxy-c" n ".pem")} /END CERTIFICATE/{c=0}'
 
# Opcjonalnie — sprawdź, co wróciło:
for f in /tmp/proxy-c*.pem; do echo "== $f =="; openssl x509 -in "$f" -noout -subject -issuer; done

2. Zainstaluj go i przebuduj magazyn zaufania

Jeśli twój zespół IT dał ci .crt bezpośrednio:

sudo cp corporate-root-ca.crt /usr/local/share/ca-certificates/corporate-proxy-ca.crt
sudo update-ca-certificates

Jeśli wyodrębniłeś go z powyższego łańcucha, zaufaj każdemu certyfikatowi z wyjątkiem liścia (c1):

i=0; for f in $(ls -v /tmp/proxy-c*.pem | tail -n +2); do
  i=$((i+1)); sudo cp "$f" "/usr/local/share/ca-certificates/corporate-proxy-ca-$i.crt"
done
sudo update-ca-certificates

3. Zweryfikuj

Każdy host IronFlock w chmurze musi teraz walidować przez proxy — status HTTP, a nie błąd TLS:

for H in instance-registry.ironflock.com web.ironflock.com cbw.ironflock.com \
         registry.ironflock.com regauth.ironflock.com; do
  curl -x http://<PROXY_HOST>:<PROXY_PORT> -sS -o /dev/null -w "$H -> %{http_code}\n" "https://$H/"
done

Kod taki jak 200, 401 lub 404 dla wszystkich pięciu oznacza, że CA jest poprawny. Następnie zrestartuj Appliance, aby usługi go uwzględniły. Jeśli instalacja zatrzymała się na kroku logowania, uruchom zamiast tego ponownie to samo polecenie instalacyjne: kontynuuje od miejsca, w którym się zatrzymało.

sudo ironflock appliance restart

Zdalny dostęp do interfejsów użytkownika urządzeń

IronFlock pozwala otworzyć interfejs użytkownika działający na urządzeniu brzegowym lub maszynie — HMI maszyny, stronę PLC, ekran konfiguracji lub pulpitu na urządzeniu — bezpośrednio w IronFlock, z dowolnego miejsca. To kluczowy element umożliwiający zdalny serwis i wsparcie: inżynier może dotrzeć do interfejsu maszyny bez przebywania on-site ani w sieci lokalnej. Dostęp jest zawsze pośredniczony i strzeżony przez system uprawnień IronFlock, więc do danego urządzenia docierają wyłącznie autoryzowani użytkownicy.

Ten tunel zdalnego dostępu jest zbudowany na frp (Fast Reverse Proxy) — dojrzałej, powszechnie używanej technologii open source. IronFlock wykorzystuje go wyłącznie do zapewnienia opisanego powyżej dostępu do interfejsów urządzeń.

Dlaczego firmowe proxy może przeszkadzać

frp ma zaawansowane możliwości pokonywania barier sieciowych i z tego powodu produkty antywirusowe oraz zabezpieczające proxy często oznaczają go ogólnie jako riskware — mimo że jako komponent open source z długą historią jest bezpieczny i jest tu używany wyłącznie do usankcjonowanej funkcji zdalnego dostępu. Gdy tak się dzieje, proxy blokuje pobranie komponentu IronFlock zawierającego frp.

To nie psuje twojego Appliance: tunel zdalnego dostępu jest funkcją opcjonalną, więc jeśli ten komponent zostanie zablokowany, platforma instaluje się i działa normalnie, po prostu funkcjonując bez dostępu do interfejsów urządzeń. W panelu elementy sterujące zdalnym dostępem danego urządzenia wskazują wtedy, że zdalny dostęp nie jest dostępny na tym Appliance.

Na co musi zezwolić firmowe IT

Jeśli twoja organizacja chce skorzystać z funkcji zdalnego serwisu IronFlock, komponent IronFlock zawierający frp musi mieć zezwolenie na pobranie przez firmowe proxy. Poproś swój zespół sieciowy/bezpieczeństwa o dwie konkretne rzeczy:

• Wyjątek od skanowania dla pobrań obrazów z instance-registry.ironflock.com, aby ogólna klasyfikacja jako riskware nie blokowała komponentu tunelu. To węższy zakres niż wyłączenie całego ruchu IronFlock z inspekcji TLS — pozostały ruch Appliance może nadal podlegać inspekcji.
• Odnotowanie wykrycia jako znanego fałszywego alarmu. frp to powszechnie używane reverse proxy open source; IronFlock wykorzystuje je wyłącznie do opisanej powyżej funkcji zdalnego dostępu, chronionej systemem uprawnień.

Obowiązują te same punkty końcowe IronFlock, które są już wymienione dla Appliance — zobacz Konfiguracja zapory sieciowej; tu chodzi o niepoddawanie tego ruchu skanowaniu/blokowaniu, ponad samym jego kierowaniem.

Gdy frp zostanie już przepuszczony, następna aktualizacja ponawia pobranie, a funkcja włącza się, gdy tylko się ono powiedzie, bez żadnych innych zmian. Aby spróbować od razu, uruchom ponownie instalację z wersją, na której działa Appliance (pokazuje ją ironflock status); zachowuje ona sekrety i ustawienia Appliance:

sudo ironflock appliance install --version <version>

Działanie bez zdalnego dostępu

Jeśli nie potrzebujesz dostępu do interfejsów urządzeń — lub chcesz czystej instalacji w czasie, gdy załatwiany jest wyjątek proxy — możesz jawnie wyłączyć tunel. Cała reszta instaluje się jak zwykle:

# w czasie instalacji
sudo ironflock appliance install --license-file license.txt --no-tunnel
 
# lub na już zainstalowanym Appliance
sudo ironflock appliance configure --no-tunnel

Wybór jest zapamiętywany między aktualizacjami. Włącz go ponownie później (gdy frp zostanie przepuszczony) za pomocą --tunnel:

sudo ironflock appliance configure --tunnel

Rozwiązywanie problemów

Instalacja zatrzymuje się na logowaniu do instance-registry.ironflock.com z błędem Client.Timeout. Demon Docker nie może dotrzeć do rejestru. Uruchom ponownie ironflock appliance install i przekaż swoje proxy za pomocą --http-proxy / --https-proxy, jak pokazano powyżej.

Logowanie nadal nie powiodło się po skonfigurowaniu proxy. Twoje proxy najprawdopodobniej przechwytuje TLS. Zainstaluj firmowy CA zgodnie z opisem w sekcji Proxy przechwytujące TLS, a następnie ponownie uruchom polecenie instalacyjne.

Sprawdź, czy demon Docker widzi proxy:

sudo docker info | grep -i proxy
sudo docker login instance-registry.ironflock.com

docker info pokazuje proxy, z którego korzysta Docker, z zamaskowanym hasłem. Jeśli docker login powiedzie się samodzielnie, instalacja Appliance przejdzie poza nieudany krok.

Pojedynczy komponent nie może się pobrać, podczas gdy cała reszta instaluje się bez problemów. To zwykle komponent zdalnego dostępu oparty na frp, blokowany przez twoje proxy lub antywirus jako riskware. Instalacja i tak kończy się pomyślnie — niedostępny jest jedynie dostęp do interfejsów urządzeń. Aby go włączyć, poproś zespół zarządzający proxy o przepuszczenie tego ruchu zgodnie z opisem w sekcji Zdalny dostęp do interfejsów użytkownika urządzeń, a następnie uruchom sudo ironflock appliance install --version <version> z wersją, na której działa Appliance. Aby celowo zainstalować bez tego komponentu, przekaż --no-tunnel.

Aktualizacje

Gdy Appliance zostanie zainstalowany za proxy, jego ustawienia proxy są zapamiętywane w /opt/ironflock/.env i ponownie stosowane przy każdej aktualizacji. Aktualizacje z interfejsu Appliance i poleceniem ironflock appliance update nadal działają przez proxy bez dodatkowych działań — zobacz Utrzymanie w przewodniku po Appliance. Aby skierować Appliance na inne proxy — lub całkowicie odłączyć go od proxy — zobacz Późniejsza zmiana lub usunięcie proxy.

Jeśli zdalny dostęp do interfejsów urządzeń został zablokowany w czasie instalacji, każda aktualizacja automatycznie ponawia jego próbę — więc gdy tylko twoje proxy przepuści frp, następna aktualizacja włączy tę funkcję bez żadnych dodatkowych kroków.