私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ【PHP】Laravel【フレームワーク】 Part.5
php スレッド一覧へ / php とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
>>299
お前はアホなのか。それも環境ごとにファイル用意して管理て話だから、.envコミット否定派のナレッジなんだが。後、まとめてくれてるやつってどれ?
お前はアホなのか。それも環境ごとにファイル用意して管理て話だから、.envコミット否定派のナレッジなんだが。後、まとめてくれてるやつってどれ?
Q. Should I have multiple .env files?
A. No. We strongly recommend against having a "main" .env file and an "environment" .env file like .env.test.
Your config should vary between deploys, and you should not be sharing values between environments.
辞めたほうが良いよってdotenvの公式にも書かれてるけどね
どうしてもそうしたいなら好きにすればいいと思うけど、それはあなたのプロジェクト内の話であってデファクトみたいな顔すんのは違うんじゃねーの?
A. No. We strongly recommend against having a "main" .env file and an "environment" .env file like .env.test.
Your config should vary between deploys, and you should not be sharing values between environments.
辞めたほうが良いよってdotenvの公式にも書かれてるけどね
どうしてもそうしたいなら好きにすればいいと思うけど、それはあなたのプロジェクト内の話であってデファクトみたいな顔すんのは違うんじゃねーの?
>>304
デファクトの話は今してないよ
.envをコミットしなきゃならないプロジェクトに置かれたときに、前スレに有用そうな情報を提示してくれている人がいるってことと、世の中にはコミットしなきゃならないプロジェクトがあるってことを延々と説明させられてる
有用そうな情報を提供してくれている人がいるのに、それをまるっと否定するやつが邪魔なだけ
デファクトの話は今してないよ
.envをコミットしなきゃならないプロジェクトに置かれたときに、前スレに有用そうな情報を提示してくれている人がいるってことと、世の中にはコミットしなきゃならないプロジェクトがあるってことを延々と説明させられてる
有用そうな情報を提供してくれている人がいるのに、それをまるっと否定するやつが邪魔なだけ
.envコミット否定派は、.envという.gitignoreされているものをわざわざコミット可能にするのは意味がないって言っているわけよ。理由は以下だ。
・環境ごとに異なるから
・クレデンシャル情報がコミットされるリスクがあるから
それに対して、.env.prdや.env.stgて別ファイルにして管理してますってのは.envコミット賛成派の意見なの?
・環境ごとに異なるから
・クレデンシャル情報がコミットされるリスクがあるから
それに対して、.env.prdや.env.stgて別ファイルにして管理してますってのは.envコミット賛成派の意見なの?
.envをgitに入れてる事自体が一般的には異常なのにな
こういう奴らはsshのprivate keyとかも平気でgitに入れてそうで怖いわw
こういう奴らはsshのprivate keyとかも平気でgitに入れてそうで怖いわw
>>308
賛成派っておかしくない?ここ一連の流れでは、「必要があるからコミットする」って説明しかしてないんだけど?
賛成派っておかしくない?ここ一連の流れでは、「必要があるからコミットする」って説明しかしてないんだけど?
そんなわけあるか。事実、.env.exampleの存在を否定派は認めていたでしょ。否定してたのは.envてファイルそのもののコミットだよ。
まとめを貼り付けておくね
・.envは環境を定義するためのものなので環境ごとに異なる。各環境に直置きし、ソース管理に含めないのがお手軽
・定義すべき内容(テンプレート)は.env.exampleで共有すると良い(こちらはソース管理に含む)
とはいっても.envを管理対象に含めたいプロジェクトはそこそこある
以下の対応をすると良い
*機密情報の取り扱いに関して
厳密には、.envを管理する/しないとは関係がないが、以下のように整理すると良い
・どのような立場の人から情報を守りたいのかを定義し(セキュリティポリシー)、その対応としての実装を行う(ガイドライン)
・公式ドキュメントには、「source control repository」からの流出が一例として載っているが、その想定は一般的ではないのでポリシー設計時には自システムに対応した脅威を整理すること
・ルールで縛られることも多い。例えば「データベースへの接続情報は、ミドルウェアの管理者が管理する事」とか「特定管理者以外に資格情報は開示しない」とか
・実装方法は、.envに記述する/環境変数を使用する/変数として管理しデプロイ時に上書き等々あるが、ポリシーとセットで語られるべき内容なので省略
*.envファイルの管理方法
以下のような実装方法がある模様
・環境ごとのファイルを用意して、環境変数APP_ENVで切り替える(注:defining a server-level APP_ENV)
・各環境のローカルリポジトリとして管理
・共通の.envを用意して部分的に環境変数で上書き
・共通の.envが使用できるように、デプロイ先の環境をそろえる
・.envは環境を定義するためのものなので環境ごとに異なる。各環境に直置きし、ソース管理に含めないのがお手軽
・定義すべき内容(テンプレート)は.env.exampleで共有すると良い(こちらはソース管理に含む)
とはいっても.envを管理対象に含めたいプロジェクトはそこそこある
以下の対応をすると良い
*機密情報の取り扱いに関して
厳密には、.envを管理する/しないとは関係がないが、以下のように整理すると良い
・どのような立場の人から情報を守りたいのかを定義し(セキュリティポリシー)、その対応としての実装を行う(ガイドライン)
・公式ドキュメントには、「source control repository」からの流出が一例として載っているが、その想定は一般的ではないのでポリシー設計時には自システムに対応した脅威を整理すること
・ルールで縛られることも多い。例えば「データベースへの接続情報は、ミドルウェアの管理者が管理する事」とか「特定管理者以外に資格情報は開示しない」とか
・実装方法は、.envに記述する/環境変数を使用する/変数として管理しデプロイ時に上書き等々あるが、ポリシーとセットで語られるべき内容なので省略
*.envファイルの管理方法
以下のような実装方法がある模様
・環境ごとのファイルを用意して、環境変数APP_ENVで切り替える(注:defining a server-level APP_ENV)
・各環境のローカルリポジトリとして管理
・共通の.envを用意して部分的に環境変数で上書き
・共通の.envが使用できるように、デプロイ先の環境をそろえる
>>311
その必要なケースとは何?って聞いても
「客の依頼」とか「上司からの指示」しか答え返ってきてないけど
自身の主張は無いの?
「上司の指示でコミットするけど、自分はそれを合理的な指示だと思わない」
と
「上司の指示でコミットするし、自分もそれを合理的な指示だと思う」
の2パターンあるよね
前者の場合だと.envをコミットは否定されるから、結局客や上司の主張と合理性は関係ないよね。
その必要なケースとは何?って聞いても
「客の依頼」とか「上司からの指示」しか答え返ってきてないけど
自身の主張は無いの?
「上司の指示でコミットするけど、自分はそれを合理的な指示だと思わない」
と
「上司の指示でコミットするし、自分もそれを合理的な指示だと思う」
の2パターンあるよね
前者の場合だと.envをコミットは否定されるから、結局客や上司の主張と合理性は関係ないよね。
おかしいのはお前だよ。老害認定する奴もそうだったけど、.env自体のコミットは意味ないって話だったのに、なんで、.env.stgや.env.prdが.envコミットすることと同義になるんだよ・・・。勝手にゴールポスト変更するなよ。
>>315
> 自身の主張は無いの?
それは、このスレで議論しても仕方ないって言ったはずだけど?
おおよそ不具合発生時の対応として発生したルールで、QCに関わる部分だから上意下達が普通
合理的かどうかは、開発部門全体が見れるポジションにいなければ判断できない
個社別の理由だからLaravelスレで開示されても困る
> 自身の主張は無いの?
それは、このスレで議論しても仕方ないって言ったはずだけど?
おおよそ不具合発生時の対応として発生したルールで、QCに関わる部分だから上意下達が普通
合理的かどうかは、開発部門全体が見れるポジションにいなければ判断できない
個社別の理由だからLaravelスレで開示されても困る
1中 composer.lock, package-lock.json をコミットしない
2右 vendor, node_modules をコミットする
3左 .envを別名で複数作る
4一 .envをコミットに入れる
5三 jsonをレスポンスするAPIは脆弱
6二 サロゲートキーをAIするのは頭が腐ってる
7遊 本番環境が開発環境
8捕 emailカラムにemailと関係無いユーザー識別子を入れる
9投 零細企業で勤務する
2右 vendor, node_modules をコミットする
3左 .envを別名で複数作る
4一 .envをコミットに入れる
5三 jsonをレスポンスするAPIは脆弱
6二 サロゲートキーをAIするのは頭が腐ってる
7遊 本番環境が開発環境
8捕 emailカラムにemailと関係無いユーザー識別子を入れる
9投 零細企業で勤務する
>>321
これがこのスレにおける平均的ララベラーですね
これがこのスレにおける平均的ララベラーですね
>>318
同じだぞ。exampleはアプリケーションを開発環境で動かす際に必要な環境変数を定義しておく。もちろんクレデンシャル情報は除く。
.env.stgや.env.prdも同様。
違いがあるとすればそれを自動でロードするか手動で.env内にコピーして使うかの違いでしかない。
同じだぞ。exampleはアプリケーションを開発環境で動かす際に必要な環境変数を定義しておく。もちろんクレデンシャル情報は除く。
.env.stgや.env.prdも同様。
違いがあるとすればそれを自動でロードするか手動で.env内にコピーして使うかの違いでしかない。
俺、今まで.envをコミットするのってネタだと思ってたんだけど、マジレス具合見てるとネタじゃなくて本気なんだと考えを改めるようになった
リファクタしました
1中 composer.lock をコミットしない
2右 vendor をコミットする
3左 .envを別名で複数作る
4一 .envをコミットする
5三 jsonをレスポンスするAPIは脆弱
6二 サロゲートキーをAIするのは頭が腐ってる
7遊 本番環境が開発環境
8捕 emailカラムにemailと関係無いユーザー識別子を入れる
9投 年収450万円上未満
1中 composer.lock をコミットしない
2右 vendor をコミットする
3左 .envを別名で複数作る
4一 .envをコミットする
5三 jsonをレスポンスするAPIは脆弱
6二 サロゲートキーをAIするのは頭が腐ってる
7遊 本番環境が開発環境
8捕 emailカラムにemailと関係無いユーザー識別子を入れる
9投 年収450万円上未満
>>326
.envをコミットしなきゃならん環境なんてでかい会社だと普通にある
.envをコミットしなきゃならん環境なんてでかい会社だと普通にある
「でかい会社」ってのがどういう規模なのか知らんけど、
人数が多くなればなるほど機微情報をリポジトリに入れるリスクは増えるからありえないと思う、むしろ零細のほうがデメリットが少ない。
※ デメリットが減るというだけでメリットがあるわけではない。
>>330
記録が欲しいという観点だと開発用のリポジトリとは別の媒体で管理するけどね。
今俺が勤めてる会社はいわゆる中小企業だけど、親会社は大手でそこからの出向者も多く居る会社だけど、
本番や検証環境のクレデンシャルなんかは別の媒体で管理してて、閲覧可能なメンバーはデプロイ担当者とマネージャー系だけに限られてるよ。
リポジトリに機微情報入れるとか絶対にありえないよw
人数が多くなればなるほど機微情報をリポジトリに入れるリスクは増えるからありえないと思う、むしろ零細のほうがデメリットが少ない。
※ デメリットが減るというだけでメリットがあるわけではない。
>>330
記録が欲しいという観点だと開発用のリポジトリとは別の媒体で管理するけどね。
今俺が勤めてる会社はいわゆる中小企業だけど、親会社は大手でそこからの出向者も多く居る会社だけど、
本番や検証環境のクレデンシャルなんかは別の媒体で管理してて、閲覧可能なメンバーはデプロイ担当者とマネージャー系だけに限られてるよ。
リポジトリに機微情報入れるとか絶対にありえないよw
ミソとなるのは開発メンバー全員に本番環境のクレデンシャル晒すところだよね
確かに零細ならメンバー少ないしそこまで否定できないかも
大手ほどコミットするって話は本当に開発用リポジトリに対しての話なの?w
独立したリポジトリにコミットしてるとかなら話は別だしそれは否定することでも無いよ
確かに零細ならメンバー少ないしそこまで否定できないかも
大手ほどコミットするって話は本当に開発用リポジトリに対しての話なの?w
独立したリポジトリにコミットしてるとかなら話は別だしそれは否定することでも無いよ
ナレッジとして使えるように整理しておいたわ。
論点1
クレデンシャル情報入りの.envをコードと同じリモートリポジトリで管理して良いか?
ありえない。理由は以下。
・プライベートであっても、リモートリポジトリは容易に設定ミスでパプリックになるリスクがあるから
・プライベートリポジトリはクラッカーの攻撃対象として常に脅威に晒されているから
・コードにアクセスできる人とクレデンシャル情報の人は基本的に一致しないから
管理上どうしても履歴管理したいなら、AWSなどが提供する専用サービスを使う、ローカルリポジトリまたは暗号化されたリモートリポジトリでコードと分けて管理するのが合理的。
履歴管理が不要なら、サーバー側の環境変数としてあらかじめ設定しておく。
論点2
クレデンシャル情報なしの.envをコードと同じリモートリポジトリで管理して良いか?
ありえない。なぜなら環境によって使用するパラメータが異なるから。
論点2-1
全環境同じパラメータを使う場合なら良いか?
ありだが間抜け。その場合はconfigファイルのデフォルト値に設定すれば良いので.env自体不要と考えるべき。
論点2-2
環境ごとのファイルを別途用意し、切り替えて使うなら良いか?
あり。
論点1
クレデンシャル情報入りの.envをコードと同じリモートリポジトリで管理して良いか?
ありえない。理由は以下。
・プライベートであっても、リモートリポジトリは容易に設定ミスでパプリックになるリスクがあるから
・プライベートリポジトリはクラッカーの攻撃対象として常に脅威に晒されているから
・コードにアクセスできる人とクレデンシャル情報の人は基本的に一致しないから
管理上どうしても履歴管理したいなら、AWSなどが提供する専用サービスを使う、ローカルリポジトリまたは暗号化されたリモートリポジトリでコードと分けて管理するのが合理的。
履歴管理が不要なら、サーバー側の環境変数としてあらかじめ設定しておく。
論点2
クレデンシャル情報なしの.envをコードと同じリモートリポジトリで管理して良いか?
ありえない。なぜなら環境によって使用するパラメータが異なるから。
論点2-1
全環境同じパラメータを使う場合なら良いか?
ありだが間抜け。その場合はconfigファイルのデフォルト値に設定すれば良いので.env自体不要と考えるべき。
論点2-2
環境ごとのファイルを別途用意し、切り替えて使うなら良いか?
あり。
>>324
根拠一切無しの決めつけは草
根拠一切無しの決めつけは草
>>338
ゴミみたいなガイドラインでもそれに従えて話か?そんなエッジケース、論点でもなんでもないだろう。ナレッジって意味わかってるか?
ゴミみたいなガイドラインでもそれに従えて話か?そんなエッジケース、論点でもなんでもないだろう。ナレッジって意味わかってるか?
環境ごとに異なるから.envに書いているのに、環境ごとに異なるとは限らないと主張するのは面白いな
>>341
安倍晋三かよw
安倍晋三かよw
>>340
しかも論点2-1にそれへのアンサーも書いてあるんだよね。
しかも論点2-1にそれへのアンサーも書いてあるんだよね。
.envはもうどうでもいいよ
サロゲートキーで発狂する話のほうがまだ面白いわ
サロゲートキーで発狂する話のほうがまだ面白いわ
dotenvの解釈、足りてないぞ
設定をコードから分離する先としても機能する
設定をコードから分離する先としても機能する
>>346
ヤベーなお前。そんなエッジケースがここにいる他の奴らにどう役立つんだ?ナレッジの意味わかってるか?
ヤベーなお前。そんなエッジケースがここにいる他の奴らにどう役立つんだ?ナレッジの意味わかってるか?
みんなの評価 :
類似してるかもしれないスレッド
- 【PHP】Laravel【フレームワーク】 Part.9 (884) - [98%] - 2022/3/13 12:00
- 【PHP】Laravel【フレームワーク】 Part.8 (148) - [98%] - 2021/8/8 21:30
- 【PHP】Laravel【フレームワーク】 Part.7 (779) - [98%] - 2021/7/9 16:18
- 【PHP】Laravel【フレームワーク】 Part.6 (745) - [98%] - 2021/6/21 6:30
- 【PHP】Laravel【フレームワーク】 Part.12 (314) - [96%] - 2023/1/30 18:45
- 【PHP】Laravel【フレームワーク】 Part.10 (446) - [96%] - 2022/6/6 19:30
- 【PHP】Laravel【フレームワーク】 Part.4 (460) - [96%] - 2021/4/4 4:00
- 【PHP】Laravel【フレームワーク】 Part.3 (983) - [96%] - 2021/2/12 4:00
- 【PHP】Laravel【フレームワーク】 Part.2 (917) - [96%] - 2019/9/10 9:15
- 【PHP】Laravel【フレームワーク】 Part.11 (870) - [96%] - 2022/8/28 15:45
- 【PHP】Laravel【フレームワーク】 (887) - [84%] - 2019/4/23 21:00
- 【PHP】フレームワーク Akelos (129) - [56%] - 2019/5/9 7:46
トップメニューへ / →のくす牧場書庫について