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):

3 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 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

Invocando comandos de gestão

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
`latest`	Versão estável do Weblate, corresponde à última versão marcada	Atualizações contínuas num ambiente de produção
`<VERSION>-<PATCH>`	Versão estável do Weblate	Implantação bem definida num ambiente de produção
`edge`	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
`edge-<DATE>-<SHA>`	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
`bleeding`	Versão de desenvolvimento do Weblate do Git	Atualizações contínuas para testar os próximos recursos do Weblate
`bleeding-<DATE>-<SHA>`	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ários
ssl/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.

Veja também

https://github.com/docker-library/postgres/issues/37

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-docker_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

(Optional) Update password for the Weblate user. This might be needed when migrating to PostgreSQL 14 or 15 as way of storing passwords has been changed:
```
docker-compose exec -T database psql --username weblate --dbname postgres -c "ALTER USER weblate WITH PASSWORD 'weblate'"
```
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

Veja também

WEBLATE_WORKERS CELERY_MAIN_OPTIONS, CELERY_NOTIFY_OPTIONS, CELERY_MEMORY_OPTIONS, CELERY_TRANSLATE_OPTIONS, CELERY_BACKUP_OPTIONS, CELERY_BEAT_OPTIONS, WEB_WORKERS

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#

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.

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

Desativar o modo de depuração

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

Definir domínio correto do site, SITE_DOMAIN

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 (veja WEBLATE_ADMIN_PASSWORD para mais informações).

Exemplo:

environment:
  WEBLATE_ADMIN_NAME: Weblate admin
  WEBLATE_ADMIN_EMAIL: noreply@example.com

Veja também

Autenticação como administrador, Configurar administradores corretamente, ADMINS

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 e WEBLATE_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.

Veja também

Autenticação como administrador, WEBLATE_ADMIN_PASSWORD, WEBLATE_ADMIN_PASSWORD_FILE, WEBLATE_ADMIN_NAME, WEBLATE_ADMIN_EMAIL

WEBLATE_ADMIN_PASSWORD_FILE#: Define o caminho para um ficheiro que contém a palavra-passe para o utilizador admin.

Veja também

WEBLATE_ADMIN_PASSWORD

WEBLATE_SERVER_EMAIL#: O endereço de e-mail a partir do qual as mensagens de erro são enviadas.

Veja também

SERVER_EMAIL, Configurar envio de e-mail

WEBLATE_DEFAULT_FROM_EMAIL#: Configura o endereço para e-mails de saída.

Veja também

DEFAULT_FROM_EMAIL, Configurar envio de e-mail

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

Veja também

ALLOWED_HOSTS, Configuração de hosts permitidos, Definir domínio correto do site

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#: Novo na versão 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

Veja também

ENABLE_HTTPS Definir domínio correto do site, WEBLATE_SECURE_PROXY_SSL_HEADER

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

INTERLEDGER_PAYMENT_POINTERS

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 define IP_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 para HTTP_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

SECURE_PROXY_SSL_HEADER

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 e REMOVE.

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.

Veja também

Pull requests do GitHub

WEBLATE_GITLAB_USERNAME#

WEBLATE_GITLAB_TOKEN#

WEBLATE_GITLAB_HOST#

Configures GitLab merge-requests integration by changing GITLAB_CREDENTIALS.

Exemplo:

WEBLATE_GITLAB_USERNAME=weblate
WEBLATE_GITLAB_HOST=gitlab.com
WEBLATE_GITLAB_TOKEN=token

Veja também

Merge requests do GitLab

WEBLATE_GITEA_USERNAME#

WEBLATE_GITEA_TOKEN#

WEBLATE_GITEA_HOST#: Configures Gitea pull-requests integration by changing GITEA_CREDENTIALS.

Veja também

Pull requests do Gitea

WEBLATE_PAGURE_USERNAME#

WEBLATE_PAGURE_TOKEN#

WEBLATE_PAGURE_HOST#: Configures Pagure merge-requests integration by changing PAGURE_CREDENTIALS.

Veja também

Merge requests do Pagure

WEBLATE_BITBUCKETSERVER_USERNAME#

WEBLATE_BITBUCKETSERVER_TOKEN#

WEBLATE_BITBUCKETSERVER_HOST#: Configures Bitbucket Server pull-requests integration by changing BITBUCKETSERVER_CREDENTIALS.

Veja também

Bitbucket Server pull requests

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

DEFAULT_PULL_MESSAGE

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

Assinando commits do Git com GnuPG

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.

Veja também

Política de segurança de conteúdo, CSP_SCRIPT_SRC, CSP_IMG_SRC, CSP_CONNECT_SRC, CSP_STYLE_SRC, CSP_FONT_SRC

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 e 5000/hour para utilizadores autenticados.

Veja também

Limitação de taxa da API

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.

Configura EXTRA_HTML_HEAD.

WEBLATE_PRIVATE_COMMIT_EMAIL_TEMPLATE#: Novo na versão 4.15.

Configura PRIVATE_COMMIT_EMAIL_TEMPLATE.

WEBLATE_PRIVATE_COMMIT_EMAIL_OPT_IN#: Novo na versão 4.15.

Configura PRIVATE_COMMIT_EMAIL_OPT_IN.

WEBLATE_UNUSED_ALERT_DAYS#: Novo na versão 4.17.

Configures UNUSED_ALERT_DAYS.

WEBLATE_CORS_ALLOWED_ORIGINS#

Novo na versão 4.16.

Allow CORS requests from given origins.

Exemplo:

environment:
  WEBLATE_CORS_ALLOWED_ORIGINS: https://example.com,https://weblate.org

CLIENT_MAX_BODY_SIZE#

Novo na versão 4.16.3.

Configures maximal body size accepted by the built-in web server.

environment:
    CLIENT_MAX_BODY_SIZE: 200m

Dica

This variable intentionally lacks WEBLATE_ prefix as it is shared with third-party container used in Certificados SSL automáticos a usar Let’s Encrypt.

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_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

Autenticação por LDAP

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 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#

SOCIAL_AUTH_SLACK_SECRET#: Ativa a autenticação Slack, veja Slack.

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#: Configures generic OpenID Connect integration.

Veja também

OIDC (OpenID Connect)

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

Configuração de banco de dados para o Weblate

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

CONN_MAX_AGE, Persistent connections

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

Veja também

DISABLE_SERVER_SIDE_CURSORS, Transaction pooling and server-side cursors

Configurações de backup de base de dados#

Veja também

Dados despejados para backups

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

Ativar o cache

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_PASSWORD

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

Configuração de e-mail de saída

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

EMAIL_PORT

WEBLATE_EMAIL_HOST_USER#: Utilizador da autenticação por e-mail.

Veja também

EMAIL_HOST_USER

WEBLATE_EMAIL_HOST_PASSWORD#: Palavra-passe da autenticação por e-mail.

Veja também

EMAIL_HOST_PASSWORD

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_HOST_PASSWORD

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_PORT, WEBLATE_EMAIL_USE_TLS, EMAIL_USE_SSL

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_PORT, WEBLATE_EMAIL_USE_SSL, EMAIL_USE_TLS

WEBLATE_EMAIL_BACKEND#: Configura o back-end do Django para usar no envio de e-mails.

Veja também

Configurar envio de e-mail, EMAIL_BACKEND

WEBLATE_AUTO_UPDATE#: Configura se e como o Weblate deve atualizar os repositórios.

Veja também

AUTO_UPDATE

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_LEGAL_URL#: Configura LEGAL_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.

Veja também

Traduzir HTML e JavaScript a usar CDN Weblate, LOCALIZE_CDN_URL, LOCALIZE_CDN_PATH

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

CHECK_LIST, AUTOFIX_LIST, WEBLATE_ADDONS, INSTALLED_APPS

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 e WEB_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

Veja também

Opções de worker do Celery, Tarefas de fundo a usar o Celery

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.

The cache volume is mounted as /app/cache and is used to store static files and CACHE_DIR. Its content is recreated on container startup and the volume can be mounted using ephemeral filesystem such as tmpfs.

Ao criar os volumes manualmente, os diretórios devem pertencer ao UID 1000, pois é o utilizador usado dentro do contentor.

Veja também

Documentação sobre volumes do Docker

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

Personalizar o Weblate

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:

Crie um pacote Python personalizado.
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 ambiente DJANGO_SETTINGS_MODULE para o seu módulo de configurações:

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

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 adicionar build: . ao nó weblate nesse ficheiro, mas a sua imagem personalizada será marcada como weblate/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 do docker-compose .override.yml, pode fazer uma cópia do ficheiro docker-compose.yml oficial e editar a sua cópia para substituir image: weblate/weblate por build: ..

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.

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 overridden by environment variables and setting overrides defined in the data volume. Setting defined after the import statement cannot be overridden.

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#

Novo na versão 3.8-5.

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 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/.

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