# Etapa 9

NGINX é o servidor web oficialmente suportado pelo GitLab. Se você não pode ou não quer usar o NGINX como seu servidor web, consulte [GitLab recipes](https://gitlab.com/gitlab-org/gitlab-recipes/).

### Instalação

```
sudo apt-get install -y nginx
```

### Configuração do Site

Copie a configuração do site de exemplo:

```
sudo cp lib/support/nginx/gitlab /etc/nginx/sites-available/gitlab
sudo ln -s /etc/nginx/sites-available/gitlab /etc/nginx/sites-enabled/gitlab
```

Certifique-se de editar o arquivo de configuração para corresponder à sua configuração. Além disso, certifique-se de corresponder seus caminhos ao GitLab, especialmente se estiver instalando para um usuário que não seja o usuário git:

```
# Altere YOUR_SERVER_FQDN para o totalmente qualificado
# nome de domínio do seu host que atende o GitLab.
#
# Lembre-se de combinar seus caminhos com o GitLab, especialmente
# se estiver instalando para um usuário diferente de 'git'.
#
# Se estiver usando a instalação nginx padrão do Ubuntu:
# remova o default_server da linha de escuta
# ou então sudo rm -f /etc/nginx/sites-enabled/default
sudo editor /etc/nginx/sites-available/gitlab
```

Se você pretende habilitar o GitLab Pages, há uma configuração NGINX separada que você precisa usar. Leia tudo sobre a configuração necessária no [GitLab Pages administration guide](https://docs.gitlab.com/ee/administration/pages/index.html).

Se você quiser usar HTTPS, substitua a configuração gitlab NGINX por gitlab-ssl. Ver [Using HTTPS](https://docs.gitlab.com/ee/install/installation.html#using-https) para detalhes de configuração HTTPS.

Para que o NGINX possa ler o soquete GitLab-Workhorse, você deve garantir que o usuário www-data possa ler o soquete, que pertence ao usuário GitLab. Isso é alcançado, se for legível por todo o mundo, por exemplo, se tiver permissões 0755, que é o padrão. www-data também deve ser capaz de listar os diretórios pai.

### Configuração de teste

Valide seu arquivo de configuração gitlab ou gitlab-ssl NGINX com o seguinte comando:

```
sudo nginx -t
```

Você deve receber mensagens de sintaxe correta e teste bem-sucedido. Se você receber mensagens de erro, verifique se há erros de digitação no arquivo de configuração gitlab ou gitlab-ssl NGINX, conforme indicado na mensagem de erro fornecida.

Verifique se a versão instalada é superior a 1.12.1:

```
nginx -v
```

Se for menor, você pode receber o erro abaixo:

```
nginx: [emerg] Desconhecido "start$temp=[filtered]$rest" Variável
nginx: configuration file /etc/nginx/nginx.conf test failed
```

### Restart

```
# Para sistemas executando systemd
sudo systemctl restart nginx.service

# Para sistemas executando SysV init
sudo service nginx restart
```

### Pós-instalação

### Verifique novamente o status do aplicativo

Para garantir que você não perdeu nada, faça uma verificação mais completa com:

```
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production
```

Se todos os itens estiverem verdes, parabéns pela instalação bem-sucedida do GitLab!

Forneça a variável de ambiente SANITIZE=true para gitlab:check para omitir nomes de projetos da saída do comando check.

### Login inicial

Visite YOUR\_SERVER em seu navegador da web para seu primeiro login no GitLab.

Se você não [forneceu uma senha de root durante a instalação](/gitlab-no-ubuntu/instalacao-e-configuracao-source/etapa-8.md#inicializar-banco-de-dados-e-ativar-recursos-avancados), será redirecionado para uma tela de redefinição de senha para fornecer a senha da conta de administrador inicial. Digite a senha desejada e você será redirecionado de volta para a tela de login.

O nome de usuário da conta padrão é root. Forneça a senha que você criou anteriormente e faça o login. Após o login, você pode alterar o nome de usuário, se desejar.

### Aproveitar!

Para iniciar e parar o GitLab ao usar:

* unidades systemd: use `sudo systemctl start gitlab.target` ou `sudo systemctl stop gitlab.target`.
* O script de inicialização do SysV: use `sudo service gitlab start` ou `sudo service gitlab stop`.

### Instale a documentação do produto

Este é um passo opcional. Veja como [self-host the product documentation](https://docs.gitlab.com/ee/administration/docs_self_host.html).

### Advanced Setup Tips

#### Relative URL support

Veja a [Relative URL documentation](https://docs.gitlab.com/ee/install/relative_url.html) para obter mais informações sobre como configurar o GitLab com uma URL relativa.

### Usando HTTPS

Para usar o GitLab com HTTPS:

1. Em gitlab.yml:
   1. Defina a opção de porta na seção 1 para 443.
   2. Defina a opção https na seção 1 como true.
2. No config.yml do GitLab Shell:
   1. Defina a opção gitlab\_url para o endpoint HTTPS do GitLab (por exemplo, `https://git.example.com`).
   2. Defina os certificados usando a opção ca\_file ou ca\_path.
3. Use a configuração de exemplo gitlab-ssl NGINX em vez da configuração do gitlab.
   1. Atualize SEU\_SERVIDOR\_FQDN.
   2. Atualize ssl\_certificate e ssl\_certificate\_key.
   3. Revise o arquivo de configuração e considere a aplicação de outros recursos de aprimoramento de segurança e desempenho.

O uso de um certificado autoassinado não é recomendado. Se você precisar usar um, siga as instruções padrão e gere um certificado SSL autoassinado:

```
   mkdir -p /etc/nginx/ssl/
   cd /etc/nginx/ssl/
   sudo openssl req -newkey rsa:2048 -x509 -nodes -days 3560 -out gitlab.crt -keyout gitlab.key
   sudo chmod o-r gitlab.key
```

### Ativar resposta por e-mail

Veja em [“Reply by email” documentation](https://docs.gitlab.com/ee/administration/reply_by_email.html) para obter mais informações sobre como configurar isso.

### Autenticação LDAP

Você pode configurar a autenticação LDAP em config/gitlab.yml. Reinicie o GitLab após editar este arquivo.

### Usando provedores OmniAuth personalizados

Veja em [OmniAuth integration documentation](https://docs.gitlab.com/ee/integration/omniauth.html).

### Construa seus projetos

O GitLab pode construir seus projetos. Para habilitar esse recurso, você precisa que os corredores façam isso por você. Consulte a seção [GitLab Runner](https://docs.gitlab.com/runner/) para instalá-lo.

### Adicionando seus Proxies Confiáveis

Se você estiver usando um proxy reverso em uma máquina separada, talvez queira adicionar o proxy à lista de proxies confiáveis. Caso contrário, os usuários aparecem conectados a partir do endereço IP do proxy.

Você pode adicionar proxies confiáveis ​​em config/gitlab.yml personalizando a opção Trusted\_proxies na seção 1. Salve o arquivo e [reconfigure GitLab](https://docs.gitlab.com/ee/administration/restart_gitlab.html) para que as alterações entrem em vigor.

### Conexão Redis personalizada

Se você deseja se conectar a um servidor Redis em uma porta não padrão ou em um host diferente, pode configurar sua string de conexão por meio do arquivo config/resque.yml.

```
# Exemplo
production:
  url: redis://redis.example.tld:6379
```

Se você deseja conectar o servidor Redis via soquete, use o esquema unix: URL e o caminho para o arquivo de soquete Redis no arquivo config/resque.yml.

```
# Exemplo
production:
  url: unix:/path/to/redis/socket
```

Além disso, você pode usar variáveis ​​de ambiente no arquivo config/resque.yml:

```
# Exemplo
production:
  url: <%= ENV.fetch('GITLAB_REDIS_URL') %>
```

### Conexão SSH personalizada

Se você estiver executando o SSH em uma porta não padrão, deverá alterar a configuração SSH do usuário do GitLab.

```
# Add to /home/git/.ssh/config
host localhost          # Give your setup a name (here: override localhost)
    user git            # Your remote git user
    port 2222           # Your port number
    hostname 127.0.0.1; # Your server name or IP
```

Você também deve alterar as opções correspondentes (por exemplo, ssh\_user, ssh\_host, admin\_uri) no arquivo config/gitlab.yml.

### Estilos de Marcação Adicionais

Além do estilo Markdown sempre suportado, existem outros arquivos rich text que o GitLab pode exibir. Mas você pode ter que instalar uma dependência para fazer isso. Veja o [`github-markup` gem README](https://github.com/gitlabhq/markup#markups) Para maiores informações.

### Usando o Sidekiq em vez do Sidekiq Cluster

A partir do GitLab 12.10, as instalações do Source estão usando bin/sidekiq-cluster para gerenciar os processos do Sidekiq. O uso direto do Sidekiq ainda é suportado até a versão 14.0. Portanto, se você estiver enfrentando problemas:

1. Edite o script init.d do sistema para remover o sinalizador SIDEKIQ\_WORKERS. Se você tiver /etc/default/gitlab, deverá editá-lo.
2. Restart GitLab.
3. [Create an issue](https://gitlab.com/gitlab-org/gitlab/-/issues/-/new) Descrevendo o problema.

### Configuração do servidor Prometheus

Você pode configurar o servidor Prometheus em config/gitlab.yml:

```
# example
prometheus:
  enabled: true
  server_address: '10.1.2.3:9090'
```


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://liedsons-organization.gitbook.io/gitlab-no-ubuntu/instalacao-e-configuracao-source/etapa-9.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
