インフラ部の荒井（@ryot_a_rai）です。この記事ではクックパッドで利用しているプロビジョニングツール "Itamae" の紹介と細々した Tips を紹介します。 式年遷宮とプロビジョニングツール 現在、弊社ではインフラの式年遷宮*1を進めています。式年遷宮以前、弊社では Puppet を利用してサーバをセットアップしていましたが、式年遷宮に際して既存のプロビジョニングに関するコードは捨てることになるため、プロビジョニングツールの再検討を行うことになりました。 Puppet, Chef, Ansible, SaltStack を検討した結果、 言語特性の観点では、Ruby DSL な Chef が良い アーキテクチャ・エコシステムの観点では、シンプルな Ansible が良い といった点から、どれも決め手に欠ける状況で、Ruby DSL で記述できるシンプルなプロビジョニングツール
※2016/04/24 追記 昨年末にItamae meetupで話した時のスライドリンクを追記しました。 Databag > itamae-secret の話やConsul連携の話が追加されています。 http://www.slideshare.net/tsuyoshitorii5/itamae-meetup-vol1public 現在自分が運用管理しているChef-soloプロビジョニングの仕組み 1 を Itamaeに移行した時のお話をしようと思います。 管理規模としては大規模ではなく、小〜中規模的なところかと思います。 （ロールによってレシピ切り分けたり、環境毎にレシピ用意したりなど…） 最初に: Itamaeについて https://github.com/itamae-kitchen/itamae 軽量なChef と考えればよいでしょう。 Chefの複雑さを取り除き、必要十分な部
自分のinit.elや.zshenvはGitHubのPrivateリポジトリで管理しています。 masutaka.netでも同じ設定を使いたかったので、Chef経由(実際はKnife Solo経由)でgit cloneしようとしたら結構ハマったので、メモしておきます。 ぶっちゃけmasutaka.netに秘密鍵をおけば、ハマることはないです。でも セキュリティ的にあんまりなので、sshのforward agent機能を使い、ロー カルの公開鍵をリモートでも使うようにします。 (1) sshのforward agentを設定する# やり方は簡単で、ローカルの~/.ssh/configに以下を追加し、ローカルで ssh-addコマンドを実行するだけ。 Host masutaka.net ForwardAgent yes この状態でmasutaka.netにsshログインし、git cloneす
前回はローカルで docker 上で serverspecを実行した。 今回は、CircleCI上で dockerを起動し、knife-soloで構築し、 serverspecでテストができるようにしようと思う。 全体のワークフローとしては、以下の順序となる。 Githubにchefのコードをpushする CircleCI上でdockerを起動する dockerのimageを作成し、コンテナを起動。 そのコンテナに対し、knife-soloを実行し、インフラを構築。 構築したコンテナに対して、serverspecを実行し、テストを行う そうすると、Githubの Merge Pull Request ボタンにテストの結果が表示される。 CircleCIの始め方などは、割愛。 Dockerfileを使用して、dockerイメージを作成する まず、以下のDockerfileを作成し、ssh可能
ブログ書きました → Chef-Soloを100倍楽しく使うためのrsoloというツールを作りました。 http://t.co/GI1DrlMx8O #chef #knifesolo — DQNEO.php (@DQNEO) September 27, 2014 @DQNEO ご存知かもしれませんが参考までにどうぞ（最近の流れだとchef-solo -> chef local mode）: http://t.co/wNvSJz3iOR — Shuhei Tanuma (@chobi_e) September 27, 2014 全俺が泣いた。 SoloからZeroへ。Chef Client Local Modeに移行しましょう 詳しくはChef公式ブログの記事に書かれています。 From Solo to Zero: Migrating to Chef Client Local Mode Ch
最近PrePAN uses carton 1.0 now! - $shibayu36->blog;でも書いたとおり、PrePANのcarton 1.0化を進めていました。 通常であれば変更点をアプリケーションサーバにデプロイし、サーバを再起動すれば良いのですが、cartonを0.9から1.0に上げるというまあまあ大きな変更を加えるため、事前に動作確認を行い、無停止でデプロイしたいと考えました。そこでAWSを使って無停止デプロイを試してみたのでそれについて書こうと思います。 PrePANのサーバ構成やデプロイ手順の検討 無停止デプロイの説明の前にPrePANのサーバ構成を紹介しておきます。 現状はELB 1つに対し、EC2が2台ぶら下がっているという状態で運用しています。そしてEC2に対してはそれぞれapp-1, app-2という名前でタグがついています。 開発メモ#2 : AWS でのホス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く