Docker Part4

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/

そういうことじゃないから...
アスペムーブやめてほしい

>>818
コンテナ内で何のプロセス動かしてんの？

>>821
iaxmodemを複数個

>>822
iaxmodemだけなら小さい消費だが、
それらをfaxgettyさせてhylafaxに接続すると、
5倍くらいに膨れ上がった。

コンテナ内でのサービス再起動時にメモリが溢れるってのもよくわからんが、そのサービスの再起動の動作が特殊なのかね
再起動のための停止時には一時的にメモリ使うとか？

コンテナごと再起動するなら内部のサービスは通常の停止（あるいは強制停止？）＋起動だろうから、メモリに問題ないのはまあわかる

どっちにしろdockerというよりサービス固有の事情に見える

>>824
参考になります。

iaxmodemが始動されると、プロセスが生成されます。
その後、hylafaxを始動させて、
さらに別途faxgettyによって、両者を連結させるイメージです。（3者登場します。そのうち、iaxmodemと、faxgettyはたくさん。hylafaxとは、多対１の関係になっています。）

>>823のように、iaxmodemだけでは専有容量は僅かなんですが、
faxgettyさせると、膨れ上がります。

faxgettyは、hylafaxの関係者なので、
hylafaxがガーベージコレクトするようです。

以前テストした結果は、hylafaxの再起動時には、直ちにfaxgettyプロセスは消滅しました。

しかし、今回の環境ではそういう風にならなかったようです。
前回の環境はCentOS6でネイティブ、今回はCentOS7でコンテナです。
iaxmodemや、hylafaxのバージョンも上がっています。

いずれにしても、デーモンの再起動が特殊です。

逆に考えて、ネイティブ環境でも他の要因で同じ問題を引き起こすなら、
コンテナ環境であってよかったと思います。
docker restart faxContainerをcrontabでコンテナの外側ホストでスケジュールすれば良いのですから。

コンテナ内部でそういうデーモンの消滅のスケジュールを組むと、イメージ化されていることからタイミングの変更が困難になるので、
せっかくの利便性を損なうと思いました。
docker restart faxContainer　は素晴らしいです。

俺はどちらかといえば「Dockerコンテナは仮想マシンじゃない」方の思想に近いから
コンテナごと再起動するのは普通というか自然だけど荒れるかな

そもそも個別ソフトの事情でメモリ食いすぎるなら、ホストでOOM起こすくらいならコンテナにリソース制限するのがいいのでは

Linux上でchrootを仮想マシンと思うやつは、どうにかしている。

>>826
荒れるっていうか・・・・
その事に対してコダワリ持ってるのって一人だよね？

殆どの参加者は、そもそもどうでもいい話題で、そいつの書き込みに
反応するのは、そいつがなぜ、VMじゃないからどうのこうのと反発する
必要があるのか分からないから。

イスラム原理主義者に向かって暴力行為やめろよ。そもそも宗教なんて
どうだって良いだろ？と言うのと変わらない。

0番の親プロセスから連鎖的に、必要な環境（ディストリ標準体系）を組みた立てていくということを、「仮想マシン」とよんでいるだけですよね。
それに対して、例えば、helloworldバイナリを実行するだけなのが、非「仮想マシン」ということですよね。

前者は、systemctlによるコントロールができて楽です。
また、アプリを構成するデーモンに依存関係がる場合はとても楽です。

しかし、後者はそういう構成を組むのに別途考慮が必要になるのでお手軽さがなくなり、せっかのコンテナがとっつきにくくなってしまいます。

こういう認識を持っているのです。

>>829
必要な環境（ディストリ標準体系）と言いましたが、最初にcentos7をdocker ハブから引っ張ってきているので、標準体系にはならないですよね。

最初に何が入っているのか知らないけど、

docker run --privileged -d --net=mynetwork --name centos7 centos:centos7 /sbin/init

のようにすれば、いわゆる「仮想マシン」風の操作性のコンテナができます。

あとは、yumなどでパッケージを導入すれば、
systemctlで制御ができます。

--net=mynetwork に指定するネットワークは、自分で作成が必要になります。
LAN に対して、ポート開放もいらなくなります。
ipfilterで制御するだけです。

--net=ネットワーク名　を指定しないと、インターネットへの穴を開けてしまって危険。

ネットワークの知識がいるので、
これが唯一難しい点ではないかと思います。

個々のコンテナの中でsystemd動かしてrsyslogdでログ出してlogroteteまてやるとか無駄の極み
動かすプロセスは複数でもいいけど必要なものだけ動かすのがdocker的な考え方だよ
systemctlに頼らず起動コマンドくらい自分で調べろ

そんなにsystemd入れてinitしたいならlxcを熱烈推奨

コンテナ内でsupervisordとか動かすのはアンチパターン

gitlabはマルチプロセスを採用してるが？

>>833
ごった煮版は手軽に試したい人向けだろ

まともに使いたい人はhelmチャート版か
よそのDockerイメージ使えって事だろう

>>834
つまりマルチプロセスなら手軽に使えるコンテナが作れるわけだよね
ということはコンテナ分割と利便性はトレードオフの関係なんだよ
このことを無視してごった煮はダメだアンチパターンだとわめき散らすのは典型的な解ってない人

>>835
helmチャートとかdocker-compose.ymlで配布してくれた方がカスタムしやすい。

ログやCPU使用率も各コンテナで分かれるので見やすい
よって利便性も複数コンテナの方が上

docker-composeで試せるものが
docker runで試せるようになったからって
そんな楽になったとは思えない
むしろ不便になってる件

ほれみろ。仮想マシンのような使い方をした結果

いつものように苦しんでるではないかｗ

>>836
カスタムはある程度は環境変数とかでできる
高度なカスタムが必要なら勝手に非公式で頑張れ
ほとんどの人は公式ので十分だ

オーケストレーターごとにマニフェストを用意しなきゃならんのは面倒だ
オーケストレーターを選択するのも負担になる
マルチプロセスならdocker runだけでOK
これ以上にかんたんなものはない

>>837
コンポーズだとファイルが必要だし内容の理解も必要
docker runはファイル不要で面倒なことは考えなくていい
これ以上楽なことはない

>>838
苦しまない
むしろ楽になってる

ここで仮想マシンのような使い方をしようとして
簡単に解決できない質問が出てるのが苦しんでる証拠

>>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するだけ（引数がたくさんで辛いよぉ）←これを見なかったことにするな

>>846
仮想マシンのようなとは？

>>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ならこの問題が解決されてますか？

goofysやs3fsを特権コンテナ内で動かすとか？

https://stackoverflow.com/questions/53631567/share-a-fuse-fs-mounted-inside-a-docker-container-through-volumes


https://hub.docker.com/r/ecardoso/s3fs-nfs
https://github.com/cloudposse/goofys

あるいはnfs clientを特権コンテナ内でとか
https://hub.docker.com/r/d3fk/nfs-client/

podmanはそんな事しないと解決できませんか？

それはまた別な問題だろ

UID、GIDをホスト側とコンテナで合わせておくか
コンテナのentrypointでボリューム内のディレクトリやファイルのUID、GIDをユーザーに設定すれば良い
そうすればroot要らない

>>876
podmanの実行ユーザーのuid gidになるよ
dockerはオワコン

>>880
勝手にホストのファイルのUIDが変わったらホラーだろ
ありえねー

dockerは勝手にrootで作っちゃうからやべーのなんの

自分で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日コースも受講したみたい

k0sすげーな

>>900
投じた21万を広告収入で回収しようと必死やなｗ

くろかわのAWS 新講座のモニター受講生には、千人が殺到した。
1万円もらえるらしいけど

その中から5人と、スタッフ7人を選んだみたい

彼は日本の初心者に、クラウド革命を起こしそう！

>>900
ここで宣伝すんな。

とおもったら、 >>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でビルドとか時間かかる
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でよくね？