本題に入る前に言っておきます。私は、このトピックは重大であるし、Chef Software（以後Chef Incと表記）の一部の人たちにとっては、ことさら重要な意味があると思っています。「Chefはオープンソースではない」という問題に向き合う時が来たのです。いつからそうなったか正確には分かりませんが、この数年間でChefはオープンソースモデルから確実にシフトしてきています。 「でも、コードはGitHubに公開されていますよ」 確かに、文字通りの意味では、コードは自由に閲覧および改変できるようになっていますが、それだけではオープンソースの理念を満たしているとは言えません。なぜなら、オープンソースとは協力してソフトウェアを構築するコミュニティだからです。 「でも、私もパッチを提供したことがありますよ」 皆さんのコントリビューションには感謝しますが、この問題は大局的に捉える必要があります。元々「
1. 本番前提で を使わずに 開発する Araki Yasuhiro スタートアップ 前に おすすめ！
開発環境は難しい 最適な開発環境をつくるのっていつも難しいなーと思います。サーバ側に入って開発する人もいれば、クライアント側のIDEあげてる人もいるわけで人それぞれです。 その人に特化した開発環境をつくるだけであればそこまで難しい話ではありませんが、チームでの開発となるとそのあたりをうまく解消するのがだんだん難しくなってきます。また、新しくサブドメインが増えたりなど開発環境も常にアップデートし続ける必要があります。 このあたりを、サーバエンジニアが手動でやってると死にます。悪しきDev/Opsの対立関係がうまれてしまうので、なんとかしないといけない。 というわけで、オフィス移転をきっかけに開発環境を作りなおしてみました。以下の3点からさくらVPSを選びました。 コストを抑えたい 最近さくらVPSに東京リージョンができた ローカルネットワーク接続できるようになった 新規開発環境をつくる上での
早いもので2013年もまもなく終わります。特にChefについては今年は大きな飛躍の1年になりました。Chefについては話題の流れも多く、自身としても何があったのかを即座には思い出せません。今回はすでにChefを使っている人の話題の復習や、Chefをまだキャッチアップしていない人が今からでも間に合う情報収集としてまとめてみます。 はてなブックマーク上でも2013年の記事でChefタグが付けられた3ブックマーク以上の記事が800エントリを超え、ブックマークの回数は3万2千回を超えるというとてつもない状況です。今回はその中でも100ブックマーク以上が付いた記事の中から特に注目が集まった話題を時系列で振り返ります。 2013年1月:「兆し」 2013年早々にChefの大躍進の契機になるエントリが@naoya_itoさんのブログに投稿されます。「開発メモ#4 : EC2スナップショットとの差分は c
Engine Yardを含むさまざまな場面で利用が広がったChefですが、その動作原理やアーキテクチャについてご存じない方もいることに気が付きました。細かなアーキテクチャを理解しなくても使うことができるというChefの長所を示しているともいえますが、細かな挙動を制御する際にはやはり動作原理などの知識があると役立ちます。 今回は表題のとおりレシピが実行される際のサイクルについてあまり知られていない部分を紹介します。 Chefの実行サイクルとリソースコレクション Chef(Chef Client、Chef Solo)が実行された際には直ちにサーバの設定が始まるわけではなく、さまざまなステップ毎に処理が実行されます。大まかには下記のようなステップになります。 Chef Serverとの通信、認証処理 Chef Serverからのクックブック、データの取得 クックブックのコンパイル ノードの設定
新規サービス用の監視をNagiosからsensuに切り替えて2ヶ月経ったので、 導入時の調査で社内で公開してたissueと、投入して2ヶ月間運用した記録を公開しておこうと思う。 というか以前Sensuの事を書くと公言していたのに、すっかりサボっていて 昨日@ma0eさんのブログを見て下記のやり取りを思い出して急いで書いた… @ma0e We started using it. @glidenote will report the detail soon, I think. — kentaro (@kentaro) 2013, 10月 30 @kentaro @glidenote that would be nice — Mitsutoshi Aoe/maoe (@ma0e) 2013, 10月 30 導入環境はCentOS 6.4で、利用しているsensuのバージョンは0.12.1-1にな
Matthew Weier O'Phinney氏はZend Frameworkのプロジェクトリードとして知られる、PHPコミュニティの中でも特に大きな業績があり、また広いネットワークを持っている人物です。今回、Matthew氏がゲスト投稿としてEngine Yardのブログに寄稿して頂きました。本記事は英語版のブログで2013/09/25に公開された記事の翻訳版です。 私は最近、様々なクラウド プラットフォーム サービス(PaaS)の試験をしていて、ごく自然にEngine YardがPHP開発者の為に提供するEngine Yard Cloudに興味を持つようになった。 筆者のアプリケーションのデプロイは、いくつかの非自明な側面が含まれており、それを実現する事が簡単だったり、難しかったりするかを知りたかった。これには下記のようなものが含む。： Gitリポジトリからデプロイ。 私のプロジェクト
AWS OpsWorksを使ってみた（概要編） では、AWS OpsWorksの概要について紹介しました。今回の記事ではそれに補足して、前回触れられなかったOpsWorksの機能の詳細や、OpsWorksの初期構築処理の仕組みに関して把握できた範囲で紹介します。 OpsWorksの各種機能 前回の記事 でも特徴の所で簡単に触れましたが、OpsWorksにはChefによる自動構築以外にも様々な機能が用意されています。まずは前回掘り下げられなかったこれらの機能について、簡単に紹介していきます。 Auto Healing (障害自動復旧) Auto Healingは、インスタンスの障害を検知した際に代替となる新しいインスタンスを自動的に立ち上げる機能です。OpsWorksの各インスタンスではOpsWorks Agentと呼ばれるサービスが稼動しており、定期的にKeepaliveパケットを送信して
Vagrantをもっと便利に使う この記事では、VirtualBoxのフロントエンドであるVagrantを使用して、仮想OSを作成してみました。 Vagrantは単に仮想OS作成が楽にできるだけでなく、Chef(等の自動設定ツール)と連携して環境構築まで楽にできるようです。 今回はChefを使用して、Vagrantで作成した仮想OSにソフトウェアをインストールしてみましょう。 環境構築方法 今回使用した動作環境は以下のとおりです。 OS : MacOS X 10.7.5 Vagrant : 1.2.2 Ruby : 1.9.3 VirtualBox : 4.1.2 ここで作ったCentOS環境を使用するので、vagrant upで起動できるようにしておきましょう。 Chef概要など 最近は社内でもあたりまえのように使用しているChefですが、私はほとんどさわったことがありませんでした。(r
こんにちは、植木和樹です。ここ最近ChefとCloudFormation漬けの毎日をすごしています。 さてChefを使ってサーバ環境を構築・保守するにあたって様々なファイルをあつかっていることと思いますが、ファイルの置き場所としてS3が使えたらいろいろ便利ですよね。cookbookと一緒のリポジトリで管理するのがふさわしくない設定ファイルや、サイズが大きくてcookbookに入れたくないオレオレRPMファイルなんかをS3に置いておいてchefレシピから扱えたら・・・今日はそんな課題に取り組んでみたいと思います。 s3_fileリソース 検索サイトで"chef s3"で検索するとs3_fileという、chefからS3を扱うためのライブラリを配布されている方がいました。 https://gist.github.com/peplin/470321 さらにこのページのコメント欄を読むと、AWS S
去る2/22(金)に恵比寿の弊社オフィスにて初の勉強会となる「初めてのChefの教室」を開催しました。インフラエンジニアだけでなく、アプリケーションエンジニアからも注目が集まっているChefの勉強会という事で様々な方にお集まり頂き、濃い情報交換が繰り広げられました。 この記事では内容のまとめてスライドや動画などの各種資料を集約します。さらに公開された記事などの資料も順次追加していきます。 Chef未経験者向けのセッション [eytokyo] 初めてのChefの教室 from suzuki on Vimeo. まずは最初のセッションとしてRubyもChefも未経験な人(≒PHPer)向けのChefのセッションをyandoが担当しました。セッションではChefの動作原理やアーキテクチャの全体像を示した上で、最低限レシピを書いて実行する為に必要な手順だけをデモを交えて紹介しました。また実際に公
Announcing Amazon Managed Service for Apache Flink Renamed from Amazon Kinesis Data Analytics Today we are announcing the rename of Amazon Kinesis Data Analytics to Amazon Managed Service for Apache Flink, a fully managed and serverless service for you to build and run real-time streaming applications using Apache Flink. We continue to deliver the same experience in your Flink applications without
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
