[過去ﾛｸﾞ] Docker Part3 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
128(5): 2019/11/10(日)10:24 ID:xpJeV64E(1/3) AAS
>>122
VMに対して、Dockerは「共通の部分のリソース(Kernel)は
共通で使ったほうが良くない？VMだとCPU上にほとんど変わらん
Linux Kernel複数動いとるやん！」
という提案にそうだねと思ったから使ってる。
メモリとCPU大量につみゃいいじゃん。て言われりゃ、あぁそうだね。
俺はやだけどね。ってだけだ。
たまに、また新しいもの覚えなきゃいけないんすか・・
とか言われることあるよ。そんなの右翼、左翼の違いと一緒じゃないの？
社内でVM陣営(右派)とDocker陣営(左派)に別れちゃったり。
新しもの好きの奴らのほうがハイパフォーマーが多いので
VM陣営は化石になっちゃうんだけどな。
安定度とかはどうなのよって言われると、そりゃVM陣営（保守派）。
でも、新しもの好きはそういうの気にしない。なんとかなる！とか
思っちゃってる人ばっかだから:p
129(1): 2019/11/10(日)10:24 ID:VIhv4B2u(4/27) AAS
>>124
> でもそれって担当者の退職が一番の原因じゃね？
担当者の退職は避けられない
ってかインフラでは属人性をなくせ、暗黙知を減らせって
やってきただろ？そのための道具だったはずなのに。
属人性は無くなったが、最低限必要な技術レベルと経験が高くなりすぎてしまって
代わりになる人間を見つけるのが難しくなってしまったんだよ
構成が複雑になりすぎて、新しく入ってきた人がシステムを
理解するまで時間がかかる。それって属人性と対して変わらないから。
低い知識で十分だが、やってることはわかっても、それがなんのために必要なのかわからないし
書いてないことが多すぎて謎に包まれてる。
これが
ちゃんと書いてあるしやってることはわかるはずだが、そのためには高い知識が必要で
高い知識がないければ、意図が読み取れず、結局何をやってるのかわからない。
コレに変わっただけ。
130(5): 2019/11/10(日)10:25 ID:KPJdW8/s(3/19) AAS
>>126
いやいや、開発「機」を作るんだろ？先ずお客さんからどのようなサービスを作るのかヒアリングして
要件定義してそれに相応しいOS、パッケージなんかを決めて本番機を念頭に「開発機」を作る。
当然VM。その後に、実際の開発を行い、
開発機の手順なりスクリプトなりをインフラの人に渡して本番機を作ってもらう。
だから開発機の構築は本番機の構築の事前準備になる。これをDockerで作っちゃったら手順も
違うし環境も違うわで、そのノウハウが全く本番機に生かせなくなる。
131: 2019/11/10(日)10:25 ID:KPJdW8/s(4/19) AAS
>>125
>色々考慮しないといけなくなる。ディストロアップデートしたら、そのパッケージで動くか検証したり
>パッケージの新しいバージョンを使う時、それが今のディストロでちゃんと動くのか検証しなくちゃいけない。
これは別にDocker使うからやらなくて良いって話にはならないだろ？
132: 2019/11/10(日)10:27 ID:KPJdW8/s(5/19) AAS
>>127
>失敗すると次から次へとマシンが落ちていって制御不能になって
>最悪データの損失が発生する。
こんなのVMに対するデメリットでしか無いじゃん。
VM使って在るゲストOSが落ちたから別のゲストOSも使えなくなってEXSi全体が落ちる
（或いはAmazonECS全体が落ちるとか）訊いたことないわ。
133(1): 2019/11/10(日)10:31 ID:VIhv4B2u(5/27) AAS
>>128
VM vs Dockerとなってる時点でやばい
VMとDockerは組み合わせて使うもの。
Dockerコンテナを何個起動したって、マシン台数が
増えることを意味しないからパフォーマンスはあがらないんだよ。
パフォーマンスをあげるには、一台のスペックをあげるか台数を増やすしか無い。
一台のスペックあげるのは当たり前ですぐに限界が来るので
結局台数を増やすことでシステム全体のパフォーマンスをあげるわけだが
そのためには物理マシン数を増やすってのはクラウドで簡単に台数を増減できる時代の今
大変なだけなので却下するとして、じゃあなにか＝仮想マシン（VM）でしょ？
結局仮想マシンは使うってことは大前提なはずなんだが？
Dockerを使う理由は仮想マシンと別にあって、
パフォーマンスを上げる＝仮想マシンを増やす
増やした仮想マシンに配布しやすくする＝Docker
という結論になるはずなんだが？
134: 2019/11/10(日)10:33 ID:VIhv4B2u(6/27) AAS
>>130
> いやいや、開発「機」を作るんだろ？
開発「機」を作る事自体を否定してるんじゃなくて、
Dockerを使って開発「機」を作るってのがおかしいと言ってるの
Dockerは機械はどれでも構わないってやつなんだから
機械は機械で別に設計しろ。それはDockerの役割じゃない。
135(1): 2019/11/10(日)10:34 ID:VIhv4B2u(7/27) AAS
>>130
あんたの意見のすべてが「ズレてる」のは
Dockerの役割がわかってないからだよ。
136(2): 2019/11/10(日)10:36 ID:VIhv4B2u(8/27) AAS
なるほどそうか。>>130の話には「開発ソフトウェア」が抜けてるんだわ
Dockerの役割は「開発ソフトウェア」に関わる話なのに
>>130にはその話が抜けてるから、Dockerがでてこない。
（出てきてるように見えるのはDockerの間違った使い方）
137(2): 2019/11/10(日)10:37 ID:VIhv4B2u(9/27) AAS
連投すまんね
>>130の
> その後に、実際の開発を行い、
> 開発機の手順なりスクリプトなりをインフラの人に渡して本番機を作ってもらう。
ここやね。インフラの人に渡すものはコマンド一つ程度でよくなるのがDockerだよ。
138(1): 2019/11/10(日)10:37 ID:KPJdW8/s(6/19) AAS
>>128
いやいや保守派がどうのと言うより費用対効果だろ？
学習コストを上回る効果が得られるなら、当然やる。
めちゃくちゃに忙しいエンジニアが己の持ち時間を削って勉強するんならそれ相当の
見返りを期待するわ。
>メモリとCPU大量につみゃいいじゃん。て言われりゃ、あぁそうだね。
そういうこと。一方でサイボウズの例みたいに1つのサービスのために
1000台のコンピュータが動いていると言うなら、考慮の余地は無いから
鳴るべく軽いコンテナベースに、と言うことにはなるだろうね。
>>129
これは単に分かりやすかった筈のOSの仮想化技術、アプリケーションの仮想化技術を
「コンテナ型」とか分かりにくく言い直しただけ。
別段高い知識でもなんでもない、ワザとか何か知らないけど分かり難くしている。
139(1): 2019/11/10(日)10:40 ID:VIhv4B2u(10/27) AAS
>>138
> これは単に分かりやすかった筈のOSの仮想化技術、アプリケーションの仮想化技術を
> 「コンテナ型」とか分かりにくく言い直しただけ。
まだ「個」でしか見えてないｗ
Kubernetesでは「個」で考えるのではなく「群」を作るのが前提のものだから
難しくなってるって話をしてる。
140(2): 2019/11/10(日)10:40 ID:KPJdW8/s(7/19) AAS
>>136
ん？「実際の開発を行い」と書いているだろ？
フルスタックのエンジニアなんだから、インフラも開発も全部見るのが普通だろ？
というか、君は見ないのか？
141: 2019/11/10(日)10:41 ID:KPJdW8/s(8/19) AAS
>>139
すまんね。Dockerの話をしてるのかと思ったよ。
142(1): 2019/11/10(日)10:44 ID:VIhv4B2u(11/27) AAS
「個」をいくつか作っていって、それを組み合わせていけば
そのうち「群」になりますよね？っていうのが従来の発想で、
まず「群」を作りましょう。「個」はその中に生まれていきます。
っていうのがKubernetes。
最初から「大群」になるのがわかってるならKubernetes一択なんだが
「個」をちょこちょこ作っていって「群」まで育てばいいなぁの世界だと
いきなり「群」を作るのは、想定外の話なんだよ。
なんでこの段階からそんなことまで考えなければいけないの？のオンパレードになるから
そういうのをやったことがある人でないとKubernetesは使いこなせない。
143(1): 2019/11/10(日)10:47 ID:KPJdW8/s(9/19) AAS
>>137
この話で行くなら、既にDockerが本番環境でも利用される事を前提にしないと
話が進まない、と言うか導入しようぜ、とならない。
>>123がいつの間にかこんな事言っているけど、ちょっと前までは、>>71みたいに
あくまで開発者の環境という話だったはずだが？
144: 2019/11/10(日)10:49 ID:VIhv4B2u(12/27) AAS
>>140
両方見るにしても分けて考えないといけない。
両方見てるだけで、一緒にしてるわけじゃない。
分離して考えて、インフラはインフラのことだけ考えればいい
（利用者などの要件に応じて、どんな規模のインフラを作るか？という話）
そのインフラに、アプリを配布するときに渡す「アプリ開発者が渡す手順書」
（どんなパッケージをインストールするのか？）
っていうの少なくて済みますよっていうのがDocker
インフラ担当はインフラの性能のことだけ考えればいいし、
（アプリ開発者が渡した）アプリを動かす手順書見て
四苦八苦しながらアプリ動かしてみせる！のはインフラの仕事じゃない
145(1): 2019/11/10(日)10:51 ID:KPJdW8/s(10/19) AAS
>>136>>126>>135
スゲー不思議なんだけど、こういうレスが出る奴ってのは
自分達が開発したソフトウェアが本番環境で動作する事を
全く考慮せずに開発してるって事？
そのほうがズレてると思うが？
てか、そんなやり方で環境の差異とかで困った事は無いの？
146(1): 2019/11/10(日)10:53 ID:VIhv4B2u(13/27) AAS
>>143
だからDockerを本番環境で使うんだよｗ
お前は今どちらの立場で考えてる？
インフラ担当の立場だろう？
お前が気にするのは、インフラの性能と
Dockerコンテナが動くための環境を用意することだけだ
作ったインフラで開発したアプリを動かす、あれやこれやの
パッケージインストール作業の仕事はしなくていい
（↑従来はインフラの仕事だった所）
なぜなら開発アプリをDockerイメージにしておけばコマンド一つとか
設定ファイルにイメージのアドレスを書き込めば終わるから
147(1): 2019/11/10(日)10:58 ID:VIhv4B2u(14/27) AAS
>>145
> 自分達が開発したソフトウェアが本番環境で動作する事を
> 全く考慮せずに開発してるって事？
> てか、そんなやり方で環境の差異とかで困った事は無いの？
困ったことはあるよ？ 以前は環境の差異で手元の開発機と
本番環境で微妙にパッケージのバージョンが違ったりして
動かなかったり、動かすために本番環境に手を入れるのが大変だった。
Dockerを導入すると、そういう困ったことが無くなるって話
そこを理解すべきところなのに、Dockerの役割勘違いしてるから
それが解決されるってことがわかってないんだろ？
Dockerを導入した場合、自分達が開発したソフトウェアから見ると
本場環境の違いっていうのは、単にインフラのスペック・能力、インフラの構成が違うだけにしか見えない。
（インフラの構成が違うっていうのは、一台にアプリとデータベースサーバーが
同居してるかというレベルの話で、アプリは普通に最初から分離できるように作るので）
148: 2019/11/10(日)11:00 ID:VIhv4B2u(15/27) AAS
ちなみにKubernetesはインフラの構成の一つなのでインフラの話で
Dockerはアプリの配布方法の話なのでアプリ開発の話
KubernetesとDockerは組み合わせて出てきてくるから
同じ層の話だと勘違いする人が多いけど、別だから。
149(1): 2019/11/10(日)11:03 ID:KPJdW8/s(11/19) AAS
>>146
いやいや、何でそうなるのさ？インフラ担当な訳ないだろ？
俺の書込みを見て俺がインフラ担当だと思うのなら、
本当に開発の事しかわからない、俺にとっての不思議ちゃんだわ。
マジでインフラを全く考慮せずに開発するのね。
150(1): 2019/11/10(日)11:05 ID:VIhv4B2u(16/27) AAS
>>149
逆に聞くがお前はインフラの何を考慮してるんだ？
Docker導入したら、インフラは「性能が違うマシン」程度しか
考慮しなくて良くなるんだが、
お前は何で困ってるんだ？
151(1): 2019/11/10(日)11:07 ID:KPJdW8/s(12/19) AAS
>>150
え？困ってるなんて一度も書いてないが？
152(1): 2019/11/10(日)11:08 ID:VIhv4B2u(17/27) AAS
>>151
困ってないなら、インフラのことを考慮することないじゃん。
エンドポイント（例えばデータベースの接続先）のアドレスはどこか？
程度しか考慮しなくていいだろ。その先がどういう構成になってるか
アプリから知る必要はない。
153: 2019/11/10(日)11:11 ID:VIhv4B2u(18/27) AAS
念の為いっておくが、仕事全体としてインフラのことを考慮してないんじゃなくて、
アプリ開発者の帽子をかぶってるときには、インフラのことを考えなくていいって意味だぞ
インフラ技術者の帽子をかぶってるときは、逆にアプリのことは考えずにインフラのことを考える
一人で担当してるからって、ごっちゃにして考えるなよｗ
154: 2019/11/10(日)11:11 ID:KPJdW8/s(13/19) AAS
>>147
>Dockerを導入すると、そういう困ったことが無くなるって話
>そこを理解すべきところなのに、Dockerの役割勘違いしてるから
>それが解決されるってことがわかってないんだろ？
>本場環境の違いっていうのは、単にインフラのスペック・能力、インフラの構成が違うだけにしか見えない。
じゃあやっぱり、Dockerで開発「機」を作ってるじゃん。
155(1): 2019/11/10(日)11:12 ID:xpJeV64E(2/3) AAS
>>133
>>>128
>VM vs Dockerとなってる時点でやばい
>VMとDockerは組み合わせて使うもの。
ちょっとまてw
Dockerを複数動かすより、VMを複数立てていったほうが良いだろ？
ってのが、最初の問いかけじゃなかったっけか？
156(1): 2019/11/10(日)11:13 ID:VIhv4B2u(19/27) AAS
それをどう読めば開発「機」の話になるんだ？
わけがわからん。
> てか、そんなやり方で環境の差異とかで困った事は無いの？
↑ってお前が聞いたんだから、
お前は困ったことがあるんだろ？
って思ったら困ったこと無いって言うしｗ
157: 2019/11/10(日)11:13 ID:KPJdW8/s(14/19) AAS
>>152
いやいや、俺が困ってるとか、俺が考慮するとかじゃなくて、
君達何を考えてるのかね？と言う話だったんだが。
158(1): 2019/11/10(日)11:16 ID:KPJdW8/s(15/19) AAS
>>156
わけわかんねー。
本場環境の違いっていうのは、単にインフラのスペック・能力、インフラの構成が違うだけにしか見えない。
といっているのは開発したときの環境と、本番環境の差がなくなったからだといっているんだろ？
で、その開発環境は自分で作ったんだろ？要件にあわせて。
159: 2019/11/10(日)11:16 ID:VIhv4B2u(20/27) AAS
>>155
> Dockerを複数動かすより、VMを複数立てていったほうが良いだろ？
だから、VMは（システム全体としての）性能を上げるために
複数立てるんだよ。
Dockerは、その性能の話と全く関係ない。
仮想マシンだろうが物理マシンだろうが関係なく、
（Dockerサーバーが動いてる）そのマシンに簡単に配布できますよ。
従来インフラ担当者に渡していた
「アプリを正しく動かすための手順書」はいらなくなりますよ。
インフラ担当者が四苦八苦してトップページ表示までたどり着く作業は
いらなくなりますよ。っていうのがDockerを使う理由だから
160: 2019/11/10(日)11:19 ID:VIhv4B2u(21/27) AAS
>>158
> といっているのは開発したときの環境と、本番環境の差がなくなったからだといっているんだろ？
「差がなくなった」とは何の話をしてる？
どうも、全く同じマシンを手に入れた。って言ってるように見えるんだがｗ
開発環境と本番環境が違っていても（Dockerサーバーさえ動いていれば）
その環境の差を気にしなくていいと言ってる。
差がなくなったのではない。差を気にしなくてもいい。
（Dockerサーバーの上だけを見れば、差がなくなったとも言えるのは正しいが）
> で、その開発環境は自分で作ったんだろ？要件にあわせて。
開発環境なんて手元のMacとかだろｗ
まあ、別にどこでもいいがね。Dockerサーバーさえ動いていれば
Dockerイメージにした自分が作ったアプリは問題なく動くので。
161(2): 2019/11/10(日)11:24 ID:VIhv4B2u(22/27) AAS
なんかもう、根本からズレてる気がするんだよなｗ
なんか本番環境と同等の開発環境を作って
そのマシンにリモートでログインしてアプリを開発する
みたいな発想をしてるように見える
まあ、昔はそれをやっていたので人のこといえんけどな
本番環境サーバーを模した開発環境サーバーにSSHログインして開発してた
違うねんｗ 今の開発はそうじゃないねんｗ
どこでもやれるねん。そんな専用環境なんか作らなくて良くなったんだよ。
Dockerのおかげでね。手元の開発環境がMacであろうとWindowsであろうと
本番環境とどれだけ性能などの差があろうと
（開発環境、もしくは本番環境）のDockerサーバーの上では
性能の違いがあるだけで同じように見えるんだよ。
162: 2019/11/10(日)11:26 ID:lF4IP4va(1) AAS
まだサーバーを家畜ではなく
ペットのように可愛がってるおじさん？
163(1): 2019/11/10(日)11:28 ID:KPJdW8/s(16/19) AAS
>>161
>なんかもう、根本からズレてる気がするんだよなｗ
>なんか本番環境と同等の開発環境を作って
>そのマシンにリモートでログインしてアプリを開発する
>みたいな発想をしてるように見える
発想をしている、では無い。
これに対する利点を述べてくれ、とずっと要っているのだが？
それに対する利点に合点がいかなければ、その環境を例に挙げて
反論を述べている。・・・すると、おかしな勘違いする奴がいる。
164(1): 2019/11/10(日)11:30 ID:xpJeV64E(3/3) AAS
>>161
俺、Docker便利だよ派だけど、
あなたの言い分だと、ID:KPJdW8/sが言う、
VMでいいじゃん。に対する反論になってなくない？
>違うねんｗ 今の開発はそうじゃないねんｗ
>どこでもやれるねん。そんな専用環境なんか作らなくて良くなったんだよ。
>VMホスト環境のおかげでね。手元の開発環境がMacであろうとWindowsであろうと
>本番環境とどれだけ性能などの差があろうと
>
>（開発環境、もしくは本番環境）のVMホスト環境の上では
>性能の違いがあるだけで同じように見えるんだよ。
165: 2019/11/10(日)11:46 ID:DMFKw9iR(1) AAS
仮想マシン配布より
プライベートレジストリでDockerイメージ配布の方が楽だし
速いし
同じCPUアーキテクチャならどのLinuxディストリでも動く
Nested VirtualizationのないAWSにもそのまま持ち込める
そもそも仮想マシンには
予めPHPとかインストールされたベースイメージがない
そこから自分でやるのはちょっとめんどくさい
166: 2019/11/10(日)11:47 ID:VIhv4B2u(23/27) AAS
>>164
どの言い分に対するレスなのか知らんけど、
俺は最初から、仮想マシン（VM）とDocker（コンテナ）は
組み合わせて使うと言ってる。
Dockerがあれば仮想マシンはいらないとか言ってない。
どういう反論をすれば良いんだ？
使い方が違うとしか言いようがない。
VM作るだけだとアプリの配布が面倒だろって言えばいいのか？
VMだけじゃ"足りない"だろ。としか言えんぞ？
167(2): 2019/11/10(日)11:52 ID:VIhv4B2u(24/27) AAS
>>163
> これに対する利点を述べてくれ、とずっと要っているのだが？
利点？ お前、客から要件聞いて、そこから開発環境
（専用の開発サーバー）作るお仕事をしてますって言ってるじゃん？
俺からすればなんでそんな事してるんだ？って言う話だから
利点と言うなら、要件聞かないと開発環境が作れませんなんてことにはなりません。
開発環境を作るコストが減りますといえばいいのかな？
開発環境だけの話をしてるのが謎だけど
Dockerを導入すれば（開発環境に限らず）どんな環境にでも容易に変更できます。
"本番環境"を要件（負荷等）に応じて、自社サーバーにするのも
クラウドにするのも、環境を用意に変更できます。
（という話の環境の中に開発環境も含まれてる）
168(1): 2019/11/10(日)11:59 ID:KPJdW8/s(17/19) AAS
>>167
>>130実際の開発を行い
>>137実際の開発を行い
>>140実際の開発を行い
何度も書ているんだが、日本語読める？
てか、お前、馬鹿なんだから俺の質問にレスすするな。
おかしなレッテルの上で話を進めるから訳がわからない。
他の人はまあ、読んでると思うけど、お前は全部的を外している。
169(2): 2019/11/10(日)12:15 ID:KPJdW8/s(18/19) AAS
>>142
何か、話が飛躍しすぎている気がする。流行りだし>>128が言うようにVMは
やがて鯖側で化石になるだろうから、Dockerで運用してみようかな？
と思わない事も無い。でもこんなにデカイのは要らないんだよなぁ・・・
2台のWeb or Socketサーバーを平日の繁忙時間だけ3台にしてくれるような
ツールは無いですかね？
170: 2019/11/10(日)12:21 ID:VIhv4B2u(25/27) AAS
>>169
DockerとKubernetesの話は別だ。分けて考えてくれ。
Dockerは配布が楽になる。どこでも動かせるようになる。
そのどこでもの中の一つにKubernetesで構成した大規模なインフラも含まれるってだけ
開発したアプリがどこでも動かせるから、手元のMacでも
本番環境の物理マシンでも仮想マシンでもKubernetesで作った
クラスタ環境でも簡単に動かせるってだけ。
別にKubernetes使うのは必須じゃない。Kubernetes使ったからって
簡単になるもんでもない。逆に難しい。Kubernetesが生きるのは大規模な本番環境であって
2台のWeb or Socketサーバーを平日の繁忙時間だけ3台にしてくれるような
ツールなら、クラウドの仮想マシンオートスケールの設定でもして
その上で「Dockerコンテナを」動かせばいい。
というふうに組み合わせて使うんだよ・・・
Dockerは配布が簡単になるだけのものなんだから
171: 2019/11/10(日)12:22 ID:VIhv4B2u(26/27) AAS
>>168
で？
172: 2019/11/10(日)12:27 ID:VIhv4B2u(27/27) AAS
>>169
> 流行りだし>>128が言うようにVMは
> やがて鯖側で化石になるだろうから
上でも言ってるけどならんよ。
（Docker）コンテナはいくら数を増やしたって
システムの性能は上がらないんだから。
システムの性能を上げるために必要なのは
（マシンスペック強化は別として）VMの台数を増やすこと
まあクラウド側の提供として、コンテナを動かすための環境を提供して
その環境ごとに課金するタイプなら見た目上、VMはなくなったように見えるが。
でもVM単位の課金か、コンテナ環境単位の課金かの違いになっただけやねｗ
173(5): 71 2019/11/10(日)22:00 ID:hNrQ9NRe(1) AAS
亀です。
軽くレスおってるだけで提言なんだけど、配布とか楽なのはわかる。
compose upすればいいだけ。すごく楽。
だけど保守には向かないんだよ。docker自体にログがドカドカ出す機能はないし、中のアプリケーションから何らかのものを出さないといけない。
dockerのネットワークもEsxiとかに比べたら柔軟に構築できないし、障害対応に当たるメンツの教育コストも考えなきゃいけない。
立ち上げだけ上手くいくテスト環境にはいいけど本番環境はやっぱり難しいと思う
174(2): 2019/11/10(日)23:34 ID:KPJdW8/s(19/19) AAS
>>173
>docker自体にログがドカドカ出す機能はないし
ログ自体はdocker-compose logs -f で見れるじゃん。
>dockerのネットワークもEsxiとかに比べたら柔軟に構築できないし
これやね。
Dockerは何故ルーター噛ます事がデフォルトになっているのか？
DD-WRTとかCiscoのXRVとかをそれこそ「コンテナとして」提供するならまだしも、
（ESXiはそれが出来る）勝手にルーター込みで作るとかマジで止めて欲しいわ。
アクセス自体もOSによっては「名前の解決を行っています」に1秒くらいかかって遅い気がする。
>立ち上げだけ上手くいくテスト環境にはいいけど本番環境はやっぱり難しいと思う
これだと、結局Dockerは開発者のおもちゃ程度じゃん。
175(2): 2019/11/11(月)00:21 ID:0/0z68zi(1/6) AAS
>>173
>docker自体にログがドカドカ出す機能はないし
いつものなにか勘違いしてる系だよｗ
「あなたが作った開発アプリのログ出力機能」を
Dockerのせいにするのはおかしいと気づかなきゃいけない。
開発アプリのログを出す責任は、アプリ開発者にあるでしょ？
標準出力と、標準出力エラー出力（あとファイル）を出せるんだから
ドカドカだすのはアプリ開発者の仕事だよ
> 立ち上げだけ上手くいくテスト環境にはいいけど本番環境はやっぱり難しいと思う
そういう基本を理解してない人が、間違った話をした上で、難しいと言っても説得力がない
>>174
> Dockerは何故ルーター噛ます事がデフォルトになっているのか？
ルータを噛まさないで可搬性が作れるなら、提案してみれば？
ともかく、どんなサーバーでも動かせるということは、
そのサーバーで他のコンテナが動いてる可能性もある。
だからアプリがポート番号決め打ちだとかぶって困るよね。
つまりDocker自身がポート番号の変更機能を持ってなきゃいけないんだよ。
アプリ側で変更可能にしておくのが常識だけど、それだとアプリごとにやり方が異なる
そういうのをコンテナとしてまとめて、Dockerが可搬性をもたせると主張してるのだから
Dockerの仕事になる。そこでルーティング機能がでてくる。
176(1): 2019/11/11(月)00:42 ID:KWmDlLck(1/4) AAS
>>175
>ルータを噛まさないで可搬性が作れるなら、提案してみれば？
ESXiのゲストOSは（AmazonのEC2も）ルータなんか噛まさないだろ。
177: 2019/11/11(月)01:06 ID:0/0z68zi(2/6) AAS
>>176
なんでアプリの可搬性と関係ない
ゲストOSの話なんか出てくるの？
どこでも（俺の手元のMacでも）そのゲストOSとやらが動くとでも言うのか？
178(1): 2019/11/11(月)01:07 ID:0/0z68zi(3/6) AAS
それにゲストOSだけ動いてもしょうがないんだけどなｗ
アプリがなければただのOS
179: 2019/11/11(月)04:37 ID:KWmDlLck(2/4) AAS
>>178
お前のレスは兎に角、的外れ。
それしか感想は無い。
俺以外にもそう思っている奴はいる筈
180: 2019/11/11(月)08:39 ID:0/0z68zi(4/6) AAS
的外れと言うばかりで、具体的な指摘なし
181: 2019/11/11(月)09:43 ID:KWmDlLck(3/4) AAS
それは馬鹿にしゃべってもしょうがないから♪
182: 2019/11/11(月)09:52 ID:0/0z68zi(5/6) AAS
という書き込みを見た人がどう思うか？
反論できな人という烙印だよ
183: 2019/11/11(月)10:17 ID:KWmDlLck(4/4) AAS
一向に構わんね。
妄想して変なレッテルを前提に、判っても居ない癖に
禄でもない話する奴に教えてあげる必要は無い。
俺さえ分かっていればそれで良い。
184: 2019/11/11(月)11:41 ID:rpyMzwNX(1) AAS
>>120
ライブラリーやヘッダの依存関係が衝突するツールチェーンの環境作ってビルドするのにいいよ(´･ω･`)
例えば、MinGW-w64クロスツールチェーンとMinGW向けのビルドをする、llvmクロスツールチェーン(´･ω･`)
185: 2019/11/11(月)11:48 ID:0/0z68zi(6/6) AAS
本番環境でも開発環境でも
同じDockerイメージを使えるのは便利だね
186(1): 71 2019/11/14(木)05:02 ID:pJpBijFV(1) AAS
>>175
アプリケーションじゃなくてシステム運用保守の点でdocker自体の挙動の話。
>>174
すまん。logs -fは忘れていた。。。
もしdockerで管理するんだったらSNMPはホスト側で見とくんか？
あとグラフィカルな管理をお願いされたらportainerとかは限界あるけどみんなどう考えているんだ？
187(1): 2019/11/14(木)05:17 ID:UYzAkhIS(1) AAS
>>186
Dockerで作ったものはアプリだってわかってるか？
お前が言ってるのは、exeを実行した時のSNMPをどうすればいいんだとか
いうわけがわからん話をしてるんだが
お前が作ったアプリがあるだろ？そこに単にDLLをくっつけただけ。
アプリが動いているかを確かめたいなら、
そのアプリに対してヘルスチェックでもすればいいだろ
188(1): 2019/11/14(木)22:51 ID:5w0W9exo(1/2) AAS
Ubuntu18.04でAndroid版Mozcのapk作ろうと思ってるんだけど､
なんでDockerが必要なの?
C++だけで出来ないの？
Build Instructions
How to build Mozc in Docker: Android, NaCl, and Linux desktop builds.
How to build Mozc in OS X: OS X build.
How to build Mozc in Windows: Windows build.
189: 2019/11/14(木)23:02 ID:5J9mUBHW(1/2) AAS
>>188
Dockerの中にまとまってる「構築手順」を
お前がそのまま実行すればできるよｗ
構築が簡単にできるように
Dockerでビルド環境を整えてるんだろ
そういうときに使う道具なんだから
190: 2019/11/14(木)23:03 ID:5J9mUBHW(2/2) AAS
つくづくDockerはアプリ開発者のための道具だってわかるよなｗ
仮想マシンの代替だと思ってると、こういう使い方が思いつかない。
191: 2019/11/14(木)23:40 ID:5w0W9exo(2/2) AAS
なんか知らんが､いっぱいインストールして
環境ぐちゃぐちゃにならないように､Docker使ってるの？
まあ､Dockerインストしてやったほうが楽なのかな？
192: 2019/11/15(金)01:11 ID:v0WAyrLU(1) AAS
Docker自体は、デーモン常駐させるのにあんまし向いてないような気がする…
193: 2019/11/15(金)01:26 ID:B8H5uf6m(1/2) AAS
ちょっと質問なのですが､
Dockerの中でやったほうがいいというのはわかったのですが､
mozc.pyというのはどこにあるのですか？
ファイルが見当たりません
外部ﾘﾝｸ[md]:github.com
194: 2019/11/15(金)01:40 ID:OT68/gV4(1) AAS
海のもずくとなったのだ
195(1): 2019/11/15(金)01:57 ID:B8H5uf6m(2/2) AAS
ありました､すみません｡
mozc-master/srcにありました｡
Docker使わずにPythonコマンドうったら
$ python build_mozc.py gyp --target_platform=Android
INFO: Generating version definition file...
INFO: Version string is 2.23.2815.103
CRITICAL:
==========
CRITICAL: GYP does not exist at /home/user_name/mozc-master/src/third_party/gyp/gyp_main.py.
Please run "git submodule update --init" to check out GYP.
If you want to use system-installed GYP, use --gypdir option to specify its location.
e.g. "python build_mozc.py gyp --gypdir=/usr/bin"
CRITICAL:
==========
となりました｡
どうすればいいですか？
196: 2019/11/15(金)04:45 ID:E8h29lNR(1) AAS
どっかーとかんけいないので
どっかーにいってください
197(1): 2019/11/15(金)08:24 ID:ijiYYYu1(1/2) AAS
>>187
相変わらずズレた事言ってんなコイツは・・・。
198(1): 2019/11/15(金)08:26 ID:KYbcJ9F4(1/3) AAS
>>197
じゃあお前が反論しろ
何も言い返せないのにグチグチレスだけしなくていい
199: 2019/11/15(金)10:09 ID:ijiYYYu1(2/2) AAS
>>198
ズレている、が反論以外の何者でもない。
>お前が作ったアプリがあるだろ？そこに単にDLLをくっつけただけ。
>アプリが動いているかを確かめたいなら、
>そのアプリに対してヘルスチェックでもすればいいだろ
何を言ってるんだお前は・・・。
200: 2019/11/15(金)10:36 ID:KYbcJ9F4(2/3) AAS
なるほど。その内容が反論できる限界ってわけだ。
201: 2019/11/15(金)10:41 ID:Se8qUwOH(1) AAS
>>195
そういうふうにならないためにdockerがあるんですがね
202: 2019/11/15(金)16:49 ID:KFqjiKrH(1) AAS
Docker Hub から、好きなコンテナを探せば良いだけだろ
そしたら、その中に環境一式が入っている
203: 2019/11/15(金)20:07 ID:KYbcJ9F4(3/3) AAS
好きなコンテナ探して使うとか、そういう使い方じゃないよ。
Docker Hubのコンテナの正しい使い方は
1. Docker公式が用意しているものを使う
2. ディストリ公式が用意してるものを使う
3. 何らかのアプリであれば、そのアプリの公式が用意してるものを使う
それ以外は、参考イメージに過ぎない。
そんな環境が入ってるかもしれないとか思って探すものじゃないｗ
204: 2019/11/16(土)04:47 ID:SNHSHops(1/2) AAS
$ sudo docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
<none> <none> aaaaaaaaa 10 minutes ago 5GB
となってしまってるのだが､
$ sudo docker run -it --name nonedocker none /bin/bash
だと起動しない｡
ImageID指定して起動する方法ないの？
205(3): 2019/11/16(土)05:07 ID:SNHSHops(2/2) AAS
出来ました
なぜnoneになってしまってたのだろう･･･
あと､ググっても出てこないのだが､
docker内でsudo apt install unzipやろうとしても
パスワードが分からなくて出来ません｡
デフォルトパスワードってなんですか？
パス設定してないのだが
206: 2019/11/16(土)06:01 ID:c+cyy5cT(1/3) AAS
>>205
docker内で実行するのではなく、
Dockerfileを書きましょう。
207(1): 2019/11/16(土)08:21 ID:/wQVztcY(1) AAS
そういえばみんな手書きでDockerファイル書いてる？
バッシュヒストリーとか行動をDockerファイル化するツールとか存在するの？
208: 2019/11/16(土)08:26 ID:c+cyy5cT(2/3) AAS
手作業はたいてい試行錯誤するのにその内容がそのまま使えるわけ無いだろｗ
イメージの構築手順をコード化できるのがDockerのいいところなのに
必要なとこだけメモっとけよ
209(1): 2019/11/16(土)08:35 ID:aXw+ZntQ(1) AAS
>>205
元々UbuntuとかDebianベースのDockerイメージにはsudoさん入ってなくね？
Dockerコンテナ内での実行ならexecする時にユーザー変更出来るからパスワードもない
rootユーザーなら須藤さんなしでaptを実行できるが
docker execで実行してもコンテナを消した時に消える
コンテナって、儚い
普通はベースイメージに何か追加するときはDockerファイルに書いて
Dockerfileを配布か
CIツールにDockerイメージのビルドとレジストリへのプッシュをさせて
レジストリのURLを配布
210: 2019/11/16(土)08:41 ID:c+cyy5cT(3/3) AAS
>>209
execのときにユーザー変更なんてあまりしないなぁ。
普通はユーザー変更するならDockerfileのUSERで変更する。
たまにアプリがrootでは動かないようになってて
そういうときにUSERで一般ユーザー権限になるぐらいだな
そういうイメージをメンテナンスするときぐらいか？
execでユーザー変更するのは。
ともかく、またDockerイメージをVMの代わりに使おうとしてるような臭いがするが
DockerっていうのはDockerfileを使ってイメージを作るものだよ
アプリの配布を楽にするために、アプリにユーザーランドを全てくっつけるために使う。
sudoが必要になることはまず無い。
211: 2019/11/16(土)09:28 ID:KYjs1Plb(1) AAS
>>205
コンテナイメージは何をお使いですか？
sudoなしで試してみるとどうですか？
212(1): 2019/11/16(土)15:07 ID:M11z94Ko(1) AAS
管理者は、CentOS なら、ユーザーをwheel グループに追加するのでは？
visudo で、/etc/sudoers を開いて編集するとか、間違えると恐ろしい手順！
Debian 系は、知らないけど
>>207
ヒストリーは、head .bash_history と入力すると、
以下のように行区切りで、コマンドが表示される
だから、こういう単純なテキストファイルを作って、Docker に含めて、コピーすれば？
man unzip
exit
man gunzip | less
exit
213: 2019/11/17(日)16:34 ID:DepsKVcB(1) AAS
>>212
別にlivebootで /etc/sudoers あたりをいじればいいでしょ。
214(9): 2019/11/18(月)02:59 ID:fwqLgOPw(1/5) AAS
これやってMozc/Androidをインストールしようとしてます｡
外部ﾘﾝｸ[md]:github.com
Set up Ubuntu 14.04 Docker container
$mkdir ubuntu14.04 && cd ubuntu14.04
$curl -O 外部ﾘﾝｸ:raw.githubusercontent.com
$sudo docker build --rm -t $USER/mozc_ubuntu14.04 .
$sudo docker run --interactive --tty --rm $USER/mozc_ubuntu14.04
をやりました｡
次に､
$sudo docker run -it --name docker1 012345abcde /bin/bash
でDockerにコンテナを作り､ログインしました｡
Build Mozc for Android:
$python build_mozc.py gyp --target_platform=Android
$python build_mozc.py build -c Debug android/android.gyp:apk
をやりました｡
mozc.pyというファイルがないです｡
ビルド出来ません｡どうしたらいいですか？
ちなみにwget使えないのでファイルダウンロードできません｡
apt installも出来ません
215: 2019/11/18(月)05:11 ID:526otgY3(1/2) AAS
> $sudo docker run -it --name docker1 012345abcde /bin/bash
> でDockerにコンテナを作り､ログインしました｡
そんな手順があるわけない
216: 2019/11/18(月)06:33 ID:526otgY3(2/2) AAS
スレ違いだしリンク先を読む気はさらさらないが、
Dockerを使ったビルドでやることは決まってる。
1. Dockerのインストール。Dockerを使う以上これは自分で準備する必要がある。
2. ビルドスクリプトを動かす言語、つまりその場合はpythonを準備する必要がある。
3. ビルドスクリプト。ソースからのビルドならソースに付いてるだろ。
以上。準備するのはこれだけ。
まともなビルドスクリプトであればDockerを直接触ることはない。
せいぜい不要になったものを削除するぐらいだろう
ビルドに必要なものは勝手に準備してくれる。
Dockerコンテナの中に入って作業することなど無い
217: 2019/11/18(月)07:56 ID:ESYqS5lO(1/2) AAS
>>214
プログラミング少年？
子供には優しく教えてあげよう。
>Build Mozc for Android:
>
>python build_mozc.py gyp --target_platform=Android
>python build_mozc.py build -c Debug android/android.gyp:apk
って書いてあるよ。
中学生以上なら頑張って英語読もうね。
218: 2019/11/18(月)07:57 ID:ESYqS5lO(2/2) AAS
おっと、俺は日本語を読んでなかった。
手順にコンテナに入れなんて書いてないよ。
219(1): 2019/11/18(月)10:46 ID:C4AZd6Pu(1) AAS
Dockerの利点のlibに依らないってスタティックビルドすりゃええやんって気もする
220(1): 2019/11/18(月)10:54 ID:NkkjQGwg(1) AAS
>>219
ウェブサービスで使われるスクリプト言語は
ソースファイルがそのまま必要だし、
バイナリにできるとは限らないし、例えバイナリにできたとしても、
ffmpegコマンドを呼び出すなんてのはスタティックビルドにできないし
考えが浅すぎるよ
221: 2019/11/18(月)12:48 ID:yWgPvH2u(1) AAS
>>220
全体的に同意だが
ffmpegはバイナリ置いとけば呼び出せるのでは？
222: 2019/11/18(月)12:52 ID:rYgoyQ9U(1/7) AAS
そのffmpegが依存しているものは？
apt-getで簡単に入るものに対して頑張ってスタティックビルドするの？
ffmpegは依存してるものが多すぎてビルドはかなり大変なんだが
223(1): 2019/11/18(月)13:39 ID:3lFA7L7g(1/4) AAS
いやそもそもDockerという環境の為に普通のビルド方法を変更すること自体
どうかと思うが？Docker以外の環境ではMakefile書き直すの？
224(1): 2019/11/18(月)14:33 ID:3lFA7L7g(2/4) AAS
>>214
そもそもこれ、最初のビルドは上手くいくの？
gitにアップしたのが2017年12月？
ssl絡みでdocker buildがエラーになるはずだけど？
225(1): 2019/11/18(月)15:38 ID:rYgoyQ9U(2/7) AAS
>>223
Dockerは環境じゃないんだが？
この場合は、buildってやったら、ビルドバイナリを生成するツールってだけ
226(1): 2019/11/18(月)16:43 ID:3lFA7L7g(3/4) AAS
>>225
dockerが環境で在るかどうかなんて、どうでも良い話。
単にDockerのためにMakefileを書き換えるというなら違和感を感じる
といっているだけ。
227: 2019/11/18(月)16:58 ID:rYgoyQ9U(3/7) AAS
>>226
わざとやってんのか本気で馬鹿なのか
後者なんだろうけど、お前の言うMakefileの中で
Dockerを使ってビルドしてるだけの話
228: 2019/11/18(月)17:00 ID:rYgoyQ9U(4/7) AAS
スタティックビルドの話でもそうだが
C/C++の開発経験しか無いんじゃないだろうか
経験が浅すぎる
229: 2019/11/18(月)17:01 ID:rYgoyQ9U(5/7) AAS
makeだけがビルドツールではない。
ヒントな
230: 2019/11/18(月)17:07 ID:3lFA7L7g(4/4) AAS
>ffmpegは依存してるものが多すぎてビルドはかなり大変なんだが
こんな紛らわしい書き方するからだろ。
configure一発でいけるなら別に大変でも何でもない。
231: 2019/11/18(月)17:09 ID:rYgoyQ9U(6/7) AAS
> configure一発でいけるなら別に大変でも何でもない。
configure一発でいけないから大変
232(1): 2019/11/18(月)17:14 ID:rYgoyQ9U(7/7) AAS
Docker使えば普通にapt-get使って、それをそのまま一つのイメージにすることができる。
このイメージを使えばどの環境でも同じように動く。
どの環境でも動くようにするために、スタティックビルドすればいいじゃんと言うが、
オレオレビルドなんて、今の時代はやらない上に、
スタティックビルドにするために、いろんなライブラリをかき集めて
configureを通すとか時間の無駄。
Dockerなら普通にapt-get使って、どこでも動くイメージが作れる。
233: 214 2019/11/18(月)20:55 ID:fwqLgOPw(2/5) AAS
みなさんありがとうございます
>>224
これですね､多分
なんか赤文字連発したり途中で終わってる感抜群だしで､
Dockerfileのビルド自体失敗してるくさい
234: 214 2019/11/18(月)20:56 ID:fwqLgOPw(3/5) AAS
これUbuntu18.04LTS使用だとDockerfile書き直せばいけるの？
てか､Dockerの中身をそのままDocker使わずに普通にコマンドラインで打っても行ける？
235(1): 214 2019/11/18(月)21:00 ID:fwqLgOPw(4/5) AAS
dockerfile見るとこうなってるじゃん
$ apt install -y clang python pkg-config git curl bzip2 unzip make
やっぱ､これらのコマンドすらインストールされてないから､ビルド失敗してるわ
コマンド打ってもコマンドなしになるもん
236: 214 2019/11/18(月)21:04 ID:fwqLgOPw(5/5) AAS
mozcのDockerfileは､2018年1月更新となってますが､やっぱり古すぎですか？
Update the copyright year to 2018
REF_BUG=
REF_CL=180466480
REF_TIME=2018-01-01T00:00:18-08:00
REF_TIME_RAW=1514793618 -0800
237: 2019/11/19(火)00:19 ID:TB1GOjb/(1/4) AAS
>>235
それは全く関係ない
238(2): 2019/11/19(火)01:50 ID:H229ozOy(1) AAS
>>232
windows とlinuxでコンテナの互換性ないよ。同一OS上は可能だが、何処でもは無理
239: 2019/11/19(火)02:00 ID:TB1GOjb/(2/4) AAS
>>238
だからWindowsとmacOSではLinux仮想マシンを使ってるんだよ。
結果、Windows（とmacOS）上でもLinux用のDockerコンテナがそのまま使える
240: 2019/11/19(火)02:19 ID:TB1GOjb/(3/4) AAS
それとWindowsのWSL2では仮想マシンでLinuxカーネルをそのまま使うので
Linux用のDockerコンテナが、公式サポートと言っていいレベルになる。
つまり今はDockerが仮想マシンイメージを作っているが、それが不要になる。
それだけかと思うかもしれないが、大きな違いが2つある。
一つはメモリ使用量。一般的には仮想マシンにある一定のメモリを割り振らなければいけないが
WSL2ではMSがカーネルに手を入れているため、Windowsとメモリを共有できる。
Linux上でDockerコンテナを動かしたのと殆ど変わらないメモリ使用量になる。
これは従来の仮想マシンを使うmacOSでは難しい（ある程度は仮想マシンのメモリを開放しているようだが）
そしてもう一つは、これは俺の予測だが、Ubuntuなどのディストロを使わずに
DockerがWSL2上でそのまま動くようになる可能性がある。
今、Dockerが提供しているDockerサーバーはHyperV上でDockerDesktopVMという
Linuxカーネルを使用するための軽量仮想マシンを動かしているが、
WSL2では複数のディストロがLinuxカーネルを共有する。
Dockerが動作するのに必要なのは、原則としてLinuxカーネルだけなので
WSL2でLinuxカーネルがすでに動いているとしたら、理論上はDockerサーバーは
WSL2の/initから直接起動することが可能となる。
将来のDockerは今のUbuntuと同じように、Microsoftストアからインストールする
単体のサーバーアプリ相当になるだろう。
241: 2019/11/19(火)02:22 ID:TB1GOjb/(4/4) AAS
>>238
あと、当たり前だが、どこでも同じように動くというのは
「"Linux用Dockerが動く環境なら"どこでも同じように動く」という意味だ。
さすがにFreeBSDでもSolarisでもPS5でも動くとかそういう話はしてないｗ
242: 214 2019/11/19(火)21:32 ID:BbWOlht1(1) AAS
mもしかして､Android版Mozcのapk作るのって
ここにあるソースとAndroidStudioだけで出来る？
AndroidStudioならSnapにあるから楽なんだけど
外部ﾘﾝｸ:github.com
243: 2019/11/19(火)21:56 ID:4mU598Ua(1) AAS
もう完全なるすれ違い。
244: 2019/11/19(火)22:18 ID:bNC5wdZW(1) AAS
Docker 19.03.5リリースされたけど、Mac版でまれにフリーズする問題、まだ直ってないね。
for i in $(seq 100); do echo $i; echo FROM alpine | docker build -; done
外部ﾘﾝｸ:github.com
245: 2019/11/20(水)08:58 ID:S7eWFdSu(1/2) AAS
WSL2がWindows10のSlowRingにも来た
不安定で、かつ頻繁にアップデートするFast Ringじゃなくても
dockerが動かせる
246: 2019/11/20(水)09:05 ID:Ea4P6MqO(1/2) AAS
ん？前から来てなかったっけ？
別件でfast ringに変えたけど、
ちょっと前までslow ringで試してたはずなんだが
247: 2019/11/20(水)09:07 ID:S7eWFdSu(2/2) AAS
11月11日に来たみたいだ
ちょっと前と言えば前だけど
外部ﾘﾝｸ:blogs.windows.com
248: 2019/11/20(水)09:25 ID:Ea4P6MqO(2/2) AAS
これだな。WSL 2対応のDocker Desktop
外部ﾘﾝｸ[html]:forest.watch.impress.co.jp
249(2): 2019/11/20(水)12:28 ID:CdtAMkQV(1/2) AAS
なんつーかDockerて誕生してから5年経過してると思うけど
未だこんなレベルなのか・・・。
250(1): 2019/11/20(水)12:31 ID:ggOPHuIR(1) AAS
>>249
お前は5年前から何も変わってないなｗ
251: 2019/11/20(水)13:11 ID:CdtAMkQV(2/2) AAS
>>250
馬鹿じゃね？お前に何が分かるんだよ？
相変わらずこのスレには禄でもない奴が住んでるな
どっか消えろよ。
252: 2019/11/20(水)14:53 ID:/X658f56(1) AAS
>>249
未だにWindowsでネイティブ動作しない事？
253: 2019/11/20(水)15:03 ID:3GvUfUkB(1) AAS
Windowsにもコンテナはあって、
Dockerはそれに対応してるから
Windowsネイティブで動作する。
254: 2019/11/20(水)21:23 ID:sHwSvmkR(1/2) AAS
わざわざwindows使う必要はないよね
上下前次1-新書関写板覧索設栞歴
あと 748 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.192s*