もう、朝
寝れてないのでついでに明後日の登壇資料の準備をしている。あとは謎の挙動にぶつかってLDAP にキレていたのを Sleep で切り抜けたので明日、聡明な自分が解決してくれることを信じてます。 2021年3月11日にCLOUDNATIVE DAYS SPRING 2021 ONLINE に登壇しました(事前収録)。 発表では 主に Docker/Kubernetes でのCI 周りのツールの紹介などを行いましたが日々のコンテナイメージのレビューに憑かれた人に向けて多少楽になる一助になればいいと思いました(ほんなこつ???)が時間管理が無限に下手で本当に入門なだけになってしまいました。 結局、言いたいことの骨子をまとめてないからこんなことになるんやぞ!!!
あとは所属組織でCloudNative Days Spring 2021 Onlineにトップスポンサーで協賛をしておりその関連で幕間CMを撮りました。これを見た幼稚園の頃からの幼馴染からインスタ経由でDMが来ました。 ソフトウェアエンジニアとして正しい仕事しかしたくないみたいな感情は1年目になくなったのでなんでもやります。登壇資料よりこっちの方が伸びていて複雑な感情になった。
やってました…
— nwiizo (@nwiizo) 2021年3月11日
最後のジャンプだけ見てください…https://t.co/AKJ5UkKkcC https://t.co/TuwMv6cBTk
今回は登壇にあたって選考などはなく登壇者は動画を送れば終わりである。最初に聞いた時にはどうすんだろ...とギョッとしましたが1日目を終えた時には多様な価値観や発表を聞いてそれらが杞憂であると確信できました。
また、公式ブログには以下のような文章があります。
『今ならオンラインの特性を生かして、CloudNative Daysをダイナミックな環境でスケーラブルな形に更に進化させられるのではないか?』 オンラインでは、誰でも情報を得ることができ、誰もが発信することもできます。オープンな思想のもとに作られたインターネットには境界がありません。 そうしたインターネットの成り立ちを思い出し、初心者から達人まで、住んでいる場所を問わず、クラウドネイティブに取り組む人が、 ・今まで参加者だった人が壁を感じずに発信できる
一日目を終えただけですが今回はどの発表も素敵で、非常に多様化していると感じました。しかし、自由であるが故に同じ時間と場所を共有できないコミュニケーションの難しさを感じました、。資料や発表に対する意見を聞けずに悲しい顔をしてます。
資料で紹介したツールの紹介
Docker
Docker は DockerfileをbuildしてImageを生成して Imageを実行してcontainer が爆誕するという大まかなながれがあるので 確認ポイントがDockerfile、DockerImage、実際の環境での3つある。実際の環境での確認は環境にもよるがeBPF とか言い出さなければならないので今回はスコープから外します。
hadolint
ベストプラクティスのDockerイメージを構築するのに役立つよりスマートなDockerfile Linter です。設定ファイルを置くことで特定のルールは無視することができるのでCIにも組み込みやすいと思います。
ちなみに、hadolint から指摘されすぎて hadolint 先輩って呼んでます。
dockle
ベストプラクティスのDockerイメージや セキュアなイメージを構築するのに役立つDocker Image Linter です。
hadolint との違いは hadolint はDockerfileに対してのLinterなのに対してdockle はDocker Imageに対するLinter であることです。Event を拾う場所、適用する場所が違います。
ある程度似たようなことも言ってくるのですが、はじめ易さでいうと hadolint に軍配があるとは思います(独自的偏見)。
Trivy
コンテナ脆弱性スキャンツールで、コンテナイメージからコンテナの OS パッケージやアプリケーションの依存ライブラリの脆弱性を検出してくれます。
レポートの仕方も多様で滅茶苦茶にユーザーの事を考えているツールだと思います。
container-structure-test
コンテナ内部でコマンドを実行することで正しい出力やエラーが帰ってくるかどうかや、コンテナ内部のファイルが正しく格納されているかなどの検証を実行できるフレームワークです。
Goss っぽいことができます。内部でコマンド実行して結果を確認するだけなんでコマンドで確認できるものは確認できます。ちょっとしたテストだとこれでどうにかなります。
ShellCheck
資料にないし登壇でも言及してないが非インフラエンジニア も entrypoint.sh などでシェルスクリプトを書く機会が増えると思う。要出典ではあるのだがシェルスクリプトは普通に動いてくれるので想定外の処理 を埋め込んでしまうことが多々ある。そんな時に頼りになるのがshellcheck である。不用意なrm などを諫めてくれたり変数の取り扱いなど良くハマるあれやこれやを指摘してくれる。頼もしい
Kubernetes
Kubernetes のマニュフェスト を確認できるツールは大きく分類すると主に3つのカテゴリに分類できます。
API Validators とは Kubernetes APIサーバーに対して特定のYAMLマニフェストを検証
Built-in checkers とは セキュリティ、ベストプラクティスなどの決まったものの検証を行う
Custom validators とは自らでルールや規約を作成して検証を行う、API Validators と違ってURLの重複チェックなどができないが大体気軽。
kubeval Built-in checkers
kubeval は、Kubernetes manifest のファイルを検証するために使用され、単純な記述ミスを検知することができます。
kubectlには kubectl apply --validate=true --dry-run=true -f manifest.yaml
で検証を行う事ができます。kubectlを使った検証方法では実際に対象のmanifestファイルを実行するため権限が必要
kube-score Built-in checkers
kube-score は、Kubernetes manifest のファイルを分析し、スコアを付けされます セキュリティの推奨事項とベストプラクティスに基づいてチェックされこれらを選択することができます。
conftest Custom validators
conftest は YAML や JSON などの構造化データに対してユニットテストを記述できるツールです。
ポリシーはOpen Policy Agent (OPA) で使われているポリシー言語 Rego で記載することができます。
柔軟性が高くyaml の確認ができるので様々なツールで利用可能で組織横断で使う設定を決めてしまえるのでかなり、オススメ!!!!!
さいごに
おわり、。特に振り返りもしてないけど もう眠い。
宣伝
グループ内でいくつか発表があったので紹介させてください。感想は気が向けばあとから追記します。
「PGマルチペイメントサービス」のマイクロサービス移行計画
決済システムにおけるクラウドネイティブへの挑戦
インフラ目線でみた、初めてコンテナでサービスをリリースする時のセキュリティポイント
最近、推してる音楽
歌詞と歌声があまりにも最高なので聞いてくれ!!!!!!!!
年老いて眠くなる 死ぬ前になってわかる 人は何を恐れて夢み 今は生きてることに感心だ つまらない感情抱えた今 最低なことばかりじゃない youtu.be
Open Policy Agent Rego Knowledge Sharing Meetup
別でOPAのイベントがあったようなのでぜひ、みて欲しくて動画を追加しておきました。