Pine, Linux alpino basato su OSTree
Scegliere cosa OS gira sui tuoi server è una questione di comodità e familiarità. Convenienza significa che vuoi qualcosa che ti dia meno problemi possibile, familiarità significa che preferiresti non per imparare cose aggiuntive se non è necessario.
I miei server sono animali domestici quindi sto bene impartendo manualmente alcuni comandi di tanto in tanto e non richiedo l'automazione completa.
Dopo aver provato Core OS per un anno sono passato alla mia semplificata distribuzione a base di alpino e ostree.
Questa versione di alpine prende spunto da pianale e progetto-atomico e dovrebbe essere installato come un file system root di sola lettura con gli aggiornamenti che avvengono in modo atomico, ovvero, o hanno successo o il sistema torna allo stato precedente. Affinché questo sia possibile, il sistema deve sempre avere almeno due istantanee della versione del file system rilasciata, disponibile sullo storage.
In quali ambienti verrà eseguito il sistema? ho preso di mira OVZ e [KVM], ma in generale puoi dire contenitori e macchine virtuali con la differenza principale che i contenitori non eseguono il proprio kernel, in particolare non hanno un processo di avvio, chiamano direttamente nel dentro sistema (che per esempio in aDockerfile sarebbe definito daCMD oENTRYPOINT dichiarazioni), che è responsabile della gestione dell'albero dei processi che manterrà il contenitore in esecuzione (proprio come una normale sessione, se il processo init muore, il contenitore termina). Inoltre, i contenitori non possono configurare le manopole di sistema e possono avere restrizioni aggiuntive sulle funzionalità.
Come si costruisce l'immagine?
Ilprepare.sh lo script gestisce le dipendenze, la maggior parte delle quali sono i pacchetti per offrire strumenti cli comuni comecoreutils, util-linux, binutils , utility per operare con dispositivi a blocchi comeblkid, sfdisk, multipath-tools e file system conxfsprogs ee2fsprogs . Ilsquashfs-tools pacchetto viene utilizzato alla fine per comprimere il file system root costruito. UNglib anche il pacchetto di compatibilità è installato di default perché alpine è basato sumusl , il pacchetto di compatibilità funziona fornendo alcune librerie basate su .
Gli alberi dei file sia per le VM che per i container sono costruiti rispettivamente conmake.sh emake_ovz.sh . Questa è una descrizione semplificata dei passaggi
imposta la versione da compilare in base al tag del repository
creare una directory per il nuovo albero e cancellare l'ambiente
creare directory di destinazione di base e directory richieste da ostree, comesysroot
creare collegamenti simbolici per conformarsi al standard di gerarchia del filesystem
copia servizi personalizzati e configurazioni personalizzate
configurare chroot con le directory di sistema montate
bootstrap un rootfs alpino con pacchetti di base
applica una configurazione minima a rootfs come credenziali, fuso orario, nome host.
servizi di copia che devono essere avviati da init
impostare la configurazione di avvio con l'immagine del kernel specificata
aggiungere opzionalmente moduli del kernel personalizzati
eseguire pulizie
commit the rootfs[1] al repository ostree
Per i contenitori, la sequenza è la stessa, ma la configurazione cambia, perché con un sistema non avviato da a boot loader ostree ha problemi a verificare l'ambiente, dobbiamo applicarne un po' soluzioni alternative e configurare alcuni dispositivi che di solito sono gestiti dal initramfs fare un passo. Questo è come OVZ o LXC i modelli sono configurati.
Una volta che abbiamo il nostro albero di file impegnati ostreebuild.sh obuild-update.sh si occupa di produrre il manufatto che verrà distribuito. La differenza tra gli script è che la versione di aggiornamento inizia da un repository ostree precedente e anche produce un artefatto delta che un sistema in esecuzione può applicare alla sua istanza ostree per eseguire gli aggiornamenti. Questa è una descrizione semplificata dei passaggi di compilazione
se nuova build
creare nuove partizioni su una nuova immagine montata come dispositivo loop
altro
monta sysroot e partizioni di avvio della build precedente
ripulire le distribuzioni precedenti di ostree (link farm) su build montate
commit di un nuovo albero costruito su build montata
verifica integrità e checksum
creare un nuovo delta per gli aggiornamenti
eseguire la distribuzione ostree per rigenerare la configurazione di avvio
rimuovi i vecchi commit di ostree
verificare l'integrità della partizione di avvio
smonta la nuova immagine di build aggiornata
generare il checksum dell'immagine e comprimerlo (consquashfs per contenitori)
La configurazione delle partizioni viene applicata con un fdisklayout.cfg file che definisce le dimensioni delle partizioni, abbiamo una partizione per rootfs (~430M ), la partizione di avvio (~40M ) e una partizione di swap (~40M ). Con i contenitori salta semplicemente il montaggio della build precedente su un dispositivo loop e trascina semplicemente il nuovo commit ostree sul vecchio repository ostree (estratto).
Cosa sto raggruppando in questa immagine (a parte i pacchetti installati)?
Un piccolo lib infunctions.sh per le attività comuni eseguite all'interno della shell
script di aggiornamento basati su ostree con meccanismo di blocco basato su KV store
script di monitoraggio per IO sia locali (iomon ) e rete (tcpmon)
script di configurazione per runtime del contenitore diversi dabubblewrap: podman, toolbox
Quello che era e non è più
sup: sup è stato utilizzato per l'orchestrazione (distribuzione dei contenitori) e la configurazione della macchina host, ma poi sono passato a ansible perché c'erano bug di vecchia data in sup che mancavano di una correzione, non ho scelto ansible dall'inizio perché non volevo una dipendenza python da installare su ogni server, alla fine ho optato per un alpine secondario chroot sulle macchine host, situate in/opt/alp dovessi installare software aggiuntivo meno critico. Oggi, tuttavia, vorrei passare di nuovo da ansible a pyinfra , perché
è python senza boilerplate (ansible ha pseudoDSL che provoca più mal di testa di quelli che risolve)
esegue le sue ricette con semplici comandi ssh, quindi non c'è un requisito di dipendenza python sugli host di destinazione
containerpilot: Il caso d'uso per il pilota del contenitore è gestire dipendenze complesse tra contenitori senza script di shell... ha smesso di ricevere aggiornamenti da gioiosa ed è stato messo in modalità di manutenzione, inoltre, non mi piaceva che i requisiti di memoria e l'utilizzo della memoria aumentassero costantemente per un lungo periodo di tempo di attività. L'ho cambiato per semplici script di shell con console , potrei esaminare alternative più appropriate se gli script di shell iniziano a crescere troppo. Soluzioni più pesanti come kubernetes, sciame o nomade sono stati scartati fin dall'inizio.
beegfs : Ero solito spedire il modulo del kernel necessario per beegfs ma dopo un po 'ha rotto la compatibilità e il fatto che non ci fosse un supporto adeguatamente fusibile modulo fatto essere eliminato del tutto, al momento non sto eseguendo un [DFS] sui miei server, ma la possibilità di avere un file system pronto per l'uso per collegare una rete è ancora allettante.
Per installare l'immagine puoi caricarla sul provider di hosting e installarla da VNC, nel caso di macchine virtuali, ma di solito dirotto un'installazione esistente, perché è sempre possibile, e ho testato lo script di installazione rispetto alla versione di la distribuzione linux, generalmente uso debian-8 o ubuntu-14, non ne ho testati altri poiché questi li ho sempre trovati disponibili. La procedura di installazione segue
garantire il supporto https per i download
scarica una versione di busybox
installa una link-farm di busybox
determinare gli indirizzi ipv4/ipv6 per la configurazione di rete
assicurare le capacità di chroot
scarica l'immagine del pino ed estraila
se VM
flash sul dispositivo di destinazione
montare su un dispositivo loop
scrivere la configurazione della rete locale su essere lampeggiato rootfs
se contenitore
copia il servizio init (per i contenitori) sul punto di montaggio della radice principale/sbin/init
se VM
partizionare il disco rimasto con standard (xfs ) partizioni
smontare
verificare l'integrità delle partizioni
riavviare
ho fatto pino 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 server che tendono ad offrire risorse estremamente basse, in realtà ho una scatola in esecuzione con solo64M di RAM e ho ancora tutte le funzionalità di cui ho bisogno.
| [1] | file system radice |
