- 1 名前:login:Penguin mailto:sageteoff [2017/09/28(木) 14:00:45.18 ID:/4TtIqGt.net]
- LXCを使った軽量仮想環境。
これからの動向が気になるところ。 情報共有しましょう。 www.docker.io/ 前スレ Docker mao.2ch.net/test/read.cgi/linux/1374861492/
- 191 名前:login:Penguin mailto:sage [2018/07/01(日) 09:23:55.84 ID:+w2giTsy.net]
- >>179
> ということは、dockerで起動したOS内でvimが使いたければ それから通常はdockerで起動したOSの中に乗り込んでvim実行して ファイル修正とかしないからな 独自のDockerイメージを作るときに、デバッグ目的にやることはあるけど 「dockerで起動したOS」なんて考え方を持ってはいけない なぜなら、何らかのプログラムに実行環境をくっつけただけで、 作られるものは、実行環境付きのなんらかのプログラムなんだから そこにOSなんてものはないと思え
- 192 名前:login:Penguin mailto:sage [2018/07/02(月) 19:23:28.69 ID:1jLd0V1g.net]
- 今日から新しいプロジェクトでmac上でDOCKERを使う事になったんですが
最初の社内のチュートリアルに従ってHOMEBREWからインストールして起動したところ 新しいバージョンがありますって言われたので アップデート&ReLunchをしたらそのまま反応がなく アプリからダブルクリックしても起動しなくなりました MAC使うのもバージョン管理ツール使うのも初めてだらけで くだらない質問で申し訳ないんですが 考えられる解決方法はありませんでしょうか
- 193 名前:login:Penguin mailto:sage [2018/07/02(月) 20:07:43.00 ID:Eg1cE
]
- [ここ壊れてます]
- 194 名前:gm9.net mailto: 社内の人に聞け []
- [ここ壊れてます]
- 195 名前:login:Penguin mailto:sage [2018/07/02(月) 20:45:02.37 ID:Y1QFiQ2T.net]
- 普段サーバーサイドJavaとかPHP JSでウェブアプリかいてて
mac の Ruby on Rails のサーバーサイドの案件が修羅場でヘルプはいったんだけど 分かってる人はみんな忙しくて質問なげてもなかなかかえってこないんですよね でもこんな情報じゃわかるわけないですよね… 明日また社内できいてみます すいませんでした…
- 196 名前:login:Penguin mailto:sage [2018/07/03(火) 00:50:17.25 ID:1PLz+sRr.net]
- >>182
dockerは公式サイトのやり方でインストールしたほうがいいんじゃね?
- 197 名前:login:Penguin mailto:sage [2018/07/03(火) 00:52:28.72 ID:1PLz+sRr.net]
- 社内のチュートリアルが何年前に書かれたかだな
Docker Toolbox使ってたら古いやり方だな まあ社内全員やり方が決まってるなら仕方ないが
- 198 名前:login:Penguin mailto:sage [2018/07/03(火) 02:50:11.95 ID:88JNN2bg.net]
- 支給されたmac PCが他の人も使うみたいで
別の人がインストールしたhomebrewが/usr/localにはいってて 権限が変更できないくてホーム以下にインストールしたんだけどそのせいなのかなと… 1日がかりでbrew rbenv dockerの3ついれただけなんだけど どれが原因なのかがぜんぜん分からない… マックはじめてで最初の1,2時間は日本語変換や窓の最小化やコピペもわからないレベルで作業効率も悪いし Javaからruby覚えるのはすぐできると思ったけど OSが違ったりフレームワークの環境構築がこんな大変だと思わなかった
- 199 名前:login:Penguin mailto:sage [2018/07/03(火) 05:53:39.58 ID:0N07jwhz.net]
- もうmac板で質問したほうがいいのでは
- 200 名前:login:Penguin mailto:sage [2018/07/03(火) 06:10:23.01 ID:1PLz+sRr.net]
- >>187
なんの苦労もなく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を使うなと
- 201 名前:login:Penguin mailto:sage [2018/07/03(火) 06:28:04.40 ID:88JNN2bg.net]
- そうなんですね
クリーンインストールしていいかお願いしてみます 検索するとわりとホーム以下にインストールする方法とかでてきたのでいけるかと思ったんですけど コーディングスキルかわれて入ったのに初日から環境構築だけでつぶされてストレス なまじできると思われてるからしょーもない質問もしにくいし もともと大学院研究室あがりでスクラッチからかくのが好きな ブラックボックスなツール使うの気持ち悪い 古い人間だから昨今のフレームワークだらけの業界きついなあ…
- 202 名前:login:Penguin mailto:sage [2018/07/03(火) 06:35:07.67 ID:HvrBhqqa.net]
- 頭でっかちの使えないやつか現場も大変だ
- 203 名前:ネ []
- [ここ壊れてます]
- 204 名前:login:Penguin mailto:sage [2018/07/03(火) 06:54:24.03 ID:B87Zf6Sc.net]
- macやhomebrewがはじめてなのはともかく、バージョン管理ツールはじめてはないわ
それでひとりで環境構築しろってほったらかしなのも普通はありえんと思うけど 仕事ほしくて経験ないのに経験ありとか嘘かいたんじゃねーの
- 205 名前:login:Penguin mailto:sage [2018/07/03(火) 07:12:51.42 ID:ArJzlEvp.net]
- 最後にききたいんですけど /usr/local じゃなく
~〜/homeblew に homeblew をいれたんですが この blew から Docker をインストールした場合実態はどこにあるんでしょうか チュートリアルにアプリケーションからdockerを起動とあるんですけど /Application/Docker.app を起動したときにもっと新しいのがありますっていわれて 更新かけたらそれっきりだったので これが前の人がインストールしたやつだったのかな… コマンドラインの docker はホーム以下のパスになってたんですけど アプリケーションからじゃなくコマンドラインからDockerのGUIアプリ起動する方法ってありますか?
- 206 名前:login:Penguin mailto:sage [2018/07/03(火) 11:19:37.64 ID:oYvmZw+l.net]
- 解決しました
初回起動時に窓が出たのでずっと窓を探してたんですけど 右上のクジラマークからアクセスするんですね… おさわがせしました
- 207 名前:login:Penguin mailto:sage [2018/07/03(火) 13:54:24.15 ID:oYvmZw+l.net]
- 何度もすいません
docker-compose up -d で ERROR: manifest for xxx/yyy:2018zzzz not found が出るんですがどこを見ればいいのでしょうか 一応同じディレクトリに docker-compose.yml はあって yyy: image: xxx/yyy:2018zzzz と書かれています
- 208 名前:login:Penguin mailto:sage [2018/07/03(火) 14:20:45.35 ID:1PLz+sRr.net]
- >>195
普通はそうならないので環境の問題です OSをクリーンインストールしてください
- 209 名前:login:Penguin mailto:sage [2018/07/04(水) 02:14:06.32 ID:COxRspz9.net]
- rubyは導入ハードル高すぎ
よっぽど複雑なプロジェクトでもなけりゃこんな開発環境作ってるあ労力で案件終わるわ
- 210 名前:login:Penguin mailto:sage [2018/07/04(水) 06:04:14.37 ID:WJvTzUXE.net]
- 利用プロジェクトの多くが低品質だったせいでいわゆるアタリショックみたいな扱い受けてるよな
負の遺産だとかRuby巻き返しの目は潰えてるとまで言われてるし・・・Javaみたいにはならんで欲しいマジで
- 211 名前:login:Penguin mailto:sage [2018/07/07(土) 17:30:55.41 ID:fg0oR1Sy.net]
- 散々Perlディスっといてこれだもんなm9(^Д^)プギャー
- 212 名前:login:Penguin mailto:sage [2018/07/07(土) 21:06:35.47 ID:1D6mHUpx.net]
- やめて…perlは6を引き伸ばし杉た件のせいで世間との剥離からユーザー離れが尋常じゃなく
引き合いに出されると最底辺の戦いじみて嘲笑の的です…
- 213 名前:login:Penguin mailto:sage [2018/07/07(土) 21:59:02.61 ID:fg0oR1Sy.net]
- イシキダケタカイケイ
- 214 名前:login:Penguin mailto:sage [2018/07/09(月) 12:21:03.01 ID:4SJdzKl6.net]
- WSL上でDocker Engineが動くようになっていたっぽいという話
https://qiita.com/yanoshi/items/dcecbf117d9cbd14af87
- 215 名前:login:Penguin mailto:sage [2018/07/09(月) 12:48:52.62 ID:qh/Cnej+.net]
- マジかよDockerForWindows消してくる
- 216 名前:login:Penguin mailto:sage [2018/07/09(月) 13:31:43.43 ID:pfSJA2ey.net]
- もしかしてHyperV無しのHome版WSLでも動くようになってるのか
- 217 名前:login:Penguin mailto:sage [2018/07/10(火) 17:37:18.97 ID:hi/Ud89A.net]
- パブリッククラウドや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上からダウンロ
- 218 名前:ードできる。 []
- [ここ壊れてます]
- 219 名前:login:Penguin mailto:sage [2018/07/10(火) 18:37:07.13 ID:TEPxwuu8.net]
- ええやん
alpine使いにくいし乗り換えようかな
- 220 名前:login:Penguin mailto:sage [2018/07/11(水) 00:29:12.16 ID:dU5xb19g.net]
- minidebのUbuntu版みたいなヤツか
- 221 名前:login:Penguin mailto:sage [2018/07/11(水) 13:45:07.36 ID:Za+YUtMW.net]
- ええやん、なんぼなん
- 222 名前:login:Penguin mailto:sage [2018/07/12(木) 01:08:55.93 ID:Spx3HNht.net]
- 展開後のサイズは約80MB前後でminidebのようなコンテナ特化支援コマンドはさすがに無いっぽいな
Ubuntu版の公式slimとしてapt系で最新パッケージ使いたいなら(Debianのslimじゃなくて)こっちでねって感じか 野良イメージじゃない公式スリムに選択肢が増えるのは嬉しい
- 223 名前:login:Penguin mailto:sage [2018/07/12(木) 07:54:44.88 ID:2fRy1rm8.net]
- debianよりも少ないの?
- 224 名前:login:Penguin mailto:sage [2018/07/12(木) 08:05:41.95 ID:uhTdlutY.net]
- alpineで慣れちゃった。
- 225 名前:login:Penguin mailto:sage [2018/07/13(金) 09:30:31.30 ID:PFiL2FSs.net]
- debian:stretch-slimは55MB
(bitnami/minideb:stretchは54MB) ubuntu:bionicは81MBで去年から変わってないみたいだけど今回発表されたやつは何なんだいったい… 元記事タイトルにDocker Hubとあるが実は関係なくてアマとかGCPで使うimgファイルが小さくなりますたってことか
- 226 名前:login:Penguin mailto:sage [2018/07/15(日) 20:58:09.55 ID:9hWJVlJh.net]
- ミニマルすぎると一個ゲットした途端大量に依存がやって来る悪寒しかない
- 227 名前:login:Penguin mailto:sage [2018/07/15(日) 21:53:50.81 ID:rnlXfHys.net]
- ミニマムすき
- 228 名前:login:Penguin mailto:sage [2018/07/15(日) 22:11:32.38 ID:Xmkkcspf.net]
- エセロリやん
- 229 名前:login:Penguin mailto:sage [2018/07/19(木) 17:07:15.56 ID:4Cjfx+r5.net]
- 「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も統合した。
- 230 名前:login:Penguin mailto:sage [2018/07/27(金) 03:51:52.83 ID:6DSLURTJ.net]
- 訳あってソースコードからビルドしないといけない物があるんだけど、
ビルドに必要なパッケージをインストールしたくない。 だからDockerでビルドして、インストール先はDockerの外って やりたいんだけど、そういう使い方のノウハウって どこかにまとまってないかなぁ? ソースコードのディレクトリをボリュームにして make installだけDockerの外でやるのが一番かなぁ?
- 231 名前:login:Penguin mailto:sage [2018/07/27(金) 04:48:47.30 ID:1joj4I21.net]
- そういうときはmake install先のディレクトリだけ -v でマウントしとくパターンが簡単で良いね
例えば ./configure --prefix=/usr/local で入れるやつはインスコ先になる/usr/localを docker runのときに -v "/usr/local:/usr/local" って指定する コンテナでmake installまでやれるしホストもソースやビルドツールで汚れないから安心 docker公式マニュアルのどっかに書いてあった気がしたが見当たらなくなってた
- 232 名前:login:Penguin mailto:sage [2018/07/27(金) 07:25:43.45 ID:7fogAuN8.net]
- 詳しい解説サンクス
- 233 名前:login:Penguin mailto:sage [2018/07/28(土) 15:41:09.29 ID:0ikx9NUA.net]
- >>218
もう少しアイデアを発展させてみた。 このアイデアをどうするかは任せる make install、前々からの問題。何処に何がインストールされるかわからない。 基本的には--prefixで指定した所だろうけれど、確実にそうとは言い切れない make uninstall、これも前々からの問題。uninstallをサポートしているものが少ない インストールした後消すのが大変 docker、make installでインストールされるファイルは多分レイヤーの差分を見ればわかる インストールされるファイルがわかるのだから、それを消せばアンインストールになる インストールするファイルも残っているのだから、ファイル内容を比較することで アンインストール時に想定外のファイルを削除しなくてすむかもしれない
- 234 名前:login:Penguin mailto:sage [2018/07/28(土) 16:06:06.83 ID:PwMG08J6.net]
- 今はMulti-stage buildが公式実装されて>>220のアイデアを綺麗に実現できるようになったね!
ビルドコンテナのmake install結果をホスト経由せずに実行用コンテナに簡単に乗せられる ビルドコンテナも実行用コンテナも使い終わればコンテナごとすべて消せるから --prefix完全無視の無作法野良ツールにホストのファイルが上書きされることもないし make uninstall非対応でもコンテナ消せば良いだけだからゴミが残ったりもしない
- 235 名前:login:Penguin mailto:sage [2018/07/28(土) 19:21:25.29 ID:fgC/Ah69.net]
- >>221
> make uninstall非対応でもコンテナ消せば良いだけだからゴミが残ったりもしない なんかちょっと違うw インストール先はコンテナの外よ。だからコンテナ消せば良いだけってことにはならない。 どんなものでもコンテナ化して使えるかっていうと、例えば(独自ビルドの)gitコマンドを コンテナに入れて使うのは大変だと思う。カレントディレクトリを見るし、 サブコマンド次第ではカレント以外のディレクトリも見るしね インストールするファイルを知ることができるから、コンテナでビルドして生成したものを コンテナの外にインストールしてアンインストールもしやすくなるだろうと言う話
- 236 名前:login:Penguin mailto:sage [2018/07/29(日) 00:30:39.68 ID:wo8fIaJv.net]
- 最初のうちはエディタとかgitとかはどうしても大変に思えてホストに直接置きたくなるんだよな
俺もコンテナ上のgitからホストのカレントディレクトリを見る方法がわからんというごく最初の段階でつまずいた 絶対パス指定ならツールで使う主要ディレクトリを-vに指定しとけば大半普通に開けるけど カレントを含めた相対パスも単に-v $(pwd):$(pwd) -w $(pwd)を書いておけばいいという基本をDocker Hubのgitイメージページ読んで知った
- 237 名前:login:Penguin mailto:sage [2018/07/29(日) 01:53:02.32 ID:vXZjVBrz.net]
- >>223
だから大変だからホストに直接おいたほうが良いって話なんだが 例えばgit diff --no-indexでカレント(gitディレクトリ)以外を 比較したくなったら-v $(pwd):$(pwd)じゃ対応できない。 他にもgit applyとかさ -v $HOME:$HOMEにしたら動くかもしれないけど、 それでもhomeの外では使えないコマンドになってしまう。 (例えば/opt以下にgitリポジトリをcloneするツールとかさ) コマンド実行した時、特定のファイルはコンテナの外を見ますが、 それ以外はコンテナの中を見てますとかややこしいだけだから 俺は頑張ったんだって自己満足してたいだけでしょ? そんなのは意味がないから辞めたほうが良い
- 238 名前:login:Penguin mailto:sage [2018/07/29(日) 01:54:06.34 ID:vXZjVBrz.net]
- あ、そうだ。gitのglobal configがあるから、
絶対HOMEをボリュームにしないとだめなんだ。
- 239 名前:login:Penguin mailto:sage [2018/07/29(日) 01:57:06.96 ID:vXZjVBrz.net]
- ssh鍵の話もあったな
-v $(pwd):$(pwd) -w $(pwd)を書いておけばって 実際には使ってないだろ。 コンテナ化に適してないアプリをコンテナ化しても使いにくいだけ
- 240 名前:login:Penguin mailto:sage [2018/07/29(日) 02:32:06.22 ID:vXZjVBrz.net]
- 面白い例を思いついた
> 最初のうちはエディタとかgitとかはどうしても大変に思えてホストに直接置きたくなるんだよな エディタとgitをコンテナにするとどうなるか 環境変数GIT_EDITOR、コミットメッセージなどを編集する時に使用されるエディタをしている。 まあGITが使う多数の環境変数をコンテナの中に渡す。これだけでも面倒くさくてやりたくないが、 gitをコンテナの中で動かしたりすると、エディタがコンテナの中で起動される つまり、gitコンテナの中にエディタまで入れないといけない。 さてそのエディタ、当然(?)のごとく
- 241 名前:git連携機能がついている。
エディタからgitを呼び出されるならば、エディタのコンテナの中に、gitを入れないといけない 環境変数? おっと、gitコンテナの中でエディタを起動するならば、 エディタで使う環境変数も、gitコンテナに渡さないといけないな。 おっと、エディタからgitを呼び出すこともあるから、エディタのコンテナを実行する時も gitの環境変数を渡さないといけないな はは、乾いた嘲笑の笑いしか出てこない。こんなムダでややこしいことやって なんの意味があるんだ。 [] - [ここ壊れてます]
- 242 名前:login:Penguin mailto:sage [2018/07/29(日) 18:09:34.64 ID:PCsU6lV8.net]
- 長くて全部読んでないけど、ホスト側のgitなりエディタ設定なりに依存するようなコンテナって筋悪くない?
k8sとかでコンテナを別ホストに移動したら使えなくなるような気がする。
- 243 名前:login:Penguin mailto:sage [2018/07/29(日) 18:12:14.75 ID:PCsU6lV8.net]
- エディタが何かによるけど、vim程度ならコンテナ毎に入っててもいいのでは。有償のIDEでgit連携して使ってる人にとってはちょっとしんどいとかかな。
- 244 名前:login:Penguin mailto:sage [2018/07/29(日) 20:28:18.31 ID:vXZjVBrz.net]
- そりゃ単に、
普通は使わないけど入っていても良い。イメージのサイズがでかくなるだけ。 程度のことだな 普通はコンテナのイメージはDockerfileで作るし、コンテナの中のファイルを 直接修正することはない。Dockerfileの開発中とかデバッグのために 便利かもーぐらいで入れておいてもいいが、最終的には使わんので消す コンテナ内のvimは使わない。の意味がわからんやつは 勉強し直したほうが良い
- 245 名前:login:Penguin mailto:sage [2018/07/29(日) 21:46:50.04 ID:PCsU6lV8.net]
- え、普通にvim使ってるけど。何でなの?
- 246 名前:login:Penguin mailto:sage [2018/07/29(日) 21:48:26.84 ID:PCsU6lV8.net]
- 本番環境って前提ならそもそも本番で稼働している設定ファイルはみだりに編集しないってのは分かるけど。
単にコンテナ内でvim使うかどうかって話だとしたら本気で意味分からん。
- 247 名前:login:Penguin mailto:sage [2018/07/29(日) 21:51:36.18 ID:PCsU6lV8.net]
- コンテナの中のファイルは絶対編集しないってどういうことなんだろう。良くあるベストプラクティスに書いてあるから盲目的にそうするって事だとしたら、はぁ、そうですかで話終わりにするけど。
- 248 名前:login:Penguin mailto:sage [2018/07/29(日) 22:27:59.92 ID:Hv8rsH9m.net]
- >>238
Dockerはアプリケーションコンテナと言って、 アプリケーションをコンテナ化するもの システムコンテナと違って、コンテナの中で作業するためのものじゃない。 だから、vimという手動で作業するツールをコンテナに入れる意味はないし、 vim自体をコンテナ化しても使いづらいことは説明済み > 良くあるベストプラクティスに書いてあるから ベストプラクティスレベルの話じゃない。Dockerの使い方の基本の話。 とりあえずアプリケーションコンテナとシステムコンテナの 違いぐらい学習してから出直せ
- 249 名前:login:Penguin mailto:sage [2018/07/29(日) 22:32:59.80 ID:/XpMabXH.net]
- ドヤ顔で未来にエスパーしてて草
- 250 名前:login:Penguin mailto:sage [2018/07/29(日) 22:49:16.80 ID:Hv8rsH9m.net]
- 内容は間違えてないだろ?ニヤリ
- 251 名前:login:Penguin mailto:sage [2018/07/29(日) 23:31:49.15 ID:PCsU6lV8.net]
- >>234
アプリケーションコンテナとシステムコンテナの違い、ですか。そうですか。 教科書にはきっとそう書いてるんでしょうね。その辺はよく知らないけど、たぶん間違ってないんだと思います。 でも、私はDockerで開発するファイルも編集します。はい。
- 252 名前:login:Penguin mailto:sage [2018/07/29(日) 23:37:55.72 ID:PCsU6lV8.net]
- コンテナでsshd起動してsshでアクセスするなとかいうのも基本としてあるってのは聞いたことある。
けどそんなの関係ねぇ。 実際エンジニアに開発環境としてコンテナ提供するのにsshでアクセスできないって不便でしかない。
- 253 名前:login:Penguin mailto:sage [2018/07/29(日) 23:54:22.87 ID:PCsU6lV8.net]
- ちなみにシステムコンテナってSolarisのzoneみたいなものかな。Linuxだと何かあるのだろうか。
- 254 名前:login:Penguin mailto:sage [2018/07/30(月) 01:20:21.45 ID:QZl1Bega.net]
- >>237
コンテナの中にあるファイルはコンテナ削除すると消えるでしょ?永続化しない。 残っていてほしいファイルはボリュームでコンテナの外にだすわけだから そのファイルの編集はコンテナの外でやれば良いわけ 中にvimを入れておくのは開発中とかの一時的にしかやらんよ っていうか使いづらいでしょ? あんたvimの設定とかしてないの? デフォルト設定で使いづらいからカスタマイズするのが常識だけど コンテナの中にあるのはなんの設定もされてないvimじゃん
- 255 名前:login:Penguin mailto:sage [2018/07/30(月) 01:23:38.82 ID:QZl1Bega.net]
- >>238
関係ないとか言ってないで、自分の
- 256 名前:解釈が大きくずれているって考えたほうが良いよ
ちょっと間違いレベルじゃなくて、方向性が大きくずれている 変な使い方をしているから、使いづらく感じるんだよ [] - [ここ壊れてます]
- 257 名前:login:Penguin mailto:sage [2018/07/30(月) 06:34:10.24 ID:jEBEwRTJ.net]
- >>240
残ってほしい開発後のプログラムがあるならgitでpushしとけば良くない? 設定あんまりシナイ派だけど、仮にするとしても、それこそvimrcとかgitでpushしてるものをcloneで持ってくれば設定なんて一撃で終わらない?それじゃあダメな理由とかある?
- 258 名前:login:Penguin mailto:sage [2018/07/30(月) 06:40:38.62 ID:jEBEwRTJ.net]
- >>241
解釈がどうじゃなくて、実際便利に使えるかどうかが問題なんだけど。 どんなに正しくても実際に使い難ければ正しくてもやらない。 もちろんセキュリティーや影響は考慮するけど、その辺問題なければ基本がどうとか関係ない。 PMBOKとかAgileとか、基本に忠実にそのままやったら余計効率が悪くなって使えたもんじゃないでしょ。教科書守れば良いって思考は実用的な効率を犠牲にする。
- 259 名前:login:Penguin mailto:sage [2018/07/30(月) 06:42:13.68 ID:QZl1Bega.net]
- >>242
gitは作業中断時に一時保存するための道具じゃないし、 設定しないなんて使いづらいだけだし、 いちいちcloneするとか面倒くさいことこの上ないし、 ホストでやれば普通にできることを、いちいちやらないといけないのか? 間違ってる方向に進むとこれから、あれやこれが使いにくいって愚痴るだけだぞ すでに愚痴ってそうだがw その原因はすべて間違った使い方にある 変な癖が付く前に矯正したほうがいい
- 260 名前:login:Penguin mailto:sage [2018/07/30(月) 06:43:07.14 ID:QZl1Bega.net]
- >>243
> 解釈がどうじゃなくて、実際便利に使えるかどうかが問題なんだけど。 便利に使うための手段を、お前がみんな捨ててるから、 (俺は不便な中で生活してるから)不便に思わないんだって言ってるだけじゃん
- 261 名前:login:Penguin mailto:sage [2018/07/30(月) 06:44:51.91 ID:QZl1Bega.net]
- >>243
> PMBOKとかAgileとか、基本に忠実にそのままやったら余計効率が悪くなって使えたもんじゃないでしょ。教科書守れば良いって思考は実用的な効率を犠牲にする。 お前のその考え方だと、間違った解釈をして間違ったやり方をやって 余計効率が悪くなった。PMBOKとかAgileはクソって言ってるようにしか見えないね まず教科書守ってやろう。いまお前は教科書通りのことを守らずに使いづらいと言ってる
- 262 名前:login:Penguin mailto:sage [2018/07/30(月) 06:48:28.40 ID:jEBEwRTJ.net]
- >>244
一時保存なんて利用用途で言った覚えはないけど、仮にそうだとしても何で一時保存でgit使ったらダメなの? あなたって基本に従うってことに束縛されて思考が限定されてる気がする。自分だけでそういう方針で進めるのは勝手だけど、人にやり方強制しだすと嫌われるから考え改めた方が良いよ。 新卒ならまだ良いけど。
- 263 名前:login:Penguin mailto:sage [2018/07/30(月) 06:51:41.70 ID:jEBEwRTJ.net]
- >>245
よくわからんけど、君の言ってるようにアプリケーションコンテナの中のファイルは編集するなって事を守ると何が便利なの?物凄く不便じゃない? ローカルなホストにファイルを永続化させるよりgitにpushする方が安心感あると思わない?
- 264 名前:login:Penguin mailto:sage [2018/07/30(月) 06:52:59.21 ID:QZl1Bega.net]
- >>247
gitはバージョン管理するための道具であって、 バージョン管理しないならタダの保存に過ぎないから それにgit使うなら、コミットする時に、メールアドレスと名前の設定がいるだろ? gitでpushするならssh鍵が必要だろ? rootでやるわけないから、自分のhomeディレクトリがいるだろ お前本当にコンテナの中でgitでpushとかしてるんか? してねーだろ。使いづらいもんな お前はまだ初心者で、どうせgitもオープンソースものをcloneするぐらいのことしか したこと無いんだろ。基礎ができてないんだからまず教科書通りにやれと
- 265 名前:login:Penguin mailto:sage [2018/07/30(月) 06:54:15.51 ID:jEBEwRTJ.net]
- PMに教科書通りのやり方を強制されて疲弊してる現場を見てきたから経験談として話してるだけ。
教科書通りやって現場がうまくまわってるならそうすればいいよ。 というか、むしろ教科書なぞってうまくいってる現場があるならそれ勉強会とかで話してほしい。見に行くので。
- 266 名前:login:Penguin mailto:sage [2018/07/30(月) 06:55:30.13 ID:QZl1Bega.net]
- >>248
> よくわからんけど、君の言ってるようにアプリケーションコンテナの中のファイルは編集するなって事を守ると何が便利なの?物凄く不便じゃない? ホストに置いたファイルを編集すればいいだけだろ。
- 267 名前:それがコンテナの中にボリュームを通して見えてるんだから
コンテナの中に入って編集する必要がない。 コンテナの中の環境を整える必要もない もっと便利なものが俺には見えてるんだが、 お前のやり方は何が便利なの? できるといってるだけで便利なんてお前は一言も言ってないよね? お前のやり方が俺は不便だと言ってる。反論は? できる、やったらだめなの?は不便であることの反論にはならない [] - [ここ壊れてます]
- 268 名前:login:Penguin mailto:sage [2018/07/30(月) 06:55:41.00 ID:jEBEwRTJ.net]
- ということで、あなたのやり方を変えさせるつもりもないし、自分のやり方を変えるつもりもありません。
以上終わり。
- 269 名前:login:Penguin mailto:sage [2018/07/30(月) 06:57:17.09 ID:QZl1Bega.net]
- >>248
> ローカルなホストにファイルを永続化させるよりgitにpushする方が安心感あると思わない? ホストにあればgitにpushしたいと思ったタイミングでpushできるんだが コンテナ消すと中で編集したファイルが消える。不便だからgit入れて忘れずにpushしなきゃって コンテナのファイルを直接編集すると不便だと言ってなかったか?w
- 270 名前:login:Penguin mailto:sage [2018/07/30(月) 06:58:17.45 ID:QZl1Bega.net]
- >>252
俺はやり方をお前に押し付けてるんじゃなくて、 正しいやり方にしないとお前が困るという事実を言ってるだけ お前はその事実に反論してない。困るのは自分だけだから 良いじゃないかって逃げてるだけだ。
- 271 名前:login:Penguin mailto:sage [2018/07/30(月) 07:00:14.56 ID:QZl1Bega.net]
- >>250
そのPMが教科書通りにやってないだけだよw 教科書通りにやることが簡単だと思ってはいけない 教科書に反論するときは、教科書の場合と何が違っているかまで 理解してからじゃないといけない。 教科書になってるぐらいだから基本的には正しいんだよ。 それが当てはまらない理由を見つけない限り、教科書に反論してはいけない。 当てはまらない理由がわからないのは、理解してないってことになるんだから。
- 272 名前:login:Penguin mailto:sage [2018/07/30(月) 07:08:27.71 ID:QZl1Bega.net]
- ほんとね。反論の一つでもできればまだいいんだが、
回避策はあるというだけじゃ、その方が良いってことにはならないんだよ。 全部回避策を入れないとやっていけないってことになってるんだから、 優れた方法っていうのは、回避策を使わずとも自然な形で実現できる いちいち回避策を考えなきゃやってられないってのは、 やり方が間違ってる証拠でしか無いんだよ 余談だが、アメリカではツールをただ導入するのではなく、そのツールが 想定している使い方を学習して、やり方をツールにあわせるから効率的になるらしい。 日本だとツールを導入して、自分のやり方にカスタマイズさせる。 やり方を変えようとしないから生産性も変わらないし、 ツールのカスタマイズにコストも掛かるとのこと。それと同じだ
- 273 名前:login:Penguin mailto:sage [2018/07/30(月) 09:12:18.18 ID:2DtBR6Mw.net]
- アプリケーションコンテナはyum, aptのパッケージ相当だと思ってるなぁ
基本的に使い捨てて常にクリーンなコンテナに出来るのがいいし, だからこそkubernetesとかで高い自己修復性を持てる
- 274 名前:login:Penguin mailto:sage [2018/07/30(月) 09:22:21.96 ID:IG0rWwn1.net]
- すると、Vimのような手動カスタマイズほぼ必須のアプリは
コンテナ化には適さないのか docker searchしてもVimが出てこないのが不思議だったがそういうことか
- 275 名前:login:Penguin mailto:sage [2018/07/30(月) 09:55:24.40 ID:2DtBR6Mw.net]
- そのカスタマイズ部分を, プラグインならホストからマップするか別コンテナで, 設定ファイルはホストからマウントする必要があるだろう
- 276 名前:login:Penguin mailto:sage [2018/07/30(月) 16:34:35.00 ID:QZl1Bega.net]
- >>258
手動カスタマイズの有無じゃないな。 プログラム本体がコンテナに隔離されているので、 コンテナの外に自由にアクセスするものは適さない もちろんプログラム本体がコンテナに隔離されているおかげで コンテナの外がどうなっていようがいろんな環境に持っていける コンテナと外部との通信は基本的にネットワーク通信で行うか ボリュームとしてマウントしたディレクトリ経由で行う ボリュームとしてマウントするから、コンテナの外がどのような OSやディレクトリ構造であっても、コンテナの中からは同じよう見える コンテナの外がどうなっていても中からは同じように見える。 Dockerの "仮想化" というのはこういう意味 (ハードウェアをソフトウェアで仮想的に作り出すという意味じゃない) もちろん不可能ではないが面倒なだけ
- 277 名前:login:Penguin mailto:sage [2018/07/30(月) 19:40:21.56 ID:vC8FJAc3.net]
- これいわゆるイキリstaticおじさんが駄々こねて屁理屈連投してるいつもの案件じゃなくて
もしかして今回
- 278 名前:に限っては、Docker業界的にも、回避策やカスタマイズの工夫するくらいなら
コンテナはそぐわないからツールの使い方としてもやめてねって方向性にいつの間にか大勢が傾いてるのか [] - [ここ壊れてます]
- 279 名前:login:Penguin mailto:sage [2018/07/30(月) 19:45:58.92 ID:QZl1Bega.net]
- エクセルで小説書くなってだけの話
- 280 名前:login:Penguin mailto:sage [2018/07/31(火) 19:28:27.70 ID:9kOFb8Cb.net]
- docker-tramp.el 便利だー。この機能使うためだけにemacs使いになっても良いと
思うくらい。コンテナにvimやsshdインストールする必要がありません。
- 281 名前:login:Penguin mailto:sage [2018/07/31(火) 20:23:57.73 ID:GXqvrTdQ.net]
- いまWSL使ってDockerを使っているんですが、atomでホストに置いたファイルを修正して
それをイメージに反映させたいのですが、修正するたびにビルドするのが面倒です。 なのでボリュームを使ってホストのディレクトリをコンテナ内に共有しようと思っています。 Linuxではうまく動いているのですが、WSLだとうまく動かないのですが、 何が問題だと考えられますか?
- 282 名前:login:Penguin mailto:sage [2018/07/31(火) 20:24:57.09 ID:GXqvrTdQ.net]
- と、書き込んでからひらめきました。
WSLで使ってるのはWindows上のDockerなので パスの指定をC:\〜でやらないといけないきがします。
- 283 名前:login:Penguin mailto:sage [2018/07/31(火) 20:28:45.59 ID:C0KTXAUF.net]
- ビンゴでした!
こんな感じでホストのディレクトリがコンテナから見えました。 これでWindowsのatomを使って簡単に編集できそうです。 スレ汚し申し訳ありません
- 284 名前:login:Penguin mailto:sage [2018/07/31(火) 20:30:02.34 ID:C0KTXAUF.net]
- ↑なぜかコマンドを書き込んだらエラーになったので怪しそうな所を大文字で書きます。
docker run -p80:80 -v"$(wslpath -wa www):/var/www" -d httpd
- 285 名前:login:Penguin mailto:sage [2018/07/31(火) 20:33:08.23 ID:PupCkl8+.net]
- >>263
もとからvimもsshdも入れたりなんかしてないよ。 入れるもんでもないしね。 docker-tramp.elも別にいらないかな。 ファイルを修正したいならボリュームにすればいいだけだし、 sshdはdocker execを使えばいいので、
- 286 名前:login:Penguin mailto:sage [2018/07/31(火) 20:50:25.97 ID:PXAb2zrY.net]
- >>268
定位置にあるconfファイル等を色々いじってテストしたい時はどうしているの?
- 287 名前:login:Penguin mailto:sage [2018/07/31(火) 20:52:18.71 ID:WDZkbP+f.net]
- >>268
コンテナ提供するアプリエンジニアにdocker exec使えって言うの?
- 288 名前:login:Penguin mailto:sage [2018/07/31(火) 20:54:37.84 ID:WDZkbP+f.net]
- 大した負荷のかからないコンテナをサーバーって言ってアプリエンジニアに提供するときある。ポート番号ちょっと変わってるサーバだと思って使ってくれてるよ。
本人はdockerだのコンテナだのを使ってる事に気づいてない。
- 289 名前:login:Penguin mailto:sage [2018/07/31(火) 21:27:30.82 ID:PupCkl8+.net]
- >>269
だからボリューム使えばいいじゃない? $ 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 略 >>270 普通に使ってるからなぁ。 アプリエンジニアがDockerfileを書かないで誰が書くというの? アプリを動かすのに何が必要かを知ってるのはアプリエンジニアだけなんだが。 build, run, exec などを使って正しく動くコンテナのイメージを作るまでがアプリエンジニアの仕事で コンテナを動かす環境を作って指定されたイメージを起動するのがインフラエンジニアの仕事 >>271 アプリエンジニアがDockerイメージを作ってないのはおかしい。 アプリを作ってる人でないと、アプリを動かすのに必要なものは知らないんだから 「手元のマシンだと動きました」「ライブラリのバージョンが違ってるんですねー」 これをなくすためにDockerがあるというのに。仕事の分担が間違ってる。
- 290 名前:login:Penguin mailto:sage [2018/08/01(水) 05:48:16.53 ID:rxe3lfEn.net]
- 動くコンテナのイメージ作るのがアプリエンジニアの仕事なら、結局必要なミドルをアプリエンジニアが入れる事になってそれこそインフラエンジニアの作った本番環境と差異が出てしまうと思うのですが。
まあ新規や中小規模のサービスならそれでも問題無いと思うけど。
- 291 名前:login:Penguin mailto:sage [2018/08/01(水) 05:52:39.03 ID:rxe3lfEn.net]
- 大き
|
|