Perl Hackers Hub

第61回GitHub ActionsとAmazon ECSを使ったDockerアプリケーションの自動デプロイ(2)

前回の(1)こちらから。

PerlアプリケーションをECS化するポイント

(2)では、PerlアプリケーションをECSにデプロイする際に押さえておくべきポイントを解説します。

Perlのベースイメージの選び方

便利なことに、Docker HubにはPerlの公式イメージが用意されているので、基本的にはこれを使用します。ただし、バージョンによってはパッチバージョンがあまり更新されていないため注意してください。

今回は特にバージョンにこだわる理由がないので、先ほどは執筆時点で最新のperl:5.30をベースイメージとして採用しました。

Docker Hubに登録されていないバージョンを使いたい場合

Docker Hubに登録されていないバージョンを使いたい場合は、Docker HubにあるDebian GNU/Linuxイメージなどをベースイメージとして、その上にxbuildなどを使ってPerlを手動ビルドしてください。

ソースコードをイメージに含める? 含めない?

Dockerイメージを作るうえで考えなければならないのが、Dockerイメージのライフサイクルです。Immu table Infrastructureのポリシーに従うならば、アプリケーションのソースコードが修正されるたびに、Dockerイメージは新たに作りなおすべきです。

とはいえ、ソースコードを修正するたびにDockerイメージをビルドしなおすのは、ローカル開発環境ではおっくうです。そのため、開発用のDockerイメージにはソースコードを含めず、Dockerのbindマウントを使ってローカル開発環境のソースコードをマウントする手法が用いられます。特にスクリプト言語ではビルドを行う必要がないため、この手法をよく用います。

ECSにデプロイする場合はソースコードを含めないわけにはいきませんから、デプロイ用のイメージにはソースコードを同梱し、Perl処理系にそれを読み込んでもらいます。

そのため、ローカル開発用とデプロイ用とで2つのDockerイメージを用意します。まずローカル開発用にソースコードを含めないDockerイメージを用意し、それをベースとしてソースコードをコピーしたデプロイ用のDockerイメージを作成し、タグを分けるというのが定石です。

今回はECSにPerlアプリケーションをデプロイして動作させることが目的ですから、先ほどはすべてのソースコードをDockerイメージに同梱しました。

なお、Dockerイメージにソースコードを含めるかどうかについては、坪内佑樹さんによる本連載第34回DockerによるPerlのWebアプリケーション開発でより詳しく解説されています。

CPANモジュールをイメージに含める? 含めない?

たいていのPerlアプリケーションは複数のCPANモジュールに依存しているので、Dockerイメージにソースコードを含める場合、これらのCPANモジュールをインストールする必要があります。

どのCPANモジュールを使うかは、サービスの中で比較的変更の少ない箇所です。そのため、CPANモジュールはコンテナで管理する「環境」とみなせ、Dockerfile中でcartonを使い、DockerイメージにCPANモジュールを含めるアプローチが可能です。

今回は、Dockerfile中でcarton install --deploy mentを実行し、cpanfile.snapshotをもとにモジュールをインストールすることで、DockerイメージにCPANモジュールを含めることにします。cpanfile.snapshotは、cpanfile(ここでは省略)に記述された依存関係のもとで必要になるすべてのライブラリとバージョンを記載した、ロックファイルと呼ばれるファイルです。このファイルはのちほどGitHub Actionsで自動生成します。

別解:ENTRYPOINTでCPANモジュールをインストールするアプローチ

イメージのビルド時にCPANモジュールをインストールするのではなく、DockerfileのENTRYPOINTにシェルスクリプトを設定し、そこで動的にCPANモジュールをインストールするアプローチも考えられます。cpanfile.snapshotを書き換えてもイメージのビルドをやりなおす必要がなくなるため、頻繁にライブラリを入れ替える開発の初期段階であれば有効なテクニックですが、コンテナの状態が一意に定まらなくなるため、プロダクション環境には不向きです。

Server::Starterは不要

PerlでWebアプリケーションを書く場合は、Server::Starterをよく用います。Server::Starterの仕事は、PSGIサーバが停止してしまった場合に自動で再起動したり、処理中のリクエストを処理しきってからプロセスを入れ替えるgraceful restartを行うことです。ECSはこういった自動再起動やgraceful restart機能も実装可能なため、ECSを利用する際はServer::Starterを利用する必要はありません。

<続きの(3)こちら。>

WEB+DB PRESS

本誌最新号をチェック!
WEB+DB PRESS Vol.130

2022年8月24日発売
B5判/168ページ
定価1,628円
(本体1,480円+税10%)
ISBN978-4-297-13000-8

  • 特集1
    イミュータブルデータモデルで始める
    実践データモデリング

    業務の複雑さをシンプルに表現!
  • 特集2
    いまはじめるFlutter
    iOS/Android両対応アプリを開発してみよう
  • 特集3
    作って学ぶWeb3
    ブロックチェーン、スマートコントラクト、NFT

おすすめ記事

記事・ニュース一覧