Furyu
[フリュー公式]

Tech Blog

フリュー株式会社の技術ブログです

2018年12月18日

Kayo

Ansibleで連番の複数ホストを指定できなかったのでその原因と対策

みなさん、こんにちは。ピクトリンク事業部インフラ課の藤本佳世です。

フリュー Advent Calendar 2018の12/18分の記事になります。

 

先日、SSL証明書の更新をAnsibleで実施しようとコードを書いていた時にはまった

「Ansibleで連番の複数ホストを指定できなかった件」について、シェアしたいと思います。

みなさんも、「これで動きそうなんだけど、なぜ動かない!!」と思ったことあるかと思います。

今回、私もそんな状況になってしまいました。

※Ansibleについては、以前ブログを書いているのでこちらをご覧ください。

やりたかったこと

今回やりたかった作業はSSL証明書の更新です。この作業をAnsibleで実施しようと考えました。

サーバ ドメイン
test-web-01~05 hoge.com
test-web-06~10 fuga.com

SSL証明書の場所は下記の通りです。

Webサーバ証明書ファイル /usr/local/ssl/server.crt
Webサーバの秘密鍵ファイル /usr/local/ssl/private.key
中間CA証明書ファイル /usr/local/ssl/server_ca.crt

ここで注意ポイントがあります。
test-web-01~test-web-05はドメインhoge.comの証明書
test-web-06~test-web-10まではドメインfuga.com証明書
のように、サーバによって証明書が異なることです。

実際のAnsibleコード

role配下のmain.ymlはこんな感じで書きました。

playbook.ymlはこんな感じです。

サーバによって証明書が異なるので、when句を使って
test-web-01~test-web-05はhoge_com
test-web-06~test-web-10はfuga_com
のように指定したつもりでしたが、うまくいきませんでした。

ex) test-web-05, test-web-10に対して実行した結果

エラー出力されませんが、すべてskippingされた状態になりました。

対処法

下記のようにplaybook.ymlを修正しました。

inventroy_hostname(ホスト名)の数字の部分だけを取り出し、「5以下」、「6以上」と識別するようにしました。
公式ドキュメントにも書いている通り、CentOSのバージョンによって処理を分けることもできます。

Tip: Sometimes you’ll get back a variable that’s a string and you’ll want to do a math operation comparison on it.

このTipsは今後も使えそうです!

だめだった方法

記述方法をいろいろ替えてやってみましたが、うまくいかず。。。

こちらの記事を参考にしてみましたが、うまいかず。。。

うまくいかなかった問題に関しては、また時間がある時に調べてみたいと思います。

最後に

2018年度の私の投稿はこの記事で最後になります。

2018年は大変お世話になり、ありがとうございました。来年もどんどんブログを書くつもりなので、

今後ともどうぞよろしくお願い致します。

 

みなさまにとって2018年は素敵な年となりましたでしょうか?
願わくは、2019年も素敵な年となりますように★


2018年10月16日

awata

ansible で become_user が失敗した時の対応

はじめまして。こんにちは。
ピクトリンク事業部インフラ課の粟田です。

今回の内容を書くに至った経緯

ansibleを社内で利用している事は他の記事を参照してもらえればわかると思いますが、今回そんな運用の中で発生した問題とその解決方をメモとして残しておこうという次第です。

ついでに周りからのなんか書いて投稿しろ、という感じだったりします。

 

発生した問題

ユーザ管理とsudoの権限設定にはldapを使用している環境になります。

実際にログインした状態で

などは実行できます。

また、ansibleを実行する際に、ansible_ssh_userにrootを基本的には使用しないのが運用ルールとしてあります。

どのサーバにもrootでログインしようとする人が居るので、これは禁止すべきでしょ、普通。

この状態で、以下の様なplaybookを実行するとエラーになりました。

エラー内容はこう(あまりにも見難かったのでjqで整形してあります)

become_userを記載しない場合には問題なく実行完了するので、油断してたんですが、実際にログインして、コマンドを実行してみました。

ようは、

  • ansibleでログインする際のユーザは一般ユーザ
  • 一般ユーザでもsudoできる
  • sudo -u 別ユーザ コマンド が実行できない

という部分がポイントです。

そんな環境そうそうないでしょうけど…

解決方法

  • 今更ldapの設定を変更して失敗したら影響範囲が大きいのでとっても億劫
  • 一部バッチ処理でもsudoしてるのがあるのでldapいじりたくないな
  • とりあえず、運用としてansibleユーザだけなんとかできれば良い

という事で、ansibleユーザのsudoの権限を単純に解決することにしました。

としてローカルで作成したファイルをansibleのcopyモジュールでリモートの/etc/sudoers.d以下に配置するという最も単純な手法で解決としました。

あとがき

ldapサーバ作った時にもうちょっと検証しておけば…

内輪ネタは削除された…


2016年06月27日

Kayo

Ansible Meetup in Tokyo 2016.06に行ってきました!

みなさん、こんにちは。コンテンツ・メディア第1事業部インフラ担当の藤本佳世です。前回のブログの続き、「OpenStack構築手順」などご紹介する予定ですが、その前に2016年6月1日(水)に開催された「Ansible Meetup in Tokyo 2016.06」に参加したお話しをしたいと思います。自称「Ansible女子」の私。3年前にも参加したことがあり、今回は3回目の参加でした。

詳細URL http://ansible-users.connpass.com/event/31222/

Ansible

Ansibleとは、今回Meetupの会場でもあるレッドハットが開発するオープンソースの構成管理自動化ツールです。
ssh通信を利用して、クライアントサーバに直接命令を送り込むことができます。
フリューでは約3年前にAnsibleを導入し、ミドルウェアのインストールなどサーバ構築・管理には欠かせないツールとして利用しています。Ansibleを使うメリットはとても大きく、導入したことで、今まで手動で3時間もかかっていたサーバ構築作業を、1時間以内まで時間短縮を実現することができました。
使い始めた頃は、参考書も少なく、公式HPの英語ドキュメントを参考にしていましたが、今年の4月にO’Reillyから本も発売され、ますます注目されています。

公式ホームページ https://www.ansible.com/

発表内容

  • 「Ansible Core 2.0 Overview and future releases」 by Dylan Siliva
  • 「Jupyter+AnsibleによるLiterate Computing(手順書 as a Code)への挑戦」 @ enakai00
  • 「共通言語Ansible」 @seri_wb
<LT詳細>
  • 「ansible-vaultについて何か」 (ynn)
  • 「Ansibleの教育トレーニングはじめました」 (spchildren)
  • 「Ansible2.0とOpenStackの関係」 (saito_hideki)
  • 「Playbookからのドキュメント自動生成やってみてる」 (h-hirokawa)
  • 「Ansibleとterraformで実現するタグベース複数環境プロビジョニング実例」 (takuya_onda_3)

内容まとめ

Ansible2.0新機能と今後のリリース関連

  1. 200以上の新しいモジュールが追加された
  2. エラーメッセージの改善:よりわかりやすくエラーメッセージ内容を記載するようになった
  3. アーキテクチャが変更され、より簡単に開発できるようになった
  4. ansible-vaultと呼ばれる機密情報が書かれたファイルを暗号化するツールがリリースされた
  5. 36個の OpenStackモジュール追加され、バージョン1と比べて、とても使いやすく親和性が高い
  6. sudo機能が使えなくなる予定。ansible_ssh_hostnameを ansible_hostname, ansible_userに変更する必要がある
  7. 約400以上のモジュールをリリース予定(Dockerモジュールも追加予定)
  8. python3対応予定
  9. クラウド技術にも力を入れる予定 (AWS, OpenStackなど)

運用について

  1. 開発とインフラの作業ラグをなくす取り組みについて、ミドルウェアバージョンアップなどインフラではなく、開発メンバーにAnsibleを実行してもらっている
  2. ansible-vaultと呼ばれる機密情報が書かれたファイルを暗号化するツールの利用
  3. Ansibleは自動化だが、やはりメンテナンスする必要がある。複雑なplaybookを書いてしまい、結果ブラックボックス化してしまう。手順書を用いることで、だれが見ても分かるようにする
  4. Ansibleコードをシンプルに保つことが大切

感想

Ansibleバージョン2.0の新機能や今後リリース予定のモジュールなどの紹介がありました。
個人的には、【Jupyter+AnsibleによるLiterate Computing(手順書 as a Code)への挑戦 @ enakai00 】の発表が非常に興味深かったです。手順書作成の必要性について、いかにAnsible(コード)だけに頼らず、うまく手順書にAnsibleを載せるかについて紹介されていました。

私が所属するインフラチームは、Ansibleを導入して約3年ほど経ちます。新規サーバ構築以外に、ミドルウェアのアップデート、脆弱性対応など、様々なケースで利用しています。しかし、Ansibleの構成が複雑化してしまい、他のメンバーが使いこなす事が非常に難しい状態です。そんな時、やはり手順書があればと思っていました。発表で「Jupyter」を使った手順書作成についてのお話しを聞くことができました。Jupyterの知識はゼロですが、是非検証してみたいなと思いました。

その他にもOpenStackについて、Ansibleバージョン2以降、とても使いやすくなったとの発表もありました。
前回のブログで紹介したOpenStackは、Ansibleを使って構築しました。今後のブログで、その手順をご紹介するので、是非読んでいただければ嬉しいです。


2014年11月4日

kunihira

Vagrantで簡単Ansible実行環境を配布する

こんにちは。 最近、英語の勉強にハマっている国平です。

少し前の話になりますが、Bashに脆弱性が見つかった際にみなさまどのように対応されたでしょうか? 私の部署ではサーバのBashのバージョンアップを1台ずつログインして手動で実行していました。

このバージョンアップ作業自体は1コマンドで完了するのですが、サーバ台数が多く1台ずつに順にsshでログインしコマンドを実行するのは結構な手間が掛かりました。

そこでAnsibleを使って複数のサーバの状態をまとめて変更できるようにしました。

Ansibleによるサーバの管理自体は資料も多くすぐに実行出来ました。 以前、このブログでAnsibleを取り上げたときには参考にできる情報が少なかったのですが、 現在では非常に多くの優れた資料が公開されていますので、Ansibleを利用する事自体はそれほど難しくないかと思います。

しかし、次の課題としてチーム全員がAnsibleを利用できるようにしなくてはいけません。 Ansibleの利用に集中できるように簡単にAnsibleの実行環境を構築できるような仕組みづくりを目指して、 Vagrantを利用して実行環境も含めてGitで管理し、配布できるようにしました。

今回のポイント

今回の課題は、チーム全員が簡単にAnsible実行環境を使えるようにするということです。 AnsibleのPlaybook自体はGitでバージョン管理出来ているので、同様にGitで実行環境も管理できると、 便利で配布がしやすくなりそうです。

そのため、今回はVagrantの設定ファイルをPlaybookとセットでGit管理し、Vagrantを実行するだけで、 Ansibleがインストール済みで、Playbookも利用できる仮想マシンにアクセスできるような仕組みづくりを行いました。

Ansibleとは

Ansibleはリモートマシンのあるべき状態をPlaybookというファイルに記述し、実行する事で、リモートマシンの環境を整えるツールです。 以前にもこのブログの記事でも取り上げました。

最近では急速に普及が進んで、利用するための情報も多く公開されていますし、電子書籍ですが入門Ansibleという本も公開されています。

Vagrantとは

Vagrantは仮想環境をコマンドラインから利用するツールです。 VirtualBoxをコマンドラインから利用する事ができる他、ネット上で公開されているBoxを取得して実行したり、 仮想マシンの起動時にShellスクリプトやChef、Puppetなどを利用してプロビジョニングを行う事も出来ます。

こういった設定を全てVagrantfileにRubyのDSLとして記述する事ができるので、Vagrantfileとプロビジョニングに使うファイルをGitにコミットしておけば、どこからでも同一状態の仮想マシンを利用する事が出来ます。

今回の方針

今回は、PlaybookとVagrantfile、そして仮想マシンのプロビジョニングファイルを1つのGitリポジトリにまとめてコミットしておきます。 プロビジョニングには、チームメンバーが誰でも読み書きできる前提で、Shellスクリプトを利用することにしました。

今回作成したGitリポジトリのサンプルはこちらです。

仮想環境構築のポイント

Vagrantで仮想環境を複数人で利用するためのポイントは下記の3点です。

  • Boxを自動的に取得するようにする
  • 仮想マシンを起動したら自動でPlaybookを実行できるようにする

Boxを自動的に取得するようにする

Vagrantでは仮想マシンの起動の際にベースとなるイメージファイルをBoxと呼びます。 最初にVagrantを利用する際にはBoxを取得して利用するのですが、 チームメンバーが個々にBoxを取得するのも面倒です。

なので、全員がおなじBoxを利用できるようにVagrantfile内で config.vm.box_url を設定しておきます。 これにより、Vagrantを実行するホストマシンに config.vm.box で指定したBoxが存在しなければ、指定したURLからBoxを取得して起動するようになります。 サンプルではCentOS6のBoxを取得して、furyu_blog_sample という名前で利用できるように設定しています。

仮想マシンを起動したら自動でPlaybookを実行できるようにする

この処理には2つのポイントがあります。

ホストのディレクトリを同期

まずは、仮想マシンとホストマシンのディレクトリを同期する設定をします。 Vagrantfileで config.vm.synced_folder "<HOST_DIR>", "<VM_PATH>" を設定すると、ホストマシンの指定したディレクトリを、仮想マシンから参照できるようになります。

サンプルで公開しているリポジトリの場合ですと、下記のように設定する事でサンプルリポジトリ全体を仮想マシン上では /playbook ディレクトリとして扱う事が出来ます。

仮想マシンをShellプロビジョニング

もう一つのポイントは、Vagrantのプロビジョニング機能を利用して仮想マシンにAnsibleやその実行のために必要なツールをインストールすることです。

Vagrantでは前述の通り仮想マシンの新規起動時にシェルスクリプトなどの実行をさせる事ができます。 なので、先ほど同期したリポジトリ内に、Ansibleのインストールなどを行う処理をまとめたシェルスクリプトを用意しておいて、実行するようにします。

今回は、リポジトリ内のvagrantディレクトリに置いてある、bootstrap.shを実行するようにします。

bootstrap.shは下記のような内容になっています。

Ansibleを実行する

サンプルリポジトリを使ってAnsibleを実行してみます。 なお、今回仮想マシンに利用しているCentOS6では、Ansibleが実行時にsshを自動的には利用してくれないので、-c オプションをつけて明示的にsshを利用するようにしています。 このサンプルは、Vagrantが利用できる事が前提となっています。

上記のコマンドを順に実行すると仮想マシンが立ち上がり、接続し、そしてplaybookが実行出来ます。

まとめ

今回の記事ではAnsibleの実行環境をVagrantを利用して配布しました。 これによって、チームメンバー全員が簡単にAnsibleを利用する事ができます。 簡易ながらVagrantを用いてプロビジョニングする事で、 サーバ環境だけでなく、実行環境にもべき等性を持たせる事が出来ました。 これでチームメンバーのローカルマシンの設定の差に影響を受けずに作業する事ができます。

関連記事


2013年09月4日

kunihira

AnsibleでNginxインストールしてみた

全国のプロビジョニングフレームワークファンの皆さんこんにちは。 フリューChef導入委員長(自称)の国平です。

前回の記事から2ヶ月も間が開いてしまいました。 この2ヶ月間何をやっていたかというと、ネタLTしてみたり、フレームワーク作ってみたり、夏サミ2013に参加してみたり、あとはひたすらPlay2.1+Scalaと格闘していました。

さて、今回の記事ですが、プロビジョニングフレームワーク周りでChefの対抗馬として注目を集めているAnsibleを触ってみたので、その使用感をレポートしたいと思います。

目的

本記事の目的は、プロビジョニングフレームワークの検討です。 前々回の記事で、ChefとFabricを使ってみた感想をまとめましたが、同様にAnsibleを検証してみます。

Ansibleとは

http://www.ansibleworks.com/

Ansibleは最近話題の構成管理ツールです。 Python製のツールで、サーバの環境設定はPlaybookと呼ばれるyaml形式のファイルにまとめます。このPlaybookがChefのrecipeに相当します。 構成管理ツールとして作られているので、べき等性が保証されており、Playbookに記述した状態にリモートマシンを収束させます。

サーバに対する操作はsshで実行されるので、リモートマシンにAnsibleをインストールする必要がなく、Ansibleをインストールしたマシンが1台あれば利用出来ます。

使ってみる

今回もNginxのインストール手順をAnsibleで自作してみました。 Nginxインストールの要件は、以前の記事と同じで下記のようになっています。

  • Nginxをソースからビルドする
  • ビルドに必要なライブラリもインストールする
  • nginx.confを配備する
  • nginx.confはテンプレートを用意し、本番環境/開発環境で設定内容を書き換える
  • 本番環境は、AWS EC2のm1.largeを想定しworker_processを2に設定
  • 開発環境は、m1.smallを想定し worker_processを1に設定

ファイル構成

Ansibleを実行するための最小ファイル構成は、非常にすっきりしています。 公式ドキュメントでは、ディレクトリ構成などのベストプラクティスも紹介されていますが、今回は以下のディレクトリ構成となりました。 Chefに比べて非常にスッキリとしています。

このPlaybookはGistで公開しています。 Playbook|Gist

今回、環境ごとに変数を切り替える方法が調べきれなかったので、実行時に外部から–extra-varsオプションで変数を渡すことでnginx.confの出し分けを行いました。 (こういった出し分け方法をご存知の方がいらっしゃれば是非ご教授ください。)

使った感想

いろいろなところで、「Chefに挫折したのでAnsible」という記事をよく見かけますが、確かにChefより実行環境の構築が楽で、やりたい事が記述しやすいように思います。 特に、Push型の構成で、リモートサーバに対するインストールが不要というのが大きいと思います。 Chefの場合ですと、knife-soloを利用する事で、Push型に似せた実行が出来るのですが、やはりプラグインを追加でインストールしなくてはならない上に、あくまでPush型ライクな実行ができるだけにとどまっています。

Playbookもシンプルなので、これまでシェルスクリプトを書いていたり、実行していたコマンドを元に、書き起こしやすいと思います。

ただ、やはりyamlファイルなので、込み入った事がやりづらいという印象でした。 今回のような、変数の出し分けで、まずはPythonのDictionaryを使いたいと思ったのですが、yamlで扱う方法がわかりませんでした。 この辺り、ChefやFabricならRubyなりPythonなりでダーティーながらも、やりたい事を無理矢理書いて動かしてしまえました。 その一方で、Ansibleは、きちんと型に沿って利用するのが大前提になっているようです。

Chef/Fabricとの比較

どのツールでも、サーバに対する操作をソースコードにまとめられるので、Gitなどでバージョン管理する事が出来ます。 また、Ansibleはべき等性が保証されている点がChefと同様であり、リモートマシン環境を収束させるという使い方で実力を発揮します。

その一方で、Chefが基本的にはサーバ/クライアント構成のPull型アーキテクチャであるのに対して、AnsibleはFabric同様のPush型アーキテクチャになっています。

比較表

項目 Ansible Chef Fabric
構成 Ansibleサーバ → リモートマシン Chef-Solo Fabricサーバ → リモートマシン
言語 Python(2.6~) Ruby(1.9系) Python(2.5~)
設定ファイル yamlで記述 DSLで記述 Pythonで記述(シェルライク)
日本語ドキュメント 少ない 豊富 少ない
サンプル 少ない 豊富 少ない
サーバ追加の作業 少ない:実行先をhostsファイルに追加するだけ 多少多い: Chefインストールの手間がかかる 少ない:タスクの実行先を追加するだけ

まとめ

今回、話題のAnsibleを利用して、使い勝手を検討してみました。 環境構築が楽で、すぐに実行出来る点は非常に優れていますが、一方でyamlの記述力が物足りない感じでした。

また、あくまで現段階の比較ですが、Chefが既に膨大なrecipeが公開されているのに対して、Ansibleは参考になるPlaybookが見つけづらく、日本語の資料もまだまだ少ないようでした。 この辺りは、時間とともに充実してくると思いますが、現段階ではChefの方が情報がまとまっていて、扱いやすいように思いました。 また、VagrantはAnsibleも使えるようになったようですが、AWS OpsWorksやPackerなど利用されている範囲が広い点でも、まだChefが優位な様子です。

参考

最後に、Ansibleを利用する上で役に立ったサイトを挙げておきます。