
Hoje em dia, muitas empresas operam sem a capacidade de gerenciar diretamente a composição de pacotes de repositórios externos, mesmo que usem mirroring, proxy e caching. Isso leva ao fato de que o ambiente de execução muda constantemente, em particular, a composição das imagens docker muda com mais frequência do que a produção exige.
Existem situações em que alterações indesejadas contidas em dependências externas podem entrar na composição do produto que está sendo desenvolvido. Isso é especialmente verdadeiro durante a certificação do produto. Como resultado, atrasos na certificação, testes noturnos e falhas nos testes de integração, interrupção da produção local (um ambiente de produção localizado nos próprios recursos da organização) ao executar um hotfix e assim por diante. Em um novo artigo, descrevemos uma abordagem para evitar esses problemas.
O que queríamos alcançar
Antes de começar a descrever a abordagem, algumas palavras sobre as tarefas que queríamos resolver:
- Obtenha controle total sobre a composição de pacotes externos no lançamento (previsibilidade).
- Corrija as composições de repositórios externos para implementação rápida de hotfixes com teste adicional mínimo (velocidade).
- Fornece suporte de QA do produto com um ambiente fixo, previsível e repetível (repetibilidade).
- Independência da presença de canal de comunicação externo (autonomia).
- Mudança instantânea para repositórios oficiais em caso de falha (tolerância a falhas).
- Validação garantida de chaves para repositórios externos em pipelines de montagem (confiança).
- E o mais importante, transfira o gerenciamento e o controle sobre a composição de pacotes externos para as equipes de produto e gerentes de lançamento (autogerenciamento).
Análise do ciclo de vida da criação de recursos
Nossa abordagem resolve o problema de corrigir a composição de repositórios externos para uma data específica, para um lançamento ou um recurso. O diagrama a seguir ilustra o gerenciamento da versão, construção de recursos e ciclo de vida do hotfix.
Vamos pegar o repositório condicional Debian Stretch como exemplo. Essa abordagem é aplicável a repositórios Docker, SaltStack, etc. Três fatias foram registradas na linha do tempo para as datas T1, T2 e T3.

T1 | T2 | T3 | |
---|---|---|---|
esticam | 20200305 | 20200420 | 20200615 |
Feature1 | 20200304 | 20200304 | 20200501 |
Feature2 | 20200304 | 20200304 | 20200601 |
Feature3 | 20200301 | 20200406 | 20200406 |
Tabulamos o conteúdo do repositório Debian Stretch externo para construir as distribuições Feature1, Feature2 e Feature3. Na tabela, você pode ver que a composição do repositório externo é controlada por cada filial de forma independente. Fizemos um acordo para nos comprometermos com o branch master para o Debian Stretch diariamente e marcar cada slice no formato AAAAMMDD, por exemplo 2020304 para o slice de 4 de março de 2020. A tabela resume os instantâneos do repositório externo usado para a distribuição em cada ramo em três pontos diferentes no tempo e a composição no assistente para Debian Stretch. A equipe para cada recurso ou para cada versão atualiza a composição dos repositórios externos a seu critério e de acordo com seu ciclo de desenvolvimento.
Usando o Feature1 como exemplo: a equipe do produto começa a desenvolver um novo recurso e corrige a composição do repositório externo a partir de 20200228 nos arquivos de configuração (veja o diagrama acima).
Mude para 20200228
deb http://repository.co/debian-stretch-20200228 stretch main contrib non-free
Durante o desenvolvimento, devido ao aparecimento de novos pacotes, torna-se necessário atualizar o banco de dados de pacotes para a data 20200304. Mude o repositório de trabalho para a data desejada.
Mude para 20200304
deb http://repository.co/debian-stretch-20200304 stretch main contrib non-free
Em seguida, outra troca da base do pacote para a data 20200501 ocorre.
Mude para 20200501
deb http://repository.co/debian-stretch-20200501 stretch main contrib non-free
Se agora desenharmos intervalos de tempo, veremos que nos pontos de tempo T1 e T2 o desenvolvimento do Feature1 está na base do pacote, "congelado" em 4 de março de 2020 E no corte T3, o desenvolvimento já está em andamento em uma nova base de embalagem para 1º de maio de 2020.
Gerenciamento de dependência multi-lançamento do produto
Agora, vamos examinar o gerenciamento de dependências para vários lançamentos de produtos ativos. Existem três versões de suporte, 2.5, 2.6 e 2.7.
Na tabela, vemos a correspondência de releases e datas para as quais o instantâneo do repositório foi feito. Mostra qual instantâneo da composição do repositório externo foi usado para construir uma versão específica da distribuição.

Lançamento | Composição |
---|---|
2.5.128, 2.5.135, 2.5.207 | 20200301 |
2.6.201, 2.6.215, 2.6.315 | 20200301 |
2.7.210, 2.7.217, 2.7.305 | 20200404 |
Em vez de nomear fatias por datas AAAAMMDD, também usamos nomenclatura de tag no formato <ProjectName.ReleaseVersion> (release_name.release_version do produto, por exemplo name.2.2) ou <ProjectName-FeatureNumber> (adicione um número de recurso, por exemplo 3).
Snapshot para 2.5 a partir de 20200301
deb http://repository.co/debian-stretch-projectname-2.5 stretch main contrib non-free # 20200301
Assim, durante o desenvolvimento da versão 2.5, a equipe corrige a composição dos repositórios dependentes a partir de 20200301. Em algum momento de abril, a equipe inicia uma nova versão 2.6 e decide usar a composição dos pacotes do repositório externo a partir do 2.5. Crie um novo instantâneo 2.6 a partir do instantâneo 2.5. No futuro, os repositórios para versões 2.5 e 2.6 podem divergir facilmente. Fizemos nossa própria tag debian-stretch-projectname-2.6 para 2.6.
Instantâneo para 2.6 a partir de 20200301
deb http://repository.co/debian-stretch-projectname-2.6 stretch main contrib non-free # 20200301
No caso da versão 2.7, a equipe pode iniciar o desenvolvimento a partir do branch master - um instantâneo diário do repositório original.
Instantâneo para 2.7 em 20200404
deb http://repository.co/debian-stretch-projectname-2.7 stretch main contrib non-free # 20200404
Gerenciamento de dependência de vários produtos
Vejamos o gerenciamento de dependência de vários produtos usando o exemplo de dois produtos com diferentes ciclos de lançamento e suas próprias equipes de produto: Stealth e Infiniti.

Vamos comentar na mesa o que acontece e quando.
produtos | Lançamento | Composição |
---|---|---|
stealth2.2 | r2.2.124 | 20200301 |
stealth2.2 | r2.2.131, r2.2.162 | 20200305 |
infiniti4.0 | r4.0.235, r4.0.241 | 20200303 |
infiniti4.0 | r4.0.250 | 20200308 |
1. Vamos iniciar o desenvolvimento da versão 2.2 do projeto Stealth em 1º de março de 2020, para isso foi criado um instantâneo da composição do banco de dados de pacotes para a data atual. O lançamento do release 2.2.124 é feito com a base de pacotes do repositório externo de 20200301.
Stealth 2.2
deb http://repository.co/debian-stretch-stealth-2.2 stretch main contrib non-free # 20200301
2. No quinto dia, a base de pacotes é atualizada. O repositório de trabalho debian-stretch-stealth-2.2 muda instantaneamente para a data desejada, o lançamento das versões 2.2.131 e 2.2.162 é feito com os pacotes de repositório externo de 20200305. Sem manipulações adicionais no ambiente, todos os 100500 microsserviços do produto receberam instantaneamente um novo ambiente no pipeline de montagem 20200305 ...
Stealth 2.2
deb http://repository.co/debian-stretch-stealth-2.2 stretch main contrib non-free # 20200305
3. Paralelamente ao terceiro dia, o desenvolvimento do projeto Infiniti versão 4.0 começa e uma fatia da composição do repositório para a data 20200303 é criada para ele. As versões 4.0.235 e 4.0.241 são lançadas com os pacotes de repositórios externos para 20200303.
Infiniti 4.0
deb http://repository.co/debian-stretch-infiniti-4.0 stretch main contrib non-free # 20200303
4. Após o lançamento da versão 4.0.241 a equipe decide atualizar a composição do repositório para 20200308 e lançar uma nova versão com uma nova composição de pacotes externos. A versão 4.0.250 é lançada com pacotes de pacotes para 20200308.
Infiniti 4.0
deb http://repository.co/debian-stretch-infiniti-4.0 stretch main contrib non-free # 20200308
Duas opções para alternar entre os estados dos repositórios permitem que você escolha uma abordagem que seja conveniente para o processo de desenvolvimento. No primeiro caso, mudamos para o estado desejado especificando um instantâneo dos repositórios em uma data específica. No segundo caso, para produtos com vários componentes, usamos uma fatia nomeada e a movemos para a data desejada. Este mecanismo fornece uma comutação de corte única em todos os 100500 componentes do produto.
Gerenciamos as fatias de cada repositório externo em um contêiner Docker separado, portanto, a qualquer momento, podemos alternar um repositório específico para baixar da rede externa no caso de alguns acidentes.
Baixe uma lista de todos os repositórios
# For example
curl repository.co/info/sources.list | grep $(lsb_release -cs) > /etc/apt/sources.list
Criação automática de fatias de repositórios externos
Os repositórios são atualizados todas as noites de acordo com o agendador GitLab. Quando um novo repositório é adicionado, as alterações são aplicadas automaticamente ao servidor.

No momento de comprometer um novo slice do repositório externo, seu certificado é verificado, se for diferente do salvo conosco, então a atualização não ocorre e recebemos uma mensagem de erro.
Resultado
- Preparar uma nova versão de um kit de distribuição para certificação não é mais uma dor de cabeça. Para o período de certificação, corrigimos a composição da distribuição, e se você precisar consertar algo prontamente, então com grande probabilidade não haverá erros no hotfix lançado devido a mudanças no ambiente.
- Todas as compilações de recursos obtêm o estado gerenciado de repositórios externos.
- A implementação de Hotfix e a verificação de QA são aceleradas com um resultado previsível, rápido e bem-sucedido.
- Feature- , .
- .
Observe que o Debian tem um recurso oficial snapshot.debian.org com snapshots diários e armazenamento profundo. Para certas tarefas, isso é suficiente.
Agradecimentos a Sergey Smirnov e à comunidade por uma excelente ferramenta para gerenciar a composição dos repositórios externos do Aptly. De nós - uma pequena contribuição para as melhores práticas de uso desta ferramenta útil em transportadores de produção.
Nos próximos artigos, falaremos sobre o pacote Aptly + Simple-CDD para preparar imagens ISO de distribuições, delegar o gerenciamento de dependências externas às equipes de produto e os problemas de usar o Aptly no processo de gerenciamento de dependências externas.
Autores : Nikita Drachev , Alexander Pazdnikov , Timur Gilmullin