Docker

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

http://www.docker.io/

>>306
Dockerの中で動かしつつアプリを開発するのはやめたほうがいいよ。
デバッグ用のツールなど使いづらくなって、単に面倒になるだけ。
Docker使わずに作られたアプリ。それを動かす環境を作る時に
Dockerを使うってだけにした方がいい。

もう少し詳細に説明すると、まずWindows（boot2docker）で考えるとややこしくなるので、
ホストOSにLinuxを使っていると仮定する。

開発はDockerを使わない。IDEはLinuxにインストールする。
これだと何も複雑なことはないよね？これをメインの開発環境とする方がいい。

開発時にはDockerを使わないといったけど、テストを実行すときとか実機でDockerを使うとして、
リリース時とできるだけ同じ状態にしたいとかDockerの中だけで発生する問題とか、
開発時にDockerを使いたい時もある。

そういう時は、ソースコードのディレクトリをData volume（dockerの-vオプション）で
コンテナ内にマウントする。ビルドが必要な物（scssからcssへの変換等）は
Dockerの外でビルドしてそのディレクトリをマウントする。

ただしビルドで生成するものがバイナリ実行ファイル等の場合は、ホストOSとDockerコンテナで
使うOSが違いすぎると動かない可能性があるので、Dockerコンテナでビルドする必要がある。
本来Dockerコンテナにはビルドツール等は入れるものではない。本来はビルドするときは
>>300で書いたようにビルドツールを入れてビルドしてビルドツールを消すことになる。

apt用のキャッシュプロキシでパッケージのダウンロードは避けられるとはいえ、
ビルドのたびにパッケージのインストールとか時間的にやってなれないので、
（実行用のDockerイメージとは別の）ビルドをするためのDockerイメージを作る必要がある。

な？ Dockerを開発時に使うことは出来なくはないし、テスト実行のために出来たほうがいいんだけど
面倒で手間がかかる。だから通常の開発はホストOSでやった方がいいんだ。
ホストOSがWindowsの場合は、vagrantで作ったLinuxで開発するのをおすすめする。

話をWindowsに戻すと、おそらくDocker Toolbox（に含まれるboot2docker仮想マシン）か
boot2dockerを使ってるだろう。これはVirtualboxの仮想イメージなので更にややこしいｗ

俺としてはvagrantで作ったLinuxで開発するのをおすすめする。
Linuxで開発すると言ってもCLIコマンドを実行する程度。
samba使ってファイル共有すれば、ソースコードの修正はWindowsのエディタが使える。
Windowsに入れたIDEを使う場合は、デバッグ機能に多少制限が出るかもしれないので
俺はやってないけど、XクライアントをWindowsに入れて、Linux用のIDEを
使うとかのほうがいいかもしれない。

で、結局の所、開発時にはDocker使わない方がいいので、Windowsで
開発したいなら今までどおりDocker関係なく、Windowsで開発すればいい。

そしてWindowsで開発したアプリをDockerで動かしたい場合だけど、
boot2dockerの中は結局のところLinuxなので>>307の話が通用するとして、
問題はWindowsのソースコードをどうやってboot2dockerから参照するか？

一番簡単なのは、Virtualboxの共有フォルダー機能を使う方法だろう。
（ぶっちゃけboot2docker使ってないのでそこまで詳しくない）

注意が必要なのは、Virtualboxの共有フォルダー機能を使うと、最終的には
Windowsのファイルを見てるわけだから、パーミッション周りで苦労するのと
シンボリックリンクが使えない（頑張れば使える？）などの問題が発生する。

なのでWindows＋boot2dockerでの開発はやっぱりお薦めしないｗ
boot2dockerは、dockerコンテナを動かして。たいけど、ホストOSがWindowsで
Linuxが無いんだよ。って言う時に、おいWindowsでもdockerコンテナ動くぜｗｗｗ
これなら、dockerイメージさえあれば、どこでも同じように動く、
それがたとえWindowsであっても（ｷﾘｯ ってやりたい時だけに使うものだと思ってる。

で、長々と書いたが、Dockerを使うことで、

（ウェブ）アプリを開発する → それを動かす環境を作るのが面倒
っていう時代から、

環境まで含めた（ウェブ）アプリ を開発できる → それを動かすのは簡単！
という時代になったわけだけど、

アプリの開発自体は、今までのやり方のままでいいってこと。

今Windowsを使ってるなら、Windowsでいいし、
俺はvagrantを使って作ったLinuxの開発環境を使ってる。

実機へのデプロイやテスト等で動かすときにDockerを使うことで
同じ実行環境を簡単に作れるから "追加で" Dockerへの対応をするといい。


余談だが、
今までは、アプリエンジニアとインフラエンジニアが分かれていて、
アプリを動かす環境を作成する部分はインフラエンジニアが担当していたから、
その連携が大変でどうたらとかDevOptsとかいう言葉が出てきたりしたけど、
Docker出現で実行環境づくりがインフラエンジニアからアプリエンジニアに移ってきてるんだよ。
アプリエンジニアは大変（笑）というかインフラエンジニアの仕事が減って、クラウドを使えば
さらにコードでインフラかけるから、この2つを分ける必要ないよね？ってなってきてると思ってる。

追記

> 一番簡単なのは、Virtualboxの共有フォルダー機能を使う方法だろう。
Virtualboxの共有フォルダーは遅いという問題もある。

やり方は他にもgitでリポジトリからソースコードを持ってきたり、
結局はソースコードさえあればいいのだからNFSを使って
共有したりする方法もある。

DockerコンテナもData volumeを使わずに、git cloneしたり。
（実機で使うDockerイメージは、イメージ作成時にgit cloneするべきだろう）

git cloneするということは、（開発中の）ソースコードが
リポジトリにpushされている必要があるね。

とまあ、できるにはできるけど、開発中にDockerを使いつつ作業するのは面倒なだけ。
でもDockerで動くようにしていれば、gitリポジトリにソースコードをpushした時に
CIでDocker使ってテストを実行するなんてことができるようになる。

なげーよ

>>311
だから？

>>307-310
すごく参考になりました。
わからないことも多いですが、ざっくりと雰囲気はつかめました。
右も左もわからず暗中模索してましたが少し霧が晴れた感じです。
いただいたレスをよく読み返して学習の指針とさせていただきます。
ありがとうございました。

>>307-310

質問者と同じく開発スタイルで迷っていたので参考になりました。

> ただしビルドで生成するものがバイナリ実行ファイル等の場合は、ホストOSとDockerコンテナで
> 使うOSが違いすぎると動かない可能性があるので、Dockerコンテナでビルドする必要がある。

ただ、これに関してはホスト OS と Docker コンテナで使う OS を同じにすればいいと思うので
ホスト OS でビルドして、Docker コンテナにはコンパイラなどのビルド環境を入れないように
してもいいかなと思ってます。

boot2docker は罠ですね。

docker-machine create する場合も、Docker ホストは自動的に boot2docker になりますが、
ここを任意の OS に切り替えられると話が早そうです。

>>314
理屈上はそうなんだけどね。

でもそうすると、ホストで開発しやすいOSを使う＝コンテナも同じものに
制限されてしまうので、分けるほうが好ましい。

Dockerイメージのサイズを減らすためにAlpine Linuxを使いたいし、
開発ではホストOSにUbuntuを使っていても、awsで動かすときは
CoreOSを使うかもしれないし、柔軟に変更可能にするためにも分離さておいたほうがいい。

まあ別に開発中であれば自己責任で適当に使っていいと思うよ。
アプリ開発のためのインフラとしてDockerを使って開発環境を整備するんじゃなくて
開発作業の一貫としてDockerというツールを使うという使い方。
Dockerの中で開発するのは面倒なだけだからさ。
（あくまで ”アプリ開発" スタイルの話。インフラ・運用の話ではない）

>>315
boot2dockerは、アプリ開発者がWindowsで開発している時に
Dockerを簡単に使うためのものではなくて、

アプリは完成したものとして、そのアプリを動かしたい時に
ホストがWindowsの場合に使う手段だと思ったほうがいいよ。

わざわざWindowsをサーバーに使う人は居ないだろうから
実運用向きではなく、Docker自体の勉強で使うときとか、
Windows上にDockerコンテナでサービスを動かしてそのサービスを
個人的に使うのを目的とするとか。
（例えばHTML Validatorをローカルで動かすとか）

> Dockerイメージのサイズを減らすためにAlpine Linuxを使いたいし、
> 開発ではホストOSにUbuntuを使っていても、awsで動かすときは
> CoreOSを使うかもしれないし、柔軟に変更可能にするためにも分離さておいたほうがいい。

なるほど。そういう観点ですね。
だとすると以下の引用のようにビルド用のイメージを作るってことになると思いますが、

> ビルドのたびにパッケージのインストールとか時間的にやってなれないので、
> （実行用のDockerイメージとは別の）ビルドをするためのDockerイメージを作る必要がある。

この場合、ホスト OS とビルド用の Docker コンテナは -v でフォルダ共有してから対象ファイルをビルド。
そして、実行用のコンテナを作る際には、ホスト OS から （実行用コンテナに）ビルド済みバイナリを ADD すればいいということですね。

>>318
なので、基本的にアプリ開発中はDockerを使わない。
で、どうしても必要だと思ったときは使うけど・・・
うーん、その場合はいくつかやり方が考えられるんだけど、どれも一長一短

・docker buildでビルドする
完全に動くDockerイメージを作る途中で、ビルドも行う方法。
ビルドツールは入れて消すのでサイズも小さいし実運用でも使える。
だけど毎回ビルドツール入れるので時間がかかる。

・docker buildでビルドする（その2）
サイズは諦めてビルドツールを入れたイメージからイメージを作る。
サイズは最小にはならないが、それが問題になることは少ないだろうから一番楽かも

・実行用イメージとビルド用イメージを分ける
>>318で書いてあるやり方ね。実行用イメージは小さくて実運用でも使え
ビルドの時間も少なくなるけど、作るのが面倒くさい。
ビルド済みファイルを受け渡しする方法を作らないといけないし、
特にフレームワークがビルドとかもしてくれる仕組みだと
なんか二度手間感がある

・docker runした時にビルドする。
必然的にビルド環境も含めたイメージになる。
ファイル更新時に自動的にビルドしてくれるようなフレームワークを
使っている場合、この方が便利かもしれない。テストも実行できるし、
実運用用は別で作ることになるだろう。

ちゃんと作るならおそらく3番目が良さそうではあるけど、開発にとって便利か？
って考えると4番目かなーとも思うけど、そこまでやるのが面倒なので
開発中はDocker使わんでいいやんって思ってるわけ。

一つのDockerfileで開発にもデバッグにもテストにも実運用にも使える
万能な方法があればいいんだけど、

そういやテスト実行環境っていうのもあるんだよね。

実行環境は、実行出来るだけで良い。
デバッグは、最低限デバッグモードで起動できればいいから、その場合は実行環境用と
共通化できるがデバッグのためのツールを入れるならば、追加でなにか必要。
ビルド環境は、ビルドツールが必要。
テスト実行環境は、実行環境に加えてテスト用ライブラリやツールが必要


やっぱり、それぞれわけないとだめだよなーっていうのが現時点の俺の結論。

> なので、基本的にアプリ開発中はDockerを使わない。

まあ結局そういうことですね。今のところは運用環境として割り切って使っていこうと思います。
諸々のノウハウありがとうございました。

>>321
使わないと言っても、開発の終盤っていうか、区切りがいい時点で
実環境をDockerにしているとして、それと同じ環境でテストを
実行したいって場合には使うけどね。

ただ無理して開発時までDocker使いまくるのはちょっと違うかなーって思う。

あー、そうそう例えばウェブアプリを開発していて、データベースとして
MySQLを使う場合に、ホストOSに直接入れるんじゃなくてDocker使っていれる。
なんて使い方はするよ。

自分の場合、開発をアプリごとに新規で立ち上げた VirtualBox(Vagrant) のゲスト OS 内で
やっているので、DB を含むアプリで使うミドルウエアは ゲスト OS に入れることにしてます。

今のところ Docker の使いどころは、リモート環境へ配布するときに Vagrant 内で
Docker イメージを作ってそのままデプロイできるってあたりかなと思ってます。

>>323
> 自分の場合、開発をアプリごとに新規で立ち上げた VirtualBox(Vagrant) のゲスト OS 内で
> やっているので、DB を含むアプリで使うミドルウエアは ゲスト OS に入れることにしてます。
俺もそんな感じ。

スレ違いだけど、これをやると幾つもの仮想マシンにソースコードが分散してしまうのと、
仮想マシンをアップデートするときに、いくつもメンテナンス作業（再プロビジョンは時間がかかる）が
必要だったり、ベースとなるboxファイルを更新しても、既存の仮想マシンはそれを使うわけじゃないし
消してから作りなおせばいいんだけど、仮想マシン上にあるソースコード、全部コミットしたっけ？
消してよかったっけ？とかなって、まだ満足していない。
ホームディレクトリの設定も仮想マシン毎に必要になるし。
常に最新の開発環境が、素早く使えればいいんだけどな。

> 今のところ Docker の使いどころは、リモート環境へ配布するときに Vagrant 内で
> Docker イメージを作ってそのままデプロイできるってあたりかなと思ってます。
ミドルウェアに使うのも便利だよ。例えばいろんなバージョンのMySQLでテストするとか。

仮想マシンじゃなくてchroot環境のすごい版てことか

>>325
その通り。

OpenVZいうコンテナ技術を使ってKVMのような仮想マシンを
つくり上げるソフトウェアがあるが、これとは考え方が
違うということに注意する。

chrootが特定のプロセスだけのルートディレクトリを変更するのと同じように
Dockerが作るものは、特定のプロセス（のように見える物）であって
マシンを作っているわけではない。

じゃあGUIアプリを動かすのは
Dockerじゃうまくイカないんだな
X飛ばすしかないもんな

>>327
普通に出来てるぞ。これとか

http://fabiorehm.com/blog/2014/09/11/running-gui-apps-with-docker/

Xはクライアント・サーバーモデルなのでウェブアプリと
同じようにXアプリとしてネットワーク通信経由で動くよ。


たぶんあんたはGUIのログイン画面とかあってVNCで接続するようなものを
イメージしているのだろうけど、そもそもそれは仮想マシン的使い方であって
Dockerの本来想定する使い方じゃない。

とは言えvncserverとか入れれば出来ないことはないんじゃね？
デスクトップ環境全体を一つのアプリとして考えるという、
ChromeでOS作りましたみたいな話になるけどｗ

>>328
ホストは64bit環境だけど
32bitライブラリじゃないと動かないアプリがあるので
Dockerで閉じ込めたい と思っただけ

chrootだとXつかうのに 結構手間かかったけど
Dockerでもやっぱゴチャゴチャするんだな

まあ地味にもっと面倒くさいのは 音を出す方なんだよな

上でdllヘルがどうとかあったけどwinなら実行ホルダにdll突っ込んどけば避けられるんだよな
ハードリンク使えば容量も食わない
Linuxもようやく追いついたということか

dockerの実際の運用例の解説とかでオススメの書籍はありませんか？

>>331
釣れると良いですねぇ

>>332
運用例ならネットの方が百花繚乱では。採用事例とか書籍になるころには古くなってるようなもんだし

Docker内でファイルを書いたり消したりを繰り返すと
容量が増えていくんだけど回避策ないの？

>>335
Dockerの使い方が間違っている可能性が高い。
基本的に追加することはあっても消さない。

>>336
使ってるWebFrameworkがファイルアップロードするとテンポラリとしてファイルに落としてから処理してんだよね。
この方がメモリの使用量が少ないので、こんな仕組みは多いと思うけど。
使い方間違っているというか一般的な問題かなと。

それテンポラリのファイルを消してないだけじゃないの？

使用容量はどうやって調べたの？

>>336
マジで？
仮想環境的に使うものじゃないの？
増えたり減ったりするファイルはどうするの？
nfsとかするの？

データ用のコンテナ作るかホストの領域をバインドする

>>337が書かないから調べてみたが、削除したらデータ増えない。
watch -n 1 df -m しつつ下を実行。

・作成して削除・・・増えない
docker run -i -t busybox /bin/sh -c 'while true; do dd if=/dev/urandom of=/tmp/a bs=1M count=1; rm /tmp/a; done'

・作成する・・・当然増え続ける。
docker run -i -t busybox /bin/sh -c 'while true; do dd if=/dev/urandom of=$(mktemp) bs=1M count=1; done'

>>340
何度も言ってるけどDockerは仮想環境じゃない。アプリを作るもの。
アプリ＋それを動かすのに必要なサーバーやライブラリなどを
一つにまとめて、単体のアプリのようにするもの。

アプリのバイナリの中にデータ追加していかないだろ？
それと同じで完成したコンテナの中にデータは追加しない。
追加するときは>>341が言ってるようにコンテナの外に保存する。

じゃあ便利なchroot環境としては使えないの？

>>344
別に使えなくはないけど、そういう使い方を目的として作られたものじゃない。

まずchrootは単なる技術。ルートディレクトリを変えるだけの技術。
基本技術だからいろんな応用ができるもの。
その技術を使って特定の用途に最適化されたものがDocker。

せっかく、特定の用途（アプリケーションコンテナ）に最適化されてるのに、
それを捨てるならDockerを使う意味は無いし、
想定された用途以外に使うなら無理やりな使い方になるから、
逆に使いにくいだけだよ。

dockerの中でマウントしたら
外でマウントしたことがわかる？

永続化がよく分からなくて試行錯誤してたけど
Dockerfile内にvolumeが指定されてるとコンテナを作るときに--volumeで明示的に指定しないと
/var/lib/docker/volumesの中にランダムな名前のディレクトリがコンテナを作る度に増えていく
コンテナが残ってればdocker inspect CONTAINERで分かるけど削除してしまった場合どうやって整理すればいいの？

>>335の言ってる増え続けるってこれのことなんじゃないの？

ああvolumeをdockerの管理下に置きつつ任意の名前にしたい場合は
docker volume create --name hoge
して
docker create -v /var/lib/docker/volumes/hoge:/hoge image
にすればいいのか

あとデータ用のコンテナを作ってる例が多いんだけど
これって複数のコンテナから参照する場合だけ？
1つのコンテナからだけ参照する場合は上記のようにボリュームを作るだけでいいのかな

連投すまん
整理する方法は見つけた
https://hub.docker.com/r/martin/docker-cleanup-volumes/

あー、docker volumeってこんなんなんだ。
alpha版（？）のdocker-volumesの方が分かりやすかったな。

> コンテナが残ってればdocker inspect CONTAINERで分かるけど削除してしまった場合どうやって整理すればいいの？
docker volume ls -f dangling=true で調べられるみたいだよ。
一気に消したい時はお馴染みのアレだね。

> 1つのコンテナからだけ参照する場合は上記のようにボリュームを作るだけでいいのかな
というかそれが「コンテナでボリュームをあつかう」という一番シンプルな事例の話だと思う。

1つのボリュームを複数のコンテナから共有したい。という要求があった時に
ボリュームは複数のコンテナからマウントできないから、
データ用のコンテナを作ってコンテナの方を参照するってめんどくさい話がでてくる。

例えて言うのならUSB-HDDを複数のPCに同時に接続できないから、
専用のPCに接続して、ネットワーク経由で参照するみたいな感じなわけだけど。

>>349
それは・・・多分、docker volume実装前に作られたやつかな。
ソースコードざっと見ただけだけどファイルを直接消してるみたい。
きっとdocker volumeよりかは便利なのだと思うけど、内部を直接触ってる。


リポジトリ見に行ったらお馴染みのアレ書いてあった。
> Note about Docker 1.9 and up
>
> To delete orphaned volumes in Docker 1.9 and up you can also use the built-in docker
> volume commands instead of this docker-cleanup-volumes script. The built-in
> command also deletes any directory in /var/lib/docker/volumes that is not a
> volume so make sure you didn't put anything in there you want to save:
> List:
>
> $ docker volume ls -qf dangling=true
> Cleanup:
>
> $ docker volume rm $(docker volume ls -qf dangling=true)

なるほどサンクス

あとごめんいちいちvolume create しなくても
docker create -v hoge:/hoge image
でよかった
なんか最初やったとき上手くいかなかった気がするけど今やったら普通に出来た

docker 1.10.0 リリース

(´・ω・｀)rktってどう

もう選ぶ理由ないだろ？

>>322
なぜ？

rktを作った理由＝Dockerの問題点はもう解決済み

これからはrkt

dockerでインストールしたプログラムを
ホスト側で実行してるようにみせることはできる？

だれに？

ネットワーク経由なら

>>360
ホストに。
ホストでパイプに繋げたい

>>362
考え方間違ってる。
こういう風に使うんだよ。

（ホスト上で実行）
docker run --rm busybox cat /etc/passwd | cut -d: -f1

考え方的には、コンテナ＝1アプリと考えて
view_password | cut -d: -f1
とやってるのと同じ。

あるアプリが、"たまたま" コンテナで動いていただけ。と考える。
ファイルやソケットに関してはvolumeの機能を使えば
コンテナ内に情報を渡せる。

>>363
その発想だよね。シンプルが第一

うちの上級技術者さんもなんかやたら頑張りたがるので複雑になるばかりだわ

マルチホストネットワークのこと言ってんじゃねーの？
363は勘違いしている可能性高い

>>365
勘違いしてるのはお前だよｗ

考え方の問題もあるけど解決したい問題の内容がわからんことにはな
上級技術者さんがどんなタスク振られてるのか想像することしかできん

「こんなのDocker前提でやらせんなよ」みたいな類の難題を、泣く泣くやらされてるだけかも知らんしな

用もないのにdocker入れて大炎上してる
もちろん誰も助けてくれない

俺も全く必然性は無いけどDocker入れてやろうと考えてる
周りは技術ゼロだけどバッチ処理に使うだけだから大丈夫だろ

新しいサービスはdockerにしてるけど
一人で管理してるから俺が突然死んでも大丈夫なように最低限ドキュメントは作ってる

むしろ俺がDockerによって作られた

どっかいけ

ドッカン、ドッカン

震える〜

寒い。天使が見える。

スレたった頃から比べれば、物凄いハッテンしたよね（´・ω・｀）

ホストとコンテナのLinux OSのバージョンは同じでなければならないんでしょうか。
例えばホストが3.8でコンテナが2.6みたいなことは可能ですか？

>>377
できない。そういうことがしたかったら、KVMとか、Xenとか、ESXi とかどうぞ。

他のOSみたいにVMでdockerを動かす方法はあるけど
そもそもその質問自体dockerを理解してるか？

Docker 上で TensorFlow 使いたいんだけど

$ docker run -it b.gcr.io/tensorflow/tensorflow

ってやると notebookserver が立ち上がってコマンドプロンプトが出ない．
notebookserver とやらを起動しないでプロンプト表示させる方法誰か教えて．

ちなみに http://[自分の IP]:8888/ をブラウザで開こうとしても
ERR_CONNECTION_REFUSED でダメ．

docker run -i -p 8888:8888 b.gcr.io/tensorflow/tensorflow

docker toolbox使っているならそのデフォルトIP
http://192.168.99.100:8888/
でなんか出てきたぞ

beforehoge | hoge | afterhoge
みたいな処理のうち、hogeが
32bitアプリで、仕方ないから

Docker便利ですね

便利だけど

利用する
便利じゃん

具体的な用途は何?
今使っている物とは別のバージョンのソフトを入れるとか?

今すぐサーバー上で設定済みのWordPressを動かして！
Dockerならできます。

>>387
Dockerなら、何もしなくて設定済みのWordPressインストールされてて即実行できるの?
今すぐっていうことは、ダウンロードも必要ないんだ?

へー、ノーベル賞とかチューリング賞取れるレベルのソフトなんだね。

サーバーのコンテナの次は何だろう

WordPressっていうかWebサービスだよね
Webサービス丸々一つ持ち運べる

>>388
$ docker run --name some-wordpress --link some-mysql:mysql -p 8080:80 -d wordpress

この程度じゃ取れないと思うよ（マジレス

データの保存をどうするか、悩むところだ。
Dockerこんてなのデータ永続化はどうしてるんだろう。

DB

意外とこれを知らん奴が多いのな
Docker使ってなんかやろうと思うなら読んどけよ

The Twelve-Factor App
http://12factor.net/ja/

dockerを勝手に運用に使ってた奴が辞めて現場は大混乱だ

>>395
それだけ重要な人を失ったということだ。

社長が辞めて大混乱になるのと
同じぐらい大変なことが起きてるな。

今どきDockerを知らないレベルはヤバイ
問題は運営方法をどうするか決めずに設定だけやってる奴ら
うちの会社だとバックアップ方法がバラバラなので、どれかコンテナの運用者がいなくなると一気に危険ゾーンだわ

そいつらどんな了見で自分勝手な本番運用しやがるんだよｗ
いますぐ皆クビにしろマジで

>>395
勝手に言うか全部自分に任されてるから勝手にやってるけど
自分が今急に死んだらやばいかも
まあそうならないようにドキュメント書くようにはしてるけど

俺が死んだら、迷惑かけても、痛む心がなくなってるわけだから、どうでもいいや。

俺は嫌な思いしてないから
それにお前らが嫌な思いをしようが俺の知った事ではないわ
だって全員どうでもいい人間だし
大袈裟に言おうがお前らが死んでもなんとも思わん
それはリアルでの繋がりがないから
つまりお前らに対しての情などない

どうした突然ｗｗｗｗ

勝手に運用してるのも問題だけど、辞めるまで気づきませんでした、技術的にスキルが追いつかず引き継げませんってのもまた問題じゃね?

技術力を売りにしながら現場丸投げはダメな会社あるあるだよね〜

>>403
自分勝手な事するような馬鹿にスキルが追いつかないとかありえんからｗ
何の夢見てんだよお前ｗ

>>405
自分勝手なことをやるのは、単に
その会社のコミュニケーションの問題だろ。
そもそも勝手にできてしまうって状況が駄目だってわかる？

一人で作業をさせているってことだし、ドキュメントを
用意してないってことだし、ミーティングもなにもない
情報の共有がされてない会社だってことだよ。


Dockerがわからないのは単に技術力不足。
これはわからないほうが悪い。

>>406
> Dockerがわからないのは単に技術力不足。
こんなレベルのやつ現実の職場にはいないからｗ
おまえあれだろ？春休みの学生さんってやつだろ？
まともな会社に入れるようにせいぜい努力するこったな