chef から ansible に乗り換えた時のお話。
これまでVagrantやChefをつかってインフラのコード化を勉強してきましたが、今回はさらに一歩進めてServerspecを使ったインフラのテストと、『test-kitchen』を使ったTDDにチャレンしてみました! 慣れてくるとtest-kitchenのコマンドで設定をやり直し => インフラのテストがソースコードを書くような感覚で、インフラを構築できるのがすごく心地良かったです。 ようやくですが、localのvagrantと『AWS EC2』、『Digital Ocean』に対応しました。コマンドひとつでChefを適用したり、Serverspecでリモートの環境をテストできます! (05-02 08:35) Rubyサーバ・デプロイまでのチェックリストを追加 🐝 今回のソースコードVagrant/Digital Ocean/AWS EC2上にnginx/MySQL/rbenv/Ru
Vagrant (Ubuntu) に chef-solo を使用して Rails 環境の構築を実施 git, rbenv, ruby, rails をインストールするための chef の recipe を作成する vagrant を使用して新規に仮想環境を作成 chef-solo を使用して作成した仮想環境に rails をインストールする できていないこと(要改善) chef を使用していながら bash コマンドを多用しているため、冪等性が保証できていない 前提条件 chef を使うために操作するマシン(workstation) に Mac を、環境を設定する対象のマシン(node) を Vagrand で作成する Ubuntu server 12.04 とする VirtualBox, Vagrant, chef, knife-solo が Mac にインストールされていること vag
ども、大瀧です。Amazon EC2のテンプレートであるAMI(Amazon Machine Image)の作成が設定ファイルとコマンドラインで簡単にできる、Packerというツールを以前ご紹介しました。 その記事の後半で触れていたchef-solo provisioner(Chef連携機能)が、3日前にようやくmasterにマージされたので試してみました。 chef-solo provisionerとは Packerは、AWS環境だとEC2インスタンスを作成し(下図1)、設定ファイル(Template)を元に一定の構成を行い(下図2)、そこから新たなAMIを作成できます(下図3)。 chef-solo provisionerは、下図2のEC2インスタンスの構成としてChefのインストールとchef-soloによるcookbooks/recipeを実行する機能を持ちます。Packerおよび
こんにちは! 先月ドワンゴは歌舞伎座に引っ越したので"銀座"にあうように人生初の美容院に行ったけど、結果は床屋で切ったのと変わりなかった氏家です。 前回はChefとはなんぞや、というところで終わってしまいましたが、今回は導入編で、 - 最新のChef Solo 11.6.0、Knife Solo 0.3.0 限定 - 導入から実行するまでの、迷わない セットアップ手順 及びファイル構造の新定番! を提案したいと思います。 それは、私がChef Soloを導入しようとしたときに引っかかった インストールして使い始めるまでのとっつきにくさ 開発環境と本番環境をどうCookbookで表せばいいのか 用途の違う複数のサーバーや、複数のプロジェクトを、どう管理するのがよいか 開発メンバーにも秘密にしたい秘匿情報は… といった問題をどう解決したか、そして少しでもChef導入の手助けになればと思っていま
Docker をいじって遊んでいる。 http://www.docker.io/ Docker は PaaS ベンダの DotCloud がその PaaS のバックエンドとして使っている (?) ミドルウェアを公開したもの。適当な条件の VM をポコポコ生み出してはテストや実際の運用に使うことができたりするもの。例えば「Ruby と Bundler が入っている VM」みたいなのを設定で作っておくと、後日何か Ruby でアプリケーションを動かしたいと思ったときにそのイメージをベースに VM を作ってデプロイしてやればすぐにアプリケーションが動き出す。そもそも PaaS がやっているのはそういう事で、それを汎用化したのが Docker。Travis CI のような、各言語ごとの実行環境が整った VM みたいなものに任意のコードを渡してビルドさせる、みたいなプラットフォームを作るのにも使える
サーバ構築は開発マシンであるmacから「knife-solo」でサーバ構築を行います ※knife-soloの設定は以下の記事をに書いています knife-soloを設定して開発マシン(mac)からchef-soloを実行する 設定を行うサーバは「sakura vps 1G」です、osはデフォルトの「centos6.3 x86_64」です サーバは単純なLAMP環境です 以下構築のログになります、なお今回はできるだけopscode communityに公開されているcookbookを使っていこうかと思います opscode community またサーバにログインするのは確認のみで設定をするのはすべてchefで行う予定です 構築ログ chef を実行するユーザを作成 この作業のみサーバで実行する $ ssh [ipaddress] -l root # useradd chef # pass
遅れながら、Chefの新しい11系のバージョンを触ってみました。 つまづいた途中経過を含めて、セットアップのログや動きで気付いた事を簡単に残しておきます。 尚、今回使ってみた実行環境は、CentOSの6系です(Linux)。 結論から申し上げますと、Chefの新しいバージョンは、サーバのセットアップが物凄く楽でした。 旧来のバージョンでもUbuntuはそこそこ楽でしたが、CentOSの面倒くささと言ったら、んもう。 インストールパッケージの入手先 最近は、下記のChef本家となるOpscodeのサイトから、client/serverともインストーラ(各OSでのパッケージ)をダウンロードできるようになっています。 Chef Downloads Clientのインストール 上記サイトからパッケージをダウンロードしてインストールしてもよいのですが、Linuxであれば curl -L https:
以前、ある環境のデータベースを作ったときは、忙しくて手が回らないという理由で ユーザやデータベースのセットアップは script リソースを作ってえいやと済ませてしまった tk0miya です。こんにちは。 今回はすべて community cookbook で環境を作る方法をまとめてみました。 やり方が分かってしまえばシンプルに実現できるので、泥臭く script リソースを作らずに済みそうです。 鍵は database cookbook ユーザやデータベースを作るレシピが mysql cookbook に入っていないため、 公式には提供されていないものといままで諦めていたのですが、 調べてみると mysqll cookbook ではなく database cookbook でリソースが提供されているようです。 以下、README の説明です。 The main highlight of
昨晩 Jenkins と Vagrant で CI だ、と書いたら という反応があった。確かに、可能なら物理サーバに依存しない形でテストできるとより嬉しい場面もありそうですね。 しかしそこは Vagrant。Vagrant はバージョン 1.1 から、バックエンドを VirtualBox だけでなく AWS (EC2) などの IaaS を指定して仮想サーバーを作ったり壊したりできるようになっています。詳しくは http://d.hatena.ne.jp/naoya/20130315/1363340698 この辺を。この機能を利用すれば昨日の Jenkins + Vagrant のフローをほとんど変えずに、EC2 のインスタンスでのインテグレーションテストができそうですね。 速見もこみち「では、早速やっていきましょう。」 Multi VM でローカル/リモート両対応に せっかくなので Vi
Jenkins おじさんと戯れること半日、うまくいったので備忘録を残しておく。 やりたかったのは Chef で構築したサーバーを Jenkins で CI する、というもの。このときサーバーはテストが終わる度に破棄して、テスト開始時に再度真っ新な状態から立ち上げたい。(こういうサーバーを壊して作ってというテストはなんという名前で呼ばれるのだろう?) 仮想サーバーを破棄/作成をプログラマブルにやるのはもちろん Vagrant プロビジョニングは Chef Chef の環境を整えるのに knife-solo 0.3.0.pre3 テストは serverspec コードは Github に上げる (https://github.com/naoya/jenkins-vagrant-test) CI は Jenkins という構成になっている。ひとまず Jenkins や Vagrant はローカル
AWS OpsWorksって何? から、運用しやすくなる下準備のポイントまで:AWS OpsWorksアプリケーション運用の勘所(1)(1/5 ページ) はじめに 2013年2月にリリースされたAWS OpsWorks。筆者が試しにいじっているうちに、どう使うと便利なのか、気を付けないと逆に運用が大変になるポイントなどが見えて来ました。 本連載では、何回かに分けてAWS OpsWorksの便利な点、不便な点をおさらいしながら使い勝手を紹介して行きたいと思います。題材として、「EC-CUBE」というAWS OpsWorksに最適化されていないオープンソースのパッケージを使ってみました。 AWS OpsWorksは、Amazon Web Servicesが提供するChefをベースにしたサービスです。Chefのレシピを使ってシステムの構成などを一元的に設定できます。また、アプリケーションのデプロ
去る2/22(金)に恵比寿の弊社オフィスにて初の勉強会となる「初めてのChefの教室」を開催しました。インフラエンジニアだけでなく、アプリケーションエンジニアからも注目が集まっているChefの勉強会という事で様々な方にお集まり頂き、濃い情報交換が繰り広げられました。 この記事では内容のまとめてスライドや動画などの各種資料を集約します。さらに公開された記事などの資料も順次追加していきます。 Chef未経験者向けのセッション [eytokyo] 初めてのChefの教室 from suzuki on Vimeo. まずは最初のセッションとしてRubyもChefも未経験な人(≒PHPer)向けのChefのセッションをyandoが担当しました。セッションではChefの動作原理やアーキテクチャの全体像を示した上で、最低限レシピを書いて実行する為に必要な手順だけをデモを交えて紹介しました。また実際に公
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く