> 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/she-ding/overleaf-toolkit/sandboxed-compiles.md). # サンドボックス化されたコンパイル Overleaf Pro には、企業向けセキュリティのために、保護されたサンドボックス環境でコンパイルを実行するオプションがあります。これは、各プロジェクトをそれぞれ独立した保護済み Docker 環境で実行することで実現しています。 ### セキュリティの向上 Sandboxed Compiles は、PDF のコンパイル処理の一部として任意のシェルコマンドを実行する必要がある／実行できる LaTeX 文書が多いため、Server Pro では推奨される方法です。Sandboxed Compiles を使用すると、各コンパイルは、他のユーザーやプロジェクトと共有されない制限付き機能を持つ個別の Docker コンテナで実行され、ホストネットワークなどの外部リソースにはアクセスできません。 {% hint style="warning" %} Overleaf Pro を実行しようとして、 **Sandboxed Compiles を使用しないと、** コンパイルはメインの Docker コンテナ内で他の同時実行中のコンパイルと並行して動作し、ユーザーは LaTeX コンパイル実行時に `sharelatex` コンテナのリソース（ファイルシステム、ネットワーク、環境変数）に対して完全な読み書きアクセス権を持ちます。 {% endhint %} ### パッケージ管理をより簡単に パッケージを手動でインストールするのを避けるため、Sandboxed Compiles を有効にすることを推奨します。これは Server Pro 内の設定可能な項目で、ユーザーに overleaf.com と同じ TeX Live 環境へのアクセスを、独自のオンプレミス環境内で提供します。Sandboxed Compiles で使用される TeX Live イメージには、ギャラリーのテンプレートに対してテスト済みの最も一般的なパッケージとフォントが含まれており、オンプレミスのプロジェクトとの最大限の互換性を確保します。 Sandboxed Compiles を有効にすると、プロジェクト内でユーザーが選択できる TeX Live のバージョンを設定し、新規プロジェクト向けのデフォルトの TeX Live イメージバージョンも設定できます。 {% hint style="info" %} Sandboxed Compiles を使用せずに Overleaf Pro を実行しようとすると、インスタンスはコンパイルに基本スキーム版の TeX Live を使用するようになります。この基本版は軽量で、LaTeX パッケージのごく限られたサブセットしか含まないため、特に事前作成済みテンプレートを使用しようとした場合、ユーザーにはパッケージ不足のエラーが発生する可能性が高くなります。 {% endhint %} Overleaf Pro はオフラインで動作するよう設計されているため、overleaf.com のギャラリーテンプレートをオンプレミス環境に自動で統合する方法はありません。ただし、テンプレートごとに手動で行うことは可能です。これがどのように動作するかの詳細については、overleaf.com からテンプレートを移行するガイドをご覧ください: [/pages/a063fd471ca852c7f6a1e6ca6ef1432353b2e04a#transferring-templates-from-overleaf.com](https://ayakaleaf-pro.ayaka.space/on-premises/ja/she-ding/overleaf-toolkit/pages/a063fd471ca852c7f6a1e6ca6ef1432353b2e04a#transferring-templates-from-overleaf.com "mention"). {% hint style="info" %} Sandboxed Compiles では、 `sharelatex` コンテナがホストマシン上の Docker ソケットに（バインドマウント経由で）アクセスできる必要があります。これにより、隣接するこれらのコンパイル用コンテナを管理できます。 {% endhint %} ## 仕組み Sandboxed Compiles が有効になると、Docker ソケットがホストマシンから `sharelatex` コンテナにマウントされ、コンテナ内のコンパイラサービスがホスト上に新しい Docker コンテナを作成できるようになります。その後、各プロジェクトの各コンパイラ実行ごとに、LaTeX コンパイラサービス（CLSI）は次の処理を行います: * プロジェクトファイルを次の内部の場所に書き出す `OVERLEAF_DATA_PATH`. * マウントされた Docker ソケットを使用して新しい `texlive` コンパイル実行用のコンテナを作成する。 * コンテナに `texlive` コンテナが次の配下の場所からプロジェクトデータを読み取る `OVERLEAF_DATA_PATH`. * プロジェクトを次の内部でコンパイルする `texlive` コンテナ。 ### Sandboxed Compiles の有効化 #### Toolkit ユーザー向け サンドボックス化されたコンパイル（Sibling containers とも呼ばれます）を有効にするには、次の設定を `overleaf-toolkit/config/overleaf.rc`: {% code title="config/overleaf.rc" %} ```dotenv SERVER_PRO=true SIBLING_CONTAINERS_ENABLED=true ``` {% endcode %} #### Docker Compose ユーザー向け {% hint style="danger" %} Overleaf CE/Server Pro 以降では `5.0.3` 環境変数の名称が次のように変更されました: `SHARELATEX_*` から `OVERLEAF_*`. {% endhint %} もし `4.x` 系のバージョン（またはそれ以前）を使用している場合は、変数のプレフィックスがそれに合わせていることを確認してください（例: `SHARELATEX_MONGO_URL` の代わりに `OVERLEAF_MONGO_URL`). 
version: '2'
services:
    sharelatex:
        #...
        volumes:
            - /data/overleaf_data:/var/lib/overleaf
            - /var/run/docker.sock:/var/run/docker.sock
        environment:
            #...
            DOCKER_RUNNER: "true"
            SANDBOXED_COMPILES: "true"
            SANDBOXED_COMPILES_HOST_DIR: "/data/overleaf_data/data/compiles"
            #...
        #...
### TexLive イメージの変更 {% hint style="info" %} 中国本土のユーザーは、 `ghcr.nju.edu.cn` を使用してダウンロードを高速化できます。 {% endhint %} Overleaf Pro は、Sandboxed Compiles で使用する TeX Live イメージを決定するために 3 つの環境変数を使用します: * `TEX_LIVE_DOCKER_IMAGE` **（必須）** 新規プロジェクトのコンパイルに使用されるデフォルトの TeX Live イメージです。このイメージは次の中に含まれている必要があります: `ALL_TEX_LIVE_DOCKER_IMAGES`. * `ALL_TEX_LIVE_DOCKER_IMAGE_NAMES` **（必須）** フロントエンドのオプションで使用される、イメージの親しみやすい名前をカンマ区切りで並べた一覧です。 * `ALL_TEX_LIVE_DOCKER_IMAGES` **（必須）** 使用する TeX Live イメージのカンマ区切り一覧です。デプロイに Overleaf Toolkit を使用している場合、これらのイメージはダウンロードまたは更新されます。ダウンロードを省略するには、次を設定してください: `SIBLING_CONTAINERS_PULL=false` の `config/overleaf.rc`. 次を使用して Overleaf Pro インスタンスを起動すると `bin/up` コマンド、Toolkit は次に一覧表示されたすべてのイメージを自動的に取得します: `ALL_TEX_LIVE_DOCKER_IMAGES`. 以下は、新規プロジェクトでは TeX Live 2025 をデフォルトにし、既存プロジェクトでは 2024 を引き続き使用する例です。 {% tabs %} {% tab title="共通インストール" %} 次の設定では、2025 年から 2026 年までのすべてのフル TeX Live Docker イメージをインストールします。この設定を使用する前に、少なくとも 80 GB の空きストレージを確保することを推奨します。 {% code title="config/variables.env" overflow="wrap" %} ```dotenv ALL_TEX_LIVE_DOCKER_IMAGES=ghcr.io/ayaka-notes/texlive-full:2026.1, ghcr.io/ayaka-notes/texlive-full:2025.1 ALL_TEX_LIVE_DOCKER_IMAGE_NAMES=Texlive 2026, Texlive 2025 TEX_LIVE_DOCKER_IMAGE=ghcr.io/ayaka-notes/texlive-full:2026.1 ``` {% endcode %} {% endtab %} {% tab title="フルインストール" %} 次の設定では、2020 年から 2026 年までのすべてのフル TeX Live Docker イメージをインストールします。この設定を使用する前に、少なくとも 256 GB の空きストレージを確保することを推奨します。 {% code title="config/variables.env" overflow="wrap" %} ```dotenv ALL_TEX_LIVE_DOCKER_IMAGES=ghcr.io/ayaka-notes/texlive-full:2026.1,ghcr.io/ayaka-notes/texlive-full:2025.1,ghcr.io/ayaka-notes/texlive-full:2024.1,ghcr.io/ayaka-notes/texlive-full:2023.1,ghcr.io/ayaka-notes/texlive-full:2022.1,ghcr.io/ayaka-notes/texlive-full:2021.1,ghcr.io/ayaka-notes/texlive-full:2020.1 ALL_TEX_LIVE_DOCKER_IMAGE_NAMES=Texlive 2026,Texlive 2025,Texlive 2024,Texlive 2023,Texlive 2022,Texlive 2021,Texlive 2020 TEX_LIVE_DOCKER_IMAGE=ghcr.io/ayaka-notes/texlive-full:2026.1 ``` {% endcode %} {% endtab %} {% endtabs %} {% hint style="danger" %} 次を設定することを強く推奨します: **少なくとも 2 つの texlive-full イメージ**。詳細な理由については、次を参照してください: [#known-issues](#known-issues "mention") {% endhint %} ### 利用可能な TeX Live イメージ これらは Overleaf 向けに特別に最適化された一連の TeX Live イメージで、次にも追加できます: `TEX_LIVE_DOCKER_IMAGE` および `ALL_TEX_LIVE_DOCKER_IMAGES`: * `ghcr.io/ayaka-notes/texlive-full:2026.1` （また `latest` タグ） * `ghcr.io/ayaka-notes/texlive-full:2025.1` * `ghcr.io/ayaka-notes/texlive-full:2024.1` * `ghcr.io/ayaka-notes/texlive-full:2023.1` * `ghcr.io/ayaka-notes/texlive-full:2022.1` * `ghcr.io/ayaka-notes/texlive-full:2021.1` * `ghcr.io/ayaka-notes/texlive-full:2020.1` {% hint style="warning" %} イメージのタグ付け方法には厳密なスキーマがあります **必要が** あります（次の正規表現が適用されます `^[0-9]+.[0-9]+`。このうち最初の数字は TeX Live の年を、2 番目の数字はパッチバージョンを表します）。 {% endhint %} ### 他のイメージレジストリを使えますか > ghcr.io を別のミラーサイトに置き換えたり、Docker Hub の別のイメージに texlive を切り替えたりできるのではないかと考える人もいるかもしれません。 `ghcr.io` 別のミラーサイトに置き換えたり、Docker Hub の別のイメージに texlive を切り替えたりできますか？ いいえ、設定が比較的複雑なため推奨しません。ミラーサイトからダウンロードしている場合は、イメージ名を次のように変更できます: `ghcr.io/ayaka-notes/texlive-full`. ただし、どうしても独自のイメージレジストリを使いたい場合は、次を追加してください: {% code title="config/variables.env" overflow="wrap" %} ```dotenv IMAGE_ROOT=hub.your.com/your-repo ``` {% endcode %} その場合、texlive のすべてのイメージが次の場所にあることを確認する必要があります: `your-repo`、たとえば * `hub.your.com/your-repo/texlive-full:2025.1` * `hub.your.com/your-repo/texlive-full:2024.1` 詳細については、以下のソースコードを読んで、環境変数をどのように解釈しているかを確認してください: {% code title="sandboxed-compiles/index.mjs" overflow="wrap" expandable="true" %} ```mjs if (process.env.SANDBOXED_COMPILES === 'true') { // 指定されていない場合はデフォルトのイメージルートを設定 let imageRootPath = process.env.IMAGE_ROOT || "ghcr.io/ayaka-notes"; // imageRoot を Settings にエクスポート Settings.imageRoot = imageRootPath // allowedImageNames は次のようになります: // [ // { imageName: "texlive-2023:latest", imageDesc: "TeX Live 2023" }, // { imageName: "texlive-2022:latest", imageDesc: "TeX Live 2022" }, // ] Settings.allowedImageNames = parseTextExtensions(process.env.ALL_TEX_LIVE_DOCKER_IMAGES) .map((texImage, index) => ({ imageName: texImage.split("/")[texImage.split("/").length - 1], imageDesc: parseTextExtensions(process.env.ALL_TEX_LIVE_DOCKER_IMAGE_NAMES)[index] || texImage.split(':')[1], })) // 最後に、imageName は imageRoot と組み合わされて完全なイメージパスになります // 完全な名前は次のようになります: ghcr.io/ayaka-notes/texlive-2023:latest // 指定されていない場合はデフォルトのイメージ名を設定 if(!process.env.TEX_LIVE_DOCKER_IMAGE) { process.env.TEX_LIVE_DOCKER_IMAGE = imageRootPath + "/" + Settings.allowedImageNames[0].imageName } // currentImageName を Settings にエクスポート // これは新しく作成されたプロジェクトのイメージ名です Settings.currentImageName = process.env.TEX_LIVE_DOCKER_IMAGE } ``` {% endcode %} ### 既知の問題 これは Overleaf コミュニティでの実際の事例です: > 使用しているのは `6.0.1-ext-v3.3`で、 `variables.env`: > > ```dotenv > TEX_LIVE_DOCKER_IMAGE=texlive/texlive:latest-full > ALL_TEX_LIVE_DOCKER_IMAGES=texlive/texlive:latest-full > ``` > > これは次のもので問題なく動作します: `texlive/texlive:latest-full`。しかし、別の texlive イメージを取得しました `danteev/texlive:2025-10-15` そして、これら 2 つの変数を新しいイメージ名に変更しましたが、うまくいきません: > > ```dotenv > TEX_LIVE_DOCKER_IMAGE=danteev/texlive:2025-10-15 > ALL_TEX_LIVE_DOCKER_IMAGES=danteev/texlive:2025-10-15 > ``` > > ログには次のように表示されます: > > {% code overflow="wrap" %} > > ``` > {"name":"clsi","level":50,"err":{"message":"(HTTP code 404) no such container - No such image: texlive/texlive:latest-full ","name":"Error","stack":"Error: (HTTP code 404) no such container - No such image: texlive/texlive:latest-full ... > ``` > > {% endcode %} > > の設定を更新したようですが、 `variables.env` 反映されていないようです。コンパイルは引き続き次のイメージでの実行を試みます: `texlive/texlive:latest-full` 古いイメージであって、新しい > > 再起動し、コンテナを削除して再実行もしてみましたが、同じ問題が続きます。 > > 解決策はありますか？ いくつかの技術的制約により、たとえば 1 つの Docker TeXLive イメージだけを設定した場合、 `texlive-fullA:latest` ``` ALL_TEX_LIVE_DOCKER_IMAGES=texlive/texliveA:latest-full ALL_TEX_LIVE_DOCKER_IMAGE_NAMES=TeXLiveA TEX_LIVE_DOCKER_IMAGE=texlive/texliveA:latest-full ``` そして、Overleaf インスタンスをしばらく稼働させた後で、TeXLive イメージを次のように変更したくなるかもしれません: `texlive-fullB:latest`。すると、ユーザーがすべてのプロジェクトをコンパイルできなくなることがわかります。 ``` ALL_TEX_LIVE_DOCKER_IMAGES=texlive/texliveA:latest-full ALL_TEX_LIVE_DOCKER_IMAGE_NAMES=TeXLiveA TEX_LIVE_DOCKER_IMAGE=texlive/texliveA:latest-full ``` これは、各プロジェクトにおける TeXLive-Full イメージ（サンドボックスコンパイル用）の名前がデータベースに保存されているためです。 *ユーザーが自分のプロジェクトの TeXLive バージョンを、たとえば 2024 から 2025 に切り替えた場合にのみ、データベース内のイメージ名が変更されます*. CLSI がプロジェクトをコンパイルするときは、データベースに保存されているコンテナイメージ名を使って直接プロジェクトをコンパイルします。 Docker イメージを 1 つしか提供しない場合、ユーザーはプロジェクトのコンパイルに使用されるイメージを変更できません。この場合、次のためのスクリプトを書く必要があります: **手動で変更する** mongoDB 内のすべてのユーザープロジェクトの TeXLive イメージを ### デバッグ Toolkit から clsi のログを確認するには、次のコマンドを実行してください: {% code overflow="wrap" %} ```bash bin/logs clsi ``` {% endcode %} --- # 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/she-ding/overleaf-toolkit/sandboxed-compiles.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.