タグ

chefに関するsupermomongaのブックマーク (24)

  • 次世代監視ツール Sensu リファレンス - Qiita

    バージョン 0.9 くらいのときの公式ドキュメントのざっくり訳+個人のメモ 情報が古い+理解が間違ってるとこあるかもなので注意して欲しいけど、需要がありそうなので出してみる Overview Sensu は監視ツールの一つ。Sensu はよく "monitoring router" と記述される。もっと平たく言うと、Sensu は多くのノードに対して "check" スクリプトを実行し、1 つまたは複数の Sensu サーバーにて "handler" スクリプトを実行する。 例えば、Apache の死活チェックをするとしよう。チェックスクリプトにより死活だけでなくメトリクスも収集する。そしてそのアウトプットは 1 つまたは複数の Handlers にルーティングされる。Handlers はチェック結果によって何をするのか定義するものだ。Handlers は今のところ E メール、IRC、T

    次世代監視ツール Sensu リファレンス - Qiita
  • chefからansibleに乗り換えた5つの理由|TechRacho by BPS株式会社

    1年くらいchefを使ってサーバ構築をしていたのですが、最近ansibleに乗り換えたので紹介記事を書いてみます 1. サーバ側に何もインストールする必要がない chefは管理対象ノードにchef-clientをインストールする必要がありますが、ansibleはPython 2.4が入っていて、sshでログインできればOKです。 chefもパッケージや,knife bootstrapコマンド等があるので始めやすいですが、何もする必要がないansibleの方が敷居が低いのかなと思ってます。 例えばsshでログインできれば、以下のコマンドを打てば10.0.10.1~10.0.10.3サーバの情報をとってくれます(カーネルバージョン,CPU,メモリ,ディスクサイズ,ディストリビューション等)。 この機能はchefで使われているohai相当のことをしてくれます。 echo 10.0.10.1 >

    chefからansibleに乗り換えた5つの理由|TechRacho by BPS株式会社
  • 【発売のお知らせ】Chef実践入門

    全国1000万人のInfrastructure as Code職人とImmutable Infrastructure芸人のみなさんこんばんは! ということでタイトルの通りなのですが、このたび5月22日に「Chef実践入門 コードによるインフラ構成の自動化」(技術評論社)が発売になりますのでお知らせいたします。 の表紙はこんな感じになります(カバーの色やデザインは変更の可能性があります)。 ご予約は、こちらで受付中です!昨年前半に着手していたので随分時間がかかってしまいましたが、なんとか出すことができました。 今回はCakePHP界隈でもおなじみの安藤祐介さん、イケメン寿司&ドラクエ好きでおなじみの伊藤直也さん、Ruby使いの菅井さん、インフラのスペシャリスト並河さんという凄い人たちとの共著になります。 の内容ですが、Vagrantを使って簡単なクックブックをChef Soloを使って実

    【発売のお知らせ】Chef実践入門
  • 入門Chef Solo落ち穂拾い

    Provisioning Frameworks Casual Talks vol.1 (https://gist.github.com/studio3104/5417631) での発表スライドです

    入門Chef Solo落ち穂拾い
  • Run Kubernetes on a Mac with Kube Solo

    Explore Azure Get to know Azure Discover secure, future-ready cloud solutions—on-premises, hybrid, multicloud, or at the edge Global infrastructure Learn about sustainable, trusted cloud infrastructure with more regions than any other provider Cloud economics Build your business case for the cloud with key financial and technical guidance from Azure Customer enablement Plan a clear path forward fo

  • chefでインストール済みかどうかの判定にpacoを使うと便利 - UNIX的なアレ

    cookbookを書くときの冪等性 cookbookはインストール時だけでなく、何度実行しても同じ状態に保たれることが重要視されます。 chef業界ではこれを冪等性(べきとうせい)と読んでいたりします。これは設定ファイルやパッケージのインストールなど、すべてに当てはまります。 例えば、パッケージシステム経由でvimをインストールするようば場合のrecipeは以下のようにして書きます。 package 'vim' このようにすることで、それぞれのディストリビューションにあったパッケージシステムをつかってvimをインストールしてくれます。当然、二重にインストールされることはありません。 sourceからインストールするcookbook たとえばCentOSにphpをパッケージ経由でインストールすると、ちょっと古いバージョンのものがインストールされてしまいます。 新しいバージョンを使いたい場合は

    chefでインストール済みかどうかの判定にpacoを使うと便利 - UNIX的なアレ
  • ssig33.com - Docker をプロダクトのデプロイに使う

    コミケの列に並んでたあたりのころから Docker 格的に使ってます。このサイトもさっき Docker でデプロイするような感じにしました。 Docker の利点と欠点で 開発環境の配布が容易にできる プロダクトのデプロイにつかうにはなにかとキツい みたいな意見をわりと頻繁にみかけるのですが、逆じゃねえかと思ってます。これ開発環境の配布に使うの無理でしょ。各コンテナ使い捨て前提なんだし。 Docker をデプロイに使う際の問題点としては以下があります Dockerfile に 42 個しか命令かけないみたいなやつ なんだかんだでコンテナのビルドに時間がかかる コンテナの管理とかどうするのか リバースプロキシの設定とかどうするのか 一個目に関しては頑張ってください。僕はセットアップ用やデプロイ用のシェルスクリプトを ADD して RUN させるようにしてます。シェルスクリプトセットアップ

  • さくらVPSでLXCを使って安価に複数台構成を実現する - orangain flavor

    2013年6月7日 22:04更新: Upstartのデフォルトの設定ファイルを書き換えない方法に変更しました。hitoさんありがとうございます。 lxcなどのバージョンを記載しました。 はじめに Chefを使っていると、役割やサービスごとに環境を分離したくなります。 しかし、個人レベルで大してトラフィックがない段階で、サービスごとに仮想サーバーを借りていてはお金が足りません。 そこで、安価なVPS上でLinux Container (LXC) を使うことで、複数のサーバーを作ります。 スケールしたくなったときは、コンテナを潰して、新しく仮想サーバーを借りてChefで同様の設定をすれば手軽にスケールできると考えています。 Heroku使えば?と言われるかもしれませんが、色々なミドルウェアを利用したり、バックグラウンドで処理をしようとすると、たちまちお金がかかるので、VPSをやりくりして遊び

    さくらVPSでLXCを使って安価に複数台構成を実現する - orangain flavor
  • さくらVPSセットアップ用のシェルスクリプトを今話題の「Ansible」で書き直してみた - Copy/Cut/Paste/Hatena

    「Chef! Chef!」と叫ばれる昨今、そのChefに挫折した皆様、いかがお過ごしでしょうか? Chefに挫折中のid:k1LoWです。 Ansibleいいよ。Ansible。 Chefに挫折したからといってプロビジョニングツールへの憧れは消えるわけもなく、時間を見つけてはいろいろいじっていた時、 同僚からの「Ansibleというツールが良さげらしい」という情報をそのまま鵜呑みにし、PHP Matsuri 2013を通じて使ってみて今に至っています。 Ansibleいいよ。Ansible。 AnsibleはPython製のプロビジョニングツールです。ChefやPuppetと同じ領域のツールですね。 ちなみに、呼び方は、日英語的に「あんしぼぉ」です。「あんじぼぉ」でも「あんそぉぼぉ」でもありません。PHP Matsuri 2013でVagrantのMitchell Hashimotoさ

    さくらVPSセットアップ用のシェルスクリプトを今話題の「Ansible」で書き直してみた - Copy/Cut/Paste/Hatena
  • グリーのインフラに Chef を導入した話 | GREE Engineering

    類似のソフトウェアとして、Puppet や Ansible といったものもあります。こういったインフラ自動化まわりのソフトウェアについてはペパボの宮下さんの インフラ系技術の流れ が参考になります。 Chef in グリー さて、グリーでのChefまわりの構成をご紹介します。下図が全体の構成です。 開発環境 開発は各個人のマシン上で仮想マシンを立ち上げて行なっています。クックブックの開発では、クックブックを開発する人が serverspec でテストを書くようにしていて、構築後のサーバが期待通り動くことをテストしています。一つのクックブックでも設定値などの条件によって動作が変わってくるため、test-kitchen を用いて複数の条件(ランリストやノードのアトリビュート(以下、「アトリビュート」)などの組み合わせ)でテストを行っています。 また、一部仮想マシンを使う必要がないテスト(att

    グリーのインフラに Chef を導入した話 | GREE Engineering
  • さくらVPSを使って便利な開発環境を構築する - UNIX的なアレ

    開発環境は難しい 最適な開発環境をつくるのっていつも難しいなーと思います。サーバ側に入って開発する人もいれば、クライアント側のIDEあげてる人もいるわけで人それぞれです。 その人に特化した開発環境をつくるだけであればそこまで難しい話ではありませんが、チームでの開発となるとそのあたりをうまく解消するのがだんだん難しくなってきます。また、新しくサブドメインが増えたりなど開発環境も常にアップデートし続ける必要があります。 このあたりを、サーバエンジニアが手動でやってると死にます。悪しきDev/Opsの対立関係がうまれてしまうので、なんとかしないといけない。 というわけで、オフィス移転をきっかけに開発環境を作りなおしてみました。以下の3点からさくらVPSを選びました。 コストを抑えたい 最近さくらVPSに東京リージョンができた ローカルネットワーク接続できるようになった 新規開発環境をつくる上での

    さくらVPSを使って便利な開発環境を構築する - UNIX的なアレ
  • Chefのレシピは上から下に実行されるという誤解 | Engine Yard Blog JP

    Engine Yardを含むさまざまな場面で利用が広がったChefですが、その動作原理やアーキテクチャについてご存じない方もいることに気が付きました。細かなアーキテクチャを理解しなくても使うことができるというChefの長所を示しているともいえますが、細かな挙動を制御する際にはやはり動作原理などの知識があると役立ちます。 今回は表題のとおりレシピが実行される際のサイクルについてあまり知られていない部分を紹介します。 Chefの実行サイクルとリソースコレクション Chef(Chef Client、Chef Solo)が実行された際には直ちにサーバの設定が始まるわけではなく、さまざまなステップ毎に処理が実行されます。大まかには下記のようなステップになります。 Chef Serverとの通信、認証処理 Chef Serverからのクックブック、データの取得 クックブックのコンパイル ノードの設定

    Chefのレシピは上から下に実行されるという誤解 | Engine Yard Blog JP
  • さくらVPSの初期設定をChef Soloでやってみた〜サードパーティcookbookの使い方〜 | tsuchikazu blog

    Chef Soloの正しい始め方 | tsuchikazu blogがどういうわけかgoogleさんに好かれているので、続編を書きました。入門Chef Soloと正しい始め方を読んで、じゃあ実際に色々やってみようかな。とはいえ、チュートリアル的なことでなく、もうちょっと実践的なことをして理解を深めたい。このような人を対象に、さくらVPSの初期設定を題材に、Chef Soloを説明していきます。 この記事でやることは以下のとおりです 一般ユーザの作成 鍵認証の設定 sudo有効化 sshの設定 iptablesの設定 さくらVPSでよく行われる初期設定で、これを実施すればrootが乗っ取られてヤバイことになった。とかそういう事態は防げるはずです。AWSのEC2ですと、デフォルトで設定される内容になっていますので、さくらVPSをEC2レベルまでセキュリティ向上させるのを目標にします。 前提 自

    さくらVPSの初期設定をChef Soloでやってみた〜サードパーティcookbookの使い方〜 | tsuchikazu blog
  • EC-CUBE の Cookbook を作った (1) | 平穏な暮らし

  • 今っぽい Vagrant + Chef Solo チュートリアル - Qiita [キータ]

    Vagrant と Chef Solo ってとてもベンリそうに見えてたのですが、ネット上にあるのは断片的な情報が多かったり、そもそもいろんなやり方があって混乱してたので、サックリ始めるためのチュートリアルを書きました。これをきっかけにベンリな Vagrant ライフを堪能して頂ければ幸いです。 [追記10/10/2013] Window 上の Vagrant でも問題なく動きました。ただ1点注意があって、UAC のポップアップに反応しないと、Vagrant か VirtualBox 側でタイムアウトになってしまうので、ポップアップを見張るか、放置したいなら一時的に無効にしておくとよいです。 [/追記終わり] [追記 10/23/2013] VirtualBox 4.3 だとまだうまく動かないようです(私も host-only adapter の作成で VirtualBox 側のエラーになり

    今っぽい Vagrant + Chef Solo チュートリアル - Qiita [キータ]
  • IDEA * IDEA

    ドットインストール代表のライフハックブログ

    IDEA * IDEA
  • 【勉強会】AWS管理を自動化する奥義を開催しました! | DevelopersIO

    クラスメソッドブログ課外授業8日目 AWS&自動化の勉強会はやっぱり勢いがありますね~!満員御礼でした!ただ、ここまで超満員になったのは初めてでしたので、会場に来ていただいた方の中には資料が見づらいなどご不便おかけしたと思います。次回以降改善対象とさせていただきます。 @shinyaa31さんがまとめてくれたTogetterはこちらになります! 1時間目:ChefとOpsWorksでEC2楽チンクッキング! 1時間目は、大瀧隆太によるシステムの運用管理ツールとして注目されるChef。ChefをベースとしてEC2の管理に活用できるOpsWorksについてです。発表したスライドは以下になります。 ChefSoloのデモを行っている大瀧先生。Chef 2時間目:Rudess(仮)を支える技術 ~ CloudFormationの活用事例と詳細解説 2時間目は、都元ダイスケCloudFormatio

  • Chefのあれこれ #pfcasual - maoeのブログ

    昨日Provisioning Frameworks Casual Talks vol.1というイベントに参加した。イベントの内容はスライドも上がってるだろうし割愛して、今の状況や思うことなどを書いてみよう。 前提として、現職での管理対象のサーバは少なくて仮想サーバを含めてせいぜい40台程度。各人が使う開発マシンとバッチ処理が走っているマシンが半々くらい。残りは雑多な用途とproductionが数台。web系の会社と比べると極端にproductionサーバが少ないと思う。僕が入社するまではお手製のセットアップスクリプトで諸々の設定をしていたようだ。 chef-solo vs. chef-server サーバ台数はさほど多くないがchef-serverを使っていて、chef-clientを常時起動させて30分ごとにsyncするようにしている。productionサーバについてはかなり慎重に設定

    Chefのあれこれ #pfcasual - maoeのブログ
  • [Chef][serverspec]ChefSoloを使ってnginx+mysql+rubyサーバー(VPS)を30分で作る - takatoshi blog

    何かアプリを書いた時にVPSなんかで公開しようとすると 「パッケージをインストールしてアプリ書いてサーバーの設定変更してデプロイ環境を作って…etc」 と色々作業しないといけないので非常にめんどくさい。 昨今heroku/sqale/engineyardなんかのPaasもあるけれど、やっぱり自由度の高い環境を安価に欲しい場面ありますよね ってことで サーバーの基設定(ユーザーの作成やファイアウォールの設定,リモートログイン環境の整備,パッケージいインストールなど) アプリケーションの稼働環境の整備/環境のテスト,稼働 この範囲を自動化してサクッとサーバー作ります。 サンプルコードを置いているので、使ってもらえればサクッとサーバー作れます。 サーバーの基設定 サーバーのプロビジョニングはChef-Soloでやります。 Cookbookはこれ https://github.co

  • サーバ構築・デプロイの自動化の話。或いはChefとCapistranoの素敵な関係 - プログラマでありたい

    最近のChefのブレイクで、サーバの構築も自動化でという潮流になっています。そんな中でチラホラ見受けられるのが、アプリのリリースもChefでという考え方です。私は微妙に違うのではないかなぁと思っているので、ちょっと考えを整理してみました。併せてCapistranoの紹介もしてみます。 Chefの役割 まずChefについてです。Chefの役割としては、サーバの状態を管理するものです。ここで言うサーバの状態というのは、各種ミドルウェアのインストール状態&設定です。いわいるサーバ構成ですね。またChefを使う最大のメリットは、開発環境やステージング環境、番環境と全ての環境を同じスクリプトで構築するので、手作業によるミス等による微妙な差異が発生しなくなることです。 さてここで問題になるのが、サーバ上のアプリケーションのコードやデータベースのテーブル定義は、サーバの状態に入るのかという点です。入る

    サーバ構築・デプロイの自動化の話。或いはChefとCapistranoの素敵な関係 - プログラマでありたい