2024年2月にリリースされた AWS CloudFormation の「IaC ジェネレーター機能」を使うとマネジメントコンソール・AWS CLI などを使って作った（作ってしまった）リソースをスキャンして，自動的に AWS CloudFormation テンプレート化 (YAML / JSON) できる❗️もちろんそのまま AWS CloudFormation スタックにリソースをインポートすることもできる． aws.amazon.com 今までも AWS CloudFormation のインポート機能はあったけど，リソース設定と見比べながら（そしてドリフト機能を活用しながら）テンプレートを書くのはそこそこ大変さがあったと思う．IaC ジェネレーター機能を使う流れは以下のブログにも載っていて，今回紹介するワークショップの内容にも似ている👀 aws.amazon.com IaC Gen

Trivy の「Misconfiguration Scanning」は Terraform をサポートしていて（AWS CloudFormation もサポートしている👏），Terraform コードのセキュリティ課題や設定ミスを検出できる❗️Trivy を活用した Terraform のスキャンを試した作業ログをまとめる📝 aquasecurity.github.io tfsec から Trivy へ 🔜 tfsec は現在も使えるけど，今後は Trivy に移行する流れとなっている💡 GitHub Discussions に今年2月頃 tfsec is joining the Trivy family というアナウンスが投稿されている❗️ github.com さらに GitHub の tfsec リポジトリ（master ブランチ）に今年5月頃 Migrating from

今まで GitHub Actions から AWS を OIDC (OpenID Connect) で連携する場合にサムプリントを取得して ID プロバイダを作る必要があった💡しかし，2023年6月27日に GitHub Changelog でサムプリントを2種類設定するという記事が公開されて対応することになったけど，2023年7月6日から AWS 側で自動的に証明書の検証をしてくれるようになって，特に気にする必要がなくなった．結果的に適当なサムプリントを指定しておけば良く楽になった👀 動作確認をする機会があったので簡単にまとめておこうと思う． github.blog ちなみに「2023年7月6日」という日付は AWS から送られてきたメールに載っていた📩 [NOTIFICATION] OpenIDConnect (OIDC) errors when using GitHub OID

HTTP ヘッダーを使ってアプリケーションのパフォーマンスメトリクスをクライアント側に返す仕様「Server Timing」を調べながら試してみた．詳細な仕様は以下の W3C ドキュメントに載っている．ドキュメントの Introduction に載っているけど，今まではクライアント側で "レスポンスタイム" は確認できても「どの段階でなぜ時間がかかったのか」という詳細までは確認できなかったという背景がある．そして Google Chrome 65 以上など，Server Timing をサポートしてるブラウザなら DevTools で可視化できる❗️ www.w3.org Server Timing 仕様 仕様としては HTTP ヘッダー Server-Timing にパフォーマンスメトリクスを設定してレスポンスを返す．フォーマットは以下の通り（W3C ドキュメントを引用）． Server

ID を採番するときによく使われる UUID Version 4 の課題として「順序性がなくソートしにくい」という側面があり，ULID (Universally Unique Lexicographically Sortable Identifier) を使えばソートできるようになるという記事を前に書いた． kakakakakku.hatenablog.com 関連して調査をしていたら，標準化団体 IETF (Internet Engineering Task Force) によって，UUID Version 6, 7, 8 という新しい仕様が提案（ドラフト段階）されていることを発見した❗️UUID Version 6, 7, 8 の目的を簡単にまとめると「タイムスタンプ情報を使ってソートできる ID を採番できるようにする」となり，もしこの仕様が取り込まれると，UUID を活用する幅がさ

データベースのマイグレーションを行うツール migrate を試した．migrate は MySQL / MariaDB / PostgreSQL / Amazon Redshift / MongoDB / Cassandra など，多くのデータベースに対応している．GitHub リポジトリを見るともっと多くのデータベースに対応していることがわかる．他にも GitHub や Amazon S3 に置かれたマイグレーションファイルを直接読み込む機能や Go ライブラリとしてアプリケーションに組み込める機能などもある．今回は MySQL を使ってマイグレーションの基本的な機能を試す❗️ github.com インストール macOS だと Homebrew を使って簡単に migrate CLI をインストールできる．今回は v4.15.2 を使う． $ brew install golang

Pluto を使うと Kubernetes マニフェストの apiVersion に対して deprecated（非推奨）と removed（削除）を検出できる．警告自体は Deprecated API Migration Guide | Kubernetes を見れば確認できるし，kubectl apply コマンドを実行したときにも表示されるけど，Pluto は実行前に確認できて便利！パイプラインに組み込むのも良し！ github.com セットアップ Pluto CLI は macOS なら Homebrew を使えば簡単にセットアップできる．今回は現時点で最新となる Pluto v5.10.2 を前提とする． $ brew install FairwindsOps/tap/pluto $ pluto version Version:5.10.2 Commit:0070fa70364

jupyter nbconvert コマンドを使うと Jupyter Notebook を Python コード / PDF / HTML などに変換できる．指定できるフォーマットの一覧は GitHub に載っている．また Jupyter Notebook で使える Download as メニューも同じ仕組みを使っている． github.com Python コード Jupyter Notebook を「Python コード」に変換するなら --to script オプションを使う．例えば，MLOps として「データサイエンティスト」の実装した Jupyter Notebook を「機械学習エンジニア」が Python コードにリファクタリングするときに使えたりする． $ jupyter nbconvert --to script xxx.ipynb PDF Jupyter Notebo

記述したテンプレートから YAML を生成するツール 「ytt」 を試す．ytt は YAML に対して「テンプレート機能」と「オーバーレイ機能」が使える．VMware 社を中心に開発されているツールセット Carvel に含まれている． carvel.dev YAML のテンプレート機能やオーバーレイ機能と言えば，特に Kubernetes の文脈だと Kustomize や Helm が代表的だと思う．ytt も似たように使えるけど Kubernetes に限らず「汎用的に使える」というメリットがある．他にはテンプレート構文を含めても「YAML フォーマットとしては valid のまま」という点もメリットに挙げられると思う．汎用的に使えるということは，例えば AWS CloudFormation テンプレートを生成することにも活用できる．ytt と関連ツールの違いは以下のドキュメントに

コンテナワークロードにおけるセキュリティ対策の理解を深めるため「Docker/Kubernetes 開発・運用のためのセキュリティ実践ガイド」を読んだ．実は本書は 2021年7月頃 に1度読み終わっていたけど，実際に気になった部分を試したり，CKS (Certified Kubernetes Security Specialist) を受験 しながら読み直していたら書評記事をまとめるのが遅れてしまった (；・∀・) 本書を読んで1番良かったと感じるのは「セキュリティに関して "知らなかったことに気付けた"」ことだと思う．苦手意識のあるセキュリティ領域に対して「視野を広げる」ことができた．本当に読んで良かったと思うし，何よりも「日本語で」読めることに感謝しかない！本書は 2020年2月 に出版されていて，Kubernetes 1.16.1 を前提にしていたり，ランタイムなども含めて多少のアッ

Kubernetes でコンテナワークロードの脅威検出として使える「Falco」に入門する．CNCF (Cloud Native Computing Foundation) で Incubating に位置しているプロジェクトで，今回は実際に Falco を使って Pod に対する操作（振る舞い）を検出したり，独自ルールを作る．Falco はコンテナに限らず，ホスト側のプロセスも監視できる． falco.org インストールをする 🦅 以下の検証環境を使う．ドキュメントに書いてある Ubuntu の手順をそのまま使って，ワーカーノードに簡単に Falco v0.31.1 をインストールできた．また Helm を使って Kubernetes 上に Falco を DaemonSet としてインストールをする選択肢もある．Falco は日本語ドキュメントがとても充実しててイイ✨ Kubern

最近「Monokle」を使っている．Monokle（モノクレ）は「Kubernetes マニフェスト用エディタ」とも言えるアプリで，2週間ほど使って操作にも慣れてきたので紹介する！macOS でも Windows でもアプリをダウンロードすればすぐに使えるぞ！ github.com 機能 ☸️ Monokle の機能（できること）はドキュメントに載っている．機能は本当に多くて，継続的にリリースもされている．今回は代表的な機能を4点紹介する！Monokle v1.6.0 を前提にする．UI は日々変わるかも！ マニフェスト操作 Kustomize 対応 Helm 対応 Kubernetes クラスタ統合 kubeshop.github.io 検証環境 ☸️ 今回はブログ記事用にサンプルマニフェストを管理するディレクトリを作った（非公開）．すぐに試すなら普段仕事などで使っている GitHub

Kubernetes で「Pod Topology Spread Constraints」を使うと Pod をスケジューリングするときの制約条件を柔軟に設定できる．今回は Zone Spread (Multi AZ) を試す！詳しくは以下のドキュメントに載っている！ kubernetes.io spec.topologySpreadConstraints Pod Topology Spread Constraints を使うために YAML に spec.topologySpreadConstraints を追加する．構文と各項目の概要を以下にまとめる．単純に Node Label を指定するだけではなく maxSkew や whenUnsatisfiable も設定できて柔軟さを感じる💡 topologyKey : スケジュールする制約条件に使う Node Label maxSkew

Kubernetes で VPA (Vertical Pod Autoscaler) を使うと，Pod に設定する CPU / Memory リクエスト値をオートスケールできる．CPU / Memory リクエスト値 (spec.containers[].resources.requests) に対する「スケールアップ」と「スケールダウン」とも言える．今回は VPA を試していく．なお，VPA コンポーネントは Kubernetes Autoscaler の GitHub リポジトリに含まれている． github.com 準備 1 : Kubernetes クラスターを構築する 🐳 今回は kind を使って，Mac 上に検証用の Kubernetes クラスターを構築する．以下のように v1.19.1 を使う． $ kind create cluster Creating cluste

「n8n.io」を使うと GitHub / Slack / Google Sheets など多くのサービス（ドキュメントを見ると 240 以上もインテグレーションできる！）を組み合わせて自由に「ワークフロー」を構築できる．関連サービスで言えば IFTTT のような感じ！例えば IFTTT Pro に課金せずにセルフホスティングできたりする．今回は「n8n.io 入門」を目的として Mac で Docker を使って「n8n.io」を試す．現状だと Docker と npm (npx) で試せる．なお，SaaS として使える「n8n.cloud」もある（最近まで coming soon になっていた）． n8n.io n8n.io 入門 : 完成形 今回は「GitHub リポジトリに対する Star⭐/ Unstar⭐をトリガーに Slack 通知とコマンド実行に条件分岐をするワークフロー」

「モブプログラミング」を採用すると「全員で同じタスクに取り組む (WIP 1)」ため，複雑な Git ブランチ戦略は必要なくなる．例えば master ブランチと develop ブランチだけで運用することもできる．今回紹介する mob コマンドを使うと，モブセッションで繰り返し行なう「ドライバー（タイピスト）交代」をシュッと実現できる．特に「リモートモブプログラミング」だと GitHub に git push をしてドライバーを交代する（Git Handover と言う）ため，mob コマンドを使うと便利！ mob.sh インストール mob コマンドは brew コマンドで簡単にインストールできる．そこそこ頻繁にリリースされているため，定期的に brew upgrade をしておくと良さそう．今回の記事を書いてる間にも v0.0.13 ➔ v0.0.17 にバージョンアップしていた．

無限に届くメールを整理するために Gmail の「フィルタ設定」を使っている人は多いと思う． ラベルを付けたり アーカイブをしたり 削除をしたり 僕自身 Gmail を10年以上（メールを遡ったら2006年頃から）使っているため，歴史的な経緯から「フィルタ設定」が増えすぎてしまって，もはや管理不可能になっていた．もともと「フィルタ設定」には XML 形式で「エクスポート」と「インポート」をする機能があるけど，もっとシンプルに設定を記述し，GitHub で管理し，継続的にデプロイする「Gmail Filter as Code」 を実現できたら最高だな！と考えていた． gmailfilters とは？ gmailfilters を使うと，TOML フォーマットで Gmail フィルタ設定を記述できる．以下の例は「notifications@github.com から届くメールに GitHub

2012年に Heroku のエンジニアによって提唱された「The Twelve-Factor App」は素晴らしく，アプリケーションをうまく開発し，うまく運用するための「ベストプラクティス」として知られている．2020年になった現在でもよく引用されていると思う．日本語訳もある． 12factor.net Beyond the Twelve-Factor App とは？ クラウド化が進むなど，提唱された2012年と比較すると技術的な変化もあり，今までの「The Twelve-Factor App」で宣言されていた観点以外にも必要な観点やベストプラクティスがあるのでは？という意見もある．そこで，2016年に Pivotal のエンジニアが「Beyond the Twelve-Factor App」を提唱した．The Twelve-Factor App にあった「12項目をアップデート」し，新

2019年10月に発売された「Ansible 実践ガイド 第3版」を読んだ．実は今年の頭に「第2版」を購入していて，読もう読もうと積読をしていたら「第3版」が発売されたため，すぐに買い直して積読の優先順位を入れ替えた．個人的にプロダクション環境だと Chef の経験が長く，Ansible の経験が少ないこともあり，体系的に知識を整理しておこうという目的で読んだ． 読んだ感想としては，Ansible 初学者を中心に「Ansible で実現できることを知る」ことに適した良い本だと思う．Ansible の基礎から応用（徹底活用）まで幅広く学べる．逆に言うと，仕様を網羅したリファレンス本ではないし，ステップバイステップに写経をしながら試す本でもなく「どう読むと効果的なのか？」は気になるところ．今回は検証環境を Vagrant と Amazon EC2 に構築し，本書をリファレンスのように読みながら

今回は Docker で使える「ヘルスチェック機能」を試す．Release Note を読むと，機能としては Docker 1.12 から使えるらしく，3年前からあったなんて...！仕組みとしては，Docker デーモンからコンテナに指定したコマンドを定期的に実行する． Dockerfile 構文 「ヘルスチェック機能」を使う場合，まず Dockerfile に HEALTHCHECK を設定する．実行するコマンド以外に以下のオプションも設定できる．注意点として，--retries 以外は秒数を指定するため，表記は 5s のように単位も付ける． --interval=DURATION (default: 30s) --timeout=DURATION (default: 30s) --start-period=DURATION (default: 0s) --retries=N (defa