ServerlessDays Tokyo 2019でWorkshop 03「Knativeで作るDIY FaaS」を担当しました #serverlessdays

0 Shares

ServerlessDays Tokyo 2019に関わられたすべてのみなさんお疲れさまでした!

僕は主に10/21(月)のWorkshop03「Knativeで作るDIY FaaS」のコンテンツ作成と当日の解説・進行に携わりました。22(火・祝)のカンファレンスではスタッフとしてうろうろしたり、Knative本を頒布したりしていました。

大規模なワークショップを作ったり運営したりするのは初めてだったので振り返ってつぎにつなげようと思います。

概要

  • 概要説明のスライド
  • ワークショップコンテンツの本体
  • カンファレンスでKnative Servingのお話をされていた@toversus26さんにいろいろ教えてもらってKnativeのDesign Docs見れるようになったのでもっと正確に、深く、理解したい

ServerlessDaysでワークショップを担当することに対する思い

これを実現したかったからです。

ServerlessDaysも何か話したりハンズオン担当したり(?)、海外でも登壇できたらなぁと思っています。

どちらかというと登壇そのものというよりは、人に話したくなったり、話してフィードバックもらいたくなるような好きな技術に常に触れていられたら幸せという気持ちの方が強いです。

そういうハンズオンやContributor Dayも含め、好きになる可能性のある技術に触れたり、どっかの誰かがなんか言ってる技術が自分の身近な課題を解決できるものと感じられるようになる場を作るというのにも興味を持ち始めました。

Serverless Meetup Tokyo #11 で「入門 Knative 〜KubernetesとServerlessとの出会い〜」を話してきました #serverlesstokyo

去年、一昨年とワークショップに参加して、僕はカンファレンスで話を聞いているよりも手を動かす場の方が好きでした。そこで今度は自分がそういう場を提供できるようになりたいという思いがありました。

改善点はあるとは思うものの、まずは思いを持ってServerlessDaysのワークショップを担当できて幸せでした。

テーマ

GCP

今年取り組んでいたKnativeを使ったワークショップを準備しました。題材はOSSなので実行環境はどこでもよかったのですが、つぎの理由からGKEを中心にGCPのサービスを使っています。

  • AWSとMicrosoftは毎年ワークショップあるのにGoogleはないので自分がやろう
  • 会社でGCPたくさん使っているものの、普段はGKEのクラスタ構築したりgcloudコマンド叩いたりすることが少ないので馴染みたい
  • 環境やマシンスペック揃える観点でローカルは避けたい、そしてGCPのCloud Shellが必要十分なことは技術書典で本を書く中で検証済みだった

DIY FaaS

KnativeでFaaSを作るというテーマにしたのはつぎの理由からです。

  • コンポーネントの各機能を動かしているだけではなんとなくいろいろな機能があって複雑なものという印象で終わってしまう(特に普段FaaSを触っている人から見ると)
  • リソースの抽象化は一面でしかないので抽象化好き、嫌いの好みの問題で終わってしまう(特に普段プラットフォームの運用・開発をしている人から見ると)

こういう背景があり、プラットフォームを作り運用する人の観点とプラットフォームを利用する開発者という立場を明確に分け、両方の立場からKnativeやKnativeがベースとなっているプロダクトに触れられるようにというコンセプトを強めに押し出しました。

  • Knative、Tektonの各コンポーネントを理解するステップ
  • KnativeベースのOSSを自分たちのプラットフォームにインストールして使うステップ
  • OSSを組み合わせてプラットフォームを構築するステップ
  • Knativeベースのマネージドサービスを使うステップ

という構成がそのコンセプトを具体化したものです。

対象参加者

Serverlessコミュニティ向けに行うということを考えたときに、Kubernetesをどこまで前提知識にするかは少し迷いました。必要最低限のリソースやコンセプト的な部分は軽くスライドで触れることにしました。

そして募集の段階で対象はつぎのように明示しました。それ以外の人の参加を拒否する目的ではない旨を話した上で参加者に挙手してもらうと、実際は右に書く人数が該当していました。

  • 普段Kubernetes上でアプリケーションを開発している方: 数名
  • プラットフォームを開発している方: 数名
  • AWS Lambda、Azure Functions、Cloud FunctionsなどFaaSが好きな方: 参加者40人くらいほとんど
  • Goでアプリケーションを開発している方: 数名

想定とずれてはおらず、自分のできる範囲で用意すべき材料は用意したという感じでした。こういうときはやはりフィードバックがほしいですし、自分で質問項目を準備して具体的なフィードバックを求めるべきですね…。

進行

つぎのような感じに進めました。

  • コンテンツに入る前にスライドで概要を説明
  • 基本的に僕が前で解説・実行しながら進める
  • 自分のペースで進めたい人はどんどん先に行って大丈夫

ゆっくり目に進めたつもりが進行が早かったとの声もあり、どう進めるのがよいのか考えていました。社内で毎週Go(とGCP)の知見を共有したり議論したりするGo Fridayという勉強会があり、このワークショップを紹介するとともに、golang.tokyo、Women Who Go Tokyo、GCPUGなどでどのようにワークショップを運営されてるのかを聞いてみました。

僕の進め方に足りてないと思ったのはこういうのです。

  • 前でやってから参加者の方々がコマンド動かす時間を確保する
  • step毎の完成イメージや動くものを先に見てもらう

前でやるなら見てもらうフェーズと操作してもらうフェーズを分けないと前見たりPC見たり大変で進められない!というのに自分で気づけなかったのは謎です。

あとはコードを書くタイプならTODOが書いてある枠組みを配ったり(tenntenn/gohandson)、他にもコードラボ形式のもあると教えてもらいました。

今回僕がやったCloud Shell上で進めていくものであればチュートリアル形式もあったりするので活用するのがよさそうです。

少なくともGitHubとCloud Shellを行ったり来たりしてYAMLの中身を保存してもらうよりはCloud Shellでgit cloneしてもらう方がよさそう。そうするとkubectl applyをひたすら打つだけになる気もする一方で、YAMLの中身をコピーして保存するときも必ずしも中身が読まれるとは限らないですね。

今度は11月頃に社内でやる予定なのでやっていき!!

振り返り

Good

  • 本番が始まるまでになんどもコンテンツを見直せた
  • 実際に自分でやってみながら致命的なミスを修正できた
  • ロールの分類とstepの位置付け明確化
  • ワークショップがまとまりあるアウトプットとして残るのはなんとなくうれしい
  • スライドを作るのが速くなった気がしたけど単に使い回し比率高いだけの気もする

Challenge

  • 進行方法改善
  • Eventing薄めなのでもう少しやりたい、cloudevents/sdk-goに馴染みたい
  • ワークショップでDIYしたFaaSはこの辺に書いてるとおり課題があるので、現実的な課題解決に耐えうるものを作りたい

今後

カンファレンスでKnativeの話をされた方にいろいろ教えていただきかなり学びがありました。

実際にSREとしてインフラや開発者の声に向き合いながらKnativeの本番環境での活用に向け検証を進められているようで、掘り下げも素晴らしかったです。定期的に話を聞きに行きたい。

教えてもらった中でもこのページknative-users@knative-dev@でGoogleグループをたどれて、「参加する(devは人が承認)」とTeam Drive内のDesign DocやMTGの議事録などいろいろ見れるようになるのは超重要情報でした。公式のドキュメントも古くなってる部分もあるとのことで、実装とこの辺りの情報を見ながら理解をアップデートしていく所存です。

今後はKnativeももちろん追いつつ、以下の記事でも書いてるようにプラットフォームエンジニアへの闘争を推進すべくKubernetes自体の理解に軸足を置けるとよいかなぁと思っています。

2019年7〜9月ふりかえり 〜プラットフォームエンジニアへの闘争〜

0 Shares

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です