lang: en | ja
先日@naoya_itoさんが自身のブログ(インフラの継続的デリバリー)でKAIZEN platform Inc.のインフラについて書いていたやつの続編的な内容。 TL;DR Chat(Slack) + Hubot + CircleCI + GitHub を用いてセキュリティアップデートを自動化した GitHubのPull Requestを契機にセキュリティアップデートを実行できるようにした CircleCIが大変便利。インフラ系の作業を自動化するのに非常に合っている気がする 背景 KAIZEN platform Inc.では、 ネットワーク脆弱性スキャン アプリケーション脆弱性スキャン セキュリティアップデートの定期実行 の3つをセキュリティ系タスクとして継続的にやっていこうという話になり、今回は私が担当した、「セキュリティアップデートの定期実行」の話。 RHEL系OSにはyumの自動更
事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更
2014年6月1日（日）、東京・渋谷マークシティにおいて、GitHubユーザグループ主催によるイベント「GitHub Kaigi」が開催されました。500人の定員に対し800人を超える参加申し込みのあったこのイベントには、日本におけるGitHub活用の第一人者たちはもちろん、米GitHub社から招いた開発者たちも登壇し、いずれ劣らぬ濃いセッションが繰り広げられました。ここではその様子を紹介します。 GitHub実践入門 ── Pull Requestによる開発の変革 トップバッターとして登壇したのは、WEB+DB PRESS plusシリーズ『GitHub実践入門 ── Pull Requestによる開発の変革』の著者である大塚弘記氏です。 『GitHub実践入門』の著者、大塚弘記氏 同氏はまず、「GitHubを利用した開発の世界を知る」「GitHubを（利用｜活用）する違いを
少し前までアプリケーションのデプロイと言えば capistrano などをコマンドラインから叩いてデプロイ、みたいなことをやっていたが、最近は少し様子が違うのでそのやり方、KAIZEN platform Inc. での事例を紹介する。 GitHub のイベントを契機に CI as a Service にデプロイを担当させる GitHub で Pull Request を送って開発するのが前提になっているのは以前にも紹介した。 最近は Travis CI や CircleCI などに代表される CI (Continuous Integration) as a Service があって、CI も自分たちで環境を構築しなくてもクラウドに任せることができる。KAIZEN では CircleCI を積極的に使っている。 これらの CI as a Service は基本的に GitHub と連携するこ
冒頭、庄司氏は「クックパッドの印象としては、レシピのサービスが一番強いと思いますが、これ以外のサービス、新規事業にも力を入れています」とした上で「cookpad.comに関する話をします」と切り出してセッションを始めました。 まず、Ruby 2.0/Rails 3.2による環境構成を説明し、「このボリューム、正直狂っているんじゃないかな。数か月間でこれだけ増えてるんです。……あの、ここ笑うところですよ？」と独特の語り口でセッションを進めていきます。 サービスの成長と安定性を両立させる3チーム制 しかし、上図のような成長ペースにもかかわらず、デプロイは1日10回ペースを維持している。一体どうやって、これほどの安定リリースを実現しているのでしょうか？ 庄司氏はこの点について、エンジニアで構成されている『サービス開発部』『インフラ部』『技術部』の存在を挙げました。 サービス開発部隊がサービス開発
皆さんお元気ですか?LINEサーバー開発室でサーバ開発を担当している崔珉秀と申します。 この記事ではLINEのサーバーの開発とリリースプロセスについて述べたいと思います。 LINEの開発者はどんな形で開発しているのか、サービスに変更事項をどのように適用しているのか、お互い協力してより良い開発環境を得るためにどんな努力をしているのかをお伝えする機会になったらいいなと思います。 ここで述べるリリースプロセスは、LINEのサーバ開発の流れとソース管理システムの運用方法、そして本番環境に変更事項を適用するまでの過程です。 LINEのServer Applicationはその役割とシステムの構成によって複数のServer Applicationに分かれて構成されています。 例えばNetwork通信及びProtocolなどを担当するApplication、messagingやsocial graph
類似のソフトウェアとして、Puppet や Ansible といったものもあります。こういったインフラ自動化まわりのソフトウェアについてはペパボの宮下さんの インフラ系技術の流れ が参考になります。 Chef in グリー さて、グリーでのChefまわりの構成をご紹介します。下図が全体の構成です。 開発環境 開発は各個人のマシン上で仮想マシンを立ち上げて行なっています。クックブックの開発では、クックブックを開発する人が serverspec でテストを書くようにしていて、構築後のサーバが期待通り動くことをテストしています。一つのクックブックでも設定値などの条件によって動作が変わってくるため、test-kitchen を用いて複数の条件（ランリストやノードのアトリビュート（以下、「アトリビュート」）などの組み合わせ）でテストを行っています。 また、一部仮想マシンを使う必要がないテスト（att
今年の3月に 入門Chef Solo - Infrastructure as Code という本を書いた。 その名の通り Chef の入門書なのだけど、このサブタイトルは "Configuration Management Tool (構成管理ツール)" でもなく "Provisioning Framework (プロビジョニングフレームワーク)" でもなく、はたまた "Automated Infrastructure (自動化されたインフラ)" でもなく、"Infrastructure as Code" にした。 この一年で Chef や Puppet にはずいぶんと注目が集まった。おそらく、AWS をはじめとするクラウドサービスがより広いユーザーに浸透したことで仮想化環境が前提になって、以前よりも頻繁にサーバーを構築し直したりする機会が増えたとかその辺がひとつ理由として挙げられると思う
GitHub社内のDevOpsを支えるツール「Boxen」と「Hubot」（後編）～DevOps Day Tokyo 2013 世界中でDevOpsのイベントとして行われている「DevOps Days」の東京版「DevOps Day Tokyo 2013」が9月28日に開催、海外から来日した多くのゲストスピーカーによるセッションが行われました。 （本記事は「GitHub社内のDevOpsを支えるツール「Boxen」と「Hubot」（前編）～DevOps Day Tokyo 2013」の続きです） チャットを共有のターミナルとして使う 次は「Hubot」について。HubotはJavaScriptで書かれていて（注：Node.jsを用いたサーバサイトJavaScript）、メッセージを受けてその内容に従って動作します。僕は何か問題があるとHubotのせいにしています（笑） ターミナルをシェアす
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
