ツナワタリマイライフ

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

「エンジニアリング組織論への招待 ☓ カイゼン・ジャーニー」に行ってきた

カイゼンジャーニー/エンジニアリング組織論への招待

行ってきた。

devlove.doorkeeper.jp

感想

  • 2冊の共通点は「問いを続けること」
  • 理論的なアプローチか、ジャーニー(旅)/ストーリー的なアプローチかの違い
  • 何事にも理由があり、それは歴史的経緯や、科学/学術的な部分なしに納得できない
    • 学び続けることの重要性をガツーンと受けた感じ
  • なぜアジャイルなのか、なぜオブジェクト思考なのか、それには経緯がある
  • 「エンジニアリング組織論への改善」を読み終えて思ったことだけど、広木さんの知の巨人ぶりが本当にすごい
    • 年齢もたった数年しか変わらないとは
    • いい意味で刺激を受けた、いい意味の焦り
  • 問い続けよう
  • 憧れ続けよう
  • ひとに向き合おう
  • 向き合い続けよう
  • 少しずつはじめよう!
  • 「エンジニアリング組織論への招待」は今復習中、ぼちぼちブログにあげますが、何回かにわけます(内容が濃い!)
  • この本は本当に出会えてよかった、自分の関心部分をガッツリ言語化してくれた本なので、著者の話を生で聞けてよかった。
  • 2冊のコラボイベント、楽しみにしていたしいいイベントでした、ありがとうございました。

以下、メモ

LT

未定(不確実なタイトルとして)」

  • ギブリー取締役CTO
  • 不確実性の扱いについて一貫した書籍だよね
    • 思考方法、メンタリング、チーム運営、組織運営
  • 自分自身は不確実なことに対する耐性は強いが、他人の不確実性に向き合えてなかった
  • 自分を振り返るにはとても良い本
  • 組織リファクタリングの先
    • いろんな大きな組織見てきた
    • 振り返ると技術力よりは組織力がよかった
    • コモディティ化が進むと技術やビジネスモデルだけじゃダメ
  • 人には能力が眠っていて、誰にでも創造性を発揮できるポテンシャルがある
    • みんな成長する
  • 定まっていない未来は切り開ける
  • エンジニア出身の方がエンジニアリングの枠を超えてより業界で活躍する未来を期待
  • link

カイゼン・ジャーニーについて語る

  • アトラクタ代表原田さん
  • アジャイルコーチ/ジョイ・インク翻訳
  • 著者はあることが下手くそ。。。?
  • この本に書かれてないことを話します
      1. 大事なこと「助けて」
        • 主人公自分でなんとかしすぎ
        • マネージャーになんで助けてって言わないの?
        • 向き直ってなんとかしたのはすごいいいことだけど、マネージャーが助けたらもっとよかったのでは?
      1. 急ぎすぎ
        • 本だから仕方ないけど
      1. 外部のひと優秀すぎ
        • コーチの目標は答えを教えることじゃない
      2. 逸脱しよう
        • まずは自分のまわりのギリギリをちょこっとはみ出してみよう
        • まわりが何してるか少しわかるようになる

経営者が読みたくなる「エンジニアリング組織への招待」の進め方

  • タイトル誤字
  • VOYAGE GROUP CTO 小賀さん
  • この本が経営者と技術責任者の対話のベースになると幸せな組織が増えそう
  • エンジニアは結構読んでそうなので経営者に読ませよう!
  • 読んでも1章で挫折するのでは?
  • 経営者がリファクタリング、メンタリング、アーキテクチャを聞いてもテンション上がらないのでは
    • 経営者メンタリングできると思ってる
  • エントロピーとか数式出てくるよね、エンジニアってすぐ〜ってなりそう
  • 具体的で細かい指示<抽象的で自由度のある指示
  • デリゲーションポーカー
  • なんで似たような修正でも時間かかるようになる?
    • 影のときはよくわからないものの例
  • エンジニアが知っていて、経営者が知らないこと:アーキテクチャの複雑性
  • 経営者が知っていて、エンジニアが知っていて:将来要件の複雑性
  • このへんは後半に出てくるので、前半の数式は読み飛ばそう

わいが西方でおま

  • 西村さん
  • 流しのスクラムマスター
  • なぜそれをやるのか、理由がのってるのがいい
  • 順序がある
  • 共感が軸、おれの話じゃね?って思える
  • 前提知識増えて今難しいよね、新しい知識をアップデート、知識の再編集
  • 巻き込み力、これからのHR、人材スキル、ニーズがある
  • 後半は時間切れで終わり

著者対談

テーマ0:お互いの本を紹介しあってみましょう

エンジニアリング組織論への招待

  • 多岐にわたっていて、書くの大変だっただろうな
  • 幅が広く深い
  • 認知心理学、エフィカシー、学ぼうと思っていた

カイゼンジャーニー

  • ひとって説明しても受け取り方違うよね
  • 自分は原理原則、納得が落ちる
  • 物語性、ナラティブ性があったほうが共感持てるよな、と思ったが、自著には入れられなかった
  • 小説書くわけじゃないし、いれられないなあ、と思っていたら
  • 同時期にカイゼンジャーニーが出た
  • 伝えたかったことのもうひとつのアプローチ、ぜひお話ししたいと思った

テーマ1:2つの本に共有することは何か。なぜ、共通部分が生まれたのか。

  • 市谷さん
    • ある難しさに向き合っていくためにどうしたらいいかを考える
    • 組織の問題、自分1人しかいない問題。。。
      • エンジニアリング組織論はこういう構造があってどう立ち向かうのか
      • カイゼンジャーニーは旅、動的なもの
    • アプローチは違うけど、立ち向かうこと一緒
  • 広木さん
    • 「問いを持ちなさい、その問いは常にあなたに向かっています」
    • 再帰
    • 書かれていることは知ってるか知らないか、知識じゃなく、知恵
    • なぜ問いを持ち続けられるの?
      • まわりをよくしたいから
      • もういいやってなるかもしれないけど、
      • また問い直す
    • バイラル
      • まきこんだほうがつらくない
      • ずっと問いをせずにいられる

テーマ2:それぞれの本で異なる考え方、表現は何か

  • 新井さん
    • カイゼンジャーニー
      • 物語、解説、、、
      • 第1部はひとり、第2部はチーム、、、と展開が変わっていく
      • 展開に合わせたプラクティスを紹介している
    • エンジニアリング組織論への招待
      • タイトルにセオリーとあるとおり、セオリーが書いてある
    • ページ数のボリュームが違う
      • エンジニアリング組織論は深い
      • カイゼンジャーニーでも最初はダブルループ学習についても書いてあったが削った
    • カイゼンジャーニーは解説でも西方さんの口調だったりするので、バックにキャラがいる
  • 広木さん
    • いきなりエントロピーとか言っちゃう感じ(笑)
    • シンプルな理屈が説明されないでアジャイルスクラム、マイクロサービスとか唐突に出てくるの不思議
    • 若い子が流行りものに乗って大失敗してるのを見てる
    • 理屈は?
    • ベースは情報科学、そもそも科学とは?
    • 経験主義はスクラムに書いてあるが。。。?最初わかった?
      • 経験主義でベーコンのこと浮かんだ?
      • 科学哲学史、大学の教養課程でチラっと出てくるけど、実務やってないし流しちゃう
    • 実はエンジニアリング組織論っぽいこと、大学の情報科学にのってる
  • ジャーニーとつけることで旅は続くよ感(笑)
  • 招待を書くことでまだ全部じゃないよ感(笑)

テーマ3:現場でそれぞれの本をどんな風に使っていけばいいか。著者が気をつけていることは?

  • 市谷さん
    • ぼっちのひと向けに書いた
    • なーんかおかしいな、でも言いづらいなってとき
    • 助けてっつっても助けてくんないんだよなあ
    • そういうときでもかたわらでおける本
  • 広木さん
    • 何人かで読んでみたらいいと思う
    • ちょっとうまくいかないあいつと、話し合いのきっかけに
    • 読み終わったあと、アルコール飲もうぜ
    • 正しいアジャイル、正しいスクラムなんてない
    • 本当は「ちゃんと話をしなきゃいけない」問題には気づいていた
    • 気づかなきゃいけないことに、気づき直す
    • 本当しては不確実性、コンティンジェンシー組織論
    • 監視しあっちゃうと月崩せない、だから仕組みで買えないといけない、社会の仕組みで
    • ちょっと気になる(恋心ではない)あいつと一緒に読む、そのきっかけに使う本
    • 最強のソーシャルゲーム、アルコールでは?と思ってた(笑)
    • この本は限りなくビールがライバル(笑)
  • 新井さん
    • プランニングポーカー、指さえあればできる
    • 何かしらやってみるきっかけになる
    • 簡単そうに、できるんじゃないかなーと思うことを、ぜひやってみてほしい

テーマ4:お互いに聞いてみたいこと

  • 新井さん
    • 表紙のグリーン、英語のタイトルEnginering Organization Theoryの決め方は?
  • 広木さん
    • わりと本読む方、かっこよさげのタイトルをつけたい!
    • アルファベット2文字かっこいいなあ、ジョイ・インク
    • 技評さん、違うみたいな気配(笑)
    • 和物でいくか
    • いい本、なんとか論への招待って本多いなあ
    • 装丁、デザインやりとりしてる
      • まんなかで英語いれたい、英語欲
      • デザイナーがぽっと出してきた
      • これはよい!
    • ちょっとティール色
      • ティール流行りそう
      • もうちょっと青っぽくした
  • 広木さん
    • それぞれのモデルいるのか、モデルいた!
    • 他にもいる?許可とってやった?
  • 市谷さん
    • 今のところ直接言われたりはない
    • 司会のひともモデルになっている
    • 原文読んでるときはガチバイネームで書かれていた(笑)
    • 新井さんは公共交通サービスを作ってる小町さん
  • 広木さん
    • 当て書き書いてるとき、まさに技術そのものだったりする?
    • シンガーソングライターの歌詞で恋愛を予想する感じになってるけど(笑)
    • 見るひとみたら何の話かわかるのでは?
  • 市谷さん
    • 反応はないけど、第一部のおわりの2章はまんま
  • 新井さん
    • 自分の実体験を3つ4つ、ミクスチャーして抽象度はあげてる
    • 実体験ベースではある

テーマ5:会場からの質問

  • 技術的負債の返却は、ビジネスインパクトに中々跳ね返ってこず、経営層やステークホルダーの協力を継続的に得ることが難しいと感じています。特に長期プロジェクトで中々成果が出ないような状況を乗り越えるコツやエピソードがあれば聞きたいです
  • 広木さん
    • コンピュートリソースは簡単に調達できるけど、エンジニアリングリソースを調達するのは難しい
    • 一番ボトルネックとなってる部分に投資できない会社が生き残れるわけない
    • ならもう一度対話して、本当にそうなの?って聞かないと
    • 技術的負債、ちゃんと説明したのかなあって思った
      • それで説明して?って言われたのをわかってない、だとすれば破綻
    • 実は理解を継続的に得ることを難しいと感じてるかもしれないけど、本当にそういう態度で向かっているか?を問い直してみよう
    • 実際、いま採用に困ってない会社なんてない
    • 採用しなくてもエンジニアリングリソース、開発効率をあげられますって言って「いやいや」っていう経営者いないと思うよ
    • いつも文句言ってるやつと思われてると難しいかも
    • 作り直し幻想あるよね、作り直しすれば技術的負債はなくなるけど、作り直しもだいたい失敗する
  • 市谷さん
    • できなくなることがこれだけあります、やりたいことはいろいろある、と言えばマジか、ってなる
    • 向き合えない!となってエンジニアが逃げちゃうとなるとやばい
    • やれなかったら引くしかないっすって覚悟で言う
  • 『エンジニアリング組織論への招待』への質問です。 「不確実性に向き合う」というテーマに少しでも関連する理論やプラクティスが全部ブッ込まれてるように感じるほどの情報量だと感じました。これらは広木さん自身、全部実際に実践してきた経験を通して書かれたのでしょうか。どの辺りが理論で、どの辺りが実践なのかに興味ありました。
  • 広木さん
    • だいたい実践したことじゃないと理論として書かない、という気持ちでいる
    • 使ったことないフレームワークや試したことない理論は基本的にないはず
    • 理屈が切断されたように、やってみたらいいよってぶん投げ方はしたくなかった
    • なぜやるといいかをとことん突き詰めると理屈っぽくなっただけ
    • 実践した部分だけ集めて理論化したらこういう感じになった
  • 経営者へ本を薦めるお話がありましたが、マネジメントされている側の立場として、同僚やマネージャーなどに広げていく方法など何かありませんか??
  • 新井さん
    • 反応がなくてもこつこつ続けていこう
  • 広木さん
    • 買ってそっと置いとく
    • 本って見つけて読んで、おお面白いってなって、勧めたいって思う
    • いろんなひとから勧められるといいかなって斜に構えちゃう族いるよね
    • なんか発見した、見つけた感を演出してやる
  • 新井さん
    • 問題駆動
      • チームのこと、コミュニケーションのこと、、、
      • 一部のスクショを社内ソーシャルにアップして誘導
  • 広木さん
    • 社内slackにシェアする分には画像シェアok(笑)
    • 著作権フリー(笑)
    • ユニコーン企業は#generalに書かれてるらしい

最後に締め

  • 新井さん
    • 明日から何かやってみよう、今日夜お風呂で考えたり妄想したこと
    • 夜中のラブレター
    • それをやってみちゃえー!
    • そのやっちゃうことが数億の失敗はないよね
  • 広木さん
    • この本書くにあたって、セルフマネジメントできることを証明するために45kg痩せた
    • 今日まで禁煙もした
    • 痩せられる、禁煙もできる素晴らしい本!
  • 市谷さん
    • 誰かと一緒に何かを作る、仕事するってすげー難しいって今更思う
    • いったいなんなんだろう、人類の歴史から。。。
    • なかなかうまくいかんところに改めて向き合っている
    • ここにきているひとたちが一緒にカイゼンジャーニーや、エンジニアリング組織論を広めていくことをしていきたい

「別のしかたで ツイッター哲学」を読んだ

はじめに

読んだ。

別のしかたで:ツイッター哲学

別のしかたで:ツイッター哲学

驚いた。この本、すべて著者の千葉雅也のツイートだ。

Twitterとは、140文字以内という非意味的切断された言葉たち。それはそのときの文脈から切り取られてまた別の意味になる可能性がある。

千葉さんは勉強の哲学で知った。

blog.chaspy.me

勉強の哲学で採用されているツイートももちろん記載されていた。

あとこれも好きだな。

僕とツイッター

ツイッターは長いことやっているが、今は無意識で使っている。その無意識に刈り取られた言葉たちは、特別あとに別の意味を持つことも、読み返すこともしていない。なんなら、定期的に全部削除したりしている。

例えば自分のブランディングのためにツイッターを使っているのであれば、内容はこだわったほうがいいだろうし、自分が思考する、思考を整理するツールとして使うのであれば、ある程度あとで見返して整理することになるんだろう。

僕はといえばほぼ反射でつぶやいているので、あんまり考えをつぶやいている意識はない。ときおり、愚痴のような勢いで思ったことを連続で吐き出すこともあるが、やっぱりその手軽さであとから一切見返さない感じ、独り言のように流れていく感じが、ツイッターの好きなところだ。

ツイッターが140文字による非意味的切断だとすれば、僕はその上で、それらはさらに希薄化していくというイメージ。もちろん自分で消さない限り消えないし、自分が変わればその文字は過去になるかもしれないが、無自覚に、反射的に吐き出して、それはだんだん古くなり、そしていずれ捨てられる、テンポラリーな言葉置き場という認識だ。

考えたいことは、ちゃんと考えるしな。今はこの使い方でいいかなって思う。

おわりに

140文字で。280文字で。制約はうまく使うと創造性を育む。うまく使っていこう。

戦うWebデザイン―制約は創造性をはぐくむ

戦うWebデザイン―制約は創造性をはぐくむ

「Qiita/Qiitadon ファンミーティング #2」に参加した

はじめに

参加した。

increments.connpass.com

Qiitaにはいつもお世話になっているので、参加した。

LTした

LT枠余ってそうだったので突発でLTした。色といい内容といいQiitaへの忖度みを多分に含んでいる。

speakerdeck.com

発表内容に関して、(いろんな理由で)聞けてよかったというフィードバックを得られて嬉しかった。ちゃんとOrganizationアピールもしたよ。

他の方のLT

PANQ

www.panq.jphttp://www.panq.jp

speakerdeck.com

qiitaの記事のうち、他のqiita記事に参照されている記事を 検索するサービスを作ったという話。

APIでは被link数は取れないらしい、クローリングされるよりはAPI出したほうがいいんだけど、悩ましいようでした。 qiita自身の検索の話が少し話題になりました。

1人でWebサービスを作って公開した話

qiita.com

クラウド勤怠管理サービス、利用者は1000人ほど。

1人開発はモチベーション維持が敵、 逆にモチベーションに頼らず、必ず朝2時間は開発する、と決めたそう。 (それができるのがまたすごいですが)

HelloWorldかるた

helloworldkaruta.strikingly.com

技術書展4で頒布していたらしいHelloWorldかるたを、エンジニアたちが囲んでいた姿は本当に面白かった。言語マニアだなぁ、と。。。

Qiitaの今後

書いていいのかわからないのでやめておく。

今日ぐらいのゆるっとした感じが続けばいいな。

Qiita自身、素晴らしい情報共有プラットフォームを提供しているのだから、その対価でしっかり稼いでもらいつつ、一緒に"エンジニアリングに関する情報共有"の答えを考えていきたいです。

「IT業界を楽しく生き抜くためのつまみぐい勉強法」を読んだ

はじめに

読んだ。

IT業界を楽しく生き抜くための「つまみぐい勉強法」 (技評SE選書)

IT業界を楽しく生き抜くための「つまみぐい勉強法」 (技評SE選書)

渋川さんのツイートを見て中古で購入。

読んでみると、今は実践できていることもあれば、ウッ、できてない、ってこともあり、1年目の自分に送りたい気持ちと、これからも勉強やっていくぞーって気持ちと両方持ちました。

つまみぐい勉強法とは

本書の「はじめに」に書いてある通り、以下の特性を持つ勉強法のことです。

「多くの先輩達が実践している、楽しく学び続けるための勉強法」

であるとし、

「つまみぐい勉強法」は、次の3つの価値から構成されています。 * えいやで、すぐ始める * ほかの勉強へすばやくスイッチする * 対象は変わっても、勉強自体は続ける

IT業界で働くものとして、業務以外での学びが必要であり、それを継続して行うことが重要です。でも、どうせやるなら、楽しく勉強したい。楽しく学び続けるためのプラクティスがたくさん載っています!

少しだけ紹介します。

第1章 つまみぐい勉強法とは何か?

僕自身、飽きっぽくて、多動なんですよね。集中し続けることが苦手で、いろんなことが気になって、気になってはそれに手をつけてしまう。だから、基本的にかなり多くのタスク、勉強がパラレルで走っている状態です。でも、それでいいんだと思います。

この本の中で「得意技を見つけよう」という考えがあって、好きなので紹介します。

自分に合う勉強というのは、「継続できるかどうか」で判断できると説明しましたが、得意技の特徴は次のとおりです。 * つまみぐいしてきた勉強の中で、思った以上に効果のあるもの * 自分では普通のことなのに、思った以上に他人から評判が良かったもの * 実施していて楽しいもの

つまみぐいですから、いろいろやるんです。いろいろやっては、別のことをやって、って繰り返す。でもそれだけだと、きっと面白くない。どこかで面白いもの、自分の得意技となる勉強対象が見つかるはず、それ見逃さないようにね、というメッセージを受け取りました。その通りだと思います。

本を読んでいても、合わない本ってありますよね。それをせっかく買ったから、ととっておかずに、やらないという選択をする。飽きたらすぐやめて、"別の勉強をする"(何もしないではない)というのは、僕も実践してるところです。

第2章 守りの勉強法

守りの勉強法とは、実際に自分が仕事を与えられたところで、それを自分自身でなるべく解決するために勉強しよう、という趣旨です。仕事外の勉強ではなく、まずは仕事をうまくやるための勉強ということでここでは"守りの勉強法"と書かれています。

この章でいいなと思ったのは、会社というものが、別の視点で捉えられるようになります。単なる自分の所属組織から、人と道具と場所を与えてくれるチャンスの場として捉えられるようになるでしょう(p77)というところです。

言われたことをやるところから、自分自身で仕事の枠を設定し、自分で仕事を設定するようになると、自分でキャリアを築くことができます。そうなれば、上記のように、会社はキャリア形成のチャンスの場、と捉え、好循環がはじまります。こうなるまではなかなか時間かかりますね。

一次情報か二次情報かを気にし、できるだけ一次情報にあたること、ということは僕も最近ようやく意識しはじめたことです、、、

第3章 攻めの勉強法

自分の業務で遭遇したことを学ぶのが守りの勉強法だとして、それ以外の範囲の勉強のことを攻めの勉強と本書では呼んでいます。まとめから引用すると

  • 勉強時間を作る
  • 本は最強の時間短縮メディア
  • 手を動かす
  • ソースコードから学ぶ
  • ブログを書く
  • 翻訳して学ぶ

中でも、これからやっていきたいなーと思ったのは翻訳です。仕事で使うものは、必要に応じて英語のドキュメントを訳してブログに載せてきたりしましたが、それ以外でも翻訳は今後も積極的にやっていきたい。

そのため、yakstというサイトに翻訳者として貢献することにしました。

yakst.com

ちょっとまだ何も動けていないのですが、これからはyakstのプラットフォームに投稿していこうと思います。

4章 勉強法座談会

一言だけ、いいなーと思ったのは最後の渋川さんと牛尾さんの発言。

渋川:僕の高校の先生が「重要なのは若さとバカさだ」と言っていました。ハンドルとブレーキは壊れているけどアクセル全開みたいな。 牛尾:勘違いは重要ですよね。俺イケてるんちゃう?とか。後で絶対鼻を折られるんですがそのエネルギーがないと何も進まないです。(p159-160)

勘違いしてでも、とにかく自分を突き動かすエネルギーを持たないと、何もはじまらないってことですよね。

しかしこの本が出版された2010年時点だと牛尾さんはシンプルアーキテクトという会社の代表だったとか。今はすっかりMSのイメージですが。

はてなダイアリーにはその頃のアカウントがまだ残ってますね。

d.hatena.ne.jphttp://d.hatena.ne.jp/simplearchitect/about

5章 勉強会に行こう

今でこそたくさん社外の勉強会にいくようになりましたが、社会人になって最初はなかなか勇気が持てなかったことを思い出します。本章では勉強会にいくことの価値に加えて、自分で勉強会を主催してみようというところまで書かれています。

勉強会の10のメリットをメモしておきます。

  • ファミリーを作る
  • 日常に変化を与える
  • 方向性を正す
  • リーダーシップをのばす
  • 世の中の流れを知る
  • 初心者レベルからロケットスタートする
  • ストレスへの耐性を付ける
  • 高い目標を発見する
  • 自分のブランドを確立する
  • 出版デビューのチャンスをつかむ

どれもそうだと思いますが、僕は中でも大きいのは「日常に変化を与える」「世の中の流れを知る」ことですね。これから発信することが増えていけば最後の方の「ブランドを確立する」「出版デビュー」もついてくるんだと思いますが。

自分の会社にいるだけだと、結局自分の会社内の世界で完結してしまう。自分自身がどういう価値なのか、世の中的にはどういうことが行われていて、自分の会社ではどうなのかという比較ができる、そこが一番大きいですね。

あとは今でも言われていますが、勉強会に参加しまくるだけじゃなダメ、発信しないとダメ、という話。もちろんそれはそうですけど、僕はそれでも最初は行くだけでも違うと思います。行きまくっていいと思います。ただ、行くだけで何も考えない、行ったことに対して何も発信しないのはさすがに意味がないので、Twitterハッシュタグをつけてでもいいので感想や気づいたことをつぶやくとかでもいいと思います。

登壇しなくたって、勉強会に出て、何か考える、刺激を受ける、新しいことを知ることは、行かないよりいいと思います。

6章 勉強を思考タイプ別に攻略

4種類のタイプを歴史上の人物に例えて説明している章。僕は④勉強法で大切なのは、面白いかどうかだ、で、坂本龍馬タイプでした。

飽きっぽいしわりと直感で動くし多動なんですよね。今は自分はそんな人間だって割り切ってますが。

本書のよると以下のような勉強法が向いているらしいです。

  • ひたすら試して飽きたら、すぐに次の興味のあるものに飛びつく
  • 理論は考えずに体感して学ぶ。理論は後からついてくる
  • まったくつながりのない業界の弁y行をして、参考にする

いやーその通りだなーと思いました。理論も大事なんですけどね。。。

7章 家庭を持っているひとの勉強の仕方

家庭持ってませんけど、時間減りますよね。。。朝とか夜になるんだろうなあ。

おわりに

1年目の自分に送りたい気持ちです。もう4年経ってしまった。翻訳と、勉強会での発信は今後やっていきます!

「Container Days Japan v18.04」に参加した

はじめに

行ってきた。

eventregist.com

感想

  • とにかくいいイベントだった!満足感高い
  • ひとの数も多すぎない、参加者は500人程度、ストレスは感じなかった
  • 小さいながらも充電スペースや、コーヒーも飲めたりとうれしい配慮
  • 何より発表内容!自分自身が興味が強いのもあるが、全セッション見るイベントはなかなかない(たいてい1つ休憩する)
  • 8割型Kubernetesだったとはいえ、コンテナ/コンテナオーケストレーションのプロダクション導入事例にみんな飢えてるのは感じた(自分もそうだ)
  • コンテナを含む、アプリケーションプラットフォームは、kubernetesがデファクトとはいえ、まだまだ混沌としていて、少なくとも2,3年は試行錯誤が続きそうな気がした
  • Yahoo(Z Lab)さん、CyberAgentさん、まずOpenStackが安定稼働しているところがすごい、これは他社は真似できない
    • だからこそOpenStackの上でkubernetes-as-a-serviceができる
  • 見たどのセッションもいろんな視点でkubernetes(コンテナ)を見ていて、自分自身これからどうやって活用していくかに役立つ
  • pivotal草間さんのセッションが印象に残った、「適材適所」だがそれが難しい
    • コンテナも、kubernetesも所詮技術、ビジネス解決に何が適しているかを見極めるのがエンジニアリング
    • そのためにはServerlessも、PaaSも、Container Orchestrationも、"正しく理解"しなければならない
  • 最後Zlab五十嵐さんの発表、なんであんなにスライドきれいなんですか。。。
    • istio触りたくなる見事な発表でした
  • 今後もkubernetesを自分も触っていくが、アプリケーションの信頼性、ひいてはアプリケーションが解決するビジネス課題のために技術があるという視点は忘れないようにしたい
  • 次回は12月!参加したい!

公式さんがまとめてくれる前に、@Yukotanさんが資料をまとめてくれています、助かります!

medium.com

以下、メモです。

サイバーエージェントにおけるプライベートコンテナ基盤AKEを支える技術[Masaya Aoyama(CyberAgent)]

speakerdeck.com

  • AKE(Adtech Container Engine)

  • https://developers.cyberagent.co.jp/blog/archives/12058/

  • 2人で作ったとのこと

  • 構築

    • パッチをあてたkubernetesバイナリをビルド、packerでqcow2に。
    • その後heatで展開
    • バージョン依存、くみあわせ、kubernetes, docker, etcd,,,
    • E2E test
  • key機能

    1. kubernetes, swarm(multi COO)
    2. openstack integration
      • keystone(Identity)
      • cinder(persistent volume)
      • designate(DNS), cluster名をもとに名前解決
      • heat(orchestration)
      • なんで他のツール使わないの?
        • magnum、開発スピード遅い、不安
        • rancher、2.0のGAは5月(2年前になかった)、細かい設定
        • tectonic
      • なんでベアメタルじゃなくてVMにしたのか
        • VMのほうがオーバーヘッドがあるが、
        • ベアメタル、コンテナ詰め込んで落ちると影響範囲が大きい
    3. high performance
    4. add-on mechanism(monitoring, logging), datadog, kibana, elastic
    5. tuning for adtech system
    6. multi container runtime

    7. まとめ

      • Pros
        • なんでもできる
        • kubernetes最高
        • add-techに特化したkubernetes環境を作れる
        • オンプレなので、パブリッククラウドとのハイブリッド構成もできる
      • cons
        • 実装コストが大きい
        • 運用コストが大きい
        • 内部実装を理解する必要がある
    8. あくーえちゃんの飼い主、we are hiring
    9. KubeCon 2018 EU 日本交流会@コペンハーゲン

マイクロサービスアプリケーションとしての機械学習[Takuma Yamaguchi(Mercari)]

speakerdeck.com

  • 画像認識を中心とした機械学習

  • 機械学習基盤の現状と課題

    • 要求性能が高い
    • サーバコストが高い
    • 学習モデルと、ソースコードのバージョンを合わせるのは面倒
    • プロダクション以外にも学習環境が必要
  • 機械学習を使った新機能をリリースしたい、インフラ担当ならどうする?

    • サーバでは1日100万リクエス
    • workerでは常時25GBメモリ
    • 機械学習のモデルのファイルサイズは15GB
    • モデルは定期的に更新し、GPUが必要
  • 回答「とりあえずdockerfileを書いてください、なんとかします」

  • Dockerfileはじめて書いた、シェルスクリプト感覚で1日で書けた

  • 1週間後、動きました

    • 画像はS3、GPUがあるのでAWSと併用
    • 通常の運用で見るのはkubernetes deploy(spinnaker経由)とdatadog(monitoring)
  • なんで一週間でできたのか

    • 複数の開発拠点(日本、サンフランシスコ、ロンドン)
    • マイクロサービス化していて、影響範囲が明確になっていた
  • 今までは「手順書を用意してくれれば構築します」だった、運用の限界は見えていた

  • 機械学習におけるMicroservicesのメリット

    • persistent volumeにモデルが入っている、更新のために毎回作り直す(blue green deploy)
    • 機械学習エンジニアだけで学習モデル以外のシステム運用もできるかも
  • まとめ

    • 実行環境や運用が特殊なことが多くMicroservicesとの親和性が高い
  • 200GBのモデルなんですけど -> 苦笑いながら「とりあえずdockerfileをもってきて」

  • 参考:http://tech.mercari.com/entry/2017/08/21/092743

  • SpinnakerによるContinuous Delivery

"Yahoo! JAPANのKubernetes-as-a-Service"で加速するアプリケーション開発[Masaya Ozawa(Yahoo! Japan)&Kazuki Suda(Z Lab)]

www.slideshare.net

Yahoo!ズバトク on kubernetes

  • おとくなくじやキャンペーンを掲載するためのキャンペーンプラットフォーム
  • yahooズバトクの技術スタック:openstack, jenkins, 社内独自パッケージシステム、php
  • 課題
    • スケールアウト、スケールアップができない
    • リリース自動化ができてない
    • パフォーマンステストのための本番同等の環境がなかった
  • kubernetesを使おう
    • 技術スタック:openstack、kubernetes、docker、Concourse CI、Java
    • concourse CIを使い、開発デプロイ、プルリク作成、本番デプロイできるように
    • GitHub上の操作で完結できるようなフローになった
    • ログも集約され、障害発生時もも簡単に(splunk)
  • Kubernetes移行
    • 考え方、設計方針のスイッチ
      • Cloud Native的な考え方

Yahoo Japanのkubernetes as a service

  • zlabのkaasについて
    • セルフサービス
    • オートヒーリング
    • ゼロダウンタイムアップグレード
    • クラスタアドオン
  • kaasの価値
    • 煩雑なkubernetesのオペレーションから運用者を解放する
    • AUTOMATE ALL THE THINGS
  • kaasの要件
    • スケーラブル、管理対象が数万台でも動く
    • 非同期モデル、マシン(VM)準備など処理完了まで時間かかることも
    • 堅牢性
  • CustomResourceDefinitions(CRD)

まとめ

  • kaas導入によりビジネスロジックに集中できるように
  • ソフトウェアですべてを自動化
  • kubernetes-as-a-service on kubernetes

Kubernetes x PaaS - コンテナアプリケーションのNoOpsへの挑戦[Yoichi Kawasaki(Microsoft)]

www.slideshare.net

  • venture -> yahoo -> microsoft
  • cloud app dev専門
  • NoOps
    • システムに自立運用(自己回復性)をもたせて運用コストを最小限にする
    • エンドユーザーにとってはサービス停止時間が最小に、高いサービスレベルを享受
    • 運用担当にとってもSRE的な運用機能に注力
    • デブサミ2018 NoOps
    • https://www.slideshare.net/hiromasaoka/noops-88082246
  • 特徴

    • self healing
    • in-flight renewing(無停止メンテ)
    • adaptive scale
  • kubernetes

    • self healing
      • pod's phase
      • probe
        • lieness 生きているかどうか、再起動の判断
        • readiness probne トラフィック受付可能かどうか、通信先決定の判断
      • restart policy、再起動判断
      • deploymentとreplicasetの仕組み
    • in-flight renewing
      • deployment配下を段階的に入れ替える
    • autoscale
      • podのhorizontal pod autoscale(HPA)
      • cluster autoscaler(CA0 クラスタレベルのオートスケール
        • node追加する
        • リソース不足でこれ以上podを増やせなくなった動く
  • マネージドサービス、PaaS、Serverlessを活用?
    • kubernetesは強いけど向かない例もあるよね
    • 無理にしなくていいよ
    • Kelsey Hightowerさん
    • ステートフルなもの、StatefulSetsやVolumesとかあるけど、まだまだ経験が必要な段階
    • こういうのはプラットフォームとして回復性がネイティブ実装されたPaaSやServerlessを可能なかぎり選ぶべき
    • Open Service Broker API
      • もともとCloud Foundryで考えられたものを汎用化
      • 外部サービスのprovisioning、更新、削除、bindingなどを自動化
    • Service Catalog
      • kubernetesがService Brokeと簡単に連携する
    • kubernetesはService Catalogを通じて、OpenService Broker APIともしもしし、Service Broker(各種ベンダ製プラットフォーム)とやりとりする
    • AWSのRDS(MySQL)を使う例
      • credentialな情報はSecretへ
  • マネージド型kubernetesの活用
    • masterの可用性、めんどくさいよね、オフロードしたいよね
    • AKS(Azure Container Service)
      • コマンド一発でクラスタアップグレードできるよ
      • ノードのjoinもコマンド一発
  • クラスタフリー&サーバレスコンテナサービス
  • Service Mesh
    • Service間通信の課題を解決するソフツェアレイヤー
    • コードを変更することなく回復性機能を追加できる
    • podの中でenvoyをサイドカー的にいれて、プロキシ的振る舞い
    • 1行かけばバグは生まれる、コーディングレスにこしたことはない
  • CI/CDは重要
    • Helm、パッケージャ
      • Service, ingress, pods, deployment… yaml、煩雑
      • これらを1つのパッケージとして面倒見る
      • ひとかたまりごとにrollbackできる
  • モニタリングとログ収集
    • クラスタ全体で何が起きてるかを把握できることが重要
    • それに対してテクノロジ選択、いろいろあります
  • Cloud Native Landscape
    • エコシステム広大
  • まとめ
    • kubernetes非常に強力だけど完璧じゃない
    • オフロードが可能であるなら回復力がもったマネージド、Paas、serverless活用
    • 足りない部分はエコシステムを活用して賢くギャップを埋めよ
    • NoOpsの目的は運用負荷を最小にして空いた時間をさらなるイノベーションに埋めよう

Cloud Native Apps入門[Takuya Noguchi(iRidge/dockerjp)]

speakerdeck.com

  • @tnir
  • アプリケーションエンジニアに普段からClod Native Appを使ってほしいな

Cloud native appsとは

  • CNCF
    1. Container packaged -> containerization
    2. Dynamically managed -> orchestration
    3. Micro-services oriented -> service mesh
  • 20プロジェクトある
    • 昨年kubernetesがgraduate
  • CNCF CI dashboard
  • certification kubernetes認定プログラム
    • 個人の認定資格もある, administratorとdevelopper
  • cloud aoolication maturity
  • twelve factor app
  • GitLab CI評価高い
    • ソースはどれだろ

まとめ

  • どんなワークロードでもkubernetesで実行できる世界を目指しましょう(アプリのcloud native化)
  • cloud nativeなアプリを開発していける仕組み化が重要(?
  • スタートとしてmicroservicesにこだわらないことも大事
  • コミュニティの皆様に支えられてやってこれ、社内のコンテナ標準化ができた

Spinnakerを利用したKubernetesへの継続的デリバリ[Takashi Mizouchi(AP Communications)]

speakerdeck.com

  • APCommunication、7割がインフラエンジニア
  • ミランティスとのジョイントベンチャーミランティス・ジャパン株式会社
  • コンテナのメリット
    • ポータビリティ、別環境で実行可能
    • 軽量、VMイメージより軽い
    • 実行環境の隔離
  • コンテナの管理、以下の課題をkubernetesが解決
    • 複数のDockerホストの管理
    • コンテナの死活監視
    • 障害発生時のセルフヒーリング
    • ロードバランサー
    • 永続的なデータ管理
    • ログの管理
  • kubernetesでも解決が難しい問題?
    • CI/CDの機能がない
  • SpinnakerはCDツール。kubernetesをdeployできる。
  • Spinnekerの特徴
    • マルチクラウド対応CDツール
    • 自動デプロイに必要な機能を搭載
      • パイプライン、
      • 様々なdeploy方法
        • blue/green deploy
        • rolling deploy
        • canary deploy
    • GUIでパイプライン(ワークフロー)を作成できる
      • パイプライン中にカスタムスクリプトの実行が可能
        • serverspecとか
        • 他のパイプライン(jenkinsやgitlab-ci)でもできそうな気がする。。。
    • 連携できるCIツールはJenkinsとtravisCI
    • manual jadgementはよさそう
    • write-listed execution windows
      • よく使う時間(日中、9時ー17時とか)をデプロイ禁止にできる
    • chaos monkey integration - ツールがついてる?そう動くんだろ
    • enable monitoring
      • datadog
      • prometheus
      • stackdriver
    • spinaker <->k8sのマッピング
    • 今後
      • 2ヶ月毎のvup
      • k8sのmanifestをデプロイする機能
      • カナリアテストを自動で行うOSS Kayenta

Helmを利用したKubernetes as a Serviceの実装[Motohiro Otsuka(NEC Solution Innovators)]

speakerdeck.com

  • keynoteのyahooさんとかぶって、、、
  • 自前で運用してたけど、運用したくない!
  • kubernetesはクラウドネイティブなアプリケーションの運用管理基盤
  • helm、kubernetesのパッケージマネージャ
    • 一般的なアプリケーションですらmanifest書いてた
    • chartって単位で共有できる
    • https://kubeapps.com
  • kubernetes as a serviceは、ユーザごとにクラスタを提供する
    • 共有してnamsespaceで切ってもいいんだけど、それぞれのupdateポリシーにあわせたりできる
    • コントロールプレーンをKaaSでフルマネージド、ノードだけユーザはもらう
    • GKEやAKS、コントロールプレーンの管理費は含まれない
  • クラウドに対抗するkaasを出すには?
    • コントロールプレーンのデプロイ、管理を自動化する
    • kubernetesがあるのでは?
  • kubernetes on kubernetesですよね
    • 自然な発想ですよね
    • kubernetesだってクラウドネイティブアプリケーションですし

Google Kubernetes Engineにおけるバッチ処理のパターン[Shota Yoshikai(Kabuku)]

speakerdeck.com

  • バッチ処理
    • 数秒から数時間以上かかる処理
    • 非同期
  • バッチ処理パターン
    • kubernetes標準のジョブ
    • メッセージキューイングの組み合わせ
  • kubernetesのjob
    • 一度切りの処理を実行させるコンテナ
  • ジョブのみを使う構成
    • メリット、シンプルでいい
    • デメリット
      • ジョブの数が増えると管理が大変、labelつけてもいいけどつら
      • 一度に大量のジョブを作るとリソースの上限に達してしまう
  • 公式での解決策
    • parallel processing using expansions
    • rabbitmqやredisと組み合わせる
  • MQと組み合わせる
    • 検討すべき点が増える、MQのサービスどれ使うか
    • pushかpullか
    • ネットワーク構成
  • クラウドのMQ
    • GCP、Cloud Pub/Sub
    • フルマネージド
    • 負荷は札束で殴って解決
    • 通信経路がk8sのネットワーク外
  • 経路:client -> Cloud Messqge Queue -> k8s pod
  • ミドルウェアのメッセージキューイング
    • rabbit mqとか
  • 経路:client -> k8s middleware message queue -> k8s pod
    • k8sに中にいる
  • 構築例
    • いろいろあって、、、いけてないところも、、、
    • 課題、httpやめたい
  • 検討したもの
    • Cloud Pub/Sub ACKの期限が最大10分
    • Cloud Tasks、アルファなので本番使えない
    • Redis、シンプルで早いけど必要な機能たりない
    • RabbitMQ、重いけど多機能。かわいい
  • まとめ

『コンテナ疲れ』と戦う、k8s・PaaS・Serverlessの活用法![Kazuto Kusama(Pivotal)]

www.slideshare.net

  • アンケートによると参加者の46%がコンテナを商用活用してる、、、?
  • そんなわけじゃないよね
  • 参加者偏ってる、選りすぐり、それでも46%
    • 平日昼間に参加可能
    • 5000円も払ってきてる
  • ゴール:正しいテクノロジースタックを選択してもらう知識を得てもらう
  • なんでコンテナが普及しないのか?
    • コンテナ技術、楽しいよね
    • コンテナいれると幸せになれましたか?
    • コンテナいれて業務は劇的に改善した
  • コンテナ辛い
    • Dockerfileつらい
    • 教えるのもつらい
  • コンテナ技術は抽象度が低い、エンジニアがカバーする必要あり
  • kubernetesはgoogleのborgが元、すばらしいけどエンジニアのスキルの高さが前提
  • SREも同じ、日本でやるには熱意と覚悟が必要
  • テクノロジーの流れ
    • 高い抽象化と自動化の繰り返し
    • 一度抽象化、自動化したものが戻ることはない
  • コンテナの次になにがくる?
    • より高度に抽象化、自動化されたもの
    • Dockerfile書かなくていい
    • 運用もみてくれる
    • 何も指定しなくても勝手にスケールしてくれる
    • あれ?
  • PaaS?昔からあるような?
    • Herokuは2007年
    • CloudFoundryは2011年
  • PaaSの多くは内部でコンテナ技術使ってるから、時代遅れとかじゃないよ
  • Serverless、コンテナ関係ない、、、?そうではない
  • CaaS、PaaS、Serverless、何を採用すべきか?
  • [CNCF Serverless Whitepapter](https://github.com/cncf/wg-serverless/tree/master/whitepaper
  • 目的をしっかり考えよう
    • 強靭性
    • スケーラビリティ
    • ステートレス、ステートフル
    • アプリの更新頻度
    • 既存資産の流用
    • Dev, Opsの人数
  • 潜在的なコストを考慮しよう
    • 誰もがイチからアプリを作れる恵まれた環境にいるわけではない
    • lift & shiftは楽だけど長期的にはコストかかるかも?
    • Serverless化するとインフラコストは下がるけど、アプリ書き換えコストに見合うとは限らない
    • ServerlessはRDBとの相性が良くない、LambdaだとDynamoDBのほうが向いてる
  • PaaSやserverlessはopinionated。プラットフォームにあわせて開発しないといけない、その代わり合わせると生産性はあがる
  • kubernetesはless-opinionated。自由度は高いが、、、生産性は?
  • Serverlessは究極のロックイン(今のところ)
    • コード自体は一般的な言語が使えるし、フレームワークもあるが
    • 仕組み上他サービスと組み合わせるので結果ロックイン
    • ロックインが別に悪いってわけじゃない
  • 得意不得意があるので組み合わせよう
    • ただし自動化はしっかりしよう
  • 「戦うWebデザイン」制約は創造性をはぐくむ
    • railsの設定より規約
    • 適度な制約があると本来すべきことに注力し、創造性、生産性を高められる

Istioと共にマイクロサービスに立ち向かえ![Aya Igarashi(Z Lab)]

speakerdeck.com

  • Istioの解決方法
  • Microserviceにありがちな問題
  • Microservices
    • よくあるモノリシックとの比較
    • スケールアウトしやすい
    • 変更しやすい
    • 大人数で開発しやすい
  • 銀の弾丸ではない、複雑になる
  • 複雑なサービスメッシュの管理が追いつかない、という問題を解決するOSS
  • サービスメッシュ:アプリケーション間でメッシュ上に交差するネットワーク
    • どうやって管理?envoyがappにくっつく
    • controle planeがenvoyに向かって情報書き換える
    • envoy
      • c++、L4/L7 LoadBalancer
      • ナウい機能ついてる
        • Lyftが開発
        • HTTP2, GRPC対応
        • API経由で動的に設定変更できる
        • 設定変更時にrestart不要
    1. ServiseMeshを制御しきれない問題
      • アプリケーションのコードにServiceMeshの設定が埋め込まれている場合
        • 修正毎に再デプロイ
        • 運用、開発双方に負荷
      • ServiceMeshの設定を分離
      • k8sにappをdeploy
      • k8s、init containr、iptableを書き換える
      • containers、app+envoyを立てる
    1. 鍵と証明書を管理しきれない問題
      • システムによってはアプリケーション間通信の暗号化は必須、、、
      • 鍵と証明書の生成、配布、更新、廃止に対応
    1. システムの全体像が把握できない問題
      • ドキュメントは更新されなくなるよね
      • 可視化ツールとの連携
        • metrics prometheus/grafana
        • traces: zipkin
        • ServiceGraph Graphbiz/Prometheus
    1. 障害発生時に何が起こるかわからない問題

      • 障害を起こすテストを起こすのはコストがかかる
      • 結局障害が起こるまで対策が打たれない
      • Fault Injection(chaos enginering)
      • Circuit Brakerで被害を最小限
  • istio入門チャート
    • GKEがらく
    • quickstartを参考にistioインストール
  • こまったとき
    • トラシューガイド
    • FAQ(めっちゃ充実)
    • StackOverFlowやGitHubのIssue

「Japan Container Days v18.04 Meetup」に参加した

はじめに

行ってきた。もちろん本編も参加した。

eventregist.com

感想

  • 会場提供はリクルートテクノロジーズさん、アルコールありでした
  • 翌日本編の事前登録&事前配布もあり、前日meetupとして有益な取り組みあり、素晴らしい
  • IppeiSuzukiさんのCNCFに投稿された記事の分析は面白い、もっと詳細な分析を聞きたかった
    • kubernetesは新たにレイヤを作り、その上か下か、という考え方ははじめて知った
  • Ryoma Fujiwaraさんの発表は個人的に示唆に富む、興味深い発表
    • ワンボタンデプロイ=自動化、チーム/組織でデプロイ&運用を考える姿勢良いですね
  • DataDogさんの話ももっと時間かけて聞きたい内容だった、DataDogさんだからこそ持つ情報がたくさん
  • 本編CFP出しての40分枠を5分に圧縮してもらってるので時間超過は堪忍な、という説明あり

以下、メモ。

CNCF(Cloud Native Computing Foundation)の最新動向 Ippei Suzuki

kubernetes導入事例分析

  • kubernetes.ioの導入事例を整理
  • CNCF、kubernetesだけに絞った、まずはkubernetes nativeに絞りたかった
    • docker
    • redhat,openshiftとかあるけど...
  • kubernetes導入の悩みはkubernetesだけじゃない
    • あえて新しいレイヤーを載せる意味とは?
    • ノースバウンド、サウスバウンド
      • SDN業界で使う言葉
      • あるレイヤーを境に、上半分か下半分かを指す
      • kubernetesのノースバウンドはアプリケーションそのもの
    • kubernetesの導入が目的じゃない、ノースバウンドのために導入し、運用が変わる
      • サウスバウンドのひと(情シス)にとってはレイヤー増えるだけ、メリットがない

Kubernetes導入、国別の分類

  • アメリカがぶっちぎり多いが。。。
  • ヨーロッパ
  • 中国(バイドゥ、JD、2社)

コンテナ化の対象は何か?

  • 会社のIT業務をコンテナファースにする決断、比率的に多い
    • とはいえ突然そうしたわけじゃないよね
  • データ分析基盤
  • インフラ(KubernetesをOpenStackに乗せた事例、サウスバウンド側の事例)

Kubernetes導入のプラットフォーム

  • オンプレとクラウドが半々ぐらい?
  • AWSよりGCPのほうが多い、たまたまか?
  • レガシーなデータセンターの上にkubernetes載せてる例もある
  • ベアメタルクラウドの上も
  • インフラのこと話してない会社もある(アプリケーションのことだけ)

Kubernetes導入事例紹介

  • Amadeus
  • 飛行機の予約システム
  • メインフレームの時代から、オンラインで飛行機予約システム出してた
  • 拠点はドイツ、世界中にデータセンターをおいてる
  • トランザクションが多い
  • 24/265
  • 以前はOpenShift
  • トランザクションを止めずに導入
    • マイクロサービス化の促進
  • 35万個のコンテナが動いている

エンジニアの異常な愛情 ~または私は如何にして心配するのをやめてワンボタンデプロイを愛するようになったか~ (Ryoma Fujiwara)

  • コンテナ関連の先進アーキテクチャ事業
  • RancherJPコアメンバー
  • 先行事例に学ぶKuberntes...

  • デプロイの重要性

    • デプロイされなければ、公開されなければ何も意味がない
  • ワンボタンデプロイ
    • sshログインなんでせずに、1回クリックするだけでデプロイできる
    • 頑張って作り上げてもいつのまにか使われなくなる
  • ワンボタンデプロイはなぜ使われなくなるのか
    • 環境ごとに後世に乖離が発生しまって動かなくなる
    • 失敗した時にリカバリできなくなる
  • どう解決する?
    • Docker+kubernetesでアプリケーション層の構成の差異を埋めましょう
    • パブリッククラウドを使えばカバーできそう?
    • 環境構成の乖離を防ぐのはインフラエンジニアの腕の見せ所
      • docker+k8sは強力
  • 失敗した時リカバリできなくなる問題
    • チームで頑張れ
  • ワンボタンデプロイのこだわる理由
    • 絶対に成功か絶対に失敗する、に近づけたい
    • 誰のせいで失敗した、は悲しい
    • AMデプロイしたらPM仕事にならない(魂抜ける)
    • 作業者/作業管理者がいると、作業者が非難されるのはつらいp
  • ピープルウェア/Effective DevOps

    • エラー大歓迎(from ピープルウェア)

      • チャレンジしてるってこと
    • 非難のない文化(from Effective DevOps)

      • 個人じゃなくて組織として考えるってこと
  • ワンボタンデプロイにこだわる理由(2)

    • 曖昧さを排除する

      • 作業前に実はこのコマンド事前に打ってるとか
      • 開発商用不一致を避ける
      • 継続的デプロイ、何が嬉しいかってすぐに戻せること
    • 個人を非難から守る

      • コードレビューするよね
      • 個人の責任が希薄化、組織として責任持つようになる

まとめ

  • デプロイ大事
  • ワンボタンデプロイ
    • 作業者の負担軽減
    • 個人の批判集中軽減
    • チャレンジが継続的に行われ、イノベーションが起きる組織に
    • 失敗から学べる組織に

~Dockerfileの開発を劇的に楽にする~ Dockerfile開発環境 EDGE (Tatsunori Saito)

www.slideshare.net

  • TIS
  • Docker、コンテナ使うメリット
    • ホスト環境汚さない
    • 迅速にアプリ起動
    • 高いポータビリティ
  • Dockerfileからコンテナイメージができるまで
    • docker buildコマンド、パラメタ指定、大変
    • 期待したコンテナかのテスト、execで入るとか、修正してまたbuildするとか
    • やってられっかい!
  • Dockerfile開発環境を作った
    • Elastic dockerfile Generating environment
    • TDD実践できる
      1. テストコード(Serverspec)
      2. Dockerfile書く
        • ビルド変数はiniファイルで定義
      3. bin/build test
      4. bin/edge spec build_test
    • https://github.com/bbrfkr/edge

CoreOS Container Linuxで始めるベアメタルKubernetes ( Shoichi Kagawa)

speakerdeck.com

  • coreos
  • bootcube
    • self hosted kubernetes
      • k8sを使ってk8sのマスターコンポーネントをデプロイする
      • kubernetes meetup tokyo #8で詳しい解説されてる
  • MatchBox
  • Typhoonというterraformモジュール
  • 学習コストは高い
    • 一度環境を整えると楽になるよ
    • Typhoonカスタマイズしたいな

そろそろLambda編(CI/CD編) Akira Koyasu

www.slideshare.net

  • AWSの話です
  • EmotionTech
  • AWS LambdaをCI/CDする
  • やりたいことの確認(絵に意味はない)
    • ファンクションを書いて、リポジトリへpushしたらチェンジセットのステータスによって確認環境やら本番環境やらにデプロイできる
    • 😕
  • AWS SAM
    • 依存リソース含め管理できる
    • ローカルはSAM Local
  • CodeBuild / CodePipeline
    • お金払っただけビルドできる

Kubernetes 採用トレンド 2018 (Masahiro Hattori)

www.slideshare.net

  • https://www.slideshare.net/MasahiroHattori2/docker-adoption-in-datadog-japan-container-days-v1804-20180418
  • Datadoc
  • @toolyee さん
  • 用語
    • Adopter: Docker採用ユーザー、稼働ホスト50%以上
    • Dabbler:Docker利用しているが、50%以下?
    • Aamdoner:Dockerを過去に使ったことがあるユーザー
  • Dockerの利用者、1年に40%増
    • Datadocの中で15%ユーザーがdocker使ってる
    • 規模が大きい企業ほどDocker採用進んでる
  • コンテナのオーケストレーターは?
    • Dockerを稼働させている40%のユーザーがオーケストレーターを利用
    • Kubernetesのシェアは41%
  • オーケストレーターを使うことでDockerホストのライフタイムを40%縮小
    • kubernetesがコンテナのライフタイムを平均で1.5日まで縮小
  • コンテナ集積度
    • すべてのコンテナユーザーでは1ホストあたり平均7コンテナが稼働
    • 25%のユーザーのうち14以上のコンテナを稼働させてもいる
    • ECSだと3コンテナ
  • ...最後かけあし、データたくさん!!!もっとみたい!

安全で軽いコンテナを目指して minachi katsuya

  • @int_tt さん
  • Dockerfile
    • 雑に書いてもちゃんと動くのすごい
    • レイヤー数減らして軽くする
    • 便利な書き方、使い方紹介します
  • buildするためにinstallするの遅いよね
  • dockerのキャッシュ
    • layerは親子関係、順番がある。親に変更が入ると以降のキャッシュは使わない
    • add,copy以外のコマンドはコマンド事態に変更がなければキャッシュを利用する
    • add,copyは転送されるファイルのチェックサムを見る
  • package installを先に持ってこよう
  • multi-stage-buildめっちゃ便利
    • 複数のビルドコンテキスト間でファイルのやり取りができる
    • build専用ステージ作って、生成物だけ取り出したり
    • docker-composeで結合テストもできる
  • まとめ
    • layer cacheをうまく使おう
    • build時にtestまわそう
    • 結合テストもdocker-composeで実行
    • テスト通過済みの安全で軽いイメージを維持
    • docker公式にbest practiceに全部描いてあった
    • google container-struture-test

gitlab.comのgitlab-ciとmkdocsでmarkdown + pagesでの静的サイト作成がドチャクソ便利

はじめに

gitlab.comのgitlab-ciとmkdocsでmarkdown + pagesでの静的サイト作成がドチャクソ便利

です。

さて、GitLabではgitlab-ci機能を内包しており、.gitlab-ci.ymlというファイルをリポジトリのルートに置くだけでCIを実現できます。

about.gitlab.com

GitLabが実現しようとしている世界はこちらを参照してください。

blog.chaspy.me

自前でgitlabを運用するのであればrunnerの設定が必要ですが、gitlab.comではshared runnerが使えるのでその準備も不要です。

本当に5分で実現できるので、markdownをgitlab pagesとしてデプロイしてみましょう。

使用するビルドツールを選択する

GitLab pages exampleというグループから好みのツールを選択し、行った先の指示に従いましょう。

gitlab.com

今回はmkdocsを利用します。

gitlab.com

Forkする

Forkしましょう。

Fork後は、関連付けを解除しておきましょう。

Setting -> Advanced Settings -> Remove fork relationship

f:id:take_she12:20180418101506p:plain

プロジェクト名を変更する

任意のプロジェクト名に変更しましょう。

今回はmkdocs-sampleとしてみました。

f:id:take_she12:20180418101759p:plain

urlとtitleを変更する

mkdocs.ymlを変更します。

gitlab.com

1番最初はgroup名か自分のuser名を指定します。

コミット後、CIが実行され、passするとページが公開されています!

f:id:take_she12:20180418102144p:plain

http://chaspy.gitlab.io/mkdocs-sample にアクセスしてみましょう。

chaspy.gitlab.io

markdownを編集する

docs以下にmarkdownファイルがあるので、こちらを編集しましょう。

urlを追加するcommitをしてみました。

gitlab.com

CIがまわりきれば更新されます。

注意

shared runnerは共有リソースなので、込み合っていたり、gitlab.comがbusyだとpendingとなることがあります。昨夜1時頃実施したんですが、CIがまわったのは朝8時ごろでした。そういうこともあるので、pendingになった場合は一晩寝かしてみてください。

どうやって実現しているのか

そもそもgitlab pagesはどうすれば利用できるのか?公式ドキュメントを見てみる。

docs.gitlab.com

今回やった手順しか書いてないですね。

.gitlab-ci.ymlを眺めてみる。

image: python:alpine

before_script:
  - pip install mkdocs
  # Add your custom theme if not inside a theme_dir
  # (https://github.com/mkdocs/mkdocs/wiki/MkDocs-Themes)
  # - pip install mkdocs-material

pages:
  script:
  - mkdocs build
  - mv site public
  artifacts:
    paths:
    - public
  only:
  - master

mkdocs buildを実行すると、docs以下のディレクトリをbuildし、siteというディレクトリでhtmlが生成される。

www.mkdocs.org

siteというディレクトリをpublicにrenameし、artifactsとして登録してやる。

gitlab pagesではpublicディレクトリのみを対象とするようです。根拠はここ。

docs.gitlab.com

pagesというjob名であること、publicというディレクトリであること、artifactsとして登録すること、この3つがあれがgitlab pagesとして公開されるようですね。

docs.gitlab.com

おわりに

gitlab-ciや、buildツールであるmkdocsの知識がなくても、GitLab Pagesと組み合わせて静的サイトとして簡単に公開できます。ちょっとしたポータルページをささっと作ることができるのは本当にすごい。

gitlab-ci含め、最近のGitLabができることはこの本を参考に。

GitLab実践ガイド (impress top gear)

GitLab実践ガイド (impress top gear)

blog.chaspy.me