Blogフリュー株式会社の技術ブログです2018年12月18日Ansibleで連番の複数ホストを指定できなかったのでその原因と対策Ansibleインフラみなさん、こんにちは。ピクトリンク事業部インフラ課の藤本佳世です。2018の12/18分の記事になります。先日、SSL証明書の更新をAnsibleで実施しようとコードを書いていた時にはまった「Ansibleで連番の複数ホストを指定できなかった件」について、シェアしたいと思います。みなさんも、「これで動きそうなんだけど、なぜ動かない!!」と思ったことあるかと思います。今回、私もそんな状況になってしまいました。※Ansibleについては、以前ブログを書いているのでこちらをご覧ください。やりたかったこと今回やりたかった作業はSSL証明書の更新です。この作業をAnsibleで実施しようと考えました。fuga.comSSL証明書の場所は下記の通りです。/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はこんな感じで書きました。server_ca.crtplaybook.ymlはこんな感じです。}サーバによって証明書が異なるので、when句を使ってtest-web-01~test-web-05はhoge_comtest-web-06~test-web-10はfuga_comのように指定したつもりでしたが、うまくいきませんでした。failed=0エラー出力されませんが、すべてskippingされた状態になりました。下記のようにplaybook.ymlを修正しました。}inventroy_hostname(ホスト名)の数字の部分だけを取り出し、「5以下」、「6以上」と識別するようにしました。公式ドキュメントにも書いている通り、CentOSのバージョンによって処理を分けることもできます。記述方法をいろいろ替えてやってみましたが、うまくいかず。}こちらの記事を参考にしてみましたが、うまいかず。}うまくいかなかった問題に関しては、また時間がある時に調べてみたいと思います。最後に2018年度の私の投稿はこの記事で最後になります。2018年は大変お世話になり、ありがとうございました。今後ともどうぞよろしくお願い致します。失敗した時の対応AnsibleLinuxはじめまして。ピクトリンク事業部インフラ課の粟田です。今回の内容を書くに至った経緯ansibleを社内で利用している事は他の記事を参照してもらえればわかると思いますが、今回そんな運用の中で発生した問題とその解決方をメモとして残しておこうという次第です。ついでに周りからのなんか書いて投稿しろ、という感じだったりします。発生した問題ユーザ管理とsudoの権限設定にはldapを使用している環境になります。visudoなどは実行できます。ansibleを実行する際に、ansible_ssh_userにrootを基本的には使用しないのが運用ルールとしてあります。どのサーバにもrootでログインしようとする人が居るので、これは禁止すべきでしょ、普通。この状態で、以下の様なplaybookを実行するとエラーになりました。上で実行することは許可されていません。上で実行することは許可されていません。1}become_userを記載しない場合には問題なく実行完了するので、油断してたんですが、実際にログインして、コマンドを実行してみました。上で実行することは許可されていません。上で実行することは許可されていません。実行できないという部分がポイントです。一部バッチ処理でもsudoしてるのがあるのでldapいじりたくないなとりあえず、運用としてansibleユーザだけなんとかできれば良いという事で、ansibleユーザのsudoの権限を単純に解決することにしました。ansibleとしてローカルで作成したファイルをansibleのcopyモジュールでリモートの/etc/sudoers.d以下に配置するという最も単純な手法で解決としました。2016.06に行ってきました!Ansibleインフラ勉強会みなさん、こんにちは。コンテンツ・メディア第1事業部インフラ担当の藤本佳世です。2016.06」に参加したお話しをしたいと思います。自称「Ansible女子」の私。3年前にも参加したことがあり、今回は3回目の参加でした。http://ansible-users.connpass.com/event/31222/AnsibleAnsibleとは、今回Meetupの会場でもあるレッドハットが開発するオープンソースの構成管理自動化ツールです。ssh通信を利用して、クライアントサーバに直接命令を送り込むことができます。フリューでは約3年前にAnsibleを導入し、ミドルウェアのインストールなどサーバ構築・管理には欠かせないツールとして利用しています。Ansibleを使うメリットはとても大きく、導入したことで、今まで手動で3時間もかかっていたサーバ構築作業を、1時間以内まで時間短縮を実現することができました。使い始めた頃は、参考書も少なく、公式HPの英語ドキュメントを参考にしていましたが、今年の4月にO’Reillyから本も発売され、ますます注目されています。OpenStackモジュール追加され、バージョン1と比べて、とても使いやすく親和性が高いsudo機能が使えなくなる予定。OpenStackなど)運用について開発とインフラの作業ラグをなくす取り組みについて、ミドルウェアバージョンアップなどインフラではなく、開発メンバーにAnsibleを実行してもらっているansible-vaultと呼ばれる機密情報が書かれたファイルを暗号化するツールの利用Ansibleは自動化だが、やはりメンテナンスする必要がある。複雑なplaybookを書いてしまい、結果ブラックボックス化してしまう。感想Ansibleバージョン2.0の新機能や今後リリース予定のモジュールなどの紹介がありました。】の発表が非常に興味深かったです。手順書作成の必要性について、いかにAnsible(コード)だけに頼らず、うまく手順書にAnsibleを載せるかについて紹介されていました。私が所属するインフラチームは、Ansibleを導入して約3年ほど経ちます。新規サーバ構築以外に、ミドルウェアのアップデート、脆弱性対応など、様々なケースで利用しています。Ansibleの構成が複雑化してしまい、他のメンバーが使いこなす事が非常に難しい状態です。そんな時、やはり手順書があればと思っていました。発表で「Jupyter」を使った手順書作成についてのお話しを聞くことができました。Jupyterの知識はゼロですが、是非検証してみたいなと思いました。その他にもOpenStackについて、Ansibleバージョン2以降、とても使いやすくなったとの発表もありました。前回のブログで紹介したOpenStackは、Ansibleを使って構築しました。今後のブログで、その手順をご紹介するので、是非読んでいただければ嬉しいです。Tweet2014年11月4日Vagrantで簡単Ansible実行環境を配布するAnsibleProvisioningVagrantこんにちは。最近、英語の勉強にハマっている国平です。私の部署ではサーバのBashのバージョンアップを1台ずつログインして手動で実行していました。このバージョンアップ作業自体は1コマンドで完了するのですが、サーバ台数が多く1台ずつに順にsshでログインしコマンドを実行するのは結構な手間が掛かりました。そこでAnsibleを使って複数のサーバの状態をまとめて変更できるようにしました。Ansibleによるサーバの管理自体は資料も多くすぐに実行出来ました。現在では非常に多くの優れた資料が公開されていますので、Ansibleを利用する事自体はそれほど難しくないかと思います。次の課題としてチーム全員がAnsibleを利用できるようにしなくてはいけません。Vagrantを利用して実行環境も含めてGitで管理し、配布できるようにしました。今回のポイント今回の課題は、チーム全員が簡単にAnsible実行環境を使えるようにするということです。便利で配布がしやすくなりそうです。Ansibleがインストール済みで、Playbookも利用できる仮想マシンにアクセスできるような仕組みづくりを行いました。AnsibleとはAnsibleはリモートマシンのあるべき状態をPlaybookというファイルに記述し、実行する事で、リモートマシンの環境を整えるツールです。以前にもこのブログの記事でも取り上げました。最近では急速に普及が進んで、利用するための情報も多く公開されていますし、電子書籍ですが入門Ansibleという本も公開されています。VagrantとはVagrantは仮想環境をコマンドラインから利用するツールです。仮想マシンの起動時にShellスクリプトやChef、Puppetなどを利用してプロビジョニングを行う事も出来ます。いった設定を全てVagrantfileにRubyのDSLとして記述する事ができるので、Vagrantfileとプロビジョニングに使うファイルをGitにコミットしておけば、どこからでも同一状態の仮想マシンを利用する事が出来ます。今回は、PlaybookとVagrantfile、そして仮想マシンのプロビジョニングファイルを1つのGitリポジトリにまとめてコミットしておきます。プロビジョニングには、チームメンバーが誰でも読み書きできる前提で、Shellスクリプトを利用することにしました。今回作成したGitリポジトリのサンプルはこちらです。仮想環境構築のポイントVagrantで仮想環境を複数人で利用するためのポイントは下記の3点です。Boxを自動的に取得するようにする仮想マシンを起動したら自動でPlaybookを実行できるようにするBoxを自動的に取得するようにするVagrantでは仮想マシンの起動の際にベースとなるイメージファイルをBoxと呼びます。チームメンバーが個々にBoxを取得するのも面倒です。指定したBoxが存在しなければ、指定したURLからBoxを取得して起動するようになります。いう名前で利用できるように設定しています。"https://github.com/2creatives/vagrant-centos/releases/download/v6.4.2/centos64-x86_64-20140116.box"</code>仮想マシンを起動したら自動でPlaybookを実行できるようにするこの処理には2つのポイントがあります。ホストのディレクトリを同期まずは、仮想マシンとホストマシンのディレクトリを同期する設定をします。設定すると、ホストマシンの指定したディレクトリを、仮想マシンから参照できるようになります。ディレクトリとして扱う事が出来ます。"/playbook"</code>仮想マシンをShellプロビジョニングもう一つのポイントは、Vagrantのプロビジョニング機能を利用して仮想マシンにAnsibleやその実行のために必要なツールをインストールすることです。Vagrantでは前述の通り仮想マシンの新規起動時にシェルスクリプトなどの実行をさせる事ができます。先ほど同期したリポジトリ内に、Ansibleのインストールなどを行う処理をまとめたシェルスクリプトを用意しておいて、実行するようにします。今回は、リポジトリ内のvagrantディレクトリに置いてある、bootstrap.shを実行するようにします。"bootstrap.sh"</code>bootstrap.shは下記のような内容になっています。/etc/ssh/ssh_config'</code>Ansibleを実行するサンプルリポジトリを使ってAnsibleを実行してみます。オプションをつけて明示的にsshを利用するようにしています。このサンプルは、Vagrantが利用できる事が前提となっています。vagrantと入力する</code>上記のコマンドを順に実行すると仮想マシンが立ち上がり、接続し、そしてplaybookが実行出来ます。まとめ今回の記事ではAnsibleの実行環境をVagrantを利用して配布しました。これによって、チームメンバー全員が簡単にAnsibleを利用する事ができます。サーバ環境だけでなく、実行環境にもべき等性を持たせる事が出来ました。これでチームメンバーのローカルマシンの設定の差に影響を受けずに作業する事ができます。Provisioning関連記事一覧Tweet2013年09月4日AnsibleでNginxインストールしてみたLinuxProvisioningクラウド全国のプロビジョニングフレームワークファンの皆さんこんにちは。フリュー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インストールの要件は、以前の記事と同じで下記のようになっています。worker_processを1に設定ファイル構成Ansibleを実行するための最小ファイル構成は、非常にすっきりしています。公式ドキュメントでは、ディレクトリ構成などのベストプラクティスも紹介されていますが、今回は以下のディレクトリ構成となりました。Chefに比べて非常にスッキリとしています。nginx.ymlこの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を利用して、使い勝手を検討してみました。環境構築が楽で、すぐに実行出来る点は非常に優れていますが、一方でyamlの記述力が物足りない感じでした。現段階の比較ですが、Chefが既に膨大なrecipeが公開されているのに対して、Ansibleは参考になるPlaybookが見つけづらく、日本語の資料もまだまだ少ないようでした。この辺りは、時間とともに充実してくると思いますが、現段階ではChefの方が情報がまとまっていて、扱いやすいように思いました。OpsWorksやPackerなど利用されている範囲が広い点でも、まだChefが優位な様子です。最後に、Ansibleを利用する上で役に立ったサイトを挙げておきます。あんしぼーちゅーとりあるそこはかとなく書くよん。