Il existe un serveur utilisé en commun par plusieurs dizaines de personnes.
Chacun y sert son projet dans un conteneur.
Quand un problème survient, comme un redémarrage du serveur, il est difficile pour l’administrateur de savoir comment réagir pour gérer ces conteneurs.
Faut-il demander à chacun de fournir à l’avance la commande d’exécution de son conteneur Docker, puis les relancer une par une ?
Ou bien faut-il tout configurer avec Docker Compose, puis entrer dans le dossier de chaque projet pour faire un compose up ?
Je souhaiterais avoir des conseils, du point de vue d’un administrateur, sur la manière de gérer plusieurs conteneurs.
9 commentaires
Merci à toutes celles et ceux qui ont répondu. Je crois que l’objectif de cette année devra être l’adoption de Kubernetes.
Le plus simple est de daemoniser les conteneurs pour qu’ils démarrent aussi au lancement de l’OS.
Si vous êtes sur une distribution de la famille EL (Enterprise Linux, terme générique pour la lignée RHEL), vous pouvez enregistrer les conteneurs comme services systemd. Cela s’appelle Quadlet.
À voir uniquement la question, on dirait que ça peut se résoudre avec
depend on,restart alwaysouunless stoped, mais j’imagine qu’il y a des situations compliquées non mentionnées dans la question. Cela dit, si on parle de quelques dizaines de personnes, vous finirez sans doute par devoir passer à Kubernetes.En posant simplement la question telle quelle à une IA, vous devriez aussi pouvoir trouver la réponse.
Si vous donnez ces éléments, il sera plus facile d’en discuter.
Pour vous répondre simplement sur la base de ce que vous avez dit...
Je ne vois pas pourquoi une commande d’exécution de conteneur serait nécessaire. Demandez qu’on vous crée un fichier Compose, puis configurez les choses pour que tout puisse être lancé avec la même commande (la commande Compose).
:) Puisque vous êtes administrateur, demandez qu’on vous mette ça en place ; les autres le feront, alors imposez-le :)
Je recommande peu k8s, car je trouve que c’est une solution assez lourde dans un environnement géré seul.
Je pense qu’il est toujours préférable de garder une infrastructure la plus simple possible.
Il y a 4 serveurs on-premise.
Je gère ça seul.
Docker a été introduit dans l’entreprise il y a maintenant 4 mois après validation sécurité, et je ne connais que les concepts de k8s. Je vais bientôt devoir mettre en place HARBOR pour Docker, et une fois Harbor déployé, Docker Hub sera bloqué. Il est probable que je sois le seul à garder l’accès à Docker Hub et que, lorsqu’il y aura des demandes, je sois le seul à récupérer les images depuis Docker Hub pour les publier sur le Harbor interne de l’entreprise.
Je n’ai pas voulu forcer la gestion avec des commandes Compose ni aller dans les dossiers de chaque projet pour lancer manuellement
compose up, car cela me semblait irréaliste. À la place, j’ai demandé à utiliser des commandes Docker avec des chemins absolus, mais ces derniers temps, je n’arrive pas à me défaire de l’idée que c’était une mauvaise approche.Ne suffit-il pas d’ajouter une option de redémarrage à Docker ?
Dans ce cas, mieux vaut utiliser Kubernetes et attribuer un contexte à chaque utilisateur.
Il est aussi possible de limiter les autorisations afin que chaque utilisateur ne puisse utiliser que le contexte qui lui est attribué.
On utilise k8s.
Je pense aussi un peu comme tujuc : introduire k8s seul, sans personne expérimentée, puis l’exploiter de façon stable sans incident me semble comporter pas mal de risques.
Cela dit, vous dites que 4 serveurs sont utilisés en commun par plusieurs dizaines de personnes, donc le cas est un peu ambigu,
mais plutôt que de raisonner en fonction du nombre de personnes concernées, si la quantité de programmes serveur est vraiment trop importante et la situation trop complexe, alors cela peut valoir le coup d’envisager d’apprendre k8s.
Si j’étais dans la même situation que l’auteur, j’aurais sans doute amélioré l’environnement par étapes, comme ci-dessous.