『The DevOps 逆転だ！究極の継続的デリバリー』（ジーン＝キム、ケビン＝ベア、ジョージ＝スパッフォード著、榊原彰監修、長尾高弘訳）を読んだ。本書は小説の形でケーススタディを行いながらDevOpsとは何かを解説するものである。経済学でいうところの「もしドラ」のような本だ。友人が絶賛していたのでうっかりポチって読んだ。以下はその感想であり、当然のようにネタバレを含む。 IT運用部長である主人公が突然CEOに呼び出され、CIOに任命されるところから始まる。IT部門は腐りきっており、プロジェクトは常に炎上しているうえ、デプロイも毎回のようにトラブルを起こすような状態である。さらに事業部は気が狂ったような開発スケジュールを引いてくる。そのような状況の中、主人公は開発と運用が協力してシステムを作り上げるプロセス、いわゆるDevOpsを実現するという内容だ。ここで、この本の範囲は開発と運用のみ、
デブサミ2017で発表予定の資料です。 http://event.shoeisha.jp/devsumi/20170216 2017/02/14 ver1.0 公開Read less
DevOpsの採用は大企業が先行、DockerとAnsibleの利用は1年で倍増。RightScaleがDevOpsの調査結果を発表 マルチクラウドに対応したマネジメントサービスを提供している米RightScaleが、DevOpsに関する調査結果を発表しました。調査対象は1060人のITプロフェッショナルで、うち42％が1000人以上の大企業に勤めています。 調査結果では、大企業の方が中堅中小よりもDevOpsの導入が進んでいること、Dockerの利用が急速に立ち上がっていること、ChefとPuppetを両方採用している企業が多いことなどが示されています。 主な調査結果のグラフを見てみましょう。 大企業（Enterprise）と中堅中小（SMB）では、大企業のDevOps採用が81％、中堅中小では70％と、大企業の方がDevOpsの採用が進んでいることが分かります。 利用しているDevOp
2016/02/26 に出版される「サーバ/インフラエンジニア養成読本 DevOps編」というムック本にて、Ansible 2 について書きました。 本書は、昨今では普及してきた DevOps や Infrastructure as Code といったキーワードに関心がある方向けの本です。はじめに概念の定義や現状をおさえた後に、Ansible、Circle CI、Docker、Kubernetesなどツールを活用して実践する構成となっています。 Ansible 2 によるサーバ環境の構築 特集 1 である「Ansible 2 によるサーバ環境の構築」を担当しました。ここでは、Ansible の基礎をベースに、Vagrantを利用したサーバ環境の構築を解説しています。 Ansible には多くのユーザがおり、すでに多くの Playbook が公開されています。そこで、Playbook のシン
フェイスブックにおけるオペレーションの自動化戦略を、同社のエンジニアリング担当バイスプレジデントが語る。その根底には「優秀人材を活かす」という明確な意図が見られた。 フェイスブックでのオペレーションの実行は大仕事である。世界中に膨大なネットワークを持ち、サービスの信頼性とユーザー体験の充実が絶対的に重視される。そのうえ、現行の製品・サービスの維持に甘んじてはいられないという現実がある。自社がさまざまなイノベーションの目標を追求できるよう、常に新たな柔軟性と処理能力を生み出すことが求められているのだ。将来を見据えた同社の野心的な取り組みには、コネクティビティ・ラボ（世界中のインターネット未整備地域に接続環境を行き渡らせる計画に取り組む）、人工知能、ディープラーニング、そして次世代のコンピュータ・プラットフォームとなるバーチャルリアリティなどがある。 本記事では、フェイスブックのエンジニアリン
Hashicorpから2015年秋の新作が2つ登場した． Otto - HashiCorp Nomad - HashiCorp Ottoがなかなか面白そうなのでコードを追いつつ，Ottoとは何か? なぜ必要になったのか? どのように動作するのか? を簡単にまとめてみる． バージョンは 0.1.0 を対象にしている（イニシャルインプレッションである） Ottoとは何か? 公式はVagrantの後継と表現されている．が，それはローカル開発環境の構築も担っているという意味で後継であり，自分なりの言葉で表現してみると「OttoはHashicorpの各ツールを抽象化し開発環境の構築からインフラの整備，デプロイまでを一手に担うツール」である．ちなみにOttoという名前の由来はAutomationと語感が似ているからかつ元々そういう名前のbotがいたからとのこと． なぜOttoか? なぜVagrantで
2015-07-22 EC2 Container Service(ECS)を管理して、Blue-Green Deploymentを実現するツールを書いた AWS Docker ECS 最近は暑いのでめっきり外に出なくなりましたが、相変わらずDevOpsのOpsばっかりやっています。 さて、今やってるプロジェクトではAmazon EC2 Container Service(ECS)で完全にDockerベースでの開発をしています。本番運用を見越したオペレーションの作り込みをやってるわけですが、今回はBlue-Green Deploymentを実現してみたよってお話。 材料 必要な材料は以下の通り。 VPC Route53 EC2 ELB AutoScaling Group ECS 方式 最近ELBがAutoScaling Group単位での切り替えができるようになったので、これを利用します。基
概要 TerraformのAWSを使って、CLIを通してインスタンスの起動→変更→停止を行うためのチュートリアル。Terraform の基本概念である plan apply show のサイクルを理解するためのもの。 追記 Terraformのblog投稿、参考訳 - Qiita http://qiita.com/zembutsu/items/402e02950ce9d59fa0e6 Terraform入門 日本語訳 - Qiita http://qiita.com/zembutsu/items/84f5478701c5391df537 Terraform とは Hashicorp (Vagrant, Packer, Serf, Consul を作っている会社) によって 7/28 に公開された新しいオープンソースのプロダクト。 Terraform http://www.terraform
ども、大瀧です。 VagrantやPacker、Serfを開発するHashiCorpが手がける新オーケストレーションツール、Terraformが発表されました。zembutsuさんが神速で日本語チュートリアル記事を既に公開しているので、terraformコマンドの使い方はそちらを参照ください。 Terraformとは Terraformは、あらかじめインフラ構成をテンプレートファイルに記述し、terraformコマンドでクラウド環境に適用・管理するツールです。一見するとAWS CloudFormationと非常に良く似た作りですが、以下の特徴があります。 複数のクラウドサービスに対応し、高レイヤーのアプリケーション構成に特化 現時点でTerraformが対応するサービス/プロダクトは以下です。 AWS CloudFlare Consul DigitalOcean DNSimple Hero
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 >
When it comes to DevOps tooling and configuration management, there's still a lot of confusion as to which tools do what, and how they play with each other, if it all. For the second part of our interview with Docker, we got some more clarity on how Docker fits into people's current toolset and discussed some use cases in which Docker is most useful as a primary tool vs. as a complimentary tool. L
なんかごく一部に補足されているので、念のため軽く説明しておきます。 masahiro nagano@kazeburo某所のlestrratさんのgolangなアプリはhot-deployが可能になってる。サーバはserver_starter経由で起動されていて、バイナリ消してHUPを送ると自動でビルドしなおしてプロセスを入れ替えてくれる。便利 2014/04/30 12:18:31 これ、ベストな方法だとは思っていないんだけど、最初にこれを書いた当時の考え方は以下の通り： これは自分の部署で初めて 本番に設置するgoアプリである一次対応をする人は自分とは限らない細かいコード内容の修正はともかく、明らかなバグっぽいものの修正（例：SQL文の変更）などを自分以外の人間が施した後にサーバーを簡単に再コンパイル＋再起動するする方法がないと椅子が降ってくる事が容易に予想される Apache::Log
この記事はDockerに関する実験的な記事や，Buildpackを使ってHeroku AppをDocker Containerとして使えるようにする“building”の開発などで知られるCenturyLink Labsの “What is Docker and When To Use It”の翻訳です． Dockerとは何か？Dockerをどこで使うべきか？についてよく見かける記事とは違った視点から説明されています． 翻訳は許可をとった上で行っています． Dockerとは何でないか Dockerとは何かを説明する前に，Dockerは何でないかについて述べる．Dockerの否定形は何か？Dockerの制限は何か？Dockerが得意でないことは何か？ DockerはLXCのようなLinux Containerではない DockerはLXCだけのラッパーではない（理論的には仮想マシンも管理でき
このエントリは前後編に分かれています。前編は主に運用フローやそこでの工夫点、後編は実際の運用から得た知見や今後の課題といった内容です。 ヌーラボのインフラ運用最前線 〜イミュータブルを目指して〜 (前編) ヌーラボのインフラ運用最前線 〜イミュータブルを目指して〜 (後編) 最近はインフラ運用・DevOPS関連のトピックとして目にしないことはないくらい、「イミュータブルインフラストラクチャー」について様々な議論がなされています。私たちも昨年、継続的デリバリという文脈で、@IT の連載にてその基本的な考え方について紹介させていただきました。 さて、今年の二月にローンチをしたばかりのヌーラボのシングルサインオンサービス「ヌーラボアカウント」では、イミュータブルインフラストラクチャの一歩手前として、特定の変更を加える場合のみ、ごっそり環境ごと入れ替えるというやり方にてその運用をスタートしました。
みなさんこんにちは。@ryuzeeです。 DevOpsGuysというサイトのTwelve DevOps Anti-Patternsという記事が秀逸です。 作者の方に許可を頂き翻訳しましたので公開します。 原文も軽妙なタッチで読みやすいと思いますのでぜひご参照ください。 また本文で様々なスライドや資料へのリンクがありますので、そちらも見ていただくと理解が深まるんじゃないかと思います！ えっとDevOpsを始めたいのかな？おっけー。ただ始める前に、やってはいけないいくつかのことについて見ておこう。 古き良き時代には単に「良くないアイデア」って呼んでいたんだけど、外交やポリティカル・コレクトネス運動の結果、ブレストやアイデアシャワーをして、最近は「アンチパターン」と呼ばれるようになった。 パターンが絶対的に正しいのであれば、すなわち「アンチパターン」は間違いということになる。そして間違いを避ける
Daniel Schauenberg氏は先日のQCon Londonで、DevOpsや継続的インテグレーションを実践していることで有名なEtsyが、いかにして1日に50回ものデプロイをしているのかについて語った。リスクを最小限に抑えながらこのペースの変更を実現するためには、完全に自動化されたデプロイメントパイプライン、徹底的なアプリケーションのモニタリング、IRCベースの共同作業、これらすべてが重要なのだ。 Etsyの開発への取り組みは、いくつもの小さくて途切れることのない変更を中心に回っている。直接影響するのは、一日に何度もデプロイする必要性だ。Daniel Schauenberg氏の言葉を借りれば、Etsyの開発者はいつどんなときでも「今すぐこの変更をデプロイするゆとりが自分にはあるか？」という質問の答えを知っていなければいけない。常にゆとりを持てるように、Etsyはさまざまなツールや
by @dekokun on 2013/05/21 23:46 Tagged as: Capistrano, Fabric. 最近、Fabric, Capistranoと立て続けに2種類のデプロイツールを使ってデプロイ環境を構築する機会がありましたので、その際に感じた両者の利点を書いてみたいと思います。 両者の簡単な解説 そもそもCapistrano, Fabricについて、「片方は知っているけど片方は知らないよ」という人がいるかと思いますので、簡単な説明をします。 両方とも何かを知らない人は…「自動デプロイ」とかそのあたりで検索してみるといいんじゃないですかね。 Capistranoとは Ruby製のFabricみたいなものです Fabricとは Python製のCapistranoみたいなものです Fabricは私の中ではデプロイツールという認識なのですが、最近Chefと比較されること
http://nerds.airbnb.com/making-breakfast-chef-airbnb/ Airbnbが社内でのchefの利用事例について、かなり細かめに紹介してくれてます。 1) 背景 Airbnbは動的なコード環境にある。Amazon EC2のバーチャルマシン上で動くサービスが組み合わさってサイトが構成されている。 昨年、EC2のインスタンスを立上げ & 設定をするCloudMakerをオープンソースで提供し、従前の手動作業からは相当効率化したが、YAMLの設定を全て希望するかたちにはできなかったので、S3に複雑なバージョンのシェルスクリプトツリーができて、メンテナンスが難しくなった。 そこで、2012年2月からChefへの統合を開始。OpscodeのホスティングChefを利用し、数週間で共通設定項目についての移行が完了し、本番稼働した。しかし、Chefユーザが増える
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: エンタープライズ開発 新潮流 (日経BPムック): 日経コンピュータ, ITpro: 本
