GitHub ActionsでPythonを動かす
今回の目的
GitHubでpullやmergeを実施した際に、Pythonで処理を行う方法をまとめました。
作業の流れ
1. GitHub Actionsのワークフロー格納ディレクトリの作成
GitHub Actionsで実施されるワークフローは「.github/workflows」に格納する必要があるため、 対象のディレクトリをGitHubのルートディレクトリ直下に作成します。 (GitHub Actions を理解する - GitHub Docs)
2. GitHub Actionsのワークフローの作成
ワークフローはyamlファイルで記載する必要があります。 以下に基本的な構文について説明します。
name
ワークフローの名前。 GitHub では、ワークフローの名前がリポジトリの [アクション] タブに表示されます。 name を省略すると、GitHub により、リポジトリのルートに相対的なワークフロー ファイル パスに設定されます。
on
ワークフローを自動的にトリガーするには、on を使用してワークフローを実行する原因となるイベントを定義します。 使用可能なイベントの一覧については、「ワークフローをトリガーするイベント」を参照してください。
jobs
ワークフロー実行は、既定で並列実行される 1 つ以上の jobs で構成されます。 ジョブを順番に実行するには、jobs.<job_id>.needs キーワードを使用して他のジョブへの依存関係を定義できます。 各ジョブは、runs-on で指定されたランナー環境で実行されます。
jobs.<job_id>.runs-on
jobs.<job_id>.runs-on を使って、ジョブを実行するマシンの種類を定義します。
jobs.<job_id>.steps
1 つのジョブには、steps と呼ばれる一連のタスクがあります。 ステップでは、コマンドを実行する、設定タスクを実行する、あるいはリポジトリやパブリックリポジトリ、 Dockerレジストリで公開されたアクションを実行することができます。
jobs.<job_id>.steps[*].name
GitHubで表示されるステップの名前。
jobs.<job_id>.steps[*].id
ステップの一意の識別子。 id を使って、コンテキストのステップを参照することができます。
jobs.<job_id>.steps[*].uses
ジョブでステップの一部として実行されるアクションを選択します。 アクションとは、再利用可能なコードの単位です。 ワークフローと同じリポジトリ、パブリック リポジトリ、または公開されている Docker コンテナー イメージで定義されているアクションを使用できます。
jobs.<job_id>.steps[*].run
オペレーティングシステムのシェルを使用してコマンドラインプログラムを実行します。 name を指定しない場合、ステップ名は既定では run コマンドで指定されたテキストになります。
※その他の構文については以下をご参照ください
GitHub Actions のワークフロー構文 - GitHub Docs
今回は以下のようなワークフローを作成しました。
# ワークフローの名称を記載 name: 'Test' # トリガーを定義 on: push: branches: - main # ジョブを定義 jobs: setup: # 実行環境を定義(ubuntu) runs-on: ubuntu-latest # ステップを記載 steps: - uses: actions/checkout@v3 # パブリックアクションの定義(pythonのセットアップ) - name: Setup Python uses: actions/setup-python@v2 with: python-version: '3.8' architecture: 'x64' # pythonのバージョン取得 - name: Get Python version run: python -V # pythonの実行 - name: Run Python run: python .github/workflows/test.py
3. Pythonコードの作成
pythonの実行ファイル(.github/workflows/test.py)を作成します。 今回はprintで「Execute from GitHub Actions」とだけ出力するコードとします。
print("Execute from GitHub Actions!!!")
実際に実行してみた。
今回はトリガーをmainブランチへのpushとしていますので、実際にmainにpushしてみると、 問題なくpythonのコードが実行されていることが確認できました。
CloudWatchLogsからのメトリクス抽出方法
今回の目的
CloudWatchLogsからメトリクスフィルタ機能を使って、AuroraのメモリサイズをカスタムメトリクスとしてCloudWatchに表示させたいと思います。
作業の流れ
1. Auroraの拡張モニタリングの有効化
2. CloudWatchLogsにてメトリクスフィルタ作成
1. Auroraの拡張モニタリングの有効化
Auroraの拡張モニタリングの有効化はAWSマネジメントコンソール上で設定することが可能です。拡張モニタリングはインスタンス単位でオン/オフを設定できるので、インスタンスの設定で以下のようにチェックボックスをオンにしてください。
2. CloudWatchLogsにてメトリクスフィルタ作成
拡張モニタリングを有効化したら、CloudWatchLogsに「RDSOSMetrics」というロググループが存在していることが分かります。
ログの出力はJSON形式で、下記のようなフォーマットでAuroraのOS情報が出力されます。
"memory": {
"free": xxxxxxxxx,
"active": xxxxxxxxx,
"total": xxxxxxxxx,
"buffers": xxxxxxxxx
}
上記のOS情報をCloudWatchのカスタムメトリクスとして表示するため、ロググループにチェックを入れて、アクションから「メトリクスフィルターを作成」を選択します。
メトリクスフィルタでは、フィルタパターンを適切に設定することで、ログから抽出したい情報を設定することができます。詳細はCloudWatchのフィルタパターンの構文をご確認ください。
今回はJSON形式のフォーマットに対して、memoryのtotalを抽出したいので、{$.memory.total>0}とパターンを設定します。この設定で、totalが0以上のログだけが抽出されます(0以上ということは全部という意味ですが..)
メトリクス値では、フィルタに合致した文言からどの文字列を抽出するかを設定することができます。今回はmemoryのtotalを抽出したいので、$.memory.totalを設定します。
その他の設定はCloudWatchの名前空間などですが、CloudWatchの画面上の名称などなので、自分のお好みの設定にしてください。以上で設定は完了です。
設定が完了したら、CloudWatchのカスタムメトリクスが作成され、メトリクスの値が取得できていることを確認することができます。
感想
CloudWatchLogsのメトリクスフィルタを利用して、AuroraのOS情報を簡単にカスタムメトリクスとして表示する方法についてご紹介しました。
他のAWSサービスでも標準メトリクスとして欲しい情報がマッチしない場合もあると思います。そんな時に今回の方法を使うことで足りない部分を補うことができると思うので、ぜひ試してみてください。