[過去ログ] Docker Part5 (1002レス)
上下前次1-新
このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
853: 2021/03/13(土)14:35 ID:OkB9sWH0(2/2) AAS
>>852
OpenShiftはランダムと言ってますが、それはコンテナごとに
違うという意味で、実際には推測可能なUIDが割り当てられます
854: 2021/03/13(土)16:08 ID:w6Cw4gKa(3/4) AAS
namespaceを作るとUID、GIDの範囲が自動的に割り当てられ
同じnamespace内のポッドは同じUIDとグループIDになる
これによって他のnamespaceやホストマシンで動いてるプロセスが使用してるファイルなど、
無関係のファイルを読み書き出来てしまうのを防ぐ
何も指定しないとUIDとGIDは範囲内で使える最初の値になるようだ
だから同じ名前空間内のボリュームだったら
どのポッドも読み書きできるね
855(1): 2021/03/13(土)19:00 ID:CGLHT5pS(1) AAS
podがどうのこうのと言っている時点で既にDockerの話じゃないんだけどな。
不特定のnode, podに対してUSER指定させたらマルチテナント環境でバッティングするから
ランダムにしよーぜなんてのはDockerレベルで考える事じゃない。
856: 2021/03/13(土)19:28 ID:nRE6g312(1/6) AAS
今話をしてるのはUIDの話であって
USER指定の話ではない
857: 2021/03/13(土)19:29 ID:nRE6g312(2/6) AAS
>>6
Chromeでもエラー出るようになったwww
858: 2021/03/13(土)19:30 ID:nRE6g312(3/6) AAS
レスする場所間違えたw
859(1): 2021/03/13(土)19:38 ID:fBnyEFkA(2/3) AAS
ほらなdockerならではの面倒くささあるじゃん
860: 2021/03/13(土)19:45 ID:nRE6g312(4/6) AAS
>>859
それを判断するのは、お前がDockerを使わない場合に
同じ問題をどう解決できるかを言ってからだ
早くレスしてくれ
861: 2021/03/13(土)19:52 ID:fBnyEFkA(3/3) AAS
はいいつもの奴NG
862: 2021/03/13(土)19:54 ID:nRE6g312(5/6) AAS
ほらな?逃げただろ。こいつは反論が一切できない。
なぜならNGにして見えないからだw
まあ実際は見てるんだろうがな
だから実際には反論できないというが正解
863: 2021/03/13(土)20:04 ID:w6Cw4gKa(4/4) AAS
>>855
ランダムUIDは万が一コンテナのサンドボックスが破られてホストに侵入された時のためで
ファイルの所有者がバッティングするからどうこうではない
864: 2021/03/13(土)20:07 ID:WuKb+LRj(1) AAS
ランダムなら何度も繰り返し攻撃したらそのうち通るんじゃね
865: 2021/03/13(土)20:12 ID:nRE6g312(6/6) AAS
この流れでコンテナのサンドボックスが破られるぐらいなら
最初からDocker(コンテナ)を使わずに、サンドボックスの外で
直接動かせばいいとか言うんだろうなw
866: 2021/03/13(土)21:43 ID:9K/sAZAs(1) AAS
OpenShiftのためだけにUID指定するながベストプラクティスってやべえな
867(1): 2021/03/17(水)19:41 ID:ajiqTOqm(1) AAS
Dev image作る人
Ops image使う人
☝あってる?
868: 2021/03/18(木)01:46 ID:4WrbQg+w(1) AAS
>>867
あってる
ただしDevが作るイメージとは自分たちで開発したアプリのイメージ
自分たちで開発してないアプリ、オープンソースなどは
Docker公式や開発公式が作ってることが多いので
そういうのをイメージする作業は開発とは言わない
アプリ開発の一環としてDockerイメージも作る
869: 2021/03/18(木)09:38 ID:QA403diq(1) AAS
Introducing fixuid: Tool for Changing Docker Container UID/GID at Runtime
外部リンク:boxboat.com
One of the most helpful things about using Docker containers for development is that it reduces developer onboarding time from a few days to a few hours or less.
Developers are able to clone a repository, start a container or run Docker compose, and start contributing immediately.
Development containers are often very different from production containers.
They usually include package managers, build tools, SDKs, remote debugging, and more.
Source code can be mounted into the development container via a host mount and changes can be immediately re-rendered via live-reload build tools.
This is where the road gets bumpy – Docker containers run as a single user. Users/groups, UIDs/GIDs, and file ownership must be decided when an image is built with docker build.
Host volumes, however, are owned by a user on the host and the host user's UID may or may not match the container user's UID.
There's an issue in the Moby repository with over 100 comments about this very topic.
省4
870: 2021/03/19(金)13:01 ID:edcYEDQK(1/6) AAS
nix使ったらDockerイメージのマージはできないけど
nixのパッケージ使ってDockerイメージ作れば似たような事は出来るね
使いたいCLIツールのパッケージが依存してるランタイムのバージョンが違ってても共存させる事が出来る
No dependency hell
ビルド時にだけ必要なパッケージと
実行時に必要なパッケージが明確に区別されてるので
要らない一時ファイルを誤ってDockerイメージに含める心配がない
nixpkgsのパッケージが豊富だし
無くても自分で書けば良い
GitHubで自作パッケージを公開し、ビルド済みバイナリをcachixに置いておけば
省5
871(1): 2021/03/19(金)13:14 ID:dlChmxiq(1/2) AAS
前にも言ったと思うけど
俺らが本当に欲しかったものってdockerじゃなくてスマートなパッケージマネージャ(とリポジトリ)なんだよね
Container imageってアイデアは失敗だった
872: 2021/03/19(金)13:43 ID:edcYEDQK(2/6) AAS
一応nixにもnixパッケージ使って隔離されたNixOS環境を作る
nixos-containerってのがあるがDockerみたいに完璧な隔離ではないらしい
nixos-containerの隔離が完璧になって
自前のバイナリキャッシュも
ローカルのnixストアみたいにGCで最小構成で保存出来たら
Dockerみたいに使えるかも
873: 2021/03/19(金)15:13 ID:edcYEDQK(3/6) AAS
あらゆるCLIツールがnixでインストール可能になれば
開発環境ではnix-shell使って
本番では必要なパッケージを一つに固めたDockerイメージをk8sとかで使うってやり方が実現できる
そんな世界をまず目指そう
874(1): 2021/03/19(金)15:28 ID:OafZaxWN(1/15) AAS
そうじゃなくて
開発も本番もパッケージはホストにインストールするんだよ
で本番はコンテナにパッケージを読み取り専用でマウントすんの
全部固めたイメージなんてものは要らない
875(1): 2021/03/19(金)16:22 ID:R4CRH11B(1/18) AAS
>>871
> 俺らが本当に欲しかったものってdockerじゃなくてスマートなパッケージマネージャ(とリポジトリ)なんだよね
パッケージマネージャーだけだと
実行するときの分離ができないだろ
「俺らが」じゃなくて「お前が」欲しいものはパッケージマネージャーなので
Dockerでパッケージマネージャー相当のことがしたい
できないのは苦痛だなどと言わないように
お前の目的にあってないのよ
Dockerは開発者が自分で作ったアプリを
デプロイするためのツールだって何度も言ってるだろ
876: 2021/03/19(金)16:25 ID:edcYEDQK(4/6) AAS
それをやろうとしてるのはnixos-containerじゃね
コンテナ起動時にパッケージへのシンボリックリンクを動的につくるか、
PATHをパッケージの絶対パスで埋め尽くせばDockerでも行けそう
後はバイナリキャッシュのバイナリだけを利用するとか、実行時に必要なパッケージだけをダウンロードするモードがnixにないとか
その辺がなんとかなれば
本番で不要なビルド用パッケージを落としたりソースからビルドとかしたくないし
nix expressionの評価が遅いって問題もあるが
それはnix flakesで解決しそう
dockerTools.buildLayeredImage使えば
パッケージ毎にイメージレイヤーを作ってくれるので
省6
877(1): 2021/03/19(金)16:25 ID:R4CRH11B(2/18) AAS
>>874
なんでパッケージマネージャーが欲しいやつがDockerなんて使おうとするんだろ?w
例えばapacheのDockerイメージ、nginxのDockerイメージ
どちらもポート80で起動する
というDockerイメージを、同一のホストで複数起動する場合どうすればいいのか?
Dockerイメージを変更すること無く、待受ポート番号を変更するにはどうすればいいのか?
それができるように作られたのがDockerなんだが
ファイルを置くだけのパッケージマネージャーじゃこんな事はできない
実行時のプロセスの分離を行う仕組みが必要
878: 2021/03/19(金)16:30 ID:OafZaxWN(2/15) AAS
>>875
実行する時の分離はできるだろ
コンテナに読み取り専用でマウントするだけ
879(1): 2021/03/19(金)16:32 ID:OafZaxWN(3/15) AAS
>>877
nginxのパッケージを入れて2つの隔離されたnginxプロセスを起動するだけだろ
880: 2021/03/19(金)16:54 ID:edcYEDQK(5/6) AAS
独自のコンテナランタイムとか作らないってこと?
今使ってるコンテナのイメージレイヤーは削除出来たらだめって挙動をパッケージでやるのは
独自のコンテナランタイム作らずには難しくね
今コンテナで使ってるパッケージを削除してしまったり
逆に古いパッケージが消えないってなりそう
881: 2021/03/19(金)16:57 ID:R4CRH11B(3/18) AAS
>>879
> nginxのパッケージを入れて2つの隔離されたnginxプロセスを起動するだけだろ
パッケージを1つだけ入れて2つのnginxプロセスを起動したりしたいんだよ
それもnginxの設定を変更せずに
882: 2021/03/19(金)17:00 ID:R4CRH11B(4/18) AAS
Dockerとパッケージマネージャーは使う目的が全く違うんだから
パッケージマネージャーが欲しい人がDockerをパッケージマネージャーの代わりとして使って
「Dockerはパッケージマネージャーで代用できる!」なんて適当なことを言わないでくれ
それはお前がDockeをパッケージマネージャーという
間違った用途で使ってるだけだ
883: 2021/03/19(金)17:37 ID:OafZaxWN(4/15) AAS
作るとしたらこんな感じだろうな
デベロッパ
myapp:
name: MyApp
version: 2.0
packages:
- ruby == 3.0.0
- hoge.com/hoge-cli == 1.2
files:
- src: ./src
省16
884(1): 2021/03/19(金)17:40 ID:R4CRH11B(5/18) AAS
ただの設定ファイルの形式変えてるだけじゃん
イメージいらないって、イメージなくしてどうやって起動速度上げるのさ?
どうやって全く同じイメージだと保証できるのさ?
同じ設定ファイルから作ったとしても一年後にやって同じイメージが出来る保証はない
885: 2021/03/19(金)17:41 ID:OafZaxWN(5/15) AAS
済まない
↑のリポジトリのURLは適当に架空のURLを書いたつもりだったが存在するドメインだったので無視してくれ
886(1): 2021/03/19(金)17:41 ID:R4CRH11B(6/18) AAS
あとrubyしか書いてないけど、ディストリに含まれる
全てのライブラリのバージョンも書かないと駄目だろw
887: 2021/03/19(金)17:43 ID:OafZaxWN(6/15) AAS
>>884
ファイル形式を変えてるだけじゃない
パッケージを分離してる
イメージは必要ない
必要なのはパッケージ、メタデータだけ
888: 2021/03/19(金)17:44 ID:OafZaxWN(7/15) AAS
>>886
rubyに必要な依存はrubyパッケージのメタデータに書く
889(1): 2021/03/19(金)17:44 ID:R4CRH11B(7/18) AAS
多数の仮想マシンに同一のイメージを配布することは出来るが
多数の仮想マシンに設定ファイルから一からインストールするなんて時間かかるし
すべてのファイル(OSに含まれる全てのファイル)を、そのリポジトリとやらに
アップしてそれをダウンロードして使うってならそれがDockerのイメージの仕組みです
としか言いようがない
890(1): 2021/03/19(金)17:45 ID:R4CRH11B(8/18) AAS
メタデータから再インストールするのは
時間がかかるって言ってます。
完成済みのファイルをコピーしたほうがずっと速い
それがイメージ
891: 2021/03/19(金)17:46 ID:OafZaxWN(8/15) AAS
>>889
dockerとの違いはイメージに固めないこと
これによって同じパッケージを使うアプリでパッケージ共有できる
ディスク容量や通信時間を大幅に節約できる
892: 2021/03/19(金)17:47 ID:OafZaxWN(9/15) AAS
>>890
重複を避けて少量のファイルをpullしたほうが速い
imageだと同じパッケージを使ってても別のimageと認識されるから無駄が大きすぎる
893(1): 2021/03/19(金)17:47 ID:R4CRH11B(9/18) AAS
パッケージだけあったって、インストールの順番で
出来上がるものは違うだろうが
あとからnanoをインストールするのと
あとからvimをインストールするので
同じものが出来ると思うか?
894(1): 2021/03/19(金)17:48 ID:R4CRH11B(10/18) AAS
> 重複を避けて少量のファイルをpullしたほうが速い
だからそれがイメージ
895: 2021/03/19(金)17:48 ID:OafZaxWN(10/15) AAS
>>893
インストール順番に依存しないようにするための賢いパッケージマネージャだろ
Dockerfileは手続き型だから順番を気にしないといけないがnixのような関数型のパッケージマネージャならそれを克服できるというわけだ
896(1): 2021/03/19(金)17:48 ID:R4CRH11B(11/18) AAS
パッケージだけあったって、同じイメージは作れないんだが?
インストール済みの状態のファイル=レイヤーが必要
897: 2021/03/19(金)17:50 ID:R4CRH11B(12/18) AAS
nixのような関数型のパッケージマネージャは
バージョンごとに複数のパッケージをインストールするというだけ
898(1): 2021/03/19(金)17:50 ID:OafZaxWN(11/15) AAS
>>894
imageでは重複をうまく回避できない
RUN xxx
RUN apt-get hoge
RUN yyy
RUN apt-get hoge
たったこれだけで別物と見なされてhogeの重複ダウンロードされる
これじゃ効率が悪すぎる
899(1): 2021/03/19(金)17:51 ID:R4CRH11B(13/18) AAS
そしてnixのような関数型のパッケージマネージャは
ポート番号を変えて起動とかしてくれない
Dockerの目的をパッケージマネージャーは満たしてくれてない
900: 2021/03/19(金)17:51 ID:OafZaxWN(12/15) AAS
>>896
パッケージバージョンを完全に指定すれば同じ
901(1): 2021/03/19(金)17:52 ID:OafZaxWN(13/15) AAS
>>899
起動時のオプションで変えるだけ
902(1): 2021/03/19(金)17:52 ID:R4CRH11B(14/18) AAS
>>898
> たったこれだけで別物と見なされてhogeの重複ダウンロードされる
nixのような関数型のパッケージマネージャも
バージョンが異なれば重複ダウンロードされる
903(1): 2021/03/19(金)17:53 ID:R4CRH11B(15/18) AAS
>>901
「パッケージマネージャー」に起動時のオプションを変更する機能があるんですか?w
904: 2021/03/19(金)18:00 ID:OafZaxWN(14/15) AAS
>>902
imageの場合はバージョンが全く同じでも重複
パッケージマネージャはバージョンが同じなら重複ダウンロードしない
905: 2021/03/19(金)18:01 ID:OafZaxWN(15/15) AAS
>>903
いやいやそうなるように作るべきって話だろ
今はまだ無い賢いパッケージマネージャの話をしてんだ
906(1): 2021/03/19(金)18:08 ID:edcYEDQK(6/6) AAS
nixはbrewやyum, apt-getみたいなのじゃないぞ
nixはパッケージマネージャーの皮を被ったビルドツールだ
ビルド結果をS3に保存できるのはバイナリキャッシュ機能のおかげ
ビルド時のフラグや依存関係などを利用して生成したユニークIDを自動的にパッケージに付ける
少しでも設定変えればIDも変わる
パッケージはみんな/nix/storeの下に入る
/usrを直接変えるような事はしない
使う時は各パッケージの/binにsymlinkをはる
907: 2021/03/19(金)19:25 ID:r5P2gC/O(1) AAS
次スレわっちょい付けますか?
908: 2021/03/19(金)19:28 ID:hGR6Rk9p(1) AAS
今の所不要じゃね
909: 2021/03/19(金)20:02 ID:ydlHbAph(1) AAS
//docs.docker.com/compose/compose-file/
compose.yml っていうファイル名が 1.27.0+ から使えるらしいんだけど、1.27.4 の環境で読み取ってくれない
1.27.0+ の + って以上って意味じゃないのかな
ワッチョイあったほうがいいと思ってたけど、age てるやつを NG すれば問題ないことに気付いたよ
910: 2021/03/19(金)22:28 ID:R4CRH11B(16/18) AAS
>>906
nixは「パッケージマネージャー」
起動時にポート番号やボリュームディレクトリを変更したりする機能はない
911(1): 2021/03/19(金)22:30 ID:dlChmxiq(2/2) AAS
機能を追加すればいいだけ
というか実行に関してはdockerでいいかもね
パッケージマネージャが管理してるディレクトリをマウントするだけだから
912: 2021/03/19(金)22:47 ID:R4CRH11B(17/18) AAS
パッケージマネージャーにない機能
パッケージマネージャーとは関係ない機能を追加して
Docker相当のものを作るってことは
本当に欲しかったものはパッケージマネージャーではないということだろう
913: 2021/03/19(金)22:48 ID:R4CRH11B(18/18) AAS
>>911
「パッケージマネージャが管理してるディレクトリ」=Dockerのイメージ
「パッケージマネージャが管理してるディレクトリ」に
OS標準コマンドも入ってるんですか?入ってませんね。
Dockerの劣化版
まず「パッケージマネージャが管理してるディレクトリ」に
カーネル以外のすべてのファイルを入れることから始めましょう
914: 2021/03/24(水)17:58 ID:FIcallii(1) AAS
Kubecost raises $5.5 million to help teams monitor and reduce their Kubernetes spend
外部リンク:blog.kubecost.com
915: 2021/03/25(木)15:28 ID:+f1vIM7g(1) AAS
創業2年で5億かぁ…
916: 2021/03/28(日)01:08 ID:hxUNtDrJ(1) AAS
さ
917(4): 2021/03/28(日)01:54 ID:2P/rKl6w(1) AAS
すまんが、ユーザーにビルドの権限だけ与える(実行権限なし)ことってできないんかな?
918: 2021/03/28(日)06:50 ID:vAibOhoV(1) AAS
>>917
ビルドマシンと実行マシン分けたらいいだけじゃね?
919: 2021/03/28(日)09:48 ID:QMhp1XDK(1) AAS
docker in dockerすれば
VMを使った牢獄の代わりになると思う
920: 2021/03/28(日)10:24 ID:gSeZ2/tw(1) AAS
GitHub Actionsとかで自動ビルドすれば
921: 2021/03/28(日)15:48 ID:1NFy3up2(1) AAS
>>917
ビルドツールを実行させずに
ビルドさせたいってこと?
無理じゃねw
922: 2021/04/03(土)17:28 ID:RxgrSHyR(1) AAS
>>917
ビルドはJenkinsとかにやらせてユーザーが出来るのはJenkins上のWebボタンを押すことだけで良いんじゃね
923: 2021/04/03(土)21:42 ID:SCQDyQM3(1) AAS
>>917
早く出てこいよ
924: 2021/04/03(土)23:38 ID:aeUpR8Fe(1) AAS
山浦清透、1/15
Docker超入門講座 合併版 | ゼロから実践する4時間のフルコース
動画リンク[YouTube]
Windows 10 Home版, WSL2, Ubuntu 20.04 LTS,
Docker Compose, VSCode, Heroku, Ruby on Rails, Git, CI/CD, CircleCI
925: 2021/04/07(水)10:34 ID:+R9vNIAU(1) AAS
スレチであれだけど、最近よくマスコミや政治家が言ってる「デジタル推進」
とか「デジタル改革」って言葉の意味がわからなくて困惑してる。
たぶん、情報技術(ソフト・ハードとも)を使った各種処理の効率化・省人化
を図ったり、新たなサービスの創出で社会を活性化させたり、セキュリティ面
の強化とか、そういうことが言いたいのかなぁって想像してはいるんだけど。
でもそれだったらIT革命とかIT推進とかIT庁の方がまだ意図が見えるような。
別にアナログ技術だから不便・遅れているってわけでもなかろうに。
926: 2021/04/07(水)11:29 ID:NzwhU5o2(1) AAS
IT を広い意味で使うと何もかもが it になりそう製造業も情報からだよねっと
そして誤爆かなと思っております
927: 2021/04/07(水)12:15 ID:J3p3B2Dm(1) AAS
なんのスレだ?
928: 2021/04/12(月)12:59 ID:i8zJNg4j(1) AAS
docker-machineってメンテ止まってる?
もう使わないほうがいいのかなこれ
929: 2021/04/12(月)13:46 ID:+hWGpe2Y(1) AAS
docker-machineは使う理由がなくなったよな
あれは、リモートにdockerサーバーがある場合にそれを操作するもので
・どっかのクラウドがdockerサーバーを提供しててそこにつなぐ
→ローカルでやるしなぁ
・Windowsで仮想マシンに入れたDockerにつなぐ
→Docker for Windows使うから仮想マシン使わないしなぁ
こんな感じで使う理由がない
省2
930(1): 2021/04/24(土)18:59 ID:OnnP5g+1(1) AAS
過疎ってるね
dockerもいよいよオワコンかな
931: 2021/05/18(火)10:44 ID:uSuJalCX(1) AAS
別に過疎ってるわけじゃないけどな。
スレチに答えてもしゃーないってだけ。
932: 2021/05/18(火)11:31 ID:meCXSbYd(1) AAS
>>930
たかが2chの一スレから判断しようとすな!
933(1): 2021/05/20(木)15:21 ID:DVPorPa2(1/4) AAS
外部リンク:trends.google.co.jp
まあ、Dockerが徐々にオワコン化しそうなのは、その通りだけどね。
結局面倒臭い割には解決できる問題が限定的すぎるるんだよ。
934(1): 2021/05/20(木)15:30 ID:1220+Fxs(1/6) AAS
>>933
いやいや、一つだけじゃ何の比較にもならんやろ
別の単語入れて検索せーや
935(1): 2021/05/20(木)15:37 ID:dv9bYuSQ(1) AAS
Dockerに代わるものってなんかあったっけ?
936(2): 2021/05/20(木)15:38 ID:jE+d/Fxl(1/2) AAS
でも結局個人開発で使うんならDocker一択でね?
ほかはビジネス用ばっかだし
937: 2021/05/20(木)15:44 ID:1220+Fxs(2/6) AAS
>>935
ないよw
Googleトレンドなんて検索キーワードの数なんだから、普及すれば減るのは当たり前
Linuxなんて完全にオワコンじゃんw
外部リンク:trends.google.co.jp
938(1): 2021/05/20(木)15:48 ID:DVPorPa2(2/4) AAS
>>934
何かと比較じゃなくて時系列ね。
最も話題になったのは去年の今頃って話。
話題の最盛期に比べて今は7割。
これといって素晴らしい機能がリリースされた訳でも無し。
939(3): 2021/05/20(木)15:51 ID:DVPorPa2(3/4) AAS
>>936
個人開発するならそもそもコンテナ化の必要がない。
940: 2021/05/20(木)15:59 ID:nbAHJ6Nf(1/2) AAS
VM用意すれば心置きなくいじくりまわせるよねw
余計な知見()なんかいらないしww
941: 2021/05/20(木)16:14 ID:QqXlbgki(1/2) AAS
再現できるVMをつくるのはいがいとめんどい。
Dockerだとらくちんちん。
942: 2021/05/20(木)16:16 ID:jE+d/Fxl(2/2) AAS
>>939
環境構築済のものがすぐ使えるのがいい
943(1): 2021/05/20(木)16:46 ID:nbAHJ6Nf(2/2) AAS
まぁVMはシステムだからなぁ
1プロセスしか面倒見切れない人はDockerでいいと思うょ
944: 2021/05/20(木)17:52 ID:QqXlbgki(2/2) AAS
>>943
その理屈だとこうなる。w
× 1プロセスしか面倒見切れない人はDocker
○ ヒマ人はVM
実際は臨機応変。
945(1): 2021/05/20(木)18:19 ID:1220+Fxs(3/6) AAS
>>938
だから検索数じゃ何がオワコンか判断できないって言ってんの
Linuxみてみろよ。大幅に検索数減ってんだろうが
946(1): 2021/05/20(木)18:21 ID:1220+Fxs(4/6) AAS
>>939
個人開発とコンテナは全く関係ないとみんなが知ってる中で、
個人開発とコンテナを結びつけてしまった時点で
あんたが理解してないだけってみんなわかってしまったわけだがw
947: 2021/05/20(木)18:22 ID:1220+Fxs(5/6) AAS
>>939
仮想マシン(VM)の中でコンテナを使うっていう
使い方をするのがほとんどなんだが、わかってないんだよな
まあ多くの人はわかってると思うけどね。
だから検索数も減ってるわけで
948(1): 2021/05/20(木)18:52 ID:DVPorPa2(4/4) AAS
>>945
30年の歴史が在るLinuxと6年7年の歴史しかないDockerを何故同じと看做す?
linuxだって89年代初頭は検索があれば右肩上がりだったろうよ。
Dockerはそこまで枯れてない。WSL2が出たことすら最近。
この状態で減ってるのはヤバイだろ。
>>946
いつものお前だよな!相変わらずコミュ障だな!
病院行けって言ったろww>>936で個人開発とDocker(コンテナ化)を結びつけて話してるのに
お前だけが日本語を理解してないよなwwwホント、不思議な解釈するよね!
話しても時間の無駄だから、お前はもうレスするなよ!
949: 2021/05/20(木)18:54 ID:1220+Fxs(6/6) AAS
>>948
> 30年の歴史が在るLinuxと6年7年の歴史しかないDockerを何故同じと看做す?
だから、最初に言ったんだろ。
何と比べてるんだ?一つだけじゃ何の比較にもならんやろって
950(2): 2021/05/20(木)21:42 ID:cTdK2CMJ(1/2) AAS
Ruby on Rails では、
WSL2, Linux, Node.js(Webpack, Babel), Docker Compose, CircleCI,
VSCode(Remote Container, Remote WSL)、データベース
さらに最近は、AWS Fargate, Terraform, React, Vue.js
Docker Compose までが学校の初心者コース
もし、どこかの学校が新技術を採用したら、
競争上、他の学校も採用せざるを得ないから、
どんどん未経験者の技術力が上がっていく
今では、1年の未経験者が10年以上のプロよりも、技術力が上になってる!
951(1): 950 2021/05/20(木)21:50 ID:cTdK2CMJ(2/2) AAS
初心者は皆、YouTube で有名な雑食系エンジニア・KENTA のサロンとか、
AWS のくろかわこうへいのサロンへ行くから、
AWS Fargate をやる
だから、EC2 もいらない。
サーバーレス。OS レス
OSの事は、何も知らない
952: 2021/05/21(金)06:09 ID:tYg5cszE(1) AAS
開発もqiitaのコピペだしな。何も知らなくても大丈夫だよ
上下前次1-新書関写板覧索設栞歴
あと 50 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル
ぬこの手 ぬこTOP 0.252s