C'est bon, avec un titre comme ça, j'ai votre attention ? :p Prenons les noms les plus trollogĂšnes du moment, mettons les ensemble dans un shaker, rajoutons quelques noms moins connus, secouons bien fort, et nous obtenons un dĂ©licieux cocktail : CoreOS. Il Ă©tait temps de parler en quelques mots de CoreOS, en prenant soin cependant de laisser de cĂŽtĂ© un ton acadĂ©mique pour laisser de la place Ă un peu d'humour et de bullshit. Restera au lecteur Ă allez voir -et tester- par lui mĂȘme de quoi il en retourne. Parceque l'avenir de linux est lĂ . (hoo, un coincoin)
CoreOS, kézako ?
Linux for Massive Server Deployments
CoreOS enables warehouse-scale computing on top of a minimal, modern operating system
Il s'agit d'un projet de systÚme minimaliste, sur lequel on greffe des containers applicatifs indépendants et sécurisés.
Prenez donc tout ces mots-clefs, ajoutez y "Vagrant, Amazon, VMWare, OpenStack, Facebook, Google, ChromiumOS & Gentoo" et vous obtenez une grille gagnante au bingo-réunion de la semaine.
Les bonnes idées venues d'ailleurs :
Partitions systÚme à états :
Pourquoi ChromiumOS ? Parceque CoreOS en reprend une fonctionnalité essentielle : celle de la double partition / systÚme : architecture dans laquelle une partition "froide" reçoit les mises à jour, et lors du reboot elle devient "partition chaude". Si cela se passe mal, un reboot automagique est opéré sur l'ancienne partition n'ayant pas reçue de mises à jour. Ceci de maniÚre transparente. On parle de "partition statefull"
Mise à jour systÚme en unique unité :
Plus de gestionnaires de paquets, on met à jour le systÚme d'un seul trait. Cela réduit l'activité disque, permettant un contrÎle plus fin au sein d'un cgroup spécifique afin que cette activité disque n'impacte nullement le service rendu, pendant l'écriture de la mise à jour du systÚme. Bien sûr on perd là toute l'atomisation possible que nous permettent nos fantastiques gestionnaires de paquets, quels qu'ils soient : pour une mise à jour de sécurité sur une bibliothÚque systÚme, on se voit obligé d'écrire la totalité du RootFS. Mais ça se pÚse, surtout pour un systÚme ultra-minimal. On parle de "Omaha"
Contraindre toutes les applications Ă ĂȘtre autonomes :
Toutes les applications installĂ©es, bureau y compris, seront contraintes dans un container dĂ©diĂ© Ă chacune d'elle. Elles ne verront que leurs propres arborescence, et la gestion sĂ©curitaire en sera grandement facilitĂ©. Nous aurons donc la facilitĂ© de l'obsolĂšte dossier "program files" de Windows, tout en ayant le meilleur des possibilitĂ©s de Linux. L'application codĂ©e de la pire maniĂšre qui soit, ou pire encore, une belle application mais empaquetĂ©e par des Ă©chappĂ©s d'un asile, ne pourront plus pourrir votre systĂšme. Le second gain est la facilitĂ© de dĂ©placement des applications d'un systĂšme Ă un autre. Le _workflow" dev->qual->prod ne se fera plus que sur les contraintes de l'application elle mĂȘme. On parle maintenant de "Docker" et encore de "Omaha"
Configurations distribuées et Gestion Centralisée :
Exit la complexitĂ© de maintenance des bons vieux outils que nous connaissons tous, que cela soit pour un cluster de calcul ou un cluster de services, mĂȘme la plus belle possible genre Ă rĂ©-installation automatique aprĂšs surveillance dĂ©faillance d'un noeud, sa sortie automatique du cluster. Et bonjour le service de gestion centralisĂ©e avec une api JSON... On parle lĂ "d'etcD" Mais aussi de "FleetCTL"
Simplicité, rapidité
Un des objectifs de CoreOS est un boot en moins de deux secondes. Lorsqu'on sait utiliser kexec, et que l'on sait les 4 minutes chrono en main pour l'initialisation des "bios" modernes de certains serveurs, on rĂȘve d'avoir un reboot qui devienne transparent pour les usagers... aussi transparent qu'un mini lag d'un chargement de page web... Et bien CoreOS propose mieux puisqu'il est simplissime de dĂ©mĂ©nager Ă chaud une instance d'un container d'un systĂšme Ă un autre, de rebooter une machine sans passer par les phases "bios", et d'ĂȘtre assurĂ© d'un boot sans encombre avec la sĂ©curitĂ© de la double partition systĂšme. Une intervention en cas de problĂšme se fera sans arrĂȘt de service. Ceci n'est pas option payante et chĂšre (suivez mon regard) qui en plus marche mal. Non : ça fonctionne, c'est libre et c'est inclu. Ces techniques ne sont pas nouvelles en soi, elles sont dĂ©jĂ Ă l'usage chez les grands noms tel que VmWare, Amazon et Google. Mais elles sont ici disponibles librement, comme dans « Logiciels Libres » ;-)
Conclusion
J'ai écris ce journal en mode bullshit (sans notion de qualité pour présenter ce projet), mais ne loupez pas CoreOS. Allez y, lisez leurs docs, testez, amusez vous. Le seul point à vraiment relevé : il y a des mises à jour plus rapide si l'on souscrit un abonnement. Car CoreOS est aussi un projet commercial, pas seulement un magnifique bac-à -sable pour voir les évolutions en avance de phase et profiter du meilleur de notre noyau favori.
Pour tester, on a le choix :
- Amazon EC2
- Google Compute Engine
- Rackspace Cloud
- Brightbox Cloud
- Eucalyptus
- Libvirt
- OpenStack
- QEMU
- Vagrant
- VMware
Et bien sûr, une installation en dur sur son laptop ;-) avec un choix en "readonly + ram" ou en "double partition".
CoreOS
(une dizaine de pages qui, une fois lues, mettrons l'eau Ă la bouche de tout les geeks et nerds du coin, coin)
# Je suis déçu...
PostĂ© par Atem18 . ĂvaluĂ© Ă 10.
Moi qui pensait que tu allait troller sur systemd, me voilà fort contrarié.
[^] # Re: Je suis déçu...
PostĂ© par BeberKing . ĂvaluĂ© Ă 5.
Moi qui pensais que tu allais troller...
# Docker IO et Vagrant: essaie encore
PostĂ© par Ife . ĂvaluĂ© Ă 7. DerniĂšre modification le 27 fĂ©vrier 2014 Ă 20:20.
Je suis un fan de la premiĂšre heure de LXC. J'adore tout, le concept, la performance, le fait qu'on peux enfin faire du
chrootdopĂ© aux stĂ©roĂŻdes en utilisant SELinux (alors qu'on ne pouvait pas avec OpenVZ)LXC est enfin sorti en version 1.0, on peux lancer un container en tant qu'utilisateur. Ăa c'est vraiment cool. Ăa me rassure d'un point de vue sĂ©curitĂ©.
Idem pour KVM, j'adore l'intégration avec Fedora, l'interface
virt-managerde Red Hat.Par contre, je dois avouer que je suis vraiment déçu par Docker IO et Vagrant.
Docker IO parce que c'est juste hype, ça n'apporte rien de nouveau. J'utilise LXC pour avoir une Gentoo qui fait tourner Nginx (comme ça je peux personnaliser les options de compilation), une Debian pour mes emails et une Fedora pour mes applications erlang et python.
Ce que Docker IO offre, c'est juste des containers, prĂ©-compilĂ©s, prĂȘts Ă ĂȘtre lancĂ©s tel quels. Le systĂšme entier est partagĂ© en lecture seule entre des container (par exemple un container "wordpress" a un serveur LAMP), le container lance les services, et une partition de donnĂ©e est unique pour chaque instance (dans notre exemple de wordpress, on peux Ă©crire dans
/var/lib/mysqlet/var/www/wordpress/uploads/). C'est sympa dans l'idée, le problÚme pour utilisateur comme moi c'est que j'ai pas assez de contrÎle dessus, pour un utilisateur pas trop admin sys, le problÚme c'est que les "templates" comme ils les appellent, ne sont pas vraiment maintenus.Vagrant, l'idée est sympa pour le développement, ce que j'aime c'est l'idée de télécharger un cd d'installation, simuler les appuis clavier dans la VM. Comme ça on fait des installations automatiques. Le problÚme c'est que ça utilise VirtualBox (on a vu mieux au point de vue performance, et des grosses briques de virtualbox ne sont pas sous licence libre.) Je sais que Red Hat travaille sur un support de KVM dans Vagrant. J'attends avec impatience!
Ruby est le rĂ©sultat d'un gamin qui apprend le Java, puis jette un Ćil Ă Perl et se dit « je peux le rĂ©parer! »
[^] # Re: Docker IO et Vagrant: essaie encore
PostĂ© par hermenegilde . ĂvaluĂ© Ă 2.
VoilĂ , un problĂšme de contrĂŽle. Quand tu es tout seul sur ton serveur pour faire 2/3 trucs, c'est sympa. Quand tu dois dĂ©ployer 500 applis sur 200 serveurs, tu t'amuses pas Ă faire des trucs Ă la main. Docker, c'est sympa dans ce cas, mĂȘme si ça apporte d'autres problĂšmes.
Je vois bien l'intĂ©rĂȘt d'utiliser un docker avec Apache Mesos par exemple.
# Quid du support d'ARMv7 & ARMv8 ?
PostĂ© par HLFH . ĂvaluĂ© Ă 1.
Sais-tu que le Raspberry Pi a ouvert le marché des Single-board computers (SBC) ?
Les SBCs ont un comparatif Ă jour : http://en.wikipedia.org/wiki/List_of_single-board_computers
D'aprÚs ce comparatif et l'historique communautaire, la communauté la plus en vue est la communauté linux-sunxi au sein duquel agit la tribu Cubie avec le Cubietruck (supportant KVM), le SBC de troisiÚme génération tournant sur Allwinner A20 (ARMv7).
http://cubieboard.org/
Ces ÎŒPCs sont trĂšs utilisĂ©s pour le selfhosting et donc l'environnement serveur.
Ton CoreOS semble uniquement supporter l'architecture amd64.
Peut-ĂȘtre que ce crĂ©ateur d'image universel peut aider pour porter CoreOS vers ARMv7 : https://github.com/EddyBeaupre/armStrap
[^] # Re: Quid du support d'ARMv7 & ARMv8 ?
PostĂ© par Misc (site web personnel) . ĂvaluĂ© Ă 3.
Coreos supporte uniquement amd64 car il faut bien se rendre compte que si ton but est d'avoir un consommation de courant minimal ( cas typique d'avoir une board arm Ă la place d'un pc complet pour chez toi ), tu va pas commencer Ă faire un cluster de machine.
De plus, docker n'a pas l'air d'avoir eu un port ARM pendant longtemps ( https://github.com/dotcloud/docker/issues/636 ), et il faut bien voir que l'avantage de docker, c'est d'avoir aussi une liste d'image dans leur index, et que les images sont mono-arch pour le moment. Et que tout refaire, ça revient Ă refaire tout le travail d'une distribution, ce que visiblement, les gens veulent pas ( sinon, ils feraient une distro, soyons honnĂȘtes )
Suivre le flux des commentaires
Note : les commentaires appartiennent Ă celles et ceux qui les ont postĂ©s. Nous nâen sommes pas responsables.