A Canonical publicou uma nova versão do sistema de gerenciamento de containers LXD 5.20, que se destaca pela mudança na licença do projeto e pela introdução da necessidade de assinatura do acordo CLA para a transferência dos direitos sobre o código ao aceitar alterações no LXD. A licença do código adicionado ao LXD por funcionários da Canonical foi alterada de Apache 2.0 para AGPLv3, enquanto o código de colaboradores externos, sobre o qual a Canonical não possui direitos, permanece sob Apache 2.0. Como a Canonical não tem a capacidade de alterar a licença de todo o código LXD, o projeto agora será fornecido sob condições mistas — parte do código sob AGPLv3 e parte sob Apache 2.0. A transição para a nova licença é explicada pelo desejo de unificar a licença com outros produtos de servidor da Canonical, que utilizam AGPLv3.
O código das versões anteriores continua disponível sob a licença Apache 2.0, mas todas as alterações feitas nos componentes relançados serão publicadas apenas sob a licença AGPLv3, o que impedirá o fork do Incus de transferir alterações do LXD sem migrar sua base de código para a licença AGPLv3. As licenças Apache 2.0 e AGPLv3 têm compatibilidade unilateral, que se resume ao fato de que o código sob a licença Apache 2.0 pode ser incorporado ao código sob a licença AGPLv3, mas não o contrário. A mudança significa o fim total da colaboração entre os projetos LXD e Incus, pois a nova licença impede a transferência de alterações do LXD para o Incus, e a necessidade de assinatura do acordo CLA, que os desenvolvedores do Incus não pretendem assinar, bloqueia a transferência de alterações do Incus para o LXD.
Uma característica da licença AGPLv3 é a introdução de restrições adicionais para aplicações que suportam o funcionamento de serviços de rede. Ao usar componentes AGPL no funcionamento de serviços de rede, o desenvolvedor é obrigado a fornecer ao usuário o código-fonte de todas as alterações feitas nesses componentes, mesmo que o software subjacente do serviço não seja distribuído e seja utilizado exclusivamente na infraestrutura interna para a organização do funcionamento do serviço. A licença AGPL também impõe condições de copyleft, ou seja, para incluir código AGPL do LXD em seu projeto, a base de código de seu próprio projeto deve ser relançada sob a licença AGPL.
LXD fornece ferramentas para gerenciamento centralizado de contêineres e máquinas virtuais implantadas em um cluster de múltiplos servidores. O LXD é implementado como um processo em segundo plano que recebe solicitações pela rede através da API REST e suporta vários backends de armazenamento (árvore de diretórios, ZFS, Btrfs, LVM), snapshots com instantâneas de estado, migração ao vivo de contêineres em execução de uma máquina para outra e ferramentas para armazenamento de imagens de contêineres. O runtime para execução de contêineres utiliza o conjunto de ferramentas LXC, que inclui a biblioteca liblxc, um conjunto de utilitários (lxc-create, lxc-start, lxc-stop, lxc-ls, etc.), templates para construir contêineres e um conjunto de ligações para várias linguagens de programação. A isolação é realizada através dos mecanismos padrão do kernel Linux (namespaces, cgroups, Apparmor, SELinux, Seccomp). Além do LXC, o LXD também utiliza componentes dos projetos CRIU e QEMU.
Entre os recursos adicionados no LXD 5.20:
- Durante a criação de pools de armazenamento com base no Cephfs, foi adicionada a capacidade de criar metadados e dados para pools OSD (Object Storage Daemon), usando os parâmetros cephfs.create_missing, cephfs.meta_pool e cephfs.data_pool. Por exemplo: lxc storage create mypool cephfs source=cephfs \ cephfs.create_missing=true \ cephfs.data_pool=xyz_data \ cephfs.meta_pool=xyz_meta
- No pacote snap do LXD, foi adicionada a possibilidade de configurar a prioridade de inicialização de diferentes discos ao usar o modo security.csm.
- Um modo de depuração foi adicionado ao firmware EDK2 UEFI (boot.debug_edk2=true) para diagnosticar problemas de inicialização máquinas virtuais. O log de depuração é salvo no arquivo $LXD_DIR/logs/<instance_name>/edk2.log.
- O código de autorização foi reorganizado em uma base modular, permitindo o suporte ao OpenFGA além da autorização baseada em certificados TLS e Canonical RBAC.
- Para compilar o LXD, agora é necessário ter pelo menos a versão 1.20 da linguagem Go.
- O suporte ao Shiftfs foi removido. O mapeamento de identificadores de usuários deve usar o montante com idmap, suportado para Ext4, XFS, Btrfs, ZFS e Cephfs.
- O suporte a firmwares UEFI de 2MB foi removido (é necessário usar firmwares de 4MB).
- Do código-fonte do fork Incus, foi transferido o suporte para a criação de armazenamentos baseados na tecnologia NVME. Para indicar o tipo de disco, um novo parâmetro de configuração "io.bus" foi adicionado, que por padrão é definido como "virtio-scsi". Ao alterar o valor para "nvme", o armazenamento na máquina virtual será reconhecido como NVME SSD.
- Do código-fonte do fork Incus, foi transferido o suporte para conexão e desconexão a quente (hot-plug/hot-remove) de caminhos de arquivos ou partições individuais, passados a partir do ambiente do hospedeiro. Anteriormente, esse tipo de conexão com o driver virtio-fs ou FS 9p exigia a parada da máquina virtual. Para contornar essa limitação, foi utilizada a capacidade do QEMU de conectar a quente dispositivos PCI e montar caminhos dentro do sistema convidado através do incus-agent.
- O identificador do dispositivo org.linuxcontainers.lxd foi renomeado para com.canonical.lxd (para manter a compatibilidade com versões anteriores, o suporte ao identificador antigo foi mantido).
Fonte: opennet.ru
