Pine, Alpine linux baseado em OSTree
Escolhendo o que SO executado em seus servidores é uma questão de conveniência e familiaridade. Conveniência significa que você deseja algo que ofereça o mínimo de problemas possível, familiaridade significa que você prefere não para aprender coisas adicionais se não for necessário.
Meus servidores são animais de estimaçãoportanto, posso emitir alguns comandos manualmente de vez em quando e não exigir automação completa.
Depois de experimentar CoreOS por um ano mudei para o meu próprio simplificado distro baseado em alpino e ostree.
Esta versão do alpino segue dicas de vagão plano e projeto-atômico e deve ser instalado como um sistema de arquivos raiz somente leitura com atualizações acontecendo atomicamente, ou seja, elas são bem-sucedidas ou o sistema volta ao estado anterior. Para que isso seja possível, o sistema deve ter sempre pelo menos dois instantâneos da versão lançada do sistema de arquivos, disponível no armazenamento.
Em quais ambientes o sistema será executado? Eu almejei OVZ e [KVM], mas em geral você pode dizer containers e máquinas virtuais com a principal diferença de que os contêineres não executam seu próprio kernel, em particular eles não têm um processo de inicialização, eles chamam diretamente no iniciar sistema (que, por exemplo, em umDockerfile seria definido peloCMD ouENTRYPOINT ), que é responsável por gerenciar a árvore de processos que manterá o contêiner em execução (assim como uma sessão normal, se o processo init morre, o contêiner é encerrado). Além disso, os contêineres não podem configurar botões do sistema e podem ter restrições adicionais de recursos.
Como a imagem é construída?
oprepare.sh script lida com dependências, a maioria das quais são pacotes para oferecer ferramentas CLI comuns comocoreutils, util-linux, binutils , utilitários para operar com dispositivos de bloco comoblkid, sfdisk, multipath-tools e sistemas de arquivos comxfsprogs ee2fsprogs . osquashfs-tools pacote é usado no final para compactar o sistema de arquivos raiz construído. UMAglib pacote de compatibilidade também é instalado por padrão porque alpine é baseado emmusl, o pacote de compatibilidade funciona fornecendo algumas bibliotecas construídas contra.
Árvores de arquivos para VMs e contêineres são construídas com, respectivamentemake.sh emake_ovz.sh . Esta é uma descrição simplificada das etapas
definir a versão a ser construída de acordo com a tag do repositório
crie um diretório para a nova árvore e limpe o ambiente
crie diretórios de destino básicos e diretórios exigidos por ostree, comosysroot
criar links simbólicos para estar em conformidade com o padrão de hierarquia do sistema de arquivos
copie serviços personalizados e configurações personalizadas
configurar chroot com diretórios de sistema montados
inicializar um rootfs alpino com pacotes básicos
aplique configuração mínima ao rootfs como credenciais, fuso horário, nome do host.
serviços de cópia a serem iniciados por init
definir a configuração de inicialização com a imagem de kernel especificada
opcionalmente, adicione módulos de kernel personalizados
realizar limpezas
comprometer o rootfs[1] para o repositório ostree
Para contêineres, a sequência é a mesma, mas a configuração muda, porque com um sistema não inicializado a partir de um bootloader Ostree tem problemas para verificar o ambiente, temos que aplicar alguns soluções alternativas e configurar alguns dispositivos que geralmente são manipulados pelo initramfs Passo. É assim OVZ ou LXC os modelos são configurados.
Assim que tivermos nossa árvore de arquivos confirmados para ostreebuild.sh oubuild-update.sh cuida da produção do artefato que será distribuído. A diferença entre os scripts é que a versão de atualização começa a partir de um repositório ostree anterior, e tb produz um artefato delta que um sistema em execução pode aplicar em sua instância ostree para realizar atualizações. Esta é uma descrição simplificada das etapas de construção
se nova construção
criar novas partições em uma nova imagem montada como um dispositivo de loop
outro
monte o sysroot e partições de inicialização da compilação anterior
limpar as implantações anteriores do Ostree (link farms) na construção montada
comprometer nova árvore construída em construção montada
verificar integridade e somas de verificação
criar novo delta para atualizações
execute a implantação do Ostree para regenerar a configuração de inicialização
remover antigos commits de ostree
verificar a integridade da partição de inicialização
desmontar nova imagem de compilação atualizada
gerar a soma de verificação da imagem e compactá-la (comsquashfs para contêineres)
A configuração das partições é aplicada com um fdisklayout.cfg arquivo que define os tamanhos das partições, temos uma partição para o rootfs (~430M ), a partição de inicialização (~40M ) e uma partição swap (~40M ) Com contêineres, basta ignorar a montagem da compilação anterior em um dispositivo de loop e apenas puxar o novo commit do ostree sobre o antigo (extraído) repositório do ostree.
O que estou agrupando nesta imagem (além dos pacotes instalados)?
Uma pequena lib emfunctions.sh para tarefas comuns executadas dentro do shell
Scripts de atualização baseados em ostree com mecanismo de bloqueio baseado em KV store
scripts de monitoramento para IO locais (iomon ) e rede (tcpmon)
scripts de configuração para tempos de execução de contêiner diferentesbubblewrap: podman, toolbox
O que costumava ser e não é mais
sup: E aí foi usado para orquestração (implantar contêineres) e configuração da máquina host, mas depois mudei para ansible porque havia bugs de longa data no sup que não tinham uma correção, não escolhi o ansible desde o início porque não queria que uma dependência python fosse instalada em todos os servidores, eventualmente resolvi usar um alpino secundário chroot nas máquinas host, localizadas em/opt/alponde instalar software adicional menos crítico. Hoje, no entanto, eu mudaria novamente de ansible para pyinfra , Porque
é python sem clichê (ansible tem pseudoDSL que causa mais dores de cabeça do que as que resolve)
ele executa suas receitas com comandos ssh simples, portanto, não há um requisito de dependência de python nos hosts de destino
containerpilot : O caso de uso do piloto de contêiner é gerenciar dependências complexas entre contêineres sem scripts de shell ... ele parou de receber atualizações de alegre e foi colocado em modo de manutenção, também não gostei dos requisitos de memória e o uso de memória aumentava constantemente por um longo período de tempo de atividade. Troquei para scripts de shell simples com cônsul , Posso procurar alternativas mais adequadas se os scripts de shell começarem a crescer muito. Soluções mais pesadas como Kubernetes, enxame ou nômade foram descartados desde o início.
beegfs : Eu costumava enviar o módulo do kernel necessário para Beegfs mas depois de um tempo quebrou a compatibilidade e o fato de que não havia um suporte adequado fusível módulo feito ser descartado por completo, eu atualmente não estou executando um [DFS] em meus servidores, mas a possibilidade de ter um sistema de arquivos pronto para ligar em uma rede ainda é atraente.
Para instalar a imagem, você pode carregá-la para o provedor de hospedagem e instalar a partir do VNC, no caso de máquinas virtuais, mas eu costumo sequestrar uma instalação existente, porque sempre é possível, desde que testei o script de configuração contra a versão do a distribuição linux, geralmente eu uso debian-8 ou ubuntu-14, não testei outros desde que sempre os achei disponíveis. As etapas de configuração seguem
garantir suporte https para downloads
baixar uma versão do Busybox
instalar um farm de links de busybox
determinar endereços ipv4 / ipv6 para configuração de rede
garantir recursos de chroot
baixe a imagem do pinho e extraia-a
se VM
flash sobre o dispositivo alvo
montar sobre um dispositivo de loop
escrever a configuração da rede local sobre o para ser relampejado rootfs
se contêiner
copie o serviço init (para contêineres) sobre o ponto de montagem raiz principal/sbin/init
se VM
particionar a sobra do disco com padrão (xfs ) partições
desmontar
verificar a integridade das partições
reinício
Eu fiz pinho 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 servidores que tendem a oferecer recursos ultrabaixo, na verdade, eu tenho uma caixa funcionando com apenas64M de RAM e ainda ter todos os recursos de que preciso.
| [1] | sistema de arquivos raiz |
