「docker compose」での複数環境の構築の話

はじめに

当記事では、開発環境を「複数」個、作りそれを活用すれば、
レビュー待ちの時に、先行で次タスクの開発をする
レビューの指摘事項対応と、次タスクの開発を環境わけで、やれるから作業しやすいよ
って話題が書かれてます。
ざっくりは、この話題です。
詳細は、メンドイ話なので、以降、ガッツリ書いてます。

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
手っ取り早く、複数環境の作り方だけ見たい、急いでる！！
という人は、

「docker-compose.ymlでのdocker環境にて「複数」環境を作る話」

の項目箇所だけ読めばいいです

その後、まだ、時間があれば、

「開発環境を「複数」個作ることのメリット」

の項目箇所を読めば、複数環境ある前提で、レビュー待ちの時に、どのように次タスクの開発がしやすくなるかがわかると思うです

急いでる人は、このように逆順で、つまみ読みしたらと思います

特に、急いでなければ、順番どおり熟読したら得るもの沢山あります
「複数環境の作り方」とは、直には関係ないが周辺でのいろいろな知識や考え方が
頭に入ってくるはずなので、順番どおり熟読したら得るもの沢山あるのではないかと思います。
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

★★
★★読むのがメンドイと思いますが。熟読したら意味がわかるように、
★★書いたつもりではあります
★★( 流し読み、斜め読みしたら、意味がわからなくなると思います )
★★熟読してもわからない箇所があれば、何か基礎となる知識が不足しているのではないか
★★該当分野の知識を高めてから、熟読を再チャレンジするなどしていただけたらと思います。
★★(なるべく、当記事だけの熟読でわかるようには書こうとしたが、他の人の知識レベルまで
★★わかりませんし、本筋と無関係な事を書きまくるのを避けるため、ある程度の基礎知識は
★★必要になってしまいます)
★★
★★この記事に書いてるノウハウを他で探してピッタリのは、なかなか無いと思います
★★なので、熟読してしまったほうがトータルで早い思います。
★★

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
すいません、私事のお知らせ ( CM をここで入れさせていただきます )
Docker環境ならば、Ubuntu(WSL2)がおススメ
https://zenn.dev/tazzae999jp/articles/07bed12c3ae6c0
こちらも、よろしく
WSL2の共通のLinuxカーネル上でDockerとUbuntuのディストロが動作するため
余計な変換処理や、余計な共有ファイルの結合など不要なため、
高速で安定します。
今回の
「docker compose」での複数環境の構築を沢山、好き放題やって、
作業効率をあげていっても、
高速で、非常に安定した環境で開発が行えるのが、Ubuntu(WSL2)だと言えます。

ただし、「他の環境が楽するためのやり方」が連携された時に、
(だから、Ubuntu(WSL2)側は、単なる被害者なのですが)
Ubuntu(WSL2)は、ホストとコンテナでファイルの所有者が同じになる(これがむしろ当たり前)
性質のため、権限問題が発生しますが、
それを、POSIX ACLという裏技で解決してます。その件も、上記の記事に詳しく記載され
Ubuntu(WSL2)での開発環境構築についての実践的で、これだけあれば、問題なし！！
な、レベル感での記載が満載なので、是非、上記、記事をよろしくです！！
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

話を元に戻して、

複数環境あれば、
他にも、gitで、何かトラブったときに、予備環境にリモートから直で
落としてきたところに、要る分だけ突っ込んで、プッシュするなどして、逃げれます。
（　トラブった環境は捨てればよい、また、いつでも、環境は増やせます )
などのメリットもあります。

それから、下記のような人がいた。
dockerがよくわからなくて、前のフェーズでの環境をつぶして、
新たなフェーズでの環境を作ってる
本当は、前の分も共存して動かしながら、今の分も動かしたい
つまり、共存して並列的に動かしたいのに、
それをどうやってやったらいいかわからないよって
人もいらっしゃった。

そのやり方も、
目次項目「docker-compose.ymlでのdocker環境にて「複数」環境を作る話」
で、書かれているやり方を理解すれば、
自分で応用して、好きな環境を作れるかと思います。

まずは、
目次項目「開発環境を「複数」個作ることのメリット」
で、
レビューの指摘事項対応と、次タスクの開発を環境わけで、やれるから作業しやすいよ
って話題を詳細に書いてます。
ここでは、実際の複数環境の構築のやり方は書いてません。

複数環境がある前提ならば、どのようなやり方で
git操作をしてけば、
レビュー待ちの間に、次タスクの開発が先行して進めやすいか

そこのノウハウが書かれています。

最後の目次項目「他、複数環境での実例」
で、他の現場での複数環境での作業の実例がさらっと書いてます。
守秘義務あるため、詳細には、書けませんが
思考法や、やり方は、工夫次第では応用が効くんだよ
ということを最後に説明したかったわけです。

開発環境を「複数」個作ることへの考え方

ここでいう「複数」とは、何を意味しているのかというと、
ローカルのgitのリポジトリのレベルで根元から別のフォルダに作ったものを複数個という意味である。

言い換えると「ls -a」をした時に、直下に「.git」があるフォルダ
また、言い換えると「git clone」で初期構築して作られるフォルダ
このレベルから、完全に別フォルダにしたものを複数個という意味である。

言語やフレームワークなどによって、様々なのかもしれませんが、「ls -a」で直下に「.git」がある
ローカルのgitのリポジトリのフォルダが、そのまま、使ってる言語やフレームワークのアプリのプロジェクトのルートフォルダで、
そのフォルダをVSコードなどで開く形で開発作業をする事が多いのではないか。
( そこをカレントディレクトリの状況で、ターミナルで、「code .」を打ち込むなどして )
★★★★★★★★★★★★★★★★
補足） 誤解を生むような表現だったので補足します。
★★★★★★★★★★★★★★★★
当記事で実例でだしてるコミュニティの環境では、
/jit_myDocker/laravel_next_docker
での上の階層の.gitリポジトリのレベルでの複数の環境の並列化してます。
そこも、設定系のファイルを編集のため、「code .」をすることはありますが、実装のためというわけではなさそう。

「code .」で、VSコード起動し実装作業するのは、
下の階層の
/jit_myDocker/laravel_next_docker/frontend/nextapp
や、
/jit_myDocker/laravel_next_docker/backend/laravelapp
★★★★★★★★★★★★★★★★

そのレベルのフォルダ(根本の「.git」を置いてるフォルダ)が、別フォルダの形で複数個ありますよ。

通常は、
/jit_myDocker
└── laravel_next_docker

だけで、この1つの環境でやりくりして、開発作業を行うのでしょうが。

それを複数個作って

/jit_myDocker
├── laravel_next_docker
├── w2_laravel_next_docker
├── w3_laravel_next_docker
├── w4_laravel_next_docker
├── w5_laravel_next_docker
└── wk_laravel_next_docker

のような構成にして、複数環境を使って、開発作業をしたほうが、効率的ではないですか
というのが、当記事でいう、複数環境のススメの話です。

それが、当記事で言ってる複数環境のことである。( 開発PC自体は1つでいいですよ。)
まず、この説明書きをしておかないと、何を言ってるのか理解されないと思いましたので、書いておきました。

Mac環境の人への注意事項

Dockerはそもそも、Linuxカーネルの上でしか動作しません。
私の環境は、Ubuntu(WSL2)です。
WSL2の共通のLinuxカーネル上でDockerおよび、Ubuntuのディストロが動作してます。
ですので、バインドマウントで、コンテナからホストの領域にアクセス時は、
同じカーネル内の別のプロセスが単に見に行ってるだけです。
ファイルシステムについても、
コンテナもホストも、ともに、ext4で同じなため、
変換処理のようなものが一切ありませんので、高速です。

ですので、私は、好き放題、dockerの開発環境で、複数環境を作って並行動作させてますが
安定稼働してます。
それと同じようなイメージで、Macでどこまでの個数を複数個並列して
安定稼働できるかは、定かではありません。

より少ない個数での複数環境に限定しておかないと、動作が安定しないかもしれません

なぜなら、MacはLinuxではなく、直接、dockerを動作できないため、
別個に、VMでLinuxカーネル動作させて、そこでDockerを動かしています。
Macの本体のホスト側と、Dockerのコンテナ側では、
ファイルシステムもaplfsと、ext4で異なるなどします。
動いてるカーネルが本体と、Dockerでは、別になっていてファイルシステムの異なります。

それゆえ、osxfs, fuse, virtioFSなどのファイル共有の仕組みで
バインドマウントしてるはずです。

ですから、これは、Ubuntu(WSL2)での状況に比べると
安定稼働に必要な複数並列での動作環境が、幾分、制約を受けるのではないかと予想されます

私は、Macユーザではありませんので、どの程度まで、いけるかのさじ加減はわかりません

そのさじ加減度合は、Macユーザの方で経験的に実証していただければ、
そして、もし、それがわかったならば、教えていただければ

この文章のところに、加筆をしたいと思います。

個数について、アバウトな言い方をしましたが、
docker compose build --no-chache
でイメージを作るところについては、より沢山できるが

docker compose up -d
でコンテナを起動する数は、限定的で、
docker compose stop
で、今使ってない分を適宜、停止して、

一度に、起動するコンテナ数を制限するようなやり方をすれば、
Macでも、これだけの個数は複数環境いけるよ

など、そういうレベル感での情報があれば、幸いで
そのイメージで加筆できたら、いい感じだなぁ

なども思っております。

ここでは、一旦、私が当記事で書いてるイメージでの好き放題複数並列の個数を増やしまくってるような
イメージではやれないかもしれません。
数は限定されるかもしれません。
ということだけ、Macユーザの方に、あらかじめ、ご了承してもらうための
説明文を書いておくことにしました。

開発環境を「複数」個作ることのメリット

いくつか、メリットはあると思うです。よく考えられるのは、下記の2点かと思うです。

• 以前に開発していたシステムも、別個に並列で動作できるようにしたい
  つまり、以前のシステムのソースコードを参照しながら、その実装を流用して
  今の開発をするにあたって、
  今開発中のシステムだけでなく、以前の分も、別個に並列的に動作できる状況にしたほうが
  参照元にしている以前のシステムも把握しやすい。
  そのために、複数環境を並列動作させる　ことのメリット
• 開発中に、プルリクのレビュー待ちで作業が止まらないようにして、
  次のタスクの開発がしやすくなる。　ことのメリット

ここでは、後者の
「プルリクのレビュー待ちで作業が止まらないようにして、次のタスクの開発がしやすくなる。」

この件について、細かい話を順を追って説明します。

ここでの目的は、
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
★★　もし、複数環境があったら、どのように開発作業を効率化していけるかを具体的に示すこと。
★★　複数環境作ることに、メリットが感じられなければ、わざわざ、しようと思わないでしょう。
★★
★★　具体的に、どのように開発作業が効率化されるのか示せば、
★★　「そういうことであれば、是非、複数環境作ってやってみたい」
★★　と、思う人がいるかもしれません。
★★　
★★　単に、複数環境作る方法論を示しても、そのモチベーションがなければ、
★★　しないでしょう
★★　
★★　まず、そのモチベーションの部分のため、
★★　もし、複数環境があったら、どのように開発作業を効率化していけるかを示します。
★★　
★★　それを見ても、別に、「自分は要らない」と思うのでしたら
★★　その人は、複数環境を作らなくてもいいんじゃないでしょか。
★★　
★★　その考え方は、効率的だ！！
★★　そういうことか！！、それなら、是非、やったほうがいい
★★　と思う人であれば、複数環境を作ればよいと思います。
★★　
★★　そのように、思えるのかどうか、まずは、ここの説明を読んで、確認してみてほしいです。
★★　
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

プルリクを出した時に、レビュー待ちなる。
次のタスクは、レビュー中のプルリクでの実装をベースにして、追加実装が必要なケースもある。

本来は、レビューが承認され、マージされた後、本流のdevelopなどをプルして
最新のdevelopなどから分岐されたfeatureで次の開発をすべきである。

しかし、レビューが承認され、マージされるまで、待つのが時間の無駄である。

レビューが承認され、マージされる前に、
次のタスクの開発作業をはじめたいが、レビュー中のプルリクのソースコードもベースとしてある環境で
次のタスクを仕掛かりたい。なぜなら、レビュー中のプルリクの分の実装もベースにして、次のタスクは追加実装したかったりするからだ。
( 作業効率を考えて、同じエンジニアに同じテーマの開発をシリーズもので任せたりすれば、そのエンジニアにとっての次タスクに開発すべきものは、つい、さっき、プルリクを出したソースコードの実装をベースにした追加開発になることは多いだろう )

そんな時に、もし、複数の環境があれば、安定したやり方で、うまくやれる。
人によっては、gitのスタッシュをうまく活用すれば、１つの環境でもやりくりできる　という考え方もあるようだ。

ただ、複数環境があって、それを活用するのも、やり方として、よろしいのではないか。
その必要性は、人によりますので、強制はしませんが、考え方として参考までに知っておいてもよろしいのではないか

ここから具体的に書くと、

「環境1」で、最新のdevelopから分岐したfeature111にて、プルリクを出してレビュー待ちになったとします。
そのプルリクのレビューが承認され、developにマージされる前に、
次のタスクの開発作業をしたいが、feature111で実装したソースコードも、前提としてある状況で
次のタスクの開発作業をしたい。

そこで、
別の環境の「環境2」で、
git fetch --all
git checkout -t origin/feature111

補足:
上記のコマンドの意味がわからない人は、
https://zenn.dev/tazzae999jp/articles/07bed12c3ae6c0
の
gitの「リモート追跡ブランチをローカルブランチ化」方法
の項目の説明を参照のこと

補足:
上記をする前に、先に、developブランチにいる状況で、
git pull origin develop
をしておいて、developが最新化された状況を作っておいたほうがよいです。
この「環境2」で、後ほど
feature111からdevelopへ
ブランチの切り替えをすることが想定されます。
ブランチを切替時に、切替元と、切替先の差異が少ない方がgit上のトラブルが起きにくいと
感じておりなるべく、差異を減らすため、一旦、先に、developブランチにいる状況で、
git pull origin develop
での最新化をする。（もしくは、最新化されているかの確認をする)
をした後に、
git fetch --all
git checkout -t origin/feature111
したほうが、後ほどのトラブルの確率を下げれると思ってます。

をするとプルリクを出してる前タスクの「feature111」の状況を
リモートから直接、落としてきて、「feature111」のソースコードがある状況で、
次のタスクの開発作業を「環境2」で、はじめられます
この段階で「環境2」では現在のブランチが「feature111」になっています。

でも、この「環境2」での次タスクを開発している際中で実装した分は、
一旦は、コミットやプッシュはしないでおくべきだと思います。
なぜなら、最終的に次のタスクは、前の分のプルリクが承認されてマージされたdevelopから派生させたfeatureでプルリクを出す必要があるので、この状況でコミットやプッシュするのはまずいです

ですから、この「環境2」で次のタスクでの開発作業での分は、一旦は、
未ステージング領域で置きっぱなしにしておきながら、次のタスクの開発作業を進めておきます。
その状況で、実装、デバッグ、動作確認など、次のタスクの開発作業をすすめておきます。

しばらくすると、前のfeature111のプルリクについて、レビューが実施され、
レビューの指摘事項の対応をしてくれと、レビューワーから連絡が来ることがあると思います

そしたら、そのレビューの指摘事項対応を、先に、優先的にやるべきだと思います

しかし、「環境2」のほうでは、次のタスクの開発のためソースコードを変更しまくってるので
そこで、feature111のレビューの指摘事項対応はやりにくい状況ではある。

「環境1」のほうはfeature111についてのプルリクを出した時点の状況のままになっている
ですから「環境1」のほうで、feature111についてレビューの指摘事項対応をして、
再プッシュまでやればよろしいと思います。
そこまで「環境1」でやりきったら、また、feature111について、再レビュー待ちになると思います

そしたら、また、「環境2」に戻ってきて、次のタスクの開発作業の続きをやれば、よろしいのですが
今、feature111でレビューの指摘事項対応でプッシュした分の実装も取り込んだうえで、
次のタスクの開発作業の続きがしたいわけですよね。

「環境2」では、現在のブランチがfeature111で、
次のタスクの開発分は、未ステージング領域に置きっぱなしの状況です。
そのまま、
git pull origin feature111
をすればよいわけです。そしたら、先ほどのレビューの指摘事項対応の分も取り込めます
ただ、この「git pull origin feature111」は怒られてできない場合があります。
「git pull origin feature111」によって落ちてこようとするファイルと同じファイルが
未ステージング領域にある場合です。

その場合は、該当のファイルの相対パス ( gitコマンドはローカルのgitのリポジトリのルートで打ち込むのが基本だが、そこからの相対パス )
が示されたエラーメッセージがでて、「git pull origin feature111」自体が失敗します。
完全に失敗しますので中途半端な状態にはなりません。プルは失敗したら、プルの行為を行う前状態が保持されます。

そうなった場合の対応ですが、未ステージング領域などは、gitスタッシュなどをつかって一回退避して
未ステージング領域のファイルがなくなった状況で、プルを成功させ、
gitスタッシュからの復元時の自動マージ機能で復元すればよいよ。という考え方があるようですが。

私個人は、怒られた該当のものだけ、相対パスが示されてますので
cp コマンドのコピー元の第１引数にそのまま、その相対パスを指定し、別のフォルダを第２引数にして
怒られた分だけバックアップをとってしまいます。

そして、その後、
git checkout HEAD -- <<該当の相対パス>>
で、ローカルのHEADリビジョンに戻します

補足:
上記のコマンドの意味がわからない人は、
https://zenn.dev/tazzae999jp/articles/07bed12c3ae6c0
の
ローカル編集中の内容を元に戻す方法( git現在のブランチの最新リビジョン（HEAD）に戻す )
の項目の説明を参照のこと

それを怒られたファイルの分だけやります。
そしたら、未ステージング領域から、その怒られた分だけ、消えます　（　ローカルのHEADリビジョンに戻ります )

その後、再度、
git pull origin feature111
をすれば、今度は、成功します。

その後、バックアップとった分と、WinMergeなどのソースコードの差分を見るソフトウェアで比較して
必要な個所（つまり、次のタスクの開発で実装している必要な分 )を手作業で戻してます

ここまでやれば、feature111でのレビューの指摘事項対応で対応した分の実装も取り込めて
それも、ベースにしたうえでの、次のタスクの開発作業の続きが行える状況になりましたので、

引き続き「環境2」での次のタスクの開発作業が続行できます。

そのうちに、他の人のプルリクが承認されてdevelopにマージされたとします。
そしたら、それも、取り込んだうえで、次のタスクの開発作業の続きができたらしたいわけですよね

★★★★★★★★★
自分のタスクに無関係ではないかと考えるかもしれませんが、私は、そうは思いません。
本来は、人の開発分も取り込んだうえで、なるべく、その時の最新状態のコードベースに
自分がいま開発してる分で、動作が問題ないかをすべきかとは思うです。
それをやっておけば、少なくても、自分が開発した分は、結合レベルでのトラブルがないと
品質保証できます。また、人の分を取り込んだ結果、動かなくなった場合
誰かが何かを間違ってるということです。自分かもしれません。
だから、それも含めて、早い段階で調査できます。そして、
その件を早い段階で連絡や、相談ができます。
・他の人の実装を取り込んで最新化したら結合レベルでバグってしまうような
実装を自分のタスクでやってしまってるケースがあれば、軌道修正できます。
人の分を取り込んで最新化することをさぼってしまったがゆえに、それを知らずに、
本当は、最新のコードベースで結合レベルでバグってるのにも関わらず、
できましたと、次のタスクの分をプルリクをだしてしまうなどの愚行を防ぐことができます。
・その軌道修正は、他の人が間違ってるのか、自分がおかしいのか、どちらも間違っていないが
単にインターフェースについて、意思疎通不足の可能性もあります
問題は、様々かもしれませんが、実際に、うまく結合して動かないということが
早期に発見できる可能性が高まるのですから、常に最新化したコードベースで自分の
開発をしてるほうがよいのではないかと考えています。
せっかく動作確認や、テストをするのであれば、常に最新化したコードベースに対して
自分の開発分がある状況でするほうがよいと思うのです。
この思想をもって、
「それも、取り込んだうえで、次のタスクの開発作業の続きができたらしたいわけですよね」
と、上記では書いています。
★★★★★★★★★

slackなどで、プルリクがマージされたので、取り込んでねって連絡があればよいですが、
その連絡を忘れていたり、こなかったり。

３つ目の「環境3」があればよいわけです。基本的に、developなどで頻繁に、
いつも、「環境3」でプルしておれば、特に、落ちてくるものがなければ、「Already up to date.」と表示されるわけです。
私は、しょっちゅう、プルしてます。たいてい「Already up to date.」でますが、気にせず、しょっちゅうプルしてます

誰かの変更を検知して、なるべく早く取り込みたいからです。
作業が一段落したタイミングで手癖のように頻繁にしてます。

普段、しょっちゅう、プルして、「Already up to date.」を出してる状況で、
実際に、「環境3」で何か落ちてくれば
追加で誰かのプルリクが承認されてマージされたことを気づくことができます。

ですので、私は、環境は最低３つあればよいのではないかと考えています

１つ目は、プルリクのレビューの指摘事項対応の環境
２つ目は、次のタスクの開発作業を行う環境
３つ目は、予備になにかあったときの環境で、他の人のプルリクが承認されたことを気づくトリガーにも使えます

なにか、git上でトラブルが起きてハマってぬけられなくなったとき、予備環境があれば、
そこに、git checkout -t origin/featureXXX で、リモートの分を復元した上で、
要る分の実装をそこに、Winmergeなどを使って、追加するなどで復元できます。

それが、できれば、トラブって、ぬけられなくなった環境は、最悪は、捨てればよいと思うです。
また、環境を作ればよいです。生きてる環境が最低、３つあればよく
開発の初期のできるだけ早い時期に、環境をもう１個作るために最低限なにをやればいいかのノウハウを確立させて
そのノウハウだけ、書いた資料を作り、それ、見ながら、素早く環境を１個増やせる状況を作ればよろしいと思います。

この３つの環境をローテーションして使えばよろしいのではないか、と考えています
場合によっては、すごく、めんどうで複雑なタスクを沢山こなす諸事情により、もっと環境増やした方が良いケースもありますが
そういうことがなければ、最低３つ環境あれば、よろしいのではないかと考えてます

話を元に戻しますが、

他の人のプルリクが承認されマージされたら、どうすればよいかですが、
現在の自分のプルリクのレビューの指摘事項対応の環境に割り当たってる
「環境1」でマージ作業すればよいかと思ってます

「環境1」は今、feature111についてのレビューの指摘事項対応の環境になってますが
ここで、
git checkout develop
で、developブランチに移動します

git pull origin develop
で、他の人の分の承認されたプルリク分を取り込んで最新化します。

再び、git checkout feature111 でfeature111にブランチを切り替えて、
git merge --no-edit develop

developからfeature111にマージします。

補足:
マージの時に、「--no-edit」をつけてる件は、
私がUbuntu(WSL2)環境で開発しているからです。
そうでない人は、「--no-edit」はなしでもよく、気にしなくてもいいと思います
Ubuntu(WSL2)環境に興味があり、なぜ、ここで、「--no-edit」をつけているかの
話題に興味があれば、
https://zenn.dev/tazzae999jp/articles/07bed12c3ae6c0
の
git mergeでエディタを起動しないようにする設定の話
の項目の説明を参照のこと
エディタ起動抑止の設定が3種類あり、私は、3種類の対策を、すべてやってます。
その関係上で、私は、マージするときは、常に「--no-edit」指定することを
癖づけることにしてます。
そのため、「--no-edit」があるだけです。
「　そうでない人は、「--no-edit」はなしでもよく、気にしなくてもいいと思います　」
と上記で書きましたが、「--no-edit」をつけてれば、どんな環境でも
マージの時に、エディタ起動抑止できます。その環境の設定の問題です
Ubuntu(WSL2)以外であれば、デフォルトの設定が、「マージの時に、エディタ起動しない」
なのですから、「--no-edit」をつけなくてもマージの時にエディタ起動しない可能性が
高いだけです。でも、100%そうとは限らない。(環境の値がズレていたら限らない)
この点が気になるならば、上記の参照先を読んでいただければと思います。

もし、コンフリクトが起きたならば、その対応もして、コミットします。

git logでマージした分（および、コンフリクト対応したなら、その分のコミットも)
含まれた状況を確認して、

git push origin feature111
で、レビュー中のプルリクに自動反映すればよいです。

もし、コンフリクト対応があった場合は、レビュー対象の差分で表示される
ソースコードに変化あるかもなので、レビューワーに連絡したほうがと思います

その後、次のタスクを開発中の「環境2」で、
git pull origin feature111
をやれば、他の人の承認されたプルリク分も取り込んだうえで、
次のタスクの開発作業が続行できる状況になると思います

それから、もし、次のタスクの開発が、動作確認まで終わってるのにも関わらず、
前のタスクの自分のfeature111について、まだ、レビューが終わってない
( 指摘事項対応は迅速に自分が行って連絡しているのにも関わらず )

そんな状況は、あってはならないと思ってます
それは、はっきり言って、レビューワーが仕事してないです。（　遅すぎます　）
諸事情はあるかもしれませんが、それは、もっと早くしてくださいと、依頼を出してもよいのではないかと思ってます。

ですので、そこは、自分のほうが「レビューの指摘事項対応を迅速に適切に対応してる状況」
だと言える状況では、
レビューワーをつついても、全然問題ないとおもっております。

そのような事がない前提で、当記事の説明は続行します。

話を元に戻しますが、

しばらくすると、当初の自分のfeature111のプルリクが承認されて、developにマージされたとします。

そしたら、やるべきことは、
次の開発作業をしている「環境2」で
git checkout develop
git pull origin develop
だと思います

次のタスクの開発作業分は、未ステージング領域に置きっぱなしであるため
ブランチの切り替えをしても、プルしても、そのままついてきます。

そのままついてくるのですが

ブランチの切り替えや、プルのときに、怒られて失敗することがあります

理由は、未ステージング領域に置きっぱなしのファイルでありまして、
その場合は、怒られたメッセージで該当のファイルだけ、相対パスが表示されます

別にすべての未ステージング領域に置きっぱなしファイルが怒られるわけではないです。
経験上、それらが仮に、10ファイルあっても、怒られるのは、せいぜい、１ファイルや、２ファイルだったりしますので、
その怒られたものだけを対応すればよいのです。

ここで、gitスタッシュを使って云々の考え方の人もいますが
自分は、その怒られた分だけ、バックアップをとって、それをHEADリビジョンに戻して
ブランチの切り替えや、プルを成功させてから、
バックアップからWinmergeなどで差分を見て、手動で要る分（次のタスクの開発で要る分の実装）を反映させてます。

git checkout develop
git pull origin develop
まで、成功させて、そこに、次のタスクの開発の実装分が入ってる状況を作ります

つまり、自分の前タスクのfeature111の分や、他の人の分も含めた最新分を取り込んで、
かつ、次のタスクの開発作業分の実装も、入ってる状況を作って
なおかつ、次のタスクの開発作業、動作確認まで終わりました

ということになれば、

git checkout -b feature222
で、最新のdevelopから派生させて、feature222を作ります。

ブランチは、今、作ったfeature222に移動した状況になります。
未ステージング領域に置きっぱなしである、次のタスクの開発分の実装も、そのままついてきます。

ですので、それらの未ステージング領域に置きっぱなしの次のタスクの開発分の実装について、
ステージングに、追加し、コミットしてプッシュして、feature222についてのプルリクを出せばよろしいかと思います。

そして、feature222のプルリクを出したら、レビュー待ちになってしまうので、
別の「環境3」などで、
git fetch --all
git checkout -t origin/feature222
で、リモートから直でfeature222をそのまま落としてきて、
さらに、その次のタスクの開発作業を「環境3」で続行すればよろしいかと思います

すると、
「環境2」がfeature222のレビュー指摘事項対応の環境
「環境3」が先行開発環境
「環境1」が予備環境。および、他の人のプルリクが承認されてマージされたことを発見するためのトリガー環境
などのようにローテーションされる形となります。

以後は、同様のことの繰り返しになります

複数作ってる環境でローテーションさせながら、レビュー待ちの時間なしで、次のタスク、次のタスクの
開発作業が行える状況となってます。

ここで、

自分のほうが「レビューの指摘事項対応を迅速に適切に対応してる状況」だと言える状況を作り
次のタスクが動作確認まで終わってるのにも関わらず、前の分のレビューが終わってないことについては、
あってはならないこととして、適切にレビューワーに仕事するようにつつきまわしておけば
レビュー待ちのために作業が止まることがまったくなく
矢継ぎ早に、どんどん、プルリクが出せます

前の分のプルリクが承認され、マージされる頃には、次タスクが大半終わってる状況になってたりするので、効率よくタスクをこなすことができると思います

次タスクの開発のためにソースコードを編集しまくってる状況では、
前タスクのレビューの指摘事項対応がしにくい問題も
複数環境あって、これまで説明したようにやれば、問題がなくなると思います

もちろん、人によっては、gitスタッシュなどをいい感じに使いこなして、やりくりすれば、１つの環境でも全然、いけるよって
思想の持ち主もいらっしゃるのかもしれませんが、複数環境でやってたほうが、わかりやすいし、作業内容自体が安定するんじゃないでしょうか

また、タスクの割り振りや、スケジューリングしている人間にも、ここでの作業イメージを、是非とも伝えておきたいとは感じております

要するに、「プルリクのレビュー依頼を出して、それが承認され、マージされたら」、タスク完了で、
そこではじめて、次のタスクを割り振ればよい

みたいに、思われると、結局、次の作業が割り振られるまでの間、無駄な待ち時間になってしまうわけです。
そりゃ、レビューがなされて、指摘事項があれば、その指摘事項対応できますけど
レビューがなされるまでの待ち時間、指摘事項対応後の、再レビューの待ち時間
がすべて、無駄な待ち時間になるわけです。

そうじゃなくて、プルリクをだしたときには、次のタスクの開発が、これまで、説明したような要領でできるわけですから、
プルリクをだしたときには、次のタスクが割り当たってなければ、ならないわけです。（無駄な待ち時間をゼロにしようとしたら）
ですので、あと、１日で、あと半日で、プルリクをだせそうですので、今のタスクをプルリクをだした後の次タスクの割り当てを考えといてくださいね

そして、プルリクをだす、少し前、もしくは、プルリクをだすやいなや、すぐ、次タスクが割り当たって
これまで、説明した要領で、次タスクの開発が開始される。

それ前提でのタスク割り振りで、考えといてね
ということを、タスクを割り当てする人間に説明するには、これまでの要領でのやり方を説明し、理解しておいてもらう必要がありますよね

ネット上で、自作のこのような記事があれば、この記事を使って、それを説明できるわけで、
今後、自分自身が、その説明をするための、ネタとしても使えるので、このような記事を書いてます。

このような説明するのがメンドイ話は、ネット上で誰でも見れる形で記事にして、それをネタにして、説明するのが効率的だと
思ってますので、それを実践するための、私個人の記事であります。

ですが、それが、他の人にも役立てば、なおよしだよね。とは、考えております。

どうせ、業務中の時間は拘束時間であり、そこでの無駄時間を減らしたい
進捗を進めておけば、プライベート時間を守れます。
つまりは、
進捗遅れでの残業や、休日対応などを防げくことができます。
また、進捗がよければ、どうしても外せないプライベートな用事での休暇も取りやすい。

プライベート時間を確保すること、侵害されないこと、に貢献できます。

説明するのが、メンドイ話でしたが、プライベート時間を守るためには必要だと思います。

私は、Ubuntu(WSL2)にて開発環境を作ってますが、
ここで、紹介した複数の環境を活用して開発作業を進めるときに、
windows terminalを使って作業すると、とても快適です。

code .
は、カレントディレクトリでVSコード開きます

explorer.exe .
で、カレントディレクトリでエクスプローラーを開きます
( expl まで打ち込んで、TABをおしたら、explorer.exeとのその後ろに半角スペース1つまで
自動補完されるので、「.」を入力してエンターでよい )

補足:
まさか、docker-compose.ymlや、Dockerfileなどの設定系のファイルまで、
Linuxのターミナル上で、vimエディタで編集とかしたくないわけで、
VSコードで開いて編集というのもありますが。
普通にexplorerで開いてwindowsの操作で、別の環境のものをコピペして
編集したりしたいわけで、sakuraエディタなどで編集したいときもあれば、
Winmergeにexplorerで表示中のファイルをドラッグアンドドロップして
比較もしたいわけで。そのようなWindows側の操作との入口がexplorerなわけです。
それから、sakuraエディタなどで編集したら、保存時に改行コードがCRLFでなく
全体がLFで統一されるように作業すべきです。（そのやり方は自分で調べて下さい)
★★★★★★★★★★★★★★★★★★★★★★★★★★★★
gitの資産は、リモート側は、改行コードはLFで保存されます。
（それが普通。Macや、Linuxユーザに配慮してのこと)
Git for Windowsは、インストール時に、Windowsユーザに配慮し、
リモートからローカルへは、CRLFに、逆に、
ローカルからリモートへは、LFに変換する設定で、インストールされます。
( インストール時に設定を変更しなければ、デフォルトでそうなります )
しかし、Ubuntu(WSL2)は、PATトークンの入力なしで、git push可能にするために、
「Git for Windows」の認証機能を間借りする設定にしたりしますけれども、
gitコマンド自体は、Ubuntu(WSL2)にあるものを使いますので、そのような変換はしません。
ですので、ext4の領域にあるソースコードなどは、改行コードはLFのままで
編集保存をしておくべきです。
しかしながら、Windows側のアプリを使うと、CRLFで保存してしまうことがありますので、
そうならないような、配慮をしての作業が必要とされますので、
そこの意識が必要です。
VSコードで作業してたら、元のファイルがLFならば、LFのまま、編集されます。
他のWindowsの操作で、なにかのアプリを使う時に、気を付けるべきです
これを、注意事項としてここに書いておきましたので、
ミスって他の人に迷惑かけないようにしたほうがよいです。
★★　Ubuntu(WSL2)をご利用の際は、この点を、くれぐれくも、お気を付けください。★★
★★★★★★★★★★★★★★★★★★★★★★★★★★★★
Windowsの機能で保存した場合は、Ubuntu(WSL2)にインストールした初期ユーザで
操作することになります。ファイルを作ったら、所有者もそのユーザになります。
ですので、そもそも、そのユーザで権限があるファイルや、フォルダでしか変更操作できないので
その場合は、Linuxターミナルで必要に応じて、sudoなどでroot権限使って調整が要ります。
「ファイルを作ったら、所有者もそのユーザになります。」ですが、それは、
wsl.confの設定で決まります。
Ubuntu(WSL2)のその部分にご興味があれば、
https://zenn.dev/tazzae999jp/articles/07bed12c3ae6c0
の
wsl.confの設定変更時の参考ネタ
の項目を参照してください。
このように、Ubuntu(WSL2)は、Windowsの便利機能をいかしながら、
Linux環境が使える。というスグレモノのため、私はとても気に入っています

https://zenn.dev/tazzae999jp/articles/07bed12c3ae6c0
の
explorer.exeでUbuntu(WSL2)の領域でファイルをコピーなどした時にファイル名が「Zone.Identifier」で終わるものが自動作成されてしまう件
の項目も参照のこと

補足:
上記の
→ しかし、Ubuntu(WSL2)は、PATトークンの入力なしで、git push可能にするために、
→ 「Git for Windows」の認証機能を間借りする設定にしたりしますけれども、
の部分の記述がなんのことなのか、気になる人は、
https://zenn.dev/tazzae999jp/articles/07bed12c3ae6c0
の
PATトークンの入力なしで、git push可能にするため、Windows側の認証機能を間借りする方法
の項目を参照してください

windows terminalが入ってるとスタートメニューから、terまで打ち込むと
「ターミナル」というものが出てくるのでそれを押すと起動します。

複数タブで、作業できるため、並行作業中の分をタブ表示しとく感じです
最初、Powershellが起動しますが、適切に設定してたら
wslと打ち込めば、いつも、使ってるUbuntuのディストロに入れます。
( ディストロを指定しないときの、デフォルトをいつも、使ってるディストロにする設定 )
Ubuntu専用の窓より、windows terminalのほうが作業しやすいです。

※個人情報の部分は伏せた形の画像にしてます

タブは左右の位置関係はドラックアンドドロップすれば調整できますので、
たとえば、
「一番左のタブ」が次のタスクの開発環境
「真ん中のタブ」がプルリク中の分の「レビュー指摘事項対応の環境」
「一番右のタブ」が予備環境。および、他の人のプルリクが承認されてマージされたことを発見するためのトリガー環境
などにするように、マイルールをきめて、作業すれば、わかりやすいと思います。

windows terminalは、Microsoft Storeからインストールできます。

※個人情報の部分は伏せた形の画像にしてます

それから、
https://zenn.dev/tazzae999jp/articles/07bed12c3ae6c0
こちらの↑↑の記事には、Ubuntu(WSL2)での、各種ディストロのインストールや、設定
windows terminalの話、WSL2の基礎的な話や
また、dockerや、gitの話。チーム開発時の他のMac環境での楽な設定を連携されたときに、
被害をうけて権限問題をPOSIX ACLの裏技で解決する話
とにかく、Docker使うなら高速ですよって話
環境トラブルに関して、この初期設定しとけば、快適で防げるよ
など、実践的なノウハウが満載なので、ここの記事を熟読して完全理解すれば
Ubuntu(WSL2)で、ほぼ、困らないよってレベルでの実践的な内容が満載なので
是非、この記事を活用して、Ubuntu(WSL2)で、いっとこう！！

お知らせ(CM)は、この程度にとどめておいて、

次の目次項目では、いよいよ、docker-compose.ymlを使った環境での
複数環境構築のやり方の具体例の説明をすることにします。

docker-compose.ymlでのdocker環境にて「複数」環境を作る話

これまで、複数環境を作ったら、何が嬉しいのか。
その複数環境をどう活用するのかの、考え方に焦点を当てた説明を書いてきましたが

じゃぁー、実際に、その複数環境は、どうやって作るの？
みたいな疑問が出てくるのが、当然かと思います。

そこで、以前、個人的に、かかわったコミュニティでdocker-compose.ymlを
使ったdocker環境でチーム開発をしていた時に、
その設定系のファイルなど加工して、複数環境を作っていった時に、どうしていたか。
その複数環境の作り方の「実例」と、「説明」をこれから書いていきたいと思います。

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
もし、当項目の記載内容で何を言ってるのか、よくわからなければ、
https://zenn.dev/suzuki_hoge/books/2022-03-docker-practice-8ae36c33424b59
のzennの本を全部読んで見たらとは思うです。
概念はつかめるとは思うですが、1つ1つの細かいdockerのコマンドを覚えて実践するの大変だと
思うです。だから、docker-compose.ymlで、開発環境で必要な分のコンテナを1セットでまとめて、
一括で操作する「docker compose」の便利な方法をとってるんだろうと思います。
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

そのコミュニティの管理人には設定値の実例での記事掲載の許可をもらいました。
一般的に公開されている技術の組み合わせでの設定値の内容が構成されているため、
特に、秘匿性が高い内容でないことと
そのコミュニティのメンバーに複数環境構築のやり方を質問されたときの回答として、
私個人の当記事の掲載内容の説明を使ってもらって構わないという条件で、
実例での設定値を示した記事掲載の許可をもらってます。

そのコミュニティでの開発案件では、docker-compose.ymlを使った
docker環境の構築をしておりました。

実際に、このコミュニティ内で使われていたdocker-compose.ymlを下記に示します。

version: '3'
services:
 app:
   container_name: laravel_app
   ports:
     - "8080:80"
   build: ./Docker/App
   volumes:
     - ./backend:/var/www/html
 front:
    container_name: next_app
    ports:
      - "3000:3000"
    build: ./Docker/Front
    tty: true
    environment:
     - WATCHPACK_POLLING=true
    volumes:
      - ./frontend:/www/html
 db:
   image: mysql:5.7
   container_name: laravel_db
   environment:
     MYSQL_ROOT_PASSWORD: root
     MYSQL_DATABASE: laraveldb
     MYSQL_USER: dbuser
     MYSQL_PASSWORD: dbpass
     TZ: 'Asia/Tokyo'
   command: mysqld --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
   volumes:
     - ./Docker/DB/volume:/var/lib/mysql
     - ./Docker/DB/my.cnf:/etc/mysql/conf.d/my.cnf
   ports:
     - 13306:3306
 adminer:
    container_name: adminer
    hostname: adminer
    image: adminer:4.7.5
    restart: always
    ports:
      - 8088:8080
    depends_on:
      - db

意味はわからないかもしれませんが、ざぁっと、見て、だいたいどんな事が書かれているのか
自分なりに想像して予想してみていただきたく思うです。

★★　意味がわからないから、すぐ、顔をそむけるのではなく、わからないながらも、
★★　おそらく、こういう意味ではないかと、予想してみるのが大事です。
★★　知らなくても、見ていったら、おそらく、こういう意味かなぁと、想像できるものは
★★　あると思います。それがどの程度なのかは、各自のスキルレベルで異なるかもしれませんが
★★　多かれ少なかれ、予想できる部分もあるかと思います。
★★　いきなり、答え　を見るよりも
★★　あらかじめ、予想しておけば、仮に間違っていたとしても
★★　どの部分をどう勘違いして、間違っていた、これはそう考えべきだったのか！！
★★　のように、深めに理解できて、記憶にも残るわけですから
★★　そのほうが、トータルで早く理解できます。
★★　また、あらかじめ、予想しておけば、というのは、いくら考えてもわからないのに
★★　長時間無駄にうんうん考えるということではないです。
★★　ある程度は、こうかなと、短時間で予想をたてて、デバッガーで動かしてみたら
★★　判明することが多く、ある程度、予想たててないと、どうやったら、その該当部分を動かすかも
★★　見えない。だから、ある程度は、予想たてて、考えるけど、無駄に考え過ぎずに
★★　さっさと予想が当たってるか、調べる、作業して動かしてみる。
★★　理解や、作業完了に必要なトータル時間が少なめでも効率が上がるようにする。
★★　みたいなお話しでした。

はっきり言って自分も知識なく、適当に見てます
ただ、適切にインデントがなされているので、これがヒントになります

version: '3'
services:
のあとに、
インデントがなされて

app:
front:
db:
adminer:
の４つがあります。だから、このdocker-compose.ymlは、この４つを
１セットにして、環境を操作するような設定ファイルだろうと想像つきます。

この４つとも、「container_name:」「ports:」があります
db:
adminer:
には、「image:」はありますが、
app:
front:
には、「image:」がありません。
しかし、その代わりに「build:」があります。

これは、何でしょうか
db:
adminer:
では、おそらく、dockerHubに登録されているイメージ名を直接「image:」のところに、
指定して、そのイメージをそのまま使って、コンテナまで構築しますよって意味だと思います

一方、
app:
front:
「build:」に書かれた相対パス( docker-compose.ymlがおている位置からの相対パス)
にDockerfileが置いてあり
そのDockerfileにdockerHubにに登録されているイメージ名の指定があり、
そいつに、Linuxコマンドを複数組み合わせて ( dockerの用語でレイヤーを重ねて )
イメージを作り、それに基づき、コンテナを構築しますよってことだと思います。

「ports:」の

- "8080:80"
- "3000:3000"
- 13306:3306
- 8088:8080

の部分は、一体何を表しているのかというと
たとえば、

- "8080:80"

について、左側の8080はホスト側でのアクセス時のポート番号、右側の80はコンテナ側でのポート番号です。

たとえば、

 app:
   container_name: laravel_app
   ports:
     - "8080:80"
   build: ./Docker/App
   volumes:
     - ./backend:/var/www/html

このコンテナ「laravel_app」の内容は、Dockerfileを見ないとわからないのですが、
ここでは、それを割愛し、このコンテナは、phpでwebアプリを開発し、それをapacheのwebサーバーで
動作するのに、都合がよいコンテナになってます
そのapacheが、コンテナ内で80のポート番号で起動してます
本来であれば、

http://localhost:80     ( 80の場合は、ポートを省略して、http://localhost にできますが　)

でアクセスできるはずですが、これは、コンテナの内部の話なので
ホスト側のPC ( 開発作業してるWindows端末や、Mac端末や、Linux端末のことです。 )
で、ブラウザからアクセス時には、ホスト側のポートの8080を指定して

http://localhost:8080

でアクセスすることになります。
すると、その昇り通信、下り通信について、80番で動いてるコンテナ側と連携して動いてくれる　（　通信をフォワードしてくれる )
そういう設定だと思うです。
（　私、知識が適当なので、アバウトな理解で、厳密には間違ってるかもしれませんが、だいたいはあってると思います )

★★★★★★★★★★★★★★★★★★★★★★★★
バインドマウントに関する「余談」
★★★★★★★★★★★★★★★★★★★★★★★★
余談ですが

   volumes:
     - ./backend:/var/www/html

の部分は、
./backend:/var/www/html
の「:」記号の左側の
./backend
がホスト側の相対パスです。
つまり、docker-compose.ymlがあるフォルダの、
/jit_myDocker/laravel_next_docker
からの相対パスでの「./backend」のことです。
これは、絶対パスでは、
/jit_myDocker/laravel_next_docker/backend
のことを表しています。
./backend:/var/www/html
の「:」記号の右側の
/var/www/html
がコンテナ側でのパスであり、
コンテナ側での
/var/www/html
パスの配下について、
ホスト側の
/jit_myDocker/laravel_next_docker
の配下にあるものと同じものが見えるようにします。
そのようにコンテナ側からホスト側をマウントします。
という設定のことです。
/jit_myDocker/laravel_next_docker/backend
の下に、laravelapp
のフォルダがありますが
コンテナにログイン後に、
/var/www/html
の下に、laravelapp
のフォルダがある。ような状況を作っています。
この設定をバインドマウントというらしいです。

ソースコードや、データベースのデータなど永続化したいものは、ホスト側に保存し、
コンテナはマウントしてそれを見に行く状況にしてるようです。

ですので、コンテナや、イメージを作り直しても、ソースコードや、データベースのデータなどは
何の影響も受けず、そのまま残っているのです。

そして、このマウントにおいて、
Ubuntu(WSL2)での開発環境では、非常に高速で安定しているわけです。
なぜかというと、Dockerはそもそも、Linuxカーネルの上でしか動かないものなのですが、
WSL2の共通のLinuxカーネルの上に、DockerとUbuntuのディストロがあります。
ホスト側のUbuntuのディストロの領域と、コンテナ側の領域は、
同じ共通のLinuxカーネルにあります。
その状況で、コンテナ側が、ホスト側の領域を見に行ってるだけです。
( 同一カーネル上ですから、普通に同じPC内で別のアプリが見に来ました。みたいなイメージです )
Dockerのイメージは、DockerHubで登録されているもので、なにかの
ディストロ(Ubuntu, Debian, CentOS, Alpineなど)に基づいて作られています。
Ubuntu(WSL2)の環境では、ホスト側はUbuntuで、コンテナ側も何かのDebianなどのディストロで
WSL2の共通のLinuxカーネルで動作します。
ファイルシステムについても、ホスト側、コンテナ側がともに、
Linuxで標準のext4になります。

補足:
DockerはホストマシンにLinuxカーネルがあることを前提にして、
なにかのディストロに各種のapacheなど、
そのイメージを特徴づけるもの付加した形のイメージが、DockerHubで公開されています。
ディストロ自体には、ファイルシステムはなく、
ホストマシンのLinuxカーネルにファイルシステムがあります。
そのホストマシンのLinuxカーネルにファイルシステムがext4の場合(そのケースが多いが)
結果的に、ホスト側も、コンテナ側もext4になります。
★★★★
Dockerのイメージの段階では、overlayfsや、unionfsなどの抽象化されたような
フォルダや、ファイルの階層構造でしか情報を保持しておらず
具体的なファイルシステムがあるわけではないです。
それを、docker compose build --no-cache
でビルドされたイメージに基づき
docker compose up -d
でコンテナを初回起動時に、コンテナが作成され、そのときに、
ホストマシン側のLinuxカーネルで採用しているext4などの
ファイルシステムへの書き込みがなされるような仕組みになってます。
ですから、ホストマシン側のLinuxカーネルで採用しているext4などの
ファイルシステムにコンテナ側も従うようになっているのです。
★★★★
ls -lで表示される「ファイルや、フォルダ」の所有者や、パーミンションなどの
権限情報は、この共通のLinuxカーネルのext4での保持であります。
Ubuntu(WSL2)でDockerを使ってるケースでは、
ファイルや、フォルダの所有者や、所有グループや、パーミンションなどの権限情報は、
ホスト側と、コンテナ側とでは、同期がとられて常に同じ権限情報になります。
（　同じext4ファイルシステムにあるそれらの情報を参照しているわけですから )
バインドマウントの対象になってるホスト側の領域は実態が1つで、それをコンテナが参照している
ですから、コンテナ側に入ったときにrootユーザでファイルや、フォルダを作れば、
ホスト側でそれを見た時に、そのファイルや、フォルダの所有者もrootユーザで見えるわけです。
しかし、他環境では、その前提なく、単に楽できる設定をチーム内で連携のため、
Ubuntu(WSL2)側では、権限問題の被害をうけます。
それを「POSIX ACL」でカーネルレベルで、gitを操作する一般ユーザに
gitのローカルリポジトリからの配下については、末端まで、
問答無用でフルでなんでもできる権限を付与をしてしまう裏技があるわけです。
その方法で、git操作をしたときの権限エラーが起きないようにしてるわけです。
私は、この20年ぐらい前からLinuxに備わった枯れた技術である
「POSIX ACL」の裏技で上記の権限問題を解消してます。
余談の余談みたいな話ですが。Ubuntu(WSL2)の利用者にとっては、かなり重要なネタです。
この件に、ご興味があれば、
https://zenn.dev/tazzae999jp/articles/1a044f201c735d
の
上記で最後で記載した★権限問題★とは何か
の項目で、権限問題の詳細を書いてます
また、
POSIX ACL
の項目で、実際に「POSIX ACL」での設定の仕方が書いてます
ので、ご参照ください

同じカーネル上で動作しているファイルシステムも同じプロセスが、見に来てるだけです
Ubuntu(WSL2)におけるDocker環境のバインドマウントは、この直接的な参照となり、
非常に高速なのです。間に、余計な変換処理や、余計なネットワーク結合など一切ありません。
ですから、複数環境でDockerコンテナが多数あって、並列に動くような環境を
沢山、好き放題やっても、全体の負荷にあまり影響せず、好き放題並列化して
開発作業を効率化しやすいわけです。
Webの開発は、Linuxをターゲットにしたアプリ開発であることが多いわけですから
Linux環境でローカル環境を構築するのが、断然いいわけです。
しかし、ネイティブLinuxのPCだと作業効率の問題もあるため
Windowsでの便利機能をいかしたうえで、Linux環境が使える
Ubuntu(WSL2)がもっとも、本来的な環境であろうと、私は思っております。
https://zenn.dev/tazzae999jp/articles/07bed12c3ae6c0
こちらの記事では、その本来的な、Ubuntu(WSL2)についての環境構築のノウハウが満載なので、よろしく！！

話を元に戻して、

しかし、これがMac端末だと、
MacはLinuxではありませんので、直接的にDockerを動かすことはできません。
そのため、VMを作りそこでLinuxカーネルを動作させて、その上でDockerを動かしてます。
本体のホスト側(BSDのUnix)と、コンテナ側(別でVMで用意してるLinux)では、
別のカーネルになっていて、
ファイルシステムもホスト側はaplfsで、コンテナ側では、ext4と異なります。
それをosxfs, fuse, virtioFSなどの共有ファイルの仕組みでくっつけている諸事情により
このバインドマウントが、Ubuntu(WSL2)環境に比べて、低速です。

共有ファイルのような仕組みでのネットワークでの結合のようなものですので、
それって、あんまり沢山、同時にやりまくると、全体の負荷に影響あるのか？
などが懸念されるわけですよね。
その影響で、当記事で話題に上がってる複数環境でどこまでの個数を並列化しても安定稼働するかの
さじ加減が異なるかもしれないですよ。
ということを注意事項として、書いたのが
目次項目「Mac環境の人への注意事項」の記述内容であります

私、このコミュニティ内でDockerでのトラブルがおきてる人を2、3人見ましたが
いずれも、Macユーザでした。

• 環境自体が壊れて、一回綺麗にしたら、解決したがまた、再発して何日も解決に時間がかかってる
• コンテナを起動したときに、バインドマウントしているはずのホスト側のソースコードが見えてないが
  コンテナを停止して、起動しなおしてやってみたら、治った。
  みたいな不安定な諸事情で、再度やってみたら、うまくいった。
  また、おかしくなった。
  系統のいわゆる、負荷がかかっていたら変になる系統
  いわゆる、不安定。

だから、そもそも、MacでDockerを使うというのは、
Ubuntu(WSL2)や、ネイティブLinux環境でのDockerの利用に比べ、不安定なのではないでしょうか

目次項目「Mac環境の人への注意事項」の記述内容で、
複数環境での並列化の個数についてのさじ加減について、個数が少なめになるかもね
と書いたのは、この不安定さに配慮しての記述であります。

それから、
ホスト側がWindows端末でGit Bashなどで開発作業をしている人で、
ホスト側のこのバインドマウントに指定されたフォルダが
NTFSファイルシステムの領域にある状況でしてる場合は、
要するに、コンテナ側のapacheの起動プロセスがそこにあるphpのソースコードを読み込んで
実行するのだけど、そのソースコードを読み込む際に、
NTFSと、ext4との間での変換処理のようなものがあり、それが、
糞遅いため、アプリの動作が遅くなってしまうよ問題があるんですね。
ただし、このGit Bashで開発している変換が糞遅い　という問題に関しましては、
Dockerの環境が不安定であるということとは、また別物だと思いまして
Mac環境とは、趣旨が異なると思っています。
そこのバインドマウントの早さで言えば、MacのvirtioFSでのマウントのほうが早いとは思うのですが、

Git Bashでのその現象は、一応は、安定動作はしてますが、「単に、糞おそい」
そういう現象のように私個人はとらえています。
ですので、糞遅い　ということさえ、我慢すれば、
意外と、Git Bashでの環境の人のほうが、複数個並列の個数としては、多めにやっても
安定動作するのではないかと私は、予想しております
ですので、Git Bash環境に関しての注意事項の目次項目は特に、記載しなかったのです。

なぜ、そう思うのか、根拠らしきものはあります。
Git Bashの環境で開発しているWindowsユーザもDocker DesktopのWindows版を動作させるために、
Windows PC上でWSL2の基礎部分を有効にする必要があるんです。
そもそも、Dockerは、Linuxカーネルでしか動かないため、その必要があるんです。

私のようにWSL2にUbuntuのディストロをインストールして環境作って、などそのようなことはしてないでしょうけど
DockerがWSL2の基礎部分を利用して、NTFSのファイルシステムへアクセスする機能を保持してます。
私は、Ubuntu(WSL2)環境でUbuntuのディストロの領域にあるものをWindowsアプリからアクセスしたり
または、逆にUbuntuのディストロからWindowsのNTFSの領域にアクセスするようなこともあります

WSL2でのLinuxではマイクロソフトがそのように、WindowsのNTFSとのやり取りの仕組みを持っているのです
これは、低速であるものの、安定はしてます。

共有ファイルのようなものとも、また、異なるものと思ってます。

おそらく、その仕組みのようなもので、Windows版のDockerはNTFS領域のものを安定的にバインドマウントできてるんじゃないかと思うです
遅いんですが、安定はしているでしょう。

一方、Docker for Macが採用してる、virtioFSの共有ファイルは、RedHadなどが開発元だったりします。
つかえるものを単に利用してるだけです。
これが、もし、Appleが音頭をとって、本体のaplfsのファイルシステムと結合するための
安定的な仕組みを作って、それをDocker for Mac側と、調整して
共同開発するなどの事を積極的にやって解決してるというならば、
安定性はあるんじゃないでしょうか。
そのようなことをせず、Docker for Macは、RedHadなどが開発元になってる
ぜんぜん、違う、virtioFSが使えそう
みたいな感じで採用した。そんな感じです
ですから、安定性を欠いてしまうんじゃないか。と懸念されます
ちょくちょくネットで、Mac環境でのDockerでの不安定な情報や、トラブルシューティングに
関する記事情報などは、チラホラ見ますが、このような経緯かと思います。

補足:
私個人は、Macが好きな人が、Macを使えばよいと思ってます。
身の回りのものをAppleの製品だらけにして、電話機もiphone、PCもMac
腕にはApple watch、寝転がってipadでkindleの書籍を見てるなど
Apple好きでMacが好きだという人が開発端末をMacにすればよいと思ってます
これは、私の考え方です。
本当は、Windowsが使いたいのだけど、Webの開発するときに環境作ったりするのが
Macのほうが簡単だと言われたから、別に、こんな高い端末買いたくないけど
しゃーないからMac使ってるみたいな後ろ向きな理由の人は減らしたいと思ってます
そういう人には、Webの開発するのであれば、Linuxについて詳しくなるのは
どうせ必要ですよね。
Linuxについて、詳しくなるのに、2、3ヶ月、プログラミングの学習が先送りになってしまいますが
長いエンジニア人生の事を思えば、大した話ではなかろう
最終的に、使いたいWindowsで、Linuxも使える。Ubuntu(WSL2)のほうがよくないですか
という情報伝達をすれば、Ubuntu(WSL2)の人は増えると思ってます。
それでも、本人が、そうは考えないとか
Macが好きなんだというのであれば、それは、自由にすればよいと思うです
そういう情報の伝え方をするのが、フェアじゃないですか
と、私は思ってます。
それから「それでも、本人が、そうは考えないとか」の理由が、
環境作るのが楽だからみたいな後ろ向きな理由な連鎖でのユーザ数を気にしてるが、ゆえならば、
その理由も本質的なものとは感じられない
どちらの端末で開発作業するのが、自分にとって、好きなのか、どちらの端末で作業したいのか
Macが好きなのか、Windowsが好きなのか、その純粋な好き嫌いで、選べるような状況が
本来だと思ってます。

補足:
それから、私は、Appleに対しても、モノ申したいと思ってます。
Macユーザも、Microsoftが開発したVSコードや、Office製品を使ってるじゃないか
相互乗換して、使えるようにMicrosoftはしてるはず、
なぜ、Appleはスマホの開発でiphoneの動作環境のシュミレーターみたいなところで、
端末購入しているかのライセンスでのブロックをするんだよ。
やり方が汚い。こういうところが、私は好きになれない
マシンクラウドを使う方法もあると聞いてるので、
なにかのクロスプラットフォーム開発時(Flutterとか、react nativeなど)
に、iphoneの動作テストをマシンクラウドでなんとかできないかも。
いつか、記事にしたいと思ってます。
これ、完全に、好き嫌いでの端末選びを阻害する要因ですよね。
Appleは、やり方が汚い。
ここは、私個人としては、本来の本当の好き嫌いでの選定が人々がして、
そこ結果としてUbuntu(WSL2)のユーザが増えるような活動を個人としてはやっていきたい
私、ガラケーやめて、一番最初にスマホを持とうとした時に
iphoneとAndroidについて情報収集してどちらにしようか、考えた時期がありました。
しかし、Appleがこういう汚い事をして、囲い込みみたいなところで、不当に高いものを買わせようと
するような流れだと判断したため、iphoneを買うと、その後、そこの流れにのって、
端末やガジェットについて、自由に好きなものを買うのを阻害される系だな
と、悟りましたので、iphoneを敬遠した経緯があります。それがMacに起きてると思います
そこらへんが、個人的には、全く、好きになれません。

補足:
それから、Microsoftにも、頑張ってほしいことがある。
自社の「Hyper-V」を使って、WSL2の環境を構築し、
Windows側との連携をとって、Windowsの機能を生かしてのLinux環境を作ったのは素晴らしい
でも、そこで甘んじるのではなく
WSL2で、インストール可能な、ディストロの開発にもっと力を入れたらどうかと思う。
Ubuntuとか、Debianとか普通のディストロではなく、
Microsoftがオリジナルのディストロを作ればよろしいのではないか。

というのも、Linuxはサーバーで動作することを想定したもののため
ローカルの開発環境を便利にするという思想は、元々はない
( Ubuntuは比較的に個人作業向けのディストロのようだが )
それゆえ、各自が環境設定を頑張ることになる。

しかし、Macが開発環境の構築が楽みたいに言われているのであれば
それに対抗する形で、
基礎的な開発環境がはじめから、いい感じになってるような
Microsoftがオリジナルのディストロをはじめから、WSL2のLinuxカーネルで
動作できるようにすれば、開発環境の構築が楽みたいな理由での端末選びを
Windows側にもってこれて、結果として、WSL2のユーザを増やせるのではないか

「開発環境の構築が楽」でしかも、Linuxである。
という素晴らしい環境になるよね。
そこに、Azure環境との相互連携が、めっちゃやりやすい
みたいな拡張機能を
その、Microsoftがオリジナルのディストロに付加すればビジネスにもなるのではないか。
実際、Microsoftは、「.net」を拡張して「.net core」を出してきて、
Linux環境でも動く技術を出してきてるのだから
この話で、WSL2や、Azureのユーザが増えるならば、
Linuxでも動く「.net core」にとってもいい話なはずだと思うです。

それから、
Macユーザも、Microsoftが開発したVSコードや、Office製品を使ってるじゃないか
相互乗換して、使えるようにMicrosoftはしてるはず
なのだから、Apple側にも、聖域なき、相互乗換をもっと要求して
プレッシャーをかけるなど。そこらへんを頑張ってほしい。
というのが、私個人の考え

（　めっちゃ長い、補足の前にある本文を思い出して(再度、参照して)下記を読んでもらえば・・・)

そのあたりで、速度が云々とは、また別での概念で、不安定さのようなものがあるように思えます。
適当な理解で、申し訳ないですし、100%の確信はありませんが、なんとなくの根拠らしきものは、想像しております。
それが、予想の理由です。
早い／遅いと安定／不安定は、別個の概念となるケースはあります。

はい、これで、説明するのが、メンドイ余談が、ひととおり終わりました。
★★★★★★★★★★★★★★★★★★★★★★★★

「 バインドマウントに関する「余談」 」がようやく終わりました。長い余談でした・・

さて、

話を元に戻しますが、

ここでdockerを使う時の制約として、
コンテナ名と、ホスト側のポート　について、重複したものがあってはならないということです。

dockerでは、まず、コンテナの元になるイメージをビルドして作り、
その後、そのイメージを元に、コンテナを起動する

という２段階で動いてるようです

つまり、
docker compose build --no-cache
で、イメージをビルドする。
それに成功したら、
docker compose up -d
でコンテナを起動しますが、初回だけビルド済のイメージよりコンテナを作成してから起動になります。
2回目以降は、コンテナの起動だけになります。
(
なお、
docker compose stop がコンテナの停止
docker compose down がイメージの削除 ( コンテナ自体も当然、削除されます )
)
ここで、余談ですが
docker-compose なにがし
と、間に「-」記号を使う方式は非推奨になってるとのことで、
docker compose なにがし
のように、間に半角スペースを指定する方式が現在は推奨されているとのこと
いつまで、間に「-」記号を使う方式が実行できるか、不明なので
今のうちに、間に半角スペースを指定する方式で慣れとくのがよいのではないかと
思っております。

話を元に戻しますが、

それで、経験上、イメージを作る段階で、コンテナ名や、ホスト側のポートで重複したものが
既にあれば、怒られて、イメージを作ることができないです。

ですので、
例えばの話ですが
フォルダなどの置き場所を変更するため、新しい環境でイメージをビルドして、
コンテナを起動したりしたい場合で、
元の環境と、新しい環境で、コンテナ名や、ホスト側のポート番号で
同じものがあるケースにおいては、

まず、
元の環境で、
docker compose stop
で、コンテナを停止する。
docker compose down
で、イメージを削除する。
までやっておかないと、

新しい環境でイメージを
docker compose build --no-cache
で、ビルドしようした段階で、怒られてしまいできなかったりします。

話を元に戻しますが、

当記事で話題になってるのは、複数環境を作りたいということです。
ここでは、docker-compose.ymlを利用したdocker環境で、
それを複数環境作りたいときの話をしています。

これを実現するには、コンテナ名と、ホスト側のポート番号を、
作る環境ごとに別名にしたり、改番して、ずらしていく必要があります。

なお、コンテナ側のポート番号、つまり、
「ports:」の

- "8080:80"
- "3000:3000"
- 13306:3306
- 8088:8080

などにおける右側の80、3000、3306、8080
については、環境ごとに改番する必要はありません。
複数環境で重複してても問題ありません。

それは、なぜかというと、
dockerは、そもそも、Linuxカーネルの上でしか動作しないものなのですが
Linuxに以前よりあるnamespaceという仕組みで環境ごとに完全に別個に独立した
環境を作れる仕組みを利用しているからです。

dockerの中に複数のコンテナにまたがって、重複して3306のポート番号で待ち受けてる
サービスがあっても、それらは、全部、別物として、隔離されて管理しており
ホスト側のポートが異なっておれば、対応する、どのコンテナの3306に対して、
通信をフォワードするかの対応を別個にきちんと管理してくれるからです。

結果として、コンテナ名と、ホスト側のポート番号　が複数環境で重複が
発生しないようにすればよいのです。
( コンテナ側のポート番号は、変更なしで複数環境での重複はOK )

先ほど、個人的にかかわったコミュニティ内での開発環境で
私個人は、Ubuntu(WSL2)環境で、
/jit_myDocker
のフォルダでgit cloneをしてました。

その際、
git cloneで、フォルダ名を指定せず、

git clone https://github.com/hogehogehoge/laravel_next_docker.git

※urlの「hogehogehoge」の部分は架空の値に変更した上で例を示してます

～.git のリポジトリ名そのままで、
laravel_next_dockerのフォルダが作成され、
その直下に、「.git」や、dokcer-compose.yml
などをリモートから落としてきた環境。

複数環境作るため

git clone https://github.com/hogehogehoge/laravel_next_docker.git wk_laravel_next_docker

※urlの「hogehogehoge」の部分は架空の値に変更した上で例を示してます

のように、「wk_laravel_next_docker」のフォルダ名を指定し、
wk_laravel_next_dockerのフォルダが作成され、
その直下に、「.git」や、dokcer-compose.yml
などをリモートから落としてきた環境。

などがあり、

結果的に、
/jit_myDocker
├── laravel_next_docker
├── w2_laravel_next_docker
├── w3_laravel_next_docker
├── w4_laravel_next_docker
├── w5_laravel_next_docker
└── wk_laravel_next_docker

このような状況になってます。
なお、「/jit_myDocker」は私個人のローカルで、ここに環境を作ろうと決めた
フォルダ位置で、これは、各自のローカル環境によって様々、かと思います。

余談ですが、
ホスト側の作業ユーザのhomeディレクトリの配下は個人的にはあまりおススメしない
/ の直下などで、フォルダを作った後に、作業ユーザの所有に変えてしまって
そこに、配置したほうが、環境トラブルになりずらいです。
/ の直下に、フォルダ作ったり、そのフォルダの所有者を変更するのは、
root権限がないとできませんので、sudoを使って作業します。

cd /
sudo mkdir jit_myDocker
sudo chown -R user1:group1 jit_myDocker
※user1:group1の箇所は、作業ユーザのユーザ名:グループ名で。

話を元に戻しますが、

laravel_next_dockerについては、元のdocker-compose.ymlそのまま、
使った環境にしてます。
他の、
w2_laravel_next_docker
w3_laravel_next_docker
w4_laravel_next_docker
w5_laravel_next_docker
wk_laravel_next_docker
は、元のdocker-compose.ymlに対して、
ローカルだけで(gitにはコミット、プッシュせず、個人のローカル環境だけの変更保存だけで)、コンテナ名と、ホスト側のポート番号を
別名にしたり、改番して、ずらしていって、全て、重複しないようにして構築してあります。

ここで、余談ですが、
jit_myDockerや、w2_laravel_next_docker
のフォルダ名のつけ方として、他との違いを表す、
「jit_」や、「w2_」などの文字列について、名称の先頭位置、左側に持ってくるように
してます。他との違いは、左側にしてます。
それは、なぜかというと、ターミナルで作業時に
lsや、cd コマンドを使う際に、途中まで打ち込んで、TABキーでの自動補完を効かすためには、
より先頭位置の文字列で他との違いを表す文字列が入ってる方が都合がよいからです。
( たとえば、w2まで打ち込んでTABキーを押せば、w2_laravel_next_dockerだけ一択に決まるため
w2_laravel_next_dockerがすぐに補完されます。 )
ですので、そういうフォルダ名のつけ方にして、作業効率をあげています。

話を元に戻しますが、

ここでは、具体的に、

/jit_myDocker/laravel_next_docker/docker-compose.yml
と、
/jit_myDocker/wk_laravel_next_docker/docker-compose.yml
を、Winmergeで比較した時の画面キャプチャーの画像を見てもらったほうが早いと思います。

なお、私個人は、Ubuntu(WSL2)の環境で、Ubuntu-24.04-my　という名称の
ディストロでの環境で

/jit_myDocker/laravel_next_docker/docker-compose.yml
と、
/jit_myDocker/wk_laravel_next_docker/docker-compose.yml

があります。
それを、WinmergeなどのWindowsアプリでアクセスするためのパスは、

\\wsl.localhost\Ubuntu-24.04-my\jit_myDocker\laravel_next_docker\docker-compose.yml
と
\\wsl.localhost\Ubuntu-24.04-my\jit_myDocker\wk_laravel_next_docker\docker-compose.yml

であり、それでの比較のキャプチャー画像になってます

上記の画像は全体はとらえやすいと思うですが
ちょっと、該当の差分の箇所が小さくて見えずらいと思いましたので
拡大した画像を２つ、下記に追加しました。

app:では、
コンテナ名の「laravel_app」を「wk_laravel_app」にリネーム
ホスト側のポート番号の「8080」を「5080」に改番
front:では
コンテナ名の「next_app」を「wk_next_app」にリネーム
ホスト側のポート番号の「3000」を「3100」に改番
db:では
コンテナ名の「laravel_db」を「wk_laravel_db」にリネーム
ホスト側のポート番号の「13306」を「14306」に改番
adminer:では
コンテナ名の「adminer」を「wk_adminer」にリネーム
ホスト側のポート番号の「8088」を「5088」に改番

という具合に、コンテナ名と、ホスト側のポート番号が
複数環境で重複しないように、ずらしてます。

それから、Laravelでのアプリの開発環境であったため、
.envファイルを上記のずらした結果に応じて、調整する必要がありました。

APP_URL=http://localhost:8080
を
APP_URL=http://localhost:5080
に調整してます。
また、
DB_HOST=laravel_db
を
DB_HOST=wk_laravel_db
に調整してます。
この調整をしないとアプリが動作しません。

実は、このコミュニティーの開発環境では、
複数環境を構築時に、あと、もう１つずらしているものがありました。
それは、Xdebugのホスト側での待ち受けポート番号です。
Xdebugのホスト側での待ち受けポート番号は、php.iniに記述されています。
php.ini

[Date]
date.timezone = "Asia/Tokyo"
[mbstring]
default_charset = "UTF-8"
mbstring.language = "Japanese"

xdebug.mode=debug
xdebug.start_with_request=yes
xdebug.client_host="host.docker.internal"
xdebug.client_port=9003
xdebug.log=/tmp/xdebug.log

上記の
xdebug.client_port=9003
の9003がXdebugのホスト側の待ち受けポート番号です。
まず、Xdebugはphpでの拡張機能で開発時にデバッガーが使えるようにするものです。
peclという仕組みを使ってインストールするのが簡単です。
ちなみに、docker-compose.ymlでの

 app:
   container_name: laravel_app
   ports:
     - "8080:80"
   build: ./Docker/App
   volumes:
     - ./backend:/var/www/html

における
/jit_myDocker/laravel_next_docker/docker-compose.yml
からの相対パス
./Docker/App
つまり、絶対パスでは、
/jit_myDocker/laravel_next_docker/Docker/App
ここに、000-default.conf、Dockerfile、php.iniがあります。

/jit_myDocker/laravel_next_docker/Docker/App
├── 000-default.conf
├── Dockerfile
└── php.ini

このDockerfileがdocker-compose.ymlでの「app:」での
イメージを作るためのもので、中身は下記のようになってます
Dockerfile

FROM php:8.3-apache

ADD php.ini /usr/local/etc/php/
ADD 000-default.conf /etc/apache2/sites-enabled/

RUN cd /usr/bin && curl -s http://getcomposer.org/installer | php && ln -s /usr/bin/composer.phar /usr/bin/composer

RUN apt-get update \
&& apt-get install -y \
git \
zip \
unzip \
vim \
libpng-dev \
libpq-dev \
&& docker-php-ext-install pdo_mysql

RUN pecl install xdebug && \
docker-php-ext-enable xdebug

RUN mv /etc/apache2/mods-available/rewrite.load /etc/apache2/mods-enabled
RUN /bin/sh -c a2enmod rewrite

FROM php:8.3-apache
がDockerHubにある「php:8.3-apache」というイメージをベースにしてますよ
って意味だと思うです。
これは、phpのversion8.3をベースにした環境で、apacheで動作させる
Webアプリを開発し動作させるのに、都合がよいイメージってことではないか
って、思ってます。( めっちゃ適当な理解ですが、大枠、間違ってないと思います )

ADD php.ini /usr/local/etc/php/
の部分ですが、Dockerfileと同じ階層においてるphp.iniを
最終的に、作られるコンテナの
/usr/local/etc/php/
の場所に、コピーしますよ
つまり、コンテナに入ったら、
/usr/local/etc/php/php.ini
がある状況にしますよ
ってことです。

/jit_myDocker/laravel_next_docker/backend/laravelapp$ docker exec -it laravel_app bash
root@21eafaa59f26:/var/www/html# php --ini
Configuration File (php.ini) Path: /usr/local/etc/php
Loaded Configuration File:         /usr/local/etc/php/php.ini
Scan for additional .ini files in: /usr/local/etc/php/conf.d
Additional .ini files parsed:      /usr/local/etc/php/conf.d/docker-php-ext-pdo_mysql.ini,
/usr/local/etc/php/conf.d/docker-php-ext-sodium.ini,
/usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini

root@21eafaa59f26:/var/www/html#

docker exec -it laravel_app bash
でコンテナの中に入って
php --ini
で確認すると、
Loaded Configuration File: /usr/local/etc/php/php.ini
と表示されます。

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
とっても大事な話をします
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
複数環境構築時は、
docker exec -it laravel_app bash
で、コンテナにログイン時に、指定する「laravel_app」に該当する部分は、
★★　その環境にあったものにしなきゃだめよ　★★
ってことです。
つまり、

app:では、
コンテナ名の「laravel_app」を「wk_laravel_app」にリネーム
ホスト側のポート番号の「8080」を「5080」に改番
みたいにしたわけですよね。

今、wk_laravel_app　のコンテナ名での環境で作業中では、

docker exec -it wk_laravel_app bash

と、今、作業している環境でのapp:でのコンテナ名を指定しなきゃだめよ
ってことです。

これ本当に、間違えやすくて、気をつけなきゃならないんです
間違えてても、怒られないんです。（エラーになってくれればいいんですが）
怒られないんです。だから、複数環境で今、自分が作業中ではない
別の環境のコンテナに間違えてログインして作業してましたーー！！！　残念！！！
みたいなことがおきるんですよ。

じゃ、なんで怒ってくれないのかって話です。

docker compose なにがし
のコマンドは、そのコマンドを打ち込んだカレントディレクトリおよび、
その親ディレクトリをさかのぼって行って、docker-compose.ymlが
見つからなければ、エラーになるし
見つかったら、そのdocker-compose.ymlの記述内容に従った動作をしようとしますので、
別の環境のものをやってましたー！！　ってことにはならないんです

しかし、
docker exec -it wk_laravel_app bash
は、普通のdockerコマンドなんです
このコマンドは、それを打ち込んだカレントディレクトリがどこであろうが、
システムの中に、wk_laravel_appがあってそれが起動しておれば、
wk_laravel_appにログインできるわけです。
別環境のコンテナ名を間違えて指定してても、それが起動中であれば、怒られないんですよね

怒ってくれないので、間違える可能性があります！！

★★　ですから、本当に気を付けて下さいね　★★
docker compose ps
で、起動中のコンテナ名を表示できます。
これは、所属しているdokcer-compose.ymlに従って表示されますので
今の環境でのものが表示されることは、保証されます
ですので、
docker compose ps
で、起動中のコンテナ名を表示して、
そこで、コンテナ名を確認したうえで、
そいつを、ちゃんと指定することでの
docker exec -it wk_laravel_app bash
を実行するなどを、
癖づけるなどの工夫を各自考えてやってくださいね
こういう、これは、気を付けて下さいね。って系統の事柄は、
間違えると、本当にメンドイ話になりますから、ちゃんと理解してやるのがおススメです
★★　意味わからなかったわー、見てなかったわー、知らんかったわー　★★
みたいに、後で言われても知らんです。ちゃんと、ここは気を付けて下さいねぇ
違う環境のコンテナで間違えて、環境を変えるようなコマンドをやっちゃいましたー
それにしばらく気が付きませんでしたー
なんてことがおきたら、そのリカバリーのため、そのミスがどの時点でおきたか
どこから、リカバリーすべきか、などを考えて、リカバリー作業が発生するなどしたら
糞メンドイことになるって想像できますよね！！！
これは、まさに、「注意1秒、ケガ一生」などと同じであり
再三再四にわたって、
★★　docker compose psで確認してから、
★★　そのコテンテナ名を指定する形でのコンテナへのログインをしろよ
というのは、
★★ 己自信に肝に銘じて、絶対に間違えないように作業するように心がけて下さい ★★

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

大事な話は、一旦、おわって　（　本当に、説明するのが、メンドイ話ですわ )

話を元に戻すと

コンテナ側の
/usr/local/etc/php/php.ini
の件ですが、
複数環境で、複数のコンテナが同じ
/usr/local/etc/php/php.ini
のパスであったとしても、
dockerの仕組みでLinuxのnamaspaceの機能で別個に管理されているから
問題なしなんですね。

それから、
Dockerfile自体には、コンテナ名や、ホスト側のポート番号の記述は、ありませんので、
複数環境で、全く、同じものを使うことができます。
git cloneで落としてきたDockerfileそのままで、変更なしでよいということです
あくまで、今回示したDockerfileでは、そうでしたと言うだけの話ですよ
なにかの環境設定の事情で、Dockerfileにコンテナ名や、ホスト側のポート番号の記述が
あれば、それも、リネームや、改番の対象になりますよ
dockerでの環境で、複数環境作りたいときは、
設定系のファイルの値を調べ上げて、
コンテナ名や、ホスト側のポート番号の記述があるかどうかを確認して、
あれば、それらは、リネームや、改番の対象になりますよ
ってことですよ。
たまたま、今回、示したDockerfileでは不要でした
という意味ですので、この事を誤解しないようにしてくださいね。

話を元に戻して、

しかし、php.iniの

xdebug.client_port=9003

については、ホスト側のXdebugの待ち受けポート番号ですので、
これは、複数環境をつくるときに、環境ごとにずらして、改番していく必要があるんですね

/jit_myDocker/laravel_next_docker/Docker/App/php.ini
と
/jit_myDocker/wk_laravel_next_docker/Docker/App/php.ini

の比較をだしますね。
WindowsアプリとしてのWinMergeがUbuntu(WSL2)のディストロ「Ubuntu-24.04-my」
での領域での上記のLinuxパスに相当するファイルに
アクセスできるパスとして、

\\wsl.localhost\Ubuntu-24.04-my\jit_myDocker\laravel_next_docker\Docker\App\php.ini
と
\\wsl.localhost\Ubuntu-24.04-my\jit_myDocker\wk_laravel_next_docker\Docker\App\php.ini

の比較になります。

xdebug.client_port=9003
を
xdebug.client_port=9006
に変更調整する形で、複数環境を作ってます。

Xdebugでは、リモートデバッグの形で動作してます。
webアプリの実行は、コンテナ側で、www-dataの実行ユーザで動作中のapacheのプロセスで、
phpやLaravelの実装が動作します。
VSコード自体は、ホスト側で動作させているアプリなので、
コンテナ側での上記の実行について、デバッガーでステップ実行をしたければ、
ステップ、バイ、ステップで、コンテナ側と通信をして、
VSコード内でデバッガーに、必要な動作中の情報を取得し、表示反映する必要があります。

上記のコンテナとホストの通信の基点は、コンテナ側になります。
なぜなら、ホスト側のVSコードでデバッガーを起動しても、それだけでは
デバッグ実行にならないからです。
デバッグ実行が始まるトリガーが、コンテナ側でアプリが動作した時になります
動作の基点が、コンテナ側であり、それをホスト側に通知する形で
リモートデバッグが機能するわけです。
そのとき、コンテナ側がホストに接続しにくい必要があるわけです。
そしたら、コンテナ側のXdebugのモジュールは、ホスト側に対して、どのポート番号で
接続しにいくべきかを知ってなければならないですよね。
それを、php.iniの
xdebug.client_port=9003
の記述で書くことになってるわけなんです。

コンテナ側からホストに接続しにいくときに、ホスト側のどの待ち受けポート番号で
につなぎに行けばよいかというポート番号が9003や、9006であり、
それを、php.iniに記述しているわけです。
まずは、一旦、ホスト側でDockerfileを置いてる場所に、php.iniを置いておくのですが、
それが、
docker compose build --no-cache
のときに、
/usr/local/etc/php/php.ini
にコピーされるわけですよね。

そして、VSコードでは、デバッガーを起動するときには、
php.iniに設定されている、その9003や、9006と同じポート番号と、
同じものを設定値として知ってる必要があります。
同じポート番号を待ち受ける（Listenする）形でのサーバーソケットを起動した形での
プロセス起動をする必要がありますね。

その設定をしているのが、
.vscode/launch.json
であります。
launch.jsonは、下記のとおりになっております。
launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Listen for Xdebug",
            "type": "php",
            "request": "launch",
            "hostname": "0.0.0.0",
            "port": 9003,
            "pathMappings": {
                "/var/www/html/laravelapp": "${workspaceFolder}"
            }
        }
    ]
}

ここでは、Xdebugの環境構築の基礎は、知ってる前提で話すすめますが

補足:
すいませんが、基礎がなければ、
https://zenn.dev/tazzae999jp/articles/07bed12c3ae6c0
のXdebugについて書かれたところに、
dockerでの開発環境でのXdebugの話が書いてますので、そちらを参照するなどしていただきたく思います。
しかし、そこも、そもそも、普通のローカルだけの開発環境でのXdebugの基礎知識がある前提で
書いてしまってますので、それも、わからなければ、そのレベルから
ググってもらって、基礎をさかのぼって、得てから、
また、当記事までもどっていただくなどのメンドイ事をしてもらう必要あります。
すいませんが、複数環境の構築の話と直接関係ない、話をここに書きまくることになってしまうのを避けたいため、ご理解いただきたく思います

複数環境構築時には、
.vscode/launch.json
での待ち受けポート番号をずらして、改番しての環境設定が要るわけです。

では、

/jit_myDocker/laravel_next_docker/backend/laravelapp/.vscode/launch.json
と
/jit_myDocker/wk_laravel_next_docker/backend/laravelapp/.vscode/launch.json

の比較をだしますね。
WindowsアプリとしてのWinMergeがUbuntu(WSL2)のディストロ「Ubuntu-24.04-my」
での領域での上記のLinuxパスに相当するファイルに
アクセスできるパスとして、

\\wsl.localhost\Ubuntu-24.04-my\jit_myDocker\laravel_next_docker\backend\laravelapp\.vscode\launch.json
と
\\wsl.localhost\Ubuntu-24.04-my\jit_myDocker\wk_laravel_next_docker\backend\laravelapp\.vscode\launch.json

の比較になります。

"port": 9003,
を
"port": 9006,
に、ずらして、複数環境を作るようにしてます。

そのココロは、どの環境でも、デバッガーが問題なく動作できるようにするためです！！

以上で、複数環境構築時に、ずらしていく設定値について、
ひとおおり見ていくというのが終わりました。

最初のほうに戻りますが、

/jit_myDocker
├── laravel_next_docker
├── w2_laravel_next_docker
├── w3_laravel_next_docker
├── w4_laravel_next_docker
├── w5_laravel_next_docker
└── wk_laravel_next_docker

という構成になってます
laravel_next_docker
は、gitの資産そのままの環境になってます

これまで、
laravel_next_docker
wk_laravel_next_docker
とのWinmergeの比較画像を示しながら、
コンテナ名とホスト側のポートでのリネームや、改番の要領を示しましたが

w2_laravel_next_docker
w3_laravel_next_docker
w4_laravel_next_docker
w5_laravel_next_docker
wk_laravel_next_docker
についても、やってることは、同じです
ただし、どのコンテナ名、どのホスト側のポート番号に
リネームや、改番をしているかが、環境ごとに異なるだけであり（重複なきようにずらした)
やってることは、同じです。

そして、私個人は、全部で６環境あるものに対して、どこに何を設定したかなど
記憶できませんので、Excelファイルに簡単な落書きをする形での
管理簿のようなものを作って管理をして
そこに、記録をしながら、複数環境の作成や、管理をしておりました。

本チャンで開発で使ってた管理簿ファイルは、開発時にこの環境では
このタスクで今、こうしてるなどのメモ書きが沢山ありまして。

コミュニティでの秘匿性がある情報を含んでしまっているので
ここでは、本チャンの管理簿をコピーして
それらの秘匿性の情報の記述を削除したファイルを
Excelで開いた時に、どうなってるかについての、画面キャプチャー画像を示すことにしました

まずは、全体像を示すため、細部が見えにくいことは承知の上で、
全体画像を示しました

実は、8環境作ってるんです( 全て、Xdebugが問題なく動作します )

JIT:8080
JIT:5080
JIT:1080
JIT:2080
JIT:3080
JIT:4080
KK:6080
OK:7080
の8環境です。

拡大図を2枚示します。設定値をずらして、ずらし具合の該当部分文字列を赤字にして
記録し、管理して言ってる様子です
横スコールさせての拡大図のため、2枚示します。

コミュニティでの開発での話で、部外者に詳細は知られたくないため、
隠語を使わせていたできますが、

紆余曲折ありまして、8環境ございます。
順を追って説明しますと、

最初、OK:8080という環境だけがありました。
その後、KKというフェーズになりまして、
KK:8080を作りたいのですが、OK:8080がある状況でそれをしようとすると
怒られてできませんので、
一旦、OK:8080を
docker compose stop
docker compose down
で、イメージまで削除して

KK:8080を作りました。
その後、OK:8080は、OK:7080として復活させて
KK:8080と、OK:7080を同時に起動できる環境を作り
OK:7080の資産を動かしながら、確認し、その資産を流用しながら、
KK:8080の開発作業をしておりました。

そのうちに、
KK:8080で、開発作業時に、KKを複数環境作った方がよいよねぇ
って、途中で思ったので
KK:6080をはじめ、複数個作りました。

その後、KKのフェーズが終わりまして、JITのフェーズに開発が移行しました。
そこで、kkの環境については、
KK:6080だけは、残して、他は
docker compose stop
docker compose down
で、イメージまで削除しました。

そして、
JIT:8080を作りました。
その後、
JIT:5080
JIT:1080
JIT:2080
JIT:3080
JIT:4080
と増やしました。

結果的に、
JIT:8080
JIT:5080
JIT:1080
JIT:2080
JIT:3080
JIT:4080
KK:6080
OK:7080
の8環境を複数並列で動作可能であり
全ての環境でXdebugでのデバッガーが使える状況になっております。

補足:
私はUbuntu(WSL2)の環境で、
git操作をする一般ユーザにに対して、ローカルのリポジトリルートからの配下について、
「POSIX ACL」でのフルに問答無用の権限を与える設定を、
上記の8環境全てで、設定してます。
★★★★★★★★★★★★★★★★
ここについて、詳しく書くと、
/jit_myDocker/laravel_next_docker
のレベルの、ローカルリポジトリでは、「POSIX ACL」の設定は不要でした。
「POSIX ACL」の設定をしたのは、
dockerコンテナにログイン時に、rootユーザでファイルや、フォルダを作成し、
ホスト側で、それらのファイルや、フォルダがrootユーザの所有に
なっているように見える ( Ubuntu(WSL2)の場合の話 )
ことがおきうる
(コンテナ側で「php artisan なにがし」でファイルや、フォルダを作るコマンドありますよね、
コンテナにrootユーザでログインしてるのだから、そこで作られたものはroot所有になります)
/jit_myDocker/laravel_next_docker/frontend/nextapp
と、
/jit_myDocker/laravel_next_docker/backend/laravelapp
について、このローカルリポジトリのルートより末端までの領域について、
git操作をするユーザに対して、「ls -l」で見れる所有者、所有グループや、
パーミッションがどうあれ、問答無用で、フルでなんでも可能な権限設定を
「POSIX ACL」を使ってすることで
git操作時の権限エラーが発生しないようにしていたということです。
Ubuntu(WSL2)でのこの話題に、ご興味があれば、
https://zenn.dev/tazzae999jp/articles/1a044f201c735d
の
上記で最後で記載した★権限問題★とは何か
の項目で、権限問題の詳細を書いてます
また、
POSIX ACL
の項目で、実際に「POSIX ACL」での設定の仕方が書いてます
ので、ご参照ください
★★★★★★★★★★★★★★★★
そういうことも含め、「環境1つ」作り直すのに、最低限、何をやればよいかを
書いた資料を（綺麗な資料である必要はない）おいておいて
それを見ながらなら、5分、10分で作れてしまうような状況にしとくのだと思います。
常に、いつでも、さっさと、もう1つ環境作れる状況にしておけば、
環境トラブルがおきたとき(gitなどもそうですけど)
捨てて、環境作ったほうが早いみたいになります。
メンドイ、トラブルは解決するより、捨てて逃げたほうが早いです。
捨てると決めた環境で、
docker compose stop
docker compose down
してから、根元のフォルダ名の先頭に「back_」などをつけてリネームし、
その捨て環境用のdocker-compose.ymlなどのずらした設定値があるファイルを
新たに作り直した環境にそのままもってくればよいです。
「back_」などをつけて捨てたものは、そこからいる分をもってくるように
数日はおいておけばよいですが、1週間も、2週間もたって、タスクもどんどん
他のものをやっていったら、そのうち、もういらなくなるわけですから
邪魔なので適当なところにフォルダごと移動してしまえばと思うです
( vendorとか、node_moduleとかのフォルダはでかいので、先に、ターミナルでrm -rf で
消したうえで移動です。それらのでかいものをWindowsの機能で削除や、移動すると、糞遅いです
Linuxコマンドでrm -rfしたらすぐ、消えます )
ゴミ箱候補みたいなフォルダにため込んで、どっかのタイミングで
そこから、更新日付の古いもの順に、本当に削除ですよね。
そんな感じでしてます
要するに、gitなどでトラブって、ぬけられなくなって、長時間ハマるより
さっさと、捨てて、環境作り直した方が早いわけです
（　初期段階でもう1つ環境作るのは、これだけやればよしの環境構築手順を落書きでいいから
資料作って、さっさとやれるノウハウ確立しとけばです )
無駄時間減らして、進捗進めて、プライベート時間を守りたいというのが、
私の考え方です。

目次項目「開発環境を「複数」個作ることのメリット」の中でも説明したとおり
3つ環境あれば、事足りることが多いです。

ただ、JITのフェーズで個人的に、Laravelのバージョンを6から11までバージョンアップさせて
開発中のアプリが動作できる状況にする。という特殊なタスクが実施した関係で、
6環境まで増やしました。

Lavel 6から7
Lavel 7から8
Lavel 8から9
Lavel 9から10
Lavel 10から11
の5タスクを続きものとして対応時に、
目次項目「開発環境を「複数」個作ることのメリット」の中でも説明した要領で、
Lavel 6から7 のプルリクのレビュー待ちの状況で、Lavel 7から8を別の環境で実施し、
動作確認まで終わって、次プルリクだしたいのに、
Lavel 6から7 のプルリクのレビューの指摘事項対応も1回終わってる状況から
レビューがすすまず、仕方なしで、次の次のタスクのLavel 8から9の調査に入っていた
しかし、次の次のタスクのため、環境調整が非常にやりにくく、
また、技術調査の面で、これって、本当に大丈夫かなど、複数の可能性の調査もしたかったので、
次の次のLavel 8から9の調査で、2つの環境を使ってどっちがいいかとか、比べたり
そういう事をいろいろ、やりくりしてくうちに、6環境まで増やすことになったという経緯があります。
この5タスクは、プルリクが通ったら、およそ40分後には、次プルリクを出してました。
当然ですよね。もう、次のものは、動作確認まで終わってて、
「featureを切って、ステージング追加、コミット、プッシュや、プルリクの本文を記述する」など
そういった。いわゆる、手続き的な事しか、残ってませんの状況でしたので、
前タスクのプルリクが承認されマージされた時点では、次タスクは、常に
動作確認完了状態で、手続き的なことしか残ってません。の状況で進んでましたので、
プルリク承認されたら、およそ40分後に次プルリクを出す
ようなやり方になってました。

話を元に戻して、

再度、

拡大図を2枚示します。設定値をずらして、ずらし具合の該当部分文字列を赤字にして
記録し、管理して言ってる様子です
横スコールさせての拡大図のため、2枚示します。

ここまで、真面目に（こんな説明するのも、読むのもメンドイ話を）
読んでくださって、内容をご理解いただいてる人であれば、

私個人が「何を」この管理簿に、記録しているのか、おわかりになると思います。

この管理簿は、縦スクロールし上に行くと、環境ごとに、
Linuxのパスが書かれており（苦肉の策で、斜めに、ずらして書いてますけど)
そこが、各環境での基点のパスになってます。
上部で、パスを斜めにして、書いてる箇所も
拡大図を2枚示します。（左右の横スクロールで2枚)

なんで、いちいち、こんな管理簿のファイルのキャプチャー画像を示してるのかというと
こういうある程度の正確性が求められる作業を、どうやってやったら、いいか想像がつかないような
人が、時々、いらっしゃるのです。
ですから、こんな感じでやってましたと。キャプチャー画像示しておけばイメージつくかと思いました。
そういう苦手要素みたいなのが、積み重なって、やらない、やれない
みたいにあきらめる系の人がいるかもしれないので、
イメージつけば、作業のハードル下がるかなとおもいましたので、キャプチャー画像はりました。

やってることは、単純なんです。やり方は、好きにしたらいいですが
こんな、めっちゃ適当な落書きで、簡単に管理できますので。
そのことだけ伝えるため、キャプチャー画像はりました。

コンテナ名や、ホスト側のポート番号をどのようなルールで、ずらしていくかは、
完全に個人の自由です
自分の開発PCの中で、重複がないように管理できておれば、それでよろしいのです。

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
面白い記事を発見したので、リンクしておくことにしました。
https://zenn.dev/tak_matz/articles/cf30ce2dd876f5
の記事のように、
docker-compose.ymlでの複数環境構築時の
可変部分を別のファイルにして切り出しておいて
その切り出したファイルだけ、複数環境で切り替えるようなやり方もあるようだ。
そしたら、チーム内で、この切り出した、このファイルのここを直してください
とか、もしくは、
環境1はこれ。
環境2はこれ。
環境3はこれ。
みたいに複数、管理者がつくっといて、
とりあず、git資産は環境1用のものを置いておくが
もし、複数環境作りたかったら、切り出したそのファイルを
環境2、環境3用などに置き換えたらいいよ。
みたいな情報連携もできるかもしれない。
( より簡単に各自、複数環境作れるだろう )
ですので、自分が、docker-compose.ymlで環境を作る立場になってる場合は、
複数環境構築が、各自しやすいように、このやり方でしてみるのもよいだろう。

ただ、今回は、既に、上記のようなことしていない環境設定値が
チーム内で連携されてる状況で
複数環境構築したい各自が、どのようにローカル環境で、設定をしてくか
という前提で、説明しました。
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

それから、注意事項ですが、
ホスト側のポート番号を改番した調整値を考える際には、いわゆる、
TCP/IPの世界でのウェルノウンポートと呼ばれている「0から1023」の範囲に
相当するものは、避けた方がよいです。
また32768から61000の範囲は、エフェメラルポートと呼ばれ、
他のプロセスでクライアントソケットを起動時に
割り当てるかもしれず、それと重複していると誤動作になるため、避けた方がよいです。
ですので、1024から32767までの間で、開発PCの中で、他に何かのサービスが
待ち受けポートとして(サーバーソケットでListenしてるポート番号として)利用していない
空き番での指定ということで、ホスト側のポート番号を調整する形がよいと思うです。

だいたいのやり方は、伝わったはずだと思うのですが（そう願います）

これ以上は、個人の管理能力や、作業の実践能力の範疇になってしまいます。
これ以上は、私はどうすることもできません。（そのギリギリ一杯までの必要な情報は記載したつもり）

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
補足事項：
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
このコミュニティでのJITフェーズでは、
/jit_myDocker/laravel_next_docker
の直下に「.git」が、まずある

/jit_myDocker/laravel_next_docker
├── .git
├── .gitignore
├── Docker
├── Readme.md
├── api
├── backend
├── docker-compose.yml
└── frontend

その配下に、

/jit_myDocker/laravel_next_docker/frontend/nextapp
├── .babelrc
├── .env
├── .git
├── .eslintrc.json
├── .gitignore
├── .next
├── .prettierrc.js
├── .yarnrc.yml
├── README.md
├── components
├── features
├── hooks
├── lib
├── next-env.d.ts
├── next.config.js
├── node_modules
├── package-lock.json
├── package.json
├── pages
├── postcss.config.js
├── public
├── styles
├── tailwind.config.js
├── tsconfig.json
└── yarn.lock

および、

/jit_myDocker/laravel_next_docker/backend/laravelapp
├── .git
├── .gitattributes
├── .styleci.yml
├── .editorconfig
├── .env
├── .env.example
├── .github
├── .gitignore
├── .phpstorm.meta.php
├── .phpunit.result.cache
├── .vscode
├── README.md
├── _ide_helper.php
├── _ide_helper_models.php
├── app
├── artisan
├── bootstrap
├── composer.json
├── composer.lock
├── composer.phar
├── config
├── database
├── lang
├── openapi.yaml
├── openapi.yaml_bak
├── package.json
├── phpcs.xml
├── phpstan.neon
├── phpunit.xml
├── public
├── rector.php
├── resources
├── routes
├── server.php
├── storage
├── tests
├── vendor
└── webpack.mix.js

があります。

/jit_myDocker/laravel_next_docker
が、まず、ローカルのgitのリポジトリのルートになっており
そこに、docker-compose.ymlでのdocker環境の定義がある。

配下に、２つ、

/jit_myDocker/laravel_next_docker/frontend/nextapp
と
/jit_myDocker/laravel_next_docker/backend/laravelapp
も、
ローカルのgitのリポジトリのルートになっている。

当記事では、

一番、上の
/jit_myDocker/laravel_next_docker
のところの、根元で、
他にも

/jit_myDocker/w2_laravel_next_docker
/jit_myDocker/w3_laravel_next_docker
/jit_myDocker/w4_laravel_next_docker
/jit_myDocker/w5_laravel_next_docker
/jit_myDocker/wk_laravel_next_docker

を作り、これらの環境でのdocker-compose.ymlなどで、コンテナ名や、ホストのポート番号をリネームや、改番して
複数環境を作ることを、説明してきました。

配下の、
/jit_myDocker/laravel_next_docker/frontend/nextapp
と
/jit_myDocker/laravel_next_docker/backend/laravelapp
のレベルのものは、

/jit_myDocker/w2_laravel_next_docker/frontend/nextapp
と
/jit_myDocker/w2_laravel_next_docker/backend/laravelapp

などのようになるだけです。

状況にもよりますが、このように、
ローカルのgitのリポジトリが、上下の階層で2段階になってるケースで、
根元のdockerの設定に、関わるところの、
コンテナ名や、ホストのポート番号をリネームや、改番して
複数環境を作ればよいということで、下の階層のローカルのgitのリポジトリについての説明は、割愛してきました

「docker compose」利用時の複数環境を作る話題の本質とは関係ない部分なので、説明を割愛していました。
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

他、複数環境での実例

詳細は、守秘義務などがあり、書けませんが
当記事の複数環境構築の説明のネタとして、使える範囲で
アバウトに記載します。
一般的な話題でどこにでもあるような、一般的な情報の組み合わせが示されただけの
情報の記述の仕方にとどめます
システムの仕様や、詳細までは書けません。

Pythonのdjangoフレームワークでのwebの開発
dockerは使ってない

ローカル開発時、DBはローカルのSQL Server。
本番環境は、azureで、azure環境のDBに接続

ローカル端末での開発時は、ローカルのSQL Serverのインスタンスに接続
なので、SQL Serverのインスタンスを複数個作成するノウハウを早めに確認した。

Laravelのシーダーに相当するものがあれば、DBを環境ごとにわけてもデータに困らない。
djangoには、マイグレーションはあるが、Laravelのシーダーに相当する機能が見当たらない
（　単に私が知らないだけ、単に、その現場にノウハウがなかっただけで、調べたらあるかも、そこは、わからない、知らない )
たまたま、開発中のアプリの仕様上、他システムから連携された情報をDBのデータとして
大量にインポートする機能があり、
そのデータより、業務を遂行していきながら、適宜、更新を加えていくような仕様のwebアプリだった。

ですので、データのインポートの機能や、テストデータもそろっていたわけです。

Laravelのシーダーに相当するものがなくても、
複数環境で、DBのインスタンスをわけても、別にデータに困るような状況ではなかった。

場合によっては、DBからダンプをして、そのまま、別のDBインスタンスに突っ込んで置き換えるような
手法を調べる必要はあるかもしません。
この現場ではそれは不要だった。
( 以前、IBMの「DB2」を使ってた時には、そのようなノウハウがありました )

現場によって、アプリの仕様によっては、DBはチーム内共通のサーバーで作業するケースも
あり、その場合は、複数環境構築しても、それらは、どの環境も同じ
チーム内共通のDBのサーバーを見るような構成ですべきだろう。

現場に参画したら、すぐに、環境構築の資料を見て、開発環境のセットアップ作業に
とりかかることになった。

その環境構築の資料を自分用にコピーして、そこに落書きや、メモ書きを加えながら作業をした。
目的は、
・環境の資料が間違ってるケースがあって、それを指摘して、資料を修正したいので、それらのやり取りする前に、事前にある程度、メモりたい
・複数環境作るために、どの部分を、複数回やるか。
基礎的な共通部分と、複数個環境作る時に、別個に、やり直す必要がある部分とを、コピーしたローカルの資料に印を打ち込んでいった

複数環境での、環境をもう1個作る必要性があったときに、
どの部分のどこをやり直したら、素早く、もう1個環境が作れるか
一目瞭然として、もう1個環境作る行為が、いつでも、さっさと、素早く行える状況を
初期の早い段階で確立させた。

• デバッガーが使えるノウハウは早めに確保しときたいです。
• 複数環境のノウハウは早めに確保しときたいです。

git cloneしている根本から、環境をわけて、3つの環境を作った。
SQL Serverのインスタンスも3つ作って、環境ごとに、別のものを見に行くようにした。

ローカルのwebサーバー起動時のポート番号は、全て8000番でこれは変更しなかった
デバッガーを起動すれば、ローカルのwebサーバーが8000番で起動し、デバッガーを終了すれば、その8000番のポートの待ち受けが無くなる。
( dockerの時は、imageを作る段階で重複があると怒られたが、この現場はdocker使っておらず、その必要がない )
本当に、複数環境で、ローカルのwebサーバーを同時に起動する必要性が無かったので、8000番のままずらさなかった。
( なにかの諸事情でその必要性があれば、ずらせばよい )

この現場でも、プルリクをだしたら、すぐ、次のタスクの開発をはじめるやり方をしていた。
つまり、これまで、当記事で、説明した通り、
別の環境で、プルリクした前タスクのfeatureをリモートから直で落としてきて
未ステージング領域に置きっぱなしで、次のタスクを開発をした。

開発環境は、現場によって様々、かと思いますが、
うまいこと工夫をすれば、複数環境作って、別環境で次タスクを先行でする思考法は
つかえるとは、思います。

要は工夫次第です。
そのことを伝えるために最後に、別の現場での事柄を書きました。

バックアップの話

PCが壊れたケースで、開発中の資産がぶっ飛んだら、かけた工数が無駄になってしまいますよね

趣味でならば、自分が悲しいだけですけど

オカネもらって仕事してて、それは避けたい

結局、gitはリモートにプッシュするまでは、ローカルにしか資産がない。

未ステージ領域で作業してたりしてる場合も、

仮に、ローカルでコミットしてても、

結局、gitはリモートにプッシュするまでは、ローカルにしか資産がない。

これまで、説明した要領で、別環境に、

未ステージング領域におきっぱなし

とかだと、PCが壊れたときのリスクもあるため

適度なタイミングで、現場のファイルサーバーにバックアップしてます

ただし、あんまり、沢山、それをすると、迷惑だと思うです

ファイルサーバーの容量も無限ではないため

ですので、

vendorとか、node_moduleなどは、避けたい

/jit_myDocker/laravel_next_docker/backend/laravelapp

が、カレントディクトリの状況で、ターミナルで、

explorer.exe .
( explまでうって、TABで補完すると、「explorer.exe 」で半角スペースまで補完されるので、
「.」を打ち込んで、エンターを打つと、カレントディクトリに基づいて
今のUbuntuのディストロにおける、Windowsが参照するようのパスでエクスプローラーが起動する)

で、エクスプローラーで開くと、

たとえば、

私個人は、Ubuntu(WSL2)の環境で、Ubuntu-24.04-my　という名称の
ディストロでの環境での

\wsl.localhost\Ubuntu-24.04-my\jit_myDocker\laravel_next_docker\backend\laravelapp

のパスを
で、エクスプローラーで開くことになる

Ctrl+A

で、全選択後に、

Ctrlキーを押しながら　vendor フォルダをクリックすると

vendor フォルダが選択対象から外れる

その状況が、下記の図である

この状況で、右クリして、サイズを見ると

わずか、11.8　MB　程度の容量である。

vendorとか、node_moduleなどは、避けたい　それがほとんどの大きさ

それを避ければ、わずかであることが多い

アプリの仕様によっては、storageとかに画像や、動画もあるかもなので、場合によってはそれも避けるなどして

いい感じの大きさで、

右クリして、コピーして

ファイルサーバーのバックアップとりたいフォルダを事前につくっといて

貼り付けのような形

わずか、11.8　MB　程度の容量であれば

ファイルサーバーに、個人用の作業領域を作らせてもらって、

日付をつけたフォルダの中にバックアップをとるを

３世代ぐらいして。

古いものは、削除しとく

それぐらいであれば、その現場には、あまり迷惑ではない

プルリクがだせて、リモートにプッシュできしまったものは、大丈夫ですが

それまでの過程で、PCが壊れて、飛んでしまわないように

ちょくちょく、これをするようには、したほうがよさげ

個人開発だと、バックアップ先が、外付けの容量の大きなハードディスク
だったりするだけで考え方同じ。