Docker Part2©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
社内のチュートリアルが何年前に書かれたかだな Docker Toolbox使ってたら古いやり方だな まあ社内全員やり方が決まってるなら仕方ないが 支給されたmac PCが他の人も使うみたいで 別の人がインストールしたhomebrewが/usr/localにはいってて 権限が変更できないくてホーム以下にインストールしたんだけどそのせいなのかなと… 1日がかりでbrew rbenv dockerの3ついれただけなんだけど どれが原因なのかがぜんぜん分からない… マックはじめてで最初の1,2時間は日本語変換や窓の最小化やコピペもわからないレベルで作業効率も悪いし Javaからruby覚えるのはすぐできると思ったけど OSが違ったりフレームワークの環境構築がこんな大変だと思わなかった >>186 なんの苦労もなくhomebrewを使いたいなら Macを他に人に使わせるな。そしてクリーンインストールして 自分ひとりのものとして使え homebrewはインストールしたユーザー以外がまともに使うことは無理 homebrew自体はsudo使ってインストールするくせに(/usr/localに書き込むから) パッケージ自体は/usr/local以下に一般ユーザーでインストールするからな ディレクトリはこんな感じになる https://github.com/Homebrew/brew/issues/3322#issuecomment-336770069 > -rw-r--r-- 1 weicool admin 3161 Jan 18 2016 /usr/local/CODEOFCONDUCT.md > drwxr-xr-x 18 weicool admin 576 Oct 8 13:58 /usr/local/Cellar/ > drwxr-xr-x 2 weicool wheel 64 Oct 15 10:57 /usr/local/Frameworks/ > -rw-r--r-- 1 weicool admin 1241 Jan 18 2016 /usr/local/LICENSE.txt 見ての通り、adminグループに書き込み権限がないから、 最初にパッケージをインストールした人以外がいじることはできない。 brew管理用のユーザーを別で作成するとかumaskの設定をいじってたりとか ちゃんとやってればマルチユーザーで使えるかもしれんがな homebrewの設計自体はsudoを使わない方針なんだが https://docs.brew.sh/FAQ#why-does-homebrew-say-sudo-is-bad じゃあ共有のディレクトリ/usr/localを使うなと そうなんですね クリーンインストールしていいかお願いしてみます 検索するとわりとホーム以下にインストールする方法とかでてきたのでいけるかと思ったんですけど コーディングスキルかわれて入ったのに初日から環境構築だけでつぶされてストレス なまじできると思われてるからしょーもない質問もしにくいし もともと大学院研究室あがりでスクラッチからかくのが好きな ブラックボックスなツール使うの気持ち悪い 古い人間だから昨今のフレームワークだらけの業界きついなあ… macやhomebrewがはじめてなのはともかく、バージョン管理ツールはじめてはないわ それでひとりで環境構築しろってほったらかしなのも普通はありえんと思うけど 仕事ほしくて経験ないのに経験ありとか嘘かいたんじゃねーの 最後にききたいんですけど /usr/local じゃなく ~〜/homeblew に homeblew をいれたんですが この blew から Docker をインストールした場合実態はどこにあるんでしょうか チュートリアルにアプリケーションからdockerを起動とあるんですけど /Application/Docker.app を起動したときにもっと新しいのがありますっていわれて 更新かけたらそれっきりだったので これが前の人がインストールしたやつだったのかな… コマンドラインの docker はホーム以下のパスになってたんですけど アプリケーションからじゃなくコマンドラインからDockerのGUIアプリ起動する方法ってありますか? 解決しました 初回起動時に窓が出たのでずっと窓を探してたんですけど 右上のクジラマークからアクセスするんですね… おさわがせしました 何度もすいません docker-compose up -d で ERROR: manifest for xxx/yyy:2018zzzz not found が出るんですがどこを見ればいいのでしょうか 一応同じディレクトリに docker-compose.yml はあって yyy: image: xxx/yyy:2018zzzz と書かれています >>194 普通はそうならないので環境の問題です OSをクリーンインストールしてください rubyは導入ハードル高すぎ よっぽど複雑なプロジェクトでもなけりゃこんな開発環境作ってるあ労力で案件終わるわ 利用プロジェクトの多くが低品質だったせいでいわゆるアタリショックみたいな扱い受けてるよな 負の遺産だとかRuby巻き返しの目は潰えてるとまで言われてるし・・・Javaみたいにはならんで欲しいマジで 散々Perlディスっといてこれだもんなm9(^Д^)プギャー やめて…perlは6を引き伸ばし杉た件のせいで世間との剥離からユーザー離れが尋常じゃなく 引き合いに出されると最底辺の戦いじみて嘲笑の的です… マジかよDockerForWindows消してくる もしかしてHyperV無しのHome版WSLでも動くようになってるのか パブリッククラウドやDocker Hubに最適化した「Minimal Ubuntu」がリリース 2018/07/10 12:06:20 https://news.mynavi.jp/article/20180710-662006/ Canonicalは2018年7月9日(米国時間)、パブリッククラウドおよびDocker Hubに最適したLinux ディストリビューション「Minimal Ubuntu」をリリースしたことを明らかにした。 AWS(Amazon Web Services)およびGCP(Google Cloud Platform)を推奨パブリッククラウドとし、 イメージファイルはWeb上からダウンロードできる。 ええやん alpine使いにくいし乗り換えようかな 展開後のサイズは約80MB前後でminidebのようなコンテナ特化支援コマンドはさすがに無いっぽいな Ubuntu版の公式slimとしてapt系で最新パッケージ使いたいなら(Debianのslimじゃなくて)こっちでねって感じか 野良イメージじゃない公式スリムに選択肢が増えるのは嬉しい debian:stretch-slimは55MB (bitnami/minideb:stretchは54MB) ubuntu:bionicは81MBで去年から変わってないみたいだけど今回発表されたやつは何なんだいったい… 元記事タイトルにDocker Hubとあるが実は関係なくてアマとかGCPで使うimgファイルが小さくなりますたってことか ミニマルすぎると一個ゲットした途端大量に依存がやって来る悪寒しかない 「OpenNebula 5.6」公開、Dockerサポートの強化などが加わる 2018年7月18日15:00 末岡洋子 https://mag.osdn.jp/18/07/18/150000 クラウドインフラストラクチャ構築・管理プラットフォーム「OpenNebula」の開発チームは7月16日、 最新安定版となる「OpenNebula 5.6」(Blue Flash)を公開した。 Docker管理機能を新たに統合、任意のOpenNebulaクラウドで、Dockerアプリケーション実装の 土台となるDockerエンジンの仮想マシンをMarketplaceよりインポートできるようになった。また、 OpenNebula APIやインターフェイスを経由することなくDockerエンジンをシームレスに管理する Docker Machineも統合した。 訳あってソースコードからビルドしないといけない物があるんだけど、 ビルドに必要なパッケージをインストールしたくない。 だからDockerでビルドして、インストール先はDockerの外って やりたいんだけど、そういう使い方のノウハウって どこかにまとまってないかなぁ? ソースコードのディレクトリをボリュームにして make installだけDockerの外でやるのが一番かなぁ? そういうときはmake install先のディレクトリだけ -v でマウントしとくパターンが簡単で良いね 例えば ./configure --prefix=/usr/local で入れるやつはインスコ先になる/usr/localを docker runのときに -v "/usr/local:/usr/local" って指定する コンテナでmake installまでやれるしホストもソースやビルドツールで汚れないから安心 docker公式マニュアルのどっかに書いてあった気がしたが見当たらなくなってた >>217 もう少しアイデアを発展させてみた。 このアイデアをどうするかは任せる make install、前々からの問題。何処に何がインストールされるかわからない。 基本的には--prefixで指定した所だろうけれど、確実にそうとは言い切れない make uninstall、これも前々からの問題。uninstallをサポートしているものが少ない インストールした後消すのが大変 docker、make installでインストールされるファイルは多分レイヤーの差分を見ればわかる インストールされるファイルがわかるのだから、それを消せばアンインストールになる インストールするファイルも残っているのだから、ファイル内容を比較することで アンインストール時に想定外のファイルを削除しなくてすむかもしれない 今はMulti-stage buildが公式実装されて>>219 のアイデアを綺麗に実現できるようになったね! ビルドコンテナのmake install結果をホスト経由せずに実行用コンテナに簡単に乗せられる ビルドコンテナも実行用コンテナも使い終わればコンテナごとすべて消せるから --prefix完全無視の無作法野良ツールにホストのファイルが上書きされることもないし make uninstall非対応でもコンテナ消せば良いだけだからゴミが残ったりもしない >>220 > make uninstall非対応でもコンテナ消せば良いだけだからゴミが残ったりもしない なんかちょっと違うw インストール先はコンテナの外よ。だからコンテナ消せば良いだけってことにはならない。 どんなものでもコンテナ化して使えるかっていうと、例えば(独自ビルドの)gitコマンドを コンテナに入れて使うのは大変だと思う。カレントディレクトリを見るし、 サブコマンド次第ではカレント以外のディレクトリも見るしね インストールするファイルを知ることができるから、コンテナでビルドして生成したものを コンテナの外にインストールしてアンインストールもしやすくなるだろうと言う話 最初のうちはエディタとかgitとかはどうしても大変に思えてホストに直接置きたくなるんだよな 俺もコンテナ上のgitからホストのカレントディレクトリを見る方法がわからんというごく最初の段階でつまずいた 絶対パス指定ならツールで使う主要ディレクトリを-vに指定しとけば大半普通に開けるけど カレントを含めた相対パスも単に-v $(pwd):$(pwd) -w $(pwd)を書いておけばいいという基本をDocker Hubのgitイメージページ読んで知った >>222 だから大変だからホストに直接おいたほうが良いって話なんだが 例えばgit diff --no-indexでカレント(gitディレクトリ)以外を 比較したくなったら-v $(pwd):$(pwd)じゃ対応できない。 他にもgit applyとかさ -v $HOME:$HOMEにしたら動くかもしれないけど、 それでもhomeの外では使えないコマンドになってしまう。 (例えば/opt以下にgitリポジトリをcloneするツールとかさ) コマンド実行した時、特定のファイルはコンテナの外を見ますが、 それ以外はコンテナの中を見てますとかややこしいだけだから 俺は頑張ったんだって自己満足してたいだけでしょ? そんなのは意味がないから辞めたほうが良い あ、そうだ。gitのglobal configがあるから、 絶対HOMEをボリュームにしないとだめなんだ。 ssh鍵の話もあったな -v $(pwd):$(pwd) -w $(pwd)を書いておけばって 実際には使ってないだろ。 コンテナ化に適してないアプリをコンテナ化しても使いにくいだけ 面白い例を思いついた > 最初のうちはエディタとかgitとかはどうしても大変に思えてホストに直接置きたくなるんだよな エディタとgitをコンテナにするとどうなるか 環境変数GIT_EDITOR、コミットメッセージなどを編集する時に使用されるエディタをしている。 まあGITが使う多数の環境変数をコンテナの中に渡す。これだけでも面倒くさくてやりたくないが、 gitをコンテナの中で動かしたりすると、エディタがコンテナの中で起動される つまり、gitコンテナの中にエディタまで入れないといけない。 さてそのエディタ、当然(?)のごとくgit連携機能がついている。 エディタからgitを呼び出されるならば、エディタのコンテナの中に、gitを入れないといけない 環境変数? おっと、gitコンテナの中でエディタを起動するならば、 エディタで使う環境変数も、gitコンテナに渡さないといけないな。 おっと、エディタからgitを呼び出すこともあるから、エディタのコンテナを実行する時も gitの環境変数を渡さないといけないな はは、乾いた嘲笑の笑いしか出てこない。こんなムダでややこしいことやって なんの意味があるんだ。 長くて全部読んでないけど、ホスト側のgitなりエディタ設定なりに依存するようなコンテナって筋悪くない? k8sとかでコンテナを別ホストに移動したら使えなくなるような気がする。 エディタが何かによるけど、vim程度ならコンテナ毎に入っててもいいのでは。有償のIDEでgit連携して使ってる人にとってはちょっとしんどいとかかな。 そりゃ単に、 普通は使わないけど入っていても良い。イメージのサイズがでかくなるだけ。 程度のことだな 普通はコンテナのイメージはDockerfileで作るし、コンテナの中のファイルを 直接修正することはない。Dockerfileの開発中とかデバッグのために 便利かもーぐらいで入れておいてもいいが、最終的には使わんので消す コンテナ内のvimは使わない。の意味がわからんやつは 勉強し直したほうが良い 本番環境って前提ならそもそも本番で稼働している設定ファイルはみだりに編集しないってのは分かるけど。 単にコンテナ内でvim使うかどうかって話だとしたら本気で意味分からん。 コンテナの中のファイルは絶対編集しないってどういうことなんだろう。良くあるベストプラクティスに書いてあるから盲目的にそうするって事だとしたら、はぁ、そうですかで話終わりにするけど。 >>238 Dockerはアプリケーションコンテナと言って、 アプリケーションをコンテナ化するもの システムコンテナと違って、コンテナの中で作業するためのものじゃない。 だから、vimという手動で作業するツールをコンテナに入れる意味はないし、 vim自体をコンテナ化しても使いづらいことは説明済み > 良くあるベストプラクティスに書いてあるから ベストプラクティスレベルの話じゃない。Dockerの使い方の基本の話。 とりあえずアプリケーションコンテナとシステムコンテナの 違いぐらい学習してから出直せ >>233 アプリケーションコンテナとシステムコンテナの違い、ですか。そうですか。 教科書にはきっとそう書いてるんでしょうね。その辺はよく知らないけど、たぶん間違ってないんだと思います。 でも、私はDockerで開発するファイルも編集します。はい。 コンテナでsshd起動してsshでアクセスするなとかいうのも基本としてあるってのは聞いたことある。 けどそんなの関係ねぇ。 実際エンジニアに開発環境としてコンテナ提供するのにsshでアクセスできないって不便でしかない。 ちなみにシステムコンテナってSolarisのzoneみたいなものかな。Linuxだと何かあるのだろうか。 >>236 コンテナの中にあるファイルはコンテナ削除すると消えるでしょ?永続化しない。 残っていてほしいファイルはボリュームでコンテナの外にだすわけだから そのファイルの編集はコンテナの外でやれば良いわけ 中にvimを入れておくのは開発中とかの一時的にしかやらんよ っていうか使いづらいでしょ? あんたvimの設定とかしてないの? デフォルト設定で使いづらいからカスタマイズするのが常識だけど コンテナの中にあるのはなんの設定もされてないvimじゃん >>237 関係ないとか言ってないで、自分の解釈が大きくずれているって考えたほうが良いよ ちょっと間違いレベルじゃなくて、方向性が大きくずれている 変な使い方をしているから、使いづらく感じるんだよ >>239 残ってほしい開発後のプログラムがあるならgitでpushしとけば良くない? 設定あんまりシナイ派だけど、仮にするとしても、それこそvimrcとかgitでpushしてるものをcloneで持ってくれば設定なんて一撃で終わらない?それじゃあダメな理由とかある? >>240 解釈がどうじゃなくて、実際便利に使えるかどうかが問題なんだけど。 どんなに正しくても実際に使い難ければ正しくてもやらない。 もちろんセキュリティーや影響は考慮するけど、その辺問題なければ基本がどうとか関係ない。 PMBOKとかAgileとか、基本に忠実にそのままやったら余計効率が悪くなって使えたもんじゃないでしょ。教科書守れば良いって思考は実用的な効率を犠牲にする。 >>241 gitは作業中断時に一時保存するための道具じゃないし、 設定しないなんて使いづらいだけだし、 いちいちcloneするとか面倒くさいことこの上ないし、 ホストでやれば普通にできることを、いちいちやらないといけないのか? 間違ってる方向に進むとこれから、あれやこれが使いにくいって愚痴るだけだぞ すでに愚痴ってそうだがw その原因はすべて間違った使い方にある 変な癖が付く前に矯正したほうがいい >>242 > 解釈がどうじゃなくて、実際便利に使えるかどうかが問題なんだけど。 便利に使うための手段を、お前がみんな捨ててるから、 (俺は不便な中で生活してるから)不便に思わないんだって言ってるだけじゃん >>242 > PMBOKとかAgileとか、基本に忠実にそのままやったら余計効率が悪くなって使えたもんじゃないでしょ。教科書守れば良いって思考は実用的な効率を犠牲にする。 お前のその考え方だと、間違った解釈をして間違ったやり方をやって 余計効率が悪くなった。PMBOKとかAgileはクソって言ってるようにしか見えないね まず教科書守ってやろう。いまお前は教科書通りのことを守らずに使いづらいと言ってる >>243 一時保存なんて利用用途で言った覚えはないけど、仮にそうだとしても何で一時保存でgit使ったらダメなの? あなたって基本に従うってことに束縛されて思考が限定されてる気がする。自分だけでそういう方針で進めるのは勝手だけど、人にやり方強制しだすと嫌われるから考え改めた方が良いよ。 新卒ならまだ良いけど。 >>244 よくわからんけど、君の言ってるようにアプリケーションコンテナの中のファイルは編集するなって事を守ると何が便利なの?物凄く不便じゃない? ローカルなホストにファイルを永続化させるよりgitにpushする方が安心感あると思わない? >>246 gitはバージョン管理するための道具であって、 バージョン管理しないならタダの保存に過ぎないから それにgit使うなら、コミットする時に、メールアドレスと名前の設定がいるだろ? gitでpushするならssh鍵が必要だろ? rootでやるわけないから、自分のhomeディレクトリがいるだろ お前本当にコンテナの中でgitでpushとかしてるんか? してねーだろ。使いづらいもんな お前はまだ初心者で、どうせgitもオープンソースものをcloneするぐらいのことしか したこと無いんだろ。基礎ができてないんだからまず教科書通りにやれと PMに教科書通りのやり方を強制されて疲弊してる現場を見てきたから経験談として話してるだけ。 教科書通りやって現場がうまくまわってるならそうすればいいよ。 というか、むしろ教科書なぞってうまくいってる現場があるならそれ勉強会とかで話してほしい。見に行くので。 >>247 > よくわからんけど、君の言ってるようにアプリケーションコンテナの中のファイルは編集するなって事を守ると何が便利なの?物凄く不便じゃない? ホストに置いたファイルを編集すればいいだけだろ。 それがコンテナの中にボリュームを通して見えてるんだから コンテナの中に入って編集する必要がない。 コンテナの中の環境を整える必要もない もっと便利なものが俺には見えてるんだが、 お前のやり方は何が便利なの? できるといってるだけで便利なんてお前は一言も言ってないよね? お前のやり方が俺は不便だと言ってる。反論は? できる、やったらだめなの?は不便であることの反論にはならない ということで、あなたのやり方を変えさせるつもりもないし、自分のやり方を変えるつもりもありません。 以上終わり。 >>247 > ローカルなホストにファイルを永続化させるよりgitにpushする方が安心感あると思わない? ホストにあればgitにpushしたいと思ったタイミングでpushできるんだが コンテナ消すと中で編集したファイルが消える。不便だからgit入れて忘れずにpushしなきゃって コンテナのファイルを直接編集すると不便だと言ってなかったか?w >>251 俺はやり方をお前に押し付けてるんじゃなくて、 正しいやり方にしないとお前が困るという事実を言ってるだけ お前はその事実に反論してない。困るのは自分だけだから 良いじゃないかって逃げてるだけだ。 >>249 そのPMが教科書通りにやってないだけだよw 教科書通りにやることが簡単だと思ってはいけない 教科書に反論するときは、教科書の場合と何が違っているかまで 理解してからじゃないといけない。 教科書になってるぐらいだから基本的には正しいんだよ。 それが当てはまらない理由を見つけない限り、教科書に反論してはいけない。 当てはまらない理由がわからないのは、理解してないってことになるんだから。 ほんとね。反論の一つでもできればまだいいんだが、 回避策はあるというだけじゃ、その方が良いってことにはならないんだよ。 全部回避策を入れないとやっていけないってことになってるんだから、 優れた方法っていうのは、回避策を使わずとも自然な形で実現できる いちいち回避策を考えなきゃやってられないってのは、 やり方が間違ってる証拠でしか無いんだよ 余談だが、アメリカではツールをただ導入するのではなく、そのツールが 想定している使い方を学習して、やり方をツールにあわせるから効率的になるらしい。 日本だとツールを導入して、自分のやり方にカスタマイズさせる。 やり方を変えようとしないから生産性も変わらないし、 ツールのカスタマイズにコストも掛かるとのこと。それと同じだ アプリケーションコンテナはyum, aptのパッケージ相当だと思ってるなぁ 基本的に使い捨てて常にクリーンなコンテナに出来るのがいいし, だからこそkubernetesとかで高い自己修復性を持てる すると、Vimのような手動カスタマイズほぼ必須のアプリは コンテナ化には適さないのか docker searchしてもVimが出てこないのが不思議だったがそういうことか そのカスタマイズ部分を, プラグインならホストからマップするか別コンテナで, 設定ファイルはホストからマウントする必要があるだろう >>257 手動カスタマイズの有無じゃないな。 プログラム本体がコンテナに隔離されているので、 コンテナの外に自由にアクセスするものは適さない もちろんプログラム本体がコンテナに隔離されているおかげで コンテナの外がどうなっていようがいろんな環境に持っていける コンテナと外部との通信は基本的にネットワーク通信で行うか ボリュームとしてマウントしたディレクトリ経由で行う ボリュームとしてマウントするから、コンテナの外がどのような OSやディレクトリ構造であっても、コンテナの中からは同じよう見える コンテナの外がどうなっていても中からは同じように見える。 Dockerの "仮想化" というのはこういう意味 (ハードウェアをソフトウェアで仮想的に作り出すという意味じゃない) もちろん不可能ではないが面倒なだけ これいわゆるイキリstaticおじさんが駄々こねて屁理屈連投してるいつもの案件じゃなくて もしかして今回に限っては、Docker業界的にも、回避策やカスタマイズの工夫するくらいなら コンテナはそぐわないからツールの使い方としてもやめてねって方向性にいつの間にか大勢が傾いてるのか docker-tramp.el 便利だー。この機能使うためだけにemacs使いになっても良いと 思うくらい。コンテナにvimやsshdインストールする必要がありません。 いまWSL使ってDockerを使っているんですが、atomでホストに置いたファイルを修正して それをイメージに反映させたいのですが、修正するたびにビルドするのが面倒です。 なのでボリュームを使ってホストのディレクトリをコンテナ内に共有しようと思っています。 Linuxではうまく動いているのですが、WSLだとうまく動かないのですが、 何が問題だと考えられますか? と、書き込んでからひらめきました。 WSLで使ってるのはWindows上のDockerなので パスの指定をC:\〜でやらないといけないきがします。 ビンゴでした! こんな感じでホストのディレクトリがコンテナから見えました。 これでWindowsのatomを使って簡単に編集できそうです。 スレ汚し申し訳ありません ↑なぜかコマンドを書き込んだらエラーになったので怪しそうな所を大文字で書きます。 docker run -p80:80 -v"$(wslpath -wa www):/var/www" -d httpd >>262 もとからvimもsshdも入れたりなんかしてないよ。 入れるもんでもないしね。 docker-tramp.elも別にいらないかな。 ファイルを修正したいならボリュームにすればいいだけだし、 sshdはdocker execを使えばいいので、 >>267 定位置にあるconfファイル等を色々いじってテストしたい時はどうしているの? >>267 コンテナ提供するアプリエンジニアにdocker exec使えって言うの? 大した負荷のかからないコンテナをサーバーって言ってアプリエンジニアに提供するときある。ポート番号ちょっと変わってるサーバだと思って使ってくれてるよ。 本人はdockerだのコンテナだのを使ってる事に気づいてない。 >>268 だからボリューム使えばいいじゃない? $ docker run -it debian cat /etc/debian_version 9.5 # ホスト上のファイルにすげかえ $ docker run -it -v/etc/hosts:/etc/debian_version debian cat /etc/debian_version 127.0.0.1 localhost 略 >>269 普通に使ってるからなぁ。 アプリエンジニアがDockerfileを書かないで誰が書くというの? アプリを動かすのに何が必要かを知ってるのはアプリエンジニアだけなんだが。 build, run, exec などを使って正しく動くコンテナのイメージを作るまでがアプリエンジニアの仕事で コンテナを動かす環境を作って指定されたイメージを起動するのがインフラエンジニアの仕事 >>270 アプリエンジニアがDockerイメージを作ってないのはおかしい。 アプリを作ってる人でないと、アプリを動かすのに必要なものは知らないんだから 「手元のマシンだと動きました」「ライブラリのバージョンが違ってるんですねー」 これをなくすためにDockerがあるというのに。仕事の分担が間違ってる。 動くコンテナのイメージ作るのがアプリエンジニアの仕事なら、結局必要なミドルをアプリエンジニアが入れる事になってそれこそインフラエンジニアの作った本番環境と差異が出てしまうと思うのですが。 まあ新規や中小規模のサービスならそれでも問題無いと思うけど。 大きい会社だとIDEしか使ったことがない、CUI触ったこと無いアプリエンジニアとか普通に居りましてですね まあその程度のアプリエンジニアはいずれ淘汰されると切り捨てるなら問題無いんですけどね。 アプリ動かすのに必要なミドルウェアをバージョンも含めて熟知してるアプリエンジニアって相当優秀だと思う。 取りあえずアプリ動く程度に適当にミドル入れまくるアプリエンジニアいるけど、それができるアプリエンジニアすらそこそこ出来る評価なんだけど。 >>272 やっぱお前使い方間違ってるわ 答えだけ言っておくね。本番環境と全く同じ環境になる >>274 > アプリ動かすのに必要なミドルウェアをバージョンも含めて熟知してるアプリエンジニアって相当優秀だと思う。 お前の会社の人間が馬鹿だってことかな? そうなんだろうな。 ミドルウェアのバージョンを把握してないで どうやってアプリが正しく動くことを保証するのか? 言ってみ コンテナの中にミドルウェアが入ってしまってるのに どうやってインフラエンジニアがミドルウェアを入れ替えるんだ? コンテナに手を入れてミドルウェアを差し替えるんか?w え、もしかして自分でミドル入れずにDockerhubに落ちてるミドル入りコンテナ使ってるクチだったりするの? コンテナの中庭ミドルが入ってしまっているのにって、じゃあそのミドルは誰が入れるの? アプリエンジニアが適当に入れたミドルをそのまま本番に使ってたりするんですか? インフラエンジニアの居ない規模の企業でアプリエンジニアが勉強して開発から本番運用までやってるって言うなら分かるけど。 インフラエンジニアいるのにミドル部分までアプリエンジニアが制御するって問題無いの? 部署をまたいだアプリエンジニア同士で宗教論争はじまってまとまらないと思うんだけど。。 最終的にはインフラ分からないアプリはフェードアウトするって意見に異論はないけど、まだその時ではないと思ってる。中小規模やベンチャーは知らない。 >>280 > アプリエンジニアが適当に入れたミドルをそのまま本番に使ってたりするんですか? なんで適当に入れるんですか? お前じゃあるまいしw >>281 お前さ、アプリケーションが動くサーバー作ったことないだろ? どうせデータベースサーバーのセットアップぐらいしかしてねーだろ? データベースサーバーのセットアップなんて簡単だもんな 設定ファイルをいじるだけ。そんな簡単な仕事はお前にやらせるよ で、アプリ開発してないやつが、どうやってアプリケーションが 動くサーバーを作れるっていうの? あぁ、どうせお前、オープンソースのアプリ動かしてるだけだっけ?w 俺が作ったアプリ、そのアプリが動くのになんのライブラリが必要か言ってみ? アプリを開発してる俺は当然わかるが、教えないからなw アプリのコード読んで必要なものを調査するとかやんなくていいよ 俺がコンテナのイメージつくってやっからさ、 お前はそれ動かすだけ。おまえにできないことはやらなくていい お前はDockerr動くLinuxマシンだけ用意してればいい ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる