Instalando a usar Docker
Com a implantação do Weblate dockerizada, pode pôr 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.
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):
2 GB de RAM
2 núcleos de CPU
1 GB de espaço de armazenamento
Quanto mais memória melhor – ele é usada para cache em todos os níveis (sistema de ficheiros, banco de dados e Weblate).
Muitos utilizadores simultâneos aumentam a quantidade de núcleos de CPU necessários. Para centenas de componentes de tradução é recomendado pelo menos 4 GB de RAM.
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 tamanho mínimo deles a fazer clones rasos.
Nota
Os requisitos reais para a sua instalação do Weblate variam fortemente com base no tamanho das traduções geridas nele.
Instalação
Os exemplos a seguir presumem que tem um ambiente Docker funcional, com docker-compose
instalado. Verifique a documentação do Docker para obter instruções.
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
.
Alterado na versão 2.15-2: A configuração foi alterada recentemente, antes havia um contentor de servidor web separado, desde 2.15-2 o servidor web está embutido no contentor do Weblate.
Alterado na versão 3.7.1-6: Em julho de 2019 (a começar com a tag 3.7.1-6), os contentores não estão a ser executados como um utilizador root. Isso mudou a porta exposta de 80 para 8080.
Veja também
Escolhendo a tag do hub Docker
Pode usar as seguintes tags no hub do Docker, veja https://hub.docker.com/r/weblate/weblate/tags/ para uma lista completa das tags disponíveis.
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 |
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.
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
Novo na versão 3.8-3.
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;
listen [::]:443;
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 passar os dois ficheios a ele e então fazer:
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.10-1: Desde o Weblate 4.10-1, o contentor Docker usa Django 4.0, o que requer PostgreSQL 10 ou mais recente, atualize-o antes de atualizar o Weblate. Veja Atualizar da 4.9 para 4.10 e 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 --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_postgres-data
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 postgres
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
Dimensionando horizontalmente
Novo na versão 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 Weblate tem um papel definido a usar 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
Many of Weblate’s Configuração can be set in the Docker container using the environment variables described below.
If you need to define a setting not exposed through Docker environment variables, see Configuration beyond environment variables.
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
Configura o detalhamento do log.
- 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_PASSWORD_FILE
Define o caminho para um ficheiro que contém a palavra-passe para o utilizador admin.
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_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_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
Novo na versão 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_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
.
- WEBLATE_GOOGLE_ANALYTICS_ID
Configura o ID para o Google Analytics a alterar
GOOGLE_ANALYTICS_ID
.
- WEBLATE_GITHUB_USERNAME
- WEBLATE_GITHUB_TOKEN
- WEBLATE_GITHUB_HOST
Configures GitHub pull-requests integration by changing
GITHUB_CREDENTIALS
(ifWEBLATE_GITHUB_HOST
is set), orGITHUB_USERNAME
andGITHUB_TOKEN
.Veja também
- WEBLATE_GITLAB_USERNAME
- WEBLATE_GITLAB_TOKEN
- WEBLATE_GITLAB_HOST
Configures GitLab merge-requests integration by changing
GITLAB_CREDENTIALS
(ifWEBLATE_GITLAB_HOST
is set), orGITLAB_USERNAME
andGITLAB_TOKEN
.Veja também
- WEBLATE_GITEA_USERNAME
- WEBLATE_GITEA_TOKEN
- WEBLATE_GITEA_HOST
Configures Gitea pull-requests integration by changing
GITEA_CREDENTIALS
(ifWEBLATE_GITEA_HOST
is set), orGITEA_USERNAME
andGITEA_TOKEN
.Veja também
- WEBLATE_PAGURE_USERNAME
- WEBLATE_PAGURE_TOKEN
- WEBLATE_PAGURE_HOST
Configures Pagure merge-requests integration by changing
PAGURE_CREDENTIALS
(ifWEBLATE_PAGURE_HOST
is set), orPAGURE_USERNAME
andPAGURE_TOKEN
.Veja também
- 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
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
Novo na versão 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
Novo na versão 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
Novo na versão 4.13.
Configura
ENABLE_HOOKS
.
- WEBLATE_ENABLE_AVATARS
Novo na versão 4.6.1.
Configura
ENABLE_AVATARS
.
- WEBLATE_AVATAR_URL_PREFIX
Novo na versão 4.15.
Configura
AVATAR_URL_PREFIX
.
- WEBLATE_LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH
Novo na versão 4.9.
Configura
LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH
.
- WEBLATE_SSH_EXTRA_ARGS
Novo na versão 4.9.
Configura
SSH_EXTRA_ARGS
.
- WEBLATE_BORG_EXTRA_ARGS
Novo na versão 4.9.
Configura
BORG_EXTRA_ARGS
.
- WEBLATE_ENABLE_SHARING
Novo na versão 4.14.1.
Configura
ENABLE_SHARING
.
- WEBLATE_EXTRA_HTML_HEAD
Novo na versão 4.15.
Configures
EXTRA_HTML_HEAD
.
- WEBLATE_PRIVATE_COMMIT_EMAIL_TEMPLATE
Novo na versão 4.15.
Configures
PRIVATE_COMMIT_EMAIL_TEMPLATE
.
- WEBLATE_PRIVATE_COMMIT_EMAIL_OPT_IN
Novo na versão 4.15.
Configures
PRIVATE_COMMIT_EMAIL_OPT_IN
.
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 Configurando 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_BIND_PASSWORD_FILE
Caminho ao ficheiro que contém a palavra-passe de ligação do servidor LDAP.
Veja também
- 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.
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 OAuth 2 do Google.
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
Enables Gitea authentication.
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_UBUNTU
Slack
- WEBLATE_SOCIAL_AUTH_SLACK_KEY
OpenID Connect
Novo na versão 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 intergraçã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.
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.
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.
- POSTGRES_PASSWORD_FILE
Caminho para o ficheiro que contém a palavra-passe do PostgreSQL. Use como uma alternativa para POSTGRES_PASSWORD.
- POSTGRES_USER
Nome de utilizador do PostgreSQL.
- POSTGRES_DATABASE
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
Configura o nome da função para alterar durante as migrações, consulte Configurar Weblate para usar PostgreSQL.
- POSTGRES_CONN_MAX_AGE
Novo na versão 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 (este é o comportamento predefinido).
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
Novo na versão 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
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.
- REDIS_PASSWORD_FILE
Caminho ao ficheiro que contém a palavra-passe do servidor Redis.
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_HOST_PASSWORD_FILE
Caminho para o ficheiro que contém a 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
.
Relatório de erro
É recomendado coletar erros da instalação sistematicamente, veja Coletando relatórios de erros.
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 DSN no Sentry.
- SENTRY_ENVIRONMENT
O seu ambiente no Sentry (opcional).
CDN de localização
- WEBLATE_LOCALIZE_CDN_URL
- WEBLATE_LOCALIZE_CDN_PATH
Novo na versão 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 aplicações, verificações, extensões ou correções automáticas ativados
Novo na versão 3.8-5.
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
Exemplo:
environment:
WEBLATE_REMOVE_AUTOFIX: weblate.trans.autofixes.whitespace.SameBookendingWhitespace
WEBLATE_ADD_ADDONS: customize.addons.MyAddon,customize.addons.OtherAddon
Veja também
Configurações do contentor
- WEBLATE_WORKERS
Novo na versão 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
- 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 cacho) exportados pelo contentor Weblate. Os outros contentores de serviço (PostgreSQL ou Redis) também têm os volumes de dados deles, mas eles não são cobertos por este documento.
O volume de dados é usado para armazenar dados persistentes do Weblate, como repositórios clonados ou para personalizar a instalação do Weblate.
O posicionamento do volume Docker no sistema hospedeiro depende da configuração do Docker, mas geralmente é armazenado em /var/lib/docker/volumes/weblate-docker_weblate-data/_data/
(o caminho consiste no nome de seu diretório docker-compose, contentor e nomes de volume). No contentor, ele é montado como /app/data
.
O volume do cache é montado como /app/cache
e é usado para armazenar ficheiros estáticos. O conteúdo deles é recriado na inicialização do contentor e o volume pode ser montado a usar um sistema de ficheiros efêmero como tmpfs.
Ao criar os volumes manualmente, os diretórios devem pertencer ao UID 1000, pois é o utilizador usado dentro do contentor.
Veja também
Configuration beyond environment variables
Docker environment variables are intended to expose most configuration settings of relevance for Weblate installations.
If you find a setting that is not exposed as an environment variable, and you believe that it should be, feel free to ask for it to be exposed in a future version of Weblate.
If you need to modify a setting that is not exposed as a Docker environment variable, you can still do so, either from the data volume or extending the Docker image.
Veja também
Overriding settings from the data volume
You can create a file at /app/data/settings-override.py
, i.e. at the
root of the data volume, to extend or override settings
defined through environment variables.
Overriding settings by extending the Docker image
To override settings at the Docker image level instead of from the data volume:
Add a module to your package that imports all settings from
weblate.settings_docker
.For example, within the example package structure defined at Criar um módulo Python, you could create a file at
weblate_customization/weblate_customization/settings.py
with the following initial code:from weblate.settings_docker import *
Create a custom
Dockerfile
that inherits from the official Weblate Docker image, and then installs your package and points theDJANGO_SETTINGS_MODULE
environment variable to your settings module:FROM weblate/weblate USER root COPY weblate_customization /usr/src/weblate_customization RUN pip install --no-cache-dir /usr/src/weblate_customization ENV DJANGO_SETTINGS_MODULE=weblate_customization.settings USER 1000
Instead of using the official Weblate Docker image, build a custom image from this
Dockerfile
file.There is no clean way to do this with
docker-compose.override.yml
. You could addbuild: .
to theweblate
node in that file, but then your custom image will be tagged asweblate/weblate
in your system, which could be problematic.So, instead of using the
docker-compose.yml
straight from the official repository, unmodified, and extending it throughdocker-compose.override.yml
, you may want to make a copy of the officialdocker-compose.yml
file, and edit your copy to replaceimage: weblate/weblate
withbuild: .
.See the Compose file build reference for details on building images from source when using
docker-compose
.Extend your custom settings module to define or redefine settings.
You can define settings before or after the import statement above to determine which settings take precedence. Settings defined before the import statement can be overriden by environment variables and setting overrides defined in the data volume. Setting defined after the import statement cannot be overriden.
You can also go further. For example, you can reproduce some of the things that
weblate.docker_settings
does, such as exposing settings as environment variables, or allow overriding settings from Python files in the data volume.
Substituindo o logotipo e outros ficheiros estáticos
Novo na versão 3.8-5.
Os ficheiros estáticos que vêm com Weblate podem ser sobrescritos a colocar 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 PostgtreSQL 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/.
Container internals
The container is using supervisor to start individual services. In case of Dimensionando horizontalmente, it only starts single service in a container.
To check the services status use:
docker-compose exec --user weblate weblate supervisorctl status
There are individual services for each Celery queue (see Tarefas de fundo a usar o Celery for details). You can stop processing some tasks by stopping the appropriate worker:
docker-compose exec --user weblate weblate supervisorctl stop celery-translate