CODE TO CLOUDTM SECURITYThe future of cloud security is Precision AI™.Radically simplify cloud and application security.
この記事はSelenium/Appium Advent Calendar 2018に参加した記事です。 新機能のAWS Lambda Layersが発表されました。 これまでAWS Lambdaのコードファイルが50MBぎりぎりだとか悩まなくてもよくなりますし、コードを更新するたびに重たいアップロードをしなくてもよくなります。 AWSもストレージ容量が減らせるのではないでしょうか。 LambdaでChrome Headlessドライバを使ってスクレイピングをしているのですが、コードのzipファイルが48MBとかなので、制限ぎりぎりです。 これ以上何かを増やすと制限にひっかかります。 そして、ファイルが大きすぎてマネジメントコンソールから直接コードが編集できませんし見えません。 そこで登場したAWS Lambda Layers。 これは使うしかないでしょうということで、試してみました。 過去
AWS Lambda ( Typescript ) の Lambda Layers 活用、開発、デプロイ考察 動機が2つあります。 Lambda Function を TypeScript で実装したい 2018年の re:Invent で発表された AWS Lambda Layers を使ってみたい TypeScript で これまでサーバーレスの業務では、Lambda Function をPythonで開発することが多かったのですが、どうしても型が欲しくなりました。特に、Lambda Function は AWS SDK を使うシーンが多いため、このパラメータや戻り値の型情報をドキュメントから得るか、コード補完できるかは、大きな違いです。いくつか選択肢がありますが TypeScript を選びました。 AWS Lambda Layers ちょっと触ってみたかったというのが正直なところで
Serverless Frameworkのserverless-layersプラグインを使って超お手軽にnode_modulesをAWS Lambda Layers化する Serverless Frameworkで手軽にLambda Layersを扱えないかなということで探していたところ、serverless-layersというプラグインを見つけました。このプラグインを利用することで、依存モジュールを簡単にLambda Layersとしてデプロイできます。 こんにちは。サービスグループの武田です。 AWS Lambdaを使ってサーバーレスなアプリケーションを開発する際に、Serverless Frameworkが非常に便利で重宝しています。 さてLambdaをNodeで開発する場合、依存モジュール(node_modules)の扱いにはいくつか選択肢があります。その中で、現在ではLambda
Lambda Layersで解決できること Lambdaの実行環境には追加ライブラリが存在しないため、ライブラリを使用する際はデプロイパッケージにライブラリを含める必要がありました。 しかしAWS Lambda Layersを使用することで、ライブラリなどの共通コンテンツをレイヤーとして作成することで、パッケージにライブラリを含める必要がなくなりました。 Lambda Layersとは、複数のLambda関数で外部ライブラリやビジネスロジックを共有できる仕組みです。 イメージはこんな感じです。 使用するライブラリや共通のビジネスロジックをZIPアーカイブし、Layerに追加することができます。 デプロイパッケージの容量を少なくすることができるためLambdaのソースコードの管理が楽になります。 また依存関係をインストールしてパッケージ化する際に発生するエラーを回避することや、ライブラリのビ
こんにちは、最近のクラウドシステム開発は、ほぼサーバーレス・アーキテクチャで対応している takanorig です。 この記事は Serverless Advent Calendar 2018 の9日目の記事です。 昨日は、システムテスト自動化カンファレンス2018で、「マイクロサービスのテスト自動化 with Karate」という内容で発表をしてました。 上記はテスト自動化に関する内容ですが、こちらも、サーバーレス・アーキテクチャの関連があって利用を始めたもの。 当初、このKarateを使っての内容を書こうかと思っていたのですが、今回のタイトルの内容の方が自分的に優先度が高くなったので、内容を切り替えての投稿です。 はじめに 先日のre:Invent2018で AWS Lambda Layers が発表されましたが、「これはPJで早速導入したい」と思った内容でした。 社内のプロジェクトで
SAM CLI の基本的な使い方については、以前 Qiita にあげたのでこちらも参照いただければと思います。 AWS SAM CLI 再入門 2019.12 https://qiita.com/hayao_k/items/7827c3778a23c514e196 簡単な例 sam init で作成できる Python 3.8 の Hello World Example を例に考えます。 $ sam init --runtime python3.8 $ cd sam-app $ tree . ├── events │ └── event.json ├── hello_world │ ├── app.py │ ├── __init__.py │ └── requirements.txt ├── README.md ├── template.yaml └── tests └── unit ├─
Lambda Layers へデプロイする流れ Lambda Layers へ node_modules をデプロイするにあたり、ベースとなるプロジェクトをcloneしておきます。これは私が自分の手元で AWS CDK のワークショップ を実施してプッシュした状態のリポジトリです。 git clone git@github.com:cm-wada-yusuke/eval-cdk.git -b v0.1.0 ワークショップによって構築されるアプリケーションは、 AWS CDK Stacks: エンドポイントにアクセスすると DynamoDB のカウントを増やすアプリケーション AWS CDK Stacks: DynamoDB のテーブルビューア( cdk-dynamo-table-viewer ) Lambda Function のソースコード というコンポーネントで構成されています。これら
はじめに こんにちは、CX事業本部、re:Invent 2022 現地参加組の田中孝明です。 対応内容 Amazon Inspector は脆弱性管理サービスで、Amazon EC2、Amazon ECRに存在するコンテナ イメージを継続的にスキャンします。 今日からAWS Lambda関数と AWS Lambda Layers に対応しました。 今まで、AWS Lambda を脆弱性診断したい場合は、AWS とサードパーティツールを使用する必要がありました。 この機能をアクティブ化すると、Amazon Inspector は選択したアカウントを自動的にスキャンします。 Amazon Inspector は AWS のネイティブ サービスであるため、AWS Lambda または AWS Lambda Layers にライブラリまたはエージェントをインストールする必要がありません。 Java
既存のLambda FunctionにLambda Layersを導入し、AWS SAMで管理する(Node.js) Summary axiosなどのモジュールに依存した既存のNode.js Lambda Functionがある このfunctionで使用しているモジュールをAWS Lambda Layersに移行し、aws-sam-cliでデプロイする 既存functionで個別にnpm installしていたモジュールを削除し、デプロイしたLayerを使用するように変更する Layer移行後も既存functionが sam local invoke コマンドでローカルで実行できる事を確認する Layerを使うように変更した既存functionをデプロイする 移行した結果 既存functionのサイズを半分以下に削減できた 既存functionの実行時間を半分以下に削減できた AWS S
const lambda = require('@aws-cdk/aws-lambda') const layer = new lambda.LayerVersion(this,"theLayer",{ code: lambda.AssetCode.fromAsset("layers/app-base"), }) こうすると、ローカルの ./layers/app-base/file が Lambda 環境では /opt/file としてアクセス可能になります。 同様に、フォルダが含まれる場合は ローカルの ./layers/app-base/path/to/file が Lambda 環境では /opt/path/to/file としてアクセス可能になります。 これを利用することで、Lambdaの実装コード中の記述としては require("/opt/path/to/file") となりま
AWS Compute Blog Working with AWS Lambda and Lambda Layers in AWS SAM The introduction of serverless technology has enabled developers to shed the burden of managing infrastructure and concentrate on their application code. AWS Lambda has taken on that management by providing isolated, event-driven compute environments for the execution of application code. To use a Lambda function, a developer ju
AWS Lambda Layers If you are using AWS as a provider, all layers inside the service are AWS Lambda layers. Configuration All of the Lambda layers in your serverless service can be found in serverless.yml under the layers property. # serverless.yml service: myService provider: name: aws layers: hello: path: layer-dir # required, path to layer contents on disk name: ${sls:stage}-layerName # optional
Node.jsを使用していると必ずといっていいほどnpmコマンドでライブラリをダウンロードしてくると思います。 npmでダウンロードしたライブラリをLambda Layersへ登録しておけば、Lambda本体はかなり軽く作成することができます。 今回はAmazon Echoのask-sdkを例にLayersへ登録して使ってみます。 npmでダウンロード ローカルPC上で"nodejs"フォルダを作ります。 最後に説明しますが"nodejs"という名前には意味があります。 "nodejs"フォルダ内でnpmコマンドを実行します。 cd nodejs npm install ask-sdk "nodejs"をzipファイルへ圧縮します。 中身ではなく"nodejs"フォルダごと圧縮するのを注意してください。 Layersへ登録 AWS の管理コンソールからLambda>Layersを開いて"レ
概要 AWSのlambda関数で、外部のライブラリを実行したい場合、昔は、デプロイパッケージに、利用するコードを全て含めてやる必要がありました。 ただ、pandasやscikit-learnなどの重量級のライブラリの場合、毎回アップロードするのは、きついものがあります。 例えば、pandas(依存関係のあるnumpyなども含む)だと、圧縮状態で35Mbyteほどあります。 そこで、AWS Lambda layersの出番です。 これを使うことで、外部ライブラリのアップロードは、1回で済む様になり、自分で書いた部分のみを更新していけば良いことになります。 また、他のlambda関数でも使い回し可能です。 docs.aws.amazon.com 手順 以下、pandasを例にした手順です。 とりあえず、lambda関数の実行環境を確認します。 19年2月現在は、以下の通りでした。 Python
Summary Node.jsのLambdaで、レイヤー用のスタックと、それを利用するFunctionスタックのAWS SAMによる作成を以下の手順で実施 レイヤーのスタックをデプロイ レイヤーを利用するLambda Functionのスタックで、sam local invoke によるローカル実行で動作確認 レイヤーを利用するLambda Functionのスタックをデプロイ レイヤーのスタックでは、<テンプレートのContentUriで指定したフォルダ>/nodejs/node_modules というフォルダにライブラリがインストールされるようにフォルダを構成する sam deploy を --guided オプション付きで実行するとデプロイ成果物配置用のS3バケットを自動で作成(既にあれば再利用)してくれるが、このバケットは "バージョニング有・ライフサイクル未設定" で作成されるの
はじめに こんにちは。みんなのウェディングのインフラエンジニア横山です。 この記事はくふうカンパニーアドベントカレンダーの4日目になります。 今回は、re:Invent2018で発表されたAWS Lambda LayersをPythonで使ってみたのでまとめていきます。 AWS Lambda Layersとは複数のLambda関数で共通利用したい処理をまとめておける機能です。 Lambdaを書いていると、Slackへの通知処理など複数のLambda関数で同じような処理を書いていることに気づくと思います。 AWS Lambda Layersを使うと、こういった処理をLambda関数から切り離し、Layerとすることで、複数のLambda関数で再利用することが可能になります。 使い方 まずはlayerとなる関数を作成します。ファイル名はなんでも良いですが、pythonディレクトリを作成してその
Serverless Framework+TypeScriptのプロジェクトでnode_modulesをAWS Lambda Layers化しよう Serverless Framework+TypeScriptのプロジェクトで、serverless-layersプラグインを使ってみました。簡単に依存モジュールをLambda Layersとしてデプロイできます。 こんにちは。サービスグループの武田です。 先日Serverless Framework+JavaScript環境に、serverless-layersプラグインを導入し、お手軽にnode_modulesをLambda Layers化しました。 Serverless Frameworkのserverless-layersプラグインを使って超お手軽にnode_modulesをAWS Lambda Layers化する 今回は同様のことを、
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く