Kubernetesとは

Kubernetesとは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースのプラットフォームです。

参考：https://kubernetes.io/ja/docs/concepts/overview/what-is-kubernetes/

Composeのように単一のDockerホスト上でコンテナ群を動かすのではなく、冗長性を得るため複数のホストを束ねてクラスタを構築し、その上で冗長化されたコンテナを動かします。

このようにKubernetesの登場により、複数のDockerなどのコンテナの管理や自動化が進み、この仕組みは「コンテナオーケストレーション」と呼ばれています。

サッカーの例えがわかりやすい

といってもなかなかイメージがつかないところ、Docker/Kubernetes超入門という本でKubernetsをサッカーで例えており、わかりやすくイメージしやすくなりました。

サッカーで例えるとコンテナが選手だとすると、Kubernetesは監督にあたります。グラウンドの正しい位置に選手(コンテナ)を配置し、チーム(アプリ)として連携を取れる形を作ります。

それだけでなく、怪我した選手(調子の悪いコンテナ)の交代や選手(コンテナ)をを減らしたり増やしたり(これはサッカーのルールから外れるが。。)などの仕事をします。

エンジニアはチームオーナーとして監督(Kubernetes)に「こういう方針でいきます」と頼んでおけばあとは任せておけるといった感じです。

Kubernetesの構成

参考：Docker/Kubernetes超入門

Kubernetesの構成は主に図の左側のコントロールプレーンと右側のデータプレーンにわかれます。大まかな担当は左側のマスターノードが頭脳として使われ、右側のワーカーノードは処理する肉体として使われます。

また、Kubernetesでシステムを構築する場合は、Kubernetes上だけで構築するのではなく右の図にある仮想マシンやクラウドが提供するマネージドサービスなども併用して開発するのが一般的です。

サービスやポッドのところは実際に動かしながら理解を深めていきます。

実際に触ってみる

というわけで実際にKubernetesを触っていきます。Docker Desktopが既にインストールされていれば環境設定から「Enable Kubernetes」にチェックを入れて有効化するだけで使えます。

マニフェストファイルを使ってNginxを動かす

Kubernetesのアプリ展開はマニフェストファイルと呼ばれる構成ファイルで行われるのが一般的です。今回はDocker/Kubernetes超入門の本を参考にポッドのマニフェストとそれを外部に公開するサービスのマニフェストを使ってNginxを展開します。

マニフェストファイルはYAML形式で記述します。それぞれの意味は以下のようになっています。

• apiVersion: マニフェストのバージョン
• kind: リソースの種類
• metadata: リソース名などのメタデータ
• spec: リソースの詳細

・pod.yml

apiVersion: v1
kind: Pod
metadata:
  name: web-pod
  labels: 
    svc2pod: web
spec:
  containers:
  - name: nginx
    image: nginx:1.17.6-alpine
    ports:
    - name: http
      containerPort: 80

サービスのマニフェストも上の部分はポッドと同じですが、重要なのはspecの下にある「selector」で、これを使ってサービスが接続するポッドを指定します。

先程ポッドのマニフェストで定義した「svc2pod: web」を指定し、このサービスの接続先を定義します。

selectorの下の「ports」は外部に公開するポートと接続先のポートを指定しています。portがKubernetes内部から接続で利用するポートでnodePortがホスト外から接続で利用するポートです。

・service.yml

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    svc2pod: web
  ports:
  - port: 80
    targetPort: http
    nodePort: 30000
  type: NodePort

リソースを展開する

作成したマニフェストファイルを元にリソースを展開していきます。展開コマンドでは「kubectl apply -f」コマンドを使うのが一般的です

$ kubectl apply -f pod.yml
pod/web-pod created

$ kubectl apply -f service.yml
service/web-service created

サービスリソースを確認するとweb-serviceが立ち上がっていることが確認できます。

$ kubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
web-service NodePort 10.99.80.170 <none> 80:30000/TCP 67s

nodePortで指定したポートを指定し、http://127.0.0.1:30000/にアクセスするとNginxのページを見ることができます。

デプロイメントを試してみる

実際の運用ではポッドを機能拡張したデプロイメントというリソースを使うことが一般的なようなため、実際に動かして試してみます。

デプロイメントは内部に下位リソースとしてレプリカセットというリソースを持ち、それが水平スケールや自動復旧機能を担当します。デプロイメントの主要機能としては、ポッドのアップグレードで、バージョンアップなど発生した際に古いポッドを入れ替えてくれます。

Docker/Kubernetes超入門の本を参考に動かしてみます。

spec.replicasフィールドで指定された通り、5つのレプリカPodを作成します。

spec.strategy.rollingUpdateフィールドでPodの数を指定した個数ずつ増減させてアップデートしていきます。

spec.strategy.typeにRollingUpdateと指定し、spec.strategy.rollingUpdateにmaxSurgeとmaxUnavailableを指定します。

• maxSurge: replicasで指定した数よりも増やしていい最大Pod数(デフォルト値25%・絶対値 or %を設定)
• maxUnavailable: replicasで指定した数よりも減らしていい最大Pod数(デフォルト値25%・絶対値 or %を設定)

・db.yml

apiVersion: v1
kind: Service
metadata:
  name: db
spec:
  selector:
    pod: db
  ports:
  - port: 6379
    targetPort: redis
  type: ClusterIP

---
apiVersion: v1
kind: Pod
metadata:
  name: db
  labels: 
    pod: db
spec:
  containers:
  - name: db
    image: redis:5.0.6-alpine3.10
    ports:
    - name: redis
      containerPort: 6379

・app.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  replicas: 5
  strategy:
    rollingUpdate:
      maxSurge: 50%
      maxUnavailable: 0%
  selector:
    matchLabels:
      pod: app
  template:
    metadata:
      name: app
      labels: 
        pod: app
    spec:
      containers:
      - name: app
        image: sample/app
        ports:
        - name: http
          containerPort: 80
        env:
        - name: REDIS_HOST
          value: db

---
apiVersion: v1
kind: Service
metadata:
  name: app
spec:
  selector:
    pod: app
  ports:
  - port: 8080
    targetPort: http
    nodePort: 30000
  type: NodePort

kubectl applyで展開し、ポッドを確認すると5つ起動していることが確認できます。

$ kubectl apply -f app.yml -f db.yml 
deployment.apps/app created
service/app created
service/db created
pod/db created
$ kubectl get po
NAME READY STATUS RESTARTS AGE
app-975c58898-7rzxk 1/1 Running 0 6m18s
app-975c58898-clwxx 1/1 Running 0 6m18s
app-975c58898-lqfdl 1/1 Running 0 6m18s
app-975c58898-r64gw 1/1 Running 0 6m18s
app-975c58898-s6jl4 1/1 Running 0 6m18s
db 1/1 Running 0 12m

$ kubectl get replicaset
NAME DESIRED CURRENT READY AGE
app-975c58898 5 5 5 6m

デプロイメントの詳細情報は以下のコマンドで取得できます。

$ kubectl describe deployment app
Name:                   app
Namespace:              default
CreationTimestamp:      Sun, 14 Nov 2021 07:15:16 +0900
Labels:                 <none>
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               pod=app
Replicas:               5 desired | 5 updated | 5 total | 5 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  0% max unavailable, 50% max surge
Pod Template:
  Labels:  pod=app
  Containers:
   app:
    Image:      sample/app
    Port:       80/TCP
    Host Port:  0/TCP
    Environment:
      REDIS_HOST:  db
    Mounts:        <none>
  Volumes:         <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   app-975c58898 (5/5 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  17m   deployment-controller  Scaled up replica set app-975c58898 to 5

参考：外部アプリケーションから Cloud SQL に接続する | Cloud SQL for MySQL

前提条件

Cloud SQLをローカルのクライアントツールに接続する前提として以下が当てはまっていることが条件です。

• Cloud SQL AdminAPIが有効化されていること
• Cloud SQLのインスタンスが作成されていること
• Cloud SQLにDB・ユーザが作成されていること

プロキシクライアントのインストール

ローカルから認証に必要なプロキシクライアントをインストールします。

Macの場合は以下のコマンドでダウンロードします。他のOSからのコマンドは以下の公式を参考にしてください。

参考：ローカルマシンにプロキシ クライアントをインストールする

$ curl -o cloud_sql_proxy https://dl.google.com/cloudsql/cloud_sql_proxy.darwin.amd64

プロキシの実行権限を付与します。

$ chmod +x cloud_sql_proxy

サービスアカウントの作成

次にローカルからCloud SQLに接続する際に、認証で必要となるサービスアカウントを作成します。

GCPの「IAMと管理」からサービスアカウントを選択します。「サービスアカウントを作成」を押下します。

以下の項目を入力し、作成を押下します。

• サービスアカウント名
• サービスアカウントID
• サービスアカウントの説明

役割は「Cloud SQL クライアント」を選択し、続行を押下します。

「キーを作成」を押下します。

キーのタイプは「JSON」を選択し、作成を押下します。すると認証ファイルがダウンロードされるので、保存します。今回は、sample-key.jsonというファイル名で保存します。

プロキシの起動

先ほどインストールしたプロキシを起動します。

• instances : インスタンス接続名
• tcp : 13306
• credential_file : 先ほど保存した認証ファイル

$ ./cloud_sql_proxy -instances=<インスタンス接続名>=tcp:13306 -credential_file=sample-key.json

起動し以下のように「Ready for new connections」が表示され、正常に起動できていることを確認します。

2020/03/10 19:56:57 using credential file for authentication; email=sample@<project_id>.iam.gserviceaccount.com
2020/03/10 19:56:58 Listening on 127.0.0.1:13306 for <インスタンス接続名>
2020/03/10 19:56:58 Ready for new connections

DBeaverに接続

いよいよDBeaver(クライアントツール)に接続します。

以下を入力して接続完了です。

• Server Host : ローカルループバックアドレス
• Port : 先ほど指定したポート
• Database : Cloud SQLで作成したDB名
• User name : Cloud SQLで作成したユーザ名
• Password : Cloud SQLで作成したユーザのパスワード

接続時に「Communications link failure」エラー

最後のクライアントからの接続時に以下のエラーでハマりました。

Communications link failure
The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.
Can not read response from server. Expected to read 4 bytes, read 0 bytes before connection was unexpectedly lost.

ログを確認すると以下のエラーが表示されていました。調べてみるとどうやら接続の問題のようですが、特に問題なさそう。

[Note] Aborted connection xxx to db: 'sample' user: 'sample' host: 'cloudsqlproxy~xxxxx' (Got an error reading communication packets)

タイムアウトやbuffer_sizeを増やしたり、あれこれ設定を変更するが解決できず。。

結局、原因は会社で使用しているWiFiでした。試しにWiFiをオフにして、テザリングを使ってみると、問題なく接続できました。

基本的には以下の公式を参考に環境構築しています。

• Running Rails 5 on App Engine flexible environment | Ruby
• Using Cloud SQL for MySQL with Rails 5 | Ruby

前提条件

デプロイするRailsプロジェクトが以下に当てはまっていることが前提条件です。

• Ruby バージョン2.3.4以降をインストール
• Rails 5 gem をインストール
• Bundler gem をインストール

必要なAPIを有効化

データストア、Pub / Sub、Cloud Storage JSON、Stackdriver Logging、およびGoogle+必要なAPIを有効にします。

app.yamlの作成

GAEにデプロイするRailsアプリのディレクトリ直下にapp.yamlを作成します。

今回はスタンダード環境なので「env: flex」はコメントアウトしておきます。またapp.yamlに環境変数を書くことでGAEに環境変数を渡せます。

secret keyは以下のコマンドで確認できます。

$ bundle exec rails secret

・app.yaml

entrypoint: bundle exec rackup --port $PORT
runtime: ruby25
# env: flex
env_variables:
    SECRET_KEY_BASE: < Your secret key>

GAEにデプロイしたアプリはDocker上で動くためDockerfileがプロジェクト直下にあるとruntime rubyでデプロイができません。

runtime rubyでデプロイする場合は、DockerfileをDockerfile-devなどに置き換えておきましょう。

.gcloudignoreの作成

デプロイしないファイルを指定するために.gcloudignoreファイルを作成します。

・.gcloudignore

.gcloudignore
#!include:.gitignore
.git
.gitignore

!/public/assets

MySQL用Cloud SQLをセットアップ

RailsアプリでCloud SQLを使用するために、mysql2とappenginegemをGemfileファイルに追加します

$ bundle add mysql2
$ bundle add appengine

以下のコマンドでインスタンス接続名を取得できます。
gcloud sql instances describe < インスタンス名 >

・database.yml

production:
    adapter: mysql2
    encoding: utf8
    pool: 5
    timeout: 5000
    username: < username >
    password: < password >
    database: < database >
    socket: /cloudsql/< インスタンス接続名 >

GAEにデプロイ

以下のコマンドで、GAEアプリを作成します。

$ gcloud app create

デプロイする前に、Railsアセットをプリコンパイルします。

$ bundle exec bin/rails assets:precompile

アセットのコンパイルが完了したらGAEにデプロイします。

$ gcloud app deploy

マイグレーションでテーブル作成

以下のコマンドでプロジェクトを一覧表示できます。アプリのデプロイに使用するプロジェクトを見つけ、プロジェクト番号をコピーします。

$ gcloud projects list

roles/editorデータベース移行を実行するロールのプロジェクトIAMポリシーに新しいメンバーを追加します。

$ gcloud projects add-iam-policy-binding < YOUR-PROJECT-ID > --member=serviceAccount: < PROJECT_NUMBER > @cloudbuild.gserviceaccount.com --role=roles/editor

先ほど追加したappengineを使用して、Cloud SQL上でのマイグレーションを実行します。

$ bundle exec rake appengine:exec -- bundle exec rake db:migrate

Cloud SQL画面の「Cloud Shellを使用して接続」から以下のコマンドで接続し、実際にテーブルが作成されたか確認してみましょう。

$ gcloud sql connect < インスタンス名 > --user=< username > --quiet

以降のデプロイ

以降、ソースを更新して再度デプロイする場合は以下のコマンドで実行する流れになります。

$ bundle exec bin/rails assets:precompile
$ gcloud app deploy
$ bundle exec rake appengine:exec -- bundle exec rake db:migrate

ハマりポイント

① コンパイル時にエラー

コンパイル時に以下のエラーが発生。

Note: Google::Cloud::Logging is disabled because it failed to authorize with the service.
Note: Google::Cloud::Debugger is disabled because it failed to authorize with the service.
Note: Google::Cloud::ErrorReporting is disabled because it failed to authorize with the service.
Note: Google::Cloud::Trace is disabled because it failed to authorize with the service.

develop環境では使用しないようfalseにすることで解決しました。

・development.rb

config.google_cloud.use_logging = false
config.google_cloud.use_debugger = false
config.google_cloud.use_error_reporting = false
config.google_cloud.use_trace = false

② MySQLに接続できない

以下のエラーによりCloud SQLのMySQLに接続できずハマり。。

[STDERR] rake aborted!
[STDERR] Mysql2::Error::ConnectionError: Unknown MySQL server host '/cloudsql/< インスタンス接続名 >' (2)

公式ではdatabase.yamlの「/cloudsql/< インスタンス接続名 >」の箇所がhostとなっていたため、hostで書いていたのですが、socketに変更することで解決しました。。

参考：

ruby-docs-samples/appengine/rails-cloudsql-postgres/config/database.yml at 0a6e898a1acd140ca04c63c7b68da1468acb4082 · GoogleCloudPlatform/ruby-docs-samples · GitHub

Ruby samples for Google Cloud Platform p…

github.com

・修正前

production:
    adapter: mysql2
    encoding: utf8
    pool: 5
    timeout: 5000
    username: < username >
    password: < password >
    database: < database >
    host: /cloudsql/< インスタンス接続名 >

・修正後

production:
    adapter: mysql2
    encoding: utf8
    pool: 5
    timeout: 5000
    username: < username >
    password: < password >
    database: < database >
    socket: /cloudsql/< インスタンス接続名 >

③ GAEのデフォルトTime Outが10分なためSeedが完了しない

GAEのデフォルトタイムアウトが10mのため、Seedが完了せず途中で終了してしまう。。

TIMEOUT: 10m

GAE_TIMEOUTオプションでタイムアウトを伸ばすことができました。1h23m45sの形式で指定できます。

bundle exec rake appengine:exec GAE_TIMEOUT=30m -- bundle exec rake db:seed

参考：

How to set the value of timeout? · Issue #26 · GoogleCloudPlatform/appengine-ruby · GitHub

Could not find this documented anywhere …

github.com

以上、Google App EngineのRuby 2.5 StandardでRails環境構築する方法とCloud SQLのMySQLとの接続方法でした。

ERROR: Operation Denied. Signature expired: 20190204T011910Z is now earlier than 20190204T012127Z (20190204T012627Z - 5 min.)

調べたところ、サーバの時刻を定期的に同期させる必要があるとのこと。

そこでntpdateコマンドを使い、以下のコマンドでNTPサーバから時刻を合わせました。

NTPがインストールされていなかっため、インストールしてから実行

$ yum -y install ntpdate

$ ntpdate clock.nc.fukuoka-u.ac.jp
4 Feb 01:33:39 ntpdate[17044]: step time server 133.100.9.2 offset 437.076330 sec

無事エラーが消えて解決しました。

参考：

amazon web services - Signature expired: is now earlier than error : InvalidSignatureException - Stack Overflow

I am trying a small example with AWS API…

stackoverflow.com

実行環境

• Vagrant 1.8.1
• CentOS 7.1
• Ruby 2.5.0
• Rails 5.2.1

以下の記事を参考に、Railsプロジェクト作成後にMySQLを入れる。

RailsのDBを(初めから| |後から)MySQLに変更する

・Gemfile

Gemfileに以下を追記

gem 'mysql2'

・/config/database.yml

developmentの箇所を以下に修正

development:
adapter: mysql2
encoding: utf8
database: rails_tutorial
pool: 5
username: root
password: 
host: localhost

bundle installでmysql2インストール時にエラー

バンドラーインストール実行。

$ bundle install --without production

…
--without-mysql-lib=${mysql-dir}/lib
--with-mysqlclientlib
--without-mysqlclientlib

To see why this extension failed to compile, please check the mkmf.log which can

be found here:

/usr/local/rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/extensions/x86_64-linux/2.5.
0-static/mysql2-0.5.2/mkmf.log

extconf failed, exit code 1

Gem files will remain installed in
/usr/local/rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/mysql2-0.5.2 for
inspection.
Results logged to
/usr/local/rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/extensions/x86_64-linux/2.5.
0-static/mysql2-0.5.2/gem_make.out

An error occurred while installing mysql2 (0.5.2), and Bundler cannot
continue.
Make sure that `gem install mysql2 -v '0.5.2' --source 'https://rubygems.org/'`
succeeds before bundling.

In Gemfile:
mysql2

するも、エラー。言われたとおりに「gem install mysql2 -v ‘0.5.2’」をインストールしてみるもダメみたい。

$ gem install mysql2 -v '0.5.2'

Building native extensions. This could take a while...
ERROR: Error installing mysql2:
ERROR: Failed to build gem native extension.

bundle installでmysql2インストール時にエラーした時の対処法

mysql-develをインストールしてみましょう。

$ sudo yum install mysql-devel

Installed:
mariadb-devel.x86_64 1:5.5.60-1.el7_5

Dependency Updated:
mariadb-libs.x86_64 1:5.5.60-1.el7_5

Complete!

mysql-develインストール後、再度トライしたらいけました。

$ bundle install --without production

・XAMPP

https://www.apachefriends.org/jp/index.html

・Visual Studio Code

https://code.visualstudio.com/

Visual Studio CodeでPHPデバッグができるまでの流れ

大体以下のような流れ。

1. Xdebugのインストール(既にある場合は不要)
2. XdebugをXAMPP内に配置
3. php.iniにXdebugの情報を追記
4. Visual Studio Codeに「PHP Debug」をインストール
5. 「PHP Debug」にデバッグ設定

Xdebugのインストール

phpinfo()で出力された情報を全てコピーし、以下のサイトのテキストエリアに貼り付けると、スムーズにインストールすることができる。

Windowsの場合は、.dllをインストールして、\xampp\php\extに配置すればok。ただ大体の場合は元々\xampp\php\extに存在しているため、わざわざインストールする必要はないかも。

https://xdebug.org/wizard.php

php.iniの編集

php.iniにインストールしたXdebugの情報を追記。今回はXAMPPのApache使用のため、9000番ポートはコメントアウトしてます。

C:\xampp\php\php.ini

[XDebug]
zend_extension = "C:\xampp\php\ext\php_xdebug.dll"
xdebug.remote_enable=1
xdebug.remote_host=localhost
; xdebug.remote_port=9000
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_autostart=true

追記したら、phpinfo()でXdebugが記載されていることを確認します。

プラグインをインストール

拡張機能「PHP Debug」をインストールします。

「PHP Debug」にデバッグ設定

インストール完了後、画面左のツールバーから虫のアイコンを選択。画面上部にある歯車アイコンを選択し、PHPをクリック。

するとlaunch.jsonファイルが生成されるため、以下のように追記しました。先ほどのphp.iniに9000番ポートを指定した場合は、80→9000に読み替えてください。

・launch.json

{
"version": "0.2.0",
"configurations": [
    {
      "name": "Custom Xdebug setting",
      "type": "php",
      "request": "launch",
      "port": 80,
      "serverSourceRoot": "${workspaceRoot}",
      "localSourceRoot": "${workspaceRoot}"
    },
  ]
}

あとはブレークポイント設定し、構成の名前を指定してデバッグを実行するだけ。なのに結構ハマってしまった…。

実行環境

実行環境は以下の通り。Apacheは既に起動し、MySQLの設定が完了した前提。

• Window7(ホスト)
• VirtualBox5.0.16
• Vagrant1.9.6
• CentOS7(ゲスト)
• FuelPHP 1.7.2
• PHP 7.0.31
• MySQL 5.6.40
• Apache 2.4.6t

db.phpの編集

ローカルで開発しているFuelPHPプロジェクトとMySQLを接続するための設定を行う。作成したデータベースやMySQLユーザの情報を以下のように記述する。

・fuel\app\config\development\db.php

<?php

return array(
 'default' => array(
  'connection' => array(
   'dsn' => 'mysql:host=localhost;dbname=fuel_dev',
   'username' => 'root',
   'password' => 'root',
  ),
 ),
);

$ systemctl restart httpd.service

Apacheを再起動し、アプリケーションを動かしてみるもエラー。

「PDOException: could not find driver」エラーと対処法

早速ログを確認してみると「PDOException: could not find driver」で、ドライバーが見つからないとのこと。

C:\sample\fuel\app\logs\
ERROR - 2018-07-24 09:11:39 --> PDOException: could not find driver in /sample/fuel/core/classes/database/pdo/connection.php:96

FulePHPプロジェクトのindex.php上部に以下を書き込み、PHPの環境設定情報を表示する。

・index.php

<?php
echo phpinfo();exit;

再起動して、あらためてブラウザで開くとPHPの環境設定情報が表示される。

案の定PDO driversに「mysql」がなかったため、こちらを参考にphp-mysqlndを入れた。

参考：PHP7+Nginx+MariaDBでPDO接続したとき”could not find driver”が出た際にやったこと

php-mysqlndをインストール

$ yum install --enablerepo=remi-php70 php-mysqlnd

正常にインストールされたか確認

$ yum list installed | grep mysqlnd
php-mysqlnd.x86_64 7.0.31-1.el7.remi @remi-php70

php-fpmとApacheを再起動

$ systemctl restart php-fpm
$ systemctl restart httpd.service

PDO driversに「mysql」入っていることを確認し、再度開くと無事接続されました。

Vagrant+VirtualBoxで仮想サーバを立ち上げ、CentOS7環境を構築。Apacheをインストールし、ローカルのFuelPHPプロジェクトを動かすまでの手順メモ。

実行環境

実行環境は以下の通り。

VagrantでCentOS環境を構築した前提。

• Window7(ホスト)
• VirtualBox5.0.16
• Vagrant1.9.6
• CentOS7(ゲスト)

Apacheのインストール

-yオプションで実行することで、インストール時の応答確認を省略。

$ yum -y install httpd

バージョン確認

$ httpd -v
Server version: Apache/2.4.6 (CentOS)

Apacheの起動

ちゃんと起動しているか確認。

$ systemctl start httpd.service
$ systemctl status httpd.service
● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor prese
Active: active (running) since
Docs: man:httpd(8)
man:apachectl(8)
Process: 13928 ExecStop=/bin/kill -WINCH ${MAINPID} (code=exited, status=1/FAI LURE)
Main PID: 13958 (httpd)
Status: "Processing requests..."
Memory: 8.1M
CGroup: /system.slice/httpd.service
tq13958 /usr/sbin/httpd -DFOREGROUND
tq13959 /usr/sbin/httpd -DFOREGROUND
tq13960 /usr/sbin/httpd -DFOREGROUND
tq13961 /usr/sbin/httpd -DFOREGROUND
tq13962 /usr/sbin/httpd -DFOREGROUND
mq13963 /usr/sbin/httpd -DFOREGROUND

ファイアウォールの設定

firewall-cmdコマンドで80番ポートに外部からの接続許可できる設定を追加。設定を反映するために再読み込みします。

$ firewall-cmd --add-service=http --permanent
success
$ firewall-cmd --reload
success

ファイアウォールの設定が完了したら以下のコマンドで確認。

$ firewall-cmd --list-all
public (default, active)
interfaces: enp0s3
sources:
services: dhcpv6-client http ssh
ports:
masquerade: no
forward-ports:
icmp-blocks:
rich rules:

Apacheの設定ファイルの編集

Apacheの設定ファイルにFuelPHPプロジェクトが動くよう編集します。

FuelPHPプロジェクトはローカルにマウントするよう、あらかじめVagrantfileに記述してから起動する必要があるため、忘れていた方はこちらを参考に。

・Vagrantfile

# "ホストPCのFuelPHPプロジェクト格納場所", "ゲストPCのFuelPHPプロジェクト格納場所"
config.vm.synced_folder "C:/sample", "/sample"

Apacheの設定ファイルの編集。

$ vi /etc/httpd/conf/httpd.conf
<VirtualHost *:80>
DocumentRoot /sample/public #FuelPHPプロジェクトのパス指定
<Directory "/sample/public">
 Order allow,deny
 Allow from all
 DirectoryIndex index.php
</Directory>
</VirtualHost>

「client denied by server configuration」エラーと対処法

Apacheを再起動して動かしてみるも、エラー。tailコマンドでエラーログを確認する。

$ tail -f /var/log/httpd/error_log
AH01630: client denied by server configuration

クライアント側がサーバの設定によって拒否されていることがわかった。

調べてみると、Apache2.4からディレクティブの書き方が変わったみたい。

ということで、

• Order allow,deny
• Allow from all

の部分を

• Require all granted

に書き換えました。

<VirtualHost *:80>
DocumentRoot /sample/public #FuelPHPプロジェクトのパス指定
<Directory "/sample/public">
 Require all granted
 DirectoryIndex index.php
</Directory>
</VirtualHost>

といことで改めて再起動してブラウザで開くと、index.phpの画面は表示された！

しかし、ホーム画面から遷移しようとすると404になる…。

「404」エラーと対処法

DocumentRootのDirectoryディレクティブ内にある「AllowOverride None」が原因だった模様。

「AllowOverride All」に設定することで、public以下で配置している .htaccessのmod_rewrite機能が動作するようになるとのこと。

<VirtualHost *:80>
DocumentRoot /sample/public
<Directory "/sample/public">
 AllowOverride All
 Require all granted
 DirectoryIndex index.php
</Directory>
</VirtualHost>

$ systemctl restart httpd.service

再起動して無事に表示！「AllowOverride All」に書き換えて再起動すると、正常に画面遷移しました。

「httpd: Could not reliably determine the server’s fully qualified domain name」が表示された場合は

ちなみにエラーで「httpd: Could not reliably determine the server’s fully qualified domain name」と書かれている場合は、ServerNameの指定がされていないため、httpd.confに記載しましょう。

MySQLはdocker-composeを使用してインストールした。

実行環境

実行環境は以下の通り。

• Window7
• VirtualBox5.0.16
• Vagrant1.9.6
• CentOS7
• Docker18.03.1
• MySQL5.6
• DBeaver5.1.2

事前準備

VirtualBoxのインストール

• VirtualBox https://www.virtualbox.org/

Vagrantのインストール

• Vagrant https://www.vagrantup.com/

VagrantでCentOS7をインストール

• 日本語手順 https://qiita.com/RyochanUedasan/items/b1ff13bc39913cb5b561

CentOS7にDockerをインストール

• 公式手順 https://docs.docker.com/install/linux/docker-ce/centos/#os-requirements
• 日本語手順 https://qiita.com/inakadegaebal/items/be9fecce813cebec5986

DBeaverのインストール

• DBeaver https://dbeaver.io/

Vagrantで立ち上げた仮想環境を起動し、SSHでログインする

作成した作業ディレクトリにて仮想環境を起動し、SSHでログインします。

$ vagrant up

立ち上がったら、仮想環境にログインします。ログアウトはexitです。

$ vagrant ssh

docker-composeをインストール

docker-composeをインストールします。バージョンは適宜置き換えてください。

$ curl -L https://github.com/docker/compose/releases/download/1.3.1/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose
$ chmod +x /usr/local/bin/docker-compose

参考URL：https://qiita.com/zembutsu/items/dd2209a663cae37dfa81

docker-compose.ymlの編集

docker-compose.ymlを作成し、下記のように編集します。バージョンやユーザ名などは適宜置き換えてください。

$ vi docker-compose.yml

docker-composeは複数のコンテナを管理できるため、MySqlの下にNginxなどのコンテナを追加することができます。

docker-compose.yml

db:
image: mysql:5.6
ports:
- "3306:3306"
environment:
MYSQL_DATABASE: sample_db
MYSQL_USER: sample
MYSQL_PASSWORD: password
MYSQL_ROOT_PASSWORD: password

docker-composeの起動

docker-compose.ymlファイルを作成したら、docker-composeを起動します。

$ docker-compose up -d

docker-composeのプロセス確認

docker-composeが起動しているか確認します。

$ docker-compose ps
Name Command State Ports
---------------------------------------------------------------------------
test_db_1 docker-entrypoint.sh mysqld Up 0.0.0.0:3306->3306/tcp

仮想サーバで構築したMySQLをクライアントツール(DBeaver)に接続

MySQLを起動できているのを確認したら、ホストPCにインストールしてあるDBeaverに接続しましょう。

接続設定は以下の通りです。

DBeaverの接続設定

Server Host　MySQLが起動しているサーバのIPアドレス
Port　MySQLに接続するポート
Database　データベース名(書かなくても良い)
User Name　MySqlに接続するユーザ名
Password　MySqlに接続するユーザのパスワード

・SSH Tunnel
Host/IP　SSH接続するサーバのIPアドレス
Port　SSH接続するポート
User Name　SSH接続するユーザ名
Authentication Method　Public Key
Private Key　秘密鍵が格納されているパス
Passphrase　SSH接続するユーザのパスワード

Authentication Methodは「Password」と「Public Key」を選択できるようになっています。僕の場合、「Password」 選択時は接続することができなかったため、「Public Key」を選択し秘密鍵が格納されているのパスを入力しました。

設定が完了したら、OKボタンを押して接続されていることを確認しましょう。

実施環境

• Windows7
• VirtualBox-5.0.16
• DockerToolbox-18.03.0

作業環境

環境構築する前にdockerコマンドが使えることを確認します。

$ docker -v
Docker version 18.03.0-ce

$ docker-compose -version
docker-compose version 1.20.1

$ docker-machine --version
docker-machine version 0.14.0

laradockをクローン

laradockをクローンするためのディレクトリを作成します。作成したディレクトリに移動し、laradockをクローンします。

クローンに成功するとlaraveltest/laradockが作成されるので確認しましょう。

$ mkdir laraveltest
$ cd laraveltest/
$ git clone https://github.com/LaraDock/laradock.git

.envファイルをコピー

laradockのディレクトリに移動し、「env-example」ファイルをコピーし、「.env」ファイルを作成します。

$ cd laradock/
$ cp env-example .env

dockerコンテナの起動

nginxとmysqlを起動しましょう。psコマンドで起動されていることを確認します。

$ docker-compose up -d nginx mysql
$ docker-compose ps

IPアドレスを表示

IPアドレスを表示し、アクセスすると404となっていることを確認します。

$ docker-machine ip

Laravelプロジェクトを作成

workspaceコンテナの中に入り、Laravelプロジェクトを作成します。今回は、testというプロジェクト名で作成しました。

$ docker exec -it {workspace-container-id} /bin/bash
$ composer create-project --prefer-dist laravel/laravel test

.envファイルの編集(laraveltest\laradock配下)

.envファイルを編集します。デフォルトでは、「../」となっているので、正しいパスに変更しましょう。

APP_CODE_PATH_HOST=../test

.env の変更を反映し、コンテナを再起動

.envファイルの編集が終わったら、変更を反映させるために一時停止します。その後、コンテナを再起動します。

$ docker-compose stop
$ docker-compose up -d nginx php-fpm mysql workspace

$ docker-machine ipで表示されたIPにブラウザでアクセスし、このようにlaravelの画面が表示されたら成功です。

初めてなのでハマリまくったが、なんとかできた…。