[B! devops] griefworkerのブックマーク

Four Keysがなぜ重要なのか - 開発チームのパフォーマンスを改善する方法について - yigarashiのブログ

ソフトウェアエンジニアとして働き始めて以来、ずっとソフトウェアデリバリーのパフォーマンスに興味を持って、さまざまな改善活動をしてきた。当初はスクラムを中心としたプロセスの改善に注力したが、最近はチームの成熟に伴って技術的なプラクティスに興味が移りつつある。より広い視点からデリバリーについて考えるのは非常に楽しい仕事だ。デリバリーのパフォーマンスを改善していくには、定量指標として確立されたFour Keysを計測し改善するのが業界標準となりつつある。恥ずかしながら、私はこれまでこのFour Keysが腹落ちせず、積極的に計測してこなかった。しかし、多方面に興味が向いて知識や経験が蓄積するにつれて、猛烈にFour Keysの重要性が腹落ちしてきた。この記事では、現時点における自分のFour Keysに関する理解と解釈を整理してみようと思う。 Four Keysとは Four Keysの妥当性

griefworker 2022/06/01

リンク

PulumiでECS環境を構築する - Kaizen Platform 開発者ブログ

SREの本田︵@mov_vc︶です。Kaizen Platformではインフラ構築にPulumiを採用し始めています。今回は、Pulumiの基本的な説明+ECS環境をPulumiで構築した手順をまとめました。結論から言うとPulumi、かなり便利なので、導入を考えているよ〜という人はぜひ読んでみてください。 TL;DR 汎用言語で書ける TypeScript, JavaScript, Pythonで記述できます。依存関係解決してくれるリソース間に依存関係があってもPulumiさんがよしなにやってくれます。 WebUIやべーじゃん WebUIはこんな感じでプロジェクト、環境一覧画面があり、イケてます。作業履歴とかもWebUIで確認できる環境ごとのstate情報、Pulumi作業履歴などが確認できます。開発めっちゃ活発リリースサイクルが週1ペース。ちゃんと寝てる？？？ぷ…Pul

griefworker 2019/11/12

Infrastructure as Code で TypeScript や Go や C# の型の恩恵を受けられるのは大きいな。

リンク

Pulumi - Infrastructure as Code in any Programming Language

Infrastructure as code for engineers in Node.js, Python, Go, .NET, Java, and YAML

griefworker 2019/11/11

Terraform対抗馬。TypeScriptやGoといった汎用言語でInfrastructure as Code。

リンク

「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（後編）。Regional SCRUM GATHERING Tokyo 2016

「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（後編）。Regional SCRUM GATHERING Tokyo 2016 アジャイル開発手法の1つであるスクラムをテーマにしたイベント「Regional SCRUM GATHERING Tokyo 2016」が1月19日と20日の2日間、都内で開催されました。そこでマイクロソフトが行ったセッション「マイクロソフトが実践したScrum導入7年間の旅。そしてDevOpsへの進化」は、アジャイル開発からクラウドサービスの提供へと進んだマイクロソフトが、サービス開発の過程で学んださまざまな知見を共有するものとなりました。（本記事は「「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（前編）。Regional S

griefworker 2016/01/20

リンク

「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（前編）。Regional SCRUM GATHERING Tokyo 2016

「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（前編）。Regional SCRUM GATHERING Tokyo 2016 アジャイル開発手法の1つであるスクラムをテーマにしたイベント「Regional SCRUM GATHERING Tokyo 2016」が1月19日と20日の2日間、都内で開催されました。そこでマイクロソフトが行ったセッション「マイクロソフトが実践したScrum導入7年間の旅。そしてDevOpsへの進化」は、アジャイル開発からクラウドサービスの提供へと進んだマイクロソフトが、サービス開発の過程で学んださまざまな知見を共有するものとなりました。そこには、アジャイル開発の延長線上にあるDevOpsを成功させる組織と技術、そしてマインドのあり方が紹介されていました。セッションの内容をダイジェストで紹介

griefworker 2016/01/20

リンク

『Flexible Blue Green Deploymentのススメ』

どうもこんにちは。@stormcat24です。前回寄稿した記事から1年半ぶりになります。主な仕事は業務中のTwitterで、その傍らでAmebaFRESH!というサービスを絶賛開発してたりしています︵この記事が公開される頃にはリリースしてるかしら？︶。何かネイティブやりに意気揚々と異動してきたんですが、いつの間にかサーバサイドエンジニアになってました。まあサーバサイドといっても、自分はかなりWebオペレーション寄りなんですけど。で、今回はFlexibleBlueGreen Deploymentの仕組みを作ったよっていうお話です。そもそもBlueGreen Deploymentとは BlueGreen DeploymentとはImmutable Infrastructure︵不変なインフラストラクチャ︶思想の一貫で、サーバの内容やアプリケーションを更新したい場合に、稼働している

griefworker 2015/10/17

リンク

Hashicorp Ottoを読む

Hashicorpから2015年秋の新作が2つ登場した． Otto - HashiCorp Nomad - HashiCorp Ottoがなかなか面白そうなのでコードを追いつつ，Ottoとは何か? なぜ必要になったのか? どのように動作するのか? を簡単にまとめてみる．バージョンは 0.1.0 を対象にしている（イニシャルインプレッションである） Ottoとは何か? 公式はVagrantの後継と表現されている．が，それはローカル開発環境の構築も担っているという意味で後継であり，自分なりの言葉で表現してみると「OttoはHashicorpの各ツールを抽象化し開発環境の構築からインフラの整備，デプロイまでを一手に担うツール」である．ちなみにOttoという名前の由来はAutomationと語感が似ているからかつ元々そういう名前のbotがいたからとのこと．なぜOttoか? なぜVagrantで

griefworker 2015/10/06

リンク

Terraformを割と安全に使う方法 - tehepero note(・ω<)

2015-06-01 Terraformを割と安全に使う方法 DevOps Terraform インフラの構成管理という意味で今のプロジェクトではTerraformを使ってます。 hashicorp/terraform github.com 非常に便利ですが、まだまだ全然枯れてないので若干猛獣使いな感じです。というわけで現時点で﹁割りと安全に﹂Terraformを使う方法を簡単に紹介しましょう。 tfstateの管理方法 Terraformでは管理しているインフラの状態をtfstateというファイルで管理してます。tfstateの中身はJSONです。このような唯一無二な状態を保持し、かつコンフリクトを起こすと悲惨な性質を持つファイルはGitでバージョン管理すべきではありません。 S3を使う Amazon S3のように耐久性のあるオブジェクトストアで管理するのが懸命です。Terraformでは

griefworker 2015/06/02

リンク

運用を楽にするためのアプリケーションコードを書くということ : sonots:blog

griefworker 2015/05/18

devops

リンク

railsbox - Fast and easy Ruby on Rails virtual boxes

railsboxAutomate your Ruby on Rails server configuration with ansiblerailsbox helps you to start applying best DevOps practices in your project by generating ansible playbooks for configuring and deploying Ruby on Rails applications. You no longer need to edit a single configuration file on your server and use tools like capistrano for code deployments - all this comes out of the box.

griefworker 2015/01/13

リンク

インフラの継続的デリバリー - naoyaのはてなダイアリー

事前に断っておくがここでいう﹁インフラ﹂はレイヤ的にはOSより上の話。少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリーで、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更

griefworker 2014/08/21

リンク

Admins Bar

7: Water Hammer (itkq) クックパッドの @itkqさんをお迎えして、マイクロサービス時代のWebインフラや、スピリチュアルエンジニアリング、競女などについて話しました。 6: Mackerelの裏側、あるいはISUCON5で優勝する技術 (songmu) はてなの @songmu さんをお迎えして、Mackerel のアーキテクチャや ISUCON5 の優勝についてお話を伺いました。 Perl と MySQL の組み合わせを使ってきたはてなさんが、なぜ Mackerel では Scala とPostgreSQL を選んだのか。特性や使い勝手の違いなど面白いお話が聞けました。

griefworker 2014/07/26

mirakuiさんのPodcast。

リンク

Infrastructure as Code - naoyaのはてなダイアリー

今年の3月に入門Chef Solo - Infrastructure as Code という本を書いた。その名の通り Chef の入門書なのだけど、このサブタイトルは "Configuration Management Tool (構成管理ツール)" でもなく "Provisioning Framework (プロビジョニングフレームワーク)" でもなく、はたまた "Automated Infrastructure (自動化されたインフラ)" でもなく、"Infrastructure as Code" にした。この一年で Chef や Puppet にはずいぶんと注目が集まった。おそらく、AWS をはじめとするクラウドサービスがより広いユーザーに浸透したことで仮想化環境が前提になって、以前よりも頻繁にサーバーを構築し直したりする機会が増えたとかその辺がひとつ理由として挙げられると思う

griefworker 2013/12/15

リンク

specinfra をベースとしたオレオレ Configuration Management Tool/オレオレ serverspec 構想 - Gosuke Miyashita

specinfra v0.0.6 では、serverspec/configspec/Syllabus で実行する具体的なコマンドを SpecInfra::Command::* に統合しました。以前のバージョンまでは「OS を自動判別し、OS に適したコマンドクラスを返す commands と呼んでいるレイヤー」を specinfra で提供していましたが、コマンドクラスは各プロダクト側で実装していました。 specinfra v0.0.6 では、コマンドクラスも specinfra 側で持つようになりました。これで何がうれしいのかというと、オレオレ Configuration Management Tool が簡単に実装できるようになる、ということです。 Exec/SSH といったバックエンド実行形式の切り替えや、OSを自動判別して適切なコマンドを実行する部分はすべて specinfr

griefworker 2013/12/04

ruby
devops

リンク

Immutable Infrastructure時代のConfiguration Management Toolの要件およびその実装について - Kentaro Kuribayashi's blog

本稿では、"Immutable Infrastructure"時代におけるconfiguration management tool(以下、CMT)の要件およびそれを満たすツールについて議論する。背景の整理 "Immutable Infrastructure"とは、2013年6月、Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components - Chad Fowlerにより提唱された概念だ。ある種のプログラミング言語における不変性がプログラムにおける厄介な問題を解決するように、サーバの状態を不変な(正確には、状態を変更しない)ものとすることで、成長し続けるソフトウェアにとって避けられない、時間の経過によりもたらされる種々の問題が、解決可能であるとする。そもそもどのような

griefworker 2013/12/02

リンク

specinfra という serverspec/configspec に共通する処理を抜き出した gem をつくった - Gosuke Miyashita

The backend of serverspec/configspec might have to be extracted to a gem to accommodate people's preferences to abstraction level. — kentaro (@kentaro) November 26, 2013 とあんちぽさんからごもっともな指摘をいただいたし、実際に configspec を書いてて、ほとんどが serverspec からのコピペで、今後開発をつづけるのであれば、共通部分を抜き出したgem をつくるべきだな、と思ったので、specinfra というgem をつくった。 specinfra で抜き出した処理は以下の部分。 SSH, ローカル、WinRM などの実行形式を抽象化している backend と呼んでいるレイヤーOSを自動判別し、O

griefworker 2013/12/01

gem
devops

リンク

configspec という Immutable Infrastructure 用 Configuration Management Tool をつくってみた - Gosuke Miyashita

Immutable Infrastructure の有用性 - Togetter の流れの勢いで、インフラ系技術の流れとかRebuild: 25: Immutable Infrastructure (Naoya Ito, Gosuke Miyashita) とかで言ってたような、冪等性とか依存関係とかを考慮しないシンプルな Configuratin Management Tool である configspec をつくってみました。rubygems.org にもアップしてます。この手のツールに自分が望む要件は以下の様な感じ。冪等性とかどうでもいいまっさらな状態からのセットアップでしか使わない依存関係とかどうでもいいファイル名順、上から書いた順で実行してく対象サーバに余分なものをインストールしたくない対象サーバに SSH さえできればOKシェルスクリプトよりは抽象度を高め

griefworker 2013/11/26

“Immutable Infrastructure 用 Configuration Management Tool”

リンク

インフラ系技術の流れ - Gosuke Miyashita

ここ最近のインフラ系技術の流れがおもしろいなー、と思ったので、Puppet が出た辺りぐらいから、振り返って整理してみる。殴り書きなので、後から修正したり書き加えたりするかも。特に後半の方は、あまり考えが整理できてない。最近のウェブ界隈での﹁インフラ﹂という用語の使われ方には、色々異論もあるようだけど、ここではごく最近使われるようになってきた、OSからミドルウェアといったソフトウェアレイヤーを指す言葉としてのインフラについて触れる。︵英語圏でも同様の意味で使われているようなので、ある程度市民権を得たと言っても良さそうだし。︶プロビジョニングレイヤーまず、前提知識としてプロビジョニングレイヤーと自分が勝手に呼んでるものについて整理。 Chef や Puppet は﹁プロビジョニングフレームワーク﹂とも呼ばれているが、以下の議論をより厳密にするために、Lee Thompson 氏による

griefworker 2013/10/29

“システムを変更する際に、既に動いているサーバに対して変更を加えるのではなく、新しく別にシステムを構築し、古いシステムと差し替える、ってなことをやる。”

リンク

はてなブックマーク

タグ

関連タグで絞り込む (13)

devopsに関するgriefworkerのブックマーク (18)

お知らせ

今週のはてなブックマーク数ランキング（2024年7月第3週）

今週のはてなブックマーク数ランキング（2024年7月第2週）

はてなブックマーク透明性レポート（2024年 2月-2024年4月）

公式Twitter

キーボードショートカット一覧

はてなブックマーク

公式Twitter

はてなのサービス