Construindo imagens de sistema operacional
O OpenFactory transforma uma receita normalizada em artefato de imagem e, quando solicitado e disponível, inicializa esse artefato para verificação. Os builders e estágios exatos variam por família de imagem base e deployment.
O que uma receita controla
| Área | Localização canônica | Pergunta de revisão |
|---|---|---|
| Base e intenção de hardware | base_image, hardware | Esta é a distribuição, release, arquitetura e perfil mínimo corretos? |
| Features e pacotes | os.features, os.packages | As capacidades solicitadas estão presentes e suportadas nesta base? |
| Serviços e contas | os.services, os.users | Configuração e acesso com menor privilégio estão explícitos? |
| Desktop e branding | os.desktop_settings, os.branding | O desktop selecionado possui essas configurações e assets? |
| Instalador e persistência | os.installer, os.persistence | Requisitos de install-to-disk e persistência foram de fato testados? |
| Automação personalizada | os.startup_scripts, anexos, pacotes de origem | As entradas estão fixadas, limitadas e seguras para rodar como o usuário declarado? |
| Verificação | scenarios | Os testes observam todo resultado material, não só boot? |
Veja Recipe Schema para o formato completo.
Ciclo de vida do build
O stream público de status pode incluir planning, configuration, trabalho de source-package, geração de imagem, finalização e testes. Não há garantia de que apareçam como estágios nomeados idênticos para todo alvo. Siga o ID de build retornado pelo pedido de start e trate o status atual do backend como autoritativo.
Mantenha estes resultados separados:
validatedsignifica que o formato reconhecido da receita foi aceito;- um build terminal bem-sucedido significa que um artefato foi finalizado;
- sucesso nos testes significa que as asserções selecionadas passaram no ambiente delas; e
- certificação ou publicação, quando habilitadas, é uma decisão de política posterior.
Progresso silencioso não é motivo para criar build duplicado. Reconecte ao console de build ou endpoint de status usando o mesmo ID de build. Se o build falhar terminalmente, preserve estágio, erro e logs antes de tentar de novo.
Fluxo recomendado
- Escreva critérios de aceitação observáveis.
- Gere ou edite a receita.
- Valide e compare o resultado normalizado com a conversa completa.
- Inspecione features inferidos, fontes externas, configurações de instalador e cenários.
- Inicie um build e siga seu ID durável.
- Revise digest do artefato, inventário de pacotes, avisos e evidências de teste.
- Inicialize ou instale em ambiente descartável adequado ao pedido.
- Promova ou publique apenas pelo gate de aprovação aplicável.
Guias por tópico
| Tópico | Use para |
|---|---|
| Imagens base | Selecionar uma família de build suportada |
| Features | Entender módulos de capacidade registrados |
| Serviços | Declarar configuração de serviço |
| Software personalizado | Revisar entradas de pacote respaldadas por repositório |
| Usuários | Criar contas locais à imagem com segurança |
| Desktop | Escolher e verificar configurações de desktop |
| Scripts de startup | Autorar units first-boot limitadas |
Comece com a imagem útil mais pequena. Adicione features só depois de entender comportamento e evidências do artefato anterior.