Derrière un proxy d’entreprise

De nombreux réseaux d’usine et d’entreprise n’atteignent internet qu’à travers un proxy HTTP d’entreprise (par exemple un proxy Squid sur le port 3128). L’IronFlock Appliance s’installe et fonctionne sans accroc dans cette configuration — vous fournissez votre proxy dans la commande d’installation, et ironflock appliance install configure tout le reste à votre place.

Cette page suppose que l’hôte de l’appliance n’a aucune variable d’environnement de proxy définie — vous fournissez le proxy explicitement. Elle explique ce que l’installation gère automatiquement et l’étape supplémentaire nécessaire pour les proxys qui interceptent le TLS.

Ceci est le complément « proxy » de la section Configuration du pare-feu du guide Appliance. Les mêmes points de terminaison IronFlock doivent être accessibles — la différence est qu’ici ils sont atteints à travers votre proxy.

Pourquoi un proxy demande de l’attention

Les images de la plateforme IronFlock sont récupérées par le démon Docker — un service en arrière-plan avec sa propre configuration réseau, distincte de votre shell. Même sur un hôte qui peut par ailleurs atteindre internet à travers le proxy, le démon ne le connaît pas tant qu’on ne le lui indique pas explicitement. Laissé non configuré, il tente de se connecter directement, le réseau le bloque, et l’installation s’arrête à l’étape de connexion avec un délai d’attente dépassé :


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

Ce que l’installation gère pour vous

Lorsque vous fournissez un proxy dans la commande d’installation, ironflock appliance install configure le démon Docker et l’agent d’appareil de l’hôte à votre place — il conserve les paramètres de proxy dans /etc/ironflock/proxy.env, que seul root peut lire, fait pointer Docker et l’agent vers ce fichier et redémarre Docker afin qu’il puisse atteindre le registre IronFlock. Cette étape est :

Sans intervention — vous fournissez le proxy une seule fois (voir ci-dessous) ; l’installation écrit la configuration et redémarre Docker pour vous, aucune configuration manuelle du démon.
Entièrement ignorée lorsqu’aucun proxy n’est fourni — les installations en accès internet direct ne sont pas affectées.

L’installation achemine également la propre connexion de l’appliance vers le cloud à travers le proxy — la validation de la licence et l’uplink de gestion à distance qui vous permet d’atteindre votre instance depuis ironflock.com. Il enregistre votre proxy dans le fichier de configuration central de l’appliance, /opt/ironflock/.env, et la plateforme l’utilise automatiquement. Chaque mise à jour ultérieure le conserve (voir Modifier ou supprimer le proxy ultérieurement). Aucune configuration distincte n’est nécessaire pour que l’appliance se mette en ligne.

Lancer l’installation derrière un proxy

Le proxy est nécessaire à deux endroits : le script d’installation en a besoin pour télécharger ironflock, et ironflock appliance install en a besoin pour configurer Docker. Définissez l’URL du proxy une fois, passez-la à curl avec --proxy et au script d’installation sous forme de variables d’environnement, puis à ironflock appliance install avec --http-proxy / --https-proxy :


# Votre proxy d'entreprise — modifiez cette ligne
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"

Remplacez l’URL du proxy par la vôtre, et license.txt par le fichier qui contient votre Instance Key (voir Installation). Si votre proxy exige une authentification, voir Authentification auprès du proxy : le mot de passe ne va pas dans l’URL.

Les drapeaux de proxy de ironflock appliance install :

Drapeau	Rôle
`--http-proxy <url>`	Proxy pour le trafic HTTP en clair de Docker, de l’agent et de l’appliance. `""` le supprime.
`--https-proxy <url>`	Proxy pour le trafic HTTPS (celui qui importe pour la récupération des images). `""` le supprime.
`--no-proxy <list>`	Hôtes supplémentaires séparés par des virgules qui doivent contourner le proxy.
`--proxy-password-file <file>`	Un fichier ou un pipe (`/dev/stdin`) dont l’unique ligne est le mot de passe de l’utilisateur indiqué dans les URL de proxy.

sudo ne transmet pas les variables de proxy de votre shell à ironflock : indiquez donc le proxy avec les drapeaux. Les autres drapeaux de la commande sont décrits dans ironflock appliance install.

Le trafic local contourne toujours le proxy

Vous n’avez pas besoin de gérer NO_PROXY à la main. L’installation garde toujours localhost, 127.0.0.1 et la propre adresse d’hôte de l’appliance en dehors du proxy (tout ce que vous passez avec --no-proxy est conservé et fusionné). Cela garantit que l’app store local et le registre de l’appliance sont atteints directement, jamais acheminés vers l’extérieur à travers le proxy d’entreprise.

Authentification auprès du proxy

Si votre proxy exige une authentification, attribuez à l’appliance son propre compte de service plutôt que le compte d’une personne. Son trafic apparaît alors dans les journaux du proxy sous un nom que votre équipe réseau maîtrise : elle peut restreindre les destinations autorisées pour ce compte, le désactiver ou en changer le mot de passe sans toucher aux identifiants personnels de qui que ce soit. C’est le pendant côté proxy de la section Identité réseau des hôtes IronFlock.

Pris en charge : l’authentification Basic. Nommez l’utilisateur dans l’URL du proxy et fournissez le mot de passe avec --proxy-password-file, un fichier qui le contient sur une ligne (ou /dev/stdin). ironflock refuse une URL de proxy qui contient un mot de passe, car chaque utilisateur de l’hôte peut lire les lignes de commande. L’appliance conserve le mot de passe dans des fichiers que seul root peut lire : vous pouvez donc supprimer le fichier ensuite :
```
sudo ironflock appliance install --license-file license.txt \
  --https-proxy "http://[email protected]:3128" \
  --proxy-password-file proxy-password.txt
```
Pas encore pris en charge : l’authentification intégrée Windows (Kerberos, NTLM). Si votre proxy n’accepte rien d’autre, demandez à votre équipe réseau d’autoriser le compte de service avec l’authentification Basic, ou d’admettre l’adresse de l’appliance sans authentification en tant qu’hôte nommé.

Ce qu’il faut indiquer à votre équipe réseau au sujet de ce trafic :

Il se limite aux points de terminaison de la liste Configuration du pare-feu, en HTTPS sur le port 443. Le relais d’e-mails sur le port 2525 n’utilise jamais le proxy.
L’uplink de gestion à distance vers cbw.ironflock.com est une connexion WebSocket de longue durée, avec un trafic keep-alive toutes les quelques secondes. Si le proxy coupe les connexions de longue durée au bout d’un délai fixe, l’appliance se reconnecte d’elle-même en quelques secondes, mais les utilisateurs distants peuvent remarquer une brève interruption à chaque fois — dans la mesure du possible, exemptez cette connexion des limites de durée de vie des connexions.

Modifier ou supprimer le proxy ultérieurement

Le proxy est enregistré dans le fichier de configuration central de l’appliance, /opt/ironflock/.env, et chaque mise à jour le conserve. Pour le modifier sur une appliance installée, utilisez ironflock appliance configure. La commande applique les paramètres au démon Docker, aux services de la plateforme et à l’agent de l’appareil, et ne redémarre l’appliance que lorsque quelque chose a changé :


# Passer à un autre proxy
sudo ironflock appliance configure --https-proxy "http://proxy2.your-company.com:3128"
 
# Modifier les hôtes qui contournent le proxy
sudo ironflock appliance configure --no-proxy "buildserver.corp.example.com"

Chaque paramètre est indépendant : un paramètre que vous ne fournissez pas garde ce que l’appliance a, si bien que passer uniquement --https-proxy laisse votre liste NO_PROXY existante intacte.

Pour supprimer le proxy — par exemple après avoir déplacé l’appliance vers un réseau avec accès internet direct — passez un proxy vide :


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

La configuration du proxy est de nouveau retirée du démon Docker et de l’agent de l’appareil, et l’appliance revient à des connexions directes. Votre liste NO_PROXY est conservée en vue d’une réactivation ultérieure.

Un proxy qui exige une authentification ne peut pas encore être défini avec configure : ironflock appliance configure n’accepte pas de mot de passe de proxy. Seul ironflock appliance install accepte --proxy-password-file. Exécuté sur une appliance installée, appliance install l’amène aux options données et conserve ses secrets et ses paramètres (Exécuter à nouveau la commande) ; il peut donc définir le nouveau proxy avec son mot de passe :


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

Donnez à --version la version qu’exécute l’appliance (ironflock status l’affiche) ; sans cette option, l’exécution met aussi l’appliance à jour vers la version la plus récente de son canal. L’appliance installée conserve son Instance Key : l’exécution n’a donc pas besoin de --license-file.

Appareils Edge

Tout ce qui précède s’applique de la même manière aux appareils edge connectés avec ironflock agent install. Il prend les mêmes drapeaux de proxy — passez le proxy lorsque vous l’exécutez, et il achemine ses téléchargements (gestionnaire de paquets, installation de Docker, téléchargement de l’agent), le démon Docker et l’agent de l’appareil à travers le proxy pour vous :


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

Le script d’installation qui télécharge ironflock s’exécute avant lui : donnez donc le proxy à cette étape aussi. sudo ne transmet pas par défaut les variables de proxy de votre shell ; passez-les explicitement et transmettez les flags de proxy à 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"

Si l’appareil récupère les images d’apps depuis un app store d’appliance local plutôt que depuis le cloud, ajoutez l’hôte de ce registre avec --no-proxy pour que ces récupérations restent sur le réseau local.

Si le proxy exige une authentification, le mot de passe ne va pas dans l’URL du proxy sur un appareil. ironflock refuse une option de proxy dont l’URL contient un mot de passe, car chaque utilisateur de l’appareil peut lire les lignes de commande. Indiquez l’utilisateur dans l’URL et placez le mot de passe dans un fichier qui le contient sur une seule ligne :


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

L’appareil conserve le mot de passe dans /etc/ironflock/proxy.env, que seul root peut lire : vous pouvez donc supprimer le fichier ensuite.

Sur les appareils Windows, l’agent s’exécute en tant que service Windows. Transmettez le proxy à l’installateur du service — il couvre la connexion à la plateforme ainsi que les mises à jour automatiques de l’agent :


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

Quels hôtes contournent le proxy

NO_PROXY s’applique au nom d’hôte composé par le client, jamais à l’adresse vers laquelle ce nom est résolu. Une appliance que l’appareil atteint par son nom — toute appliance en mode domaine, voir Interfaces d’applications et HTTPS — doit donc être nommée explicitement, faute de quoi l’agent envoie sa connexion vers l’appliance locale à travers le proxy d’entreprise. La plupart des proxies refusant de router vers le réseau interne, l’appareil ne se connecte jamais.

L’installateur le déduit du .flock de l’appareil lui-même. À côté de localhost et 127.0.0.1, il ajoute le domaine de l’appliance — dans sa forme simple et dans celle avec point initial — ainsi que tout hôte de registre joint sans TLS. Les appareils cloud ne reçoivent rien au-delà des deux entrées de loopback, car leurs points de terminaison sont publics et ont bel et bien besoin du proxy.

Tout le reste dont votre site a besoin passe par -no-proxy, l’équivalent de l’option --no-proxy d’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"

Modifier les réglages par la suite

Le résultat est écrit dans %ProgramData%\IronFlock\DeviceAgent\proxy.env, et ce fichier fait autorité à partir de là :


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

Modifiez-le puis relancez .\device-agent.exe service install pour appliquer le changement. Une installation ultérieure n’écrase jamais le fichier, et service uninstall conserve le répertoire de l’agent : vos réglages survivent donc au cycle désinstallation/installation qu’impose une réinstallation du service. Utilisez -force-proxy pour remplacer délibérément le fichier à partir des options.

Sur les appareils Windows installés avant l’agent 1.4.0, le dossier reste %ProgramData%\IronFlock\Reagent tant que l’agent n’a pas migré l’appareil vers la nouvelle organisation.

Supprimez une entrée si ce site atteint l’appliance via le proxy. Les deux cas existent réellement : une appliance sur le même réseau local d’usine est jointe directement, tandis qu’une appliance hébergée de façon centralisée peut n’être accessible que par le proxy d’entreprise. L’installateur ne peut pas les distinguer, il écrit donc les hôtes littéralement — retirez ceux qui ne s’appliquent pas à votre réseau.

Docker se configure séparément

Docker Desktop ne lit ni proxy.env ni l’environnement du service. Les images sont téléchargées par le démon Docker, qui dispose de ses propres réglages sous Settings → Resources → Proxies, y compris sa propre liste d’exclusions — laquelle a elle aussi besoin de l’hôte de l’appliance. Un proxy corrigé côté agent ne répare pas docker pull.

Appareils Linux

ironflock agent install accepte --no-proxy directement ; l’appliance peut donc être nommée dès l’installation :


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

localhost, 127.0.0.1 et ::1 contournent toujours le proxy. Le serveur de mise à jour nommé dans le fichier .flock de l’appareil le contourne aussi lorsqu’il n’est pas un hôte du cloud IronFlock, ce qui est le cas pour les appareils d’une appliance.

Les réglages sont conservés dans /etc/ironflock/proxy.env, que seul root peut lire. Docker et l’agent de l’appareil les y prennent tous les deux. Pour les ajuster ensuite, utilisez ironflock agent configure. Chaque option que vous donnez remplace son réglage, et les autres restent inchangés :


# Modifier les hôtes qui contournent le proxy
sudo ironflock agent configure --no-proxy "appliance.corp.example.com,buildserver.corp.example"
 
# Passer à un autre proxy
sudo ironflock agent configure --https-proxy "http://proxy2.your-company.com:3128"
 
# Retirer l'appareil du proxy
sudo ironflock agent configure --remove-proxy

La commande affiche les réglages avant et après la modification. Docker doit redémarrer pour les appliquer, ce qui arrête un instant les apps de l’appareil ; la commande pose donc d’abord la question. Une variable de proxy dans un drop-in systemd que vous avez créé vous-même (systemctl edit) ne prend plus effet dès que le fichier de réglages définit la même variable ; la commande vous avertit de la présence d’un tel drop-in. Voir ironflock agent configure pour les détails.

Les appareils configurés avant ironflock conservent leur proxy dans un drop-in systemd nommé http-proxy.conf, où chaque utilisateur de l’appareil peut le lire, mot de passe compris. La première exécution de ironflock agent configure déplace les réglages dans /etc/ironflock/proxy.env.

Sur les appareils installés avant octobre 2026, l’unité s’appelle encore reagent.service (avec le répertoire de drop-ins reagent.service.d) jusqu’à ce que l’agent ait déplacé l’appareil vers la nouvelle disposition.

Proxys interceptant le TLS (CA d’entreprise)

De nombreux proxys d’entreprise inspectent le trafic HTTPS en le re-signant avec une autorité de certification (CA) de l’entreprise. Pour ceux-ci, configurer le proxy est nécessaire mais pas suffisant — l’hôte de l’appliance doit également faire confiance à cette CA, sinon chaque connexion vers le cloud (récupération des images, validation de la licence, uplink de gestion) est rejetée.

Il s’agit ici de la confiance de l’appliance envers votre CA — et non de servir du HTTPS aux navigateurs. Vous faites en sorte que les connexions sortantes de l’appliance vers le cloud aboutissent à travers un proxy qui intercepte le TLS. Servir les interfaces web des applications aux navigateurs de votre réseau est la direction opposée — voir Interfaces d’applications et HTTPS.

Installez la CA une seule fois, dans le magasin de confiance du système de l’hôte. L’appliance monte ce magasin de confiance dans tous ses conteneurs, de sorte que Docker et chaque service IronFlock prennent en compte la CA — il n’y a rien à configurer par conteneur ou par service. Comme les conteneurs la lisent au démarrage, redémarrez la stack après avoir ajouté ou modifié la CA (étape 3 ci-dessous).

1. Obtenir la CA d’entreprise

Demandez à votre équipe réseau la CA racine d’« inspection SSL » / d’« interception TLS » du proxy — le même certificat déjà déployé sur les machines d’entreprise gérées — sous forme de fichier .crt. C’est la source la plus propre.

Installez la CA émettrice, pas le certificat d’un seul hôte. L’erreur courante est d’enregistrer le certificat re-signé par le proxy pour un nom d’hôte (par exemple uniquement instance-registry.ironflock.com). Cela ne fait fonctionner que cet hôte et laisse échouer tous les autres hôtes du cloud. Vous avez besoin de la CA qui signe ces certificats.

Si vous ne pouvez pas obtenir le fichier directement mais que le proxy présente sa chaîne complète, vous pouvez extraire la CA depuis le réseau — remplacez <PROXY_HOST>:<PROXY_PORT> par votre proxy :


# Capture la chaîne, un PEM par certificat. c1 est la feuille propre à l'hôte (à ignorer) ;
# c2..cN sont la chaîne de CA d'entreprise à approuver.
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}'
 
# Facultatif — inspectez ce qui est revenu :
for f in /tmp/proxy-c*.pem; do echo "== $f =="; openssl x509 -in "$f" -noout -subject -issuer; done

2. L’installer et reconstruire le magasin de confiance

Si votre équipe IT vous a fourni le .crt directement :


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

Si vous l’avez extrait de la chaîne ci-dessus, approuvez chaque certificat sauf la feuille (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. Vérifier

Chaque hôte du cloud IronFlock doit désormais se valider à travers le proxy — un statut HTTP, et non une erreur 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

Un code comme 200, 401 ou 404 pour les cinq signifie que la CA est correcte. Redémarrez ensuite l’appliance pour que les services la prennent en compte. Si l’installation s’était arrêtée à l’étape de connexion, exécutez plutôt à nouveau la même commande d’installation : elle reprend là où elle s’est arrêtée.


sudo ironflock appliance restart

Accès à distance aux interfaces utilisateur des appareils

IronFlock vous permet d’ouvrir une interface utilisateur qui s’exécute sur un appareil ou une machine edge — un IHM de machine, une page d’automate (PLC), un écran de configuration ou de tableau de bord embarqué — directement dans IronFlock, depuis n’importe où. C’est un facilitateur clé pour le service et le support à distance : un technicien peut atteindre l’interface d’une machine sans être sur site ni sur le réseau local. L’accès est toujours médiatisé et protégé par le système de privilèges IronFlock, de sorte que seuls les utilisateurs autorisés atteignent un appareil donné.

Ce tunnel d’accès à distance repose sur frp (Fast Reverse Proxy), une technologie open source mature et largement utilisée. IronFlock l’utilise uniquement pour fournir l’accès aux interfaces des appareils décrit ci-dessus.

Pourquoi un proxy d’entreprise peut faire obstacle

frp possède de puissantes capacités de traversée de réseau, et pour cette raison les produits de sécurité antivirus et proxy le signalent souvent de façon générique comme logiciel à risque (riskware) — même si, en tant que composant open source ayant fait ses preuves, il est sûr et n’est utilisé ici que pour la fonction d’accès à distance autorisée. Lorsque cela se produit, le proxy bloque le téléchargement du composant IronFlock qui contient frp.

Cela ne casse pas votre appliance : le tunnel d’accès à distance est une fonction optionnelle, donc si ce composant est bloqué, la plateforme s’installe et fonctionne normalement et opère simplement sans accès aux interfaces des appareils. Dans le tableau de bord, les commandes d’accès à distance d’un appareil indiquent alors que l’accès à distance n’est pas disponible sur cette appliance.

Ce que le service informatique de l’entreprise doit autoriser

Si votre organisation souhaite bénéficier des fonctions de service à distance d’IronFlock, le composant IronFlock contenant frp doit être autorisé à se télécharger à travers le proxy d’entreprise. Demandez à votre équipe réseau/sécurité deux choses précises :

Une exception d’analyse pour les téléchargements d’images depuis instance-registry.ironflock.com, afin que le verdict générique de logiciel à risque (riskware) ne bloque pas le composant du tunnel. C’est plus ciblé que d’exclure tout le trafic IronFlock de l’inspection TLS — le reste du trafic de l’appliance peut continuer d’être inspecté.
L’enregistrement de la détection comme faux positif connu. frp est un reverse proxy open source largement utilisé ; IronFlock l’utilise uniquement pour la fonction d’accès à distance décrite ci-dessus, soumise à un contrôle d’accès.

Les mêmes points de terminaison IronFlock déjà listés pour l’appliance s’appliquent — voir Configuration du pare-feu ; il s’agit ici de ne pas analyser/bloquer ce trafic, en plus de simplement l’acheminer.

Une fois frp autorisé à passer, la mise à jour suivante retente le téléchargement, et la fonction s’active dès qu’il aboutit, sans aucun autre changement. Pour essayer tout de suite, exécutez à nouveau l’installation avec la version qu’exécute l’appliance (ironflock status l’affiche) ; elle conserve les secrets et les paramètres de l’appliance :


sudo ironflock appliance install --version <version>

Fonctionner sans accès à distance

Si vous n’avez pas besoin de l’accès aux interfaces des appareils — ou si vous voulez une installation propre pendant que l’exception du proxy est mise en place — vous pouvez désactiver le tunnel explicitement. Tout le reste s’installe normalement :


# au moment de l'installation
sudo ironflock appliance install --license-file license.txt --no-tunnel
 
# ou sur une appliance déjà installée
sudo ironflock appliance configure --no-tunnel

Ce choix est mémorisé d’une mise à jour à l’autre. Réactivez-le plus tard (une fois frp autorisé) avec --tunnel :


sudo ironflock appliance configure --tunnel

Dépannage

L’installation s’arrête à la connexion à instance-registry.ironflock.com avec une erreur Client.Timeout. Le démon Docker ne peut pas atteindre le registre. Exécutez à nouveau ironflock appliance install et passez votre proxy avec --http-proxy / --https-proxy, comme montré ci-dessus.

La connexion échoue toujours après avoir configuré le proxy. Votre proxy intercepte très probablement le TLS. Installez la CA d’entreprise comme décrit dans Proxys interceptant le TLS, puis exécutez à nouveau la commande d’installation.

Vérifiez que le démon Docker voit le proxy :


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

docker info affiche le proxy qu’utilise Docker, avec un mot de passe masqué. Si docker login réussit de lui-même, l’installation de l’appliance dépassera l’étape défaillante.

Un seul composant échoue au téléchargement alors que tout le reste s’installe correctement. Il s’agit généralement du composant d’accès à distance basé sur frp qui est bloqué par votre proxy ou votre antivirus en tant que logiciel à risque (riskware). L’installation se termine tout de même — seul l’accès aux interfaces des appareils est indisponible. Pour l’activer, demandez à votre équipe proxy d’autoriser ce trafic comme décrit dans Accès à distance aux interfaces utilisateur des appareils, puis exécutez sudo ironflock appliance install --version <version> avec la version qu’exécute l’appliance. Pour installer délibérément sans lui, passez --no-tunnel.

Mises à jour

Une fois qu’une appliance est installée derrière un proxy, ses paramètres de proxy sont mémorisés dans /opt/ironflock/.env et réappliqués à chaque mise à jour. Les mises à jour depuis l’interface de l’appliance et avec ironflock appliance update continuent de fonctionner à travers le proxy sans action supplémentaire — voir Maintenance dans le guide Appliance. Pour faire pointer l’appliance vers un autre proxy — ou la retirer complètement du proxy — voir Modifier ou supprimer le proxy ultérieurement.

Si l’accès à distance aux interfaces des appareils a été bloqué au moment de l’installation, chaque mise à jour le réessaie automatiquement — ainsi, dès que votre proxy autorise frp, la prochaine mise à jour active la fonction sans aucune étape supplémentaire.