Itamaeのmruby実装「mitamae」が大体いい感じになった話 - k0kubun's blog
Roppongi.rb #2 で「mitamae」について話してきた Roppongi.rb #2が "Infrastructure x Ruby" をテーマに開催され、そこで RubyなしでItamaeレシピを実行できる「itamae-go」を作った - k0kubun's blog 話と pure mrubyで実装されたItamae「itamae-mruby」を作った - k0kubun's blog 話をしてきた。 いいたかったことはスライドの通りだけど、枠が15分でいろいろ漏れた話を書いておく。 mitamaeの現状について なんでitamae-mrubyからMItamaeに変えたの というか一昨日までmitamaeはitamae-mrubyという名前だった。エエー。変えた理由は真面目な奴がいくつかあるんだけど、あえて不真面目な奴だけ書くと、名前が微妙なソフトウェアは流行らない気が
Itamae、Auto Scaling、CodeDeployを用いてdeployフローを刷新した話。そして板前をprovisioningした話。 - SmartNews Engineering Blog
その上で、新しく作り上げた deploy フローについて、雑な絵になりますが概略図を以下に示します。 主要な登場人物は Itamae Auto Scaling CodeDeploy GitHub / Circle CI となります。それぞれ追って説明をしていきます。 https://github.com/itamae-kitchen/itamae Itamae は @ryot_a_rai さんが作られた LightWeight な Chef like な OSS です。Chef で実現できた事のうち、 recipes の部分のみを切り出したようなシンプルなツールになっています。 (こちらの発表資料より引用) 弊社内で蓄積された Chef 関連のリソースを再利用・再整理するために粒度がちょうど良かったこともあり、Itamae を用いて provisioning の定義を書き直すことにしました
プロビジョニングツールをChef-soloからItamaeに替えてみました - yuumi3のお仕事日記
Chef から Itamae ？ EY-Officeではサーバーソフトの構築を行うプロビジョニングツールとして現在は Chef-solo を使っています。しかし Chef-solo は終了するらしいのですが、その移行先が良いように思えず悩みながら使い続けてきました。 そんなとき登場してきた Itamae はシンプルでとても魅力を感じました。詳しくは クックパッド開発者ブログのItamae記事 をご覧下さい。 今回時間があったので、EY-Officeの開発支援サーバー (Redmine, Git/Gnatara, CI ...)の全プロビジョニングをChefからItamaeに置き換えてみました。書き換えたレシピは約700行です、そこで感じた事を書きます。 Itamaeの良いところ、良くないところ 1. 情報が貧弱 まず良くない点ですが、Chefのドキュメント に比べると情報の量、質ともに低い
第1回 シンプル・軽量な構成管理ツールItamae | gihyo.jp
はじめに はじめまして。クックパッド株式会社の荒井（@ryot_a_rai）と申します。 今回から全5回、構成管理ツールであるItamaeの入門から実際の活用例までを解説していきます。今まで構成管理ツールを使ったことがなかった方から、Itamaeをすでに使っている方まで、ぜひご覧ください。 Itamaeとは Itamaeは筆者が中心となって開発を進めているオープンソースの構成管理ツールです。同様のツールとしてはPuppet、Chef、Ansibleなどが有名ですが、ItamaeはChefに影響を受けています。Chefの記述性・柔軟性を持ちながら、シンプルで導入しやすい構成管理ツールを目指して開発が進んでいます。 構成管理ツールの必要性 Itamaeの解説を始める前に、構成管理ツールを使う理由について軽く考えてみたいと思います。 サーバ構築の自動化 手動構築の手間と時間を減らす 手動構築によ
クックパッドのサーバプロビジョニング事情 - クックパッド開発者ブログ
インフラ部の荒井（@ryot_a_rai）です。この記事ではクックパッドで利用しているプロビジョニングツール "Itamae" の紹介と細々した Tips を紹介します。 式年遷宮とプロビジョニングツール 現在、弊社ではインフラの式年遷宮*1を進めています。式年遷宮以前、弊社では Puppet を利用してサーバをセットアップしていましたが、式年遷宮に際して既存のプロビジョニングに関するコードは捨てることになるため、プロビジョニングツールの再検討を行うことになりました。 Puppet, Chef, Ansible, SaltStack を検討した結果、 言語特性の観点では、Ruby DSL な Chef が良い アーキテクチャ・エコシステムの観点では、シンプルな Ansible が良い といった点から、どれも決め手に欠ける状況で、Ruby DSL で記述できるシンプルなプロビジョニングツール
chefに疲れたあなたにはItamaeがおすすめ！ - ゆーじのろぐ
chef使うのめんどくさくないですか？ 私はいままでサーバーの設定を自動化するためのツールにchefを使っていました。 最初chefを使い始めた時は、いままで手作業でやっていたことがコード化・自動化できるので「お、便利ー！chef最高！」という感じだったのですが、 だんだん使っていくうちにchefが高機能が故に自分の用途としては使うのが辛くなってきました。 そもそも自分はchef soloしか使わない chef は基本的にはchef-server - chef-client という構成で、設定を自動で行いたいサーバーに対してchef-clientをインストールします。 そして対象のサーバーの設定をコード化したrecipeを保持するchef-serverとchef-clientが通信して対象サーバーにrecipeを適応します。 このchef-serverを立てずにchef-clientだけで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
