Jupyter&Ansibleで「手順書 as a Code」を実現?!
- 編集部の見解や意向と異なる内容の場合があります
- 編集部は内容について正確性を保証できません
- 画像が表示されない場合、編集部では対応できません
- 内容の追加・修正も編集部では対応できません
CTC教育サービスはコラム「Jupyter&Ansibleで「手順書 as a Code」を実現?! 」を公開しました。
はじめに
前回に続いて、Jupyterを活用したシステム運用・管理のアイデアを紹介します。Ansibleなどの自動化ツールが登場する中で、プログラムコードから環境を操作する「Programmable Infrastructure」、あるいは、「Infrastructure as a Code」という考え方が広く知られるようになりました。
しかしながら、その一方で、従来の手順書に基づいた運用とのギャップが大きく、どのように導入を進めてよいかわからないという声を聞くこともあります。あるいは逆に、Ansibleの活用を大規模に進める中で、新たな課題に直面することもあるようです。そのような中で、Jupyterを活用することで、これらの課題を解決していこうという取り組みをしているグループがあります(*1)。この取り組みは、Ansibleの活用そのものが主眼ではありませんが、ここでは、Ansibleの新たな活用方式として紹介してみたいと思います。
Playbookのコンテンツ管理がAnsibleの課題
Ansibleを使用する際は、一般に専用の管理サーバーを用意して、管理対象機器のインベントリーを保存しておきます。このサーバー上でAnsibleを用いて、管理対象の機器を操作していきます。操作手順を記載した「Playbook」を用いることで、複数の手順からなる作業をまとめて自動化することができます。
しかしながら、Ansibleの役割は、基本的にはPlaybookを適用して操作を実行するだけで、Playbookの内容そのものを管理する機能はありません。そのため、同一の定形作業を繰り返すには便利ですが、環境ごとに必要なカスタマイズを加えることが困難になる場合もあります。現実には、1つのPlaybookをさまざまな環境で利用しながら、その内容を改善していく、あるいは、より汎用性を高めていくという取り組みが必要となります。
そこで、1つのPlaybookにすべての作業を詰め込んでブラックボックス化するのではなく、Playbookの内容を作業者にも理解しやすい形で分割しつつ、Jupyterを用いた「実行可能な手順書」として提供しようというのが、ここでの発想となります。
Jupyter経由でAnsibleを利用
Jupyterを利用してAnsibleを操作する環境は、図1のようになります。基本的には、Ansibleの管理サーバーにJupyterを追加導入しているだけで、特別な環境というわけではありません。
この続きは以下をご覧ください
http://www.school.ctc-g.co.jp/columns/nakai/nakai88.html
ソーシャルもやってます!