Docker Part6
■ このスレッドは過去ログ倉庫に格納されています
誰が使うんだと聞かれたから、
彼が使うんだと答えたんだろう Linuxカーネルの「Dirty Pipe」脆弱性に対処した「Docker Desktop 4.6.0」 - 窓の杜
https://forest.watch.impress.co.jp/docs/news/1395775.html ホームディレクトリの環境変数って何を指定するのが正しいのでしょうか?
docker-compose.yml内で$HOMEを使うと
WARNING: The HOME variable is not set. Defaulting to a blank string.
と怒られます(~でホームディレクトリを指定できました)
Dockerfileでは$HOMEでホームディレクトリを参照出来ました。
Windowsです opemediavault dockerで動かしてる人いる?
USB HDDのマウントややこしいなあ、、 Docker公式のチュートリアルをやりはじめたのですが、
https://docs.docker.com/get-started/02_our_app/
のイメージのビルドのところで、
error Received malformed response from registry for "glob". The registry may be down.
Error: Received malformed response from registry for "aws4". The registry may be down.
というエラーが出て失敗します(他にもwarningが多数)
ググっているうち、
Dockerのtutorialが動かなかった話
https://qiita.com/yutake27/items/2b147547a5fd6cebf251
という記事を見つけました
この記事に書かれている問題は、今のチュートリアルでは修正されていますが
また別の理由で動かなくなっているようです
公式のチュートリアルを読んでいくのが確実だろうと思ったのですが、
どうもあまり細やかなメンテナンスがされていない印象があります
公式のチュートリアルは初学者の勉強にはあまり適していないのでしょうか? >>589
> 公式のチュートリアルは初学者の勉強にはあまり適していないのでしょうか?
自分で、チュートリアル相当なチュートリアルを作りながらやってみて、
それで公式のチュートリアルの内容が理解できているなら、それでよいのでは? マジメそうやけど独学するならもっと柔軟に
動かんもんは動かんからさっさと切り替えて行け
お勉強のお膳立てされてるとは限らない
お勉強環境作るとこからよ >>589
QiitaかZennに書くと誰かが答えてくれるかもしれないし同じ現象が起きた人がその記事を見つけてヒントを得られますよ。あなたの環境やチュートリアル内の具体的にはどの指示をやろうとしてるのか、あなたが叩いたコマンドは何なのか書いておくとアドバイスする方も助かります。一般的にチュートリアルは最高の学習コンテンツですしチュートリアル自体に不備があるのなら修正リクエストを出して貢献することも歓迎されます。 >>587
ありがとう。
実はec2の例はお客が用意したもので今となっては詳しく分からないんだけど
次同じことがあったらそのへんを注目してみます。 チュートリアルは完全に初学者向けに書かれてるとはかぎらないかもね。
さっさと使い方知りたい人向けだし、往々にしてそういう人は(そのプロダクトが動くプラットフォームの)初学者じゃないだろうし。 いや、チュートリアルは初心者向けやろ
たまたま壊れてるの引いたから諦めて別のに行くか
自分で解決するしか無いだけ、
数週間前のコマンドがアップデートや仕様変更で
通らないなんて事ザラにある
書いてるコマンドそのままでやりたいなら
探し回るしか無い >>595
さっさと使いた知りたい人はmanします(笑) >>589
暇だったから試してみたけど普通に全部動いたぞ? linuxの知識がないから足りないパッケージ入れれ無いんじゃない。
エラーメッセ見て対応してけば動く気がするけどな
それが出来ないことを問題と思うくらい初心書なら
もっと手取り足取り書いてるテキストなり探すしか無いねえ The registry may be down.
つーてるやん。
サーバーにつながらんかったんちゃうの?
たまたまか、プロキシとかか。 ほんまやな、単にネットに繋がってないだけやな
大体DNSやな
あとはipかサブネットの設定ミスってるかやな ネットつながらずにどうやってdocker入れたんや
お気に入りツールも入れられんやろし、
初心者のやることは謎やで >>604
何いってんだよ・・・
そんな訳ないじゃん! (1)DockerfileにENTRYPOINTでサーバーを立ち上げるコマンドを実行するのと
(2)docker-composeのcommandでbashに入ってサーバーを立ち上げるためのスクリプト起動してサーバーを立ち上げるのと
どちらでやるべきでしょうか
(1)だと同じ環境で別のサーバーを立ち上げたいとき
ENTRYPOINTの行を変えたDockerfileを用意しないといけないですよね あれ・・そこまで難しい内容でしたかね・・?
(1)Dockerfileにて
ENTRYPOINT ここにサーバー立ち上げコマンド
とするか
(2)docker-compose.ymlにて
command: bash -c "ここにサーバー立ち上げコマンド"
とするか
結局どちらもできるんですがdocker-compose.ymlありきの場合
海外のサイトとかみてるとどちらの場合もあって
あえてやってるのか(視認性とかで)、そうした方がいいのか、どっちでもいいのか
何か慣習でもあるのかと思いまして。 あえてやってるのかは本人に聞けよとしか
動いてんなら自分が使いやすいと思う方採用すれば良いじゃんとしか >動いてんなら自分が使いやすいと思う方採用すれば良いじゃんとしか
いえ、そういう意味ではなく
動いてるので、もちろんすでに好きな方を採用してるんです
慣習とか後々のメンテナンスやら技術的な面で何か理由があるのかな、ということだけです
ただ、返答内容を見る限り
あなた自身はこういうケースを経験したことがなく私と同じようにわからない
ということは少なくともわかりました
ありがとうございます 前から過疎スレに対して私も思っている部分がありますね
レスが止まると返信しなければいけない使命感が生まれる
という部分に関して。
基本的に質問がきても
わからなかったり興味がなければ
答えなくていいし無視して良いんですよ
他の人は知りませんが私は答えが出なかったところで
答えが出るまで活動を止めているわけではないし何も問題はないんです
でも実際レスが止まると
次レスする人は、(本来は無いはずの)レスを止めた原因を意識してしまい
「ワシが何かアドバイスしなくては ワシがこの状況を打破しなくては」
みたいな焦燥感が生まれ、無理に結論を導き出そうとする
そして的はずれなやり取りになってしまう
経験上過疎スレにはそういうのをよくみます すみません613の存在に気づきましたが>>614は>>613に対しての返信ではありません
>>615が誰に対して言っているのかは知りませんが、念の為 "ここにサーバー立ち上げコマンド"から滲み出る無能感 こういう無能がツイッターとかでちょっと技術的なツイートに俺知ってるアピール自己語りリプするんだよな サーバー立ち上げコマンドとやらをコンテナイメージに固めてしまうか
イメージの外でメンテできるようにしておくか
の違いだと思うが
何のコンテナなのかも
サーバー立ち上げコマンドが何なのかもわからん
人にものを聞くならコミュニケーション能力を磨いた方がいいよ entrypointとcmdとどっちが一般的ですか!
前提条件は諸々不明です!
こんなかんじ? docker-composeはあくまでdockerコマンドのオプション諸々を一発実行してくれるマニフェストファイルだからdockerfileを代替するものではない >>622
>の違いだと思うが
それは違う
docker-composeの使い方を理解していない dockerコンテナ同士で、ボリュームを相互にマウントさせる事はできますか?
例えばAコンテナの/work/xxxというディレクトリをdocker volume化して、
Bコンテナから参照できる。
docker run -itd --name A \
-v xxx-linux-opt:/work/xxx \
${A_IMAGE}
docker run -itd --name B \
-v /var/run/docker.sock:/var/run/docker.sock \
--volume-from A
${B_IMAGE}
同時にBコンテナの/work/yyyというディレクトリをAコンテナでも参照できるようしたい。これって実現可能? 同一ホストで動いてるんなら普通にホストのディレクトリを両方にマウントすりゃいいでしょ >>629
ホストディレクトリを汚染したくないのです。A、Bコンテナは互いに相手を必要としており、コンテナが相互マウントできれば嬉しいです 状態はコンテナの外に持ちなさいってばっちゃんが言ってた ホストディレクトリを汚したくないなら先にボリュームを作ってそれぞれのコンテナからそれを利用すればいい dockerの公式ドキュメント見やすくて探しやすいぞ このスレの住民より信憑性ある そか、ええな、kubenetes組んだ時どうすんのか疑問だった >>638
複数のデータセンターにサーバー置いて、
クラスター作って高可用性を持たせるような用途なら
NFSじゃなくてレプリケーション対応したデータベースを使うのが普通
地理的に離れた場所でファイルシステムに必要な一貫性持たせるのは速度を犠牲にしないと困難
データベースのレプリケーションアルゴリズムで同期した方がストレージの全ファイルに一貫性持たせるより効率的だし
必要なければ部分的に一貫性を犠牲にする事で性能上げられる >>639
おうちkubenetes予定民(ラズパイ待ち
やからそこまでやる気ないんやけど
コンフィグファイルとかもDB化できるん?
できるならそこまでやってみたいなあ >>640
コンフィグファイルぐらいならk8sのconfigmapとかsecretに置けばよくね
本家k8sならetcdっていう分散データベースに保存される
k0sとかk3sはsqliteとかも保存先に使えるらしいけど
もっと沢山データ入れるなら普通にデータベース使え >>642
ほーんニキ詳しいなあ、ありがと
仕事利用民かな?
その辺ちょっとみたけど、マイクラのマップデータ見たいな大きめのファイル群もなんとでもなりそうやね、当たり前か Web アプリ開発を例に挙げると、最近はクラウド上に立てたコンテナの中で
プログラムを書き、もし性能が足りなければコンテナ数を増やして対処することが一般的です。
ただこのやり方だとスケールアップする度に膨大な予算がいるし、
OSごと仮想化するのでどうしても動作が遅い。一言で言えば無駄が多いんです。 >>644
>OSごと仮想化するのでどうしても動作が遅い。一言で言えば無駄が多いんです。
それあなたの感想ですよね
データとかあるんですか? >>645
いちゃもんつけないでください。
言ってることは正しいです。 重要なのはただこのやり方だとスケールアップする度に膨大な予算がいるということ 何が言いたいのかよーわからんけどそもそもdockerはそのリソース節約するのも一つの目的で
awsなりでコンテナ増やして金が余分にかかるのは
しゃーないしosごと立ち上げるより安いやろ
膨大な金が金額指してるのかもよーわからんが、規模に応じた金額しかかからんから千円だろうが5億だろうが昔に比べりゃ格安だろ。オンプレでdockerのリソース増やしても、1ハード1システムの時代に比べりゃ遥かに安い 普通は人件費のほうがずっと高いからな
サーバー家畜化で低級の運用SEを一人削減できたらそれだけで月100万浮くわけで、AWSで月100万あれば相当な規模のサービスを運用できる コンテナ使わない場合、常にスケールアップ後の構成にしておかないとサービス落ちるんじゃね
スケールダウンできるコンテナ使用の方が安くなりそうだけど コンテナ使おうが使うまいがサーバーのリソースに十分な空きがあったらスケールダウンはできる
むしろコンテナをプロダクションで使う場合は予めCPUやメモリの枠を予約するのが普通だから、一般的にはリソースの利用効率は悪くなりスケールダウンもしにくいよ
そもそもスケールアップとスケールダウンの意味わかってる?サーバー増やすことじゃないぞ? Web アプリ開発を例に挙げると、最近はクラウド上に立てたコンテナの中で
プログラムを書き、もし性能が足りなければコンテナ数を増やして対処することが一般的です。
ただこのやり方だとスケールアップする度に膨大な予算がいるし、
OSごと仮想化するのでどうしても動作が遅い。一言で言えば無駄が多いんです。 あまりにも面白いレスだったから俺のお気に入りレスに追加したわ いや多分ワケ分かってなくて一緒懸命考えて書いたんだけどあまりにもアホな内容なことが自分でもなんとなく分かってきて、コピペのふりして書き直してるんやで あっはっは、ちゃうねんw
ツッコミどころがありまくりの広告記事に
お前らがどういう反応するか見てるだけやねんw
続きがあったらどうぞ
今、ユニケージ開発手法にギークが熱狂するワケ【USP研究所代表&オープンソースOSコミッター対談】
BSDコンサルティング株式会社 代表取締役「當仲寛哲」と取締役「後藤大地」の対談
https://type.jp/et/feature/14070/
後藤「Web アプリ開発を例に挙げると、最近はクラウド上に立てたコンテナの中でプログラムを書き、
もし性能が足りなければコンテナ数を増やして対処することが一般的です。
ただこのやり方だとスケールアップする度に膨大な予算がいるし、
OSごと仮想化するのでどうしても動作が遅い。一言で言えば無駄が多いんです。
ユニケージ開発手法なら1台のマシンをフルに使い切れますし、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を使うのか
あとサードパーティーの関数やライブラリは使用禁止ね。
それがユニケージのお作法w んでもこんな与太話結構あるから
そんな意地になって追求せんでもええやん
本当にいいものなら自然に残るし、
ダメなら淘汰されてく。
確かにまあネタとしてかなり特異で気にはなるけど >>679
wikipediaにご丁寧にコードのサンプルも載ってるけど
う〜〜んそりゃfor文なくせりゃ何よりだけど、
for文の本質で、繰り返し処理より、変数勝手に入れてってくれることじゃね?ておもた
ユニケージなるものもこの人たち関連の記事しかヒットしないし、
面白いから専スレ立ててくれたら参加するよ
かなり香ばしい結果になる可能性あるなあw 技術的に初心者の人でもわかるように可読性上げる、、
とか言いつつ、シェルは使わせるの必須なんだよな、、
ほんとよーわからん
IT系に長く勤めてるけど、噂にも聞いたことなかった
開発本筋の仕事じゃないけど
開発系の人たちにはそれなりに有名なんかな?
実績あげてりゃやり方なんて何でもいい(というかわかるやついない)
業界だから、事実ならもっと頭角表しててもおかしくない ■ このスレッドは過去ログ倉庫に格納されています