Reprise du message précédent :
Un argument peut être simplement la connaissance des équipements Cisco ?Il y a un petit apprentissage à refaire ? Le temps à se reformer ça se calcule aussi. Je ne connais pas les Dell donc c'est peut être pas valable comme arguments.
Effectivement le nouveau système de licence chez Cisco est abusé mais c'est pour limiter le marché gris de certains fournisseurs qui achetaient en gros pour un client, et qui revendait à d'autres les quantités restantes.

Je cherche une solution pour simplifier l'administration d'un parc de serveurs linux (essentiellement du debian).
 
Jadis, on avait cinq serveurs qui se battaient en duel et debian qui sortait une demi release tous les 5 ans. Maintenant, on doit avoir pas loin d'une cinquantaine de vm et debian sort une release tous les deux ans. Je crains un peu pour le futur et j'ai pas envie d'avoir un admin qui se tape les maj à la papa.
 
On a plutôt une architecture monoservice: cad. un OS => un service. On a un peu tous les services de base qu'on peut imaginer: serveurs dns, dhcp, http, proxies, smtp, ftp, ntp, smb, bdd, etc. Parfois on a mutualisé, typiquement sur les bdd ou les serveurs http, ce qui nous pose évidemment des problèmes de gestion de version.
 
On n'a pas de problématique de charge. Le but est plutôt de gagner en simplicité et lisibilité, et de décorréler ces services des OS qui les hébergent.
 
Bref, j'aurais bien containerisé tout ça à coup de docker. Sur le papier ça a pas l'air bien compliqué d'écrire des dockerfile et de monter les fichiers/répertoires qui vont bien puis de recréer les images à intervalle régulier histoire de tenir les soft à jour. Après j'ai lu des retours pas extraordinaires (mais qui ont quelques années pour la plupart).  
 
Est-ce que vous avez ce genre de solution dans votre cogip ? Et sinon comment vous gérez ça ?

Perso j'utiliserai un truc genre Salt ou Ansible avec tes fichiers de recettes dans Git. C'est plutôt propre, et ça peut très bien aller.
 
Par toi-même, en écrivant les recettes, tu vas déjà pas mal factoriser ton « parc ». Ensuite si tu veux aller plus loin, tu peux utiliser Terraform, mais m'est d'avis q'un Ansible déjà bien écrit ça irait

C'est déjà ce qu'on utilise pour pousser des modifs de base. En gros on a un template historique avec la conf de base qui nous va bien, on le clone, on installe les paquets qu'il nous faut et on l'enregistre sous salt. On utilise ansible pour d'autres choses mais pas encore pour faire des setups de serveurs linux.
 
J'y ai pensé aussi mais disons que ça me défrise un peu d'avoir à faire tourner et maintenir toute une vm pour un pauvre serveur ntp ou un bind. Et là, on fait ça x50 et demain ce sera x100. En gros j'aurais voulu me débarrasser des OS (mais c'est peut-être utopique ou un peu con comme idée).

 
 
ansible, salt, puppet
 
ansible plus facile de prise en main.
puppet plus compliqué mais plus balèze.
salt jamais pratiqué mais je le met au même niveau que puppet.

Serverless dans le cloud

Nous on est sur K8s avec du coreos, ça réponds à tous tes problèmes par contre faut monter en compétences

merci, je vais regarder ça (j'ai survolé rapidement rkt). Vous utilisez quels types de containers ?

Oui enfin faut avoir besoin de scalabilité si tu pars là dessus. Pour de la VM de service, ça me parait overkill.

Là visiblement ce qui chiffonne docmaboul c'est d'avoir une VM pour un DNS ou un NTP. M'enfin perso je trouve pas ça mauvais dans le sens où tu peux garder une bonne flexibilité sur ton infra physique avec ça (migrer à chaud tes services pour la maintenance etc.). Essayer de penser k8s avec ce genre de services, ça me parait vraiment chercher trop de complexité.

Après si c'est pour apprendre, c'est autre chose

A noter que tu peux aussi rassembler tes services dans certaines VMs (les VMs utilitaires par exemple) et réduire leur nombre. Bien séparer l'applicatif de chez vous avec le service (DNS, NTP etc. vs applis métiers).

Bref, des approches intermédiaires qui sont pas trop complexes et qui peuvent tout de même bien marcher jusqu'à quelques milliers de VMs. Au dessus, ou avec des besoins de scalabilité, en effet, k8s.

K8s ça ne gère pas que la scabilité !
Ça tourne très bien avec quelques noeuds, tu as de la résilience et surtout tu peux tout automatisé, la problématique de départ.
K8s c’est des API tout simplement avec une base etcd, tu peux y mettre des VMs tu es pas obligé de faire que du container docker, bien que ça doit être plus de 90% des usages.

Salut
C'est compliqué de proposer du Docker / K8s dans un service IT qui n'en a jamais fait ?

Tu conseille quoi pour débuter en douceur ?

Merci  

 
Dans mon ancienne boite j'étais chef de service technique donc c'est moi qui à poussé, c'était simple je prenais ce genre de décision.  
J'ai eu l'appui de ma direction car ça a répondu à plusieurs incidents.
Maintenant je suis dans une grosse cogip qui l'utilisait avant moi, je suis référent technique.  
 
Déjà il faut bien connaitre docker, et donc passer par du docker-compose avant de faire du K8s.
J'ai pas de réponse tout faire, ça va dépendre de la boite, les compétences du besoin, budget, etc...
 
Je préconise de faire du rancher2, openshift pour débuter surtout pour du on-premise.
Si l'objectif c'est le cloud, du GKE, EKS, etc..
 
Il faut mettre en avant la plus value de passer sur cette technologie par rapport à l'existant. Bien sur il faudra former des collaborateurs.  
Mais c'est pas toujours bien de le faire, le bénéfice sera peut être inférieur à l'énergie / budget employé.  
 
Avec k8s tu peux gérer finement les ressources alloués à chaque container et avec du recul réduire le budget hardware par exemple, mais il faut accepter de dépenser plus les premieres années.

Une formation

Conf management, automation & ci/cd
 
Puppet ou ansible/tower
Gitlab et ses runners
 
Mais en vrai tout dépend les ressources available et ce que vous avez prévu pour le futur.
 
Perso j'irais au plus simple (pour moi) : puppet (master, agent, bolt), gitlab/r10k (gestion des environnements)

Je te conseille de relire le message de Plam à ce sujet

 
ça veut dire quoi proposer ? et le service il est composé de qui / quoi ?
 

 
Conteneuriser pour conteneuriser ça ne sert à rien. Si t'as pas des applis et des archis designées pour ça, tu vas dans le mur.
Il te faut a minima un conf manager comme dit plus haut.
 
Ansible n'en est pas vraiment un, c'est plutôt un outil de provisioning. Il gère mal la MCO (notamment les updates systèmes) et il scale mal puisque basé sur le très lent ssh. Il faut le coupler à des solutions dégueulasses come Ansible tower / awx ou rundeck pour lui faire approcher des fonctionnalités d'un vrai conf manager. Maintenant entre de l'ansible et une gestion à la main comme en 1998, il vaut mieux encore ansible
Salt est le conf manager du moment. Beaucoup quittent puppet/chef pour aller chez eux. Il fait aussi de l'event-driven mais c'est techniquement bcp plus complexe que du conf management de base. Là dessus j'ai pas de clergé, faut tester ce qui existe et voir lequel vous parle le plus. Avec Salt tu pourras mettre sans problème ton parc à jour en toute transparence. Tu peux même le faire parler dans un slack ou équivalent, il pourra te dire quand il va mettre à jour, quand quelqu'un s'est connecté à une machine, si une machine a dérivé etc.

J'ai toujours kiffé Salt perso (utilisé chez nous depuis 2013)

Pour en dire plus sur ce que je peux voir dans le monde IT en m'y baladant pas mal : il faut séparer la hype de ses vrais besoins.

Par exemple, j'ai lu une phrase très pertinente d'un utilisateur sur nos forum il y a 1 mois : « Everyone wants high availability, but not everyone needs it ».

Ça marche encore plus avec une techno en particulier. Il faut surtout faire l'effort de savoir ce qui est recherché en terme d'objectifs IT. Puis regarder les risques. Et enfin choisir des solutions en fonction des objectifs/risques et bien entendu coût de mise en place (coût = temps et/ou argent, deux facettes d'une même pièce en entreprise).

À noter que je défend pas une paroisse, quand je vois des gens mettre en VMs des choses qu'ils devraient pas, ça me plaît pas non plus (nœud de storage par exemple).

Bref, plus on met en place des stacks compliquées, plus il faut que le bénéfice soit élevé, sinon le coût de maintenance est énorme (compétences, failover qui font n'importe quoi si pas documenté, besoin de procédures etc.)

J'ai vu des dizaines de clients/utilisateurs appeler au secours après avoir fait des infra avec de la redondance de partout sans que ça soit nécessaire. Le downtime est BIEN plus élevé que chez des gens avec une infra similaire en nombre de machines, pourtant avec des systèmes bien plus simples. Principe KISS. Désolé c'est pas sexy…

Bref, case départ : besoins de l'IT. Ensuite à voir comment trouver la solution la plus adaptée.

Si on a envi de se faire plaisir en terme techno, c'est autre chose mais alors c'est pour du labo

Tellement de véritance dans ce post  
 
même problématique que docmaboul pour ma part:
pour l'instant j'utilise ansible pour le provisionning et un peu de config...

+1 avec tout ce que dit Plam.
Ca devrait être affiché dans toutes les DSI

ha c'est sur qu'avec k8s comme hype du moment le kiss est pas vraiment à la fête

 
k8s : Keep it 8 times more Sophisticated

 
Combien de fois je vois les gens arriver et dire « je veux de la HA gnagnagna ». Okay mais t'en a besoin ? Et au final, par rapport au risque… eh ben non
 
Pareil pour les gens qui veulent absolument du Ceph pour 2 ou 3 pauvres machines   Quand le truc pète et que tout tombe    
 
Après k8s j'ai vu des exemples très pertinent d'usage, chez des gens qui font du streaming (chaîne TV bien connue par exemple ). Entre les 3 viewers en milieu de journée et un match de foot, t'es content d'avoir un truc qui passe à l'échelle easy Pour eux, le cloud public c'est aussi une très bonne idée.
 
Pour de l'interne/stable, du on premises, quand tu vois la puissance que tu cales dans une armoire 42U… Pour un coût très raisonnable.

 
Ca n'a jamais été le sujet.
 
Après j'avoue avoir du mal à comprendre ce que tu entends par "applis et des archis designées pour ça" et où serait la difficulté dans mon cas.
 
Prenons un serveur bind par exemple. Il y a quelques fichiers de conf à plat, quelques ports, un peu de logs, une réplication entre les serveurs maîtres et esclave. A quel moment on part si facilement que ça dans le mur ?
 
 

 
Je suis d'accord mais pour revenir à ma situation, manager tout un OS à chaque fois qu'on veut faire tourner un serveur/service, c'est pas KISS compliant à mon sens. Empiler les services sur un même OS, idem. J'aime beaucoup ansible, salt, saltreactor, ..., mais là non plus, ça s'apparente plus à des workarounds qu'une vraie solution à mes yeux : ça facilite/industrialise la gestion de l'OS alors que je voudrais la supprimer. Parce que bon, ce qu'on veut au final c'est bien faire tourner son serveur/service, peu importe l'os qu'il y a en dessous (du moment que c'est performant et sécurisé).
 
La bonne solution, ce serait à mon avis de pouvoir gérer ça directement depuis son hyperviseur, et à peu près aussi simplement qu'une VM.
 
Au boulot

Salut les gens,
https://forum.hardware.fr/forum2.ph [...] 0&filter=1 ne ramenant aucun résultat (sauf ce futur post ) :
Qqn a eu à étudier et mettre en place une solution d'antivirus sur son parc de serveurs et poste de travail Linux ?

Ce que j'ai déjà trouvé :
- étude 100% Linux mais datant de 2015 : http://www.av-comparatives.org/wp- [...] 015_en.pdf
- étude tout OS de 2019/12 : https://www.av-comparatives.org/wp- [...] _12_en.pdf
Sur cette dernière, le tableau de récap indique Linux supporté pour la solution Micosoft alors que cela n'en parle pas dans le paragraphe concernant le produit, j'ai des gros doutes du coup sur la fiabilité
EDIT :
Effectivement, Microsoft Defender Advanced Threat Protection (ATP) est annoncé pour Linux en 2020 : https://www.zdnet.com/article/micro [...] x-in-2020/

 
ben parce ce que ce que tu cherches c'est un K8S. Et donc passer d'une infra à la papa même pas gérée par le code, à une infra dans K8S, c'est avoir grillé quelques paradigmes (parce que là pour le coup, ce sera full git)
Et normalement on commence par conteneuriser des petits workloads non critiques, genre un bout d'appli pour un client, pas toute son infra.
C'est pas impossible cela dit. Après y a certains éléments d'infra qu'il faudra garder en-dehors de ton orchestrateur, sinon c'est l'oeuf et la poule (tiens au hasard, ton dns )
 
Si tu pensais lancer des dockers à l'ancienne par du systemd + engine ou du compose, ça te résout en rien ton problème de mcs sur tes os, il faudra toujours les maintenir. Et c'est pas parce que tu auras évacué les problemes de dépendances entre lib de l'os et le service conteneurisé que t'auras pas aussi à maintenir constamment tes images pour qu'elles ne tirent pas des images de base obsolètes, des libs obsolètes etc. Ton mcs se ferait même à trois niveaux désormais: OS, docker engine, contenu du dockerfile. Il te faudra donc une usine à image tout comme si tu utilises un orchestrateur, intégrée dans une CI pour les tester et les scanner. Il te faudra aussi un conf manager pour continuer à gérer les guest os et le cycle de vie du docker engine. Quant à la sécurité, on reste sur du conteneur type docker / lxc qui ne sont que des simple namespace kernel, loin d'être étanches. Il faut aussi s'ajouter la surveillance des CVE spécifiques au docker engine. Si tu as plusieurs clients qui se partagent les machines, c'est pas anodin.
 
Si tu utilises un orchestrateur, le mco/mcs ne disparait pas non plus. L'os de tes nodes il faut le mettre à jour. K8S il faut le monter en version et c'est pas une mince affaire. Tes dockerfiles il faut les mettre à jour constamment, encore une fois il te faut une usine à image. K8S c'est aussi une belle usine à gaz qui est un métier à part entière. Il faut des profils solides pour le troubleshooter, et ils sont encore rares, et chers.

Je ne sais pas mais ça me paraît vraiment pas fou-fou tout ça, en admettant que les technologies sous-jacentes ne soient pas moisies (ce qui était un peu ma crainte initiale après être tombé sur ce lien chez les aigris).
 
Maintenir les dockerfiles ? Les trucs qui font 100 lignes la fois où l'auteur était vraiment énervé ? On parle de rien.
 
Scanner les images pour les mettre à jour ? Autant les reconstruire à intervalle régulier avec quelques tests unitaires sans se poser de question (je pars du principe que ça doit être un workflow quasi-standard)
 
Tenir à jour les nodes ? On en a 50 aujourd'hui, ça pourra pas être pire
 
L'étanchéité/les failles de docker est très certainement le point qui m'inquiéterait le plus.
 
Je vais tester rancher et OKD pour commencer.

 
Je plussoie KISS. Beaucoup d'admin sys poussent malheureusement des techno pour pouvoir jouer avec alors que le besoin n'est pas vraiment la. ça génère un dette technique énorme ensuite    

+1
même moi qui adore la hype je KISSe

Là on essaie de réduire la dette technique (élevée) et finalement on l'agrandit
mais ça va changer

Franchement ça me parait exagéré, j'administre un k8s avec 10 000+ containers.  
La mise à jour des noeuds, tu es tranquille sous coreOS. La mise à jour de k8s ok il faut la gérer, mais ça fait partie du job de maintenir k8s, c'est juste plus le même métier.  
Les mises à jours de containers, c'est les équipes de dev. Les scans de sécu c'est l'équipe sécu.  
 
En faite il faut que tu remplace ton debian par coreOS   mais pas forcement utiliser k8s. Ou alors automatiser les updates  
 
Si tu veux commencer, regarde la formation du CNCF

ct lxc directement sur le proxmox et puis voilà
un conf manager bien branlé et puis voilà

Lxc vs docker, t'a un gros train de retard en terme d'écosystème. C'est juste incomparable.

obvious

 
Sans déconner, avec des équipes spécialisés en plus Bien sûr que le coût d'adoption en vaut la peine dans ton cas !
 
J'ai comme un doute que le posteur d'origine ait une équipe sécu, une équipe intégration, une équipe maintenance soft, une équipe réseau etc.

perso, j'aimerais déjà avoir un mec correct au helpdesk  

j'aimerais avoir un seul collègue compétent et/ou qui essaie (essayer rien que ça) d'avoir une vue d'ensemble

Podman FTW  

 
Oui oui, on a tout ça
 
C'est souvent le même mec d'ailleurs

 
à toi de voir, mais je suis étonné que si tu trouves que maintenir des images, de la ci, des tests,  un git et ses runners, ce n'est pas grand chose, pourquoi tu n'avais pas déjà en place une infra automatisée à base de salt / ansible etc. des upgrades qui se font tout seul avec unattended etc. ?
Quand on passe de debian 9 à 10, il n'y a pas à réécrire tout le code de l'infra, au pire c'est quelques retouches qu'on voit sur les tests ci qui passent rouges (c'est pas comme si on passait à systemd tous les jours )
 
au final la démarche c'est de tout faire par le code. Les conteneurs sont un moyen d'y arriver mais pas le seul.
 
 

unattended-upgrades ? t'es sérieux là ?