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

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

ハードウェア要件

Weblate は、最新のハードウェアであれば問題なく動作します。以下は、Weblate を単一のホスト（Weblate、データベース、Web サーバー）で動作させるために必要な最小限の構成:

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

メモリは多ければ多いほど良い - すべてのレベル（ファイルシステム、データベース、Weblate）でキャッシュとして使用します。

同時使用者が多い場合、必要な CPU コアの数が増えます。数百の翻訳コンポーネントを使用する場合は、少なくとも 4 GB の RAM が必要です。

一般的なデータベースストレージの使用量は、ホストサーバーで管理する 100 万語の単語につき約 300 MB 必要です。リポジトリのクローンに必要なストレージスペースはさまざまですが、Weblate は、シャロークローンを実行してサイズを最小限に抑える努力をします。

注釈

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

インストール

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

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 からアクセスできます。

バージョン 2.15-2 で変更: 最近、設定が変更され、以前は Web サーバーは独立したコンテナでしたが、2.15-2 以降では Web サーバーは Weblate コンテナに組み込まれています。

バージョン 3.7.1-6 で変更: 2019 年 7 月（3.7.1-6 タグ以降）、コンテナは root ユーザーとしては実行されていません。これにより、公開ポートが 80 から 8080 に変更されました。

参考

管理コマンドの起動

Docker ハブタグの選択

Docker ハブでは、次のタグを使用できますが、使用可能なタグの完全なリストについては、https://hub.docker.com/r/weblate/weblate/tags/ を確認してください。

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

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

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

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

独自の SSL 証明書の使用

バージョン 3.8-3 で追加.

使用したい独自の 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;
    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>;
    }
}

<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.10-1 で変更: Weblate 4.10-1 以降の Docker コンテナーは、PostgreSQL 10 以降が必要な Django 4.0 を使用するため、Weblate をアップグレードする前に PostgreSQL コンテナのアップグレードをしてください。参照: 4.9 から 4.10 にアップグレードおよび 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 --username weblate > backup.sql

データベースコンテナの停止:
```
docker-compose stop database
```

PostgreSQL ボリュームの削除:

docker-compose rm -v database
docker volume remove weblate-docker_postgres-data

新しい PostgreSQL のバージョンを使用するように :file:`docker-compose.yml`を編集します。
データベースコンテナの起動:
```
docker-compose up -d database
```

データベースをバックアップから復元:

cat backup.sql | docker-compose exec -T database psql --username weblate --dbname postgres

（オプション）Weblate ユーザーのパスワードを更新させる。これは、パスワードの保存方法が変更されたため、PostgreSQL 14 または 15 に移行するときに必要となる場合の方法:
```
docker-compose exec -T database psql --username weblate --dbname postgres -c "ALTER USER weblate WITH PASSWORD 'weblate'"
```
残りのコンテナをすべて起動:
```
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

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

バージョン 4.6 で追加.

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

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

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

Docker 環境変数

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

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

一般的な設定

WEBLATE_DEBUG

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

例:

environment:
  WEBLATE_DEBUG: 1

参考

デバッグモードの無効化

WEBLATE_LOGLEVEL: ログの冗長性を設定します。

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_PASSWORD_FILE、WEBLATE_ADMIN_NAME、WEBLATE_ADMIN_EMAIL

WEBLATE_ADMIN_PASSWORD_FILE: 管理者ユーザーのパスワードを含むファイルへのパスを設定します。

参考

WEBLATE_ADMIN_PASSWORD

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

参考

SERVER_EMAIL、メールの送信設定

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

参考

DEFAULT_FROM_EMAIL、メールの送信設定

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: バージョン 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: バージョン 4.12.1 で追加.

Weblate でドキュメントの先頭に `meta[name=monatezation] ` フィールドを設定します。複数指定した場合は、ランダムに 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_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 変数を使用してデフォルト値を変更できます。

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

WEBLATE_GITHUB_USERNAME

WEBLATE_GITHUB_TOKEN

WEBLATE_GITHUB_HOST: GITHUB_CREDENTIALS を変更して、GitHub プルリクエストの連携を設定します。

参考

GitHub プルリクエスト

WEBLATE_GITLAB_USERNAME

WEBLATE_GITLAB_TOKEN

WEBLATE_GITLAB_HOST: GITLAB_CREDENTIALS を変更して、GitLab マージリクエストの連携を設定します。

参考

GitLab マージリクエスト

WEBLATE_GITEA_USERNAME

WEBLATE_GITEA_TOKEN

WEBLATE_GITEA_HOST: GITEA_CREDENTIALS を変更して、Gitea プルリクエストの連携を設定します。

参考

Gitea プルリクエスト

WEBLATE_PAGURE_USERNAME

WEBLATE_PAGURE_TOKEN

WEBLATE_PAGURE_HOST: PAGURE_CREDENTIALS を変更して、Pagure マージリクエストの連携を設定します。

参考

Pagure マージリクエスト

WEBLATE_BITBUCKETSERVER_USERNAME

WEBLATE_BITBUCKETSERVER_TOKEN

WEBLATE_BITBUCKETSERVER_HOST: BITBUCKETSERVER_CREDENTIALS を変更して、Bitbucket Server プルリクエストの連携を設定します。

参考

Bitbucket Server プルリクエスト

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: バージョン 4.6 で追加.

接続制限を設定します。

ヒント

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

参考

接続制限、RATELIMIT_ATTEMPTS、RATELIMIT_WINDOW、RATELIMIT_LOCKOUT

WEBLATE_API_RATELIMIT_ANON

WEBLATE_API_RATELIMIT_USER: バージョン 4.11 で追加.

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

参考

API 接続制限

WEBLATE_ENABLE_HOOKS: バージョン 4.13 で追加.

ENABLE_HOOKS を設定します。

WEBLATE_ENABLE_AVATARS: バージョン 4.6.1 で追加.

ENABLE_AVATARS を設定します。

WEBLATE_AVATAR_URL_PREFIX: バージョン 4.15 で追加.

AVATAR_URL_PREFIX の設定。

WEBLATE_LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH: バージョン 4.9 で追加.

LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH を設定します。

WEBLATE_SSH_EXTRA_ARGS: バージョン 4.9 で追加.

SSH_EXTRA_ARGS を設定します。

WEBLATE_BORG_EXTRA_ARGS: バージョン 4.9 で追加.

BORG_EXTRA_ARGS を設定します。

WEBLATE_ENABLE_SHARING: バージョン 4.14.1 で追加.

ENABLE_SHARING を設定します。

WEBLATE_EXTRA_HTML_HEAD: バージョン 4.15 で追加.

EXTRA_HTML_HEAD を設定します。

WEBLATE_PRIVATE_COMMIT_EMAIL_TEMPLATE: バージョン 4.15 で追加.

PRIVATE_COMMIT_EMAIL_TEMPLATE を設定します。

WEBLATE_PRIVATE_COMMIT_EMAIL_OPT_IN: バージョン 4.15 で追加.

PRIVATE_COMMIT_EMAIL_OPT_IN を設定します。

WEBLATE_CORS_ALLOWED_ORIGINS

バージョン 4.16 で追加.

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

例:

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

自動提案の設定

バージョン 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_BIND_PASSWORD_FILE: LDAP サーバーにバインドするためのパスワードを含むファイルへのパス。

参考

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

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_UBUNTU

Slack

WEBLATE_SOCIAL_AUTH_SLACK_KEY

SOCIAL_AUTH_SLACK_SECRET: Slack 認証を有効にします。参照: Slack。

OpenID Connect

バージョン 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.

参考

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_NO_EMAIL_AUTH: 値を設定すると、メール認証を無効にします。参照: パスワード認証の無効化。

PostgreSQL データベースの設定

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

参考

Weblate のデータベース設定

POSTGRES_PASSWORD: PostgreSQL のパスワード。

POSTGRES_PASSWORD_FILE: PostgreSQL パスワードを含むファイルへのパス。POSTGRES_PASSWORD の代わりに使用します。

POSTGRES_USER: PostgreSQL ユーザー名。

POSTGRES_DATABASE: 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

バージョン 4.8.1 で追加.

データベース接続の有効時間を、整数で秒単位を指定します。各リクエストの終了時にデータベース接続を閉じるには、0 を指定します（これがデフォルトの動作）。

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

設定例:

environment:
    POSTGRES_CONN_MAX_AGE: 3600

参考

CONN_MAX_AGE、Persistent connections

POSTGRES_DISABLE_SERVER_SIDE_CURSORS

バージョン 4.9.1 で追加.

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

設定例:

environment:
    POSTGRES_DISABLE_SERVER_SIDE_CURSORS: 1

参考

DISABLE_SERVER_SIDE_CURSORS、Transaction pooling and server-side cursors

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

参考

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

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_PASSWORD_FILE: Redis サーバーのパスワードを含むファイルへのパス。

参考

REDIS_PASSWORD

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_HOST_PASSWORD_FILE: メール認証用パスワードを含むファイルへのパス。

参考

WEBLATE_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_ENVIRONMENT: Sentry の環境設定（オプション）。

CDN の現地化

WEBLATE_LOCALIZE_CDN_URL

WEBLATE_LOCALIZE_CDN_PATH

バージョン 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

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

バージョン 3.8-5 で追加.

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

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

バージョン 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 ボリュームドキュメント

環境変数以外の設定

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 ファイルのビルドリファレンスを確認してください。
カスタム設定モジュールを拡張して、設定を定義または再定義します。

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.

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

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

バージョン 3.8-5 で追加.

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

ヒント

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

この方法は、Weblate テンプレートの変更にも使用できます。例: legal`ドキュメントは、:file:/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 サーバーの設定

PostgtreSQL コンテナは、デフォルトの 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 を使用したインストール

ハードウェア要件

インストール

Docker ハブ タグの選択

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

独自の SSL 証明書の使用

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

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

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

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

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

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

Docker 環境変数

一般的な設定

自動提案の設定

認証設定

LDAP

GitHub

Bitbucket

Facebook

Google

GitLab

Gitea

Azure Active Directory

Azure Active Directory with Tenant support

Keycloak

Linux ベンダー

Slack

OpenID Connect

SAML

その他の認証設定

PostgreSQL データベースの設定

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

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

メールサーバーの設定

サイト連携

エラーの報告

CDN の現地化

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

コンテナの設定

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

環境変数以外の設定

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

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

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

PostgreSQL サーバーの設定

コンテナ内部

Docker ハブタグの選択

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

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

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