Docker Part3

LXCを使った軽量仮想環境。
これからの動向が気になるところ。
情報共有しましょう。

http://www.docker.io/

前スレ
Docker Part2
https://mao.5ch.net/test/read.cgi/linux/1506574845/

>>696
ない。ボリュームを使え。

コンテナなら
いちいちインフラチームにNode使えるサーバー用意してとか言って
準備してもらう必要もないからな
最終的にDockerイメージを作りさえすれば良い

>>696
このひとDockerをVirtualBoxか何かと勘違いしてる？
両者は異なる問題を解決するために作られたものだ

>>700
すみません正にその通りです。軽いから簡易的なVirtualBoxのような使い方ができそうとか考えてた初心者です、素直にそっち使うことにします。
所で新たに生じた疑問なんですがよく紹介されてるUbuntuとかのOSイメージって何に使われてるんでしょうか？
色々調べたらアプリとか鯖に使われてることは大半なんですがOSの使用例があまり見つからなくて。

>>695
あいつはたぶんニートか学生だろ。
月曜午前中に連投してたし。
たぶん学生じゃね？

>>679
>で、その話とは関係無しに、Docker以前の開発現場で場数を踏んでいれば、
>「当然本番機にあげなきゃ動かないよね？どうやっていたの？」に対して何らかの解決策を行っていたはずなんだか？
>君の場合、それは何だったの？

俺はこの回答をずっと待っているんだが、
早く答えてくれないかな？
何で時間がかかるのか全く分からんｗ

>>701
サーバやアプリケーションを動かすための最小限のファイルセットが含まれている

OSそのものとしてはあまり使わないのでinit（systemd等）も通常入ってない

>>703
どうやっていたの？って何を聞きたいのかわからん。
Docker以前？ 大昔のデプロイの話か？

今みたいにぽんぽんサーバー作れるわけじゃないから、新しくサーバーをデプロイするのは
たいていサーバーの購入から始まる。サーバーのセットアップは手順書が残ってるからそのとおりやる。
もちろん手順書がない初回は、手順書を書きつつサーバーにセットアップするわけだが。

手順書と言ってもそのハードウェアとかOSのバージョンは変わるわけで、
手順書通りやると言うより記録見ながらその都度対応が必要になる。
アプリ用とか特定のものを動かすのに必要なパッケージを手順書という名の
記録を見ながらインストールしていく

で、パッケージをインストールしただけじゃ終わらない。バージョンが微妙に変わるから
アプリの改修作業が必要になる。大体は言語のライブラリが新しくなってるからそれに合わせてアプリを修正する。
アプリの改修作業まで行ってようやく（例えばアプリケーションサーバーの）一台のデプロイが完了する。

その後はそのサーバーを大事に育てる（笑）上記のようなデプロイ作業をアプリのアップデートのたびにやれるわけがないからね
データベースサーバーとかならセキュリティパッチを当てるぐらいで対して変わらないがアプリケーションサーバーは大変。
ある機能に対応するためにライブラリのアプデートが必要だがそれが標準パッケージで提供されてないから
オレオレでパッケージングする必要がある。当時はperlだったから、dh-make-perlだっけな？それでDebian用のパッケージを作る。
アプリの更新はsvn up（笑）そしてapacheの再起動（笑）手動（笑）当時は便利なツールは何もなかったからな。

今は楽だよ。Dockerさえ動く環境があればいい。アプリのアップデート作業なんてものはない。
サーバーはハードウェア仮想化され消して作り直すことなんて簡単、壊してデプロイすればアプリも新しくなっている。
アプリもコンテナ化され、単一のサーバーだろうがクラスタだろうがどこでも動く

うちは最初はサーバーはSSHしてセットアップし、
phpファイルをSFTPでアップロードしてた
当然ながら要らないファイルをアップしたり、し忘れるミスが多発

次にローカルからのrsyncになったが、
rsyncの無視するファイルのルールを編集し忘れて
ファイルが消えたりした

なお、どちらでも本番環境を直接書き換える模様
ブルー・グリーンデプロイ？なにそれ美味しいの？

次の進化は>>651
みたいなphp専用のデプロイツールとも思ったが、
それを経由せずCIでビルドとAmazon ECSでデプロイに進化した

データベースのマイグレーションを除けば
Dockerイメージの更新だけで
安全にローリングデプロイ可能になった

EC2インスタンスはあるが、
ASGで使い捨てになり
サーバーがキャトルミューティレーションされたみたいに死んでも、
代わりをすぐ作れるようになった

アプデもAmazonの配布するAMIの更新で済む

なんか最近はコンテナランタイム沢山あってよくわからない
どれを使えと
rkt（死亡？）
containerd
podman
lxd
cri-o

基本はDockerを使っていればいい
コンテナランタイムは使える場合があったときに考えればいい
自分から使えるようにするものじゃない

openshiftの話題が全然出てこないけど、まだみんな使ってないのかな

ベースはKubernetesだからなぁ

クーベルネイティスのスレもあるんやけどなあ

クベルネテスかクーベネティスが好き

クバァでしょ

CoreOS Container LinuxをDockerコンテナ動かすOSに使ってたが
サポート終わりそう
Fedora CoreOSかFlatcar Container Linuxに乗り換えたい

FlatcarはほぼCoreOSのまま
メンテされるらしいが
rktは削除されるのか…？

OpenShiftはIBMが主に金融機関に対してクラウドのセキュリティリスク煽ってオンプレでサポート特盛契約をゴリ押しするための飯の種だろ
自社で使うようなもんじゃないよ

代替技術が本家を超えることってめったに無いよな
なんかったっけな？

LinuxってUNIXの代替じゃん？

Android RuntimeもJava VMの代替品

超えちゃいないなどっちも。

Docker Desktop for Windows 2.2.2.0(Edge)でようやくWindows Homeでもインストールできるようになった。

insider preview(slow ringで十分)でwsl2が必要。

もう正式版が出たのかと思った。
WSL2がまだだからそれはないかｗ

Docker Desktop for WSL2として出すんじゃなくて
Docker Desktop for WindowsをWSL2対応するってことかな？

だからDocker Desktop for Windowsとしては正式版だけど
WSL2対応機能は一応ベータ版と。完璧に動いていてもWSL2が
正式版じゃない以上なにか変わるかもしれんしね。

GKE無料じゃなくなるらしい

https://devopsdirective.com/posts/2020/03/managed-kubernetes-comparison/

0.1ドル*24*30=月72ドル
EKSとほぼ変わらない値段になる
ただし、単一ゾーンのクラスターは1つだけ無料

小規模クラスターだろうと大規模クラスターだろうと
値段は一緒なので
小規模クラスターを大量に使うなら
AKSやDOが安い

>>710
使ってるよ
minishift入れたけどバグが目立つ

minishiftはバージョン3なんだよね
今ならCRCの方が良さそう

dockerがあるとJDK要らないみたいな話聞いたんだけど
でもdockerがあるからといってOSのAPIに非依存になるわけじゃないよね？
dockerの上にJDK置いてその上でJavaを実行するとかなら分かるけど、
dockerだけだと例えばLinuxカーネルとかに依存したプログラムを書くことになる、という理解であってる？

>>726
間違ってる。まずなぁ、JDKは開発のためのツールであってJavaアプリを
動かすのに必要なものじゃない。その時点で間違ってる。お前はJavaすら分かっていない。
Javaアプリを動かすのにひとうようなのはJREだ

> dockerの上にJDK置いてその上でJavaを実行するとかなら分かるけど、
> dockerだけだと例えばLinuxカーネルとかに依存したプログラムを書くことになる、という理解であってる？

人づてに聞いて想像するんじゃなくて、Dockerをちゃんと勉強しろ
お前が言ってるのは、

　スマホがあればネットするのにパソコンはいらないって話を聞いたんだけど、
　スマホの上にブラウザをインストールしてネットするならわかるけど
　スマホだけならネットできないよね

って言ってるようなもんだよ。例えの意味わかる？
お前が「スマホだけだとネットできない！」って言ったら
スマホはブラウザをインストールして（してあって）ネットするために
作られた道具なんだよってツッコミはいるだろ？

DockerはJRE（等）を置いて使うために作られたものなんだよ。
Dockerだけで使うとかなんだそりゃｗ
スマホだけだと電話しか使えないという理解であってるって聞かれているようなもんだ。

今（オラクルの）JREは存在しませんよ
あとJDKでも実行できます

今（オラクル以外の）JREは存在してますよ
と言われても困るんだがｗｗｗ

> あとJDKでも実行できます
JDKとJREの違いが今重要って分かってないから
君は"Java"の初心者なんだよ。

JREがあれば動くからJDKはいらん。
という答えでも良いんやで？ｗ

OSのAPIに非依存とか言ってる点からWindowsのことしか知らんのだなってわかるし
Linuxカーネルとかに依存したプログラムとか言ってる点からLinuxも知らんのだなってわかる

ああいい、言わなくていい。中途半端にしか知らんって意味だから。
浅い知識のまま、何年もやってるんだろうなってわかる。
そして自分が詳しいつもりでいるんだろうなって文章からわかるからさ。

なんか格好悪い。

dockerだけだとLinuxカーネルに依存したプログラムを書くことになるよね？って言うのは、
フランス料理フルコースの店って単品で頼めばフルコースじゃないよね？って言うようなもんだｗ

私の頭は悪すぎる。
ここのやり取りは半分もわからない。
何を言っているだろうな。

kubernetesだんだん分かってきたわ
面白い仕組みやね(´・ω・`)

オーバースペック気味だよな
なによりメモリ消費量が多すぎる

流行ってないけどswarm modeが結構好き

dockerを前提としたソフト開発において、差分ビルドとかデバッグはどうやって使っていけばいいの？

>>738
毎度のことながら使い方が間違っている。
Dockerは仮想マシンじゃない。

Dockerの中で差分ビルドやデバッグという
開発作業は行わない

開発が終わってテストもデバッグもすんで
それを配布するときに使うもの

>>739
ありがとう。いっていることは分かる。
質問を変えてもう聞きたいのだけど、開発環境の統一化という意味でdocker使いたいけどいい案ありますか？

そんなふわっとした聞き方するならググった方が早いんでね？

>>740
開発環境を押し付けるな。プログラマの自由にやらせろ。「統一環境」ではなく
「推奨環境」として環境づくりが面倒な人のために、例の一つとして作るだけにしろ
統一はしないという前提で「統一しなくても信頼できる」
ことを保証するためにDockerを使うんだよ

統一しないっていうことはわかりやすく言えば、開発環境は
WindowsでもLinuxでもmacOSでも使っていいということ
使うIDEやテキストエディタやブラウザなどはそれぞれ違うだろう
しかし何を使って作っても、同じように動くと保証するにはどうするか？

それが必要なのは"差分"ビルドやデバッグ環境を統一することではない。
"完成版"ビルドと完全なテスト用のDockerイメージを作成することだ。
テスト用のDockerイメージを使ってCIで実行すれば
どういう開発環境を使って開発していたとしても正しく動くことが保証される。

もちろんこのテストというのは全体のテストだ。
自分が開発した部分のテストだけをやりたいのに全体のテストをしていては時間がかかる。
こういうのは自分の開発したマシンでやることだ。つまりそれぞれ違う開発環境でやることだ。

開発には何よりスピードが重要だ。いちいちDocker（ついでにいうと仮想マシンも）を
絡ませなければ開発できないなんて愚の骨頂だ。
環境特有のバグはゼロではないから、統一した環境（つまりDocker）でテストすることは重要だが
大抵の問題は開発者が書いたコードにバグがある。特定の環境でしか発生しない問題は少ない。

どうしてもDockerや仮想マシンが必要な場合でない限り、Dockerや仮想マシンを使わない。
それが開発環境のあるべき姿だ。Dockerや仮想マシンを使わずに高速に開発テストし
場合によってはローカルでDockerを使って統一"実行"環境でテストも出来るようにする。
そして最終的には共通のCIサーバーでテストを実行する。本番用Dockerイメージを使って実行する。
これが今の理想の開発スタイルだ。
もう一度言うがDocker（や仮想マシン）で開発環境を統一するな。そういう時代は終わった。

Heroku, CircleCI などの、CI/CD パイプラインだろ

git すれば、Jenkins などのタスクランナーが走って、テスト・デプロイされる

何を持ってそんな自信満々に言えるんだろう。クッソ古いlibcとかどーすんのさ

libc5やELF移行前とかどうすんのさ！ってか。

>>744-745
なにがいいたいのかわからん。クロスコンパイルがしたいって話？
つまり開発マシンでそのまま動かすことが出来ないバイナリを動かしたいって話？

いや俺は長文は読まない主義なので、元ネタすら知らん。

おまえらの糞みたいな書き込みは3行が限界だ。
それ以上は時間の無駄。

自分で知恵遅れ宣言してて草

ガイジの日記帳だからしゃーない

>>742
へいすみません

クーベルネーテスって便利ですか？

そーでもねーです

Dockerfileに以下を書いてbuildしてもWarningになってしまいます…
Qiitaやら海外の掲示板の情報を試しても上手くいかず…
誰か同じ経験or解決したことある人いませんか？
docker介さず行えばpip install コマンドは動くのですが…
Hyper-VにCentos8入れてそこでやってます。

FROM python:3.7
RUN pip install --upgrade pip

→WARNING: Retrying (略　Failed to establish a new connection

>>754
おそらくプロキシ環境でDockerfileにプロキシ設定していないのでは

>>754
これ実行したらどうなる？

docker run -it busybox ping 8.8.8.8
docker run -it busybox wget http://google.com

>>755 ありがとう。プロシキ環境は使ってないっす。念のため調べてみます。

>>756 こんな結果になりました。下が通らないのが変なのでしょうか？
[root@localhost ~]# docker run -it busybox ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=5 ttl=49 time=29.793 ms
64 bytes from 8.8.8.8: seq=6 ttl=49 time=15.181 ms
64 bytes from 8.8.8.8: seq=7 ttl=49 time=13.270 ms
64 bytes from 8.8.8.8: seq=8 ttl=49 time=18.520 ms

[root@localhost ~]# docker run -it busybox wget http://google.com
wget: bad address 'google.com'

ネットワークはつながってるけど、DNSサーバーの問題だね。
いまから飯作るんで後でなｗｗｗ
それか他の人お願い

DNSサーバーか…ありがとう、もう少し調べてみます！

でもまあ解決策はよく知らんのよねｗ
俺は普通に使えるし。

こことか参考になるんじゃね？
https://qiita.com/frost-tb-voo/items/fcc0c0fe7561b9101bf4

あと興味があるからこの結果も見てみたいな。
普通はプライベートIPアドレスなはずだが
身元がばれるようなものが入ってないことに注意なｗ

docker run -it busybox df -h
docker run -it busybox cat /etc/resolv.conf

DNSサーバーっていうか、名前解決が出来てないってことね

test

Filesystem Size Used Available Use% Mounted on

何か書けないな？
resolv.confはプライベートIPアドレスと、あと自分でさっき追加した8.8.8.8が入ってました…

>>760
docker run -it busybox df -h
↑の結果を書こうとしたら何故かjaneがエラーになーるww

hyper-Vの設定が悪さしてる気がしてきた…

Docker Desktop for Windows を使ってるんだよね？

何か、コンテナの概念と仕組みをスッキリ、はっきり
説明してるお勧めサイトってありませんか？

遅まきながら使い始めたけど、よくわからない。
思考がどうもコンテナ≒仮想マシンってイメージに引っ張られる

とりあえずくじらが書いてある本を、ｱﾏｿﾞﾝﾎﾟﾁｰﾉからのンロッカーで受け取って
ざっと読んだが、余計に混乱しだした・・・。

すみません、コンテナはDockerの誤りです。

>>768
何のためにDockerが作られ、どんな問題を解決しているのか？を調べたほうがいいよ
何に使えるかじゃなくて、何のために使うか。
（何に使えるかだと本来の用途ではない使い方をしてる例が多い。
曰くそういう使い方も出来るからいいじゃん。らしいｗ）

まあ答えを言ってしまえば、自分でビルドしたアプリを配布するために使う。
用途が重要だから仕組みをいくら調べても間違ったイメージは訂正できない。

Dockerの本とかでも良くない例が多くて、Dockerはdockerコマンドや
kubenetes使いこなすんじゃなくて、Dockerfileを自分で書くことが重要なんだが
そのDockerfileであっても例として「既存の○○サーバーをDockerで動かしてみましょう。」
という話が始まる。本来は自分で開発したアプリのDockerfileを書くものだ。
「自分で開発したアプリ」はDockerの話からすれば本題からずれるから
既存の○○を例として使うのはわかるが、そうするとDockerの正しいイメージから遠ざかってしまう。

自分が使いたい使い方を我慢してまで
Dockerの本来の使い方を守ろうとする意味は何？

他の方法がある、とか言うんだろうが
いろんな手法を混ぜるのがめんどくさいから
多少設計思想から外れても全部Dockerでやっちゃうってのも別に自由じゃん

あ、ごめん流れ読んでなかった。
>>768の質問があっての返答なら全くごもっともだわ

>>771
> 自分が使いたい使い方を我慢してまで

自分が使いたい使い方にはそれに適したツールがあるから
より適したツールが有るのに、我慢してDockerを使わなくていい

>>771
> いろんな手法を混ぜるのがめんどくさいから

いるよね。そういう奴ｗ
より適したツールが有るのに「新しいのを覚えるのが嫌だから」
全部エクセルで頑張りましたとかｗ

頑張るところを間違っている。楽するために頑張って知恵をつけるのではなく
バカなまま無駄な努力をすることを頑張る

>>773-774
スクリプト書けば一発なのにExcelで何とかするのは純粋に時間のムダだけど、
「Dockerの本来の想定からは外れるかもしれないけどあっさり使える」用途があるなら
実際そういう使い方もできるからいいじゃんとしか言えんわな。

何のために作られたとか、
作った奴の思想はこうだから、とかクソどうでもいい。

>>775
実際は「そういう使い方出来るからいいじゃん。
それにしてもDockerって使いづらいですねｗ
こんな事したいんですが出来ないんです。」
ってなってるから言ってんだよ

>>776
そこは異論ないよ。
俺のそもそものツッコミも筋違いだったわけだし。

>>770
> Dockerはdockerコマンドや
> kubenetes使いこなすんじゃなくて、

買った本はまさにそんな感じの本だった。
このコマンドを打つと、コンテナはこういう状態になりまーす、って感じで
Dockerコマンドとは、Dockerとは何ぞや、どういう仕組みなのかって事が中心で
「どうしたら、Dockerって便利だなーってなるんだよ！！」って雰囲気の本だった

目鱗。ありがとうございます。

「前CentOSで組み立てたこのWebサービス環境だけど今度はUbuntuで動かして！」とかいう指示が来た時にdockerで作っていればもしや楽だったのでは…ってなった事はあった
そういう感じじゃないかなぁ的外れだったらごめん

インフラ専業の人が仮想化技術の1つとしてdockerを学ぼうとしているのだとしたら、
たぶんそれはあまり意味がないからやめた方がいい
dockerコンテナはアプリケーションのパッケージ化技術だ
アプリケーションにOSを丸ごとバンドルする、いわばスタティックリンクの一種にすぎない

インフラ屋だけどDocker便利。
Zabbixコンテナを複数環境にそれぞれ独立して作ってるんだけど、
VMではメモリ消費の観点で難しかった。

開発者がCPUやコンパイラの技術を知っておくべきなのと同じように
インフラ屋がDockerの内部技術を知っておくのは正しいが、
普段の仕事でそれらの技術は使わないんだよ。

知っておくとトラブル解決が素早く出来るが
インフラ屋にとってのdockerを使う普段の仕事は
作られたDockerイメージをただ起動するだけ
YAMLファイルに一行書けば終わるぐらいのもの

インフラ屋の仕事が楽になるのではなく、
インフラ屋の仕事が無くなるのがDockerの便利さなんだから

世にあるDocker本は「Docker入門」ではなく
「Dockerを実現する内部技術詳細」と言ったほうがいいぐらい
それぐらい普段の使い方と入門書の内容はずれている

いや普段の仕事で使ってるけど

用途を決めつけるんじゃなくこれなら便利だって思ったらどんどん活用すればいいんだよな
このスレ見てるとdockerは将来夢のような快適さを提供してくれる
気がする

実際には、間違った用途で使っていて、
これDockerでどうやるの？
こんな事したいんですがどうやるの？
Dockerって使いにくいね
って話になるのでうんざり。

間違った用途で使うと、Docker批判につながる
だから、用途が間違ってると、毎回言ってる。

読点とか改行の使い方がアレっぽい

>>786
そういうとこだぞ

正しいか間違ってるかってより
向いてるか向いてないかよね

インフラ屋はすぐにDockerの中でsshサーバーを動かそうと考える
Dockerはそういう為のものじゃない

なんかめんどくさい原理主義荒らしが居着いたね

wordでドキュメント書くの面倒だから、dockerでasciidocのコンパイラを作って、
イメージファイルと、バッチファイルを配布した。
なかなか便利に使ってる模様。

↑このように
本当にやりたいことは「asciidocのコンパイラ」を作りたいだけ
だけど、それを動かすのにライブラリとかが必要だから
Dockerでまとめる。という使い方をするもの

CIで使うようなビルド用/テスト用の本当に使い捨てのコンテナは十分にコンテナ仮想化の哲学と目的にマッチしてるけどな
上でも書いたがVSCodeで使えるような開発用コンテナも十分に有用

個人的には使い捨て或いは壊れたら作り直すものならアプリも環境もサービスもコンテナが良い
そういう意味では, コンテナ仮想化を選択する前に用途が決まっていないと話にならない

用途が違うこともまぁあるんだろうが, それ以上にコンテナに求めるものが曖昧なのにふわっとした目的で使おうとするからコンテナに柔軟性やら壊れた時に直すやらが必要になるのだと思う
少なくともディスポーザブルな環境としてのコンテナは普通に適応

MS-DOS時代ならOSもアプリも全部フロッピー一枚だったのにな

せやな、Aドライブに起動ディスクを入れて、
Bドライブにシステムディスクを入れるんだよね。

>>754
Dockerfileのビルド時に--network=host入れたらビルド出来たわ…

Docker哲学とかどうでもよすぎてゲロ吐きそう