- Release notes
- Lei de direito autoral
- 1 Introdução
- 2 Requisitos
- 3 Instalação usando o Rancher UI
- 4 Instalação usando a linha de comando
- 5 Alta Disponibilidade configuração
- 6 Configure Rancher como um Provedor de Identidade OIDC
- 7 Perguntas frequentes
- 8 Solução de problemas
- A Substituindo o gráfico SUSE Private Registry Helm
- B Exemplo de um Registro Privado gráfico de configuração HA Helm
- C Licença GFDL (GNU Free Documentation License)
- C1 0. PREÂMBULO
- C2 1. APLICABILIDADE E DEFINIÇÕES
- C3 2. CÓPIAS LITERAIS
- C4 3. COPIANDO EM QUANTIDADE
- C5 4. MODIFICAÇÕES
- C6 5. COMBINANDO DOCUMENTOS
- C7 6. COLEÇÕES DE DOCUMENTOS
- C8 7. AGREGAÇÃO A TRABALHOS INDEPENDENTES
- C9 8. TRADUÇÕES
- C10 9. REVOGAÇÃO
- C11 1. REVISÕES FUTURAS DESTA LICENÇA
- C12 ADENDO: Como usar esta Licença em seus documentos
Release notes #
SUSE Private Registry is an on-premises container registry. It is designed for SUSE customers who need a container registry that works well with other SUSE services and products.
This document provides a high-level overview of the features, capabilities and limitations of SUSE Private Registry, and highlights important product updates.
1 Release 1.2.0 #
Security updates:
Updates Harbor 2.14.3 to 2.15.1 (Release Notes v2.15.1).
Updates Trivy version 0.68.2 to 0.70.0 with adapter v0.36.0 general availability (GA) (Release Notes v0.70.0).
Component updates:
Updates
k8s.io/client-goto 0.34.1.Updates
aws-sdk-goto 1.55.8.Updates
go-ldapto 3.4.11.Updates Go to 1.25.9.
New features and performance:
Adds support for the Cosign v3 Bundle signature format.
Introduces an option to disable audit log recording to the database during initialization.
Enables pprof support and the ability to export the Harbor version via the Prometheus exporter binary.
Replaces the existing pull-through cache with a new proxy cache implementation.
Improves general performance through code refactoring (for example, by using
strings.Builderandstrings.CutPrefix).
Key fixes:
Implements a security fix to reject bearer tokens issued before project creation.
Fixes issues related to OpenID Connect (OIDC) integration for users with a single group.
Corrects errors in user and group search functionality.
Resolves various user interface (UI) issues, including an unwanted scrollbar in tag retention and issues with the "Copy Pull Button" when tags are undefined.
Adds support for both
docker-composev1 anddocker-composev2.Calls the
/v2/auth/tokenapplication programming interface (API) to get a bearer token for the Docker Hub adapter.
Container image updates:
private-registry/harbor-core:1.1.2 ➡ private-registry/1.2/harbor-core:1.2.0
private-registry/harbor-exporter:1.1.2 ➡ private-registry/1.2/harbor-exporter:1.2.0
private-registry/harbor-jobservice:1.1.2 ➡ private-registry/1.2/harbor-jobservice:1.2.0
private-registry/harbor-portal:1.1.2 ➡ private-registry/1.2/harbor-portal:1.2.0
private-registry/harbor-registry:1.1.2 ➡ private-registry/1.2/harbor-registry:1.2.0
private-registry/harbor-registryctl:1.1.2 ➡ private-registry/1.2/harbor-registryctl:1.2.0
private-registry/harbor-trivy-adapter:1.1.2 ➡ private-registry/1.2/harbor-trivy-adapter:1.2.0
Helm chart updates:
The chart is the version 1.2.x will be in oci://registry.suse.com/private-registry/1.2/private-registry-helm
Makes health probe
timeoutSecondsandfailureThresholdconfigurable via values.Fixes extra environment variables for the exporter.
Installs
PodDisruptionBudgetresources when the replica count is greater than one.
Upgrade notes:
No breaking changes in this release.
2 Release 1.1.3 #
Security updates:
Updates Harbor 2.14.2 to 2.14.4 (Release Notes v2.14.4).
Updates Trivy version 0.68.2 to 0.70.0 with adapter v0.36.0 (Release Notes v0.70.0).
Key fixes:
Fixed SessionRegenerate arguments/lifetime and prevented background polling from artificially renewing session TTLs.
Fixes scanner application programming interface (API) issues and resolves an issue that occurs when editing distribution instances without credentials.
Calls the
/v2/auth/tokenAPI to get a bearer token for the Docker Hub adapter.Bumped Go to version 1.25.9 and upgraded the OpenTelemetry SDK and go-jose packages.
Container image updates:
private-registry/harbor-core:1.1.2 ➡ private-registry/harbor-core:1.1.3
private-registry/harbor-exporter:1.1.2 ➡ private-registry/harbor-exporter:1.1.3
private-registry/harbor-jobservice:1.1.2 ➡ private-registry/harbor-jobservice:1.1.3
private-registry/harbor-portal:1.1.2 ➡ private-registry/harbor-portal:1.1.3
private-registry/harbor-registry:1.1.2 ➡ private-registry/harbor-registry:1.1.3
private-registry/harbor-registryctl:1.1.2 ➡ private-registry/harbor-registryctl:1.1.3
private-registry/harbor-trivy-adapter:1.1.2 ➡ private-registry/harbor-trivy-adapter:1.1.3
suse/postgres:17.9 ➡ suse/postgres:17.10
suse/nginx:1.21 ➡ suse/nginx:1.27
Upgrade notes:
No breaking changes in this release.
3 Release 1.1.2 #
Security Updates:
CVE-2026-4404: Use of hard coded credentials allows attackers to use the default password and gain access to the Web UI, if not set during installation or upgrade.
Now if the HARBOR_ADMIN_PASSWORD is not set during the installation or upgrade, it will be generated randomly and stored in a Kubernetes secret.
This change mitigates the risk of using a default password and enhances the security of the installation.
Upgrade Notes:
No breaking changes in this release.
4 Release 1.1.1 #
Security Updates:
Update Harbor 2.14.1 to 2.14.2 (Release Notes v2.14.2)
Trivy version update 0.67.2 to 0.68.2 (Release Notes v0.68.2)
Container Image Updates:
private-registry/harbor-core:1.1.0 ➡ private-registry/harbor-core:1.1.1
private-registry/harbor-exporter:1.1.0 ➡ private-registry/harbor-exporter:1.1.1
private-registry/harbor-jobservice:1.1.0 ➡ private-registry/harbor-jobservice:1.1.1
private-registry/harbor-portal:1.1.0 ➡ private-registry/harbor-portal:1.1.1
private-registry/harbor-registry:1.1.0 ➡ private-registry/harbor-registry:1.1.1
private-registry/harbor-registryctl:1.1.0 ➡ private-registry/harbor-registryctl:1.1.1
private-registry/harbor-trivy-adapter:1.1.0 ➡ private-registry/harbor-trivy-adapter:1.1.1
Upgrade Notes:
No breaking changes in this release.
5 Release 1.1.0 #
Security Updates:
Updated Harbor 2.13.2 to 2.14.1 (Release Notes v2.14.1)
Container Image Updates:
Update the base image bci/bci-micro:15.6 to bci/bci-micro:15.7
Updated images:
private-registry/harbor-valkey:8.0.6 ➡ suse/valkey:8.0.6
private-registry/harbor-db:2.13.2 (postgres 17) ➡ suse/postgres:17.6
private-registry/harbor-nginx:1.21 ➡ suse/nginx:1.21
Upgrade Notes:
Images are now tagged with the SUSE Private Registry version instead of the corresponding Harbor version. The change in image versioning scheme is handled by Helm when upgrading the installation using the chart:
private-registry/harbor-core:1.1.0
private-registry/harbor-exporter:1.1.0
private-registry/harbor-jobservice:1.1.0
private-registry/harbor-portal:1.1.0
private-registry/harbor-registry:1.1.0
private-registry/harbor-registryctl:1.1.0
private-registry/harbor-registryctl:1.1.0
No breaking changes in this release.
6 Release 1.0.1 #
Security updates:
CVE-2025-55198: Helm may panic due to incorrect YAML content.
CVE-2025-55199: Helm charts with specific JSON schema values can cause memory exhaustion.
CVE-2025-54410: Moby versions before 25.0.13, when firewall reloads, Docker fails to re-create iptables rules isolating bridge networks. This allows any container to access all ports on any other container across different bridge networks on the same host and breaks network segmentation in multi-tenant environments (only
--internalnetworks remain protected).CVE-2025-29923: go-redis allows potential out of order responses when
CLIENT SETINFOtimes out during connection establishment.CVE-2025-54388: Moby versions 28.2.0–28.3.2 fails to re-create iptables rules after a firewall reloads. This exposes containers with localhost-published ports (e.g., 127.0.0.1:8080) to remote access via the Docker bridge, while unpublished ports remain protected; fixed in version 28.3.3.
GHSA-2464-8j7c-4cjm: go-viper’s map structure may leak sensitive information in logs when processing malformed data.
CVE-2025-8959: HashiCorp go-getter vulnerable to arbitrary read through a symlink attack.
CVE-2025-58058: github.com/ulikunitz/xz leaks memory when decoding a corrupted multiple LZMA archives.
CVE-2025-53547: Helm chart dependency updating with malicious Chart.yaml content and symlink can lead to code execution.
Bugs fixed:
Trivy: the correct version is shown when calling
trivy version.
Container image updates:
Valkey updated from 8.0.2 ➡ 8.0.6.
Upgrade notes:
No breaking changes in this release.
7 Release 1.0 #
Key features:
SUSE Private Registry is based on Harbor 2.13.2
Integration with Model Spec for first-class handling of AI models
Enhanced audit logging
Predictable release cycle aligned with SUSE Rancher Prime. SUSE Private Registry will be updated every 4 months
Each release is supported by SUSE for 18 months from the date of release
6 months of security and bug fix maintenance, followed by
12 months of security-only maintenance
Can be used to mirror SUSE Coleção de Aplicativos
Supports SUSE Segurança as an external scanner
SUSE Private Registry includes all the features of Harbor:
On-premises private container image and OCI artifact registry
Web interface for administration
Role-based Access Control
Fine-grained project configuration for image and artifact storage
Mirroring and pull-through caching of upstream registries' artifacts
Image retention and garbage collection controls
Scanning images for security vulnerabilities with the Trivy scanner
Generate SBOMs for stored images
Content trust with Cosign (Notary is not included)
Lei de direito autoral #
Copyright © 20XX–2026-07-09 SUSE LLC e colaboradores. Todos os direitos reservados.
Permissão concedida para copiar, distribuir e/ou modificar este documento sob os termos da Licença GNU de Documentação Livre, Versão 1.2 ou (por sua opção) versão 1.3; com a seção invariante sendo estas informações de copyright e licença. Uma cópia da versão 1.2 da licença está incluída na seção intitulada 'GNU Free Documentation License'.
Para marcas SUSE, veja https://www.suse.com/company/legal/. Todas as marcas registradas de terceiros pertencem aos seus respectivos proprietários. Os símbolos de marca registrada (®, ™ etc.) indicam marcas registradas de SUSE e de suas afiliadas. Os asteriscos (*) indicam marcas registradas de terceiros.
Todas as informações deste manual foram compiladas com a maior atenção possível aos detalhes. Entretanto, isso não garante uma precisão absoluta. Nem SUSE LLC, nem suas afiliadas, nem os autores, nem os tradutores serão responsabilizados por possíveis erros ou pelas consequências resultantes.
1 Introdução #
1.1 O que é o comando SUSE Private Registry? #
SUSE Private Registry (Registro Privado) é um registro de contêiner no local. Registro Privado é projetado para clientes SUSE que precisam de um registro de contêiner que funcione bem com outros serviços e produtos SUSE.
1.2 Quais são os benefícios de SUSE Private Registry? #
Registro Privado é baseado no projeto Harbor e inclui todos os seus recursos principais, além de benefícios adicionais. Por exemplo:
Registro de contêiner no local. Registro Privado é um registro de contêiner hospedado localmente com acesso a serviços de registro SUSE online.
Segurança. Registro Privado oferece considerações de segurança para ambientes conteinerizados. Inclui autenticação, autorização e varredura de vulnerabilidades.
Flexibilidade de implantação. Você pode instalar Registro Privado em um ambiente Kubernetes como SUSE Rancher Prime: RKE2. Você também pode implantar Registro Privado com configuração de alta disponibilidade.
Gerenciamento de usuários. Registro Privado fornece um mecanismo de autenticação e autorização com controle de acesso com base em função (RBAC).
Interface do usuário. Além de uma interface de linha de comando, você pode administrar Registro Privado via interface web do usuário.
1.3 Como funciona o SUSE Private Registry? #
Registro Privado é entregue como Open Container Initiative (OCI) containers e é esperado que seja implantado em um cluster Kubernetes. Registro Privado consiste nos seguintes contêineres:
harbor-core: o componente principal do registro Harbor, responsável por gerenciar funcionalidades principais, como gerenciamento de projetos, repositórios e interações de usuários.
harbor-db: o contêiner de banco de dados que armazena todos os metadados relacionados a imagens, usuários e configurações para o registro Harbor.
harbor-jobservice: um serviço que gerencia trabalhos em segundo plano, como replicação de imagens e tarefas agendadas, garantindo processamento eficiente de operações dentro do registro.
harbor-nginx: o proxy reverso e balanceador de carga que roteia solicitações recebidas para os serviços Harbor apropriados, fornecendo um único ponto de entrada para os usuários.
harbor-portal: a interface web que permite aos usuários interagir com o registro Harbor, gerenciar imagens e configurar as configurações por meio de uma interface gráfica.
harbor-registry: o contêiner que serve como o back end de armazenamento real de imagens, lidando com o armazenamento e recuperação de imagens de contêiner.
harbor-registryctl: uma ferramenta de linha de comando para gerenciar o registro Harbor, permitindo que os usuários realizem tarefas administrativas e configurações diretamente do terminal.
harbor-trivy-adapter: um contêiner que integra o Trivy scanner de vulnerabilidades com Harbor, permitindo a varredura de segurança automatizada de imagens de contêiner em busca de vulnerabilidades.
harbor-exporter: o contêiner que exporta Harbor métricas em um formato que pode ser coletado por Prometheus para monitoramento e observabilidade.
harbor-valkey: um armazenamento de chave-valor em memória.
Após a implantação, você pode fazer login via interface web. Após a autenticação e autorização bem-sucedidas, você pode configurar múltiplos aspectos do produto, por exemplo:
Configure configurações globais, como definir o registro para modo somente leitura ou restringir quem pode criar projetos.
Selecione um método de autenticação.
Adicione usuários quando estiver no modo de autenticação de banco de dados e atribua o papel de administrador a outros usuários.
Aplique quotas de recursos aos projetos.
Configure a replicação de imagens entre instâncias Registro Privado.
1.4 Para obter mais informações #
Consulte as seguintes fontes para obter mais detalhes:
A página inicial do projeto Harbor está em https://goharbor.io/.
O uso de Harbor está detalhado em https://goharbor.io/docs.
2 Requisitos #
Esta seção descreve os pré-requisitos mínimos da plataforma e o dimensionamento de produção recomendado para SUSE Private Registry.
2.1 Pré-requisitos #
Versão 1.20 ou superior do Kubernetes cluster
HelmVersão 3.2.0 ou superior
Suporte a provisionador de Volume Persistente (PV) em sua infraestrutura
Uma assinatura ativa para SUSE Private Registry
2.2 Recomendações de hardware e dimensionamento #
Use esses valores como um ponto de partida para a produção. Ajuste com base na política de retenção, rotatividade de imagens, concorrência de varredura e tráfego de replicação. ==== Linha de Base do Cluster
| Escopo | Ponto de partida recomendado |
|---|---|
Nós de trabalho | Mínimo de 3 nós de trabalho |
Formato do nó | Mínimo de 4 vCPU e 16 GiB de RAM por nó |
Formato de nó preferido | 8 vCPU e 32 GiB de RAM por nó para maior concorrência de varredura e de push |
Essas recomendações estão alinhadas com a orientação do Rancher para o RKE2 Kubernetes. Para detalhes, veja Requisitos de instalação do RKE2 Kubernetes.
2.2.1 Linha de Base de Armazenamento Persistente #
| Componente | Tamanho padrão do gráfico | Tamanho de partida recomendado |
|---|---|---|
Dados do registro | 5 Gi | 500 Gi a 1 Ti |
Cache e DB do Trivy | 5 Gi | 20 Gi a 50 Gi |
Registros do Jobservice | 1 Gi | 10 Gi |
PostgreSQL Interno (se utilizado) | 1 Gi | Mínimo de 20 Gi |
Valkey Interno (se utilizado) | 1 Gi | Mínimo de 20 Gi |
Os padrões do gráfico são orientados para instalação e não devem ser usados como valores de capacidade de produção a longo prazo.
3 Instalação usando o Rancher UI #
Para instalar SUSE Private Registry usando o Rancher UI, você deve atender aos seguintes requisitos e seguir os passos abaixo.
3.1 Quais requisitos preciso atender? #
Um ambiente com um ou mais clusters Kubernetes suportados em execução e Rancher implantado. Consulte Rancher requisitos de instalação para mais detalhes.
Credenciais SUSE Registro para uma conta com uma assinatura SUSE Private Registry (um nome de usuário e uma senha/token). Consulte Obtendo Kubernetes segredos de SCC para mais detalhes.
3.2 Quais são os passos para instalar SUSE Private Registry usando o Rancher UI? #
Faça login no Rancher.
Clique no menu de três linhas (☰) no canto superior esquerdo, selecione , e clique no nome do seu cluster, geralmente
local.No menu à esquerda, selecione › .
Clique no botão no canto superior direito e preencha o formulário que se abre:
Destino: Selecione .
Nome: Digite um nome para o repositório, como
SUSE Private Registry.Descrição: Opcionalmente, adicione uma descrição do repositório.
URL do Host do Repositório OCI: Enter `oci://registry.suse.com/private-registry/private-registry-helm`.
Autenticação: Altere para
Create an HTTP Basic Auth Secrete insira o nome de usuário e a senha das credenciais do registro.
Confirme com .
Clique no menu de três linhas (☰) no canto superior esquerdo e selecione .
Mude para o cluster ao qual você deseja adicionar o segredo e clique em .
Para navegar até o gerenciamento de segredos, selecione › e clique em no canto superior direito.
Selecione o segredo e, em seguida, o namespace
private-registry.Digite
suse-registrycomo o nome do segredo.Preencha os campos
usernameepasswordcom as credenciais SUSE obtidas em Section 3.1, “Quais requisitos preciso atender?”.
No menu principal à esquerda, selecione › .
Digite o nome do SUSE Private Registry repositório atribuído na caixa de pesquisa. Por exemplo,
SUSE Private Registry. Se não aparecer na lista, clique em .Clique no chart e visualize o
README.md.Opcionalmente, você pode personalizar os valores de instalação. Ou clique nas seções do lado esquerdo do painel
Edit Optionspara visualizar todos os valores que você pode configurar, ou edite os valores diretamente no arquivo YAML do chart.No canto superior direito, clique em .
4 Instalação usando a linha de comando #
Os seguintes procedimentos descrevem como implantar SUSE Private Registry (Registro Privado) em um cluster Kubernetes.
4.1 Obtendo segredos de Kubernetes do SUSE Atendimento ao Cliente #
Para baixar e instalar as imagens de Registro Privado do SUSE Registro, você precisa de um segredo Kubernetes com as credenciais de espelhamento SUSE Atendimento ao Cliente (SCC). Para obter as credenciais de SCC, siga estes passos:
Visite SUSE Atendimento ao Cliente em https://scc.suse.com e faça login.
Selecione a organização com uma assinatura ativa de Registro Privado na barra lateral esquerda.
Selecione
Proxiesno menu superior. As credenciais são exibidas no canto superior direito.Para ver a senha, clique no ícone de 'olho'.
Crie um arquivo
password.txtcontendo a senha obtida.>head -1 ./password.txt | helm registry login registry.suse.com \ --username <PRIVATE_REGISTRY_USERNAME> --password-stdinCrie um namespace para SUSE Registro.
>kubectl create namespace <PRIVATE_REGISTRY_NAMESPACE>Armazene as credenciais de espelhamento recuperadas de SCC como segredos Kubernetes executando o seguinte comando:
>kubectl create secret docker-registry suse-registry \ --namespace <PRIVATE_REGISTRY_NAMESPACE> \ --docker-server=registry.suse.com \ --docker-username=<PRIVATE_REGISTRY_USERNAME> \ --docker-password=$(head -1 ./password.txt)Opcionalmente, para usar comunicação criptografada por TLS, crie um segredo TLS a partir de seus arquivos de chave privada e certificado.
>kubectl create secret tls suse-registry-tls \ --namespace <PRIVATE_REGISTRY_NAMESPACE> \ --cert=<CERTIFICATE>.pem \ --key=<PRIVATE_KEY>.pem
4.2 Instalando e executando Registro Privado usando Helm #
O seguinte procedimento descreve como instalar Registro Privado usando Helm.
Substitua <RELEASE_NAME> pelo seu nome de lançamento personalizado para a implantação do gráfico Helm.
Faça login em SUSE Registro usando as credenciais de espelhamento SCC obtidas.
>head -1 ./password.txt | helm registry login registry.suse.com \ --username <SUSE_REGISTRY_USERNAME> --password-stdinInstale a versão mais recente do gráfico Registro Privado Helm.
>helm install <RELEASE_NAME> \ oci://registry.suse.com/private-registry/private-registry-helm \ --namespace <PRIVATE_REGISTRY_NAMESPACE>Quando você instala o gráfico Registro Privado Helm, ele exibe a seguinte saída:
NOTES: CHART VERSION: 1.1.6 It may take several minutes for the SUSE Private Registry 1.1.2 deployment to complete. Once the deployment has finished, you will be able to open the SUSE Private Registry portal at https://core.harbor.domain To get the admin credentials, copy and run the following commands: echo Username: "admin" echo Password: $(kubectl get secret --namespace <PRIVATE_REGISTRY_NAMESPACE>-harbor-core <RELEASE_NAME> -o jsonpath="{.data.HARBOR_ADMIN_PASSWORD}" | base64 -d)Com a versão 4 do Helm, você pode usar um digest para especificar o gráfico a ser instalado:
>helm install <RELEASE_NAME> \ oci://registry.suse.com/private-registry/private-registry-helm@sha256:<DIAGEST_OF_CHART_TO_INSTALL> \ --namespace <PRIVATE_REGISTRY_NAMESPACE>
Para obter a senha do usuário administrador, você também pode executar o seguinte comando:
>kubectl get secret \ --namespace <PRIVATE_REGISTRY_NAMESPACE> \ --harbor-core <RELEASE_NAME> \ -o jsonpath="{.data.HARBOR_ADMIN_PASSWORD}" | base64 -d; echoÉ possível usar o kstatus watcher com a flag '--wait=watcher' para garantir que todos os objetos estejam prontos para finalizar a instalação. Usar o watcher pode fazer com que o comando demore mais.
Para substituir a instalação padrão por valores personalizados do arquivo suse_registry_override.yaml, consulte Appendix A, Substituindo o gráfico SUSE Private Registry Helm.
O comando começa a implantar vários contêineres relacionados e pode levar vários minutos para ser concluído. Ele também imprime uma mensagem com a URL do Registro Privado portal Web e comandos para obter as credenciais do administrador.
4.3 Fazer upgrade de Registro Privado #
Para fazer upgrade da versão do gráfico Helm para uma versão mais nova específica, execute o seguinte comando:
>helm upgrade <RELEASE_NAME> \
oci://registry.suse.com/private-registry/private-registry-helm \
--version <NEW_VERSION_OF_HELM_CHART> \
--namespace <PRIVATE_REGISTRY_NAMESPACE> \O digest só é possível com a versão 4 do Helm.
>helm update <RELEASE_NAME> \
oci://registry.suse.com/private-registry/private-registry-helm@sha256:<DIAGEST_OF_CHART_TO_INSTALL> \
--namespace <PRIVATE_REGISTRY_NAMESPACE> \5 Alta Disponibilidade configuração #
Você pode usar Helm para implantar o altamente disponível (HA) Registro Privado em um cluster Kubernetes. O configuração de HA garante que os usuários não experimentem interrupções de serviço se um dos nós em que Registro Privado está sendo executado se tornar indisponível.
5.1 Arquitetura do configuração de HA #
A maioria dos componentes do Registro Privado agora é sem estado. Portanto, podemos escalá-los aumentando as réplicas de pod, garantindo que eles sejam executados em vários nós de trabalho. Kubernetes Os serviços garantem conectividade entre os pods.
Para armazenamento, os usuários devem fornecer um HA PostgreSQL e um cluster Valkey ou Redis para os dados da aplicação, juntamente com PVCs ou armazenamento de objetos para armazenar imagens e gráficos.
image::private-registry-ha.png[Registro Privado configuração de HA, width=100%]. Registro Privado configuração de HA Kubernetes cluster com Ingress em configuração de HA usando HA PostgreSQL e HA Valkey.
5.2 Pré-requisitos #
Um Kubernetes cluster com versão 1.20 ou superior
Helm com versão 3.2.0 ou superior
Controlador HA Ingress (Registro Privado não gerencia o endpoint externo)
HA PostgreSQL 9.6+ (Registro Privado não gerencia a implantação do banco de dados HA)
HA Valkey ou Redis (Registro Privado não gerencia a implantação do HA Valkey ou Redis)
Reivindicação de Volume Persistente (PVC) que pode ser compartilhada entre os nós ou armazenamento de objetos externo
Uma assinatura ativa para SUSE Private Registry
5.3 Implantando Registro Privado com HA #
Baixe o gráfico Registro Privado Helm.
$ helm pull oci://registry.suse.com/private-registry/private-registry-helm --untar
Update the deployment parameters to match your requirements. Refer to Appendix B, Exemplo de um Registro Privado gráfico de configuração HA Helm for an example Helm chart for Registro Privado HA setup. Refer to Appendix A, Substituindo o gráfico SUSE Private Registry Helm for a complete list of values to specify or override.
Install the Registro Privado Helm chart. Replace
<RELEASE_NAME>with your custom release name for the Helm chart deployment.$ helm install <RELEASE_NAME> private-registry-helm/
6 Configure Rancher como um Provedor de Identidade OIDC #
Este guia explica como configurar Rancher para atuar como um Provedor de Identidade OIDC, permitindo que os usuários se autentiquem em aplicativos externos como SUSE Private Registry usando suas credenciais Rancher.
6.1 Etapa 1: Ative a flag de recurso oidc-provider #
Efetue login na interface do Rancher como administrador.
Clique no menu de três linhas (☰) no canto superior esquerdo e vá para › .
Encontre a flag
oidc-provider, clique no ícone Ações Adicionais (⋮) e clique em Ativar.
6.2 Etapa 2: Crie um recurso OIDCClient #
Rancher usa um recurso OIDCClient personalizado para registrar aplicativos downstream.
Crie um arquivo chamado
rancher-oidc-client.yamlcom o seguinte conteúdo:apiVersion: management.cattle.io/v3 kind: OIDCClient metadata: name: spr-client spec: tokenExpirationSeconds: 600 refreshTokenExpirationSeconds: 3600 redirectURIs: # Replace this with the actual callback URL of your SUSE private registry instance - "https://<SUSE_PRIVATE_REGISTR_URL>/c/oidc/callback"Aplique o arquivo no cluster onde Rancher está em execução:
>kubectl apply -f rancher-oidc-client.yaml
6.3 Etapa 3: Recupere o ID do Cliente e o Segredo #
Uma vez que o recurso é criado, Rancher preenche automaticamente o clientID e provisiona um Segredo Kubernetes contendo o clientSecret.
Obtenha o ID do Cliente gerado:
>kubectl get oidcclient spr-client -o jsonpath="{.status.clientID}"Recupere o Segredo do Cliente. Lembre-se de substituir
<YOUR_CLIENT_ID>pelo ID recuperado na etapa anterior:>kubectl get secret <YOUR_CLIENT_ID> -n cattle-oidc-client-secrets -o jsonpath="{.data.client-secret-1}" | base64 -d
6.4 Etapa 4: Configure SUSE Private Registry #
Você pode configurar SUSE Private Registry para usar Rancher como seu provedor OIDC passando os valores via Helm.
Use o bloco core.configureUserSettings na sua configuração values-oidc.yaml.
O seguinte é um bloco de exemplo usando seu Rancher ponto de extremidade e as credenciais recuperadas acima.
Substitua os valores de <YOUR_CLIENT_ID> e <YOUR_CLIENT_SECRET>.
core:
configureUserSettings: |
{
"auth_mode": "oidc_auth",
"oidc_name": "Rancher",
"oidc_endpoint": "<RANCHER_URL>/oidc",
"oidc_client_id": "<YOUR_CLIENT_ID>",
"oidc_client_secret": "<YOUR_CLIENT_SECRET>",
"oidc_scope": "openid,profile,offline_access",
"oidc_verify_cert": false,
"oidc_auto_onboard": true,
"oidc_user_claim": "preferred_username",
"oidc_groups_claim": "groups",
"oidc_admin_group": "spr-admins"
}Certifique-se de que oidc_verify_cert esteja definido como false se sua instância Rancher estiver usando certificados autoassinados.
Ao especificar oidc_admin_group, qualquer usuário Rancher pertencente ao grupo spr-admins receberá automaticamente privilégios de administrador do sistema em SUSE Private Registry.
7 Perguntas frequentes #
7.1 Visão geral do produto e diferenciais #
- Que tipo de assinatura os clientes precisam para SUSE Private Registry?
Está incluído no Rancher Suite e oferecido como um complemento para Rancher Prime.
O preço do complemento é o mesmo que outros complementos.
- Quais são os diferenciais com Harbor (da Coleção de Aplicativos ou upstream)?
Use SUSE Private Registry se você precisar:
Suporte de Nível 3 (L3) para problemas de produto.
Um ciclo de lançamento previsível.
Imagens corrigidas para vulnerabilidades conhecidas. Imagens upstream Harbor de Docker Hub frequentemente contêm várias vulnerabilidades não corrigidas.
Com o tempo, SUSE também adicionará integrações prontas para uso com Rancher e priorizará solicitações de funcionalidades dos clientes.
- Os clientes precisam comprar o mesmo número de assinaturas de complemento SUSE Private Registry que assinaturas Rancher Prime?
Sim, assim como outros complementos, como SUSE Segurança. Uma vantagem adicional do modelo de assinatura SUSE Private Registry é que ele permite que os clientes realizem quantas implantações precisarem.
7.2 Relação com upstream Harbor #
- Como o ciclo de lançamento se alinha com upstream Harbor?
O ciclo de lançamento de SUSE Private Registry é independente do ciclo de lançamento de upstream Harbor.
Ao lançar novas versões de SUSE Private Registry, SUSE visa incluir a versão mais recente do projeto upstream Harbor que atende aos requisitos de garantia de qualidade e manutenção da SUSE.
- Você publicará considerações sobre migração para clientes que executam Harbor de outras fontes?
Não neste momento.
7.3 Implantação e instalação #
- Você suporta a instalação do SUSE Private Registry via docker-compose?
Não. Você deve instalar e configurar o SUSE Private Registry usando seu gráfico Helm. Este gráfico também é usado para gerenciamento contínuo (operações do Dia 2) e pode ser integrado com fluxos de trabalho GitOps.
- Você recomenda implantações no cluster local (Rancher Manager)?
Não. A SUSE recomenda implantar o SUSE Private Registry em um cluster downstream. Isso torna o registro acessível a outros clusters downstream que precisam consumir imagens.
- Quais são as melhores práticas de implantação para um ambiente de alta disponibilidade (HA)?
Para HA, não implante o SUSE Private Registry no cluster de gerenciamento Rancher para evitar contenção de recursos.
Você pode implantar o SUSE Private Registry em um cluster dedicado ou em um ou mais de seus clusters de aplicativos.
Para obter instruções, consulte Chapter 5, Alta Disponibilidade configuração. Observe que você deve fornecer seus próprios componentes de HA para o banco de dados Postgres, servidor Valkey ou Redis, e controlador Ingress. Esses componentes não são implantados pelo gráfico SUSE Private Registry Helm e não são suportados pelo SUSE.
- O gráfico SUSE Private Registry Helm será adicionado à Coleção de Aplicativos eventualmente?
Sim, a SUSE planeja publicar o gráfico lá no futuro.
- Você fornece um operador Kubernetes?
O SUSE Private Registry não vem com um operador dedicado. Ele é instalado e gerenciado usando seu gráfico Helm, que pode ser integrado com GitOps. SUSE continua a avaliar a gestão baseada em operadores para lançamentos futuros.
7.4 Segurança, escaneamento e assinatura #
- Você integra alguma ferramenta de assinatura dentro de SUSE Private Registry?
SUSE Private Registry não assina imagens por si só, mas pode armazenar, distribuir e verificar assinaturas compatíveis com a Open Container Initiative (OCI).
Uma ferramenta amplamente utilizada é
cosign, que pode assinar imagens e armazenar as assinaturas em SUSE Private Registry.As assinaturas de
cosignanexadas às imagens são visíveis e podem ser baixadas do portal SUSE Private Registry.- É possível assinar imagens com Notary ou Cosign para aprovação durante o processo de implantação?
SUSE Private Registry pode armazenar, distribuir e verificar assinaturas de
cosign.SUSE Private Registry não assina imagens por si só. Você deve assinar as imagens durante o processo de construção e, em seguida, fazer o upload da assinatura para o registro junto com a imagem.
Notary não está incluído ou suportado com SUSE Private Registry.
- As imagens são escaneadas para Vulnerabilidades e Exposições Comuns (CVEs) apenas com Trivy, ou pode usar SUSE Security (NeuVector) também?
As imagens são escaneadas com Trivy, que vem pronto para uso. SUSE Security pode ser adicionado além de ou como substituto do Trivy.
- É possível executar ClamAV ou varreduras de malware semelhantes?
Por padrão, SUSE Private Registry escaneia imagens usando Trivy. Você também pode configurar SUSE Security (NeuVector) como um scanner.
- No cenário de cache de pull-through, os critérios de vulnerabilidade serão aplicados?
Sim, mas com uma limitação conhecida. Devido aos Harbor issues conhecidos, os critérios de vulnerabilidade não são aplicados na primeira extração de uma imagem porque a varredura ainda não foi concluída.
Para cobertura completa, combine SUSE Private Registry com SUSE Security controles de admissão.
- As imagens de SUSE Private Registry estão endurecidas?
Sim. As imagens de contêiner para SUSE Private Registry estão endurecidas. Elas são baseadas em SUSE Linux Enterprise Base Container Images (SLE BCI) e construídas no mesmo Serviço de Construção da SUSE de nível empresarial usado para o SUSE Linux Enterprise. Isso garante uma cadeia de suprimento segura. As imagens também são assinadas, e a SUSE publica suas Atestações de Níveis de Cadeia de Suprimento para Artefatos de Software (SLSA).
- As imagens de SUSE Private Registry estão assinadas? Como?
As imagens estão assinadas com
cosign. Você pode verificá-las salvando a chave de assinatura no formato PEM publicada em KB 000021411.Então execute, por exemplo:
cosign verify --key container-key.pem registry.suse.com/private-registry/harbor-portal:latest
7.5 Replicação e sincronização #
- Há um plano para um plug-in para sincronizar com SUSE Registro e SUSE Coleção de Aplicativos?
Sim, tal recurso está planejado.
- O SUSE Private Registry oferece replicação em múltiplos sites?
Sim. O SUSE Private Registry suporta replicação de imagens em múltiplos sites, baseada em políticas (pull e push). Você pode sincronizar imagens em várias implantações de SUSE Private Registry enquanto mantém cada registro independente.
7.6 Recursos e integração com Rancher #
- Há um plano para integrar o Registro dentro do Rancher usando uma extensão?
Sim. O SUSE planeja uma integração mais profunda com o Rancher Prime e outras ofertas. As melhorias futuras em consideração incluem integração de single sign-on (SSO), configuração simplificada para scanners de SUSE Segurança e espelhamento da Coleção de Aplicativos, monitoramento com SUSE Observabilidade e uma extensão de UI Rancher.
- O SUSE adicionará o Registro ao Catálogo de Treinamento?
Isso ainda não está planejado. Se você estiver interessado em material de treinamento, entre em contato com SUSE para discutir possibilidades com a equipe de Treinamento.
7.7 Suporte e documentação #
- Há uma política de suporte para SUSE Private Registry?
Sim. A política de suporte de SUSE Private Registry é a mesma de qualquer outro complemento Prime Rancher.
- Se a documentação de SUSE Private Registry estiver faltando informações, posso me referir à documentação oficial de Harbor?
Sim. Como SUSE Private Registry é baseado em Harbor, a documentação oficial de Harbor é um recurso útil. Para recursos específicos da versão SUSE, consulte a documentação de SUSE Private Registry.
Os Release notes especificam qual versão do Harbor upstream corresponde à sua versão de SUSE Private Registry.
8 Solução de problemas #
Esta seção fornece soluções para problemas que você pode encontrar ao implantar ou usar SUSE Private Registry.
- Estou encontrando o erro
401 unauthorizedao tentar instalar SUSE Private Registry. A versão completa da mensagem de erro é a seguinte:
Error: INSTALLATION FAILED: GET "https://registry.suse.com/v2/private-registry/private-registry-helm/tags/list": response status code 401: unauthorized: authentication required: [map[Action:pull Class: Name:private-registry/private-registry-helm Type:repository]]
Para instalar e usar SUSE Private Registry, você precisa do seguinte:
Uma assinatura qualificada que inclua este produto, como uma assinatura do Rancher Suite ou uma assinatura do SUSE Private Registry complemento. Se você não tiver uma assinatura qualificada, entre em contato com seu representante SUSE.
Faça login no SUSE Registro com Helm usando as credenciais de espelhamento SCC da organização SCC que possui a assinatura. Consulte Section 4.1, “Obtendo segredos de Kubernetes do SUSE Atendimento ao Cliente” para obter mais detalhes.
A Substituindo o gráfico SUSE Private Registry Helm #
O gráfico SUSE Private Registry (Registro Privado) Helm é entregue com valores padrão. Você pode ajustar a instalação do gráfico Helm de uma das seguintes maneiras:
Anexe parâmetros específicos às flags
--setna linha de comandohelm install, por exemplo:$ helm install <RELEASE_NAME> \ oci://registry.suse.com/private-registry/private-registry-helm \ --namespace <PRIVATE_REGISTRY_NAMESPACE> \ --set harborAdminPassword=<MY_PASSWORD> \ --set externalURL=https://<PRIVATE_REGISTRY_FQDN> \ --set expose.ingress.hosts.core=<PRIVATE_REGISTRY_FQDN>
Create a SUSE custom
suse_registry_override.yamlfile and pass it to the--fflag, for example:$ helm install <RELEASE_NAME> \ oci://registry.suse.com/private-registry/private-registry-helm \ --namespace <PRIVATE_REGISTRY_NAMESPACE> -f suse_registry_override.yaml
A1 Exemplos de arquivos de substituição SUSE Registro Helm #
expose: type: ingress 1 ingress: hosts: core: <PRIVATE_REGISTRY_FQDN> 2 externalURL: https://<PRIVATE_REGISTRY_FQDN> 3 harborAdminPassword: "<MY_PASSWORD>" 4 database: internal: password: "<MY_PASSWORD_POSTGRESQL>" redis: internal: password: "<MY_PASSWORD_REDIS>"
Como SUSE Registro é exposto. Pode ser | |
Nome de host para a configuração de rede interna do Kubernetes. | |
URL onde o aplicativo SUSE Registro é executado. É usado para gerar links na interface do usuário, redirecionamentos e também para respostas da API. | |
A senha do administrador para o aplicativo. |
loadBalancer #expose: type: loadBalancer 1 tls: enabled: true certSource: secret 2 secret: secretName: <SECRET_NAME> auto: commonName: <PRIVATE_REGISTRY_FQDN> 3 externalURL: https://<PRIVATE_REGISTRY_FQDN> 4 harborAdminPassword: "<MY_PASSWORD>" 5 database: internal: password: "<MY_PASSWORD_POSTGRESQL>" redis: internal: password: "<MY_PASSWORD_REDIS>"
Como SUSE Registro é exposto. Pode ser | |
Pode ser | |
Ao usar a criptografia TLS, este campo deve corresponder ao valor | |
URL onde o aplicativo SUSE Registro é executado. É usado para gerar links na interface do usuário, redirecionamentos e também para respostas da API. | |
A senha do administrador para o aplicativo. |
A2 Substituindo os parâmetros e valores do gráfico Helm #
As tabelas a seguir listam todos os parâmetros com descrições que você pode usar para substituir os valores de instalação padrão.
global.imageRegistryDefine uma substituição global para o registro de imagens do contêiner usado para todas as imagens.
global.imagePullSecretsDefine segredos globais de pull para acessar o registro de imagens do contêiner.
harborAdminPasswordDefine a senha inicial para o administrador Harbor. Altere-a pelo portal após a implantação. O padrão é
Harbor12345.externalURLEspecifica a URL externa para o serviço
harbor-core. O padrão éhttps://core.harbor.domain.existingSecretAdminPasswordKeyDefine o nome da chave no segredo que contém a senha do administrador Harbor. O padrão é
HARBOR_ADMIN_PASSWORD.imagePullSecretsDefine os nomes
imagePullSecretspara todas as implantações.updateStrategy.typeDefine a estratégia de atualização para implantações com volumes persistentes. Aceita
RollingUpdateouRecreate. UseRecreatequando RWM para volumes não for suportado. O padrão éRollingUpdate.logLevelDefine o nível de log para os serviços Harbor. Aceita
fatal,error,warn,info,debugoutrace. O padrão édebug.enableMigratehelmHookExecuta a tarefa de migração do banco de dados via o gancho Helm. Quando
true, separa a tarefa de migração deharbor-core. O padrão éfalse.caSecretNameEspecifica o nome do segredo que contém a chave
ca.crt.
proxy.httpProxyEspecifica a URL do servidor proxy HTTP. O padrão é
"".proxy.httpsProxyEspecifica a URL do servidor proxy HTTPS. O padrão é
"".proxy.noProxyDefine URLs que ignoram a configuração do proxy. O padrão é
127.0.0.1,localhost,.local,.internal.proxy.componentsDefine componentes que utilizam a configuração do proxy. O padrão é
["core","jobservice","trivy"].
expose.typeEspecifica o tipo de exposição do serviço:
ingress,clusterIP,nodePortouloadBalancer. O padrão éingress.expose.tls.enabledHabilita TLS. O padrão é
true.expose.tls.certSourceDefine a fonte do certificado TLS como
auto,secretounone. O padrão éauto.expose.tls.auto.commonNameDefine o nome comum do certificado quando o tipo não é
ingress.expose.tls.secret.secretNameEspecifica o nome do segredo que contém
tls.crt(certificado) etls.key(chave privada).expose.ingress.hosts.coreDefine o host do serviço kernel Harbor na regra Ingress. O padrão é
core.harbor.domain.expose.ingress.controllerDefine o tipo de controlador Ingress. Suporta
default,gce,alb,f5-bigipencp. O padrão édefault.expose.ingress.kubeVersionOverrideSubstitui a versão Kubernetes para a template Ingress.
expose.ingress.annotationsDefine as anotações Ingress.
expose.ingress.labelsDefine os rótulos específicos de Ingress. O padrão é
{}.expose.clusterIP.nameDefine o nome do serviço ClusterIP. O padrão é
harbor.expose.clusterIP.annotationsDefine as anotações do serviço ClusterIP. O padrão é
{}.expose.clusterIP.ports.httpPortDefine a porta do serviço HTTP. O padrão é
80.expose.clusterIP.ports.httpsPortDefine a porta do serviço HTTPS. O padrão é
443.expose.clusterIP.labelsDefine os rótulos específicos do ClusterIP. O padrão é
{}.expose.nodePort.nameDefine o nome do serviço NodePort. O padrão é
harbor.expose.nodePort.ports.http.portDefine a porta do serviço HTTP. O padrão é
80.expose.nodePort.ports.http.nodePortDefine a porta do nó HTTP. O padrão é
30002.expose.nodePort.ports.https.portDefine a porta do serviço HTTPS. O padrão é
443.expose.nodePort.ports.https.nodePortDefine a porta do nó HTTPS. O padrão é
30003.expose.nodePort.annotationsDefine as anotações do NodePort.
expose.nodePort.labelsDefine os rótulos específicos do NodePort. O padrão é
{}.expose.loadBalancer.nameDefine o nome do serviço. O padrão é
harbor.expose.loadBalancer.IPDefine o IP do loadBalancer quando a atribuição de IP é suportada. O padrão é
"".expose.loadBalancer.ports.httpPortDefine a porta do serviço HTTP. O padrão é
80.expose.loadBalancer.ports.httpsPortDefine a porta do serviço HTTPS. O padrão é
30002.expose.loadBalancer.annotationsDefine as anotações do serviço loadBalancer. O padrão é
{}.expose.loadBalancer.labelsDefine os rótulos específicos do loadBalancer. O padrão é
{}.expose.loadBalancer.sourceRangesEspecifica intervalos de endereços IP para loadBalancerSourceRanges. O padrão é
[].
persistence.enabledHabilita ou desabilita a persistência de dados. O padrão é
true.persistence.resourcePolicykeepimpede a remoção de PVCs durante uma operação de exclusão Helm. Valor vazio exclui PVCs após a exclusão do gráfico. O padrão ékeep.persistence.persistentVolumeClaim.registry.existingClaimO PVC existente que deve ser criado manualmente antes da vinculação. Requer uma especificação de subPath se o PVC for compartilhado com outros componentes.
persistence.persistentVolumeClaim.registry.storageClassO
storageClassque provisiona o volume.persistence.persistentVolumeClaim.registry.subPathO subpath no volume.
persistence.persistentVolumeClaim.registry.accessModeO modo de acesso do volume. O padrão é
ReadWriteOnce.persistence.persistentVolumeClaim.registry.sizeO tamanho do volume. O padrão é
5Gi.persistence.persistentVolumeClaim.registry.annotationsAs anotações do volume.
persistence.persistentVolumeClaim.jobservice.jobLog.existingClaimO PVC existente que deve ser criado manualmente antes da vinculação. Requer uma especificação de subPath se o PVC for compartilhado com outros componentes.
persistence.persistentVolumeClaim.jobservice.jobLog.storageClassO
storageClassque provisiona o volume.persistence.persistentVolumeClaim.jobservice.jobLog.subPathO subpath no volume.
persistence.persistentVolumeClaim.jobservice.jobLog.accessModeO modo de acesso do volume. O padrão é
ReadWriteOnce.persistence.persistentVolumeClaim.jobservice.jobLog.sizeO tamanho do volume. O padrão é
1Gi.persistence.persistentVolumeClaim.jobservice.jobLog.annotationsAs anotações do volume.
persistence.persistentVolumeClaim.database.existingClaimO PVC existente que deve ser criado manualmente antes da vinculação. Requer uma especificação de subPath se o PVC for compartilhado com outros componentes.
persistence.persistentVolumeClaim.database.storageClassO
storageClassque provisiona o volume.persistence.persistentVolumeClaim.database.subPathO subpath no volume. Ignorado quando um banco de dados externo é utilizado.
persistence.persistentVolumeClaim.database.accessModeO modo de acesso do volume. Ignorado quando um banco de dados externo é utilizado. O padrão é
ReadWriteOnce.persistence.persistentVolumeClaim.database.sizeO tamanho do volume. Ignorado quando um banco de dados externo é utilizado. O padrão é
1Gi.persistence.persistentVolumeClaim.database.annotationsAs anotações do volume.
persistence.persistentVolumeClaim.redis.existingClaimO PVC existente que deve ser criado manualmente antes da vinculação. Requer uma especificação de subPath se o PVC for compartilhado com outros componentes.
persistence.persistentVolumeClaim.redis.storageClassO
storageClassque provisiona o volume. Usa a StorageClass padrão se não for especificada.persistence.persistentVolumeClaim.redis.subPathO subpath no volume. Ignorado quando um Valkey externo é utilizado.
persistence.persistentVolumeClaim.redis.accessModeO modo de acesso do volume. Ignorado quando um Valkey externo é utilizado. O padrão é
ReadWriteOnce.persistence.persistentVolumeClaim.redis.sizeO tamanho do volume. Ignorado quando um Valkey externo é utilizado. O padrão é
1Gi.persistence.persistentVolumeClaim.redis.annotationsAs anotações do volume.
persistence.persistentVolumeClaim.trivy.existingClaimO PVC existente que deve ser criado manualmente antes da vinculação. Requer uma especificação de subPath se o PVC for compartilhado com outros componentes.
persistence.persistentVolumeClaim.trivy.storageClassO
storageClassque provisiona o volume. Usa a StorageClass padrão se não for especificada.persistence.persistentVolumeClaim.trivy.subPathO subpath no volume.
persistence.persistentVolumeClaim.trivy.accessModeO modo de acesso do volume. O padrão é
ReadWriteOnce.persistence.persistentVolumeClaim.trivy.sizeO tamanho do volume. O padrão é
1Gi.persistence.persistentVolumeClaim.trivy.annotationsAs anotações do volume.
persistence.imageChartStorage.disableredirectControla a gestão de redirecionamentos de back ends de conteúdo. Defina como verdadeiro para desabilitar redirecionamentos para back ends não suportados. O padrão é
false.persistence.imageChartStorage.caBundleSecretNameO nome do segredo contendo o pacote CA para certificados de serviço de armazenamento autoassinado.
persistence.imageChartStorage.typeO tipo de armazenamento para imagens e gráficos:
filesystem,azure,gcs,s3,swiftouoss. O padrão éfilesystem.persistence.imageChartStorage.gcs.existingSecretO nome do segredo existente contendo a chave JSON da conta de serviço GCS. A chave deve ser
gcs-key.json. O padrão é"".persistence.imageChartStorage.gcs.useWorkloadIdentityHabilita o uso de identidade de carga de trabalho em um cluster GKE. O padrão é
false.
nginx.image.repositoryO repositório de imagens para nginx. O padrão é
private-registry/harbor-nginx.nginx.image.tagA tag da imagem para nginx.
nginx.replicasO número de réplicas a serem executadas. O padrão é
1.nginx.revisionHistoryLimitO número máximo de revisões antigas de
ReplicaSeta serem mantidas. O padrão é10.nginx.resourcesOs recursos de computação alocados para o contêiner. O padrão é
undefined.nginx.automountServiceAccountTokenControla a montagem automática do token da conta de serviço. O padrão é
false.nginx.nodeSelectorOs rótulos do nó usados para a atribuição de pods. O padrão é
{}.nginx.tolerationsAs tolerâncias de atribuição de pods. O padrão é
[].nginx.affinityAs regras de afinidade de nó ou pod. O padrão é
{}.nginx.topologySpreadConstraintsAs regras para espalhar pods por domínios de falha, como regiões ou zonas de disponibilidade. O padrão é
[].nginx.podAnnotationsAs anotações adicionadas ao nginx pod. O padrão é
{}.
portal.image.repositoryLocalização do repositório para a imagem do portal. O padrão é
private-registry/harbor-portal.portal.image.tagTag para a imagem do portal. O padrão é
3.11.portal.replicasNúmero de réplicas a serem criadas. O padrão é
1.portal.revisionHistoryLimitNúmero máximo de revisões antigas de
ReplicaSeta serem mantidas. O padrão é10.portal.resourcesRecursos alocados para o contêiner. O padrão é
undefined.portal.automountServiceAccountTokenControla a montagem automática do token da conta de serviço. O padrão é
false.portal.nodeSelectorRótulos de nó usados para atribuição de pod. O padrão é
{}.portal.tolerationsTolerâncias usadas para atribuição de pod. O padrão é
[].portal.affinityConfigurações de afinidade de nó e pod. O padrão é
{}.portal.topologySpreadConstraintsDefine a distribuição de pods entre domínios de falha, como regiões ou zonas de disponibilidade. O padrão é
[].portal.podAnnotationsAnotações adicionadas ao pod do portal. O padrão é
{}.portal.serviceAnnotationsAnotações adicionadas ao serviço do portal. O padrão é
{}.portal.priorityClassNameNome da classe de prioridade para execução do pod.
portal.initContainersContêineres init a serem executados antes que o contêiner do controlador inicie. O padrão é
[].
core.image.repositoryO repositório para a Harbor imagem do kernel. O padrão é
private-registry/harbor-core.core.image.tagA tag para a Harbor imagem do kernel. O padrão é
2.11.core.replicasO número de réplicas. O padrão é
1.core.revisionHistoryLimitO limite de histórico de revisões. O padrão é
10.core.startupProbe.initialDelaySecondsO atraso inicial em segundos para a verificação de inicialização. O padrão é
10.core.resourcesOs recursos a serem alocados para o contêiner. O padrão é
undefined.core.automountServiceAccountTokenMonta o token da conta de serviço. O padrão é
false.core.nodeSelectorOs rótulos de nó para atribuição de pod. O padrão é
{}.core.tolerationsAs tolerâncias para atribuição de pod. O padrão é
[].core.affinityAs afinidades de nó ou pod. O padrão é
{}.core.topologySpreadConstraintsAs restrições que definem como os pods são distribuídos entre domínios de falha, como regiões ou zonas de disponibilidade. O padrão é
[].core.podAnnotationsAs anotações a serem adicionadas ao pod kernel. O padrão é
{}.core.serviceAnnotationsAs anotações a serem adicionadas ao serviço kernel. O padrão é
{}.core.configureUserSettingsUma string JSON na variável de ambiente CONFIG_OVERWRITE_JSON para configurar as configurações do usuário.
core.quotaUpdateProviderO provedor para atualizar o uso da cota do projeto, as opções são
redisoudb. O padrão édb.core.secretUsado quando o servidor kernel se comunica com outros componentes.
core.secretNameO nome de um Kubernetes segredo para usar seu próprio certificado TLS e chave privada para a criptografia ou descriptografia de token.
core.tokenKeyA chave privada RSA formatada em PEM usada para assinar tokens de serviço.
core.tokenCertO certificado formatado em PEM assinado por
core.tokenKeyusado para validar tokens de serviço.core.xsrfKeyA chave XSRF, gerada automaticamente se não for especificada.
core.priorityClassNameA classe de prioridade para executar o pod.
core.artifactPullAsyncFlushDurationA duração do tempo para atualizar assíncronamente o tempo de pull de artefatos e a contagem de pull do repositório.
core.gdpr.deleteUserHabilita a exclusão de usuários em conformidade com o GDPR. O padrão é
false.core.gdpr.auditLogsCompliantHabilita a conformidade com o GDPR para logs de auditoria, alterando o nome de usuário para seu valor CRC32 se esse usuário foi excluído do sistema. O padrão é
false.core.initContainersOs contêineres init a serem executados antes que o contêiner do controlador inicie. O padrão é
[].
jobservice.image.repositoryO repositório para a imagem do serviço de trabalho. O padrão é
private-registry/harbor-jobservice.jobservice.image.tagA tag para a imagem do serviço de trabalho. O padrão é
2.11.jobservice.replicasO número de réplicas. O padrão é
1.jobservice.revisionHistoryLimitO limite de histórico de revisões. O padrão é
10.jobservice.maxJobWorkersO número máximo de worker de trabalho. O padrão é
10.jobservice.jobLoggersOs registradores para trabalhos:
file,databaseoustdout. O padrão é[file].jobservice.loggerSweeperDurationA duração em dias para manter os logs de trabalho (ignorados se
jobLoggersestiver definido comostdout). O padrão é14.jobservice.notification.webhook_job_max_retryO número máximo de tentativas para o envio de notificações via webhook. O padrão é
3.jobservice.notification.webhook_job_http_client_timeoutO tempo limite do cliente HTTP em segundos para o envio de notificações via webhook. O padrão é
3.jobservice.reaper.max_update_hoursO tempo máximo em horas para aguardar a conclusão de uma tarefa. Se a tarefa não for concluída após as horas especificadas, ela é marcada como um erro, mas continua em execução. O padrão é
24.jobservice.reaper.max_dangling_hoursO tempo máximo em horas para execução em estado de execução sem uma nova tarefa criada. O padrão é
168.jobservice.resourcesOs [recursos] a serem alocados para o contêiner. O padrão é
undefined.jobservice.automountServiceAccountTokenMonta o token da conta de serviço. O padrão é
false.jobservice.nodeSelectorOs rótulos de nó para atribuição de pod. O padrão é
{}.jobservice.tolerationsAs tolerâncias para atribuição de pod. O padrão é
[].jobservice.affinityAs afinidades de nó ou pod. O padrão é
{}.jobservice.topologySpreadConstraintsAs restrições que definem como os pods são distribuídos entre domínios de falha, como regiões ou zonas de disponibilidade. O padrão é
[].jobservice.podAnnotationsAs anotações a serem adicionadas ao pod do serviço de trabalho. O padrão é
{}.jobservice.priorityClassNameA classe de prioridade para executar o pod.
jobservice.secretO segredo usado quando o serviço de trabalho se comunica com outros componentes. Se uma chave secreta não for especificada, Helm a gera. Deve ser uma string de 16 caracteres.
jobservice.initContainersOs contêineres init a serem executados antes que o contêiner do controlador inicie. O padrão é
[].
registry.registry.image.repositoryA localização do repositório para a imagem do registro. O padrão é
private-registry/harbor-registry.registry.registry.image.tagA tag para a imagem do registro. O padrão é
2.11.registry.registry.resourcesOs [recursos] a serem alocados para o contêiner. O padrão é
undefined.registry.controller.image.repositoryA localização do repositório para a imagem do controlador do registro. O padrão é
private-registry/harbor-registryctl.registry.controller.image.tagA tag para a imagem do controlador do registro. O padrão é
2.11.registry.controller.resourcesOs [recursos] a serem alocados para o contêiner. O padrão é
undefined.registry.replicasO número de instâncias replicadas. O padrão é
1.registry.revisionHistoryLimitO número máximo de revisões a serem mantidas no histórico. O padrão é
10.registry.nodeSelectorOs rótulos de nó para atribuição de pod. O padrão é
{}.registry.automountServiceAccountTokenControla se deve montar o token da conta de serviço. O padrão é
false.registry.tolerationsAs tolerâncias para atribuição de pod. O padrão é
[].registry.affinityAs afinidades de nó ou pod. O padrão é
{}.registry.topologySpreadConstraintsAs restrições que definem a distribuição de pods entre domínios de falha, como regiões ou zonas de disponibilidade. O padrão é
[].registry.middlewareSuporte a middleware para um CDN entre o armazenamento de back end e Docker destinatário de pull.
registry.podAnnotationsAs anotações a serem adicionadas ao pod do registro. O padrão é
{}.registry.priorityClassNameA classe de prioridade para a execução do pod.
registry.secretO segredo que protege o estado de upload entre o cliente e o armazenamento do registro back end.
registry.credentials.usernameO nome de usuário para acesso ao registro interno do kernel Harbor. O padrão é
harbor_registry_user.registry.credentials.passwordA senha para acesso ao registro interno do kernel Harbor. O padrão é
harbor_registry_password.registry.credentials.existingSecretUm segredo existente contendo a senha para acesso à instância do registro no modo de autenticação htpasswd. O padrão é
"".registry.credentials.htpasswdStringO login e a senha no formato de string htpasswd. Exclui
registry.credentials.usernameeregistry.credentials.password. O padrão éundefined.registry.relativeurlsRetorna URLs relativas nos cabeçalhos de Localização quando verdadeiro. Necessário se Harbor estiver atrás de um proxy reverso. O padrão é
false.registry.upload_purging.enabledHabilita a purgação de diretórios de upload. O padrão é
true.registry.upload_purging.ageO período de tempo após o qual os arquivos nos diretórios de upload são removidos, o padrão é uma semana. O padrão é
168h.registry.upload_purging.intervalO intervalo de tempo entre operações de purgação. O padrão é
24h.registry.upload_purging.dryrunHabilita o modo de simulação para purgação de uploads. O padrão é
false.registry.initContainersOs contêineres init que são executados antes do início do contêiner do controlador. O padrão é
[].
trivy.enabledHabilita ou desabilita o Trivy scanner. O padrão é
true.trivy.image.repositoryO repositório para a Trivy imagem do adaptador. O padrão é
private-registry/harbor-trivy-adapter.trivy.image.tagA tag para a Trivy imagem do adaptador. O padrão é
2.11.trivy.resourcesOs recursos a serem alocados para o Trivy contêiner do adaptador. O padrão é
undefined.trivy.automountServiceAccountTokenSe deve montar o token da conta de serviço. O padrão é
false.trivy.replicasO número de réplicas do Pod. O padrão é
1.trivy.debugModeHabilita o modo remover Trivy para solução de problemas. O padrão é
false.trivy.vulnTypeLista de tipos de vulnerabilidades separados por vírgula (
oselibrary). O padrão éos,library.trivy.severityLista de severidades de vulnerabilidades a serem verificadas, separadas por vírgula. O padrão é
UNKNOWN,LOW,MEDIUM,HIGH,CRITICAL.trivy.ignoreUnfixedExibe apenas vulnerabilidades corrigidas. O padrão é
false.trivy.insecureIgnora a verificação do certificado do registro. O padrão é
false.trivy.skipUpdateDesabilita downloads de banco de dados Trivy do GitHub. O padrão é
false.trivy.skipJavaDBUpdateRequer download manual do arquivo
trivy-java.dbquando habilitado. O padrão éfalse.trivy.offlineScanImpede que Trivy envie solicitações de API para identificar dependências. O padrão é
false.trivy.securityCheckLista de problemas de segurança a serem detectados, separados por vírgula. O padrão é
vuln.trivy.timeoutO tempo de espera para a conclusão da varredura. O padrão é
5m0s.trivy.gitHubTokenO token de acesso do GitHub necessário para downloads de banco de dados. O padrão é
undefined.trivy.priorityClassNameA classe de prioridade para executar o pod. O padrão é
undefined.trivy.topologySpreadConstraintsDefine restrições de distribuição do pod entre domínios de falha. O padrão é
undefined.trivy.initContainersLista de contêineres init a serem executados antes do contêiner principal iniciar. O padrão é
[].
database.typeO tipo de banco de dados. Defina como
externalao usar um banco de dados externo. O padrão éinternal.database.internal.image.repositoryO repositório para a imagem do banco de dados. O padrão é
private-registry/harbor-db.database.internal.image.tagA tag para a imagem do banco de dados. O padrão é
2.11.database.internal.passwordA senha para o banco de dados interno. O padrão é
changeit.database.internal.shmSizeLimitO limite de tamanho da memória compartilhada para PostgreSQL (tipicamente 50% do limite de memória do contêiner). O padrão é
512Mi.database.internal.resourcesOs recursos alocados para o contêiner do banco de dados. O padrão é
undefined.database.internal.automountServiceAccountTokenControla se o token da conta de serviço é montado. O padrão é
false.database.internal.initContainer.migrator.resourcesOs recursos alocados para o contêiner de inicialização do migrador de banco de dados. O padrão é
undefined.database.internal.initContainer.permissions.resourcesOs recursos alocados para o contêiner de inicialização das permissões do banco de dados. O padrão é
undefined.database.internal.nodeSelectorOs rótulos de nó para atribuição de pod. O padrão é
{}.database.internal.tolerationsAs tolerâncias para atribuição de pod. O padrão é
[].database.internal.affinityAs configurações de afinidade do nó ou pod. O padrão é
{}.database.internal.priorityClassNameA classe de prioridade para executar o pod. O padrão é
undefined.database.internal.livenessProbe.timeoutSecondsO tempo limite em segundos para a liveness probe (intervalo: 1-5s). O padrão é
1.database.internal.readinessProbe.timeoutSecondsO tempo limite em segundos para a verificação de prontidão (intervalo: 1-5s). O padrão é
1.database.internal.extrInitContainersContêineres de inicialização adicionais que são executados antes do contêiner do banco de dados iniciar. O padrão é
[].database.external.hostO nome de host do banco de dados externo. O padrão é
192.168.0.1.database.external.portO número da porta do banco de dados externo. O padrão é
5432.database.external.usernameO nome de usuário para o banco de dados externo. O padrão é
user.database.external.passwordA senha para o banco de dados externo. O padrão é
password.database.external.coreDatabaseO nome do banco de dados usado pelo serviço kernel. O padrão é
registry.database.external.existingSecretO segredo existente contendo a senha do banco de dados. A chave deve ser
password. O padrão é"".database.external.sslmodeO método de conexão para o banco de dados externo. Opções:
require,verify-full,verify-ca,disable. O padrão édisable.database.maxIdleConnsO número máximo de conexões ociosas no pool (0 ou menos significa que nenhuma conexão ociosa é mantida). O padrão é
50.database.maxOpenConnsO número máximo de conexões abertas ao banco de dados (0 ou menos significa ilimitado). O padrão é
100.database.podAnnotationsAs anotações a serem adicionadas ao pod do banco de dados. O padrão é
{}.
redis.typeO tipo de implantação Redis. Defina como
externalpara Redis externo. O padrão éinternal.redis.internal.image.repositoryO repositório da imagem Redis. O padrão é
private-registry/harbor-redis.redis.internal.image.tagA tag da imagem Redis. O padrão é
7.2.redis.internal.resourcesOs recursos alocados para o contêiner Redis. O padrão é
undefined.redis.internal.automountServiceAccountTokenControla se o token da conta de serviço é montado. O padrão é
false.redis.internal.nodeSelectorOs rótulos de nó para atribuição de pod. O padrão é
{}.redis.internal.tolerationsAs tolerâncias para atribuição de pod. O padrão é
[].redis.internal.affinityAs configurações de afinidade do nó ou pod. O padrão é
{}.redis.internal.priorityClassNameA classe de prioridade para executar o Redis pod. O padrão é
undefined.redis.internal.jobserviceDatabaseIndexO índice do banco de dados para o jobservice. O padrão é
1.redis.internal.registryDatabaseIndexO índice do banco de dados para o registry. O padrão é
2.redis.internal.trivyAdapterIndexO índice do banco de dados para o Trivy adaptador. O padrão é
5.redis.internal.harborDatabaseIndexO índice do banco de dados para a Harbor lógica de negócios diversa. O padrão é
0.redis.internal.cacheLayerDatabaseIndexO índice do banco de dados para a camada de cache de Harbor. O padrão é
0.redis.internal.initContainersOs contêineres init que são executados antes do Redis contêiner iniciar. O padrão é
[].redis.external.addrO endereço da Redis instância externa. O padrão é
192.168.0.2:6379.redis.external.sentinelMasterSetO nome do Redis conjunto mestre Sentinel (se aplicável). O padrão é
undefined.redis.external.coreDatabaseIndexO índice do banco de dados para o kernel. O padrão é
0.redis.external.jobserviceDatabaseIndexO índice do banco de dados para o jobservice. O padrão é
1.redis.external.registryDatabaseIndexO índice do banco de dados para o registry. O padrão é
2.redis.external.trivyAdapterIndexO índice do banco de dados para o Trivy adaptador. O padrão é
5.redis.external.harborDatabaseIndexO índice do banco de dados para a Harbor lógica de negócios diversa. O padrão é
0.redis.external.cacheLayerDatabaseIndexO índice do banco de dados para a camada de cache de Harbor. O padrão é
0.redis.external.usernameO nome de usuário para Redis autenticação externa. O padrão é
undefined.redis.external.passwordA senha para Redis autenticação externa. O padrão é
undefined.redis.external.existingSecretO segredo existente contendo a Redis senha. A chave deve ser
REDIS_PASSWORD. O padrão é"".redis.podAnnotationsAs anotações a serem adicionadas ao Redis pod. O padrão é
{}.
exporter.replicasO número de réplicas a serem executadas. O padrão é
1.exporter.revisionHistoryLimitO limite do histórico de revisões. O padrão é
10.exporter.podAnnotationsAnotações a serem adicionadas ao pod do exportador. O padrão é
{}.exporter.image.repositoryO repositório para a imagem do exportador. O padrão é
private-registry/harbor-exporter.exporter.image.tagA tag para a imagem do exportador. O padrão é
2.11.exporter.nodeSelectorRótulos de nó para atribuição de pod. O padrão é
{}.exporter.tolerationsTolerâncias para atribuição de pod. O padrão é
[].exporter.affinityAfinidades de nó ou pod. O padrão é
{}.exporter.topologySpreadConstraintsRestrições que definem como os Pods se espalham por domínios de falha, como regiões ou zonas de disponibilidade. O padrão é
[].exporter.automountServiceAccountTokenControla se deve montar o serviceAccountToken. O padrão é
false.exporter.cacheDurationA duração do cache para informações coletadas pelo exportador. O padrão é
30.exporter.cacheCleanIntervalO intervalo de limpeza do cache para informações coletadas pelo exportador. O padrão é
14400.exporter.priorityClassNameA classe de prioridade para executar o pod. O padrão é
undefined.
metrics.enabledHabilita Harbor métricas. O padrão é
false.metrics.core.pathO caminho da URL para métricas do kernel. O padrão é
/metrics.metrics.core.portA porta para métricas do kernel. O padrão é
8001.metrics.registry.pathO caminho da URL para métricas do registry. O padrão é
/metrics.metrics.registry.portA porta para métricas do registry. O padrão é
8001.metrics.exporter.pathO caminho da URL para métricas do exportador. O padrão é
/metrics.metrics.exporter.portA porta para métricas do exportador. O padrão é
8001.metrics.serviceMonitor.enabledHabilita a criação de um Prometheus ServiceMonitor (requer Prometheus CRDs). O padrão é
false.metrics.serviceMonitor.additionalLabelsRótulos adicionais a serem aplicados ao manifesto do ServiceMonitor. O padrão é
"".metrics.serviceMonitor.intervalO intervalo de coleta para métricas de Harbor. O padrão é
"".metrics.serviceMonitor.metricRelabelingsAs regras de reetiquetagem para métricas antes da ingestão. O padrão é
[].metrics.serviceMonitor.relabelingsAs regras de reetiquetagem para métricas antes da coleta. O padrão é
[].
trace.enabledHabilita a funcionalidade de rastreamento. O padrão é
false.trace.providerO provedor de rastreamento (
jaegerouotel). A versão do Jaeger deve ser 1.26 ou superior. O padrão éjaeger.trace.sample_rateA taxa de amostragem para dados de rastreamento.
1amostra 100%,0.5amostra 50%. O padrão é1.trace.namespaceO namespace para diferenciar diferentes serviços de Harbor.
trace.attributesUm dicionário de chave-valor para atributos definidos pelo usuário na inicialização do provedor de rastreamento.
trace.jaeger.endpointO endpoint para rastreamento do Jaeger. O padrão é
http://hostname:14268/api/traces.trace.jaeger.usernameO nome de usuário para autenticação do Jaeger.
trace.jaeger.passwordA senha para autenticação do Jaeger.
trace.jaeger.agent_hostO host do agente para o Jaeger.
trace.jaeger.agent_portA porta do agente para o Jaeger. O padrão é
6831.trace.otel.endpointO endpoint para rastreamento de OpenTelemetry. O padrão é
hostname:4318.trace.otel.url_pathO caminho da URL para OpenTelemetry. O padrão é
/v1/traces.trace.otel.compressionHabilita a compressão para OpenTelemetry. O padrão é
false.trace.otel.insecureEstabelece uma conexão insegura para OpenTelemetry. O padrão é
true.trace.otel.timeoutO tempo limite em segundos para OpenTelemetry. O padrão é
10.
cache.enabledHabilita a camada de cache. O padrão é
false.cache.expireHoursO tempo de expiração em horas para a camada de cache. O padrão é
24.
B Exemplo de um Registro Privado gráfico de configuração HA Helm #
O arquivo de valores de exemplo a seguir ilustra os parâmetros necessários para a configuração mínima Registro Privado de HA.
expose:
ingress:
hosts:
core: core.harbor.domain 1
externalURL: https://core.harbor.domain 2
portal:
replicas: 2 3
core:
replicas: 2 4
jobservice:
replicas: 2 5
registry:
replicas: 2 6
database:
type: external
external: 7
host: "192.168.0.1"
port: "5432"
username: "user"
password: "password"
coreDatabase: "registry"
existingSecret: "" 8
sslmode: "disable" 9
redis:
type: external
external: 10
addr: "192.168.0.2:6379" 11
sentinelMasterSet: "" 12
coreDatabaseIndex: "0" 13
jobserviceDatabaseIndex: "1"
registryDatabaseIndex: "2"
trivyAdapterIndex: "5"
harborDatabaseIndex: "6" 14
cacheLayerDatabaseIndex: "7"15
username: "" 16
password: ""
existingSecret: "" 17
persistence:
enabled: true 18Nome de host do serviço kernel na regra Ingress. | |
A URL externa para o serviço harbor-core. | |
Número de réplicas a serem criadas. Especifique dois ou mais. | |
Preencha os detalhes da conexão do banco de dados na seção | |
Se estiver usando um segredo existente, o valor deve ser | |
Aceita um dos seguintes valores:
| |
Preencha as informações de conexão na seção | |
Suporta redis e redis+sentinel. | |
O nome do conjunto de Valkey instâncias a serem monitoradas. Deve ser configurado para suportar redis+sentinel. | |
Deve ser | |
Opcional. O padrão é | |
Opcional. O padrão é | |
Se estiver vazio, será autenticado contra o usuário padrão. | |
Se utilizado, a chave deve ser <REDIS_PASSWORD>. | |
Para armazenar todas as imagens, metadados e digitalizações, certifique-se de que as configurações relacionadas à persistência (Parâmetros de persistência) estejam devidamente configuradas. |
C Licença GFDL (GNU Free Documentation License) #
Copyright © 2000, 2001, 2002 Free Software Foundation, Inc. 51 Franklin St, quinto andar, Boston, MA 02110-1301 EUA. Qualquer pessoa está autorizada a reproduzir e distribuir cópias literais deste documento de licença, mas não é permitido alterá-lo.
C1 0. PREÂMBULO #
A finalidade desta Licença é tornar um manual, um livro ou outro documento funcional e útil "livre", no sentido de garantir a todos a liberdade efetiva para copiá-lo e redistribuí-lo, com ou sem modificações, para fins comerciais ou não. Em segundo lugar, esta Licença preserva ao autor e ao editor uma forma de obter crédito pelo seu trabalho, sem ser considerado responsável pelas modificações feitas por outros.
Esta Licença é um tipo de "copyleft", o que significa que trabalhos derivados do documento também devem ser livres no mesmo sentido. Ela complementa a Licença Pública Geral GNU, que é uma licença de copyleft projetada para software livre.
Criamos esta Licença para usá-la em manuais de software livre, pois o software livre precisa de documentação livre: um programa livre deve incluir manuais que ofereçam as mesmas liberdades que o software. Contudo, esta Licença não está limitada a manuais de software; pode ser usada para qualquer trabalho textual, independentemente do assunto ou se é publicado como um livro impresso. Recomendamos esta Licença principalmente para trabalhos cuja finalidade seja instrução ou referência.
C2 1. APLICABILIDADE E DEFINIÇÕES #
Esta Licença se aplica a qualquer manual ou outro trabalho, em qualquer meio, que contenha um aviso colocado pelo detentor dos direitos autorais informando que pode ser distribuído sob os termos desta Licença. Esse aviso concede uma licença em nível mundial, isenta do pagamento de royalties e de duração ilimitada, para usar o trabalho sob as condições aqui estabelecidas. O "Documento", abaixo, refere-se a qualquer manual ou trabalho. Qualquer membro do público pode ser um licenciado e é tratado como "você". Você aceita a licença se copiar, modificar ou distribuir o trabalho de uma forma que exija permissão de acordo com a lei de direitos autorais.
Uma "Versão Modificada" do Documento significa qualquer trabalho que contenha o Documento ou parte dele, seja copiado fielmente, ou com modificações e/ou traduzido para outro idioma.
Uma "Seção Secundária" é um apêndice nomeado ou uma seção de introdução do Documento que trata exclusivamente da relação dos editores ou autores do Documento com o assunto geral do Documento (ou com questões relacionadas) e não contém nada que possa estar diretamente ligado a esse assunto geral. (Portanto, se o Documento for parcialmente um livro de matemática, uma Seção Secundária não poderá explicar nada de matemática.) A relação pode ser uma questão de conexão histórica com o assunto ou com temas relacionados, ou de posição legal, comercial, filosófica, ética ou política a respeito deles.
As "Seções Invariáveis" são determinadas Seções Secundárias cujos títulos são designados como sendo referentes a essas Seções Invariáveis, no aviso que indica que o Documento foi lançado sob esta Licença. Se uma seção não se encaixar na definição acima de Seção Secundária, não poderá ser designada como Invariável. O documento pode não conter Seções Invariáveis. Se o Documento não identificar nenhuma Seção Invariável, então não há nenhuma.
Os "Textos de Capa" são certos trechos curtos de texto que estão listados, como Textos de Capa Frontal ou Textos de Capa Traseira, no aviso que diz que o Documento é liberado sob esta Licença. Um Texto de Capa Frontal pode ter no máximo 5 palavras, e um Texto de Contracapa pode ter no máximo 25 palavras.
Uma cópia "Transparente" do Documento significa uma cópia que pode ser lida por máquina, representada em um formato cuja especificação está disponível ao público em geral, que é adequada para revisar o documento de forma direta com editores de texto genéricos ou (para imagens compostas de pixels) programas gráficos genéricos ou (para desenhos) algum editor de desenho amplamente disponível, e que é adequada para entrada em formatadores de texto ou para tradução automática para uma variedade de formatos adequados para entrada em formatadores de texto. Uma cópia feita em um formato de arquivo Transparente cuja marcação, ou ausência de marcação, foi organizada para impedir ou desencorajar modificações subsequentes pelos leitores não é Transparente. Um formato de imagem não é Transparente se usado para qualquer quantidade substancial de texto. Uma cópia que não é "Transparente" é chamada "Opaca".
Exemplos de formatos adequados para cópias Transparentes incluem ASCII simples sem marcação, formato de entrada Texinfo, formato de entrada LaTeX, SGML ou XML usando um DTD publicamente disponível, e HTML simples, PostScript ou PDF que estejam em conformidade com padrões e sejam projetados para modificação humana. Exemplos de formatos de imagem transparentes incluem PNG, XCF e JPG. Formatos Opacos incluem formatos proprietários que podem ser lidos e editados apenas por processadores de texto proprietários, SGML ou XML para os quais o DTD e/ou ferramentas de processamento não estão geralmente disponíveis, e o HTML, PostScript ou PDF gerados por máquina produzidos por alguns processadores de texto apenas para fins de saída.
A "Página de Título" significa, para um livro impresso, a própria página do título, além das páginas subsequentes necessárias para conter, de forma legível, o material que esta Licença requer que apareça na página do título. Para obras em formatos que não têm uma página de título assim, a "Página de Título" significa o texto próximo à ocorrência mais proeminente do título da obra, precedendo o início do corpo do texto.
Uma seção "Intitulada XYZ" significa uma subunidade nomeada do Documento cujo título é precisamente XYZ ou contém XYZ entre parênteses após o texto que traduz XYZ para outro idioma. (Aqui XYZ representa o nome de uma seção específica mencionada abaixo, como "Agradecimentos", "Dedicatória", "Apoio" ou "Histórico".) "Preservar o Título" de tal seção quando você modifica o Documento significa que ela continua sendo uma seção "Intitulada XYZ" de acordo com esta definição.
O Documento pode incluir Isenções de Responsabilidade quanto a Garantia próximas ao aviso que indica que esta Licença se aplica a este Documento. Essas Isenções de Responsabilidade quanto a Garantia são consideradas incluídas por referência nesta Licença, mas apenas no que diz respeito à isenção de garantias: qualquer outra implicação que essas Isenções de Responsabilidade possam ter é nula e não tem efeito sobre o significado desta Licença.
C3 2. CÓPIAS LITERAIS #
Você pode copiar e distribuir o Documento em qualquer meio, comercialmente ou não, desde que esta Licença, as informações de copyright e o aviso de licença dizendo que esta Licença se aplica ao Documento sejam reproduzidos em todas as cópias, e que você não adicione outras condições, quaisquer que sejam, às condições desta Licença. Você não pode usar medidas técnicas para obstruir ou controlar a leitura ou a cópia futura das cópias que você fizer ou distribuir. Contudo, você pode aceitar remuneração em troca das cópias. Se você distribuir um número suficientemente grande de cópias, deverá também seguir as condições na seção 3.
Você também pode emprestar cópias, sob as mesmas condições mencionadas acima, e pode exibir cópias publicamente.
C4 3. COPIANDO EM QUANTIDADE #
Se você publicar cópias impressas (ou cópias em mídias que normalmente têm capas impressas) do Documento, em número superior a 100, e o aviso de licença do Documento exigir Textos de Capa, deverá encadernar as cópias em capas que contenham, de forma clara e legível, todos esses Textos de Capa: Textos de Capa Frontal na capa frontal e Textos de Contracapa na contracapa. As duas capas também devem identificar, de forma clara e legível, você como o editor dessas cópias. A capa frontal deve apresentar o título completo com todas as palavras do título igualmente proeminentes e visíveis. Você pode adicionar outros materiais nas capas. Cópias com mudanças limitadas às capas, desde que preservem o título do Documento e satisfaçam essas condições, podem ser tratadas como cópias literais em outros aspectos.
Se os textos exigidos para qualquer uma das capas forem muito volumosos para serem incluídos de forma legível, você deve colocar os primeiros listados (quantos couberem razoavelmente) na própria capa e continuar o restante nas páginas adjacentes.
Se você publicar ou distribuir cópias Opacas do Documento em número superior a 100, deverá incluir uma cópia Transparente legível por máquina juntamente com cada cópia Opaca, ou informar em, ou juntamente com, cada cópia Opaca um local na rede de computadores do qual o público geral possa acessar e baixar, usando protocolos de rede públicos padrão, uma cópia Transparente completa do Documento, livre de material adicionado. Se você optar pela segunda opção, deverá tomar medidas razoavelmente prudentes, quando começar a distribuição de cópias Opacas em quantidade, para garantir que essa cópia Transparente permaneça acessível no local indicado até pelo menos um ano após a última vez que você distribuir uma cópia Opaca (diretamente ou através de seus agentes ou distribuidores) dessa edição ao público.
É solicitado, mas não exigido, que você contate os autores do Documento muito antes de redistribuir qualquer número grande de cópias, para dar-lhes a oportunidade de fornecer uma versão atualizada do Documento.
C5 4. MODIFICAÇÕES #
Você pode copiar e distribuir uma Versão Modificada do Documento sob as condições das seções 2 e 3 acima, desde que forneça a Versão Modificada estritamente sob esta Licença, com a Versão Modificada no lugar do Documento, permitindo assim a distribuição e modificação da Versão Modificada a quem quer que possua uma cópia desta. Além disso, você deve realizar as seguintes ações na Versão Modificada:
Use na Página de Título (e nas capas, se houver) um título distinto do título do Documento e dos de versões anteriores (os quais devem, se houver, ser listados na seção "Histórico" do Documento). Você pode usar o mesmo título de uma versão anterior se o editor original dessa versão der permissão.
Liste na Página de Título, como autores, uma ou mais pessoas ou entidades responsáveis pela autoria das modificações na Versão Modificada, juntamente com pelo menos cinco dos autores principais do Documento (todos os seus autores principais, se houver menos de cinco), a menos que eles dispensem você dessa exigência.
Mencione na Página de Título o nome do editor da Versão Modificada, como o editor.
Preserve todas as informações de copyright do Documento.
Adicione informações de copyright apropriadas para suas modificações ao lado das outras informações de copyright.
Inclua, imediatamente após as informações de copyright, um aviso de licença concedendo ao público permissão para usar a Versão Modificada sob os termos desta Licença, na forma mostrada no Adendo abaixo.
Preserve, nesse aviso de licença, as listas completas de Seções Invariantes e os Textos de Capa necessários fornecidos no aviso de licença do Documento.
Inclua uma cópia inalterada desta Licença.
Preserve a seção intitulada "Histórico", Preserve seu Título e adicione a ela um item mencionando pelo menos o título, o ano, os novos autores e o editor da Versão Modificada, conforme indicado na Página de Título. Se não houver uma seção intitulada "Histórico" no Documento, crie uma mencionando o título, o ano, os autores e o editor do Documento, conforme indicado na Página de Título; em seguida, adicione um item descrevendo a Versão Modificada, como mencionado na frase anterior.
Preserve a localização de rede, se houver, indicada no Documento para acesso público a uma cópia transparente deste e, da mesma maneira, as localizações de rede indicadas no Documento para versões anteriores nas quais ele se baseia. Essas informações podem ser incluídas na seção “Histórico”. Você pode omitir uma localização de rede para um trabalho que foi publicado pelo menos quatro anos antes do Documento em si, ou se o editor original da versão à qual a localização se refere der permissão.
Para qualquer seção intitulada "Agradecimentos" ou "Dedicatória", Preserve o Título da seção, e preserve dentro da seção toda a essência e o tom de cada um dos agradecimentos e/ou dedicatórias aos colaboradores nela mencionados.
Preserve todas as Seções Invariantes do Documento, inalteradas em seu texto e títulos. Números de seção ou o equivalente não são considerados parte dos títulos das seções.
Apague qualquer seção intitulada “Apoio”. Tal seção não pode ser incluída na Versão Modificada.
Não modifique o título de qualquer seção existente para "Apoio" nem de forma a gerar conflito com o título de qualquer Seção Invariável.
Preserve as Isenções de Responsabilidade quanto a Garantia.
Se a Versão Modificada incluir novas seções iniciais ou apêndices que sejam qualificados como Seções Secundárias e não contiver material copiado do Documento, você poderá, a seu critério, tornar invariantes algumas dessas seções ou todas elas. Para fazer isso, adicione seus títulos à lista de Seções Invariantes no aviso de licença da Versão Modificada. Esses títulos devem ser diferentes de outros títulos de seção.
Você pode adicionar uma seção intitulada "Apoio", desde que ela não contenha nada além do apoio recebido para sua Versão Modificada por várias partes--; por exemplo, declarações de avaliação por pares ou de que o texto foi aprovado por uma organização como a definição oficial de um padrão.
Você pode adicionar uma passagem de até cinco palavras como Texto de Folha de Rosto, e uma passagem de até 25 palavras como Texto de Contracapa, ao fim da lista de Textos de Capa na Versão Modificada. Somente uma passagem de Texto de Folha de Rosto e uma de Texto de Contracapa pode ser adicionada por (ou através de arranjos feitos por) uma entidade qualquer. Se o Documento já incluir um texto de capa para a mesma capa, anteriormente incluído por você ou por arranjo feito pela mesma entidade em cujo nome você está agindo, não será possível adicionar outro; mas você poderá substituir o antigo, com permissão explícita do editor anterior que o incluiu.
O(s) autor(es) e editor(es) do Documento, por esta Licença, não concedem permissão para que seu(s) nome(s) seja(m) usado(s) para publicidade ou para afirmar ou sugerir apoio de qualquer Versão Modificada.
C6 5. COMBINANDO DOCUMENTOS #
Você pode combinar o Documento com outros documentos publicados sob esta Licença, sob os termos definidos na seção 4 acima para versões modificadas, desde que você inclua na combinação todas as Seções Invariantes de todos os documentos originais, sem modificações, e as liste como Seções Invariantes de seu trabalho combinado, no aviso de licença, e que você preserve todas as Isenções de Garantia.
O trabalho combinado somente precisa conter uma cópia desta Licença, e várias Seções Invariantes idênticas podem ser substituídas por uma única cópia. Se houver várias Seções Invariantes com o mesmo nome, mas com conteúdos diferentes, torne o título de cada uma dessas seções único, adicionando ao fim dele, entre parênteses, o nome do autor ou editor original da seção, se conhecido, ou então um número exclusivo. Faça o mesmo ajuste nos títulos de seção na lista de Seções Invariantes no aviso de licença do trabalho combinado.
Na combinação, você deve combinar quaisquer seções intituladas "Histórico" nos vários documentos originais, formando uma seção intitulada "Histórico"; do mesmo modo, combine quaisquer seções intituladas "Agradecimentos" e quaisquer seções intituladas "Dedicatória". Você deve eliminar todas as seções intituladas “Apoio”.
C7 6. COLEÇÕES DE DOCUMENTOS #
Você pode fazer uma coleção consistindo do Documento e outros documentos publicados sob esta Licença, e substituir as cópias individuais desta Licença nos vários documentos por uma única cópia a ser incluída na coleção, desde que você siga as regras desta Licença para cópias literais de cada um dos documentos em todos os outros aspectos.
Você pode extrair um único documento dessa coleção e distribuí-lo individualmente sob esta Licença, desde que insira uma cópia desta Licença no documento extraído e siga esta Licença em todos os outros aspectos com relação à cópia literal desse documento.
C8 7. AGREGAÇÃO A TRABALHOS INDEPENDENTES #
Uma compilação do Documento ou seus derivados com outros documentos ou trabalhos separados e independentes, dentro de ou junto a um volume de uma mídia de armazenamento ou distribuição, é chamada de "agregado" se os direitos autorais resultantes da compilação não forem usados para limitar os direitos legais dos usuários da compilação além do que os trabalhos individuais permitem. Quando o Documento é incluído em um agregado, esta Licença não se aplica a outros trabalhos no agregado que não sejam, por sua vez, derivados do Documento.
Se o requisito do Texto de Capa da seção 3 for aplicável a estas cópias do Documento e, ainda, se o Documento for menor do que a metade do agregado inteiro, os Textos de Capa do Documento poderão ser colocados em capas que encerrem o Documento dentro do agregado, ou no equivalente eletrônico das capas, se o Documento estiver em formato eletrônico. Caso contrário, eles deverão aparecer como capas impressas que envolvam o agregado inteiro.
C9 8. TRADUÇÕES #
A tradução é considerada um tipo de modificação, portanto, você pode distribuir traduções do Documento em conformidade com os termos da seção 4. A substituição de Seções Invariantes por traduções requer permissão especial de seus detentores de direitos autorais, mas você pode incluir traduções de algumas ou de todas as Seções Invariantes, além das versões originais dessas Seções Invariantes. Você pode incluir uma tradução desta Licença e todos os avisos de licença no Documento, bem como quaisquer isenções de garantia, desde que também inclua a versão original em inglês desta Licença e as versões originais dos avisos e das isenções de garantia. Em caso de discordância entre a tradução e a versão original desta Licença ou entre um aviso de licença ou uma isenção de garantia, a versão original prevalecerá.
Se uma seção do Documento for intitulada "Agradecimentos", "Dedicatória" ou "Histórico", o requisito (seção 4) para Preservar seu Título (seção 1) normalmente exigirá a mudança do título em si.
C10 9. REVOGAÇÃO #
Você não pode copiar, modificar, sublicenciar ou distribuir o Documento, exceto como expressamente previsto por esta Licença. Qualquer outra tentativa de copiar, modificar, sublicenciar ou distribuir o Documento é anulada, e implicará a revogação automática de seus direitos sob esta Licença. Porém, terceiros a quem você forneceu cópias ou direitos sob os termos desta Licença não terão suas licenças revogadas, desde que permaneçam em plena conformidade com ela.
C11 1. REVISÕES FUTURAS DESTA LICENÇA #
A Free Software Foundation pode publicar ocasionalmente novas versões revisadas da Licença de Documentação Livre GNU. As novas versões serão semelhantes à versão atual, mas poderão diferir em detalhes para atender a novos problemas ou preocupações. Consulte a https://www.gnu.org/copyleft/.
A cada versão da Licença é atribuído um número de versão exclusivo. Se o Documento especificar que um número de versão específico desta Licença "ou de qualquer versão posterior" se aplica a ele, você terá a opção de seguir os termos e condições da versão especificada ou de qualquer versão posterior que tenha sido publicada (não como rascunho) pela Free Software Foundation. Se o Documento não especificar um número de versão desta Licença, você poderá escolher qualquer versão já publicada (não como rascunho) pela Free Software Foundation.
C12 ADENDO: Como usar esta Licença em seus documentos #
Copyright (c) YEAR YOUR NAME. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".
Se você tiver Seções Invariantes, Textos de Capa Frontal e Textos de Contracapa, substitua a linha "com…Textos." por isto:
with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
Se você tiver Seções Invariantes sem Textos de Capa, ou alguma outra combinação das três, una essas duas alternativas para se adequar à situação.
Se seu documento contiver exemplos não triviais de código de programação, recomendamos publicar esses exemplos paralelamente, sob a licença de software livre de sua escolha, como a Licença Pública Geral GNU, para permitir seu uso em software livre.



