今年読んだ技術書籍（2019年）
今年読んだ技術書籍やレポートなどをざっくりまとめてる．Infrastructure Engineer・Platfomerとして日々の業務に直結するものから1年くらいかけてやっていきたいと思っていることなどを中心に． Kubernetes 業務ではメインにKubernetesを使っているのでKubernetesに関わる書籍は発売されれば大体目を通すようにしている． 今年発売されたので良かったのはProgramming Kubernetes．この本はCRDやOperatorによってKubernetes nativeなアプリケーションを構築することにフォーカスしている．昨年のJapanContainerDaysでのMicroservices Platform on Kubernetes at Mercariでも話したようにKubernetesを使う大きな理由の1つはその拡張性にある．Kubebu
KustomizeでKubernetes YAMLを管理する
Kubernetes YAMLの壁で述べたようにKubernetesのYAML管理はKubernetesユーザにとって長年の課題だ．コミュニティでは様々なツールが議論されてきた．先日SIG-CLIから登場したkustomizeは将来的にkubectlに統合される前提で開発されている+他のツールと比べても非常に筋が良い（と感じている）．本記事ではkustomizeが登場した背景とKustomizeを使って何ができるのかをまとめる． Declarativeであること Declarative ConfigurationはKubernetesの重要な機能の一つだ．KubernetesユーザはKubernetes APIに対してあるべきDesiredな状態を宣言（Declare）することでKubernetesはその状態になるように動き続ける．例えばユーザが「Podを5つ動かす」という状態を宣言すると
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を構築
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
コマンドラインツールを作るときに参考にしている資料 | SOTA
コマンドラインツールについて語るときに僕の語ること - YAPC::Asia Tokyo 2014 コマンドラインツールが好きで昔からつくってきた． 今年のYAPCで，そのコマンドラインツールをつくるときにどういうことを意識して作っているのか？どのような流れで開発しているのか？といったことを語る機会をもらえた． 具体的な内容については，是非トークを聴きに来てもらうとして， スライドをつくるにあったって過去に読んだ資料や，よく参考にしている記事を集め直したので，その一部を参考資料としてまとめておく． UNIXという考え方 UNIXという考え方 Mike GancarzによるUNIXの思想や哲学をまとめた本．古いが全然色あせてない． コマンドラインツールの作り方を書いた本ではないが，これらの思想の上で動くツールはこの思想に準拠して作られるべきだと思う．何度も読んで考え方を染み付かせた． 小さい
KubernetesでGPUを使う
KubernetesでGPUを使う 一般的なWebアプリケーションと比較してMachine Leaning（ML）は複雑なインフラを要求する．Data processingを行う環境やModelのTraining/Validationを行う環境，実際にサービスからModelを利用するためのServingの環境といった複数の異なる環境が必要であり，WorkloadによってはCPUだけではなくGPUも必要になる．これらを効率的に扱うためのインフラを構築・運用するのは容易でなくGoogle and Uber’s Best Practices for Deep Learningにあるようにこれまで培われてきたDevOpsの知見を結集していく必要がある． このような複雑なMLのインフラとしてContainerとKubernetesが利用されることが多くなってきている．特に複数の環境間のPortabi
SREとしてMercariに入社した | SOTA
1月16日よりMercariにてSRE/BSE（Backend System Engineer）として働いてる． これまではとある会社で社内向けのPaaSエンジニアとして働いてきた（ref. PaaSエンジニアになった）．PaaSの目標である「アプリケーション開発者の効率を最大化」を突き詰めながら少人数のチームでいかにScalableなプラットフォームを構築するかに注力してきた．Cloud FoundryやDockerといったインフラの最前線とも言える技術やアーキテクチャに触れ，かつその中で自分の技術的な柱である自動化に取り組むことができたのは非常に刺激的で自分に大きなプラスになった． その一方でPaaSというプラットフォームはその性質上サービスそのものからは中立的になることが避けられない（だからこそScalabilityを実現できるのだが）．よりサービスに近い部分，サービスの成長に直結す
Writing An Interpreter In Goを読んだ
Thorsten Ballによる“Writing An Interpreter In Go”を読んだ． 技術界隈のブログを見ているとたまにSteve Yeggeの「If you don’t know how compilers work, then you don’t know how computers work」という言葉に出会う．その度に学生のときにコンパイラの授業を受けなかったこと後悔し，社会人になって挑戦しようとして挫折したことを思い出して悲しい気持ちになる．@rui314さんのCコンパイラをスクラッチから開発してみたを読んではかっこいいなと思いつつ僕には無理だなあと心が折れていた． どの言語を書いていてもコンパイラ（もしくはInterpreter）は切っても離せないものであり内部の動きがどうなっているかを知っておきたいという欲求はプログラマーなら誰しもあると思う（少なくとも僕に
Systems Performanceを読んだ
Brendan Greggによる“Systems Performance: Enterprise and the Cloud”を読んだ． Linux（Solaris）のパフォーマンスの分野でBrendan Greggという名前を聞いたことがあるひとは多いと思う．名前を知らなくてもが書いているブログやカンファレンスでの発表資料を見かけたことはあると思う．また彼が開発したFlame Graphにお世話になってるひともいるのではないか（ref. GolangでFlame Graphを描く）．とにかくパフォーマンスに関して常に先端にいるひとである． そんな彼がSystems（ここでいうSystemsとはCPUやメモリといったハードウェアとKernelやOSといったソフトウェアを指す）のパフォーマンスについて内部のアーキテクチャーを含め徹底的に解説したのが本書である．面白いに決まってる． 本書の根底
2016年振り返り
最初に今年やったことなどをつらつらと書いてみる． 2月．Dave Cheneyが中心となりGo1.6のRelease Partyが世界各地で開催されることになった（Go 1.6 release party）．東京でもやりたかったのでOrganizerとなりHatenaのオフィスを借りて開催した．8月のGo1.7のリリース時は特に世界規模でやる流れはなかったがフォーマットだけは借りて再びHatenaのオフィスで開催した．この時リリースの概要をまとめたスライドを作ったが@bradfitzがそれを改変して別のMeetupの発表資料に使ってくれた嬉しかった．2017年2月にリリース予定のGo1.8のリリース時は再び世界規模でやるかってのをDaveと話したのでぜひ参加してください． 5月．みんなのGo言語の執筆を主に行っていた．自分はコマンドラインツールに関する章を担当した．今まで発表やブログ記事の
Dockerコンテナ接続パターン (2014年冬)
本記事はDocker Advent Calendar 2014の1日目の記事です． Dockerによるコンテナ化はリソース隔離として素晴らしい技術である．しかし，通常は1つのコンテナに全ての機能を詰め込むようなことはしない．マイクロサービス的にコンテナごとに役割を分け，それらを接続し，協調させ，全体として1つのサービスを作り上げるのが通常の使い方になっている． コンテナ同士の接続と言っても，シングルホスト内ではどうするのか，マルチホストになったときにどうするのかなど様々なパターンが考えられる．Dockerが注目された2014年だけでも，とても多くの手法や考え方が登場している． 僕の観測範囲で全てを追いきれているかは分からないが，現状見られるDockerコンテナの接続パターンを実例と共にまとめておく． なお今回利用するコードは全て以下のレポジトリをcloneして自分で試せるようになっている．
Docker Share
Docker Share Vagrant Shareとngrok Vagrant Share素晴らしい．外部ネットワークのマシンから，ローカルに立てた仮想マシンへのアクセスを実現している． TL;DR ngrokを使えば，Dockerコンテナに対してVagrant Shareと同様のことができる．つまり，Dockerコンテナを外部ネットワークからアクセス可能にすることができる． 以下をやってみた． Apacheコンテナへのアクセス Railsコンテナへのアクセス 準備 OSX上で行った．dockerはboot2dockerで動かす． $ brew install boot2docker 事前にboot2dockerにport forwardingの設定をしておく． $ VBoxManage modifyvm "boot2docker-vm" --natpf1 "tcp-port8080,t
DockerfileのONBUILD| SOTA
DockerfileのONBUILD Docker 0.8においてONBUILDというDockerfile用のコマンドが導入された．0.8ではOSXのdocker clientが脚光を浴びたが，このONBUILDはかなり強力な機能．リリースノートはこちら．ONBUILDの公式ドキュメントはこちら． ONBUILDを使うと，次のビルドで実行するコマンドをイメージに仕込むことができるようになる．つまり，ベースイメージにONBUILDによるコマンドを仕込み，別のDockerfileでそのベースイメージを読み込みビルドした際に，そのコマンドを実行させるということが可能になる．要するに，親DockerfileのDockerfileコマンドを子Dockerfileのビルド時に実行させることができる機能． これは，アプリケーション用のイメージを作るときや，ユーザ特有の設定を組み込んだデーモン用のイメージ
DockerのHost networking機能
DOCKER 0.11 IS THE RELEASE CANDIDATE FOR 1.0 1.0のRCである0.11はいくつかの新機能が追加された．例えば，SELinuxのサポートや，Host networking機能，Link機能でのホスト名，Docker deamonへのpingなど． この中でもHost networking機能がなかなか面白いので，実際に手を動かして検証してみた．事前知識として“Dockerのネットワークの基礎”も書きました．ネットワークに関して不安があるひとが先にみると，Host Networing機能の利点／欠点もわかりやすいと思います． TL;DR Host networking機能を使うと，異なるホスト間のコンテナの連携がちょっぴりやりやすくなる．SerfやConsulのようなサービスディスカバリーツールとの相性も良さそう． まだ出たばかりの機能で実際に使っ
logspoutでDockerコンテナのログの集約・ルーティング
logspoutでDockerコンテナのログの集約・ルーティング progrium/logspout logspoutは，ホスト内で動かした全てのDockerコンテナの出力を集約して，好きなところに飛ばす（ルーティングする）ためのツール．開発者はDokkのJeff Lindsay． 以下の2つの特徴がある コンテナとして起動（ステートレス） HTTP APIによるルーティングの設定 ログを貯めて管理したり，検索するといったことはできない．コンテナのログをリアルタイムで好きなところに飛ばすだけ． これだけだが，Dockerのログの問題をいい感じに解決してくれそう． Dockerのログのしくみ まず，簡単にDockerのログのしくみを説明する． 現時点（2014年5月）でDockerはコンテナ内で吐き出されたstdout/stderrを取得することができる．コンテナのプロセスがstdoutとs
Dockerの再起動オプション
Dockerの再起動オプション Announcing Docker 1.2.0 | Docker Blog v1.2でもいくつかの面白い機能が追加された．例えば，今まで--privilegedオプションを使うと全権限を与えてしまっていたが--cap-addや--cap-dropオプションでそれを制限できるようになったり，–deviceオプションで利用したいデバイスを指定できたり，コンテナ起動時に/etc/hostsを編集できたり…など． 中でも再起動オプションが良さげなので，実際に触ってみた．docker runを実行するときに--restartオプションに以下を指定するとコンテナの再起動の挙動を変更できる: no - 再起動しない（デフォルト） on-failure - 終了ステータスがnon-zeroの場合に再起動する on-failure:X - 終了ステータスがnon-zeroの場
Hashicorp Ottoを読む
Hashicorpから2015年秋の新作が2つ登場した． Otto - HashiCorp Nomad - HashiCorp Ottoがなかなか面白そうなのでコードを追いつつ，Ottoとは何か? なぜ必要になったのか? どのように動作するのか? を簡単にまとめてみる． バージョンは 0.1.0 を対象にしている（イニシャルインプレッションである） Ottoとは何か? 公式はVagrantの後継と表現されている．が，それはローカル開発環境の構築も担っているという意味で後継であり，自分なりの言葉で表現してみると「OttoはHashicorpの各ツールを抽象化し開発環境の構築からインフラの整備，デプロイまでを一手に担うツール」である．ちなみにOttoという名前の由来はAutomationと語感が似ているからかつ元々そういう名前のbotがいたからとのこと． なぜOttoか? なぜVagrantで
CoreOSに入門した
CoreOS is Linux for Massive Server Deployments · CoreOS CoreOS + Docker Meetup Tokyo #1に参加してCoreOSにめっちゃ感動したので，CoreOSに入門していろいろ触ってみた． まず，CoreOSの概要とそれを支える技術について説明する．次に実際にDigitalOcenan上にVagrantを使って実際にCoreOSクラスタを立てて，CoreOSで遊ぶ方法について書く． CoreOSとは何か CoreOSは，GoogleやFacebook，Twitterといった企業が実現している柔軟かつスケーラブル，耐障害性の高いインフラの構築を目的としたLinuxディストリビューションである．軽量かつ使い捨てを前提にしており，クラウドなアーキテクチャのベストプラクティスを取り入れている．CoreOSの特徴は大きく4つ挙
Dockerの諸問題とRocket登場の経緯
2014年の後半あたりからDocker，Docker Inc.への批判を多く見かけるようになった（もちろんもともと懸念や嫌悪を表明するひとはいた）．それを象徴する出来事としてCoreOSチームによる新しいコンテナのRuntimeであるRocketのリリースと，オープンなアプリケーションコンテナの仕様の策定を目指したApp Containerプロジェクトの開始があった． CoreOS is building a container runtime, Rocket 批判は，セキュリティであったり，ドキュメントされていない謎の仕様やバグだったり，コミュニティの運営だったり，と多方面にわたる．これらは具体的にどういうことなのか？なぜRocketが必要なのか？は具体的に整理されていないと思う．これらは，今後コンテナ技術を使っていく上で，オーケストレーションとかと同じくらい重要な部分だと思うので，ここ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Taichi Nakashima