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/

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でよくね？

リンクされているAWSのブログを見たらIAMロールは新規で作れるようだ

ツールの目的は既存のdocker-composeを出来るだけ変更せずECSで動かすことらしい

既存クラスターやロールの利用も可能だがそれだと省力化の意味が薄れるな

ボリュームはEFSになるようだ
対応してないファイルシステムの機能が必要なくて
速度がEBSに劣るのを許容できれば使えると思う

>>918
コンテナでやることじゃない

>>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
と同じ

>>925
なんで最初からイメージに入れない？

ディスク消費を抑えるため

>>929
そんなことしても
面倒くさいだけで節約にならなくね

ディスクは…レイヤーの掃除しなくていいかな？その程度の差だね
面倒くさくはないよ
この程度ならワンライナーsshできる
K8Sよりよっぽど楽だ

定期的にdocker image pruneすれば良くね？
何日以内は残すとか指定も可能

>>932
面倒

>>928
開発中はマウントして作業してるので、そのままの構造で行きたいのと、masterにpushしてpullするだけのgitコマンドで完結するので楽かなぁと...

>>934
それでいいよ
というかターゲットマシン決まってるならまじでDockerは要らない
不要な管理対象スタックが増えるだけ
どこで動かすかわからないならdockerのほうがいいけどな

>>935
確かにそうですね
一応、本番機にはdocker入れるだけでPHPやらnodeやらは直接入れなくてビルドするだけでいいのでその辺は楽かなと思ってますが

>>936
稼働中のPHPサーバーでgit pullとかcomposer installしたらエラーになりまくる
デプロイ中はサーバー停止が必要
そんなテキトーな管理でも怒られないようなサービスなら別に良いけど

それが嫌なら、ディレクトリ2つ作って入れ替えるデプロイツールとかが必要になるが
そこまでするぐらいなら、俺はマネージドのコンテナオーケストレーターとかDockerレジストリを使う

>>925のやり方ならオーケストレーションもレジストリも要らないね
余計なものを持ち込まないことが成功の鍵
KISSの法則
YAGNIの法則

趣味ならともかくまともなサービスならデプロイの度にダウンタイムは許されない

いや思ったよりぜんぜん許されるよ

銀行とかゲームとかしょっちゅうメンテナンスしてるだろ

銀行とかゲーム以外は許されない

固定回線や携帯電話の回線交換機やパケット交換機がメンテナンスで停止する事あるんですか？
はい論破

まともなシステムから「システムメンテナンスのお知らせ」的なメールがよく来るな

じゃあ5ch今から止めていい？

いいよ、ついでに荒れ放題のLinux板閉鎖で頼む

>>927
に書いたように、

CodePipeline は、Ruby 製だから、EC2 に、Rubyが入る。
200MB ぐらい使うのでは？

サイズなど気にしていたら、キリがない

>>925
> EC2一台で動かすようなシステムなんだけど、git pullでソースコードもdockerfile docker-composeも持ってきて、ソースコードマウントして動かして大丈夫？

シェルスクリプトでも動かす気？
まあ
KISSの法則
YAGNIの法則
ならシェルスクリプトしかありえないけど

EC2に言語とかライブラリとか色々入れないと動かないなら
KISSの法則
YAGNIの法則
でDocker使うといいよ

Dockerだけ入れれば動くからね

>>948
正解

毎回本番サーバーでソースコードの入ってるディレクトリをマウントしたり
npmのパッケージインストールしたり
ビルドしたりするなんてシンプルじゃない

AWSならECSとECR使えば良くね？

git pull && make

シンプルイズベスト

ビルド後に再起動必要じゃね？

makeでやる

M1対応まだかな

クライン【KLEIN】の動画を、この順番で見るとよい。
他にも、AWS の動画なら、くろかわこうへいが神！

2020/5
【AWS 入門】EC2とDockerでHello Worldしよう
https://www.youtube.com/watch?v=HvrIPQ77xRY

2020/8
【AWS 入門】ECS(Fargate)とECRで楽々コンテナからHelloWorldしよう！
https://www.youtube.com/watch?v=2_FxLp9xgmo

AWSが流行ってるけどお金かかる？

>>956
自分がAWSを作ったら、無償で提供すんのか？

>>956
LightSailでいいんじゃね？

Lightsail コンテナ: クラウドでコンテナを実行する簡単な方法
↓規制でURL貼れないのでURLを少し変えた
https://aws.アマゾン.com/jp/blogs/news/lightsail-containers-an-easy-way-to-run-your-containers-in-the-cloud/

スポットインスタンス活用でも良いが
難易度は高い

仮想OS 1つで、1日300円。月1万円

企業向け

Dockerもそろそろオワコンかもな
猫も杓子も静的サイト、関数サービス、マネージドDB

>>960
Dockerの本来の対象である
アプリケーションサーバーはどこに行った？ｗ

サーバー用途は諦めて、ユーザーへのアプリ配布に活路を見出そうぜ

Dockerはアプリケーションサーバー用途が一番適してるんだって
アホなのかな？

一番かは別として、コンテナにしてデプロイ〜はよくやる動作ではあるだろ

>>961
静的サイトと関数に別れた

>>962
それだと利益が出ないんだよな
オンプレミスでもライセンス料取れるほど価値のあるサービスって難しいよ

折角今まで孤軍奮闘してきたDockerがイメージ配布で立て直そうとしたのに
横から急に出てきた巨大資本に掠め取られるんだもんな
そりゃやってられんわ

Dockerはマイクロソフトあたりに買収されれば安泰じゃないか

>>965
関数ってなんだ？
関数だけでアプリケーションサーバーが作れるのか？
railsを関数とやらで動かしてみてくれよ

>>967
> Dockerがイメージ配布で立て直そうとしたのに
なんか勘違いしてそう

Dockerの言うイメージ配布というのは
自社開発アプリのデプロイという意味だぞ

なんかフリーソフト配布みたいなものと
勘違いしてる感じがするんだよなｗ

>>969
関数は関数だよ
ラムダとかAzureFuncとか

いわゆるFaaSってやつだな
今や世の中だいたいこれで動いてる

>>970
pullにお金を取るようにしようとしたのは有料サービスでお金稼ぐ為じゃないの？

いやだからrailsをその関数で動かしてみてくれと言ってる

>>973
6 時間あたり 100 件の pull という制限で金稼げると思うの？
6時間すぎればまた100個pullできるようになるというのに

>>974
動かす必要がない
railsみたいなフレームワークを不要にするのが関数
関数を動かすのにいちいちフレームワークを導入するか？
しないだろ