手作業とAnsibleの違い
ここまでの旅路にて皆さんはAnsibleに関する色々なことを知りました。自動化する作業の例を紹介する前に、手作業とAnsibleの違いを簡単に振り返っておきましょう。playbookを利用することで、多数のネットワーク機器やサーバといった管理対象に対して、作業ミスを発生させることなく構成変更やデプロイ、オーケストレーションといったことを実行することができました。
Playbookには対象の在るべき姿となる構成情報を記載
実行するとPlaybookの内容が対象に反映
対象が1台でも100台でも（1,000台でも！）同じ労力で実施可能
対象の状態が揃っていなくても纏めて実施可能
作業ミスをなくし、作業品質のバラツキを解消
管理台数に比例した作業量の増加を防止
また、従来は手順書とパラメータシートを用意していましたが、Ansibleの場合はplaybookとインベントリを用意するという違いもありました。
Ansibleが実際に使われている領域の例
それでは、実際にAnsibleが使われている例を自動化の難易度と合わせていくつか紹介します。自動化の難易度は、対象機器や既存の手順にも依存するため、単純に言えない部分もあるので目安として考えましょう。もしかしたら、皆さんが日頃から面倒だと感じている作業が含まれているかもしれません。とても簡単な使用例の場合は、まさに自動化のチャンスです！
- とても簡単な使用例
- • 複数のシステムから一括でログを収集
- • 複数の機器から一括でSOSレポートを取得
- • 複数のネットワーク機器のコンフィグと状態を一括で取得して保存
- • 対象機器に実行したAnsibleのログを証跡として保存
- 簡単に実装できる使用例
- • 複数のインフラシステム・機器の停止や再起動を一括で実施
- • 複数の機器へのユーザーの登録作業
- • 定期的にユーザーパスワードを一括で変更
- • WindowsやLinuxのパッチ・セキュリティアップデートを一括で変更
- • 複数台のWebサーバーの構築とアップデートを一括で変更し、状態を揃える
- • 仮想マシン用意、Apache等の各種サービスの一括設定
- • Webサーバーやアプリケーションサーバーの構築と共にセキュリティ設定やコンプライアンス設定を実施
- • ADへのユーザーと権限の登録や再登録
- • ロードバランサーのSSL証明書の更新を一括で実施
- • ネットワーク機器のコンフィグの修正
- 実践を経てから実装してほしい使用例
- • ネットワーク機器のコンフィグ変更や経路変更後のテスト
- • セキュリティ適応状況の確認作業
- • デプロイしたインフラやアプリケーションに対するテスト
- • インフラとアプリケーションを併せた環境でのCI/CDパイプラインの実装
このように、Ansibleの自動化の対象と用途は多岐にわたり、多くのユーザーが既に実践し利用しています。
とても簡単に実装できる内容から少し経験が必要な内容までありますが、簡単な内容の中にも皆さんがやりたいことや日頃作業しているものと似たことがあったのではないでしょうか？
Ansibleは、背伸びをせずにシンプルなところから始めることができます。皆さんの環境でも是非トライしてみてください。自分自身での環境準備の方法はSTEP3を参照しましょう。
参考までにplaybookも掲載しておきます。Playbookですっきり記述することができます。
例 1：Windowosアップデートの実施
---
- name: windows update
hosts: windows
tasks:
- name: win_update
win_updates:
reboot: yes
reboot_timeout: 3600
例 2：Apacheのアップデートと各種変更
---
- name: Apache server installed
hosts: web
become: yes
tasks:
- name: latest Apache version installed
yum:
name: httpd
state: latest
- name: Apache enabled and running
service:
name: httpd
enabled: true
state: started
- name: copy web.html
copy:
src: web.html
dest: /var/www/html/index.html
notify: restart_apache
handlers:
- name: restart_apache
service:
name: httpd
state: restarted
絶対に失敗しない自動化
初めて現実の作業を自動化する時に最も気をつけるべきことは「絶対に失敗しないこと」です。何を当たり前のことを言っているんだ、失敗するつもりで取り組む人はいないぞ、と思われたかもしれません。この理由について順を追って説明させてください。
ありがちな失敗
新しい技術を覚えると、ついついそれを駆使して身の回りの課題を解決したくなります。あれもAnsibleで自動化しよう、これもできそうだ、あっちも行けるな、という具合です。Ansibleは汎用性の高いツールですので、やってみるとできてしまうことも多いです。しかし、できるからと言って、それが簡単にできるかという話と、成功率が高いかは全く別の話です。Ansibleを覚えたてのエンジニアが難しい作業を選んで、途中までは実装できるものの難易度の高い箇所でハードルを超えられずに挫折してしまうというのは本当によくある話なのです。
失敗は勢いを失わせる
せっかくAnsibleの使い方を覚えても、はじめの一歩でつまずいてしまうことで自動化を続ける意欲も削がれてしまいます。それに自動化を歓迎しない人にとって、自動化推進派の失敗は格好の導入停止の材料にもなってしまいます。ほら、やっぱり自分たちには自動化なんて不要なんだよ、という具合です。これでは自動化の勢いも削がれてしまいます。そうならないためにも最初の自動化は失敗しないことが重要です。
絶対に失敗しない3つのポイント
ここからは失敗の可能性を下げる作業の選び方を紹介します。以下の3つのポイントを満たす作業を選びましょう。慎重すぎるように感じられるかもしれませんが、そのくらいに最初の一歩を成功させるというのが重要だとも言えます。
(1)簡単な作業を選ぶ
難しい作業を選ぶことで失敗する可能性が高まるので、簡単な作業を選ぶというのが最初のポイントです。簡単すぎる作業くらいがちょうど良いです。たとえこれが「5分の作業を30秒に短縮する」程度の効果しかなかったとしても構いません。自動化を進めればいずれこういった簡単な作業にも手を付けることになります。ならば最初に持ってきて、成功の第一歩目になってもらいましょう。Ansibleではこのような小さな自動化が積み重なって大きな効率化につながります。
(2)手順が確立されている作業を選ぶ
誰がやっても間違わない完全な手順書がある作業を選びましょう。手順書というのは属人的なものが多く、暗黙知を前提とした手順もたくさんあります。「ここでエラーが出ないことを確認する（しかし、何がエラーかはシステムを知っている人しかわからない）」などがよくある例です。このような手順書を自動化しようとすると、エラー条件の抽出と判定ロジックを作り込んだりと想像以上に手間がかかります。
(3)自分一人で完結できる作業を選ぶ
自動化するにあたり、誰か別の人の協力が必要な作業は避けましょう。関係者が増えることで、思わぬハードルが出てきてしまう場合があります。もしかすると手伝って貰う人が突発的な案件対応で時間が取れなくなるかもしれません。初期段階では可能な限り少人数、できれば自分自身だけで自動化を完了できるような作業を選びましょう。
上記で説明した観点でまずみなさんが自動化すべき対象を選ぶための「絶対に失敗しない自動化のワークシート」を準備しました。このワークシートを使って自動化を行う対象作業を抽出してみてください。
3つのポイントで作業を選ぶことで、最初の自動化の成功率を大きく上げることができます。そして小さな成功を成し遂げたら、上司や同僚に「AnsibleでXXXの作業を自動化してみたら楽になりましたよ」と共有しましょう。成果を上げたよという報告は、とてもインパクトがあります。たとえ小さくても成果がある状態を作ることができると、自動化を次のステップに進めることがとても容易になります。
ぜひ、この「絶対成功する自動化」を持って小さな成果を上げ、みなさんの自動化の最初の一歩としていただけると幸いです。
