ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

「Effective DevOps」を読んだ

はじめに

読んだ。

Effective DevOps ―4本柱による持続可能な組織文化の育て方

Effective DevOps ―4本柱による持続可能な組織文化の育て方

DevOpsというワードの定義が曖昧なまま数年経過し、各組織ごとに理解したDevOpsで"なんとなく"やっている。僕としてはもうDevOpsという言葉を使うのもちょっと避けていたぐらい。「今時はデブオプだー」っていう声を聴くと耳を塞ぎたくなる。

とはいえ、じゃあ自分はDevOpsを正確に理解しているのか?そもそも正確な理解なんてあるのか?自分なりの答えはあるのか?と言われるとNoで、本書はDevOpsの定義について、人間的なアプローチで迫った最初の本だと思う。

実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである(監訳者まえがきより)とあるように、DevOpsは単に役割の変化だとか、ツールの導入だとか、その点だけ見ても成功しないことは多くのひとが見てきた光景だと思う。(僕もそうだ)

組織論に興味を持っている僕に、ぴったりの一冊だった。内容を復習していく。

第I部 DevOpsとは何か

DevOpsとは何か。DevOpsとはものの考え方であり、仕事の進め方である。(p3)とある。ツールではない。組織体系でもない。ものの考え方であり、それを推進するために文化を育てなければならない。だから文化的、組織的な面に徹底して着目しているのが本書である。

第I部で重要な点は以下の2点だと思う。

  1. DevOpsはチームであるという誤解

なんども言うが、本書の主張は一貫している。DevOpsは「DevOpsチーム」なるものを作っても解決しない。DevOpsは考え方のフレームワークであり、組織全体に浸透する文化となるべきである。

2 .DevOpsには「正しい方法」などない

組織文化となりうるものであるので、唯一無二の組織がない以上、DevOpsも唯一の正解はない。

この基本的な考え方を抑えた上で、DevOpsに効果的な4本の柱を見ていこう。

第II部 コラボレーション

コラボレーション、ひととひとがうまく開発を行うための仕組みで、以下のような例がある。

  • 非同期でのコードレビュー
  • ドキュメント作成
  • 問題の更新とバグレポート
  • その週に進んだ内容のデモ
  • 定期的な状況報告
  • ペア作業

チームを分析すると、賢いチームには以下の特徴があるという。

  • コミュニケーション
  • 平等な参加
  • 心の理論

コラボレーションはひととひとがうまくやるためのものだ。組織には様々な経歴を持ったひとがいる。そしてチームとしての目標がある一方で、個人としてもそれぞれに違う目標を持っていることを理解する必要がある。「ただの仕事」と割り切ってる人がいる一方で、自分のキャリアに重要なポジションと理解している人もいるということだ。

僕が重要だと思うのは、7.3.4 認知スタイルだ。結局、最終的に組織やコミュニケーションの問題はここに行き着くような気がする。

  • 内向、外向、両向 ... 人が自分の中のバッテリーをどのようにして「充電」するか
  • 質問と推測 ... 人にものを頼む時の態度の2タイプ
  • スターターとフィニッシャー ... 新しい仕事をスタートするか、きっちり問題を解決して終わらせるか
  • 分析的思考、批判的思考、水平思考 ... 事実と根拠から問題を分析する / 間接的に情報を集めて検討する / 情報から正当性を分析、熟考する
  • 純粋主義者と現実主義者 ... 問題解決のために絶対的に最高な技術を使おうとする / コストを天平にたて実現性を重視する

いろんな認知スタイルがあることを知り、考慮しなければならない。

その後もマインドセットや評価、フィードバック、コミュニケーションの形と、組織論が続く。コミュにケーションツールを並べてみる。

  • 電子メール
  • 臨時の会議
  • チャット
  • 正式な会議
  • Twitterなどのマイクロブログ
  • GitHubのプルリクエス
  • 付箋紙のメモ
  • PagerDutyページ
  • nahiosアラート
  • 書籍またはブログ
  • 画像、グラフ

これらを「即時性」「オーディエンスへの浸透度」「受け手の負担」「コンテキスト」「構成の緻密さ」という観点で表にしている。

僕自身、ひとにあったツールを採用すべきであるという考えをしたことがある。口頭のコミュニケーションは苦手でもチャットだとしっかり受け取ってくれるとか、その逆があったりするので、ツールの特性には常に目を光らせるべきだと思う。

人々がうまくやるためには、信頼と共感が必要である。そもそもDevOpsの起源からして、2つの異なるチームを対話させるところからはじまった。異なる文化、経歴の人々が、コミュニケーションを通じて、信頼・共感していく、これがDevOpsの本質だというのが、本書の主張だと思う。

8章で好きな言葉を書いておく。

優れたリーダーは、自分自身や少数の「ロックスター」だけを重視してはいけない。優れたリーダーとは、周りにいるすべての人たちから最良のものを引き出せる人のことである。(p91)

そんなリーダーになりたいですね。

第III部 アフィニティ

アフィニティは、結びつき、個人間でもそうだし、チーム間の結びつきの強さのことを話題にしていると受けとりました。結びつきにはコミュニケーションが必須なので、重複するような気もしますが。

チーム間で仲が悪いとか、あのチームは自分のチームの利益だけ考えて他のチームに対して排他的だとか、ありますよね。悲しいですけど。

チームで行う仕事として、以下を例にあげています。

  • リアクション
  • 計画
  • 手続き
  • 不安への対処
  • 問題解決
  • 人間関係★

6つめの人間関係こそがアフィニティに必要だが、計測が難しい。

9.3.3 チーム内の個人的な結びつき9.3.4 チームの文化で語られていること。確かに、どのチームにも文化と呼べるような、行動指針をほのかに感じることができる。そのチームにとって正しい文化を伝えることは、コミュニケーションをしたり、普段の仕事を通じてぼんやり浸透していくものだろう。ただ、それでも明に言葉にして伝えることが大切で、リーダーの役目なんだろうなと思った。チームに価値観を日頃から伝えていれば新しいメンバーが入ってきたときも戸惑うこともないだろう。

また、チーム間のアフィニティを強くすることも必要。企業として共通の目標を見せつつ、各チームの目標を、競合しないように決めなければならない。この点はあまり言及されていなかった。多分、大事なのは各チームの目標を、各チームが知っていることであり、それこそがアフィニティを強くするんだと思った。

第IV部 ツール

ここではDevOpsでよくある「ツールをいれればいいんでしょ」に対する誤解を丁寧に説いている。

`「ツールに大した意味はない」という主張には、2つの意味がある。

  • ツールを導入していることは、devops文化が定着していることの十分条件にはならない
  • ツールでは問題のある文化を修正できない。ツールは環境の既存の状況を暴き悪化させる(p181)`

よくある話だが、ツールを採用するプロセスをチームで一貫させ、共有しておくことが大事だと思う。そこさえ一致しておけば、採用後に大きな問題にはなりにくいと思う。

僕自身、チームにCI/CDプロセスを、ツール含めて導入したことがある。それはチームにツールを導入するはじめてのことだったから、手探りだった。

結局、devopsも同じだが、「ツールを導入したからといって一晩で問題が解決することはない」ということを理解する必要があると思う。

ツールが浸透するまでは時間がかかる。ツールの選定方法だってたくさんある。それを繰り返し、フィードバックして、チームに馴染むツールを見つけることを繰り返す。繰り返すがツール(技術)はツールでしかない。それで本当に問題解決したのか。使うひとたちが幸せになったのか。その観点は絶対に忘れてはならないと思う。

この点も、冒頭のdevopsが目指すものと同じ話ですね。ツールも、唯一の正解はない。組織にあったものを探していくしかない。

第Ⅴ部 スケーリング

スケーリングって何だろう?って思った。ビジネス規模拡大に対して組織・チームを増やすことだろうか?単に「スケールアウト」という言葉で言われる拡大だけを言うのではなく、何らかの問題が発生したときに「変化」させることを言っているようである。方向転換のコツ、と言ったところ。

スケーリングは次のことを意味する場合がある(p220)

  • 顧客ベースの拡大
  • 収益の拡大
  • 需要に合わせたプロジェクトやチームの拡張
  • システムに割り振る人の割合や金額の維持、改善
  • 競合他社よりも早い成長

組織を大きくしたり小さくしたりするときに発生する採用、関係会社の利用、報酬について書かれている。本当にバリエーションに富んだ本だと思う。

SRE的な考えに習い、ビジネスのスケールアップに対して、人材をスケールしなくて済む仕組み作りが大事だと思う。とはいえ、人手が必要で、その人で集めにいまいろんな会社が苦労しているのもわかる。いまいま自分は採用について関わる立場ではないのでおいておく。

強い意見と弱い執着(p241)は大切だと思った。特定の立場や何らかの意見を持つことに注力するが、現在の意見と違う結論に達したら柔軟に変えられることを言う。`

第Ⅵ部 devops文化への架け橋

最後に、これまでの4本柱をどう組織にインストールするか、それにはストーリーから学ぶことが重要だという。

価値観を伝える上で、禁止事項を明示するというのはいいと思った。暗黙の禁止事項も多い中、禁止事項を明確にすることは、禁止事項を行ってしまったことによる被害を抑えるとともに、文化/価値観の伝達にも役立つ。

また、神話・儀式も面白いと思った。これは神話では?これは儀式なんだよね、とまずは自覚することに気を配るべきだと思った。

おわりに

用語説明、事例を交えながらの各要素の説明、そしてアンチパターンの紹介と、本当に親切で、多彩な要素を、それでもコンパクトに盛り込んだ、良い本だった。自分自身がいるフェーズによって響くポイントが違うと思う。今回ももちろんすべてを吸収しきったわけではない。それでも「DevOpsに唯一の正解はない」し、「組織を作る人間同士がうまくやる文化作り」が重要であることはわかった。

結局、文化とは、結果であり、人と人の、チームとチームの、コミュニケーションの積み重ねが文化なんだと思う。だから文化を作る、という言葉には少し違和感がある。こういう文化となるよう、小さな行動を、今からはじめてみよう、そういう結論なんだと思う。

また今とは違うポジションになったときに読み返したいと思う一冊。

「MBA組織と人材マネジメント」を読んだ

はじめに

読んだ。

グロービス MBA組織と人材マネジメント

グロービス MBA組織と人材マネジメント

きっかけ

転職活動中、HeartBeatsの高村さんと、HB主催のイベントで再開しました。再開、というのは、僕はJuly Tech Festaで彼の発表を一番前の席で聞いていたのでした。

speakerdeck.com

結構僕にとって衝撃的で、刺激的な発表だったんですね。

まず、エンジニアがMBAを(この時点ではよくわかってない)取りに行ったこともびっくりだし、かなり若い頃から(野球の挫折を通じて)自分が何が得意で、何が興味あるかを見つめている点が、ほわ〜〜〜かなわないな〜〜〜と思いながら聴いていた記憶があります。

今でこそ、就職活動を通じて自覚していますが、僕も「ITエンジニアリングと組織マネジメントに対するモチベーションは高い」(スライド11p)わけで、完全に一致していました。僕自身、この頃は特にマネジメントを実践でしたこともなく、なんとなく得意っぽい?好きっぽい?ぐらいでした。それでも、ガツンと、似たようなひとがいるなぁと思ったことをよく覚えています。

これはその後お会いしたときに高村さんと話したんですが、「何事も原理原則が大事」とおっしゃっていて、リーダーシップとかマネジメントとか、そういうよく言われる言葉や役職で必要なスキルは、経営大学院では「組織行動論」「人的資源管理」という分野できちんと体系化されているということを僕ははじめて知りました。知ったというより、自覚したという感じ。

で、普通に教科書でてるので読んでみたらいいですよ、ということで読んでみました。

感想

でここまできっかけを述べてなんですが「う〜〜〜〜ん何か違うな〜〜〜〜」って感じでした。(笑)というのも、読んでいて、確かにその通りなことがたんたんと書いてあるんですが、きれいな教科書なんですよね。。。僕は何を期待してたんでしょうか?

その自分の期待が何かを探るためにも内容を自分なりに咀嚼してみます。

内容

MBA(経営大学院)の一科目としての「組織と人材マネジメント」についてです。

経営をするには、必ず人からはじまります。まえがきのしょっぱなが「組織の経営は人に始まり、人に終わる。」です。「協調システムである組織を動かすために、人材をどのようにマネジメントすべきかということ」がテーマ。以下も同じくまえがきより引用。

  • 組織の意志としての戦略を組織メンバー全員が共有化すること
  • よき組織文化を共有し継承していくこと
  • 環境変化に応じて働く仕組み(組織構造)を設計すること
  • 人間として豊かな生活を送ることができ、かつ多くの社員を動機づけられるような人事制度を設計すること
  • 組織と人材のマネジメントは人事部だけの仕事ではなく、すべてのマネジャーの仕事であることを認識し実戦すること

うん。なんというかですね、今ここまで書いてわかりました。ぼく経営やったことないから全然ピンとこないんですわ。。。(当たり前だ)

本書は7章構成。おおざっぱにサマリ(メモ)を書くと、

  1. 組織の目的 … 共通の目的を達成するためにはひととひとが協調する必要があり、行動指針(戦略)が必要である
  2. 組織文化 … 組織文化はメンバーの価値判断に関係するためコントロールできると効果は大きい
    • 文化によい悪いはないが、好ましい文化の例
      1. 多様性を奨励する
      2. 変化をつくる
      3. 社員を大切にする
  3. 組織構造 … 組織は分業システムであるため、分業の強みを発揮できるかどうかを決めるのが組織構造である
  4. 人事システム … 組織でひとが活躍できるために、採用から退職まで関わる人事システムについて
    • 採用・配置システム
    • 評価システム
    • 報酬システム
    • 能力開発システム
  5. 多様性のマネジメント … 昨今多様性は無視できなくなり、重要性を増してきている
    • 主にグローバルカンパニーでの事例が多かった
  6. 組織と人材を動かす仕組み … 人事システムを作ったあとの運用について
  7. 実践例

序章で書かれている通り、「組織と人材マネジメント」の中には2つの要素があり

  1. 「企業の仕組み」で動かす組織と人材のマネジメント
  2. 「個人の取り組み」で動かす組織行動学

明確に二分できるわけでもないようですが、大きく分けたうちだと僕は後者に興味があります。もちろん前者にも興味はあるといえばあるんですが、実戦機会がないため、ピンとこなかったようです。

まとめ

自分自身の関心は「ひと」にあります。とにかく「ひと」が好きで、「ひと」と話すのが好きです。利他主義で、みんなでハッピーになりたいし、成果も出したいと思っています。

本書の内容は、"経営者"が人事制度あるいは組織文化を変化させることで組織の生産性を最大化させるための原理が書かれています。僕自身は経営レベルで行ってきたことがないため、ピンとこないのも当たり前かなーと思いました。

かといって、興味がないわけではないです。ただ、この本を読むには、自分の視座がまだ足りなかったと言えます。

一方で経験があるのは現場レベルでのチーム生産性向上や改善といったチームビルディング。人事制度とまで大きいものではないですが、チームビルディングで気をつけていることは、人事制度においても同様な考え方をしている点があってもおかしくないと思います。そこに共通点があるのか、やはり違うのか、が気になります。

(チームも組織であるので)組織のスケールがどのようなものであれ、結局人間の認知が重要だと思います。そこをこれから学んでいきたいですね。

おわりに

今すぐに役立つ本ではなかったとはいえ、自分自身の視座が足りないことと、今興味がある点が見えてきたので読んでよかったです。

18/4月振り返りと5月目標

はじめに

4月が終わってGWも過ぎたので振り返りと次の月の目標をかんたんに。

blog.chaspy.me

4月振り返り

技術

kubernetes

大きなテーマとしてKubernetesに入門することがありました。本当に入門しただけなんですが、予定していた本は終わったのと、軽く動かすことはできたので、5月以降は実践ですね。

blog.chaspy.me

blog.chaspy.me

組織論

いくつか読み終わったものの、まだ全部は終わってないです。自分が興味がある分野なんでしょうけど、インプットの量が多すぎた。

RubyGitHubツールビルディング、Terraform

こっちはノータッチでした。

音楽

2nd album mix完GW明けまでの予定ですが、残念ながらできてないです。音楽へのモチベーションというか、かけるエネルギーが下がっているのを感じますね。。。

とはいえCDの発売日は5/23に迫っているので5月は何とか出します。

英語

毎週水曜日の英語ランチに行って、何かひとつ自分から話題を出すということでしたが、英語ランチ行けてないです。こっちもモチベ不足。

健康

  • 美しくなるために痩せる
  • apple watchを買って運動量を警告してもらう

逆にこっちは美意識が高まりまくっていて、いい感じです。apple watchや体重計も新調しました。

登壇

  • kubernetesについて社内勉強会

dockerメインになりましたけど発表しました。

speakerdeck.com

speakerdeck.com

  • 組織について身内のLT会

こっちは組織についてはまとめが終わらなかったのでやってなく、代わりにノンデザイナーズデザインブックの実践と、非IT業界のひと向けのWebアプリケーションの仕組みについての説明資料を作りました。デザインの勉強をやったのはいいことですね。

speakerdeck.com

blog.chaspy.me

speakerdeck.com

  • rubyについて、kawasaki.rb

こっちもrubyについて終わらなかったので、LTは見送り。

全然関係ないですがqiitaのファンミーティングでLTしてきました。社外での発表はほぼほぼはじめてだったりして、いい機会を得られました。まずはLTから、少しずつ発表機会を増やしていきたい。

speakerdeck.com

blog.chaspy.me

5月目標

技術

技術のテーマは2つ以上はできないような気がしてきたので絞ります。

Nginx + mruby

いずれもはじめて触るので、きっちりキャッチアップしていきたい。以下の本を購入済み。

nginx実践入門 (WEB+DB PRESS plus)

nginx実践入門 (WEB+DB PRESS plus)

マスタリングNginx

マスタリングNginx

成果は5月のkawasaki.rbのLT大会で発表します。

組織論

3月、4月からいろいろ読んでいる組織論、主に残っている以下の3冊分について復習をして、自分なりに結論を出します。

Effective DevOps ―4本柱による持続可能な組織文化の育て方

Effective DevOps ―4本柱による持続可能な組織文化の育て方

グロービス MBA組織と人材マネジメント

グロービス MBA組織と人材マネジメント

これも何かしら、自分がどこを目指すのか?っていう観点で発表資料は作りたいところ。

英語

何か1つでもいいので習慣に持ち込みたい。スタディサプリEnglishを進めてみます。1日30分はやる、ことにしましょう。

音楽

猫の休日2nd albumリリースが5/23なので、それを出します。

健康

  • 自分のhealth dataをxml出力できるようなので、それを可視化して公開する仕組みを作ります。
  • 毎日のactivityの目標を毎日達成します

登壇

  1. kawasaki.rbのLT大会でnginx + mrubyで何か
  2. 組織論について自分が目指すものをまとめてどこかで発表
  3. JulyTechFestaへのCFP提出
  4. 月末にクローズド勉強会をする予定なのでそこで何か

おわりに

これ以外にも目標に定めずに本読んでアウトプットってのはやっているので、規則正しい生活と、可処分時間を増やすことに注力していきたい。

5/9追記

ブログ振り返り

4月は19記事で、久しぶりに数が増えた。

blog.chaspy.me

書籍が8、イベント参加が6、目標や振り返りが2、技術ネタやtipsが3。

イベントや書籍の感想をブログに書くのを控えようと思っている。今後はgistに書いておき、必要に応じてブログで引用する形としたい。理由はたいして他者に役立ってる感がないから。

目標と振り返りはpublicにすることである程度自分に行動を課したいので続けたい。

技術ネタ、tipsの数を増やしていきたい。qiitaとのバランスが気になるが。これまで業務で得たことは業務中にqiitaに書くってしてたけど、これからどうするかなあ。

読んだ本

4月は20冊読んだ。ずいぶんたくさん読んだ。3月中に読んでいたけど感想が遅れたのもありそうな気はする。

技術本は前述の通りkubernetesを2冊。組織論まわりをたくさん読んで、まだ復習が終わってないものもある。このあたりブログに書いたものもあれば書いてないものもあるので、今後はgistに投げて、ブログでのまとめを自動化できたらなーとぼんやり思っている。

そういえばGitHubツールビルディングがいつまでも読み終わらないままだ。なーんか合わないんですよね。。。

GitHubツールビルディング ―GitHub APIを活用したワークフローの拡張とカスタマイズ

GitHubツールビルディング ―GitHub APIを活用したワークフローの拡張とカスタマイズ

「入門Kubernetes」を読んだ

はじめに

読んだ。

入門 Kubernetes

入門 Kubernetes

最近ようやくKubernetesを触ってみている。次の職場で使うのでキャッチアップ中。まだまだGCPで軽く動かしてみた程度だから、これからより応用的なことや、実際に中で動いている技術、実際に本番想定でアプリケーションを動かしてみることをしていきたい、という状況。

この本は最初の1冊にちょうどいい。まさに入門。コンセプトからはじまり、基本的な動作をチュートリアル的にやりつつ、Kubernetesで存在する概念が順に説明されている。

なおマニフェストファイルのAPIのバージョンが書籍のものと違っていて都度修正が必要なケースがあった。forkして修正している。

github.com

動かしたGKE上でのkubernetesのバージョンは1.8.8-gke.0

とりあえず概念が多いのでその整理を本書の掲載順に振り返っておく。

1章 Kubernetes入門

Kubernetesの特徴、およびコンセプト

  • Immutability
  • Declarative Configuration
  • Online self-healing system

2章 コンテナの作成と起動

Dockerコンテナの復習なのでskip

3章 Kubernetesクラスタのデプロイ

この本でも勧めている通り、クラウドベースのソリューションがオススメだと思う。僕はGKEを使いました。1年間で300ドルまで無料なので。

ちなみに本2冊分作ったり消したりして一月700円分だったので、無料枠なくても出してもいいかなーって感じのコストです。

この章は各Kubernetesソリューションの導入の紹介と、Kubernetesを構成するコンポーネントが記載されている。

  • Kubernetes proxy ... Kubernetesクラスタ内のロードバランスされたServiceにネットワークトラフィックをルーティングする役割。各ノードで動いている
  • Kubernetes DNS ... クラスタ内で定義されているServiceのネーミングとディスカバリを行うためのDNSサーバ。
  • KubernetesのUI ... GUI

4章 よく使うkubectlコマンド

コマンドの前に、コマンドで使われる概念。

  • Namespace ... クラスタ内のオブジェクトを構造化するNamespace(そのまんま)デフォルトはdefaultというnamespace。
  • Context ... $HOME/.kube/configにあるkubectlの設定ファイルに保存される。クラスタの接続情報と認証情報。

他よく使うkubectlコマンド

  • get ... 情報取得
  • delete ... オブジェクトの削除
  • apply ... -fでファイル内容の適用
  • logs ... podのログ
  • exec ... podでのコマンド実行
  • cp ... ファイルをpodへのコピー(逆も可)
  • help ... ヘルプ

5章 Pod

Kubernetesの扱う最小のリソース単位で、アプリケーションコンテナとストレージボリュームを含む。

Podに何をいれるべきか

同一Pod内のコンテナは

  • 同じIPアドレスとポート(ネットワークネームスペース)を使用
  • 同じホスト名(UTSネームスペース)を持つ
  • System V IPCやPOSIXメッセージキューを経由したネイティブなプロセス間通信チャネル(IPCネームスペース)を使って通信できる
  • 同じ共生関係を持つこと

各コンテナが別のノードに配備されて正常に動作しないなら、1つのPodにまとめるべき。

Podのヘルスチェック

  • Liveness probe ... 正常かどうか(再起動するべきか)を確認する方法
  • Readiness probe ... 要求を処理できるかを確認する方法(Ready + ness)

6章 LabelとAnnotation

  • Label ... オブジェクトのメタデータを特定するもの。オブジェクトを識別してグループ化する。
  • Annotation ... ツールやライブラリを手助けするためのもの。オブジェkとがどこから来たのか、どのように使うのか、どのようなポリシーなのかといった追加情報を提供する。

どちらも似ているが、用途が違うみたい。

セレクタとして他から呼ぶときに使うようなものはLabelで、追加情報がAnnotationといった役割分担みたいですね。

7章 サービスディスカバリ

Serviceオブジェクトでサービスディスカバリを実現する。

ここがわかりづらい。Serviceはservice名を元に、kubernetesクラスタ上で一意のホスト名と、ServiceのIPアドレスを持つ。これによって外部からAPIを通じてpod群にアクセスするための入り口となる。Endpointはpod個別にIPアドレスを持たせるための、Serviceと関連づいたオブジェクト。

という理解であってるかな?

8章 ReplicaSet

Podのレプリカを管理するためのオブジェクト。レプリカ数をマニフェストに宣言的に設定する。podのヘルスチェックを用いて自己回復させる。

kubectl scaleコマンドで命令的にレプリカ数をスケールさせることができるが、(おそらく)バージョン管理システムで管理されているであろうマニフェストファイルの数値と実態が異なることになるので注意すること。(ファイルを修正して、kubectl applyでスケールさせるほうがよい)

水平スケーリングができる。CPU使用率やメモリ使用率を用いて、最小/最大pod数を宣言することで実現できる。

9章 DaemonSet

各ノードに1つずつ割り当てるための、podの集合を定義するオブジェクト。ReplicaSetと似ているが、ReplicaSetは冗長化のため。

ログコレクタや監視エージェントなど、それぞれのノードで動く必要があるものに使う。

10章 Job

短時間だけ動くタスクを扱うオブジェクト。バッチ処理や、データベースマイグレーションなど。

並列実行数や、リトライの数など、ワークロードを制御できる。

11章 ConfigMapとSecret

設定情報を保存しておくオブジェクト、Secretはそれを機密管理するもの。

keyをファイル名、中身をvalueとして、ファイルシステムとしてpodにマウントすることもできるし、環境変数としてpodに渡すこともできる。

12章 Deployment

新しいバージョンのリリースを管理する仕組みを提供するオブジェクト。

DeploymentはReplicaSetを管理する。

Deploymentマニフェストファイルを更新し、applyすることでアップデートする。ダウンタイムを出さないような、ローリングアップデートができるのが最大の利点のようだ。

ただし、ここで重要なのは、ローリングアップデートを行うためには、一時的に新旧のpodが共存してしまう。そのため、どちらのバージョンとも連携できるようにアプリケーションを構築することが必要。クラウドネイティブアプリケーションの要件の1つと言えるでしょう。

アップデートのスピードもコントロールできる。

13章 ストレージソリューションとKubernetesの統合

最後が1番難しい。

永続的なストレージとの連携

これまでのオブジェクトはほぼすべてステートレスが前提だった。しかし、たいていのアプリケーションがステートレスであり、ボリュームがその代表だろう。

  • PersistentVolume ... Podあるいはコンテナとは独立した寿命を持つストレージ。
  • PersistentVolumeClaim ... PersisitentVokumeを指定するオブジェクト。

StatefulSet

ReplicaSetに似た、複製されたPodのグループ。各レプリカには、一意なインデックスを含む永続的なホスト名がつけられる。

データベースクラスタで使えるだろう。

個人的にはやっぱり現状だとクラウドが提供するマネージドなDBと接続し、DB自体の信頼性はKiubernetesの外(クラウド)に任せるのが現状は一番良い気がした。

14章 実用的なアプリケーションのデプロイ

Parse、ghost、redisを使った実用例。

まとめ

図にしてみよう。

gitlab.com

この図は継続的に更新していきたい。なんでも図にしよう。

おわりに

次はKubernetes By Exampleを動かしてみる予定。

kubernetesbyexample.com

以下はどちらかというとKubernetesだけでなく、コンテナ・オーケストレーションツール全般取り扱ったもの。

コンテナ・ベース・オーケストレーション Docker/Kubernetesで作るクラウド時代のシステム基盤

コンテナ・ベース・オーケストレーション Docker/Kubernetesで作るクラウド時代のシステム基盤

blog.chaspy.me

「悲劇的なデザイン」を読んだ

はじめに

読んだ。

悲劇的なデザイン

悲劇的なデザイン

デザインちょいとやるかーってことでノンデザイナー・デザインブックや、デザインの基本と買った時に、目について面白そうだったので読み物として購入。

デザインが呼ぶ悲劇

本書では胸が痛む悲しい過去事例をたくさんあげている。デザインのせいで、オペレーターのミスを誘発し、実際に命を落とす。にも関わらずデザインではなくオペレーター、つまり人間が責められるのはおかしい。

サブタイトルのあなたのデザインが誰かを傷つけたかもしれないと考えたことはありますか?がまさにメインメッセージとなっている。常に最悪の自体を想定しなければならない。

デザインは人間とテクノロジーの橋渡しをするためのもので、橋がどれだけ渡りやすいかは、私たちデザイナーにかかっている。橋を渡れずに除外された人は、社会的にも、政治的にも、創造性の面でも置いて行かれたと感じる(p184)

「たかがデザインでしょ」なんて軽視するんじゃなく、重く重く、悲劇的に考えないといけない。デザイナーじゃなく、プロダクトに関わるすべてのひとが心に留めておくべき考えだと思います。手元に置いておきたい一冊。

ノンデザイナーズ・デザインブック [第4版]

ノンデザイナーズ・デザインブック [第4版]

blog.chaspy.me

「ノンデザイナーズ・デザインブック」を読んで実践してみた

はじめに

読んだ。

ノンデザイナーズ・デザインブック [第4版]

ノンデザイナーズ・デザインブック [第4版]

いやだいぶ前から知ってていつか読まないとなーと思ってた本。今後勉強会での発表増やしていきたいと思ったので、発表資料のデザインにもこだわりたい!と思って購入。

マジでエンジニアに限らずすべてのひとが読んでいい名著なんじゃないですかね。。。

実践してみた

読みっぱなしではダメなので実践してみました。

speakerdeck.com

原理・原則に名前をつけて、それを無意識的に使えるようになることが、成長だと思います。(これを僕はインストールする、と呼んでいます)原理・原則をわかった上で、外す時はあえて外す、としないといけない、というのが本書のメタ・メッセージだと思いました。

こう見比べてみると一目瞭然ですね。

この4原則を知るだけなら、ちょっとググればまとめているサイトはあると思います。ただ、僕は本を実際に買って、読んで、納得して、手を動かしてみてようやくインストールできるタイプなので、やってみました。なんでもそうだよね。

おわりに

超名著です。マジで。デザイン大事。読んでないひといますぐ読もう!

「コンテナ・ベース・オーケストレーション」を読んだ

はじめに

読んだ。

コンテナ・ベース・オーケストレーション Docker/Kubernetesで作るクラウド時代のシステム基盤

コンテナ・ベース・オーケストレーション Docker/Kubernetesで作るクラウド時代のシステム基盤

コンテナオーケストレーションツールであるKubernetesを今後使っていくにあたって、全体感が知れそうな雰囲気のある本だったので購入。

コンテナ/Dockerの復習からはじまるので、コンテナ含めて初学者が一気に追いつくのにも優しい本です。

著者がたくさんいて、コンテナオーケストレーションツールもKubernetesそのものについて、Kubernetes on Google Kubernetes Engine、Rancher、Kubernetes on IBM Cloud, Rancher,OpenShiftと多彩です。(なぜかOpenShiftのページ数が非常に多い)

現在デファクトであるKubernetesの説明が多数を占めるとはいえ、自分の好みの環境で動かせばいいと思います。私はGKEで動かしました。

では順に復習していきます。

第1章 コンテナ技術とオーケストレーションを取り巻く動向

この章ではコンテナ技術そのものよりまず、ソフトウェアをどのように利用してきたかを歴史的に振り返っていきます。ハードウェアリソースを所有し、その上でソフトウェアを使ってサービスを提供してきた時代から、インターネットを利用して、現在の多くのas a Serviceのように利用する形態に変わってきました。

仮想化技術が生まれ、ハードウェアリソースはServiceとして利用するようになり、同時にInfrastracture as a Codeの概念も広がりました。自動化、コードによる構成管理ができるようになりました。それでも環境差異を埋めるのが難しい状況は一部で残り、それを解決するのがDockerでした。

Dockerはポータビリティを重視し、開発/本番でも同様に動くことを意識しました。それがDockerHubというDocker Registryであり、加えてユーザーフレンドリーなインターフェースによって、従来からあったコンテナ技術が爆発的に広がりました。

コンテナはLinuxKernel技術の組み合わせです。namespaces / cgroupがその代表でしょう。

コンテナ実装はDockerだけでなく、以前はLXCがよく使われていました。コンテナ実装はCoreOS、rktなど様々なコンテナランタイムが生まれましたが、OCP(OpenContainerProject)が発足し、標準化されました。Dockerの内部で使っていたlibcontainerはrunCという名称に変更するとともに、OCPに寄贈しました。

OCPはOCI(Open Container Initiative)となり、ランタイム仕様やイメージ形式を策定しました。

また、コンテナオーケストレーションも様々な種類が存在しています。

2015年にCNCF(Cloud Native Computing Foundation)が発足しました。乱立するコンテナ/コンテナオーケストレーションを標準化し、Cloud Nativeと呼ばれるアプリケーションを支えるために標準化を推進する団体です。

クラウドベンダもCNCFに加盟し、Kubernetesをサポートする流れができている、という現在までの流れをまとめている章です。その通りかなと思います。

第2章 dockerコンテナの基礎とオーケストレーション

Build, Ship, RunのスローガンのDocker。Webアプリケーションのポータビリティを支え、簡単に、どこでもアプリケーションを実行できるようにしたDockerについて。

Dockerイメージについて。コンテナ作成時に必要となるファイル群の総称であり、読み込み専用(read-only)のテンプレート。イメージという言葉が仮想マシンイメージとどうしてもかぶって誤解されそうなところですね。仮想マシンイメージはLinuxカーネルやシスtメウライブラリを含む。

Dockerイメージの特徴、レイヤの概念。各レイヤはそのレイヤで新たに作成したファイルを持っていて、依存レイヤが見えるようになっている。UnionFSを使っている。

Dockerコンテナの実行とは何か?Dockerイメージに含まれるファイルを使って、Linuxコンテナ状態としてプロセスを起動すること。

あとはセットアップの方法が載っています。

あとはコンテナのリアフサイクルや、orchestration文脈でのDocker Compose。盛りだくさんとは言わないが、さわりを知っているひとには復習になるだろう。Docker Swarmは使ってないので読み飛ばし。

あとはプロジェクトについて。DockerはOCIにlibcontainerを寄贈、runCと改めました。

Docker Engine(dockerd) -> containerd(docker-containerd)->shim->runC->コンテナという関係性で動いてるんですね。

第3章 CaaS(Container as a Service)

CaaSという言葉ははじめて聞きましたが、コンテナ実行環境をサービスとして利用するわけで、つまるところAWS ECSのことかな?と思ったら、ビルド、デプロイ、ランを一連の流れで行うプラットフォームのことを指すそうです。as a Serviceじゃない気がするけど。。。本書ではMesos、Marathonが紹介されてます。サンプルをフォークして試してみました。

github.com

動作確認結果です。

github.com

リッチなGUIですし、コンテナの実行状態を確認できるのはいいなーと思いました。細かい機能までは見切れてないです。コンテナのWebインターフェースへlinkされてるのいいですね。

CaaSの課題としては1クラスタあたりのサイジング、ヘルスチェック、サービスディスカバリ、コネクション数上限、通信トラフィック制御があげられています。これらをクリアしているのがKubernetes、ってつながりになりそうですね。

第4章 Kubernetesによるコンテナオーケストレーション概要

KubernetesはCNCFの最初のプロジェクトなんですね。まぁ、まさにCloud Nativeなアプリケーションのプラットフォームだからか。。。

Kubernetesに関連する以下のプロジェクトの概要は押さえておきたい。

  • パッケージ管理:Helm
  • モニタリング:Prometheus
  • ログコレクタ:Fluentd
  • 分散KVS:etcd
  • コンテナランタイム:containerd、CRI-O
  • サービスメッシュ:Istio、Linkerd、Conduit
  • リソース定義作成支援:Kompose、ksonnet、Kedge

KubernetesのMasterとnodeの役割や、上に乗るコンテナの障害発生時の動き、用語解説。このあたりの用語の整理は「入門Kubernetes」の読書後のブログにまとめようと思う。

入門 Kubernetes

入門 Kubernetes

未だによくわかってないところで、podは生き死にをともにするコンテナの集まりで、1コンテナ1プロセス原則をまもりつつも、localhostで通信できる共同体としての集まりをpodにしている。どういうケースでそれは推奨されるのかが、loggingだったり、サービスメッシュのistioだったり(サイドカーパターン?)ぐらいしか聞いたことがない。

各リソース(オブジェクト?)の記述方法が公式ではちょっとわかりにくいかも?ということで以下のサイトが紹介されてました確かによさそう!全部一通り動かしておきたい。

kubernetesbyexample.com

この章で紹介されてるのを見て「覚える概念多すぎだろ!」と思いました;あとで整理します。。。

章の後半ではminikubeを使ってサンプルアプリケーションを動かす例があります。minikubeも使いましたし、macにはいれてますけど、個人的には最初からGKE等のクラウドを使ってマルチクラスタでやったほうがいいと思いました。GKEは初回だったら1年間、3万円分無料のクレジットがついてきます。本2冊分軽く動かして壊すぐらいなら数百円程度です。

このへんを動かしながら、なんとなく各概念をふわーっとつかめます。実際にwebアプリケーションが動くのは嬉しいですね。

第5章 GKE(Google Kubernetes Engine)

というわけでKubernetesをGKEで動かす例。GKEを使うと得られる恩恵、マスタの管理不要だったり、ノードの増減が可能だったり、リージョナルにノードを配備できたりですね。ローカルでクラスタ作ろうと思うと結構ハマりどころがあったりするんですが、簡単です。ノードのバージョンを自動アップグレードしてくれるのも嬉しい。こればっかりはお金払ってもマネージドを使ったほうがいいと僕は思います。

Kubernetesそのものの説明は4章で行ったので、ここではGKE、無料トライアルのやり方が説明されてます。これを見ながら僕も登録しました。デプロイメントのバージョンアップも軽く行います。この章はGKE + Kubernetesをやるのによかったので、概念をささっとつかみたいひとは、前半部分をさらっと読みつつ、5章でGKEを使ってkubernetesを動かし始めて、そのあと4章で概念を学ぶ。という使い方をすればいいと思いました。

第6章 Rancher

Rancher、軽く動かそうか悩んだのですが、1系と2系で混沌としてそうな時期だったので今回は見送りました。実際数あるコンテナオーケストレーションツールではKibernetes以外だとRancherには注目しています。コミュニティも盛り上がってますし、Kubernetesをオンプレで使うならRancherが良さそうだなーという印象はあります。

2系が安定してからまた試すかもしれません。

第7章 Kubernetes on IBM Cloud Container Service

IBM Cloud上でのKubernetes。Kubernetesそのものの説明は前の章であったので、IBM Cloudを直近では使わないこともありぱらぱらめくって読み飛ばし。

第8、9章 OpenShift

OpenShiftも直近では使わなさそうなので軽くぱらぱら見つつ読み飛ばしました。基本的にはKiubernetesをRedHatがサポートする感じですね。

おわりに

ひととおり章ごとに振り返ってみました。ちょっと誤字があった(2件翔泳社に報告してみた)のと、著者が違うので1冊の本というまとまりはあまり感じられません。ただ、現在コンテナオーケストレーションはKubernetesが強いとはいえ、他のプラットフォームも扱っていること、DockerやCNCFの歴史から丁寧に解説していて、最近のコンテナ界隈の勢いに全然ついていけないが、急に仕事で使うことになった!というひとにはベストの1冊だと思います。(僕も似たようなものですが)

途中でも書きましたが、Kubernetesメインにささっとキャッチしたいというひとは、1章〜3章をささっと読んで、5章でGKEでお試し、そのあと4章でKubernetesの概念を覚えつつ試して、6章以降は興味がある章だけ読んでおくor必要になったら読む、という感じにすればいいと思います。そして入門KubernetesへGoですね。