Docker を使用したインストール
Docker 化された Weblate デプロイでは、数秒で個人の Weblate インスタンスを起動して実行できます。Weblate の依存関係はすべて含まれています。PostgreSQL が、デフォルト データベースとして設定されています。
ハードウェア要件
Weblate は、最新のハードウェアであれば問題なく動作します。以下は、Weblate を単一のホスト(Weblate、データベース、Web サーバー)で動作させるために必要な最小限の構成:
3 GB of 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/ を確認してください。
タグ名 |
説明 |
使用例 |
---|---|---|
|
Weblate 安定版リリース、最新のタグ付きリリースに対応 |
運用環境でのローリング アップデート |
|
Weblate 安定版のリリース |
運用環境での明確な展開 |
|
Docker コンテナに開発上の変更を加えた Weblate 安定版のリリース(例: 依存関係の更新など) |
ステージング環境でのローリング アップデート |
|
Docker コンテナに開発上の変更を加えた Weblate 安定版のリリース(例: 依存関係の更新など) |
ステージング環境での明確な展開 |
|
Git から開発版の Weblate |
今後の Weblate の機能をテストするためのローリング アップデート |
|
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 つです。
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
(Optional) Update password for the Weblate user. This might be needed when migrating to PostgreSQL 14 or 15 as way of storing passwords has been changed:
docker-compose exec -T database psql --username weblate --dbname postgres -c "ALTER USER weblate WITH PASSWORD 'weblate'"
残りのコンテナをすべて起動:
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_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_PASSWORD
、WEBLATE_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_REGISTRATION_REBIND
バージョン 4.16 で追加.
Configures
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
- 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-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
- 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
Configures GitHub pull-requests integration by changing
GITHUB_CREDENTIALS
.
- WEBLATE_GITLAB_USERNAME
- WEBLATE_GITLAB_TOKEN
- WEBLATE_GITLAB_HOST
Configures GitLab merge-requests integration by changing
GITLAB_CREDENTIALS
.
- WEBLATE_GITEA_USERNAME
- WEBLATE_GITEA_TOKEN
- WEBLATE_GITEA_HOST
Configures Gitea pull-requests integration by changing
GITEA_CREDENTIALS
.
- WEBLATE_PAGURE_USERNAME
- WEBLATE_PAGURE_TOKEN
- WEBLATE_PAGURE_HOST
Configures Pagure merge-requests integration by changing
PAGURE_CREDENTIALS
.
- WEBLATE_BITBUCKETSERVER_USERNAME
- WEBLATE_BITBUCKETSERVER_TOKEN
- WEBLATE_BITBUCKETSERVER_HOST
Configures Bitbucket Server pull-requests integration by changing
BITBUCKETSERVER_CREDENTIALS
.
- WEBLATE_DEFAULT_PULL_MESSAGE
PAGURE_TOKEN
を変更して、API 経由の Pagure のプルリクエストに対して、Pagure の個人用アクセス トークンを設定する。
- WEBLATE_SIMPLIFY_LANGUAGES
言語簡略化ポリシーを設定します。参照:
SIMPLIFY_LANGUAGES
。
- 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 で追加.
- 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 で追加.
Allow CORS requests from given origins.
例:
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_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)
参考
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
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
Linux ベンダー
Linux ベンダー認証サービスを使用した認証を有効にするには、以下の変数を指定の値に設定します。
- WEBLATE_SOCIAL_AUTH_FEDORA
- WEBLATE_SOCIAL_AUTH_OPENSUSE
- WEBLATE_SOCIAL_AUTH_UBUNTU
Slack
- WEBLATE_SOCIAL_AUTH_SLACK_KEY
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_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。
参考
- 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 がリポジトリを更新するかどうか、どのように更新するかを設定します。
参考
注釈
これは論理値の設定です(
"true"
または"false"
を使用する)。
サイト統合
- WEBLATE_GET_HELP_URL
GET_HELP_URL
の設定。
- WEBLATE_STATUS_URL
STATUS_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_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
- 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
としてマウントされます。
The cache volume is mounted as /app/cache
and is used to store static
files and CACHE_DIR
. Its content is recreated on container startup
and the volume can be mounted using ephemeral filesystem such as tmpfs.
ボリュームを手動で作成する場合、ディレクトリの所有者は UID 1000 であることが必要です。これは、コンテナ内でユーザーが使用するディレクトリです。
環境変数以外の設定
Docker 環境変数 は、Weblate インストールに関連するほぼすべての システム設定 の公開が目的です。
環境変数として公開されていない設定を見つけ、その設定が公開されるべきであると考えた場合は、お気軽に Weblate の将来のバージョンで公開されるように依頼 してください。
Docker 環境変数として公開されていない設定を変更することが必要な場合でも、データ ボリュームからの設定のオーバーライド または Docker イメージの拡張による設定のオーバーライド を使用して変更できます。
データ ボリュームからの設定のオーバーライド
ファイルは、/app/data/settings-override.py
に作成できます。つまり、データ ボリューム のルートにあり、環境変数で定義した設定を拡張またはオーバーライドします。
Docker イメージの拡張による設定のオーバーライド
データ ボリュームからではなく、Docker イメージの段階で設定をオーバーライドするには:
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
が行うことを一部 再現 できます。
ロゴおよびその他の静的ファイルの変更
バージョン 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