果たしてGitLab.comで何が起きたのでしょうか? これまでの経緯をまとめました。 スパムによるトラフィックのスパイクからレプリケーションの不調へ GitLab.comは今回のインシデントについての詳細な経過を「GitLab.com Database Incident - 2017/01/31」で公開しています。また、もう少し整理された情報がブログ「GitLab.com Database Incident | GitLab」にも掲載されています。 これらのドキュメントを軸に、主なできごとを時系列に見ていきましょう。 1月31日16時(世界協定時。日本時間2月1日午前8時)、YP氏(Yorick Peterse氏と思われる)はPostgreSQLのレプリケーションを設定するためにストレージの論理スナップショットを作成。これがあとで失われたデータを救う幸運につながります。 1月31日21時
Google、書籍「Site Reliability Engineering」の無料公開を開始。インフラや運用をソフトウェアで改善していく新しいアプローチ 「Site Reliability Engineering」(SRE)とは、GoogleのシニアVPであるBen Treynor氏が提唱した、高い信頼性や性能を発揮するシステムインフラを実現し、改善していくアプローチのひとつです。 これまでの運用チームやインフラチームによる運用や改善とSREが異なるのは、SREでは積極的にコードを書き、ソフトウェアによって目的の達成を目指している点にあるといえます。 Googleが公開しているSREのWebサイトでは、SREを次のように説明しています。 Like traditional operations groups, we keep important, revenue-critical syst
私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。 尚、これは所属会社の見解ではないことは明確にしておきます。 サム・グッケンハイマーの一言 私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ15年ぐらい実施し、導入の支援をしている。私はかつては、日本の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか?ということを考えていた。 ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答して
私が初めてeXtreme Programming に出会ったのは確か2000年だと思う。実際に初めてのプロジェクトを実施したのが2001年。それからすでに15年が経過していることになる。そんな長い間アジャイル、そして DevOps の日本での導入に関わってきた。日本のアジャイル導入に関しては全て成功とは言わないが、かなり成果は上げてきたとは思う。だけと、今日は自分の導入ポリシーの誤りに気付いて、新たなステージにいける気がしたので、そのことを共有してみたい。 2002年 尊敬するアリスターコバーンと、XP JUG関西のメンバーと清水寺で。私が写真撮ってたのかなw Alistair.Cockburn.us | Alistair's first trip to Japan sept 2002 日本はアジャイルの導入がこれからという噂を聞いたけど本当? これは、私がマイクロソフトの面接の時に、当時
Vagrant 1.8 で、ansible_local という新しいプロビジョナが追加されました。 これは、Ansible をゲスト(VM)側にインストールして、ローカルコネクションで VM 内で実行するものです。これは、まさに待ち望んでいた機能ので紹介します。 Vagrant + Ansible で気を付けること 以前から、Vagrant + Ansible の組み合わせでローカルの開発環境を作るなら、ホスト側に Ansible を入れるのではなく、ゲスト(VM)側に Ansible を入れる方が良いと考えていました。勉強会などでも良く話していたのでお聞きになった方もいるかと思います :) ホスト側に Ansible を入れない理由は、3 つあります。 まず、ホストに Ansible をインストールする手間が増える点です。Vagrant と Virtualbox のインストール(あとコー
ChefやAnsible、Puppet、Itamaeなどの構成管理ツールをあまり使ったことがなく、勉強のためにServerkitというのをつくってみたので、現状こういう感じでやってみましたというのを書き残しておく。作り手の気持ちになればこそわかるものがあるだろうと思う。 ところで去年も似たような記事を書いた。 概要 Serverkitというのは、前述した通りChefやAnsibleのような構成管理ツール。マシンの理想的な状態をレシピと呼ばれるファイルに定義しておき、現在のマシンの状態と比較してその差分を埋めるためのもの。Rubyで書かれていて、手元にversion 2.0.0以上のRubyと、Serverkit、それからServerkitが利用している幾つかのライブラリが入っていれば動作する。Serverkitを動かすマシンと同じマシン、もしくはSSHで接続できるマシンに対して実行できる。
はじめに このエントリは非常にポジティブで技術的なチャレンジに関するまとめであり求人エントリでもあります。 まとめ 昨年後半から、急成長するサービスを支えるため “どオンプレ” な環境で作ったサービスをクラウドに持っていく仕事をしていました。 クラウドのオイシイところを押さえられるよう作り変えをした結果として “Infrastructure as Code” を実践することになり、結果としてソフトウェアエンジニアだけですべてがコントロール出来る状態になり、インフラおじさん業が不要になりました。 そういった環境で働きたい "腕の立つITエンジニア(特にスマホとサーバサイド)" を募集しています。 発表資料&箇条書きで振り返る最近の動き AWS Casual Talks #3 https://github.com/myfinder/aws-casual-3/blob/master/slide.
※2016/04/24 追記 昨年末にItamae meetupで話した時のスライドリンクを追記しました。 Databag > itamae-secret の話やConsul連携の話が追加されています。 http://www.slideshare.net/tsuyoshitorii5/itamae-meetup-vol1public 現在自分が運用管理しているChef-soloプロビジョニングの仕組み 1 を Itamaeに移行した時のお話をしようと思います。 管理規模としては大規模ではなく、小〜中規模的なところかと思います。 (ロールによってレシピ切り分けたり、環境毎にレシピ用意したりなど…) 最初に: Itamaeについて https://github.com/itamae-kitchen/itamae 軽量なChef と考えればよいでしょう。 Chefの複雑さを取り除き、必要十分な部
若手インフラエンジニア現状確認会 #wakateinfra に参加したまとめ Feb 23, 2015 若手インフラエンジニア現状確認会に参加してきた。とにかく最高だった。 若手インフラエンジニア現状確認会 きっかけはこれです。 @rrreeeyyy @deeeet @y_uuk1 飲み会しよ pic.twitter.com/zUehyYnP7v — okumura takahiro (@hfm) 2015, 1月 22 Mackerel Meetup #3 Tokyo に参加した辺りで若手少ないかつ交流そんなにないよね、みたいになって開催が決定した。 あれよあれよという間に各社から有名若手がバンバン集まってきてこの中に居ていいのか…みたいな気分はあったんだけど、参加してみたらとにかく最高だった。 資料 各人の発表資料(無い人もいる)とちょっとしたまとめ、思ったことを付しておく。 ペパボ、
Ansibleのディレクトリ構成を決める際、プロダクション環境、ステージング環境、開発環境といった環境ごとに異なる設定を変更する方法でしっくり来るものを思いつかず、どうしたものかと悩んでいたのですが、今日見つけたブログ記事でそれもスッキリ解消したのでメモっておきます。 結論 まず結論を。プロダクション環境、ステージング環境、開発環境といった環境ごとに異なる設定する場合は、以下のように対応するのが良さそうです。 ディレクトリ構成は、公式ドキュメントに従う。 Best Practices — Ansible Documentation プロダクション、ステージング、開発など、ステージごとの変数切替は以下のブログを参考に、"group_vars"を利用して行う。 インベントリファイルの中に、"[production:children]"のようなグループすべてが属するグループを作ってしまい、そのグ
今年の6月にChef Soloは役割を終え、今後引退への道をたどると言うアナウンスがChefの公式ブログでありました。Chef Soloがなくなるということは、必ずChef Serverが必要になると言うことでしょうか?答えはなんとYesです。 しかし安心してください。そのためにChef Zeroが用意されています。一言で言うと、Chef Zeroはローカルで動かせるChef Serverです。 そしてChef Clientをローカルモードで動かすことでローカルのChef Zeroに接続するため、別のChef Serverは必要ありません。要するにChef Soloと同じような感覚でChefを使い続けることができます。 更にKnife-Zeroを使うとChef Solo同様にセットアップ先のマシンにChef Clientを簡単に入れることができます。そこで今回はこのKnife-Zeroを使
2014/10/11 に開催された PHPカンファレンス にて、「Ansibleではじめるサーバ作業の自動化」という発表を行ってきました。 午前中のセッションだったのですが、多くの方にご参加頂き、ありがとうございました。 発表資料 発表資料をslideshareに公開しました。 今回は、これからAnsibleを使ってみようという方を対象として、Ansibleの基本的な内容をメインにしました。また、実際に私自身がPHPプロジェクトで採用した際のユースケースを紹介しています。 発表後、「Ansibleをやってみます!」という意見を頂けたので、このセッションの目的は達成することができました:D このセッションのフィードバックは、joind.in にて受けて付けています。すでにいくつか好評価を頂いていて安心していますが、もし良かったらお願いします。 https://joind.in/talk/vi
米マイクロソフトはDocker社と提携し、次期Windows ServerでDockerをサポート。Microsoft AzureでもDockerをサポートするとともに、Docker Hubとの統合も行うと発表しました。 同社のエンタープライズおよびクラウド部門の責任者であるスコット・ガスリー氏が自身のブログ「Docker and Microsoft: Integrating Docker with Windows Server and Microsoft Azure」で明らかにしています。 DockerのWindowsイメージに対応 ガスリー氏のブログによると、Windows ServerとMicrosoft AzureによるDocker対応は以下の通り。 (1)マイクロソフトはDocker Engineを次期Windows Serverに統合。次期Windows Serverにコンテナ
Amazon EC2は9月末、その内部で使用しているXenハイパーバイザのセキュリティリスクに対処するため、全インスタンスの約10%にあたるインスタンスに対して段階的にリブートを行うメンテナンスを実行していました。 リブートをユーザーが回避する手段はなく、AWSから事前に通知を受けたユーザーはリブートによってデータを失ったりシステムがダウンしたりしないように、何らかの処置をする必要がありました。 AWS上で大規模なシステムを運用しつつもこのメンテナンスリブートを難なく乗り切ったのが、米国で動画配信サービスなどを運用するNetflixです。その理由は同社が開発したChaos Monkeyというツールにありました。 同社のブログにポストされた記事「A State of Xen - Chaos Monkey & Cassandra」で、その顛末が紹介されています。 Chaos Monkeyによっ
「マイクロサービス」という新しいアーキテクチャスタイルが話題になっています。ごく簡単に言えば、1つのシステムを複数の小さなサービスを組み合わせて実現することです。マーチン・ファウラー氏とJames Lewis氏が今年の5月に公開した記事「Microservices」で注目が集まりはじめました。 参考:"Microservices"を読んだ | SOTA 参考:クックパッドとマイクロサービス - クックパッド開発者ブログ 参考:マイクロサービスとSOA - InfoQ このマイクロサービスを実現する上で、組織が備えていなければならない能力について、マーチン・ファウラー氏が先月、「MicroservicePrerequisites(マイクロサービスの前提条件)」という記事を公開しています。同氏のWebサイトの記事は翻訳が許可されているので、ここで翻訳を紹介したいと思います。 マイクロサービスの
退職時の引継ぎの際に、chefで自動化されている作業を(chefを使わなくて済むように)サーバ構築手順書としてドキュメント化してくれと言われた…
本日、Mackerelを正式リリースしました。 Mackerelは、Immutable Infrastructureを取り入れたアーキテクチャや、ChatOpsといった運用スタイルに最適化した、新しいクラウドパフォーマンス管理サービスです。 Mackerelは2014年5月8日にベータ公開し、それから4ヶ月間、機能追加と安定化を目指してきました。今後も引き続き、クラウド上のサーバとそれらによって構築されるWebサービスを管理するための、より使いやすく、より便利なサービスとして開発運用を加速させていきます。並行して国際化対応し、グローバルへの展開も積極的に行います。 本日より、フル機能をご利用いただける「Standardプラン30日間無料!」キャンペーンを実施しております。ぜひお試しください。 ご意見ご要望などがありましたら、お気軽にサポートまでお知らせください。 Mackerelの特徴 M
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く