SIOSのDX Product & Integrationチームでマーケティングを担当している村田です。
前回、Vol.1ではリモートワークが出来る理由、出来ない理由として企業におけるリモートワークの課題をあげてみました。今回の記事ではこれをAnsibleの目線で、どのように使えるのか、その時の課題はどのようなことがあるのか？その解決策は？をお届けします。
こちらの記事の内容はあくまでも一例となり、各企業ごとに根本的に解決しなければならない点があるかと思います。Ansibleに取り組みたい企業のお悩みもサイオステクノロジーではお聞きしておりますので、これから始めたい方はお気軽にご相談ください。
運用に自動化ツールを取り入れる目的
一般的にITシステムの自動化を検討する際には以下のような目的をもって検討することが多いのではないでしょうか。
単純に自動化ツールを入れてコストを削減したいという目的で進む場合もありますが、このケースは成功するパターンは少ないためより具体的な課題に対してアプローチするべきだと私は考えています。
コストの削減が目的で走った場合、自動化ツールのメンテナンスにかかる工数やツールの費用まで削減対象にしてしまい、結果として自動化の導入効果が得られないという声に変わってしまうケースもあります。
このような体験談から私は自動化の導入に対する目的をしっかりと持ってもらうことをおすすめし、それが品質の向上や運用の効率化、コンプライアンスやガバナンスが効いた運用への改善という内容で持ってもらいたいと問いかけをしています。
Red Hat Ansible Automation とは？
Red Hat Ansible AutomationはITシステムの自動化ソリューションとして導入企業も増加しており、皆様も一度は聞いたことがあるソフトウェアではないかと思います。
Ansible Automationには、自動化を行うためのエンジンとしての「Ansible Engine」と自動化を管理するための「Ansible Tower」の2つが提供されています。Ansible Engineは一般的にAnsibleと総称されていますが、エンタープライズで利用するにはAnsible Towerを含めて検討しないと効果を発揮できないケースが多々あるのでご注意ください。（この辺はいずれ記事にします）
Ansibleを説明する上では「シンプル」「パワフル」「エージェントレス」という3つのキーワードが使われます。それぞれ簡潔にまとめると下記のようになります。
シンプル
Ansibleでは、YAML形式で記述するPlaybookという自動化の設計書を使用します。このPlaybookは従来の自動化ツールで多く採用されてきたスクリプト形式の設計書とはことなり、目指す状態を上から順に記述していく形になるので可読性が高く、誰もが自動化された運用に参加できるのが強みになります。
例として、Apacheのインストールを行うPlaybookでは下記のように記述します。
※Red Hat Ansible Automation Workshop Linux Server編より抜粋
---
- name: Apache server installed
hosts: node1
become: yes
tasks:
- name: latest Apache version installed
yum:
name: httpd
state: latest7行目からがTaskの内容になりますが、http（Apache）をyumモジュールを使ってインストールするという内容がなんとなく見てわかるのではないでしょうか。
このようにシンプルに記述出来るPlaybookだからこそ、誰もが参加できる運用が実現でき、このPlaybookを設計書の代わりに保存しておけば、現在の状態がコードで管理できるという状態にも変えていけます。（詳しくはいずれIaC: Infrastructure as Codeについて触れたいと思います）
パワフル
Ansibleが自動化の対象にするのは Linux Server だけなく、Window Server や仮想化基盤、クラウドサービス基盤、そしてネットワーク機器など多くのITシステムを管理することができます。
管理対象ごとにツールを使い分ける必要がなくなるため、運用の標準化と一元管理が行いやすくなります。
また、利用シーンも構築時から運用まで幅広く使えます。インフラ基盤のプロビジョニングからアプリケーションやOSなどの設定やセキュリティ等のポリシーチェックやアップデートの適用、最近ではCI/CDやDevOpsのツールとしての利用まで広がっています。
エージェントレス
最後のキーワードのエージェントレスは、その名の通りエージェントツールを管理対象ノードにインストールする必要がない事を意味します。
どのような仕組みでエージェントレスが実現されているのかを説明すると、Ansibleと管理対象間の通信プロトコルにSSHやWinRM、Rest APIなど、モジュールごとに管理対象ノードに最適な方法で接続する方式を取っています。
Linux Serverの場合は、管理対象ノードへSSHでアクセスを行い、モジュールは管理対象ノード内に小さなプログラムをコピーして作業を行う方法を取ります。作業が完了するとコピーされたプログラムは削除される仕組みになります。
これまでの自動化ツールのように管理対象ノードごとにエージェントをインストールして、場合によってはバージョン管理を行ったり、脆弱性対応を行ったりという運用から開放されます。
Red Hat Ansible Automationの導入効果（リモート対応編）
Red Hat Ansible Automationを導入する効果として、リモートワークの観点から今回は見ていきたいと思います。
下記図はセミナーの中で使用したスライドになりますが、リモートワーク対応の自動化を考えた場合、GUIの管理画面がありセキュリティやガバナンスが効かせられるツールが必要だと考えました。
Newノーマルなリモート対応では誰もが管理できる状態を作らねばリスクが高くなると考えています。例えばコロナウイルスの感染者が発生し、その発症者にしか作業できない事があったとしたら、そこで運用が停止してしまいます。このようなリスクを防ぐためにも誰もが利用できるシンプルなGUIツールは欠かせません。
また、自動化ツールは悪意のあるユーザーに乗っ取られてしまうと全ての管理ノードがダメージを受けてしまうことになり、被害は甚大です。セキュリティの対策はもちろんのこと、権限管理や証跡管理まで配慮されたツールでなければなりません。
Ansible Automationの中で管理機能を提供するAnsible TowerはGUI管理画面からの管理機能を利用することができます。Ansible Engineでは提供されない、権限管理や証跡管理、GUIツールやジョブワークフロー、スケジューラーなどの機能がAnsible Towerにはついています。
Red Hat Ansible Automationを利用することで、サーバー個々に対してアクセスしていた現状から、Ansible Towerにのみ接続して運用する形に変えることができます。そして、アカウント管理も行えるため役割に応じた権限設定を行い作業履歴もデータベースに残しながら使えるため、ガバナンスが効いた状態での運用が実現できます。
これから自動化に取り組みたい方向けのWorkshop
サイオステクノロジーでは、Red Hat Ansible Automationをより多くの方に知って頂き、実際に体験いただきたいと考えており、定期的にAnsible Automation Workshopの開催を行っています。
自動化の課題で多く耳にするのが、自動化を始めたいけどどこから始めたらいいかわからない方や自動化に関する情報が反乱するなかでどのような情報源に頼ればいいのかわらないという声です。このようなお声に対応するためにWorkshopから始めて頂き、自動化への第一歩を進めてもらえたらと考えています。
Red Hat Ansible Automationへのご興味をお持ち頂けました方はぜひ下記のお問い合わせよりお気軽に相談をいただけたらと思います。
