Docker一強の終焉にあたり、押さえるべきContainer事情
章立て はじめに Docker・Container型仮想化とは Docker一強時代終焉の兆し Container技術関連史 様々なContainer Runtime おわりに 1. はじめに Containerを使うならDocker、という常識が崩れつつある。軽量な仮想環境であるContainerは、開発からリリース後もすでに欠かせないツールであるため、エンジニアは避けて通れない。Container実行ツール（Container Runtime）として挙げられるのがほぼDocker一択であり、それで十分と思われていたのだが、Dockerの脆弱性や消費リソースなどの問題、Kubernetes（K8s）の登場による影響、containerdやcri-o等の他のContainer Runtimeの登場により状況が劇的に変化している。本記事では、これからContainerを利用したい人や再度情報
作業環境をDockerfileにまとめて、macOSでもLinuxでもWSL2でも快適に過ごせるようになった話
こんにちは、CLI生活至上主義？の、 ひのしば です。 まぁ、至上主義というのは、ちょっと言い過ぎかもしれませんが、screen, vim, mutt, newsboat, pass, あとは、gitやssh 辺りを使う生活をしており、1日の作業がこれだけで完結するような事もあるような生活を送っています。 さて、そんな私が、ワークステーションサーバに、macOSや、Windows, Linuxから接続して操作するといった構成から、 作業環境をDockerfileにまとめ、手元で上がる環境をdockerコンテナへ統一し作業する構成とした話を紹介します。 この環境は、ここ数ヶ月、不自由なく使えている事もあり、自身の整理のためにも、どのような点が気になって対応したのかを挙げていきます。 詳細は下部に記載する通りですが、 例えば、dockerfile上のuidの問題に気をつける点、Linuxとma
Dockerは非推奨じゃないし今すぐ騒ぐのをやめろ - Cloud Penguins
今話題のこれ。 kubernetes.io これに関しての日本語情報として、 @inductor が相当詳細に記事を書いてくれている。 blog.inductor.me blog.inductor.me にも関わらず、未だに完全に間違った解釈をしている人が多く観測される。記事をちゃんと読めば理解できるはずなのだけど、たぶんタイトルしか読んでいない。 タイトルしか読まないのであれば、あえて強めのタイトルにしておけば目にはつくかなと思い、改めて書いてみることとした。 Dockerは非推奨じゃないし、これからもバンバン使え まず @inductorが解説しているとおり、k8sを使っていない人には全く関係のない話なので、今まで通りDockerを使って良い。 が、もう一つ誤解を解いておきたいのが 自分の環境でDockerを使ってイメージ作成し、Kubernetesにデプロイしている人にも、今回の件は
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. 影響範囲を知りたい場合
WSL2 Docker が PC のディスクを圧迫する - Qiita
概要 WSL2 バックエンドの Docker では、コンテナやボリューム、イメージを削除しても、ホスト (Windows) のディスク容量が解放されない。 原因 WSL2 は一度確保したディスクをホストに返さないらしい。Issue が上がっている: WSL 2 should automatically release disk space back to the host OS · Issue #4699 · microsoft/WSL 確認 雑に確認してみる。 Docker のディスクファイル (%LocalAppData%\Docker\wsl\data\ext4.vhdx) のサイズを確認する。 WSL2 バックエンドを作成したばかりのまっさらな状態: > docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE > dir Direc
Dockerのログ収集方法の調査 - Qiita
すべてのログは標準出力・標準エラー出力に出力 ・Dockerのlogging driver ・ログの集約がしづらい ・Fluentdに転送設定 コンテナ起動時に既にFluentdが死んでいる場合、コンテナが起動できない など。詳細は以下のサイトを参照 Dockerコンテナ上のログ集約に関するまとめ Dockerのlogging driver: それぞれの特徴と使いどころ(json-file, syslog, journald, fluentd) 対象のログ リアルタイムに出力されるログが対象 ・Fluentd / fluentd-ui ・FluentBit ・Filebeat ・Logstash 既にあるログが対象 ・Embulk Fluentdのバッチ版Embulk(エンバルク)のまとめ Docker-composeを使ってEmbulk,Elasticsearch,Kibana環境を構築
DockerHubで公開されているコンテナが安全か確かめてみた結果【人気のコンテナ上位800個】 - Qiita
はじめに Docker Hubに公開されているイメージはどの程度安全なのか、 Dockle と Trivy を利用して検証しました。 検証結果は、 https://containers.goodwith.tech/ に公開しています。 結論 基本的にどのコンテナにも脆弱性はある！ 人気が高いコンテナ/最近ビルドされているコンテナでも関係ない！ ただ、Docker公式が用意しているコンテナは今のところ大丈夫。 より詳しいことを知りたい人は 操作方法 を見て、 https://containers.goodwith.tech/ を操作してみてください。 操作方法 ① ソートやフィルタが簡単にできます ※ Scoreは脆弱性のCVSSスコアなどを元にした参考値です。指標を一つに統一したかったので作りました。 ガチ勢の方々、怒らないでください & よりよい指標をつくるためのアドバイスをください。
コンテナはなぜ安全（または安全でない）なのか - sometimes I laugh
CVE-2019-5736を覚えていますか？今年の2月に見つかったrunc（Dockerがデフォルトで利用しているコンテナのランタイム）の脆弱性で、ホストのruncバイナリを好き勝手にコンテナ内部から書き換えることができるというものです。 脆弱性の仕組みに興味があったので調べたところ、コンテナを攻撃する方法というのは他にもいろいろあって、runcは頑張ってそれを塞いでいるようです。これまとめると面白いかも、と思ったので以下のようなおもちゃを作りました。 Drofuneは簡単なコンテナランタイムです。drofune runとかdrofune execなどでコンテナを起動したり、入ったりすることができます、といえば想像がつくでしょうか。 これだけでは何も面白くないので、Drofuneはわざと安全でない実装になっています。なので、今回発見されたCVE-2019-5736を利用した攻撃も成立します
「それコンテナにする意味あんの？」迷える子羊に捧げるコンテナ環境徹底比較 #cmdevio2019 | DevelopersIO
みなさんコンテナを使うことの意味を自信もって答えられるでしょうか？ ここ1年ほどコンテナ関連の仕事をメインでやっているハマコーですが、いろんなお客様からこういったお声をいただくことが多くありました。 「それはコンテナ化する意味があるの？」 「こんなコンテナ運用は危ない？」 「ECSの設定とか実際めんどい。docker runじゃだめ？」 「EKSって使えんの？」 そういう声を聴く中で、自分なりの答えを模索していたわけですが、岡山での弊社イベントAWS最新技術の祭典Developers.IO 2019 at 岡山城へ登壇するにあたり、そのあたりのもやもやを自分なりに昇華したのが、本日の内容です。 「このアプリをコンテナ化する意味があるのか、わからない」 「コンテナ化することで余計めんどくさくなった」 「AWSのコンテナサービスの何を使ったら良いのかわからない」 という悩みを抱えている方には、
毎秒1万リクエストの負荷試験をした話 - pixiv inside
はじめまして。ピクシブで広告関連のプロダクトを開発しているeastです。今回は、社内で運用している広告配信サーバーの負荷テストを実施したので、その話をしたいと思います。 経緯 ピクシブの広告配信サーバーは、pixiv本体を中心に複数のサービスに対して広告配信を行なっています。現在私はこの広告配信サーバーの大規模改修を行なっているのですが、先日ついに広告配信サーバーの改修がほぼ完了したので、試しに負荷試験を行なってみたいと思い立ちました。 目標は毎秒1万リクエスト ピクシブの広告配信サーバーへのリクエスト数はDailyで 4〜6億req もあり、これは毎秒平均に直すと約 5,000RPS(Request Per Second) になります。さらに、ピークタイムである休日の深夜帯には 12,000RPS にも達します。つまり新しい広告配信サーバーにも、毎秒12,000のリクエストを捌く性能が必
Registry v2 と Let's Encryptを使ってDocker Private Repositoryを構築 - Qiita
Registry (https://github.com/docker/distribution) を利用すると誰でも気軽にDocker Private Repositoryを立てられるが, DockerはHTTPによる通信を非セキュアとして通常は許可しておらず, HTTPSによる通信を行なうためには証明書を取得する必要があり, そのためのコストが高かった. ここで面倒臭くなって大分長いことPrivate Repositoryを立てたいと思いつつ, 実行に移せていなかったのだが, そういえば Let's Encrypt が 2016年4月に正式公開されたはずなので, これを利用すればオレオレ証明書をでっちあげたりしなくても, 簡単に認証付きRegistryを立てられることに気付いた. この記事ではLet's Encrypt を利用して, 証明書を発行し, 認証付きのRegistryを立てる
ECS運用のノウハウ - Qiita
関連記事 マイクロサービスを支えるインフラアーキテクチャ (AWS Dev Day 2019登壇資料) ECSデプロイツールを公開しました ECSにおけるログの取り扱いを別ページに移動させました 設計 基本方針 基盤を設計する上で次のキーワードを意識した。 Immutable infrastructure 一度構築したサーバは設定の変更を行わない Infrastructure as Code インフラの構成をコードで管理 (Terraformを採用) Serverless architecture 無駄にサーバを増やさない アプリケーションレイヤに関して言えば、Twelve Factor Appが参考になる。コンテナ技術とも親和性が高い。 ECSとBeanstalk Multi-container Dockerの違い 以前に記事を書いたので、詳しくは下記参照。 Dockerコンテナデプロイ
コンテナのデザインパターンを学べる論文「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
kubernetesをローカルの開発に活用する - Please Drive Faster
できる限りプロダクションのクラスタ設定をそのままローカルの開発にも使いたいなー、と思って色々と試行錯誤して、ようやく形になってきたので書いておく。 なぜローカルでkubernetesを動かしたいのか 最近ではInfrastructure as Code、Immutable Infrastructureの考え方と共に、コンテナの上でアプリケーションの環境の構築、運用、開発をすることが増えてきた。 少し前までは、Dockerでローカルの開発環境の構築は楽になったけど、本番にデプロイするのにはハードルがある印象が個人的にはあった。だけど、kubernetesの登場によってそのハードルは大きく下がった。 最近はマイクロサービスアーキテクチャへの注目と共に、様々なコンテナが協調してサービスを形作る構成が増えてきたように思う。kubernetesはこの全てのコンテナを管理する。 kubernetesは
"dockerやめてどうしたか？"を読んで - Qiita
ずいぶん前の記事だが これ dockerやめてどうしたか？ とか これ Docker ではないコンテナ systemd-nspawn を使ってみた / マスタカの ChangeLog メモ を最近読んで僕も知識不足で自分にイラッときたのでちょっと考えてみた。 なお仕事でコンテナを使った経験はない。 あとsystemd-nspawnとかLXDは適宜各「システムコンテナ技術」に置き換えても同じ。 TL;DR 自分は以下で判断することにした。 1. とりあえずDockerイメージがないか探して自分が起こそうとしている環境が簡単に実装できるか見極める 2. オーケストレーションする以上に手を加える必要があるならsystemd-nspawnやLXDなどを使う Dockerfileをいじって思ったのは、 DockerHubなんかにあるDockerfileから実行プロセスを追加・変更するべきではないとい
Dockerとchrootを組み合わせたシンプルなコンテナデプロイツール - ゆううきブログ
この記事ははてなエンジニアアドベントカレンダー2015の1日目です。今回は、既存の運用フローに乗せやすいDockerイメージへのchrootによるデプロイの考え方と自作のコンセプトツール droot を紹介します。 github.com 背景 Docker 本番導入の課題 Docker 導入の目的 Docker + chroot のアイデア droot: Dockerイメージにchrootするコンテナツール droot の使い方 droot push: Dockerイメージをtar ball化しS3にpushする droot pull: S3にpushしたイメージをダウンロードし展開する droot run: 展開先のディレクトリにchrootする droot の実装 droot push/pull の実装 droot run の実装 あわせて読みたい あとがき 背景 Dockerがリリー
Dockerじゃないsystemd-nspawn＋machinectlが非常に良い
前回、 自作FRPライブラリTimeEngineをブラッシュアップして http://timeengine.github.io/ を公開しました。 次回は、その日本語訳、 Reactの応用技術、あるいはReact再入門についての記事をUPしますのでお楽しみに！ と書いていたのですが、Dockerじゃないsystemd-nspawn＋machinectlが非常に良い、ので予定を変更して、こちらを先にエントリします。いろいろ印象を忘れないうちに。TimeEngineに関してはとりあえず自分がすでに英文で書いたものを和訳してどこかにUPしておいたほうが、何か別展開や国内のためになるかな程度のことなのでお急ぎの方は上記リンクから英文読んでください。そちらも全部仕上がっているとは言えないですし、行き届いていないところをセルフチェックするために和訳もしておこうという感じです。 実用的で枯れた技術「コン
ただ動くだけのdockerコンテナを作る - None is None is None
DBもapacheも何も要らない、空っぽのdockerコンテナが欲しい。 ただし、1度起動したら、docker stopするまで起動しっぱなしでいて欲しい。 回答 pseudo-tty付きのBashを走らせれば良いようです。 docker run -itd base bash -c "bash --rcfile <(echo \"trap 'exit 0' TERM\")" sleep infinityやtail -f /dev/nullも考えたのですが、これらはTERMシグナルに反応しないらしく、 docker stopするのに時間がかかってしまう（強制終了されてしまう）ようです。 こんなもの何に使うのか？ docker run --netにcontainerという、コンテナ間でネットワークを共有するオプションがあります。 --net="container:<name|id>": Set
[翻訳] Dockerについてよくある勘違い｜TechRacho by BPS株式会社
こんにちは、hachi8833です。今回は弊社システム管理者のyamasitaさん監修のもとで、Matt Jaynes氏のDocker Misconceptionsを翻訳いたしました。それなりに文言を最適化してあり、原文と一対一対応しているとは限りませんのでご了承ください。エラーがありましたらお知らせいただけると助かります。 Dockerについてよくある勘違い Matt Jaynes 元記事: Docker Misconceptions Dockerは最近のシステム管理業界で大変な脚光を浴びてます。これによるシステム管理の進歩ははかりしれないものがありますが、いくつか重要な点で勘違いしている人を見かけます。 分野を限定して語っているのでよろしく この記事で説明する内容は、主にWebサービスにおけるミッションクリティカルなシステムのマルチホストセットアップに限定しています。Dockerをそれ
![[翻訳] Dockerについてよくある勘違い｜TechRacho by BPS株式会社](https://cdn-ak-scissors.b.st-hatena.com/image/square/bba8947fb1fb4d0e9acba9c31526a1b7e40488a3/height=288;version=1;width=512/https%3A%2F%2Ftechracho.bpsinc.jp%2Fwp-content%2Fuploads%2F2014%2F02%2Fhomepage-docker-logo.png){kind=logo}
Dockerfileを書かずにAnsibleでプロビジョニングする | Webシステム開発／教育ソリューションのタイムインターメディア
Dockerコンテナでsshdを動かしてはいけない この記事ではDockerコンテナにAnsibleで接続してプロビジョニングする方法を説明します。 その前に、Dockerコンテナでsshdを動かしてAnsibleで接続しているみなさん、Ansible 2.0からDocker Connection Pluginが導入されてsshは必要なくなったので今すぐsshdを停止してください。 Dockerコンテナでsshdを動かしてはいけない理由は以下を参照してください。 Dockerコンテナ内でsshdを実行してはいけない理由 今回のファイル一式をGitHubに置きました https://github.com/eyasuyuki/docker-ansible AnsibleとDockerのインストール この記事は以下の環境で試しています。 OS X 10.11.5Ansible 2.1Docker
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
