mito’s blog

IT技術メインの雑記。思い立ったが吉日。

Cloud Operator Days Tokyo 2023 参加レポート

はじめに

Cloud Operator Days Tokyo 2023(以下、CODT2023)に、登壇とクロージングイベントへ現地参加してきました。
いくつかのセッションと現地参加の感想を記載しています。

Cloud Operator Days Tokyo - Cloud Operator Days Tokyo 2023


セッション動画の資料感想

内製開発のすゝめ〜NTT 東日本が取り組んだクラウド内製化開発の歩みと、社外展開の壁、持続可能な開発体制〜

event.cloudopsdays.com

  • 登壇者
  • 内製開発チーム作りのポイントが見どころ
    • 生成系AIを教育者とする
  • 内製開発はコスト削減に繋がらない


全面的に動的閾値監視(Anomaly Detection)を採用して分かったメリットデメリットについて

event.cloudopsdays.com

  • 登壇者
  • セブン銀行の監視の話
    • 動的閾値が向いているもの向いていないもの、具体的なフローの提示など、こちらの解釈が不要でそのまま知見を受け入れられそう
    • 実障害とそれを動的閾値で検知できたかまで記載
      • ここまで公開していてありがたい


業界初Generative AI オブザーバビリティ・アシスタント登場〜次世代AIOpsによる運用業務の変革

event.cloudopsdays.com

  • 登壇者
    • New Relic 株式会社 清水 毅さん
  • 運用業務にAIをどう活かすか活かせるかが分かりやすかったです。
    • 例えば、AIで障害解決までの時間を超短縮する
  • 動画が格好いい!


クラウドネイティブで監視は何がかわるのか? ~レストランに例えて、考えてみた~

event.cloudopsdays.com

  • 登壇者
    • 株式会社アシスト 中村 利一さん
  • 具体的にどうする?という話ではなく、概念の話
    • クラウドネイティブの監視はこう変わっていくよと、理解しやすいと思いました
    • ゴーストレストランの理解が必要


クロージングイベントの現地参加感想

現地参加のみで、ディスカッションへの参加や懇親会が開催されました。

トラブルシューティング&オブザーバビリティ(&APM

オブザーバビリティの定義

  • 既知の未知、未知の未知
    • 【既知】気づける
      • 【既知】理解できる
        • 実用的な監視  - 気づいた後に対処できる 特定の機能が使えない
      • 【未知】理解できない
        • とりあえずの監視
        • 対処できない リソース使用率が上がっている
    • 【未知】気づけない
      • 【既知】理解できる
        • 実用的な監視予備軍
        • 障害発生して後手対応になったが、次回から監視で気づける
      • 【未知】理解できない ★★ ここが対応できることがオブザーバビリティ ★★
        • 監視できていない
        • 障害発生したが減員が分からず監視もできない
          • どうするの?
            • アプリがあらゆるイベントでログをだせるようにしろ、そして取れ。解析しやすいように構造化しておけ
  • 監視をオブザーバビリティへ、レベルアップさせる

    • クラウドネイティブ環境の監視は「オブザーバビリティ」
    • 未知の未知を、既知の既知にできるか
  • QA

    • ログのストレージコストの相談は5本指に入る
      • どこまでログ取るかは試行錯誤が必要
      • 事前に予測できない、従量課金
      • 全体のインフラコストに対して、何割あてるかみたいな議論をしたほうがいいかもしれない
    • ログをLLMで解析してる?
      • XXXはやってる。モデルを作るのには、ユーザのログは使っていない(使えない)。解析に使っている
      • XXXはやってない


ハイブリッドクラウド

ハイブリッドクラウドの定義

  • 消極的と積極的がある。
  • 消極的でも積極的でもない
    • 意図があったりなかったりのそれぞれの部署がある
    • 会社の政治理由
  • プライベートクラウド
    • うまみ
      • バージョンアップのタイミングが社内調整できる
    • つらみ
      • HWが調達できない
  • パブリッククラウド
    • つらみ
      • 文化。パブクラのFWが使えず、パブクラからわざわざ社内のFWを通し、パブクラに戻すことも


クラウドセキュリティ

セキュリティ対策は何をしているか

  • セキュリティ対策
    • 現場の落とし所と現場からの正論・理想論のぶつけ合い、リスク許容・コスト観点
    • ここはやらなくていいよ集というガイドを決める
  • 基準
    • ツール基準なら、今まで使ってきて問題がないから今も使っている
  • 責任を押し付けるのではなく、共有してアドバイス貰う
    • 知らないからこそ、あなた担当だろという押しつけは散見される


モダン開発におけるAIOpsの重要な役割:ぐるなびが目指す効率的な運用戦略

完全オフラインのようなので、一部メモのみ。

  • クラウド利用における運用の変化
    • 障害発生
      • アラート通知は、開発担当にもいく
        • 開発も一時切り分けをする
    • モダン開発におけるモニタリング
      • アプリケーションは絶えず変化し続ける
        • どこのアラートが把握しにくい
        • 単一のリソースを監視しても、サービスが異常かわからない
    • どうするべきか
      • オブザーバビリティが大事
        • 運用効率化は、サービス状態の把握/可視化が第一歩
      • AIOpsの大事な役割
        • 限られた時間の中で最も不足しているのは経験
          • それをAIOpsで補完する
            • 補完するもの、運用経験において大事な側面
              • 状態の把握、傾向の分析、深い調査力
        • 最小の工数で、一人前のインフラエンジニアに仕立て上げる
  • AIOpsで大事なこと
    • マイクロサービスでは、特定のサービスの異常を検知するだけでは、原因特定が難しい時がある
      • 関連するサービスの異常を紐づける
    • 閾値監視は失敗
    • DevにOpsが入るだけでなく、OpsにもDevが入る
    • 過検出や過検知は発生する
      • 誤検知ではない
      • 最終的には経験が鍵


パネルディスカッション

AIOpsは運用のどこで使うの?使えるの?

  • AI製品を使うのではなく、裏でAIが動いていたという状態が自然
  • AIOpsによるAzureサービス品質の向上
  • 代表的な保守意見
    • ジュニアがAIを使うと危険、学習しない
  • みんなで運用に役立てよう
  • 実際に利用しての効果と課題
    • 運用コストは特に下がらない
      • 理解しようとして使う人たちだから
      • 最後に判断するのはエンジニア
    • コストは下がるけど、品質も下がるなら良くない
  • 生成系AIは使える?
    • 使える
      • ジュニアは新しいアイディアを形にできる
      • エキスパートはさらに仕事ができる
      • 間にいる人は、ただ経験が得られないだけになる?
        • 危機感を持ったほうが良い
    • ChatGPTは出来ないと回答してくれないので、ずっと質問を続けるジュニアもいる
      • 人間でも頑張って教えてくれる先輩はいたが。。。
    • 一番いいと思った例
      • 自然言語の問い合わせを、XXXQLに変換する質問
        • マーケが効果的に使っていた
          • エンジニアに分析を依頼すると、1週間とか時間がかかる
          • エンジニアは勉強すればいいというが、それが正とは限らない
  • 変化するスキルセット
    • 自分は次何をするべきか、考えられる人物が残る
    • AI適用による技術の空洞化のリスク
      • そういうものと受け入れるだけ
      • なくなる仕事はそんなにないと思うが、ものすごく生産性が高まる


所感

濃密な時間を過ごせました。内製化はどうなのか(自動化と同じで周回すると考えが変わる)、オンプレミスの解像度をあげないとだめなのではなどと考えさせられました。
また、オンラインイベントに参加していただいたのに、対面交流がなかった人達とも挨拶できてヨシ!
12月のCNDT2023もぜひ現地参加したい。

[GitHub Actions] セルフホストランナーをCloud9で試す

はじめに

GitHub ActionsをCloud9に構築したセルフホストランナーで動かしてみます。
GitHubホストランナーは利用時間の制限(無料/有料)があったり、OSの種類が決まっていますが、
セルフホストランナーは自身で用意するため、制限はなくカスタマイズも自由です。

GitHub Actions を理解する - GitHub Docs セルフホステッド ランナーの概要 - GitHub Docs



セルフホストランナーの追加手順

1. プライベートリポジトリの作成

適当なリポジトリをPrivateで作成します。

2. Agentマシンの構築

今回はCloud9を使用します。
Cloud9をインスタンスタイプ「t2.micro」、Platform「Ubuntu Server 18.04 LTS」で立てます。
セキュリティグループはデフォルトそのままでも大丈夫です。インバウンドルール、アウトバウンドルールともに何か追加する必要はありません。

セルフホステッド ランナーの概要 - GitHub Docs


3. セルフホストランナーの追加

追加したいリポジトリのメニューをたどっていくと、OSごとにセルフホストランナーを追加するコマンド手順が表示されます。
コマンドにはトークンも記載されているため、改変する必要はなく、コピペで済みます。

上部メニュー[Settings] -> 左サイドメニュー[Actions] -> [Runners] -> [New self-hosted runner]

自己ホストランナーの追加 - GitHub Docs

Linuxの例

**Download**
# Create a folder
$ mkdir actions-runner && cd actions-runner
# Download the latest runner package
$ curl -o actions-runner-linux-x64-2.303.0.tar.gz -L https://github.com/actions/runner/releases/download/v2.303.0/actions-runner-linux-x64-2.303.0.tar.gz
# Optional: Validate the hash
$ echo "e4a9fb7269c1a156eb5d5369232d0cd62e06bec2fd2b321600e85ac914a9cc73  actions-runner-linux-x64-2.303.0.tar.gz" | shasum -a 256 -c
# Extract the installer
$ tar xzf ./actions-runner-linux-x64-2.303.0.tar.gz

**Configure**
# Create the runner and start the configuration experience
$ ./config.sh --url https://github.com/mito-201/リポジトリ名 --token ******************
# Last step, run it!
$ ./run.sh


run.shを実行すると、以下のようにGitHubと接続されたメッセージが表示され、[Runners]にも追加されます。

$ ./run.sh 

√ Connected to GitHub

Current runner version: '2.303.0'
2023-05-05 16:35:39Z: Listening for Jobs


ランナーのステータス

ステータスは次のいずれかです。

  • Idle
    • ランナーはGitHubに接続されており、ジョブを実行する準備ができています。
  • Active
    • ランナーは現在ジョブを実行しています。
  • Offline
    • ランナーは GitHub に接続されていません。
    • マシンがオフライン、セルフホストランナー上でアプリケーションが実行されていない、アプリケーションがGitHubと通信できない可能性があります。


ワークフローの作成手順

GitHub Actions を理解する - GitHub Docs

1. ディレクトリの作成

ワークフローファイルを格納するためのディレクト.github/workflowsを作成します。


2. ワークフローファイルの作成

ディレクト.github/workflowsに、以下のファイル内容でgithub-actions-demo.ymlを作成します。

  • ワークフローのトリガー
    • branches: [ "main" ] へのpush
    • branches: [ "main" ] へのpull_request
  • runs-on: [self-hosted]
    • ワークフローを実行するランナーのラベルを指定します。

GitHub Actions のワークフロー構文 - GitHub Docs


# This is a basic workflow to help you get started with Actions
name: CI

# Controls when the workflow will run
on:
  # Triggers the workflow on push or pull request events but only for the "main" branch
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: [self-hosted]
    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v3

      # Runs a single command using the runners shell
      - name: Run a one-line script
        run: git --version

      # Runs a set of commands using the runners shell
      - name: Run a multi-line script
        run: |
          echo Add other actions to build,
          echo test, and deploy your project.


3. ワークフローの実行

github-actions-demo.ymlをmainブランチにプッシュした際、すでにワークフローが実行されています。
上部メニュー[Actions]より、ワークフローのログが確認できます。


その他

セルフホストランナー上のコンテナでワークフローを動かしたい

GitHub Actions のワークフロー構文 - GitHub Docs

以下のように、container: image: ****と動かしたいコンテナイメージを記載します。

    runs-on: [self-hosted]
    container:
      image: bitnami/git


step単位でコンテナを指定することもできます。

    steps:
      - name: My first step
        uses: docker://alpine:3.8


セルフホストランナーのアプリケーションをサービスとして設定する

セルフホストランナーアプリケーションをサービスとして設定する - GitHub Docs

run.shと同じフォルダにあるスクリプトsvc.shを、目的に合う引数で実行します。

# インストール
$ sudo ./svc.sh install

# スタート
$ sudo ./svc.sh start

# ステータス確認
$ sudo ./svc.sh status


GitHubで利用されているIPアドレスを確認する

以下のメタ情報で確認できます。

About GitHub's IP addresses - GitHub Docs

https://api.github.com/meta

[Ansible][Terraform]AnsibleとTerraformのModuleの違い

AnsibleとTerraformには、Moduleと呼ばれる機能があります。
ただし、名前が同じなだけで内容は異なります。

概要 Ansible Terraform
コードの要素 Module タスクの単位  Resource リソースの単位 
再利用可能なコードの単位 Role  タスクの集合  Module  リソースの集合 


AnsibleのModuleとTerraformのResource

どちらもリソースの構築や設定を行うコードの要素です。


  • Ansible

AnsibleのModuleは、Playbookのtasksに記載するコードの単位です。
ターゲットノードに、Moduleの処理内容を実行します。
以下の例では、ローカルホストに、yumモジュールでhttpdの最新版をインストールします。

- hosts: localhost
  
  tasks:
    - name: Install the latest version of Apache
      ansible.builtin.yum:
        name: httpd
        state: latest


  • Terraform

TerraformのResourceは、TFファイルに記載するコードの要素です。
Terraformで構築するリソースを記載します。
以下の例では、AWSのEC2インスタンスを、マシンイメージはUbuntuインスタンスタイプはt3.micro、インスタンス名はHelloWorldで構築します。

resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"

  tags = {
    Name = "HelloWorld"
  }
}



AnsibleのRoleとTerraformのModule

どちらもコードを再利用可能な形で外に切り出したものです。
プログラミングで言う関数のようなものです。


  • Ansible

AnsibleのRoleは、タスクや変数ファイル、ハンドラーなどを再利用可能な形で、仕様に基づいたディレクトリやファイル構造に分割したものです。
Roleのタスクを参照することで、Roleの変数ファイル、ハンドラーなどを自動的に読み込みます。
以下の例は、再利用可能な形にしたcommonロールをPlaybook.ymlで呼び出すディレクトリ・ファイル構造です。

$ tree
.
├── playbook.yml
└── roles
    └── common
        ├── handlers
        │   └── main.yml
        ├── tasks
        │   └── main.yml
        └── vars
            └── main.yml

5 directories, 4 files


  • Terraform

TerraformのModuleは、リソースを再利用可能な形で外に切り出したものです。
カレントディレクトリのTFファイルで、Moduleディレクトリ内にあるTFファイルの実行結果を参照します。
以下の例は、再利用可能な形にしたcommonモジュールをカレントディレクトリのTFファイルで呼び出すディレクトリ構造です。

$ tree
.
├── modules
│   └── common
│       └── main.tf
├── output.tf
├── terraform.tf
└── variable.tf

2 directories, 4 files

[Terraform][AWS]Terraformで作成したSecrets ManagerとParameter Storeのtfstateにおける違い

結論

terraformで以下のリソースを作成し、手動などでシークレットの値を更新した後、再度terraformコマンドを実行すると、

  • Secrets Manager
    • terraform refreshをしても、tfstateに変更はありません。
    • terraform applyをしても、changedになりません。
  • Parameter Store
    • terraform refreshをすると、tfstateが更新されます。
    • terraform applyをすると、changedになります。



はじめに

Terraformで作成したSecretsManagerとParameterStoreのそれぞれの値について、tfstateでの管理に差異があったので書き留めておきます。

Resource: aws_secretsmanager_secret

Resource: aws_ssm_parameter


リソース:aws_secretsmanager_secret

シークレットマネージャは、AWSマネジメントコンソールからは即削除できませんが、
Terraformではrecovery_window_in_days = 0を設定することで即削除できます。

recovery_window_in_days - (Optional) Number of days that AWS Secrets Manager waits before it can delete the secret. This value can be 0 to force deletion without recovery or range from 7 to 30 days. The default value is 30.


SecretsManager作成のTFファイル

シークレット名web_passwordを作成し、key:valuepassword:test1234を登録します。

resource "aws_secretsmanager_secret" "asm_secret_web" {
  name = "web_password"
  recovery_window_in_days = 0
}

resource "aws_secretsmanager_secret_version" "asm_secret_web_version" {
  secret_id     = aws_secretsmanager_secret.asm_secret_web.id
  secret_string = jsonencode({"password" = "test1234"})
}


terraform applyの実行

terraform applyを実行し、シークレットマネージャにリソースを作成します。

$ terraform apply
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

()

Plan: 2 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

aws_secretsmanager_secret.asm_secret_web: Creating...
aws_secretsmanager_secret.asm_secret_web: Creation complete after 1s [id=arn:aws:secretsmanager:ap-northeast-1:*****:secret:web_password-7fD0bZ]
aws_secretsmanager_secret_version.asm_secret_web_version: Creating...
aws_secretsmanager_secret_version.asm_secret_web_version: Creation complete after 0s [id=arn:aws:secretsmanager:ap-northeast-1:*****:secret:web_password-7fD0bZ|********]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.


tfstateには、以下が記載されています。

"name": "web_password",
"secret_string": "{\"password\":\"test1234\"}",


passwordの書き換え

ansibleでpasswordをtest1234から、oioioioioiに更新します。

Playbook例
[Ansible][AWS] SecretsManagerモジュールでユーザとパスワードを登録する(更新2023.02.13) - mito’s blog

$ ansible-playbook add_secretmanager.yml 
[WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'

PLAY [localhost] ***********************************************************

TASK [debug] ***************************************************************
ok: [localhost] => {
    "msg": {
        "password": "test1234"
    }
}

TASK [Update Secrets Manager] *************************************************
changed: [localhost]

TASK [debug] ***************************************************************
ok: [localhost] => {
    "msg": {
        "password": "oioioioioi"
    }
}

PLAY RECAP *****************************************************************
localhost : ok=3  changed=1  unreachable=0  failed=0  skipped=0  rescued=0  ignored=0

$ 


terraform apply -refresh-onlyの実行

terraform apply -refresh-onlyを実行しても、tfstateには変更ありません。

$ terraform apply -refresh-only
aws_secretsmanager_secret.asm_secret_web: Refreshing state... [id=arn:aws:secretsmanager:ap-northeast-1:*****:secret:web_password-7fD0bZ]
aws_secretsmanager_secret_version.asm_secret_web_version: Refreshing state... [id=arn:aws:secretsmanager:ap-northeast-1:*****:secret:web_password-7fD0bZ|********]

No changes. Your infrastructure still matches the configuration.

Terraform has checked that the real remote objects still match the result of your most recent changes, and found no differences.

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.
$ 


tfstateのpasswordは、test1234のままです。

"secret_string": "{\"password\":\"test1234\"}",


terraform applyの実行

terraform applyの実行でも変更はありません。

$ terraform apply
aws_secretsmanager_secret.asm_secret_web: Refreshing state... [id=arn:aws:secretsmanager:ap-northeast-1:*****:secret:web_password-7fD0bZ]
aws_secretsmanager_secret_version.asm_secret_web_version: Refreshing state... [id=arn:aws:secretsmanager:ap-northeast-1:*****:secret:web_password-7fD0bZ|********]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.
$


リソース:ssm_parameter

ParameterStore作成のTFファイル

パラメータ名web_passwordを作成し、valuetest1234を登録します。

resource "aws_ssm_parameter" "ssm_parameter_web_password" {
  name        = "web_password"
  type        = "SecureString"
  value       = "tes1234"
}


terraform applyの実行

terraform applyを実行し、パラメータストアにリソースを作成します。

$ terraform apply

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following
symbols:
  + create

()

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

aws_ssm_parameter.ssm_parameter_web_password: Creating...
aws_ssm_parameter.ssm_parameter_web_password: Creation complete after 0s [id=web_password]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
$ 


tfstateには、以下が記載されています。

"name": "web_password",
"value": "tes1234",


passwordの書き換え

ansibleでpasswordをtest1234から、oioioioioiに更新します。

Playbook例
[Ansible][AWS] ParameterStoreモジュールでユーザとパスワードを登録する - mito’s blog

$ ansible-playbook add_paramater.yml 
[WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'

PLAY [localhost] ***************************************************************

TASK [debug] *******************************************************************
ok: [localhost] => {
    "msg": "tes1234"
}

TASK [Update SSM parameter store] ************************
changed: [localhost]

TASK [debug] *******************************************************************
ok: [localhost] => {
    "msg": "oioioioi"
}

PLAY RECAP *********************************************************************
localhost : ok=3  changed=1  unreachable=0  failed=0  skipped=0  rescued=0  ignored=0   

$ 


terraform apply -refresh-onlyの実行

terraform apply -refresh-onlyを実行すると、tfstateに変更が入ります。
また、-refresh-onlyを付けているためapplyは実行しておらず、0 changedになります。

$ terraform apply -refresh-only
aws_ssm_parameter.ssm_parameter_web_password: Refreshing state... [id=web_password]

Note: Objects have changed outside of Terraform

Terraform detected the following changes made outside of Terraform since the last "terraform apply":

  # aws_ssm_parameter.ssm_parameter_web_password has changed
  ~ resource "aws_ssm_parameter" "ssm_parameter_web_password" {
        id        = "web_password"
        name      = "web_password"
      + tags      = {}
      ~ value     = (sensitive value)
      ~ version   = 1 -> 2
        # (6 unchanged attributes hidden)
    }


This is a refresh-only plan, so Terraform will not take any actions to undo these. If you were expecting these changes then you can
apply this plan to record the updated values in the Terraform state without changing any remote objects.

Would you like to update the Terraform state to reflect these detected changes?
  Terraform will write these changes to the state without modifying any real infrastructure.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: yes


Apply complete! Resources: 0 added, 0 changed, 0 destroyed.
$ 


tfstateには、差分が見受けられます。
passwordやversionが更新されています。

$ diff -u terraform.tfstate.backup terraform.tfstate                                     
--- terraform.tfstate.backup    2023-03-04 21:22:36.243115094 +0900
+++ terraform.tfstate   2023-03-04 21:22:36.243115094 +0900
@@ -1,7 +1,7 @@
-  "serial": 8,
+  "serial": 9,
@@ -23,12 +23,12 @@
-            "tags": null,
+            "tags": {},
-            "value": "tes1234",
-            "version": 1
+            "value": "oioioioi",
+            "version": 2


terraform applyの実行

terraform applyを実行すると、passwordが書き換え前に変更されます。

$ terraform apply
aws_ssm_parameter.ssm_parameter_web_password: Refreshing state... [id=web_password]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following
symbols:
  ~ update in-place

Terraform will perform the following actions:

  # aws_ssm_parameter.ssm_parameter_web_password will be updated in-place
  ~ resource "aws_ssm_parameter" "ssm_parameter_web_password" {
        id             = "web_password"
      + insecure_value = (known after apply)
        name           = "web_password"
        tags           = {}
      ~ value          = (sensitive value)
      ~ version        = 2 -> (known after apply)
        # (6 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

aws_ssm_parameter.ssm_parameter_web_password: Modifying... [id=web_password]
aws_ssm_parameter.ssm_parameter_web_password: Modifications complete after 0s [id=web_password]

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.
$ 


passwordが書き換える前の値(TFファイルの値)に変わりました。

$ diff -u terraform.tfstate.backup terraform.tfstate
--- terraform.tfstate.backup    2023-03-04 21:29:22.879912086 +0900
+++ terraform.tfstate   2023-03-04 21:29:22.895912433 +0900
@@ -1,7 +1,7 @@
-  "serial": 9,
+  "serial": 11,
@@ -27,8 +27,8 @@
-            "value": "oioioioi",
-            "version": 2
+            "value": "tes1234",
+            "version": 3
$ 


備考

Secrets ManagerとParameter Storeのどちらを使用するかは、運用に応じて選択するのが良いかと思います。
ただし、terraform外での値の変更が予想される場合には、terraform applyの実行では値が変更されないSecretsManagerをお勧めします。課金されるけど。

[Ansible][AWS] ParameterStoreモジュールでユーザとパスワードを登録する

はじめに

community.awsにあるssm_parameterモジュールで、ユーザとパスワードを登録します。

community.aws.ssm_parameter module – Manage key-value pairs in AWS Systems Manager Parameter Store — Ansible Documentation


AWS Systems Manager(SSM)パラメータストアは名前にシークレットと付かないし、同系統のサービスでシークレットマネージャーがあるためセキュリティは強くないイメージを持ってしまいますが、そんなことはありません。
オプションには string_type があり、平文のString StringList、暗号化のSecureStringと選択できます。


環境

  • ansible core: 2.13.7
  • community.aws: 5.0.0

5.0.0以降ののモジュール名はcommunity.aws.ssm_parameterで、それより前はcommunity.aws.aws_ssm_parameter_storeです。
使い方は特に変わりありません。


パラメータストアにユーザとパスワードを登録する

パラメータストアは、1組のkey:value(またはlist)が登録できます。
複数のkey:valueが登録できるシークレートマネージャとは異なります。

Playbook

2組のkey:valueを登録するので、それぞれモジュールを実行します。
また、パラメータストアの値はlookupプラグインで取得できます。

---
- hosts: localhost
  gather_facts: no
  
  tasks:
    - name: Create key/value pair in AWS SSM parameter store
      community.aws.ssm_parameter:
        name: "web_user"
        string_type: "String"          # ユーザの種別はStringを指定
        value: "admin"

    - name: Create key/value pair in AWS SSM parameter store
      community.aws.ssm_parameter:
        name: "web_password"
        string_type: "SecureString"    # パスワードの種別はSecureStringを指定
        value: "oioioioi"

    - debug:
        msg: "{{ lookup('amazon.aws.aws_ssm', item) }}"  # lookupプラグインを使って呼び出す
      loop:
        - "web_user"
        - "web_password"


実行ログ

想定通りに登録されました。

$ ansible-playbook add_paramater.yml 
[WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'

PLAY [localhost] **************************************************************************

TASK [Create key/value pair in AWS SSM parameter store] ***********************************
changed: [localhost]

TASK [Create key/value pair in AWS SSM parameter store] ***********************************
changed: [localhost]

TASK [debug] ******************************************************************************
ok: [localhost] => (item=web_user) => {
    "msg": "admin"
}
ok: [localhost] => (item=web_password) => {
    "msg": "oioioioi"
}

PLAY RECAP ********************************************************************************
localhost : ok=3  changed=2  unreachable=0  failed=0  skipped=0  rescued=0  ignored=0   

$ 





「/」で階層構造を表示する

nameの先頭に「/」を付ける必要があります。
複数のkey:valueをまとめられるシークレットマネージャーと比べると見づらい部分もありますが、
先頭にシステム名を入れスラッシュで区切ると、登録数が増えても幾分か見やすくなります。

Playbook
---
- hosts: localhost
  gather_facts: no
  
  tasks:
    - name: Create key/value pair in AWS SSM parameter store
      community.aws.ssm_parameter:
        name: "/web/user"             # 先頭に必ず「/」を入れる
        string_type: "String"
        value: "admin"

    - name: Create key/value pair in AWS SSM parameter store
      community.aws.ssm_parameter:
        name: "/web/password"         # 先頭に必ず「/」を入れ
        string_type: "SecureString"
        value: "oioioioi"

    - debug:
        msg: "{{ lookup('amazon.aws.aws_ssm', item) }}"
      loop:
        - "/web/user"
        - "/web/password"


実行ログ

無事に取得できました。

$ ansible-playbook add_paramater.yml 
[WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'

PLAY [localhost] **************************************************************************

TASK [Create key/value pair in AWS SSM parameter store] ***********************************
changed: [localhost]

TASK [Create key/value pair in AWS SSM parameter store] ***********************************
changed: [localhost]

TASK [debug] ******************************************************************************
ok: [localhost] => (item=/web/user) => {
    "msg": "admin"
}
ok: [localhost] => (item=/web/password) => {
    "msg": "oioioioi"
}

PLAY RECAP ********************************************************************************
localhost : ok=3  changed=2  unreachable=0  failed=0  skipped=0  rescued=0  ignored=0

$ 


備考

値を登録するだけであれば、パラメータストアは値の履歴が残り、課金されるまでの上限も余裕があるため、シークレットマネージャーよりも使いやすいかもしれません。
また、CloudFormationではSecureStringは作成できないようです。