コンテナランタイム「containerd 2.0」がまもなく登場。何が変わるのか？
コンテナランタイムの代表的な実装の1つである「containerd」の初のメジャーバージョンアップとなる「containerd 2.0」の開発が進んでいます。 今年（2024年）3月に最初のリリース候補版「v2.0.0-rc.0」が登場し、6月には「v2.0.0-rc.3」まで進捗しているため、数カ月以内には正式版が登場すると思われます。 containerdのこれまで もともとcontainerdはDockerコンテナの一部として実装され、2016年に独立したオープンソースプロジェクトとなりました。現在でもDockerのコンテナランタイムとして採用されています。 参考：Dockerエンジンのコアランタイムが「containerd」として分離、独立したオープンソースプロジェクトに。Docker、AWS、Google、IBM、マイクロソフトらが協力して開発推進へ 2017年3月にCloud
コンテナイメージなのにブート可能な新技術による「Image mode for Red Hat Enterprise Linux」、Red Hatが発表。レジストリなどのコンテナ関連ツールがそのまま利用可能
コンテナイメージなのにブート可能な新技術による「Image mode for Red Hat Enterprise Linux」、Red Hatが発表。レジストリなどのコンテナ関連ツールがそのまま利用可能 Dockerコンテナで使われるコンテナイメージは、そもそもOSのカーネルなどが含まれていないためそれ単体で実行することはできず、コンテナに対応したOSの上にデプロイすることで実行されます。 このコンテナイメージのフォーマットは業界標準の「OCIコンテナ」（Open Container Initiativeコンテナ）として標準化されていますが、このOCIコンテナのフォーマットを守りつつ、ベアメタルサーバ上でブート可能な「ブータブルコンテナイメージ」の開発が進められています。 ブータブルコンテナイメージとは？ ブータブルコンテナイメージは、カーネルやデーモンなどの単独で実行可能なOSとしての
雰囲気でDocker Composeを触っている状態から脱するために調べたこと（2023） - Activ8 Tech Blog
エンジニアの岡村です。 自分はサーバーがメインではなく、あまり業務でガッツリ触るわけでもないのですが、最近それなりに活用するようになってきました。しかし、ネット上の日本語情報を読んでいるだけではこれの書き方が正しいのかよく分からない、と悩むことが結構あったため、色々情報を漁ってみました。 この記事は、特に自分が気になった部分の調べた結果を記事に纏めてみたものです。対象読者はdocker-composeを雰囲気でupやdownは叩けるけどComposeファイルの書き方がよく分からんとなってる人です。 Docker Composeの概要とcompose.yaml、Compose Specの関係 compose.yamlの書き方は Compose Specに準拠すればOK Compose Specの場所 推奨のファイル名はcompose.yaml compose.yaml内にバージョンを記述する
DHH氏によるコンテナデプロイ自動化ツール「Kamal 1.0」正式リリース。ベアメタルや仮想マシンに自動デプロイ、ゼロダウンタイムのアプリ更新も可能
DHH氏によるコンテナデプロイ自動化ツール「Kamal 1.0」正式リリース。ベアメタルや仮想マシンに自動デプロイ、ゼロダウンタイムのアプリ更新も可能 Ruby on Railsの作者として知られるDavid Heinemeier Hasson（DHH）氏は、Dockerコンテナに対応したアプリケーションのデプロイ自動化ツール「Kamal 1.0」をリリースしました。 Kamalはアプリケーション（群）の構成とデプロイ先のサーバ（群）のIPアドレスなどの基本的な情報を設定すると、あとは仮想マシンやベアメタルサーバ、クラウドのサーバインスタンスなどにDocker環境の構築からアプリのデプロイ、トラフィックの切り替えまでを自動的に行ってくれる、デプロイ自動化ツールです。 Kamal 1.0 has shipped. Deploy your web apps anywhere from bare
WebAssemblyに注目 | POSTD
WebAssemblyは今、転換点にあります。今後数年間で、コンテナ化からプラグインシステムやサーバレス・コンピューティング・プラットフォームに至るまで、IT業界全体でWebAssemblyの導入が増えると筆者は予想しています。この記事では、WebAssemblyとは何か、なぜそれが重要なテクノロジーであるのか、現在はどのような分野で利用されているかを説明します。また、WebAssemblyが大きな影響をもたらす可能性がある用途や、WebAssemblyの将来に関する予測も紹介します。 WebAssemblyとは何か WebAssembly（Wasm）とは、さまざまなプログラミング言語と多様な実行環境の間に位置する中間層です。30以上の異なるプログラミング言語で書かれたコードを.wasmファイルにコンパイルし、そのファイルをブラウザ、サーバ、あるいは自動車でも実行できます。 「WebAss
GUIでDockerコンテナのビルドやPodsのKubernetesへの展開を可能にする「Podman Desktop」が登場。新たなDocker Desktop対抗となるか
GUIでDockerコンテナやKubernetesの操作を可能にするオープンソースの「Podman Desktop」がリリースされたことをRed Hatが発表しました。Windows、Mac、Linuxに対応します。 Install, configure, and keep your container engine up to date with a GUI, which allows users to interact with containers and pods running in #Podman. Try Podman Desktop. https://t.co/5hPV8xOHYF — Red Hat Developer (@rhdevelopers) November 6, 2022 Podman DesktopはRed Hatが開発したDocker互換のツール「Podm
AWS、コンテナ特化で瞬時に起動する軽量VM「Firecracker」オープンソースとしてバージョン1.0に到達。AWS LambdaやAWS Fargateで利用
Amazon Web Services（AWS）がオープンソースとして開発し、コンテナの実行に特化した軽量な仮想マシン「Firecracker」がバージョン1.0に到達しました。 Firecrackerは2018年11月に行われたAWSのイベント「AWS re:Invent 2018」でオープンソース化が発表されました。コンテナのために作られた仮想化技術で、同社が「マイクロVM」と呼ぶセキュリティにフォーカスして設計されたスリムな仮想マシンです。 AWS Lambdaのような高速なサーバレス環境を実現するために同社が開発しており、実際にAWS LambdaやAWS Fargateで利用されていると説明されています。 基本的な特徴として、小さなメモリフットプリントとオーバーヘッドに加えて、外部から攻撃可能な部分を最小限にするなどのセキュリティ対策を実装しています。 速度にもフォーカスしており
AWS、コンテナ特化で瞬時に起動するオープンソースの軽量VM「Firecracker」がバージョン1.0に到達
この記事は新野淳一氏のブログ「Publickey」に掲載された「AWS、コンテナ特化で瞬時に起動する軽量VM「Firecracker」オープンソースとしてバージョン1.0に到達。AWS LambdaやAWS Fargateで利用」（2022年2月2日掲載）を、ITmedia NEWS編集部で一部編集し、転載したものです。 Firecrackerは2018年11月に行われたAWSのイベント「AWS re:Invent 2018」でオープンソース化が発表されました。コンテナのために作られた仮想化技術で、同社が「マイクロVM」と呼ぶセキュリティにフォーカスして設計されたスリムな仮想マシンです。 「AWS Lambda」のような高速なサーバレス環境を実現するために同社が開発しており、実際にAWS Lambdaや「AWS Fargate」で利用されていると説明されています。 基本的な特徴として、小さ
Rust初心者がRustで全文検索サーバを作ってみた - Qiita
情報検索・検索エンジン Advent Calendar 2019 の5日目の記事です。このAdvent Calendarを作った@takuya_aさんより、お誘いいただきました。 @minoru_osuka もし余裕あれば12/5の記事お願いします！ https://t.co/YIA9tIB4Gj — takuya-a (@takuya_b) December 1, 2019 ということで、仕事とは別で個人的に始めたプロジェクトについて紹介できたらと思います。 私自身はApache Solrを好んで利用しています。 ただ、最近のサーバサイドの技術の移り変わりや、新しい開発言語の登場など、取り巻く環境が変化してきています。それらの習得も踏まえ、使ったことのない開発言語を用いて軽量な全文検索サーバを作り始めるという内容です。 開発した経緯 インフラの変化 ここ数年でインフラは大きく変化しました
Google Cloud、コンテナネイティブなロードバランス機能を正式版に。Kuberntesとの統合など強化
Google Cloud、コンテナネイティブなロードバランス機能を正式版に。Kuberntesとの統合など強化 Google Cloudは、Google Kubernetes Engine（GKE）でコンテナネイティブなロードバランス機能を正式版としたことを発表しました。 従来、コンテナに対するロードバランス機能は、コンテナが属するインスタンスのiptablesを経由してコンテナに到達していました（下図上）。 コンテナネイティブなロードバランス機能では、KubernetesのIngressコントローラに新しくNetwork Endpoint Groups（NEG）と呼ばれるレイヤが組み込まれ、これがコンテナを直接認識することで、コンテナに到達するまでのホップ数を減らし、効率的なトラフィック分散を実現しています（下図下） また、従来のロードバランサーはコンテナを認識しないため、コンテナに対し
Google、Dockerコンテナをサーバレス化する「Cloud Run」をAnthosに搭載。オンプレミスを含むハイブリッドクラウド環境で実行可能に
Google、Dockerコンテナをサーバレス化する「Cloud Run」をAnthosに搭載。オンプレミスを含むハイブリッドクラウド環境で実行可能に Googleは、ハイブリッドクラウド環境を実現するAnthosの新機能として、Dockerコンテナをサーバレスで実行できる「Cloud Run for Anthos」や、サービスメッシュを実現する「Anthos Service Mesh」などを発表しました。 Cloud Runをパブリッククラウドだけでなくオンプレミスでも Anthosとは、Kubernetesをクラウド基盤の抽象化レイヤとして用いることで、コンテナ化したアプリケーションをオンプレミスとクラウドのどちらでも実行可能にする、ハイブリッドクラウドおよびマルチクラウドのためのプラットフォームです。 Google CloudやGoogleが認証したオンプレミス用のサーバ構成だけでな
Firecracker – サーバーレスコンピューティングのための軽量な仮想化機能 | Amazon Web Services
Amazon Web Services ブログ Firecracker – サーバーレスコンピューティングのための軽量な仮想化機能 私の好きなAmazonリーダーシッププリンシプルの1つはCustomer Obsessionです。 私たちがAWS Lambdaをローンチしたとき、私たちは開発者にセキュアなサーバーレス体験を提供し、インフラストラクチャの管理を避けることに重点を置いていました。 目的のレベルの分離を達成するために、我々は各顧客に専用のEC2インスタンスを使用しました。 このアプローチにより、私たちはセキュリティ目標を達成することができましたが、私たちがLambdaを裏で管理する方法に関していくつかのトレードオフを余儀なくされました。 また、新しいAWSサービスの場合と同様に、顧客がLambdaをどのように使用するのか、あるいはサーバーレスモデル全体をどのように考えているのかも
Kubernetes のない世界
Kubernetes のない世界 セクションナイン吉田さんからお声がけいただき、2人で Japan Container Days v18.04 にて『Kubernetesのない世界 -すべてがサーバーレスになる-』というタイトルで発表してきました. 我ながら賛否両論な良タイトルを生み出したと満足しています. 当日の発表が漫談になってしまったのは楽しかったので良いとして、吉田さんと僕ではこのテーマにおける考え方が異なります. そこであらためて僕の考えを脳内整理も兼ねて書いたのがこの記事です. 基本的には僕の妄想ポエムなので、そういうのが苦手な方はそっとタブを閉じると良さそうです. スライド 結論 すべてが「サーバーレス」になる日はいつか来る そのためには FaaS と Docker に代表されるコンテナ技術の間にもう一つ何かが必要 なぜそう思うのか、以下ポエムです. コンピューティングリソー
Netflix、自社開発したコンテナマネジメントプラットフォーム「Titus」、オープンソースで公開
動画配信サービスを提供するNetflixは、Amazon Web Services上に巨大な動画配信用のシステムを構築していることはよく知られています。同社は先月、2018年4月の実績によると、そのシステム内で1週間あたり約300万ものコンテナを起動したそうです。 その膨大なコンテナのマネジメントプラットフォームとして同社が自社開発した「Titus」が、オープンソースとして公開されました。 Titus, the Netflix container management platform, is now open source 同社はこのTitusのうえで機械学習やビッグデータの分析、エンコーディング、社内エンジニア向けのツールなど、同社のビジネスを支える重要なシステムを稼働させています。 コンテナマネジメントプラットフォームには、すでにKubernetesやMesosphere DC/OS
Kubernetesで実際のメモリを超えるコンテナアプリを動かすと、どうなるか？ - あさのひとりごと
Kubernetesは、コンテナアプリケーションをデプロイするためのオーケストレーションツールです。Kuberenetesは分散環境におけるスケーラブルなコンテナ実行環境をつくるための、さまざまな機能が提供されています。 もともとはGoogleが開発したBorgをもとにOSS化したものですが、今日ではマイクロソフトや（ry Kubernetesをつかうとステートレスでマイクロサービス的なアプリケーションを1日に何度もデプロイでき、スパイクアクセスがきても水平スケールが容易なので、大規模Webシステムでスケーラブルな基盤を作れる、というのは広く知られています。 一方、Kubernetesには「Resource Requests」という機能があり、これはPodをデプロイする時に必要とするリソース(CPU/メモリ)を指定できるものです。これにより、Kubernetesクラスタのリソースの使用率を
Open Container Initiative（OCI）がDockerイメージの配布プロトコル標準化に着手。事実上の標準であるDocker Registry HTTP API V2をベースに
Open Container Initiative（OCI）がDockerイメージの配布プロトコル標準化に着手。事実上の標準であるDocker Registry HTTP API V2をベースに Dockerコンテナの標準仕様を策定するOpen Container Initiativeは、事実上の標準であるDocker Registry HTTP API V2をベースに、コンテナイメージの配布プロトコルの標準化に着手すると発表した。 コンテナ型仮想化を実現するDockerは、登場当初こそDocker社によって開発された独自実装でしたが、2015年にDocker社やマイクロソフト、Google、Red Hat、VMware、IBM、Amazon Web Servicesなど主要各社がコンテナの標準化団体「Open Container Initiative」（OCI）が発足。仕様の標準化作業が
Dockerコンテナ時代の第一章の終わり、そして第二章の展望など － Publickey
コンテナ型仮想化の技術や実装はDockerが登場する以前から存在していたとはいえ、IT業界で本格的にコンテナの活用が始まったと言えるのは、やはり2013年3月に当時のdotCloudからDockerが登場したことがきっかけでしょう。 そうして始まったコンテナ時代の第一章は今年2017年、コンテナの標準仕様がOpen Container Initiativeによって策定完了し、コンテナオーケストレーションの事実上の標準がKubernetesに決まったことで基盤技術の基本要素がおおむね固まり、一つの区切りがついたように見えます。 そして今後は、この基盤技術を用いたコンテナによる分散アプリケーションのための様々なサービスや開発、テスト、デプロイ、本番環境に対応したツールやサービス実行環境などのソリューションが登場し、競う段階へ入っていくのではないでしょうか。 この記事では、Docker登場から現
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
長年運用されてきたモノリシックアプリケーションをコンテナ化しようとするとどんな問題に遭遇するか？ / SRE NEXT 2022
歴史から紐解くLinuxカーネルのコンテナ機能 / CNDT2019
TechCrunch | Startup and Technology News
