設定:Configuration

Virtual Channelの設定は環境変数を使用して行います。Virtual Channelのルートフォルダに含まれる`.env` ファイルには、利用可能なすべての設定オプションがリストされており、デフォルト値とその意味の簡単な説明が記載されています。

シェル環境に設定された値は、.env ファイルに設定された値を上書きします。これは、必要に応じて設定をカスタマイズするための推奨される方法です。

セキュリティ(Security)

Virtual Channelに慣れるためだけの場合は、信頼できるテスト環境で行う場合は、このセクションを一時的にスキップできます。ただし、本番環境でVirtual Channelを使用する前、またはサービスを公開エンドポイントで公開する前、または一般的に信頼できないクライアントにさらされる可能性のある環境で使用する前に、このセクションを読む必要があります。

APIキー認証(API Key authorization)

Virtual ChannelのAPIエンドポイントへのアクセスは、任意のクライアントに許可することも、認証ヘッダーでAPIキーを提供するクライアントに制限することもできます。これらのアクセス制限を有効/無効にするには、2つのシェル環境変数に対して操作を行うことができます。

  • API_KEY

  • API_INSECURE

安全ではない制限のないAPIモードを有効にするには、シェルに以下を設定する必要があります。

  • API_KEY: 未設定または空

  • API_INSECURE: 未設定または空

Warning

上記の意味に注意してください。デフォルトでこれらの変数を設定しない場合、Virtual Channel APIは安全でない制限の無いモードで開始されます!

APIキー認証を有効にするには、シェルに以下を設定します。

  • API_KEY:生成したキーに設定します (即ち export API_KEY=<my_key>)

  • API_INSECURE:Falseに設定します (即ち export API_INSECURE=False)

APIキー認証が有効になると、クライアントはHTTPリクエストに追加のヘッダーを追加する必要があります。

USP-API-KEY: <my_key>

たとえば、cURLを使用して、認証が有効になっている有効なリクエストは次のようになります。

curl -H "USP-API-KEY: <my_key>" "http://localhost:8000/version"

Note

APIキー認証が有効になっている場合でも、ヘルスチェックにのみ使用されるルート"/"エンドポイントは意図的に開いておきます

RabbitMQのクレデンシャル情報(RabbitMQ credentials)

Virtual Channelは内部的にメッセージブローカーとしてRabbitMQを使用し、Virtual Channelサービスがそれを使用するためにはクレデンシャル(資格)情報が必要です。デフォルトのクレデンシャル(資格)情報を変更する必要がある場合は、デフォルト値を変更するか、RABBITMQ_DEFAULT_USERRABBITMQ_DEFAULT_PASS 環境変数を上書きすることができます。

上記のいずれかを変更するには、redis_data のDockerボリュームからすべてのデータを削除して「クリーン」なRabbitMQを開始する必要があります。これを行うことで、これまでに作成したすべてのチャンネルとトランジションも失われることに注意してください。

TLS / HTTPSの有効化(Enabling TLS / HTTPS)

デフォルトのVirtual Channel Docker Composeファイルは、すべてをHTTP経由で実行します。TLSを処理するCDNと/またはロードバランサーの背後で実行されると想定しています。

HTTPを使用するための構成は、デフォルトのdocker composeオーバーライドファイル`docker-compose.override.yaml` で提供されます。

ただし、HTTPSを使用したい場合は、別の構成を利用することができます。

まず、証明書を certs ディレクトリに追加します。これにより、すべてのトラフィックのエントリーポイントである Traefik コンテナから証明書が利用可能になります。

次に、docker-compose.override.https.yaml 構成ファイルを更新し、TLSセクションを調整して証明書をロードします。

tls:
  certificates:
    - certFile: /certs/replace_this_with_your_cert_filename.crt
      keyFile: /certs/replace_this_with_your_key_filename.key

詳細な構成オプションについては、Traefikドキュメント を参照してください。

証明書の設定が完了したら、デフォルトのオーバーライドファイル`docker-compose.override.yaml` の代わりにこのYAMLファイルを参照して、代替のDocker Compose構成を実行できます。

docker compose -f docker-compose.yaml -f docker-compose.override.https.yaml up -d

この構成では、デフォルトのHTTPポート80および8000を、それぞれHTTPSポート443および8443にリダイレクトします。

curl https://localhost:8443 を実行してサービスが正常に起動しているかどうかを確認できます。これにより、I'm alive メッセージが返されます。

ストレージ(Storage)

Virtual Channelは、ローカルまたはネットワークファイルシステムからのVODメディアファイル、またはS3などのHTTPオブジェクトストレージを使用して利用できます。

ローカルまたはネットワークファイルシステム(Local or network filesystem)

ローカルまたはネットワークファイルシステムを使用する場合、メディアファイルは、プレイリストを処理してVODコンテンツをライブ配信に変換するVOD2Liveワーカー(VODファイルをリアルタイムのライブ配信に変えるためのシステムのこと)と、チャンネルを配信するUnified Originの両方で同じパスでアクセスできる必要があります。

ローカルメディアを素早く使い始めるためには、メディアファイルを既存の`channels` ディレクトリに配置することで対応できます。このディレクトリは、すでに2つのコンテナ間で共有されるボリュームとして設定されています。メディアファイルはその後、SMILファイル内で相対パスを使用して参照することができます。

ローカルにマウントされたネットワークファイルシステムは、docker-compose.yamlorigin および virtual-channel-worker-vod2live サービスに追加のバインドマウントを追加するだけで使用できます。

例:

volumes:
- type: bind
  source: /mnt/network-share
  target: /mnt/network-share

メディアファイルはSMIL内で絶対パスで参照できます。

共有ボリュームをDockerコンテナにマウントする他の方法の詳細については、公式のDockerドキュメントを参照してください。

HTTPオブジェクトストレージ(S3互換)(HTTP object storage (S3-compatible))

署名付きリクエストを必要としないHTTPオブジェクトストレージは、追加の構成を必要とせずに動作します。

S3互換ストレージの認証は、アクセスキー、シークレットキー、およびリージョンを処理するための環境変数を使用して管理されます。S3認証が必要なオブジェクトストレージを参照するSMILプレイリストを使用する予定の場合は、次のように設定する必要があります。

export S3_ACCESS_KEY=<ご自身のs3アクセスキー>
export S3_SECRET_KEY=<ご自身のs3シークレットキー>
export S3_REGION=<ストレージバケットのs3リージョン>
export REMOTE_STORAGE_URL=<s3 httpバケットのURL>

Warning

この時点で、Virtual Channelは常に1つのS3バケットのみで動作することができます。これは起動時に設定されます。つまり、プレイリストで参照される*すべて* のVODコンテンツは同じS3バケットに属している必要があります(つまり、2つ以上の異なるS3バケット上のコンテンツを参照する2つ以上のプレイリストを横断してトランジションすることはできません)。

Remixタイムアウト(Remix Timeout)

チャンネルとトランジションが作成されると、バックグラウンドの非同期タスクがremixとmp4splitを実行します。SMILプレイリストが非常に長い場合や、遅いストレージ上のメディアを参照する場合、remixタスクは時間がかかる場合があります。タスクを実行する「エンジン」として動作するCeleryは、REMIX_TASK_TIMEOUT秒よりも長い時間がかかるジョブをタイムアウトします。 チャンネルやトランジションが作成されると、バックグラウンドの非同期タスクがremixやmp4splitの実行を管理します。SMILプレイリストが非常に長い場合や、メディアが遅いストレージ上にある場合、remixタスクの処理に時間がかかることがあります。これらのタスクを実行するエンジンである``Celery`` は、正常性チェックを行い、REMIX_TASK_TIMEOUT 秒を超えて実行されているジョブをタイムアウトさせます。

このタイムアウトのデフォルト値は、最も一般的なユースケースを処理するのに十分な長さに設定されていますが、非常に長いプレイリストを使用したり、遅いストレージ上のメディアを参照したりする場合(またはその両方の場合)、タイムアウトが発生する可能性があります。

Note

非常に長いプレイリスト(24時間以上)を使用してリミックスタイムアウト(または非常に長いリミックス実行時間)が発生する場合は、長いプレイリストを短いプレイリストに分割してトランジションを作成することを覚えておくとよいでしょう。一般的に、これが望ましいアプローチです。

必要な場合は、REMIX_TASK_TIMEOUT環境変数を上書きしてタイムアウトを長くすることができます。

自動トランジション削除(Automatic transition deletion)

トランジションには、remix MP4ファイルやISMLファイル用のストレージスペース、そして内部データベースへのエントリーが必要です。トランジションが不要になった場合は、長期的にディスクスペースを圧迫しないように削除するべきです。

Virtual Channel には、毎日実行される定期的なメンテナンス作業が含まれており、不要なトランジションを削除しつつ、「DAYS_TO_KEEP_TRANSITIONS_FOR」で定義された日数分のアーカイブコンテンツを維持して動作させるようになっています。

つまり、このメンテナンスタスクは各チャンネルごとに <現在> - <DAYS_TO_KEEP_TRANSITIONS_FOR日> より前のすべてのトランジションのリストを取得します。そして、最新のトランジションを除いてそれらをすべて削除します。最新のトランジションを保持することが必要なのは、アーカイブ期間内のコンテンツを参照し、それを運用状態で維持する必要があるためです。

このメンテナンスタスクはトランジションのみを削除し、関連するベースチャンネルは決して削除しないことに注意してください。

Virtual Channel がトランジションを保持する日数は、DAYS_TO_KEEP_TRANSITIONS_FOR 環境変数で変更できます。ただし、必ずアーカイブ期間と同じか、それ以上の値に設定するようにしてください。