今年は有難いことにk8sをお仕事で使用する機会に恵まれました。その中で、アプリケーションやインフラのデリバリをGitOpsで実現する手段としてArgoCDを使用しました。
イメージはだいたいこんな感じです。
ArgoCDとググれば公式サイトをはじめ結構たくさんの情報がヒットします。なので、今更まとめ記事を書く必要もなさそうです。ハマりどころをスキップしてサッと試せるサンプルがあれば十分かなと思ったので、AWS EKSでk8sクラスタを作成してArgoCDでGitOpsを試すサンプルを作成してGitHubに置きました。
とりあえず適当なアプリでArgoCDがどんなものか触ってみたい人は試してみてください。
※補足
k8sサンプルアプリはいつものやつ（Sock Shop）を使用してますが、EKS:v1.18だとAPIバージョンなど廃止された記述があってうまくapplyできないのでマニフェストをForkして少しだけ修正してあります。
AWS 認定DevOps エンジニア – プロフェッショナル を取得（11/29）しました。
スコアは844でした。試験対策や所感などをメモがてら書き残しておきます。
詳細は以下の公式ページに記載されています。
ざっくり言うとAWS（Amazon）が公式に認定するベンダー資格です。大きくは２つのレベル（アソシエイトとプロフェッショナル）に分かれています。
また、プロフェッショナルとは別に専門知識というカテゴリも用意されており、以前は英語のみ受験が可能だったのですが、現在は全て日本語での受験が可能になっているようです。（なんかどんどん増えますねぇ、、、今や全部取得すると12冠なんですって）
試験対策ですが先達の方々からのアドバイスによるとUdemyの教材が良いと聞いていたのでセール期間にいくつか購入していたのですがいずれも英語の教材でした。英語が嫌い過ぎてどーにもやる気が出ず2週間前くらいまで『無』の境地で諦めモードでした。が、なんと試験2週間くらい前になって、いい感じの日本語の教材を見つけました！
AWS認定 DevOpsエンジニア – プロフェッショナル (DOP-C01) 模擬試験 (2020年試験対応版) | Udemy（※有償：¥3000 yen → ¥1200 yen）
他にやったことは、公式のサンプル問題を解いたくらいですね。
公式のサンプル問題（※無料）
現時点でDOP日本語の教材は非常に少ないので、他には下記くらいだと思うのですが、今回はいずれも利用しませんでした。（そう考えると対策のコスパ良かったな）
試験会場は行きつけの歌舞伎座テストセンターにしたかったのですが、日程が合わず断念。自宅でAWS認定試験が受験できるようになったので、自宅で受験しようとも思ったのですがバウチャーが利用できないのでそれも断念。最終的に、昔SAA受験した時に利用した（PSI試験で嫌な思い出のある）田町テストセンターで受験することになったので会場（というよりは試験中の異常なまでの監視）に不安があったのですが、前回のPSI試験の時とは違って、入室前に身分証明書などを提示してカメラで顔写真を撮った際の事前チェックをしてからは、Webカメラでの監視や試験官とのチャットでのコミュニケーションなども一切なく試験に集中して淡々と進めることができました。今回はピアソンVUE試験だったからかな？これなら歌舞伎座じゃなくても良いかもって思いました。
お疲れさまでした。
新型コロナウイルスによる自粛生活が始まってから集合形式の勉強会は殆どがキャンセルされ、久しく社外勉強会に参加していませでしたが、最近ではオンライン形式の勉強会も増えてきました。これまで何度が参加させてもらったアジャイル・ディスカッション勉強会も遂にオンラインで開催されるということで参加してきました。
そもそもオンラインで大人数のディスカッションなんてできるのか？など一体どんな雰囲気になるのか想像もつきませんでしたが、うまくツールを活用してオンラインのディスカッションを実現していました。
オンライン勉強会では以下のツールを活用しました。
テキスト・音声どちらも使えるチャットツールです。
特に付箋に特化したオンラインホワイトボードです。
オンライン勉強会は、OST（オープン･スペース・テクノロジー）形式で進められました。OSTでは、その場に居る人達が議論したい内容を持ち寄って、自分達でディスカッションしたいテーマを決定します。1つのOSTの中でテーマは複数あり、テーマごとに同時並行でディスカッションを進めます。どのテーマのディスカッションに参加するかは自由に選択できます。具体的な進め方は、実際にディスカッションのテーマ出しをする前に、Mural上に用意されたアウトラインのスライドに沿ってDiscordボイスチャットで説明してくれました。運営の方、事前準備どうもありがとうございました。
Discordには、ディスカッション用の部屋が複数用意されていました。参加者が出し合ったディスカッションテーマを部屋ごとにひとつ割り当てて、前半／後半の2つのタイムボックスでそれぞれディスカッションしました。
ディスカッションへの参加度合いは人それぞれ自由で、積極的に話すファシリ役から聞き役まで様々で、ディスカッション前の説明ではOSTへ参加する役割について次のように説明されました。
）：トピックに群がり議論を前に進め、建設的な提案をする人
）：複数のトピックを回りながら、他家受粉を促す人私はテレワークをもっとカイゼンしたかったので「オンラインでのふりかえり方法」や「オンラインでの困り事」のディスカッションに参加させてもらいました。テレワークが始まって以来、社外の人とSNSなどで情報交換したことはありましたが、口頭で議論するのは初めてだったので良い情報交換ができました。
Discordを初めて使用したのですが、多人数（30人弱）で利用しても遅延を感じることもなく全体をとおして通話品質が良いなという印象でした。初めての利用でしたが、ワンクリックでの部屋移動など、操作も簡単でした。オンライン勉強会でも結構やれるな、と思った反面、話し手（※特にメインスピーカ）の顔が見えないので、音声以外の情報（表情や仕草など）から雰囲気や感情を感じ取れないのは辛いな、とも思いました。今度Discordのカメラ機能を使ってカイゼンできないか試してみたいところです。
総合的にみて オンライン勉強会いいな！ という感想を持ちました。今まで私が参加してきた対面形式の勉強会は自宅から遠いことが多かったので、終電や長時間の移動を気にせず参加できるオンライン勉強会は神です。今までのような対面形式の勉強会と比べて不便はありますが、メリットも大きいと感じました。オンライン勉強会が定着して、その不便もカイゼンされていけば、いつでもどこからでも世界中の勉強会に参加できますね。今後のオンライン勉強会の進化に大いに期待したいところです。
本日（5/18）Certified Kubernetes Application Developer (CKAD) 試験に合格しました。合格するまでの勉強方法などのメモです。誰かの何かの役に立てば幸いです。
詳細はこちらの過去記事をご覧ください。
今回は「CKAD-JP」で試験を申し込んで受験しました。ちょうど今、割引キャンペーンを実施中で今月末（5/31）まで受験費用は30%OFF（$300→$210）になっていますので受験を考えている方はエントリしてみては如何でしょうか。有効期間は、エントリ後1年間です。好きなタイミングで受験できるので、いずれ受験しようと考えているのであれば、とりあえずエントリして、（自分で自分の尻に火をつけて）それをモチベーションに今から勉強して頃合をみて受験することも可能です。
ちなみにクーポンコードは、エントリする際、クーポンコード入力欄に
ANYWHERE30
と入力するだけでOKです。
今回の試験対策で実践した内容は（ほぼ）次のひとつだけです。
CKAと同様に去年のクリスマスセール中に激安で購入した英語のCKADオンライン教材です。割引キャンペーン時に購入すれば、コスパ最強の教材です。Udeimyは頻繁に割引セールを実施しているので、キャンペーンを利用して上手に購入してください。ちなみに、このブログ書いている今は割引なし。うーん、高いな、、、
この教材の優れた点などは、同じく前述の CKAの過去記事 を参考にしてください。
CKA受験から3週間空けてCKADを受験した訳ですが、ギリギリながら1発合格することができました。試験対策としての勉強は、下記だけです。CKA試験対策のベースがあったのでセクション1～10のセミナー動画は結局最後まで見ませんでした。
取り組んだ順番も上記のとおりです。セクション12の「Mock Exams」から着手する理由は、セクション11の「Lightning Labs」があまりにも難しくて、かつ、試験時間も足りなすぎて、CKAD試験がこのレベルだと思ってしまうと心が折れます（たぶん）。よって、まずは Mock Exams に挑戦してみて、慣れてからLightning Labsに挑戦してみると良いと思います。
ちなみに私は、最後まで Lightning Labs の問題を時間内に完全に終わらせることができませんでしたが、ちゃんと（？）試験をパスできました。なので Lightning Labs が時間内に全部終わらなくても焦らなくて大丈夫です。
様々なCKAD試験対策のブログやネット記事で取り上げられていたので、一応は見てみましたが、Udemyの問題と比べると簡単な問題が多い印象で、ほんの少しだけ手を付けて辞めてしまいました。ざっと眺めてみて、知らないとか苦手だと思うものがあったら手を付ける程度で十分と思いました。
自宅でのオンライン受験はかれこれ3回目だったので、特に今回は手順でハマったところはありませんでしたが、受験15分前にコイツが出た時は少し焦りました。何が起きるか分からないので、当日試験前は十分時間に余裕を持ってスタンバイすると良いです。
また、あえて付け足すなら、 試験開始前に試験官からWebカメラで身分証明書（パスポート）、机の上、部屋の中を見せるように言われるのですが、その際、自分のWebカメラの映像をWebブラウザにプレビューすることができます。プレビュー映像を確認しながらやらないと、試験官から、パスポートが見えないとか、部屋の中をもっとよく見せろとかしつこく言われててしまい非常に時間がかかります。その結果、試験を時間通り開始できなくて焦ってしまったり、疲れてしまったりするので、ちょっとしたことですが、知っておくと吉です。
今回は、試験のペース配分をミスってしまい、一番最後の問題（高配点）を解く時間がなくなってしまいました。受験の際は、ちょっとでもハマって時間がかかりそうになったり、問題文が長くて内容を理解するのに時間がかかりそうだなと思った場合は、躊躇なく後回しフラグを立てて、どんどん進んだ方がいいです。特に、本当は解けるはずの高配点の問題を逃してしまうのが一番勿体ないです。CKADの試験問題はCKA試験と比べると、問題文も長くて、難易度も高い傾向にあるので特にその意識を強めに持った方がいいと思います。
今年の1月から、CKAの勉強を始めて約4ヶ月半でCKAとCKADの試験に合格できました。勉強の進め方をふりかえってみると、まずCKAでkubernetes全般の知識を広く（浅く）学び、そのベースを元にして追加でCKADの勉強を進める、というなんとなくな戦略で対策を進めてきましたが、結果として（自分にとっては）正しかったように思います。いきなりCKADの難易度の高い問題をやっていたら、すぐ嫌になって投げ出していたかもしれません。コツコツと進めるのが性に合っている人にとっては、この順番で対策を進めることをお勧めしたいと思います。
加えて、CKA／CKAD試験は自宅で受験しましたが、移動コストや交通遅延を気にする必要もなく、慣れた環境（自分の部屋、普段使い慣れたモニタ、キーボードなど）で受験することができるので、今まで受験した試験と比べて非常にリラックスして受験することができました。まだしばらくは新型コロナウイルス感染症（COVID-19）の影響で外出しにくい状況が続きそうなので、自宅で受験できるような試験が増えるとありがたいですね。
k8sのトラブルシュートなどでpodから疎通確認する方法についての簡単なメモです。
時々しか使わないので、時間が経つと100%忘れるのでここにメモを残しておきます。
NetcatはHobbit氏によって開発された、汎用TCP/UDP接続コマンドラインツールです。
ncコマンドはNetcatの略。非常に多機能なツールですが、今回は一部機能のみ使用します。
（外部接続の疎通確認の）コマンド実行の書式は下記です。
nc [-オプション] 接続先 ポート番号
疎通確認時によく使うオプションは下記です。
| オプション | 覚え方 | 説明 |
|---|---|---|
| -z | zero I/Oの[z] | ゼロI/Oモード（ポートスキャン時） |
| -v | verboseの[v] | （多弁：verbose）情報表示モード |
| -w secs | waitの[w] | タイムアウトwait時間（秒数指定） |
まず、疎通確認したい pod（接続元） へ入ります。
$ kubectl exec -it webapp-color -- sh
次に、疎通確認したい pod / service （接続先）へ nc コマンドを実行します。
疎通OKの場合
# nc -z -v -w 3 secure-service 80 secure-service (10.108.84.141:80) open
疎通NGの場合（※タイムアウト）
# nc -z -v -w 3 secure-service nc: secure-service (10.108.84.141:0): Operation timed out
上記は、CKA / CKAD のトラブルシュート試験でよく出題されて焦るやつなので覚えておくと吉。
この記事を書くにあたり下記の情報を参考にさせていただきました。
k8sコンテナでコマンドを実行するマニフェストファイルの記述例を紹介します。
下記の流れでk8sコンテナでコマンドを実行するサンプルをいくつか試してみました。
単純な引数ありコマンドを実行する（commandのみ）記述方法
■ sample01.yaml
apiVersion: v1
kind: Pod
metadata:
name: sample01
spec:
containers:
- name: busybox
image: busybox
command: ['echo' , 'The sample01 app is running!']
サンプルpodをデプロイ
$ kubectl apply -f sample01.yaml pod/sample01 created
サンプルpodの実行確認
$ kubectl logs sample01 The sample01 app is running!
ちゃんと実行されてますね。 ただし、コンテナのメインプロセスが即終了するためコンテナが再起動を繰り返してしまいます。
$ kubectl get pods sample01 -w NAME READY STATUS RESTARTS AGE sample01 0/1 Completed 1 7s sample01 0/1 CrashLoopBackOff 1 7s sample01 0/1 Completed 2 21s sample01 0/1 CrashLoopBackOff 2 34s sample01 0/1 Completed 3 48s sample01 0/1 CrashLoopBackOff 3 1m
シェルで複数の引数ありコマンドを実行する（commandのみ）記述方法
■ sample02.yaml
apiVersion: v1
kind: Pod
metadata:
name: sample02
spec:
containers:
- name: busybox
image: busybox
command: ['sh', '-c', 'echo The sample02 app is running! && sleep 3600']
サンプルpodをデプロイ
$ kubectl apply -f sample02.yaml pod/sample02 created
サンプルpodの実行確認
$ kubectl logs sample02 The sample02 app is running!
ちゃんと実行されてますね。
シェルで複数の引数ありコマンドを実行する（command + args）記述方法①
■ sample03.yaml
apiVersion: v1
kind: Pod
metadata:
name: sample03
spec:
containers:
- name: busybox
image: busybox
command: ['sh']
args: ['-c', 'echo The sample03 app is running! && sleep 3600']
サンプルpodをデプロイ
$ kubectl apply -f sample03.yaml pod/sample03 created
サンプルpodの実行確認
$ kubectl logs sample03 The sample03 app is running!
ちゃんと実行されてますね。
シェルで複数の引数ありコマンドを実行する（command + args）記述方法②
■ sample04.yaml
apiVersion: v1
kind: Pod
metadata:
name: sample04
spec:
containers:
- name: busybox
image: busybox
command:
- 'sh'
args:
- '-c'
- 'echo The sample04 app is running! && sleep 3600'
サンプルpodをデプロイ
$ kubectl apply -f sample04.yaml pod/sample04 created
サンプルpodの実行確認
$ kubectl logs sample04 The sample04 app is running!
ちゃんと実行されてますね。
シェルで複数の引数ありコマンドを実行する（command + 環境変数）記述方法
■ sample05.yaml
apiVersion: v1
kind: Pod
metadata:
name: sample05
spec:
containers:
- name: busybox
image: busybox
env:
- name: MESSAGE
value: 'The sample05 app is running!'
command: ['sh', '-c', 'echo $(MESSAGE) && sleep 3600']
サンプルpodをデプロイ
$ kubectl apply -f sample05.yaml pod/sample05 created
サンプルpodの実行確認
$ kubectl logs sample05 The sample05 app is running!
ちゃんと実行されてますね。
同じような実行結果を出力する場合でも、いろいろな書き方があります。 全てを覚える必要はありませんが、書き方は一つじゃないということと、 変にハマらないために、まずは無難な書き方を覚えて徐々に慣れるのが良いと思います。
この記事を書くにあたり下記の情報を参考にさせていただきました。
コンテナイメージの違いによる pod のふるまいに関するちょっとしたメモです。
下記の流れでコンテナイメージの違いによる pod のふるまいの違いを確認しました。
まずk8sクラスタ上にテキトーなpodを配置したかったのでマニフェスト
■ busybox.yaml
apiVersion: v1
kind: Pod
metadata:
name: busybox
spec:
containers:
- name: busybox
image: busybox
を書いてサンプルのpodをデプロイ
$ kubectl apply -f busybox.yaml pod/busybox created
してみたら、あれ？podが起動（Running）にならない、、、
$ kubectl get pods -w NAME READY STATUS RESTARTS AGE busybox 0/1 ContainerCreating 0 3s busybox 0/1 Completed 0 6s busybox 0/1 Completed 1 9s busybox 0/1 CrashLoopBackOff 1 10s busybox 0/1 Completed 2 24s busybox 0/1 CrashLoopBackOff 2 38s busybox 0/1 Completed 3 54s busybox 0/1 CrashLoopBackOff 3 55s ：
しかも再起動を繰り返してる、、なんでだろう？
試しに nginx のマニフェスト
■ nginx.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx
を書いてサンプルのpodをデプロイ
$ kubectl apply -f nginx.yaml pod/nginx created
してみたところ問題なくpodが起動（Running）した。なんでだろう？
$ kubectl get pods -w NAME READY STATUS RESTARTS AGE busybox 0/1 CrashLoopBackOff 5 3m46s nginx 0/1 ContainerCreating 0 4s nginx 1/1 Running 0 7s
次に、先ほどのマニフェストにコマンド実行を追記して
■ busybox.yaml（※command 追記）
apiVersion: v1
kind: Pod
metadata:
name: busybox
spec:
containers:
- name: busybox
image: busybox
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
既存のpod（busybox）を削除して
$ kubectl delete pod busybox pod "busybox" deleted
問題のpodを再作成してみる。
$ kubectl apply -f busybox.yaml pod/busybox created
ちゃんと起動しました。
$ kubectl get pods -wNAME READY STATUS RESTARTS AGE busybox 1/1 Running 0 56s nginx 1/1 Running 0 13m
この理由ですが、k8sコンテナは、実行中のメインプロセスが終了するとコンテナも終了しようとするためです。 つまり、nginxイメージを使用するpodは、メインプロセスであるnginxが動作し続けているため、 podは起動状態（Running）になり、その状態を維持し続けますが、busyboxイメージを使用するpodは、 実行コマンドが指定されていない場合、メインプロセスがすぐに終了してしまうため、podは、 ほんの一瞬だけ起動状態（Running）になりますが、すぐに完了（Completed）してしまいます。
今回マニフェストに追記したコマンド（sleep）により3600秒間（1時間）はメインプロセスが終了しないため、 busyboxイメージを使用するpodも起動状態（Running）となりました。 が、その時間が経過すると、先ほどと同様に再起動を繰り返すようになります。
ちなみに、busyboxイメージを使用する kubernetes の資料やマニフェストのサンプルの多くはコマンドを指定して使用されています。
知っていればそれまでなのですが、テキトーにサンプルをつくると、想定外の事象に苦しむことになりがちなので、 ご注意ください。
この記事を書くにあたり下記の情報を参考にさせていただきました。
