Dans un contexte de container je suis un peu circonspect. Le container est immuable donc ouvrir un shell dessus ne devrait pas être d'une grande utilité, tu as évidement l'accès aux logs qui peut être utile mais ça ne demande pas d'ouvrir un shell. Si tu veux manipuler la configuration, je dirais que de la même manière ça pourrait être fait à distance via un protocole ad-hoc.
Personnellement pour y arriver je tenterais de ne plus accéder en SSH à vos environnements de dev/QA pour vérifier ce qui peut vous manquer ou non comme info et donc appliquer les même procédures que chez vos clients en interne.
Si par contre l'idée c'est d'accéder à l'hôte, depuis un container ça ne marche pas très bien pour vos setop box je dirais que vous pouvez faire une communication entre le container et la machine hôte pour l'activer (ou simplement ouvrir le port).
[^] # Re: Conseil
Posté par barmic 🦦 . En réponse au journal La galère de Python en déploiement. Évalué à 2.
Dans un contexte de container je suis un peu circonspect. Le container est immuable donc ouvrir un shell dessus ne devrait pas être d'une grande utilité, tu as évidement l'accès aux logs qui peut être utile mais ça ne demande pas d'ouvrir un shell. Si tu veux manipuler la configuration, je dirais que de la même manière ça pourrait être fait à distance via un protocole ad-hoc.
Personnellement pour y arriver je tenterais de ne plus accéder en SSH à vos environnements de dev/QA pour vérifier ce qui peut vous manquer ou non comme info et donc appliquer les même procédures que chez vos clients en interne.
Si par contre l'idée c'est d'accéder à l'hôte, depuis un container ça ne marche pas très bien pour vos setop box je dirais que vous pouvez faire une communication entre le container et la machine hôte pour l'activer (ou simplement ouvrir le port).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll