Docker Part6
■ このスレッドは過去ログ倉庫に格納されています
ネットつながらずにどうやって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系に長く勤めてるけど、噂にも聞いたことなかった 開発本筋の仕事じゃないけど 開発系の人たちにはそれなりに有名なんかな? 実績あげてりゃやり方なんて何でもいい(というかわかるやついない) 業界だから、事実ならもっと頭角表しててもおかしくない 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-} の場合は、出力されませんでした。 ホンマに意味が分かっているのか、怪しい 完全にエイジョイ勢やな 記法を分かって、変数を使っていると思えない 荒らしがいないと過疎やけどな、平和なんはええことよ 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使うようになってから開発がつらくなった とにかく意味不明のエラーが多すぎる、流行ってる割に完成度低いなコレ >>700 実行環境においては、今はDockerEngineという無駄なレイヤを省いてcontainerdを直接使うのが主流 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる