Que se passe t’il en ce moment dans le monde du #DevOps ou du #Cloud ?
Actus DevOps est une nouvelle émission que l’on vous propose.
@cchaudier est avec avec @thomas @erwan et @bpetit
N’hésite pas à réagir à ces nouvelles et à donner ton point de vue en commentaire.
Portainer ça peut servir à l’ensemble des équipes qui ne font pas du gitops tout simplement.
Nous on utilise Rancher parce que nous avons plusieurs clusters kubernetes et que Rancher apporte certaines fonctionnalités comme l’authentication proxy.
Openshift je n’aime pas trop car il impose une approche particulière, d’ailleurs je déteste l’idée du S2I.
Concernant les attaques par chiffrement, il est à mon sens très important que l’export des backups se fasse de l’environnement distant vers l’environnement local histoire de ne pas laisser la possibilité aux attaquants d’accéder à l’espace distance de sauvegarde.
Yep, j’ai bien compris pour Portainer. J’explique juste que j’aime plutôt voir le problème autrement. En général déjà dans les contextes dans lesquels je travaille c’est full IaC / API (exemple les créations sur la console sont désactivées), pour des raisons de tracabilité / sécurité et pour forcer à passer par la forge.
Si jamais il manque de vision sur une metric ou un objets j’essaye aux maximums de l’ajouter ou de le faire ajouter dans la stack d’observabilité. Comme ça si jamais on a un soucis en prod on a les métrics nécessaires (même si c’est dans un dashboard totalement isollé. Le jour d’un incident en prod je veux que le dev qui n’a jamais été sur la prod puisse s’en sortir.
Après Rancher & OpenShift j’ai jamais trop touché, je sais que chez un de mes clients ils étaient tellement fan d’Openshift qu’ils l’ont installé sur AWS 
Oui et d’avoir des sauvegardes hors ligne en général, même si c’est des sauvegardes avec des données moins récentes. Ca permets de pas tout perdre dans ce type de situation.
Oui on est tout à fait d’accord pour l’approche IaC. On gère aussi notre infra comme ça, on n’effectue aucune modification à la main.
Par contre, on a laissé les accès aux dev au dashboard de Rancher car parfois ils font du debug et des tests mais au final je le regrette car cela génère des inconsistances entre les environnements et il n’y a pas de documentation des modifications. C’est pour cette raison que nous sommes entrain de tester une approche GitOps pour les déploiements sur Kubernetes à l’aide de ArgoCD.
Pour finir, Rancher n’est pas totalement comparable à Portainer, car Rancher est plus qu’un simple dashboard, c’est une distribution Kubernetes qui intègre un outil de déploiement de cluster k8s, le monitoring (basé sur Prometheus), l’export de logs (basé sur fluentd), …etc.