機雷がなんだ! 全速前進!

SEというかプログラマというか、日々のエンジニア生活の中で体験したことなどを中心に書き残しています。

AWS Sorry Page定番パターン整理(ソーリーページ/メンテナンスページ)

はじめに

Webシステムを利用していて「メンテナンス中」や「アクセスが集中しています」などと表示された経験はないでしょうか?あまり頻繁に目にするものでは(というより目にしたく)ありませんが、このようにサービスが一時的に利用できない場合に表示するページを一般的にソーリーページ(SorryPage)と呼ぶことが多いと思います。ソーリーページがないと無骨でそっけないエラー画面が表示されることになるので利用者に現在の状況が伝わらず、サービスへの印象も悪くなってしまいます。

しかし、計画されたメンテナンスと突発的な障害の両方を一緒くたにソーリーページと呼ぶことには個人的には違和感があります。そこで、ここでは次のように区別して呼ぶことにします。

  1. 突発的な障害:ソーリーページ(SorryPage)
  2. 計画的な停止:メンテナンスページ(MaintenancePage)

記事の目的

AWS環境でソーリーページ/メンテナンスページを表示する定番の方式について調査したところ、まとまった情報がなかなか見つからず苦労したので、再度同じ苦労をしなくて済むよう、調査した内容を今後のためナレッジとしてまとめておくことが目的です。

注意点

本記事でまとめた以外にも様々な実現方式が存在すると思います。また、本内容は現時点(2024年2月時点)の情報に基づいた内容になっている点についても併せてご承知おきください。

実現方式

以下に定番の実現方式を示します。

1.突発的な障害:ソーリーページ(SorryPage)

以下の方式は、突発的な障害が発生した際、マネージドサービスのフェイルオーバー機能を利用して、自動的にセカンダリであるバックアップサイトのソーリーページに遷移させます。

続きを読む

*[本]「ソフトウェアアーキテクチャメトリクス」: アーキテクチャ品質を改善する10のアドバイス

昨年の夏頃に @snoozer05 さんこと島田さんがX(旧Twitter)でソフトウェアアーキテクチャに関する翻訳書籍の原稿レビュアーを募集しているのを偶然お見かけしました。ここ最近ソフトウェアアーキテクチャに興味があって、いろいろと書籍を読み漁っていたこともあり、これは良い機会だと直感してすぐにエントリーしました。その後、こちらのレビューに参加させていただけることになりました。

ちなみに原著はこちらの書籍(Software Architecture Metrics)です。

そして、今年の2024年1月24日についに翻訳書が発売されました👏👏👏

www.oreilly.co.jp

以上の経緯から、今回やったこと、感じたことなどを書き留めておくことにします。

期間と実績

約1ヶ月強という比較的短い期間の平日の仕事終わりの時間と週末の空き時間を使って翻訳レビューの作業をしました。〆切のレビュー期限までに書籍全体100%を網羅することができず申し訳なかったです。最終レビュー実績は6割超(188/308ページ)でした。大変お粗末様でした🙇 

作業の内容

いろいろやり方を考えたのですが、今回はGoogle翻訳とDeepLに適切な長さの原著の英文をそれぞれ入力して翻訳文を比較したり、ツール翻訳文を書籍の翻訳案と見比べて分かりにくい点がないかなどをチェックしました。翻訳ツールへの入力の工夫としては、入力する英文をいくつかのパターンに区切って翻訳させて、より確からしい意味を模索するなどしました。気付いた点は、作業用GithubリポジトリにIssueチケットとして起票して翻訳者へお伝えしました。チケット粒度は特に明確なルールはなかったのですが、私は章や節などある程度の単位ことにチケットを起票して、分かりにくいと思った理由と英文を箇条書きで翻訳文と併記しました。また、より分かりやすいと思える翻訳文のアイデアを思いついた箇所は、翻訳文案も併記してお伝えするようにしました。

感じたこと

今回の作業で感じたことは、昨今ではGoogle翻訳やDeepLなどの優れた翻訳ツールがあって本当に助かるなぁ、ということでした。とはいえ、自分が理解するためだけなら、翻訳文の日本語が多少変でも良いと思うのですが、書籍としてできるだけ分かりやすく、なるべく日本語として不自然でなく、原著の意図を汲み取りながら、数百ページの長文を翻訳するのは、やはり大変な労力が必要だなと改めて感じました。況や今日のような便利な翻訳ツールがなかった頃、大量の翻訳をやられていた @a_konno さん達のような先達の苦労は如何ばかりだったかと思うと本当に頭が上がりません。

さいごに

一昨年の2022年には 自分が寄稿した書籍を技術書典13で自ら販売するという機会 を得ましたが、商用本の翻訳レビューのお手伝いは初めての経験でした。実際にやってみると便利な翻訳ツールが整っている今日でも、思った以上に大変な作業でしたが、前述したように先達の苦労を少しだけ窺い知れたことや、技術書の内容を先んじて読んで理解を深めることができたという点において貴重な機会でした。そして謝辞に名前を入れていただけたのが嬉しかったです。ご献本いただきありがとうございました🙇

AWS AWS 認定 DevOps エンジニア – プロフェッショナル(DOP-C02)を【再】取得しました

本日 AWS AWS 認定 DevOps エンジニア – プロフェッショナル(DOP-C02)を無事に【再】取得(11/11)しました。

AWS Certified DevOps Engineer - Professional (AWS 認定 DevOps エンジニア - プロフェッショナル) バッジ

試験対策

今回は時間がなくて、下記の学習を試験の約1ヶ月前から実施しただけでした。

まとめ

AWS Certified DevOps Engineer - Professional (DOP-C02) のスケーリングスコアは 100~1,000点です。合格に必要なスケーリングスコアは 750 点です。 今回のスコアは 823 でコンピテンシーのバランスもまずまずでした。

幸いなことに直近半年くらいは、業務でクラウド(AWSが中心)のシステム構成図のレビューなどを行う立場だったこともあり、普段の業務の中である程度のキャッチアップができていたことが救いだったように思います。

新規取得時とは違い、継続の場合は受験へのモチベーションの維持が最大のテーマな気がいつもしていますが、とりあえず一発で合格できてよかったです。次はまた3年後に頑張ります。とりあえず乙でした🙇

補足

ここ最近は受験後すぐに結果が分からず翌日くらいにメールで合否通知されるのですが、実は受験後2時間くらいで、AWS 認定アカウントのサイト に合否が掲載されています。

合否の通知メールをヤキモキしながら眠れぬ夜を過ごさなくても、当日自分からサイトを見に行けば結果は分かるようでうす。(※必ず当日中に分かるかは保証しませんが)

アーキテクチャがテーマの「デブサミ2023夏」@ONLINEへ参加してきました

先月の7/27(木)に 夏サミ2003@オンライン開催 へ参加してきました。少し時間が経ってしまい既に失念した点もありますが、これ以上忘れないうちに感じたこと、思ったことなどを記録に残しておこうと思います。

テーマについて

今回のテーマは「サービスの継続的発展に向けた、最新技術の活用とアーキテクチャの追求」でした。アーキテクチャあるいはアーキテクチャリングには、ここ最近個人的に興味を持ってインプットしようとしている領域だったので久々に終日ガッツリ参加させていただきました。

オンライン開催について

コロナ禍を経てオンライン開催が中心となったことで、良くも悪くも聞きたいセッションを仕事の合間にチョコっと聴講するといったことができるようになりました。その結果、移動の時間やコストなども気にせず参加でき、イベント参加する際のハードルがかなり下がったと感じます。その反面、コロナ禍前までオフラインで開催されてきたイベントと比較してイベント会場での出会いや、会場の熱量を感じることなどがなくなってしまい、せっかくのイベントに前ほど集中して参加できていないようにも感じます。下世話な話、イベントそれ自体が有償なのか無償なのかというのもありますが、わざわざ交通費や移動時間などの対価を払って参加するのだから、元を取りたい、という感覚もあるように思えます。今回、特に興味がそそられるテーマということもあり(大した対価ではありませんが…)仕事を休んでイベントに集中して参加することにしました。

聴講したセッション

今回聴講したセッションは以下のとおりです。講演資料が公開されているものについては、リンクを貼っておくので詳細についてはリンク先をご参照ください。

 

セッション資料 講演資料

C-1

これから学ぶ人のためのソフトウェアアーキテクチャ入門
島田 浩二[えにしテック]

https://event.shoeisha.jp/devsumi/20230727/session/4471/

これから学ぶ人のための ソフトウェアアーキテクチャ入門: Software architecture is a tool to enhance our humanity - Speaker Deck

D-2
お客様のToilをなくすためのアプリケーション開発支援を始めました
佐藤 慧太[スリーシェイク]

https://event.shoeisha.jp/devsumi/20230727/session/4481/

資料なし(↓当日の様子)

D-3
セキュアに構築するCI/CDパイプラインの最前線!~事例でみるソフトウェア署名をクラウドで実現する方法~
中村 圭祐[デジサート・ジャパン]

https://event.shoeisha.jp/devsumi/20230727/session/4482/

資料なし(↓当日の様子)

B-4
モノリス化したコード・組織の両方を分割してアーキテクチャを改善する
前田 浩邦[サイボウズ]/太田 絵一郎[サイボウズ]/内山 武尊[サイボウズ]

https://event.shoeisha.jp/devsumi/20230727/session/4465/

資料なし(↓当日の様子) 

C-5
ChatGPTはコーディングテストをどこまで解答できるのか?!~Trackと10X社・GMO社のエンジニアが、AIを使って挑戦してみた~
田島 聖也[ギブリー]/石田 光一[10X]/津田 良太郎[GMOグローバルサイン・ホールディングス]

https://event.shoeisha.jp/devsumi/20230727/session/4475/

資料なし(↓当日の様子) 

C-6
見えない壁を越えよう!アジャイルやマイクロサービスを阻む「今までのやり方」
鈴木 雄介[グロース・アーキテクチャ&チームス]

https://event.shoeisha.jp/devsumi/20230727/session/4476/

アジャイルやマイクロサービスを阻む「今までのやり方」 - arclamp

C-7
実体験から考える受託開発でのモノリス脱却の道
能勢 大輔[マネジメントソリューションズ]

https://event.shoeisha.jp/devsumi/20230727/session/4477/

資料なし(↓当日の様子) 

A-8
UiPathのローコードIDEで自動化するUIテスト~テストデータ生成など、AIとも統合された自動テストの未来~
津田 義史[UiPath]/八波 博和[UiPath]

https://event.shoeisha.jp/devsumi/20230727/session/4460/

資料なし(↓当日の様子) 

B-9
日々の意思決定の積み重ねを記録するアーキテクチャ・デシジョン・レコード
内山 高広[リクルート]

https://event.shoeisha.jp/devsumi/20230727/session/4470/

資料なし(↓当日の様子) 

関連資料:〜その意思決定を刻め〜「アーキテクチャ・デシジョン・レコード(ADR)」を利用した設計の記録 - スタディサプリ Product Team Blog

 

ソフトウェアアーキテクチャに対して無関心だと何が起こるか

講演【C-1:これから学ぶ人のためのソフトウェアアーキテクチャ入門】の後半で、「ソフトウェアアーキテクチャに対して無関心だと何が起こるか?」という話がありました。

開発者がアーキテクチャを気にせず設計を進めた場合、特に考えなしにアーキテクチャが決定されてしまい、それは「必要十分なソフトウェアアーキテクチャ」ではなくなってしまうという内容でした。当然、競合する関心事間のトレードオフを考慮した「少なくとも最悪でないアーキテクチャ」であるはずもなく、開発のみならず、その後の運用保守なども含めてプロジェクトの大きなリスクとなり得ます。DX推進が叫ばれ、より多くのものがデジタル/システム化されつつありますが、思考停止して単なる前例踏襲のみでアーキテクチャを決定することはアンチパターンであることを改めて肝に銘じておく必要がある気がしました。

<補足>

夏サミ2023の講演資料は、以下の公式サイトにまとめられる想定のようです。

codezine.jp

しかし、最終更新が(2023/08/08 17:30 更新)となっており、本日時点(2023/8/13)では、私が聴講したセッションの講演資料へのリンクは掲載されていないようでした。

Ubuntu の Firewallツール (UFW:Uncomplicated firewall)を触ってみた

Ubuntu の Firewallツール (UFW:Uncomplicated firewall)で試してみる。

Wikipedia から引用

Uncomplicated Firewall(UFW)は、簡単に使用できるように設計された、netfilter(英語版)ファイアウォールの管理プログラムである。少数のシンプルなコマンドからなるコマンドラインインターフェイスを使用する。内部の設定には、iptablesを使用している。UFWは、8.04 LTS以降のすべてのUbuntuインストールでデフォルトで使用可能である。


はじめに

今回の試行条件は下記のとおりです。

試行環境

今回試した環境は以下(※一応記録しておく)

cat /etc/os-release

実行結果

NAME="Ubuntu"
VERSION="20.04.5 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.5 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

初期状態

初期状態はインアクティブになっている。

systemctl status ufw

実行結果

● ufw.service - Uncomplicated firewall
     Loaded: loaded (/lib/systemd/system/ufw.service; enabled; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:ufw(8)

FW設定変更

下記のとおり軽く設定を変更してみる。

TCP接続を許可する

SSH通信用にTCP接続を許可する。

ufw allow 22/tcp

実行結果

Rules updated
Rules updated (v6)

接続を許可する

任意の通信用にTCP/UDP接続を許可する。

ufw allow 80

実行結果

Rules updated
Rules updated (v6)

特定IPからの接続を許可する

特定IP(135.22.65.0/24)から9090ポートへのTCP通信を全て許可する。

ufw allow from 135.22.65.0/24 to any port 9090 proto tcp

実行結果

Rules updated

特定IP(135.22.65.0/24)から9091ポートへのTCP通信を全て許可する。

ufw allow from 135.22.65.0/24 to any port 9091 proto tcp

実行結果

Rules updated

FW有効化

ファイアウォールを有効にして、システム起動時に自動実行されるようにする。

ufw enable

実行結果

Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

ファイアウォールはアクティブかつシステムの起動時に有効化されます。

FW実行/停止

手動で実行する

systemctl start ufw

特に何も表示されないため、以下のコマンドでステータスを確認する。

systemctl status ufw

実行結果

● ufw.service - Uncomplicated firewall
     Loaded: loaded (/lib/systemd/system/ufw.service; enabled; vendor preset: enabled)
     Active: active (exited) since Fri 2023-03-31 22:14:06 EDT; 2s ago
       Docs: man:ufw(8)
    Process: 21145 ExecStart=/lib/ufw/ufw-init start quiet (code=exited, status=0/SUCCESS)
   Main PID: 21145 (code=exited, status=0/SUCCESS)

Mar 31 22:14:06 node01 ufw-init[21149]: Firewall already started, use 'force-reload'

手動で停止する

systemctl stop ufw

特に何も表示されないため、以下のコマンドでステータスを確認する。

systemctl status ufw

実行結果

● ufw.service - Uncomplicated firewall
     Loaded: loaded (/lib/systemd/system/ufw.service; enabled; vendor preset: enabled)
     Active: inactive (dead) since Fri 2023-03-31 22:19:12 EDT; 2s ago
       Docs: man:ufw(8)
    Process: 21145 ExecStart=/lib/ufw/ufw-init start quiet (code=exited, status=0/SUCCESS)
    Process: 21953 ExecStop=/lib/ufw/ufw-init stop (code=exited, status=0/SUCCESS)
   Main PID: 21145 (code=exited, status=0/SUCCESS)

Mar 31 22:14:06 node01 ufw-init[21149]: Firewall already started, use 'force-reload'

参考

Certified Kubernetes Security Specialist (CKS) 試験に合格しました【k8s三冠達成】🐳🐳🐳

本日(4/17)Certified Kubernetes Security Specialist (CKS) 試験に合格しました。過去に取得したCKA、CKADと併せて念願のk8s三冠達成🐳🐳🐳できました!個人的な感想としては、これまで受験した資格試験の中で過去イチ難しかったと感じています。合格するまでの勉強方法などのメモです。誰かの何かの役に立てば幸いです。(※ほぼ未来の自分用ですw)

 

Kubernetes認定資格について

Kubernetesは、Googleの社内技術を元にオープンソース化されたコンテナオーケストレーションのデファクトスタンダードとも言うべきものです。ググればいくらでも情報が見つかるのでここでの説明は割愛します。

 

3年前(2020年)はCKAとCKADしかありませんでしたが、現在ではLinux Foundationが認定するKubernetesの認定資格は、次の4種類(KCNA/CKA/CKAD/CKS)があります。2020年11月にCKS、2021年11月にKCNAの認定試験が追加されており、ここ数年におけるKubernetesニーズの高まりを感じます。

略称 正式名 概要

KCNA

KCNA-JP

  • Certified Kubernetes Administrator (KCNA)
  • 認定Kubernetesクラウドネイティブアソシエイト (KCNA-JP)
Kubernetesと広範なクラウド ネイティブ エコシステムに関する基本的な知識とスキルを証明する(有効認定期間:3年間)

CKA

CKA-JP

  • Certified Kubernetes Administrator (CKA)
  • 認定Kubernetes管理者  (CKA-JP)
Kubernetes管理者の責任を遂行するスキル、知識、および能力を備えていることを保証する(有効認定期間:3年間)

CKAD

CKAD-JP

  • Certified Kubernetes Application Developer (CKAD)
  • 認定Kubernetesアプリケーション開発者 (CKAD-JP)
ユーザーが Kubernetes 用のクラウドネイティブ アプリケーションを設計、構築、デプロイできることを証明する(有効認定期間:3年間)

CKS

CKS-JP

  • Certified Kubernetes Security Specialist (CKS)
  • 認定Kubernetesセキュリティスペシャリスト (CKS-JP)
Kubernetesの熟練した実践者(CKA認定が必要)であり、コンテナベースのアプリケーションやKubernetesプラットフォームの構築、デプロイ、ランタイム時のセキュリティを確保するための幅広いベストプラクティス能力を実証する(有効認定期間:2年間

入門編のKCNA以外は受験費用は何れも$395です(JPは$430と割高です)。およそ3年前にCKAとCKADを受験した時の費用は$300でしたのでかなり値上げされている印象ですね。但し、これまでと同様で費用に1回分の再受験が含まれているので心理的にもお財布的にも嬉しいのは変わらずでした。また、時々割引キャンペーンで受験費用が10〜30%OFFになることがあるので、試験対策を進めながらこまめにチェックするとお得に受験できるかもしれません。

ちなみに、日本語(の試験官)で試験を受けたい場合はJPが付いているものを選択するのですが、現在のLinux Foundationの試験サイトには下記のように記載されています。

2022年12月31日以降、日本語を話す監督官は JP 試験をサポートできなくなります。2023年01月01日以降、これらの試験は英語を話す監督者によって監督されます。(注:試験内容は引き続き日本語で提供されます。)

リモート試験監督のチャット対応は簡単な英語が理解(読解)できれば問題ないですし、試験環境の言語設定を日本語に変更すれば、JP試験を選択せずとも(※2021年7月から)日本語で受験が可能ですので、今回は「CKS」で試験を申し込んで受験しました。ちなみに、CKSの受験者は、前提としてCertified Kubernetes Administrator(CKA)試験に合格している必要があるのでご注意ください。

 

今回の受験対象となる環境は【Ubuntu20.04、Kubernetes v1.26】でした。

 

■ 試験対策について

今回の試験対策で実践した内容は3つです。 (購入した順番に記載しています)

 

1.Udemy(※有償:¥4800 → ¥2400)★50%OFF!

一番最初に購入した教材です。CKAやCKADも基本的には、ほぼUdemy講座の一本足打法で学んだので、今回もまずは同じアプローチを採用しました。(後に、コレだけじゃだめだ!となる訳ですが、、、)

この教材の解説動画は英語なので、全部ガッツリ見るというより、概要を把握するためにサラッと参考程度に流して見ました。大切なのは、実技(PracticeとTEST)です。本番のCKS試験もしっかりと実技試験なので、下記のような学習の流れが効率良い気がしました。

  1. 解説動画をサラッと見て概要を把握する
  2. 実技(PracticeとTEST)をガッツリやる
  3. 実技の解説で不明点があれば、そこだけピンポで解説動画/書籍/ネットで学ぶ

また、講座の中で実技環境は「Killer Shell CKS」という環境を利用するのですが、特に試験前の実技練習としては、実技試験は時間との勝負という点もかなり重要です。こちらのシナリオを何度も繰り返して実践して実技に慣れておくことを強くおすすめします。

 

2.参考書籍

英語が得意でない身としては、Udemyの解説動画やネット検索だけだと学習効率が悪いと感じたため、補助的な教材として、CKSを学ばれた何人かの方がおすすめしていたこちらの書籍を購入しました。

まず本の全体構成を把握するためにサラッと流し読みしました。その後は、ガッツリ全部読むというよりは、前述した実技(PracticeとTEST)を実践した後でポイントを絞って読むのが、個人的にはおすすめの読み方です。日本語で体系的学ぶために良い教材ではありますが、対策として必須か?と言われると少し微妙な気もします。日々どんどんとバージョンが上がっていくKubernetesに対して、本の情報は古いまま更新されていかないので、その点を理解してうまく活用する必要があります。(例:Kubernetes v1.25で削除されたPSPなど)

 

3.KodeKloud(※有償:$25/月)★サブスク契約サービス

前述の教材1と2で学び、昨年(2022年11月)CKSを受験したのですが、合格には至りませんでした。Udemyの教材を一旦やり切った気がしていたので、同じ教材だとどうしてもモチベーションが上がりそうもなく、加えて同じ教材で学んでも合格できるイメージが湧きませんでした。という訳で、こちらのサブスク教材を購入しました。

こちら教材は、実はCKAとCKADのUdemy教材で講師をされているお馴染みの方(Mumshadさん)で、なぜかCKSの教材はUdemyにないので、KodeKloudのサービスをサブスク契約して直接利用するという感じでした。内容はUdemyの講座と重複する点も多々ありましたが、全体的に簡潔で分かりやすい印象でした。Udemyと同様に実技を中心に実施し、実技の解説で不明点があれば、重点的に解説動画/書籍/ネットで学ぶ、というアプローチは同様です。

 

4.Kubernetes Exam Simulator(CKS Simulator)

CKSの試験申込みを行うと、こちらの試験シミュレーター(Killer Shell - CKS CKA CKAD Simulator)を2回まで利用できるようになります。1回あたり36時間利用でき、本番に近い環境で模擬試験を実施することができます。厳密には本番の環境とは異なりますが、かなり近しい環境で本番さながらの試験を体験できるので、試験までに必ず活用することをおすすめします。この模擬試験は、解説付き解答が用意されているので、うまく回答できなかった問題は、しっかりと解説を読んで理解します。実技を伴うこの試験では、本番試験中にじっくりと考え込む時間は殆どありません。そのため、ある程度感覚的に手が動くよう訓練しておく必要があります。この模擬試験は、36時間内であれば、何度でも再挑戦することができるので、試験1~2日前くらいにアクティブ化して2~3回ほど模擬試験を繰り返して手を動かしておくと良いと思います。

注意点としては、本番の試験と違い、この模擬試験では試験問題の言語を日本語に切り替えることができないため、Webブラウザ上の試験問題の英文をChromeのGoogle翻訳拡張などで翻訳しながら実施することになり問題文を理解するのに時間を要します。よって、模擬試験に設定された試験時間では足りなくなる可能性が非常に高いですが、本番ではそのようなことはないので、問題文の翻訳に要する時間については、あまり気にし過ぎなくても大丈夫です。

 

■ 試験本番の注意点

試験本番で気をつけることは、いろいろありますが、これまで受験された方々がいろいろとまとめ記事を書いてくれています。こちらのQiita記事が比較的新しい記事だったので「当日の試験について」を参考にさせてもらいました。当日の注意点の詳細は先達の記事に委ねたいと思いますが、前回CKAとCKADを受験し、今回CKSを受験して大きく変わったと感じた点について少しだけ触れておきたいと思います。

 

1.PSI Secure Browser(仮想接続を介して安全に試験配信する専用Webブラウザ)

前回(2020年)のCKAとCKADの受験時は、自分のPCにWebブラウザを使用して試験を受験するスタイルでした。そのため事前にBookmarkするなどして、試験で問われそうなドキュメントを準備した状態で試験に望むことができました。しかし、2022年6月から受験専用ツールである「PSI Secure Browser」を使用した環境のみでしか受験できなくなりました。現在はCKSだけでなくCKAやCKADなどの他の試験も同様の環境でのみ受験可能となっています。普段から使い慣れている自分のPC環境のWebブラウザと比べて操作感やレスポンスが大きく違うためこの点についてはかなり注意が必要です。(※以下が試験環境の説明動画です)

 

2.禁止された常駐アプリ(※これは、前回試験時もあったかも、、)

試験前のシステムチェックで終了させたはずの禁止ツール(Dropbox、OneNote、etc.)のサービスがバックグラウンドで勝手に起動して試験が中断される場合があります。CKSは試験時間が足りなくなることが多くいので、試験問題以外の要因で少しでも時間が削られるようなシチュエーションになると焦って自制心が乱れてしまいそうになりますが、もし中断されてしまった場合でも、対象のツール名がメッセージとして表示されるので、慌てず落ち着いてタスクマネージャなどから対象のサービスを終了して試験に復帰しましょう。もちろん、試験に全集中している時に思考が分断されてしまうのは良くないので、できるだけ自動起動しないように設定した状態で受験するのがベストです。ちなみに、私の環境の場合、試験中に2回ほど中断される羽目になりましたが、最小限のロスで復帰できたと思います。(実は計5回も受験したので大概のことに慣れてしまったという話もありますが...😅)

 

3.試験中のWebカメラの画角(※但し、試験監督によって差がある)

試験前のチェックで試験監督の指示で、受験する部屋の中をWebカメラで撮影して不正がないことを証明します。全てのチェックが終了して試験が開始されてからは、基本的にWebカメラは受験者の正面に設置し、受験者の顔が中央にしっかりと映っている位置で、リモート試験監督に監視されながら試験を進める必要があります。私の場合、初回受験時に正面でなく、斜め横にWebカメラを設置して受験したのですが、特に注意されることもないまま試験は終了しました。しかし、その後の再試験の受験時に別の試験監督から試験中にカメラ位置の是正を強く要求され、試験監督が納得するカメラ位置になるまで試験が中断されてしまいました。時間にして数分くらいだっと思いますが、どの位置に設置したら試験監督からOKが出るかを試験中に不慣れな英語のチャットでやりとり(※しかも、ChromeのGoogle翻訳拡張などは利用できません)しながら交渉するのはかなり骨が折れました。その後、試験には復帰しましたが、そもそも試験時間が足りないことに加えて、思考の分断、時間の浪費、それらによる焦りなどもあり、その試験はしっかりと不合格になりました。そんなもん、試験入る前に言えよ!って思ったりしましたが、後の祭りでした。ただでさえ時間が足りないCKSの受験においては、こういったちょっとしたことも、事前に把握して、準備しておくことが大事だと感じました。

 

■ 最後に

ずっと絶え間なく勉強を続けてきた訳ではありませんが、CKSを取得しようと思い立ってから取得までに1年くらいかかってしまったような気がします。結果的に受験履歴はこんな感じでした。改めて見るとひどい戦歴ですね、、、😅

  1. 2022/11/06:CKS-JP試験(初陣)←★不合格 ※割引クーポン(22%Off)$320
  2. 2022/11/23:CKS-JP試験(再試験)←★不合格
  3. 2023/04/09:CKS試験 ←★不合格 ※割引クーポン(50%Off)$198
  4. 2023/04/12:CKS試験(再試験)←★不合格
  5. 2023/04/16:CKS試験 ←☆合格 ※割引クーポン(50%Off)$198

CKSの受験条件であるCKAの有効期限がもうすぐ(2023/04/27)切れてしまうこともあり、もう取得は無理かなぁ、と思った瞬間もありました。これまでCKAやCKAD、またAWSのSAPやDOPなどの勉強をして来ましたが、CKSは個人的には過去イチ難しい試験だったように感じました。昔と比べて試験制度が変わったこともあるため単純な比較はできませんが、個人的には、

個人的な試験難易度:CKS>>>>>>CKA>=CKAD

くらいの印象でした。(こちらのQiita記事の試験難易度に激しく同意です。※個人の感想)

 

なんとか目指してきたk8s認定資格の三冠を達成できたのですが、保有しているCKAやCKADはうすぐ有効期限切れを迎えます。CKAやCKADの再取得を目指すかどうかは別途考えていきたいと思いますが、残すところ10日くらいある超刹那的三冠生活中は、一旦クールダウンしようと思います(笑)それでは、お疲れ様でした🙇

 

<追記>

ご覧のとおりひどい受験履歴でして、すべての受験費用をまともに定価でお支払いすると$1185(余裕で10万円超え)となってしまいます。が、定期的に公開される割引クーポン(10~30%)や過去にCKAやCKADなどを受験していると、半額バウチャー(なかなか気付かなくて見落としがちなので是非活用すべきです)がもらえたりします。これらを駆使することで全て合計しても$716の負担で済みました。まぁ、見方によっては、これでも十分お高いかもしれませんが、個人的には必要な投資だったかな、と考えて(言い聞かせて?)います。

k8s NetworkPolicyの条件(ports)記述の注意点

NetworkPolicyでハマったので備忘録としてメモしておきます。

やりたいこと

  • 名前空間 A の全 Pod を Namespace B の Pod への送信を制限する np という NetworkPolicy を作成する。(受信は特に制限なし)
  • 名前空間 B の全 Pod が Namespace A の Pod からの受信しかできないよう制限する np という NetworkPolicy も作成する。(送信は特に制限なし)
  • ポート 53 TCP および UDP での DNS 通信を許可する。

やったこと(★失敗)

名前空間 A 用のNetworkPolicy

■ np-A.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: np
  namespace: A
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: B
    ports:
    - protocol: TCP
      port: 53
    - protocol: UDP
      port: 53

名前空間 B 用のNetworkPolicy

■ np-B.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: np
  namespace: B
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: A

やったこと(☆成功)

名前空間 A 用のNetworkPolicy

■ np-A.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: np
  namespace: A
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: B
  - ports:
    - protocol: TCP
      port: 53
    - protocol: UDP
      port: 53

名前空間 B 用のNetworkPolicy

■ np-B.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: np
  namespace: B
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: A

ハマった原因

成功と失敗で何が違うのかぱっと見ても分かりにくいと思うので差分表示してみます。

名前空間 A 用のNetworkPolicy(np-A.yaml)

←(左:★失敗) | (右:☆成功)→

これ(ハイフン「-」の有無)に目視で気付くのは、かなり難しい気がしましす。(少なくとも私には)

しかも kubernetes の公式ドキュメント「ネットワークポリシー | Kubernetes」のサンプルは今回失敗したパターンの「 ports:」の記載のみで、成功パターンの「- ports:」という記載の仕方については、特に触れられていませんでした。これはハマりやすいやつですね。

今回の「ports」とは別のNetworkPolicy設定項目(「namespaceSelector」と「podSelector」)で類似の問題について解説されている記事「Kubernetes道場 16日目 - NetworkPolicyについて - Toku's Blog」を発見して、やっと原因に気付くことができました。(※以下の内容は、記事から抜粋して引用)

しかし、このフィールドは一部のフィールドの組み合わせが許可されており、以下のような指定が可能だ。 (中略) なんとも分かりづらいが、 podSelector のハイフンが消えて、1要素になっている。 この設定は project=test-app とマッチするNamespaceにあるPodで role=frontend とマッチするものが対象になる。 要はこの記述でNamespaceとPodを同時に指定できる。

本当になんとも分かりづらい問題でした。

今後もNetworkPolicyのマニフェストを記述する際は、(portsのみならず)この点に注意したいと思いました。

さいごに

とはいえ、この手の問題は、実際に動作確認して気付くのが近道な気もするので、意図した挙動か下記のようなコマンドでとっととチェックした方が良いかもしれません。

■ 通信OK

kubectl -n A exec app1-0 -- curl -m 1 app1.B.svc.cluster.local
kubectl -n A exec app1-0 -- curl -m 1 app2.B.svc.cluster.local
kubectl -n A exec app1-0 -- nslookup tester.default.svc.cluster.local
kubectl -n kube-system exec -it test-pod -- curl -m 1 app1.A.svc.cluster.local

■ 通信NG

kubectl -n A exec app1-0 -- curl -m 1 tester.default.svc.cluster.local
kubectl -n kube-system exec -it test-pod -- curl -m 1 app1.B.svc.cluster.local
kubectl -n kube-system exec -it test-pod -- curl -m 1 app2.B.svc.cluster.local
kubectl -n default run nginx --image=nginx --restart=Never -i --rm  -- curl -m 1 app1.B.svc.cluster.local