Vagrant – CentOS7 – Python3インストール

概要

Vagrant上のCentOS7にPython3をインストールした記録。

要点は以下の通り。

  • IUSのリポジトリーでインストール
  • --enablerepo=iusが必要

バージョン確認

まずPythonのバージョンを確認する。

一応Python2の動作確認。

Python3はインストールされていない。

IUSのリポジトリー追加

リポジトリー追加ができない。

リポジトリーは作成できている。

GitをインストールしたときにIUSのリポジトリーをインストールしていたのを忘れていた。

Python3がインストールできない

Python3.6をインストールしようとするができない。

/etc/yum.repos.d/ius.repoの設定でenabled = 0になっているため。Gitのインストールの時に書き換えているが、毎回元に戻るのか?

オプション設定でインストール成功

設定ファイルを書き換えてもよいが、yum実行時のオプションで--enablerepo=iusを追加して成功。

確認

バージョン確認。

動作確認。

Python2ではない。

python3の場所。

pipのバージョン確認。

 

PHP – Pythonのzip()

Pythonのzip()関数は、複数のコレクションの要素をパラレルに取り出すことができる。

PHPでは、array_map()関数を使って同様のことができる。

以下はコードで確認した例。

これをforeachに入れて各要素を配列で受け取れば、複数配列の要素をパラレルに得ることができる。

 

さくらサーバー – Laravel~デプロイ

概要

ローカルで開発したLaravelのプロジェクトを、さくらのレンタルサーバーにデプロイした時の記録。

  • ローカルで
    • CentOS7~Laravel~MySQLで開発
    • 必要に応じてデータベースのダンプファイルも含める
    • GitHubのリポジトリーに登録
  • さくらサーバーにssh接続
    • 秘密鍵と公開鍵をさくらサーバーにコピー
    • GitHubのリポジトリーをclone
    • 必要に応じてデータベースのダンプファイルから復帰
    • Laravelのpublicディレクトリーのシンボリックリンクを公開ディレクトリーに作成

躓いたのは以下の点

  • ssh鍵ファイルのパーミッション設定
  • login/registerのパス設定

Laravelを直接さくらサーバー上でインストールする手順はこちら

ローカルでの開発

プロジェクトの開発

通常の方法によって、ローカル環境でLaravelプロジェクトを開発。このとき、さくらのサーバー上で利用可能なPHP/Laravel/MySQLのバージョンを確認しておく。

データベースのダンプ

開発中にデータベースの実データを扱っている場合は、データベースの内容をダンプファイルに出力しておく

今回はリポジトリーのディレクトリーにダンプファイルを保存して、GitHub経由で共有した。

GitHubへのpush

ローカルの開発結果をコミットしてGitHubへpush。以下の手順によった。

  1. git add -f .venderディレクトリーなども含めてステージング
  2. git commit -mでコミット
  3. git pushでGitHubのリポジトリーに反映

ローカルでの状況は以下のとおり。

  • プロジェクトの配置→.../laravel/PROJECT/
  • ローカルサーバー→PROJECT/下でサーバーを起動
  • ローカルでのアクセス→localhost:3000/
  • GitHubのリポジトリー→laravelディレクトリー以下

さくらサーバーでのデプロイ

ssh接続の準備

GitHubとSSHでやり取りする準備。

  •  秘密鍵(id_rsa)と公開鍵(id_rsa.pub)をさくらサーバーにアップロード
    • アップロード先は~/.ssh/ディレクトリー
    • .ssh/ディレクトリは既に存在していて、パーミッションは700
  • アップロードした2つの鍵ファイルのパーミッションを600に変更する必要がある

ssh鍵でのエラー

当初、鍵ファイルのパーミッションが他者から読み取り可能のままになっていて接続できなかった。

2つの鍵のパーミッションを600に変更して解決。

プロジェクトの配置計画

さくらサーバーでの配置計画は以下のようにした。

  • プロジェクト本体は公開領域以外に置く
  • 公開領域にプロジェクトのpublicディレクトリーのシンボリックリンクを置く
  • シンボリックリンクの名前をプロジェクト名にする

これによって、”サイト名/プロジェクト名“というURLをアプリケーションのメインページとすることができる。

プロジェクトのダウンロード

GitHubのリポジトリーをさくらサーバーのユーザーホームディレクトリー下でclone。

故人開発であり、git pull/pushにするとサーバー側での.envの編集などの本質でない操作などが反映されてしまうので、ローカル側で編集したプロジェクトをさくらサーバー上でcloneするのがよいと考えた。

.envファイルの編集

さくら側のMySQLに接続するため、.envファイルの以下を変更。

  • MYSQL_HOSTはさくらのMySQLホスト名
    • mysql**.ユーザー名.sakura.ne.jpなど
  • DB_NAMEはさくら上でのDB名
    • ユーザー名_任意のDB名など
  • USER/PASSはMySQLに接続するためのユーザー名とパスワード

publicディレクトリーのシンボリックリンク

非公開に置いたプロジェクトのうち、公開対象のpublicディレクトリーのシンボリックリンクを公開領域(~/www)に作成する。リンク名はプロジェクト名と同じにした。

ログイン・サインアップできない

Laravelでの症状

当初プロジェクトをさくらサーバーに配置したとき、以下のような状況になった。

  • 非認証時のメインページや説明ページなどは表示・遷移できる
  • ログインやサインアップのフォームページも表示される
  • ログインページで入力後にボタンを押すと、WordPressのログイン画面に遷移してしまう
  • サインアップページで入力後にボタンを押すとWordPressの「ページが見つかりませんでした」表示

元々ドメイン直下ではWordPressが実行されるようになっていて、サブディレクトリーでLaravelを動かそうとしてこのような状況になった。

URL指定による同じ状況の再現

LoginController/RegisterControllerredirectToを変えたり、ルーティングファイルやindex.phpを触ったりしてみたが、状況は変わらず。その中で、以下のことに気づく。

  • URLで直接http://DOMAIN.com/loginを指定すると、WordPressのログイン画面に遷移する
  • URLで直接http://DOMAIN.com/registerを指定すると、WordPressの「ページが見つかりませんでした」表示

原因特定

Laravelではいずれもボタンを押した後に上と同じ状況になることに気づき、login.blade.phpregister.blade.phpを見てみると、POSTを発しているform要素のaction"/login""/register"を直に書いていた。

これらをルート名で"{{ route('login') }}""{{  route('register') }}"に変更したところ、正常にログインとサインアップができるようになった。これらのルート名は、Auth::routes()で設定自動的に設定されるので、artisanで確認。

考えてみれば至極当然の挙動で、ローカルと本番で配置形態が変わる場合に備えて徹底的にroute()を使うのがよさそう。

 

さくらサーバー – Laravel~インストール

概要

さくらレンタルサーバーのスタンダードプランを利用していて、そこにLaravelをインストールしてみた記録。以下の2つの方法を試してみた。

  • composerをドキュメントルートに配置し、ドキュメントルート下にプロジェクトを作成
  • composerをドキュメントルートと別の場所に配置し、ドキュメントルート下で公開

ローカルで開発したプロジェクトをデプロイする手順はこちら

ドキュメントルートへのインストール

composerのインストール

ssh接続後~/www(ドキュメントルート)に移動し、composer.pharをダウンロード。

インストール確認。

プロジェクト作成

~/wwwディレクトリーでテスト用のプロジェクトを作成。

動作確認

welcomeページ

ブラウザーでURLを指定。

結果は以下のエラー。

Forbidden
You don’t have permission to access this resource.

 

URLを以下のように指定して、welcomeページが無事表示される。ドキュメントルート下にプロジェクトを配置すると、publicディレクトリー内が公開対象になる。

ルーティング

以下のルーティングで'Hello'が表示される。

コントローラー

TestControllerコントローラーを作成してアクションを定義し、その中で文字列を渡す。

ルーティングを以下のように変更。

これでブラウザーに'Hello!'と表示される。

ビュー

resource/viewsディレクトリーに以下のビューファイルtest.blade.phpを作成。

TestControllerを以下のように修正。

これでブラウザーにアクセスすると、タブのタイトルが'Laravel Test'となり、h1要素のフォントで'Hello from blade!'と表示される。

別ディレクトリーへのインストール

composerのインストール

ドキュメントルート下にプロジェクトを配置するのは気持ち悪いので、別に配置する。ここではユーザーホーム下のディレクトリーに配置してみる。ライブラリーを加えていないので、インストールはcomposer.pharを移動して配置するのみ。

まずcomposer_testディレクトリーを作ってその下にcomposer.pharを移動。また、先にドキュメントルートに作ったプロジェクトを削除しておく。

移動先でcomposerの動作確認。

プロジェクトの作成

composer_testディレクトリー下に先と同じ手順でプロジェクトを作成。

公開ディレクトリーへのシンボリックリンク

公開ディレクトリー以外に配置したプロジェクトは、クライアントからは認識されない。そこでプロジェクトのpublicディレクトリーのシンボリックリンクをドキュメントルート下に作成する。

ここではシンボリックリンク名をプロジェクト名と同じ名前にして、~/wwwディレクトリー下に作成。

この状態で以下のURLを指定するとwelcomeページが表示される。

コントローラー・ビュー

新しいプロジェクトでTestControllerコントローラーを作成。

ビューを呼び出すアクションを定義。

ルーティングを定義。

resources/views/ディレクトリーにtest.blade.phpファイルを以下の内容で作成。

これでブラウザーにアクセスすると、タブのタイトルが'Laravel Test'となり、h1要素のフォントで'Hello from blade!'と表示される。

Laravelのバージョン指定

composerでプロジェクトを作成するときにLaravelのバージョン指定が可能だが、さくらサーバーでワイルドカードを使うとうまくいかない。

以下のようにワイルドカードを指定しない方法だと、無事にプロジェクトが作成される。

バージョン確認。

プロジェクトの設定

タイムゾーンとロケールをconfig/app.phpファイルで設定。

データベースはさくらサーバーの設定に従って、.envファイルで設定。DB_HOSTはmysql5.7アップグレード後の場合、phpMyAdminなどで使われるサーバー名。

 

Laravel – クエリービルダーでのエイリアス

概要

SQLではフィールド名やテーブル名のエイリアスを定義できるが、同じことがクエリービルダーでもできる。

  • フィールド名のエイリアスは、select()メソッドのフィールド名の引数にそのままASを書く
  • JOINされるテーブルのエイリアスはjoin()メソッドのテーブル名の引数にそのままASを書く
  • 親テーブルのエイリアスはfrom()メソッドの引数で指定する

SQLの記述

元のSQLとして以下を使う。

このSQLでフィールド名とテーブル名のエイリアスを以下のように定義する。これと同じことをクエリービルダーで書いていく。

クエリービルダーの記述

オリジナル

元のSQLに対応するクエリービルダーは以下のとおり。

フィールド名のエイリアス

フィールド名のエイリアスは、select()メソッドのフィールド名の引数にas aliasで定義。

JOINされるテーブルのエイリアス

親テーブルに結合される子テーブルのエイリアスは、join()メソッドのテーブルを指定する引数(第1引数)でas aliasを指定する。

親テーブルのエイリアス

親テーブルのエイリアスは、最初にfrom()メソッドを呼んでその引数で指定する。select()メソッドはメソッドチェーンで繋げる。

 

MySQL – データベースの複製

mysqldumpによる方法

元のデータベースのダンプファイルを作成。

MySQLで新データベースを作成。またはOSのコマンドラインからmysqladminで新データベースを作成。

ダンプファイルの内容を新データベースに再現

 

Linux – find

名前を指定して検索

特定の名前のファイル・ディレクトリーを探す。

  • -nameオプションに続けて”名前”で検索
  • 大文字/小文字が区別される(case sensitive)

大文字・小文字を問わず名前を指定して検索する場合は、-inameを指定する(case insensitive)。

この場合"SEARCH_NAME""Search_Name"などもヒットする。

種類を指定して検索

-type 形式コードを指定。以下はファイルのみを検索する例。

主な形式コードは以下のとおり。

  • -type f:ファイルを検索
  • -type d:ディレクトリーを検索
  • -type l:シンボリックリンクを検索

ワイルドカード

'*'は任意長の文字列。以下の例では'.conf'で終わるファイルがヒット。

'?'は任意の1文字にヒット。以下の例では'*'と組み合わせていて、'loc'に3文字が続き、任意の拡張子を持つファイルが検索される。

たとえば以下のようなファイルがヒットする。

  • locale.rb
  • locker.c
  • locker.js
  • lock-i.ri

サイズ指定

-sizeオプションにサイズ、単位、以上/未満の符号をつけて検索する。

-size [符号なし/+/-]数値[c/k/M/G/b]

単位記号

  • c:bytes
  • k:K bytes
  • M:M bytes
  • G:G bytes

前置符号

  • 符号なし:指定サイズに等しいファイル
  • +:指定サイズ以上のファイル
  • -:指定サイズ未満のファイル

以下の例では100キロバイトちょうどのファイルがヒットする。

以下の例では10Mバイト以上のファイルがヒットする。

以下の例では10Kバイト未満のファイルがヒットする。

-sizeの組み合わせが可能で、以下の例では10Mバイト以上、15Mバイト未満のファイルがヒットする。

時刻指定

時刻の種類には以下の三種類がある。

  • Access Time: ファイルに最後にアクセスがあった時刻
  • Modification Time: ファイル内容が最後に変更された時刻
  • Change Time: ファイルの状態(inodeデータ)が最後に変更された時刻

3つの時刻に対して、指定する数値が日単位か分単位かでオプション名が変わる。

  • 日単位:-atime, -mitime, -ctime
  • 分単位:-amin, -mmin, -cmin

各オプションに、時間の数値と前置符号を指定する。

  • -atime/-mtime/-ctime [符号なし/+/-]日数
  • -amin/-mmin/-cmin [符号なし/+/-]分数

前置符号

  • 符号なし:その時刻前、たとえば
    • -atime 3 → 3日前にアクセス
  • -:その時刻以内、たとえば
    • -mtyme -3 → 変更されたのが3日前以内
  • +:その時刻以上経過、たとえば
    • -ctyme +3 → 変更されて以降3日以上経過

 

さくらサーバー – MySQLのアップグレード

概要

2021年11月、さくらインターネットのカスタマーセンターよりメールがあり、内容はMySQL5.1, 5.5から5.7へのアップグレードを推奨するものだった。5.5のサポート終了やWordPressなどCMSの推奨環境のバージョンアップなどの背景によるもの。

私の環境はさくらレンタルサーバーのスタンダードプラン。後述の経緯もあって少しとまどったが、アップグレードとWordPressの設定を終えた。

状況としては、

  • MySQL5.5と並んで、既にMySQL5.7が稼働していた
  • WordPressで使っていたのはMySQL5.5の方

手順の概要は

  1. 5.7のWordPress用データベースを削除
  2. 5.5のWordPress用データベース以外を削除
  3. アップグレード予約・実行
  4. wp-config.php書き換え

経緯

今回の経緯は以下のとおり。

  1. 2016年、さくらレンタルサーバー(スタンダードプラン)の利用開始
    • このときにMySQL、WordPressも運用開始
  2. その後2021年6月までの間に5.5→5.7へアップグレード
    • アップグレード後も5.5は存続
    • このときにWordPressの設定は変更せず
    • このため、これ以降も投稿等は5.5の方に記録
  3. 2021年11月に5.7へのアップグレード推奨メール
  4. 2021年12月に再度アップグレードとWordPress設定変更完了

確認作業

データベース構成

メールを受けてさくらサーバーのコントロールパネルで確認したところ、以下の2つのデータベース(以下、DB)が存在。

  • mysql57.アカウント名.sakura.ne.jp→MySQL5.7
    (mysql2019.db.sakura.ne.jp)
    →システムの管理で使われるホスト名
  • mysql304.db.sakura.ne.jp→MySQL5.5

5.5のデータベースは以下のとおり。

  • information_schemaはMySQLの管理用
  • _wp1はWordPress用のDB
  • _main_testの2つはテスト用に自分で作成したもので、特に重要ではない

5.7のデータベースは以下のとおり。こちらにもWordPress用の_wp1があり、他のDBも5.5と同じ。

WordPress用データベース

MySQL5.5、5.7ともアカウント名_wp1のテーブル構成は同じで、以下のとおり。

ここで、5.5と5.7でwp_ts01_postsに以下のような違いがあった。

5.5の投稿数。投稿日付は2016年6月16日~2021年12月13日で確認時点の日付まで。

5.7の投稿数。2016年6月16日~2021年2月8日まで。

5.5に対して5.7の投稿数が少なく、途中までの投稿記録で途切れている。

wp-config.phpのMySQLホスト名を確認すると、以下のようにMySQL5.5の方のホスト名になっていて、MySQL5.7運用開始後もWordPressは5.5を使っている。

したがってMySQL5.7運用開始後もWordPressでは利用されず、投稿等は5.5の方に記録されていることになる。このことから5.7のWordPress用データベースを破棄して5.5のデータベースに入れ替え、設定変更することにする。

アップグレード

要点

アップグレードの要点は、さくらインターネットのサイトによると以下のとおり。

  • MySQLの5.5→5.7へのアップグレードは、既に5.7が存在していても可能
  • アップグレード先の5.7に5.5と同じ名前のDBが存在する場合はアップグレード不可
  • アップグレードはDBを指定して実行時間を予約
  • アップグレード後にWordPress等の設定変更が必要

データベースの整理方針

5.5のデータベースをアカウント名_wp1のみ残して削除し、アップグレード先の5.7の同じ名前のDBを削除。

  • 5.5の他のデータベースは自分で作成したテスト用のものだけなので、削除しても問題ない
  • 5.7のアカウント名_wp1は途中までしか投稿記録がなく、不要と判断
  • 双方のinformation_schemaは残置

アップグレードの予約

アップグレードの予約はコントロールパネルで行った。

  • さくらのコントロールパネルで
    • 5.7のアカウント名_wp1を削除
    • 5.5のアカウント名_wp1以外を削除
  • information_schemaはコントロールパネルでは表示されないが5.5、5.7とも残置
  • 12/21の02時にアップグレード予約

アップグレードの確認

翌朝確認したところ、MySQL5.7の方にアカウント名_wp1が作成されており、コンソールで確認したところ昨日までの最新の投稿が記録されていた。

コメントが2件、2時以降についていたが、いずれもspam判定のもので、内容も確認して無視。

WordPressの設定変更

コンソールでも可能だが、さくらインターネットサイトにあるとおりファイルマネージャーで実行。

  1. コントロールパネル左の”Webサイト/データ”→”インストール済み一覧”を選択して、でWordPressのインストール先を確認
  2. “Webサイト/データ”→”ファイルマネージャー”を開いて上記のディレクトリーに移動
  3. wp-config.phpを確認
  4. コンソールでwp-config.phpのコピーを別名で保存(バックアップ用)
  5. ファイルマネージャーでwp-config.phpを右クリック→編集
    • MySQLのホスト名の変更
    • DB名は同じ名前なので変更しない
    • パスワードも変更していないのでそのまま
  6. ファイルマネージャーで”保存”、”閉じる”

WordPressの設定後確認

設定変更後、以下を確認した。

  • WordPressが正常に表示される
  • 新規投稿を書き込み、投稿が反映されること、その内容がMySQLのDBのテーブルに反映されていることを確認
  • 新規投稿を削除し、削除が反映され、テーブルにも削除経緯が反映されることを確認

 

Laravel – Collection – 先頭・末尾などの例外処理

コールバックを用いるメソッドで、コールバック内で先頭要素や末尾要素に応じた処理をしたい場合、クロージャ―のuseを使う。ただしこの方法は、全要素に対して先頭・末尾などの判定処理が行われる。

以下の例ではコレクションの要素を並べた1つの文字列を返すが、文字列の最初に'('、最後に')'を付加し、要素間には','を置いている。

要点は以下のとおり。

  • クロージャ―のuseで呼び出し元のコレクションインスタンスを指定
  • クロージャ―内でコレクションインスタンスの先頭要素/末尾要素に等しいかどうかを判定し、それらに応じた処理を実行

 

Laravel – Collection – グルーピングと集計

概要

LaravelCollectionには、count()sum()などの集計用メソッドが準備されている。groupBy()メソッドも準備されているが、これはグルーピングされたキー列の値で配列をまとめるだけなので、直接groupBy()の結果をcount()などに適用することはできない。

たとえば以下のようなコレクションがあって、

groupBy()によってgenderでグルーピングすると以下のようなコレクションが得られる。

この結果を単にcount()メソッドに渡すと、malefemaleの2つのグループあることから、グループ数に対応する'2'が返される。

これを、male/female各グループの要素数をカウントしたり、グループごとの身長の集計値を出したりするようにしたい。

map()メソッドの利用したグループ処理

map()メソッドはコールバックを引数にとり、そのコールバックの引数には元のコレクションの各要素が順次与えられる。

たとえば先のグルーピングの結果をmap()メソッドに渡すと、2つの要素malefemale(その中身は連想配列の配列)が順次与えられる。これらグループ化された配列に対して、Collectionの集計メソッドを使うことができる。

この場合、グループ化された1つ目のグループの各要素に関する処理、2つ目のグループの各要素に関する処理・・・と実行される。

集計例

count()の例

性別ごとの人数をカウントする例。

average()の例

性別ごとの平均身長を計算する例。