APC Automation blog

ネットワーク自動化支援のAutomation Coordinatorを提供する、エーピーコミュニケーションズ ACTの自動化ブログ

「年1回の証明書更新」はもう限界？証明書短命化時代のインフラ運用設計

はじめに

こんにちは。BzD部 ACTの中山です。

公開TLS証明書の有効期間は、今後段階的に短縮され、最終的には47日まで短くなる方針が示されています。

これにより、これまで年次作業として扱っていた証明書更新は、より短いサイクルで確実に実施する必要があります。 特に、複数サイト・複数システムで証明書を管理している組織では、手作業による更新漏れや反映漏れのリスクが高まります。

本記事では、発行済みの証明書や秘密鍵を HashiCorp Vault で安全に保管し、 Ansible で各サーバやロードバランサへ配布・反映・確認する運用設計の考え方を紹介します。

コード実装には踏み込まず、今後の証明書運用を見直したい管理者層やインフラ担当者向けに解説します。

証明書更新は「年1回の作業」ではなくなる

TLS証明書は、Webサービス、API、管理画面、ロードバランサなど、さまざまな場所で利用されています。

これまでは、有効期間が約1年あることを前提に、証明書更新を年次作業や半期作業として扱っていた組織も多いと思います。しかし、公開TLS証明書の有効期間は今後段階的に短縮され、より短いサイクルで更新を行う必要があります。

一方で、複数サイト、複数システム、複数ロードバランサ、複数チームで証明書を扱う環境では、対象が増えるほど更新漏れやオペレーションミスが起きやすくなります。 期限切れそのものは証明書の枚数に関係なくサービス停止やブラウザ警告につながるリスクがありますが、管理対象が多いほど、そのリスクを未然に防ぐための運用難易度は高くなります。

そのため、これからの証明書更新は「担当者が手動で対応する運用」ではなく、「仕組みで継続的に回す運用」として設計していく必要があります。

証明書47日問題とは何か

ここで挙げている「証明書47日問題」とは、公開TLS証明書の有効期間が段階的に短縮され、最終的に47日となることで、証明書運用の負荷が大きくなる問題を指しています。

具体的には、以下のような段階的な短縮が行われます。

時期 公開TLS証明書の最大有効期間
現在 約1年
2026年3月15日以降 最大200日
2027年3月15日以降 最大100日
2029年3月15日以降 最大47日

これまで「年1回の更新作業」が、今後は数か月単位、最終的には1〜2か月単位で繰り返される運用になります。

そのため、最終的な47日化を待ってから対応するのではなく、今のうちから手作業や属人化を前提にした証明書運用を見直す必要があります。

なぜ有効期間は短縮されるのか

証明書の有効期間短縮は、Web PKI 全体の信頼性を高めるための取り組みです。

CA/B Forum では、証明書の有効期間や検証済みデータの再利用期間を短縮することで、Web PKIの健全性を高める方向性を示しています。

TLS証明書は、発行時点でドメインや組織情報が正しいことを示すものですが、時間が経つほど実態とずれる可能性があります。

たとえば、ドメイン管理者の変更、組織情報の変更、秘密鍵の管理状態の変化などが起きた場合、長期間有効な証明書ほど古い情報が残り続けやすくなります。

証明書の有効期間を短くすることで、古い情報を含む証明書や問題のある証明書が使われ続ける期間を短くできます。

セキュリティ上は合理的な変更ですが、利用者側から見ると運用負担は確実に増えます。 そのため、証明書更新を手作業で管理するのではなく、短いサイクルで確実に更新できる仕組みが必要になります。

大量の証明書を扱う環境で起きる課題

証明書が数枚であれば、台帳と手作業でもなんとか運用できるかもしれませんが、実際のインフラでは、証明書はさまざまな場所に配置されています。

たとえば、以下のような場所です。

  • Webサーバ
  • ロードバランサ
  • リバースプロキシ
  • WAF
  • CDN
  • Kubernetes
  • メールサーバ
  • 各種ソフトウェアのWebコンソール
  • ネットワーク機器

証明書の配置先が増えるほど、「どこで」「どの証明書が」「いつ期限切れになるのか」を把握することが難しくなります。

また、証明書更新には、単に新しい証明書を取得するだけではなく、秘密鍵の管理、証明書の配置、サービスへの反映、反映後の確認といった作業が伴います。

これらを手作業で行っている場合、運用対象が増えるほど、更新漏れ、配置漏れ、反映漏れ、確認漏れのリスクも高まります。 証明書の有効期間が短くなる時代では、証明書更新を「担当者が頑張って管理する作業」として扱い続けるのは難しくなります。

必要になるのは「更新できる仕組み」

証明書47日問題で考えるべきポイントは、単に証明書の期限が短くなることではありません。

重要なのは、証明書更新を「担当者が覚えて対応する作業」から、「短いサイクルで安全に、確実に同じ品質で更新できる仕組み」へ変えていくことです。

具体的には、以下のような状態を目指す必要があります。

  • 証明書の配置先を把握できている
  • 証明書や秘密鍵を安全な場所で管理できている
  • 必要な機器やサーバへ同じ手順で配布できる
  • 更新後に正しく反映されたことを確認できる
  • 作業履歴やアクセス履歴を追跡できる
  • 特定の担当者に依存しない運用になっている

つまり、これからの証明書運用では、証明書そのものだけでなく、証明書を扱うプロセス全体を整備することが重要になります。

解決アプローチ：Ansible × HashiCorp Vault

この課題に対するアプローチの一つが、Ansible と HashiCorp Vault を組み合わせた運用です。

Ansible と HashiCorp Vault を利用した証明書更新運用の全体像

※①期限検知は、Vault に保管された証明書情報や、実際に公開されているTLS証明書の有効期間を確認する運用を想定しています。

ここでのポイントは、Vault を証明書発行基盤として使うのではなく、発行済みの証明書や秘密鍵を安全に保管する場所として利用することです。

HashiCorp Vault は、シークレットを安全に保管・管理するための仕組みを提供します。証明書や秘密鍵などの機密情報を管理する用途にも利用できます。

一方、Ansible は各サーバやロードバランサに対して、証明書を配布し、サービスへ反映し、反映後の状態を確認する役割を担います。

Ansible は複数の管理対象に対して構成変更や運用作業を自動化できるツールであり、証明書更新のように「同じ作業を複数対象に安全に繰り返す」運用と相性が良いです。

それぞれの役割を整理すると、以下のようになります。

  • Vault：発行済み証明書、秘密鍵、中間証明書を安全に保管する
  • Vault Policy：誰が、どの証明書情報へアクセスできるかを制御する
  • Ansible：Vault から証明書情報を取得し、対象機器へ配布する
  • Ansible：証明書反映後にサービスのリロードや状態確認を行う
  • 監査ログ：証明書情報に、いつ、誰がアクセスしたかを追跡する

上記のような構成を設計することで、証明書更新を属人的な作業から、継続的に回せる運用へ変えていくことができます。

管理者視点で見たときのメリット

管理者視点では、Ansible と HashiCorp Vault を導入するメリットは、単に作業時間を短縮できることだけではありません。 より重要なのは、証明書更新の属人性を下げ、運用品質を安定させられることです。

たとえば、以下のような効果が期待できます。

  • 証明書や秘密鍵の保管場所を集約できる
  • 証明書更新作業を標準化できる
  • 更新漏れや反映漏れを減らせる
  • 作業履歴やアクセス履歴を追跡しやすくなる
  • 担当者変更時の引き継ぎリスクを減らせる
  • 証明書有効期間の短縮に備えた運用基盤を作れる

証明書更新は、普段は見えにくい運用ではありますが、失敗するとサービス停止や信頼低下につながります。

だからこそ、問題が起きる前に、仕組みとして整えておくことが重要です。

まず取り組むべきこと

いきなり全証明書を自動化するのは現実的ではありません。 まずは、現在の証明書運用を把握するところから始めるのがよいです。

最初に確認すべきことは、以下のような内容です。

  • どの証明書が存在するか
  • どの FQDN で利用しているか
  • どのサーバや機器に配置されているか
  • いつ期限切れになるか
  • 誰が管理しているか
  • 秘密鍵をどこで保管しているか
  • 更新手順が標準化されているか

この棚卸しができていない状態で自動化を始めると、管理対象から漏れる証明書が出てしまいます。 そのため、最初の一歩は「自動化すること」ではなく、「管理対象を明確にすること」が重要です。

そのうえで、証明書や秘密鍵の保管先として Vault を整備し、配布・反映・確認の部分を Ansible で標準化していく流れが現実的です。

まとめ

公開TLS証明書の有効期間短縮により、証明書更新はこれまで以上に高頻度な運用になります。

証明書の枚数が少ない環境では大きな問題に見えにくいかもしれません。 しかし、複数サイト、複数システム、複数機器で証明書を扱う環境では、手作業や属人化を前提にした運用は大きなリスクになります。

今後は、証明書更新を「担当者が覚えて対応する作業」ではなく、「短いサイクルで確実に回せる仕組み」として設計することが重要です。

そのアプローチとして、発行済み証明書や秘密鍵を HashiCorp Vault で安全に保管し、Ansible で各サーバやロードバランサへ配布・反映・確認する構成は有効な選択肢になります。

証明書47日問題は、単なる期限短縮の話ではありません。 証明書管理をより安全で、再現性があり、属人化しない運用へ変えるきっかけになるはずです。

これからの証明書運用を見直す際の参考になれば幸いです。

Automates登壇レポート：実践型自動化CoEワークショップで「形骸化しない」自動化を目指す！

はじめに

皆さん、こんにちは！ACTの木村昌哉です。

先日、Red Hat社が主催する国内最大級の自動化イベント「Ansible Automates 2025 Japan」に、SOMPOシステムズ様との共同登壇という形で参加させていただきました。本ブログでは、登壇の様子や率直な感想をお伝えするとともに、弊社が提供する「自動化CoEワークショップ」の概要と、皆さんの組織にもたらすメリットを深く掘り下げてご紹介します。

本記事は、以下のような課題を抱える皆様にとって、お役に立てる内容となっております。

  • これから自動化を始めたいが、何から手をつけていいか分からない方
  • 自動化を導入したものの、なかなか成果が出ず、うまくいっていないと感じる方
  • 技術スキルはあっても、組織的にどう現場に落とし込み、活用すべきか悩んでいる方

Ansible Automatesとは？

まずは「Ansible Automates」について簡単にご紹介します。 冒頭でも触れた通り、このイベントはRed Hat社が主催する、自動化に特化した国内最大級のイベントです。Red Hat社が提唱する「自動化2.0」という概念を中心に、各企業がAnsibleやRedHat® Ansible® Automation Platform（通称AAP）を用いた自動化事例や最新情報を紹介する、まさに「自動化の祭典」ともいえる場となっています。　　

今年のテーマは<「AI × 自動化」で切り拓く未来のインフラ運用！インフラ自動化の最前線に迫る！>でした。多くの企業がAnsibleやAAPを活用した先進的な取り組みを発表しており、自動化の進化のスピードを肌で感じることができました。

ご視聴がまだの方は、後日録画が配信されますので、ぜひチェックしてみてください。（録画視聴にはRed Hat社ウェビナーへの登録が必要になります。）

Ansible Automates 2025 Japan

エーピーコミュニケーションズとしてのAutomates

弊社としては、今回で4回目の登壇となりました。いずれも他社様との共同登壇という形ではありますが、お客様の自動化ご支援事例をご紹介し続けています。今回は国内損害保険会社大手の子会社である、SOMPOシステムズ様との共同登壇という運びになりました。

共同登壇のタイトルは<「ネットワーク担当受難の時代」を乗り切る運用高度化のビジョンと実践>です。SOMPOシステムズ様でのネットワーク運用高度化に向けたビジョンと、弊社との「協働」による実践内容についてご紹介しました。

Automates登壇の様子と感想

今回の登壇では、<SOMPOシステムズ様が当初抱えていた「自動化ツールの導入がゴールとなっていた」という課題に対し、弊社の「自動化内製化支援」として実践型自動化CoEワークショップをご提供することで、SOMPOシステムズ様の自動化推進チームが「実践知を習得」し「全体最適化の視座を習得」することを支援し、結果として「自ら業務を変革する文化の礎」を築くという大きな成果を上げることができた>、というストーリーをお話ししました。また「自動化内製化支援」と並行して、自動化環境の整備やAAPの構築、運用手順のPlaybook化を含む「自動化導入サービス」を実施することで、お客様の初期負担を大きく軽減したことについても登壇の中で触れております。まさに「協働」によって段階的に自走できる構造を構築できた、という事例をご紹介させていただきました。

ここからは登壇の裏話も交えながら当時の様子を少し振り返りたいと思います。今回は都内某所のスタジオから、ライブ配信形式で視聴者の皆様にお届けする登壇となりました。 もちろん、人生で初めてカメラを前に話すという機会になったので、多少どころか、とても緊張しました（笑）。ですが、頭が真っ白になってもよいように、PowerPointのスピーカーノートに話す内容を事細かに記載していたおかげで、伝えたいことを無事に届けられたのではないかと考えています。

Auotmates登壇時の様子

登壇を終えて、正直なところホッとした気持ちと、多くの方に私たちの取り組みを伝えられた喜びでいっぱいです。 登壇前に直属の上司から「登壇自体に意義があるので、多少のミスは気にしないように」と温かいメッセージをいただき、自信をもって本番に臨むことができました。ライブ配信という都合上、視聴者の皆様の反応を直接見ることはできませんでしたが、少しでも魅力的に感じてくださる方がいれば嬉しいなと願っております。

自動化CoEワークショップとは？そして受講するメリット

ここからは登壇でも触れた「自動化CoEワークショップ」についてご紹介します。

なぜ自動化が進まないのか？

そもそも、多くの企業で自動化を進めるにあたって、なかなか成果が出ないという課題に直面しています。弊社では、その要因が複数あり、それらが複合的に絡み合うことで大きな障壁となっていると考えています。

代表的な課題 具体的な課題の中身
戦略・計画の課題 ゴールの曖昧さ、費用対効果の評価困難
業務プロセスと運用の課題 業務再設計の困難さ、部門横断連携の壁
人材と組織文化の課題 従業員の抵抗、経営層のコミットメント不足
技術・システムの課題 技術スキルの現場適用、ノウハウ不足、既存システム制約

このような状況では、自動化を進めるためには、戦略的に、そして組織横断的に自動化を推進する「司令塔」となる存在が必要です。 その存在こそが自動化CoEです。CoEとは、Center of Excellenceの略で、一般的には「組織横断的な課題解決を目指すチームや機能」を意味します。 私たちは、自動化CoEは単なる「技術者集団」ではなく、組織全体に変革をもたらす力強い「推進力」である、と考えています。その司令塔を育成するためのワークショップが、弊社の実践型の自動化CoEワークショップなのです。

自動化CoEワークショップの特徴とは？

弊社がご提供する実践型の自動化CoEワークショップについてご紹介します。

  • 1時間×5回＝計5時間の手を動かすワークが中心のプログラム: 座学だけでなく、実際の企業が抱える課題を題材として深掘りし、現場目線で課題を体感し、その改善策までを考える、「実践知」の習得にこだわった内容です。
  • 現役の自動化エンジニアがファシリテーション: 現場のリアルな課題や、自動化推進の「生きたノウハウ」を持つ現役エンジニアがファシリテーターを務めます。
  • 「自動化2.0」への視点: 単なる作業自動化（自動化1.0）に留まらず、人や組織のオーバーヘッドを削減し、業務プロセス全体の最適化・変革を目指す「自動化2.0」の視点を養います。

結果として、参加者が自動化の本質をつかむことで、形骸化しない「現場を変える力」を養うことにつながると考えています。

自動化CoEワークショップを受講するメリット

受講することで、具体的に以下のような変化が期待できます。

  • 意識変革と全体最適の視座獲得 : 「局所最適」に陥りがちな視点から脱却し、自動化が組織全体に与える影響を考慮した「全体最適」の視座を獲得できます。
  • CoEメンバーとしての役割認識の深化 : 単なる「やることリスト」の実行者ではなく、組織全体の変革を牽引する「司令塔」としての役割を明確に認識できるようになります。
  • 実践的な課題解決能力の向上 : ワークを通じて、現場の課題を特定し、業務フローを見直し、改善策を実行に移すための具体的な「現場を変える力」を養うことができます。
  • 「自ら業務を変革する文化」の礎 : 従業員のスキルアップとエンゲージメントを高め、組織全体に「自ら改善・変革していく」という文化を根付かせるための強固な土台を築きます。

自動化CoEが目指す未来

自動化CoEが目指す未来を一言で表すなら、Red Hat社が提唱する「自動化2.0」の考え方を体現することです。これは、局所的な自動化ではなく、業務プロセス全体を俯瞰して進める自動化を意味します。

自動化CoEが立ち上がったばかりは、その影響範囲はまだ限定的かもしれません。しかし、その取り組みは、この全体最適化の視座を持ち合わせ、また人や組織を巻き込んだ変革力を組み合わせることで、最終的には自律的な変革力を持つ文化の構築につながると確信しています。

この未来を築く上で、初速を得るための「協働」が自動化成功の鍵の一つになりうると思います。「協働」により、強力な推進力をもった自社で運用可能な自動化2.0を目指すことができると信じています。

まとめ

本レポートでは、まず先日開催された「Ansible Automates 2025 Japan」の様子と、私の登壇の感想をお伝えしました。SOMPOシステムズ様と共同登壇させていただき、ネットワーク運用高度化に向けたビジョンと、協働による実践内容をご紹介できたことを大変嬉しく思います。

次に、弊社の「自動化CoEワークショップ」について詳しくご説明しました。この実践型のワークショップを通して、参加者は実際の企業が抱える課題の体感から課題の解決までを体験し、「実践知」の習得と「全体最適化の視座」を獲得することを目指しています。

自動化推進の次の一歩を私たちと踏み出すには

自動化をこれから始めたい方、始めたけどうまくいっていない方、技術はあるが現場にどう落とし込んでいくか悩んでいる方など、自動化に対する課題をお持ちの方々は、一度弊社の自動化CoEワークショップをご検討ください。
状況に合わせた自動化推進のアイデアを手に入れていただけます。

「まずは情報収集から」「自社のケースで相談したい」といった方は

下記のURLから無料相談をお気軽にご依頼いただけます。
[【無料】30～60分のオンライン無料相談へのお申し込み]
(https://form.k3r.jp/apc_act/act_Applicationform)

TerraformとAnsibleの連携「効率的なITインフラ運用の実現」

はじめに

こんにちは、iTOC事業部ACTのエンジニアKです。
IaCツールで有名なものとしてTerraformとAnsibleがありますが、これらはどちらもコードとしてインフラを定義し管理します。
そのため、どちらか片方のツールのみでもインフラプロビジョニングは可能です。
ですが、AnsibleとTerraformを組み合わせることで効率的なITインフラ運用を実現することができます。
そこで今回はAnsibleとTerraformの連携について紹介します。
業務等でAnsibleやTerraformを使用されている方に読んでいただきたい内容です。

AnsibleとTerraformの違いについて

まずは本記事で扱うAnsibleとTerraformの違いについて簡単に説明します。
・得意な領域が異なるため、自動化を行いたい対象や範囲によって使うツールを選び使い分ける ・オンプレミスのNW機器やセキュリティ製品、OSレイヤ以上の自動化はAnsibleが得意とする領域 ・ハイパーバイザーやクラウドサービス上のインフラリソースの自動化はTerraformが得意とする領域 違いについて、より詳細に知りたい方は、弊ブログにそれぞれを解説した記事があるのでそちらを参照してください。
AnsibleとTerraformの違い、使い分けについて

連携することのメリット

ここからはAnsibleとTerraformの得意領域について言及しつつ、連携することのメリットを説明します。

①インフラのプロビジョニングと構成管理の統合

Terraformはインフラのプロビジョニングに優れており、クラウドリソースの作成や管理をコードで行います。
一方、Ansibleは構成管理に強く、サーバやアプリケーションの設定をコードで自動化します。
AnsibleとTerraformを連携することにより、インフラのセットアップからアプリケーションのデプロイまで、一貫した自動化が可能になります。

②柔軟性の向上

Terraformの宣言型アプローチとAnsibleの手続き型アプローチを組み合わせることで、複雑なインフラとアプリケーションの管理がより柔軟に行えます。
Terraformでインフラの状態を定義し、Ansibleで詳細な設定やデプロイを行うことで、より細かい制御が可能になります。

③一貫性と再現性の確保

両ツールを併せて使用することで、インフラとアプリケーションの設定がコードとして管理されるため、一貫性と再現性が向上します。
これにより、環境間での差異を減らし、デプロイの信頼性を高めることができます。

3点のメリットを簡単にまとめると、「AnsibleはGUIで管理をするがTerraformはコードで管理をするため、AnsibleとTerraformを連携すると、インターフェースがひとつに統一できるから管理が楽になる」です。

連携の方法

AnsibleからTerraformを呼び出す方法にはいくつかのアプローチがあります。以下にその方法を説明します。

①ansible.builtin.shellモジュールの利用

ansible.builtin.shellモジュールを使用して、シェルコマンドとしてTerraformを実行する方法もあります。
この方法では、Ansibleタスク内で直接terraform initやterraform applyなどのコマンドを実行します。

②cloud.terraformコレクションの利用

Ansibleのcloud.terraform.terraformモジュールを利用して、Terraformプロジェクトを呼び出すことができます。
このモジュールを使うことで、Ansible Playbook内で直接Terraformの操作を行うことが可能です。 　 cloud.terraformモジュールはterraformを呼び出す際の設定をyaml形式で入れることができるため視認性が上がります。
またoutputを構造化してくれるのでその後の処理などでも使いやすくなります。
次項目にてcloud.terraformモジュールを詳しく紹介します。

cloud.terraformモジュールの紹介

Ansibleでcloud.terraformモジュールを使用してTerraformを実行する簡単なコードを例に説明します。

以下のコード例は、AnsibleのPlaybookでTerraformを実行し、指定されたプロジェクトパス内のTerraform設定ファイルを適用するものです。

まず、ディレクトリ構成は以下のようにします。

.
├── terraform_test_playbook.yml
└── terraform
    └── main.tf

Terraform設定ファイル（main.tfと） main.tfとvariables.tfには、Terraformの設定を記述します。 ここでは簡単な例として、「sample_instance」というNameタグを持つAWS EC2インスタンスをオハイオリージョン(us-east-2)に作成する設定を示します。
（AWSの認証については今回省略しています。）

main.tf
provider "aws" {
  region = "us-east-2"
}

resource "aws_instance" "example" {
  ami           = "ami-037774efca2da0726"
  instance_type = "t2.micro"
  tags = {
    Name = "sample_instance"
  }
}

Ansible Playbook（terraform_test_playbook.yml） 次に、Ansible Playbookを作成します。このPlaybookは、ローカルホストでTerraformを実行します。

terraform_test_playbook.yml
---
- name: Execute Terraform from Ansible
  hosts: localhost
  connection: local
  tasks:
    - name: Run Terraform
      cloud.terraform.terraform:
        project_path: "./terraform"
        state: present
        force_init: true

このようにして、AnsibleからTerraformを実行することができるようになります。

Automation ControllerからTerraformを実行する場合の例

ここまではオープンソースのAnsibleでの連携を紹介してきました。 しかし、商用導入する場合はRed Hatからエンタープライズ版の製品群であるAnsible Automation Platformを使用する場合が多いです。
AnsibleとAnsible Automation Platformについて AAPの中でAnsibleを用いた自動化の製品としてAutomation Controllerが提供されているので、 Automation ControllerからTerraformを実行する例を紹介します。
Automation ControllerからTerraformを 実行する際には、Terraformが導入されたコンテナ環境（Execution Environment 以下 EE）を構築する必要があります。

EEの構築

AnsibleのEEを利用して、Terraformを実行するためには、EE内にTerraformをインストールする必要があります。
Automation Controllerで使用されているデフォルトの EEにはTerraformが含まれていないため、独自にビルドする必要があります。

execution-environment.ymlの作成

・execution-environment.ymlファイルを作成し、必要なパッケージや依存関係を定義します。 ・ansible-builderを使用して、EEをビルドします。 以下に簡単な例を紹介します。

exection-environment.ymlのファイルを作成し、下記を記述します。

version: 3
images:
  base_image:
    name: quay.io/centos/centos:stream9
dependencies:
  ansible_core:
    package_pip: ansible-core
  ansible_runner:
    package_pip: ansible-runner
  galaxy:
    collections:
      - name: cloud.terraform
additional_build_steps:
  append_base: |
    RUN yum install -y git
    RUN curl https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo | tee /etc/yum.repos.d/terraform.repo
    RUN yum install -y terraform


EEのビルド

上記の設定でansible-builder buildコマンドを実行し、Terraformが含まれたEEを作成します。

$ ansible-builder build -t localhost/terraform-ee


Terraformがインストールされていることを確認

ビルドしたEEにTerraformがインストールされているかを確認します。
例えば、以下のコマンドでバージョン確認ができればTerraformがインストールされています。

$ docker run localhost/terraform-ee terraform –version
Terraform v1.9.6
on linux_amd64

このEEを用いることで、AAPからTerraformを用いたジョブを実行することが可能になります。

作成したEEを利用してEC2を構築する

TerraformがインストールされたEEを作成できたので、これでAutomation Controller上から先ほど作成した、AnsibleとTerraformを連携させたPlaybookも実行できるようになります。

細かい設定についてはこの記事内では割愛しますが、最終的には下記のようにボタン一つでクラウドリソースの構築ができるようになります。

上記はAutomation Controllerに設定したAWS EC2インスタンスをプロビジョニングするジョブテンプレートの詳細画面です。 ジョブテンプレートには先ほど紹介したPlaybookを設定しています。

画面下部にある起動ボタンをクリックすることで、ジョブが起動して下記の画面に移ります。

Playbookで設定されているTerraformを利用したEC2プロビジョニングのタスクの結果が「changed」となり、成功していることがわかります。

Automation Controllerのジョブによって「sample_instance」という名前のEC2インスタンスがオハイオリージョン(us-east-2)に作成されていることがわかります。

まとめ

本記事ではAnsibleとTerraformの連携について説明してきました。 内容を簡単にまとめると

・インフラのプロビジョニングと構成管理の統合が可能になる
・複雑なインフラとアプリケーションの管理が柔軟に行える
・インフラとアプリケーションの設定がコードとして管理されるため一貫性と再現性が確保できる

となります。 AnsibleとTerraformはどちらか一方を選択するのではなく、AnsibleとTerraformを連携させることで、それぞれのツールの強みを活かしつつ、自動化の範囲を広げられるだけでなく、自動化フローを１つのツールに集約できるため、インフラとアプリケーションの管理がより効率的になります。

これから自動化を進める方だけでなく、AnsibleやTerraform単体で自動化を進めていた方は、是非TerraformとAnsibleの連携もご一考ください。

AnsibleとTerraformの違い、使い分け

はじめに

こんにちは、iTOC事業部 ACTの西城です。
今回はAnsibleとTerraformにはどういった違いがあるのか、どう使い分けるかを紹介します。
それぞれの名前は分かるが具体的にどう違うのか知らない方や、業務の自動化を検討しているがどのツールを選べばよいか分からない方に読んでいただきたい内容です。
※技術的な内容より、端的にツール毎の特徴を知りたい方は末尾から先に読んでいただけると分かりやすいかもしれません。
　

AnsibleとTerraformについて

まずは本記事で扱うツールについて簡単に説明します。
各ツールについて詳細に知りたい方は、弊ブログにそれぞれを解説した記事があるのでそちらを参照してください。
Ansibleについて
-> Ansibleとはなにか [特徴 | 製品紹介 | 入門 | できること/できないこと] - APC Automation blog
Terraformについて
-> ITインフラ自動化推進: Terraformとは - APC Automation blog

Ansible

現在はRed Hat社が開発しているOSSの構成管理、自動化ツールです。 Pythonで開発されており、インフラの構成を記述したコードはYAML形式で記述します。

Terraform

HashiCorp社が開発したIaCツールです。
Go言語で開発されており、インフラの構成を記述したコードはHCL*形式で記述します。
※HCL(HashiCorp Configuration Language)はHashicorpが開発した言語です。
　
　
開発言語やコードの記述形式は異なりますが、両者ともインフラ構成をコードとして記述するIaC、自動化ツールです。また、AnsibleもTerraformも共に多機能なツールであるため、同様の機能が多くあります。
しかし、特徴や得意な領域が異なるため、自動化を行う対象や範囲によって使い分けることで、ツールを最大限に活用することができます。

Ansible、Terraformがどういったシーンで活用できるか

ここからはAnsibleとTerraformはそれぞれどういった特徴を持っていて、どういったシーンで活用できるのかを説明します。
　

Ansibleの特徴① 得意なこと

エージェントレスでありSSHログイン可能な機器は自動化対象であること

Ansibleは自動化対象の機器にSSHでログインし操作を行います。 自動化対象の機器で事前に行う設定はSSHサーバの設定だけなので、エージェントソフトといった特別なソフトがインストールできない機器または環境でも動作可能です。
※自動化対象の機器やサービスによってはSSHではなく、APIなどを使用して操作するものもあります。

豊富なモジュールにより様々なOS、機器に対応

LinuxやWindowsといったOSや、Cisco, Juniper, F5, Fortinetなど様々なベンダの機器に対応するモジュールが存在します。豊富なモジュールにより、サーバOSの設定、ソフトウェアの設定やNW機器、セキュリティ機器の設定の自動化が行えます。

冪等性が確保しやすい

Ansibleはこれから設定しようとしているコンフィグが既に設定されているかどうかをモジュールが判断してくれるので、冪等性を確保しやすいです。 そのため、冪等性確保のために処理を追加する開発を減らすことができます。

冪等性の例：新規でファイルを作成するコードでは、ファイル作成前に該当のファイルが存在するかを確認して、存在しない場合は作成を行う、既に存在する場合はファイル作成の処理をスキップする。このような動作により同じコードを複数回実行しても結果は同じになる。
　

Terraformの特徴① 得意なこと

豊富なプロバイダーにより、多くのクラウドサービスや仮想化基盤に対応

クラウドサービス(AWS, Azure, Google Cloudなど)はもちろん、オンプレミスで動かしているハイパーバイザー(ESXiやHyper-Vなど)にも使用可能です。

様々なプラットフォームに対する統一された操作

上記のようにTerraformは様々なプラットフォームで使用可能です。そのため、複数種類のクラウドサービスや、クラウドサービスとオンプレミスを組み合わせた環境などで、環境ごとに異なるIaCツールを使用することなくTerraformで管理することが可能になります。

構築したインフラのリソース情報はファイルとして保持

Terraformは構築したリソースの情報を基に、現在のインフラ構成がどうなっているかをテキスト形式の「状態ファイル」で保持します。
Terraform実行時にはコードに記述された理想の状態と、「状態ファイル」に記述された現在の状態を比較し、どのリソースを作成、変更、削除するのかを決定します。必要な変更だけを加えるため、予期しない構成の変更を防ぐことができます。
　
　

Ansibleの特徴② 苦手なこと

自動化対象の機器やサービスに外部からコマンドを入力できる環境が必要

Ansibleは主にSSHを使用して機器に接続するので、対象機器がSSHサーバとして動作する必要があります。 (SSHに対応していない古いNW機器などの場合はTelnet接続も一応できます。)
そのため、SSHサーバおよびIPアドレスの設定は手動または別の方法で行う必要が出てきます。
また、SSH以外の接続方式を使用するモジュールも存在します。
Windowsを操作するモジュールの場合、SSHサーバではなくWinRMの設定を事前に行う必要があります。
APIを使用して接続するモジュールの場合、自動化対象のサービスでAPIから設定が行えるように事前準備を行う必要があります。

対応するモジュールがないと、Ansibleの真価が発揮できない

行いたい設定に対応するモジュールがなくても、CLIで入力するコマンドを使用して設定を行うことは可能ですが、Ansibleの特徴の1つである冪等性が確保できません(冪等性を確保する処理を追加する必要が出てきます)。
　

Terraformの特徴② 苦手なこと

自動化対象のプロバイダー(API)がないと何もできない

IssSや仮想化基盤へのアクセス方法はAPIを経由したものなので、そもそもシステムを操作できるAPIがなかったり、そのAPIを利用したプロバイダーが提供されていないとTerraformは何もできません。

コンフィグの自動化

Terraformでもシェルスクリプトを使用することでVMに対してコンフィグを投入することが可能ですが、Ansibleと比べると柔軟性や再利用性で劣ります。

構築済みの環境への導入

Terraformが正常に動作するには、状態ファイルと実際のインフラ構成が一致している必要があります。そのため、既に構築されている環境にTerraformを導入したい場合は、状態ファイルを実際の構成に合わせる形で修正する作業が必要になります。

管理体制の統一が求められる

理由は1つ上のものと同じになりますが、Terraformで構築した環境にTerraform以外の方法で変更を加えてしまうと、状態ファイルと実際の構成がズレてしまいTerraformの動作に支障が生じます。
そのため、Terraformで構築した環境はTerraform以外からは変更を加えない、といった統一された管理体制が必要になります。
　 　
　

Ansible、Terraform、特徴のまとめ

2つのツールについて簡単にまとめると
・AnsibleはOSレイヤ以上の自動化が得意で、機器の初期設定の自動化が苦手
・Terraformはクラウドサービスやハイパーバイザー上のリソースの自動化が得意、OSレイヤ以上の自動化が苦手
となります。
　
　

既にAnsibleが導入されている環境にTerraformを導入すると、どのようなメリットがあるのか

Ansibleは導入しているがTerraformは導入しておらず、クラウドサービスやハイパーバイザーの管理をAnsibleまたは手動で行っている環境にTerraformを導入することで、どういったメリットがあるかを説明します。

作成したインフラリソースの情報をTerraform側で管理してくれる

Terraformでは構築したインフラリソースを状態ファイルとして保持しますが、Ansibleには作成したインフラリソースの状態を保持する機能はありません。
構築されたインフラがどういった状態かをTerraformが把握することで下記のようなメリットがあります。

変更を適用する前に具体的な変更点を確認できる

Terraformでは状態ファイルとコードに記述された構成を比較し、具体的にどのリソースが作成、削除、変更されるのかを表示します。
具体的な変更点を確認してから、反映させることができます。

Ansibleにもドライラン機能(チェック機能)がありますが、モジュールによっては対応していなかったり、表示内容は変更点があるか否かしか表示されず、具体的に何が作成、削除、変更されるのかまでは分かりません。

環境の削除が容易になる

Terraformは状態ファイルにより現在のインフラ構成を把握するので、Terraformの削除用コマンドを実行するだけで作成した環境を削除することができます。

一方でAnsibleは構築したインフラ構成を把握していないため、環境を削除するためには削除用のコードを別途開発する必要があります。

コード内で依存関係を意識しなくても良い

Ansibleは手続き型のため、作成するリソースの依存関係を意識してコードを記述する必要があります。一方、Terraformは宣言型であり依存関係をツール側が解決してくれるため、依存関係を厳密に意識することなく開発することができます。
例：EC2とそのEC2が接続するVPCを同時に作成するコードで、EC2->VPCの順に記述しても、Terraformが依存関係を解決し実行時にはVPC->EC2の順で作成を行い、VPCにEC2が接続されます。
　
　

既にTerraformが導入されている環境にAnsibleを導入すると、どのようなメリットがあるのか

Terraformは導入しているがAnsibleは導入しておらず、VMのコンフィグをスクリプト等で投入している。または手動で行っている環境にAnsibleを導入することでどのようなメリットがあるかを説明します。

OSやソフトウェアの設定が容易に

TerraformでもスクリプトでOSやソフトウェアの設定をある程度行えますが、Ansibleで設定を行うことで下記のようなメリットがあります。

冪等性を確保しやすい

シェルスクリプトでは現在の設定やファイルの有無に関わらずコマンドが実行されるため、複数回スクリプトを実行した際にコマンドによってはエラーとなってしまいます。そのため、エラーを回避するための処理を追加で書く必要があります。
Ansibleでは設定変更やファイル作成などを行う前に、該当の設定値やファイルの有無をモジュールが確認してくれるため、別途確認処理を記述しなくても冪等性を確保できます。

再利用しやすい形でコードを開発できる

Ansibleではコードを分割することで再利用しやすい形での開発が可能です。
多くの機器に対して使用する処理を分割し使いまわすことで、システムが大規模になった際に開発コストの削減が見込めます。

記述方法の統一

AnsibleのコードはYAMLという形式で書く必要があります。また、Ansibleのコードでは変数の宣言や処理を記述するディレクティブが決まっています。そのため、スクリプトと比べて誰が書いても統一感のあるコードになりやすいです。
また、Ansibleではディレクトリやファイルを名前で判別し読み込みます。そのため、必然的に名前が統一され乱雑になることもありません。

自動化の対象を増やせる

Terraformが管理できるリソースはプロバイダーが提供されているものに限られますが、AnsibleはSSH接続できれば管理可能なため、今までは自動化の範囲外だった機器も自動化の対象にすることが可能です。 例：オンプレミスのルータやスイッチ、セキュリティ製品など 　
　

まとめ

本記事ではAnsibleとTerraformの違い、使い分けについて説明してきました。
内容を簡単にまとめると。
・得意な領域が異なるため自動化を行いたい対象、範囲によって使うツールを選び使い分ける。
・オンプレミスのNW機器やセキュリティ製品、OSレイヤ以上の自動化はAnsibleが得意とする領域
・ハイパーバイザーやクラウドサービス上のリソースの自動化はTerraformが得意とする領域
となります。
　
また、この2つのツールは連携させて併用することが可能です。
連携時はAnsibleからTerraformを呼び出すことも、TerraformからAnsibleを呼び出すこともできます。
連携させることでお互いの強みを活かしつつ自動化の範囲を広げることができるので、自動化対象の範囲によっては両方とも導入することを検討してください。
連携、併用の具体的な方法については次回掲載予定の記事で説明します。

Terraformとは

Terraformとは

はじめに

こんにちは、エーピーコミュニケーションズ iTOC事業部ACTの相場です。
今回はTerraformについて紹介します。
Terraformとは何なのか？どんなことが出来るのか？特徴は？といった疑問や、クラウド自動化やIaC、構成管理について情報収集をしている方は、是非本記事を読んでいただけると嬉しいです。

Terraformとは

まず、Terraformとは何なのかについて説明します。
TerraformはHashiCorp社が提供するプロビジョニングソフトウェアです。

Terraform公式ページのリンク

プロビジョニングソフトウェアとは、インフラを構成するサーバーなどを作成する役割を持ったソフトウェアです。
コードによってインフラを構築するInfrastructure as Code(IaC)ツールの一つです。

Terraformでは、主にクラウド上でのインフラ構築を自動的に行うソフトウェアとなっています。
AWS CLIなどのCLIでクラウドを管理する場合とTerraformでクラウドを管理する場合では、以下のような違いがあります。

CLIとTerraformの比較表

項目 CLI Terraform
設定方法 命令型
具体的な手順をコマンドで明示的に定義する。 		宣言型
インフラの状態をコードで明示的に定義する。
冪等性 コマンドごとに異なる。
同じコマンドを再実行しても、異なるインフラ状態になる可能性がある。 		殆どのリソースで冪等性を確保。
同じコードを再実行しても、同じインフラ状態になる。
再現性 スクリプトの再実行で可能。
結果は実行の順序やタイミングに依存する。 		コードにより再現性を保証。
同じコードから常に同じインフラ状態が生成される。
状態管理 無し。
リソースの状態を追跡する方法を開発する必要がある。 		状態ファイルによりインフラの状態を自動的に管理する。
コードの再利用 スクリプトとして実装することで再利用可能。 モジュールとしてコードを再利用可能。コードの集合体として再利用可能なコンポーネント。

CLIの場合は管理をする必要がない簡単なタスクを手早く実行する点において便利です。
Terraformは大規模なインフラストラクチャの管理や、コードによる厳密なインフラ状態の制御を必要とする場合に適しています。

Terraformが提供しているクラウドリソースを管理するためのプラグインとTerraformを組み合わせると、サーバー、データベース、ロードバランサーなどインフラの構築に欠かせないパーツを作成できます。
対応しているクラウドサービスは、AWS、Azure、Google Cloudなどの主要なクラウドサービスを含めた複数のクラウドサービスです。

他のクラウドリソース管理ツールとの比較表

管理ツール 対応クラウド 記法 公式サポート コミュニティサポート
Terraform 複数 HCL Official Tireの範囲内 広範囲
CloudFormation AWS JSON/YAML 対応しているAWSリソース 限定的
Bicep Azure Bicep DSL 対応しているAzureリソース 限定的
Resource Manager Google Cloud JSON/YAML 対応しているGoogle Cloudリソース 限定的

※ Official Tireについては後ほど説明します。

また、クラウド以外でもTerraformを利用することができます。
例えばVMwareやKubernetesなど、様々なプラットフォームにもTerraformは対応しています。

なぜTerraformで管理が実現できるのか

Terraformでの管理は、プロバイダーによって実現しています。
プロバイダーとは、Terraformが様々なサービスや製品とやり取りするためのプラグインです。
管理したいサービスが提供しているAPIを介してTerraformで操作を行います。

Terraform Providerの一覧ページのリンク

Terraform公式やTerraformのパートナー企業、コミュニティも合わせるとおよそ、4000を超えるプロバイダーが存在します。(2024年8月時点)

Terraformで利用可能なプロバイダーには3つのTierがあります。
『Official』、『Partner』、『Community』です。

OfficialはHashiCorpが所有、維持管理を行っているプロバイダーです。
主要なプラットフォームを対象としており、それぞれのプロバイダーが独自のリリースサイクルを持っています。
公式からリリースされているため、他Tierのプロバイダーと比べて安定性、信頼性が高いです。
また、継続的なサポートやアップデートも行われています。
その他にも、Officialのプロバイダーはドキュメント類が豊富にそろっています。
管理したい対象サービスや製品がOfficialのプロバイダーであれば安心して利用できます。

Partnerはパートナー企業が所有、維持管理を行っているプロバイダーです。
HashiCorpとパートナー導入プロセスを経て、認定された企業が提供を行っています。
パートナー企業が提供するプロバイダーは、それぞれのパートナーが所有するサービスや製品をTerraformで扱うためのものです。
パートナー企業が提供するプロバイダーは、機能追加・改善、バグ修正などのサポートが積極的に行われます。
そのため、Officialと同様にPartnerのプロバイダーで管理可能なサービスや製品の管理から始めてみるのも良いです。
また、PartnerのプロバイダーもOfficialほどではありませんがドキュメントが整っています。

Communityはコミュニティが所有、維持管理を行っているプロバイダーです。
OfficialやPartnerで提供されていない技術やサービスをTerraformで管理できるように、プロバイダーの提供が行われています。
これらのプロバイダーの所有者は世界中の開発者、エンジニア、Terraformユーザーです。
Communityのプロバイダーは所有者によってドキュメントの充実度はまちまちです。
ですが、人気の高いプロバイダーや技術やサービスのコミュニティはドキュメントが充実しています。

Terraformの特徴

Terraformの特徴として、HCLという独自の言語を使用します。
独自の言語と書かれると取っつきにくいように感じますが、人間が比較的簡単に読み書きできるように設計された非常にシンプルな記法です。表現がやや複雑になりますが、JSONで記述することもできます。

シンプルな記法ですのでプログラミングを熟知していなくても、コードを見ればどのようなインフラが構築されたのか分かりやすいです。
これがTerraformの特徴であり、シンプルなコードをインフラ構成のドキュメントとすることで、厳密に定義されたネットワークの状態を確認することができます。これによって、特定の個人へのインフラの管理や構築を依存させません。(=属人化の解消)

また、十分な検証が行われた既存の手順をTerraformに落とし込むことで、インフラ構築作業における人為的なミスを減らすことができます。(=インフラ品質の向上)

Terraform単体では上記のようなメリットがありますが、Gitなどのバージョン管理システムを組み合わせることで、更なるメリットを生み出すことができます。
例えば、コードの変更履歴を確認することで過去にどのようなインフラが構築されたのか追跡することができます。
その他には、コードの変更により問題が発生した場合でも、変更履歴を確認して正常に動作していたコードに切り戻すことが可能になります。

このようにTerraformを他のシステムと組み合わせることで、更なるインフラの運用、構築の効率化を実現できます。

Terraformで出来ること

Terraformのコード

Terraformのコードを使うことで簡単にクラウド上にリソースを作成することができます。
以下のようなシンプルな記法を使い、リージョンやリソースのタイプを指定します。

EC2インスタンスを作成するサンプルコード

provider "aws" {
  region = "ap-northeast-1"
}

resource "aws_instance" "tf_blog_ec2" {
  ami           = "ami-0b9593848b0f1934e" 
  instance_type = "t2.micro" 
}

さらにコードを拡張することで、以下の構成図の各種インフラリソースを作成することが出来ます。

今回は作成するリソースにtf_blogのプレフィックスをつけています。
tf_blogでリソースの検索を行い、作成されていることを確認します。

コード実行後の各種リソースの状態

Terraformのコミュニティ

コミュニティの比較は同一条件下での比較が難しいです。
ですが、大まかにコミュニティの規模を把握することで、その技術を採用すべきかの判断基準を一つ設けることができます。
以下の表から、Terraformのコミュニティ規模は他のIaCツールと比較して大きいことが分かります。

ツール ソース クラウド コントリビューター スター ライブラリ Stack Overflow
Terraform オープン 複数 1,621 33,019 9,641 13,370
Pulumi オープン 複数 1,402 12,723 15 327
CloudFormation クローズ AWS ? ? 369 7,252
Heat オープン 複数 395 379 0 103

『詳解Terraform 第3版』の『IaCのコミュニティの比較』から引用。

コミュニティの規模が大きいことで以下のような利点があります。
コミュニティ製のプラグインや拡張機能が利用可能。
オンラインで情報を得る機会が増える。(ブログやStack Overflowなど)
Terraformを扱う協力者の確保がしやすい。(従業員、コンサルタント、SIerなど)

Terraformはコミュニティ活動により、ツールセットやベストプラクティス、学習のためのリソースなどが整っている状態です。
様々なナレッジが集まることで、より使いやすいソフトウェアとして成熟していきます。

まとめ

TerraformはITインフラにおける自動化を実現するためのソフトウェアです。
公式やパートナー企業、コミュニティから提供されるプロバイダーによって、サービスや技術の管理を実現しています。 コードによってインフラの状態を定義することで、特定の個人に依存しないインフラ構築・管理が可能になります。また、シンプルな記法のHCLにより可読性の高いコードを書くことが可能です。 人気のツールであるTerraformは公式からの情報以外に、コミュニティから提供される情報も豊富です。
公式がサポートしているサービス以外にも、様々なサービスに関する情報が集まります。 複数のサービスや技術を組み合わせたインフラ環境において、Terraformは他の管理ツールにはない独自の強みを持っています。
複雑なインフラ環境でなかなか業務の効率化を進められない、という方がいらっしゃいましたら是非一度Terraformの導入を検討してみてください。

私たちエーピーコミュニケーションズではITインフラ自動化推進をご検討の方に向けて、オンラインでの無料相談を随時実施しています。（30分～1時間程）
Terraformについてのご相談に限らず、自動化推進の為の情報収集としてもご活用いただけますので、よろしければお気軽にご利用ください。

【無料相談・お問合せフォーム】 https://www.ap-com.co.jp/contact/act.html

経験が少なくてもAIで効率的なAnsible Playbookの作成が可能！？ Ansible Lightspeedを試してみた

Designed by Freepik

初めに

こんにちは、エーピーコミュニケーションズ iTOC事業部の相場です。
今回の記事では、AIによってAnsible Playbook(以下、Playbook)の作成を支援するAnsible Lightspeedを実際に試してみたので紹介します。
なお、本記事ではTech Preview版のAnsible Lightspeed(以下、Lightspeed)を使用しています。

Tech Preview版は本記事公開時点では利用不可能なため、Lightspeedを利用したい場合は、有償で一般提供されている製品版の「Red Hat Ansible Lightspeed with IBM watsonx Code Assistant」をご利用ください。

Ansible Lightspeedとは？

Ansibleは、ネットワーク機器の設定やサーバの構成管理などを自動化するツールです。しかし、Playbook作成には経験と知識を必要とします。ここでAnsible Lightspeedの出番です。この拡張機能は、AIによるサポートで経験の少ない人材でも効率的なPlaybookの作成を可能にします。

他の生成系AIとの違いは？

先ほど「AIによるサポートで効率的なPlaybookの作成が可能」と記述しましたが、ChatGPTなどの他の生成系AIとはどう違うのか？という疑問を持った方もいらっしゃると思います。そこで簡単にAnsibleを使用する環境において、Lightspeedが他の生成系AIと比べてどのように優れているのか説明します。

①コンテンツソースの照合
Lightspeedは生成したコンテンツ(Playbookなど)に対して、その出典や信頼性を示すタグやリンクを付与します。これにより、コンテンツの品質や正確性を確認できます。

②ポスト処理
Lightspeedは生成したコンテンツに対して、文法や表現や論理性などをチェックして修正します。これにより、コンテンツの読みやすさや理解しやすさが向上します。

③前後のタスクを見て適切なPlaybookを生成
Lightspeedは生成したコンテンツに対して、その目的や背景や状況などを考慮して、最適な手順や方法を提案します。これにより、従来手作業で行っていたPlaybookの作成時間が削減されます。

実際に試してみた

実際に幾つかのパターンでLightspeedを試してみました。
①タスク名 “Debug hello world”
まずは簡単にお試し。タスク名の一番後ろにカーソルを移動した後、Enterを押すことでAIがタスクの内容を作成します。その後Tabを押せば作成した内容を反映できます。

また、学習に使用したコンテンツソースは以下のように表示されます。

② タスク名 “Run show version”
ベンダ専用のモジュールでもタスク名から作成可能です。ただし特に指定をしない場合、ネットワーク機器関連はciscoのモジュールが使用されました。

③ タスク名 “Run show version on juniper”
こちらもjuniper用のモジュールですが、タスク名で明示的に指定することでjuniper用のモジュールを使用しました。

また、異なるタスク名でも同じタスクを生成する場合もあります。
以下はOSPFのコストを変更(設定)するタスクです。

このようにタスク名が違う場合であっても、目的に対して手段が同じであればこのような結果になります。

④Cisco RouterへのHSRPの設定（ChatGPTとの比較）

まず1枚目はChatGPTにより生成したものです。『Configure HSRPというタスク名でansibleのタスクを作成してください。』というプロンプトを入力しました。基本的な設定はコンフィグが入っていることが確認できます。
設定を行うだけであればこのタスクでも十分ですが、モジュール名がFQCNではないこと、IPアドレスやインターフェースを直接書いているため再利用がしづらいことはマイナスです。

2枚目がLightspeedにより生成されたものです。かなり内容が異なります。
まず、コンフィグやインターフェースが変数で指定されています。これはPlaybookの再利用性を高めるうえで適切な手段です。またモジュール名をFQCNで記述することでansible-lintによる構文検査をパス出来ます。

おわりに

以上がAnsible Lightspeedに関する紹介です。
Lightspeedは、Ansibleの経験が少ない人材でも効率的なPlaybookの作成を実現できる画期的なツールです。現段階では、商用環境に適用するにはまだまだリファクタリング要素がありますが、Playbookの書き方を学ぶ上で、初心者の入り口としては有効なツールになり得ます。
Ansibleを利用した自動化の内製化を目指していたり、人材不足に悩まれている方は要チェックです！
製品版のLightspeedはAAPのライセンスを購入することで製品版が利用可能になるので、是非試してみて下さい。

ネットワーク自動化が体感出来る！Interop Tokyoなどの展示会にて実施している自動化デモの詳細やポイントについて

エーピーコミュニケーションズは毎年いくつかの展示会に出展し、ネットワーク自動化の便利さを実感していただくために、実際に発生しうる業務をAnsibeleを使って自動化するデモンストレーションを行っています。 今回はそのデモの詳細やポイントについて紹介させていただきます。

※展示会出展時の様子については下記の記事をご覧ください。

2023年上半期の展示会イベント参加報告 - APC Automation blog

――――――――――――――――――――――――――――――

デモはAnsibleで出来る事のほんの一部の内容ですが、実際にどんな事が自動化できるかを知っていただければ、自社の課題解決のヒントになるかもしれません。

自動化デモの概要

拠点Aとの間のメインWANを繋ぐセンター側ルーターのインタフェース設定を、Ansibleを使用して自動で切り替えるデモになります。 下図センターのバーチャルルーターに対して、下図拠点Aと通信するためのインターフェースの有効化/無効化とpingの疎通テスト、configのバックアップをGitのリポジトリにアップする所までの流れを一度の操作で行います。Slackへの通知設定もしてありますので、リアルタイムに進捗を確認します。

工程（有効化ver）

  1. テンプレート起動
  2. pingで疎通テスト
  3. 失敗した場合、有効化
  4. configをGitへバックアップ
  5. pingで疎通テスト

ポイント

  • ワンクリックで全ての工程が進行
  • 途中に承認操作を挿入する事が可能
  • 工程の都度、Slackで通知することで進捗管理が可能
  • 各操作のテンプレートを組んで自動化を構築している為、組み替える事で様々な設定にも対応可能
  • 自動化のテンプレートを作成しておく事により、経験や知識の無いメンバーでも品質を一定に保つことが可能
  • その他分岐や切り戻しなどの工程の自動化が可能
  • 直感的に操作できるUI
  • 各作業内容を記すPlaybookの記述には可読性の高いYAMLまたはJsonを使用

デモにかかる時間は2～3分ほどで、展示会では少しお話をしている間に全工程が終わってしまいます。 もし手作業で行った場合どれぐらいかかりそうかをイメージしながらご体感いただくと、より魅力を感じていただけるのではないかと思います。

show int 様に取材していただきました

Interop Tokyo 2023に出展した際にYou tubeチャンネル「show int」様に取材していただきました。 動画内では「Automation Coordinator」のご紹介と、自動化デモンストレーションの概要を説明させていただいています。 動画を視聴していただいてから記事を読んでいただけると、より分かりやすいのではないかと思います。

show int インターネットの裏側解説 チャンネル 国内最大級イベント Interop Tokyo 2023 に参加してきました - YouTube



今後の展示会出展予定（2023年秋以降）

今年は10/25から幕張メッセにて開催されるJapan IT week 2023秋を含めて３つの展示会に出展致します。 まだご覧になられてない方はもちろん、以前聞いてから自動化について更に情報収集をしたい方も、現在の状況に合わせてご案内いたしますので、お気軽にお越しください！

出展する展示会情報

10月25日～27日に幕張メッセにて開催のJapanITweek秋
参考リンク :Japan IT Week【秋】｜RX Japan株式会社

11月8日～9日に兵庫県のアクリエひめじにて開催されるDISわぁるど2023
参考リンク :Disわぁるど in 姫路

11月20日～22日に東京大学にて開催されるInternet Week2023
参考リンク :Internet Week 2023