Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
開発するように運用するインフラ JAWS DAYS 2015
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
JavaOne報告会2014アーキテクチャトレンド
2014/10/18に開催されたJavaOne報告会での「アーキテクチャトレンド」での発表資料です。 （誤字があったので再アップしました）Read less
Ph perがawsと出会ってdev opsを目指した話
EC2のストレージどう使う? -Instance Storageを理解して高速IOを上手に活用!-
Terraform by HashiCorp
Deliver infrastructure as codeTerraform codifies cloud APIs into declarative configuration files. AdoptCompose infrastructure as code in a Terraform file using HCL to provision resources from any infrastructure provider. BuildInfrastructure automation workflows to compose, collaborate, reuse, and provision infrastructure as code across IT operations and teams of developers. StandardizeEstablish gu
Docker 0.10リリースドキュメント日本語訳: 品質とOps Tooling - Happy New World
Docker 0.10が出たので例によってリリースドキュメントをざっくり翻訳してみました。間違い等見つけたら指摘お願いします！ 個人的には日本人開発者が増えてきて嬉しい限りです:) Docker 0.10のアップデートまとめ：バグ修正たくさん、シグナルハンドリングの修正、TLS認証サポート、Systemdプラグインサポート 翻訳元：http://blog.docker.io/2014/04/docker-0-10-quality-and-ops-tooling/ Docker 0.10: 品質とOps Tooling 今日はDocker 0.10をご紹介させていただきます。お気に召して頂けると幸いです！ 私たちは、今回のリリースにコントリビュートしてくださいましたすべての素晴らしいコミュニティの人たちに御礼申し上げます: Tianon Gravi, Alexander Larsson, V
etcd + docker で簡単にリモートコンテナに接続しよう - Qiita
Docker 盛り上がってますね。 色々使ってみるとこんなこと思うことありませんか？ NAT じゃなきゃ楽なのに 他ホストの Docker と Link できたら楽なのに そうです。色々使ってみるとネットワーク周りをどうするか？という問題にぶつかります。 導入、運用を考えてる方々は多くの場合、この問題に取り組まないといけなくなると思います。 では問題をおさらいしてみましょう Docker のネットワークの問題 Docker はポータビリティを上げるため他コンテナに IP, Port 番号などを教える機能を提供しています。 Link 機能です。 $ sudo docker run -d --name redis crosbymichael/redis $ sudo docker run -t -i --link redis:db ubuntu bash root@451f4256fbc8:/
不便さを我慢しないカルチャー - @kyanny's blog
Quipper, 採用は基本的に 24/7 いつでもウェルカム！なんだけど、とはいえ対外的にちゃんと求人を掲載して「募集中ですよ！」とアピールする必要もあるよね、ということで、 Wantedly でソフトウェアエンジニアと DevOps エンジニアの採用を開始した。 Quipperで新しい学びの形を創造したいエンジニアをウォンテッド！ - Quipper Ltdの求人 - Wantedly https://www.wantedly.com/projects/6602 @ffu_ とチャットで「こんなことやります」欄の内容を相談していて、「改めて考えると、自分たち普段いろんなことをどうやってるんだっけ？」と考えた末にひねり出した一文がこれ。 Quipperのエンジニアリングは「生産性」にフォーカスしています。運用に人手のかかるインフラ部分はHerokuやCircleCI等の外部サービスを積極
fluentdの効果的な活用例と安定運用のポイント
fluentdの効果的な活用例と安定運用のポイント：今さら聞けないfluentd～クラウド時代のログ管理入門（3）（1/3 ページ） 効率良く、意味のあるログ管理を実現するツールとして注目されている「fluentd」。最終回では、実際の利用シーンを想定し、より効果的なfluentdの利用法を紹介します。 第1回、第2回でfluentdを使って基本的なログ管理が実現できるようになったのではないでしょうか。fluentdはプラグインの組み合わせにより更に効果を発揮します。最終回では、実際の利用シーンを想定し、より効果的な利用法を紹介します。 fluentdの具体的な活用例 実際の利用シーンを想定した2つのfluentdの活用例を紹介します。 大量のログを分析し、「意味のある情報」として管理する タグデータを効果的に活用し、ログデータのフィルタリング管理を行う 1.大量のログを分析し、「意味のあ
ansibleをmacに入れてさくらVPSの環境構築してみる、その１
Infrastructure as Code！！ ということで、言いたい事言ってこの流れに乗ってみました。 chef流行ってますけど、なんかちょいと壁が高そうと感じてたところに、ansibleとやらを知ったので、導入してみました。 さくらVPSの乗せ変え作業が目的だったので、それを最終目標に、今回はとりあえず導入編で。 メインマシン : 手元のMac（OS X 10.7.5） 対象サーバ : さくらVPS (CentOS6) ansible インストール Macにansibleをインストールします。 (ここを参考にしました。Installing Ansible on OS X) pythonの動作環境構築 ansible はpythonで動くので、まずはpythonが動く環境を用意します。
Ansible コトハジメ - Qiita
Ansible を15分程度で「もう使えそう」と感じてもらうために書きました。 Ansible はプロビジョニング用アプリケーションです。 同じ目的のものでは Chef、Puppet などがあります。 Ansible の特徴だと感じたのは、とても簡単ですぐ実用できることです。 Chef で挫折してしまった私(不勉強ですみません)も、一日で仕事で必要なことができました。 簡単というと Fabric (やCapistrano) がありますが、環境構築やデプロイには Ansible が強いと感じます。 Python で書かれたものですがユーザーは YAML でタスクを書きます。 以下の作業で Python は出てきますが、Ansible をインストールする以外では本質的に不要なのでご安心(?)ください。 次を前提とします。 Vagrant に Ubuntu 13.10 が用意されていること Ma
Ansible チュートリアル | Ansible Tutorial in Japanese
Ansible Tutorial July Tech Festa にて開催されたハンズオンの資料が公開されていたことに刺激され、Chef の代わりに Ansible を使う資料を作りました。 Ansible を使って WordPress サーバーのセットアップを行い、ServerSpec でテストを行います。 まだ Ansible を試し始めたばかりで自分の勉強がてら書いています。 Puppet にも Chef にも乗り遅れたので Ansible に飛び乗ってみようかと。 GitHub Repository Ansible Tutorial Wiki 2013年08月13日 一段落 コピペで動かないところを全体的に修正しました。今後は 詳細ページ Wiki を充実させていきます 2013年09月09日 role についての追記しました 2013年12月22日 リニューアル Ansible
Amazon LinuxにDockerが入った！！ - Qiita
Amazon Web Services Blogで、今回のAmazon Linux AMI 2014.03リリースにDockerが導入されたことがアナウンスされています。 Docker 0.9 - You can now run Docker containers on the Amazon Linux AMI. さっそく試してみた: 確認する、 $ sudo yum search docker 読み込んだプラグイン:priorities, update-motd, upgrade-helper ================================================================== N/S matched: docker ==============================================================
【デブサミ2014】13-B-7 レポート 「何故クックパッドのサービス開発は日々進化しているのか」
冒頭、庄司氏は「クックパッドの印象としては、レシピのサービスが一番強いと思いますが、これ以外のサービス、新規事業にも力を入れています」とした上で「cookpad.comに関する話をします」と切り出してセッションを始めました。 まず、Ruby 2.0/Rails 3.2による環境構成を説明し、「このボリューム、正直狂っているんじゃないかな。数か月間でこれだけ増えてるんです。……あの、ここ笑うところですよ？」と独特の語り口でセッションを進めていきます。 サービスの成長と安定性を両立させる3チーム制 しかし、上図のような成長ペースにもかかわらず、デプロイは1日10回ペースを維持している。一体どうやって、これほどの安定リリースを実現しているのでしょうか？ 庄司氏はこの点について、エンジニアで構成されている『サービス開発部』『インフラ部』『技術部』の存在を挙げました。 サービス開発部隊がサービス開発
Docker 使ってたらサーバがゴミ捨て場みたいになってた話 #immutableinfra - ゆううきブログ
Immutable Infrastructure Conference #1 : ATND でLTしてきた。 内容はきれいにゴミを捨てましょうという話以上のものは特にない。 背景の説明が少し雑だったので補足すると、Jenkins のジョブスクリプトで、git push する度に docker run していたら ゴミがどんどんたまっていったという感じ。 1 push あたり、アプリコンテナ、DBコンテナとか合わせて3コンテナぐらい起動してるから開発が活発だと、どんどんゴミがたまる。 さらに補足すると、Device mapper がらみのゴミは、aufs 使うとかなり解決できそうな感じはしてる。 (Device mapper だとブロックデバイスレベルでイメージ差分を表現するので、デバイス毎(差分)毎に mount が走るみたいな実装になってるけど、aufs だとファイルシステム単位で複数の
LINE Serverの開発とリリースプロセス « LINE Engineers' Blog
皆さんお元気ですか?LINEサーバー開発室でサーバ開発を担当している崔珉秀と申します。 この記事ではLINEのサーバーの開発とリリースプロセスについて述べたいと思います。 LINEの開発者はどんな形で開発しているのか、サービスに変更事項をどのように適用しているのか、お互い協力してより良い開発環境を得るためにどんな努力をしているのかをお伝えする機会になったらいいなと思います。 ここで述べるリリースプロセスは、LINEのサーバ開発の流れとソース管理システムの運用方法、そして本番環境に変更事項を適用するまでの過程です。 LINEのServer Applicationはその役割とシステムの構成によって複数のServer Applicationに分かれて構成されています。 例えばNetwork通信及びProtocolなどを担当するApplication、messagingやsocial graph
クックパッドのデプロイとオートスケール、1日10回デプロイする大規模サイトの裏側（後編）。JAWS DAYS 2014
クックパッドのデプロイとオートスケール、1日10回デプロイする大規模サイトの裏側（後編）。JAWS DAYS 2014 大規模なオンラインサービスを支えるためのオートスケールと、サービスをすばやく進化させていくための迅速なデプロイ。クックパッドはこの2つをクラウド技術の組み合わせによって両立させています。 同社のインフラ責任者である成田氏がその仕組みやルールを、Amazonクラウドのユーザーコミュニティ主催のイベントJAWS DAY 2014で解説しました。 （本記事は「クックパッドのデプロイとオートスケール（前編）。JAWS DAYS 2014」の続きです） オートスケールはAmazon Auto Scalingを使わないと判断 今日の本題であるオートスケールの話をしたいと思います。 オートスケールとは一般に、トラフィックが増えたらサーバを増やしましょうね、という作業を自動化するものです
継続的システムテスト - Test Automation
JaSST'Tokyo 2014で、"システムテスト自動化による大規模分散検索プラットフォームの開発行程改善"という題目で事例発表をした。下記は当日発表に用いたスライド。 【JaSST'14 Tokyo】システムテストの自動化による 大規模分散検索プラットフォームの 開発工程改善 from Kotaro Ogino ここでは、この発表に入りきらなかったコンセプトや、口頭でしか説明していないためスライドを読んでも分からない部分について補足する。 背景：開発スタイルの変化 -継続的テストについてリーンとDevOpsから考えてみる リーンは、顧客目線でソフトウェアの価値を定義し、それらをエンドツーエンドで細く速く流れるように開発するスタイルだ[1]。小さい要件を要求分析から品質保証まで流れるように実行し、少しずつリリースして行く。ウォーターフォールでは、重厚長大にそれぞれの工程を実施していたのに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://atlas.hashicorp.com/
Etsyはいかにして1日に50回ものデプロイをしているのか
DevOpsとは何（ではないの）か、そしてどうやって実現するのか