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
今年読んだ技術書籍（2019年）
今年読んだ技術書籍やレポートなどをざっくりまとめてる．Infrastructure Engineer・Platfomerとして日々の業務に直結するものから1年くらいかけてやっていきたいと思っていることなどを中心に． Kubernetes 業務ではメインにKubernetesを使っているのでKubernetesに関わる書籍は発売されれば大体目を通すようにしている． 今年発売されたので良かったのはProgramming Kubernetes．この本はCRDやOperatorによってKubernetes nativeなアプリケーションを構築することにフォーカスしている．昨年のJapanContainerDaysでのMicroservices Platform on Kubernetes at Mercariでも話したようにKubernetesを使う大きな理由の1つはその拡張性にある．Kubebu
なぜMicroservicesか?
現職においてMonolithアーキテクチャからMicroservicesアーキテクチャへの移行とその基盤の構築に関わって2年近くが経った．未だ道半ばであるがこれまでの経験や日々のインプットをもとにいろいろ書いておこうという気持ちになった．本記事ではそもそもMicroservicesアーキテクチャとは何かを整理し，なぜやるべきか?・なぜ避けるべきかを整理する． Microservices? Microservicesアーキテクチャとは「Single purpose，High cohesion，そしてLoosly Couploedなサービスを組み合わせてシステムを構築する」アーキテクチャ手法である．それぞれの原則をまとめると以下のようになる． Single purpose: 一つのことに集中しておりそれをうまくやること Loose coupling: サービスは依存するサービスについて最小限の
Kubernetesがいかに自動化の考え方を変えたか? | SOTA
先日Japan Container Days v18.12の基調講演で話をさせていただく機会があった．内容としてはMercari のMicroservices Platformの基盤として「なぜ」Kubernetesを選択したか？ついて現状や今後の展望を踏まえて紹介をした． Microservices Platform on Kubernetes at Mercari 「なぜ」の回答としては，CRDやAdmission webhookといった拡張機構を使うことで今後起こりうる様々なWorkloadに特化したPaaSや抽象化レイヤーを書いていけるExtensibilityの高さとそのBuilding BlockとしてのEcosystemの強さを挙げた． このトークのExtensibilityの文脈で話したくて時間がなかったのが「Kubernetesがいかに我々の自動化に対する考え方を変えたか
Kubernetes YAMLの壁
Kubernetes に入門しようする人を躊躇させる原因のひとつは間違いなくYAMLによる設定ファイルだろう．Kubernetesにアプリケーションをデプロイするとき，例えそれがシンプルなサーバーアプリケーションであっても，多くのYAMLファイルを手で記述する必要がある．初心者を慄かせるその大量のYAMLはよくwall of YAML（YAMLの壁）などと揶揄される． 初心者でなくてもKubernetesのYAMLは煩わしい．YAML自体は単なるKubernetes APIへのリクエストボディであり慣れてしまえば実はそんなに難しくない．しかし記述する内容のほとんどがBoilerplateであり何度も書いていると飽き飽きする（実際にはほとんどがコピペだが）．あるアプリケーションの開発環境と本番環境のYAMLファイルをいかに効率的に管理するかについて決定的な方法もない． そもそもKuberne
Service meshとは何か
Microservicesの世界においてService meshは大きなキーワードになった．KubeCon 2017やKubeCon 2018 EUにおいても多くのセッションをService mesh（もしくはその代表格であるIstio）が占めており注目の高さも伺える．もちろんMicroservicesを進めるMercariにおいても導入を検討しており今後重要なコンポーネントの1つになると考えている．本記事ではそもそもなぜService meshという考え方が登場したのか，なぜ重要なのか? その実装としてのIstioとは何で何ができるのか? について簡単にまとめてみる． 参考文献 Service meshを一番理想的な形でサービスに使い始めその考え方を広めたのはLyftだ（と思う）．LyftはIstioのコアのコンポーネントであるEnvoyを開発しそれを用いてService meshを構築
Go言語でファジング
この記事はGo Advent Calendar 2015の21日目の記事です． 今年もGoコミュニティーから多くのツールが登場した．その中でも異彩を放っていたのがGoogleのDynamic testing toolsチームの@dvyukov氏によるgo-fuzzである． go-fuzzはGo関数のファジングを行うツールである．このツールはとても強力で標準パッケージで100以上，golang.org/x/パッケージで40以上，その他を含めると300以上のバグを発見するという実績を残している（cf. Trophies）． 本記事ではこのgo-fuzzの紹介を行う． ファジングとは? Fuzz testing - Wikipedia, the free encyclopedia ソフトウェアの脆弱性検出におけるファジングの活用 「ファジング」とはソフトウェアのテスト手法である．テスト対象となる
Dockerの諸問題とRocket登場の経緯
2014年の後半あたりからDocker，Docker Inc.への批判を多く見かけるようになった（もちろんもともと懸念や嫌悪を表明するひとはいた）．それを象徴する出来事としてCoreOSチームによる新しいコンテナのRuntimeであるRocketのリリースと，オープンなアプリケーションコンテナの仕様の策定を目指したApp Containerプロジェクトの開始があった． CoreOS is building a container runtime, Rocket 批判は，セキュリティであったり，ドキュメントされていない謎の仕様やバグだったり，コミュニティの運営だったり，と多方面にわたる．これらは具体的にどういうことなのか？なぜRocketが必要なのか？は具体的に整理されていないと思う．これらは，今後コンテナ技術を使っていく上で，オーケストレーションとかと同じくらい重要な部分だと思うので，ここ
boot2dockerでのVolume問題が解決しそう
boot2dockerでのVolume問題が解決しそう （追記）Docker 1.3がリリースされた．boot2dockerはデフォルトでVirtualBox Guest Additionsをサポートし，boot2docker-cliはinitのときにホストのディレクトリをboot2docker-vm上にマウントするようになった（Docker 1.3: signed images, process injection, security options, Mac shared directories | Docker Blog）． TL;DR OSXやWindowsでboot2dockerを使う場合に特別な操作をしなくても-vオプション（Volume）が使えるようになる． 背景 OSXやWindowsでboot2dockerを使うひとが最も不満に感じるのは-vオプション（Volume）が使
PaaSエンジニアになった
今まではモバイルアプリ向けのAPIの開発に携わりつつ，CIやデプロイ自動化といったDeveloper Productivity的なことをメインとしていたが，PaaSチームにジョインした．後に自分がどういうことを考えて舵を取ったかを見返すために簡単に今思っていることを綴ってみる． PaaSという選択 “実践Heroku入門”の’はじめに’にしつこく書かれているようにPaaSの大きな目標は「アプリケーション開発者の効率を最大化」することにある．もともとDeveloper Productivity的なことが好きでいろいろやってきたが，その究極的な形がPaaSではないかと思う． PaaSといってもプライベートPaaSだが，素晴らしいアイディアがあり，それを簡単にリリースでき，かつスケールもできる，そういうプラットフォームを社内にもっているのは大きな強みになると思う．どうすれば開発者にとって使いやす
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
わかりやすいREADME.mdを書く
GitHubなどに自分のツールやライブラリを公開するとき，README.mdは重要な役割を担っている．レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている，と言っても過言ではない．実際自分が使う側になったときも，まずREADME.mdを読んで判断していると思う． 成功しているプロジェクトを参考にしつつ，自分が実践していることをまとめておく．ここに書いていることはあくまで（自分の中で）最低限的なものである．プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う． READMEの役割 README.mdには大きく2つの役割がある． プロジェクト，ツールの使い方，インストール方法 プロジェクト，ツールの宣伝 元々READMEは前者の役割しかなかったが，GitHubの仕組み上，後者の役割も徐々に重要になっている． さらに
Dockerとtmuxを連携するdmuxというツールをつくった | SOTA
Docker + tmux = dmux ! dmuxを使うと現在起動中のtmuxのwindowにおいて，新しくpaneをつくりそこでDockerコンテナを起動することができる．使い捨て，かつ高速に起動するクリーンな環境でコマンドを試したり，ツールを入れて使ってみたりなどといったことができる．また，プロセスと途中で止めて，後にそれを再開することもできる． デモ 以下は簡単な動作例． 上のデモでは，以下のことが可能であることを示している． dmux initにより新しいpaneでコンテナを起動し，そこにアタッチする dmux stopでプロセスを停止してpaneを削除する dmux startで停止したプロセスを再開して再びコンテナにアタッチする（for文が途中から再開している） dmux deleteでコンテナとpaneを削除する なぜつくったか Dockerのv0.12.0で追加されたp
Serf 虎の巻
Serf 虎の巻 サービスディスカバリーとオーケストレーション用のツールであるSerfについてまとめた．基本的には公式のHPのGetting Startの抄訳．Vagrantで試験環境を立てて実際に触りつつSerfを使い始められるようにした． 目次 Serfとは Gossip protocolとは 試験環境の準備 クラスタの形成 クラスタからの離脱 イベントハンドラ カスタムイベント カスタムクエリ コマンド一覧 参考 Serfとは Serfはサービスディスカバリーやオーケストレーション，障害検出のためのツール．Vagrantの開発者であるMitchell Hashimoto氏により開発が進められている．SerfはImmutable Infrastructureの文脈で登場してきたツールであり，Immutableなシステムアーキテクチャー，デプロイを実現する上で必須のツールである． Imm
serverspecとdocker-apiでDockerfileをTDD
serverspecとdocker-apiでDockerfileをTDD いくつかDockerfileを書いてきた．今書いているDockerfileは短くてシンプルなものばかりだが，もっと長く複雑化した時に不安になりそうだ．不安を解消するにはテストしかない．さらにテスト駆動的にDockerイメージを開発できたら素敵だ．つまり， テストを書く Dockerイメージを作成して，テストの実行 -> RED Dockerfileの編集 Dockerイメージを作成して，テストの実行 -> GREEN テストを… の流れができるとよい． ということで，RSpecを使ってTDDでDockerfileを開発するというのをやってみた，tcnksm/docker-rspec．今回実現したのは以下． Docker Remote APIでDockerfile特有のコマンド(e.g, CMDやEXPOSE)のRSp
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
