Docker を使用したインストール¶

Docker 化された Weblate デプロイでは、数秒で個人の Weblate インスタンスを起動して実行できます。Weblate の依存関係はすべて含まれています。PostgreSQL が、デフォルトデータベースとして設定され、Redis がキャッシュバックエンドとして設定されます。

ハードウェア要件¶

Weblate should run on any contemporary hardware without problems, the following is the minimal configuration required to run Weblate on a single host (Weblate, database and web server):

3 GB の RAM
2 CPU コア
1 GB の記憶容量（HDD or SSD）

注釈

実際に必要な Weblate のインストールの要件は、Weblate で管理する翻訳のサイズによって大きく変化します。

Memory usage¶

The more memory the better - it is used for caching on all levels (file system, database and Weblate). For hundreds of translation components, at least 4 GB of RAM is recommended.

ヒント

メモリが推奨よりも少ないシステムの場合は、シングルプロセス Celery の設定を推奨します。

CPU usage¶

Many concurrent users increase the amount of needed CPU cores.

Storage usage¶

The typical database storage usage is around 300 MB per 1 million hosted words.

Storage space needed for cloned repositories varies, but Weblate tries to keep their size minimal by doing shallow clones.

Nodes¶

For small and medium-sized sites (millions of hosted words), all Weblate components (see アーキテクチャの概要) can be run on a single node.

When you grow to hundreds of millions of hosted words, it is recommended to have a dedicated node for database (see Weblate のデータベース設定).

インストール¶

ヒント

次の例は、docker-compose-plugin がインストール済みの Docker 環境が動作していることを前提としています。手順については、Docker のドキュメントを確認してください。

これにより、HTTP 経由で Weblate を展開するサーバーが作成されるため、HTTPS 終端プロキシの背後に配置することが必要です。HTTPS プロキシで展開することもできます。参照: Let's Encrypt による自動 SSL 証明書の発行。より大規模なセットアップについては、水平方向のスケーリングを確認してください。

weblate-docker リポジトリのクローンの作成:

git clone https://github.com/WeblateOrg/docker-compose.git weblate-docker
cd weblate-docker

設定した内容で docker-compose.override.yml ファイルを作成します。全ての環境変数の一覧は Docker 環境変数にあります。

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

注釈

WEBLATE_ADMIN_PASSWORD が設定されていない場合は、最初の起動時に表示されるランダムなパスワードで、管理者ユーザーのアカウントが作成されます。

この例では、Weblate はポート 80 をリッスンします。変更する場合は、docker-compose.override.yml ファイルのポートマッピングを編集してください。

Weblate コンテナを起動する:
```
docker compose up
```

配置した Weblate をお楽しみください、それは weblate コンテナのポート 80 からアクセスできます。

参考

管理コマンドの起動

Docker イメージレジストリの選択¶

Weblate コンテナーの公開レジストリ:

Docker Hub、参照: https://hub.docker.com/r/weblate/weblate
GitHub パッケージレジストリ、参照: https://github.com/WeblateOrg/docker/pkgs/container/weblate

注釈

現在、すべての例は Docker Hub からイメージを取得しています。別のレジストリを使用するように設定を変更してください。

Docker イメージタグの選択¶

環境と希望と一致するタグの選択:

タグ名	説明	使用例
`latest`	Weblate 安定版リリース、最新のタグ付きリリースに対応	運用環境でのローリングアップデート
`<MAJOR>`	Weblate 安定版のリリース	運用環境におけるメジャーバージョン内でのローリングアップデート
`<MAJOR>.<MINOR>`	Weblate 安定版のリリース	運用環境におけるマイナーバージョン内でのローリングアップデート
`<VERSION>.<PATCH>`	Weblate 安定版のリリース	運用環境での明確な展開
`edge`	Docker コンテナに開発上の変更を加えた Weblate 安定版のリリース（例: 依存関係の更新など）	ステージング環境でのローリングアップデート
`edge-<DATE>-<SHA>`	Docker コンテナに開発上の変更を加えた Weblate 安定版のリリース（例: 依存関係の更新など）	ステージング環境での明確な展開
`bleeding`	Git から開発版の Weblate	今後の Weblate の機能をテストするためのローリングアップデート
`bleeding-<DATE>-<SHA>`	Git から開発版の Weblate	Weblate の新機能をテストするための明確な展開

すべてのイメージは、公開される前に CI によってテストされるため、bleeding 版であっても安全に使用できます。

公開されているタグの完全なリストは、GitHub Packages にあります

HTTPS に対応した Docker コンテナ¶

一般的な展開手順については、インストールを確認してください。この項目では、一般的な展開手順との違いについてのみ説明します。

独自の SSL 証明書の使用¶

使用したい独自の SSL 証明書がある場合は、ファイルを Weblate データボリュームに配置するだけです（参照: Docker コンテナのボリューム）。

ssl/fullchain.pem 必要な CA 証明書を含んだ証明書を含む
ssl/privkey.pem 秘密鍵を含む

このファイルは両方とも、docker コンテナを起動したユーザーと同じユーザーが所有者であることが必要です。ファイルマスクは、600 に設定してください（所有者のユーザーのみが読み書き可能）。

さらに、Weblate コンテナはポート 4443 で SSL 接続を受け入れるようになりました。HTTPS のポート転送を docker compose オーバーライドに含めてください。ポート転送の設定方法:

version: '3'
services:
  weblate:
    ports:
      - 80:8080
      - 443:4443

すでに、同じサーバー上の他のサイトをホストしている場合は、ポート 80 と 443 が NGINX などのリバースプロキシによって使用されていることがあります。下記は、NGINX から Docker コンテナに HTTPS 接続を渡すために使用可能な構成方法:

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>;
    }
}

<SITE_URL>、<SITE> および <EXPOSED_DOCKER_PORT> は、実際に使用する環境の値に書き換えてください。

Let's Encrypt による自動 SSL 証明書の発行¶

公開サーバーで、Let’s Encrypt の自動生成 SSL 証明書を使用する場合は、追加の Docker コンテナにリバース HTTPS プロキシの追加が必要です。そのため、https-portal を使用します。これは、docker-compose-https.yml ファイルで使用されます。次に、設定した内容で docker-compose-https.override.yml ファイルを作成します。

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'

docker compose を呼び出すときは常に、両方のファイルを渡すことが必要です。その後、次を実行:

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

Docker コンテナーのアップグレード¶

通常は、Weblate コンテナのみを更新し、PostgreSQL コンテナは現在のバージョンを維持してください。PostgreSQL のアップグレードは非常に面倒であり、多くの場合あまり効果は期待できません。

バージョン 4.17-1 で変更: Weblate 4.17-1 以降の Docker コンテナーは、PostgreSQL 12 以降が必要な Django 4.2 を使用するため、Weblate をアップグレードする前に PostgreSQL コンテナのアップグレードをしてください。参照: PostgreSQL コンテナのアップグレード。

Weblate コンテナのみの更新方法。既存の docker-compose を使用し、最新のイメージを取得して再起動する手順:

# 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

Weblate データベースは、初回の起動時に自動的に移行し、追加の手動操作は必要ありません。

注釈

Weblate では、メジャーバージョン間のアップグレードには対応していません。たとえば、3.x シリーズを使用していて 4.x にアップグレードする場合は、まず最新の 4.0.x-y イメージにアップグレードします（この記事の執筆時点では 4.0.4-5）。これにより移行が実行され、新しいバージョンへのアップグレードが続行されます。

docker-compose リポジトリを更新したくなるかもしれませんが、ほとんどの場合は必要ありません。PostgreSQL サーバのアップグレードについては、PostgreSQL コンテナのアップグレードを参照してください。

PostgreSQL コンテナのアップグレード¶

PostgreSQL コンテナは、バージョンの自動アップグレードには対応していません。手動でアップグレードしてください。次の手順は、アップグレードの方法の中の 1 つです。

参考

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

Weblate コンテナの停止:
```
docker compose stop weblate cache
```

データベースのバックアップ:

docker compose exec database pg_dumpall --clean --if-exists --username weblate > backup.sql

データベースコンテナの停止:
```
docker compose stop database
```
PostgreSQL ボリュームの削除:
```
docker compose rm -v database
docker volume remove weblate-docker_postgres-data
```
ヒント

ボリューム名には、Docker Compose プロジェクトの名前が含まれます。デフォルトのディレクトリ名は、このドキュメントでは weblate-docker です。
新しい PostgreSQL のバージョンを使用するように :file:`docker-compose.yml`を編集します。
データベースコンテナの起動:
```
docker compose up -d database
```
データベースをバックアップから復元:
```
cat backup.sql | docker compose exec -T database psql --username weblate --dbname weblate
```
ヒント

データベース名が POSTGRES_DB と一致していることを確認してください。
（オプション）Weblate ユーザーのパスワードを更新させる。これは、パスワードの保存方法が変更されたため、PostgreSQL 14 または 15 に移行するときに必要となる場合の方法:
```
docker compose exec -T database psql --username weblate --dbname weblate -c "ALTER USER weblate WITH PASSWORD 'weblate'"
```
ヒント

データベース名が POSTGRES_DB と一致していることを確認してください。
残りのコンテナをすべて起動:
```
docker compose up -d
```

管理者としてサインイン¶

コンテナの設定後、WEBLATE_ADMIN_PASSWORD に設定したパスワードを使用して、admin ユーザーとしてサインインできます。設定していない場合は、初回の起動時にランダムなパスワードが生成されます。

admin パスワードをリセットするには、WEBLATE_ADMIN_PASSWORD に新しいパスワードを設定してコンテナを再起動します。

参考

WEBLATE_ADMIN_PASSWORD、WEBLATE_ADMIN_NAME、WEBLATE_ADMIN_EMAIL

プロセス数とメモリ消費量¶

uWSGI と Celery のワーカープロセスの数は、CPU の数に基づいて自動的に決定されます。これは、ほとんどのクラウド仮想マシンで適切に機能します。これは通常、CPUが少なく、メモリの量が多いためです。

CPU のコア数が多く、メモリ不足の問題が発生する場合、ワーカーの数を減らしてみてください。ワーカー数の設定例:

environment:
  WEBLATE_WORKERS: 2

個々のワーカーのカテゴリを詳細に設定する方法:

environment:
  WEB_WORKERS: 4
  CELERY_MAIN_OPTIONS: --concurrency 2
  CELERY_NOTIFY_OPTIONS: --concurrency 1
  CELERY_TRANSLATE_OPTIONS: --concurrency 1

参考

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

水平方向のスケーリング¶

Added in version 4.6.

複数の Weblate コンテナを実行して、サービスを水平方向にスケーリングできます。/app/data ボリュームはすべてのコンテナで共有することが必要であるため、GlusterFS などのクラスタファイルシステムを使用してください。/app/cache ボリュームは、コンテナごとに別々にしてください。

各 Weblate コンテナには、WEBLATE_SERVICE 環境変数を使用して役割が定義されています。一部のサービスはクラスター内で 1 回だけ実行すべきで、サービスの順序も重要であるため、ドキュメントに注意して従ってください。

設定例は、docker-compose リポジトリに docker-compose-split.yml として記載されています。

Docker 環境変数¶

Weblate の設定の多くは、以下の環境変数を使用して Docker コンテナに設定できます。

Docker 環境変数で公開されていない設定を定義する場合は、環境変数以外の設定を確認してください。

シークレットの受け渡し¶

Added in version 5.0.

Weblate コンテナは、ファイルでシークレットを受け渡すことに対応しています。これを使用するには、環境変数に _FILE 接尾辞を付加し、シークレットファイルを Docker 経由で受け渡します。

関連する docker-compose.yml の場合:

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

参考

Docker Compose でシークレットを使用する方法

一般的な設定¶

WEBLATE_DEBUG¶

DEBUG を使用して Django デバッグモードを設定します。

例:

environment:
  WEBLATE_DEBUG: 1

参考

デバッグモードの無効化

WEBLATE_LOGLEVEL¶

ログの詳細度を設定します。より詳細なログを取得するには、これを DEBUG に設定してください。

WEBLATE_DEBUG が無効の場合は、デフォルトで INFO になり、デバッグモードが有効の場合は DEBUG となります。

よりサイレントなロギングを行うには、ERROR または``WARNING`` を使用します。

WEBLATE_LOGLEVEL_DATABASE¶: データベースクエリの冗長性のログの設定します。

WEBLATE_SITE_TITLE¶: すべてのページのヘッダーに表示される、サイトタイトルを変更します。

WEBLATE_SITE_DOMAIN¶: サイトのドメインを設定します。このパラメーターは必須です。

参考

サイトの正確なドメイン設定、SITE_DOMAIN

WEBLATE_ADMIN_NAME¶

WEBLATE_ADMIN_EMAIL¶

サイト管理者の名前とメールアドレスを設定します。これは、管理者 設定と、管理者ユーザーの作成の両方に使用されます（詳細については、WEBLATE_ADMIN_PASSWORD を確認してください）。

例:

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

参考

管理者としてサインイン、適切な管理者の設定、ADMINS

WEBLATE_ADMIN_PASSWORD¶

管理者ユーザーのパスワードを設定します。

管理者パスワードが設定されておらず、管理者ユーザーも存在しない場合は、最初のコンテナ起動時に表示されるランダムなパスワードで作成されます。
管理者パスワードが設定されておらず、管理者ユーザーが存在する場合、管理者パスワードは設定されません。
管理者パスワードが設定されている場合、管理者ユーザーは、コンテナが起動するたびに WEBLATE_ADMIN_PASSWORD、WEBLATE_ADMIN_NAME および WEBLATE_ADMIN_EMAIL に設定されます。

警告

設定ファイルにパスワードを格納すると、セキュリティ上のリスクがあります。この変数は、初期設定（または Weblate の初期起動時にランダムパスワードを生成させる）またはパスワードの回復にのみ使用してください。

参考

管理者としてサインイン、シークレットの受け渡し、WEBLATE_ADMIN_PASSWORD、WEBLATE_ADMIN_NAME、WEBLATE_ADMIN_EMAIL

WEBLATE_SERVER_EMAIL¶: エラーメッセージ送信元のメールアドレス。

参考

SERVER_EMAIL、メールの送信設定

WEBLATE_DEFAULT_FROM_EMAIL¶: 送信用のメールアドレスを設定します。

参考

DEFAULT_FROM_EMAIL、メールの送信設定

WEBLATE_ADMINS_CONTACT¶: ADMINS_CONTACT の設定。

WEBLATE_CONTACT_FORM¶: 問い合わせフォームの動作を設定します。参照: CONTACT_FORM。

WEBLATE_ALLOWED_HOSTS¶

ALLOWED_HOSTS を使用して、許可する HTTP ホスト名を設定します。

デフォルトは * で、すべてのホスト名を許可します。

例:

environment:
  WEBLATE_ALLOWED_HOSTS: weblate.example.com,example.com

参考

ALLOWED_HOSTS、許可するホストの登録、サイトの正確なドメイン設定

WEBLATE_REGISTRATION_OPEN¶

REGISTRATION_OPEN を 0 か 1 に切り替えることによって、登録を公開するかどうかを設定します。

例:

environment:
  WEBLATE_REGISTRATION_OPEN: 0

WEBLATE_REGISTRATION_ALLOW_BACKENDS¶

REGISTRATION_ALLOW_BACKENDS を使用して、新しいアカウントの作成に使用できる認証方式を設定します。

例:

environment:
  WEBLATE_REGISTRATION_OPEN: 0
  WEBLATE_REGISTRATION_ALLOW_BACKENDS: azuread-oauth2,azuread-tenant-oauth2

WEBLATE_REGISTRATION_REBIND¶: Added in version 4.16.

REGISTRATION_REBIND を設定します。

WEBLATE_TIME_ZONE¶

Weblate で使用するタイムゾーンを設定します。参照: TIME_ZONE。

注釈

Docker コンテナー自体のタイムゾーンを変更するには、環境変数 TZ を使用します。

例:

environment:
  WEBLATE_TIME_ZONE: Europe/Prague

WEBLATE_ENABLE_HTTPS¶

Weblate が、リバース HTTPS プロキシの背後で動作している前提で、メールや API リンクで HTTPS を使用したり、Cookie にセキュリティフラグを設定します。

ヒント

考えられる問題点については、ENABLE_HTTPS ドキュメントを確認してください。

注釈

これにより、Weblate コンテナが HTTPS 接続を受け入れるようにはなりません。 HTTPS 接続には設定が必要です。例については、HTTPS に対応した Docker コンテナ確認してください。

例:

environment:
  WEBLATE_ENABLE_HTTPS: 1

参考

ENABLE_HTTPS サイトの正確なドメイン設定、WEBLATE_SECURE_PROXY_SSL_HEADER

WEBLATE_INTERLEDGER_PAYMENT_POINTERS¶: Added in version 4.12.1.

Weblate のドキュメントの先頭に meta[name=monetization] フィールドを設定します。複数指定した場合は、ランダムに 1 つが選択されます。

参考

INTERLEDGER_PAYMENT_POINTERS

WEBLATE_IP_PROXY_HEADER¶

Weblate が、どのような HTTP ヘッダーからも IP アドレスを取得できるようにします。これは、Weblate コンテナの前段階でリバースプロキシを使用する場合に使用します。

IP_BEHIND_REVERSE_PROXY を有効にし、IP_PROXY_HEADER を設定します。

注釈

形式は Django に準拠させてください。Django が生の HTTP ヘッダー名を transforms する例:

すべての文字を大文字に変換する
ハイフンをアンダースコアに置き換える
HTTP_ 接頭辞の追加

したがって、X-Forwarded-For は HTTP_X_FORWARDED_FOR に配置されます。

例:

environment:
  WEBLATE_IP_PROXY_HEADER: HTTP_X_FORWARDED_FOR

WEBLATE_IP_PROXY_OFFSET¶: Added in version 5.0.1.

IP_PROXY_OFFSET の設定。

WEBLATE_USE_X_FORWARDED_PORT¶: Added in version 5.0.1.

このブール値は、SERVER_PORT META 変数の代わりに、X-Forwarded-Port ヘッダーを使用するかどうかを指定します。このヘッダーを設定するプロキシが使用されている場合にのみ有効にしてください。

参考

USE_X_FORWARDED_PORT

注釈

これは論理値の設定です（"true" または "false" を使用する）。

WEBLATE_SECURE_PROXY_SSL_HEADER¶

リクエストが安全であることを示す、HTTP ヘッダーと値の組み合わせを表すタプル。これは、Weblate が標準の HTTPS ヘッダを通さない SSL 終端を行うリバースプロキシの背後で動作している場合に必要です。

例:

environment:
  WEBLATE_SECURE_PROXY_SSL_HEADER: HTTP_X_FORWARDED_PROTO,https

参考

SECURE_PROXY_SSL_HEADER

WEBLATE_REQUIRE_LOGIN¶

REQUIRE_LOGIN を有効にして、Weblate 全体に認証を強制します。

例:

environment:
  WEBLATE_REQUIRE_LOGIN: 1

WEBLATE_LOGIN_REQUIRED_URLS_EXCEPTIONS¶

WEBLATE_ADD_LOGIN_REQUIRED_URLS_EXCEPTIONS¶

WEBLATE_REMOVE_LOGIN_REQUIRED_URLS_EXCEPTIONS¶

LOGIN_REQUIRED_URLS_EXCEPTIONS を使用して、インストールした Weblate 全体に必要となる認証の例外 URL を追加します。

設定全体を置き換えることも、 ADD と REMOVE 変数を使用してデフォルト値を変更できます。

お問い合わせフォームに対して認証を強制する方法:

environment:
  WEBLATE_REMOVE_LOGIN_REQUIRED_URLS_EXCEPTIONS: /contact/$

WEBLATE_GOOGLE_ANALYTICS_ID¶: GOOGLE_ANALYTICS_ID を変更して、Google Analytics の ID を設定します。

WEBLATE_DEFAULT_PULL_MESSAGE¶: PAGURE_TOKEN を変更して、API 経由の Pagure のプルリクエストに対して、Pagure の個人用アクセストークンを設定する。

参考

DEFAULT_PULL_MESSAGE

WEBLATE_SIMPLIFY_LANGUAGES¶: 言語簡略化ポリシーを設定します。参照: SIMPLIFY_LANGUAGES。

WEBLATE_DEFAULT_ACCESS_CONTROL¶: 新規プロジェクトのデフォルトアクセス制御を設定します。参照: アクセス制御。

WEBLATE_DEFAULT_RESTRICTED_COMPONENT¶: 新しいコンポーネントのアクセス制限のデフォルト値を設定します。参照: DEFAULT_RESTRICTED_COMPONENT。

WEBLATE_DEFAULT_TRANSLATION_PROPAGATION¶: 新しいコンポーネントの翻訳の自動反映の有効化のデフォルト値を設定します。参照: DEFAULT_TRANSLATION_PROPAGATION。

WEBLATE_DEFAULT_COMMITER_EMAIL¶: DEFAULT_COMMITER_EMAIL を設定します。

WEBLATE_DEFAULT_COMMITER_NAME¶: DEFAULT_COMMITER_NAME を設定します。

WEBLATE_DEFAULT_SHARED_TM¶: DEFAULT_SHARED_TM を設定します。

WEBLATE_AKISMET_API_KEY¶: Akismet API キーを設定します。参照: AKISMET_API_KEY。

WEBLATE_GPG_IDENTITY¶: コミットの GPG 署名を設定します。参照: WEBLATE_GPG_IDENTITY。

参考

GnuPG を使用した Git コミットの署名

WEBLATE_URL_PREFIX¶: Weblate が動作している URL の接頭辞を設定します。参照: URL_PREFIX。

WEBLATE_SILENCED_SYSTEM_CHECKS¶: 非表示にする検査項目を設定します。詳細については、SILENCED_SYSTEM_CHECKS を確認してください。

WEBLATE_CSP_SCRIPT_SRC¶

WEBLATE_CSP_IMG_SRC¶

WEBLATE_CSP_CONNECT_SRC¶

WEBLATE_CSP_STYLE_SRC¶

WEBLATE_CSP_FONT_SRC¶: Content-Security-Policy HTTP ヘッダーの変更を可能にします。

参考

コンテンツセキュリティポリシー、CSP_SCRIPT_SRC、CSP_IMG_SRC、CSP_CONNECT_SRC、CSP_STYLE_SRC、CSP_FONT_SRC

WEBLATE_LICENSE_FILTER¶: LICENSE_FILTER の設定。

WEBLATE_LICENSE_REQUIRED¶: LICENSE_REQUIRED を設定します。

WEBLATE_WEBSITE_REQUIRED¶: WEBSITE_REQUIRED を設定します。

WEBLATE_HIDE_VERSION¶: HIDE_VERSION を設定します。

WEBLATE_BASIC_LANGUAGES¶: BASIC_LANGUAGES を設定します。

WEBLATE_DEFAULT_AUTO_WATCH¶: DEFAULT_AUTO_WATCH を設定します。

WEBLATE_RATELIMIT_ATTEMPTS¶

WEBLATE_RATELIMIT_LOCKOUT¶

WEBLATE_RATELIMIT_WINDOW¶: Added in version 4.6.

接続制限を設定します。

ヒント

接続制限の範囲を設定できます。そのため、接続制限に記載のある設定のいずれかに、WEBLATE_ 接頭辞を追加します。

参考

接続制限、RATELIMIT_ATTEMPTS、RATELIMIT_WINDOW、RATELIMIT_LOCKOUT

WEBLATE_API_RATELIMIT_ANON¶

WEBLATE_API_RATELIMIT_USER¶: Added in version 4.11.

API リクエストの接続制限の設定。デフォルトでは、匿名ユーザーの場合は 100 リクエスト / 日、認証済みユーザーの場合は 5000 リクエスト / 時間に制限しています。

参考

API 接続制限

WEBLATE_ENABLE_HOOKS¶: Added in version 4.13.

ENABLE_HOOKS を設定します。

WEBLATE_ENABLE_AVATARS¶: Added in version 4.6.1.

ENABLE_AVATARS を設定します。

WEBLATE_AVATAR_URL_PREFIX¶: Added in version 4.15.

AVATAR_URL_PREFIX の設定。

WEBLATE_LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH¶: Added in version 4.9.

LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH を設定します。

WEBLATE_SSH_EXTRA_ARGS¶: Added in version 4.9.

SSH_EXTRA_ARGS を設定します。

WEBLATE_BORG_EXTRA_ARGS¶

Added in version 4.9.

BORG_EXTRA_ARGS をコンマ区切りの引数リストとして設定します。

例:

environment:
  WEBLATE_BORG_EXTRA_ARGS: --exclude,vcs/

WEBLATE_ENABLE_SHARING¶: Added in version 4.14.1.

ENABLE_SHARING を設定します。

WEBLATE_SUPPORT_STATUS_CHECK¶: Added in version 5.5.

Configures SUPPORT_STATUS_CHECK.

WEBLATE_EXTRA_HTML_HEAD¶: Added in version 4.15.

EXTRA_HTML_HEAD を設定します。

WEBLATE_PRIVATE_COMMIT_EMAIL_TEMPLATE¶: Added in version 4.15.

PRIVATE_COMMIT_EMAIL_TEMPLATE を設定します。

WEBLATE_PRIVATE_COMMIT_EMAIL_OPT_IN¶: Added in version 4.15.

PRIVATE_COMMIT_EMAIL_OPT_IN を設定します。

WEBLATE_UNUSED_ALERT_DAYS¶: Added in version 4.17.

UNUSED_ALERT_DAYS の設定。

WEBLATE_CORS_ALLOWED_ORIGINS¶

Added in version 4.16.

指定したオリジンからの CORS 要求を許可します。

例:

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

CLIENT_MAX_BODY_SIZE¶

Added in version 4.16.3.

内蔵の Web サーバーにアップロードできるファイルの最大サイズを設定します。

environment:
    CLIENT_MAX_BODY_SIZE: 200m

ヒント

この変数は、Let's Encrypt による自動 SSL 証明書の発行で使用されるサードパーティのコンテナーと共有されるため、意図的に WEBLATE_ 接頭辞がありません。

サイトの資格情報をホストするコード¶

Docker コンテナでは、資格情報をホストするコードを個別の変数で設定することも、Python 辞書を使用して資格情報を一度に設定することもできます。次の例は GitHub プルリクエスト用ですが、変数名を適切に変更したすべてのバージョン管理との連携に適用されます。

GitHub のための設定例:

WEBLATE_GITHUB_USERNAME=api-user
WEBLATE_GITHUB_TOKEN=api-token
WEBLATE_GITHUB_HOST=api.github.com

しよう例:

GITHUB_CREDENTIALS = {
    "api.github.com": {
        "username": "api-user",
        "token": "api-token",
    }
}

または、Python 辞書を文字列として提供する方法:

WEBLATE_GITHUB_CREDENTIALS='{ "api.github.com": { "username": "api-user", "token": "api-token", } }'

または、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¶: GITHUB_CREDENTIALS を変更して GitHub プルリクエストを設定します。

参考

Configuring code hosting credentials in Docker

WEBLATE_GITLAB_USERNAME¶

WEBLATE_GITLAB_TOKEN¶

WEBLATE_GITLAB_HOST¶

WEBLATE_GITLAB_CREDENTIALS¶: GITLAB_CREDENTIALS を変更して、GitLab マージリクエストを設定します。

参考

Configuring code hosting credentials in Docker

WEBLATE_GITEA_USERNAME¶

WEBLATE_GITEA_TOKEN¶

WEBLATE_GITEA_HOST¶

WEBLATE_GITEA_CREDENTIALS¶: GITEA_CREDENTIALS を変更して、Gitea プルリクエストを設定します。

参考

Configuring code hosting credentials in Docker

WEBLATE_PAGURE_USERNAME¶

WEBLATE_PAGURE_TOKEN¶

WEBLATE_PAGURE_HOST¶

WEBLATE_PAGURE_CREDENTIALS¶: PAGURE_CREDENTIALS を変更して、Pagure マージリクエストを設定します。

参考

Configuring code hosting credentials in Docker

WEBLATE_BITBUCKETSERVER_USERNAME¶

WEBLATE_BITBUCKETSERVER_TOKEN¶

WEBLATE_BITBUCKETSERVER_HOST¶

WEBLATE_BITBUCKETSERVER_CREDENTIALS¶: BITBUCKETSERVER_CREDENTIALS を変更して、Bitbucket Server プルリクエストを構成します。

参考

Configuring code hosting credentials in Docker

WEBLATE_AZURE_DEVOPS_USERNAME¶

WEBLATE_AZURE_DEVOPS_ORGANIZATION¶

WEBLATE_AZURE_DEVOPS_TOKEN¶

WEBLATE_AZURE_DEVOPS_HOST¶

WEBLATE_AZURE_DEVOPS_CREDENTIALS¶: AZURE_DEVOPS_CREDENTIALS を変更して、Azure DevOps プルリクエストを設定します。

参考

Configuring code hosting credentials in Docker

自動提案の設定¶

バージョン 4.13 で変更: 自動提案サービスは、ユーザーインタフェースから設定するように変更されました。参照: 自動提案。

既存の環境変数は、Weblate 4.13 への移行時にインポートされますが、変更してもそれ以上の影響はありません。

認証設定¶

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¶

LDAP 認証の設定。

直接バインドの例:

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

検索とバインドの例:

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

ユニオン検索とバインドの例:

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

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)

参考

シークレットの受け渡し、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¶: GitHub 認証を有効にします。

GitHub エンタープライズ版¶

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¶: 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¶: Bitbucket 認証を有効にします。

Facebook¶

WEBLATE_SOCIAL_AUTH_FACEBOOK_KEY¶

WEBLATE_SOCIAL_AUTH_FACEBOOK_SECRET¶: Facebook OAuth 2 を有効にします。

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¶: Google OAuth 2 を有効にします。

GitLab¶

WEBLATE_SOCIAL_AUTH_GITLAB_KEY¶

WEBLATE_SOCIAL_AUTH_GITLAB_SECRET¶

WEBLATE_SOCIAL_AUTH_GITLAB_API_URL¶: GitLab OAuth 2 を有効にします。

Gitea¶

WEBLATE_SOCIAL_AUTH_GITEA_API_URL¶

WEBLATE_SOCIAL_AUTH_GITEA_KEY¶

WEBLATE_SOCIAL_AUTH_GITEA_SECRET¶: Gitea 認証を有効にします。

Azure Active Directory¶

WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_KEY¶

WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_SECRET¶: Azure Active Directory 認証を有効にします。参照: Microsoft Azure Active Directory。

Azure Active Directory with Tenant support¶

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_KEY¶

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_SECRET¶

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_TENANT_ID¶: テナントサポート付きで Azure Active Directory 認証を有効にします。参照: Microsoft Azure Active Directory。

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¶: Keycloak 認証を有効にします。参照: ドキュメント。

Linux ベンダー¶

Linux ベンダー認証サービスを使用した認証を有効にするには、以下の変数を指定の値に設定します。

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¶: Slack 認証を有効にします。参照: Slack。

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¶: 一般的な OpenID Connect との連携を設定します。

参考

OIDC (OpenID Connect)

SAML¶

自己署名 SAML 鍵は、最初のコンテナ起動時に自動的に生成されます。独自の鍵を使用するには、証明書と秘密鍵を /app/data/ssl/saml.crt と /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¶: SAML ID プロバイダーを設定します。参照: 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.

SAML 属性のマッピング。

その他の認証設定¶

WEBLATE_NO_EMAIL_AUTH¶: 値を設定すると、メール認証を無効にします。参照: パスワード認証の無効化。

WEBLATE_MIN_PASSWORD_SCORE¶: Minimal password score as evaluated by the zxcvbn password strength estimator. Defaults to 3, set to 0 to disable strength checking.

PostgreSQL データベースの設定¶

データベースは docker-compose.yml によって作成されるので、この設定は、Weblate と PostgreSQL の両方のコンテナに影響を与えます。

参考

Weblate のデータベース設定

POSTGRES_PASSWORD¶: PostgreSQL のパスワード。

参考

シークレットの受け渡し

POSTGRES_USER¶: PostgreSQL ユーザー名。

POSTGRES_DB¶: PostgreSQL データベース名。

POSTGRES_HOST¶: PostgreSQL サーバーのホスト名または IP アドレス。デフォルトは database です。

POSTGRES_PORT¶: PostgreSQL サーバーのポート。デフォルトは none です（デフォルト値を使用する）。

POSTGRES_SSL_MODE¶: PostgreSQL がサーバーへの接続で SSL を処理する方法を設定します。可能な選択肢については、e SSL Mode Descriptions を確認してください。

POSTGRES_ALTER_ROLE¶: 移行中に変更するロールの名前を設定します。参照: Weblate で PostgreSQL を使用するための設定。

POSTGRES_CONN_MAX_AGE¶

Added in version 4.8.1.

データベース接続の寿命を、秒単位の整数で指定します。各リクエストの最後にデータベース接続を閉じるには、0 を指定します。

バージョン 5.1 で変更: デフォルトの動作では、永続的なデータベース接続は無制限になります。

通常、接続の永続性を有効にすると、データベースへの接続がより開放されます。有効にする前にデータベース設定を変更してください。

設定例:

environment:
    POSTGRES_CONN_MAX_AGE: 3600

参考

CONN_MAX_AGE、持続的 (persistent) な接続

POSTGRES_DISABLE_SERVER_SIDE_CURSORS¶

Added in version 4.9.1.

データベース内のサーバー側カーソルを無効にします。これは一部の pgbouncer 設定で必要となります。

設定例:

environment:
    POSTGRES_DISABLE_SERVER_SIDE_CURSORS: 1

参考

DISABLE_SERVER_SIDE_CURSORS、トランザクションプールとサーバーサイドカーソル

WEBLATE_DATABASES¶: Added in version 5.1.

環境変数に基づくデータベース接続の設定を無効にするには、 false に設定します。データベース接続を手動で設定するには、データボリュームからの設定のオーバーライドを使用します。

MySQL または MariaDB サーバー¶

MySQL も MariaDB も環境変数を使用して設定することはできません。Weblate での使用方法については、MySQL と MariaDB を参照してください。データベース接続を手動で設定するには、WEBLATE_DATABASES を使用します。

データベースのバックアップ設定¶

参考

バックアップ用にダンプしたデータ

WEBLATE_DATABASE_BACKUP¶: DATABASE_BACKUP を使用して、毎日のデータベースのダンプを設定します。デフォルトは plain。

キャッシュサーバーの設定¶

Weblate では、Redis の使用を強く推奨しています。Docker で Weblate を実行する場合は、Redis のインスタンスが必要です。

参考

キャッシュの有効化

REDIS_HOST¶: Redis サーバーのホスト名または IP アドレス。デフォルトは cache。

REDIS_PORT¶: Redis サーバーのポート番号。デフォルトは 6379。

REDIS_DB¶: Redis データベースの番号。デフォルトは 1。

REDIS_PASSWORD¶: Redis サーバーのパスワード。デフォルトでは使用しない。

参考

シークレットの受け渡し

REDIS_TLS¶: Redis 接続での SSL の使用を有効にします。

REDIS_VERIFY_SSL¶: Redis 接続の SSL 証明書の検証を無効にするために使用します。

メールサーバーの設定¶

メール送信をするには、メールサーバーが必要です。

TLS 設定の例:

environment:
    WEBLATE_EMAIL_HOST: smtp.example.com
    WEBLATE_EMAIL_HOST_USER: user
    WEBLATE_EMAIL_HOST_PASSWORD: pass

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

参考

メール送信の設定

WEBLATE_EMAIL_HOST¶: メールサーバーのホスト名または IP アドレス。

参考

WEBLATE_EMAIL_PORT、WEBLATE_EMAIL_USE_SSL、WEBLATE_EMAIL_USE_TLS、EMAIL_HOST

WEBLATE_EMAIL_PORT¶: メールサーバーのポート。デフォルトは 25。

参考

EMAIL_PORT

WEBLATE_EMAIL_HOST_USER¶: メール認証ユーザー。

参考

EMAIL_HOST_USER

WEBLATE_EMAIL_HOST_PASSWORD¶: メール認証のパスワード。

参考

シークレットの受け渡し、EMAIL_HOST_PASSWORD

WEBLATE_EMAIL_USE_SSL¶: SMTP サーバと通信するときに、暗黙的な TLS（セキュア）接続を使用するかどうか。多くのメールのドキュメントでは、この種類の TLS 接続を SSL と呼びます。通常はポート 465 で使用されます。問題が発生した場合は、詳細な TLS 設定 WEBLATE_EMAIL_USE_TLS を確認してください。

バージョン 4.11 で変更: SSL/TLS への対応は、WEBLATE_EMAIL_PORT の設定により自動的に有効となります。

参考

WEBLATE_EMAIL_PORT、WEBLATE_EMAIL_USE_TLS、EMAIL_USE_SSL

WEBLATE_EMAIL_USE_TLS¶: SMTP サーバーと通信するときに TLS （セキュア）接続を使用するかどうか。これは、明示的な TLS 接続（通常はポート 587 または 25）で使用します。接続が停止する場合は、暗黙的なTLS設定 (envvar:WEBLATE_EMAIL_USE_SSL）を確認してください。

バージョン 4.11 で変更: SSL/TLS への対応は、WEBLATE_EMAIL_PORT の設定により自動的に有効となります。

参考

WEBLATE_EMAIL_PORT、WEBLATE_EMAIL_USE_SSL、EMAIL_USE_TLS

WEBLATE_EMAIL_BACKEND¶: メール送信に使用する Django バックエンドを設定します。

参考

メールの送信設定、EMAIL_BACKEND

WEBLATE_AUTO_UPDATE¶: Weblate がリポジトリを更新するかどうか、どのように更新するかを設定します。

参考

AUTO_UPDATE

注釈

これは論理値の設定です（"true" または "false" を使用する）。

サイト連携¶

WEBLATE_GET_HELP_URL¶: GET_HELP_URL の設定。

WEBLATE_STATUS_URL¶: STATUS_URL の設定。

WEBLATE_LEGAL_URL¶: LEGAL_URL の設定。

WEBLATE_PRIVACY_URL¶: PRIVACY_URL の設定。

エラーレポートの収集とパフォーマンスの監視¶

インストールから体系的にエラーを収集してください。参照: エラーレポートの収集とパフォーマンスの監視。

Rollbar への対応を有効にする設定方法:

ROLLBAR_KEY¶: Rollbar ポストサーバーへのアクセストークン。

ROLLBAR_ENVIRONMENT¶: Rollbar の環境設定。デフォルトは 運用環境（production）。

Sentry への対応を有効にする設定方法:

SENTRY_DSN¶: Sentry DSN を設定するには、SENTRY_DSN を参照してください。

SENTRY_ENVIRONMENT¶: Sentry の環境設定（オプション）。デフォルトは WEBLATE_SITE_DOMAIN です。

SENTRY_TRACES_SAMPLE_RATE¶

パフォーマンス監視用のサンプリングレートを設定します。すべてのイベントをトレースするには 1 に設定し、トレースを無効にするには 0（デフォルト）に設定します。

例:

environment:
  SENTRY_TRACES_SAMPLE_RATE: 0.5

参考

Sentry パフォーマンス監視、

SENTRY_PROFILES_SAMPLE_RATE¶

プロファイリング監視用のサンプリングレートを設定します。すべてのイベントをトレースするには 1 に設定し、トレースを無効にするには 0（デフォルト）に設定します。

例:

environment:
  SENTRY_PROFILES_SAMPLE_RATE: 0.5

参考

Sentry プロファイリング

SENTRY_SEND_PII¶: SENTRY_SEND_PII を設定します。

CDN の現地化¶

WEBLATE_LOCALIZE_CDN_URL¶

WEBLATE_LOCALIZE_CDN_PATH¶

Added in version 4.2.1.

JavaScript 現地語化 CDN の設定。

WEBLATE_LOCALIZE_CDN_PATH はコンテナ内のパスです。一時ストレージではなく、永続ボリュームに格納することが必要です。

可能性の 1 つとして、それを Weblate データーディレクトリ内に保存する方法:

environment:
  WEBLATE_LOCALIZE_CDN_URL: https://cdn.example.com/
  WEBLATE_LOCALIZE_CDN_PATH: /app/data/l10n-cdn

注釈

Weblate によって生成されたファイルの保存先を設定することが必要です。Weblate は、ファイルを設定した場所に保存するだけです。

参考

Weblate CDN を使用した HTML と JavaScript の翻訳、LOCALIZE_CDN_URL、LOCALIZE_CDN_PATH

有効なアプリ、検査、アドオン、または自動修正の変更¶

組み込まれた有効な品質検査、アドオン、または自動修正を設定する変数:

WEBLATE_ADD_APPS¶

WEBLATE_REMOVE_APPS¶

WEBLATE_ADD_CHECK¶

WEBLATE_REMOVE_CHECK¶

WEBLATE_ADD_AUTOFIX¶

WEBLATE_REMOVE_AUTOFIX¶

WEBLATE_ADD_ADDONS¶

WEBLATE_REMOVE_ADDONS¶

例:

environment:
  WEBLATE_REMOVE_AUTOFIX: weblate.trans.autofixes.whitespace.SameBookendingWhitespace
  WEBLATE_ADD_ADDONS: customize.addons.MyAddon,customize.addons.OtherAddon

参考

CHECK_LIST、AUTOFIX_LIST、WEBLATE_ADDONS、INSTALLED_APPS

コンテナの設定¶

WEBLATE_WORKERS¶

Added in version 4.6.1.

コンテナで実行されているワーカープロセスの基本数。設定しない場合、使用可能な CPU コアの数に基づき、コンテナの起動時に自動的に決定されます。

使用する設定項目 CELERY_MAIN_OPTIONS、CELERY_NOTIFY_OPTIONS、CELERY_MEMORY_OPTIONS、CELERY_TRANSLATE_OPTIONS、CELERY_BACKUP_OPTIONS、CELERY_BEAT_OPTIONS、および WEB_WORKERS。これらの設定を使用して微調整できます。

CELERY_MAIN_OPTIONS¶

CELERY_NOTIFY_OPTIONS¶

CELERY_MEMORY_OPTIONS¶

CELERY_TRANSLATE_OPTIONS¶

CELERY_BACKUP_OPTIONS¶

CELERY_BEAT_OPTIONS¶

これらの変数を使用すると、Celery ワーカーのオプションを変更できます。同時実行性を変更したり（---concurrency 16）、別のプールの実装を使用したり（---pool=gevent）するのに便利です。

デフォルトでは、同時ワーカーの数は WEBLATE_WORKERS に基づきます。

例:

environment:
  CELERY_MAIN_OPTIONS: --concurrency 16

参考

Celery worker options、Celery を使用するバックグラウンドタスク

WEB_WORKERS¶

実行する uWSGI ワーカーの数を設定します。

デフォルトは、WEBLATE_WORKERS です。

例:

environment:
  WEB_WORKERS: 32

WEBLATE_SERVICE¶

コンテナ内で実行するサービスを設定します。これは、水平方向のスケーリングに使用します。

サービスが定義されている項目:

celery-beat: Celery タスクスケジューラでは、実行は、1 つのインスタンスのみにしてください。このコンテナは、データベース構造の移行も行うため、他のコンテナよりも先に起動させてください。
celery-backup: バックアップ用の Celery ワーカー。実行は、1 つのインスタンスのみにしてください。
celery-celery: 一般的な Celery ワーカー。
celery-memory: 翻訳メモリ Celery ワーカー。
celery-notify: 通知 Celery ワーカー。
celery-translate: 自動翻訳 Celery ワーカー。
web: Web サーバー。

Docker コンテナのボリューム¶

Weblate コンテナによってエクスポートされた 2 つのボリューム（データおよびキャッシュ）があります。他のサービスコンテナ（PostgreSQL または Redis）にもデーターボリュームがありますが、そのことについてはこのドキュメントでは説明しません。

データーボリュームは、複製したリポジトリなどの Weblate 永続データを格納したり、Weblate のインストールをカスタマイズするために使用します。

ホストシステム上の Docker ボリュームの配置は Docker 設定によって異なりますが、通常は次の場所に格納されます。/var/lib/docker/volumes/weblate-docker_weblate-data/_data/ （パスは、docker-compose ディレクトリの名前、コンテナ、およびボリューム名で構成される）。コンテナでは、/app/data としてマウントされます。

キャッシュボリュームは、/app/cache としてマウントされ、静的ファイルと CACHE_DIR を保存するために使用します。その内容はコンテナの起動時に再作成され、tmpfs などの一時ファイルシステムを使用してボリュームをマウントできます。

ボリュームを手動で作成する場合、ディレクトリの所有者は UID 1000 であることが必要です。これは、コンテナ内でユーザーが使用するディレクトリです。

参考

Docker ボリュームドキュメント

読み取り専用のルートファイルシステム¶

Added in version 4.18.

読み取り専用のルートファイルを使用してコンテナを実行する場合は、追加で 2 つの tmpfs ボリュームが /tmp と /run に必ず必要です。

環境変数以外の設定¶

Docker 環境変数は、Weblate インストールに関連するほぼすべてのシステム設定の公開が目的です。

環境変数として公開されていない設定を見つけ、その設定が公開されるべきであると考えた場合は、お気軽に Weblate の将来のバージョンで公開されるように依頼してください。

Docker 環境変数として公開されていない設定を変更することが必要な場合でも、データボリュームからの設定のオーバーライドまたは Docker イメージの拡張による設定のオーバーライドを使用して変更できます。

参考

Weblate のカスタマイズ

データボリュームからの設定のオーバーライド¶

ファイルは、/app/data/settings-override.py に作成できます。つまり、データボリュームのルートにあり、環境変数で定義した設定を拡張またはオーバーライドします。

Docker イメージの拡張による設定のオーバーライド¶

データボリュームからではなく、Docker イメージの段階で設定をオーバーライドするには:

Python モジュールの作成。
weblate.settings_docker からすべての設定をインポートするモジュールをパッケージに追加します。

たとえば、Python モジュールの作成で設定されているサンプルのパッケージ構造内で、次の初期コードを使用して weblate_customization/weblate_customization/settings.py にファイルを作成します。作成方法:
```
from weblate.settings_docker import *
```

公式 Weblate Docker イメージから継承するカスタム Dockerfile を作成し、パッケージをインストールして DJANGO_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

公式の Weblate Docker イメージを使用する代わりに、この Dockerfile ファイルからカスタムイメージを作成します。

これを docker-compose.override.yml で行う綺麗な方法はありません。そのファイルの weblate ノードに build: . を追加できますが、カスタムイメージがシステム内で weblate/weblate としてタグ付けされるため、問題が発生することがあります。

そのため、公開リポジトリから直接 docker-compose.yml を変更せずに使用し、それを docker-compose.override.yml を通じて拡張する代わりに、公式の docker-compose.yml ファイルのコピーを作成し、そのコピーを編集して image:weblate/weblate を build: . に置き換えることができます。

docker-compose を使用してソースコードからイメージをビルドする方法の詳細については、Compose ファイルのビルドリファレンスを確認してください。
カスタム設定モジュールを拡張して、設定を定義または再定義します。

上記の import ステートメントの前後に設定を定義して、どの設定を優先するかを決定できます。import ステートメントの前に定義された設定は、環境変数およびデータボリュームで定義された設定のオーバーライドによって上書きできます。import ステートメントの後に定義された設定は上書きできません。

さらに詳細な設定もできます。たとえば、設定を環境変数として公開したり、データボリューム内の Python ファイルからの設定のオーバーライドを許可したりするなど、weblate.docker_settings が行うことを一部再現できます。

ロゴおよびその他の静的ファイルの変更¶

Weblate に付属する静的ファイルは、 /app/data/python/customize/static （参照: Docker コンテナのボリューム）に配置することで変更できます。たとえば、 /app/data/python/customize/static/favicon.ico を作成すると、ファビコンが変更されます。

ヒント

ファイルはコンテナの起動時に対応する場所にコピーされるため、ボリュームの内容を変更した後にWeblate を再起動させてください。

この方法は、Weblate テンプレートの変更にも使用できます。たとえば、法的文書ドキュメントは /app/data/python/customize/templates/legal/documents に配置できます。

あるいは、独自のモジュール（参照: ../ customize）を含め、個別のボリュームとして Docker コンテナに追加できます。例:

weblate:
  volumes:
    - weblate-data:/app/data
    - ./weblate_customization/weblate_customization:/app/data/python/weblate_customization
  environment:
    WEBLATE_ADD_APPS: weblate_customization

PostgreSQL サーバーの設定¶

PostgreSQL コンテナは、デフォルトの PostgreSQL 設定を使用するため、CPU コアやメモリを効果的に使用できません。性能を向上させるために設定を変更してください。

設定は、https://hub.docker.com/_/postgres のデータベースの設定の説明に従って変更できます。環境に一致する設定は、https://pgtune.leopard.in.ua/ を使用して生成できます。

コンテナ内部¶

コンテナは supervisor を使用して個々のサービスを開始しています。水平方向のスケーリングの場合、コンテナ内の単一サービスのみを開始します。

サービスのステータスを確認する方法:

docker compose exec --user weblate weblate supervisorctl status

Celery キューごとに個別のサービスがあります（詳細参照: Celery を使用するバックグラウンドタスク）。適切なワーカーを停止することで、一部のタスクの処理を停止できます。

docker compose exec --user weblate weblate supervisorctl stop celery-translate

Docker を使用したインストール¶

ハードウェア要件¶

Memory usage¶

CPU usage¶

Storage usage¶

Nodes¶

インストール¶

Docker イメージ レジストリの選択¶

Docker イメージ タグの選択¶

HTTPS に対応した Docker コンテナ¶

独自の SSL 証明書の使用¶

Let's Encrypt による自動 SSL 証明書の発行¶

Docker コンテナーのアップグレード¶

PostgreSQL コンテナのアップグレード¶

管理者としてサイン イン¶

プロセス数とメモリ消費量¶

水平方向のスケーリング¶

Docker 環境変数¶

シークレットの受け渡し¶

一般的な設定¶

サイトの資格情報をホストするコード¶

自動提案の設定¶

認証設定¶

LDAP¶

GitHub¶

GitHub エンタープライズ版¶

Bitbucket¶

Facebook¶

Google¶

GitLab¶

Gitea¶

Azure Active Directory¶

Azure Active Directory with Tenant support¶

Keycloak¶

Linux ベンダー¶

Slack¶

OpenID Connect¶

SAML¶

その他の認証設定¶

PostgreSQL データベースの設定¶

MySQL または MariaDB サーバー¶

データベースのバックアップ設定¶

キャッシュ サーバーの設定¶

メールサーバーの設定¶

サイト連携¶

エラーレポートの収集とパフォーマンスの監視¶

CDN の現地化¶

有効なアプリ、検査、アドオン、または自動修正の変更¶

コンテナの設定¶

Docker コンテナのボリューム¶

読み取り専用のルート ファイルシステム¶

環境変数以外の設定¶

データ ボリュームからの設定のオーバーライド¶

Docker イメージの拡張による設定のオーバーライド¶

ロゴおよびその他の静的ファイルの変更¶

PostgreSQL サーバーの設定¶

コンテナ内部¶

Docker イメージレジストリの選択¶

Docker イメージタグの選択¶

管理者としてサインイン¶

キャッシュサーバーの設定¶

読み取り専用のルートファイルシステム¶

データボリュームからの設定のオーバーライド¶