Instalando a usar Docker¶
Com a implantação do Weblate dockerizada, pode ter a sua instância Weblate pessoal em funcionamento em segundos. Todas as dependências do Weblate já estão incluídas. PostgreSQL é configurado como o banco de dados padrão e o Redis como backend de cache.
Requisitos de hardware¶
O Weblate deve funcionar em qualquer hardware contemporâneo sem problemas. A seguir está a configuração mínima necessária para executar o Weblate num único host (Weblate, banco de dados e servidor web):
3 GB de RAM
2 núcleos de CPU
1 GB de espaço de armazenamento
Nota
Os requisitos reais para a sua instalação do Weblate variam fortemente com base no tamanho das traduções geridas nele.
Memória utilizada¶
Quanto mais memória, melhor - ela é usada para armazenamento em cache em todos os níveis (sistema de ficheiros, banco de dados e Weblate). Para centenas de componentes de tradução, recomenda-se pelo menos 4 GB de RAM.
Dica
Para sistemas com menos memória do que o recomendado, Configuração do Celery de processo único é recomendado.
Uso da CPU¶
Muitos utilizadores simultâneos aumentam a quantidade de núcleos de CPU necessários.
Uso de armazenamento¶
O uso típico de armazenamento de banco de dados é de cerca de 300 MB por 1 milhão de palavras hospedadas.
O espaço de armazenamento necessário para repositórios clonados varia, mas o Weblate tenta manter o seu tamanho mínimo fazendo clones rasos.
Nodes¶
Para sites de pequeno e médio porte (milhões de palavras hospedadas), todos os componentes do Weblate (consulte Visão geral da arquitetura) podem ser executados num único nó.
Quando atingir centenas de milhões de palavras hospedadas, é recomendável ter um nó dedicado para o banco de dados (consulte Configuração de banco de dados para o Weblate).
Instalação¶
Dica
Os exemplos a seguir presumem que tem um ambiente Docker funcional, com docker-compose-plugin
instalado. Verifique a documentação do Docker para obter instruções.
Isto cria um servidor de implantação do Weblate via HTTP, portanto, deve posicioná-lo atrás de um proxy de terminação HTTPS. Também pode implantar com um proxy HTTPS, consulte Certificados SSL automáticos a usar Let’s Encrypt. Para configurações maiores, consulte Dimensionando horizontalmente.
Clone o repositório weblate-docker:
git clone https://github.com/WeblateOrg/docker-compose.git weblate-docker cd weblate-docker
Crie um ficheiro
docker-compose.override.yml
com as suas configurações. Veja Variáveis de ambiente do Docker para uma lista completa das variáveis de ambiente.version: '3' services: weblate: ports: - 80:8080 environment: WEBLATE_EMAIL_HOST: smtp.example.com WEBLATE_EMAIL_HOST_USER: user WEBLATE_EMAIL_HOST_PASSWORD: pass WEBLATE_SERVER_EMAIL: weblate@example.com WEBLATE_DEFAULT_FROM_EMAIL: weblate@example.com WEBLATE_SITE_DOMAIN: weblate.example.com WEBLATE_ADMIN_PASSWORD: password for the admin user WEBLATE_ADMIN_EMAIL: weblate.admin@example.com
Nota
Se
WEBLATE_ADMIN_PASSWORD
não estiver definida, o utilizador admin é criado com uma palavra-passe aleatória mostrada na primeira inicialização.O exemplo fornecido faz o Weblate escutar na porta 80. Edite o mapeamento da porta no ficheiro
docker-compose.override.yml
para alterar isso.Inicie os contentores do Weblate:
docker compose up
Aproveite a implantação do Weblate, ele está acessível na porta 80 do contentor weblate
.
Veja também
Escolher o registo de imagem do Docker¶
Os contentores do Weblate são publicados nos seguintes registos:
Docker Hub, veja https://hub.docker.com/r/weblate/weblate
Registo de pacotes do GitHub, consulte https://github.com/WeblateOrg/docker/pkgs/container/weblate
Nota
Todos os exemplos atualmente buscam imagens do Docker Hub, por favor ajuste a configuração para utilizar um registo diferente.
Escolher a tag de imagem do Docker¶
Por favor, escolha uma tag que corresponda ao seu ambiente e expectativas:
Nome da tag |
Descrição |
Caso de uso |
---|---|---|
|
Versão estável do Weblate, corresponde à última versão marcada |
Atualizações contínuas num ambiente de produção |
|
Versão estável do Weblate |
Atualizações contínuas dentro de uma versão principal num ambiente de produção |
|
Versão estável do Weblate |
Atualizações contínuas dentro de uma versão secundária num ambiente de produção |
|
Versão estável do Weblate |
Implantação bem definida num ambiente de produção |
|
Lançamento estável do Weblate com alterações de desenvolvimento no contentor Docker (por exemplo, dependências atualizadas) |
Atualizações contínuas num ambiente de teste |
|
Lançamento estável do Weblate com alterações de desenvolvimento no contentor Docker (por exemplo, dependências atualizadas) |
Implantação bem definida num ambiente de teste |
|
Versão de desenvolvimento do Weblate do Git |
Atualizações contínuas para testar os próximos recursos do Weblate |
|
Versão de desenvolvimento do Weblate do Git |
Implantação bem definida para testar os próximos recursos da Weblate |
Cada imagem é testada pelo nosso CI antes de ser publicada, então até mesmo a versão bleeding deve ser bastante segura de usar.
A lista completa de tags publicadas encontra-se em GitHub Packages
Contentor Docker com suporte a HTTPS¶
Por favor, veja Instalação para instruções genéricas de implantação, esta secção apenas menciona diferenças em comparação a ela.
Usando os seus próprios certificados SSL¶
No caso de ter o seu próprio certificado SSL que deseja usar, basta pôr os ficheiros no volume de dados Weblate (veja Volumes de contentor Docker):
ssl/fullchain.pem
a conter o certificado, incluindo quaisquer certificados CA necessáriosssl/privkey.pem
a conter a chave privada
Ambos os ficheiros devem pertencer ao mesmo utilizador que inicia o contentor do docker e ter a máscara de ficheiro definida como 600
(legível e gravável apenas pelo utilizador dono).
Além disso, o contentor Weblate agora aceitará conexões SSL na porta 4443. Ainda quererá incluir o encaminhamento de porta para HTTPS na substituição de composição do docker:
version: '3'
services:
weblate:
ports:
- 80:8080
- 443:4443
Se já hospeda outros sites no mesmo servidor, é provável que as portas 80
e 443
sejam usadas por um proxy reverso, como NGINX. Para passar a conexão HTTPS do NGINX para o contentor do docker, pode usar a seguinte configuração:
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name <SITE_URL>;
ssl_certificate /etc/letsencrypt/live/<SITE>/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/<SITE>/privkey.pem;
location / {
proxy_set_header HOST $host;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
proxy_pass https://127.0.0.1:<EXPOSED_DOCKER_PORT>;
}
}
Substitua <SITE_URL>
, <SITE>
e <EXPOSED_DOCKER_PORT>
por valores reais do seu ambiente.
Certificados SSL automáticos a usar Let’s Encrypt¶
Caso queira usar certificados SSL Let’s Encrypt gerados automaticamente na instalação pública, precisa adicionar um proxy HTTPS reverso num contentor Docker adicional, https-portal será usado para isso. Isso é usado no ficheiro docker-compose-https.yml
. Em seguida, crie um ficheiro docker-compose-https.override.yml
com as suas configurações:
version: '3'
services:
weblate:
environment:
WEBLATE_EMAIL_HOST: smtp.example.com
WEBLATE_EMAIL_HOST_USER: user
WEBLATE_EMAIL_HOST_PASSWORD: pass
WEBLATE_SITE_DOMAIN: weblate.example.com
WEBLATE_ADMIN_PASSWORD: password for admin user
https-portal:
environment:
DOMAINS: 'weblate.example.com -> http://weblate:8080'
Sempre que invocar docker compose, precisa lhe passar os dois ficheiros e depois:
docker compose -f docker-compose-https.yml -f docker-compose-https.override.yml build
docker compose -f docker-compose-https.yml -f docker-compose-https.override.yml up
Atualizando o contentor Docker¶
Normalmente, é uma boa ideia atualizar apenas o contentor Weblate e manter o contentor PostgreSQL na versão que possui, já que atualizar o PostgreSQL é muito doloroso e na maioria dos casos não traz muitos benefícios.
Alterado na versão 4.17-1: Desde o Weblate 4.17-1, o contentor Docker usa Django 4.2, o que requer PostgreSQL 12 ou mais recente, atualize-o antes de atualizar o Weblate. Consulte Atualizando contentor PostgreSQL.
Pode fazer isso a manter o docker-compose existente e apenas obter as imagens mais recentes e reiniciar:
# Fetch latest versions of the images
docker compose pull
# Stop and destroy the containers
docker compose down
# Spawn new containers in the background
docker compose up -d
# Follow the logs during upgrade
docker compose logs -f
O banco de dados do Weblate deve ser migrado automaticamente na primeira inicialização e não deve haver necessidade de ações manuais adicionais.
Nota
Atualizações entre versões principais não são suportadas pelo Weblate. Se estiver na série 3.x e quiser atualizar para 4.x, primeiro atualize à imagem 4.0.x-y mais recente (no momento em que escrevo esta é a 4.0.4-5
), que faça a migração e, em seguida, continue atualizando para as versões mais recentes.
Também pode atualizar o repositório docker-compose
, embora não seja necessário na maioria dos casos. Veja Atualizando contentor PostgreSQL para atualizar o servidor PostgreSQL.
Atualizando contentor PostgreSQL¶
Os contentores PostgreSQL não oferecem suporte a atualização automática entre versões, precisa realizar a atualização manualmente. Os passos a seguir mostram uma das opções de atualização.
Pare o contentor do Weblate:
docker compose stop weblate cache
Faça backup do banco de dados:
docker compose exec database pg_dumpall --clean --if-exists --username weblate > backup.sql
Pare o contentor de banco de dados:
docker compose stop database
Remova o volume do PostgreSQL:
docker compose rm -v database docker volume remove weblate-docker_postgres-data
Dica
O nome do volume contém o nome do projeto Docker Compose, que por padrão é o nome do diretório, que neste caso é
weblate-docker
neste documento.Ajuste o
docker-compose.yml
para usar a nova versão do PostgreSQL.Inicie o contentor de banco de dados:
docker compose up -d database
Restaure o banco de dados a partir do backup:
cat backup.sql | docker compose exec -T database psql --username weblate --dbname weblate
Dica
Verifique se o nome do banco de dados corresponde a
POSTGRES_DB
.(Opcional) Atualize a palavra-passe do utilizador do Weblate. Isto pode ser necessário ao migrar para o PostgreSQL 14 ou 15, pois a forma de armazenar palavras-passe foi alterada:
docker compose exec -T database psql --username weblate --dbname weblate -c "ALTER USER weblate WITH PASSWORD 'weblate'"
Dica
Verifique se o nome do banco de dados corresponde a
POSTGRES_DB
.Inicie todos os contentores restantes:
docker compose up -d
Autenticação como administrador¶
Após a configuração do contentor, pode entrar como utilizador admin com a palavra-passe fornecida em WEBLATE_ADMIN_PASSWORD
, ou uma palavra-passe aleatória gerada na primeira inicialização se não tiver sido definida.
Para redefinir a palavra-passe do admin, reinicie o contentor com WEBLATE_ADMIN_PASSWORD
definido com a nova palavra-passe.
Veja também
WEBLATE_ADMIN_PASSWORD
,
WEBLATE_ADMIN_NAME
,
WEBLATE_ADMIN_EMAIL
Quantidade de processos e consumo de memória¶
A quantidade de processos de trabalho para uWSGI e Celery é determinado automaticamente com base no quantidade de CPUs. Isso funciona bem para a maioria das máquinas virtuais em nuvem, pois normalmente têm poucas CPUs e boa quantidade de memória.
Caso tenha muitos núcleos de CPU e tenha problemas de memória insuficiente, tente reduzir a quantidade de workers:
environment:
WEBLATE_WORKERS: 2
Também pode ajustar as categorias de workers individuais:
environment:
WEB_WORKERS: 4
CELERY_MAIN_OPTIONS: --concurrency 2
CELERY_NOTIFY_OPTIONS: --concurrency 1
CELERY_TRANSLATE_OPTIONS: --concurrency 1
O uso da memória pode ser reduzido ainda mais com a execução de apenas um único processo do Celery:
environment:
CELERY_SINGLE_PROCESS: 1
Dimensionando horizontalmente¶
Added in version 4.6.
Pode executar vários contentores Weblate para dimensionar o serviço horizontalmente. O volume /app/data
deve ser compartilhado por todos os contentores, é recomendado usar um sistema de ficheiros de cluster como o GlusterFS para isso. O volume /app/cache
deve ser separado para cada contentor.
Cada contentor do Weblate tem uma função definida usando a variável de ambiente WEBLATE_SERVICE
. Siga atentamente a documentação, pois alguns dos serviços devem ser executados apenas uma vez no cluster e a ordem dos serviços também é importante.
Pode encontrar configuração de exemplo no repositório docker-compose
como docker-compose-split.yml.
Variáveis de ambiente do Docker¶
Muitas das Configurações do Weblate podem ser definidas no contentor Docker usando as variáveis de ambiente descritas abaixo.
Se precisar definir uma configuração não exposta por meio de variáveis de ambiente do Docker, consulte Configuração além das variáveis de ambiente.
Passar segredos¶
Added in version 5.0.
O contentor do Weblate suporta a passagem de segredos como ficheiros. Para utilizá-lo, adicione o sufixo _FILE
à variável de ambiente e passe o ficheiro secreto via Docker.
Relacionado docker-compose.yml
pode ser parecido com:
services:
weblate:
environment:
POSTGRES_PASSWORD_FILE: /run/secrets/db_password
secrets:
- db_password
database:
environment:
POSTGRES_PASSWORD_FILE: /run/secrets/db_password
secrets:
- db_password
secrets:
db_password:
file: db_password.txt
Veja também
Configurações genéricas¶
- WEBLATE_DEBUG¶
Configura o modo de depuração do Django a usar
DEBUG
.Exemplo:
environment: WEBLATE_DEBUG: 1
Veja também
- WEBLATE_LOGLEVEL¶
Configure a verbosidade do registo. Defina como
DEBUG
para obter logs mais detalhados.O padrão é
INFO
quandoWEBLATE_DEBUG
está desligado,DEBUG
é usado quando o modo de depuração está ligado.Para obter um registo mais silencioso, use
ERROR
ouWARNING
.
- WEBLATE_LOGLEVEL_DATABASE¶
Configura o log da verbosidade das consultas ao banco de dados.
- WEBLATE_SITE_TITLE¶
Altera o título do site mostrado no cabeçalho de todas as páginas.
- WEBLATE_SITE_DOMAIN¶
Configura o domínio do site. Este parâmetro é obrigatório.
Veja também
- WEBLATE_ADMIN_NAME¶
- WEBLATE_ADMIN_EMAIL¶
Configura o nome e o e-mail do administrador do site. É usado para
ADMINS
e para criar o utilizador admin (vejaWEBLATE_ADMIN_PASSWORD
para mais informações).Exemplo:
environment: WEBLATE_ADMIN_NAME: Weblate admin WEBLATE_ADMIN_EMAIL: noreply@example.com
- WEBLATE_ADMIN_PASSWORD¶
Define a palavra-passe para o utilizador admin.
Se não for definido e o utilizador admin não existir, ele será criado com uma palavra-passe aleatória mostrada na primeira inicialização do contentor.
Se não for definido e o utilizador admin existir, nenhuma ação será executada.
Se definido, o utilizador admin é ajustado em cada inicialização do contentor para corresponder a
WEBLATE_ADMIN_PASSWORD
,WEBLATE_ADMIN_NAME
eWEBLATE_ADMIN_EMAIL
.
Aviso
Pode ser um risco de segurança armazenar a palavra-passe no ficheiro de configuração. Considere usar essa variável apenas para configuração inicial (ou deixe o Weblate gerar uma palavra-passe aleatória na inicialização) ou para recuperação de palavra-passe.
- WEBLATE_ADMIN_NOTIFY_ERROR¶
Se deve enviar e-mail para administradores em caso de erro de servidor. Ativado por padrão.
Talvez queira usar outra coleta de erros, como Sentry ou Rollbar e desativar esta opção.
Veja também
- WEBLATE_SERVER_EMAIL¶
O endereço de e-mail a partir do qual as mensagens de erro são enviadas.
Veja também
- WEBLATE_DEFAULT_FROM_EMAIL¶
Configura o endereço para e-mails de saída.
Veja também
- WEBLATE_ADMINS_CONTACT¶
Configura
ADMINS_CONTACT
.
- WEBLATE_CONTACT_FORM¶
Configura o comportamento do formulário de contato, veja
CONTACT_FORM
.
- WEBLATE_ALLOWED_HOSTS¶
Configura os nomes de host HTTP permitidos a usar
ALLOWED_HOSTS
.O padrão é `` * `` que permite todos os nomes de host.
Exemplo:
environment: WEBLATE_ALLOWED_HOSTS: weblate.example.com,example.com
- WEBLATE_REGISTRATION_OPEN¶
Configura se os registos são abertos a alternar
REGISTRATION_OPEN
.Exemplo:
environment: WEBLATE_REGISTRATION_OPEN: 0
- WEBLATE_REGISTRATION_ALLOW_BACKENDS¶
Configura quais métodos de autenticação podem ser usados para criar uma nova conta via
REGISTRATION_ALLOW_BACKENDS
.Exemplo:
environment: WEBLATE_REGISTRATION_OPEN: 0 WEBLATE_REGISTRATION_ALLOW_BACKENDS: azuread-oauth2,azuread-tenant-oauth2
- WEBLATE_REGISTRATION_REBIND¶
Added in version 4.16.
Configura
REGISTRATION_REBIND
.
- WEBLATE_TIME_ZONE¶
Configura o fuso horário usado no Weblate, veja
django: TIME_ZONE
.Nota
Para alterar o fuso horário do próprio contentor do Docker, use a variável de ambiente `` TZ``.
Exemplo:
environment: WEBLATE_TIME_ZONE: Europe/Prague
- WEBLATE_ENABLE_HTTPS¶
Faz com que o Weblate presuma que é operado por trás de um proxy HTTPS reverso, faz com que o Weblate use HTTPS em e-mail e ligações de API ou defina sinalizadores seguros em cookies.
Dica
Por favor, consulte a documentação de
ENABLE_HTTPS
para possíveis advertências.Nota
Isso não faz com que o contentor Weblate aceite conexões HTTPS, precisa configurar isso também, consulte Contentor Docker com suporte a HTTPS para exemplos.
Exemplo:
environment: WEBLATE_ENABLE_HTTPS: 1
- WEBLATE_INTERLEDGER_PAYMENT_POINTERS¶
Added in version 4.12.1.
Permite que o Weblate defina o campo meta[nome=monetização] no cabeçalho do documento. Se vários forem especificados, escolhe um aleatoriamente.
Veja também
- WEBLATE_IP_PROXY_HEADER¶
Permite que o Weblate obtenha o endereço IP de qualquer cabeçalho HTTP fornecido. Use isso ao usar um proxy reverso na frente do contentor Weblate.
Ativa
IP_BEHIND_REVERSE_PROXY
e defineIP_PROXY_HEADER
.Nota
O formato deve estar de acordo com as expectativas do Django. O Django transforma nomes de cabeçalho HTTP brutos da seguinte forma:
converte todos os caracteres em maiúsculas
substitui todos os hifenes por sublinhados
prefixa o prefixo
HTTP_
Portanto,
X-Forwarded-For
seria mapeado paraHTTP_X_FORWARDED_FOR
.Exemplo:
environment: WEBLATE_IP_PROXY_HEADER: HTTP_X_FORWARDED_FOR
- WEBLATE_IP_PROXY_OFFSET¶
Added in version 5.0.1.
Configura
IP_PROXY_OFFSET
.
- WEBLATE_USE_X_FORWARDED_PORT¶
Added in version 5.0.1.
Um booleano que especifica se deve ser usado o cabeçalho X-Forwarded-Port em vez da variável SERVER_PORT META. Isto só deve ser ativado se um proxy que define este cabeçalho estiver em uso.
Veja também
Nota
Esta é uma configuração Booleana (use
"true"
ou"false"
).
- WEBLATE_SECURE_PROXY_SSL_HEADER¶
Uma tupla que representa uma combinação de cabeçalho/valor HTTP que significa que uma solicitação é segura. Isso é necessário quando o Weblate está a ser executado por trás de um proxy reverso a fazer a terminação SSL que não passa cabeçalhos HTTPS padrão.
Exemplo:
environment: WEBLATE_SECURE_PROXY_SSL_HEADER: HTTP_X_FORWARDED_PROTO,https
Veja também
- WEBLATE_REQUIRE_LOGIN¶
Ativa
REQUIRE_LOGIN
para impor autenticação em todo o Weblate.Exemplo:
environment: WEBLATE_REQUIRE_LOGIN: 1
- WEBLATE_LOGIN_REQUIRED_URLS_EXCEPTIONS¶
- WEBLATE_ADD_LOGIN_REQUIRED_URLS_EXCEPTIONS¶
- WEBLATE_REMOVE_LOGIN_REQUIRED_URLS_EXCEPTIONS¶
Adiciona exceções de URL para autenticação necessária para toda a instalação do Weblate a usar
LOGIN_REQUIRED_URLS_EXCEPTIONS
.Pode substituir configurações inteiras ou modificar o valor padrão a usar as variáveis
ADD
eREMOVE
.Para impor a autenticação para o formulário de contato, faça:
environment: WEBLATE_REMOVE_LOGIN_REQUIRED_URLS_EXCEPTIONS: /contact/$
- WEBLATE_GOOGLE_ANALYTICS_ID¶
Configura o ID para o Google Analytics a alterar
GOOGLE_ANALYTICS_ID
.
- WEBLATE_DEFAULT_PULL_MESSAGE¶
Configura o título e a mensagem padrão para pull requests via API alterando
DEFAULT_PULL_MESSAGE
Veja também
- WEBLATE_SIMPLIFY_LANGUAGES¶
Configura a política de simplificação de idioma, veja
SIMPLIFY_LANGUAGES
.
- WEBLATE_DEFAULT_ACCESS_CONTROL¶
Configura o padrão Controlo de acesso para novos projetos, veja
DEFAULT_ACCESS_CONTROL
.
- WEBLATE_DEFAULT_RESTRICTED_COMPONENT¶
Configura o valor padrão para Acesso restrito para novos componentes, veja
DEFAULT_RESTRICTED_COMPONENT
.
- WEBLATE_DEFAULT_TRANSLATION_PROPAGATION¶
Configura o valor padrão para Permitir propagação da tradução para novos componentes, veja
DEFAULT_TRANSLATION_PROPAGATION
.
- WEBLATE_DEFAULT_COMMITER_EMAIL¶
Configura
DEFAULT_COMMITER_EMAIL
.
- WEBLATE_DEFAULT_COMMITER_NAME¶
Configura
DEFAULT_COMMITER_NAME
.
- WEBLATE_DEFAULT_SHARED_TM¶
Configura
DEFAULT_SHARED_TM
.
- WEBLATE_AKISMET_API_KEY¶
Configura a chave API do Akismet, veja
AKISMET_API_KEY
.
- WEBLATE_GPG_IDENTITY¶
Configura a assinatura GPG de commits, veja
WEBLATE_GPG_IDENTITY
.Veja também
- WEBLATE_URL_PREFIX¶
Configura o prefixo da URL onde o Weblate está a ser executado, veja
URL_PREFIX
.
- WEBLATE_SILENCED_SYSTEM_CHECKS¶
Configura verificações que não deseja que sejam mostradas, veja
django: SILENCED_SYSTEM_CHECKS
.
- WEBLATE_CSP_SCRIPT_SRC¶
- WEBLATE_CSP_IMG_SRC¶
- WEBLATE_CSP_CONNECT_SRC¶
- WEBLATE_CSP_STYLE_SRC¶
- WEBLATE_CSP_FONT_SRC¶
- WEBLATE_CSP_FORM_SRC¶
Permite personalizar o cabeçalho HTTP
Content-Security-Policy
.
- WEBLATE_LICENSE_FILTER¶
Configura
LICENSE_FILTER
.
- WEBLATE_LICENSE_REQUIRED¶
Configura
LICENSE_REQUIRED
- WEBLATE_WEBSITE_REQUIRED¶
Configura
WEBSITE_REQUIRED
- WEBLATE_HIDE_VERSION¶
Configura
HIDE_VERSION
.
- WEBLATE_BASIC_LANGUAGES¶
Configura
BASIC_LANGUAGES
.
- WEBLATE_DEFAULT_AUTO_WATCH¶
Configura
DEFAULT_AUTO_WATCH
.
- WEBLATE_RATELIMIT_ATTEMPTS¶
- WEBLATE_RATELIMIT_LOCKOUT¶
- WEBLATE_RATELIMIT_WINDOW¶
Added in version 4.6.
Configura o limitador de taxa.
Dica
Pode definir a configuração para qualquer escopo do limitador de taxa. Para fazer isso, adicione o prefixo
WEBLATE_
a qualquer uma das configurações descritas em Limitação de taxa.Veja também
Limitação de taxa,
RATELIMIT_ATTEMPTS
,RATELIMIT_WINDOW
,RATELIMIT_LOCKOUT
- WEBLATE_API_RATELIMIT_ANON¶
- WEBLATE_API_RATELIMIT_USER¶
Added in version 4.11.
Configura a limitação de taxa da API. O padrão é
100/day
para utilizadores anônimos e5000/hour
para utilizadores autenticados.Veja também
- WEBLATE_ENABLE_HOOKS¶
Added in version 4.13.
Configura
ENABLE_HOOKS
.
- WEBLATE_ENABLE_AVATARS¶
Added in version 4.6.1.
Configura
ENABLE_AVATARS
.
- WEBLATE_AVATAR_URL_PREFIX¶
Added in version 4.15.
Configura
AVATAR_URL_PREFIX
.
- WEBLATE_LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH¶
Added in version 4.9.
Configura
LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH
.
- WEBLATE_SSH_EXTRA_ARGS¶
Added in version 4.9.
Configura
SSH_EXTRA_ARGS
.
- WEBLATE_BORG_EXTRA_ARGS¶
Added in version 4.9.
Configura
BORG_EXTRA_ARGS
como uma lista de argumentos separados por vírgula.Exemplo:
environment: WEBLATE_BORG_EXTRA_ARGS: --exclude,vcs/
- WEBLATE_ENABLE_SHARING¶
Added in version 4.14.1.
Configura
ENABLE_SHARING
.
- WEBLATE_SUPPORT_STATUS_CHECK¶
Added in version 5.5.
Configura
SUPPORT_STATUS_CHECK
.
- WEBLATE_EXTRA_HTML_HEAD¶
Added in version 4.15.
Configura
EXTRA_HTML_HEAD
.
- WEBLATE_PRIVATE_COMMIT_EMAIL_TEMPLATE¶
Added in version 4.15.
Configura
PRIVATE_COMMIT_EMAIL_TEMPLATE
.
- WEBLATE_PRIVATE_COMMIT_EMAIL_OPT_IN¶
Added in version 4.15.
Configura
PRIVATE_COMMIT_EMAIL_OPT_IN
.
- WEBLATE_UNUSED_ALERT_DAYS¶
Added in version 4.17.
Configura
UNUSED_ALERT_DAYS
.
- WEBLATE_CORS_ALLOWED_ORIGINS¶
Added in version 4.16.
Permitir solicitações CORS para API de determinadas origens.
Exemplo:
environment: WEBLATE_CORS_ALLOWED_ORIGINS: https://example.com,https://weblate.org
- WEBLATE_CORS_ALLOW_ALL_ORIGINS¶
Added in version 5.6.1: Permite solicitações CORS para API de todas as origens.
- CLIENT_MAX_BODY_SIZE¶
Added in version 4.16.3.
Configura o tamanho máximo do corpo aceito pelo servidor da Web embutido.
environment: CLIENT_MAX_BODY_SIZE: 200m
Dica
Esta variável não tem intencionalmente o prefixo
WEBLATE_
, pois é partilhada com um contentor de terceiros usado no Certificados SSL automáticos a usar Let’s Encrypt.
Credenciais de sites de hospedagem de código¶
In the Docker container, the code hosting credentials can be configured either in separate variables or using a Python dictionary to set them at once. The following examples are for Pull requests do GitHub, but applies to all Integração de controlo de versões with appropriately changed variable names.
Um exemplo de configuração para o GitHub pode parecer-se com:
WEBLATE_GITHUB_USERNAME=api-user
WEBLATE_GITHUB_TOKEN=api-token
WEBLATE_GITHUB_HOST=api.github.com
Será usado como:
GITHUB_CREDENTIALS = {
"api.github.com": {
"username": "api-user",
"token": "api-token",
}
}
Alternativamente, o dicionário Python pode ser fornecido como uma cadeia:
WEBLATE_GITHUB_CREDENTIALS='{ "api.github.com": { "username": "api-user", "token": "api-token", } }'
Ou o caminho para um ficheiro que contém o dicionário Python:
echo '{ "api.github.com": { "username": "api-user", "token": "api-token", } }' > /path/to/github-credentials
WEBLATE_GITHUB_CREDENTIALS_FILE='/path/to/github-credentials'
- WEBLATE_GITHUB_USERNAME¶
- WEBLATE_GITHUB_TOKEN¶
- WEBLATE_GITHUB_HOST¶
- WEBLATE_GITHUB_CREDENTIALS¶
Configura Pull requests do GitHub alterando
GITHUB_CREDENTIALS
.
- WEBLATE_GITLAB_USERNAME¶
- WEBLATE_GITLAB_TOKEN¶
- WEBLATE_GITLAB_HOST¶
- WEBLATE_GITLAB_CREDENTIALS¶
Configura Merge requests do GitLab alterando
GITLAB_CREDENTIALS
.
- WEBLATE_GITEA_USERNAME¶
- WEBLATE_GITEA_TOKEN¶
- WEBLATE_GITEA_HOST¶
- WEBLATE_GITEA_CREDENTIALS¶
Configura Pull requests do Gitea alterando
GITEA_CREDENTIALS
.
- WEBLATE_PAGURE_USERNAME¶
- WEBLATE_PAGURE_TOKEN¶
- WEBLATE_PAGURE_HOST¶
- WEBLATE_PAGURE_CREDENTIALS¶
Configura o Merge requests do Pagure alterando
PAGURE_CREDENTIALS
.
- WEBLATE_BITBUCKETSERVER_USERNAME¶
- WEBLATE_BITBUCKETSERVER_TOKEN¶
- WEBLATE_BITBUCKETSERVER_HOST¶
- WEBLATE_BITBUCKETSERVER_CREDENTIALS¶
Configura Bitbucket Server pull requests alterando
BITBUCKETSERVER_CREDENTIALS
.
- WEBLATE_BITBUCKETCLOUD_USERNAME¶
- WEBLATE_BITBUCKETCLOUD_WORKSPACE¶
- WEBLATE_BITBUCKETCLOUD_TOKEN¶
- WEBLATE_BITBUCKETCLOUD_HOST¶
- WEBLATE_BITBUCKETCLOUD_CREDENTIALS¶
Configures Bitbucket Cloud pull requests by changing
BITBUCKETCLOUD_CREDENTIALS
.
- WEBLATE_AZURE_DEVOPS_USERNAME¶
- WEBLATE_AZURE_DEVOPS_ORGANIZATION¶
- WEBLATE_AZURE_DEVOPS_TOKEN¶
- WEBLATE_AZURE_DEVOPS_HOST¶
- WEBLATE_AZURE_DEVOPS_CREDENTIALS¶
Configura o Azure DevOps pull requests alterando
AZURE_DEVOPS_CREDENTIALS
.
Configurações de sugestões automáticas¶
Alterado na versão 4.13: Serviços de sugestões automáticas agora são configurados na interface de utilizador, consulte Sugestões automáticas.
As variáveis de ambiente atuais são importadas durante a migração ao Weblate 4.13, mas alterá-las não surtirá nenhum efeito.
Configurações de autenticação¶
LDAP¶
- WEBLATE_AUTH_LDAP_SERVER_URI¶
- WEBLATE_AUTH_LDAP_USER_DN_TEMPLATE¶
- WEBLATE_AUTH_LDAP_USER_ATTR_MAP¶
- WEBLATE_AUTH_LDAP_BIND_DN¶
- WEBLATE_AUTH_LDAP_BIND_PASSWORD¶
- WEBLATE_AUTH_LDAP_CONNECTION_OPTION_REFERRALS¶
- WEBLATE_AUTH_LDAP_USER_SEARCH¶
- WEBLATE_AUTH_LDAP_USER_SEARCH_FILTER¶
- WEBLATE_AUTH_LDAP_USER_SEARCH_UNION¶
- WEBLATE_AUTH_LDAP_USER_SEARCH_UNION_DELIMITER¶
Configuração de autenticação LDAP.
Exemplo para vinculação direta:
environment: WEBLATE_AUTH_LDAP_SERVER_URI: ldap://ldap.example.org WEBLATE_AUTH_LDAP_USER_DN_TEMPLATE: uid=%(user)s,ou=People,dc=example,dc=net # map weblate 'full_name' to ldap 'name' and weblate 'email' attribute to 'mail' ldap attribute. # another example that can be used with OpenLDAP: 'full_name:cn,email:mail' WEBLATE_AUTH_LDAP_USER_ATTR_MAP: full_name:name,email:mail
Exemplo para pesquisa e vinculação:
environment: WEBLATE_AUTH_LDAP_SERVER_URI: ldap://ldap.example.org WEBLATE_AUTH_LDAP_BIND_DN: CN=ldap,CN=Users,DC=example,DC=com WEBLATE_AUTH_LDAP_BIND_PASSWORD: password WEBLATE_AUTH_LDAP_USER_ATTR_MAP: full_name:name,email:mail WEBLATE_AUTH_LDAP_USER_SEARCH: CN=Users,DC=example,DC=com
Exemplo para vinculação e pesquisa de união:
environment: WEBLATE_AUTH_LDAP_SERVER_URI: ldap://ldap.example.org WEBLATE_AUTH_LDAP_BIND_DN: CN=ldap,CN=Users,DC=example,DC=com WEBLATE_AUTH_LDAP_BIND_PASSWORD: password WEBLATE_AUTH_LDAP_USER_ATTR_MAP: full_name:name,email:mail WEBLATE_AUTH_LDAP_USER_SEARCH_UNION: ou=users,dc=example,dc=com|ou=otherusers,dc=example,dc=com
Exemplo com pesquisar e vincular ao Active Directory:
environment: WEBLATE_AUTH_LDAP_BIND_DN: CN=ldap,CN=Users,DC=example,DC=com WEBLATE_AUTH_LDAP_BIND_PASSWORD: password WEBLATE_AUTH_LDAP_SERVER_URI: ldap://ldap.example.org WEBLATE_AUTH_LDAP_CONNECTION_OPTION_REFERRALS: 0 WEBLATE_AUTH_LDAP_USER_ATTR_MAP: full_name:name,email:mail WEBLATE_AUTH_LDAP_USER_SEARCH: CN=Users,DC=example,DC=com WEBLATE_AUTH_LDAP_USER_SEARCH_FILTER: (sAMAccountName=%(user)s)
Veja também
GitHub¶
- WEBLATE_SOCIAL_AUTH_GITHUB_KEY¶
- WEBLATE_SOCIAL_AUTH_GITHUB_SECRET¶
- WEBLATE_SOCIAL_AUTH_GITHUB_ORG_KEY¶
- WEBLATE_SOCIAL_AUTH_GITHUB_ORG_SECRET¶
- WEBLATE_SOCIAL_AUTH_GITHUB_ORG_NAME¶
- WEBLATE_SOCIAL_AUTH_GITHUB_TEAM_KEY¶
- WEBLATE_SOCIAL_AUTH_GITHUB_TEAM_SECRET¶
- WEBLATE_SOCIAL_AUTH_GITHUB_TEAM_ID¶
Ativa Autenticação por GitHub.
GitHub Enterprise Edition¶
- WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_KEY¶
- WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_SECRET¶
- WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_URL¶
- WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_API_URL¶
- WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_SCOPE¶
Ativa Autenticação por GitHub EE.
Bitbucket¶
- WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_KEY¶
- WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_SECRET¶
- WEBLATE_SOCIAL_AUTH_BITBUCKET_KEY¶
- WEBLATE_SOCIAL_AUTH_BITBUCKET_SECRET¶
Ativa Autenticação por Bitbucket.
Facebook¶
- WEBLATE_SOCIAL_AUTH_FACEBOOK_KEY¶
- WEBLATE_SOCIAL_AUTH_FACEBOOK_SECRET¶
Ativa OAuth 2 do Facebook.
Google¶
- WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_KEY¶
- WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_SECRET¶
- WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_WHITELISTED_DOMAINS¶
- WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_WHITELISTED_EMAILS¶
Ativa Google OAuth 2.
GitLab¶
- WEBLATE_SOCIAL_AUTH_GITLAB_KEY¶
- WEBLATE_SOCIAL_AUTH_GITLAB_SECRET¶
- WEBLATE_SOCIAL_AUTH_GITLAB_API_URL¶
Ativa OAuth 2 do GitLab.
Gitea¶
- WEBLATE_SOCIAL_AUTH_GITEA_API_URL¶
- WEBLATE_SOCIAL_AUTH_GITEA_KEY¶
- WEBLATE_SOCIAL_AUTH_GITEA_SECRET¶
Ativa autenticação por Gitea.
Active Directory do Azure¶
- WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_KEY¶
- WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_SECRET¶
Ativa autenticação por Active Directory do Azure, veja Active Directory do Microsoft Azure.
Active Directory do Azure com suporte a Tenant¶
- WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_KEY¶
- WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_SECRET¶
- WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_TENANT_ID¶
Ativa autenticação por Active Directory do Azure com suporte a Tenant, veja Active Directory do Microsoft Azure.
Keycloak¶
- WEBLATE_SOCIAL_AUTH_KEYCLOAK_KEY¶
- WEBLATE_SOCIAL_AUTH_KEYCLOAK_SECRET¶
- WEBLATE_SOCIAL_AUTH_KEYCLOAK_PUBLIC_KEY¶
- WEBLATE_SOCIAL_AUTH_KEYCLOAK_ALGORITHM¶
- WEBLATE_SOCIAL_AUTH_KEYCLOAK_AUTHORIZATION_URL¶
- WEBLATE_SOCIAL_AUTH_KEYCLOAK_ACCESS_TOKEN_URL¶
- WEBLATE_SOCIAL_AUTH_KEYCLOAK_TITLE¶
- WEBLATE_SOCIAL_AUTH_KEYCLOAK_IMAGE¶
Ativa autenticação com Keycloak, veja a documentação.
Fornecedores Linux¶
Pode ativar a autenticação a usar serviços de autenticação de fornecedores Linux, a definir as seguintes variáveis para qualquer valor.
- WEBLATE_SOCIAL_AUTH_FEDORA¶
- WEBLATE_SOCIAL_AUTH_OPENSUSE¶
- WEBLATE_SOCIAL_AUTH_OPENINFRA¶
- WEBLATE_SOCIAL_AUTH_UBUNTU¶
Slack¶
- WEBLATE_SOCIAL_AUTH_SLACK_KEY¶
OpenID Connect¶
Added in version 4.13-1.
- WEBLATE_SOCIAL_AUTH_OIDC_OIDC_ENDPOINT¶
- WEBLATE_SOCIAL_AUTH_OIDC_KEY¶
- WEBLATE_SOCIAL_AUTH_OIDC_SECRET¶
- WEBLATE_SOCIAL_AUTH_OIDC_USERNAME_KEY¶
Configura a integração genérica do OpenID Connect.
Veja também
SAML¶
Chaves SAML autoassinadas são geradas automaticamente na primeira inicialização do contentor. Caso queira usar chaves próprias, ponha o certificado e a chave privada em /app/data/ssl/saml.crt
e /app/data/ssl/saml.key
.
- WEBLATE_SAML_IDP_ENTITY_ID¶
- WEBLATE_SAML_IDP_URL¶
- WEBLATE_SAML_IDP_X509CERT¶
- WEBLATE_SAML_IDP_IMAGE¶
- WEBLATE_SAML_IDP_TITLE¶
Configurações do provedor de identidade SAML, consulte Autenticação por SAML.
- WEBLATE_SAML_ID_ATTR_NAME¶
- WEBLATE_SAML_ID_ATTR_USERNAME¶
- WEBLATE_SAML_ID_ATTR_EMAIL¶
- WEBLATE_SAML_ID_ATTR_USER_PERMANENT_ID¶
Added in version 4.18.
Mapeamento de atributos SAML.
Outras configurações de autenticação¶
- WEBLATE_NO_EMAIL_AUTH¶
Desativa autenticação por e-mail quando definido com algum valor. Veja Desativar autenticação por palavra-passe.
- WEBLATE_MIN_PASSWORD_SCORE¶
Pontuação mínima da palavra-passe conforme avaliada pelo estimador de força de palavra-passe zxcvbn <https://github.com/dropbox/zxcvbn>. O padrão é 3, defina como 0 para desativar a verificação de força.
Configuração de banco de dados PostgreSQL¶
O banco de dados é criado por docker-compose.yml
, então essas configurações afetam os contentores Weblate e PostgreSQL.
Veja também
- POSTGRES_PASSWORD¶
Palavra-passe do PostgreSQL.
Veja também
- POSTGRES_USER¶
Nome de utilizador do PostgreSQL.
- POSTGRES_DB¶
Nome do banco de dados PostgreSQL.
- POSTGRES_HOST¶
Nome de host ou endereço IP do servidor PostgreSQL. O padrão é
database
.
- POSTGRES_PORT¶
Porta do servidor PostgreSQL. O padrão é nenhum (usa o valor padrão).
- POSTGRES_SSL_MODE¶
Configura como o PostgreSQL lida com SSL em conexão com o servidor, para as opções possíveis, consulte SSL Mode Descriptions
- POSTGRES_ALTER_ROLE¶
Configures name of the PostgreSQL role to alter during the database migration, see Configurar Weblate para usar PostgreSQL.
Defaults to
POSTGRES_USER
.
- POSTGRES_CONN_MAX_AGE¶
Added in version 4.8.1.
O tempo de vida de uma conexão de banco de dados, como um número inteiro de segundos. Use 0 para fechar as conexões do banco de dados no final de cada requisição.
Alterado na versão 5.1: O comportamento padrão é ter conexões de banco de dados persistentes ilimitadas.
Ativar a persistência da conexão normalmente causará uma conexão mais aberta com o banco de dados. Por favor, ajuste a sua configuração do banco de dados antes de ativar.
Exemplo de configuração:
environment: POSTGRES_CONN_MAX_AGE: 3600
Veja também
- POSTGRES_DISABLE_SERVER_SIDE_CURSORS¶
Added in version 4.9.1.
Desativa os cursores do lado do servidor no banco de dados. Isso é necessário em algumas configurações do pgbouncer.
Exemplo de configuração:
environment: POSTGRES_DISABLE_SERVER_SIDE_CURSORS: 1
- WEBLATE_DATABASES¶
Added in version 5.1.
Defina como false para desativar a configuração baseada no ambiente da conexão com o banco de dados. Use Substituindo as configurações do volume de dados para configurar manualmente a conexão com o banco de dados.
Servidor MySQL ou MariaDB¶
O MySQL e o MariaDB não podem ser configurados por meio de variáveis de ambiente. Consulte MySQL e MariaDB para obter informações sobre como usá-las com o Weblate. Use WEBLATE_DATABASES
para configurar a conexão do banco de dados manualmente.
Configurações de backup de base de dados¶
Veja também
- WEBLATE_DATABASE_BACKUP¶
Configura o despejo diário do banco de dados a usar
DATABASE_BACKUP
. O padrão éplain
.
Configuração do servidor de cache¶
O uso do Redis é altamente recomendado pelo Weblate e deve fornecer uma instância do Redis ao executar o Weblate no Docker.
Veja também
- REDIS_HOST¶
O nome de host ou endereço IP do servidor Redis. O padrão é
cache
.
- REDIS_PORT¶
A porta do servidor Redis. O padrão é
6379
.
- REDIS_DB¶
O número do banco de dados Redis, o padrão é
1
.
- REDIS_PASSWORD¶
A palavra-passe do servidor Redis, não usada por padrão.
Veja também
- REDIS_TLS¶
Ativa o uso de SSL para conexão Redis.
- REDIS_VERIFY_SSL¶
Pode ser usado para desativar a verificação de certificado SSL para conexão Redis.
Configuração do servidor de e-mail¶
Para fazer com que o e-mail de saída funcione, precisa fornecer um servidor de e-mail.
Exemplo de configuração TLS:
environment:
WEBLATE_EMAIL_HOST: smtp.example.com
WEBLATE_EMAIL_HOST_USER: user
WEBLATE_EMAIL_HOST_PASSWORD: pass
Exemplo de configuração SSL:
environment:
WEBLATE_EMAIL_HOST: smtp.example.com
WEBLATE_EMAIL_PORT: 465
WEBLATE_EMAIL_HOST_USER: user
WEBLATE_EMAIL_HOST_PASSWORD: pass
WEBLATE_EMAIL_USE_TLS: 0
WEBLATE_EMAIL_USE_SSL: 1
Veja também
- WEBLATE_EMAIL_HOST¶
Nome de host ou endereço IP do servidor de correio.
Veja também
WEBLATE_EMAIL_PORT
,WEBLATE_EMAIL_USE_SSL
,WEBLATE_EMAIL_USE_TLS
,EMAIL_HOST
- WEBLATE_EMAIL_PORT¶
Porta do servidor de correio, o padrão é 25.
Veja também
- WEBLATE_EMAIL_HOST_USER¶
Utilizador da autenticação por e-mail.
Veja também
- WEBLATE_EMAIL_HOST_PASSWORD¶
Palavra-passe da autenticação por e-mail.
Veja também
- WEBLATE_EMAIL_USE_SSL¶
Se deve usar uma conexão TLS (segura) implícita ao falar com o servidor SMTP. Na maioria das documentações de e-mail, esse tipo de conexão TLS é conhecido como SSL. Geralmente é usado na porta 465. Se estiver a ter problemas, consulte a configuração TLS explícita
WEBLATE_EMAIL_USE_TLS
.Alterado na versão 4.11: O suporte a SSL/TLS é ativado automaticamente com base em
WEBLATE_EMAIL_PORT
.Veja também
- WEBLATE_EMAIL_USE_TLS¶
Se deve usar uma conexão TLS (segura) ao falar com o servidor SMTP. Isso é usado para conexões TLS explícitas, geralmente na porta 587 ou 25. Se estiver a ter conexões travadas, consulte a configuração TLS implícita
WEBLATE_EMAIL_USE_SSL
.Alterado na versão 4.11: O suporte a SSL/TLS é ativado automaticamente com base em
WEBLATE_EMAIL_PORT
.Veja também
- WEBLATE_EMAIL_BACKEND¶
Configura o back-end do Django para usar no envio de e-mails.
Veja também
- WEBLATE_AUTO_UPDATE¶
Configura se e como o Weblate deve atualizar os repositórios.
Veja também
Nota
Esta é uma configuração booleana (use
"true"
ou"false"
).
Integração do site¶
- WEBLATE_GET_HELP_URL¶
Configura
GET_HELP_URL
.
- WEBLATE_STATUS_URL¶
Configura
STATUS_URL
.
- WEBLATE_PRIVACY_URL¶
Configura
PRIVACY_URL
.
A coletar relatórios de erros e monitoramento do desempenho¶
É recomendado coletar erros da instalação sistematicamente, veja A coletar relatórios de erros e monitoramento do desempenho.
Para ativar o suporte para Rollbar, defina o seguinte:
- ROLLBAR_KEY¶
O seu token de acesso ao servidor de postagem Rollbar.
- ROLLBAR_ENVIRONMENT¶
O seu ambiente Rollbar, o padrão é
production
.
Para ativar o suporte para Sentry, defina o seguinte:
- SENTRY_DSN¶
O seu Sentry DSN, consulte
SENTRY_DSN
.
- SENTRY_ENVIRONMENT¶
O seu Ambiente de Sentry (opcional), padrão para
WEBLATE_SITE_DOMAIN
.
- SENTRY_TRACES_SAMPLE_RATE¶
Configura
SENTRY_TRACES_SAMPLE_RATE
.Exemplo:
environment: SENTRY_TRACES_SAMPLE_RATE: 0.5
- SENTRY_PROFILES_SAMPLE_RATE¶
Configura
SENTRY_PROFILES_SAMPLE_RATE
.Exemplo:
environment: SENTRY_PROFILES_SAMPLE_RATE: 0.5
- SENTRY_SEND_PII¶
Configura
SENTRY_SEND_PII
.
CDN de localização¶
- WEBLATE_LOCALIZE_CDN_URL¶
- WEBLATE_LOCALIZE_CDN_PATH¶
Added in version 4.2.1.
Configuração para CDN de localização JavaScript.
O
WEBLATE_LOCALIZE_CDN_PATH
é o caminho dentro do contentor. Ele deve ser armazenado no volume persistente e não no armazenamento temporário.Uma das possibilidades é armazenar isso dentro do diretório de dados do Weblate:
environment: WEBLATE_LOCALIZE_CDN_URL: https://cdn.example.com/ WEBLATE_LOCALIZE_CDN_PATH: /app/data/l10n-cdn
Nota
É responsável por configurar o serviço dos ficheiros gerados pelo Weblate, ele só armazena os ficheiros no local configurado.
Alterar apps, verificações, extensões, tradução automática, ou correções automáticas ativados¶
A configuração embutida de verificações, extensões ou correções automática ativados pode ser ajustada pelas seguintes variáveis:
- WEBLATE_ADD_APPS¶
- WEBLATE_REMOVE_APPS¶
- WEBLATE_ADD_CHECK¶
- WEBLATE_REMOVE_CHECK¶
- WEBLATE_ADD_AUTOFIX¶
- WEBLATE_REMOVE_AUTOFIX¶
- WEBLATE_ADD_ADDONS¶
- WEBLATE_REMOVE_ADDONS¶
- WEBLATE_ADD_MACHINERY¶
Added in version 5.6.1.
- WEBLATE_REMOVE_MACHINERY¶
Added in version 5.6.1.
Exemplo:
environment:
WEBLATE_REMOVE_AUTOFIX: weblate.trans.autofixes.whitespace.SameBookendingWhitespace
WEBLATE_ADD_ADDONS: customize.addons.MyAddon,customize.addons.OtherAddon
Veja também
CHECK_LIST
, AUTOFIX_LIST
, WEBLATE_ADDONS
, INSTALLED_APPS
, WEBLATE_MACHINERY
Configurações do contentor¶
- WEBLATE_WORKERS¶
Added in version 4.6.1.
Quantidade base de processos de trabalho em execução no contentor. Quando não definido, é determinado automaticamente na inicialização do contentor com base na quantidade de núcleos de CPU disponíveis.
É usado para determinar
CELERY_MAIN_OPTIONS
,CELERY_NOTIFY_OPTIONS
,CELERY_MEMORY_OPTIONS
,CELERY_TRANSLATE_OPTIONS
,CELERY_BACKUP_OPTIONS
,CELERY_BEAT_OPTIONS
eWEB_WORKERS
. Pode usar essas configurações para fazer o ajuste fino.
- CELERY_MAIN_OPTIONS¶
- CELERY_NOTIFY_OPTIONS¶
- CELERY_MEMORY_OPTIONS¶
- CELERY_TRANSLATE_OPTIONS¶
- CELERY_BACKUP_OPTIONS¶
- CELERY_BEAT_OPTIONS¶
Essas variáveis permitem que ajuste as opções do worker do Celery. Pode ser útil ajustar a simultaneidade (
--concurrency 16
) ou usar diferentes implementações de pool (--pool=gevent
).Por padrão, a quantidade de workers simultâneos é baseado em
WEBLATE_WORKERS
.Exemplo:
environment: CELERY_MAIN_OPTIONS: --concurrency 16
- CELERY_SINGLE_PROCESS¶
Added in version 5.7.1: Esta variável pode ser definida como
1
para executar apenas um processo celery. Isto reduz o uso de memória, mas pode afetar o desempenho do Weblate.environment: CELERY_SINGLE_PROCESS: 1
Veja também
- WEB_WORKERS¶
Configura quantos workers uWSGI devem ser executados.
O padrão é
WEBLATE_WORKERS
.Exemplo:
environment: WEB_WORKERS: 32
- WEBLATE_SERVICE¶
Define quais serviços devem ser executados dentro do contentor. Use isto para Dimensionando horizontalmente.
Os seguintes serviços são definidos:
celery-beat
Agendador de tarefas do Celery, apenas uma instância deve estar em execução. Este contentor também é responsável pelas migrações da estrutura do banco de dados e deve ser iniciado antes dos demais.
celery-backup
Worker do Celery para backups, apenas uma instância deve estar em execução.
celery-celery
Worker genérico do Celery.
celery-memory
Worker do Celery para memória de tradução.
celery-notify
Worker do Celery para notificações.
celery-translate
Worker do Celery para tradução automática.
web
Servidor web.
Volumes de contentor Docker¶
Há dois volumes (dados
e cache
) exportados pelo contentor Weblate. Os outros contentores de serviço (PostgreSQL ou Redis) também têm os seus volumes de dados, mas eles não são cobertos por este documento.
O volume dados
é montado como /app/data`
e é utilizado para armazenar dados persistentes do Weblate, como repositórios clonados ou para personalizar a instalação do Weblate.
O posicionamento do volume do Docker no sistema host depende da configuração do Docker, mas geralmente ele é armazenado em /var/lib/docker/volumes/weblate-docker_weblate-data/_data/
(o caminho consiste no nome do diretório docker-compose, do contentor e dos nomes dos volumes).
O volume do cache
é montado como /app/cache
e é usado para armazenar ficheiros estáticos e CACHE_DIR
. O seu conteúdo é recriado na inicialização do contentor e o volume pode ser montado usando um sistema de ficheiros efêmero, como o tmpfs.
Ao criar os volumes manualmente, os diretórios devem pertencer ao UID 1000, pois é o utilizador usado dentro do contentor.
Veja também
Sistema de ficheiros raiz somente leitura¶
Added in version 4.18.
Ao executar o contentor com um sistema de ficheiros raiz somente leitura, são necessários dois volumes tmpfs adicionais - /tmp
e /run
.
Configuração além das variáveis de ambiente¶
As variáveis de ambiente do Docker destinam-se a expor a maioria das definições de configuração de relevância para as instalações do Weblate.
Se encontrar uma configuração que não está exposta como uma variável de ambiente e acredita que deveria estar, sinta-se à vontade para pedir que ela seja exposta numa versão futura do Weblate.
Se precisar modificar uma configuração que não está exposta como uma variável de ambiente do Docker, ainda poderá fazê-lo a partir do volume de dados ou estendendo a imagem do Docker.
Veja também
Substituindo as configurações do volume de dados¶
Pode criar um ficheiro em /app/data/settings-override.py
ou seja, na raiz do volume de dados, para estender ou substituir as configurações definidas por meio de variáveis de ambiente .
Substituindo as configurações estendendo a imagem do Docker¶
Para substituir as configurações no nível da imagem do Docker em vez do volume de dados:
Adicione um módulo ao seu pacote que importe todas as configurações de
weblate.settings_docker
.Por exemplo, dentro da estrutura de pacote de exemplo definida em Criar um módulo Python, pode criar um ficheiro em
weblate_customization/weblate_customization/settings.py
com o seguinte código inicial:from weblate.settings_docker import *
Crie um
Dockerfile
personalizado que herde da imagem oficial do Weblate Docker e, em seguida, instale o seu pacote e aponte a variável de ambienteDJANGO_SETTINGS_MODULE
para o seu módulo de configurações:FROM weblate/weblate USER root COPY weblate_customization /usr/src/weblate_customization RUN /app/venv/bin/uv pip install --no-cache-dir /usr/src/weblate_customization ENV DJANGO_SETTINGS_MODULE=weblate_customization.settings USER 1000
Em vez de usar a imagem Docker oficial do Weblate, construa uma imagem personalizada a partir deste ficheiro
Dockerfile
.Não existe
nenhuma maneira limpa <https://github.com/docker/compose/issues/7231>`__ de fazer isso com ``docker-compose.override.yml
. Poderia adicionarbuild: .
ao nóweblate
nesse ficheiro, mas a sua imagem personalizada será marcada comoweblate/weblate
no seu sistema, o que pode ser problemático.Então, ao invés de usar o
docker-compose.yml
direto do repositório oficial, não modificado e estendê-lo através dodocker-compose .override.yml
, pode fazer uma cópia do ficheirodocker-compose.yml
oficial e editar a sua cópia para substituirimage: weblate/weblate
porbuild: .
.Consulte a Referência de compilação do ficheiro Compose para obter detalhes sobre como criar imagens a partir da fonte ao usar
docker-compose
.Estenda o seu módulo de configurações personalizadas para definir ou redefinir as configurações.
Pode definir as configurações antes ou depois da instrução de importação acima para determinar quais configurações têm precedência. As configurações definidas antes da instrução de importação podem ser substituídas por variáveis de ambiente e substituições de configuração definidas no volume de dados. A configuração definida após a instrução de importação não pode ser substituída.
Também pode ir mais longe. Por exemplo, pode reproduzir algumas das coisas que
weblate.docker_settings
faz, como expor configurações como variáveis de ambiente ou permitir a substituição de configurações de ficheiros Python no volume de dados.
Substituindo o logotipo e outros ficheiros estáticos¶
Os ficheiros estáticos que vêm com Weblate podem ser sobrescritos a pôr em /app/data/python/customize/static
(veja Volumes de contentor Docker). Por exemplo, criar /app/data/python/customize/static/favicon.ico
substituirá o favicon.
Dica
Os ficheiros são copiados para o local correspondente na inicialização do contentor, portanto, é necessário reiniciar o Weblate após alterar o conteúdo do volume.
Essa abordagem também pode ser usada para substituir os modelos Weblate. Por exemplo documentos legais podem ser postos em /app/data/python/customize/templates/legal/documents
.
Como alternativa, também pode incluir o próprio módulo (veja ../ customize) e adicioná-lo como um volume separado ao contentor do Docker, por exemplo:
weblate:
volumes:
- weblate-data:/app/data
- ./weblate_customization/weblate_customization:/app/data/python/weblate_customization
environment:
WEBLATE_ADD_APPS: weblate_customization
Configurando o servidor PostgreSQL¶
O contentor PostgreSQL usa a configuração padrão do PostgreSQL e não utilizará efetivamente os núcleos de CPU ou memória dele. Recomenda-se personalizar a configuração para melhorar o desempenho.
A configuração pode ser ajustada conforme descrito em Database Configuration em https://hub.docker.com/_/postgres. A configuração correspondente ao seu ambiente pode ser gerada usando https://pgtune.leopard.in.ua/.
Partes internas do contentor¶
O contentor está usando supervisor para iniciar serviços individuais. No caso de Dimensionando horizontalmente, ele inicia apenas um único serviço num contentor.
Para verificar o estado dos serviços, use:
docker compose exec --user weblate weblate supervisorctl status
Existem serviços individuais para cada fila Celery (veja Tarefas de fundo a usar o Celery para detalhes). Pode interromper o processamento de algumas tarefas parando o worker apropriado:
docker compose exec --user weblate weblate supervisorctl stop celery-translate