Docker Part2©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
本番系のマシンと、Docker動かしてるホストとで、カーネルのバージョンって みなさんどこまで合わせてます? うちはRHELで動いてる本番系と、それとコピーの総合試験環境があって、 そいつらはカーネルもパッケージもバージョン揃えてあるんだけど、 その手前の、コーディングとか単体試験とかをやるコンテナ動かすDockerのホストも やっぱしカーネルのバージョン揃えるべき? >>6 うちは本番系から単体試験ホストまですべてカーネル揃えることにしてるよ Docket導入前だったけど、errataレベルの違いでI/Oスケジューラだったかの挙動が変わったことがあってね 理想はどうあれ、揃えておきなよ 本番系と、カーネルだけ揃えておけばいつでもコンテナ作れるっていうのが仮想マシンに対するDockerの大きな利点 カーネルをバージョンアップしてコンテナが壊れたんならさっさと作り直す、さっさと作り直せるように周辺の仕組みを整える、 消されて困るコンテナは作らない、他とカーネルを揃えられないコンテナも作らない、なんてことがDockerカンファレンスでも 強く言われてた Arukas終わったしもう遊べる場所はないのかな GCPは制限ありそうだし Linux板で言うことじゃないかもしれないけどWindowsでもHyper-Vで使えるようになってたんだな Bash on UbuntuにDockerも使えてWindowsPC強制されて虐げられてもなんとかなるぜ >WindowsでもHyper-Vで使えるようになってた Windows以外で使えるHyper-Vなんてあるの? HyperV無しのWSLで動くようになる予定はあるのかな MobyとかLinuxKitとか出てきたし タグが<none>なイメージを削除するにはどうしたら良いですか? 普通に削除しようとすると、 Error response from daemon: conflict: unable to delete XXXXX(image ID) (cannot be forced) - image has dependent child images ※-fを付けても同じ。 docker rmi $(docker images -f dangling=true -q)だと、 "docker rmi" requires at least 1 argument(s). そもそもdocker images -f dangling=trueは何も引っかからない。 "image name cannot be blank" と出たこともありました。何のコマンドか失念。 このコンテナは起動もできません。 どうやったら削除できるでしょうか? docker imagesってやったらどうでるの? docker使うとこ増えたけど アホって綺麗なサンプルいっぱいあるのになぜか設定ファイルグチャグチャ作るのな 結局構成管理出来ないだろ、あんなんじゃ Dockerで設定ファイル?何の話だ? Dockerで構成管理?何の話だ? お前なんか勘違いしてそうだな まあ言いたいことはわかるよ それだって秘伝のシェルスクリプトを書き足すよりはずっといいさ AWS Fargateってサービスがアマゾンからリリースされたらしいけど それってなんなの? docker系の技術は日進月歩すぎるのでredhatやcentosのような枯れたOSで使うのはきついですよね? 色々入れたり設定が必要だし。 お勧めなディストリはやはりubuntuやfedoraなどですか? >>21 docker自体は日進月歩すぎるところがあるので、OSは枯れたモノを使うというのがベストプラクティス fedoraでdocker運用するのって、fedoraのカーネル自体が不安定すぎて、コンテナ上げすぎると落ちたりするよ >>21-22 枯れたOSでよく話が通じるな? 対応OS書いてあるんだから、それ使うだけじゃん https://docs.docker.com/engine/installation/linux/docker-ce/ubuntu/ Artful 17.10 (Docker CE 17.11 Edge only) Zesty 17.04 Xenial 16.04 (LTS) Trusty 14.04 (LTS) https://docs.docker.com/engine/installation/linux/docker-ce/debian/ Buster 10 (Docker CE 17.11 Edge only) Stretch 9 (stable) / Raspbian Stretch Jessie 8 (LTS) / Raspbian Jessie Wheezy 7.7 (LTS) https://docs.docker.com/engine/installation/linux/docker-ce/centos/ To install Docker CE, you need a maintained version of CentOS 7. Archived versions aren’t supported or tested. https://docs.docker.com/engine/installation/linux/docker-ce/fedora/ 25 26 https://docs.docker.com/engine/installation/linux/docker-ee/rhel/#prerequisites To install Docker EE, you need the 64-bit version of Red Hat Enterprise Linux 7 running on an x86 hardware platform, or s390x (IBM Z) architecture. Dockerの古いバージョンならもう少し古いディストリでも動くかもな Redhat/CentOSはカーネル古いから新しいバージョンのdocker composeが使えないよ >>25 そんな制限あったっけ? どこかに書いてある? GUIいらないからホストOSも軽くて無駄がないalpineにするのが好き ほとんど何もできないから逆に後腐れなく気軽に捨てて新しくできるし! 俺はホストにはfedora atomic使ってるぞ なんかlinuxがいいものになったかのような錯覚をおこすわ coreosで使ってるっていう生粋のドッカーはいないのか? coreOSってalpine以上に使いにくくて何が良いの?って感じなんだけど何か取り柄はあるのかね RancherOSが出たときコレは来るかと思ったがそうでもなかった 雨後の筍のようにポコポコ出てくるな はやく収斂してくれ そいつらがいずれ、どうにもつまらない理由で内輪もめを起こしてまとまらなくなり あの機能はそちらにしかない、その機能はあちらにしかない、なんて状況となってる間に OracleやMSに持っていかれる、というところまでがテンプレ 誰かが早く僕の考えた最強Linuxを発表しないとな。 え、それが乱立してるって? BargeっていうのがDockerホスト用で最軽量・高速ブートをうたってるけど これVirtualBox専用でノートPCとかには直接インスコできないのかな? 更新頻度は高いみたいだから物理マシンでも動けば最強候補じゃないかコレ RaspberryPiで使えますみたいなことは書いてあるね 普通には使えないっぽいのは何か残念だな やっぱubuntu + kubernetesがいいのかな これからはなんでもかんでもコンテナって時代になるのですかね? 自前でリポジトリをシコシコ築いてきたディストリベンダーも もはややる意義を失っちゃったりするんですかね? chはchangeの頭文字から取っているから rootの変更って意味だろう コンテナはOS内にあるけど完全に独立しているから 例えばある家族の家の中で、 親がroot 子供がchroot ホームスティしてきた外国人娘がコンテナだ >>41 コンテナ使い出すと便利すぎてディストリあれこれこだわってたのが笑えてくるほどだね そして指摘の通り、独自にバグ潰しとかやってる一番活発なリポジトリ持ってるところと 逆に古いツールを保守し続けてるところはもてはやされてるが、それ以外が意気消沈してる 二極化だな パッケージ管理ツールをLSB前提でpythonやperlで書いてたところは それが原因でコンテナイメージのサイズをある一定以下に削減できなくてイーッてなってた かと言ってパッケージマネージャーは各ディストリのシステムに根深く食い込んでるから 切り離そうにも切り離せない・・・最近じゃsystemdの呪縛もあるだろうし でもまさかパッケージを単品ごとにインスコする日が来るとは誰も思ってなかったんだよな結局は コンテナってもっと早く登場しても良かった気がするんだが 技術的にはホスト型ハイパーバイザ型の仮想化よりも簡単なんじゃないの? そりゃ日本での常識だな、 日本は金持ちだから高性能コンピューターが当たり前だけど 世界的にはようやく高性能コンピューターが普及してきた ようやっとOS内にOSをおいても通常に使えるぐらいのPCが普及してきたんだ コンテナは昔からあっただろ Linuxに来るのが遅かっただけで user mode linuxはコンテナに入りますか? コンテナ内のプロセスがしんで終了しても自動でコンテナ再起動してくれるオプションがあった コレ使えばわざわざプロセス死活監視用ツール起動しなくて良くなるのか ちょっとスゴ杉ない? そんなもんsystemdに標準搭載されてる機能だろ dockerコンテナってホストOSのカーネル使ってるの? どこもそう説明してるんだけど、ベースイメージにlinuxつかってその上にmysqlとか載せてイメージ化してるって認識だったんだが。 ホストのカーネルを使っているという説明で合っているよカーネルの上で動かすカーネルとかもうそれVMじゃん >>55 ありがと。 そうなるとwindowsだとdockerインストール出来るけど、エンジンとかに工夫してあるのか ttps://www.slideshare.net/zembutsu/docker-images-containers-and-lifecycle ここの19ページめに、ベースイメージにイメージ層を載っけていくて記載あるけど、 これは間違ってるの? おい、素人同士で勝手に話をすすめるなw >>55 > カーネルの上で動かすカーネルとかもうそれVMじゃん VM=仮想マシン=マシン(ハードウェア)を仮想化してないならVMにはならない >>54 > dockerコンテナってホストOSのカーネル使ってるの? そもそもホストとかゲストとかいうものがない Linuxっていうのはカーネル(https://www.kernel.org/ で配布しているやつ)に DebianやらUbuntuやらRedhatなんかが、いろんなアプリをセットにして配布してる カーネルは基本的に汎用。だから同じカーネルを使っても DebianやCentOSなんていう別のディストリが作れる さてパソコンにDebianをインストールしたとする。そこにはカーネルといろんなアプリが有るわけだが Dockerで作ったDockerコンテナはこのうちカーネルだけを利用する。 例えばFROM debian:jessieであれば、debian:jessieのディスクイメージを使うと考える そのディスクイメージにはもしかしたらカーネルのバイナリも含まれてるかもしれないがそれは使わない。 パソコンにインストールしてあるカーネル + FROMの元になったディスクイメージ を使ってアプリを動かす そんなもんだから、Debianをインストールしていたとしても、UbuntuやCentOSのディスクイメージを使うこともできる パソコンにインストールしたカーネルを使う。 そこで疑問になるかもしれない。 幾つものDockerコンテナが同じカーネルを使っているとしたら psコマンドでプロセス見た時、他のコンテナのプロセスまで見えてしまわないのか?と そこで出てくるのがLinuxカーネルに搭載されたコンテナ機能 この機能によって各コンテナは別々に隔離されることになる 同じカーネルを使っているというのに、それぞれ別々の環境を持っているようにみえる ファイルシステム空間を分離したり、プロセス空間を分離したり、 メモリ空間を分離したり、ネットワーク空間を分離したり ありとあらゆるものを分離して独立した環境を作り出している それが大変な作業だった さて、ここまではパソコンにインストールされたものがLinuxの場合だけど WindowsやMacOSはどうなっているのか? コンテナ機能っていうのはLinuxカーネルが持っている機能だが WindowsやMacOSはLinuxではない。 どうやってLinuxのカーネルの機能を使っているのか? 答えを言ってしまえばあたり前のことだが、WindowsやMacOSでは 裏で仮想マシンが起動していてLinuxがインストールされている ちょっと前までの、Docker Toolboxと呼ばれていた時代はVirtualBoxを使っていた。 今のDocker for Windows および Docker for Macでは WindowsではWindows標準のHyperVを MacOSではMacOS標準のHypervisor Frameworkを利用したHyperKitを使っている 仮想マシンを使っていると言ってもDockerに最適化されており Windows もしくは MacOS のCUIからdockerコマンドを動かすとちゃんと 使えるように構成されており、まるでLinuxと同じようにOSの上に直接dockerが 起動しているようにみえる。だけど実際は仮想マシン上で動いているので Dockerの設定画面にはメモリをどれだけ仮想マシンに割り当てるかなどという設定が存在する 余談だがWindows 10ではWSLという仕組みによって LinuxカーネルをNTカーネルでエミュレートしている 今ではLinuxカーネルを使っていないのにUbuntuが Windows上で動作するようになっている。 もしこのWSLがコンテナ機能までエミュレートする完璧なものになったら その時はWindowsでHyperVを使わずにDockerが動くようになるだろう >>62 親切すぎて草 下手な記事よりわかりやすい >もしこのWSLがコンテナ機能までエミュレートする完璧なものになったら なるのかね? 最近MSがLinuxに擦り寄ってて気持ち悪い >>62 帰ってきたらすごい丁寧なレス来てたっ ありがとうございます > 例えばFROM debian:jessieであれば、debian:jessieのディスクイメージを使うと考える > そのディスクイメージにはもしかしたらカーネルのバイナリも含まれてるかもしれないがそれは使わない。 ttps://github.com/aws/amazon-linux-docker-images/blob/10641478ad16c6f44b691dc41acfc221c7a7594f/Dockerfile たしかにamazon linuxの中見ると、コマンドとかは設置してるけど/boot のカーネルとかは置いてなかったわ windows, macも結局裏では仮想化されてたのね 色々わからなかった所が一遍にわかったわ! >>59-62 これは永久保存レベル Github上のissueでもWSLだけでLinuxコンテナ動かしたいって要望はかなり挙げられてて MSスタッフからみんなの期待は認識してますってレスも付いてた もしホントに実現したら世界が変わる!みたいな投稿もあって大げさだけどちょっと同意しちゃう >>59-62 を書いた本人だけど、なんでこんなに喜ばれてるんだろう?w WindowsやMacOSでDocker使ってる人にとっては常識だと思ったんだけどね 最近MacOSでDocker使ってる人なのかな? 昔はVirtualBoxのインストールが必要だし 今もWindowsならHyperVの有効化が必要 仮想マシンが使われてるのはすぐにわかると思ったんだけど あと仮想化という言い方は良くない 色んな意味の仮想化があるから WindowsやMacOSで使った時のDockerのボリュームって謎だよね 例えばWindowsでdockerコマンド使った時、Windowsのディレクトリを ボリュームとして指定すれば、dockerコンテナの中から見える Linuxでは当たり前の動作だけど、WindowsやMacOSでは仮想マシンで dockerが動いてるのだから、単純に考えれば仮想マシンの中にボリュームができるはず まあホストOSのディレクトリを仮想マシンのディレクトリにマッピングしてるんだろうけど Docker for WindowsやDocker for Macではそういうことを感じさせない作りになってる vagrant入れて色々弄ってた後にdockerやったから全然気付かなかった 職場macで家はwindowsで、両方vagrant入れてたしね ネットで調べても、その手の情報全然見なかったよ 本読んで勉強しろって話なのかな? >>67 自分は初心者なのでナイスな解説に出会えてラッキーでした ありがとう 俺も最近、Docker for Windows入れてみてたばかりなんで、HyperVが必要な理由とかが分かって参考になった > ネットで調べても、その手の情報全然見なかったよ > 本読んで勉強しろって話なのかな? そうなんか? じゃあなんで俺知ってるんだろう?w もう3年ぐらい前から触ってるからなぁ。当時はWindows使っていたし(今はMacOS) まあ普通DockerってLinuxで使うもんな。Dockerの解説といったら普通Linux上の話だし WindowsやMacOSでどうやって使えるようにしているのかまでは関係ないか じゃあおまけでもう少し仕組みの話を。 Dockerっていうのはクライアント・サーバー型の設計になってる つまり通常端末から実行しているdockerコマンドとサービスとして実行する dockerサーバーが存在する(紛らわしいことにどちらもdockerコマンド) サーバーの方のdockerは説明したとおりWindowsやMacOSでは仮想マシンなしには動かない だけどクライアントはWindowsやMacOSでも動く (dockerはgoで作られておりマルチプラットフォームになってる) クライアントーサーバー型ということは、ようするにdockerサーバーを リモートのLinuxで動かしていて、手元のWindowsでdockerコマンドを叩いて 接続するということができる。ちなみにdocker buildを実行すると手元のDockerfileやDockerfileと 同じディレクトリにあるファイルを全てリモートに送信してDockerイメージをビルドしている (なので手元にごみファイルがあると遅くなるよ = dockerignoreの話につながるが省略) 使い方の一つとしてあちこちのLinuxサーバーでDockerサービスが動いていて 手元から接続先を切り替えて操作するというものがある この時に使うのがdocker-machineで環境変数DOCKER_HOSTなどを管理する機能がある Linuxでローカルのdockerサーバーに接続するときはsocket経由で接続するんだが Docker Toolboxの時代ではTCPで接続するためにWindowsやMacOSXではdocker-machineが必要だった でも最新のDocker for WindowsやDocker for Macではdocker-machineが必要なくなっている どういう仕組みになってるんだろうね?w 少し前の手順を見るとdocker-machineがでてくると思うがローカルのDockerに接続するだけなら忘れていい 今はWindowsでもMacOSでも、ローカルのDockerに接続するときはTCP通信を使っていない(はず)だけど WSL(Linux用Dockerサーバーは動かない)環境から、dockerクライアントのLinux用バイナリを使って HyperV上で動いているDockerサーバーに接続するときは、TCPでつなぐ必要がある。その時に必要になるのが 「Expose daemon on tcp://localhost:2375 without TLS」というやつ。詳しくはぐぐってくれ もう一つ思い出したが、Docker for WindowsはHyperVで動いているのでVirtualbBoxとは同居できない vagrantを使うのならVagrant+VirtualBoxではなくVagrant+HyperVで使う必要がある >>73 勉強になります 最近はOS、仮想化、dockerと色々と入り乱れて全体像を理解するのに苦労するなぁ ま、所詮パンピーですから dockerとkubernetes使いこなせないと時代遅れになるぞって言われたけど 一般の開発者がkubernetesを必要とするシーンってどのくらいあるのかな dockerは問答無用で便利だけど dockerとkubernetesの間にクラウド(aws、gcp等)があるね クラウドを使わなければkubernetesはでてこないだろう ローカルでのサービス開発用途であればdocker-composeで十分だし kubernetesはなんかクラウドの上でクラウドを作ってる感じで、 将来的には、いろんなクラウド会社の共通インターフェースに なるんじゃないかって思ってるけど、今は各社のクラウドのサービスに kubernetesが対応しきれない感じ。だって自社のGCPすら完璧にコントロールできないもの 例えばオートスケールしたいならkubernetesを使わないで直接クラウドの 機能のオートスケールとかした方がいいんじゃないかな なぜならkubernetesの場合コンテナのオートスケールになるわけだけど 起動しているVMの中でコンテナをオートスケールするだけなので VMの数もオートスケールしないとコストは下げられないから kubernetesを使っても頑張ればコストを下げられるオートスケールは 実現できるんだろうけど、コンテナとVMの二重のオートスケールが実行されて 少数のコンテナだと多分不安定になりそう。何十台レベルで常時コンテナが 起動してる状態じゃないと安定させられないんじゃないかな? それが将来はコンテナのオートスケール = VMのオートスケールになるんじゃないかって思ってる で最終的にはVMを使う=裏で勝手にkubernetesが動いてる時代になるんじゃないかな そうなってくるとkubernetesは確かに必須。だけど意識しない状態になってると思う でも個人的にはkubernetesの方向じゃなくて、クラウド自体がコンテナに 直接対応してくれる方を望んでるけどw(例えばGCEは起動するコンテナをデプロイできるようになった) kubernetesはバージョンが勝手にアップグレードする(GCPの場合)ことを考慮しないといけないのと kubernetesを動かすだけで各VMで1.5GB以上のメモリを使用するのが気に入らない 誰でも簡単にパソコン1台で稼げる方法など 参考までに、 ⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。 グーグル検索⇒『宮本のゴウリエセレレ』 PTHNS6LLYQ kubernetesはほぼ全部の業界大手が参画してるけど そんでもコケるってことあるんかな いやまぁ莫大な金が動くインフラ業界だからねぇ 小規模ではdocker-compose一択って事でおk? 小規模っていうか、1台のマシンの場合って考えてるよ 開発用メインでdocker runのオプションを指定するのが 面倒になった時w Docker toolboxの最新版(18.01.0-ce)を入れたら何故かdockerのデーモンに接続できなくなったけど VirtualBoxのGUIから仮想マシンを止めたら直った docker-machine restartは効果がなかった Docker toolboxってwin/mac上にlinux走らせてその上で更にdockerしてるからね 誰もがWindows Proを使えるわけじゃないからなぁ VirtualboxベースのDocker toolboxはまだ必要意義は大きい Hyper-VはProfessional以上必須なのか。 リモートデスクトップサーバ使いたいから、"わざわざ"Professionalのライセンス にしてるけど、Docker for Windows (Hyper-V)を使うために必要ってのは微妙。 Docker使ってるとKubernetesしたくなってきてKubernetes on Atomic Host on Hyper-Vとか組みたくなるしへーきへーき >>88 そういう人のためにDocker Toolboxというのがある CoreOSはDocker利用を想定してたけどコレジャナイ残念OSだったので次はRancherOSあたりに期待してる >>91 ヤフーの記事が、港のコンテナヤードの画像使ってて混乱したわw コンテナをビルドするとき Dockerfile 内で RUN yum list した結果を、ホスト側に残したいんだけど、なんか良い方法ないかな? >>95 Debian 使いだから勘違いしてる可能性が高いけどこういう感じで tee とかリダイレクトじゃダメなの? $ cat Dockerfile FROM centos RUN yum list installed | tee yum.list $ docker build -t yumlist . ~~snip~~ $ docker run --rm yumlist head -n5 /yum.list Loaded plugins: fastestmirror, ovl Installed Packages acl.x86_64 2.2.51-12.el7 @CentOS audit-libs.x86_64 2.7.6-3.el7 @CentOS basesystem.noarch 10.0-7.el7.centos @CentOS >>96 便利なやり方が無いかなーと思って。 一度起動してその出力を回収する方法しかないね。 /var/lib/docker/tmp /var/lib/docker/containers →単純にtmpfsにできる /var/lib/docker/overlay2 →ここをtmpfsにすると再起動で空になったとき整合性エラーでコンテナが起動できなくなる →かと言ってtmpfsをupperとしてoverlayfs化しても別エラーが出る(恐らくlower側のハードリンクが作れなくなるため) /var/lib/docker全体をtmpfsにすれば整合性もハードリンク問題も解決するけど 消費メモリが増えるのとanything-sync-daemonとかでバックアップの手間も増える システム再起動後にコンテナ自動起動しないならsync不要だけどイメージダウンロードからやり直しになって鬱陶しかった ☆ 現在、衆議員と参議院の両院で、改憲議員が3分の2を超えて おります。総務省の、『憲法改正国民投票法』、でググってみてください。 国会の発議はすでに可能です。日本の、改憲を行いましょう。 平和は勝ち取るものです。お願い致します。☆☆ >>98 その問題は /var/lib/docker 以下が ext4 なら、fstab でマウントオプションに commit=300 とか付けると結構な対策になる 短命コンテナをバンバン使い捨てるケースで .../docker/overlay2 にゴチャゴチャ置かれても sync 前にすぐ消えたファイルやディレクトリは単に無視されてディスクには書き戻されなくなって安心 デフォの 5 秒だとちょっと早すぎるんだよな 欠点はもちろん不意の電源ダウンで指定秒数ぶんだけデータロストする可能性があることだけど ノートだったり UPS あったり、吹っ飛んでもいいや的な状況なら sync-daemon 系も不要だから楽 俺は USB メモリだけで運用してると 1 年ちょっとで寿命が来て色々と試行錯誤の後 Arch のフォーラムかどっかに書いてあったこのシンプルな方法に落ち着いた ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる