> For the complete documentation index, see [llms.txt](https://ayakaleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ayakaleaf-pro.ayaka.space/on-premises/ja/hajimeni/microservices.md). # マイクロサービス Overleaf Server CE と Overleaf Pro インスタンスをデプロイおよび管理するための推奨方法は、Toolkit を使用することです。 Toolkit は、必要なマイクロサービスのオーケストレーションを隠蔽するカスタムスクリプトをいくつか使って、Overleaf インスタンスの作成を簡素化します。付属の初期化スクリプトを実行し、永続ストレージのパスなどいくつかの設定オプションを指定するだけで、Toolkit が Overleaf Server CE または Pro インスタンスを構成するマイクロサービスのプロビジョニングと接続を行います。 これにより、ユーザー体験のカスタマイズや、オンプレミスのインスタンスを構成する特定機能の実装に集中できます。Toolkit は裏側の複雑さをすべて処理し、Overleaf インスタンスのデプロイを簡素化します。 {% hint style="info" %} 歴史的な理由から、メインの Overleaf コンテナは `sharelatex`と呼ばれ、 `sharelatex/sharelatex` Docker イメージをベースにしています。これは、この技術が Overleaf に統合された ShareLaTeX のコードベースを基にしているためです。 [この記事arrow-up-right](https://www.overleaf.com/blog/518-exciting-news-sharelatex-is-joining-overleaf) で詳しく説明しています。将来的には、Overleaf の命名規則に合わせて名称が変更される予定です。 {% endhint %} #### アーキテクチャ Overleaf コンテナ内では、ソフトウェアは一連のマイクロサービスとして実行され、 `runit`によって管理されています。コンテナ内で特に興味深いファイルには次のものがあります。 * `/etc/service/`: マイクロサービスの初期化ファイル。 * `/var/log/overleaf/`: 各マイクロサービスのログ。 * `/overleaf/services/`: 各種マイクロサービスのコード。 * `/var/lib/overleaf/`: 永続データのマウントポイント（ホスト上で `OVERLEAF_DATA_PATH` で示されるディレクトリに対応します）。 #### MongoDB と Redis のコンテナ Overleaf は MongoDB と Redis という 2 つの外部データベースに依存しています。デフォルトでは、Toolkit は Overleaf コンテナに加えてこれら各データベース用のコンテナを用意し、合計 3 つの Docker コンテナをプロビジョニングします。 {% hint style="info" %} 既存の MongoDB または Redis インスタンスに接続したい場合は、 [overleaf.rc](https://ayakaleaf-pro.ayaka.space/on-premises/ja/hajimeni/pages/e8986bf297e44455b9871d8dd8887089298c510d#the-overleaf.rc-file) 設定ファイルで適切な設定を行うことで可能です。 {% endhint %} #### エディタとコンパイル処理 このセクションでは、ドキュメントの処理とコンパイル処理について大まかに説明します。 {% hint style="info" %} このページでは、Overleaf Pro のみで利用可能な Sandboxed Compiles を使用したコンパイル処理について説明します。Server CE では、コンパイル処理は単純なサブプロセスを使用します。a を参照する項目は **コンテナ** を単一の項目 **サブプロセスでコンパイルを実行**. {% endhint %} コンポーネント / アクター: * `user` — アプリケーションのユーザー * `editor` — ブラウザで実行されるクライアントアプリケーション * `clsi` — PDF をコンパイルするためのマイクロサービス * `document-updater` — ドキュメント更新を処理するためのマイクロサービス * `filestore` — バイナリファイルを扱うマイクロサービス * `real-time` — WebSocket を処理するためのマイクロサービス * `web` — API リクエストを処理するための（あまりマイクロではない）サービス **Redis キャッシュ** * **user**: エディタページを読み込む * **editor**: WebSocket を開く * **editor**: WebSocket 経由でドキュメントを開くリクエストを送信する * **real-time** -> **document-updater**: ドキュメントが MongoDB から Redis に読み込まれる * **editor**: WebSocket 経由でドキュメント更新を送信する * **real-time** -> **document-updater**: Redis 上のドキュメントが更新される * **editor**: さらにコンパイルリクエストを送信する * 前回の flush から 5 分が経過した後（ドキュメントごと）: * **document-updater**: ドキュメントを Redis から MongoDB に flush する * **editor**: さらに更新を送信する * 100 更新ごとに（ドキュメントごと）: * **document-updater**: ドキュメント履歴を Redis から MongoDB に flush する * **user**: エディタを離れる / ブラウザタブを閉じる * 5 分後 * **real-time**: 他の共同編集者がいるか確認し、いなければ: * **real-time** -> **document-updater**: ドキュメントを Redis から MongoDB に flush する **MongoDB から Redis への読み込み** * **document-updater** -> **web** -> **docstore**: MongoDB から読み取る **Redis から MongoDB への flush** * **document-updater** -> **web** -> **docstore**: MongoDB に書き込む **コンパイル — "full" 同期モード** * **editor**: sync-mode を "full" に設定したコンパイルリクエストを送信する * **web** -> **document-updater**: Redis から MongoDB に flush されるドキュメントがあれば * **web** -> **docstore**: すべてのドキュメントが MongoDB からダウンロードされる * **web** -> **clsi**: コンパイルリクエストが送信される先 `clsi`には、次の内容が含まれます: * sync-mode * ファイルツリーのハッシュ -> 「プロジェクト状態」 * 内容を含むすべてのドキュメント -> 7MB のリクエストボディ制限の対象 * 個別にダウンロードするためのバイナリファイル URL * **clsi**: sync-mode と「プロジェクト状態」を使ってオンディスク状態を確認する * これは full sync なので、以前のオンディスク状態は無視できます * **clsi**: コンパイルディレクトリをクリーンアップする * **clsi**: すべてのドキュメントをコンパイルディレクトリに書き込む * **clsi**: すべてのバイナリファイルをコンパイルディレクトリに書き込む * `clsi` プロジェクトごとのローカルキャッシュからファイルをコピーする * キャッシュミス時: * **clsi** -> **filestore**: ファイルをダウンロードする * **clsi**: 「プロジェクト状態」を書き込む * **clsi**: 目的の設定で Docker コンテナが存在することを確認する * コンテナオプションを構築する、texlive のバージョンを含む * オプションをハッシュ化する * コンテナ名: `project---` * **clsi**: コンテナを起動し、stdout/stderr をメモリにストリームする -> 2MB 制限 * **clsi**: 停止したコンテナを残す -> 24 時間後にクリーンアップされる * **clsi**: stdout/stderr をディスクに書き込む * **clsi**: 出力ファイルを一意の出力ディレクトリにコピーする * ビルド ID は、8 バイトのランダム値とミリ秒精度のタイムスタンプで構成される * 最後の 3 つ（匿名）/最後の 1 つ（ログイン済みユーザー）を除いて、すべてのビルドフォルダを削除する * **clsi**: コンパイルが失敗/タイムアウトした * コンパイルキャッシュを削除する — 一部のファイルが欠けている、またはキャッシュが破損している可能性がある * **editor**: output.log と output.pdf をダウンロードする **コンパイル — "incremental" 同期モード** * **editor**: sync-mode を "incremental" に設定したコンパイルリクエストを送信する * **web** -> **document-updater**: Redis からドキュメントを取得する * 「プロジェクト状態」ハッシュも Redis に保存される * **web** ファイルツリーのハッシュを `document-updater` および `document-updater` 不一致時にインクリメンタルコンパイルをフルコンパイルに切り替えられる * エディタが "full" コンパイルを要求したときのコンパイル処理を参照してください * **web** -> **clsi**: コンパイルリクエストが送信される先 `clsi`には、次の内容が含まれます: * sync-mode * ファイルツリーのハッシュ -> 「プロジェクト状態」 * 内容を含む Redis 内のすべてのドキュメント -> 7MB のリクエストボディ制限の対象 * バイナリファイルなし * **clsi**: sync-mode と「プロジェクト状態」を使ってオンディスク状態を確認する * これはインクリメンタル同期なので、「プロジェクト状態」は一致していなければならない * 不一致時: 409 を返し、Web に "full" 同期で再試行させる * エディタが "full" コンパイルを要求したときのコンパイル処理を参照してください * **clsi**: 更新されたドキュメントをコンパイルディレクトリに書き込む * **clsi**: 目的の設定で Docker コンテナが存在することを確認する * コンテナオプションを構築する、texlive のバージョンを含む * オプションをハッシュ化する * コンテナ名: `project---` * **clsi**: コンテナを起動し、stdout/stderr をメモリにストリームする -> 2MB 制限 * **clsi**: 停止したコンテナを残す -> 24 時間後にクリーンアップされる * **clsi**: stdout/stderr をディスクに書き込む * **clsi**: 出力ファイルを一意の出力ディレクトリにコピーする * ビルド ID は、8 バイトのランダム値とミリ秒精度のタイムスタンプで構成される * 最後の 3 つ（匿名）/最後の 1 つ（ログイン済みユーザー）を除いて、すべてのビルドフォルダを削除する * **clsi**: コンパイルが失敗/タイムアウトした * コンパイルキャッシュを削除する — 一部のファイルが欠けている、またはキャッシュが破損している可能性がある * **editor**: output.log と output.pdf をダウンロードする **コンパイル — モードの切り替え** * **editor**: コンパイル失敗を観測した場合、次のコンパイルは "full" コンパイルになる * **editor**: コンパイル成功を観測した場合、次のコンパイルは "incremental" コンパイルになる --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://ayakaleaf-pro.ayaka.space/on-premises/ja/hajimeni/microservices.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.