Escolha a camada de colaboração
Forgejo e Gitea são exemplos de software de forge leve; o Git SSH simples pode ser suficiente para um fluxo de trabalho menor. Alinhe issues, revisões, armazenamento de pacotes e requisitos de identidade ao projeto. Verifique as versões e licenças atualmente suportadas.
Separe as compilações da forja
Um runner de CI executa código controlado pelo projeto e não deve deter credenciais irrestritas do forge ou do host. Isole os runners, restrinja os tokens e evite executar tarefas não confiáveis na mesma conta privilegiada que o serviço do repositório.
Proteja o acesso e o registo
Desative o registo público quando o serviço for privado. Use contas individuais, autenticação forte e chaves de implementação cuidadosamente limitadas. Documente a porta SSH e a chave do host; não treine os utilizadores, sem aviso, para ignorarem avisos de chave do host.
Faça cópia de segurança do serviço completo
Apenas os repositórios podem não incluir issues, contas, anexos e configuração. Siga o procedimento de backup consistente do forge e teste uma restauração com as permissões de arquivo e os segredos da aplicação intactos.
Uma lista de verificação para recuperação de forge
Exporte o banco de dados de forma consistente e preserve o armazenamento do repositório, anexos, armazenamento de arquivos grandes se habilitado, configuração e segredos de criptografia. Verifique um clone pela rota SSH ou HTTPS pretendida após a restauração. Mantenha o forge e qualquer worker de CI isolados para que uma build não possa reescrever a própria configuração do serviço.
Mantenha os direitos de implementação restritos
Uma chave de implementação só de leitura pode ser suficiente para um servidor que apenas obtém código. Uma automatização de lançamento pode precisar de um pequeno âmbito adicional. Prefira chaves independentes para máquinas diferentes, registe o seu propósito e remova-as quando a máquina for desativada.
Utilize o serviço de colaboração mais pequeno que se adequa
Para alguns repositórios privados, Git bare sobre SSH restrito pode ser suficiente. Forgejo ou Gitea adiciona contas, pull requests, issues e pacotes opcionais ao custo de um banco de dados, atualizações de aplicação e mais estado persistente. Registre quais recursos a equipe realmente usará. Dimensione separadamente o crescimento dos repositórios, objetos de arquivos grandes, anexos e artefatos de build; a computação de CI pode exceder o próprio forge.
- Escolha um nome HTTPS canônico e proteja sua conta DNS.
- Decida se o cadastro é fechado, por convite ou moderado.
- Atribua ao serviço de forge uma identidade sem privilégios e armazenamento privado durável.
Documentação oficial: Instalação do contentor Forgejo
Separe os caminhos da web, SSH e do banco de dados
Utilize a configuração upstream para a versão selecionada e fixe a versão de imagem pretendida. Um reverse proxy TLS deve alcançar o listener web interno; a base de dados deve ser acessível apenas pela forge. Se o Git SSH utilizar uma porta de contentor, mantenha o host anunciado e a porta externa coerentes com o mapeamento. Não substitua nem exponha acidentalmente o listener SSH do administrador do host ao alterar a forge. Feche o acesso de instalação/configuração assim que o proprietário inicial for criado.
- Verifique a propriedade do volume persistente antes de iniciar a aplicação.
- Utilize um utilizador de base de dados restrito à base de dados da forge.
- Mantenha os runners de CI em um limite de confiança separado, especialmente para repositórios não confiáveis.
Documentação oficial: Rede e persistência do Forgejo em Docker
Verifique clone, push e uma operação negada
Crie um repositório privado descartável e teste seu clone HTTPS ou SSH URL a partir de uma conta de desenvolvedor normal. Faça commit e push de um arquivo inofensivo, depois verifique se outro leitor autorizado consegue buscá-lo. Uma conta não convidada deve falhar ao ler o repositório privado. Verifique o tratamento de arquivos grandes e o e-mail de notificação, se habilitado. Para máquinas de implantação apenas, teste se uma chave somente leitura consegue buscar e não consegue fazer push; um sucesso de autenticação sozinho não prova o limite de permissão pretendido.
# Use the disposable repository URL advertised by your forge:
git clone ssh://[email protected]:2222/team/check.git
# In a clone, inspect which remote is configured:
git remote -vRecupere a discussão, bem como o repositório
Faça uma cópia de segurança consistente da aplicação/base de dados, do armazenamento do repositório, dos anexos, dos dados LFS, da configuração e dos segredos de encriptação necessários. Siga o procedimento de cópia de segurança da versão de forge instalada; os comandos de cópia de segurança do Gitea não são automaticamente intercambiáveis com todas as versões do Forgejo. Reconstrua em isolamento e verifique um problema, um anexo, o início de sessão e um clone. Se o push falhar após uma mudança, verifique o host/porta SSH, o mapeamento de chaves, as permissões de armazenamento e os URLs de clone anunciados antes de alterar globalmente as permissões do repositório.
Documentação oficial: Backup e restauro do Gitea