Zero Touch Productionとは何か
GoogleのSREとSecurityによるBuilding Secure Reliable Systems という本の中で「Zero Touch Production (ZTP) 」という考え方が紹介されていた．これはインフラの権限管理やインフラの構築そのものの指針となる概念であり，自分がそうあるべきだとずっと思ってきた考え方でもある．これはどのような考え方なのか?をこれまでの歴史を踏まえて具体的なツールや事例とともにまとめておく． Zero Touch Production Building Secure Reliable Systems においてZero Touch Production (ZTP) は以下のように定義されている． The SRE organization at Google is working to build upon the concept of least
Team Topologiesを読んだ
https://teamtopologies.com/ DevOps consultantとして技術と組織の両面からDevOpsの支援を行なってるMatthew SkeltonとManuel Paisによる本．Consultant本は大体中身が薄く感じることが多くなり手に取ることは少なくなってきたが，各所で見かけたり，2人によるDevOpsにおけるチームのあり方のパターンをまとめたWhat Team Structure is Right for DevOps to Flourish?が良かったので読んでみた． 本書はDevOpsの視点から高速なDeliveryを実現するためにどのようなチームや組織を作るべきかについてまとめている．個人ではなくチームをDeliveryの最も重要な単位と考え（Team first-thinking），チームが最大限にパフォーマンスを発揮するために，チームの人数
Go言語でテストしやすいコマンドラインツールをつくる
本記事はGo Advent Calendar 2014の18日目の記事です． Go言語は，クロスコンパイルや配布のしやすさからコマンドラインツールの作成に採用されることが多い．自分もGo言語でいくつかのコマンドラインツールを作成してきた．例えば，GitHub Releaseへのツールのアップロードを簡単に行うghrというコマンドラインツールを開発をしている． コマンドラインツールをつくるときもテストは重要である．Go言語では標準テストパッケージだけで十分なテストを書くことができる．しかし，コマンドラインツールは標準出力や標準入力といったI/O処理が多く発生する．そのテスト，例えばある引数を受けたらこの出力を返し，この終了ステータスで終了するといったテストは，ちゃんとした手法が確立されているわけではなく，迷うことが多い（少なくとも自分は結構悩んだ）． 本記事では，いくつかのOSSツール（得に
Kubernetes上でgRPCサービスを動かす
Kubernetes上でgRPCサービスを動かすことが多くなってきている．が適切にロードバランスをする，リクエストを落とさずサービスをデプロイするためにいくつか注意することがあるので簡単にまとめておく． 以下の2つを意識する． Kubernetes ServiceはL4のLoad balancer（LB）であること gRPCはコネクションを使いまわすこと KubernetesのPodは死んだり作られたりを繰り返す．KubernetesのPodにはそれぞれ内部IPがアサインされるが，このIPはPodが新しく作成される度に変わる．IPが変わってもPodにアクセスするためにKubernetesではServiceをつくる．ServiceはPodを抽象化しVirtual IP（VIP）を提供する．VIPを使うことでPodのIPが変わってもPodにアクセスすることができる． VIPはNetwork i
Go言語と暗号技術（AESからTLS）
最近マスタリングTCP/IP SSL/TLS編や暗号技術入門を読んでいた．理解を深めるためにGo言語で標準のcryptoパッケージを触り/実装を読みながら読んだ． cryptoパッケージは他の標準パッケージと同様に素晴らしい．Go言語にはどのような暗号化手法が実装されているのか実例を含めてざっとまとめる．なお本文に書ききれなかったものを含め全ての実装例はtcnksm/go-cryptoにある． 共通鍵暗号 まずは共通鍵暗号をみる．共通鍵暗号は暗号化と復号化に同じ鍵を用いる暗号化方式である．共通鍵暗号はブロック暗号とストリーム暗号の2種類に分けることができる．ブロック暗号は特定の長さ単位で暗号化を行う方式であり，ストリーム暗号はデータの流れを順次処理していく方式である． Go言語にはブロック暗号としてDES（Data Encryption Standard），DESを繰り返すtriple-D
Kubernetes YAMLの壁
Kubernetes に入門しようする人を躊躇させる原因のひとつは間違いなくYAMLによる設定ファイルだろう．Kubernetesにアプリケーションをデプロイするとき，例えそれがシンプルなサーバーアプリケーションであっても，多くのYAMLファイルを手で記述する必要がある．初心者を慄かせるその大量のYAMLはよくwall of YAML（YAMLの壁）などと揶揄される． 初心者でなくてもKubernetesのYAMLは煩わしい．YAML自体は単なるKubernetes APIへのリクエストボディであり慣れてしまえば実はそんなに難しくない．しかし記述する内容のほとんどがBoilerplateであり何度も書いていると飽き飽きする（実際にはほとんどがコピペだが）．あるアプリケーションの開発環境と本番環境のYAMLファイルをいかに効率的に管理するかについて決定的な方法もない． そもそもKuberne
sync.ErrGroupで複数のgoroutineを制御する
Golangの並行処理は強力である一方で同期処理を慎重に実装する必要がある．“Go 言語における並行処理の構築部材”にまとめられているようにGolangは様々な方法でそれを実装することができる．実現したいタスクに合わせてこれらを適切に選択する必要がある． この同期処理の機構として新たにgolang.org/x/sync/errgroupというパッケージが登場した．実際に自分のツールで使ってみて便利だったので簡単に紹介する． 使いどころ 時間のかかる1つのタスクを複数のサブタスクとして並行実行しそれらが全て終了するのを待ち合わせる処理（Latch）を書きたい場合にerrgroupは使える．その中でも「1つでもサブタスクでエラーが発生した場合に他のサブタスクを全てを終了しエラーを返したい」（複数のサブタスクが全て正常に終了して初めて1つの処理として完結する）場合が主な使いどころである． 実例
GolangでAPI Clientを実装する
特定のAPIを利用するコマンドラインツールやサービスを書く場合はClientパッケージ（SDKと呼ばれることも多いが本記事ではClientと呼ぶ）を使うことが多いと思う．広く使われているサービスのAPIであれば大抵はオフィシャルにClientパッケージが提供されている．例えば以下のようなものが挙げられる． https://github.com/aws/aws-sdk-go https://github.com/Azure/azure-sdk-for-go https://github.com/PagerDuty/go-pagerduty https://github.com/hashicorp/atlas-go 特別使いにくい場合を除けば再実装は避けオフィシャルに提供されているものを使ってしまえばよいと思う（まともなものなら互換性などをちゃんと考慮してくれるはずなので）．一方で小さなサービ
Go1.7のcontextパッケージ
Go1.7ではgolang.org/x/net/contextがcontextパッケージとして標準パッケージに仲間入りする．そしていくつかの標準パッケージではcontextパッケージを使ったメソッド/関数も新たに登場する．contextパッケージは今後さらに重要な，Gopherは普通に扱うべき，パッケージになると考えられる．本記事ではそもそもcontextパッケージとは何か？なぜ登場したのか？なぜ重要なのか？どのように使うべきか？についてまとめる． contextパッケージが初めて紹介されたのは2014年のThe Go Blogの記事 “Go Concurrency Patterns: Context”である．この記事ではなぜGoogleがcontextパッケージを開発したのか，どのように使うのか具体的な検索タスクを例に解説されている．まだ読んだことがない人はそちらを先に読むと良い． co
GolangのGCを追う
Go1.5とGo1.6でGoのGCのレイテンシが大きく改善された．この変更について「ちゃんと」理解するため，アルゴリズムレベルでGoのGCについて追ってみた． まずGoのGCの現状をパフォーマンス（レイテンシ）の観点からまとめる．次に具体的なアルゴリズムについて，そして最後に実際の現場でのチューニングはどうすれば良いのかについて解説する． GoのGCの今 最初にGoのGCの最近の流れ（2016年5月まで）をまとめる． Go1.4までは単純なStop The World（STW）GCが実装されていたがGo1.5からは新たなGCアルゴリズムが導入された．導入の際に設定された数値目標は大きなヒープサイズにおいてもレイテンシを10ms以下に抑えることであった．Go1.5で新たなアルゴリムが実装されGo1.6で最適化が行われた． 以下は公開されているベンチマーク．まずはGo1.5を見る． Gophe
GolangでFlame Graphを描く
アプリケーションのパフォーマンス問題の解決やチューニングで大切なのは問題のコアやボトルネックに最短パスで到達することである． 基本的なパフォーマンス分析の入り口はアプリケーションのスレッドがon-CPUで時間を消費しているかoff-CPUで時間を消費しているかを理解するところから始まる．on-CPUの場合はそれがuserモードかkernelモードかを特定し，さらにCPUプロファイリングによってどのcode pathがCPUを消費しているのかの分析に向かう．off-CPUの場合はI/OやLock，pagingといった問題の分析に向かう． Flame Graphはon-CPUでのパフォーマンスの問題が発覚した時に行うCPUプロファイリングを助ける．どのcode pathがボトルネックになっているのかを1つのグラフ上で理解できる．本記事ではFlame Graphとは何か? なぜ必要なのか? を解
Golangのエラー処理とpkg/errors
GoConでは毎回エラー処理について面白い知見が得られる．Go Conference 2014 autumn においては（実際のトークではないが）居酒屋にて@JxckさんがRob Pike氏から以下のようなテクニックを紹介してもらっていた． Errors are values - The Go Blog Golang Error Handling lesson by Rob Pike これはWrite（やRead）のエラー処理が複数続く場合にerrWriter を定義して複数のエラー処理を一箇所にまとめてコードをすっきりとさせるテクニックであった． そして今回の Go Conference 2016 spring のkeynoteにおいてもDave Cheney氏から（僕にとっては）新たなエラー処理テクニックが紹介された． Gocon Spring 2016 実際に使ってみて/コードを読ん
Go言語のDependency/Vendoringの問題と今後．gbあるいはGo1.5
Go言語のDependency/Vendoringは長く批判の的になってきた（cf. “0x74696d | go get considered harmful”, HN）．Go1.5からは実験的にVendoringの機能が入り，サードパーティからはDave Chaney氏を中心としてgbというプロジェクベースのビルドツールが登場している．なぜこれらのリリースやツールが登場したのか?それらはどのように問題を解決しようとしているのか?をつらつらと書いてみる． Dependencyの問題 最初にGo言語におけるDependecy（依存解決）の問題についてまとめる．Go言語のDependencyで問題なのはビルドの再現性が保証できないこと．この原因はimport文にある． Go言語で外部パッケージを利用したいときはimport文を使ってソースコード内にそれを記述する．このimport文は2通りの
OSXでboot2dockerを使う
OSXでboot2dockerを使う 公式のDocker Client for OSXがリリースされて，OSXでDockerを使うのはちょっと楽になった．ただ，Docker自体はVritualBoxなどのVM上で実行する必要があり，VMの起動には時間がかかるので寿命が縮む．boot2dockerを使うと，他と比べて断然早くVMを起動でき，すぐにDockerが使える． boot2dockerというのは，Tiny Core LinuxをベースにしたDocker実行のみに特化した軽量版のLinuxディストリビューション．特化しているため起動はとても速い．前からあるが，VirtualBoxをわざわざ起動する必要があったりなど，ちょっと使うのはめんどくさかった． Vagrantの作者であるMitchell HashimotoさんがPackerを使ってboot2dockerのVagrant Boxを作
Go言語でプラグイン機構をつくる
dullgiulio/pingo Go言語でのプラグイン機構の提供方法は実装者の好みによると思う（cf. fluentd の go 実装におけるプラグイン構想）．Go言語はクロスコンパイルも含めビルドは楽なのでプラグインを含めて再ビルドでも良いと思う．が，使う人がみなGo言語の環境を準備しているとも限らないし，使い始めてもらう障壁はなるべく下げたい．プラグインのバイナリだけを持ってこればすぐに使えるという機構は魅力的だと思う． Go言語によるプラグイン機構はHashicorpの一連のプロダクトやCloudFoundryのCLIなどが既に提供していてかっこいい．net/rpcを使っているのは見ていてこれを自分で1から実装するのは面倒だなと思っていた． dullgiulio/pingoを使うと実装の面倒な部分を受け持ってくれて気軽にプラグイン機構を作れる． 使い方 サンプルに従ってプラグインを
Go言語のCLIツールのpanicをラップしてクラッシュレポートをつくる
mitchellh/panicwrap Go言語でpanicが発生したらどうしようもない．普通はちゃんとテストをしてそもそもpanicが発生しないようにする（もしくはトップレベルでrecoverする）．しかし，クロスコンパイルして様々な環境に配布することを，もしくはユーザが作者が思ってもいない使いかたをすることを考慮すると，すべてを作者の想像力の範疇のテストでカバーし，panicをゼロにできるとは限らない． panicが発生した場合，ユーザからすると何が起こったか分からない（Go言語を使ったことがあるユーザなら「あの表示」を見て，panicが起こったことがわかるかもしれない）．適切なエラーメッセージを表示できると良い．開発者からすると，そのpanicの詳しい発生状況を基に修正を行い，新たなテストケースを追加して二度とそのバグが発生しないようにしておきたい． mitchellh/panicw
AppcとCoreOS/Rocket
Dockerの諸問題とRocket登場の経緯 Rocketはリリースした直後にちょっと触ってそのまま放置していた．App containerの一連のツールとRocketが現状どんな感じかをざっと触ってみる．まだまだ全然使えると思えないが今後差分だけ追えるようにしておく． なお，今回試した一連のツールをすぐに試せるVagrantfileをつくったので触ってみたいひとはどうぞ． https://github.com/tcnksm/vagrant-appc 概要 App Container SpecやRocketが登場の経緯は前回書いたのでここでは省略し，これらは一体何なのかを簡単に書いておく． まず，App Container（appc）Specはコンテナで動くアプリケーションの"仕様"である．なぜ仕様が必要かというと，コンテナという概念は今まで存在したが曖昧なものだったため．namespac
Dockerの諸問題とRocket登場の経緯
2014年の後半あたりからDocker，Docker Inc.への批判を多く見かけるようになった（もちろんもともと懸念や嫌悪を表明するひとはいた）．それを象徴する出来事としてCoreOSチームによる新しいコンテナのRuntimeであるRocketのリリースと，オープンなアプリケーションコンテナの仕様の策定を目指したApp Containerプロジェクトの開始があった． CoreOS is building a container runtime, Rocket 批判は，セキュリティであったり，ドキュメントされていない謎の仕様やバグだったり，コミュニティの運営だったり，と多方面にわたる．これらは具体的にどういうことなのか？なぜRocketが必要なのか？は具体的に整理されていないと思う．これらは，今後コンテナ技術を使っていく上で，オーケストレーションとかと同じくらい重要な部分だと思うので，ここ
Werckerの仕組み，独自のboxとstepのつくりかた
Werckerの仕組み，独自のboxとstepのつくりかた WerckerはTravisCIやDrone.ioのようなCI-as-a-Serviceのひとつ．GitHubへのコードのPushをフックしてアプリケーションのテスト，ビルド，デプロイを行うことができる． Werckerは，TravisCIのように，レポジトリのルートにwercker.ymlを準備し，そこに記述された実行環境と実行コマンドをもとにテスト/ビルドを走らせる． Werckerには，その実行環境をbox，実行コマンド（の集合）をstepとして自作し，あらかじめWercker Directoryに登録しておくことで，様々なテストからそれらを呼び出して使うという仕組みがある．実際，Werkcerで標準とされているboxやstepも同様の仕組みで作成されている（wercker · GitHub）． 今回，WerkcerでのGo
複数プロジェクトを抱えるチームでのデプロイ自動化
複数プロジェクトを抱えるチームでのデプロイ自動化 1つのチームで，10以上のプロジェクト，コードベースを抱える場合にどのようにデプロイの自動化を進めたか，工夫したこと，考慮したことなどをまとめておく． デプロイツールには，Python製のfabricを採用しているが，他のツールでも同様のことはできそう．なお，fabricの基本的な使い方などは既にインターネット上に良い記事がたくさんあるので書かない（最後の参考の項を見てください）． fabricの選択 シェルスクリプトとCapistranoを考慮した． まず，シェルスクリプトは人によって書き方が違うため，統一が難しくメンテナンスコストも高い．また共通化も難しい． 次に，Capistranoは，裏でやってくれることが多く，学習コストも高い．プロジェクトによってはかなり特殊な環境へのデプロイも抱えているため，Capistranoの前提から外れる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
