[過去ﾛｸﾞ] Docker Part3 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
45(3): 2019/10/27(日)02:04 ID:gxVXDEx+(1/4) AAS
dockerってのはVMに対して何のメリットが在るのかサッパリ分からん。
海外のオープンソースソフトにはセットアップ面倒くさいやつは5G位の
ovaファイルとかドカンと置いているのがあって、DLさえすれば完全な
環境で動く奴が在るけど、何故それではなく、Dockerの方が良いのか
と言う説明は誰もしない。
71(4): 2019/10/29(火)03:22 ID:Ht/6B8LB(1) AAS
dockerは依存関係調べるのに手っ取り早くていい
Ubuntu minimalをrunさせればviすら入っていないプレーンなかんきょうですぐテストできる。メモリも食わない。アプリケーションのテストサーバとかいいよ。本番環境はまた別だけど。
76(4): 2019/10/29(火)21:47 ID:/JmTnPWP(1/2) AAS
ステートレスなアプリケーションを素早くスケールしたい場合にコンテナが有利、そんだけや
83(3): 2019/10/30(水)08:45 ID:R0o4MKxP(1/4) AAS
サーバーをペットのように可愛がるな、いつでも替えの効く家畜として扱え
AWSにも仮想マシンイメージ（AMI）があるが
必要なソフトウェアは起動してからDockerレジストリからプルすれば
カスタムのイメージは作らなくても良い
サーバーが全くインターネットにアクセス出来ない環境なら
そのプライベートネットワーク内にレジストリのミラーを作成するか
Packerを使って、必要なDockerイメージをプルした状態でAMIを作成
サーバーをペットのように扱ってるとASGも使えないだろうが、サーバーダウンは全て人間の監視を付けて対応する気か…？
115(3): 2019/11/09(土)16:33 ID:xm5wCBj4(1) AAS
「専任エンジニアが2人以上欲しい」：
Kubernetesの自前運用は難しい？ はてなの撤退事例
はてなのMackerelチームはKubernetesクラスタを自前で構築して運用していたが、撤退を選択したという。
なぜ、Kubernetesの運用を諦めて撤退を選んだのか。
はてなのMackerelチームでSREを務める今井隼人氏が語った。
https://www.atmarkit.co.jp/ait/articles/1911/08/news009.html
120(5): 2019/11/10(日)06:26 ID:KPJdW8/s(1/19) AAS
結局Dockerは何が魅力なんや？
現段階で本番で使えないのはKubernetes？それともDocker自身？
前にもちょっと書いたけどローカルの開発機をDockerで作っても
本番機で使えないのなら二度手間になるだけだから意味が無い。
>>76見たいな話は勿論、本番環境の事を言ってるんだよな？
128(5): 2019/11/10(日)10:24 ID:xpJeV64E(1/3) AAS
>>122
VMに対して、Dockerは「共通の部分のリソース(Kernel)は
共通で使ったほうが良くない？VMだとCPU上にほとんど変わらん
Linux Kernel複数動いとるやん！」
という提案にそうだねと思ったから使ってる。
メモリとCPU大量につみゃいいじゃん。て言われりゃ、あぁそうだね。
俺はやだけどね。ってだけだ。
たまに、また新しいもの覚えなきゃいけないんすか・・
とか言われることあるよ。そんなの右翼、左翼の違いと一緒じゃないの？
社内でVM陣営(右派)とDocker陣営(左派)に別れちゃったり。
省5
130(5): 2019/11/10(日)10:25 ID:KPJdW8/s(3/19) AAS
>>126
いやいや、開発「機」を作るんだろ？先ずお客さんからどのようなサービスを作るのかヒアリングして
要件定義してそれに相応しいOS、パッケージなんかを決めて本番機を念頭に「開発機」を作る。
当然VM。その後に、実際の開発を行い、
開発機の手順なりスクリプトなりをインフラの人に渡して本番機を作ってもらう。
だから開発機の構築は本番機の構築の事前準備になる。これをDockerで作っちゃったら手順も
違うし環境も違うわで、そのノウハウが全く本番機に生かせなくなる。
173(5): 71 2019/11/10(日)22:00 ID:hNrQ9NRe(1) AAS
亀です。
軽くレスおってるだけで提言なんだけど、配布とか楽なのはわかる。
compose upすればいいだけ。すごく楽。
だけど保守には向かないんだよ。docker自体にログがドカドカ出す機能はないし、中のアプリケーションから何らかのものを出さないといけない。
dockerのネットワークもEsxiとかに比べたら柔軟に構築できないし、障害対応に当たるメンツの教育コストも考えなきゃいけない。
立ち上げだけ上手くいくテスト環境にはいいけど本番環境はやっぱり難しいと思う
205(3): 2019/11/16(土)05:07 ID:SNHSHops(2/2) AAS
出来ました
なぜnoneになってしまってたのだろう･･･
あと､ググっても出てこないのだが､
docker内でsudo apt install unzipやろうとしても
パスワードが分からなくて出来ません｡
デフォルトパスワードってなんですか？
パス設定してないのだが
214(9): 2019/11/18(月)02:59 ID:fwqLgOPw(1/5) AAS
これやってMozc/Androidをインストールしようとしてます｡
https://github.com/google/mozc/blob/master/docs/build_mozc_in_docker.md
Set up Ubuntu 14.04 Docker container
$mkdir ubuntu14.04 && cd ubuntu14.04
$curl -O https://raw.githubusercontent.com/google/mozc/master/docker/ubuntu14.04/Dockerfile
$sudo docker build --rm -t $USER/mozc_ubuntu14.04 .
$sudo docker run --interactive --tty --rm $USER/mozc_ubuntu14.04
をやりました｡
次に､
$sudo docker run -it --name docker1 012345abcde /bin/bash
省9
274(4): 2019/11/21(木)09:29 ID:N+RiIX1p(2/6) AAS
ここ本当に実務で使ってる人居るの？
CICDはデプロイ、リリースする時の話
開発時ABCDEとかいろんな機能を同時に開発される
このうちBCEだけリリースするとなったらCICDで、と言う話では？
（元のブランチにBCEをインテグレートする）
ABCDEが混在してるローカル環境では当然ローカルで開発して
ローカルでテストする。
単体試験も通らないのにCICDとかある訳無いじゃん。
>典型的なビルドパターンの話かと思ったら
>いや開発中の話って言い出すから
省2
297(5): 2019/11/24(日)10:15 ID:gVQp9hOZ(1/5) AAS
>>286
※亀
※プロンプト>はホスト、$はコンテナ内
> vim Dockerfile
L69はコメントアウト
#RUN cd nacl_sdk && ./naclsdk install pepper_49
※一旦これでBuildして最後まで抜ける
> sudo docker build --rm -t $USER/mozc_ubuntu14.04 .
※rootでログイン
省10
301(4): 2019/11/24(日)14:53 ID:9LX+LUV7(2/15) AAS
これがDockerfile修正の差分な。
python build_mozc.pyまではしとらんが、pepper_49 インストールできたし動くやろ？
httplib2 もいらん、L18-19のコメントアウトもいらん
もう少し解析すれば、こんな意味不明な修正じゃなくてもっとマシなやり方がありそうだが。
$ diff -u Dockerfile.old Dockerfile
--- Dockerfile.old 2019-11-24 14:48:42.027977900 +0900
+++ Dockerfile 2019-11-24 14:46:08.989689200 +0900
@@ -66,6 +66,9 @@
## NaCl SDK
RUN curl -LO http://storage.googleapis.com/nativeclient-mirror/nacl/nacl_sdk/nacl_sdk.zip && unzip nacl_sdk.zip && rm nacl_sdk.zip
省5
330(4): 2019/11/29(金)00:00 ID:ebGLF78J(1/3) AAS
宮下剛輔が、テスト駆動開発(TDD)で使う、Ruby のRSpec を真似て作ったツール、
Ruby製のServerspec を使って、
CI/CD ツールのCircleCI, TraviceCI などを使って、Docker のテストをやりまくれば良いのでは？
364(3): 2019/11/30(土)14:30 ID:Se1bf1fg(10/14) AAS
>>361
OSの仮想化技術なんだから当然だろ？
君は何の技術か意味を理解しているの？
何かこういう書き込み見てると、コイツ何処まで理解して話してるんだろうな？と言う気がするね。
2つの全然違う技術をゴチャにしている
>>360
/etc/hosts
IPアドレス 起動したOS
http://起動したOS
> docker run -d -p 8080:8080 image
省14
382(3): 2019/12/01(日)01:54 ID:J+24ZJpj(3/3) AAS
>>374
> 逆にdockerは古いビルドイメージ取っとくだけでスゲー苦労するじゃん
何も大変なことはない。（プライベート）リポジトリにpushするだけ
OVAファイルは？いちいちファイル転送してダブルクリックするの？
dockerならrunするだけで新しいイメージも古いイメージも自由に使えるのに
> 仮に、本番機を誰でもエクスポートしてローカルのVMなんかで
VMはエクスポートするしか無いんだよなｗ
ソースコードからビルドするということができない
dockerでエクスポートなんかシない
リストに追加
省10
483(3): 2020/01/19(日)19:15 ID:6YirC2HC(1) AAS
Docker Hubのさぁ、Automated Buildでさぁ
GitHubのREADME.mdを中途半端に持ってくるのやめてくれないかな
リンクあるだけでいいだろ、あれ誰が嬉しいんだ？
592(4): 2020/02/02(日)10:31 ID:cuMP7GqL(3/27) AAS
>>591
代案つーか、コンテナ技術って時期尚早じゃね？サービスを構成する鯖が
10台20台程度なら入れない方が良いと思う。いつの日か>>557が書いたように
完全にコンテナだけ見ていればOKになるなら入れても良い。
例えば10コアのCPUを10台用意して、30個をフロントWEBに、20個をバックエンドに、
30個を同期サーバ、10個をその他、残りはautoscaling用、1CPU=1コンテナとか
このレベルで意思決定が出来て、そのとおり動くならマイクロサービスは素晴らしい
といえるけど、現状そうなってないんだろ？コンテナが物理サーバーに対して透過的
見えるレベルに到達してないつーか。
いつかそうなるんだろうけどね。
省1
627(4): 2020/02/02(日)17:56 ID:vTMq3yW0(2/5) AAS
俺がいない間に随分と進んでるなｗ
>>592
> 代案つーか、コンテナ技術って時期尚早じゃね？サービスを構成する鯖が
またDocker（コンテナ）とKubernetes（クラスタ）を
ごっちゃにしてるアホがいるのか
サービスでデプロイした経験ないのか？
Wordpressぐらいしたことやるやろ？できるか？何が必要か想像つくか？
PHPだぞ。apache使うとするよな？そうするとmod_phpがいるぞ。
ライブラリ使ってたらPHPモジュールも入れないとだめだぞ
一発勝負で正しく作れるか？んん？
省6
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 2.213s*