Lambda|Lambdaレイヤー:Dockerで簡単作成
知識は武器とかけまして、レゴブロックと解く、その心は――
今日もKnowledge Oasisへようこそ
案内人はkoふみです
本日のテーマは『LambdaレイヤーをDockerで簡単作成』
はじめに
AWS CloudShell のデフォルト Python は Python 3.9 で、AWS Lambda の最新ランタイムである Python 3.13 とはマイナーバージョンが異なり、CloudShell 上で直接レイヤーをビルドすると動作検証でトラブルが起きやすいです。
そこで Docker コンテナをビルダーとして使うことで、CloudShell でも Lambda 実行環境とまったく同じ Python バージョンの環境を作り、バージョン差分を吸収しつつ手軽にレイヤーを生成できます。
この記事では、CloudShell での Docker 環境の確認から、レイヤーの基礎、Dockerfile の準備・実行、ZIP 化、CLI でのデプロイ手順、そして実行後のクリーンアップまでを順に解説します。
対象読者
- AWS CloudShell 上で Lambda レイヤーを作成したいがバージョン差分に悩む方
- Docker 未経験でもコンテナを使って一貫したビルド環境を構築したい方
- CI/CD パイプラインにレイヤー生成を組み込みたい方
Lambda レイヤーとは
Lambda レイヤーは、複数の関数で共通の依存ライブラリやコードを共有できる配布メカニズムです。
レイヤーを ZIP 形式で作成し、関数実行時には /opt
配下にマウントされることで、個別の関数パッケージに同じライブラリを含める必要がなくなります。
これによりデプロイパッケージは軽量化され、ライブラリのアップデートも一元管理できるようになります。
Python バージョンのギャップ:Lambda vs. CloudShell
AWS Lambda は python3.13
ランタイムを公式サポートしており、ランタイム識別子を python3.13
に変更するだけで利用できます。
一方 AWS CloudShell は Amazon Linux 2023 ベースで「Python 3」を提供しているものの、マイナーバージョンは OS 標準のリポジトリ依存で、3.13 は含まれていません。
この差異があると、CloudShell 上でビルドしたバイナリが Lambda 実行環境で動作しない恐れがあります。
CloudShell の Docker 環境確認
AWS CloudShell には初期状態で Docker がインストールされています(docker --version
コマンドで確認可能)。
大きなイメージや多数のイメージを保持すると容量制限に達する可能性があるため、不要なイメージは docker image prune -f
で定期的に削除しましょう。
Docker を使ったレイヤー作成の全体像
-
プロジェクト準備:
Dockerfile
とrequirements.txt
を用意 -
ビルド:Docker コンテナ内で依存を解決し、
/opt/python
配下にインストール -
ZIP 化:ENTRYPOINT/WORKDIR 設定で自動的に
layer.zip
を/layers
に出力 - デプロイ:AWS CLI でレイヤーをアップロード
- クリーンアップ:不要なコンテナ/イメージを削除しディスクを解放
このワークフローにより、CloudShell/ローカル環境の差異を排除し、一貫したビルドが可能になります。
Dockerfile 解説:Python 3.13 環境を構築する手順
プロジェクト構成と requirements.txt の配置
プロジェクトルートに Dockerfile と requirements.txt を同階層で配置します。典型例:
your-project/
├── Dockerfile
├── requirements.txt
└── layers/ # ビルド後の layer.zip を出力
requirements.txt にはレイヤーに含めたいパッケージを改行区切りで記載します。例:
requests>=2.31.0
numpy==1.25.0
Dockerfile 本体
# ビルド用ベースイメージに Lambda Python 3.13 を指定(Amazon Linux 2023)
FROM public.ecr.aws/lambda/python:3.13 AS builder
# 作業ディレクトリを /work に設定
WORKDIR /work
# レイヤーZIP作成用に zip コマンドをインストール
RUN dnf install zip -y
# uv をインストール
RUN dnf install tar -y
RUN curl -LsSf https://astral.sh/uv/install.sh | sh
# ホストの requirements.txt をコンテナ内 /work にコピー
COPY requirements.txt .
# Lambda が期待するディレクトリ (/opt/python/lib/python3.13/site-packages) に依存パッケージをインストール
RUN ~/.local/bin/uv pip install -r requirements.txt --target /opt/python/lib/python3.13/site-packages/
# レイヤーZIP を /layers に自動出力するための設定
# ・作業ディレクトリを /opt に変更
# ・ENTRYPOINT で zip コマンドを実行
WORKDIR /opt
ENTRYPOINT ["zip", "-r", "/layers/layer.zip", "python"]
-
WORKDIR /work
:依存リストを扱うディレクトリ -
RUN dnf install zip -y
:ZIP化ツールを追加 -
COPY requirements.txt .
:依存リストを取得 -
RUN \~/.local/bin/uv pip install …
:依存をインストール -
WORKDIR /opt
:作業ディレクトリに移動 -
ENTRYPOINT
:コンテナ起動時に自動で layer.zip を生成
Dockerfile の実行方法
以下の手順で、2 コマンドだけでレイヤーを作成&取り出しできます。
# ① イメージビルド
docker build -t lambda-layer-builder .
# ② コンテナ実行(layer.zip を layers/ に出力)&不要リソースの後片付け
docker run --rm -v "$(pwd)/layers":/layers lambda-layer-builder
docker rmi lambda-layer-builder
-
docker build
:Dockerfile
からlambda-layer-builder
イメージを作成 -
docker run
:ENTRYPOINT によりlayers/layer.zip
を生成 -
rmi lambda-layer-builder
:イメージを削除
これだけで、Docker 未経験の方でも手軽にレイヤーが作れ、ビルド後の不要リソースもクリーンアップできます。
レイヤーのパッケージングとデプロイ
生成された layers/layer.zip
は、AWS CLI の publish-layer-version
コマンドでアップロードします。
aws lambda publish-layer-version \
--layer-name my-layer \
--zip-file fileb://layers/layer.zip \
--compatible-runtimes python3.13
-
--compatible-runtimes python3.13
:対象ランタイムを指定 - 複数ランタイムを指定することも可能
まとめ
今回は、CloudShell の Docker 環境を活用し、バージョンギャップを吸収しながら AWS Lambda レイヤーを簡単に作成する方法を解説しました。
Dockerfileとコマンドを覚えておけば、requirements.txtを書き換えるだけで別の AWS Lambda レイヤーを作ることができるので便利です。
知識のひとつひとつは小さなレゴブロック
でも、組み合わせれば世界を変えるアイディアをカタチにする武器になる!
またKnowledge Oasisでお会いしましょう
案内人はkoふみでした
Discussion