#devops

Linuxカーネルに、ローカルユーザーがroot権限を取れてしまう脆弱性が2件公開された 1つ目は Copy Fail（CVE-2026-31431）、2つ目は Dirty Frag（CVE-2026-43284 / CVE-2026-43500） どちらも page cache（ファイルの読み書きを速くするためのメモリ上のキャッシュ）を悪用する 以前大きな被害を出した Dirty Pipe と同系統の問題で、しかも多くの主要ディストリビューションに影響する 攻撃にはネット越しの侵入ではなく、ローカルの一般ユーザー権限が必要 とはいえ「一般ユーザーが入れれば終わり」なので、サーバーや共有環境ではかなり重い話 影響組織は即パッチ適用が必要 InfoQが伝えたのは、Linuxカーネルに見つかった2つのローカル権限昇格（local privilege escalation）の脆弱性です。 ざっくり言うと、普通のユーザー権限しか持っていない人が、OSの最強権限であるrootを取れてしまうという話です。これはかなり危ないです。roo

Moonrepoの `moon` が v2.0 に到達。コードネームは Phobos いちばん大きい変化は、toolchain がWASMプラグイン方式になったこと YAMLだけでなく、JSON / JSONC / HCL / Pkl / TOML など複数の設定形式に対応 CLI が整理され、`moon exec` を軸に `moon ci` / `moon check` / `moon run` を統一 task inheritance が 設定ベースに再設計され、モノレポでのタスク共有が扱いやすくなった Docker、VCS、.env、migration まわりも大幅に手直しされている ただし breaking changes が多いので、v1からは素直なアップデートでは済まない Moonrepoの `moon` は、ひとことで言うと モノレポ管理のための道具箱 です。 モノレポというのは、複数のアプリやライブラリを1つのリポジトリでまとめて管理するやり方のこと。規模が大きくなるほど「どのプロジェクトで何をどう実行するか」を

Joynのバックエンドは、最初は単一ノード中心で壊れやすい構成だった 問題の本丸はコードだけでなく、データ整合性・可用性・デプロイ時間だった 解決策としてserverlessに移行し、AWSのmanaged servicesを積極活用した データの一貫性にはHub and Spoke patternを採用 障害の広がりを抑えるためにcell-based isolationを使った さらに、multi-region active-activeを現実的なコストで実現する工夫が重要だった InfoQの「Evolution of a Backend for a Streaming Application」は、ドイツのストリーミングサービス Joyn のバックエンドが、どうやって“火の車”状態から立て直されたのかを語るプレゼンだ。 話しているのは Daniele Frasca さん。ざっくり言うと、「最初はかなり苦しい構成だったけど、AWSベースのserverlessへ段階的に移行して、可用性・スケーラビリティ・デプロイ速度を改善していった

月額 `$340` だったインフラ費用を、`$136` まで削減した やったことは「コードの大改修」ではなく、設定と運用の見直し 具体策は、インスタンスの適正化、使っていないDBの削除、静的ファイルの移動、クエリ改善、予約課金の活用 いちばん大事なのは、“なんとなく不安だから大きめ” をやめて、実測すること こういう改善は派手じゃないけれど、実際にはかなり効く。個人的にも、ここをサボるとクラウド費用は静かに膨らむと思う 元記事の筆者は、約 5 万 MAU（Monthly Active Users = 月間アクティブユーザー数）のアプリを運用しながら、クラウド費用を 月額 $340 から $136 に削減したそうです。 削減率はなんと 60%。しかも、アプリのコードを大きく書き換えずに、です。 これ、かなり面白い話です。 「性能改善 = 開発の頑張り」と思いがちですが、実際は “どんなインフラを、どう使っているか” のほうがコストに直結することが多いんですよね。クラウドは便利な反面、放っておくと“使ってないのに課金される箱”が増えが

Hyperledger FabricをKubernetes上で「本番っぽく」動かす構成を紹介している ただ動かすだけでなく、自動デプロイ・ログ出力・待機処理・エラー検知まで丁寧に作り込んでいる セキュリティ面では、rootで動かさない、権限を絞る、NetworkPolicyで通信を制限するなど、かなり堅実 Fabric特有のつらさは、やはり証明書や鍵などのcrypto material管理にある 今後は監視、Secrets管理、CI/CDまで広げたい、という流れになっている この記事は、Hyperledger Fabricという企業向けのブロックチェーン基盤を、Kubernetes上に構築していく開発日記の4日目の記録です。 タイトルだけ見るとかなり硬そうですが、内容はむしろ「地味で面倒なところを、どうやって本番運用に耐える形へ持っていったか」という実践寄りの話です。 ここが面白いところで、ブロックチェーンって「未来っぽい」響きがありますが、実際に動かすとなると、かなり泥臭いインフラ作業になるんですよね。この記事はその現実をちゃんと見せています。 まず前