Docker Part3

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

http://www.docker.io/

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

>>71
本番でも、そのままdockerコンテナを運用すればええやん！

逆に本番をDockerライクなシステムで運用しないとローカルをDockerで作る意味が無い。
本番がVMだと二度手間になる。
（開発機作るDockerfileを作った後に本番機を手作業で構築するとか）

ステートレスなアプリケーションを素早くスケールしたい場合にコンテナが有利、そんだけや

>>76
このメリットでDocker使う、と言うのならDockerは大規模サービス特化型では？
ヤフオクだアマゾンだと超大規模なサービス運用したいと思うなら、そら動的にさっさと
スケールしてくれなきゃ困る。
が、それでVM技術全部を置き換えようぜ、と言われると無理が在る

ESXiであれHyper-Vであれ学習コストがほぼゼロのOS仮想化技術を
学習コストが低くは無い（そして汎用的でもない）
Dockerでと言われると、何でそんな必要が在るの？
と言う素朴な疑問が消えない。

スケールアウトは（OSごとスケールされるけど）VMにも在るからね。

>>77
そう。

DockerをネタにVM不要論を唱えてる奴はDockerを扱ったことが無いし理解もしてないだろ

>>77
逆に小規模でvm運用だとデプロイ（vmイメージのインポート？）にサーバーサービスを選ばないか？
環境構築ツールとかアプリ単位のデプロイはどうやっているの？

>>80
デプロイ？
やり方は1物理鯖に1OSしか載らなかった大昔と全く変わらないのでは？
VMをインポートするとかではなくOSの中に入って作業をする。
デプロイ方法は中で動いているWEBアプリによって色々だろ。
FWがDeployer持っているならそれ使うし、もっと小規模なら改修したファイルをコピるだけとか。
設定ファイルのようなものインポートする形ならそうするし。
イントラネットでなくインターネット上のサービスならSCPとか。

VM使ったからといって1物理鯖に1OSをインストールして運用していた時代と手順が変わる事は無い。
そういった意味でもOSの仮想化は学習コストがとても低い。

初期の環境構築も手作業でrpmとかyumとかこれも変わらない。
但し1度作ってしまえば、VM複製して開発機→検証機→本番機に一気にコピる。
だから構築の手間自体は一回きり。

>>76のようなステートレスな鯖が例えば1AP鯖に対してフロントエンドに4Web鯖とか在ってバージョン
アップとか面倒臭いなと思えば1個マスタ作ってそれをVM複製するとか、そういった手段も出来るから
楽にはなった。
(昔は4WEBサーバあったら4回手作業でデプロイしていたので）

これをDockerに置き換えようと思えば、上記の説明を全部やり方変えないといけないから普通の企業
のシステム事業部には、なかなかそのメリットを納得させるのは難しい気がする。

OSの仮想化では無いから、コンテナの中にログインしても何が出来ると言う訳でもないので、その
意味でも面食らうし。

>>81
＞手作業でrpmとかyumとかこれも変わらない。
但し1度作ってしまえば、VM複製して＞開発機→検証機→本番機に一気にコピる。
だから構築の手間自体は一回きり。

環境更新するたびにそれとか原始的過ぎるだろ
環境増えたら更新メンテナンスが手間
記録も残らないし戻すのも面倒くさい
それとも一度作ったら二度と更新しないとでも言うのか

サーバーをペットのように可愛がるな、いつでも替えの効く家畜として扱え

AWSにも仮想マシンイメージ（AMI）があるが
必要なソフトウェアは起動してからDockerレジストリからプルすれば
カスタムのイメージは作らなくても良い

サーバーが全くインターネットにアクセス出来ない環境なら
そのプライベートネットワーク内にレジストリのミラーを作成するか
Packerを使って、必要なDockerイメージをプルした状態でAMIを作成

サーバーをペットのように扱ってるとASGも使えないだろうが、サーバーダウンは全て人間の監視を付けて対応する気か…？

>>82
>それとも一度作ったら二度と更新しないとでも言うのか

逆に訊きたいけど、じゃあ月イチとかそんな頻度でやるの？
環境更新といっているのがどのレベルなのか（例えばOSのバージョン上げるとか）
と言っているのなら、そんな頻度では当然やらない。
致命的なセキュリティホールでもない限りは経験的には5年に1回とかでは？
それなら別に面倒くさいとかは無いよ。
しかもじゃあ、Dockerならノーコストで出来るのかと言うとそうでもないし。

うちでは小規模な案件であれば、コンテナオーケストレーターにECSを利用している
EC2（仮想マシン）やECSのサービス（どんなコンテナを幾つ動かし続けるかの指定、docker-composeのサービスを拡張した感じ）はTerraform、CloudFormationで管理

これらが揃えば
公開するドメインなど、環境によって変えなければいけないものを除き
全く同一のソフトウェア構成で自動で構築できる

>>83
>サーバーが全くインターネットにアクセス出来ない環境なら
>そのプライベートネットワーク内にレジストリのミラーを作成するか
>Packerを使って、必要なDockerイメージをプルした状態でAMIを作成

これはどう見ても余計な手間が増えている。

>>84
脆弱性なんて5年に一回どころかもっと高頻度で出ると思うが
脆弱性出ないからじゃなくて
一個ずつパッチ当てるの面倒だから更新してないだけだろう？

AWSならAMIを更新してASG内のインスタンスを入れ替えれば良い
更新で出る影響は完全にインフラがコード化されていれば、テスト環境でテスト出来る

コンテナとホストOSは基本的に隔離されているので
依存性による問題が出る事はほぼない
カーネルのバグによる影響は出ないとは言い切れないが、
安定版になる前にベータ版で発見される可能性は高い

コンテナだけの更新であれば
影響範囲が限定されるし
サイズがOSより小さいので
もっと高頻度でも可能

>>85
>コンテナオーケストレーターにECSを利用・・・
>>83
>Dockerレジストリからプルすれば・・・

こういうの見ると、日本でDockerが大々的に流行るのは無理と言う気がするね。

>>51 dockerは配布の仕組みが標準化されていて
>>76 Dockerのメリットは、素早くスケール

Dockerはインターネット上の標準化されたレジストリから配布を行いすばやくスケール可能なのがウリと、
が日本じゃ社員50人以下の会社が使うようなサービスはそもそもスケールの必要は無いし、
1万人超の大会社だと、お堅い会社の場合、そもそもクラウド上にアクセスする事自体を嫌うから。
ちょっと前にSalesforce売りに行ったら、ソッコーで「クラウド駄目」とか言われたわ。
大規模な会社じゃないとスケールアウト使う意味ないし、大規模な会社はクラウドを嫌う。
唯一使うとすればヤフオク、グリデナ、メルカリ、ピクシブ、とかインターネット系の大規模サービスやってる所位？
少なくともDockerを100％使い切る会社と言えば上記のようなものしかない。

後はまあ、好奇心旺盛な新興会社が使って自慢するとか、そんな感じ？

>>87
そんなのお客さんと自社の状況しだいだろ？
セキュリティにうるさいお客さんなら月1回呼び出させてパッチあてやらされるし、そうでもなければ放置する
自社内のサービスなら売上げ上がっているなら、メンテはやる。
がこの話は「VM複製して＞開発機→検証機→本番機に一気にコピる。」とは関係ない。
そもそも俺は、「環境更新するたびにそれ」なんて言ってない。

まあ、なんと言うか、「パッチ当てが楽になるからDocker導入しましょう」
といって「そうですね、そうしましょう！」と言う話になるかどうかは分からない。

>>88
サイボウズが1000台規模のKubernetesクラスターを自前で運用してたぞ

後はAWS Outpostみたいなのを自社サーバーで運用とか？

>>86
比較するなら
PackerかDockerかだろ
VMのイメージ作成やデプロイも手動でやっていたのでは話にならん

インターネットなしの環境でKubernetesを運用するとして
Packerを併用する場合でも
Kubernetesのバージョンアップだけ気にしていれば良いから
そこまで手間ではない
ビルドとAMI作成はCIでやる

Dockerイメージの作成もCIでやる

>>90
>サイボウズが1000台規模のKubernetesクラスターを自前で運用してたぞ

これもオンプレで動くサイボウズの方じゃなくてクラウドのほうだろ？
クラウドサービスをDockerでクラスタなら分かる、軽量コンテナにうってつけだろうし。

>インターネットなしの環境でKubernetesを運用するとして

Dockerは本当にオンプレで完全に動くの？
それが出来るなら、企業のIT部門の人が勉強する意味は在ると思う。
それでも、そこに上げた名前分みても、やはり学習コストは高いと思うけど。
なんせVMwareESXiとか学習コスト殆どないし。

サイボウズはオンプレミスでKubernetesを運用している

1,000台規模のインフラ刷新！ Kubernetesを採用したサイボウズが語る「NoOps」な未来 - エンジニアHub｜若手Webエンジニアのキャリアを考える！
https://employment.en-japan.com/engineerhub/entry/2019/03/26/103000

でも北米のkintoneはAWSらしい

クラウドに行く企業、クラウドをやめる企業、それぞれの事情 - 週刊アスキー
https://weekly.ascii.jp/elem/000/000/418/418894/

>>92
ここでいう「オンプレで運用」は>>91でいう「Dockerは本当にオンプレで完全に動くの？」とは
意味が違うだろ？サイボウズが行っているのは単に自社のサービスを自社で運用しているといっているだけ。
91で訊いているのは、インターネットにアクセスせずに（アクセスすると偉い人に怒られるから）DevOpsを全部
導入できるのかと訊いている。見た感じ、頑張れば出来そうだけど。

みんな、cndk2019は行くかな？
来月だね

インターネットアクセス禁止って行っても
Dockerのベースイメージはインターネットから取る必要あるよね

OSSのCIツールを導入するにも
Dockerのベースイメージはインターネットから取得する必要がある
そう考えるとCIサーバー自体にはインターネットアクセスは必要
向こうからのアクセスは無いので、NATゲートウェイ経由で
こちら側からだけアクセス可能にする
レジストリはCIサーバーと本番機のみがアクセス出来るプライベートサブネットに配置
そうすれば本番機にはインターネットアクセスを与えずに済む

Dockerレジストリのミラーを設定して
そこから取得するとしても
レジストリのミラーリングを行うサーバーにはNATゲートウェイ等で
インターネットアクセスが必要

それも駄目だったら逆に何処からソフトウェアを持ち込むんだ
USBメモリで人力ミラーリングか？

イメージエクスポートしたらベースイメージも含まれてるのじゃないの？
そしたらそれを持ち込めば済むね

>>97
そのやり方は普通にDockerfileを書くだけで可能なの？
そもそもDockerてのは、「ベースイメージの取得にインターネットが必要」
って事自体が保守的なIT部門の理解を得られん気がするね。
ゲストOSのインストールをするのにインターネットがほぼ必須、クラウド上にしか
イメージ置かないって言われたら「なんで？」と思うのが普通だわ。

connpassにあるコンテナ系の勉強会行って各現場の導入事例を聞いてみると吉

>>99
暇が無い。
結論だけ教えてくれｗ

プライベートレジストリ立ち上がるダケじゃん

>>101
それ１つをとっても複数製品があり、やはり学習コストが低くはない
って点がどうしようもないね。
まあ、慣れだけど。

初期状態のosでnetwork隔離環境でimageのインポートしたら問題なく環境再現できた
>>98

>>103
(　´∀｀)bGJ!

>>83
>サーバーをペットのように扱ってるとASGも使えないだろうが、サーバーダウンは全て人間の監視を付けて対応する気か…？

今年の8月にAWSの大規模障害あったトキお前んトコは回避できた？
AWSをペットのように扱ってるだけちゃうん？
苦情があっても全てAWSのせいにして対応する気か…？

ﾖｰｰｰｰｼﾖｼﾖｼﾖｼｮｼﾖｼｮｼ

私が死んでも代わりはいるもの

実は83、本番環境持ってなかったりしてｗ

みんな、マイクロサービスアーキテクチャ導入してますか？

マイクロサービスって
2つのマイクロサービス間のデータのやり取りはどうする？
Dockerが解決するのはアプリのデプロイまで

マイクロソフト的には
分離性を高めるため
HTTPリクエストが来た時に別サービスへ同期的に取りに行くのではなく
バックグラウンドで予めデータを同期する方がお勧めらしい
が面倒そう
適当なことやると2つのサービスでデータの不整合が生じる

webキャッシュの話？

実装に関する説明をしているのにカタカナの単語説明ばかりで
具体的にこうしている、というコードが少ないアーキテクチャは駄目フラグ
て気がするけどな。J2EEでトランザクション分離がどうのこうのとか長々と
説明するけど具体的なコードもそれにふさわしくウザくて結局普及はしなかった。

まぁ自分トコさえ便利に使いこなせればいーやってカンジなんじゃねえの

Amazon ECRのマネジメントコンソール
久しぶりに見ると
・タグのイミュータビリティ
・イメージのスキャン

なる機能が追加されてた

https://dev.classmethod.jp/cloud/aws/ecr-repository-scan/

古いバージョンのソフトウェア使ってて
CVEの脆弱性あったら教えてくれる機能？

あまぞんのブログURLがNGワードで書けない

「専任エンジニアが2人以上欲しい」：
Kubernetesの自前運用は難しい？　はてなの撤退事例

はてなのMackerelチームはKubernetesクラスタを自前で構築して運用していたが、撤退を選択したという。
なぜ、Kubernetesの運用を諦めて撤退を選んだのか。
はてなのMackerelチームでSREを務める今井隼人氏が語った。
https://www.atmarkit.co.jp/ait/articles/1911/08/news009.html

会員登録（無料） が必要です

Kubernetesは試したけど本番環境に使う自信が無いわ

>>115
当たり前。
Kubernetesクラスタを自前で運用すると言うのはアマゾンで言えばASG
を自分たちで運用しようってな物じゃないの？
何故そんなことをする必要が在るのかと。

Kubernetesのエコシステムの図一つをとってもツールだらけで
この１つ１つを学習しろと言うのか？学習コスト高すぎで馬鹿かと・・・。
しかもそこまでやっても、汎用的では無いからVMはVMで残さなければならない。。

>>115
わかる。あれ複雑過ぎ
記事読んでないけど、少数の台数で構築してもコントロール不能に陥るだけだと思う。
Kubernetesが生きるのは100台とかで、贅沢なリソースがあって
その中で何台か生きてればいい。他はそのうち生き返るって状況が作れてからからだと思う
台数が少ないと、何台か死んだら絶滅するｗ

結局Dockerは何が魅力なんや？
現段階で本番で使えないのはKubernetes？それともDocker自身？
前にもちょっと書いたけどローカルの開発機をDockerで作っても
本番機で使えないのなら二度手間になるだけだから意味が無い。
>>76見たいな話は勿論、本番環境の事を言ってるんだよな？

>>120
76はVMに対する「コンテナ」の利点を言ってる

kubernetesもdockerもコンテナを動かせる。両方本番で使える。

>>121
そんな事は分かってるよ。両方本番で「使える」ことも分かってるよ。
でその結果>>115で止めたと言ってるんでしょ？使えるけど複雑すぎると。
でそれを読んだ俺の感想はDockerはともかく、それ以外のエコシステム含めると
学習コストも高すぎるし、本番をVMで作ってローカルの開発環境をDockerで作ると
二度手間でしかない、といっている。
で、二度手間に目をつぶってでも、取り組んだほうが良いDockerの魅力は何なのかと。

>>122
つまり本番＝VM、ローカル開発環境＝dockerを推してるやつがどこかにいてそのメリットは何かが聞きたいのね

俺は推してない

でも猫も杓子もK8Sって感じで
後はAWS限定のECSか
Swarmってやつしか無いよね

K8Sは立てるだけならツール使えば出来るが
互換性破壊が多くてアップグレードが壁になる

はてなはテスト環境でアップグレードに失敗して撤退
kubesprayが実装をkubeadmに変えた時期と
担当者の退職・移動が重なったと

でもそれって担当者の退職が一番の原因じゃね？

移行先はEKSを検討しているらしい
ECS、Fargateは既に一部で使っていて
まずECSに移行後、EKSへの移行を目指す手筈

>>120
> 結局Dockerは何が魅力なんや？

配布

WindowsのDLL Hellの話知ってるか？
昔、Windowsで大問題になってな

アプリをインストールするときに、一緒にDLLもインストールするんだが
当時はアプリにシステムDLLが含まれていたりして、
インストールするとOSのDLLを書き換えて、他のアプリが動かなくなったりした。

今ではそれが改善されて、アプリはシステムDLLを書き換えない、
必要ならアプリのディレクトリにDLLを入れたり、
.NETなんか複数のバージョンをインストールできて適切なものを使えるようになってる。

Linuxでもそれは同じでな。ディストロのパッケージだけ使ってるなら別に問題ないんだよ。
そのバージョンで動くように頑張ってるのがディストロの仕事だから

でもな、俺ら（開発者）がなにか作る時、ディストロのパッケージのバージョンを
色々考慮しないといけなくなる。ディストロアップデートしたら、そのパッケージで動くか検証したり
パッケージの新しいバージョンを使う時、それが今のディストロでちゃんと動くのか検証しなくちゃいけない。

それはつらいだろ？だからもうアプリに全部含めちゃいましょう。
というのがDockerなんだよ。（互換性が超高くて小さいカーネル以外）全部アプリに含めてるから
あちこちに簡単に移動できたり、バージョンアップできたりするんだよ。

ここまで言えば分かる通り、開発者以外にとっては関係ない道具
ディストロのパッケージ使ってるだけのやつとか、仮想マシンと勘違いしてるやつにはようはないから

>>120
> 前にもちょっと書いたけどローカルの開発機をDockerで作っても
> 本番機で使えないのなら二度手間になるだけだから意味が無い。

言葉がおかしい。開発「機」を作るわけ無いだろ？

作るのは開発アプリ。それをいろんな、開発機、テスト機、本番機で
そのまま使うことができる。

>>120
> 現段階で本番で使えないのはKubernetes？

Kubernetes。まあ使えないことはないと思うよ。
ただ使うためには労力が多すぎて、発想の転換に迫られる。

数台の本番環境を落ちないようにメンテすると言うより、
システム全体で稼働するように設計しないといけない

個でじゃなくて群で考えてメンテナンスの仕組みを作らないといけない
トラブルが合った時、個々のマシンを観察して情報を判断するのではなく
群からデータを集めてそれらを分析して、トラブルの原因を追跡するとか
個々のマシンをアップデートするんじゃなくて、群の中の一部分を
（半ば自動的に）入れ替わっていくという感じの設計が必要

失敗すると次から次へとマシンが落ちていって制御不能になって
最悪データの損失が発生する。

Googleみたいにすでに大量のマシンが存在して、個々のマシンの観察なんて
やってられないっていうのなら、Kubernetesの出番だけど
そうでない場合は、大変なだけ。

>>122
VMに対して、Dockerは「共通の部分のリソース(Kernel)は
共通で使ったほうが良くない？VMだとCPU上にほとんど変わらん
Linux Kernel複数動いとるやん！」
という提案にそうだねと思ったから使ってる。

メモリとCPU大量につみゃいいじゃん。て言われりゃ、あぁそうだね。
俺はやだけどね。ってだけだ。

たまに、また新しいもの覚えなきゃいけないんすか・・
とか言われることあるよ。そんなの右翼、左翼の違いと一緒じゃないの？
社内でVM陣営(右派)とDocker陣営(左派)に別れちゃったり。
新しもの好きの奴らのほうがハイパフォーマーが多いので
VM陣営は化石になっちゃうんだけどな。
安定度とかはどうなのよって言われると、そりゃVM陣営（保守派）。
でも、新しもの好きはそういうの気にしない。なんとかなる！とか
思っちゃってる人ばっかだから:p

>>124
> でもそれって担当者の退職が一番の原因じゃね？

担当者の退職は避けられない

ってかインフラでは属人性をなくせ、暗黙知を減らせって
やってきただろ？そのための道具だったはずなのに。
属人性は無くなったが、最低限必要な技術レベルと経験が高くなりすぎてしまって
代わりになる人間を見つけるのが難しくなってしまったんだよ

構成が複雑になりすぎて、新しく入ってきた人がシステムを
理解するまで時間がかかる。それって属人性と対して変わらないから。


低い知識で十分だが、やってることはわかっても、それがなんのために必要なのかわからないし
書いてないことが多すぎて謎に包まれてる。

これが

ちゃんと書いてあるしやってることはわかるはずだが、そのためには高い知識が必要で
高い知識がないければ、意図が読み取れず、結局何をやってるのかわからない。

コレに変わっただけ。

>>126
いやいや、開発「機」を作るんだろ？先ずお客さんからどのようなサービスを作るのかヒアリングして
要件定義してそれに相応しいOS、パッケージなんかを決めて本番機を念頭に「開発機」を作る。
当然VM。その後に、実際の開発を行い、
開発機の手順なりスクリプトなりをインフラの人に渡して本番機を作ってもらう。
だから開発機の構築は本番機の構築の事前準備になる。これをDockerで作っちゃったら手順も
違うし環境も違うわで、そのノウハウが全く本番機に生かせなくなる。

>>125
>色々考慮しないといけなくなる。ディストロアップデートしたら、そのパッケージで動くか検証したり
>パッケージの新しいバージョンを使う時、それが今のディストロでちゃんと動くのか検証しなくちゃいけない。

これは別にDocker使うからやらなくて良いって話にはならないだろ？

>>127
>失敗すると次から次へとマシンが落ちていって制御不能になって
>最悪データの損失が発生する。

こんなのVMに対するデメリットでしか無いじゃん。
VM使って在るゲストOSが落ちたから別のゲストOSも使えなくなってEXSi全体が落ちる
（或いはAmazonECS全体が落ちるとか）訊いたことないわ。

>>128
VM vs Dockerとなってる時点でやばい
VMとDockerは組み合わせて使うもの。

Dockerコンテナを何個起動したって、マシン台数が
増えることを意味しないからパフォーマンスはあがらないんだよ。

パフォーマンスをあげるには、一台のスペックをあげるか台数を増やすしか無い。
一台のスペックあげるのは当たり前ですぐに限界が来るので
結局台数を増やすことでシステム全体のパフォーマンスをあげるわけだが

そのためには物理マシン数を増やすってのはクラウドで簡単に台数を増減できる時代の今
大変なだけなので却下するとして、じゃあなにか＝仮想マシン（VM）でしょ？

結局仮想マシンは使うってことは大前提なはずなんだが？
Dockerを使う理由は仮想マシンと別にあって、

パフォーマンスを上げる＝仮想マシンを増やす
増やした仮想マシンに配布しやすくする＝Docker
という結論になるはずなんだが？

>>130
> いやいや、開発「機」を作るんだろ？

開発「機」を作る事自体を否定してるんじゃなくて、
Dockerを使って開発「機」を作るってのがおかしいと言ってるの

Dockerは機械はどれでも構わないってやつなんだから
機械は機械で別に設計しろ。それはDockerの役割じゃない。

>>130
あんたの意見のすべてが「ズレてる」のは
Dockerの役割がわかってないからだよ。

なるほどそうか。>>130の話には「開発ソフトウェア」が抜けてるんだわ
Dockerの役割は「開発ソフトウェア」に関わる話なのに
>>130にはその話が抜けてるから、Dockerがでてこない。
（出てきてるように見えるのはDockerの間違った使い方）

連投すまんね

>>130の

> その後に、実際の開発を行い、
> 開発機の手順なりスクリプトなりをインフラの人に渡して本番機を作ってもらう。

ここやね。インフラの人に渡すものはコマンド一つ程度でよくなるのがDockerだよ。

>>128
いやいや保守派がどうのと言うより費用対効果だろ？
学習コストを上回る効果が得られるなら、当然やる。
めちゃくちゃに忙しいエンジニアが己の持ち時間を削って勉強するんならそれ相当の
見返りを期待するわ。

>メモリとCPU大量につみゃいいじゃん。て言われりゃ、あぁそうだね。

そういうこと。一方でサイボウズの例みたいに1つのサービスのために
1000台のコンピュータが動いていると言うなら、考慮の余地は無いから
鳴るべく軽いコンテナベースに、と言うことにはなるだろうね。

>>129

これは単に分かりやすかった筈のOSの仮想化技術、アプリケーションの仮想化技術を
「コンテナ型」とか分かりにくく言い直しただけ。
別段高い知識でもなんでもない、ワザとか何か知らないけど分かり難くしている。
　

>>138
> これは単に分かりやすかった筈のOSの仮想化技術、アプリケーションの仮想化技術を
> 「コンテナ型」とか分かりにくく言い直しただけ。

まだ「個」でしか見えてないｗ

Kubernetesでは「個」で考えるのではなく「群」を作るのが前提のものだから
難しくなってるって話をしてる。

>>136
ん？「実際の開発を行い」と書いているだろ？
フルスタックのエンジニアなんだから、インフラも開発も全部見るのが普通だろ？
というか、君は見ないのか？

>>139
すまんね。Dockerの話をしてるのかと思ったよ。

「個」をいくつか作っていって、それを組み合わせていけば
そのうち「群」になりますよね？っていうのが従来の発想で、

まず「群」を作りましょう。「個」はその中に生まれていきます。
っていうのがKubernetes。

最初から「大群」になるのがわかってるならKubernetes一択なんだが
「個」をちょこちょこ作っていって「群」まで育てばいいなぁの世界だと
いきなり「群」を作るのは、想定外の話なんだよ。
なんでこの段階からそんなことまで考えなければいけないの？のオンパレードになるから
そういうのをやったことがある人でないとKubernetesは使いこなせない。

>>137
この話で行くなら、既にDockerが本番環境でも利用される事を前提にしないと
話が進まない、と言うか導入しようぜ、とならない。

>>123がいつの間にかこんな事言っているけど、ちょっと前までは、>>71みたいに
あくまで開発者の環境という話だったはずだが？

>>140
両方見るにしても分けて考えないといけない。
両方見てるだけで、一緒にしてるわけじゃない。

分離して考えて、インフラはインフラのことだけ考えればいい
（利用者などの要件に応じて、どんな規模のインフラを作るか？という話）

そのインフラに、アプリを配布するときに渡す「アプリ開発者が渡す手順書」
（どんなパッケージをインストールするのか？）
っていうの少なくて済みますよっていうのがDocker

インフラ担当はインフラの性能のことだけ考えればいいし、
（アプリ開発者が渡した）アプリを動かす手順書見て
四苦八苦しながらアプリ動かしてみせる！のはインフラの仕事じゃない

>>136>>126>>135
スゲー不思議なんだけど、こういうレスが出る奴ってのは
自分達が開発したソフトウェアが本番環境で動作する事を
全く考慮せずに開発してるって事？
そのほうがズレてると思うが？
てか、そんなやり方で環境の差異とかで困った事は無いの？

>>143
だからDockerを本番環境で使うんだよｗ

お前は今どちらの立場で考えてる？
インフラ担当の立場だろう？

お前が気にするのは、インフラの性能と
Dockerコンテナが動くための環境を用意することだけだ


作ったインフラで開発したアプリを動かす、あれやこれやの
パッケージインストール作業の仕事はしなくていい
（↑従来はインフラの仕事だった所）

なぜなら開発アプリをDockerイメージにしておけばコマンド一つとか
設定ファイルにイメージのアドレスを書き込めば終わるから

>>145
> 自分達が開発したソフトウェアが本番環境で動作する事を
> 全く考慮せずに開発してるって事？
> てか、そんなやり方で環境の差異とかで困った事は無いの？

困ったことはあるよ？ 以前は環境の差異で手元の開発機と
本番環境で微妙にパッケージのバージョンが違ったりして
動かなかったり、動かすために本番環境に手を入れるのが大変だった。

Dockerを導入すると、そういう困ったことが無くなるって話
そこを理解すべきところなのに、Dockerの役割勘違いしてるから
それが解決されるってことがわかってないんだろ？

Dockerを導入した場合、自分達が開発したソフトウェアから見ると
本場環境の違いっていうのは、単にインフラのスペック・能力、インフラの構成が違うだけにしか見えない。
（インフラの構成が違うっていうのは、一台にアプリとデータベースサーバーが
同居してるかというレベルの話で、アプリは普通に最初から分離できるように作るので）

ちなみにKubernetesはインフラの構成の一つなのでインフラの話で
Dockerはアプリの配布方法の話なのでアプリ開発の話

KubernetesとDockerは組み合わせて出てきてくるから
同じ層の話だと勘違いする人が多いけど、別だから。

>>146
いやいや、何でそうなるのさ？インフラ担当な訳ないだろ？
俺の書込みを見て俺がインフラ担当だと思うのなら、
本当に開発の事しかわからない、俺にとっての不思議ちゃんだわ。
マジでインフラを全く考慮せずに開発するのね。

>>149
逆に聞くがお前はインフラの何を考慮してるんだ？

Docker導入したら、インフラは「性能が違うマシン」程度しか
考慮しなくて良くなるんだが、

お前は何で困ってるんだ？

>>150
え？困ってるなんて一度も書いてないが？

>>151
困ってないなら、インフラのことを考慮することないじゃん。

エンドポイント（例えばデータベースの接続先）のアドレスはどこか？
程度しか考慮しなくていいだろ。その先がどういう構成になってるか
アプリから知る必要はない。

念の為いっておくが、仕事全体としてインフラのことを考慮してないんじゃなくて、
アプリ開発者の帽子をかぶってるときには、インフラのことを考えなくていいって意味だぞ
インフラ技術者の帽子をかぶってるときは、逆にアプリのことは考えずにインフラのことを考える

一人で担当してるからって、ごっちゃにして考えるなよｗ

>>147
>Dockerを導入すると、そういう困ったことが無くなるって話
>そこを理解すべきところなのに、Dockerの役割勘違いしてるから
>それが解決されるってことがわかってないんだろ？
>本場環境の違いっていうのは、単にインフラのスペック・能力、インフラの構成が違うだけにしか見えない。

じゃあやっぱり、Dockerで開発「機」を作ってるじゃん。

>>133
>>>128
>VM vs Dockerとなってる時点でやばい
>VMとDockerは組み合わせて使うもの。

ちょっとまてw
Dockerを複数動かすより、VMを複数立てていったほうが良いだろ？
ってのが、最初の問いかけじゃなかったっけか？

それをどう読めば開発「機」の話になるんだ？
わけがわからん。

> てか、そんなやり方で環境の差異とかで困った事は無いの？
↑ってお前が聞いたんだから、
お前は困ったことがあるんだろ？
って思ったら困ったこと無いって言うしｗ

>>152
いやいや、俺が困ってるとか、俺が考慮するとかじゃなくて、
君達何を考えてるのかね？と言う話だったんだが。

>>156
わけわかんねー。

本場環境の違いっていうのは、単にインフラのスペック・能力、インフラの構成が違うだけにしか見えない。

といっているのは開発したときの環境と、本番環境の差がなくなったからだといっているんだろ？
で、その開発環境は自分で作ったんだろ？要件にあわせて。

>>155
> Dockerを複数動かすより、VMを複数立てていったほうが良いだろ？

だから、VMは（システム全体としての）性能を上げるために
複数立てるんだよ。

Dockerは、その性能の話と全く関係ない。
仮想マシンだろうが物理マシンだろうが関係なく、
（Dockerサーバーが動いてる）そのマシンに簡単に配布できますよ。

従来インフラ担当者に渡していた
「アプリを正しく動かすための手順書」はいらなくなりますよ。
インフラ担当者が四苦八苦してトップページ表示までたどり着く作業は
いらなくなりますよ。っていうのがDockerを使う理由だから

>>158
> といっているのは開発したときの環境と、本番環境の差がなくなったからだといっているんだろ？

「差がなくなった」とは何の話をしてる？
どうも、全く同じマシンを手に入れた。って言ってるように見えるんだがｗ

開発環境と本番環境が違っていても（Dockerサーバーさえ動いていれば）
その環境の差を気にしなくていいと言ってる。

差がなくなったのではない。差を気にしなくてもいい。
（Dockerサーバーの上だけを見れば、差がなくなったとも言えるのは正しいが）

> で、その開発環境は自分で作ったんだろ？要件にあわせて。
開発環境なんて手元のMacとかだろｗ

まあ、別にどこでもいいがね。Dockerサーバーさえ動いていれば
Dockerイメージにした自分が作ったアプリは問題なく動くので。

なんかもう、根本からズレてる気がするんだよなｗ

なんか本番環境と同等の開発環境を作って
そのマシンにリモートでログインしてアプリを開発する
みたいな発想をしてるように見える

まあ、昔はそれをやっていたので人のこといえんけどな
本番環境サーバーを模した開発環境サーバーにSSHログインして開発してた

違うねんｗ 今の開発はそうじゃないねんｗ
どこでもやれるねん。そんな専用環境なんか作らなくて良くなったんだよ。
Dockerのおかげでね。手元の開発環境がMacであろうとWindowsであろうと
本番環境とどれだけ性能などの差があろうと

（開発環境、もしくは本番環境）のDockerサーバーの上では
性能の違いがあるだけで同じように見えるんだよ。

まだサーバーを家畜ではなく
ペットのように可愛がってるおじさん？

>>161
>なんかもう、根本からズレてる気がするんだよなｗ

>なんか本番環境と同等の開発環境を作って
>そのマシンにリモートでログインしてアプリを開発する
>みたいな発想をしてるように見える

発想をしている、では無い。
これに対する利点を述べてくれ、とずっと要っているのだが？
それに対する利点に合点がいかなければ、その環境を例に挙げて
反論を述べている。・・・すると、おかしな勘違いする奴がいる。

>>161
俺、Docker便利だよ派だけど、
あなたの言い分だと、ID:KPJdW8/sが言う、
VMでいいじゃん。に対する反論になってなくない？

>違うねんｗ 今の開発はそうじゃないねんｗ
>どこでもやれるねん。そんな専用環境なんか作らなくて良くなったんだよ。
>VMホスト環境のおかげでね。手元の開発環境がMacであろうとWindowsであろうと
>本番環境とどれだけ性能などの差があろうと
>
>（開発環境、もしくは本番環境）のVMホスト環境の上では
>性能の違いがあるだけで同じように見えるんだよ。

仮想マシン配布より
プライベートレジストリでDockerイメージ配布の方が楽だし
速いし
同じCPUアーキテクチャならどのLinuxディストリでも動く
Nested VirtualizationのないAWSにもそのまま持ち込める

そもそも仮想マシンには
予めPHPとかインストールされたベースイメージがない
そこから自分でやるのはちょっとめんどくさい

>>164
どの言い分に対するレスなのか知らんけど、

俺は最初から、仮想マシン（VM）とDocker（コンテナ）は
組み合わせて使うと言ってる。

Dockerがあれば仮想マシンはいらないとか言ってない。
どういう反論をすれば良いんだ？

使い方が違うとしか言いようがない。
VM作るだけだとアプリの配布が面倒だろって言えばいいのか？
VMだけじゃ"足りない"だろ。としか言えんぞ？

>>163
> これに対する利点を述べてくれ、とずっと要っているのだが？

利点？ お前、客から要件聞いて、そこから開発環境
（専用の開発サーバー）作るお仕事をしてますって言ってるじゃん？

俺からすればなんでそんな事してるんだ？って言う話だから
利点と言うなら、要件聞かないと開発環境が作れませんなんてことにはなりません。
開発環境を作るコストが減りますといえばいいのかな？

開発環境だけの話をしてるのが謎だけど

Dockerを導入すれば（開発環境に限らず）どんな環境にでも容易に変更できます。
"本番環境"を要件（負荷等）に応じて、自社サーバーにするのも
クラウドにするのも、環境を用意に変更できます。
（という話の環境の中に開発環境も含まれてる）

>>167
>>130実際の開発を行い
>>137実際の開発を行い
>>140実際の開発を行い

何度も書ているんだが、日本語読める？
てか、お前、馬鹿なんだから俺の質問にレスすするな。
おかしなレッテルの上で話を進めるから訳がわからない。
他の人はまあ、読んでると思うけど、お前は全部的を外している。

>>142
何か、話が飛躍しすぎている気がする。流行りだし>>128が言うようにVMは
やがて鯖側で化石になるだろうから、Dockerで運用してみようかな？
と思わない事も無い。でもこんなにデカイのは要らないんだよなぁ・・・
2台のWeb or Socketサーバーを平日の繁忙時間だけ3台にしてくれるような
ツールは無いですかね？

>>169
DockerとKubernetesの話は別だ。分けて考えてくれ。

Dockerは配布が楽になる。どこでも動かせるようになる。
そのどこでもの中の一つにKubernetesで構成した大規模なインフラも含まれるってだけ

開発したアプリがどこでも動かせるから、手元のMacでも
本番環境の物理マシンでも仮想マシンでもKubernetesで作った
クラスタ環境でも簡単に動かせるってだけ。

別にKubernetes使うのは必須じゃない。Kubernetes使ったからって
簡単になるもんでもない。逆に難しい。Kubernetesが生きるのは大規模な本番環境であって
2台のWeb or Socketサーバーを平日の繁忙時間だけ3台にしてくれるような
ツールなら、クラウドの仮想マシンオートスケールの設定でもして
その上で「Dockerコンテナを」動かせばいい。


というふうに組み合わせて使うんだよ・・・
Dockerは配布が簡単になるだけのものなんだから

>>168
で？

>>169
> 流行りだし>>128が言うようにVMは
> やがて鯖側で化石になるだろうから

上でも言ってるけどならんよ。

（Docker）コンテナはいくら数を増やしたって
システムの性能は上がらないんだから。

システムの性能を上げるために必要なのは
（マシンスペック強化は別として）VMの台数を増やすこと

まあクラウド側の提供として、コンテナを動かすための環境を提供して
その環境ごとに課金するタイプなら見た目上、VMはなくなったように見えるが。
でもVM単位の課金か、コンテナ環境単位の課金かの違いになっただけやねｗ

亀です。
軽くレスおってるだけで提言なんだけど、配布とか楽なのはわかる。
compose upすればいいだけ。すごく楽。

だけど保守には向かないんだよ。docker自体にログがドカドカ出す機能はないし、中のアプリケーションから何らかのものを出さないといけない。
dockerのネットワークもEsxiとかに比べたら柔軟に構築できないし、障害対応に当たるメンツの教育コストも考えなきゃいけない。

立ち上げだけ上手くいくテスト環境にはいいけど本番環境はやっぱり難しいと思う