Node.js互換でコンテナよりも高密度と高速起動を実現する「Edge.js」、Wasmerが発表
WebAssemblyランタイム「Wasmer」を開発提供するWasmer社は、Node.js互換かつコンテナよりも高密度な集約と高速起動を実現する「[Edge.js](https://edgejs.org/)」を発表しました。 What if you could run ANY Node.js app unmodified, safely anywhere… without Docker, containers, or security headaches? Introducing Edge.js • Fully compatible with Node.js • Sandboxed by design • Pluggable with any JS engine Node.js, but actually safe. And everywhere pic.twitter.com/Zh9
Node.js on Dockerでスリムかつセキュアなコンテナイメージを作る - 2025年版
はじめに みなさんはDockerfileを書いていますか？ 近年はAIによる支援でDockerfileをスクラッチで書く機会が減っていると考えられます。 しかしながら、AIに書かせる場合でも良い書き方を知っていることで、その後の修正が容易になります。 この記事では、Node.jsアプリケーションのDockerfileを作成する際に、私ならこのように書くという提案をします。 作成するDockerfileとディレクトリ構造 初めに、完成形のDockerfileとディレクトリ構造を示します。 以降のセクションで実装のポイントを解説していきます。 実行可能なサンプルコードはGitHubで公開しているので、必要に応じてこちらも参照してください。 Dockerfile 各種バージョンは記事執筆時点での最新版です。 # syntax=docker/dockerfile:1.20.0 FROM node:
yomitokuで作る日本語OCR Webアプリ【Flask + TypeScript】
はじめに 昨今、AI が急速に普及している中で、改めて「OCR（光学文字認識）」という技術に注目してみました。 OCR の API サービスは多数存在していますが、どれも従量課金制で、利用量が増えるとコストが膨らんでいきます。Google Cloud Vision API や Amazon Textract などは高精度ですが、個人開発や小規模なプロジェクトでは原価が気になるところです。 「日本語 OCR を自分で構築できれば、コストを気にせず色々なことに使えるのではないか？」 OSS の OCR ライブラリとしては、Tesseract や EasyOCR などが有名ですが、日本語の認識精度や文書構造の理解という点では課題がありました。そんな中、日本語に特化した「yomitoku」というライブラリを見つけたのですが、実際の使い勝手や実装方法について詳しく解説した記事があまり見当たりませんで
esa公式のローカルMCPサーバーを公開しました - ReleaseNotes/2025/09/17
Repository はこちら 👉 https://github.com/esaio/esa-mcp-server README に詳しいインストール方法が書いてあります。 dockerやnpxの事前インストールが前提となります。 より気軽にご利用いただけるリモートMCPサーバーも、現在開発中なので楽しみにお待ちください(\( ⁰⊖⁰)/) > esa公式 ローカルMCPサーバの主な機能esa公式 ローカルMCPサーバの主な機能 esa でご利用いただける、具体的な機能を紹介します。 今後も、随時追加を予定しております 🤖 Claude 等の AIアシスタントを通して、チャットベースでこのようなイメージで利用が可能です 🤖💬 > 利用可能な Tool利用可能な Tool > チーム管理チーム管理 アクセス可能なチームの取得 (esa_get_teams) チーム統計情報(メンバー数
docker buildx bake で高速並列ビルド - 誰かの役に立てばいいブログ
Docker ビルド職人の朝は早いーー 毎日コンテナイメージを山ほどビルドしては捨てている皆様、おはようございます。 ビルドの速度はそのまま CI にかかる時間だったりするので、短縮には余念のないことと思います。 レイヤのキャッシュやマルチステージビルドといった基本テクニックについて、ご存じない方は以下の記事がお勧めです。 future-architect.github.io この記事では、良い Dockerfile をさらに活用できる、かもしれない docker buildx bake について紹介します。 bake の紹介の前に、私が抱えていた問題を説明します。 目下のプロジェクトでは Kubernetes 上で多数のマイクロサービスを動作させています。 マイクロサービス群はモノリポ（monorepo）上の共通のフレームワークやライブラリを用いて効率的に開発されています。 そのため、全
GitHub Self-hostedに移行しました。CIが最大55%速くなり、月額が300万円節約できた！
こんにちは、SODAのSREチームのDucと申します。 GitHub Actionsのコストを削減しながらCIワークフローを高速化したの工夫をご紹介します。 背景 私たちのチームは、snkrdunk.comサイトとSNKRDUNKモバイルアプリの可用性とパフォーマンスの維持に注力しています。 それに加えて、クラウドインフラストラクチャやその他の監視・開発ツールのコスト管理も担当しています。 毎月、AWSやGitHubなどのインフラストラクチャとツールの請求書をチェックしています。 GitHubの請求額が非常に高いことに気づきました。特にGitHub Actionsの部分です。 参考までに、GitHub Actionの使用量とサーバーの本番ワークロード費用の比較をご紹介します。 Fargate: Savings Plan適用で月額約$7,000。私たちのサービスは平均約5000リクエスト/秒
すべてのコーディングエージェントに独立した開発用コンテナ環境を与えられる「Container Use」、Docker創業者がオープンソースで公開
すべてのコーディングエージェントに独立した開発用コンテナ環境を与えられる「Container Use」、Docker創業者がオープンソースで公開 Docker創業者で現在はプラットフォームエンジニアリングのツールを開発するDagger社の創業者兼CTOのSolomon Hykes（ソロモン・ハイクス）氏は、すべてのコーディングエージェントに対してそれぞれ独立した開発用のコンテナ環境を与えられるオープンソースのツール「Container Use」を公開しました。 container-use has a logo. How do you like it? pic.twitter.com/IcKmbymGLW — Solomon Hykes (@solomonstre) June 7, 2025 AIエージェントがWebブラウザを操作できるようになる「Browser Use」や、AIエージェント
MCPサーバーを安全に動かすための工夫
現在普及しているStdioServerTransport型MCPサーバーの使用方法は設定ファイルにnpxやuvxコマンドを記述する。これはその場でダウンロードしたスクリプトファイルを実行することを意味する。 https://code.visualstudio.com/docs/copilot/chat/mcp-serversしかしこの実行方式は開発者には悪名高いソフトウェアのインストール手順「curlしてbash（URLでダウンロードしてきたシェルスクリプトをパイプしてノールック実行）」を思い出させる。「curlしてbash」なら単一の信頼した配布元を基準に判断できるがnpxやuvx方式は依存するライブラリも芋づる式に参照してくる。つまり任意のコードをどこかの経路（MCPサーバー本体でなくその内部の別の依存ライブラリかもしれない）を通じて実行される可能性は残る。 curl | bash
シェルでコンテナの実行や操作ができる「Dagger Shell」、Docker創始者らによるDagger社からオープンソースで登場
Dockerの創始者であるSolomon Hykes氏らが中心となって発足されたDagger社から、コンテナ時代の新しいシェルとうたわれた新ツール「Dagger Shell」が登場しました。 シェルを補完してコンテナを操作可能に Dagger Shellはシェルを置き換えるのではなく補完するものだと説明されています。 Dagger Shellを用いることで、シェルコマンドやシェルスクリプトの中でコンテナの操作が可能になります。 下記はデモ動画のキャプチャです。ここではシェルコマンドとして「container | from alpine | with-exec apk add git | terminal」と入力、実行されています。つまりAlpine Linuxのコンテナを起動してgitをインストールし、terminalを起動するというものです。 Dagger Shellコマンドはサンドボッ
Docker Model Runner登場、Dockerコンテナと同じように任意の大規模言語モデルをDocker Hubから選んで簡単に導入、実行可能に
Docker Desktop 4.40の新機能として、Dockerコンテナと同じように任意の大規模言語モデルをDocker Hubから取得し、ローカル環境にインストール、簡単に実行できる「Docker Model Runner」β版が登場しました。 Docker Model RunnerはNVIDIA GPUとApple SilliconによるGPUアクセラレーションに対応。インストールされた大規模言語モデルは、事実上の標準的なAPIとなっているOpenAI API経由でアクセスできます。 これにより、従来手間のかかるライブラリの導入や環境設定が求められていた大規模言語モデルの導入が手間なく簡単にできるようになり、入れ替えも容易で、すぐに生成AIを活用したアプリケーションの開発に取りかかれるようになります。 OCIアーティファクトで大規模言語モデルをパッケージング Docker Model
Go製アプリケーションのコンテナ化にはkoを推したい - YAMAGUCHI::weblog
はじめに こんにちは、Google Cloudでオブザーバビリティを担当しているものです。Cloud Operations suiteをよろしくおねがいします。（宣伝終わり） この記事はGo Advent Calendar 2021 その1の22日目の記事です。昨日は @sago35tk さんの「ESP32 向けに TinyGo をセットアップする」でした。TinyGoのコアな情報を日本語で教えてくれるtakasagoさんには本当にいつも感謝しています。 さて、今日はGo製のアプリケーションをdockerlessでコンテナ化できるkoの紹介をします。koは本当にイチオシのツールで、みんなに使ってもらいたいのでぜひ使ってください。 github.com DockerによるGo製アプリのコンテナ化 まず最もポピュラーと思われるDockerを用いた場合のGo製アプリケーションのコンテナ化の方法に
GitHub Actions 上での Go の Docker ビルドを高速化する
2025-01-08 追記 さらに高速化について検証されている記事が公開されていました！ 引用させていただきます。 どうも GitHub Actions 上で Docker ビルドを行うと時間がかかるなぁと感じていました。 かなり軽量の Go の Web アプリケーションを Docker イメージにしてプッシュするプロセスなのですが、全体で 3 分ほどかかっています。 今回はその速度改善を行ったので、得た知見を記事にしたいと思います。 最終的に、ケース次第では以下のような結果を出すことができました。 ※ケース = go のソースコードのほんの一部を変更してワークフローを実行する。 go.mod など依存関係に変化はない。 go build: 60秒 → 1秒 docker/build-push-action ステップ: 2分30秒 → 30秒 ワークフロー: 3分 → 1分 前提 go b
Docker Engine 18.09 から使える Build-time secrets を試してみた | はったりエンジニアの備忘録
Docker Engine 18.09 から Build-time secrets という機能が使えるようになりました。この機能を使えば docker build するときに secrets (API key, credentials, etc) を安全に取り扱えるようになります。 Introducing Docker Engine 18.09 - Docker Blog Integrate secrets in your Dockerfile and pass them along in a safe way. These secrets do not end up stored in the final image nor are they included in the build cache calculations to avoid anyone from using the c
2024年版のDockerfileの考え方＆書き方 | フューチャー技術ブログ
最近はお客さんとの勉強会でDockerのドキュメントをつまみ食いして読むというのをやっていますが、改めて最新版を読んでみて、いろいろ思考が整理されました。2020年の20.10のマルチステージビルドの導入で大きく変わったのですが、それ以前の資料もweb上には多数あり「マルチステージビルドがよくわからない」という人も見かけるので過去の情報のアンラーニングに使っていただけるように改めて整理していきます。 仕事でPythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編で触れた内容もありますが改めてそちらに含む内容も含めて書き直しています。 本エントリーの執筆には@tk0miya氏から多大なフィードバックをいただきました。ありがとうございます。 基本的なメンタルモデル現代的な使い方を見ていくために「Dockerを使ってビルドする」というのはどのようなものか考えを整
Docker Build Cloudを導入してコンテナイメージビルド時間を80%削減しました
背景弊社では効率的で迅速な開発プロセスを維持するためにコンテナ技術を使用しています。 これまでもコンテナイメージのビルド時間を短縮するための改善を行ってきましたが、今回のDocker Build Cloudの導入により、ビルド時間を大幅に短縮することができました。この改善によって、プルリクエストごとの検証環境を迅速に作成し、デプロイフローをより速くすることが可能となりました。 成果まず最初に成果を共有します。 今回、Docker Build Cloudを活用することで、コンテナイメージビルド時間を劇的に短縮することに成功しました。具体的には、従来約6分30秒かかっていたイメージのフルビルド時間が、約1分10秒まで短縮されました。この結果、ビルド時間を80%削減することができました。 コンテナイメージビルドにおける課題今まではコンテナイメージビルドの高速化のため Registry cache
速く、もっと速く！Docker Build Cloudでイメージビルド時間を短縮する - 世界中の羊をかき集めて
2024/1/23に Docker Build Cloudが発表されました www.docker.com 早速Docker Build Cloudを試してみました Docker Build Cloudとは サイト: https://www.docker.com/ja-jp/products/build-cloud/ ドキュメント: https://docs.docker.com/build/cloud/ イメージビルドをDocker社のCloud環境で行える機能です。 これによりどのようなメリットがあるかというと イメージビルドキャッシュの共有 ローカルでイメージビルドするとき、もし他のユーザがビルド済みであればそのキャッシュを使うことができビルド時間が短縮できる CI環境では毎回サーバーが違うため--mount=type=cacheが効かないがDocker Build Cloudであれば
ActionsでM1 Macが無料で使えるように。DockerやGoの話も｜Productivity Weekly(2024-01-31号)
こんにちは。サイボウズ株式会社 生産性向上チームの平木場です。 僕たち生産性向上チームは毎週水曜日に Productivity Weekly という「1 週間の間に発見された開発者の生産性向上に関するネタを共有する会」を社内で開催しています。 本記事はその時のネタをまとめたものです。 2023-01-25 号から、基本的に隔週で連載することとしました。たまに単独でも投稿するかもしれません。 今週は 2024-01-31 単独号です。 今回が第 141 回目です。過去の記事はこちら。 news 📺 GitHub Actions で M1 macOS ランナーが public リポジトリで無料に使えるようになりました GitHub Actions: Introducing the new M1 macOS runner available to open source! - The GitH
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Claude Code + Container Use と Cursor で作る ローカル並列開発環境のススメ / ccc local dev
Docker MCP Gatewayがすんばらしい👌 - Qiita
WarpBuild - 2x faster, 50% cheaper Github Actions runners
