Pine, Alpine Linux basé sur OSTree
Choisir quoi Système d'exploitation s'exécute sur vos serveurs est une question de commodité et de familiarité. La commodité signifie que vous voulez quelque chose qui vous cause le moins de problèmes possible, la familiarité signifie que vous préférez ne pas pour apprendre des choses supplémentaires si vous n'y êtes pas obligé.
Mes serveurs sont animaux domestiquesJe peux donc émettre manuellement quelques commandes de temps en temps et ne nécessite pas une automatisation complète.
Après avoir essayé CoreOS pendant un an je suis passé au mien simplifié distribution basé sur l'alpin et ostrée.
Cette version de l'alpin s'inspire de wagon plat et projet-atomique et est censé être installé en tant que système de fichiers racine en lecture seule avec des mises à jour se produisant de manière atomique, c'est-à-dire qu'elles réussissent ou que le système revient à l'état précédent. Pour que cela soit possible, le système doit toujours avoir au moins deux instantanés de la version publiée du système de fichiers, disponible sur le stockage.
Dans quels environnements le système fonctionnera-t-il ? j'ai ciblé OVZ et [KVM], mais en général vous pouvez dire conteneurs et machines virtuelles la principale différence étant que les conteneurs n'exécutent pas leur propre noyau, en particulier ils n'ont pas de processus de démarrage, ils appellent directement dans le init système (qui par exemple dans unDockerfile il serait défini par leCMD ouENTRYPOINT instructions), qui est chargé de gérer l'arborescence des processus qui maintiendront le conteneur en cours d'exécution (tout comme une session normale, si le processus d'initialisation meurt, le conteneur se termine). De plus, les conteneurs ne peuvent pas configurer les boutons système et peuvent avoir des restrictions supplémentaires sur les capacités.
Comment se construit l'image ?
Lesprepare.sh le script gère les dépendances, dont la plupart sont les packages pour offrir des outils cli communs commecoreutils, util-linux, binutils , des utilitaires pour fonctionner avec des périphériques de bloc commeblkid, sfdisk, multipath-tools et les systèmes de fichiers avecxfsprogs ete2fsprogs . Lessquashfs-tools package est utilisé à la fin pour compresser le système de fichiers racine construit. UNEglib le package de compatibilité est également installé par défaut car alpine est basé surmusl, le package de compatibilité fonctionne en fournissant des bibliothèques construites contre .
Les arborescences de fichiers pour les machines virtuelles et les conteneurs sont construites avec respectivementmake.sh etmake_ovz.sh . Ceci est une description simplifiée des étapes
définir la version à construire en fonction de la balise du référentiel
créer un répertoire pour la nouvelle arborescence et effacer l'environnement
créer des répertoires cibles de base et des répertoires requis par ostree, commesysroot
créer des liens symboliques pour se conformer à la norme de hiérarchie du système de fichiers
copier des services personnalisés et des configurations personnalisées
configuration du chroot avec les répertoires système montés
amorcer un rootfs alpin avec des packages de base
appliquez une configuration minimale au rootfs comme les informations d'identification, le fuseau horaire, le nom d'hôte.
services de copie à démarrer par init
configurer la configuration de démarrage avec l'image de noyau spécifiée
ajouter éventuellement des modules de noyau personnalisés
effectuer des nettoyages
commit le rootfs[1] au dépôt d'ostrée
Pour les conteneurs, la séquence est la même, mais la configuration change, car avec un système non démarré à partir d'un chargeur de démarrage ostree a du mal à vérifier l'environnement, nous devons appliquer solutions de contournement et configurer certains périphériques qui sont généralement gérés par le initramfs étape. C'est ainsi OVZ ou LXC les modèles sont configurés.
Une fois que nous avons notre arborescence de fichiers validés ostreebuild.sh oubuild-update.sh se charge de produire l'artefact qui sera distribué. La différence entre les scripts est que la version de mise à jour démarre à partir d'un référentiel ostree précédent, et aussi produit un artefact delta qu'un système en cours d'exécution peut appliquer sur son instance ostree pour effectuer des mises à niveau. Ceci est une description simplifiée des étapes de construction
si nouvelle construction
créer de nouvelles partitions sur une nouvelle image montée en tant que périphérique de boucle
autre
monter sysroot et démarrer les partitions de la version précédente
nettoyer les déploiements d'ostree précédents (fermes de liens) sur la construction montée
commit un nouvel arbre construit sur la construction montée
vérifier l'intégrité et les sommes de contrôle
créer un nouveau delta pour les mises à niveau
exécuter le déploiement d'ostree pour régénérer la configuration de démarrage
supprimer les anciens commits ostree
vérifier l'intégrité de la partition de démarrage
démonter la nouvelle image de build mise à jour
générer la somme de contrôle de l'image et la compresser (avecsquashfs pour conteneurs)
La configuration des partitions est appliquée avec un fdisklayout.cfg qui définit les tailles de partition, nous avons une partition pour le rootfs (~430M ), la partition de démarrage (~40M ) et une partition d'échange (~40M ). Avec des conteneurs, il suffit d'ignorer le montage de la version précédente sur un périphérique en boucle et de tirer simplement le nouveau commit ostree sur l'ancien référentiel ostree (extrait).
Qu'est-ce que je regroupe dans cette image (à part les packages installés) ?
Une petite lib dansfunctions.sh pour les tâches courantes exécutées dans le shell
scripts de mise à niveau basés sur ostree avec mécanisme de verrouillage basé sur le magasin KV
scripts de surveillance pour les E/S à la fois locaux (iomon ) et réseau (tcpmon)
scripts de configuration pour les environnements d'exécution de conteneur autres quebubblewrap: podman, toolbox
Ce qui était et n'est plus
sup: Souper a été utilisé pour l'orchestration (déployer des conteneurs) et la configuration de la machine hôte, mais je suis ensuite passé à ansible car il y avait des bugs de longue date dans sup qui manquaient de correctif, je n'ai pas choisi ansible dès le départ car je ne voulais pas qu'une dépendance python s'installe sur chaque serveur, finalement je me suis installé avec un alpin secondaire chroot sur les machines hôtes, situées dans/opt/alpsi j'installais d'autres logiciels moins critiques. Aujourd'hui, cependant, je passerais à nouveau d'ansible à pyinfra , car
c'est du python sans passe-partout (ansible a pseudoDSL qui cause plus de maux de tête que ceux qu'il résout)
il exécute ses recettes avec des commandes ssh simples, il n'y a donc pas d'exigence de dépendance python sur les hôtes cibles
containerpilot : Le cas d'utilisation du pilote de conteneur est de gérer les dépendances complexes entre les conteneurs sans scripts shell... il a cessé de recevoir les mises à jour de joyeux et a été mis en mode maintenance, je n'aimais pas non plus les besoins en mémoire et l'utilisation de la mémoire augmenterait constamment pendant une longue période de disponibilité. Je l'ai remplacé par des scripts shell simples avec consul , je pourrais chercher des alternatives plus appropriées si les scripts shell commencent à trop se développer. Des solutions plus lourdes comme kubernetes, essaim ou nomade ont été écartés dès le départ.
beegfs : J'avais l'habitude d'expédier le module noyau nécessaire pour boeufs mais après un certain temps, la compatibilité a été rompue et le fait qu'il n'y avait pas de support correctement pris en charge fusible module a été supprimé complètement, je n'exécute actuellement pas de [DFS] sur mes serveurs, mais la possibilité d'avoir un système de fichiers prêt à l'emploi pour se connecter à un réseau est toujours attrayante.
Pour installer l'image, vous pouvez soit la télécharger sur le fournisseur d'hébergement et l'installer à partir de VNC, dans le cas de machines virtuelles, mais je détourne généralement une installation existante, car c'est toujours possible, tant que j'ai testé le script d'installation par rapport à la version de la distribution linux, généralement j'utilise debian-8 ou ubuntu-14, n'en a pas testé d'autres car j'ai toujours trouvé qu'elles étaient disponibles. Les étapes de configuration suivent
assurer la prise en charge https pour les téléchargements
télécharger une version busybox
installer une ferme de liens busybox
déterminer les adresses ipv4/ipv6 pour la configuration réseau
assurer les capacités chroot
téléchargez l'image du pin et extrayez-la
si VM
flash sur l'appareil cible
monter sur un périphérique en boucle
écrire la configuration du réseau local sur le être flashé rootfs
si conteneur
copier le service init (pour les conteneurs) sur le point de montage racine principal/sbin/init
si VM
partitionner le disque restant avec la norme (xfs ) partitions
démonter
vérifier l'intégrité des partitions
redémarrer
J'ai fait pin 5 years from time of writing and I am still using it, and I see no reasons to switch to anything else. Alpine as a linux distro is great, simple, and I have never experienced breakage. I can easily deploy on NAT serveurs qui ont tendance à offrir des ressources ultra-faibles, en fait j'ai une boîte qui tourne avec juste64M de RAM, et j'ai toujours toutes les fonctionnalités dont j'ai besoin.
| [1] | système de fichiers racine |
