Ça t'arrive tellement souvent que le rapatrier, ça prend trop de temps ?
Ben il n'y a pas que le temps qui rentre en compte. Parfois il y a aussi l'environnement qui est hostile (réseaux séparés nécessitant de passer par des machines de rebond plus ou moins sécurisées par exemple, qui rendent les transferts de fichier difficiles).
Parce que lire le fichier c'est bien,
Ben quand tu sais ce que tu cherches dans un fichier de conf qui n'ajoute pas de bruit, ça se fait plutôt bien.
le comparer avec n'importe quel autre version de ton gestionnaire de conf c'est encore mieux...
Pas toujours possible. On parle d'infra as code, avec des confs calculés, et qui peuvent se vautrer lorsqu'on se trouve dans un cas pas prévu ou mal spécifié dans la demande initiale. Exemple: combinaisons d'installation via déroulement de playbooks/roles ansible qui n'ont pas été prévus pour fonctionner ensemble, et peuvent se marcher l'un sur l'autre et produire des confs étranges dans un cas qui n'a pas été identifié. Difficile (mais pas impossible) de voir ce qui se passe dans le gestionnaire de conf. Si tu peux te baser sur la conf générée par ton outil, ça peut donner des pistes de recherche.
Tu va installer tout ça sur ta prod ?
Tout dépend de la criticité de la prod et des contraintes autour. parfois on va décider de revenir en arrière, corriger le problème, tester et redéployer ultérieurement. Parfois on va modifier direct la prod et ouvrir un ticket d'incident pour corriger le problème. Tout dépend de ce que ça coûte dans chacun des cas. Juste modifier un playbook ou un role + redéployer n'est pas toujours envisageable car les playbooks/roles peuvent être utilisés par ailleurs, et modifier pour le cas spécifique du bug peut en entrainer d'autres pour d'autres déploiements.
La meilleure méthode reste toujours de corriger à la source, mais parfois c'est long à implémenter/tester donc en attendant la correction à la source et l'automatisation, on utilise un workaround directement en prod.
Parce qu'il est déjà arrivé d'avoir un défaut et que tu as eu la flemme de le rapatrier ?
De mémoire non. De toute façon, que l'on corrige ou pas en direct sur la prod, il faut que le problème soit corrigé et que nos tests soient mis à jour pour éviter les régressions.
Parce que si je modifie la prod, je m'assure que ce soit tracé pour que le correctif soit apporté (et pour tout dire, en ce moment c pas moi qui modifie la prod, je suis plutôt chargé de créer les playbooks de déploiement et de les corriger en cas de problème). Et quand j'ai un bug à corriger, je dois passer par un cycle de développement/test/livraison qui peut parfois prendre plus de temps qu'une correction en live.
Mais c'est bizarre d'avoir les livrables qu'en prod
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par totof2000 . En réponse à la dépêche Linux capabilities : se passer des commandes su et sudo. Évalué à 2. Dernière modification le 28 septembre 2018 à 18:00.
Ben il n'y a pas que le temps qui rentre en compte. Parfois il y a aussi l'environnement qui est hostile (réseaux séparés nécessitant de passer par des machines de rebond plus ou moins sécurisées par exemple, qui rendent les transferts de fichier difficiles).
Pas toujours possible. On parle d'infra as code, avec des confs calculés, et qui peuvent se vautrer lorsqu'on se trouve dans un cas pas prévu ou mal spécifié dans la demande initiale. Exemple: combinaisons d'installation via déroulement de playbooks/roles ansible qui n'ont pas été prévus pour fonctionner ensemble, et peuvent se marcher l'un sur l'autre et produire des confs étranges dans un cas qui n'a pas été identifié. Difficile (mais pas impossible) de voir ce qui se passe dans le gestionnaire de conf. Si tu peux te baser sur la conf générée par ton outil, ça peut donner des pistes de recherche.
Tout dépend de la criticité de la prod et des contraintes autour. parfois on va décider de revenir en arrière, corriger le problème, tester et redéployer ultérieurement. Parfois on va modifier direct la prod et ouvrir un ticket d'incident pour corriger le problème. Tout dépend de ce que ça coûte dans chacun des cas. Juste modifier un playbook ou un role + redéployer n'est pas toujours envisageable car les playbooks/roles peuvent être utilisés par ailleurs, et modifier pour le cas spécifique du bug peut en entrainer d'autres pour d'autres déploiements.
La meilleure méthode reste toujours de corriger à la source, mais parfois c'est long à implémenter/tester donc en attendant la correction à la source et l'automatisation, on utilise un workaround directement en prod.
De mémoire non. De toute façon, que l'on corrige ou pas en direct sur la prod, il faut que le problème soit corrigé et que nos tests soient mis à jour pour éviter les régressions.
Parce que si je modifie la prod, je m'assure que ce soit tracé pour que le correctif soit apporté (et pour tout dire, en ce moment c pas moi qui modifie la prod, je suis plutôt chargé de créer les playbooks de déploiement et de les corriger en cas de problème). Et quand j'ai un bug à corriger, je dois passer par un cycle de développement/test/livraison qui peut parfois prendre plus de temps qu'une correction en live.
Pas si bizarre que ça. Parce que