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 で管理する翻訳のサイズによって大きく変化します。
インストール#
The following examples assume you have a working Docker environment, with
docker-compose-plugin
installed. Please check the Docker documentation for instructions.
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 からアクセスできます。
バージョン 3.7.1-6 で変更: 2019 年 7 月(3.7.1-6 タグ以降)、コンテナは root ユーザーとしては実行されていません。これにより、公開ポートが 80 から 8080 に変更されました。
参考
Choosing Docker image registry#
Weblate containers are published to following registries:
Docker Hub, see https://hub.docker.com/r/weblate/weblate
GitHub Packages registry, see https://github.com/WeblateOrg/docker/pkgs/container/weblate
注釈
All examples currently fetch images from Docker Hub, please adjust the configuration accordingly to use a different registry.
Choosing Docker image tag#
Please choose a tag that matches your environment and expectations:
タグ名 |
説明 |
使用例 |
---|---|---|
|
Weblate 安定版リリース、最新のタグ付きリリースに対応 |
運用環境でのローリング アップデート |
|
Weblate 安定版のリリース |
運用環境での明確な展開 |
|
Docker コンテナに開発上の変更を加えた Weblate 安定版のリリース(例: 依存関係の更新など) |
ステージング環境でのローリング アップデート |
|
Docker コンテナに開発上の変更を加えた Weblate 安定版のリリース(例: 依存関係の更新など) |
ステージング環境での明確な展開 |
|
Git から開発版の Weblate |
今後の Weblate の機能をテストするためのローリング アップデート |
|
Git から開発版の Weblate |
Weblate の新機能をテストするための明確な展開 |
すべてのイメージは、公開される前に CI によってテストされるため、bleeding 版であっても安全に使用できます。
Full list of published tags acan be found at GitHub Packages
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'
Whenever invoking docker compose you need to pass both files to it, and then do:
docker compose -f docker-compose-https.yml -f docker-compose-https.override.yml build
docker compose -f docker-compose-https.yml -f docker-compose-https.override.yml up
Docker コンテナーのアップグレード#
通常は、Weblate コンテナのみを更新し、PostgreSQL コンテナは現在のバージョンを維持してください。PostgreSQL のアップグレードは非常に面倒であり、多くの場合あまり効果は期待できません。
バージョン 4.17-1 で変更: Since Weblate 4.17-1, the Docker container uses Django 4.2 what requires PostgreSQL 12 or newer, please upgrade it prior to upgrading Weblate. See 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 --if-exists --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 weblate
ヒント
Please check that the database name matches
POSTGRES_DATABASE
.(オプション)Weblate ユーザーのパスワードを更新させる。これは、パスワードの保存方法が変更されたため、PostgreSQL 14 または 15 に移行するときに必要となる場合の方法:
docker compose exec -T database psql --username weblate --dbname weblate -c "ALTER USER weblate WITH PASSWORD 'weblate'"
ヒント
Please check that the database name matches
POSTGRES_DATABASE
.残りのコンテナをすべて起動:
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#
Configures the logging verbosity. Set this to
DEBUG
to get more detailed logs.Defaults to
INFO
whenWEBLATE_DEBUG
is turned off,DEBUG
is used when debug mode is turned on.
- 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 で追加.
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#
GITHUB_CREDENTIALS
を変更して、GitHub プルリクエストの連携を設定します。
- WEBLATE_GITLAB_USERNAME#
- WEBLATE_GITLAB_TOKEN#
- WEBLATE_GITLAB_HOST#
GITLAB_CREDENTIALS
を変更して、GitLab マージ リクエストの連携を設定します。例:
WEBLATE_GITLAB_USERNAME=weblate WEBLATE_GITLAB_HOST=gitlab.com WEBLATE_GITLAB_TOKEN=token
- WEBLATE_GITEA_USERNAME#
- WEBLATE_GITEA_TOKEN#
- WEBLATE_GITEA_HOST#
GITEA_CREDENTIALS
を変更して、Gitea プルリクエストの連携を設定します。
- WEBLATE_PAGURE_USERNAME#
- WEBLATE_PAGURE_TOKEN#
- WEBLATE_PAGURE_HOST#
PAGURE_CREDENTIALS
を変更して、Pagure マージリクエストの連携を設定します。
- WEBLATE_BITBUCKETSERVER_USERNAME#
- WEBLATE_BITBUCKETSERVER_TOKEN#
- WEBLATE_BITBUCKETSERVER_HOST#
BITBUCKETSERVER_CREDENTIALS
を変更して、Bitbucket Server プルリクエストの連携を設定します。
- 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_UNUSED_ALERT_DAYS#
バージョン 4.17 で追加.
UNUSED_ALERT_DAYS
の設定。
- WEBLATE_CORS_ALLOWED_ORIGINS#
バージョン 4.16 で追加.
指定したオリジンからの CORS 要求を許可します。
例:
environment: WEBLATE_CORS_ALLOWED_ORIGINS: https://example.com,https://weblate.org
- CLIENT_MAX_BODY_SIZE#
バージョン 4.16.3 で追加.
内蔵の Web サーバーにアップロードできるファイルの最大サイズを設定します。
environment: CLIENT_MAX_BODY_SIZE: 200m
ヒント
この変数は、Let's Encrypt による自動 SSL 証明書の発行 で使用されるサードパーティのコンテナーと共有されるため、意図的に
WEBLATE_
接頭辞がありません。
自動提案の設定#
バージョン 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#
GitHub Enterprise Edition#
- WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_KEY#
- WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_SECRET#
- WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_URL#
- WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_API_URL#
- WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_SCOPE#
Enables GitHub EE authentication.
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_OPENINFRA#
- 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#
Your Sentry Environment (optional), defaults to
WEBLATE_SITE_DOMAIN
.
- SENTRY_TRACES_SAMPLE_RATE#
Confgure sampling rate for performance monitoring. Set to 1 trace all events, 0 (the default) disables tracing.
例:
environment: SENTRY_TRACES_SAMPLE_RATE: 0.5
- SENTRY_PROFILES_SAMPLE_RATE#
Confgure sampling rate for profiling monitoring. Set to 1 trace all events, 0 (the default) disables tracing.
例:
environment: SENTRY_PROFILES_SAMPLE_RATE: 0.5
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
としてマウントされ、静的ファイルと CACHE_DIR
を保存するために使用します。その内容はコンテナの起動時に再作成され、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 サーバーの設定#
PostgreSQL コンテナは、デフォルトの PostgreSQL 設定を使用するため、CPU コアやメモリを効果的に使用できません。性能を向上させるために設定を変更してください。
設定は、https://hub.docker.com/_/postgres の データベースの設定 の説明に従って変更できます。環境に一致する設定は、https://pgtune.leopard.in.ua/ を使用して生成できます。
コンテナ内部#
コンテナは supervisor を使用して個々のサービスを開始しています。水平方向のスケーリング の場合、コンテナ内の単一サービスのみを開始します。
サービスのステータスを確認する方法:
docker compose exec --user weblate weblate supervisorctl status
Celery キューごとに個別のサービスがあります(詳細参照: Celery を使用するバックグラウンド タスク)。適切なワーカーを停止することで、一部のタスクの処理を停止できます。
docker compose exec --user weblate weblate supervisorctl stop celery-translate