Kubernetes 1.20からDockerが非推奨になる理由 - inductor's blog
追記: Kubernetes側での公式のアナウンスが2本出ているのでこちらも合わせてご覧ください。 kubernetes.io kubernetes.io Kubernetesコミュニティを眺めていたら、やたらめったら色んな人達が1.20 RCのリリースノート引っ張り出して「Dockerが非推奨になるからちゃんと対策を検討してね！！！」とアナウンスをしていて、挙げ句SIG Contributexではその対策に追われてバタバタしている自体を観測しました。 CNCF Ambassador Slackでもだいぶ燃え上がっていて、見かねて dev.to に記事を投稿したのでそれをかんたんに日本語にまとめてみようと思います。英語のほうはこちらをご覧ください。 dev.to 追記2. 影響範囲を知りたい場合はまずこちらをお読みください blog.inductor.me 追記2. 影響範囲を知りたい場合
コンテナのデザインパターンを学べる論文「Design patterns for container-based distributed systems」を読んだ - kakakakakku blog
2016年に USENIX Conference で発表された論文「Design patterns for container-based distributed systems」を読んだ．タイトルの通り，コンテナのデザインパターンがまとまっていて，これからコンテナ設計をする人も，既にコンテナを運用している人も，デザインパターンを学べるのは価値があると思う．一部ミスリードをしているかもしれない． Design patterns for container-based distributed systems 論文も公開されている． https://static.googleusercontent.com/media/research.google.com/ja//pubs/archive/45406.pdf パターン一覧 Single-container management pattern
2015年頃のWeb開発者がやりがちだった、DockerをVMと同じように使うのは便利だけど辞めたほうが良いという話 - inductor's blog
Dockerが普及し始めて、Docker Composeによって開発環境が簡単につくれるようになった2015年頃から、DockerはVagrantの置き換えツールとして使われることが増えてきました。 Vagrantを使うことでサーバープロビジョニングのときに発生する初期構築を全てスクリプト化し、プロジェクトメンバーの開発環境構築のコストを削減することができますし、設定がGitに残るのでメンテナンスも比較的容易です。そのため、自分の認識ではVagrantの一番の特徴はVMのパッケージングにあると思っています。 一方、Dockerはアプリケーションを動かす環境を配布するための仕組みとして普及しました。どちらもベースのイメージから必要な処理を流す点は同じですが、DockerとVagrantでは開発者が利用する上では体験の面で見ても以下のような違いがあると思います。 Vagrantは仮想マシンをV
Xilinx の開発ツールを Docker コンテナに閉じ込める | Tosainu Lab
あまり表には出していませんでしたが、少し前から FPGA を触っています。FPGA は以前から興味があったデバイスの1つだったこともあり、苦戦しながらも今まで触れたことのない概念の連続をなんだかんだで楽しんでいる気がします。欲を言えば、FPGA ともう少し普通の出会い方をし、普通の環境で勉強したかったなぁというのがありますが... その話は置いておき本題、FPGA の開発環境の話です。世の中で FPGA を使った開発が一般にどのように行われているかは詳しく知りませんが、その1つとして FPGA ベンダの提供する開発環境を利用するというのがあります。例えば最近の Xilinx なら [Vivado Design Suite](https://www.xilinx.com/products/design-tools/vivado.html) (Vivado) という感じです。さてこの Viva
WebAssemblyとRustが作るサーバーレスの未来
注目を集めるWebAssemblyとRustそしてサーバーレスに結びつく未来を、Cloudflareのエンジニアが解説する。 JavaScriptの登場によって、Webブラウザーはスタティック（静的）なWebページを表示するだけの存在から、より動的なアプリケーションを実行するプラットフォームに進化した。そしてそれをさらに進化させるために登場したのがWebAssemblyだ。WebAssemblyは2015年にMozilla Foundationによって発表され、その後2019年12月にW3Cのレコメンデーションとして採択されたブラウザーで実行されるコードのバイナリーフォーマットの標準だ。 HTML、CSS、そしてJavaScriptに続く進化のための要素の一つとして紹介されるWebAssemblyは、動的型付けのインタープリター言語であるJavaScriptと比較してコードのサイズが小さく
Jsonnetの薦め - Qiita
JsonnetというJSONテンプレート言語を紹介する。 後で見るように、これはJSONを生成するための汎用テンプレートというよりはむしろ、計算や依存関係を含む設定を静的に書き下すために便利なのではないかと考えられる。 実際Jsonnetの仕様はGoogleのBCLに似ている。BCLはGoogleでコンテナクラスタシステムBorgの設定を記述するために使われている言語だ。 JSONテンプレート言語 ある意味でJsonnetは毎度おなじみのやつだ。JavaScriptの文法の不便さに対してalt JSが多数出てきた。CSSにおけるネストの分かりづらさやの記述の重複に対してCSS preprocessorが多数出てきた。それと同じようにして、Webにおける機械可読データのLingua FrancaたるJSONを記述するのが不便なのでJSONテンプレートが出てきた。 Jsonnetはその中の1つ
「コンテナセキュリティ」とは――コンテナを活用する人が知っておくべき6つのポイント
運用管理が楽になり、クラウドとの親和性も高い――エンジニアならば避けては通れない「コンテナ」技術のメリットは、既に多くのエンジニアが肌で感じているものだろう。コンテナアプリケーションを動かすまでには、コンテナイメージを作成し、レジストリにアップロードし、そのイメージをデプロイ先にダウンロードし、コンテナを実行するというプロセスを踏む。コンテナアプリケーションの構成はDockerfileなどのテキストで表現できることもあり、構成管理は可読性も高い。 では、そこに“脅威”はないのだろうか？ コンテナ技術が普及期に入ったこともあり、昨今では“コンテナセキュリティ”に関しても注目が集まっている。しかしコンテナセキュリティが指すポイントについてはさまざまな意見があり、「いったいどこを守るべきなのか」「どこに脅威があるのか」がよく分からないというエンジニアも少なくないだろう。 そこで今回、トレンドマイ
Container Runtime Meetup #1 - 資料一覧 - connpass
終了 2019/09/24（火） 19:00〜 Container Runtime Meetup #1 OCIランタイムの筆頭「runc」のコードリーディング Kohei Tokunaga 他 東京都港区芝浦 3-4-1 (グランパークタワー34F)
コンテナランタイムの動向を整理してみた件 - Qiita
はじめに 先日以下のQiita記事を書いたのですが、公開した後にコンテナランタイムについて全然書いていないことに気付いたので、今度はコンテナランタイムの動向について整理してみたいと思います。 Docker・Kubernetes周辺の動向を整理してみた件 また、最近 containerd・cri-o・gVisor などの名前を聞くことが増えたのですが、それぞれの違いを自分が理解できていなかったので、自己学習の目的としてもWeb上の情報などを元に整理したいと思います。 コンテナ仕様の標準規格 コンテナランタイムを整理する前に、OCI（Open Container Initiative）とCRI（Container Runtime Interface）の概要について説明します。 OCI（Open Container Initiative）とは Open Container Initiative（
OCIランタイムの筆頭「runc」を俯瞰する
Container Runtime Meetup #1の発表資料です。 コンテナを使うひとならほぼ全員が使っている(であろう)コンテナランタイムの筆頭「runc」を俯瞰します。 - 前半では、コンテナの標準化団体OCIの定めるコンテナランタイムの標準仕様OCI Runtime Specificationとruncの概要、及びその関係について述べています。 - 後半では、runcがコンテナをシステム上に作り出す流れをコードレベルで俯瞰しています。runcの持つサブコマンドの中でも、特にコンテナ作成処理が網羅されているrunサブコマンドに注目し、その実装に迫ります。Read less
【図解】Dockerの全体像を理解する -前編- - Qiita
この記事は何か イメージやコンテナなどの基本からdocker-compose、docker-machine, docker swarmなどのDocker周りの様々な概念の全体像を整理して、Dockerの仕組みを理解するための記事 前編では「コンテナ、イメージ、DockerHubでのイメージ共有」について書いて行きます。 対象読者 ・Dockerって何？ ・Dockerちょっと勉強したけどDocker compose？ Docker machine？ Docker Swarm？ 色々ありすぎて意味不明 という方 Dockerとは何か Docker社が提供する「コンテナ型仮想化技術」 を実現するプロダクト 仮想化？ PCやサーバといったマシンにインストールされているOS(ホストOS)の上に、別のマシンを仮想的に立ち上げる事 簡単に言うと「パソコンの中に仮想パソコンを起動する」のが仮想化です。
コンテナ/Kubernetesの本を一冊読んでスッキリした話 - orangeitems’s diary
本を買いました 昨日のKubernetesエントリーが好評なので続きます。 早速本を買ってきました。一応記念写真を冒頭に置きました。 本全体の感想 頑張って半日で読みたい部分は読み終えました。この本は前半をしっかり読んで、後半はつまむ程度で十分です。後半については、GCPとIBM Cloudと、Redhat OpenShiftにおけるKubernetesの扱いの紹介でした。特にOpenShiftの量が多く今のところ私には不要なので見ていません。 AWSやAzureの記載がないというのも面白いところです。ただ基本的にはGCPの記載を見ておけばどのクラウドでも様子はわかるでしょう。 OpenShiftについてはちょっと毛色が違う話です。これはコンテナを使った企業の統合基盤を構築するミドルウェアです。オンプレにも構築でき、パブリッククラウドの仮想サーバー、VMwareの仮想基盤上にも構築できます
2018年なぜ私達はコンテナ/Dockerを使うのか - 続 カッコの付け方
2017年にもうコンテナの未来・一つのカタチはもう確定したと言え、今更感があるものの、改めてDockerとコンテナについて。 今更こんなことを書くのは、情報が溢れてくる今こそ、正しく理解し、正しい順序で学習することが重要だと切に思うから。 内容についてのお断り How Toはかきません あくまでも2018年時点の私見 目新しい情報はない、2016年頃に書けたレベル Dockerをこう使えとか、こうするのがいいとかの話ではなく、コンテナとDockerに関して大きな視点で現時点で私の考えを書きます。また、私自身はかなりのコンテナ推進派です。 Dockerをよくわかっている人には意味のない記事となります。 コンテナ(Docker)のメリット 何故コンテナがいいのか、コンテナをある程度の学習コストを払ってでもやる理由 コンテナとDocker コンテナ技術はDockerが生まれる前から存在する技術で
Visual StudioがKubernetes対応。DockerfileとHelmチャートを自動生成し、Kubernetes環境へデプロイ可能に
Visual StudioがKubernetes対応。DockerfileとHelmチャートを自動生成し、Kubernetes環境へデプロイ可能に マイクロソフトは、Visual Studioを用いてKubernetesに対するアプリケーション展開を容易にするツール群「Visual Studio Kubernetes Tools」のプレビュー版を公開しました。 Visual Studio Kubernetes Toolsを用いることでKubernetes環境へのデプロイに必要な設定ファイルを自動生成し、すぐにデプロイできるようになります。 DockerfileとHelmチャートを自動生成するVisual Studio Kubernetes Tools Visual Studio Kubernetes Toolsをインストールすると、Kubernetes対応のアプリケーションを開発するプロジ
Kubernetesのない世界 すべてがサーバーレスになる
Future will be Serverless!! - Serverless Meetup Fukuoka #1 Opening
『コンテナ疲れ』と戦う、k8s・PaaS・Serverlessの活用法
Kubernetes 疲れに Azure Container Apps はいかがでしょうか？（江東区合同ライトニングトーク 発表資料）
initのお仕事〜tiniのコードを読んでみた - ローファイ日記
急にinitが何をしているのか、何をすべきなのかが気になったので調べてみた。一緒に600行強のinit実装であるtiniのソースコードをざっくり読んだ。この場を借りてメモしていく。 the PID 1 problem RubyコミュニティなどではPassengerで有名なPhusion社のブログに、Docker and the PID 1 zombie reaping problemという記事が掲載されている。 blog.phusion.nl ゾンビプロセスをreapしてくれないと困る SIGTERMなどでPID=1が先に死んだらその子プロセスを処理してくれないと困る みたいな内容が書いてある。詳細は読んでみてほしい。 システムコンテナ（参考）と呼ばれる種類のコンテナを作る場合、任意のプログラムをコンテナ内部のPID=1とするのではなく、上記のような振る舞いをする軽量なinitプログラムを
Dockerfileを書く時の注意とかコツとかハックとか | Kim's Tech Blog
目次 なぜDockerfileを使うのか？ ADDとDockerfileにおいてのコンテキストを理解する CMDでコンテナをバイナリのように扱う CMDとENTRYPOINTの違い exec format error ビルド時のキャッシュについて: キャッシュが有効なときと無効なとき ある一行でキャッシュが使われなかったらそれ以降のすべての行でキャッシュは使われない 何もしないコマンドを追加してもキャッシュは無効になる コマンドと引数の間に意味のないスペースの入れてもキャッシュは無効となる Dockerfileの行に意味のないスペースを入れてもキャッシュは有効 冪等ではない命令でもキャッシュは効いてしまう ADD以降にある命令はキャッシュされない (ただし、0.7.3以前のバージョンを使っている場合のみ) コンテナをバックグラウンドで動かすハック なぜDockerfileを使うのか？ Do
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コンテナを雰囲気で動かさない話
https://github.com/takaishi/hello2018/blob/master/k8s_hands_on/README.md