CHANSHIGELOG

いろんなこと

el7+phpenv+nginx(php-fpm)で開発環境を作り直した話 その2

前回からの続き、主にwebサーバー(nginx + php-fpm)に対するの設定を書き残していきます。
chanshige.hatenablog.com

yum install するとき -y をつけてる記事が多いですが、インストールされる内容(依存関係のパッケージ)など眺めながらやるのもオススメですので、書いてません。

では、nginxをインストール

# yum install nginx

自動起動設定もやっておく
# systemctl enable nginx
 ※ nginx.service って明示的に宣言するのもあり

nginxの設定ファイルを用意する
# vi /etc/nginx/conf.d/dev.conf

server {
    listen       81;
    server_name  192.168.33.10:81;

    error_log    /var/log/nginx/error_81.log;
    access_log   /var/log/nginx/access_81.log;

    root         /home/vagrant;
    index        index.html index.htm index.php;

    location / {
        try_files $uri $uri/ /index.php$is_args$args;
    }

    location ~ \.php$ {
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        include        fastcgi_params;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
    }
}

URLはhttp://192.168.33.10:81 、ドキュメントルート(root)は/home/vagrantにしてますが、その他諸々も自由に変えてください。

php-fpmの設定を変更する
# vi /usr/local/phpenv/versions/7.2.13/etc/php-fpm.d/www.conf
user/group を適宜調整してください。よくあるのはどちらもnginxです

; Unix user/group of processes
; Note: The user is mandatory. If the group is not set, the default user's group
;       will be used.
user = vagrant
group = vagrant

phpのバージョンに合わせた、php-fpmをサービス登録する。
既存ファイルを参考にして作る記事や説明が多いですが、phpenvに同梱されているのでコピーして使います。

php7.2 を選択中なので、こちらを使う
※ systemd 配下に置くサービス名はわかりやすくバージョンつけておく
# cp /usr/local/phpenv/versions/7.2.13/etc/systemd/system/php-fpm.service /usr/lib/systemd/system/php-fpm-7.2.13.service

ここまでできたら、あとはnginx, php-fpm を起動すれば完了です。

# systemctl start php-fpm-7.2.13.service
# systemctl start nginx.service

phpのバージョンを変更するときは、以下をやってください。

7.2のphp-fpmとnginxを終了
# systemctl stop php-fpm-7.2.13.service
# systemctl stop nginx.service

バージョン毎のphp-fpm.serviceをコピー
cp /usr/local/phpenv/versions/x.x.x/etc/systemd/system/php-fpm.service /usr/lib/systemd/system/php-fpm-x.x.x.service

起動
# systemctl start php-fpm-x.x.x.service
# systemctl start nginx.service

この作業を通して、アプリケーションやサイト1つ動かすにしても、サーバー側では様々な設定が行われて動いてる(公開できている)ことがよくわかります。

こういったことを気にしなくても、ボタン一つで環境が立ち上がって、快適に使える環境を提供しているサービスがあり、それを支えてる方々は真面目にすげーなと思うばかりです。

今回の手順に関して、細かい内容はググったらだいたい出てくるので割愛してますが、世の中に向けて公開するサーバーを構築する場合は、もっと(設定を)やらないといけないことがたくさんあるので、あくまでもローカルで楽しんでくださいね😂

近いうちに、Dockerを使って開発環境作ってみた話を書こうと思います。

おわり

【2019】el7+phpenv+nginx(php-fpm)で開発環境を作り直した話 その1

あけましておめでとうございます。
2019年も引き続き、よろしくお願いいたします。

去年の大晦日から元旦にかけ、MacOSをMojaveにアップグレードしたついでに、
Vagrantの開発環境も新しくしたので、備忘録程度に残していきたいと思います。

旧環境を取っておけば一発だったと思いますが、実際にコマンド叩いて環境構築していくのも楽しいし、理解が深まるので久しぶりにやってみました。

まずは作業ディレクトリとCentOS7のBoxを使う前提のVagrantfileを生成します。

$ mkdir vagrant-dev
$ cd vagrant-dev
$ vagrant init centos/7

環境のサーバIPを設定 (好きなように変更)
$ vim Vagrantfile

  # Create a private network, which allows host-only access to the machine
  # using a specific IP.
  config.vm.network "private_network", ip: "192.168.33.10"

結構便利なプラグインも入れておく
$ vagrant plugin install vagrant-vbguest

お立ち上げからsshログイン

$ vagrant up
$ vagrant ssh

これでベースができたので、ここからサーバの設定とphpenv(rbenv), nginxなどなどを入れます。

rootに移動
$ sudo su -

SELinuxを無効にする
# vi /etc/sysconfig/selinux

disabled に変更して保存

SELINUX=disabled

timezoneをAsia/Tokyo にOverwrite

# cp /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

ここでsshログアウト後、 $ vagrant reload をしてVMを再起動
あらためて $vagrant sshログイン後、rootに移動する $ sudo su -

TimezoneがJSTになってることを確認
# date

EPELリポジトリと、phpenv等で必要になるパッケージをインストール
# yum install epel-release openssl-devel readline-devel zlib-devel libxml2-devel bzip2-devel curl-devel libjpeg-devel libpng-devel libicu-devel gcc-c++ libtidy-devel libxslt-devel autoconf bison-devel wget unzip perl-ExtUtils-MakeMaker

gitをインストール ※yumでも入りますが、新しいVersionを使う

# wget https://www.kernel.org/pub/software/scm/git/git-2.9.5.tar.gz
# tar vfx git-2.9.5.tar.gz
# cd git-2.9.5
# make configure
# ./configure --prefix=/usr
# make all
# make install

インストールできたか確認
# git --version

不要なファイルを削除
# cd ../ && rm -rf git-*

phpenv をシステムワイドに入れる

# git clone https://github.com/CHH/phpenv.git
# phpenv/bin/phpenv-install.sh
# mv .phpenv/ /usr/local/phpenv
# chmod 775 -R /usr/local/phpenv
# git clone https://github.com/php-build/php-build.git /usr/local/phpenv/plugins/php-build
# exec $SHELL
# phpenv

rbenv も必要になるので同様に入れる

# git clone http://github.com/sstephenson/rbenv.git .rbenv
# mv .rbenv/ /usr/local/rbenv
# chmod 775 -R /usr/local/rbenv
# git clone https://github.com/sstephenson/ruby-build.git /usr/local/rbenv/plugins/ruby-build
# exec $SHELL
# rbenv

rbenvのprofileを修正して保存
# vi /etc/profile.d/rbenv.sh

export RBENV_ROOT="/usr/local/rbenv"
export PATH="$RBENV_ROOT/bin:/usr/local/phpenv/bin:$PATH"
eval "$(rbenv init -)"
eval "$(phpenv init -)"

リロード
# exec $SHELL

rubyインストール

# rbenv install 2.6.0
# rbenv global 2.6.0
# rbenv versions
# ruby -v

phpenv をちょっと修正
# vi /usr/local/phpenv/bin/phpenv

#!/usr/bin/env bash
export PHPENV_ROOT=${PHPENV_ROOT:-'/usr/local/phpenv'}
export RBENV_ROOT="$PHPENV_ROOT"
exec "$RBENV_ROOT/libexec/rbenv" "$@"

リロード
# exec $SHELL

やっと、phpインストール
5.6 / 7.1 / 7.2 を入れます

# phpenv install 7.1.25
# phpenv install 7.2.13
# phpenv install 5.6.39

確認 (このときはまだバージョン指定がされていない状態)
# phpenv versions
* system (set by /usr/local/phpenv/version)
  5.6.39
  7.1.25
  7.2.13

コマンド無いよ!となる
# php -v
rbenv: php: command not found

The `php' command exists in these PHP versions:
  5.6.39
  7.1.25
  7.2.13

システムのphpバージョンを7.2に切り替える (バージョンはインストールしたものを指定)

# phpenv global 7.2.13

確認
# phpenv versions
  system
  5.6.39
  7.1.25
* 7.2.13 (set by /usr/local/phpenv/version)

生きた...!!! ちゃっかりXdebugもある素敵
# php -v
PHP 7.2.13 (cli) (built: Jan  9 2019 20:17:32) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.2.13, Copyright (c) 1999-2018, by Zend Technologies
    with Xdebug v2.6.1, Copyright (c) 2002-2018, by Derick Rethans

ついでにcomposerも入れましょう

# curl -sS https://getcomposer.org/installer | php
# mv composer.phar /usr/local/bin/composer

※ 以下でも可
# yum install composer

確認(rootで動かすなや!といわれてます。実際はrootで叩かないのでOK)
# composer --version
Do not run Composer as root/super user! See https://getcomposer.org/root for details
Composer version 1.8.0 xxxxx

長くなりましたので、この辺にしておきます!
次回は php-fpm + nginx の設定を書こうと思います。

※追記 書いたのでリンク

chanshige.hatenablog.com

ブログタイトル変えてみた

どうもちゃんしげです。CHANSHIGELOG にしてみました。CHANGELOGっぽい。

3月から全くブログを書いていなかったので、ここ最近の出来事をざっくりと。

といったかんじで、公私ともにPHPerの日々を送っております。

PHPカンファレンス福岡2018

f:id:tanakashigeki:20180725001738j:plain:w500

PSR関連のセッションがあったのは個人的に嬉しかった。 今回はLog(PSR-3)だったけど、僕的に好きなPSR-7系の話もどこかで聞きた、、(登壇

www.php-fig.org

www.php-fig.org

今年も盛り上がりと場の雰囲気作りがすごくよかったです!運営スタッフの方々ありがとうございます。

PHPカンファレンス関西2018

f:id:tanakashigeki:20180725001747j:plain:w500

名札にスキルとか好きなものをステッカー貼ってアピれるの良い!

PHPerKaigiから追っかけてた「続・SOLIDのってどんなふうに使うの?」の集大成をみることができてよかった。デザパタ大事ですよ!!!!!!

続・SOLIDの原則ってどんなふうに使うの? 〜オープン・クローズドの原則 センパイのコーディングノート編〜 - Speaker Deck

話の進め方が、センパイとコウハイくんの対話形式っていうのが親しみやすくて、面白い。日々の設計・実装(保守でも)ちょっとした意識だったり見方・捉え方を変えてみるっていうのは、やり続けたいと思いました。

PHPカンファレンス関西の会場であるグランフロント大阪

f:id:tanakashigeki:20180725002146j:plain:w500

いつみてもイケてる。なぜかグランフロント好きなんだなー(ロゴも)

やっとチリチリいけた(人の回転よすぎて驚き)

f:id:tanakashigeki:20180725002141j:plain:w500

トッピングありきであることを後で気づいたのでまた行く

セリーヌディオンすごすぎた、、最高。(10年ぶりの来日とのこと)

f:id:tanakashigeki:20180725002148j:plain:w500

番外編:福岡・大濠公園近くの「炭焼きとりこ」美味しい

f:id:tanakashigeki:20180725002157j:plain:w500

来月は今のところ福岡から出る予定はないけど、お盆だし実家帰ろうと思います。あとひきラーメン食べたいし

PHPerKaigi2018 いってきた @東京

3/9 - 3/10 に開催された記念すべき第一回目の PHPerKaigi 2018 に行ってきました!(遅)

phperkaigi.jp

僕は3/10(土曜)からの参加で、久しぶりの東京&練馬ってどこ?やばい楽しいという気持ちで望んだんですが、 率直に楽しかったし笑ったし、最高な1日を過ごすことができたと感じています。

個人的には、フレームワークBearSunday」の郡山さんのセッションを聴きたい!きっかけで参加を決めたんですが、 それも前職でお世話になったエンジニアの師匠がリスペクトをされていた方だというのもあったのでとても楽しみでした。

※ おぉ〜やばいやばいってなってました。

今回の参加で、僕が特に気になったタイトルは以下です!

SOLIDの原則ってどんなふうに使うの? - Speaker Deck

前職の師匠がちょくちょく仰ってたSOLIDの原則でしたが、例えがわかりやすくて理解度がさらに深まったと思います! 実際にやろうとするとなかなかうまくいかないなと思うんですが、良書読んだり、良いコード好きなアプローチを見て真似ることが大事かなと思いました。

Hackで作るマイクロフレームワーク - Speaker Deck

正直なところ、HHVM/Hackを全然チェックしていなかったので新鮮すぎました!!!!

男になるしかねーなっ!という気持ちです!!!!

BEAR.Sunday (2018) - Speaker Deck

コーディング・実装に対する考え方というところが本当にどハマりしてしまいました。 まだまだ理解は浅いですが、いろんなアプローチ方法(デザパタ等)を見る・取り込むことで深まる気がしています!

以下の様にメモ取ってたのですが、まだまとめられていないので改めて書こうかなって思います!

アプリケーション制約こそがフレームワーク
それぞれのドメイン(DB・認証) -> ライブラリ

アプリケーション全体にわたっての制約が"フレームワーク"

DI: 疎結合とコーディングを可能にする、ソフトウェアデザインとパターンのセット
実装ではなく、インターフェースに対してプログラムをする

実装に対するプログラム ができてないソフトウェアとは?

密結合なソフトウェアでもユーザへの価値は提供できる -> get shit done.
ただし、開発者としてメンテナンス性はどうか?
密結合している場合、再度工事が必要になってしまう。

ユーザーに新しい価値を届け続けるには、密結合のソフトウェアは向いてない
成功したソフトウェアは必ず変更し続ける

コンセント:インターフェース

インターフェースに対してコンポーネントを作る。
ドライヤー(例)以外の価値を届けることができる

リスコフの置換原則
decoratorパターン
compositeパターン
NullObjectパターン
adapterパターン

インターフェースに対して依存しているだけ
抽象を使う。インターフェースは中身がない規格だけ。

僕のやっていきがさらに高まった瞬間でもあります (本家からのレスポンスがあああああ!)

また今回のPHPerKaigi2018ですが、03/24現在でYoutubeにセッションがあがっているようですので、 是非観ていただけたらと思います、、、!

あとちょっとおもったのが、LaravelやcakePHPってやはり人気なのですね! やっぱ触っていかないとなっていう気持ちですが、僕はSymfony3(4)/Slim3 も結構好きなので、この好きをもっとアピールできるように鍛えていきたいと思います。

最後に

東京久しぶりに行ったんですよ!もう3年ぶりってぐらいだったんですけど、朝5時起きで福岡->東京(羽田)で着いたのが8:30過ぎで、 そこから京急->地下鉄?->練馬 だたんですが、結構遠いんですね!3/10オープニング間に合わなかったんです笑

結構ドタバタな1日でしたが、PHPerKaigi2018素直に楽しかったです!鳥貴族も行けたので満足です笑

なにかしらの形でしっかりアウトプットしていきたいと思いました!

次回はしっかり前乗りしていこうと思います2019!!!!!

スタッフの皆様ならびにスピーカーの方々本当にありがとうございました!!!

過去のアクセスログから特定のHTTPレスポンスコードが何件あるか調べたとき【メモ】

お仕事で xxxx-ymd.gz というように、日毎ローテートされた複数のログファイルから、特定のレスポンスコード(404,500,503とか)を持ってるレコードが何件あるかを調べることがあって、大量にファイルがあったので以下コマンドでやったんですが、なぜか wc -l のカウント数が合算されているようにみえたときがありました。

find . -type f -name "xxxx-*" |sort |xargs -t -n 1 -I% bash -c 'zcat % |awk "{if(\$9=={該当コード}) print \$0}"| wc -l'

長い!!!!

しかし、別の日にやると普通にファイルごとでカウントされた結果を吐いてる。謎!!!!!!! 見間違いならよいけど、ちょっと気になったので備忘録としてメモでした。

※とりあえずその日は別で思いついた以下で対応して終了でした。

ls |xargs -t -n 1 -I% sh -c 'zcat % |awk "BEGIN{count = 0} \$9=={当該} {count = count+1} END{print count}"'

Dockerでsystemctlすると怒られた

コンテナ内でサービスを起動しようとするとこうなった。

# systemctl start httpd.service
Failed to get D-Bus connection: Operation not permitted

であれば、 --privileged という特権を与えて /sbin/init でrunすればOKだった。

% docker run --privileged -d -p 8080:80 --name sv01 centos /sbin/init
% docker exec -it sv01 /bin/bash

ただ、--privileged はやばそうなオプションだし、もっと違う方法がありそう。

Dockerのイメージとしては、httpd単体で使うこと(1コンテナ=1プロセス)がそれっぽいし、上だとリソース食い散らかしそうだけど、さっと立ち上げて使って捨ててレベルなら便利だなと思いました!

AirPodsすごいかもしれない

最近、昔より音楽聴かなくなってきたなーと感じている。

昔はやたらCDを買い漁ってたし、レコードにも手を出して飽きてとか、 そんなこともありましたが、今やAppleMusic や Spotifyのように、 インターネットでどうにでもなっちゃう時代になっていて、 手にとって音楽を感じることが減ったとおもった。

(僕は "Spotify" を契約しています。インターネットありがとう!!!!)

そんなことを思いながら、家にはイヤホンがその辺に置いてあるんですけど、 iPhone7から、3.5mmのイヤホンジャックがなくなったせいで、 聴く時間がかなり減ったんです。(lighteningのイヤホンなんかでかい)

そんなときにAirPodsという耳から白い棒が出てるようにみえるBluetoothのイヤホンがでて、 全く期待もなく、物欲もなかったので結構な期間スルーしてたんですが、この前ヤマダ電機に行ったらあったんです。(在庫が)

コレが。

AppleStoreじゃ発送まで6週間とか、相当人気じゃん!みたいな(今は2〜3週間?)印象が強かったので気づいたら買ってたんですが、使ってみる意外と"イイ"んです。 無線だから絡まることもないし、音も悪くない、操作のタイムラグも気にならない。さすがアップル製品。

おかげで、通勤時やちょっとした時間でも聴くようになって、なんか嬉しい!!音楽でテンションは結構変わる。

ただ、手元でボリューム操作ができないのは辛いなとおもいました。

Siriに"ボリューム40%にして" と頼むのなんて、街のど真ん中ではちょい恥ずかしさがある!! 電車の中だと更にハードルが高くなるお願いですね。

割と"モノ"に左右されまくってますが、何きっかけでもいいと思うので、たくさん聴いていきたいと思いました!