Pendant longtemps, la société Maxnet Systems a utilisé la version gratuite de VMware - ESXi, à partir de la version 5.0, comme hyperviseur. La version payante de vSphere a effrayé le modèle de licence, tandis que la version gratuite avait un certain nombre d'inconvénients qui n'étaient pas disponibles dans la version payante, mais vous pouviez les supporter. Mais lorsque dans les nouvelles versions d'ESXi la nouvelle interface Web a refusé de fonctionner avec l'ancienne et que la surveillance des matrices RAID a cessé de montrer des signes de vie, la société a décidé de rechercher une solution plus universelle et ouverte. L'entreprise avait déjà une bonne expérience et une bonne impression de LXC - Linux Containers. Par conséquent, il est devenu évident que l'hyperviseur de rêve sera hybride et combinera KVM et LXD pour différentes charges - une continuation évolutive de LXC. À la recherche d'informations sur KVM, l'entreprise était confrontée à des idées fausses, des râteaux et des pratiques néfastes, mais les tests et le temps ont tout mis en place.
À propos de comment gérer le passage d'ESXi à KVM et de ne pas conduire une roue sur un râteau, dira
Lev Nikolaev (
maniaque ) - administrateur et développeur de systèmes très chargés, formateur en technologies de l'information. Parlons du réseau, des référentiels, des conteneurs, du KVM, du LXD, du LXC, du provisionnement et des machines virtuelles pratiques.
Prologue
Nous identifierons immédiatement les pensées clés, puis nous les analyserons plus en détail.
Réseau. Alors que les vitesses de vos interfaces ne dépassent pas 1 Gb / s, le bridge vous suffit. Dès que vous voulez en serrer plus, cela vous limitera.
Dépôt. Créez un stockage réseau partagé. Même si vous n'êtes pas prêt à utiliser 10 Gbit / s à l'intérieur du réseau, même 1 Gbit / s vous donnera 125 Mo / s de stockage. Pour un certain nombre de charges, cela suffira avec une marge, et la migration des machines virtuelles sera une question élémentaire.
Conteneur ou KVM? Avantages, inconvénients, pièges. Quels types de charges sont les mieux placés dans un conteneur et lesquels sont les mieux placés dans un KVM?
LXD ou LXC . Est-ce que LXD LXC? Ou une autre version? Ou un module complémentaire? De quoi s'agit-il? Dissipons les mythes et comprenons les différences entre LXD et LXC.
Provisionnement pratique . Quel est le plus pratique: prendre la même image ou installer le système à partir de zéro à chaque fois? Comment le faire rapidement et avec précision à chaque fois?
Machine virtuelle pratique. Il y aura des histoires effrayantes sur les chargeurs de démarrage, les partitions, LVM.
Divers . Beaucoup de petites questions: comment faire glisser rapidement une machine virtuelle d'ESXi vers KVM, comment bien migrer, comment virtualiser correctement les disques?
Raison de la réinstallation
D'où nous est venue l'idée folle de passer d'ESXi à KVM / LXD? ESXi est populaire parmi les petites et moyennes entreprises. C'est un bon hyperviseur bon marché. Mais il y a des nuances.
Nous avons commencé avec la version 5.0 - commodément, tout fonctionne! La prochaine version 5.5 est la même.
Depuis la version 6.0, c'est déjà plus difficile. Sur ESXi, l'interface Web n'est pas devenue immédiatement gratuite, uniquement à partir de la version 6.5, avant qu'un utilitaire pour Windows ne soit requis. Nous avons supporté cela. Qui exécute OS X achète Parallels et installe cet utilitaire. C'est une douleur bien connue.
La surveillance clignote périodiquement. Il était nécessaire de redémarrer les services de gestion dans la console du serveur - puis CIM Heartbeat est réapparu. Nous avons enduré, car il ne tombait pas toujours.
Version ESXi 6.5 - poubelles, déchets et atrocités. Hyperviseur horrible. Et voici pourquoi.
- Angular tombe avec une exception à l'entrée de l'interface Web. Dès que vous entrez votre nom d'utilisateur et votre mot de passe - immédiatement une exception!
- La possibilité de surveiller à distance l'état de la matrice RAID ne fonctionne pas car cela nous convient. Avant, c'était pratique, mais dans la version 6.5, tout va mal.
- Prise en charge faible des cartes réseau modernes d'Intel . Les cartes réseau Intel et ESXi causent de la douleur. Il y a un fil de discussion sur le forum de support ESXi à ce sujet. VMware et Intel ne sont pas amis et les relations ne s'amélioreront pas dans un avenir proche. Le plus triste est que même les clients des solutions payantes rencontrent des problèmes.
- Aucune migration dans ESXi . Sauf si la migration est considérée comme une procédure de pause, de copie et de démarrage. Nous mettons la voiture en pause, la copions rapidement et la démarrons à un autre endroit. Mais il est impossible de l'appeler migration - il y en a toujours une simple.
Après avoir regardé tout cela, nous avons eu l'idée folle de bouger avec ESXi 6.5.
Liste de souhaits
Pour commencer, nous avons écrit une liste de souhaits pour un avenir idéal que nous allons.
Gestion sous SSH et Web et plus en option. L'interface Web est géniale, mais lors d'un voyage d'affaires avec l'iPhone, aller à l'interface Web ESXi et faire quelque chose est gênant et difficile. Par conséquent, la seule façon de tout gérer est SSH, il n'y en aura pas d'autre.
Virtualisation Windows. Parfois, les clients demandent des choses étranges, et notre mission est de les aider.
Toujours de nouveaux pilotes et la possibilité de configurer une carte réseau . Désir suffisant, mais non réalisé sous ESXi pur.
Migration en direct, pas de clustering . Nous voulons pouvoir faire glisser les machines d'un hyperviseur à un autre sans ressentir de retard, d'arrêt ou d'inconvénient.
La liste de souhaits est prête, puis une recherche difficile a commencé.
Farine de choix
Le marché tourne autour du KVM ou du LXC avec différentes sauces. Parfois, il semble que Kubernetes est quelque part au-dessus, où tout va bien, le soleil et le paradis, et au niveau inférieur, il y a Morlocks - KVM, Xen ou quelque chose comme ça ...
Par exemple, Proxmox VE est Debian, qui a été tiré par le noyau d'Ubuntu. Ça a l'air bizarre, mais est-ce que ça l'amène à la production?
Nos voisins en bas sont Alt Linux. Ils ont trouvé une belle solution: ils ont assemblé Proxmox VE sous forme de package. Ils ont simplement mis le package dans une seule commande. C'est pratique, mais nous ne mettons pas Alt Linux en production, donc cela ne nous convenait pas.
Prenez KVM
Au final, nous avons choisi KVM. Ils ne l'ont pas accepté, Xen, par exemple, à cause de la communauté - KVM en a beaucoup plus. Il semblait que nous trouverions toujours la réponse à notre question. Nous avons découvert plus tard que la taille d'une communauté n'affecte pas sa qualité.
Initialement, nous avons calculé que nous prendrions une machine Bare Metal, ajouterions l'Ubuntu avec lequel nous travaillons et lancerions KVM / LXD par le haut. Nous comptions sur la capacité de gérer des conteneurs. Ubuntu est un système bien connu et il n'y a pas de surprise en termes de résolution de problèmes de démarrage / récupération pour nous. Nous savons où donner un coup de pied si l'hyperviseur ne démarre pas. Tout est clair et pratique pour nous.
Cours intensif KVM
Si vous êtes du monde d'ESXi, vous trouverez beaucoup de choses intéressantes. Apprenez trois mots: QEMU, KVM et libvirt.
QEMU traduit les souhaits d'un OS virtualisé en défis d'un processus régulier. Fonctionne très bien presque partout, mais lentement. QEMU lui-même est un produit autonome qui virtualise un tas d'autres appareils.
Plus loin sur la scène vient un tas de
QEMU-KVM . Il s'agit du module du noyau Linux pour QEMU. La virtualisation de toutes les instructions coûte cher, nous avons donc un module de noyau KVM qui
ne traduit que quelques instructions . En conséquence, cela est beaucoup plus rapide, car seuls quelques pour cent des instructions de l'ensemble général sont traitées. C'est tous les coûts de la virtualisation.
Si vous venez d'avoir QEMU, le démarrage de la machine virtuelle sans liaison ressemble à ceci:
$ qemu < >
Dans les paramètres que vous décrivez, bloquez les périphériques. Tout est merveilleux, mais peu pratique. Il y a donc libvirt.
Le but de libvirt est d'être un outil unique pour tous les hyperviseurs . Il peut fonctionner avec n'importe quoi: avec KVM, avec LXD. Il semble qu'il ne reste plus qu'à apprendre la syntaxe de libvirt, mais en réalité cela fonctionne moins bien qu'en théorie.
Ces trois mots suffisent pour faire monter la première machine virtuelle dans KVM. Mais encore une fois, il y a des nuances ...
Libvirt a une configuration où les machines virtuelles et autres paramètres sont stockés. Il stocke la configuration dans des fichiers xml - élégant, à la mode et directement des années 90. Si vous le souhaitez, ils peuvent être modifiés à la main, mais pourquoi, s'il existe des commandes pratiques. Il est également pratique que les modifications apportées aux fichiers xml soient merveilleusement versionnées. Nous utilisons
etckeeper - version du répertoire, etc. Il est déjà possible d'utiliser etckeeper et il est grand temps.
Cours intensif LXC
Il existe de nombreuses idées fausses sur LXC et LXD.
LXC est la capacité du noyau moderne à utiliser des espaces de noms - pour prétendre que ce n'est pas du tout le noyau qu'il était à l'origine.
Vous pouvez créer autant d'espaces de noms que vous le souhaitez pour chaque conteneur. Formellement, le noyau est un, mais il se comporte comme de nombreux cœurs identiques. LXC vous permet d'exécuter des conteneurs, mais ne fournit que des outils de base.
Canonical, qui est derrière Ubuntu et fait avancer les conteneurs de manière agressive, a publié
LXD, un analogue de libvirt . Il s'agit d'une liaison qui facilite l'exécution des conteneurs, mais à l'intérieur, il s'agit toujours de LXC.
LXD est un hyperviseur de conteneur basé sur LXC.
L'entreprise règne en LXD. LXD stocke la configuration dans sa base de données - dans le répertoire
/var/lib/lxd . Là, LXD mène sa configuration à la configuration dans SQlite. La copier n'a pas de sens, mais vous pouvez écrire les commandes que vous avez utilisées pour créer la configuration du conteneur.
Il n'y a pas de déchargement en tant que tel, mais la plupart des changements sont automatisés par les équipes. Il s'agit d'un analogue du fichier Docker, uniquement avec un contrôle manuel.
La production
Ce à quoi nous étions confrontés lorsque nous sommes tous entrés en service.
Réseau
Combien de poubelles infernales et d'agitation sur Internet à propos du réseau dans KVM! 90% des matériaux disent utiliser un pont.
Arrêtez d'utiliser le pont!
Qu'est-ce qui ne va pas avec lui? Dernièrement, j'ai le sentiment que la folie se produit avec les conteneurs: placez Docker au-dessus de Docker pour pouvoir exécuter Docker dans Docker tout en regardant Docker. La plupart ne comprennent pas ce que fait le pont.
Il met votre contrôleur réseau en
mode promiscuité et reçoit tout le trafic car il ne sait pas lequel et lequel. En conséquence, tout le trafic du pont passe par une merveilleuse pile Linux réseau rapide et il y a beaucoup de copies. Au final, tout est lent et mauvais. Par conséquent, n'utilisez pas de bridge en production.
SR-IOV
SR-IOV est la possibilité de virtualiser au sein d'une carte réseau . La carte réseau elle-même est capable d'allouer une partie d'elle-même aux machines virtuelles, ce qui nécessite une prise en charge matérielle. C'est ce qui empêchera la migration. La migration d'une machine virtuelle où SR-IOV est manquant est pénible.
SR-IOV doit être utilisé lorsqu'il est pris en charge par tous les hyperviseurs dans le cadre de la migration. Sinon, macvtap est fait pour vous.
macvtap
C'est pour ceux dont la carte réseau ne prend pas en charge SR-IOV. Il s'agit de la version allégée du pont: différentes adresses MAC sont accrochées sur une carte réseau, et un
filtrage unicast est utilisé : la carte réseau n'accepte pas tout, mais strictement selon la liste des adresses MAC.
Plus de détails sanglants peuvent être trouvés dans l'excellent discours de Toshiaki Makita
, Virtual Switching Technologies et Linux Bridge . Il est plein de douleur et de souffrance.
90% des matériaux sur la façon de construire un réseau en KVM sont inutiles.
Si quelqu'un dit que le pont est génial, ne parlez plus à cette personne.
Avec macvtap, le
CPU économise environ 30% grâce à moins de copies. Mais le mode promiscuité a ses propres nuances. Vous ne pouvez pas vous connecter à l'interface réseau de la machine invitée à partir de l'hyperviseur lui-même - à partir de l'hôte. Un rapport Toshiaki détaille cela. Mais en bref - cela ne fonctionnera pas.
De l'hyperviseur même aller rarement sur SSH. Il est plus pratique d'y démarrer une console, par exemple une console Win. Il est possible de «surveiller» le trafic sur l'interface - vous ne pouvez pas vous connecter via TCP, mais le trafic sur l'hyperviseur est visible.
Si vos vitesses sont supérieures à 1 Gigabit - choisissez macvtap.
À des vitesses d'interface allant jusqu'à ou environ 1 Gigabit par seconde, le pont peut également être utilisé. Mais si vous avez une carte réseau de 10 Go et que vous souhaitez vous en débarrasser, il ne reste que macvtap. Il n'y a pas d'autre option. Sauf SR-IOV.
systemd-networkd
C'est un excellent moyen de stocker la configuration réseau sur l'hyperviseur lui-même . Dans notre cas, c'est Ubuntu, mais pour d'autres systèmes, systemd fonctionne.
Nous avions un fichier
/etc/network/interfaces dans lequel nous conservions tous. Un fichier n'est pas pratique à modifier à chaque fois - systemd-networkd vous permet de diviser la configuration en une dispersion de petits fichiers. C'est pratique car il fonctionne avec n'importe quel système de version: il a été envoyé à Git et vous voyez quand et quel changement s'est produit.
Il y a une faille que nos networkers ont découverte. Lorsque vous devez ajouter un nouveau VLAN dans l'hyperviseur, je vais configurer. Ensuite, je dis: "systemctl restart systemd-networkd". En ce moment, tout va bien pour moi, mais si les sessions BGP de cette machine sont augmentées, elles se cassent. Nos networkers ne l'approuvent pas.
Pour l'hyperviseur, il ne se passe rien de mal. Systemd-networkd ne convient pas aux frontières, aux serveurs avec BGP élevé et aux hyperviseurs - excellent.
Systemd-networkd est loin d'être définitif et ne sera jamais terminé. Mais c'est plus pratique que d'éditer un énorme fichier. Une alternative à systemd-networkd dans Ubuntu 18.04 est Netplan. C'est une façon «cool» de configurer le réseau et de monter sur le râteau.
Périphérique réseau
Après avoir installé KVM et LXD sur l'hyperviseur, la première chose que vous verrez est deux ponts. L'un a fait KVM pour lui-même, et le second - LXD.
LXD et KVM tentent de déployer leur réseau.
Si vous avez encore besoin d'un pont - pour les machines de test ou pour jouer, tuez le pont, qui est activé par défaut et créez le vôtre - celui que vous voulez. KVM ou LXD le font terriblement - glissez dnsmasq, et l'horreur commence.
Stockage
Peu importe les implémentations que vous aimez - utilisez le stockage partagé.
Par exemple, iSCSI pour les machines virtuelles. Vous ne vous débarrasserez pas du «point de défaillance», mais vous pouvez
consolider le stockage à un moment donné . Cela ouvre de nouvelles opportunités intéressantes.
Pour ce faire, vous devez disposer d'au moins 10 Gb / s d'interfaces dans le centre de données. Mais même si vous n'avez que 1 Gbit / s - ne vous inquiétez pas. Cela représente environ 125 Mo / s, ce qui est assez bon pour les hyperviseurs qui ne nécessitent pas une charge de disque élevée.
KVM peut migrer et faire glisser le stockage. Mais, par exemple, en mode charge de travail, le transfert d'une machine virtuelle vers quelques téraoctets est une tâche difficile. Pour la migration avec un stockage commun, seule la RAM est suffisante, ce qui est élémentaire. Cela
réduit le temps de migration .
Au final, LXD ou KVM?
Initialement, nous avons supposé que pour toutes les machines virtuelles où le noyau correspond au système hôte, nous prendrons LXD. Et là où nous devons prendre un autre noyau - prenez KVM.
En réalité, les plans n'ont pas décollé. Pour comprendre pourquoi, examinez de plus près LXD.
Lxd
Le principal avantage est d'économiser de la mémoire sur le cœur. Le noyau est le même et lorsque nous lançons de nouveaux conteneurs, le noyau est le même. Sur ce, les avantages ont pris fin et les inconvénients ont commencé.
Le périphérique de bloc avec rootfs doit être monté. C'est plus difficile qu'il n'y paraît.
Il n'y a vraiment pas de migration . Il est et est basé sur le merveilleux instrument sombre et criu que nos compatriotes ont vu. Je suis fier d'eux, mais dans des cas simples, criu ne fonctionne pas.
zabbix-agent se comporte étrangement dans un récipient . Si vous l'exécutez à l'intérieur du conteneur, vous verrez une série de données du système hôte et non du conteneur. Jusqu'à présent, rien ne peut être fait.
Lorsque vous consultez la liste des processus sur l'hyperviseur, il est impossible de comprendre rapidement à partir de quel conteneur un processus particulier se développe . Il faut du temps pour comprendre quel espace de noms est là, quoi et où. Si la charge quelque part a sauté plus que d'habitude, alors ne comprends pas rapidement. C'est le principal problème - la limitation des capacités de réponse. Une mini enquête est menée pour chaque cas.
Le seul avantage de LXD est d'économiser la mémoire centrale et de réduire les frais généraux.
Mais la mémoire partagée du noyau dans KVM économise déjà la mémoire.
Jusqu'à présent, je ne vois aucune raison d'introduire une production sérieuse et LXD. Malgré les meilleurs efforts de Canonical dans ce domaine, la production de LXD pose plus de problèmes que de solutions. Dans un avenir proche, la situation ne changera pas.
Mais, on ne peut pas dire que LXD est mauvais. Il est bon, mais dans des cas limités, dont je parlerai un peu plus tard.
Criu
Criu est un utilitaire sombre.
Créez un conteneur vide, il arrivera avec un client DHCP et lui dira: "Suspend!" Obtenez l'erreur car il y a un client DHCP: «Horreur, horreur! Il ouvre la prise avec le signe "raw" - quel cauchemar! " Pire nulle part.
Impressions de conteneurs: pas de migration, Criu fonctionne à chaque fois.
J'aime «la» recommandation de l'équipe LXD que faire de Criu pour qu'il n'y ait aucun problème:
-
Prenez une version plus fraîche du référentiel!Et puis-je en quelque sorte le mettre à partir du package afin de ne pas courir dans le référentiel?
Conclusions
LXD est merveilleux si vous voulez créer une infrastructure CI / CD. Nous prenons LVM - Logical Volume Manager, en faisons un instantané et démarrons le conteneur dessus. Tout fonctionne très bien! En une seconde, un nouveau conteneur propre est créé, qui est configuré pour tester et rouler le chef - nous l'utilisons activement.
LXD est faible pour une production sérieuse . Nous ne pouvons pas savoir quoi faire avec LXD en production si cela ne fonctionne pas bien.
Choisissez KVM et seulement KVM!La migration
Je vais le dire brièvement. Pour nous, la migration s'est avérée être un nouveau monde merveilleux que nous aimons. Tout y est simple - il y a une équipe de migration et deux options importantes:
virsh migrate <vm> qemu+ssh://<hypervisor>/system --undefinesource -persistent
Si vous tapez «Migration KVM» dans Google et ouvrez le premier document, vous verrez une commande de migration, mais sans les deux dernières clés. Vous ne verrez aucune mention de leur importance: «Exécutez simplement cette commande!» Exécutez la commande - et elle migre vraiment, mais seulement comment?
Options de migration importantes.
undefinesource - supprimez la machine virtuelle de l'hyperviseur à partir duquel nous migrons. Si vous redémarrez après une telle migration, l'hyperviseur que vous avez quitté redémarrera cette machine. Vous serez surpris, mais c'est normal.
Sans le deuxième paramètre - persistant - l'hyperviseur où vous avez déménagé ne considère pas du tout qu'il s'agit d'une migration permanente. Après le redémarrage, l'hyperviseur ne se souviendra de rien.
- virsh dominfo <vm> | grep persistent
Sans ce paramètre, la machine virtuelle fait des cercles sur l'eau. Si le premier paramètre est spécifié sans le second, alors devinez ce qui se passera.
Il y a beaucoup de tels moments avec KVM.
- Réseau: ils vous parlent toujours de bridge - c'est un cauchemar! Vous lisez et pensez - comment cela?!
- Migration: ils ne diront rien d'intelligible non plus, jusqu'à ce que vous vous frappiez la tête contre ce mur.
Par où commencer?
Pour commencer tard - je parle d'autre chose.
Provisioning: comment le déployer
Si vous êtes satisfait des options d'installation standard, le mécanisme préconfiguré est parfait.
Sous ESXi, nous avons utilisé virt-install. Il s'agit d'un moyen régulier de déployer une machine virtuelle. Il est pratique de créer un fichier prédéfini dans lequel vous décrivez l'image de votre Debian / Ubuntu. Démarrez une nouvelle machine en lui fournissant un kit de distribution ISO et un fichier prédéfini. Ensuite, la voiture se roule. Vous vous connectez via SSH, connectez-le à un chef, lancez des cookies - c'est tout, précipitez-vous vers la prod!
Mais si vous avez assez de virt-install, j'ai de mauvaises nouvelles. Cela signifie que vous n'avez pas atteint le stade où vous voulez faire autre chose. Nous nous sommes remis et avons réalisé que virt-install ne suffisait pas. Nous sommes arrivés à une «image dorée», que nous clonons puis lançons des machines virtuelles.
Et comment organiser une machine virtuelle?
Pourquoi en sommes-nous arrivés à cette image et pourquoi le provisionnement est-il important? Parce que la communauté comprend encore mal qu'il existe de grandes différences entre une machine virtuelle et une machine normale.
Une machine virtuelle n'a pas besoin d'un processus de démarrage compliqué et d'un chargeur de démarrage intelligent . Il est beaucoup plus facile d'attacher les disques d'une machine virtuelle à une machine qui a un ensemble complet d'outils qu'en mode de récupération en essayant de sortir quelque part.
Une machine virtuelle a besoin de la simplicité d'un appareil . Pourquoi ai-je besoin de partitions sur un disque virtuel? Pourquoi les gens prennent-ils un disque virtuel et y mettent des partitions, pas LVM?
Une machine virtuelle a besoin d'une extensibilité maximale . Habituellement, les machines virtuelles se développent. Il s'agit d'un processus «cool» - l'augmentation de la partition dans le MBR. Vous le supprimez, à ce moment-là, essuyez la sueur de votre front et pensez: "N'écrivez pas maintenant, n'écrivez pas!" - et recréer avec les nouveaux paramètres.
LVM @ lilo
En conséquence, nous sommes arrivés à LVM @ lilo. Il s'agit d'un chargeur de démarrage qui vous permet de configurer à partir d'un seul fichier. Si pour éditer la configuration GRUB vous éditez un fichier spécial qui contrôle le moteur de modèle et construit le monstrueux boot.cfg, alors avec Lilo - un fichier, et rien de plus.
LVM sans partition rend le système parfait et facile. Le problème est que GRUB ne peut pas vivre sans MBR ou GPT et il gèle. Nous lui disons: «GRUB s'installe ici», mais il ne peut pas, car il n'y a pas de partitions.
LVM vous permet d'étendre rapidement et de faire des sauvegardes. Boîte de dialogue standard:
- Les gars, comment faites-vous la sauvegarde virtuelle?- ... nous prenons un périphérique bloc et copions.- Avez-vous essayé de vous déployer en arrière?- Eh bien, non, tout fonctionne pour nous!Vous pouvez lécher un périphérique de bloc dans une machine virtuelle à tout moment, mais s'il existe un système de fichiers, tout enregistrement qu'il contient nécessite trois mouvements - cette procédure n'est pas atomique.
Si vous effectuez un instantané de la machine virtuelle de l'intérieur, elle peut alors communiquer avec le système de fichiers afin qu'elle atteigne l'état cohérent souhaité. Mais cela ne convient pas à tout.
Comment construire un conteneur?
Pour démarrer et créer un conteneur, il existe des outils réguliers à partir des modèles. LXD propose le modèle Ubuntu 16.04 ou 18.04. Mais si vous êtes un combattant avancé et que vous ne voulez pas de modèle standard, mais vos rootfs personnalisés, que vous pouvez personnaliser vous-même, la question se pose: comment créer un conteneur à partir de zéro dans LXD?
Conteneur à partir de zéro
Préparation de rootfs . Debootstrap vous y aidera: nous expliquons quels packages sont nécessaires, lesquels ne le sont pas et installons.
Expliquez à LXD que nous voulons créer un conteneur à partir de rootfs spécifiques . Mais d'abord, créez un conteneur vide avec une commande courte:
curl --unix-socket /var/lib/lxd/unix.socket -X POST -d '{"name": "my-container", "source": {"type": "none"}}' lxd/1.0/containers
Il peut même être automatisé.
Un lecteur réfléchi dira: où est rootfs my-container? Où est-il indiqué à quel endroit? Mais je n'ai pas dit que c'était tout!
Nous montons les rootfs du conteneur où il vivra. Ensuite, nous indiquons que le conteneur rootfs vivra ici:
lxc config set my-container raw.lxc "lxc.rootfs=/containers/my-container/rootfs"
Encore une fois, cela est automatisé.
Durée de vie du conteneur
Le conteneur n'a pas son propre noyau , donc le chargement est plus facile
: systemd, init et volé!
Si vous n'utilisez pas d'outils standard pour travailler avec LVM, dans la plupart des cas, pour démarrer le conteneur, vous devrez monter les rootfs du conteneur dans l'hyperviseur.
Je trouve parfois des articles conseillant autofs. Ne le faites pas. Systemd a des unités de montage automatique qui fonctionnent, mais pas autofs. Par conséquent, les unités de montage automatique systemd peuvent et doivent être utilisées, mais autofs n'en vaut pas la peine.
Conclusions
Nous aimons KVM avec migration . Avec LXD, ce n'est pas encore le chemin, bien que pour tester et construire l'infrastructure, nous l'utilisons là où il n'y a pas de charge de production.
Nous adorons les performances de KVM . Il est plus courant de regarder en haut, de voir un processus pertinent pour cette machine virtuelle et de comprendre qui et ce que nous faisons. C'est mieux que d'utiliser un ensemble d'utilitaires étranges avec des conteneurs pour savoir quel genre de coups sous-marins il y a.
Nous sommes ravis de la migration. Cela est largement dû au stockage partagé. Si nous migrions en faisant glisser des disques, nous ne serions pas si heureux.
Si vous, comme Leo, êtes prêt à parler de surmonter les difficultés de fonctionnement, d'intégration ou de support, alors il est temps de soumettre un rapport à la conférence DevOpsConf d' automne. Et nous, au comité du programme, nous aiderons à préparer la même présentation inspirante et utile que celle-ci.
Nous n'attendons pas la date limite de l'appel à communications et avons déjà accepté plusieurs rapports au programme de la conférence. Abonnez-vous à la newsletter et à la chaîne de télégrammes et restez au courant des nouvelles concernant les préparatifs de DevOpsConf 2019 et ne manquez pas de nouveaux articles et vidéos.