Docker全盛の時代にDockerなしで開発環境構築してみた
開発環境を構築する上でいかに運用の手間を省けるのか
を考えてみました。
今回はDockerを使わずに開発する前提で開発環境を作りました
決してDocker否定派ではないです。
過去にDockerの入門みたいなのも取り上げたぐらいなので
読み取りのみでOKという勘違い
nginxのインストール直後のconf.dのディレクトリは755
lsとかvimとか読み取るだけであれば実行権限は不要
と思っていたのですが、実行権限を外して4にすると
ls,vimなどのコマンドが使えなくなってしまった
結局は7の全権を与えないとダメみたい
sudo chmod -R 755 conf.d/
ls conf.d/
frontend.conf fullchain.pem privkey.pem
touch conf.d/komatsu
touch: `komatsu' に touch できません: 許可がありません
chmod -R 766 conf.d/
ls
ls: ディレクトリ . を開くことが出来ません: 許可がありません
touch komatsu
touch: `komatsu' に touch できません: 許可がありません
chmod -R 777 conf.d/
# ls
frontend.conf fullchain.pem privkey.pem
# touch komatsu
777にしたら当たり前の話なんでもできる
今回、前回の記事の事もあり
普通の開発者にぎりぎりまで権限を与えて
悪い事をしたら、履歴で犯人を探せるようにと考えたら
sudoの権限でほとんどのコマンドを与えてしまうと
結局なんでもできてしまうので
前回の妄想の続きから考えると
sudoでできるコマンドは
less, ls, systemctl, tail
ぐたいに絞らなければいけないかと
このコマンドだけで、ログをみたりサービスの再起動は可能
777でもPermission denied!!
777で全許可にしたのに
/public/robots.txt" failed (13: Permission denied)
とエラーが出る
777なのに？
色々調査して再起動したりして
結局
/var/www/の所有者を
nginxにしたらいけました。
/var/www/は
chown -R nginx:任意のグループ /var/www/
その任意のグループに開発者全員を所属させる
そうすれば各開発者が自由に開発環境を構築できるはず
あとは開発者自身で開発環境構築
git clone 直後は 644のディレクトリなので権限を
755に変更
log 書き込みの部分は
777に変更
cdでgit clone したフォルダに入り
composer install
でpackage.jsonに
chmod -R 777 storage
が記載されてたら
composer install
だけでOK
Dockerのメリット・デメリット
今クラウド、Docker全盛の時代
だけどもVPSのオープンな場所でLinuxのサーバーを構築
そして、開発者はサーバーにログイン
ディレクトリとnginxの設定ファイルを作成
開発に直接ログインしてファイルを書き換えるか
ローカルPCと開発サーバーにrsyncで同期するか
のどっちかで開発しないといけません
それが手間と捉えるべきか
Dockerの場合
Dockerをインストールするだけ
たまにDBをDockerに入れられると各開発者のDB変更がある
それをseederとかで同期する手間がかかる
各開発者のローカルのDockerで「出来ました」ってなった時
ステージングサーバーとかにいちいちデプロイしないといけない
Dockerの方が運用的に手間がかかる部分もあるかも
登録日：
更新日：