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

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

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

Dockerfile の Lintツール hadolint を触ってみた

ハロウィンのイラスト「黒猫の魔法使い」

Dockerfile の Lintツール hadolint を試してみました。

名前は【Haskell(ha) Dockerfile(do) Linter(lint)】を略して hadolint だそうです。

Dockerfile の記述内容がベストプラクティスに沿っているかチェックしてくれます。

 

例えば、下記のような使い方ができます。(一部未確認)

  • インストールせずコンテナイメージとして実行(★確認済)
  • インストールしてコマンドラインで実行(★確認済)
  • インストールしてVSCode機能拡張と連携して実行(★確認済)
  • CI/CDパイプラインに組み込んで自動実行&通知(☆未確認)

また未確認のものもありますが、

作業記録&作業レジューム用に今回試したことをGithubに置いておきます。

https://github.com/orinbou/how-to-use-hadolint

github.com

未確認のものは後日試してみようと思います。

*[本]「Choose Your WoW!」: 働き方を最適化するディシプリンド・アジャイル・アプローチ(第2版)

組織的なアジャイルの導入を学ぶために何をしたものかと思い悩んでいたところ、たまたま知人が参加している DA勉強会 なるもの知り、私も参加してみることにしました。(DA:Disciplined Agile、ディシプリンド・アジャイル)

見学を兼ねて先月(2月9日)の月例会に参加せてもらったのですが、DA勉強会の教材としてこちらの書籍をご紹介いたいたので、早速購入して読んでみました。

www.kinokuniya.co.jp

ちなみにタイトルに含まれるWoWとは「チームの働き方(Way of Working )」のことです。(この表現は私は今回が初見でした)

今回、私は電子書籍(Kindle版)で購入したので、すぐ読めましたが、ペーパーブックだと届くまでに結構時間がかかる(確かN週間くらい)らしいので購入される方はご注意ください。

 

本の構成

本の構成は、下記のような章立てになっています。

<構成>
第1章 働き方の選択

第2章 規律の実現

第3章 ディシプリンド・アジャイル・デリバリー(DAD)とは

第4章 役割、権利、責任

第5章 プロセス・ゴール

第6章 適切なライフサイクルの選択

第7章 規律ある成功

 

印象に残った点

DAのコンセプトについて共感できる部分がいくつかあったので、以下のとおり引用させてもらいます。(DAの詳細についてはここでは触れません)

はじめに

本書を読むべき理由

・特定の考え方に依存しないアドバイスを提供する

単一のフレームワークや手法のアドバイスに限定したものでも、アジャイルとリーンにも限定したものでもない。わたしたちの哲学は、出自を問わず優れたアイデアを探すことであり、ベストプラクティスというものは存在しないのだと認識することだ(ワーストプラクティスもない)。新しい技法を学ぶとき、わたしたちはその強みと弱みは何か、そしてどんな状況に適用できるのか(できないのか)を理解しようと努める。

本書の対象読者

アジャイルの純度にかかわらず、「アジャイルの枠組み」にとらわれずにものごとを考え、新しい働き方を実験する意欲がある人々を対象としている。さらに、コンテキストが肝心であること、誰もがそれぞれ独自の状況で独自の方法で働くこと、そして何にでも当てはまるプロセスはないと認識している人々を対象としている。独自の状況に置かれているとはいえ、前に似た状況に直面した他者がさまざまな戦略をすでに考え出しており、それらを採用してテーラリングすることが可能だ。つまり、他者がプロセスについて学習したことを再利用することで、組織にとって重要なビジネス価値を高めることにエネルギーを注げる。本書はこの点を理解している人々も対象としている。

1.働き方の選択

チームが働き方を自ら選ぶべき理由

・わたしたちは最高でありたいと思っている

マーチン・ファウラーは最近、「アジャイル・コンビナート」という造語を生み出した。これは、多くのチームが「似非アジャイル」戦略(「名ばかりのアジャイル[AINO]」と呼ばれることもある)に従っている状況を表現した言葉である。こうした状況は往々にして、組織がスケールド・アジャイル・フレームワーク[SAFe]のような規範的なフレームワークを採用したうえで、チームに対しても、そうするのが実際に合理的であるか否かにかかわらず(合理的ではないケースがほとんどである)、そのフレームワークを採用することを強いている、あるいは、組織の標準として採用されているスクラム[ScrumGuide、SchwaberBeedle]に従うことをチームに強いていることの所産である。だが、本家本元のアジャイルは、個人と対話をプロセスやツールよりも重視するという非常にわかりやすいものだ。つまり、チームは働き方を自ら選び、それを進化させることを許されるべきであり、さらに欲を言えば、そのためのサポートを受けるべきなのである。

2.規律の実現

アジャイル・ソフトウェア開発宣言

「アジャイル・ソフトウェア開発宣言」の発表は、近年わたしたちが経験してきたようにソフトウェア開発の世界にとって、またビジネス界にとっても、画期的な出来事となった。しかし、時の流れは残酷なもので、アジャイル・マニフェストは次のようないくつかの点で古臭さを感じさせるようになってきた。

1.対象がソフトウェア開発に限定されている

アジャイル・マニフェストは、あえてソフトウェア開発に対象を絞って策定されたため、ITの他の側面はもちろん、エンタープライズ全体の他の側面も対象にしていない。アジャイル・マニフェストの概念の多くは、ソフトウェア開発以外の環境に合わせて調整することもでき、実際に長年そうされてきた。したがってアジャイル・マニフェストは、私たちが進化させることができる貴重な洞察を提供してくれており、当初意図したよりも対象を広げて進化させ、拡張させるべきものなのである。

2.ソフトウェア開発の世界は進歩した

アジャイル・マニフェストは1990年代の環境に合わせて策定されているため、その原則の中には時代遅れになったものもある。たとえば三つ目の原則は、ソフトウェアを2-3週間から2-3ヶ月ごとにリリースすることを勧めている。当時、デモンストレーション可能なインクリメントに分割してソリューションをデリバリーすることは、たとえ一か月ごとに行うとしても偉業だった。ところが現代では、偉業のハードルは大幅に上がり、アジャイルに習熟した企業は1日に何度も機能をデリバリーしている。これは、アジャイル・マニフェストがわたしたちをより良い方向へ導いてくれたおかげでもある。

わたしたちは以下の原則を信条とする

実際のところ、DAツールキットは当初から、さまざまな優れた戦略を組み合わせ、それらすべての戦略同士が実際にどのようにかみ合うのかに注目して開発されてきた。わたしたちは、科学的なアプローチと実際に役立つものが重要であることは信じて疑わないが、そこへたどりつく方法については、特定の考え方には依存しない。

原則:選択肢があるのは素晴らしいこと

この選択主導の戦略は中道である。両極の片側に位置するのは、規範的な手法だ。つまり、スクラム、エクストリーム・プログラミング(XP)、SAFeといった、ものごとを所定の方法で行うことをわたしたちに求める手法である。(…中略…)両極のもう一つの片側に位置するのは、自分たちの課題に注目して独自の手法を編み出し、原則に基づく新たなプラクティスを生み出して、それらを実験として試行しながら学習するという手法である。

 

おわりに

DAのコンセプトについては賛同できる点がいくつもあり、上記にその一部を引用させてもらいました。ここ最近、自分の中の問題意識として「アジャイル宣言」について思うところがあり、昨年末ブログにその思いの丈を書いたのですが、DAのコンセプトの中では、その点についてしっかりと触れられています。また、「特定の考え方に依存しない」ことを明言している点も、特定の手法を変に神格化しないという意味で好意的に受け止められました。

ということで、DAのコンセプトは概ね抵抗なく受け入れられる気がしましたが、これをどうやって実践し、更に、結果(価値)に繋げていくのか、についてはまだよく分かっていません(まだ実践してないから当たり前ですが)。

特定の考え方や手法に限らないこともあり、DAツールキット(道具箱)に収められた知識ベースは膨大な印象で、効率的に実践に繋げるための具体的な手段(DA Browserというものがあるらしいのですがまだ使ってない)がないと絵に描いた餅になりそうな気もしました。

実践に繋げるためにも、今後もDAのキャッチアップを続けていきたいと思います。