たそ@ITインフラ初心者

taso@初心者エンジニア

新卒2年目 エンジニアが適当に語るブログてす

Ansible Automation Controller APIを触ってみた。(ジョブテンプレート編)

はじめに

お久しぶりです。たそ(taso_int)です。
そう言えば、ネスぺを申し込みました。受けるからには受かる気で取り組みます。
あとは前回今年の目標にしてたところも触り始めてます。継続できれば…
今日はAnsible Automation Controller の REST APIについて触ります。
Ansible Automation ControllerはREST APIに対応しており、ジョブの起動などが出来たりします。
REST APIに対応しているおかげでAnsible Automation Controllerの操作設定ができるAnsibleのコレクションがあったりします。

環境

AWS

AAP

  • バージョン2.4(RHEL8用)

インストール方法はこちら

今回はAWSのEC2でAPIを実行しています。
Windows環境の場合はPostmanやWSLで行った方がいいです。
また出力を見やすくするためにjqコマンドを使えるようにしておくとよいです。
curl実行文 | jq . でJsonフォーマットとして出力してくれます。

参考情報

恐らく、上がRed Hatが提供しているリファレンスで2つ目がコミュニティのリファレンスのような気がしています。
わかる方いたら教えてください。
またhttps://controller_url/api/でも確認することが可能です。

下準備

APIを実行する際に認証用のTokenが必要になるので生成します。
アクセス→ユーザー→ユーザーを指定(今回はadmin)→トークンの順でクリックし、作成をします。
範囲は書き込みを指定して作成します。

そうするとToken情報が出るのでこれをメモリます。再表示はされないので注意してください。
以下の画像のようにトークンの一覧にパーソナルアクセストークンが出ていれば問題ないです。

今回はトークンを認証情報としてますが、ユーザーとパスワードによるBasic認証でも実行可能です。

実際に触る

ベース

curlでの実行の場合、基本的に以下のような構造になります。
-k オプションを入れているのはAnsible Automation Controller側がデフォルトのインストールだと自己証明書を設定してしまうためSSL証明書の検証を無視します。

curl -k -X HTTPメソッド \
     -H "Content-Type: application/json" \
     -H "Authorization: Bearer 生成したtoken" \
     https://controller_url/api/v2/hoge

例えば/api/v2を実行するとAPIのリストが出ます。

今回はジョブ(ジョブテンプレート)の起動と結果確認と結果のデバッグまでを書きます。
次回はジョブ(ワークフロー)の起動と結果確認と失敗したジョブの特定までを書きます。

ジョブの起動

試しにジョブテンプレートのDemo Job Templateを起動させてみます。
ジョブテンプレートを起動する際に各ジョブに割り振られているIDが必要になります。
このIDを知るには直接GUIで知りたいジョブテンプレートを開くとURLにIDが含まれています。
APIのみで完結させたい場合はapi/v2/job_templates/?search=ジョブ名でIDを調べることができます。
Demo Job Templateの場合は以下のような表記になります。

curl -k -X GET \
     -H "Content-Type: application/json" \
     -H "Authorization: Bearer 生成したtoken" \
     https://controller_url/api/v2/job_templates/?search=Demo+Job+Template
# 抜粋
  "results": [
    {
      "id": 7,
      "type": "job_template",
      "url": "/api/v2/job_templates/7/",
      "related": {
        "created_by": "/api/v2/users/1/",
        "modified_by": "/api/v2/users/1/",
        "labels": "/api/v2/job_templates/7/labels/",
        "inventory": "/api/v2/inventories/1/",
        "project": "/api/v2/projects/6/",
        "organization": "/api/v2/organizations/1/",
        "credentials": "/api/v2/job_templates/7/credentials/",
        "last_job": "/api/v2/jobs/3/",
        "jobs": "/api/v2/job_templates/7/jobs/",
        "schedules": "/api/v2/job_templates/7/schedules/",
        "activity_stream": "/api/v2/job_templates/7/activity_stream/",
        "launch": "/api/v2/job_templates/7/launch/",

      }

IDがわかったので、実際にジョブテンプレートを起動させます。 エンドポイントはapi/v2/job_templates/id/launch/になります。
ここでのレスポンスとして返ってくるIDがテンプレートの実行履歴のID(以降、ジョブID)となり、これを使用してジョブの結果を調べます。

curl -k -X POST \
     -H "Content-Type: application/json" \
     -H "Authorization: Bearer 生成したtoken" \
     https://controller_url/api/v2/job_templates/7/launch
# 抜粋
{
  "job": 76,
  "ignored_fields": {},
  "id": 76,
  "type": "job",
  "url": "/api/v2/jobs/76/",
  "related": {
    "created_by": "/api/v2/users/1/",
    "modified_by": "/api/v2/users/1/",
    "labels": "/api/v2/jobs/76/labels/",
    "inventory": "/api/v2/inventories/1/",
    "project": "/api/v2/projects/6/",
    "organization": "/api/v2/organizations/1/",
    "credentials": "/api/v2/jobs/76/credentials/",
    "unified_job_template": "/api/v2/job_templates/7/",
    "stdout": "/api/v2/jobs/76/stdout/",
    "job_events": "/api/v2/jobs/76/job_events/",
    "job_host_summaries": "/api/v2/jobs/76/job_host_summaries/",
    "activity_stream": "/api/v2/jobs/76/activity_stream/",
    "notifications": "/api/v2/jobs/76/notifications/",
    "create_schedule": "/api/v2/jobs/76/create_schedule/",
    "job_template": "/api/v2/job_templates/7/",
    "cancel": "/api/v2/jobs/76/cancel/",
    "relaunch": "/api/v2/jobs/76/relaunch/"
  }

実際にGUIでも実行されていることがわかりました。画面上の数字とジョブIDが一致していますね。

ジョブの確認

このAPIは起動するだけなので、実際の結果は別で確認することが必要です。
結果のエンドポイントはapi/v2/jobs/id/になります。このIDはジョブIDを指します。

curl -k -X GET \
     -H "Content-Type: application/json" \
     -H "Authorization: Bearer 生成したtoken" \
     https://controller_url/api/v2/jobs/76/
# 抜粋
  "launch_type": "manual",
  "status": "successful",
  "execution_environment": 2,
  "failed": false,
  "started": "2024-02-18T12:53:27.139004Z",
  "finished": "2024-02-18T12:53:30.991682Z",

ここでstatusがsuccessfulかつfailedがTrueであれば成功になります。
statusがrunningであれば実行中でfailedであれば失敗になります。

ジョブの標準出力

ここまででジョブ(ジョブテンプレート)の起動と結果確認がわかりました。
念のため起動したジョブの標準出力を確認します。

エンドポイントはapi/v2/jobs/id/stdoutでテキストフォーマットにしたいので、?format=txtを追加します。

curl -k -X GET \
     -H "Authorization: Bearer 生成したtoken" \
     https://controller_url/api/v2/jobs/76/stdout/?format=txt
PLAY [Hello World Sample] ******************************************************

TASK [Gathering Facts] *********************************************************
ok: [localhost]

TASK [Hello Message] ***********************************************************
ok: [localhost] => {
    "msg": "Hello World!"
}

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

見覚えのある標準出力が出ましたね。これでAPIでも実行から結果確認ができます。

最後に

今回はAPIを使ってジョブ(ジョブテンプレート)の起動と結果確認とジョブの標準出力をしました。
次はテンプレートの集合であるWFの方も紹介します。
ここまで読んでいただきありがとうございました。

2024年 今年の目標

はじめに

お疲れ様です。たそ(@taso_int)です。お久しぶりです。もう2月って早すぎませんか。
明けまして、なんやかんやあって、wakamonog13とJANOG53で福岡行って、もう2月ですよ…
そろそろ書かないと忘れてしまうので、今年の目標的なのをちょっと書いておこうと思います。
仕事面とプライベートそれぞれ書いておきます。

仕事面

仕事面はこの3つかなと思ってます。

  • PMを経験する。
  • IaCを鍛える。
  • 資格取る。

PMを経験する

これは上司と1on1でPMをやってみないかと相談されたことがきっかけです。
最初はかなり渋りました。個人としては技術力でお金を稼ぎたい人間です。だからこそもっと技術を伸ばせばいいと思っていたので…
ただこのまま食わず嫌いになるのもよくないなと思ったのと、PMの立場を理解している技術者はチーム的に重宝されるのではないかと思ってやることを決意しました。 正直かなり自信ないです。炎上しないように頑張りたい…
これ見てるつよつよエンジニアの方がいましたら是非おすすめの本やアドバイスください。

IaCを鍛える。

ひとまとまりでIaCと書きましたが、AnsibleとTerrafromの2つがメインです。
仕事上、Terrafromを触る機会があるかもしれないので、学習を進めていこうと思ってます。
それ関連の内容をブログでアウトプットができたらいいなと思ってます。
また今年、Azure×Ansibleの大きいアウトプットを出したいです。
うちの会社Terrafrom使ってる人多そうだし、なんか横で巻き込めたりしないかな…

資格取る。

そろそろ資格なんて意味ないとか言われる年数になるかもですが、それでも資格は積極的に取りたいです。
目標はネスぺとAzure系の資格が取れるとうれしいなと思ってたりします。

プライベート

プライベート面はこの3つかなと思ってます。

  • 英語の勉強をする。
  • 筋トレ(ボディーメイク)
  • コミュニティを盛り上げる。

英語の勉強をする。

やっぱり英語は使えるに越したことはないなと思ってます。 正直英語はトラウマで、話せば長くなりますが英語のせいでこの業界に入ったかもしれません 。
仕事ではそこまで英語に触れる機会はないとは思いますが、それでも一次ソースが英語だったりすることはよくあるので、 何とかして食らいつきたいなと思ってます。
目標はTOEIC800点ぐらいを目指せればと思ってます。

筋トレ

筋トレ初めて1年以上になりますが、引き続き続けていきたいです。
シンプルにかっこよくなりたいし、筋肉つけたいですね。
目標は今年中にベンチ100kg(今75kg)でそこが達成するならBIG3合計400kg(今275kg)目指したいです。
あとは年間8キロぐらい体重を落としたいです。

コミュニティを盛り上げる

なんか半分仕事になるかもしれませんが、IT関係のコミュニティ活動に積極的に参加したいと思います。
参加者・登壇者・運営それぞれ積極的に参加して盛り上げていければと思います。
あとはクラウド関係のコミュニティにあんまり参加できてないので参加したいです。
ちなみにイベント運営に関してはそれなりに興味があるので、ぜひ声かけてください。

終わりに

以上で2024年の目標になります。あと11ヵ月しかないですが、1つでも達成できるように頑張りたいと思います。
みなさん応援の方よろしくお願いします。
ここまで、読んでいただいてありがとうございました。

2023年お疲れ様でした。

はじめに

お久しぶりです。たそ(@taso_int)です。
今日で2023年が終わってしまいますね。皆さんは1年間どう過ごされましたか?
私はこの記事で振り返ろうと思います。あと今回は2024年の抱負も書きたいと思います。 ただ急遽母が昨日入院することになって少し正月ですがバタバタしてます。

総括

今年は正直いい1年かと言われると微妙でした。
仕事面に関してはもっと頑張ることが出来たのではないかと思います。
プライベートに関しては少しいいこともあった1年でした。

仕事面

仕事の面では、初めて兼務ということで主業務の他にエンジニアリングメンター室という部署でエンジニアを支えるお手伝いをしていました。
具体的なお手伝いの内容は紹介を見せたほうがいいのですが、このあと予定があるので省略します。すいません。
個人的には他のエンジニアの役に立ってるという気持ちが芽生えたので良い経験でした。今後も続けていきたいです。 また、会社を巻き込んでブログイベントも開催できたのは個人的には良かったと思いました。

技術面では初の社外登壇が出来たのは良かったです。来年はもっと登壇数を増やしていけたらと思ってます。
ただし、アウトプットが以前より減ってしまったのが良くないです。これはかなり反省です。
多分以前よりアウトプットのハードルをあげようとしてしまい。手が進まなくなったのが原因の一つですね。 もう少し軽いアウトプットを心がけたいです。

資格取得の方はaz-700は取れたものの正直物足りないです。
今後のキャリアのためにもそれなりに資格は取っておきたい気持ちです。

プライベート面

まずは筋トレが1年以上つづいたことが正直うれしいです。
筋トレ初めてから1年以上筋トレが続く人は4%しかいないらしい(出展不明)ので、頑張りました。 体重もMAXから8キロ〜9キロぐらい落ちたので、もっと落としたいです。 MAXの写真からするとまあマシになったけどまだ太ってるなって感じですね。

他にもありますが、大きいのは筋トレの習慣が出来たことですね。

最後に

来年は今年よりも良い1年を過ごしたいと思います。
このブログの読者様、会社の皆様、Xの皆様、1年間ありがとうございました。
来年もよろしくおねがいします。

AAP 2.4 EDA(Event-Driven Ansible) Controller を使う

AAP2.4 EDA(Event-Driven Ansible) Controllerを使ってみる。

最初に

こんにちは たそ(@taso_int)です。8月になりました。 今日は前回構築したEDA Controllerを実際に動かしていきたいと思います。 だいぶ遅くってすみません…(1ヶ月前かも…) 寝かせてたので情報古くてすみません。 ボツにするのも勿体ないので…

前回はこちら

taso-int.hatenablog.com

単体で動かす

やることは以下の通りです。

また、EDAを動かす際必ず連携しているAnsible Automation ControllerやAWX等は用意しておきましょう。(起動はさせる) 簡潔に話すとDecision Environmentsが起動するとinstall時に登録したControllerにアクセスを試みようとします。 そこで接続が出来ないとDecision Environmentsが上手く動かない可能性が高いです。

環境

AWS環境

プロジェクトの作成(rulebookの用意)

プロジェクトの作成をします。 これはrulebookが書かれているリポジトリを登録する必要があります。 ちなみにrulebookのドキュメントはこちらになります。

またrulebook書くのめんどくさい人向けにリポジトリを用意したので、適当に使ってください。 検証で使ってるのでいろいろとアップデートあるかもしれません。

今回はこのrulebook(rulr_hello)を動かします。

---
- name: Hello Events
  hosts: all

  sources:
    - ansible.eda.webhook:
        host: 0.0.0.0
        port: 5005

  rules:
    - name: Say Hello World
      condition: event.payload.message == "Hello"
      action:
        debug:
          msg: "Hello World"

イベント側ではがansible.eda.webhookモジュールを使って5005番portの受信を有効化しています。 一方、アクション側では、届いたペイロードのmessageがHelloの値であれば、Hello Worldを出力します。

プロジェクトからプロジェクトの作成で登録します。

Decision Environmentsの指定

Decision Environmentsは憶測にはなりますが、実際に動かすAnsible-rulebookのコンテナ環境のことだと思います。 イメージだとAnsible Automation ControllerのEEと似たような役割をしていると思います。

今回はインストール時に登録されているデフォルトのものを利用します。

恐らく、個別でコミュニティのedaコレクション等を使いたい場合は、Ansible builderでDecision Environmentsを作成する必要があると思います。

rulebookのアクティベーション

ルールブックのアクティベーションからルールブックの作成で作成します。

作成するとアクティベーションステータスが実行中になれば、動いている状態になります。

実際に動かす

Curlコマンドを使って実際にイベントを起こして、アクションをさせたいと思います。 以下のコマンドを入力します。(EDAのホストにちゃんとルーティングが出来る前提になります。)

curl -H 'Content-Type: application/json' -d "{\"message\": \"Hello\"}" IPアドレス:5005

問題なければルール監査に実行結果が表示されます。

また、ルールブックのアクティベーションから名前(今回はHello world)から履歴をクリックすると詳細で出力が見れます。

以上で単体での確認になります。

最後に

軽く触ってみました。
次は、Builderを使ってEDA用のイメージを作成が出来たらなと思います。

AAP2.4 EDA(Event-Driven Ansible) Controller install on AWS

最初に

こんにちは たそ(@taso_int)です。 めちゃくちゃ暑いですね。封印していたエアコンを遂に解禁しました。(解禁するのは渋るけど解禁したら使いがち)
今日は最近リリースされたAnsible Automation Platformのバージョン2.4に含まれているEvent-Driven Ansible ControllerをAWS環境上でインストールしたいと思います。
今回のバージョンの目玉ぽい印象があります。連携周りに関しては次のブログで話せればと思います。

AAP2.4で追加された内容について

Event-Driven Ansibleの紹介をする前にAAP2.4の新機能を軽く確認したいと思います。 Red Hatの公式では以下のサイトで紹介をしています。

www.ansible.com

主な内容は以下です。英語苦手なので間違ってたら申し訳ないです。 Ansible LightspeedはAAPの一部ではないので、省略します。

  • Event-Driven Ansible 今日の内容
  • コレクションリポジトリ管理 アクセスの制御を細かく出来るようになったらしい
  • Validated contentの追加 いくつかの検証済みコンテンツがAutomation Hubに追加
  • Ansible Builder 3.0 EEを作成するツールのバージョンが上がって、ビルダーイメージが廃止されベースイメージが幅広く指定出来るようになった
  • ARMアーキテクチャでのプラットフォームインストールサポート Mac環境とかでもインストールしやすくなったらしい
  • UIの更新(プレビュー) 新規のUIがプレビューですが、確認できます。詳しくはhttps://www.youtube.com/watch?v=IBtGCQBkM0Aより

盛りだくさんですね。

Event-Driven Ansibleについて

イベント駆動型 Ansibleは、特定の事象が起こったときに、それに対応する行動を自動で行うシステムです。Ansible Rulebooksというルールを定義して、どのようなイベントでどうアクションするかを決めます。

イベントではEvent Source Pluginというものが提供されており、現在だとPartner's collections(Zabbizなど)とansible.eda Collection(Webhooksなど)があり、設定をする際に使用するを想定されています。

アクションには、既存の Ansible Playbook、テンプレート、またはモジュールの実行が含まれているとのことです。

今回リリースされたのは、Event-Driven Ansible Controllerになります。 Event-Driven Ansibleのインターフェイスで、イベントソースの連携や、Ansible Automation controllerの連携が可能になります。

Event-Driven Ansible Controller のインストール

公式情報

access.redhat.com

access.redhat.com

インストール資材

AWS環境

事前にインストーラー(ansible-automation-platform-setup-bundle-2.4-1-x86_64.tar.gz)を用意してインスタンス内に入れてください。ファイル容量が多いのでまあまあ時間かかります。

インストーラーの場所 https://access.redhat.com/downloads/content/480/ver=2.4/rhel---9/2.4/x86_64/product-software

恐らく、Event-Driven Ansible Controller単体だと何もできないので、別でAnsible Automation ControllerやAWX等は用意した方がいいと思います。 また両方を同時のホストにインストールするのは難しいと思います。試してはないです。

展開および移動

tar xvfz ansible-automation-platform-setup-bundle-2.4-1-x86_64.tar.gz
cd ansible-automation-platform-setup-bundle-2.4-1-x86_64

inventoryの追記

いつも通りinventoryの追記をしていきます。 追記箇所だけ表示します。

[automationedacontroller]
Host名 ansible_connection=local ansible_host=localhost

# Automation EDA Controller Configuration
#
required_ram=true #メモリ対策
automationedacontroller_admin_password='edaのパスワード'

automationedacontroller_pg_host=''
automationedacontroller_pg_port=5432

automationedacontroller_pg_database='automationedacontroller'
automationedacontroller_pg_username='automationedacontroller'
automationedacontroller_pg_password='パスワード'

# The full routeable URL used by EDA to connect to a controller host.
# in inventory.
#
automation_controller_main_url = 'Ansible Automation ContorllerのURL'

修正が完了したらsudo ./setup.shを実行します。 インストールは成功して画面は見れますが、ログイン時に400エラーになります。

理由としては以下の通りです

EDA Controllerがインストールする際に自動的にALLOWED_HOSTSを設定します。 これが、インストーラーがよしなにホストが所持しているIPをALLOWED_HOSTSに入れるのですが、EC2自体がグローバルIPを持たないので追加されません。そのため対策をする必要があります。

詳しくは、てくなべを確認してください。いつもお世話になっております。

tekunabe.hatenablog.jp

今回はグローバルIPを固定しないので、以下の操作をします。

  1. /etc/ansible-automation-platform/eda/environmentを開く。
  2. EDA_ALLOWED_HOSTS*を追加する。
  3. sudo systemctl restart automation-eda-controllerを実行します。

inventoryにautomationedacontroller_allowed_hostnames='*'を入れるとNginx周りでエラーが起きてインストールが出来なかったので断念しました。

ログインしてみる

ユーザーはadminでパスワードはautomationedacontroller_admin_passwordの値になります。

インストールは以上です。お疲れ様でした。

最後に

今回はAnsible Automation Platformのバージョン2.4に含まれているEvent-Driven Ansible Controllerをインストールする方法について書きました。
次回は連携をしてみて実際に動かしてみたいと思います。
ここまで読んでいただきありがとうございました。

Terraform Cloudを使ってみた

最初に

こんにちは たそ(@taso_int)です。 1年も半分が過ぎようとしています。色々忙しいですね。 6/14~6/16までInteropが開催されます。私は2日目と3日目に参加します。 なので私に会いたい方は2日目か3日目にお願いします。(需要ゼロ)

今日はTerraform Cloudを触っていこうと思います。 公式にTerraform Cloudのチュートリアルをそのまま進めていきます。 ローカルからTerraform cloudにアクセスし、AWS内にEC2インスタンスを立てます。

developer.hashicorp.com

Terraform Cloudとは

Terraform Cloudは、HashiCorpによって提供されるInfrastructure as Code (IaC)ツール、Terraformのクラウドベースのプラットフォームを指します。

Terraformを動かす際に、ローカル マシンではなく一貫性のある信頼性の高い環境で Terraform の実行を管理することでデータや機密情報を安全に保存することが出来ます。さらにバージョン管理システム(GitHub)に接続が出来るので、管理や開発がしやすくなります。

まだ全容が分かってないですが、個人的にはTerraformの実行をTerraform Cloud側が担ってくれるのは結構ありがたいと思いました。

内容

最初に話した通り、公式にTerraform cloudのチュートリアルをそのまま進めていきます。 ゴールとしてはAWS内にEC2インスタンスを立てるところになります。

https://developer.hashicorp.com/terraform/tutorials/cloud-get-started/cloud-sign-up

環境

以下に環境と準備について書いておきます。
今回はAWSでTerraformのCLIを実行するためにインスタンスを立てましたが、GitHubのCodespacesでやるのもありだと思いました。

実行環境 AWS
Amazon linux t2.micro
Terraform v1.4.6 on linux_amd64

その他
Terraform Cloudのログイン準備および組織の作成
AWSのクレデンシャル準備

インストール

ターミナルからサクッとインストールします。他のインストールに関してはドキュメントを参考にしてください。

developer.hashicorp.com

sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/AmazonLinux/hashicorp.repo
sudo yum -y install terraform
$ terraform version
Terraform v1.4.6 on linux_amd64

Terraform Cloudと連携

ブラウザTerraform Cloudにアクセスをして、Tokenを生成します。 余談ですが最初API Tokenを生成して、その後のTerraform の実行に失敗しました。 恐らくユーザーのTokenが必要になるかと思います。

https://app.terraform.io/app/settings/tokens

ターミナルからTerraform Cloudにログインします。

Terraform login
Do you want to proceed?
  Only 'yes' will be accepted to confirm. ## yesとうつ

  Enter a value: yes

Token for app.terraform.io:
  Enter a value: <API token>

上手く行くとログインできます。

クレデンシャルの登録

Terraform Cloudには変数セットがあり、そこに変数を登録することでワークスペースなどで再利用することが可能です。 今回だとAWSのクレデンシャルが当てはまります。

Setting→Variable sets→Create Variable setで作成できます。 KeyとValueで登録することが出来て、複数登録が可能です。 今回はAWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEYをenvironmentのオプションを選択して登録します。 またSensitiveの属性を付けることで隠すことが出来ます。

ワークスペースの作成

チュートリアル用にリポジトリがあるので、ターミナルからそれをCloneします。

https://github.com/bashicorp/learn-terraform-cloud.git

git clone https://github.com/bashicorp/learn-terraform-cloud.git
cd learn-terraform-cloud

terraform.tfにTerraform CloudとAWSの情報があり、Terraform Cloudのorganizationを自分が設定した組織名に変更します。

その後terraform initを実行し、Terraform Cloud has been successfully initialized!が出れば、問題ないです。

実際にWorkspacesに追加されます。

Terraform変数の登録

ワークスペース内で使用する変数を登録します。 ワークスペース→Variable→Workspace variables→Add variable

今回はinstance_nameとinstance_typeを設定します。

Terraformの実行

ターミナルからTerraform applyを実行します。問題なければ成功します。 今回はus-west-1(北カリフォルニア)で作成されています。

またTerraform Cloud側で実行履歴や何を作成したかを画面で確認できます。

Terraform CloudのUIで実行する場合は、runs→Start a new runで実行できます。

作成リソースの削除

リソースが作られたことが確認できたので、削除します。 ターミナルからTerraform destroyを実行します。

Terraform CloudのUIで実行する場合は、Setting→Destruction and Deletion→Queue destroy planを実行します。

Runsの同カテゴリではなかったです。

感想

Terraform Cloudを少し触ってみましたが、めちゃくちゃ便利ですね。 クレデンシャルの管理とか実行履歴系など欲しいところをちゃんと機能としてあるのがとても良いと思いました。 Azureでも試してみたいので近いうちにやろうと思います。 ここまで読んでいただきありがとうございました。

Collectionのバージョンに対応したドキュメントを確認する方法

はじめに

お疲れ様です。 こんにちは たそ(taso_int)です。 お久しぶりです。
最近ブログのモチベがあまり上がらず… リハビリがてらブログを書いていきます。

今日はあまり技術的な内容ではないですが、書いていきます。

AnsibleのCollectionsのバージョンに対応したドキュメントの探し方について書きます。
ただし、Collectionsの説明については省略します。

Collectionsのバージョンが上がると各moduleに新しいオプションが追加される場合があります。 どのバージョンからオプションが対応しているか分からないケースがあり、それを確認するために利用しているバージョンのドキュメントを確認する必要があります。

そもそも特段の理由がない限りは最新をインストールすることをお勧めします。

結論

結論としては、最新であればAnsibleのドキュメントにあるCollection index(https://docs.ansible.com/ansible/latest/collections/index.html)から、過去のバージョンであれば、Automation hub(https://console.redhat.com/ansible/automation-hub)から確認すると良いです。

Automation hubの方はRed Hatのアカウントが必要になります。

試してみる

Azureのリソースを動かすときに使うazure.azcollection(https://github.com/ansible-collections/azure)のazure_rm_virtualmachine moduleを例にして確認したいと思います。

現在(2023/05/28)ではazure.azcollectionの最新バージョンは1.15.0です。

最新バージョンのドキュメント

Collection indexからazure.azcollectionをクリックし、対象のモジュールをクリックすることで最新のドキュメントを確認できます。

メモにも"This module is part of the azure.azcollection collection (version 1.15.0)."と記載されており、1.15.0であることが分かります。

恐らくですが、URLの文字列にあるlatestをAnsibleのバージョン(7など)に変えることでAnsibeのリリース時点でのCollectionの最新を見ることが出来ます。

Ansibeのバージョン4時点での最新のCollectionを見たければこのURL(https://docs.ansible.com/ansible/4/collections/azure/azcollection)のような書き方で確認出来ると思います。

過去バージョンのドキュメント

azure.azcollectionのバージョン1.12.0のazure_rm_virtualmachine moduleを確認したいと思います。

Automation Hubにアクセスして、Collectionsからazcollectionを探してクリックします。

トップ画面にバージョンの指定があるので、1.12.0を選択します。 そしてドキュメントからazure_rm_virtualmachineを選択して確認することが出来ます。

最後に

以上の手順でCollectionのバージョンに対応したドキュメントを確認することが出来ます。 ドキュメント以外でオプションが対応してるかを確かめる方法として考えられるのはソースコードを確認するとかですかね。 短いですが、読んでいただきありがとうございました。