brand new note

インフラエンジニアを目指す大学院生のメモ

OpenstackとAnsibleの関係性がわからないので調べた

タイトルの通りです。最近よく聞くAnsibleっていうのが何なのかさっぱり分からず、自動化とか構成管理とかいう言葉と一緒にに流れてくるのを見てOpenstackっぽいサムシングを連想したんですがどうなのか。技術的なことは書いてませんが、調べているうちに背景や今の流行がなんとなくつかめたのでその辺を網羅的にメモします。

とりあえず読むじゃん

qiita.com

www.ntt-tx.co.jp

www.slideshare.net


Infrastructure as a Code

Infrastructure as Code(IaC) というのは、物理的なハードウェア構成やインタラクティブな設定ツールの使用ではない。コンピューティング・インフラ(プロセス、ベアメタルサーバー、仮想サーバー、など)の構成を管理したり、機械処理可能な定義ファイルを設定したり、プロビジョニングを自動化するプロセスである。

Wikipediaより。DevOpsとの関係性の部分ではこのように記されています。

IaCはDevOpsのベスト・プラクティスを実現する重要な要素だろう。開発者はもっと構成の定義に参加するようになり、運用チームは、開発プロセスの初期段階で入ってくるようになる。IaCを活用するツールはサーバーの状態・構成を視覚化し、企業内のユーザーに視覚性を提供し、最終的に努力を最大限にするために、チームを結集することを目指している。 一般的に、自動化は、手作業のプロセスの混乱とエラーの起こりやすい部分を取り除き、より効率的かつ生産的にすることを目指している。手動構成の効率を低下させる複雑さを軽減することも目的としている。柔軟性が高く、ダウンタイムが少なく、全体的に費用効果が高いソフトウェアとアプリケーションを作成できる。 自動化と共同作業は、DevOpsの中心的なポイントであるため、多くの場合、インフラストラクチャ自動化ツールはDevOpsツールチェーンのコンポーネントとして含まれている。


要するにクラウドサービスが盛んになった現在では、開発から運用までをチーム一体となってカバーすることが容易になった。それに伴ってサービス設計の初期段階である「インフラ構築のフェーズ」を様々な技術者に理解してもらいやすくすることが必要となってきた。その為にあれこれを自動化、可視化してより簡単に扱えるようにしよう、という思想が広がり、これがInfrastructure as a Codeと呼ばれるようになった。

で合ってますかね!?

いっぱいサーバが並んでるところで一台一台手作業でソフトを入れたりするのはありえんしんどいので、すべてのサーバが同じ挙動をする仕組みができれば一発で大規模システムも管理できて幸せだよね、という話なんでしょうか。そういえば米microsoftは一人当たり数千台のサーバを管理しているとかいう噂を本で見たのですが、確かにこういうところでならかなりの効率化が期待できますよね。その構成管理のツールのひとつがAnsibleなんですね。

インフラ屋もコードを書くのか

他の構成管理ツールであるChefの場合はRubyベースの定義ファイルに基づく設定が必要です。しかしAnsibleの場合、yamlというマークアップではないけどプログラミング言語でもない記述方法によって簡潔に設定ができるようです。Ansibleの実装はPythonなので詰まったら実際のソースを読んでデバッグすることはあるんでしょうけど、特にPython書けなくても動かすことはできます。これなら俺にもできるだろうか。。。

ぼんやり「インフラエンジニアもこれからはコード書けないといけないということ…?」と思っていましたが、そうともいえるしまだそうでない仕事もある、でもできないと時代に取り残されるかもしれない、という認識です。学ばねばならぬ。

OpenstackとAnsibleの関係

OpenstackのモットーはVMそのものを構成する部品を作る(ブロックデバイスやネットワークIO、認証系など、コンピュータとして必要な機能をまず提供する)とでもいうべきでしょうか。そして、その中で提供する部品の一つに「自動化を助ける機能」があり、ここでChefやAnsibleといったツールが連携します。ソフトウェアの導入、サービスに応じたネットワーク設定等をするための機能です。Openstackの上にAnsibleがのっかっていて、その上に開発するサービスが動くということでしょうか。

またAnsibleはその特性から、短いスパンで改良を遂げているOpenStackとは思想が近く、相性がいいようです。Ansibleは構築したサーバにエージェントを置く必要がなく、端末からsshで設定を流し込むだけで柔軟かつ容易に構成の自動化を行えるからです。逆にあまりにも大規模なサービスの場合はエージェントを置いたChefのほうが良いみたいですね。