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/

サーバーレスは銀の弾丸ではない

関数はバックエンドだよ
バックエンドで何か処理をしたいな〜、って思ったら、まさにその処理だけを書く、ってのが関数な
その処理を書くために、色々めんどくさい、他のコードや設定を、沢山かかなきゃいけないのが、ウェブフレームワーク
関数なら、railsみたいな、めんどくさいフレームワークは必要ない

実に非論理的だ

僕たちはバックエンドで実行される、処理だけ、を書きたい
目的は関数なんだ

railsを書きたいんじゃない
railsは目的でなく、遠回りな、手段

関数サービスは目的に、最も近い、手段

Ruby on Rails は、バックエンドを勉強している香具師が、
フロントのJavaScript を勉強して構築したもの。
元々、フロント屋じゃない

一方、AWS Lambda は、バックエンド・Linux を勉強していなかった、
フロントのJavaScript の香具師が、バックエンドに攻めてきたもの

GUI だけ作っていた、Linux も何も知らない香具師が、
バックエンドは金になるからと、攻めてきた！

そうじゃない
railsのようなウェブフレームワークからこれって余計だよね？なくてもいいよね？って無駄を削減したら関数になったというだけのこと

関数じゃ無理があるな
まともなウェブアプリは作れない
作れるとういのなら見せてほしい

>>984
LambdaでWebフレームワークも動かせる

AWS LambdaでLaravelを動かす
https://qiita.com/tuuuuuuken/items/d07085d45c453704540b

ALB 経由で Lambda の Rails を実行してみた
https://www.m3tech.blog/entry/aws-alb-to-rails-on-lambda

>>986
使えるだけであって使うべきものではない

Webサイト構築にdocker使うとやっぱりオーバーヘッドありますか？

どんなものでも、オーバーヘッドがゼロのものなんてない
オーバーヘッドをゼロにしたいならOSすら使うなってことになる
答えは「僅かなオーバーヘッドで大きなメリットがある」だ

docker-compose.ymlの入ったディレクトリに移動して端末で
docker-compose upして起動したのはいいのですが
それで発生した痕跡（イメージやコンテナ含む）だけ消すにはどうしたらいいですか

stop　→　rm　→　rmi
ってのを毎回するのでしょうか・・？

docker-composeのservices名って
別のdocker-compose.ymlでかぶらない方がいいですね？

>>990
docker-compose down --rmi all

>>991
オーバーライドするときは合わせるだろ

WSL2ベースのDockerはまだβ版のような出来

PCを休止状態にすると
時計がずれてTLS通信が正常に動作しなくなる

どうしてもWindows使わなきゃならんならhyperv安定

もう丸一日PWDのサバ落ちとる　しね

docker-composeでbuildしたとき
dockerfileのrunでpipでモジュールをインストールしたら
（同じdockerfileだと）その後そのモジュールに変更があっても更新されないから
イメージ消して再びdocker-composeでbuildするしかないよね
もしくは、commandで毎回新しくpip installするか

buildのnocacheオプション

>>998
！
まさにっていうオプションがあったのか　やってみる�d

pipに限らずaptやyumでも同じことだから
誰もが一度は考える

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 107日 18時間 26分 38秒