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

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

ハードウェア要件

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

  • 2 GB の RAM

  • 2 CPU コア

  • 1 GB の記憶容量(HDD or SSD)

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

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

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

注釈

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

インストール

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

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

    git clone https://github.com/WeblateOrg/docker-compose.git weblate-docker
    cd weblate-docker
    
  2. 設定した内容で docker-compose.override.yml ファイルを作成する(環境変数の完全なリストについては、:ref:'docker-environment' を確認すること):

    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 ファイルのポート マッピングを編集してください。

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

すでに、同じサーバー上の他のサイトをホストしている場合は、ポート 80443 が 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 つです。

  1. Weblate コンテナの停止:

    docker-compose stop weblate cache
    
  2. データベースのバックアップ:

    docker-compose exec database pg_dumpall --clean --username weblate > backup.sql
    
  3. データベース コンテナの停止:

    docker-compose stop database
    
  4. PostgreSQL ボリュームの削除:

    docker-compose rm -v database
    docker volume remove weblate_postgres-data
    
  5. 新しい PostgreSQL のバージョンを使用するように :file:`docker-compose.yml`を編集します。

  6. データベース コンテナの起動:

    docker-compose up -d database
    
  7. データベースをバックアップから復元:

    cat backup.sql | docker-compose exec -T database psql --username weblate --dbname postgres
    
  8. 残りのコンテナをすべて起動:

    docker-compose up -d
    

管理者としてサイン イン

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

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

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

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

水平方向のスケーリング

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

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

WEBLATE_ADMIN_NAME
WEBLATE_ADMIN_EMAIL

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

例:

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

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

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

  • 管理者 パスワードが設定されておらず、管理者 ユーザーが存在する場合、管理者 パスワードは設定されません。

  • 管理者 パスワードが設定されている場合、管理者 ユーザーは、コンテナが起動するたびに WEBLATE_ADMIN_PASSWORDWEBLATE_ADMIN_NAME および WEBLATE_ADMIN_EMAIL に設定されます。

警告

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

WEBLATE_ADMIN_PASSWORD_FILE

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

WEBLATE_SERVER_EMAIL

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

WEBLATE_DEFAULT_FROM_EMAIL

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

WEBLATE_CONTACT_FORM

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

WEBLATE_ALLOWED_HOSTS

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

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

例:

environment:
  WEBLATE_ALLOWED_HOSTS: weblate.example.com,example.com
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_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
WEBLATE_INTERLEDGER_PAYMENT_POINTERS

バージョン 4.12.1 で追加.

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

WEBLATE_IP_PROXY_HEADER

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

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

注釈

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

  • すべての文字を大文字に変換する

  • ハイフンをアンダースコアに置き換える

  • HTTP_ 接頭辞の追加

したがって、X-Forwarded-ForHTTP_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
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 を追加します。

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

WEBLATE_GOOGLE_ANALYTICS_ID

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

WEBLATE_GITHUB_USERNAME
WEBLATE_GITHUB_TOKEN
WEBLATE_GITHUB_HOST

GITHUB_CREDENTIALSWEBLATE_GITHUB_HOST が設定されている場合)、または GITHUB_USERNAME および GITHUB_TOKEN を変更し、GitHub をプルリクエストの統合に設定します。

WEBLATE_GITLAB_USERNAME
WEBLATE_GITLAB_TOKEN
WEBLATE_GITLAB_HOST

GITLAB_CREDENTIALSWEBLATE_GITLAB_HOST が設定されている場合)、または GITLAB_USERNAME および GITLAB_TOKEN を変更し、GitLab をマージリクエストの統合に設定します。

WEBLATE_GITEA_USERNAME
WEBLATE_GITEA_TOKEN
WEBLATE_GITEA_HOST

GITEA_CREDENTIALSWEBLATE_GITEA_HOST が設定されている場合)、または GITEA_USERNAME および GITEA_TOKEN を変更し、Gitea をプルリクエストの統合に設定します。

WEBLATE_PAGURE_USERNAME
WEBLATE_PAGURE_TOKEN
WEBLATE_PAGURE_HOST

PAGURE_CREDENTIALSWEBLATE_PAGURE_HOST が設定されている場合)、または PAGURE_USERNAME および PAGURE_TOKEN を変更し、Pagure をマージリクエストの統合に設定します。

WEBLATE_DEFAULT_PULL_MESSAGE

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

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

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 ヘッダーの変更を可能にします。

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_ 接頭辞を追加します。

WEBLATE_API_RATELIMIT_ANON
WEBLATE_API_RATELIMIT_USER

バージョン 4.11 で追加.

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

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 を設定します。

自動提案の設定

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

一般的な 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 の両方のコンテナに影響を与えます。

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
POSTGRES_DISABLE_SERVER_SIDE_CURSORS

バージョン 4.9.1 で追加.

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

設定例:

environment:
    POSTGRES_DISABLE_SERVER_SIDE_CURSORS: 1

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

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

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

参考

EMAIL_PORT

WEBLATE_EMAIL_HOST_USER

メール認証ユーザー。

WEBLATE_EMAIL_HOST_PASSWORD

メール認証のパスワード。

WEBLATE_EMAIL_HOST_PASSWORD_FILE

メール認証用パスワードを含むファイルへのパス。

WEBLATE_EMAIL_USE_SSL

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

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

WEBLATE_EMAIL_USE_TLS

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

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

WEBLATE_EMAIL_BACKEND

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

WEBLATE_AUTO_UPDATE

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

参考

AUTO_UPDATE

注釈

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

サイト統合

WEBLATE_GET_HELP_URL

GET_HELP_URL の設定。

WEBLATE_STATUS_URL

STATUS_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 は、ファイルを設定した場所に保存するだけです。

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

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

コンテナの設定

WEBLATE_WORKERS

バージョン 4.6.1 で追加.

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

使用する設定項目 CELERY_MAIN_OPTIONSCELERY_NOTIFY_OPTIONSCELERY_MEMORY_OPTIONSCELERY_TRANSLATE_OPTIONSCELERY_BACKUP_OPTIONSCELERY_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
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 としてマウントされ、静的ファイルの格納に使用されます。その内容はコンテナの起動時に再作成され、tmpfs などの一時ファイルシステムを使用してボリュームをマウントできます。

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

環境変数以外の設定

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

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

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

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

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

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

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

  1. Python モジュールの作成

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

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

    from weblate.settings_docker import *
    
  3. 公式 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
    
  4. 公式の Weblate Docker イメージを使用する代わりに、この Dockerfile ファイルからカスタム イメージを作成します。

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

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

    docker-compose を使用してソースコードからイメージをビルドする方法の詳細については、Compose ファイルのビルド リファレンス を確認してください。

  5. カスタム設定モジュールを拡張して、設定を定義または再定義します。

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

    さらに詳細な設定もできます。たとえば、設定を環境変数として公開したり、データ ボリューム内の 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