Docker Part4
■ このスレッドは過去ログ倉庫に格納されています
Linuxが持つコンテナ技術を使った、仮想マシン必要ないアプリケーション仮想化技術で アプリケーションのデプロイが用意になります Docker(アプリ仮想化)は仮想マシンと併用して使うことで最も効果を発揮し 開発・テストで使ったDockerイメージと全く同じものを本番環境で使えます さらにWindowsとmacOSでも同じDockerイメージが動きます。 (Linuxは仮想マシンが不要ですが、WindowsとmacOSは仮想マシン技術を併用して実現しています。) Dockerイメージ(Dockerfile)はアプリケーション開発者が作成します 動かすのに必要なもの全てがDockerイメージに含まれるので インフラ担当者はそれを動かすだけ、本来のインフラの作業に集中できるようになります Dockerは主にウェブ業界でサービスのデプロイの必須技術になりました 情報共有しましょう http://www.docker.io/ 前スレ Docker Part3 https://mao.5ch.net/test/read.cgi/linux/1552023620/ 注意 同じコンテナ技術を使うが異なるアプローチで仮想マシンの 代替を目指しているのがLXC。目的が全く異なるので注意 LXC(Linux Containers) https://mao.5ch.net/test/read.cgi/linux/1330826939/ >Dockerは主にウェブ業界でサービスのデプロイの必須技術になりました >>1 は何も理解してない馬鹿。 すっげー前にDeployerを教えてあげて、それを納得したはずなのに何も理解していない。 マジでお前は、いつ学習が完了するんだよ。 https://mao.5ch.net/test/read.cgi/linux/1552023620/ >>651 何故話をこんなレベルまで戻すのか > すっげー前にDeployerを教えてあげて、それを納得したはずなのに何も理解していない。 手動でデプロイしてんのか? オートスケールどうするんだ? Docker使わないと構築に時間がかかるだろ Dockerはイメージのrun(内部で自動的にpullする)だけで構築が完了する アプリが動く状態として完成された物が手に入る Deployer?運用のことを全くやってないか 数台規模で夜間メンテナンスなんてのを いまどきやってる程度の小さいレベルんだろうな > すっげー前にDeployerを教えてあげて、それを納得したはずなのに何も理解していない。 なんだこれ?妄想世界の住民か? 「すっげー前にDeployerを教えてあげて」 なぜ同じ人だと思ってるのか? 「それを納得したはずなのに」 納得したという妄想だろう 納得させたというレスがあるなら持ってきてみてくれ 妄想世界の住民だろうから、絶対に無理だろう おそらく俺の予想は的中する 絶対に持ってこない buildkitっていうのがあるんだってな 環境変数で指定しなくてもデフォルトで利用できるようにしたほうがメリットないだろうか >>5 設計や動作が大きく変わってるから 長い検証期間を設けてるだけ そのうちデフォルトになるだろうがすぐは無理 俺が知っている事例で言えばマルチステージビルドで 必要ない場合にビルドされなくなることがある 通常は問題がないだろうがビルドされているという 前提があったりすると問題が発生するだろう buildpacksって OSやプログラミング言語のランタイムの更新があった時に 開発者は何もしなくても運用者側だけでアップデート出来るのが長所? しかし、package.json内の依存ライブラリの更新はそれで対応できるのか? 出来ないなら結局Dependabotみたいのは必要そう 微妙に互換性崩れてて OSや言語のバージョン上げたら動かないとかもありそう 運用者なんていない。あるのはシステムだけだ。 開発者が開発し、それを配布するときの面倒なごたごたを システムが勝手ににやるだけだろう 開発者が楽になるためのツールだ いや、Dockerfileを書かなくていいのが最大のbuildpacksの長所か Dockerfileを書かなくていいので、プロジェクト間のコピペを抑止出来る OSイメージやプログラミング言語のランタイム更新だけなら、リビルドしないことも可能らしい CIでのビルドに焦点を当ててるように見えるが、 アプリケーションコードを含んでないイメージでローカル開発も可能なんだろうか? > アプリケーションコードを含んでないイメージで なんだそりゃ? Dockerイメージは(自分で開発している)アプリケーションコードを含むものだろ 自分で開発したイメージを配布・デプロイするためにDockerは使うんだぞ 自分で開発してないイメージはDocker pullして使うものだ 例えばMySQLとかnginxイメージとか ああいうのは、本来はMySQLとかnginxの開発者が 作ってイメージとして提供するもの 実際にはDocker社が提供しているがね >>10 PHPでの開発の時 ローカル開発の時はphpのコードはボリュームマウントして入れるが 本番環境で使う時は予めphpのコードが入ったイメージをCIで作っておいて それをプルしてきて動かす >>10 アマチュアっぽい 開発中も無駄にdocker buildしてそう またキチくん暴れてるのか 頼むからコテハンつけてくれ 同じベースイメージでローカルqgp環境の開発を行い 本番環境ではベース+アプリケーションのコードが入ったイメージを使う ローカルと本番環境との差異が無くなるし サーバーが何台に増えようとも 各サーバーはビルド済みイメージをプルして実行するだけで済む ローカルのphp開発環境だった 12 factor apps的には本番環境のサーバーでビルドするのはご法度 ビルドはCIでやっとけ >>13 なぜ開発環境と本番環境を基本的に同一にしない? Dockerなら、developmentもproductionも同じにできる。 同じにするということはイメージにソースコードを含めるということだな >>15 開発中はDockerを使わない テストで使えば良いのだ 新人「せんぱぁ〜い。バグ報告書どおりにやったのに違うエラーがでるっス!助けてくださいよ〜(´;ω;`)」 べテラン「どれどれ…おいなんでDockerがあるのに使わないんだ!お前のとこだけ依存ツールのバージョンが違うじゃないか!」 新人「テストだけDocker使えばいいと思ったんスよぉ〜(´;ω;`)」 ベテラン「そもそも開発環境作るの手間だろ。なんで手間かけてトラブルの可能性を増やしてんだお前。マゾか?」 新人「いや〜苦行インストールしたほうがなんかやった感あるじゃないッスか😁いひひ」 ベテラン「はぁ…お前今日アサインしたタスク終わるまで帰るなよ」 新人「そんなあああああああ。゚(゚´Д`゚)゚。」 これ半年ぐらい前の出来事 >>23 そういうことを防ぐために例えばRubyでは Gemfileという仕組みがある Dockerを使った所でバージョンの固定なんかできんよ ディストロに入っているライブラリだけを使って開発するんじゃないんだから むしろディストロに入ってないライブラリを使うことが多い Dockerの中でGemfileを使ってバージョンを指定しているのであれば、 同じようにDockerを使わない場合もGemfile使ってバージョン指定をするだけの話 Rubyのバージョンも.ruby-versionでしていする もちろん他の言語でも同様の仕組みがある > ベテラン「そもそも開発環境作るの手間だろ。なんで手間かけてトラブルの可能性を増やしてんだお前。マゾか?」 Dockerは開発環境を作るためのものじゃない 何度もいわれていること 開発環境を作るためのものでもあるし他のためのものでもある 自分の狭い見識だけで道具の目的を決めつけようとすることは愚かだ 環境を作るとかいって仮想マシンの代わりだと思ってるやつの発言はこんなに間抜け コンテナ型仮想化Dockerスレ その2 https://mevius.5ch.net/test/read.cgi/tech/1569542871/416- 正しい使い方を知らないやつが開発環境とか言うんじゃねーよ >>28 VSCode Remote Containersという拡張機能がVSCodeにある Microsoftは間違っていたとでも言うのかwwwwwwww https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers The Remote - Containers extension lets you use a Docker container as a full-featured development environment. Whether you deploy to containers or not, containers make a great development environment because you can: * Develop with a consistent, easily reproducible toolchain on the same operating system you deploy to. * Quickly swap between different, isolated development environments and safely make updates without worrying about impacting your local machine. * Make it easy for new team members / contributors to get up and running in a consistent development environment. * Try out new technologies or clone a copy of a code base without impacting your local setup. 仮想マシンはDockerと同じっていう別なキチガイと Dockerは開発環境に使えないってキチガイの夢の共演 両方とも寝言は寝て言えっつーのw そんなの言ってるのお前だけだから 実装〜単体まではローカル端末上のDockerにコード置いたディレクトリマウントして使って、内結以降はイメージビルドして商用相当の開発環境にデプロイしてテスト、そのイメージをリポジトリにあげといて商用からはそれpullするだけって使い方が普通じゃないの? > 実装〜単体まではローカル端末上のDockerにコード置いたディレクトリマウントして使って、 デバッグどうするの? デバッグ用のパッケージを入れるの? そうすると本番環境とは厳密には違う状態になるよね? どっちみち開発では便利さのために本番環境とは違う環境になるんだから Docker使わずに開発しても同じことじゃない? できるだけ寄せていくだけだ Alpineで動かすならAlpineで開発したい でも支給マシンはubuntu、windows、mac、、、 開発環境を汚したくないんですよ dockerの特性上、1つのプロジェクトで様々な言語、言語バージョン、ミドルウェア、ツール、サービス、それらに依存するパッケージ、OSレベルの設定、、、 とまあとにかく多くのものに依存してしまう そして開発者が従事するプロジェクトは1つじゃない 開発マシンにこれらを直接インストールして管理するのは大変だ dockerならソースをpullしてコマンド打つだけ 別のプロジェクトが干渉する可能性も極めて低くなる アマチュアさんみたいにAPPとDBのシンプル構成、別プロジェクトは無し みたいな状況なら直接インストールでもいいかもしれんがね >>35 開発はディストリ依存にするべきじゃないよ 変更しづらくなる >>36 > 開発環境を汚したくないんですよ 汚す必要ないのでは? > dockerの特性上、1つのプロジェクトで Dockerの性質のものは一つもないね > 開発マシンにこれらを直接インストールして管理するのは大変だ 全然大変じゃないよ。 そのためにrbenvなどの仕組みが普及してる アプリを動かす環境は特定のディレクトリ以下にすべて入る ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる