Perl Hackers Hub

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

この記事を読むのに必要な時間:およそ 1.5 分

前回の(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.118

2020年8月24日発売
B5判/176ページ
定価(本体1,480円+税)
ISBN978-4-297-11566-1

  • 特集1
    開発環境の整備,効果的な議論,評価制度
    実践リモートワーク
    オフィスに集まれない課題の解消方法
  • 特集2
    Pythonデータ可視化入門
    COVID-19/家計調査/財政データで実践!
  • 特集3
    ツールで簡単!
    はじめての脆弱性調査
    Rails,nginx,サブドメイン,DB,OpenSSL

著者プロフィール

野口啓介(のぐちけいすけ)

大学在学中に『はてなサマーインターン』に参加し,卒業後の2016年に株式会社はてなに入社。型のパワフルさを活かした開発が得意。

入社後はScalaによる『はてなブックマーク』のリプレイスメントプロジェクトや,『はてなブログ』の開発に参加。

アプリケーションエンジニアとしてバックエンド部分を主に担当しつつも,趣味で運用している自宅サーバで培ったインフラ寄りの知識でチームをサポートしている。

2018年8月より同社のマンガビューワの開発に携わっている。

GitHub:windymelt
Twitter:@windymelt
Hatena:id:Windymelt