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 のドキュメントを確認してください。
weblate-docker リポジトリのクローンの作成:
git clone https://github.com/WeblateOrg/docker-compose.git weblate-docker cd weblate-docker
設定した内容で
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
ファイルのポート マッピングを編集してください。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_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
残りのコンテナをすべて起動:
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 コンテナに設定できます。
一般的な設定
- 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_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
GITHUB_USERNAME
を変更して、GitHub プルリクエストの GitHub ユーザー名を設定します。
- WEBLATE_GITHUB_TOKEN
バージョン 4.3 で追加.
GITHUB_TOKEN
を変更して、API を介した GitHub プルリクエストの GitHub 個人用アクセス トークンを設定します。
- WEBLATE_GITLAB_USERNAME
GITLAB_USERNAME
を変更して、GitLabマージ要求のGitLabユーザー名を構成します。
- WEBLATE_GITLAB_TOKEN
GITLAB_TOKEN
を変更して、API を介した GitLab マージリクエストの GitLab 個人用アクセス トークンを設定します。
- WEBLATE_PAGURE_USERNAME
PAGURE_USERNAME
を変更して、Pagure merge-requests 用の Pagure ユーザー名を設定する。
- WEBLATE_PAGURE_TOKEN
PAGURE_TOKEN
を変更して、API 経由の Pagure のマージリクエストに対して、Pagure の個人用アクセス トークンを設定する。
- 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 で追加.
Configures
ENABLE_HOOKS
.
- WEBLATE_ENABLE_AVATARS
バージョン 4.6.1 で追加.
ENABLE_AVATARS
を設定します。
- 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
を設定します。
自動提案の設定
バージョン 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 を有効にします。
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
Configures generic OpenID Connect intergration.
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
としてマウントされます。
キャッシュ ボリュームは、/app/cache
としてマウントされ、静的ファイルの格納に使用されます。その内容はコンテナの起動時に再作成され、tmpfs などの一時ファイルシステムを使用してボリュームをマウントできます。
ボリュームを手動で作成する場合、ディレクトリの所有者は UID 1000 であることが必要です。これは、コンテナ内でユーザーが使用するディレクトリです。
詳細な設定のカスタマイズ
データー ボリュームでの Weblate インストールを詳細にカスタマイズできます。参照: Docker コンテナのボリューム。
カスタム設定ファイル
/app/data/settings-override.py
内の設定を追加で上書きできます(参照: Docker コンテナのボリューム)。これは、すべての環境設定が読み込まれた後、組み込み設定の最後に実行され、それらを変更または上書きできます。
ロゴおよびその他の静的ファイルの変更
バージョン 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
独自の Python モジュールの追加
バージョン 3.8-5 で追加.
独自の Python モジュールを /app/data/python/`(参照: :ref:`docker-volume
)に配置し、Weblate から読み込めます。多くの場合、カスタム設定ファイル を使用します。
PostgreSQL サーバーの設定
PostgtreSQL コンテナは、デフォルトの PostgreSQL 設定を使用するため、CPU コアやメモリを効果的に使用できません。性能を向上させるために設定を変更してください。
設定は、https://hub.docker.com/_/postgres の データベースの設定 の説明に従って変更できます。環境に一致する設定は、https://pgtune.leopard.in.ua/ を使用して生成できます。