Infra Study 2nd #2「クラウドネイティブを支えるインフラ技術」の講演資料です。 参考となる情報にはPDF中からリンクをしていますが、資料中のリンクは Speaker Deck 上ではクリックできないので PDF をダウンロードしてご覧ください。
![コンテナの歴史を追いながらいまいちどコンテナについておさらいしてみる / Infra Study 2nd #2](https://cdn-ak-scissors.b.st-hatena.com/image/square/2595fe5a51c241920ede3fc558c4e737934b548a/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F554303110e75422593701d78e62f99f4%2Fslide_0.jpg%3F18283968)
章立て はじめに Docker・Container型仮想化とは Docker一強時代終焉の兆し Container技術関連史 様々なContainer Runtime おわりに 1. はじめに Containerを使うならDocker、という常識が崩れつつある。軽量な仮想環境であるContainerは、開発からリリース後もすでに欠かせないツールであるため、エンジニアは避けて通れない。Container実行ツール(Container Runtime)として挙げられるのがほぼDocker一択であり、それで十分と思われていたのだが、Dockerの脆弱性や消費リソースなどの問題、Kubernetes(K8s)の登場による影響、containerdやcri-o等の他のContainer Runtimeの登場により状況が劇的に変化している。本記事では、これからContainerを利用したい人や再度情報
Red Hat で Java Platform Advocate として OpenJDK を担当している伊藤ちひろ(@chiroito)です。 この記事は、Red Hat Developerのブログ記事、My advice for updating use of the Docker Hub OpenJDK image | Red Hat Developer の翻訳記事です。 コンテナ内のJava実行環境は、今後数カ月でアップデートを受けられなくなる可能性があります。そろそろ手を打つべきでしょう。この記事では、この問題を引き起こした原因である決定事項を説明し、解決策を提案します。 OpenJDK と Java SE のアップデート OpenJDKは、Java Platform, Standard Edition (Java SE)のオープンソース実装で、複数の企業やコントリビューターが共同
こんにちは、CLI生活至上主義?の、 ひのしば です。 まぁ、至上主義というのは、ちょっと言い過ぎかもしれませんが、screen, vim, mutt, newsboat, pass, あとは、gitやssh 辺りを使う生活をしており、1日の作業がこれだけで完結するような事もあるような生活を送っています。 さて、そんな私が、ワークステーションサーバに、macOSや、Windows, Linuxから接続して操作するといった構成から、 作業環境をDockerfileにまとめ、手元で上がる環境をdockerコンテナへ統一し作業する構成とした話を紹介します。 この環境は、ここ数ヶ月、不自由なく使えている事もあり、自身の整理のためにも、どのような点が気になって対応したのかを挙げていきます。 詳細は下部に記載する通りですが、 例えば、dockerfile上のuidの問題に気をつける点、Linuxとma
2022年5月、IPv4アドレスが枯渇してきていることもあって、IPv6 onlyな環境がVPSの一般サービスとして出てきました。 OSレベルではIPv4/IPv6のデュアルスタックで両方のネットワーク環境にサーバもクライアントも対応しつつあるのですが、 世の中にはまだAAAAレコードを持たないHTTP/HTTPSサーバも結構あって、DockerをIPv6 only環境で動かすのに一苦労しました。 今回、私自身が Rocky Linux 8.5 の IPv6 only 環境で Docker / Alpine Linux を動かした記録をメモで残しておきます。 Dockerのインストール まず最初にdnfコマンドを使ってDockerをインストールします。 sudo dnf update -y sudo dnf install -y dnf-utils device-mapper-persis
コンテナユーザなら誰もが使っているランタイム「runc」を俯瞰する[Container Runtime Meetup #1発表レポート] こんにちは、NTTの徳永です。本稿では、コンテナユーザなら誰もが使っていると言っても過言ではない、コンテナランタイムの筆頭「runc」に注目し、その概要を仕様と実装の両面から俯瞰します。本稿は私が主催者の一人として参加した「Container Runtime Meetup #1」で発表した内容をベースにしています。詳しい内容は発表資料もぜひご参照ください。 コンテナランタイムとはKubernetes等のコンテナオーケストレータを用いてアプリケーションをコンテナ(Pod)として実行するとき、実際にコンテナの作成をしているのは誰でしょうか。実はKubernetesはコンテナを直接触らず、あるソフトウェアを用います。まさにそれがコンテナランタイム(以降、ランタ
Dockerで内部的に利用されているLinuxカーネルの機能について整理しています。 個人ブログの以下の2つのエントリーを1つにまとめたものになります。 Linuxカーネル Docker関連 namespaceのメモ Linuxカーネル Docker関連 cgroupsのメモ 勉強メモ程度の内容なので間違いを含む可能性が大いにあります、ご注意ください。 環境 CentOS 7.2 (kernel-3.10.0-327.4.5.el7.x86_64) Ubuntu 14.04 (3.13.0-77-generic) Docker 1.9.1 namespace (名前空間) Linuxにおける namespace(名前空間) はプロセスに対して以下の6種類のリソースを分離するための機能として提供されています。 名前空間 定数 概要
CVE-2019-5736を覚えていますか?今年の2月に見つかったrunc(Dockerがデフォルトで利用しているコンテナのランタイム)の脆弱性で、ホストのruncバイナリを好き勝手にコンテナ内部から書き換えることができるというものです。 脆弱性の仕組みに興味があったので調べたところ、コンテナを攻撃する方法というのは他にもいろいろあって、runcは頑張ってそれを塞いでいるようです。これまとめると面白いかも、と思ったので以下のようなおもちゃを作りました。 Drofuneは簡単なコンテナランタイムです。drofune runとかdrofune execなどでコンテナを起動したり、入ったりすることができます、といえば想像がつくでしょうか。 これだけでは何も面白くないので、Drofuneはわざと安全でない実装になっています。なので、今回発見されたCVE-2019-5736を利用した攻撃も成立します
前回の ブログ記事 では、Kubernetesの話と、 ThoughtSpot がKubernetesを開発インフラのニーズに合わせてどのように取り入れたかをご紹介しました。今回はその続報として、最近の興味深いデバッグ経験について少々駆け足になりますがお話ししていきます。本記事も「コンテナ化と仮想化はノットイコールである」という事実に基づいており、たとえcgroupの上限がどれも高くない値に設定されホストマシンで十分な演算能力が利用できるとしても、コンテナ化されたプロセス同士がリソースの競合を起こす場合があることを示したいと思います。 ThoughtSpotでは内部のKubernetesクラスタで 多数のCI/CDや開発関連のワークフロー を稼働させており、ある1点を除いては全てが順調でした。唯一問題だったのは、ドッカー化された製品コピーを起動すると、パフォーマンスが期待を極端に下回るレベ
表題のような問題があり,その調査したという記録です.なお,結論を一言で言うと--initを使え,ということになります. そもそもDockerコンテナを起動すると,CMDあるいはENTRYPOINTに指定されたコマンドがコンテナ内でPID 1として起動します.これが何を意味するかと言うと,「CMDあるいはENTRYPOINTに指定されたコマンド」はそのコマンド自体の責務をまっとうするのと同時に,initプロセスとしての振る舞いも行わなければならないということになります (id:hayajo_77さんにこの辺を詳しく教えてもらいました,ありがとうございます). つまりPID 1で動いているプロセスは「SIGCHLDをトラップすることで孤児プロセスを適切に回収し,waitpidをかける」という処理も適切に行う必要があります. さて,puppeteerを使ってChromeブラウザを起動するとどうな
YAPC::ASIA Hachioji 2016 mid in Shinagawa
ご存知 PT3 による地デジ・BSの録画環境を私も重宝しているのですが、いかんせん環境設定が面倒で、OS の入れ替えを躊躇しがちに。その一因として、関連ツール類がパッケージ化されておらず、ソースを一つ一つ取得してきてインストールせざるを得ないことが挙げられると思います。 それって Docker イメージに押し込んじゃえばいいんじゃね? というわけで始めてみました。なお、録画サーバである EPGREC(トップページ - 録画予約システムepgrec)とそのバックで動く MySQL の設定については、Docker の設定としては極々オーソドックスですので、ここでは触れません(気が向いたら追記するかも)。 なお、下記の手順で、ホストでの PT3 録画環境 → Docker の PT3 録画環境への移行期間中は、ホスト側と Docker 側とで、一枚の B-CAS カードを共用して、同時に録画がで
2015/08/06 この記事は書かれてから1年以上が経過しており、最新の情報とは異なる可能性があります techDockerVagrant そもそも比較するようなものではないものの、分かりづらい解説しかなかったので、 超個人的な主観でまとめておこうと思いました。 Docker の特徴Linux 上でのみ動く (Windows, Mac 上では動かない)Linux のリソースを流用しつつも小さく閉じた環境を作ることができる小さいので作っては捨て、が容易例えるなら・・・ 病院の中に�超小型隔離施設を作るようなもの隔離されてるものの、診察も受けられるし隔離施設ごとトイレにも行けるDocker コンテナをたくさん作る ≒ 病院内に超小型隔離患者がたくさん、みたいなイメージVagrant の特徴Windows / Mac / Linux それぞれにパッケージが用意されている実際は VirtualB
いよいよ、Dockerの導入前のOSレベルでの設計、さらに具体的な導入に入ります。DockerをLinux OSにインストールする手順自体は非常に簡単ですが、導入前の基本設計を怠ってはいけません。Dockerを導入するにあたって、採用すべきOSのファイルシステムや、パーティションに関する基本的な知識を習得しておく必要があります。ここでは、Dockerをインストールする前段階での、ハードウェアに関する様々な留意点を概要レベルで紹介します。また、Dockerをインストールする前段階で知っておくべき各種パラメータと初期設定、Dockerのインストール手順を紹介します。 物理サーバーのCPUに関する留意点 2015年8月下旬現在、最新のDockerでは、64ビットのx86アーキテクチャのサーバーシステムやPCで稼働させることができます。CPUの動作周波数などに特に制限事項はありませんが、まずは、D
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く