Gestion 1Panel

Gestion 1Panel : quand le proxy OpenResty casse Milvus

Non classé

Retour d'expérience PerlAvancé

Gestion 1Panel : quand le proxy OpenResty casse Milvus

Le conteneur Milvus est passé en état ‘unhealthy’ à 3h14 du matin, alors que la Gestion 1Panel affichait pourtant un état ‘Running’ pour tous les services dépendants.

L’infrastructure reposait sur un VPS Debian 12, Docker 24.0.7 et 1Panel v1.10. Le déploiement de Milvus, une base de données vectorielle exigeante, nécessite une communication fluide entre ses composants (Etcd, MinIO, Pulsar), ce qui est compromis par une configuration de proxy mal maîtrisée.

Après avoir analysé les logs de routage, vous saurez identifier les conflits entre le reverse proxy intégré de 1Panel et les réseaux Docker internes, et comment isoler vos flux critiques.

Gestion 1Panel

🛠️ Prérequis

Pour reproduire ou analyser cet environnement, vous avez besoin de :

  • Un serveur Linux (Debian 12 ou Ubuntu 22.04 LTS).
  • 1Panel installé en version 1.10 ou supérieure.
  • Docker version 24.0.7 minimum.
  • Accès SSH avec privilèges sudo.
  • Un client Perl avec les modules LWP::UserAgent et JSON installés via CPAN.

📚 Comprendre Gestion 1Panel

La Gestion 1Panel repose sur une architecture de contrôle de conteneurs via l’API Docker. Contrairement à une installation Docker Compose classique, 1Panel injecte une couche de reverse proxy (OpenResty) pour exposer les services web.

Le schéma de flux standard est le suivant :
Client HTTP -> Port 80/443 (Host) -> OpenResty (Container) -> Proxy Pass -> Service Target (Container).

Le problème survient quand le trafic inter-conteneurs (ex: Milvus vers Etcd) tente de sortir de l’interface réseau Docker pour repasser par l’IP publique ou le proxy OpenResty. En Perl, on peut comparer cela à une variable globale qui serait réécrite par une subroutine sans scope local, corrompant l’état de tout le programme.

🐪 Le code — Gestion 1Panel

Perl
use strict;
use warnings;
use LWP::UserAgent;
use JSON;

# Vérification de l'état d'un service via l'API 1Panel
my $api_url = 'http://localhost:8888/api/v1/container/list';
my $token = 'votre_token_api_ici';

my $ua = LWP::UserAgent->new;
$ua->timeout(10);

my $response = $ua->get($api_url, 'token=' . $token);

if ($response->is_success) {
    my $data = decode_json($response->decoded_content);
    # Parcours des conteneurs pour trouver Milvus
    foreach my $container (@{$data->{data}}) {
        if ($container->{name} =~ /milvus/) {
            print "Statut de $container->{name} : $container->{status}\n";
        }
    }
} else {
    die "Erreur lors de l'appel API : $response->status_line\n";
}

📖 Explication

Dans le premier script, l’utilisation de LWP::UserAgent est cruciale car elle gère nativement les redirections et les timeouts, évitant que le script de monitoring ne bloque indéfiniment si l’API 1Panel est indisponible. Le décodage JSON avec decode_json est effectué sur le contenu brut pour minimiser l’empreinte mémoire.

Dans le second script, l’utilisation d’une expression régulière /connection refused|timeout|upstream timed out/i permet de filtrer les messages d’erreur critiques sans surcharger le CPU. Le flag i assure que la casse (majuscules/minuscules) n’empêche pas la détection du bug.

Un piège classique dans le premier script est l’oubli du use strict;. Sans cela, une faute de frappe sur la variable $token pourrait masquer une erreur de logique grave, une habitude que l’on doit bannir, même en script rapide.

Documentation officielle Perl

🔄 Second exemple

Perl
use strict;
use warnings;

# Analyse rapide des logs Docker pour détecter des erreurs de connexion
my $log_file = '/var/lib/docker/containers/milvus_error.log';

open(my $fh, '<', $log_file) or die "Impossible d'ouvrir le log : $!";

while (my $line = <$fh>) {
    # Recherche de patterns d'échec de connexion réseau
    if ($line =~ /connection refused|timeout|upstream timed out/i) {
        print "[ALERTE] Erreur détectée : $line";
    }
}
close($fh);

Retour d'expérience

L’incident a débuté par une dégradation des performances de recherche vectorielle. Les requêtes vers l’API Milvus sur le port 19530 renvoyaient des erreurs 504 Gateway Timeout. Pourtant, l’interface de Gestion 1Panel indiquait que le conteneつつ Milvus était parfaitement opérationnel.

L’investigation a commencé par un simple docker exec dans le conteneur Milvus pour tenter un ping vers le conteneur Etcd. Le ping réussissait, mais la connexion sur le port 2379 échouait systématiquement. Le problème n’était pas la couche application, mais la couche transport.

En examinant la configuration d’OpenResty générée par 1Panel, j’ai découvert que le plugin de gestion des sites web tentait de rediriger tout le trafic entrant sur les ports définis dans le dashboard vers le proxy interne. En voulant rendre Milvus accessible de l’extérieur, 1Panel avait créé une règle proxy_pass qui interceptait les appels inter-conteneurs si ceux-ci passaient par l’IP du bridge Docker par défaut.

Le piège était subtil : la règle iptables créée par 1Panel pour sécuriser l’accès au panel priorisait le routage via l’interface OpenResty. Pour Milvus, dont les composants communiquent via des adresses IP internes, cela créait une boucle de routage ou un saut inutile vers le proxy, augmentant la latence jusqu’à l’expiration du timeout.

La résolution a nécessité de sortir de l’interface graphique de Gestion 1Panel. J’ai dû modifier manuellement le fichier docker-compose.yml de l’application pour déclarer un réseau Docker ‘bridge’ personnalisé, totalement indépendant du réseau géré par le proxy OpenResty de 1Panel. En isolant les composants Milvus dans un réseau milvus_net sans passer par l’IP du gateway 1Panel, la communication est redevenue directe et performante.

▶️ Exemple d’utilisation

Exécution du script de vérification de statut :

perl check_1panel_service.pl

Sortie attendue :

Statut de milvus-standalone : running
Statut de milvus-etcd : running
Statut de milvus-minio : running

🚀 Cas d’usage avancés

1. **Automatisation de la surveillance** : Utiliser le script Perl en tâche cron pour notifier un canal Slack dès qu’un conteneur Milvus change de statut via l’API de Gestion 1Panel.
2. **Audit de configuration** : Créer un script qui compare les règles iptables actives avec la configuration théorique de 1Panel pour détecter des injections de règles non désirées.
3. **Backup intelligent** : Script Perl qui déclenche un snapshot ZFS du volume Docker uniquement lorsque la Gestion 1Panel confirme que l’écriture dans le conteneur MinIO est terminée.

🐛 Erreurs courantes

⚠️ Conflit de port Docker

Tentative de mapper le port 19530 sur l’hôte alors que 1Panel l’utilise déjà pour un autre service.

✗ Mauvais

ports: ['19530:19530']
✓ Correct

ports: ['19531:19530']

⚠️ Mauvais réseau Docker

Utilisation du réseau ‘bridge’ par défaut qui intercepte le trafic par le proxy.

✗ Mauvais

network_mode: bridge
✓ Correct

networks: [milvus_isolated_net]

⚠️ Token API expiré

Utilisation d’un token statique dans un script sans gestion de renouvellement.

✗ Mauvais

my $token = 'old_token';
✓ Correct

my $token = get_fresh_token_from_1panel();

⚠️ Regex trop permissive

Rechercher ‘error’ dans les logs sans distinction de contexte.

✗ Mauvais

/error/i
✓ Correct

/error: connection refused/i

✅ Bonnes pratiques

Pour une gestion saine de vos services sous 1Panel, respectez ces principes :

  • Isolation réseau : Ne laissez jamais vos bases de données critiques (Milvus, PostgreSQL) sur le même réseau que votre reverse proxy public.
  • Principe de moindre privilège : Utilisez des tokens API avec des permissions restreintes à la lecture seule pour vos scripts de monitoring.
  • Idempotence : Vos scripts de configuration doivent pouvoir être lancés plusieurs fois sans altérer l’état existant.
  • Logging structuré : Privilégiez les logs au format JSON si possible pour faciliter le parsing via Perl ou Python.
  • Gestion des dépendances : Utilisez un fichier cpanfile pour vos scripts de maintenance afin de garantir la reproductibilité de l’environnement.
Points clés

  • L'interface 1Panel peut masquer des échecs de services via son propre proxy.
  • Le routage inter-conteneurs doit être isolé du réseau OpenResty.
  • L'utilisation de réseaux Docker personnalisés résout les conflits de proxy.
  • Le monitoring via l'API 1Panel est plus fiable que le simple check de processus.
  • Les erreurs 504 indiquent souvent un problème de couche transport (proxy) et non applicative.
  • Perl reste l'outil de choix pour parser les logs complexes avec Regex.
  • Vérifiez toujours les règles iptables lors de l'ajout de nouveaux services.
  • L'automatisation doit inclure une gestion robuste des timeouts.

❓ Questions fréquentes

Est-ce que 1Panel est sûr pour de la production ?

Oui, si vous configurez des réseaux Docker isolés pour vos bases de données et que vous ne passez pas par le proxy global pour le trafic interne.

Comment diagnostiquer un timeout 504 sur 1Panel ?

Vérifiez d’abord les logs d’OpenResty, puis testez la connectivité directe entre les conteneurs via un conteneur de test (ex: alpine/curl).

Peut-on utiliser Perl pour automatiser 1Panel ?

Absolument. L’API REST de 1Panel est compatible avec n’importe quel langage capable de faire des requêtes HTTP et de parser du JSON.

Pourquoi Milvus est-il si sensible au réseau ?

Milvus dépend de la latence très faible entre ses composants (Etcd, Pulsar). Un saut supplémentaire via un proxy casse les protocoles de consensus.

📚 Sur le même blog

🔗 Le même sujet sur nos autres blogs

📝 Conclusion

La Gestion 1Panel est un outil efficace pour simplifier le déploiement, mais son automatisation du proxy peut devenir un obstacle pour les architectures distribuées comme Milvus. L’astuce consiste à ne pas chercher à tout faire passer par le dashboard, mais à utiliser 1Panel comme orchestrateur et non comme routeur unique. Pour approfondir la gestion des processus et des flux, la documentation Perl officielle reste une ressource indispensable pour maîtriser le parsing de logs complexes. Un administre système ne doit jamais faire confiance aveuglément au statut ‘Running’ d’un dashboard.

Une réflexion sur « Gestion 1Panel : quand le proxy OpenResty casse Milvus »

  1. Ping : plateforme RAG open-source : transformer vos documents en base de données - Perlia, du Perl

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *