[ad_1]
GitLabGenericName é uma plataforma líder para hospedar repositórios Git, pipelines de CI e Fluxos de trabalho de DevOps. Está disponível como uma oferta SaaS em GitLab.com ou como uma distribuição autogerenciada para uso privado em seu próprio {hardware}.
O GitLab é um sistema complexo formado a partir de uma teia de componentes e dependências distintas. A instalação de pacotes GitLab diretamente em seu sistema operacional adicionará novos serviços pesados à sua máquina, incluindo PostgreSQL, Redis, Gitaly e o foremost aplicativo da internet GitLab baseado em Rails.
A implantação do GitLab como um contêiner do Docker é uma maneira de evitar poluir seu ambiente com todos esses componentes. Tudo relacionado ao GitLab ficará dentro do contêiner, separadamente do sistema de arquivos do seu host.
Neste guia, usaremos o Docker para implantar uma instância do GitLab pronta para produção que você pode usar para hospedar seu código-fonte e colaborar em projetos. Uma coisa a considerar antes de prosseguir é que o Docker não elimina o GitLab requisitos básicos de {hardware}: você precisará de pelo menos 4 GB de RAM livre e cerca de 10 GB de armazenamento não utilizado.
A imagem oficial do Docker
O GitLab oferece um imagem do Docker pré-criada que vem com tudo que você precisa para implantar o tool. Estamos nos concentrando nesta imagem neste educational, mas vale a pena prestar atenção às suas limitações.
A imagem é monolítica por natureza, agrupando todos os componentes do GitLab para que sejam executados em um único contêiner. Isso simplifica a configuração, mas torna difícil dimensionar sua instalação no futuro. Vai contra práticas recomendadas de conteinerização executando vários componentes distintos no contêiner.
Isso significa que a imagem de estoque pode não ser superb para instalações ocupadas. Como alternativa, você pode usar o GitLab’s Carta do leme para implantar em um cluster Kubernetes. Isso inicia cada serviço como seu próprio pod em contêiner para que você possa dimensionar os componentes individualmente.
Implantando o GitLab com o Docker
Instalar o Docker e configure um registro DNS A para seu nome de domínio GitLab antes de continuar. Você deve apontar o registro DNS para o endereço IP do seu host Docker. Nós vamos usar gitlab.instance.com como o domínio no restante deste guia.
Você pode iniciar o GitLab executando o seguinte comando:
docker run -d -p 22:22 -p 80:80 -p 443:443
--name gitlab
--hostname gitlab.instance.com
--restart unless-stopped
--shm-size 256m
-v gitlab_config:/and many others/gitlab
-v gitlab_logs:/var/log/gitlab
-v gitlab_data:/var/choose/gitlab
gitlab/gitlab-ce:14.7.0-ce.0
O Docker baixará a imagem do GitLab Group Version (CE) e iniciará um novo contêiner usando-a. É uma prática recomendada fixar em uma versão específica do GitLab selecionando sua tag de imagem correspondente, 14.7.0-ce.0 nesse caso. Aqui está uma explicação dos sinalizadores usados no comando:
-d– Desconecte o terminal do contêiner para que ele seja executado em segundo plano.-p– Vincule as portas 22, 80 e 443 do contêiner às portas correspondentes em seu host; isso permite que o GitLab receba Git e tráfego da Internet por SSH e HTTP/S quando direcionado ao seu host.--name– Atribua um nome amigável ao contêiner para que você possa referenciá-lo convenientemente ao executar comandos da CLI do Docker no futuro.--hostname– Defina o nome do host do contêiner; isso deve corresponder ao domínio que você está usando para acessar o GitLab.--restart– Atribua ao recipiente um política de reinício por isso é reiniciado automaticamente quando sai devido a uma falha ou reinicialização do host.--shm-size– Isso é explicado na próxima sessão.-v– Configuração Volumes do Docker para armazenar persistentemente os arquivos de configuração, logs e dados de usuário gerados do GitLab fora do contêiner. Isso é essential para que você não perca seus dados quando o container parar!
Aguarde alguns minutos para que a configuração de primeira execução do GitLab seja concluída. Eventualmente, você deve ser capaz de visitar gitlab.instance.com para ver a página de login. Entrar como root; a senha da conta é gerada automaticamente e pode ser recuperada executando o seguinte comando:
docker exec -it <gitlab-container-name> grep 'Password:' /and many others/gitlab/initial_root_password
Substituto <gitlab-container-name> com o nome que você atribuiu ao criar seu contêiner. Isso foi gitlab no exemplo acima.
Investigando problemas de implantação
É standard que os scripts de instalação demorem muito para serem concluídos. O GitLab tem muitos componentes para configurar antes que o serviço comece a funcionar. Você pode monitorar o progresso por visualizando os logs do contêiner:
docker logs gitlab --follow
O melhor curso de ação se a interface do usuário da internet do GitLab não estiver disponível é simplesmente esperar um pouco mais e deixar o procedimento de configuração ser executado até a conclusão. Se algo deu errado, você está vendo 500 erros em seu navegador e os logs do contêiner não estão mostrando novas atividades, reiniciando o contêiner com docker restart gitlab às vezes pode ajudar.
Uma mensagem de erro comum que você pode ver nos logs é semelhante a esta:
writing worth to /dev/shm/gitlab/... failed with unmapped dossier
Isso ocorre porque os serviços empacotados com o GitLab gravam quantidades significativas de dados no arquivo temporário. /dev/shm sistema de arquivo. O Docker aloca apenas contêineres a /dev/shm espaço de 64 MB por padrão. Isso raramente é suficiente para sustentar a coleção de métricas do GitLab by the use of Prometheus, responsável pela maioria das gravações no sistema de arquivos.
A capacidade de /dev/shm pode ser aumentado usando o --shm-size sinalizar quando você cria seu contêiner com docker run. Isso é mostrado no exemplo de implantação acima, onde 256 MB são alocados, o mínimo recomendado pelo GitLab. Instalações muito ativas podem precisar usar um tamanho maior.
Outro problema diz respeito aos arquivos de log do GitLab: eles rapidamente se tornam expansivos, o que pode causar buffer overflow detected erros ao iniciar o Docker. Isso pode ser evitado limpando periodicamente os arquivos antigos no /var/log/gitlab diretório de dentro do seu contêiner GitLab:
docker exec -it gitlab rm /var/log/gitlab/*
Os arquivos de log que o Docker coleta dos fluxos de saída do contêiner e retém em seu host também crescerão rapidamente para tamanhos grandes. Padrão do Docker json-file o driving force de armazenamento de log é inadequado para uso com uma instância do GitLab de produção. Os arquivos JSON que ele cria são pesados, detalhados e nunca compactados ou girados. Mudar para outro driving force de armazenamento tal como native ou journald para garantir que os logs sejam alternados regularmente.
Configurando o GitLab
Você pode fornecer o GitLab trechos de arquivo de configuração quando você cria seu contêiner definindo o GITLAB_OMNIBUS_CONFIG variável de ambiente. Esta deve ser uma string Ruby válida que será anexada ao /and many others/gitlab/gitlab.rb arquivo dentro do container:
docker run -e GITLAB_OMNIBUS_CONFIG="gitlab_rails['allowed_hosts'] = ['gitlab.example.com]; nginx['redirect_http_to_https'] = true;"
Você também pode editar /and many others/gitlab/gitlab.rb de dentro do contêiner quando ele estiver em execução. Quando terminar de fazer as alterações, reinicie o contêiner para aplicá-las:
docker restart gitlab
A imagem do GitLab Docker executa automaticamente o Omnibus reconfigurar script cada vez que começa. Isso pega a configuração atual do seu gitlab.rb e aplica-o à sua instalação. É standard que o GitLab fique inacessível por alguns segundos após a reinicialização do contêiner enquanto esse processo é concluído.
Aplicando atualizações do GitLab
As atualizações do GitLab são facilmente aplicadas interrompendo seu contêiner e iniciando um novo com a mesma configuração.
Puxe a nova imagem correspondente à versão do GitLab escolhida:
docker pull gitlab/gitlab-ce:14.7.1-ce.0
Remova seu contêiner existente:
docker rm gitlab
Por fim, inicie um novo contêiner, repetindo seus sinalizadores originais, mas modificando a referência da imagem:
docker run -d -p 22:22 -p 80:80 -p 443:443
--name gitlab
...
gitlab/gitlab-ce:14.7.1-ce.0
Seus dados estarão intactos, pois os volumes do contêiner antigo serão reanexados ao novo.
Você pode evitar a repetição de seu docker run sinalizadores encapsulando sua configuração em um docker-compose.yml Arquivo:
model: "3" services and products: gitlab: symbol: gitlab/gitlab-ce:14.7.0-ce-0 hostname: gitlab.instance.com ports: - 22:22 - 80:80 - 443:443 volumes: gitlab_config:/and many others/gitlab gitlab_logs:/var/log/gitlab gitlab_data:/var/choose/gitlab restart: unless-stopped volumes: gitlab_config: gitlab_logs: gitlab_data:
Ao usar o Docker Compose, você pode abrir sua instância do GitLab executando docker-compose up -d. Para atualizar para uma nova versão, altere o symbol campo de acordo e repita o comando. O Docker Compose automatizará o processo de substituição do contêiner.
Independentemente do mecanismo que você united states of america, é importante certificar-se de que seus caminhos de atualização estejam alinhados com Rotas suportadas pelo GitLab. Ocasionalmente, pode ser necessário realizar ações manuais após a atualização para concluir a migração.
Fazendo backup de sua instalação
Backups regulares são essenciais para uma implantação bem-sucedida do GitLab. A função típica do GitLab como a única fonte de verdade da sua organização significa que, no pior cenário, todo o seu trabalho pode desaparecer para sempre, a menos que sejam feitos backups.
GitLabGenericName tem um utilitário de backup integrado que pode ser usado para criar um arquivo completo de sua instalação. Isso é acessível na imagem do Docker por meio do gitlab-backup comando:
docker exec -t gitlab gitlab-backup create
Os backups são salvos no /var/choose/gitlab/backups diretório por padrão. Isso significa que eles serão armazenados fora do contêiner, em um de seus volumes Docker montados. Para maior segurança, você deve configurar o GitLab para fazer add de backups para um provedor de armazenamento de objeto remoto adicionando estas linhas ao seu arquivo de configuração:
gitlab_rails['backup_upload_connection'] = "supplier" => "AWS", "area" => "eu-west-1", "aws_access_key_id" => "access_key", "aws_secret_access_key" => "secret_key", # "endpoint" => "https://..."
Agora o gitlab-backup create O comando carregará automaticamente os arquivos que ele gera, mantendo-os separados do contêiner do GitLab e do host do Docker. Seu último passo deve ser adicionando um cron tarefa em seu sistema que executa periodicamente o script de backup:
0 * * * * docker exec -t gitlab gitlab-backup create
Resumo
O GitLab é um tool complexo que é facilmente implantado com o Docker. O docker run O exemplo mostrado neste guia é adequado para uso em produção quando combinado com as alterações de configuração de práticas recomendadas explicadas acima. Você também deve auditar o segurança do daemon do Docker e seu host para garantir a proteção adequada de seus dados.
Uma implantação do GitLab Dockerized é uma boa maneira de testar rapidamente a plataforma. Também é uma estratégia eficaz para lançar e manter um servidor GitLab menor para uso a longo prazo. Outras opções como GitLab Omnibus em um servidor dedicado ou um instalação do Kubernetes nativa da nuvem geralmente são mais adequados para requisitos maiores e adoção corporativa sustentada.
[ad_2]
Fonte da Notícia
