GoogleクラウドでIronPDF for Javaを実行する方法
Google Cloud FunctionsへのIronPDF for Javaの展開には、非デフォルト構成が必要です。IronPDFはHTMLをPDFにレンダリングするためにバンドルされたChromiumバイナリに依存するためです。 このガイドは、Google Cloud FunctionsでカスタムDockerコンテナー内でIronPDFを実行するために必要なすべてをカバーしています—適切なpom.xml依存関係から実行権限およびリソース設定まで。
この問題は、既にGoogle Cloud FunctionsとDockerに慣れている場合には気にしなくても大丈夫です。 設定変更は簡単です。デフォルトの関数イメージをカスタムDockerfileに置き換え、Linuxエンジンの依存関係を追加し、リソース制限を調整し、作業ディレクトリを設定します。 各ステップは以下に説明されています。
Quickstart: Google CloudでIronPDF for Javaをデプロイする
最小限の作業設定には、Chromeのシステム依存関係が欠けている標準のCloud Functionイメージなので、カスタムDockerfile、ironpdf-engine-linux-x64アーティファクトが必要です。 以下のコードは、関数エントリーポイントでエンジン作業ディレクトリを設定する方法を示しています。
:path=/static-assets/pdf/content-code-examples/tutorials/google-cloud/configure-working-directory.java
import com.ironsoftware.ironpdf.Settings;
import java.nio.file.Paths;
// Point IronPDF at a writable directory in the Cloud Function runtime
Settings.setIronPdfEngineWorkingDirectory(Paths.get("/tmp/"));
作業ディレクトリを設定した後、IronPDFはCloud Functionの一時ファイルシステム内でエンジンバイナリを抽出して実行することができます。 Google Cloud Functionsのほとんどのランタイムでは、/tmp/ディレクトリが唯一の書き込み可能で実行可能なパスです。
目次
- なぜデフォルトのCloud Functionイメージは機能しないのですか?
- Google Cloud用のカスタムDockerfileをどうやって構築しますか?
- Google Cloudデプロイメント用にpom.xmlをどのように設定しますか?
- Maven Shade Pluginをどのように追加しますか?
- オプションのgRPC依存関係をどのように追加しますか?
- Google Cloud Functionsのリソース制限をどのように設定しますか?
- 作業ディレクトリとファイル権限をどのように設定しますか?
- 次のステップは何ですか?
なぜデフォルトのCloud Functionイメージは機能しないのですか?
デフォルトのGoogle Cloud Functionランタイムイメージは、設計上最小限で、一般的な言語で書かれた関数コードを実行するために必要なパッケージのみを含んでいます。 IronPDFのChromiumベースのレンダリングエンジンは、標準イメージには存在しないLinuxのより広範なシステムライブラリ(フォント、グラフィックライブラリ、サンドボックスツール)に依存しています。
Googleは、各ランタイムの利用可能なシステムパッケージの完全なリストをGoogle Cloud Functionsシステムパッケージリファレンスで公開しています。 Chromiumの依存関係は、標準の第2世代ランタイムのいずれにも含まれていません。 デフォルトイメージでIronPDFエンジンをロードしようとすると、スタートアップ時にネイティブライブラリのロードに失敗します。
解決策は、それらのパッケージを関数バイナリが追加される前に明示的にインストールするカスタムDockerイメージを構築することです。 このアプローチはGoogle Cloud Functionsで完全にサポートされており、ネイティブバイナリを必要とする関数には推奨される戦略と同じです。 含めるパッケージの完全なリストについては、IronPDF Linuxデプロイメントガイドを参照してください。
Google Cloud用のカスタムDockerfileをどのように構築しますか?
カスタムDockerfileは、ランタイム環境を完全に制御します。 公式のGoogle Cloud Functions Javaベースイメージから開始し、Chromiumが必要とするシステムライブラリをインストールします。
以下のDockerfileは推奨パターンを示しています。 関数プロジェクトの詳細を含むCMDエントリを置き換えます:
//:path=Dockerfile
# Use the official Google Cloud Functions Java 17 base image
FROM gcr.io/google-appengine/java17:latest
# Install Chrome system dependencies required by IronPDF's rendering engine
RUN apt-get update && apt-get install -y \
libglib2.0-0 \
libnss3 \
libatk1.0-0 \
libatk-bridge2.0-0 \
libcups2 \
libdrm2 \
libxkbcommon0 \
libxcomposite1 \
libxdamage1 \
libxfixes3 \
libxrandr2 \
libgbm1 \
libasound2 \
libpango-1.0-0 \
libpangocairo-1.0-0 \
--no-install-recommends \
&& rm -rf /var/lib/apt/lists/*
# Grant execute permissions on /tmp so the IronPDF engine can extract there
RUN chmod 777 /tmp/
# Copy the compiled JAR and set the entry point
COPY target/your-function.jar /app/function.jar
CMD ["java", "-jar", "/app/function.jar"]
IronPDFは、初期化中にエンジンバイナリを書き込み、実行する必要があるため、chmod 777 /tmp/ラインが必要です。 作業ディレクトリに実行権限がない場合、エンジンは起動しません。
docker runを使用してローカルで Docker イメージをテストし、Cloud Functionsにデプロイする前に確認する。 ローカルテストにより、不足している依存関係を早期に発見し、クラウドのビルドサイクルの遅延を避けることができます。Google Cloudデプロイメント用にpom.xmlをどのように設定しますか?
標準のironpdf Mavenアーティファクトは、複数のプラットフォーム用にエンジンバイナリをバンドルします。 Linux x86-64で実行されるGoogle Cloud Functions用に、プラットフォーム固有のエンジンアーティファクトを追加して、デプロイメントイメージをスリムに保ち、常に正しいバイナリが利用可能であることを保証します。
//:path=pom.xml
<dependencies>
<dependency>
<groupId>com.ironsoftware</groupId>
<artifactId>ironpdf</artifactId>
<version>2024.9.1</version>
</dependency>
<dependency>
<groupId>com.ironsoftware</groupId>
<artifactId>ironpdf-engine-linux-x64</artifactId>
<version>2024.9.1</version>
</dependency>
</dependencies>
//:path=pom.xml
<dependencies>
<dependency>
<groupId>com.ironsoftware</groupId>
<artifactId>ironpdf</artifactId>
<version>2024.9.1</version>
</dependency>
<dependency>
<groupId>com.ironsoftware</groupId>
<artifactId>ironpdf-engine-linux-x64</artifactId>
<version>2024.9.1</version>
</dependency>
</dependencies>
常にバージョン番号を最新のIronPDF for Javaリリースに更新してください。 ironpdfアーティファクトのバージョンと正確に一致しなければなりません。
Maven Shade Pluginをどのように追加しますか?
uber-JAR(ファットJAR)としてGoogle Cloud Functionsにデプロイする際、maven-shade-plugin はすべてのトランジティブ依存関係からのサービスローダファイルが正しくマージされることを保証します。 それがないと、一部のgRPCサービス登録が静かにドロップされ、エンジンの初期化が失敗する原因となります。
次のプラグイン設定を<build><plugins>セクションに追加します:
//:path=pom.xml
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3.2.4</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<transformers>
<transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>
</transformers>
</configuration>
</execution>
</executions>
</plugin>
//:path=pom.xml
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3.2.4</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<transformers>
<transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>
</transformers>
</configuration>
</execution>
</executions>
</plugin>
ServicesResourceTransformer は重要な部分です。 すべての依存JARからのServiceLoaderメカニズムを使用するので、マージされたサービスファイルはランタイムでのトランスポート選択(HTTP/2対プレーンテキスト)が働くために必要です。
オプションのgRPC依存関係をどのように追加しますか?
特定のGoogle Cloud Functionsフレームワークのバージョンを使用している場合に、明示的なgRPCトランスポート依存関係が必要となる場合があります。 関数がgRPCトランスポートまたはチャネルエラーで起動に失敗する場合、以下を追加してください。
//:path=pom.xml
<dependencies>
<dependency>
<groupId>io.perfmark</groupId>
<artifactId>perfmark-api</artifactId>
<version>0.26.0</version>
</dependency>
<dependency>
<groupId>io.grpc</groupId>
<artifactId>grpc-okhttp</artifactId>
<version>1.50.2</version>
</dependency>
<dependency>
<groupId>io.grpc</groupId>
<artifactId>grpc-netty-shaded</artifactId>
<version>1.50.2</version>
</dependency>
</dependencies>
//:path=pom.xml
<dependencies>
<dependency>
<groupId>io.perfmark</groupId>
<artifactId>perfmark-api</artifactId>
<version>0.26.0</version>
</dependency>
<dependency>
<groupId>io.grpc</groupId>
<artifactId>grpc-okhttp</artifactId>
<version>1.50.2</version>
</dependency>
<dependency>
<groupId>io.grpc</groupId>
<artifactId>grpc-netty-shaded</artifactId>
<version>1.50.2</version>
</dependency>
</dependencies>
ほとんどの場合、grpc-netty-shadedを含むことは実稼働環境に十分です。 grpc-okhttpトランスポートは、イメージサイズの最小化が優先される場合にはより軽量な代替手段として有用です。 トレースアノテーションが不足しているというクラスパス警告がある場合にのみperfmark-apiを追加します。
Google Cloud Functionsのリソース制限をどのように設定しますか?
IronPDFは最初の呼び出しでCloud Functionコンテナ内でChromiumサブプロセスを起動します。 Chromiumの起動および初期レンダリングはメモリを大量に使用し、エンジンが初期化するまで関数が長い間生き残る必要があります。Cloud Functionsのデフォルトのリソース制限は、信頼性の高い運用に十分ではありません。
関数をデプロイする際にGoogle Cloud Consoleまたはgcloud CLIで次の制限を設定します:
| 設定 | 推奨値 | 理由 |
|---|---|---|
| タイムアウト | 330秒 | コールドスタートでのChromiumの初期化には60〜90秒かかることがあります。エンジンが準備できる前に関数がタイムアウトしてはいけません。 |
| メモリ | 2,048 MB以上 | Chromiumは複雑なHTMLページをレンダリングするために大きなRAMを必要とします。メモリが不十分であると、レンダリングの途中でプロセスが終了します。 |
| Ephemeral Storage | 1,024 MB以上 | エンジンバイナリと一時的なPDFファイルは/tmp/に書き込まれます。ストレージが不足すると抽出や書き込みに失敗します。 |
これらの値は開始点です。 高ボリュームまたは複雑なPDF生成には、より高いメモリアロケーションが必要になる場合があります。 Google Cloud ConsoleでCloud Functionのメモリ使用量メトリクスを監視し、メモリ不足エラーが観察される場合は制限を増やしてください。
作業ディレクトリとファイル許可をどのように構成しますか?
IronPDFエンジンは、起動時にバイナリを作業ディレクトリに抽出します。Google Cloud Functionsでは、唯一の書き込み可能かつ実行可能なパスは/tmp/です。 任意のIronPDF APIを呼び出す前に作業ディレクトリを明示的に設定し、Dockerfileがそのパスに必要な権限を与えていることを確認してください。
PDF操作の前に、関数エントリーポイントの一番上にこの設定呼び出しを追加してください。
//:path=/static-assets/pdf/content-code-examples/tutorials/google-cloud/configure-working-directory.java
import com.ironsoftware.ironpdf.Settings;
import java.nio.file.Paths;
public class PdfFunction {
static {
// Must be called before any IronPDF operation.
// /tmp/ is the only writable and executable directory in Cloud Functions.
Settings.setIronPdfEngineWorkingDirectory(Paths.get("/tmp/"));
}
}
//:path=/static-assets/pdf/content-code-examples/tutorials/google-cloud/configure-working-directory.java
import com.ironsoftware.ironpdf.Settings;
import java.nio.file.Paths;
public class PdfFunction {
static {
// Must be called before any IronPDF operation.
// /tmp/ is the only writable and executable directory in Cloud Functions.
Settings.setIronPdfEngineWorkingDirectory(Paths.get("/tmp/"));
}
}
その後、対応する権限コマンドをDockerfileに追加してください。
//:path=Dockerfile
# Ensure the IronPDF engine can extract and run binaries from /tmp/
RUN chmod 777 /tmp/
作業ディレクトリが構成される前に、static {}初期化子ブロックを使用して、関数内のいずれかのクラスがIronPDFエンジンをロードしようとするのを保証します。インスタンスメソッドまたはリクエストハンドラーで設定する場合、他のスレッドがパスが構成される前にエンジンを初期化するリスクがあります。
次のステップは何ですか?
このガイドは、カスタムDockerコンテナを使用してGoogle Cloud Function内でIronPDF for Javaを実行するための完全な設定をカバーしています。 重要なポイントは次の通りです:Chromeシステム依存関係をインストールするカスタムDockerfileを使用し、ironpdf-engine-linux-x64 Mavenアーティファクトを含め、作業ディレクトリを/tmp/に設定し、タイムアウトを少なくとも330秒、メモリを少なくとも2,048 MBに設定し、サービスローダファイルをマージするためmaven-shade-pluginを追加します。
IronPDF for Javaドキュメントを訪問するか、以下のガイドを試して、IronPDF for Javaの詳細を探索してください。
- LinuxでのIronPDF for Java — LinuxデプロイメントのためのChrome依存関係の完全なリストを理解する
- AWS LambdaでのIronPDF for Java — AWS向けの同様のDockerベースのデプロイメントガイド
- JavaでのHTMLからPDFへの変換 — あなたの関数ロジック用のコアレンダリングワークフロー
無料トライアルライセンスを取得して、あなたのGoogle Cloud環境でIronPDF for Javaをテストしてください。 本番デプロイメントにはライセンスキーが必要です。 本番環境で使用する準備が整ったら、ライセンスを購入してください。
よくある質問
なぜGoogle Cloud FunctionのデフォルトイメージでIronPDF for Javaは起動しないのですか?
デフォルトのCloud Functionランタイムイメージには、Chromiumが必要とするLinuxシステムライブラリ、例えばlibnss3、libatk1.0-0、関連するグラフィックパッケージなどが含まれていません。IronPDFのレンダリングエンジンは内部でChromiumを使用するため、これらの依存関係を明示的にインストールするカスタムDockerfileが必要です。
なぜZipデプロイはGoogle CloudでIronPDFにサポートされないのですか?
IronPDFはランタイムでネイティブのChromiumバイナリを抽出して実行する必要があります。Zipデプロイメントモデルは書き込み可能で実行可能なファイルシステムを提供しないため、エンジンはバイナリを抽出または起動できません。Dockerベースのデプロイが必要です。
Google Cloud FunctionsでIronPDFに必要なMaven依存関係は何ですか?
com.ironsoftwareグループからironpdf-engine-linux-x64をpom.xmlに追加します。バージョン番号はコアironpdfアーティファクトと完全に一致する必要があります。このアーティファクトには、IronPDFがレンダリングに使用するLinux x86-64 Chromiumバイナリがバンドルされています。
なぜIronPDF for Javaはmaven-shade-pluginを必要とするのですか?
ub žele-JARとしてパッケージ化する際、maven-shade-pluginはServicesResourceTransformerによってすべての依存JARからMETA-INF/services/ファイルをマージします。それがないと、gRPCサービスの登録がサイレントに削除され、IronPDFエンジンが初期化に失敗する可能性があります。
Google Cloud FunctionsでIronPDFを実行するために必要なタイムアウトとメモリの設定は?
関数のタイムアウトを330秒、メモリを少なくとも2048 MB、エフェメラルストレージを少なくとも1024 MBに設定します。コールドスタートでのChromiumの初期化は60〜90秒かかることがありますし、エンジンは複雑なHTMLページをレンダリングするために大量のメモリを必要とします。
なぜSettings.setIronPdfEngineWorkingDirectoryはGoogle Cloudで/tmp/を指す必要があるのですか?
/tmp/ディレクトリは、ほとんどのGoogle Cloud Functionランタイムで利用可能な唯一の書き込み可能で実行可能なパスです。IronPDFはこの場所にエンジンバイナリを抽出し、テンポラリファイルを書き込む必要があります。この設定がないと、エンジンは適切な抽出ターゲットを見つけることができず、起動に失敗します。
なぜDockerfileはRUN chmod 777 /tmp/を必要とするのですか?
IronPDFのエンジンバイナリは/tmp/に書き込まれ、実行されなければなりません。一部の基本イメージでは/tmp/のデフォルトの権限がすべてのユーザーの実行権限を含んでいません。chmod 777コマンドは、関数ランタイムユーザーがバイナリを抽出し起動できることを保証します。
grpc-okhttpをgrpc-netty-shadedの代わりに使用すべき時期は?
grpc-netty-shadedは、より完全なHTTP/2実装を提供するため、本番環境に推奨されます。grpc-okhttpはDockerイメージサイズを最小化するのが優先事項のときに有用な軽量な代替手段です。どちらのトランスポートもGoogle Cloud FunctionsでのIronPDF for Javaと連携します。


