Pine, Alpine linux gebaseerd op OSTree
Kiezen wat? OS draait op uw servers is een kwestie van gemak en vertrouwdheid. Gemak betekent dat je iets wilt waar je zo min mogelijk last van hebt, vertrouwdheid betekent dat je dat liever hebt niet om extra dingen te leren als dat niet nodig is.
Mijn servers zijn huisdierendus ik vind het oké om af en toe handmatig een paar commando's uit te geven en heb geen volledige automatisering nodig.
Na het uitproberen CoreOS voor een jaar ben ik overgestapt op mijn eigen vereenvoudigde distro gebaseerd op alpine en ostree.
Deze versie van Alpine is gebaseerd op: platte wagen en project-atomaire en wordt verondersteld te worden geïnstalleerd als een alleen-lezen rootbestandssysteem met updates die atomair plaatsvinden, dat wil zeggen, ze slagen of het systeem keert terug naar de vorige staat. Om dit mogelijk te maken moet het systeem altijd minimaal twee snapshots van de vrijgegeven versie van het bestandssysteem, beschikbaar op opslag.
In welke omgevingen zal het systeem draaien? ik heb getarget OVZ en [KVM], maar in het algemeen kun je zeggen containers en virtuele machines met het belangrijkste verschil dat containers niet hun eigen kernel draaien, in het bijzonder hebben ze geen opstartproces, ze roepen rechtstreeks in de in het systeem (dat bijvoorbeeld in eenDockerfile het zou worden gedefinieerd door deCMD ofENTRYPOINT statements), die verantwoordelijk is voor het beheer van de structuur van processen die de container draaiende houden (net als bij een normale sessie, als het init-proces sterft, wordt de container beëindigd). Ook containers kunnen geen systeemknoppen configureren en kunnen aanvullende beperkingen hebben op de mogelijkheden.
Hoe is het beeld opgebouwd?
Deprepare.sh script behandelt afhankelijkheden, waarvan de meeste de pakketten zijn die algemene cli-tools bieden, zoals:coreutils, util-linux, binutils , hulpprogramma's om te werken met blokapparaten zoalsblkid, sfdisk, multipath-tools en bestandssystemen metxfsprogs ene2fsprogs . Desquashfs-tools pakket wordt aan het einde gebruikt om het ingebouwde rootbestandssysteem te comprimeren. EENglib compatibiliteitspakket is ook standaard geïnstalleerd omdat alpine is gebaseerd op:musl, werkt het compatibiliteitspakket door een aantal bibliotheken te bieden die zijn gebouwd tegen .
Bestandsstructuren voor zowel VM's als containers zijn respectievelijk gebouwd metmake.sh enmake_ovz.sh . Dit is een vereenvoudigde beschrijving van de stappen
stel de te bouwen versie in volgens de repository-tag
maak een map voor de nieuwe boom en wis de omgeving
maak basisdoelmappen en mappen die vereist zijn door ostree, zoalssysroot
maak symbolische links om te voldoen aan de bestandssysteem hiërarchie standaard
kopieer aangepaste services en aangepaste configuraties
chroot instellen met aangekoppelde systeemmappen
bootstrap een alpine rootfs met basispakketten
minimale configuratie toepassen op de rootfs, zoals referenties, tijdzone, hostnaam.
kopieerservices die moeten worden gestart door init
stel de opstartconfiguratie in met de opgegeven kernel-image
optioneel aangepaste kernelmodules toevoegen
opruimen uitvoeren
commit de rootfs[1] naar de ostree-repository
Voor containers is de volgorde hetzelfde, maar de configuratie verandert, omdat met een systeem dat niet is opgestart vanaf a bootloader ostree heeft problemen met het verifiëren van de omgeving, we moeten wat toepassen tijdelijke oplossingen en stel een aantal apparaten in die meestal worden afgehandeld door de initramfs stap. Dit is hoe OVZ of LXC sjablonen zijn geconfigureerd.
Zodra we onze ostree-committed-bestandenstructuur hebbenbuild.sh ofbuild-update.sh zorgt voor de productie van het artefact dat wordt gedistribueerd. Het verschil tussen de scripts is dat de updateversie start vanaf een eerdere ostree-repository, en ook produceert een delta-artefact dat een draaiend systeem kan toepassen op zijn ostree-instantie om upgrades uit te voeren. Dit is een vereenvoudigde beschrijving van de bouwstappen
als nieuwbouw
maak nieuwe partities op een nieuwe afbeelding die is gemount als een loop-apparaat
anders
mount sysroot en opstartpartities van vorige build
opschonen van eerdere ostree-implementaties (link farms) op gekoppelde build
commit nieuw gebouwde boom op gemonteerde build
verifieer integriteit en checksums
nieuwe delta maken voor upgrades
ostree-implementatie uitvoeren om de opstartconfiguratie opnieuw te genereren
verwijder oude ostree commits
controleer de integriteit van de opstartpartitie
ontkoppel nieuwe bijgewerkte build-afbeelding
genereer afbeeldingscontrolesom en comprimeer deze (metsquashfs voor containers)
De partitieconfiguratie wordt toegepast met een fdisklayout.cfg bestand dat de partitiegroottes definieert, hebben we één partitie voor de rootfs (~430M ), de opstartpartitie (~40M ) en een swappartitie (~40M ). Met containers waarbij je gewoon de vorige build over een loop-apparaat kunt overslaan en gewoon de nieuwe ostree-commit over de oude (geëxtraheerde) ostree-repository kunt trekken.
Wat bundel ik in deze afbeelding (behalve geïnstalleerde pakketten)?
Een kleine lib infunctions.sh voor veelvoorkomende taken die binnen de shell worden uitgevoerd
op ostree gebaseerde upgradescripts met vergrendelingsmechanisme op basis van KV store
monitoringscripts voor IO zowel lokaal (iomon ) en netwerk (tcpmon)
setup-scripts voor andere container-runtimes danbubblewrap: podman, toolbox
Wat was en niet meer is
sup: Sup werd gebruikt voor orkestratie (implementatie van containers) en configuratie van de hostmachine, maar toen schakelde ik over naar weerbaar omdat er al lang bestaande bugs in sup waren die geen oplossing hadden, heb ik vanaf het begin niet voor ansible gekozen omdat ik niet wilde dat een python-afhankelijkheid op elke server zou worden geïnstalleerd, uiteindelijk heb ik genoegen genomen met een secundaire alpine chroot op de hostmachines, die zich in/opt/alpwaar ik aanvullende, minder kritische software installeer. Vandaag zou ik echter weer overschakelen van ansible naar pyinfra , omdat
het is python zonder boilerplate (ansible heeft pseudoDSL dat meer hoofdpijn veroorzaakt dan het oplost)
het voert zijn recepten uit met gewone ssh-opdrachten, dus er is geen python-afhankelijkheidsvereiste voor doelhosts
containerpilot : De use case voor containerpilot is om complexe afhankelijkheden tussen containers te beheren zonder shellscripts... het stopte met het ontvangen van updates van vreugdevol en in onderhoudsmodus werd gezet, hield ik ook niet van de geheugenvereisten en het geheugengebruik zou constant toenemen voor een lange periode van uptime. Ik verwisselde het voor eenvoudige shell-scripts met consul , zou ik naar meer geschikte alternatieven kunnen kijken als shellscripts te veel beginnen te groeien. Zwaardere oplossingen zoals kubernetes, zwerm of nomade werden vanaf het begin weggegooid.
beegfs : Ik heb de kernelmodule verzonden die nodig is voor beegfs maar na een tijdje brak de compatibiliteit en het feit dat er geen goed ondersteunde lont module gemaakt om het helemaal te laten vallen, ik gebruik momenteel geen [DFS] op mijn servers, maar de mogelijkheid om een kant-en-klaar bestandssysteem te hebben om in een netwerk aan te sluiten, is nog steeds aantrekkelijk.
Om de afbeelding te installeren, kunt u deze uploaden naar de hostingprovider en installeren vanaf VNC, in het geval van virtuele machines, maar ik kap meestal een bestaande installatie, omdat het altijd mogelijk is, zolang ik het installatiescript heb getest tegen de versie van de linux-distributie, in het algemeen gebruik ik debian-8 of ubuntu-14, heb geen andere getest omdat ik deze altijd beschikbaar heb gevonden. De installatiestappen volgen:
zorg voor https-ondersteuning voor downloads
download een busybox-versie
installeer een busybox link-farm
ipv4/ipv6-adressen bepalen voor netwerkconfiguratie
zorgen voor chroot-mogelijkheden
download de afbeelding van de pijnboom en pak deze uit
als VM
flits over doelapparaat
monteren over een lusapparaat
schrijf de lokale netwerkconfiguratie over de geflitst worden rootfs
als container
kopieer de init-service (voor containers) over het hoofd root-aankoppelpunt/sbin/init
als VM
partitie de overgebleven schijf met standaard (xfs ) partities
ontkoppelen
integriteit van partities verifiëren
opnieuw opstarten
ik maakte pijnboom 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 NATed servers die de neiging hebben om ultralage bronnen te bieden, eigenlijk heb ik een box met alleen64M van RAM, en heb nog steeds alle functies die ik nodig heb.
| [1] | root bestandssysteem |
