Docker Part4
レス数が900を超えています。1000を超えると表示できなくなるよ。
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/ >>837
コンポーズだとファイルが必要だし内容の理解も必要
docker runはファイル不要で面倒なことは考えなくていい
これ以上楽なことはない ここで仮想マシンのような使い方をしようとして
簡単に解決できない質問が出てるのが苦しんでる証拠 >>840
Dockerfileでたくさん面倒なことしてるだろ
docker-composeはyamlファイルを持ってくるだけ
Dockerfileと違って中身を理解する必要がない！（笑） では分割コンテナでいいから質問者が求める構成を提示してみて
できないならそれはマルチプロセスコンテナが悪いのではなく単純に難しい構成だったというだけだな
1日待ってあげるからどうぞ >>843
gitlabはdockerhubからpullするだけで使えるということも知らんのか
dockerfileなんか書かんよ >>844
論点がずれてる
単一であっても分割であっても
仮想マシンのような使い方をするのが間違ってると言ってる >>845
docker-composeもdockerhubから勝手にpullしてくれるってことも知らんのか？
誰かが作ったdocker-compose.ymlをgitとかからpullするのが増えるだけやろ
docker-composeは、docker runだとたくさん引数を指定するのが
めんどくさいってのを解決してくれるものだ
docker runするだけ（引数がたくさんで辛いよぉ）←これを見なかったことにするな >>847
docker composeはファイルが必要 >>848
質問者が言ってるだろ
> 818 名前：login:Penguin[sage] 投稿日：2020/11/12(木) 04:08:50.18 ID:tXLSOFMO [1/7]
> Dockerコンテナ内のcrontab -eで、デーモンのスケジュール再起動を任せたら、
> oom Killerでホストが倒れてしまった。ホストにsshログインもできない状態に陥って大変あせった。データもっていかれるかと思ったが、再起動でなんとか復帰できた。
↑これが仮想マシンのような使い方
↓これが本来のDockerの使い方
> そこで、ホストにおいて、docker restart コンテナとするようにした。
> そうすると、メモリ溢れなく、安全にコンテナごとデーモンの再起動ができたので報告しておく。 >>849
ファイルをコピーするのが難しいって話をしてんの？ｗ
docker runで引数をたくさん指定するのと、その引数がファイルに全部書かれてるから
docker-composeするだけで起動できるのと、どっちが簡単ですかって話なんだが docker-composeも使えない男の人って… Linuxでdocker使ってるんですけど
volumeマウントするとホスト上のroot権限のディレクトリができるのですが
対策ありますか？
nginxです >>818
そのものズバリの「?oom-kill-disable」なんつーオプションがあるらしいね。
https://knowledge.sakura.ad.jp/5118/
--memory=1024mb
コンテナにこの辺掛けたらどうなるか、興味深いところ。
ホストが死ぬなんてことはなくなるのでは。 また、仮想マシン厨が出てきたw
Docker, Kubernetes は、immutable だから、状態を持ってはいけない。
サイボウズのkintone なんか毎日、破棄して作ってる
Heroku 相当のPaaS、AWS Elastic Beanstalk のRuby, Docker などの基本。
OOM killer も、k8s の基本
そもそも、k8sのetcd は、OS の/etc の事 >>854
oom killerせず、スワップも貧弱なら、
oom-kill-disableすれば、「盾と鉾」の話になりそうですね。
いろいろと興味深いオプションありますね。 >>855
OOM killer も、k8s の基本 って
どういうことだろう？ OOM killer を無効にしてメモリが足りなくなったら
メモリが足りなくなったプロセスが落ちるだけの話
一般的には今まさに動いてるプロセスになるだろう k8s のLimitRange で、各Pod のCPU, メモリの使用量を制限すると、
PodがOOM killed される
それで、Pod数が足りなくなるから、また再作成されて、また終了させられる だから、仮想マシン厨がやってる事は、
OS の機能を、コンテナ内でやろうとしているだけの話
Docker, Kubernetes、
Heroku 相当のPaaS、AWS Elastic Beanstalk などに書いてある OOM killerに殺されて転生したらPodでした 全て一つのマシンに配置する事も
データベースだけ別のマシンにする事も自由自在なのがコンテナの良いところ K8S使うまでもないんやけどコンテナで運用したいんやがどこのサービスがええのん？ >>864
一台しか使わないならdocker-composeでもよくね？
それともマネージドサービスが使いたい？
ならコントローラーが無料のサービスを選ぶとよい
Amazon ECSは無料
Azure Kubernetes Serviceも無料らしい
Google Kubernetes EngineはZonal Clusterなら一つは無料らしい dockerコンテナ一つで終わるなら、dockerをデーモンで起動すればいいし
複数のコンテナが必要なら、docker-composeだろうな 当然、Heroku 相当のPaaS、AWS Elastic Beanstalk
Docker, Ruby もある Fargateがベスト
K8Sなんて大げさなものは超大規模システムでしかメリットがない
アプリをお手軽にパッケージングしてお手軽にデプロイする基盤がほしい
でもDockerホストは管理したくない
大半のユーザーが求めてるモノはそれだけだ 自分でオーケストレーターをインストールするのか？
k3sなら単一ノード構成でも使えるしセットアップも比較的楽
より機能の少ない物ならNomad, Docker Swarm等もあるが
使いやすいかは知らん
HerokuもDocker使えるから
自分でオーケストレーターの管理したくないならありかも Herokuはvolume使えないんだろ
クソじゃん 古いプログラムソースのファイルアクセスをクラウドストレージアクセスに書き換えるのがめんどくさい
なんかファイルIOをフックしてクラウドに転送する魔法ないの? >>872
クラウドストレージが何を指してるのか分からないけど
単にホストがストレージをマウントしてDockerのvolumeか
mountで逃がせば良いんじゃね？ >>873
ホストに依存したくない
コンテナの中だけで解決できないか コンテナにrcloneでも入れればいい
個人的にはそういうものはホストに入れるけど dockerでボリュームマウントするとroot権限でしか編集できなくなるので面倒なのですが
podmanならこの問題が解決されてますか？ それはまた別な問題だろ
UID、GIDをホスト側とコンテナで合わせておくか
コンテナのentrypointでボリューム内のディレクトリやファイルのUID、GIDをユーザーに設定すれば良い
そうすればroot要らない >>876
podmanの実行ユーザーのuid gidになるよ
dockerはオワコン >>880
勝手にホストのファイルのUIDが変わったらホラーだろ
ありえねー dockerは勝手にrootで作っちゃうからやべーのなんの 名前付きボリュームはDockerfile内にVOLUMEで指定がなければrootになる
https://github.com/docker/compose/issues/3270#issuecomment-543603959
でもディレクトリがrootでもパーミッションがworld-writableなら
書き込みはできるんじゃね？
バインドマウントはホストのUID、GIDがそのまま使われる AWS Fargate は、Elastic Beanstalk(PaaS)のAuto Scale までも、全自動にする奴。
企業向けの究極
確かに、first choice に、Fargateを勧めている。
昔は、Elastic Beanstalkだった
AWSの動画を見ると、
Lambda, コンテナ、仮想OS の並び順で、
コンテナを仮想OS のように勘違いする人が多いけど、
あくまでもコンテナは、Lambda・仮想OSの中間だと言ってる
Elastic Beanstalkの図を見ると、
以下のようなOSの機能は、コンテナ外にあって、Amazonが提供している
ロードバランサー・Auto Scale
SNS による通知、CloudWatch による監視・アラーム
Aurora などのデータベース
仮想マシン厨は、これらをすべてコンテナ内に実装しようとしている ユーザーを、docker group に入れるのだろう。
k8s には、Namespace, Role もある
Docker の欠点は、IP・Port(NAT・ポートマッピング)でアクセスするので、
ポート80などが1つのサービスに対応付けられてしまう
k8sでは各Pod に、IPが割り当てられるので、
NAT無しで、異なるNode(ホスト)上のPod間通信もできる 関数で実装できるならコンテナもいらねえ
クラウドなら関数、でないならコンテナ、永続層はマネージドって感じか
関数とコンテナを意識せず透過的に扱えるプラットフォームが普及したら、コンテナもオワコン >>887
ECSならELBに登録するのが一般的な設計パターン
ロードバランサーが必要になる代わりに、空きポートがランダムに割り当てされるので、衝突することが無い
awsvpcネットワークモードにすればタスク毎に独立したIPになるが、
EC2の場合は1つのタスク毎に仮想ネットワークインタフェースが必要
>>889
Fargateは
料金がEC2より少し高い
EBSボリュームは利用出来ない
特権が必要な設定は利用不可
などの制約があるので万能ではない
ロードバランサーの存在は結局意識する必要があるのも何かね 何れにせよロードバランサは使うので問題ない
ECSより無駄がないし管理コストを考えたら安い
特権は別に要らんかな
永続化はマネージドに逃がすからボリュームもイラネ
Fargateが最強
Fargateならcomposeも使えるのがイイね 運用まで真面目に考えるとdockerもそんなに便利なもんじゃないね
アプリ開発〜デプロイは楽になるんだろうけど
それって全体の2割にも満たないだろう 全体の2割が解決すれば十分じゃん
アホなの？
なんつーか、ハンマーで木を切断できなければ
便利なもんじゃないって言ってるみたいだｗ 問題は2割を多少楽にするために余計な厄介事まで持ち込んでくること 全体の2割を解決するために5割の新しい問題を持ち込んでるのが実感。 厄介事じゃなくて、技術力ないやつが切り捨てられること
が正解だろ？厄介事なんてないよ クラウドリソースを使わせたいベンダの戦略にまんまと載せられてる
今更選択肢間違いでしたとも言い出せないから苦しいなと思いつつ使い続けるしかない マジでそれ！
Dockerなんかどっか行っちまえ！ くろかわこうへい、2019/7
今から追いつくDocker講座！AWS ECSとFargateで目指せコンテナマスター！〜シリーズ1回目〜
https://www.youtube.com/watch?v=DS5HBTMG1RI
彼は年明けから、会員制のAWS の初心者向け講座を始めるらしい。
彼は、Amazon の21万円のAWSの3日コースも受講したみたい >>900
投じた21万を広告収入で回収しようと必死やなｗ くろかわのAWS 新講座のモニター受講生には、千人が殺到した。
1万円もらえるらしいけど
その中から5人と、スタッフ7人を選んだみたい
彼は日本の初心者に、クラウド革命を起こしそう！ とおもったら、 >>1 に宣伝もしくはそれに準ずる投稿を禁止と書かれていない…。 ただの一般人の動画に金払うくらいならネットで十分だわ 壊れたラジオくんは動画から拾ってきた単語を並べるだけのアレだったのか...
サロンの食い物にされててかわいそう FargateはDockerイメージをキャッシュ出来ないっぽい
クソでかいイメージ動かす時は起動に時間かかるかも
ホストにDockerイメージがキャッシュされないので、
NATゲートウェイ経由でイメージをダウンロードすると起動のたびにコストがかかる
設定ミスしたECSサービスを放置することによるクラウド破産に注意
一応、ECRにイメージをミラーしてVPCエンドポイント経由で使う事で
課金を回避は可能
How we lost $800/mo with Amazon ECS Fargate - DEV
https://dev.to/raphael_jambalos/secret-costs-of-ecs-fargate-4j3b
↑は500MBのプルが2、3分おきにされる状態を1ヶ月放置して16TB分の料金を課金された人のお話 アマゾンのクラウド関係はベゾスにとって打ち出の小槌やな。
そらゲイツ抜いて世界一の金持ちにもなりますわ。 Amazon は不況の株高で、1年で5割ぐらい株価が上がっているのでは？
100兆円どころではなく、日本の総時価総額と同じ、500兆円ぐらいまで上がりそう ファイル編集した後にイメージ消してから
Docker-composeでリビルドしてイメージ作ってコンテナ立ち上げても
ファイルの中身が古いまんまなんだけどどういうこっちゃ…… ボリュームマウントしてるとか
消したつもりで消してないとかだろ CIでビルドとか時間かかる
CIは最終結果を作るためにやるもので
普段使いするものではない https://www.docker.com/blog/docker-compose-for-amazon-ecs-now-available/
docker-composeでEC2もデプロイすんの？
EC2のすべての機能が使えないLeaky Abstractionの悪寒
劣化版CloudFormation (Terraform)みたいになってるのでは？
このツールで出来ないカスタマイズがしたければTerraformとか使えってこと？ Dockerはホストに依存しないからカスタマイズなんていらないんだよね
依存してるなら開発者のスキル不足 AWS CloudFormation なら、
Terraform, Packer,
Ruby 製のkumogata, chef, Cookpad 製のitamae >>916
GPU付きインスタンスの例とか書いてるじゃん VPCとかIAMロール、ALB、セキュリティグループの設定は流石にこれでは出来まい
スポットフリートも非対応っぽい
2つのツールを使い分けるぐらいなら
もう全部Terraformでよくね？ リンクされているAWSのブログを見たらIAMロールは新規で作れるようだ
ツールの目的は既存のdocker-composeを出来るだけ変更せずECSで動かすことらしい
既存クラスターやロールの利用も可能だがそれだと省力化の意味が薄れるな
ボリュームはEFSになるようだ
対応してないファイルシステムの機能が必要なくて
速度がEBSに劣るのを許容できれば使えると思う >>921
なんで？コンテナでデプロイするの便利じゃん
GPUで機械学習とかやりたい人居るだろ？ >>922
デプロイ先を選ぶようなコンテナはコンテナでなくていい NVIDIA Container Toolkitを作ったNVIDIAが馬鹿だとでも？ EC2一台で動かすようなシステムなんだけど、git pullでソースコードもdockerfile docker-composeも持ってきて、ソースコードマウントして動かして大丈夫？
セキュリティ的に問題あります？ 問題あるかもしれないしないかもしれない
パラメータとソースコードの内容次第 AWS CodePipeline(CodeCommit/CodeDeploy)
EC2 に、yum install -y ruby と書いてあるから、Ruby 製
CircleCI, Terraform → ECR
と同じ >>929
そんなことしても
面倒くさいだけで節約にならなくね ディスクは…レイヤーの掃除しなくていいかな？その程度の差だね
面倒くさくはないよ
この程度ならワンライナーsshできる
K8Sよりよっぽど楽だ 定期的にdocker image pruneすれば良くね？
何日以内は残すとか指定も可能 >>928
開発中はマウントして作業してるので、そのままの構造で行きたいのと、masterにpushしてpullするだけのgitコマンドで完結するので楽かなぁと... >>934
それでいいよ
というかターゲットマシン決まってるならまじでDockerは要らない
不要な管理対象スタックが増えるだけ
どこで動かすかわからないならdockerのほうがいいけどな >>935
確かにそうですね
一応、本番機にはdocker入れるだけでPHPやらnodeやらは直接入れなくてビルドするだけでいいのでその辺は楽かなと思ってますが >>936
稼働中のPHPサーバーでgit pullとかcomposer installしたらエラーになりまくる
デプロイ中はサーバー停止が必要
そんなテキトーな管理でも怒られないようなサービスなら別に良いけど
それが嫌なら、ディレクトリ2つ作って入れ替えるデプロイツールとかが必要になるが
そこまでするぐらいなら、俺はマネージドのコンテナオーケストレーターとかDockerレジストリを使う >>925のやり方ならオーケストレーションもレジストリも要らないね
余計なものを持ち込まないことが成功の鍵
KISSの法則
YAGNIの法則 趣味ならともかくまともなサービスならデプロイの度にダウンタイムは許されない レス数が900を超えています。1000を超えると表示できなくなるよ。
