開発チームの環境をAnsibleで一括構築しよう
本連載ではこれまで、Ansibleの使い方から実際にPlaybookを書く際に役立つTips、テストの考え方などをご紹介してきました。最終回となる今回は、サンプルのPlaybookを使って開発チームのための環境を構築してみたいと思います。今回利用するPlaybookはこちらです。 https://github.com/OSSConsCloud/ansible_wg Playbookの紹介 今回利用するPlaybookは、本連載の第2回から第7回までの著者らが参加しているOSSコンソーシアム クラウド部会の活動で作成したものです。MITライセンスで公開していますので、どなたでも自由に利用することができます。 このPlaybookでは、以下のOSSツールの環境構築を行うことが可能です。 GitLab （バージョン管理ツール） Jenkins （CIツール） Redmine （プロジェクト管理ツ
実践！Ansibleベストプラクティス（後編） | さくらのナレッジ
webservers.ymlの修正 webservers.ymlを修正し、ロールにこれから作成するwebtierを追加します。 webservers.yml --- - hosts: webservers roles: - common - webtier webtierロールの作成 WordPressを動かすために必要なウェブサーバの設定を行うロールとして作成していきます。 httpdの追加 commonロールと同じ要領で作っていきましょう。 roles/webtier/tasks/main.yml yumでApacheをインストールし起動します。 --- # httpd - name: httpd is installed yum: pkg=httpd state=installed tags: httpd - name: httpd is runnning and enabled s
ansibleを使ってみる — そこはかとなく書くよん。 ドキュメント
ansibleを使ってみる¶ Chefが猛烈な勢いで流行り始めている今日このごろですが、似たようなものは 世の中にいくつもあります。今日はその中の一つ、 Ansible を使ってみます。 書いていたらやたらと長くなったので何回か続きます。 軽くご紹介¶ インストールの前にどのようなツールなのかを軽く説明します。マシンの設定 を自動で行なってくれる、というツールなのはChefと同じです。 そのポリシーは githubのページ に書かれています。 シンプルな設定 最初から超速くて並列 サーバーやデーモンとかいらない。今あるsshdだけあればいい クライアント側になにもいらない モジュールは「どんな」言語でも書ける 超強力な分散スクリプトを書くためのイケてるAPI rootじゃなくても便利に使える 今までで一番使える設定管理システム さて、では見て行きましょう。 インストール¶ ansibleは
Ansible コーディング規約 (の例) — そこはかとなく書くよん。 ドキュメント
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 }} です。 環境独自で上書きされる必要がある変数名は全部大文字としてください。 ロール内で完結する変数名は全部
VagrantとAnsibleで開発環境を構築 - テストとハマったこと | チャットワーククリエーターズブログ
バージョン: 1.4.2 Box: CentOS 6.5 (S3に用意) VertualBox: 4.3.4 共有フォルダ: Vagrantのsynced_folder (NFSは未使用) Ansible: バージョン 1.4.3 ディレクトリ構成: [ベストプラクティス] ベストプラクティスに沿ってプレイブックを作成すると、新しいロールの追加や不要になったロールの切り離しも簡単になります。 どんなテストをやったのか大きく分けて下の4つのテストを実施しました。それぞれのテストにどんな目的があるか、ちょっとだけ効率よくテストする方法と合わせて紹介します。 ロール単位で繰り返し実行するテスト 全体を通してのテスト 再起動するテスト 人柱テスト ロール単位で繰り返し実行するテストまずは粒度の小さいテストについて紹介します。 VagrantとAnsibleで作る開発環境をチームへ配布して運用を開始
Ansible チュートリアル | Ansible Tutorial in Japanese
Ansible Tutorial July Tech Festa にて開催されたハンズオンの資料が公開されていたことに刺激され、Chef の代わりに Ansible を使う資料を作りました。 Ansible を使って WordPress サーバーのセットアップを行い、ServerSpec でテストを行います。 まだ Ansible を試し始めたばかりで自分の勉強がてら書いています。 Puppet にも Chef にも乗り遅れたので Ansible に飛び乗ってみようかと。 GitHub Repository Ansible Tutorial Wiki 2013年08月13日 一段落 コピペで動かないところを全体的に修正しました。今後は 詳細ページ Wiki を充実させていきます 2013年09月09日 role についての追記しました 2013年12月22日 リニューアル Ansible
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
Ansible の Playbook を使ってみる - akishin999の日記
構成管理ツール Ansible を使ってみる の続きです。 今回は Playbook について調べた事をまとめてみます。 Playbook は Ansible のモジュールを使用した処理の組合せにより対象サーバの構成を記述したものです。 例えば Apache を使用して Web サーバを構築する場合、単に yum で Apache をインストールして完了、という事はなく、その後 httpd.conf の内容を適切に設定したり、iptables でポートを開けたり、といった一連の作業がありますが、そういったサーバ構築のための作業をまとめて Playbook として定義しておく事で、「実行できる手順書」として残しておく事が出来ます。 Puppet で言うところのマニフェスト、Chef でのレシピに相当するものになります。 Ansible の Playbook はフォーマットが YAML なので
Ansible Playbook向けのデバッガを作りました - Soon Lazy
（追記：このページの情報は若干古くなっています。Qiitaに紹介記事がありますので、参考にして下さい） Ansibleは強力な構成管理ツールですが、実環境で使ってみようとすると、うまく行かない点がいくつか出てきます。その中には、欲しいモジュールがない、同じことをシェルスクリプトで行うより実行時間が長くなる、などありますが、Playbookのデバッグに手間がかかる、というのもその一つだと思います。 Playbookのデバッグに手間がかかってしまうのには、少なくとも2つ原因があると考えています。1つは、Playbookの実行に失敗したときのエラーメッセージに、デバッグに必要な情報が全て含まれているとは限らないことです。例えば、インベントリやvarsファイルなどで定義した変数、Playbook内でregisterした変数についての情報は出力されません。もう1つは、Playbookの実行にかかる時
Ansibleを使い出す前に押さえておきたかったディレクトリ構成のベストプラクティス - 双六工場日誌
Ansibleのディレクトリ構成を決める際、プロダクション環境、ステージング環境、開発環境といった環境ごとに異なる設定を変更する方法でしっくり来るものを思いつかず、どうしたものかと悩んでいたのですが、今日見つけたブログ記事でそれもスッキリ解消したのでメモっておきます。 結論 まず結論を。プロダクション環境、ステージング環境、開発環境といった環境ごとに異なる設定する場合は、以下のように対応するのが良さそうです。 ディレクトリ構成は、公式ドキュメントに従う。 Best Practices — Ansible Documentation プロダクション、ステージング、開発など、ステージごとの変数切替は以下のブログを参考に、"group_vars"を利用して行う。 インベントリファイルの中に、"[production:children]"のようなグループすべてが属するグループを作ってしまい、そのグ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AnsibleロールのユニットテストからTravis CIまで - Qiita