JAWS DAYSと、私〜一般参加から登壇まで〜

JAWS DAYS 2021 来年3月20日にオンライン開催します！参加お申し込み受付中！！
https://jawsdays2021.jaws-ug.jp/

このブログは、ブログマガジン「JAWS DAYSと、私」の記事です。
「JAWS DAYSと、私」の詳しい内容や背景、参加要項はこちら

2018年: JAWS DAYSとの出会い

は、実はこのブログに書いていました。

JAWS DAYS 2018に参加して分かった、エンジニアとバンドマンの関係

まだAWSとイチャイチャするのがお仕事になる前、2018年のこと。
すでに現職への就職が決定していた頃で、
月並みですが、その熱量に圧倒された記憶があり、
この道を選んだことは間違いではないなという確信を得ました。
また気づきとして、JAWS DAYSって音楽フェスみたいなもんだなーという話を書きました。
バンドやってる身としては、いつかそのステージでライブ（登壇）してみたいな、
というのが一つの目標になりました。

2019年: スタッフ参加

晴れてAWSとイチャイチャすることをお仕事にして、2019年のJAWS DAYSは迷わずスタッフ参加しました。(Tシャツほしかったし。当日スタッフですが、やること自体は難しくないので是非Tシャツ欲しい人は参加することをオススメします。)

このときには顔なじみの人も増え、むしろ仕事で関わったことのあるお客様にも会えるなど、お祭りをより楽しむことができました。

2020年: オンライン登壇

参加者→スタッフ→ときたら、次はいよいよ登壇でしょう！ということで応募し、選んでいただき、いよいよ！というところでオンラインへシフトとなりました。あのステージでライブができなかったことは少し残念ですが、運営の皆様のおかげで素晴らしい一日になりました。(家からの登壇はちと厳しかったので会社の会議室を1日占拠したのもいい思い出)

まとめ

あんまり人生変わった感を出せてないですが、やっぱりその熱量に圧倒されることは間違いないです。そら人生変わるわ、って感じです。お祭りとしてもすごく楽しいイベントですので、オンラインはオンラインで楽しみつつ、またオフラインでみんなと顔を合わせてやれる日を楽しみにしています(運営のみなさま毎年ありがとうございます)。

おうちGKEする方法あれこれ

Kubernetesアドベントカレンダー2020 その3、12/11分です。（初・アドベントカレンダー）
https://qiita.com/advent-calendar/2020/kubernetes3

Kubernetes運用したことない初心者なのでツッコミ等歓迎です。

これはなに？

おうちにあるラズパイなどを、GKEの一部として活用するための方法を調べてみました。

きっかけ

おうちEKSというワードtwitterで流れてきたのを見て

https://speakerdeck.com/ytaka23/infra-study-meetup-7th

なにそれ面白そう！！！と思ったのがきっかけです。

はて、おうちEKS？

そういえばk3sとかもそういうエッジ向けだったはず…

GCPのAnthosもGKEをいろんなところに延伸する思想だし…

どんな技術が今あるのかちょっと調べてみよう！

とはいえ思ったよりいっぱいありそうなので、あくまでおうちGKEという観点で。

そもそもクラウドのk8sを延伸して何が嬉しいの？

間違ってたら教えていただきたいのですが、クラウドのk8sを他所に伸ばすパターンとして、

  • マルチクラウドなはなし(クラウド - クラウド)
  • エッジコンピューティングなはなし(クラウド - オンプレ)

という2つがあると思っています。いろいろ順序が逆な気がしますが、前提としてクラウド上のk8sを使ってサービスを運用している、という状況があるとします。

マルチクラウドのモチベーション

  • メインの基盤はAWSのEKSだけどBigQuery使いてぇ
  • GCPとつないでもいいんだけど…
    • データ転送のレイテンシ
    • 通信費用
    • セキュリティ面
  • が気になるのでBigQueryの処理とかはGKEで処理したい！（そしていい感じにEKSとGKEをつなげたい！）

エッジコンピューティングのモチベーション

  • たとえばIoTでセンサからデータ収集してごにょごにょしたい
  • 収集・処理はクラウドのk8sでやってもいいんだけど…
    • データ転送のレイテンシ
    • 通信費用
    • セキュリティ面
  • がやっぱり気になるのでセンサの近くで処理できるところは処理したい！

というわけで

エッジやマルチクラウドで一貫したk8sの体験を提供すべく、各社色々サービスを出しています。

  • GCP: Anthos
  • AWS: EKS anywhere[new!]
  • Azure: Azure Arc(よく知らない)

最近結構盛り上がってる分野な気がしていて、おうちGKE、おうちEKS、やっといて損はないかな、と。

やってみよう！

前置きが長くなりましたが、おうちのラズパイをクラウドの一部にするにはどういう方法があるのか、調べてみました。お手軽さ順でいきます。

1. Kube Edge

https://kubeedge.io/en/

  • 今回の調査のきっかけ
  • CNCF sandbox
  • Kubernetesクラスターを組んだ際に起きる、NW不安定問題や、外部デバイスとの連携をうまーくラッピングしてくれるらしい
    • オフラインモード
    • MQTT？(外部デバイスとの連携)

1. Kube Edgeやってみた

  • GKE + AWSのEC2(ubuntu)でできた
    • ほんとはおうちラズパイと組み合わせたかったけどラズパイ不良につき…
    • 以下構築メモ
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
参考: https://qiita.com/pideoh/items/cac19a32fdc723cca68d#kubeedge%E3%81%AE%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB-2

- GKE構築
  - ノードはUbuntuにする
  - ScopeでFull権限
- network
  - 上り10000, 10002ポートをあける
- Master(GKE Nodeで作業)
  - kubectl使えるようにする
    - https://cloud.google.com/sdk/docs/quickstart-debian-ubuntu?hl=ja
    - gcloud init --console-only
    - gcloud container clusters get-credentials cluster-1 --zone us-central1-c --project <your-project>
  - keadmインストール
    - wget https://github.com/kubeedge/kubeedge/releases/download/v1.4.0/keadm-v1.4.0-linux-amd64.tar.gz
  - のためにはauth-providerがgcpではだめ
  - ということでgcloudなしでkubectl使えるようにする
    - インスタンスについてるsa(Compute Engine default)の権限にKubernetes Engine, Clusterの管理者権限を付けておく
    - https://github.com/gravitational/teleport/blob/master/examples/k8s-auth/get-kubeconfig.sh
    - 作ったsaにフル権限付与
      - kubectl create clusterrolebinding add-on-cluster-admin --clusterrole=cluster-admin --serviceaccount=teleport:teleport-sa
    - kubeconfigができるので.kube/configと入れ替える
  - これでようやくkeadmできた
    - ./keadm init --advertise-address="xxx.xxx.xxx.xxx(NodeのPublic IP)"
- Edge
  - Ubuntu on AWS
    - 準備
      - apt-get update
      - apt-get upgrade
      - apt-get install apt-transport-https ca-certificates curl gnupg-agent software-properties-common
      - curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
      - add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
      - apt-get update
      - apt-get install docker-ce docker-ce-cli containerd.io
      - wget https://github.com/kubeedge/kubeedge/releases/download/v1.4.0/keadm-v1.4.0-linux-amd64.tar.gz
      - tar -xvf keadm-v1.4.0-linux-amd64.tar.gz
  - Kube Edge Master側で
    - keadm gettoken
  - クラスタにjoin
    - keadm join --cloudcore-ipport=xxx.xxx.xxx.xxx(GKE NodeのPublic IP):10000 --token=xxxxxx...

1. 感想

  • やり方(というか使い方)あってるかな…
  • クラウド側のk8sクラスタの中にKube EdgeのマスターがCRDで作られて、ノードをぶら下げるという理解

2. Istioを使ったマルチクラスタ構成

2. やってみた

2. 感想

  • できるけどおうちk8sクラスタはそれ自体がちょっとハードル高い…
  • IstioベースのマルチクラスタがGCPのAnthosの考え方ですね

3. Anthos Bare-Metal

https://cloud.google.com/blog/ja/topics/hybrid-cloud/anthos-on-bare-metal-is-now-ga

  • Anthosってもともとオンプレの資産を使う場合、オンプレ上のVMに立てたGKEクラスタ(GKE on Prem)とクラウドのGKEを一貫して管理しますよという話だったのでハードルがちょっと高かった
  • のですが、VMがいらなくなって少し敷居が下がっています
  • けどスペックはそこそこ求められるので検証できていません…
    • 2 つのノード（4 コア以上）、32 GB の RAM、128 GB のディスク
    • おうちAnthosはちょっとパワーが要る…

番外編A. EKS Anywhere

GKEメインで見てきましたが、AWSのEKSもオンプレに伸ばすサービスがつい先日発表されました。

https://aws.amazon.com/jp/eks/eks-anywhere/

おうちEKSもできるかも（でもこっちもスペックまぁまぁ要りそうですねきっと。

番外編B: クラウドの自前k8sクラスタとおうちをつなぐ

GKEとかEKSとか、可能な限りマネージドなものを使いたいですし、各社サービスはそれがウリではあるものの、それ以外でおうちのラズパイをクラウドの一部にする方法もあると思ったので、そちらも調べてみました。

番外編B-1. てゆーかそもそもk8sのノードはマスターと同じLANになくてもよいのでは？

  • kubeadmでクラスタつくるとき、最終的にnodeからjoin！ってやってるよね
  • マスターへの通信はインターネット経由でもいけるんちゃうん？
    • あくまで通信できればよくて認証とかは上のレイヤでやってるし
    • やりたいか、実用的かどうかはともかく

番外編B-1. やってみた

番外編B-1. 感想

  • やっぱりできる、、、けどもちろんこれだけだと実用に耐えない。。。

番外編B-2. k3s

https://k3s.io/

  • k8s から 5つ機能を抜いてk3s
  • Armでも動くIoT向け？なcertified k8s
  • Rancherが開発→CNCF sandbox入り

番外編B-2. やって、、、ない

  • たぶんやることは番外編1.と同じで、本質的にはk8sのディストリビューションの違いという差しかなさそうなので。。。

まとめ

  • クラウドのk8sクラスターをオンプレや他クラウドへ延伸するのが今アツい！（たぶん）
  • おうちのラズパイをGKEやEKSの一部として活用できる！（理論的には）
  • 各社力を入れていそうなので、今後に期待！
    • AWS使いとしてはECS Anywhereも気になる

JAWS DAYS 2020「AWSしくじり先生」でオンライン登壇しました

資料はこちら

エンジョイ・オンライン！

昨日はお疲れ様でした。初のフルオンラインということで
運営のみなさまは大変なところも多々あったかと思いますが
問題なく走りきったのは素晴らしいです！
そしてそこで登壇というある意味貴重な機会をいただけ感謝です。

JAWS DAYSとわたし

2018は一般参加でした。ちょうどその年からJAWS-UGのイベントに顔を出し
本格的にAWSとイチャイチャすることを決めた年でした。
2019はスタッフ参加でした。お祭りを盛り上げるためにお手伝い。
これも初めての経験でしたが、楽しかったです。
そして2020は登壇。25分枠でしたが初めてにしちゃぁ
Twitterとか見る限り皆さんの気付きになってもらえたかと思います。
みんなもっと失敗事例共有しようよー。

これから

今回をまた一つのアウトプット・成功体験として
これからも継続的に登壇とかやっていきます。
ネタも（失敗事例以外でも）増やしていけるようにしないと。

Cloud RunはKnativeをどこまでマネージしてくれているのか

Cloud RunかわいいよCloud Run

コンテナアプリ作っておけば「どこかで動いているKubernetes上」で
それを動かすことのできるサーバレスコンテナ環境、Cloud Run。
Webアプリコンテナだったら独自ドメインも使えるし、
Lets Encryptですけど自動で証明書もあててくれるし、いい感じです。
Cloud Runは正確には「どこかのKubernetes上で動いているKnative環境」で、
GCPがそれらの面倒を見てくれている（マネージドなKnative）わけですので、
Cloud Runを理解するためには、Knativeを理解する必要があります。
GAになったとはいえ、Cloud RunはKnativeの機能の一部しか利用できないため
今どこまでマネージドにできていて今後何ができそうなのか、というところを見ていきます。
また、一旦Knativeの構成要素のうち、「Serving」にフォーカスします。
Cloud Runも今はServingしか提供してないですし。

Knativeって？

ということで、Cloud Runを理解すると書きつつ、
ここからはKnativeを理解していきます。
概念や構築、基本的な機能は以下のハンズオンが参考になりますので端折ります。
https://github.com/toshi0607/build-your-own-platform-with-knative
公式はこちら。
https://knative.dev/

Cloud Runの機能とKnativeの機能の対応

ここからはCloud Runに現在ある機能（設定）が
Knativeのどの機能（設定）に対応しているのか、について確認します。
Cloud Runのサービス作成時の入力項目をベースに見ていきます。

認証

外部からアクセス可能か否か。
KnativeのServingはデフォルトで外にオープンなので
内部向けにするには設定を入れる必要があります。
https://knative.dev/docs/serving/cluster-local-route/
これを切り替えてくれてるんですね。
ちなみに実際に上記ドキュメントどおりにKnativeでやろうと思ったら
svc名.ns名.svc.cluster.localでkube-dnsがひいてくれない。。。
https://medium.com/google-cloud/cluster-local-issue-with-knative-eventing-v0-9-0-a1fee2215cfe
ググってこれで解決。内部用のgatewayが必要なのかしら。（よく読んでない

リクエスト数

RevisionリソースのcontainerConcurrencyの値っぽい。

タイムアウト

RevisionリソースのtimeoutSecondsの値っぽい。

コンテナポート

Cloud Runのサービスを作成するとhttpsのエンドポイントが生成されます。
なので基本http443(or 80)で外部からの通信を待ち受けます。
コンテナポートは、エンドポイントにアクセスがきたらどのポートでアプリ側のコンテナに渡すか、という設定になります。
たとえばWebアプリコンテナで8080で待ち受けてる、とかであればそのポートを設定することになります。
実際のKnative環境でも、Servingを作成するとデフォルトでhttp80で待ち受けるエンドポイントが作成されます。
これがKnativeのどこで設定されてるかちょっとわからなかったのでまた調べる。

自動スケーリング

これ
https://knative.dev/docs/serving/configuring-autoscaling/

Cloud SQL接続

使ってないので一旦置き

サービスのドメイン

Cloud Runで作ったアプリには[サービス名]-[識別子？].a.run.appっていうドメインが割り当てられる。
KnativeのConfig Mapでドメインを変更できるので、そこで設定しているのでしょう。
https://knative.dev/docs/serving/using-a-custom-domain/

カスタムドメイン&SSL化

カスタムドメインも同様に、設定時はサービスとドメインを入力するので
その情報をもってConfig Mapを更新していると思われる。
カスタムドメインの設定と同時にLets Encryptによる自動更新の証明書が
当てられていると思われる。
https://knative.dev/docs/serving/using-auto-tls/

まとめ

ざっと見た感じ、KnativeにあってCloud RunにないServingの機能って
Observabilityのところと、Routingの細かい制御くらいなのでは？
と思いました。（Knativeのドキュメントベースで）
https://knative.dev/docs/serving/
Routingできれば、Canaryリリースとかできるようになってひとまずだいたいいい感じになりそう。

AWS5冠達成と風花雪月のクラスデザイン

AWS5冠達成しました

  • Solution Architect Professional
  • DevOps Engineer Professional
  • Solution Architect Associate
  • Developer Associate
  • SysOps Administrator Associate

AWSといちゃいちゃするのをお仕事にしてから1年と3ヶ月。割とのんびりペース。

ファイアーエムブレム風花雪月における資格試験とクラス(職種)

絶賛プレイ中のNintendo Switchソフト「ファイアーエムブレム風花雪月」においても
「資格試験」に合格することで特定の「クラス」に兵種を変更できます。
これ、なかなか現実世界と同じだなと感心していて、
試験に合格するためには、もちろん勉強が必要です。
「剣士」になりたければ剣の技能を伸ばし、
技能がある程度の水準になると資格試験を受ける権利が生まれ、
さらに技能を伸ばせば合格率がどんどん上昇する（一定ライン超えたら100%になる）、というもの。

AWSの試験に置き換えても同じで、
EC2, RDSなどそれぞれの要素について深く学び
それぞれの知識が深まれば合格率が上がります。

風花雪月は「合格した後」もなかなか現実世界に沿っていて、
合格するとそのクラスになれるわけですが、
なった後、クラスそのものも経験を通して成熟します。
合格して上位のクラスになってそれで終わり、じゃなく
そのクラスを極めてからこそ初めて使えるスキルがあったりします。

現実でも、AWS Solution Architect Professionalの資格をとって
アーキテクトのプロフェッショナルを名乗れるようになるものの
その時点ではまだまだプロフェッショナルとしての経験値が少ないかもしれません。
プロフェッショナルを名乗り、プロフェッショナルとして業務にあたることで
Solution Architect Professionalというクラスを極める
という点では僕もまだまだなので、これからどんどん経験値をためていこうと思う次第です。

Classic VPNのメトリクスのとりかた

ある案件でClassic VPNのアラートがあがって、CloudWatchでメトリクス見ようとしたら、なかった

じゃあどうやってnagiosはそれを検知したのかというと、cli経由っぽい。

1
aws ec2 describe-vpn-connections

nginxのログにALBのIPが出る問題

他のログはクライアントIPが出てるのに、一部のログでALBのIPが出ている。

結論

nginxの設定上、x-forwarded-forではなくtrue-client-ipというヘッダを使って、クライアントIPを判別していた。true-client-ipはCDNをALBの前段に挟んでいるときに使うヘッダのようで、そのヘッダがないとき（たとえばALBに直接アクセスがきたとき）にはALBのIPで出てしまうって感じ。

AWS Summit Osakaに参加してきました

基調講演

顧客事例交えつつ、AWSのこれまでを振り返る感じ

クラウドネイティブなアプリケーション開発入門

やっぱり要素がたくさんあるので駆け足な感じでしたが、一通りモダンなアプリケーションに必要なことをコンパクトにまとめられていました。ベスト・プラクティスがやっぱり大事。

クラウドへシステムをマイグレーションするときの整理指針

5W1Hに沿って移行プロジェクトの進め方を解説。具体的なツールについても。

EXPO

知ってる人に声をかけたりDataDog Tシャツもらったりしました。

##　所感

まだまだ関西はクラウドの第一歩って感じですね。これをきっかけに導入が進んだり考え方が変わったりしたらいいなって感じです。

Dockerの仕組みについて勉強しよう

という勉強会に参加しました。
https://speakerdeck.com/dockerbg/docker-falseshi-zu-minituitemian-qiang-siyou-number-dockerbg

感想

なんとなく理解していたつもりのDockerの深いところが、もう少し理解できるようになりました。ガチの初心者さんにはちょっとDeep過ぎたかもですけど、ある程度触っていた自分としてはとても勉強になったし腹落ち度が増しました。