生成AI時代のSRE【サポーターズCoLab】に登壇した
4月3日、 生成AI時代のSRE【サポーターズCoLab】 に登壇しました。 資料を公開します。
4月3日、 生成AI時代のSRE【サポーターズCoLab】 に登壇しました。 資料を公開します。
在DeepSeek的威力之下,大即是正義模式正在崩潰瓦解,比起粗暴的資本堆疊也許這才是科學技術的進步。 看完新聞發完感慨之後,時隔多年我在農曆春節前夕登上了返回故鄉的飛機。其實已經準備好了電子書,所以就算是6, 7個小時的飛機也沒有那麼難熬。 飛行途中跟鄰座的年輕人自然而然地攀談了起來。「去年大學畢業。旅遊簽證去東京參加修士入學考試。朋友們都已經開始工作或者入學。因為考試完全沒心情觀光旅行。沒有直達航班在陌生的城市轉機」所有的要素跟當年的我出奇地相似,讓我想起了因為考學的壓力大到蕁麻疹發作的2017年年初。 一個人的旅途中,總會遇到很多有意思的人和事。 2007年剛上中學,在去廈門的列車上,跟火車上下鋪的惠州大哥還有他也剛剛認識的幾個大姐姐打狼人殺。具體內容早就忘記了只記得因爲我穿着一件黃白體恤於是他給我取了綽號叫大馬哈魚。 2012年上大學在去上海的臥鋪列車上遇到一個去浙江打工的大叔說鷹潭車站的雞腿好吃,要給自己老婆帶一個。聽聞我也感興趣之後深夜到鷹潭之後把我叫醒問我要不要買。那時候的臥鋪火車車站之間停的時間足夠跟站在月臺上的小販們買東西。 2013年從上海回程的列車上,遇到個大姐用中日雙語跟女兒講話。聽聞我在自學日語並且我們又是同鄉,馬上就開始講述她的傳奇人生,從沒有考上高中到去上海打工,到賭場輸掉30萬,到跟日企高管結婚,到日本婆婆不喜歡她,到她的女兒不想學日文,到她女兒用昂貴的化妝品給狗化妝。大半個車廂的人最後都成為了她的聽眾。 2014年還是在臥鋪列車上遇到了隔壁大學做慈善活動的學長,跟我講述了他組織的各種募捐活動以及自己對佛學的研究。 2015年西安青旅遇到一位退休後在世界各地旅行的天津阿姨,聽了她在世界各地旅遊的見聞,得知她的下一步計畫竟然是是去南極。她在爲此進行一系列的準備。 2016年在伊勢神宮青旅跟一個瑞士人還有日本的一家三口玩UNO,這個瑞士人僅僅學習日文幾個月卻流利到誇張,還跟我講比起外來語「オレンジ」來說他覺得「橙色(だいだいいろ)」這種說法更美。 2017年在上海住青旅,跟老闆聊了起來,他大學畢業沒有就業一人隻身騎行了大半個中國,最後在上海徐匯區開了青旅以近乎難以維持的價格爲年輕人提供住宿。 雖然他們中的大多數我再也沒有見過,跟他們的小小交集,旅途也變得更有意思。就像「回憶愛瑪儂」的故事情節一樣,如果把時間拉長到無限長,「一瞬間」跟人類所能認知的「永遠」也並沒有區別。 希望他們現在都順利。
会社のtech blogに記事を書きました KEDAを導入してAWS SQSキューとHTTPリクエストベースのスケーリングを実現する
背景 仕事ではArgoCDでGitOpsを行っており、Argo Workflowsでバッチ処理を実行するエンジンとして利用しています。 運用初期は利用者が多くなかったため、Argo CDのSSOはGitHub Team (グループ管理)とArgo CDに付随されている Dex を使用していました。 また、認可設定はシンプルに保ち、 Basic Built-in Roles を利用して、クラスタ管理者にrole:admin、利用者にrole:readonly権限を付与していました。一方、Argo WorkflowsではSSOを設定せず、デフォルトの Auth Mode であるserverを使っていたため、認証が通れば誰でもバッチのログを閲覧できる状態でした。 しかし、プラットフォームの成長に伴い、機密性の高いログが増える見込みとなり、現在の運用は対応が難しくなってきました。 そこで、先日最小権限の原則(Principle of Least Privilege、必要最小限の権限のみを付与する運用方針)に従い、Argo CDとArgo Workflowsの権限設定を見直しました。 本記事では、公式ドキュメントに記載されていない落とし穴や、実践してみて明らかになったArgo CDとArgo Workflows権限のポイントについて解説します。 Argo CDやWorkflows権限設定の権限設定を進める際の参考になれば幸いです。 Argo CD 先述の通り、今回の構成ではGitHub Teamでグループを管理し、OpenID Connect ProviderとしてDexを利用しています。この構成における認証・認可のフローは、GitHub Teams → Dex → Argo CD Applicationとなります。 Argo CDでは、グループごとにnamespaceのアクセス権限を設定することで、必要最小限の権限のみを付与できます。 ただし、Argo CDのドキュメント RBAC Configuration の記載によると、namespaceごとに設定する場合、事前に Application in Any Namespaces を有効化する必要があります。 デフォルトでは、Argo CDのApplicationはargocd namespaceに作成されるため、Applicationリソースを各namespaceに分割して配置する必要があります。この設定は比較的簡単な一方で、ApplicationSetのtemplateにおいて namespaceがサポートされていない ため、この方法を採用するのは現実的ではありませんでした。すでにApplicationSetによって複数のnamespaceにアプリケーションをデプロイしているため、ApplicationSetの廃止は容易ではありません。 その解決策として、namespaceごとにAppProjectを作成し、論理的なグループ化を行いました。AppProjectは、Argo CDにおいてアプリケーションをグループ化し、リソースやアクセス制限を設定するためのリソースです。以下は、その例です。 apiVersion: argoproj.io/v1alpha1 kind: AppProject metadata: name: samples namespace: argocd spec: destinations: - namespace: samples server: "https://kubernetes.default.svc" sourceRepos: - "https://github.com/org/repo.git" このAppProjectに対応する権限は、Dex設定用のConfigMapに定義します。 ...
会社のtech blogに記事を書きました EKSにおけるNamespaceごとにCloudWatchとEC2のコスト按分方法
副業先のtech blogに記事を書きました GKEでArgo WorkflowsにWorkflow Archiveを導入する
会社のtech blogに記事を書きました blue/green戦略によるKubernetesクラスタ更新時にIstioの対応方法
なぜ 最近のFancyなノートアプリが複雑になりすぎて個人利用には不要な機能が溢れています。 その上、自分が書いたノートなのにローカルに保存されないため、サービス障害やインシデントが起きるとを閲覧できないリスクが高いです。 そのため、MakefileとGitだけで自分用簡易ノートを作りました。 詳細 この15行のMakefileがすべてです。↓ .PHONY: pull note journal pull: git checkout master && git pull origin master today=`date +%Y%m%d` year=`date +%Y` journal_path=./journal/${year}/${today}.md name=newname note: pull @mkdir -p notes && echo "# ${name}" >> notes/${today}_${name}.md && code notes/${today}_${name}.md journal: pull @mkdir -p "./journal/${year}"; if [ ! -f ${journal_path} ]; then echo "# ${today}" >> ${journal_path}; fi; code ${journal_path} ややこしいことはやっておらず、directory journal/とnotes/にmarkdownファイルを作ってvscodeで開いているだけです。 journal/ 日記を保存するディレクトリ 年別に分けるためにjournal/配下に更にサブディレクトリYYYY/を生成するように実装している make journalを実行するとjournal/YYYY/YYYYMMDD.mdが生成される 日付などは自動生成されるので自ら記入する必要なし note/ その他のノードを保存するディレクトリ こちらは年別にわけてない make note name="hogehoge"を実行するとnotes/YYYMMDD_hogehoge.mdが生成される Markdownはコードブロックや画像挿入の機能が備えているため、ほとんど個人のユースケースに対応できます。また、ノードアプリの画像やURLを挿入する際に使う「Markdown方言」を覚える必要もなくなります。 検索に関しては、自分が普段使い慣れているIDEの検索機能を利用すればいいので、ほとんどのノードアプリより優れていると思います。 ノートをGitHubのprivate repositoryに上げておくと、GitHubにログインできれば他の端末からでも閲覧・編集できます。モバイルから編集しづらいという問題はもちろんありますが、そもそも外にいる際にスマホをいじる時間を減らして周りの景色を楽しんだほうがいいでしょう。 最後に シンプルなノードアプリを自作しましょう! ノートアプリを選んでカスタマイズする時間・お金があるのであれば、自分の趣味などに充てたほうがよいのではないでしょうか。 また、GitHub PagesとMarkdownで自作個人ナレッジマネジメントツールに興味のある方は筆者が2年前に書いた この記事 も併せて読んでみてください。 ご参考になれば幸いです。 ...