[budget alerts]Serverless FrameworkとAWS Budgetsで日次の利用料金が想定より高かったらSlackへ通知する(Cost Anomaly Detectionは採用見送り)

1.この記事を書こうと思った背景 AWSの利用料金が想定以上に高くてびっくりしたことがあった AWSの利用料金が想定より高くなったら検知するようにしようと決意したい ↓こういったことが起きないためにも、、 AWSでやらかして3桁万円請求された話 - Qiita 無事できたので、この記事でどうやったか?またいくつか検知する方法があるなかでどういった選定基準を持ったか?書いていきたい ※ サンプルコードはこちら https://github.com/gkzz/serverless-aws-budget-alerts-to-slack 2.前提 AWSの利用料金が想定より高くなったら検知する方法は2022/02/24時点で3種類あり、この記事ではbudget alertsを使った方法を採用している。ただし、各サービスの仕様変更やアップデートなどにより今後は他2つの方法を採用した方がいいということも。 3.環境情報 Serverless Frameworkのバージョンは3.2 $ grep VERSION= /etc/os-release VERSION="20.04.3 LTS (Focal Fossa)" $ sls --version Framework Core: 3.2.0 Plugin: 6.0.0 SDK: 4.3.1 $ npm --version 6.14.16 $ nodejs --version v10.19.0 Serverless Frameworkでは環境変数としてAWSのRegionとSlackのincoming webhook urlを使っている 環境変数の使い方や適用方法については以前書いたのでそちらを参照してほしい Serverless Framework 3.xでserverless-dotenv-pluginを使った環境変数の読み込みができなかったのでserverless.ymlを修正した | gkzz.dev  # ....

February 24, 2022 · 5 min · gkzz

Serverless Framework 3.xでserverless-dotenv-pluginを使った環境変数の読み込みができなかったのでserverless.ymlを修正した

1.この記事を書こうと思った背景と書いていきたいこと 1-1.背景 先日、Serverless Frameworkがv3にメジャーアップデートされたことは記憶に新しい Serverless Framework V3 Is Live! そんなServerless Frameworkを2系から3系に引き上げてserverless-dotenv-pluginを使って環境変数が読み込もうとしたところ、以下のようなエラーを引いてしまった $ sls deploy Environment: linux, node 14.19.0, framework 3.2.0, plugin 6.0.0, SDK 4.3.1 Docs: docs.serverless.com Support: forum.serverless.com Bugs: github.com/serverless/serverless/issues Error: Cannot resolve serverless.yml: Variables resolution errored with: - Cannot resolve variable at "custom.REGION": Value not found at "env" source, - Cannot resolve variable at "custom.FAVORITE": Value not found at "env" source このエラーはserverless.ymlと同じ階層のdotenvファイルに書かれた環境が読み込めないというもの 書き方はのドキュメントに詳しく書かれているのでそちらを参照してほしい。ただし、2系で使える書き方であり、3系に対応した書き方はこれから紹介する書き方を採用する必要がある。 Serverless Framework: Plugins エラーを引いたときに使ったserverless....

February 14, 2022 · 2 min · gkzz

[Github Actions]repository_dispatchとworkflow_dispatchの使い分けや書き方の違いをまとめてみた

1.この記事で達成したいこと repository_dispatchとworkflow_dispatch の使い分けや書き方の違い、共通点や相違点を整理したい 結局どっちを使うのがいいのか?判断基準を見つけたい そもそもrepository_dispatchとworkflow_dispatchはどういうときに使うのか? アプリケーションリポジトリでイメージをレジストリにpushした後、マニフェストリポジトリでそのイメージタグをマニフェストに反映させたい 使いまわしているWorkflowを呼びたい このようなときに使えるのがGithub Actionsでは2つ提供されている。それが冒頭に書いた、repository_dispatchとworkflow_dispatchである。 この記事の結論 長くなってしまったので、冒頭で結論を書く。 repository_dispatchとworkflow_dispatchの使い分けの判断基準の一つは、実行時に参照するWorkflowのブランチをデフォルトブランチ以外としたいケースがあるかどうか? デフォルトブランチ以外のWorkflowのファイルを参照してWorkflowを実行したい場合は、workflow_dispatchを選ぶしかない 2.サンプルコードで使っているリポジトリ https://github.com/gkzz/actions-playground 起点となるWorkflow(実行トリガーはpush)のリポジトリ https://github.com/gkzz/actions-dispatch-playground 起点となるWorkflowからkickされるWorkflow(実行トリガーはrepository_dispatch)のリポジトリ 3.環境情報 ローカル始めバージョンを書いておく必要があるものはない 使うActionのバージョンについては後述するWorkflowを参照してほしい 4.repository_dispatchとworkflow_dispatchの共通点や相違点 共通点 どちらも以下の権限を有する Personal Access Token が必要 repo:write 相違点 workflow_dispatchのみ、GUIから実行できる 実行場所はGithubの実行先のリポジトリのActionタブ pushしたWorkflowからdispatchする際のパラメーターの渡し方が違う(詳細は4-1参照) パラメーターの受け取り方が違う(詳細は5-1及び5-2参照) repository_dispatchのみ、event-typeを使ってWorkflowを実行するか制御できる repository_dispatchはevent-typeに応じて実行するかどうか決めることができる workflow_dispatchの場合、Workflowをkickされたら実行されてしまうのでkickしたWorkflowから渡されるパラメータの値によってjobを実行するように制御することはできる repository_dispatchのみ、Workflowはデフォルトブランチを参照して実行する 4-1.pushしたWorkflowからdispatchする際のパラメーターの渡し方 ここでは、curlコマンドでrepository_dispatchとworkflow_dispatchのWorkflowを実行しながらパラメータの渡し方の違いを確認しよう。 とりわけ、POSTする接続先URLと -d (--data)オプションで渡しているPOSTする値の書式はおさえておきたい。...

January 31, 2022 · 3 min · gkzz

[addnab/docker-run-action]GitHub Actionsでyqのコンテナイメージを使ってマニフェストを更新する

1.この記事で達成したいこと GitHub Actionsでyqのコンテナイメージを使ってマニフェストを更新したい yqはPythonのパッケージマネージャのpipでも扱うことが出来るけどコンテナイメージで扱うほうが都合がよさそうなのでコンテナイメージでがんばりたい コンテナイメージで扱うというのは、docker runコマンドでyqのイメージをスポットで使う感じ yqの使い方についてはjqのyaml版と思って大丈夫。詳細は以前書いた記事を参考にしてほしい。 yqコマンド(jq wrapper for YAML)使い方備忘録 $ docker run --rm -v "$PWD:$PWD" -w="$PWD" \ --entrypoint yq linuxserver/yq \ <yqコマンド> GitHub Actions上でDockerコンテナイメージを扱う方法と注意点 やることは addnab/docker-run-action を使うだけ 基本的な使い方はaddnab/docker-run-actionの上記のリンクにサンプルコードを添えて書かれている しかし、docker runコマンドのときのように同アクションを使おうとすると、ホストとコンテナ間でマニフェストが置かれたディレクトリをマウントするところでつまずいた そこで、この記事では特に同アクションを使う際のホストとコンテナ間でディレクトリをマウント方法する方法について、yqのコンテナイメージを使って解説していきたい 2.前提 addnab/docker-run-actionの検証リポジトリはpublic public/private問わず、同Actionsを使う際の注意点は同じはずだけど念のため書いておく yqは以下のとおり2種類あるが、ここでは https://hub.docker.com/r/linuxserver/yq を扱う ↓この記事で使うyq Github https://github.com/kislyuk/yq https://github.com/mikefarah/yq Docker Image https://hub....

January 30, 2022 · 3 min · gkzz

asdfでkubectlのバージョンを切り替えながらasdfとそのプラグインの設定方法を理解する

1.この記事で達成したいこと asdfとそのプラグインを設定する方法が頭の中でごちゃごちゃしていた。たとえば、、。 asdf plugin-addとasdf installはどっちからコマンド実行するの? 既にプラグインはをインストールしているか?確認するのはどうやるの? そこで実際に以下のasdfのプラグインを使いながら、その設定方法を理解したい kubectl asdf-community/asdf-kubectl: Kubectl plugin for the asdf version manager 2.はじめに そもそもasdfとはなにか?という説明は公式ドキュメントに譲りたいが、ひとことでいえば バージョン管理ツール である バージョン管理の類似ツールを挙げるとすれば、pythonのvirtualenvはそのひとつであろう。相違点はバージョン管理の対象がひとつだけか複数か。(virtualenvの場合はpythonのみのひとつだけ。) asdfでバージョンを管理するためには、asdf自体のインストールすることに加えて、バージョン管理したいツールに対応したプラグインもインストールする必要 がある 3.環境情報 $ grep VERSION= /etc/os-release VERSION="20.04.3 LTS (Focal Fossa)" $ asdf --version v0.10.0-0f99d0a 4.asdf自体のインストール asdfのドキュメントに従って進めればよいが、そのインストール方法はいくつかある 今回採用した方法はasdfのリポジトリのブランチを指定してクローンするという方法 指定したリリースブランチは、release-v0.10.0 $ git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch release-v0.10.0 $ tail ~/....

January 13, 2022 · 2 min · gkzz