Docker Part6

テンプレとかいらんやろ

コンテナ使おうが使うまいがサーバーのリソースに十分な空きがあったらスケールダウンはできる
むしろコンテナをプロダクションで使う場合は予めCPUやメモリの枠を予約するのが普通だから、一般的にはリソースの利用効率は悪くなりスケールダウンもしにくいよ
そもそもスケールアップとスケールダウンの意味わかってる？サーバー増やすことじゃないぞ？

Web アプリ開発を例に挙げると、最近はクラウド上に立てたコンテナの中で
プログラムを書き、もし性能が足りなければコンテナ数を増やして対処することが一般的です。
ただこのやり方だとスケールアップする度に膨大な予算がいるし、
OSごと仮想化するのでどうしても動作が遅い。一言で言えば無駄が多いんです。

>>656
botかよ

あまりにも面白いレスだったから俺のお気に入りレスに追加したわ

いや多分ワケ分かってなくて一緒懸命考えて書いたんだけどあまりにもアホな内容なことが自分でもなんとなく分かってきて、コピペのふりして書き直してるんやで

あっはっは、ちゃうねんｗ
ツッコミどころがありまくりの広告記事に
お前らがどういう反応するか見てるだけやねんｗ
続きがあったらどうぞ

今、ユニケージ開発手法にギークが熱狂するワケ【USP研究所代表＆オープンソースOSコミッター対談】
BSDコンサルティング株式会社　代表取締役「當仲寛哲」と取締役「後藤大地」の対談
https://type.jp/et/feature/14070/


後藤「Web アプリ開発を例に挙げると、最近はクラウド上に立てたコンテナの中でプログラムを書き、
もし性能が足りなければコンテナ数を増やして対処することが一般的です。
ただこのやり方だとスケールアップする度に膨大な予算がいるし、
OSごと仮想化するのでどうしても動作が遅い。一言で言えば無駄が多いんです。

ユニケージ開発手法なら１台のマシンをフルに使い切れますし、uspBOAが証明したように
マシンを並列につなげば安価で強力な実行環境を構築できます。大量の電力を消費する
データセンターなどよりはるかに環境に優しいのは言うまでもありません。
今後ますますユニケージ開発手法のメリットが理解されやすい時代になってくるんじゃないかと思っています」

また、當仲さんはユーザーフレンドリー、開発者フレンドリーな環境を追い求めるあまり、
エンジニアは大切なものを見落しているのではないかと感じている。

當仲「人間がちょっとだけ努力して歩み寄るだけで、コンピュータのリソースを
100％使い切れるわけです。その方が合理的で経済的だし、後藤さんの言うように
環境に優しいのは間違いありません。ただ漫然と楽な方へと流れていると、
課題解決の道具に過ぎない開発環境に使われてしまうことになりかねない。
もしそれが嫌ならレイヤードされた階層の上部で開発する便利さに安住せず、
エンジニアはCPUやOS、アセンブラなど、低レイヤーに属する知識をもっと積極的に学ぶべき。それが私の持論です」

初心者質問以外でOSだー仮想化だーなんて発言はマトモに読んでない

(クッソー、釣られた悔しい…。せや、他人のふりして読んでないってことにしたろ！)

>>660
興味深いけど一般的なものからかけ離れてて
にわかに信じがたい内容だな
その引用をまともにここに書くんじゃなくて
変な書き方する意図がわからん
シェルで何もかも実現出来るなら、DBもコンテナもソフトも何もかも無駄でしかないから、その記事の中での辻褄は合ってるんじゃない？
事実かどうかは別にして

まあコンテナ云々は別にして、現在主流の大規模データ処理技術はコンピュータ資源の利用効率が悪すぎるというのは事実ではあるんだよな
Apache系の無駄な仮想化レイヤを重ねすぎたエコシステムは一旦全部捨ててリセットし、低水準な技術で再構築したほうがいいと思う

だからawsとかになっていってんじゃん
巨大企業が膨大にリソース持って、必要な時だけ使わせて課金する
変態シェル職人依存するより現実的だし実際世の中に受け入れられてる

コンピュータ資源よりも、人的資源のほうが大切っつーだけやろ。

ぐだぐた言わんでも、必要ならCでもアセンブリでも使う人は使っとる。

>>663
> 変な書き方する意図がわからん

普通の人ならこれが明らかにおかしい内容だって
思うようなぁっていうのを確かめたかっただけ

> シェルで何もかも実現出来るなら、
できるわけないやろ？

>>664
> Apache系の無駄な仮想化レイヤを

Apacheが何を仮想化してるっていうの？

クラウドだと「膨大な予算がいる」ってどういうことだと思う？

>>667
この記事がガセネタってこと？
よくわからん世界だ

>>669
この記事にあるような分散型の巨大データベース検索する意図だけなら
この変態シェルシステムのが安く上がるって書いてるじゃん
にわかに信じがたいこの内容が事実なら、だけど

>>670
ガセネタというかステマだね

「USP研究所代表＆オープンソースOSコミッター対談」

実は

BSDコンサルティング株式会社
代表取締役「當仲寛哲」と取締役「後藤大地」の対談
https://www.bsdconsulting.co.jp/CGI/BSDC.CGI?CNT=ABOUTUS

でした。

なんで記事にそのことを書かないで
第三者のオープンソースOSコミッターが
すごいと認めてる風を演出をするんだ？

>>671
ミドルウェアを使わないでどうやって
分散型の巨大データベースを作ると思う？

>>673
パイプ3,40繋げて処理するとか書いてるけど
ほへーをそんなん出来んだ(知らんけど
て感じ
そんなことよりフロントエンドや各種コンフィグとかどうやってんのかが気になる
開発ってものによっちゃそっち9割やん
データのわちゃわちゃやるのなんて開発のメインでもなんでもない

>>673
分散型の巨大データベースってBigQueryとかHBaseとかRedshiftみたいなののことか？
ああいうのは仕組みは結構単純で、原理的にはデータのキーや日付でディレクトリ切ってファイルを格納してるのと変わらないんだよ
でディレクトリまで絞れたら後は力技で全部スキャンするだけ
だからシェルスクリプトで似たようなことをやるのも以外にそれほど非現実的ではなかったりするんだよ
まあ恐らくデータの持ち方が列指向じゃないから、スキャン量はちゃんとした分散DBの数十倍くらいにはなるだろうけどね

データをローカルファイルに置くだけじゃちっとも分散しないわけだが

な、データの受け渡しもシェルでやるんかな、
デカいデータだと効率悪そう

>>675
うん。簡単かどうかの話じゃないんだよ
"ミドルウェアを使わないで"
どうやって実現するのか？という話

>>674
シェルスクリプトで全部できます！
こういう手法を使うのです！

フロントエンド？JavaScript使え。手法は知らん。

でも全部シェルスクリプトでできます！


よくわからんよ
ユニケージの手法でどうやって
JavaScirptを使うのか

あとサードパーティーの関数やライブラリは使用禁止ね。
それがユニケージのお作法ｗ

んでもこんな与太話結構あるから
そんな意地になって追求せんでもええやん
本当にいいものなら自然に残るし、
ダメなら淘汰されてく。
確かにまあネタとしてかなり特異で気にはなるけど

>>679
wikipediaにご丁寧にコードのサンプルも載ってるけど
う〜〜んそりゃfor文なくせりゃ何よりだけど、
for文の本質で、繰り返し処理より、変数勝手に入れてってくれることじゃね？ておもた
ユニケージなるものもこの人たち関連の記事しかヒットしないし、
面白いから専スレ立ててくれたら参加するよ
かなり香ばしい結果になる可能性あるなあw

技術的に初心者の人でもわかるように可読性上げる、、
とか言いつつ、シェルは使わせるの必須なんだよな、、
ほんとよーわからん
IT系に長く勤めてるけど、噂にも聞いたことなかった
開発本筋の仕事じゃないけど
開発系の人たちにはそれなりに有名なんかな？
実績あげてりゃやり方なんて何でもいい(というかわかるやついない)
業界だから、事実ならもっと頭角表しててもおかしくない

LocalStackの
docker-compose.yml
に以下の記述があるのですが、
environment:
- DEBUG=${DEBUG-}
- DATA_DIR=${DATA_DIR-}
- LAMBDA_EXECUTOR=${LAMBDA_EXECUTOR-}
DEBUG-などの末尾のマイナス記号は何を意味しているのでしょうか？
「使うとき、マイナス記号を消してね」という意味でしょうか？

>>683
https://docs.docker.com/compose/environment-variables/
> ${VARIABLE-default} evaluates to default only if VARIABLE is unset in the environment.

bashの変数展開使えるのか？と思ったらそういうことではないか
デフォルト値に何も指定しないのに意味はあるのか、という点では
未定義でもWarningが出なくなることを意図しているのかも

>>684
>>685
ありがとうございます。
何が分からないのかの説明が足りていませんでした。
${VARIABLE:-default}
${VARIABLE-default}
の意味は分かるのですが、
${VARIABLE-}
の意味が分かりませんでした。

やってみたら分かった話かもしれません。
- DATA_DIR=${DATA_DIR}
として、docker-compose upしたら、以下のWARNINGが出力されました。
WARNING: The DATA_DIR variable is not set. Defaulting to a blank string.

- DATA_DIR=${DATA_DIR-}
の場合は、出力されませんでした。

>>686
変数

>>681
専スレらしきもの
金沢大学「シェルスクリプト言語論」は偽開発技術
https://mevius.5ch.net/test/read.cgi/tech/1632511262/

ホンマに意味が分かっているのか、怪しい
完全にエイジョイ勢やな
記法を分かって、変数を使っていると思えない

荒らしは出張中なのか静かやね
よかよか

荒らしがいないと過疎やけどな、平和なんはええことよ

Docker創始者らが開発、ビルド／テスト／デプロイの自動化をポータブルにするツール「Dagger」登場。そのままローカルでもGitHubでもCircleCIでも実行可能に − Publickey
https://www.publickey1.jp/blog/22/dockerdaggergithubcircleci.html

docker container createの-aオプションがよく分かりません
docker container create --name hoge -a STDOUT alpine:latest ls
としてから
docker container start hoge
とすると、lsの結果が表示されるのではないかと思ったのですが、表示されません。
docker container start -a hoge
とした場合はlsの結果が表示されますが、別にcreateに-aを指定しなかったとしても同様に表示されます
docker container createの-aオプションの意味はなんなのでしょうか？

その文章描いてる間に調べたら出てきそうな気がする

>>692
やりたいことはわかるけど流行らなそう
GitHub ActionsやCircleCIのYAMLに比べてノイズが多くて読みにくい
やってることも単なるDockerのラッパー以上のものではなく、この程度ならdockerの内外でMakefileでも叩けば十分に見える

色々調べて、
Dockerのコマンドは、裏でDocker Engine APIを叩いているということが分かりました
Docker Engine APIを考えずにDockerコマンドについてあれこれ考えても、
隔靴掻痒というか、無理がありますよね
ただDocker Engine APIについて詳しく書いている日本語の資料が、ネットで探してもなかなか見つかりません
Docker Engine APIの層について詳しく書いてる本とかサイトはないでしょうか？

>>696
https://docs.docker.com/engine/api/v1.41/
これが全て
しかし、今のDocker Engineは単なるAPIサーバーでありcontainerdに処理を投げてるだけだから、
containerdや更にその下のruncの方を学ばないと中身は何もわからない
最近は運用環境ではDocker Engineはほとんど使われなくなりつつあり、完全に終わった技術

Docker使うようになってから開発がつらくなった
とにかく意味不明のエラーが多すぎる、流行ってる割に完成度低いなコレ

完成度の高い仮想開発環境てあるのかね？

>>697
次は何が始まったんよ

>>700
実行環境においては、今はDockerEngineという無駄なレイヤを省いてcontainerdを直接使うのが主流

ググればわかる質問し続けるだけのスレ

Dockerが嫌な人は、一生chrootでも使っとけ！

>>698
エラーが多すぎるのに使ってるとか意味不明。

エラーさえ出なければこんな便利なもんはないんだけどな

意味不明のエラーというのが「(自分にとって)意味不明なエラー」なのか「(全人類にとって)意味不明なエラー」なのか分からないので何とも言えない

こないだ出たエラーの場合はぐぐるとStackOverflow(英語版)その他でも質問されてて未解決だったので俺以外にとっても謎ではあったんだろうと思う

簡単なことをもっと簡単にするために複雑なレイヤー挟んでそのレイヤーのせいで余計にトラブるってのは往々にしてよくあるわな

エラーとかほざいている人は、chrootでも使っとけって！
それさえも分からなければ、qemuとかVMwareとかにしとけって！
わざわざ難しいの使わんでかまへん。

なんだかんだで動いてる時は便利で使い慣れてきたから、できればDockerを使いたい
また別のもの覚えるの面倒くさい

Win10のWSL2環境だけど今までPowerShellからdocker-compose upできてたのに急に Are you trying to mount a directory onto a file (or vice-versa)? とか出てできなくなった
Ubuntuからならできたけど何故何もしてないのに壊れたのか
ぐぐったらStackOverflowとかに似た問題があったが俺のは解決しなかった

何もしてないのに壊れた

LinuxでDocker使ってるけど問題起きたことないな
みんなLinuxで使おう

少なくともWindowsなんか使うのをやめろ、まずはそこからだ

それはあるかも
キータあたりでぞろぞろ出てくる導入記事もマックが多かったような

macでいいならwsl2でもいい
linuxかそれ以外か

でもWindowsでWSL2で問題出まくるから、多分Windowsが一番悪い

>>717
それあなたの感想ですよね

docker commitで作成したイメージを元にして、コンテナを作成して、変更を加えた後に、さらにコミットして、
そこから別のコンテナを作って…みたいに繰り返したら、イメージサイズが大きくなりすぎます。
この最終産物のイメージを短縮化することはできるのでしょうか。

>>719
使い方が間違っています。
docker commitでイメージを作ってはいけません

>>718
事実を述べたら感想とな

>>720
どういうこと？？

docker commitはデバッグ用であり
通常は使いません

>>719
そのイメージがどうやってできているか分かったら、
自ずと答えがわかるとおもうけどね
tarballでもraw imageでも好きにすりゃいい

>>723
でもイメージ化しないと不便でしょう

不便も何も、そもそも再現性のないイメージに価値などない

正解

>>726
イメージでなければ再現するのに時間がかかるし、
再現する方法をメモしておけば良い

そのメモをDockerfileに書けば良い

怠けるな。手順書に従った作業しろ

基本的に、Dockerfileを保持する方向でいいと思うけど、
Dockerfileの書いた内容が恒久的に使えなくなる可能性がありえるので、
少なくとも自分のレジストリを用意して、イメージのバージョンを保持するとか、
tarballなりraw imageなりに吐き出しておくといいと思うけどね

ここらへんのイメージのバックアップは、VMwareとかKVMとかでも結局同じだけどな

>>731
たしかに、dockerfileだと、レポジトリの廃止や、そのディストリビューションのサポート切れで、
インストール手順が無効になる場合もあるよな

Dockerfileでビルドしたイメージをデプロイする際にはまずECR等のレジストリにプッシュし、
デプロイ先のホストがそれをプルするのが一般的なプラクティスであり、イメージのバックアップとして機能する
つべこべ言わずにDockerfileを書け

サポート切れても無理矢理使えるようにするためにイメージのバックアップ取るなんてセキュリティ的にあり得ない
その時点でサポートされているものに対応し続けるしかない

>>733
それは結局のところ、置き場所はともかくイメージは使うということですよね
Dockerfileとイメージの役割は別。
Dockerfileの役割はコンテナのメンテナンスのためにある。
イメージはソースがネットから取れなくなるなど、Dockerfileの改良ではどうにもならない場合にへの対処方法だと思う。
commitはそれをローカルに置いておくために使う。

Dockerfileだったらbuildするだけでローカルにイメージはできるだろ？
commitなんか必要ない

dockerでシステム壊れちゃったから諦めた

>>734
なぜありえないのか？
顧客がつねにお金を出してくれるのか？
顧客がお金を出さない場合は、古いイメージのまま、使い続けることになる

古いイメージ＝脆弱性があるシステム
システムを更新しないで放置してはいけない

顧客が金出さないから云々って状況がよく分からん
システム構築とかの仕事を請け負ってその後の無償対応期間ぐらいの期間であれば、作業時に使ったイメージがサポート切れになるほどの時間は経っていないだろうし
それ以降は顧客が金出さない以上何言ってきても無視するだけの話ダロウェイ

末尾変になったけど無視して

>>740
ユニケージっていうのは現場の人間が内製するためのシステムなんだよ
例えば東急ハンズのような所にプログラミングの専門家はいない
システムなんてせいぜいCGIで作った買い物カートで十分
そういった所にシステム開発費とかないから一度作ったら何年も放置するのはざら
データベースとか難しい技術はしらないし、OSのアップデートとかシステムが動かなくなったら困る

シェルスクリプトでシステムを作っていればコピーするだけでOSのアップデートは完了
OSの基本的なコマンドしか使わないから、OSをアップデートしてもそのまま動く
パイプの匠が考えた開発手法は大規模システムにも対応している
人の入れ替わりの激しい業界で、現場のやすい人材だけで内製するにはこの方法しかない

客が金出さずサポート切れの古いイメージ使い続けて脆弱性突かれて情報流出しようがこっちには関係ないんだからどうでもいいでしょ

>>735
考え方が硬すぎる
そうなりゃ別の方法、別のイメージでイメージ作ればいいやん

commit（笑）

>>744
別のディストリを使うとなると、構築のために試す必要がでてくる。
時間かかる。
逆になぜそこまでイメージを嫌うのか。

いつまでも塩漬けにすることの問題は別にして、最低限、運用中のものについてイメージを残しておくのは必須だろう
スケールアウトや再デプロイの度にいちいちビルドしてたらクソ遅いし、パッケージの更新等でビルドが失敗するようになったときに修正までの時間を稼ぐ必要がある
そのこととcommitの是非は全くの別問題だ

バックアップなら、commitよりも、exportのがええんちゃう？

イメージが大事だとして、
どうしてcommitでイメージを生成させたら駄目だと思うのか？

自動化できねーからだろ
アホ化ｗ

まずdockerの各コマンドが何をやっているのか正確に理解することからだ

>>750
自動化ってなにを？

>>746
そうやって技術的負債が増えてくんだよ^^

デプロイのためのイメージとベースイメージごっちゃになってね？

docker commit の話がなんでimageの話に化けているんだよ。
image使うにしても、まずdockerfileにまとめろよ。dockerfile無しでimageだけとか、Dockerの利点捨てているだろ。