概要
とある作業にてAWS lambdaで今度はperlを動かすことになりました。
その際、perlのライブラリ/usr/share/perl5などが見えなかったり、コマンドが実行できなかったりしたので、いろいろ調べたことをメモしておきます。
用意されているランタイム使えば余計な苦労しないのにね
結論
さっさと結論だけ記載すると、以下の環境のカーネルとlibcなどの基本的なライブラリが乗っているものになります。
- Amazon Linux
- イメージ – amzn-ami-hvm-2018.03.0.20181129-x86_64-gp2
- Linux カーネル – 4.14.154-99.181.amzn1.x86_64
- ami-00a5245b4816c38e6
注意点として、このイメージは、EC2インスタンスを作るときに、クイックスタートとして表示される、Amazon Linuxのイメージとは別物ということです。
- Amazon Linux AMI 2018.03.0 (HVM), SSD Volume Type
- ami-02ddf94e5edc8e904
EC2でカスタムランタイム用のコードを作ってアップしたかった
カスタムランタイムを作成するにあたって、開発環境も含め、今回はAWS上のサービスに構築しました。
EC2でコードを開発、zipにまとめてawscliでlambdaにコードをアップロードする、まあ標準と思われる方法を使おうと思いました。
自分のやった間違い
以下、公式マニュアルに記載があります。
AWS Lambda ランタイム
ここに、ランタイムのイメージが以下2種類あり、それぞれランタイムのバージョンごとに分かれていることがわかります。
- Amazon Linux
- Amazon Linux 2
| 名前 | 識別子 | AWS SDK for Python | オペレーティングシステム |
|---|---|---|---|
| Python 3.8 | python3.8 | boto3-1.10.34 botocore-1.13.34 | Amazon Linux 2 |
| Python 3.7 | python3.7 | boto3-1.10.34 botocore-1.13.34 | Amazon Linux |
さて、ここでカスタムランタイムの開発用にEC2のイメージを作るときに、クイックスタートの候補で、以下のようなものが羅列されると思います。
- Amazon Linux 2 AMI (HVM), SSD Volume Type
- Amazon Linux AMI 2018.03.0 (HVM), SSD Volume Type
カスタムランタイムのマニュアルでは、オペレーティングシステムの指定が見当たらなかったので、Amazon Linux 2 AMI (HVM), SSD Volume Typeを選んで作ってしまいました。
２だとダメなところ
そもそも、２はカーネルバージョンが違うようです。このため、libcなどのバージョンが異なり、lambdaにアップロードしたアプリケーションがそもそも起動すらしませんでした。
ここで、最初の間違いに気づき、インスタンスをAmazon Linux AMI 2018.03.0 (HVM), SSD Volume Typeに変更します
コマンドもなにも見つからない
さて、カーネルバージョンについてはこれで一致し、コンパイルしたアプリケーションが動くようにはなりました。
しかし、開発環境では実行できるコマンド、perlやawsが見つからないし、perlのコマンドをもっていってもライブラリが全く見つからなかったりしました。
そのため、足りないのを探すという作業をしつつ、最終的にはあきらめてすべてアップロードするコードの中にコピーすることとなりました。
振り返りつつ、次はうまくやるために
ちゃんと指定されたイメージから開発用インスタンスを立ち上げましょう
再掲
- Amazon Linux
- イメージ – amzn-ami-hvm-2018.03.0.20181129-x86_64-gp2
- Linux カーネル – 4.14.154-99.181.amzn1.x86_64
- ami-00a5245b4816c38e6
そのうえで、perlのパッケージコントロールcpanmやpythonのパッケージコントロールpipなどを活用し、追加したライブラリはできるだけ手元に作成したフォルダに保存し、コードとして一緒にアップロードできるように管理することが必要です。
最後に要望
せめてawsコマンドくらいlambda上で標準で使えてもいいんじゃないかなという素人考えな要望で締めたいと思います。