nexus-guide.md

Guia de configuração Nexus Repository Manager

Repositório de artefatos Nexus Repository Manager 3.

A instalação é feita utilizando a imagem docker oficial do nexus. Guias e documentações:

• Nexus Repository Manager OSS
• Documentação Nexus Repository Manager 3
• Docker Hub Nexus 3

Aplicação Nexus

Health check

Uma vez instalado o nexus, é possivel verificar o status de inicialização executando a requisição:

curl -u admin:admin123 http://localhost:8081/service/metrics/ping

O usuário e senha padrão do nexus é admin/admin123.

Nexus console

A interface do nexus é acessivél através do endereço:

http://localhost:8081

Estrutura de diretórios

• Diretório de instalação: /opt/sonatype/nexus
• Dados: /nexus-data

O diretório nexus-data depende do path configurado no momento de provisionamento, mapeado como volume na inicialização do container.

OrientDB Console

Caso necessário interagir com o banco de dados utilizado pelo Nexus, é necessário conectar no container e então acessar o console do OrientDB.

Conectar no container

docker ps --filter "name=nexus"
docker exec -it <container-id> bash

Conectar no OrientDB

cd /opt/sonatype/nexus
java -jar ./lib/support/nexus-orient-console.jar

Gerenciamento e configuração de repositórios

Abaixo, algumas dicas de configurações e informações úteis.

Blob Stores

Os repositórios do nexus são armazenados em estruturas internas chamadas blob stores. Por padrão, a instalação do nexus possui um blob store default. Por padrão os blob stores são localizados no diretório blobs do diretório nexus-data configurado na inicialização. Ex. de localização do blob store default:

/nexus-data/blobs/default

Para configurar blob stores acesse o menu Repository > Blob Stores.

Observações

1- Blob stores podem ser do tipo file (armazenado localmente) ou s3 (armazenados no aws s3). O recomendado é utilizar o tipo s3 apenas se o nexus for instalado em estruturas da aws.

2- Uma vez defino o path do blob store, este não pode ser alterado. Caso extremamente necessário, mas não recomendado, é possível realocar o blob store.

3- IMPORTANTE: Como o nexus é utilizado em um container docker, todo blob store criado deve ter seu path mapeado como volume na inicialização do docker. Ex.:

• Blob store: proxy-repos
• Path: /tmp/proxy-repos
• Script docker: docker run ... -v /host/dir:/tmp/proxy-repos

4- Criar blob stores além do default possibilita segmentar os repositórios, configurar cotas de espaço em disco exclusivas e realizar backups separados. Repositórios de proxy de repositórios públicos podem ser armazenados em um blob store separado dos repositórios dos artefatos privados por exemplo. Existe uma api rest para obter informações sobre a quota utilizada (caso habilitado) pelo blob store. Ex.:

curl http://localhost:8081/service/rest/v1/blobstores/{name}/quota-status

Cleanup Policies

Caso necessário é possível configurar políticas de expurgo de artefatos nos repositórios. Isso é feito através de Cleanup policies.

Para configurar cleanup policies acesse o menu Repository > Cleanup Policies.

Observações

1- Ao criar a policy e associar à um ou mais repositórios, a execução da rotina de expurgo é feita através da task Admin - Cleanup repositories using their associated policies.

2- Cleanup policies executam soft delete, ou seja, os artefatos não são removidos do disco. Para liberar espaço em disco de fato é necessário criar e executar uma task do tipo Admin - Compact blob store.

Tasks

É possível configurar rotinas (jobs) para serem executados pelo nexus, definindo agendamento, execução manual e habilitando/desabilitando elas.

Para configurar tasks acesse o menu System > Tasks.

Algumas Tasks importantes a serem consideradas são:

• Admin - Cleanup repositories using their associated policies: responsável por executar cleanup policies associadas a repositórios.
• Admin - Compact blob store: responsável por apagar do disco os artefatos removidos por soft delete.
• Admin - Export databases for backup: realização de backup da base de dados do nexus, com suas configurações, configurações de repositórios, blob stores, etc.
• Repair - Rebuild Yum repository metadata: reconstrói o metadata de um repositório yum. Sempre que um rpm é armazenado ou removido em um repositório do nexus, essa task é executada.

Repositories

Repositórios podem ser dos seguintes tipos:

• Hosted: para armazenamento dos artefatos produzidos pela organização.
• Proxy: atua como proxy de um repositório remoto, fazendo cache dos artefatos do mesmo. Isso pode reduzir a latência para obter dependências de terceiros por exemplo. É possível invalidar o cache e reconstruir o indice de busca desses repositórios.
• Group: agrupamento de repositórios de qualquer tipo para um único ponto de acesso.

No repositório são associados, entre outros, o blob store, uma cleanup policy (opcional) e uma deployment policy (opcional). Deployment policies permitem que um artefato seja atualizado no repositório sem promover sua versão. Por padrão não é possível sobrescrever um artefato.

Para configurar repositórios acesse o menu Repository > Repositories.

Observações:

1- Uma vez criado, não é possível alterar o blob store de um repositório. 2- Para repositórios yum do tipo Group é necessário que todos os repositórios no grupo tenham o mesmo nível de profundidade na localização do diretório repodata. Os repositórios abaixo não podem ser agrupados pois não possuem o mesmo nivel de profundidade, por exemplo:

• centos/7/x86_64/repodata
• centos/7/updates/x86_64/repodata

Maiores informações na documentação oficial.

Segurança

Users

Por padrão o nexus possui dois usuários locais configurados para acesso: admin e anonymous.

Para gerenciar usuários locais, acesse o menu Security > Users.

Nesse menu também é possível gerenciar usuários de outros meios de autenticação, como usuários de ldap. É possível pesquisá-los e editar as roles associadas a eles.

Anonymous

Por padrão o nexus permite acesso anônimo para visualizar o conteúdo dos repositórios e obter os artefatos.

É possível também configurar o usuário para acesso anônimo e o tipo de autenticação/realm. Por exemplo: uma conta de usuário guest do ldap com as permissões devidas para acesso anônimo.

Para desabilitar o acesso anônimo acesse o menu Security > Anonymous.

Realms

Realms determinam os tipos de autenticação utilizados no nexus. Por padrão é utilizado a autenticação de usuários locais cadastrados no nexus (realms Local Authenticating Realm e Local Authorizing Realm).

Caso queira utilizar autenticação através de um servidor ldap, basta configurá-lo e habilitar o realm LDAP Realm.

Para configurar os realms acesse o menu Security > Realms.

Observações:

1- É recomendado deixar o realm de autenticação local habilitado mesmo utilizando outros realms. Assim, mesmo que o outro provedor de acesso esteja fora será possível acessar o console de administração do nexus com um usuário local (admin por exemplo).

LDAP

É possível controlar o acesso ao nexus autenticando os usuários através de um servidor de ldap. Uma vez configurado a conexão, basta pesquisar pelo usuário no menu Security > Users e configurar as roles de permissões de acesso.

É possível também criar roles de permissões para grupos de usuários do ldap mapeando os mesmos no momento de cadastro da conexão.

Para configurar conexões com servidores ldap acesse o menu Security > LDAP. Mais detalhes na documentação.

Privileges

Privileges controlam o acesso e as Actions que podem ser feitas em um item do nexus. Um item pode ser por exemplo um repositório ou uma feature do nexus (blob store por exemplo).

Privileges são agrupados em roles para formar as permissões associadas aos usuários para garantir acesso a determinado componente.

Por exemplo, para um repositório maven myrepo, podemos ter associado o privilege nx-repository-view-mavem-myrepo-read com permissão apenas de leitura (action read).

As actions variam de acordo com o tipo do privilege. São elas:

• add, browse, create, delete, edit, read, update, *.

Os tipos de privileges mais comuns são:

• Application: features do nexus.
• Repository Admin: administração e configuração de um repositório.
• Repository View: acesso ao conteúdo de um repositório.

Outros tipos: Repository Content Selector, Script e Wildcard.

Observações:

1- Não é comum criar novos privileges, visto que quando um repositório é criado, automaticamente são gerados todos os privileges dos tipos Repository Admin e Repository View para cada action.

Para visualizar e configurar privileges acesse o menu Security > Privileges.

Roles

Roles são agrupamentos de privileges e outras roles. São elas que são associadas aos usuários dando permissões para acessar os recursos e artefatos do nexus. Por exemplo, podemos criar a role "ruby developers admin" com privilege do tipo Repository Admin e action * para o repositório "ruby-gems". Assim usuários com essa role terão acesso de admin nesse repositório.

É possível também mapear grupos do ldap como roles utilizadas pelo nexus, associando grupos com privileges e outras roles. Por exemplo, podemos ter um grupo no ldap "ruby developers admin" e criar uma role com privilege do tipo Repository Admin e action * para o repositório "ruby-gems". Assim, usuários que pertençam a esse grupo terão acesso de admin nesse repositório.

REST API

Nexus possui uma api rest para interagir com o repositório através do endereço {host}/service/rest/v1. Para mais informações sobre os recursos da api rest, acesse o menu System > API no console do nexus.

Embora o acesso dependa das permissões que o usuário possui, caso deseje bloquear o acesso por completo à api rest, pode ser adicionado uma configuração no nginx semelhante a essa:

server{
  location /service/rest/*$ {
      deny all;
      return 404;
    }
}

Backup

O processo de backup do nexus consiste em:

• blob store: processo manual, consiste em realizar o backup dos diretórios de blob store cadastrados no nexus.
• database: através da execução da Task Admin - Export databases for backup configurada no menu System > Tasks.

O restore deve ser tanto do blob store quando da database, restores parciais não funcionam. Mais detalhes sobre o processo de restore e a localização dos arquivos de backup na documentação.

Outros

Logs de acesso

Menu System > Recent Connections.

Configuração de tempo de sessão

Menu System > Capabilities, acesse a config UI: Settings e edite o campo Session timeout na aba Settings.

Autenticação em repositórios npm

Para utlizar repositórios npm com autenticação, habilitar o realm npm Bearer Token Realm

Health check

É possível criar um usuário específico apenas para monitoramento, com permissão de acesso nas rotas de health check. Siga os passos abaixo para criar um usuário com essas características:

• Crie uma Role com o Privilege nx-metrics-all. Ex.: nx-monitor.
• Crie um User e associe a Role criada a ele. Ex.: devops
• Realize o health check com as credenciais do User criado. Ex.:

curl -u devops:devops123 http://localhost:8081/service/metrics/ping

Roles customizadas

Estrutura básica das roles: (role-name)-(repo-type)-(repo-name)-(action). Ex.: nx-repository-view-rubygem-xyz-read

Abaixo alguns exemplos de roles e privileges necessários para as necessidades básicas:

• nx-repo-browse (somente leitura para todos os repositórios)

nx-repository-view-*-*-browse
nx-search-read

• nx-repo-read (download de conteúdo para todos os repositórios)

nx-repository-view-*-*-read
nx-repository-view-*-*-browse
nx-search-read

• nx-repo-content-admin (gerenciar conteúdo de todos os repositórios)

nx-repository-view-*-*-*
nx-search-read

Exemplo de configuração de repositórios

• 1 blob store para cada tipo de artefato (gems, npm, jar, yum)
• 1 blob store para armazenar todos os repositórios proxy
• 1 repositório hosted onde serão publicados os artefatos
• 1 repositório group para leitura englobando o hosted e possível repositório proxy

Exemplos de acesso a repositórios com autenticação

• gem

bundle config --local repo.url <usuario>:<senha>

• npm

npm login --registry=https://repo.url/repository/my-repo/

• yum

Criar um arquivo .repo em /etc/yum.repos.d/

[nexus-repo]
name=Repo hosted on nexus
baseurl=https://repo.url/repository/my-repo
enabled=1
gpgcheck=0
username=<usuario>
password=<senha>

Exemplo de publicação de rpm em repositório yum com autenticação

curl -v --user '<usuario>:<senha>' --upload-file <file>.rpm https://repo.url/repository/my-repo/<path>/<file>.rpm