Posts

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.yml frameworkVersionを2から3に修正しただけ service: src frameworkVersion: '3' #frameworkVersion: '2' custom: dotenv: basePath: ./ REGION: ${env:REGION} nodejsVer: nodejs12.x memorySize: 256 timeout: 900 TZ: Asia/Tokyo FAVORITE: ${env:FAVORITE} provider: 略 plugins: - serverless-dotenv-plugin - serverless-offline functions: 略 1-2.この記事で書いていきたいこと そこで今回は以下2点について書いておきたい。 ...

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する値の書式はおさえておきたい。 repository_dispatch 接続先URLは https://api.github.com/repos/<REPOSITORY_OWNER>//dispatches $ curl -X POST \ -H "Accespt: application/vnd.github.v3+json" \ -H "Authorization: token <PAT_REPOSITORY_DISPATCH>" \ https://api.github.com/repos/gkzz/actions-dispatch-playground/dispatches \ -d '{"event_type": "sample-event", "client_payload": {"hoge": "hogevalue"}}' https://docs.github.com/en/rest/reference/repos#create-a-repository-dispatch-event ...

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.docker.com/r/linuxserver/yq https://hub.docker.com/r/mikefarah/yq 3.環境情報 ローカル始めバージョンを書いておく必要があるものはない 使うActionやyqのイメージのバージョンについては後述するWorkflowを参照してほしい 4.この記事で扱うサンプルコード(つまずいたところは解決済) yqのコンテナイメージで更新対象のマニフェスト(manifests/deployment.yml.tmpl) 書き換え箇所はマニフェストのごく一部なので抜粋する --- apiVersion: apps/v1 kind: Deployment metadata: # 略 spec: replicas: 3 selector: matchLabels: app: sampleapp template: metadata: labels: app: sampleapp spec: affinity: # 略 containers: - name: sampleapp image: <REGISTRY>/<CONTAINER_IMAGE>:<IMAGE_TAG> ports: - containerPort: 80 yqのコンテナイメージを使うWorkflow(.github/workflows/mod_manifest.yml) jobs: main: runs-on: 'ubuntu-20.04' env: MANIFEST_PATH: 'manifests' steps: - name: Modify image tag uses: addnab/docker-run-action@v3 with: ## yqのイメージを指定 image: linuxserver/yq:2.13.0 ## docker runコマンドで渡していたオプションを書く ## ">"を使い、適宜改行する ## -vオプションの使い方はやや注意なので後述 options: > --rm -v ${{ github.workspace }}/${{ env.MANIFEST_PATH }}:/opt/${{ env.MANIFEST_PATH }} -w=/opt/${{ env.MANIFEST_PATH }} --entrypoint yq shell: bash run: > yq -ry '.spec.template.spec.containers[0].image |="'${{ secrets.REGISTRY }}'/'${{ secrets.CONTAINER_IMAGE }}':'${{ github.sha }}'"' /opt/${{ env.MANIFEST_PATH }}/deployment.yml.tmpl > /opt/${{ env.MANIFEST_PATH }}/deployment.yml 5.addnab/docker-run-actionでディレクトリをマウントする間違ったやり方 -vオプションで指定するホスト側のパスを「リポジトリのルートディレクトリからマニフェストの 相対パス 」とする - name: Modify image tag uses: addnab/docker-run-action@v3 with: ## yqのイメージを指定 image: linuxserver/yq:2.13.0 ## docker runコマンドで渡していたオプションを書く ## ">"を使い、適宜改行する ## -vオプションで指定するホスト側のパスを「リポジトリのルートディレクトリからマニフェストの相対パス」とする options: > --rm -v ${{ env.MANIFEST_PATH }}:/opt/${{ env.MANIFEST_PATH }} -w=/opt/${{ env.MANIFEST_PATH }} --entrypoint yq shell: bash run: > yq -ry '.spec.template.spec.containers[0].image |="'${{ env.REGISTRY }}'/'${{ env.CONTAINER_IMAGE }}':'${{ github.sha }}'"' /opt/${{ env.MANIFEST_PATH }}/deployment.yml.tmpl > /opt/${{ env.MANIFEST_PATH }}/deployment.yml 実行するとエラーとなってしまう、、 yq: error: argument files: can’t open ‘/opt/manifests/deployment.yml.tmpl’: [Errno 2] No such file or directory: ‘/opt/manifests/deployment.yml.tmpl’ エラーログ抜粋 Run addnab/docker-run-action@v3 with: image: linuxserver/yq:2.13.0 options: --rm -v manifests:/opt/manifests -w=/opt/manifests --entrypoint yq shell: bash run: yq -ry '.spec.template.spec.containers[0].image |="'your_registry'/'your_container_image':'xxxxxxxxxxxxxx'"' /opt/manifests/deployment.yml.tmpl > /opt/manifests/deployment.yml env: MANIFEST_PATH: manifests REGISTRY: your_registry CONTAINER_IMAGE: your_container_image 略 Unable to find image 'linuxserver/yq:2.13.0' locally 2.13.0: Pulling from linuxserver/yq 略 Digets: 略 Status: Downloaded newer image for linuxserver/yq:2.13.0 usage: yq [-h] [--yaml-output] [--yaml-roundtrip] [--width WIDTH] [--indentless-lists] [--in-place] [--version] [jq_filter] [files [files ...]] yq: error: argument files: can't open '/opt/manifests/deployment.yml.tmpl': [Errno 2] No such file or directory: '/opt/manifests/deployment.yml.tmpl' 6.解決策 -vオプションで指定するホスト側のパスを「GitHub Actionsのホスト側の 絶対パス 」とする Runnerのワーキングディレクトリは、GITHUB_WORKSPACE で取得できる！ options: > - --rm -v ${{ env.MANIFEST_PATH }}:/opt/${{ env.MANIFEST_PATH }} ##ホストの相対パス:コンテナ側の絶対パス + --rm -v ${{ github.workspace }}/${{ env.MANIFEST_PATH }}:/opt/${{ env.MANIFEST_PATH }} ##ホストの絶対パス:コンテナ側の絶対パス -w=/opt/${{ env.MANIFEST_PATH }} --entrypoint yq 7.[備考]GITHUB_WORKSPACEとは GitHubのドキュメントのGITHUB_WORKSPACEの説明文の頼りにすると、Runnerのデフォルトの作業ディレクトリと書かれている GITHUB＿WORKSPACE ...

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 ~/.bashrc 略 . $HOME/.asdf/asdf.sh . $HOME/.asdf/completions/asdf.bash これでasdfのインストールは終わった。いよいよプラグインのインストールに移るが、ややこしく感じたので大まかな流れをおさえておきたい。 5.バージョン管理したいプラグインのインストールと設定の大まかな流れ 必要になったプラグインあるいはそのバージョンが既にあるか確認 $ asdf plugin list | grep <プラグイン> プラグインがなければ追加 $ asdf plugin-add <プラグイン> <リポジトリ> 任意のバージョンをインストール $ asdf install <プラグイン> <バージョン> asdf global/localで導入 $ asdf local <プラグイン> <バージョン> 導入したプラグインとそのバージョンが書かれていることを確認 $ asdf current $ cat .tool-versions （不要なバージョンはuninstall） $ asdf uninstall <プラグイン> <バージョン> 参考：https://asdf-vm.com/guide/getting-started.html#install-the-plugin ...

1.この記事で達成したいこと $HOME/.aws/configに書かれた名前付きプロファイルをイイ感じに使いたい ディレクトリごとに指定できるようにしたい AWS_DEFAULT_PROFILEを都度exportするのは面倒なので避けたい $ export AWS_DEFAULT_PROFILE=user1 2.前提/環境情報 $ grep VERSION= /etc/os-release VERSION="20.04.3 LTS (Focal Fossa)" $ direnv --version 2.21.2 3. どうやるか？ direnvを使う direnvとは、ディレクトリに移動した際、自動で記載されている環境変数を読み込んでくれるもの direnvを使うことでできること ディレクトリ/環境に適したAWS_PROFILEを指定すること 前提として、$HOME/.aws/configに以下のように書かれていること [default] region=us-west-2 output=json [profile user1] region=us-east-1 output=text 出所：名前付きプロファイル - AWS Command Line Interface 4.使い方 aptでdirenvをインストール ※Installation | direnv では紹介されていなかった。。 Setup | direnv に従って ~/.bashrc を編集 $ apt search direnv | tail WARNING: apt does not have a stable CLI interface. Use with caution in scripts. Full Text Search... direnv/focal,now 2.21.2-1 amd64 [installed] ## <-- direnvがあった Utility to set directory specific environment variables extrace/focal 0.7-1 amd64 trace exec() calls system-wide ondir/focal 0.2.3+git0.55279f03-1 amd64 Automate tasks specific to certain directories in the shell $ sudo apt install direnv $ tail -n 1 ~/.bashrc eval "$(direnv hook bash) direnvを使いたいディレクトリ直下で、direnv edit . を実行し、使いたいプロファイルを書く $EDITORの値がないとエラーを引いたら、export $EDITOR=vimなどと$EDITORの値をセットすればok $ direnv edit . $ cat .envrc export AWS_PROFILE=user1 $ direnv edit . direnv: $EDITOR not found. direnv: error exit status 1 $ echo "export $EDITOR=vim" >> ~/.bashrc && source ~/.bashrc direnv allow で読み込みができるようにする $ direnv allow direnv: loading /path/to/.envrc direnv: export +AWS_PROFILE 動作確認 $ cd /path/to direnv: loading /path/to/.envrc direnv: export +AWS_PROFILE ## ディレクトリを離れると $ cd .. direnv: unloading 5.参考 名前付きプロファイル - AWS Command Line Interface Installation | direnv Setup | direnv