Cloud Penguins

Flying penguins in the cloud.

Miroの操作が直感的じゃないと感じた時はNavigation設定を見直そう

Miro Advent Calendar 2021の5日目。このブログだとMiroネタ2回目。

前回: jaco.udcp.info

「Miro、触ってみたけどなんかクセがあるというか、直感的に操作できない」 という意見を聞くことがある。そんなときは、一度設定を見直してみようという話。

Miroは直感的に操作できない?

最初同僚から「Miroの操作が直感的じゃない」と聞いたときは戸惑った。個人的には群を抜いて直感的に操作できる便利なツールだと感じていたので、「え、どこが?」 と。

が、ある時所有している他のPCから使ってみたところ、どうもいつものように操作ができない。マウスホイールを使うと拡大縮小じゃなくて上下に動くし、マウスのドラッグでボードの移動を行うこともできない。なんだなんだ、突然仕様変更されたのか? と慌てたが、結論としてはNavigation modeに問題があった。

Navigation modeを見直そう

画面左上のタイトル横にある設定マーク(新UIの場合。旧UIだと右側) をクリックし、Preferences -> Navigation modeをクリックする。 あるいは何もないところで右クリックしたときに出てくるメニューにもNavigation mode設定がある。

f:id:jaco-m:20211205024247p:plain

これを選択すると、このようにNavigation modeをどうするかという設定が出てくる。

f:id:jaco-m:20211205024257p:plain

もしマウスを使っているのであればMouse、トラックパッドを使っているのであればTrackpadを選択したほうが良い。

前述した操作の違和感は、マウスを使っているのにも関わらずTrackpadにモードが設定されていたのが原因だった。 ここの初期値がどのように決定されるのかはまだよく分からない…。

ちなみにマウス派?トラックパッド派?

ところで他の人はどちらを使っているのだろう。 個人的にはどのWindows機もトラックパッドの出来が悪いので、Windowsであればマウス一択かなと思っている。 Macであればトラックパッドが秀逸のため普段はマウスを使わないことも多いが、Miroを使うときはマウス欲しいなと感じることが多い。 特にオブジェクト間でラインをつなぐなどの細かな操作をやるときはマウスのほうが快適に出来る気がする。

追記

最近このナビゲーション設定が機能変更され、Auto switchというものが導入された。また、マウス操作時のボタンが変更になっている。

以下のエントリーも参考に

jaco.udcp.info

人類はWeb会議に向いていないので、もっとMiroを活用すべき

Miro大好きjacopenです。エンタープライズなIT界隈ではおそらく日本でトップクラスにMiroを愛している自信がある。

さて今日はMiro Advent Calendar 2021の3日目。

今日は、人類がいかにWeb会議に不向きかという話と、そのギャップをMiroで埋めようという話。あとは自分が関わっているカンファレンスでMiroを使いまくっている話をする。

Web会議の8割はXX

コロナ禍でだいぶ定着したWeb会議。でも、個人的には世の中のWeb会議の8割は上手くいっていないと思っている。数字に根拠はないけど。 何を持って上手くいっていないとするかだが、「対面の会議と比較して伝えられる度合いが低下している」とすると、8割くらいはそれに該当すると言っても過言ではないだろう。

何故そうなるかというと、基本的に人は言葉だけで物事を正確に伝えることはできないからだ。

人間の会話において、話し手は頭の中に構造化された情報があり、「今何について話しているか」という位置情報をもった状態で話す。まあ中には位置情報を持たず思い浮かんだことを喋っちゃう人や、脳内の位置情報がどんどんズレていく人もいるがそれはまた別の話。

一方聞き手は必ずしも同じ構造化された情報を持っているとは限らない。そのため、聞き取った内容から情報を組み立てて行く必要がある。また、話し手が持っている位置情報は共有されないため、話の流れから位置情報を推測し、継続的に更新していかなくてはいけない。

しかし、声というのは単位時間当たりに伝えられる情報が少ない手段だ。日本語だと1秒当たり十数文字分しか伝えられない。データ通信に置き換えるとわずか数十byte/sec。声のトーンなど付加情報を加味しても、とてもとても少ないわけだ。必然的に、伝える情報は断片的なものになってしまう。

f:id:jaco-m:20211203000057p:plain

これらは対面でも同じことが言えるのだが、人間というものは五感を働かせることによってある程度のエラー訂正が可能だ。声による情報の他にボディランゲージや表情によって情報の補完が可能なほか、聞き手の表情などから正しく伝わっていないことを読み取れれば、追加の情報を付加したり、分からないところはどこか聞き出すことも可能だ。対面の会議が好まれる理由はこのあたりにある。

これがWeb会議になってしまうと、声以外の情報がばっさり切り落とされてしまう。人間が備えているエラー訂正機能が働かなくなってしまうのだ。 そのため、聞き手の脳内で情報の構造化ができないまま話が進み、位置情報もズレてしまう。

他にも問題がある。対面のミーティングと違い、Web会議では聞き手の環境をコントロールしづらい。聞いている間に宅急便がくるかもしれないし、猫が来ることもあるし、横で開いているTwitterに面白画像が流れてきて注意が逸れることもある。対面の会議でTwitterを開いている人は比較的少数だろうが、Web会議では相手がどういう状況か知ることは難しいわけだ。たとえその注意が逸れている時間が十数秒であっても、先ほどから書いている会話の位置情報をズラすには十分な時間だ。

この話し手と聞き手の位置情報がある一定以上ズレてしまうと、聞き手はその段階で一切の情報を受け取れなくなってしまう。

例えば、車に乗って見ず知らずの場所に出かけても、移動した経路を覚えていればおおよその位置は分かる。しかし、しばらく目隠しをされていたらどうなるか。どこに居るか全く分からなくなってしまうだろう。この状態でいくらその土地の説明をされたところで、要領の得ないものとなってしまうだろう。

「開催したはいいが効果が得られないWeb会議」はこうやって生まれていく。

f:id:jaco-m:20211203000130p:plain:h300

コンテキストを揃えるべし

コミュニケーションにおける、この位置情報のことをコンテキストと言う。 正確には、コンテキストの一部と言った方が良いか。元々持ち合わせている知識や文化的な背景、会話の文脈などを総じてコンテキストと表すことが多い。

コミュニケーションで最も大事なことは、このコンテキストを共有し、各人の立ち位置を揃えることにある。

コンテキストの共有には様々な手段があるが、コストが低く効率よく行えるのは 図解をすることだ。

f:id:jaco-m:20211203002447p:plain:h200

あらかじめ図で構造化した情報をダンプし、共有することで聞き手は声から情報を構造化する手間が省け、より重要なことに脳のリソースを割くことができる。

また、声で説明しながら同時に図に起こしていくのも良い。これにより、話し手と聞き手の位置情報を細かく同期させることが可能となる。

そして、少なくとも自分が知っている限り、最もこの取り組みを効率よく、気持ちよく行えるのがMiroだ。

Miroだとこんなに良い

情報をダンプして共有するだけであれば、別にMiroでなくても可能だ。既に多くの人が、Google Docsで議事録を書いたり、PowerPointやGoogle Slidesでスライドを共有しながらWeb会議をしているだろう。

しかしこれらが最適な手段かというとそうではない。

  • WordやGoogle Docsの欠点
    • 文字が主体。文字を読んで理解していくのは脳の負担が大きく、時間がかかる。
    • 構造化した表現が難しい
  • PowerPointやGoogle Slidesの欠点
    • スライド1枚あたりの情報量が限られてしまう。
    • 1枚当たりの情報量を増やすと読みづらい。
    • 情報量を減らすと、スライドを見逃してしまったときのリカバリーが難しい。
    • リアルタイムな追加がやりづらい

Miroだとこれらの欠点を良い感じにカバーできる。

まず会議前に、あらかじめ共有しておくべき情報を書き込んでおく。文字で書いてもいいし、図にしてもいい。 情報量も、冗長でない限りは多少多くなっても構わない。見る人が拡大縮小して合わせられるからだ。

f:id:jaco-m:20211203005003p:plain

会話しながらリアルタイムに図解していくのも可能だ。以下の例は実際に会話しながら起こしたアーキテクチャ図だ。

f:id:jaco-m:20211203005715p:plain

画像を貼るのも容易だし、アイコンのライブラリが充実しているので検索するとだいたい欲しいアイコンが出てくる。

また、話し手だけでなくて聞き手側にも積極的に書き込んでもらうと良い。付箋紙を初めとした使いやすいツールが充実しているので、ブレインストーミングや振り返りにも最適だ。

聞き手側にも参加して貰うことで、少なくともYouTubeやTwitterを見ていて会議に集中していないという状況を減らしやすい。声ではなかなか質問しづらかった事項も、「気になったことがあれば付箋紙に書き出してください」と言っておけば、聞き手側も心理的な障壁が下がる。心理的障壁を下げることはコンテキストのズレを無くしていくにはとても重要だ。

f:id:jaco-m:20211203010330p:plain

組織におけるMiroの活用事例

Miroめっちゃ便利という話をしたところで、自分のMiroの活用について紹介。

自分がCo-Chairとして関わっているCloudNative Daysというクラウドネイティブ技術のカンファレンスがある。先日ちょうどCloudNative Days Tokyo 2021(CNDT2021) を開催したところだ。

event.cloudnativedays.jp

このカンファレンスの実行委員会では、昨年からMiroを積極的に活用している。上記Miroの解説にも、実際にCNDTで使ったMiroボードのスクショを使っている。

使い始めたきっかけ

もともとMiroは自分が前職(Pivotal / VMware)の時から仕事で使い倒していた。

VMwareには VMware Tanzu Labsというサービスがあり、Leanプロダクト開発とXPを組み合わせたLean XPという手法でアプリケーション開発やモダナイゼーション、プラットフォームの支援を行っている。前身のPivotal Labsの体験談をみてもらうと分かるが、ホワイトボードや付箋紙をガッツリ活用してコミュニケーションを取るスタイルを取っている。

コロナ禍以降このサービスもオンライン化を余儀なくされたが、ホワイトボードと付箋紙無しにには仕事ができない。そこでMiroを活用することで、従来と同じようなスタイルで継続することができた。

同じくオンライン化を余儀なくされたのが前述したCloudNative Days。イベント自体もそうだし、実行委員会も直接集まるのが難しくなった。Google DocsとZoomを使ってオンラインミーティングに切り替えたものの、直接会うのと比べるとどうしても意思疎通が難しい。些細な認識違いを発端とするすれ違いも多く発生した。

じゃあどうするか。ここは本業で使っているのと同じく、Miroを活用するのが最善策だろうと。そう思って導入を決めた。

CloudNative DaysにおけるMiroの活用

f:id:jaco-m:20211203011603p:plain

CloudNative Daysの実行委員会では、MiroのTeamプランを利用。

コミュニティ主体のイベントであり予算が潤沢にあるわけではないので、アカウントを所持しているのはアクティブ率の高いメンバーに限っているが、持っていないメンバーに対してもボードのリンク共有を活用して参加してもらっている。

チームに分かれタスクを分担しているが、主に以下のような用途で使われている

イベント企画

f:id:jaco-m:20211203012249p:plain:h400

どんなテーマにするか、どんなコンテンツをやるかといったイベント企画やアイディア出しに利用するパターン。マインドマップや付箋紙を使ってどんどん書き出していく。

前述したWeb会議を効率化する目的もあるが、もう一つ大きな目的としては非同期のコミュニケーションがある。

実行委員はそれぞれ本業を抱えた上でボランティアで参加しているため、ミーティングの時間を潤沢に取るのは難しい。スケジュールを合わせるのもなかなか困難だ。そこで、MiroとSlackを活用して出来る限り非同期でコミュニケーションを行うことで、負担を軽減するよう努めている。

技術的なディスカッション

f:id:jaco-m:20211203013104p:plain:h400

CloudNative Daysでは、オンラインイベントのプラットフォームを内製している。 また、配信についても技術を持った実行委員会メンバーが主体となって行っている。

インフラからコンテナを初めとしたミドルウェア、そしてアプリや配信技術まで、上から下まで幅広いレイヤーのディスカッションを行う必要があり、図を使ったディスカッションは必要不可欠だ。

振り返り

f:id:jaco-m:20211203013306p:plain:h400

より良いカンファレンスにしていくためには、カンファレンス開催後の振り返りは絶対に必要な取り組みだ。実行委員会全体、そして各チームごとに振り返り(KPTを利用) を行い、次への改善へとつなげている。

振り返りでは付箋とタイマー機能を利用している。

コンテンツとしてのMiro

CloudNative Daysでは、実行委員だけでなく一般参加者も参加できるコンテンツとして、Discussion BoardやJob BoardをMiroの埋め込みをを活用して行っている。

f:id:jaco-m:20211203014432p:plain:h400

テーマごとに参加者が質問を付箋で書き込み、それに対して知見を持っている人が付箋で返信していく。同期ないしは非同期のオンラインコミュニケーションを参加者も一体となって行うための取り組みだ。

オフライン開催していたCloudNative Days Tokyo 2019で開催し盛り上がった、ホワイトボードを使って自由にディスカッションをするCloud Native Deep Diveという取り組みが元となっている。

f:id:jaco-m:20190723134414j:plain:h200 f:id:jaco-m:20190723144146j:plain:h200

デブサミでの活用例

別イベントだが、Developers Summit 2021でやったパネルディスカッションでもMiroを活用して大変盛り上がった。

アーカイブは見られないようだが、Togetterのまとめを見ると盛り上がりの様子が分かる。

togetter.com

まとめ

Miroほんと最高なので是非活用して欲しい

HashiCorpに入社しました

本日Senior Solutions Engineerとして、HashiCorpに入社しました。

f:id:jaco-m:20210812121022j:plain

元々前職、前々職からHashiCorpのOSSプロダクトを利用していたことや、The Tao of HashiCorpという明確なプロダクトのビジョンを持っている点に魅力を感じて決めました。

HashiCorpもソフトウェアベンダーではあるのですが、競合するというよりは、どのベンダーのプロダクトとも上手く組み合わせてワークフローを作っていけるというプロダクト作りをしている点(Simple, Modular, Composable) も、CloudNative Daysをはじめとしたコミュニティ活動を行っている身としてはとても合っているなと感じています。

手始めに自宅のvSphere環境をTerraform管理に移行していくところから始めています。VaultもConsul使う形に作り替えていこうかな。

まずはHashiCorpプロダクトについて深く学んでいくオンボーディングの期間に入りますが、これまで以上に発信していければなと思っていますので、今後ともみなさまよろしくお願いします!

Tanzu Kubernetes Grid 1.4を新規構築した

先日Tanzu Kubernetes Grid 1.4が登場

tanzu.vmware.com

TKG1.3.1からのアップグレード方法はmaking先生が書いているのでそちらを見てもらうとして、自分は環境作り直しをしたかったので新規構築してみた。

CLIのセットアップ

まずは tanzu CLI等必要なものをセットアップ。基本的には以下のドキュメントを参照。

Install the Tanzu CLI and Other Tools

Customer connectからVMware Tanzu CLI 1.4.0 CLIをダウンロード(環境に応じてダウンロードするものは変わる)

https://customerconnect.vmware.com/en/downloads/info/slug/infrastructure_operations_management/vmware_tanzu_kubernetes_grid/1_x

そして tanzu のインストールとtanzu pluginのセットアップ、ytt などのCarvel toolを入れる流れ。

OVAテンプレートのダウンロードとアップロード

次にCustomer connectからOVAテンプレートを持ってくる。UbuntuもしくはPhoton、あるいはその両方をダウンロードしておく。

f:id:jaco-m:20210912175126p:plain

ダウンロードし終わったら、 vCenterからOVFテンプレートのデプロイ でデプロイ。その後テンプレートに変換 を行う。

f:id:jaco-m:20210912175426p:plain

このダウンロード&アップロード&変換は govc コマンドを使ってCLIで行うことも可能。そのあたりはmaking先生の記事を参照

Management Clusterのデプロイ

まずはManagement Clusterをデプロイする。CLIを使う方法とUIを使う方法の2つあるが、今回は初回インストールということもありUIを利用する。以下のコマンドを実行すると、 localhost:8080でUIが立ち上がるのでブラウザでアクセスする。もしも踏み台サーバ等で実行している場合は、sshのポートフォワード 例: ssh <踏み台サーバーIP> -L 8008:localhost:8080 を活用するなどしてブラウザから繋ぐと良い。

tanzu management-cluster create --ui -v 9

このような画面になるので、今回はvSphereを選択。ちなみにAWSとAzureを選ぶこともできる。

f:id:jaco-m:20210912175957p:plain

設定画面に入るので、必要項目を入れていく。まずはvCenterの設定。SSH PUBLIC KEYには、今後メンテナンス等でVMに繋ぐためのSSH公開鍵を入れる。

f:id:jaco-m:20210912180232p:plain

次にManagement Clusterの設定。インスタンスタイプはmedium以上が推奨。

f:id:jaco-m:20210912180316p:plain

どうやらTKG1.4から、Control planeのLBにNSX ALBが利用可能になった様子? (これまではkube-vipのみだった)

f:id:jaco-m:20210912180419p:plain

  1. VMware NSX Advanced Load Balancer のところは、NSX ALB利用者向けの設定なので今回は空欄

  2. MetadataもOptionalなので空欄で行ける。

RsourcesのところではvCenter上のリソースを指定。VMフォルダ、リソースプールは予めTKG向けに作っておくのがおすすめ。

f:id:jaco-m:20210912180908p:plain

次にネットワークの設定。作られたManagement ClusterのVMがぶら下がるvCenter上のネットワークを指定する。Cluster service CIDRやCluster pod CIDRは特に理由がなければそのままで良い

f:id:jaco-m:20210912181014p:plain

7 Identity Managementは、認証を外部のプロバイダーにしたい場合に設定する。この過去記事等を参照。

Auth0でTKGのクラスタを認証できるようにする - Cloud Penguins

OS Imageは先ほどアップロードしたOVAを指定。ubuntuもしくはphotonが選択出来る。

f:id:jaco-m:20210912181206p:plain

Register TMCはTanzu Mission Controlが利用可能な方は設定。

一通り設定が終わったら次に進める。すると設定の確認画面が出るので、下の方にある CLI Command Equivalent の内容をメモっておく。これは後々、CLIでのインストールを行う際に有用になる。

DEPLOY MANAGEMENT CLUSTERをクリックしてセットアップを開始。デプロイが終わったら以下のようにVMが作られていることが分かる。

f:id:jaco-m:20210912181505p:plain

Tanzu Kubernetes Cluster(Workload cluster)のセットアップ

次に、実際のワークロードを載せていくKubernetesクラスタを作る。参考にするドキュメントは以下。

docs.vmware.com

クラスタを作成するには、コンフィグファイルを作成してtanzuコマンドでデプロイする形になる。コンフィグテンプレートはドキュメントに記載されているのでコピーし、ファイルとして作成しておく。 今回自分は以下のような設定にした。環境に応じて適宜変更すること。

# CLUSTER_NAME:
CLUSTER_PLAN: dev
NAMESPACE: default
CNI: antrea
IDENTITY_MANAGEMENT_TYPE: none

#! Node configuration
#! ---------------------------------------------------------------------

VSPHERE_NUM_CPUS: 2
VSPHERE_DISK_GIB: 40
VSPHERE_MEM_MIB: 8000
CONTROL_PLANE_MACHINE_COUNT: 1
WORKER_MACHINE_COUNT: 2

#! ---------------------------------------------------------------------
#! vSphere configuration
#! ---------------------------------------------------------------------

VSPHERE_NETWORK: TKG
VSPHERE_SSH_AUTHORIZED_KEY: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQClNV5DBMYmOo5pYMpYE0PzXAFlLbYT46s6a7sGZdr9FIecJakrTtPVm6Po3uFL6qURi6uRQ8VsgeZGzZWWft8yJs1JdTcem8+KIiCenisTT7m9dRaX3EMdvhHyDtFGPSdGSq+blvgKo+HaHUem+Sx8R1lZAESzlZHjCwDxpZc5F/BkB4Jn+WiRgTeMwavOp0FJedNraLwZIHJ9h4kKV5uxIt3VgD5pHMotzjGJXDd2+jrcX6I/gQ/Cq1mXtvIMRoy72vpwF0r2knt1DrOOGi/Z029ZiPbQJl8HjbQSx/7kYPlw+ZI5W5afMSlwcs8qb3SR5ofF06gUftb3Uq/ziD2j                                                               VSPHERE_USERNAME: administrator@vsphere.local
VSPHERE_PASSWORD: <PASSWORD>
VSPHERE_SERVER: vcenter.udcp.run
VSPHERE_DATACENTER: Datacenter
VSPHERE_RESOURCE_POOL: tkg
VSPHERE_DATASTORE: vsanDatastore
VSPHERE_FOLDER: tkg
VSPHERE_INSECURE: true
VSPHERE_CONTROL_PLANE_ENDPOINT: 10.9.11.101

#! ---------------------------------------------------------------------
#! Machine Health Check configuration
#! ---------------------------------------------------------------------

ENABLE_MHC: true
MHC_UNKNOWN_STATUS_TIMEOUT: 5m
MHC_FALSE_STATUS_TIMEOUT: 12m

#! ---------------------------------------------------------------------
#! Common configuration
#! ---------------------------------------------------------------------

ENABLE_AUDIT_LOGGING: false
ENABLE_DEFAULT_STORAGE_CLASS: true
CLUSTER_CIDR: 100.96.0.0/11
SERVICE_CIDR: 100.64.0.0/13

# OS_NAME: ""
# OS_VERSION: ""
# OS_ARCH: ""

#! ---------------------------------------------------------------------
#! Autoscaler configuration
#! ---------------------------------------------------------------------

ENABLE_AUTOSCALER: false

コンフィグファイルの編集が終わったら以下のコマンドでデプロイを開始

tanzu cluster create workload -f workload.yaml

Management clusterに加え、workload clusterも構築されたことが分かる。

f:id:jaco-m:20210912182219p:plain

動作確認

終わったら以下のコマンドでkubeconfigを取得し、k8sに接続を確認。

tanzu cluster kubeconfig get workload --admin
kubectl config use-context workload-admin@workload
 kubectl get pods -A
NAMESPACE                           NAME                                                             READY   STATUS      RESTARTS   AGE
avi-system                          ako-0                                                            1/1     Running     0          67m
capi-kubeadm-bootstrap-system       capi-kubeadm-bootstrap-controller-manager-6494884869-8r5v7       2/2     Running     0          72m
capi-kubeadm-control-plane-system   capi-kubeadm-control-plane-controller-manager-857d687b9d-fxx75   2/2     Running     0          72m
capi-system                         capi-controller-manager-778bd4dfb9-tskmh                         2/2     Running     0          72m
capi-webhook-system                 capi-controller-manager-9995bdc94-7sj5n                          2/2     Running     0          72m
capi-webhook-system                 capi-kubeadm-bootstrap-controller-manager-68845b65f8-d7zs5       2/2     Running     0          72m
capi-webhook-system                 capi-kubeadm-control-plane-controller-manager-9847c6747-8fzkp    2/2     Running     0          72m
capi-webhook-system                 capv-controller-manager-55bf67fbd5-5shl8                         2/2     Running     0          72m
以下略

無事にKubernetesとして機能していることが確認できた。

その他1.4に関すること

基本的にデプロイの流れはTKG 1.3と変わるところはない。

TKG1.3にはadd-onという概念があったが、1.4からはpackageという仕組みに変更が行われた。そのため1.3からのアップデートの場合はadd-onをpackageに更新する作業が必要となる。extensionsを利用している場合も同様。

アップデート方法は例によってこちらの記事と、あとは公式ドキュメントを参考にするとよい。

VMUG Advantageに登録した

退職にともない、これまで自宅で検証用に使っていたライセンスたちが使えなくなってしまう。

jaco.udcp.info

しかし次の仕事もVMware製品と完全に無縁というわけではなく、やっぱり検証用途に環境は残しておきたい。

ということで、VMUG (VMware Users Group) に参加して、有料のAdvantageに登録することにした。

www.vmug.com

Advantageに登録すると、トレーニングのディスカウントやVMworld参加へのディスカウントがついてくるほか、365日の検証用ライセンスが利用可能になる。

検証可能なライセンスはこんな感じ。

f:id:jaco-m:20210910235505p:plain

Advantageへの登録方法はこのあたりの記事を参考にした

zokibayashi.hatenablog.com

1年、2年、3年と選べるのだけど、思い切って3年のプランにしてみた。

f:id:jaco-m:20210910234757p:plain

(ノ´∀`)ノ

EKS AnywhereをProductionでデプロイした話

先に謝っておくと、タイトルは半分釣り。嘘はついていないのだけど。

ということでEKSをオンプレ環境で動かせるEKS Anywhere (以下EKS-A)がGAに。 aws.amazon.com

現時点で対応している構築環境は、ローカルのDocker上で動かすか、あるいはvSphere環境の2択。"ちゃんとした"環境で動かすとなると、vSphereが第一の選択肢と言うことになりそう。

EKS-Aのドキュメントを見ると、Create production clusterの項目でvSphereに構築する方法が解説されている。今回のタイトルはつまりそういうことで、EKS-AをvSphereにデプロイしてみましたよ、というお話。

EKS-Aの準備をする

EKS-Aでは、環境の構築にCluster APIが使われている。VMwareのTanzu Kubernetes GridもCluster APIなので、vSphere環境でk8sを構築するのであればCluster API、というのが一般的になりそう。

Cluster APIはこのマスコットキャラクターがめちゃくちゃ上手く仕組みを表現していて、Kubernetes Clusterの中にインストールされたCluster APIが、さらにクラウドプロバイダーにアクセスして別のKubernetesを立ち上げるという、親亀子亀のような仕組みになっている。

なので、まずは作業環境にDockerを立ち上げ、その中に eksctl anywhere コマンドでbootstrapのクラスタを立ち上げられるようにする。

EKS-Aのドキュメントでは、この作業環境のことを Administrative machine と呼んでおり、現時点ではMac OSか、Ubuntuを公式ではサポートしている。他のディストリビューションでもいけるのではと思うが、試していないので分からないし、無駄なトラブルを避けるためにもまずは推奨環境で行うのが良いだろう。今回はWindowsのWSL2でセットアップしてあるUbuntu 20.04 + Docker Desktopという構成でやってみた。WSL2+Docker Desktopの時点で公式サポートの環境じゃなくなっている気もするが、少なくとも自分の環境では動いた。

Dockerのインストール方法は割愛。

以下のコマンドで最新の eksctl をインストール。バージョン0.66.0が入るはずだ。

curl "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" \
    --silent --location \
    | tar xz -C /tmp
sudo mv /tmp/eksctl /usr/local/bin/

次に eksctl-anywhere pluginをセットアップ。

export EKSA_RELEASE="0.5.0" OS="$(uname -s | tr A-Z a-z)"
curl "https://anywhere-assets.eks.amazonaws.com/releases/eks-a/1/artifacts/eks-a/v${EKSA_RELEASE}/${OS}/eksctl-anywhere-v${EKSA_RELEASE}-${OS}-amd64.tar.gz" \
    --silent --location \
    | tar xz ./eksctl-anywhere
sudo mv ./eksctl-anywhere /usr/local/bin/

AWSのトリさんが教えてくれたところによると、このプラグイン機構はeksctl 0.66.0から導入されたということなので、もし上手く動かない場合はeksctlのバージョンを確認してみると良い。

vSphere側の準備をする

次にvSphere側の準備をする。 Productionというだけあって、リソースはガッツリ必要になる。 デフォルトだと7VM立ち上がるのだが、それぞれに2 vCPU, 8GB RAM, 20GB Diskが必要だ。つまり14 vCPU, 56GB RAM。 オーバーコミットをしたとしても、まぁそれなりに覚悟は必要なリソース量にはなるだろう。 自分はたまたまガッツリ試せる環境を自宅に組んでいたので問題なかったのだが。

また、vSphereのバージョンはvSphere7.0以上が必須。自分は最新の7.0U1cを利用した。

利用するネットワークにはDHCPが必須。この制約はTKGと一緒なのだが、割と引っかかりやすいポイントなので要注意。

まず、vCenterからResource poolを作成。今回はEKSAという名前にしてみた。 f:id:jaco-m:20210910022451p:plain

次にフォルダを作成。新規仮想マシンおよびテンプレートフォルダを選択し、 EKSAという名前で作成。 f:id:jaco-m:20210910022925p:plain

また、これはドキュメントに無くてハマりポイントだが、Templates という名前のフォルダも併せて作っておく。これを作らないとエラーでコケてしまった。

Cluster configを作る

以下のコマンドでコンフィグファイルを生成

CLUSTER_NAME=prod
eksctl anywhere generate clusterconfig $CLUSTER_NAME \
   --provider vsphere > eksa-cluster.yaml

生成したコンフィグファイルを開いてみると、KubernetesのYAMLになっており、Cluster APIによるリソースが定義されていることが分かる。

次にこのファイルの必要事項を修正する。

まずClusterリソースのendpointを修正。これが作成されるKubrenetesのAPIエンドポイントになる。

  controlPlaneConfiguration:
    count: 2
    endpoint:
      host: "10.9.8.190" #これ
    machineGroupRef:

同じリソースで externalEtcdConfiguration workerNodeGroupConfigurations controlPlaneConfiguration が設定可能になっていて、count の値を変更することでVMの台数を変えることが出来る。必要に応じて変更しよう。

次に、VSphereDatacenterConfigを修正。

apiVersion: anywhere.eks.amazonaws.com/v1alpha1
kind: VSphereDatacenterConfig
metadata:
  name: prod
spec:
  datacenter: "Datacenter" #必須
  insecure: true #任意
  network: "VM Network" #必須
  server: "vcenter.udcp.run" #必須
  thumbprint: "" #任意

datacenter にはvSphere上のDatacenter、 networkにはVMをぶら下げたいネットワーク、 serverにはvCenterのアドレスを入れておく。vCenterが自己署名証明書の場合は insecureを true にするか、 thumbprintを設定する。

次に、 3つあるVSphereMachineConfigを修正。 prod-cpがk8sのcontrol plane、prod-etcdがetcd、prodがworker nodeのリソースになっている。それぞれ別の値を設定可能だが、今回は全て同じ設定を施すことにする。

以下のコメントが付いている部分を、環境に合わせて変更する

spec:
  datastore: "vsanDatastore" # 利用したいデータストア
  diskGiB: 25
  folder: "EKSA" # さっき作成した仮想マシンのフォルダ
  memoryMiB: 8192
  numCPUs: 2
  osFamily: bottlerocket # 利用したいOSを指定。今回はbottlerocket 
  resourcePool: "EKSA" #さっき作成したリソースプール
  users:
  - name: ec2-user #bottlerocket の場合はec2-userを指定
    sshAuthorizedKeys:
    - "ssh-rsa AAAAB3NzaC1yc...j" #作成されたVMにログインできるようにするための公開鍵を入れておく

デプロイする!

vCenterにアクセスするための認証情報を環境変数に入れておく。

export EKSA_VSPHERE_USERNAME='administrator@vsphere.local'
export EKSA_VSPHERE_PASSWORD='t0p$ecret'

そして以下のコマンドで構築開始。

eksctl anywhere create cluster -f eksa-cluster.yaml -v 9

ドキュメントには無かったが、 -v オプションでログレベルを変更できるとトリさんが教えてくれた。ありがたや。初期構築の場合何かとコンフィグの設定ミスを起こしやすいのだが、デフォルトのログレベルだと進捗がほとんど表示されないのでエラーが起きていても気づきにくい。 -vで高めの数字をしておくことで、トラブル時にも状況を把握しやすくなる。

最終的に以下のような表示がされれば構築完了。

f:id:jaco-m:20210910024815p:plain

作られたものを見ていく。

リソースグループを見てみると、7台のVMが構築されていることが分かる。ちなみに画像の下のリソースグループはVMware Tanzu Kubernetes Gridで構築した環境だ。同じCluster APIを利用しているため、VMの命名ルールが似ていることが分かるだろう。

f:id:jaco-m:20210910025242p:plain

コンテンツライブラリを見てみると、eks-a-templates という名前のライブラリが作成されており、その中にOVAテンプレートが追加されている。現バージョンではbottlerocketとubuntuが選択可能なのだが、ubuntuイメージは8.64GBと巨大のため、VMの起動が非常に遅かった・・・。Tanzu Kubernetes Gridの場合はubuntuでも1.5GB程度なので、何故こんなにサイズが大きいのかは謎。

f:id:jaco-m:20210910025336p:plain

作成されたk8sにアクセスするには、kubeconfigファイルが生成されているのでそれを指定

export KUBECONFIG=${PWD}/${CLUSTER_NAME}/${CLUSTER_NAME}-eks-a-cluster.kubeconfig

叩いてみると色々動いていることがわかる。 f:id:jaco-m:20210910030158p:plain

kubeconfigを毎回指定するのが面倒なので、必要であれば ~/.kube/config に内容をマージしたほうがいいかもしれない。

CNIにはCiliumが利用されている。CSIは標準でvSphere CSIが設定されているため、そのままPVが作成可能だ。

kubectl get sc
NAME                 PROVISIONER              RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
standard (default)   csi.vsphere.vmware.com   Delete          Immediate           false                  76m

LoadBalancerは、ドキュメントだとKube-vipの利用がRecommendedになっている。(個人的にあまりいい印象がないのだけど・・・)

ちなみに既にControl planeにはkube-vipがデプロイされており、Kubernetes APIの公開に利用されている。

その他FluxによるGitOpsがサポートされているなどいくつか特徴があるので、皆さんお試しあれ(これはDockerで構築しても使えるはず)

ハマったこと

オンプレならではというか、環境の差異によるハマりポイントがあったので以下メモ

public.ecr.awsからaccess denied食らって死んだ

パブリックの方のECRを以前使っていたんだけど、そのログイン情報が切れていたのかいきなりこれを食らった。get-login-passwordをやり直して解消。

eksctl anywhere create cluster -f eksa-cluster.yaml
Error: failed to create cluster: unable to initialize executables: failed to setup eks-a dependencies: Error response from daemon: pull access denied for public.ecr.aws/eks-anywhere/cli-tools, repository does not exist or may require 'docker login': denied: Your authorization token has expired. Reauthenticate and try again.

コンテンツライブラリで死んだ

若干分かりづらいエラーだったが、コンテンツライブラリへの転送でエラーと出た。原因としては、vCenterのDNS設定が間違っており名前が引けない状態だったため、OVAファイルをインターネットから持ってこれずこのエラーになった様子。この状態になってしまうと、DNS設定を直してもコンテンツライブラリにゴミが残っており、そのゴミを手動で消してあげる必要があった。

Creating template. This might take a while.
❌ Validation failed    {"validation": "vsphere Provider setup is valid", "error": "failed importing template into library: error importing template: govc: The import of library item d7869312-b889-4400-b489-af20cf1e177f has failed. Reason: Error transferring file bottlerocket-v1.21.2-eks-d-1-21-4-eks-a-1-amd64.ova to ds:///vmfs/volumes/vsan:5208a8224f1b7452-258c9915a44aa6a5//contentlib-b06b09de-5b24-4be6-86a9-b344590a9681/d7869312-b889-4400-b489-af20cf1e177f/bottlerocket-v1.21.2-eks-d-1-21-4-eks-a-1-amd64_c4187670-2a9b-4a5b-86dd-a1e8a0bd0d18.ova?serverId=86f3a054-9ba4-4b8f-81b6-b7070451c5cc. Reason: Error during transfer of ds:///vmfs/volumes/vsan:5208a8224f1b7452-258c9915a44aa6a5//contentlib-b06b09de-5b24-4be6-86a9-b344590a9681/d7869312-b889-4400-b489-af20cf1e177f/bottlerocket-v1.21.2-eks-d-1-21-4-eks-a-1-amd64_c4187670-2a9b-4a5b-86dd-a1e8a0bd0d18.ova?serverId=86f3a054-9ba4-4b8f-81b6-b7070451c5cc: IO error during transfer of ds:/vmfs/volumes/vsan:5208a8224f1b7452-258c9915a44aa6a5/contentlib-b06b09de-5b24-4be6-86a9-b344590a9681/d7869312-b889-4400-b489-af20cf1e177f/bottlerocket-vmware-k8s-1.21-x86_64-1.2.0-ccf1b754_c4187670-2a9b-4a5b-86dd-a1e8a0bd0d18.vmdk: Pipe closed.\n", "remediation": ""}
Error: failed to create cluster: validations failed

Templateの作成で死んだ

これは本文中にも書いた通り。ドキュメントの記載漏れなんじゃないかなー? Template用のフォルダを作っておく必要がある。

❌ Validation failed    {"validation": "vsphere Provider setup is valid", "error": "failed deploying template: error deploying template: govc: folder '/Datacenter/vm/Templates' not found\n", "remediation": ""}
Error: failed to create cluster: validations failed

タグが適切に設定されなくて死んだ

これ、諸々試行錯誤してたら突然出なくなって解消して、結局原因は謎。 テンプレートに必要なタグが設定されておらず死ぬパターン。 この問題を引いてしまった場合は、手動でTemplateファイルのタグにosFamilyの設定を入れてあげる必要があった。

f:id:jaco-m:20210910032218p:plain

❌ Validation failed    {"validation": "vsphere Provider setup is valid", "error": "failed tagging template: govc returned error when attaching tag to /Datacenter/vm/Templates/bottlerocket-v1.21.2-kubernetes-1-21-eks-4-amd64-a440064: govc: 400 Bad Request: {\"type\":\"com.vmware.vapi.std.errors.invalid_argument\",\"value\":{\"error_type\":\"INVALID_ARGUMENT\",\"messages\":[{\"args\":[\"urn:vmomi:InventoryServiceTag:28bd7acf-262b-4c48-a53a-775ed91b34e1:GLOBAL\",\"DynamicID (com.vmware.vapi.std.dynamic_ID) => {\\n    type = VirtualMachine,\\n    id = vm-1554590:86f3a054-9ba4-4b8f-81b6-b7070451c5cc\\n}\"],\"default_message\":\"Tagging associable types violation\",\"id\":\"\"}]}}\n", "remediation": ""}
Error: failed to create cluster: validations failed

etcd以外のノードが上がらずに死んだ

これ、結局原因が分からず、何もしてないのに直った・・・(マジ)

bottlerocketでこの問題を引き、その後ubuntuにしたら普通に立ち上がった。 で、その後bottlerocketに戻したら何故かちゃんと立ち上がった・・・。

VMwareを退職します

このたびVMwareを退職することになりました。数週間前から有休消化期間に入っており、今週末をもって退職となります

有休消化期間は、Cloud Operator Days Tokyo 2021のシステム周りをお手伝いしていたり、CI/CD Conference 2021を開催したりしてました。

VMwareに入社したのは2020年の春。それから考えると僅か1年半なのですが、元々はPivotalという会社に所属しており、買収を経てVMwareとなったので、Pivotal時代から通算するとおおよそ4年半在籍していたことになります。

そもそも何をしてたんだっけ

PivotalおよびVMwareでは、Senior Solutions Architectというポジションに居ました。一般的にSolutions Architectというとプリセールスエンジニアを指すことが多いのですが、Pivotalの場合は製品を購入していただいたお客様に対して導入の支援やコンサルティングを行う、いわゆるプロフェッショナルサービスと呼ばれる類いの仕事をしていました。

元々NTT CommunicationsでCloud FoundryをベースとしたPaaSを開発していたこともあり、Cloud Foundryの本家本元であるPivotalに転職したという経緯があります。Pivotalでは商用版であるPivotal Cloud Foundryや、KubernetesディストリビューションのPivotal Container Service、VMwareになってからはVMware Tanzu(Pivotalから継承した製品含む) 周りのプロダクトの導入支援に携わっていました。

自分がCloud Foundryに触れたのは2011年のことだったので、NTT Com->Pivotal->VMwareと延べ10年に渡り、このPaaSに関わってきたことになりますね。時が経つのは早いなぁ。

Pivotalってすごかったんだよ

Pivotalは2013年に設立された非常に若い会社でしたが、 Transform How The World Builds Software - 世界のソフトウェアの作り方を変える- のミッションのもと、主に大企業に向けたプロダクトとサービスの提供を行っていました。単にプロダクトを提供するのではなく、ソフトウェアの変革に必要なのはチームとその文化であるという強い信念を全社員が持って取り組んでおり、その信念に反する(Pivotalっぽくない) ことはやらないという、言うなれば我の強い会社だったなあと思います。

f:id:jaco-m:20200929200747j:plain ▲ Pivotalのコアバリュー。今見ても良いなって思う

ビジネスの対象としては、いわゆるエンタープライズと呼ばれる超大企業がメインでしたが、そういったビジネスの会社にありがちな堅さは全くなく、めちゃくやオープンでフレンドリーなカルチャーでした。春になるとオフィスに桜が咲き、秋にはカボチャが生え、それが終わるとクリスマスツリーが生える。いつも卓球台からは楽しそうな声が聞こえる。そんな環境でした。

f:id:jaco-m:20180404111136j:plainf:id:jaco-m:20190315170947j:plainf:id:jaco-m:20181025112616j:plainf:id:jaco-m:20171114203434j:plainf:id:jaco-m:20171031173808j:plain

こういうのをみると、「あ、シリコンバレーの会社っぽいな」って思うかもしれませんが、まさにそれ。Pivotalの場合は、Pivotalという存在自体がある意味商材そのもので、自らが持つソフトウェア開発に向いたシリコンバレーの文化を、エンタープライズにも広げていくという考えでやっていました。 "Silicon valley is not just a place, it's a state of mind" (シリコンバレーとは地名ではなく、マインドセットである) ともよく言っていましたね。

Platform as a Product

前述したように、自分はソフトウェア開発ではなく、Pivotal Cloud Foundryを中心としたクラウドのプロダクトを中心に担当していましたが、それでもこのPivotal文化による影響はバンバン受けていました。

その中でも、Platform as a Product(プロダクトとしてのプラットフォーム) という考え方に触れられたことは、自分が十数年この業界で生きてきた中でも最も衝撃的でした。一言でいうと、「役に立つプラットフォームを作るのであれば、それをプロダクトとして育てよう」という考え方なのですが、この一文で衝撃度合いを伝えるのが難しいので、CloudNative Days Tokyo 2020で発表した以下のセッションを見て欲しい。

スライド speakerdeck.com

動画 event.cloudnativedays.jp

記事 thinkit.co.jp

また改めて整理してブログに書いてもいいなと考えてたりします。

じゃあなんで辞めるの

Pivotalのすごさを語るといくらでも書けてしまうので一旦この辺にしておきますが、じゃあ何故今回退職することになったか。

まあ、VMwareはPivotalじゃなかったから という点は間違いなく理由としてあるのですが、これだけだとネガティブに伝わってしまうのでもう少し補足。

VMwareになってからは1年半経つのですが、実は大きな不満というものはないんですよね。良くも悪くも小さい会社(といっても数千人いたけど)だったPivotalに比べると、こちらは数万人規模の巨大なソフトウェアベンダー。体制の充実度は圧倒的に高く、待遇としてもPivotal時代よりも圧倒的に良くなりました。仕事の内容も同僚もポジションも変わらないのに待遇がめっちゃ良くなるの、不思議な体験でした。

また、PaaSやCaaSといったチャレンジングなプロダクトを中心としたPivotal時代と比べれば、VMwareには圧倒的なパワーを誇るプロダクトがずらっと並んでいる。こういった足腰のしっかりしたプロダクトの上に、VMware Tanzuという新しいプロダクトを載せるという形になったので、安定度(プロダクト、マーケティング双方)を増しつつも新しいことをやれるといういいとこ取りな状況になったのです。強い。

ただ、プロダクト力で推していくビジネスは強力な一方、社員に求められるものも必然と変わってくることになりました。買収と会社の成長を通じて、良い意味で フェーズが変わった んだなと個人的には考えていて、じゃあどうするかと考えた末、自分としても新しいことやろうと思い、今回の決断に至った次第です。

次は何するの

来週から新しい職場になるので、それは改めて書こうかなと思っています。 が、業界としてはほぼ同一(直接のコンペではない) なところに居るので、今居るコミュニティには引き続き参加していくつもりですし、VMwareプロダクトにも継続して触れていきたいなと思っています。

あ、VMwareの社員向けのライセンス使えなくなるから、VMUG Advantage入らないとな。

あと、11月4-5に開催するCloudNative Days Tokyo 2021、現在CFPオープンしていて締め切りは明日 9/8です!クラウドネイティブ技術に関するものであれば何でも審査の対象となりますので、ネタのある方は急いでご応募ください!

event.cloudnativedays.jp

あと定番のほしいものリスト

Amazon.co.jp