#docker

Docker を日常的に使っている人でも、実際にその中身がどう動いているかまで意識する機会は多くありません。今回の元記事は、著者が自作の container runtime を作り始めたところで、Docker の正体が思った以上に変わった仕組みの集まりだと気づいた、という話です。単なる雑談ではなく、普段「当たり前」に見えるツールが、どれだけ Linux の素の機能や妙な工夫の上に乗っているかを、かなり素朴な言葉でほどいています。読み終えると、コンテナが便利な理由だけでなく、なぜ扱いが難しいのかも少し見えてきます。 元記事の著者は、遊び半分で自分の container runtime を作り始めたところ、Docker について「変だ」と感じる発見がいくつもあったと書いています。まず強調するのは、コンテナは VM のような“本当に独立した箱”ではない、という点です。コンテナの中で動くのは結局ただの process で、kernel はその process を普通に動かしています。見ようと思えば `/proc` の中からその process を見つけることもできる。隔離されているように見えて

Docker Engineering が GitHub に公開した `docker/docker-agent` は、ひとことで言えば「AI エージェントを作って、動かして、配るための土台」です。ふつう AI エージェントというと、個別のアプリやチャット画面の中に閉じたものを想像しがちですが、このリポジトリはそこを Docker の流儀に寄せています。YAML で定義し、CLI から動かし、OCI registry に載せて共有する。今これを取り上げるのは、生成 AI の話が「モデルを使う」段階から「運用できる部品にする」段階へ移っているのが、かなりはっきり見えるからです。 このリポジトリの README は、`docker-agent` を「AI Agent Builder and Runtime」と説明しています。Docker Engineering が作ったもので、AI エージェントを構築し、実行し、共有するための仕組みだと位置づけています。特徴的なのは、コードを書き込むより先に、YAML でエージェントを定義する点です。README では `agents:` の下に `root`

What surprised me most here is not that the setup broke. It’s that it broke in five different directions, and most of the failures were *self-inflicted by automation that had too much authority*. That’s the part I’d actually take seriously if I were running something similar: not the individual bugs, but the pattern of an agent with shell access, resumable state, and the habit of “helping” while you’re trying to repair it. The strongest bit in the post is the ugly one about the agent resuming it

Baseten を inference の提供元として使おうとしていたセキュリティ企業 Strix が、公開されていた Docker/Harbor 系のイメージを自動調査したところ、古い GitHub personal access token を見つけた、というのがこの話の骨子だ。しかもそのトークンは生きていて、Baseten の内部 GitHub リポジトリに対して admin 権限を持っていたとされる。外部サービスを業務に組み込む前に、相手側の足元を自分で点検する。その重要性をかなり生々しく示した事例だと思う。 Strix は自社の自律型ハッキングエージェントを使い、`*.baseten.co` を対象にクレデンシャルなし、ソースコードなしで調査を走らせた。Baseten は推論基盤を提供する企業で、Strix は自分たちのデータやモデル、コードを預ける前に、まず相手のセキュリティを確認したかったという。調査を始めて約25分後、Strix は Baseten の GitHub personal access token を見つけたと主張している。 最初の入口は Harbor とい

このエラーが出たとしても、同じ見え方で中身が違うことがあります。今回の issue 報告では、少なくとも二つのパターンがありました。ひとつは Remote Control のセッション登録が失敗するケース、もうひとつは `/remote-control` をその場で打ったときに最初の一回だけ無言で失敗するケースです。 手元で実際に確認できた環境情報はこれだけです。 ```text OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64) Python : 3.8.13 検証日時 : 2026-09-16T08:51:20+09:00 ``` この情報だけでは、今回の症状が issue のどちらと一致するかは断定できません。ただ、もしあなたの環境で次のどれかに当てはまるなら、報告されているクラスタにかなり近いです。 Docker やコンテナの中で Claude Code を動かしていて、Remote Control の登録だけが失敗する `/remote-control` を最初に打ったときだけ何も起きず、二回目で通

Omarchyで、ふつうのユーザーが動かすあらゆるプロセスからroot権限に近い操作ができてしまう設定不備が見つかりました。見つかったのはDockerの既定設定に関する問題で、影響を受ける環境ではパスワード入力もsudoも権限昇格の確認も必要ありませんでした。公開した筆者は、すでに責任ある開示の手順で報告し、修正されたので詳細を明かしたと説明しています。Omarchyを使っているなら、まず確認すべきはシンプルで、4.0.1への更新です。 元記事が指摘しているのは、Omarchyの既定ユーザーがLinuxの`docker`グループに入っていたことです。Dockerを使ったことがある人なら、`docker run ...` を`sudo`なしで実行できる設定だと考えると分かりやすいでしょう。ただしこの便利さには重い代償があります。ArchではDockerデーモンがrootで動き、`/var/run/docker.sock` を待ち受けています。`docker`グループのメンバーはそのソケットにアクセスできるため、rootで動くデーモンに命令を送れる。Docker自身も、`docker`グル

MCP（Model Context Protocol）は、AIエージェントが外部ツールや社内システムにつながるための“共通のつなぎ方”みたいなものです。ローカルで試すだけなら、`python server.py` の一発で動くこともあります。でも、企業で本番運用するとなると話は別。元記事は、そのギャップをかなり実務的に埋めにいく内容でした。 正直、こういう記事は地味に見えて、あとで効いてくる話が多いです。認証が甘いと危ないし、止まったら困るし、アップデートで既存接続を切るのもまずい。AIまわりの話は派手なデモが目立ちますが、現場ではむしろこの“つまらないけど重要な部分”が本体だと思います。 ローカルで動くMCP Serverと、本番運用のMCP Serverでは考えるべきことがまるで違う 本番ではまず「認証」「監視と再起動」「安全なアップグレード」の3点が大事 認証は用途で使い分けるのが現実的 - 社内向けなら API Key - ユーザーごとの権限が必要なら OAuth 2.0 - 厳しい規制がある業界では mTLS Dockerでは `restart`、`internal: tru

高性能なLLMを「自分のPCや自宅サーバー」で動かすための、かなり本気の実践メモ集です。 予算ごとに「どこまでできるか」をはっきり書いていて、夢物語ではなく現実の設計図になっています。 4枚のRTX PRO 6000を使った構成は豪快ですが、単なるお金の話ではなく、PCIeスイッチや電力制御まで踏み込んでいるのが渋いです。 speech-to-text（音声→文字起こし）やDockerを使った運用も含まれていて、実験ではなく“使うための環境”として整っているのが強いです。 このリポジトリは、ひと言でいうと「ローカルでLLMをちゃんと使うための、かなり筋の通った設計図」です。 しかも雰囲気がいい。ふわっとした夢の話ではなく、「$2,000ならここまで」「$40,000ならこの景色」という、かなり生々しい金額感で話が進みます。ここがまず面白いところです。 最近のLLMはクラウドで使うのが当たり前になりましたが、ローカルで動かす意味はちゃんとあります。たとえば、外部サービスにデータを投げたくない場面。社内資料や個人メモ、音声データみたいな“出したくない情報”を扱うとき、手元で完結する安心感は

What makes this story interesting from a Claude / Claude Code perspective is less the headline and more the direction of travel: the tooling stack around LLM development is becoming more “platform-like,” and Docker is clearly trying to sit closer to where developers already work. For Claude users, that matters because the fastest path from prompt to production often runs through containers, reproducibility, and deployment workflows. The source points to Docker quietly positioning itself as an AI