July Tech Festa 2015での講演資料です。 Ansibleのモジュールの仕組みや開発方法について、ちょっと掘り下げて話しています。
![Ansible 2.0 のサマライズとこれから](https://cdn-ak-scissors.b.st-hatena.com/image/square/38c96d7a4d7cb595693b76e529e3e96f9a1c6f17/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fansible200218-160218130635-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
(追記:このページの情報は若干古くなっています。Qiitaに紹介記事がありますので、参考にして下さい) Ansibleは強力な構成管理ツールですが、実環境で使ってみようとすると、うまく行かない点がいくつか出てきます。その中には、欲しいモジュールがない、同じことをシェルスクリプトで行うより実行時間が長くなる、などありますが、Playbookのデバッグに手間がかかる、というのもその一つだと思います。 Playbookのデバッグに手間がかかってしまうのには、少なくとも2つ原因があると考えています。1つは、Playbookの実行に失敗したときのエラーメッセージに、デバッグに必要な情報が全て含まれているとは限らないことです。例えば、インベントリやvarsファイルなどで定義した変数、Playbook内でregisterした変数についての情報は出力されません。もう1つは、Playbookの実行にかかる時
今回はAnsibleを本格運用した際のイメージを掴むためにAnsibleのベストプラクティスを参考に実際に試してみたいと思います。 実践のお題はWordPressとします。WordPressのセットアップを通してベストプラクティスのイメージを掴んでいただければと思います。 準備 ローカルマシンに作業ディレクトリを作り、その中でAnsibleのベストプラクティスに則ったプレイブックを作っていきます。MacもしくはLinuxなどで試してみてください。 $ mkdir try-ansible-best-practices $ cd try-ansible-best-practices ウェブサーバとDBサーバを別個に立てますので、さくらのクラウドでサーバを二台立てておきます。OSはCentOS 6.6を利用します。サーバ作成時にrootでのsshの接続に必要となる公開鍵も忘れずに登録してください
playbook 上で例えば $HOME のような値を参照する場合、少なくとも2通りのやり方があります。 (1) lookup plugin を使う Frequently Asked Questions — Ansible Documentation playbook に次のように書きます。 vars: local_home: "{{ lookup('env', 'HOME') }}" これで、以降 "{{ local_home }}" で参照できます。 (2) Facts を使う Facts については次の公式ドキュメントに記述があります。 Variables — Ansible Documentation 環境変数は "ansible_env" というハッシュの中に入っており、$HOME は次のようにして取り出せます。 {{ ansible_env.HOME }} 以上です。
Ansibleのディレクトリ構成を決める際、プロダクション環境、ステージング環境、開発環境といった環境ごとに異なる設定を変更する方法でしっくり来るものを思いつかず、どうしたものかと悩んでいたのですが、今日見つけたブログ記事でそれもスッキリ解消したのでメモっておきます。 結論 まず結論を。プロダクション環境、ステージング環境、開発環境といった環境ごとに異なる設定する場合は、以下のように対応するのが良さそうです。 ディレクトリ構成は、公式ドキュメントに従う。 Best Practices — Ansible Documentation プロダクション、ステージング、開発など、ステージごとの変数切替は以下のブログを参考に、"group_vars"を利用して行う。 インベントリファイルの中に、"[production:children]"のようなグループすべてが属するグループを作ってしまい、そのグ
Memo/Ansible/AWS Memo/Ansible/AWX Memo/Ansible/Error Memo/Ansible/Facts Memo/Ansible/Filters Memo/Ansible/Galaxy Memo/Ansible/Install Memo/Ansible/Jinja2 Memo/Ansible/ldap Memo/Ansible/local_action Memo/Ansible/Lookups Memo/Ansible/Loops Memo/Ansible/module_development Memo/Ansible/set_fact Memo/Ansible/Tower Memo/Ansible/Troubleshooting Memo/Ansible/Validation Memo/Ansible/Variables Memo/Ansible/
ansibleで実行対象を切り替える方法¶ 本番環境、検証環境、開発環境など、複数の環境を持っており、それごとにサー バーや設定が異なる、ということはよくあると思います。 ansibleで、これらの対象を切り替える方法は複数ありますので、それを紹介 したいと思います。 サーバーが異なるだけで、設定が同じ場合¶ この場合は、inventoryファイルでグループを分けて切りかえればいいと思い ます。 [stg:children] stg_Web stg_DB [prod:children] prod_Web prod_DB [stg_web] stg_web_01 [stg_DB] stg_db_01 [prod_web] prod_web_01 [prod_DB] prod_db_01
こんにちは。アプリケーションエンジニアの id:aereal です。 この記事ははてなエンジニアアドベントカレンダー2014の1日目です。 今日はアプリケーションの開発環境を作成する手順を Ansible でコードとして表現し自動化する取り組みとその背景について簡単に紹介します。 前提 この記事で扱うアプリケーションは Perl と JavaScript で書かれた中規模の Web アプリケーションです。 アプリケーションを開発するチームのエンジニアとデザイナすべてが Mac OS X を使っています。手元で開発する際には VM などを動かさずに OS X でアプリケーションを起動させます。 また、開発やデプロイなどにおいて SOCKS プロキシを通してアクセスする必要のあるサーバが存在します。 開発環境の構築手順を始めとしたドキュメントは Redmine の Wiki にまとめられていま
Ansible コーディング規約 (の例)¶ edX がgithub上でAnsibleのコーディング規約を公開しています。 https://github.com/edx/configuration/wiki/Ansible-Coding-Conventions このリポジトリは GNU AGPLv3です。翻訳の場合でもおそらく大丈夫だと思いますので、ここで翻訳して公開してみます。 一般¶ YAMLファイル すべてのyamlファイルは2スペースのインデントで、 .yml を拡張子に 付けてください。 変数 jinja変数の形式を使ってください。 $var ではなく {{ var }} です。 jinjaの変数名の前後に空白を入れてください。 {{var}} ではなく {{ var }} です。 環境独自で上書きされる必要がある変数名は全部大文字としてください。 ロール内で完結する変数名は全部
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く