DevOpsに欠けている二つのピース

「DevOpsに欠けている二つのピース」ということで、以下のようなまとめがされている。

DevOpsを補う二つの重要なピースである「利用部門」と「分析プロセス」について述べた。利用部門を含めたDevOpsの定義は、「開発チーム、運用チーム、利用部門が一丸となり、ビジネス上の効果を高めるため、短サイクルでシステムを改善し続ける取り組み」となる。これには、開発チーム、運用チーム、利用部門の壁を超えた「プロセス」「組織体制」「ツール」の改革が必要だ。

DevOpsではあると思いますが、なんか'BtoB'とか'SI'の色が強い気もしますが、、 共感できる部分はありました。

記者の眼 - DevOpsに欠けている二つのピース:ITpro

こんな本最近出てるみたいです。

Redmine超入門 (日経BPムック)

Redmine超入門 (日経BPムック)

はてなやクックパッドの開発現場で、CIやテストはどう行われているのか?

先進的な現場でテストやCIがどのように行われ、エンジニアのチームがどのように情報共有をしているか、本音で語るという注目すべき内容でした。本記事ではそのダイジェストを紹介しましょう。

『入門Chef Solo』やWEB+DB PRESSでもおなじみの?!伊藤 直也さんも参加されています。 はてなやクックパッドの事例は、アジャイル開発やDevOpsを実践する上で、とても参考になります。

はてなやクックパッドの開発現場で、CIやテストはどう行われているのか?(前編)。CROSS 2014 - Publickey

はてなやクックパッドの開発現場で、CIやテストはどう行われているのか?(後編)。CROSS 2014 - Publickey

入門Chef Solo - Infrastructure as Code

入門Chef Solo - Infrastructure as Code

[24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)

[24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)

チームのメンバーで同じ環境を簡単に作りたい時は

もはや開発環境では定番となった、 vagrant、chef-solo、Berkshelfを組み合わせて環境を構築しています。内容は基礎レベルかもしれませんが、とても勉強になります。

以下は本文からの抜粋です。

開発環境の構築は、アプリを作る上で重要ですが、楽をしたい作業です。 ただし、開発環境構築で手を抜き、チームメンバー間で環境の差異がでてしまった場合、問題があった時の切り分けが困難になってしまいます。 そこで、チームのメンバーが同じ環境を簡単に作れるように、vagrantとchef-soloを使った開発環境の構築についてご紹介したいと思います。

では本文をどうぞ。

Rubyist Magazine - vagrantとchef-soloを使った開発環境の構築

[Rubyist Magazine]

Vagrant入門ガイド

Vagrant入門ガイド

入門Chef Solo - Infrastructure as Code

入門Chef Solo - Infrastructure as Code

【Fluentd翻訳】 forward Input Plugin

Fluentdのドキュメントをザックリ訳してみる。
※個人的に、Fluentdへの興味や、理解を深めるために行っています。公式サイトとは無関係です。正確な内容は公式サイトを参照ください。


forward Input Plugin

フォワード・インプット・プラグイン

in_foward入力プラグインはイベントストリームを受けるTCPソケットをリッスンします。並びに、UDPソケットを受けるためのハートビートをリッスンします。

このプラグインは、これがレコードを検索するはるかに効率的な方法なため、fluent-catコマンドもしくは、クライアント・ライブラリのような、主に他のfluentdからイベントログを受け取るのに用いられます。

構成例

in_forwardは、Fluentdコアに含まれます。特別なインストールを必要としません 。

<source>
  type forward
  port 24224
  bind 0.0.0.0
</source>

構成ファイルの基本的な構造と構文については構成ファイルを見てください。

パラメータ

タイプ(必須)

値はfowardでなければいけません

ポート

リッスンのためのポートです。デフォルト値は24224です。

バインド

リッスンのためのバインドアドレスです。デフォルト値は0.0.0.0(全てのアドレス)です。

プロトコル

このプラグインは、内部プロトコルにMessagePackを使います。MessagePackは、バイナリベースの データシリアラゼーション/デシリアライゼーションライブラリです。以下の構造によるMessagePackのデータストリームはinput_fowardにより受け入れられます。

stream:
  message...

message:
  [tag, time, record]
  or
  [tag, [[time,record], [time,record], ...]]

example:
  ["myapp.access", [1308466941, {"a"=>1}], [1308466942, {"b"=>2}]]

【用語集】 MongoDB/NoSQL

用語 意味
ドキュメント指向 1件分のデータを「ドキュメント」と呼ぶ。データ構造は自由で、データを追加する都度変えることができる。
スキーマレス 事前にテーブルの構造を決めておく必要がない
アドホックなクエリ RDBにおけるSQLのように、受け付けるクエリの種類を事前に定義しておく必要がないこと。
セカンダリインデックス 主キー以外のインデックス
B-tree Balanced Treeの略で、木構造のインデックスツリーにより検索を高速化するアルゴリズム
地理的空間インデックス 位置をベースにしたクエリーのための、二次元の地理空間のインデックス。
レプリケーション 複製を別の記憶装置に作成し、常に内容を同期させる機能
セマンティクス プログラミング言語において、ソースコード中で利用されている変数や文が正しく動作するかを判断する基準のこと
ジャーナリング ファイル処理中に何らかの障害が発生した場合に短時間で復旧できるようなメタデータを残す、ファイル管理手法
スケーリング サーバの処理能力を上げること。スケールアップ・スケールアウト等の方法がある。

【Fluentd翻訳】 Configuration File

Fluentdのドキュメントをザックリ訳してみる。
※個人的に、Fluentdへの興味や、理解を深めるために行っています。公式サイトとは無関係です。正確な内容は公式サイトを参照ください。


Configuration File

構成ファイル

概要

構成ファイルにより、(1)選んでいる入出力プラグイン及び、(2)プラグインのパラメータを指定する ことで、Fluentdの入出力をコントロールできます。ファイルは、Fluentdが正しく動くことを要求します。

構成ファイルの場所

RPM or Deb

構成ファイルは以下の場所を指定されます。

$ sudo vi /etc/td-agent/td-agent.conf

Gem

以下のコマンドで、構成ファイルを作成することができます。SIGHUPシグナルを送り、構成ファイルをリロードします。

$ sudo fluentd --setup /etc/fluent
$ sudo vi /etc/fluent/fluent.conf

ディレクティブのリスト

構成ファイルは、これらのディレクティブから成ります。

  1. sourceディレクティブは入力ソースを決定します。
  2. matchディレクティブは出力先を決定します。
  3. includeディレクティブは他のファイルを含めます。

sourceディレクティブ

sourceディレクティブを用いた望ましい入力プラグインを選び、設定することにより、Fluentdの入力ソースが作動します。Fluentd標準の入力プラグインは、httpfowardを含みます。

## 4224/tcp からイベントを受信
## これはログ・フォワーディングとFluentdのcatコマンドにより用いられます
<source>
  type forward
  port 24224
</source>

## http://this.host:9880/myapp.access?json={"event":"data"}
<source>
  type http
  port 9880
</source>

各々のsourceディレクティブはtypeパラメータを含まなければいけません。typeパラメータは選択された入力プラグインを指定します。

ルーティング

sourceはFluentdのルーティングエンジンにイベントを送ります。イベントは、tag・time・recordの3つのエンティティから成ります。タグは'.'で区切られた文字列(例:myapp.access)で、Fluentdの内部ルーティングエンジンに使われます。

Timeはイベントが起こるUNIX時間です。RecordはJSONオブジェクトです。上記の例において、HTTP入力プラグインは下記のイベントをサブミットします。

## http://this.host:9880/myapp.access?json={"event":"data"} で発生します
tag: myapp.access
time: (現在時刻)
record: {"event":"data"}
プラグイン

プラグインを記述することによって、最初に提供されているものに加え、Fluentdの入力ソースを拡大する ことができます。Fluentdの入力プラグインに関する詳細は、入力プラグイン概要を参照してください。

matchディレクティブ

matchディレクティブを用いた望ましい出力プラグインを選び、設定することにより、Fluentdの出力先が作動します。Fluentd標準の出力プラグインは、filefowardを含みます。

## "myapp.access" イベントタグにマッチし、
## /var/log/fluent/access.%Y-%m-%d に保存します
<match myapp.access>
  type file
  path /var/log/fluent/access
</match>

<match myapp.log.**>
  type file
  format /var/log/fluent/myapp_hourly
  time_slice_format %Y%m%d%H
</match>

各々のmatchディレクティブは、マッチパターンとtypeパラメータを含まなければいけません。 マッチパターンはイベントにフィルタをかけるのに用いられます。タグがパターンにマッチするだけで、イベントは出力に送らます。typeパラメータは出力のプラグインを指定します。

例えば、 myapp.accesslog.** と file で、マッチしたすべてのパターンを、指定されたディレクトリのファイルに送ることができます。

プラグインを記述することによって、最初に提供されているものに加え、Fluentdの出力ソースを拡大する ことができます。Fluentdの出力先に関する詳細は、出力プラグイン概要を参照してください。

マッチパターン

以下のマッチパターンを利用できます。

  • * は1つの要素にマッチします

    • 例えば、a.* はa.bにマッチします。しかし、a や a.b.c にはマッチしません
  • ** は0以上の要素のにマッチします

    • 例えば、 a.** は a、a.b、a.b.c にマッチします
  • {X,Y,Z} は X、Y、Zにマッチします。X、Y、Zがマッチパターンです。

    • 例えば、{a,b} は a と b にマッチします。しかし、 c にはマッチしません
    • これは、* や ** と 一緒に使うことができます。例としては、a.{b,c}.* と a.{b,c.**}です。

includeディレクティブ

includeディレクティブを用いることで、別々の構成ファイルをインポートできます。

## ./config.d ディレクトリの構成ファイルを含めます
include config.d/*.conf


includeディレクティブは、通常のファイルパス・globパターン・http URLをサポートします。

## 絶対パス
include /path/to/config.conf

## もし相対パスを含んでいる場合、ディレクティブは 
## このファイルのディレクトリ名を拡張します
include extra.conf

## globマッチパターン
include config.d/*.conf

## http
include http://example.com/fluent.conf