ローカルで構築したRuby On RailsのアプリをGCPへの自動デプロイ環境を構築する。①
ゴール
ローカルでいじったコードをGit PushしたらGCPに自動で反映させて、Hello Worldを表示させる。
背景
会社の開発環境とデプロイ環境をできる範囲で再現してみたかった。
きちんと説明するとそこらのチュートリアル並に長くなるので、ところどころ割愛していく。
特に開発用でやりたかっただけなので、ドメインの取得はせずにhostsファイルでなんとかする。
capistranoの使い方全然わかっていないので、かなり無茶苦茶。
必要なツール
・Vagrant
・VirtualBox
・Circle CI
・GoogleCloud Platform (for kusanagi)
・Git (GitHub) クライアントツールはSource Tree (GitUpをお試し中)
各種バージョン情報
・kusanagi 8.4.0-3 (CentOS7.5)
・Nginx 1.15.2 (kusanagiに準ずる)
・Mac High Sierra 10.13.6
・Vagrant 2.1.2
・Virtual Box 5.6.18
・Ruby 2.4.2
前提
- GoogleCloud Pratform でアカウントを作成している。
- 各種ツールに記載してあるものもインストール済み。
GCPでkusanagiを構築
インスタンスの生成
GCPにログイン後に上部にある検索バーにkusanagiと入力。
プライム・ストラテジー社が出している以下のアイコンをクリックして生成する。
COMPUTE ENGINE上で起動を押す。
以下のように入力する。
名前は適当。
ゾーンも適当にasia-northeast-bを選択
kusanagiはメモリの推奨が4GB以上なので、それ以上のVCPUx2を選択
展開を押してIPアドレスは一旦エフェメラル→なしを選択。(あとで変えます。)
そして以上の入力や選択が終わったらデプロイを押す。
4~5分?かかるので、小休憩。
デプロイが完了したら以下のように出てたらOK。
この辺はkusanagiの公式サイトに載ってあるので、こちらを参照。
VMマシンの初設定を行う
次はVMマシンの外部IPアドレスの付与、ファイヤーウォールの設定とsshの設定を行う。
外部IPアドレスの付与
マシンができたらIPアドレスを付与して外部IP、つまりグローバルIPアドレスを付与してあげることによってmacから見ることができる。
初めての場合は何もないと思うので、静的アドレスの予約を押して生成する。
無料のアカウントなら1つまで静的なアドレスをもらえる。(それ以降は動的なアドレスになる)
こんな感じで、付与してあげる。
IPは人それぞれ違う。
sshの設定を行ってローカルのmacから接続する。
kusanagiの初期設定
メニュー > Compute Engine へ移動。
接続方法は、作成したVMインスタンスの右側にあるsshボタンを押す。
初めて接続する場合は、GCPに接続する登録をメタデータとかからしないといけなかったような。。。
接続に成功するとKUSANAGIの文字がお出迎えしてくれる。
あとは、kusanagiのオフィシャルサイトのドキュメントを見てkusanagiの初期設定(kusanagi init)まで済ませる。
kusanagiはサーバーの構築をよしなに行ってくれるので、素敵なサーバー構築が楽にできる。
その分何をしているかは勉強していかないと。
ローカルから接続
そんなこんなで初期設定を終えたらローカルから接続してみる。
が、その前にkusanagiのアカウントで直接接続できるように
サーバーに公開鍵を置いて、ローカルに秘密鍵を置く。
恐らく邪道な気がするが、ここではブラウザ上で表示させてローカルにコピーしてしまう。 本当はローカルで生成した鍵をサーバーに置くのが正解。
まずは、以下のコマンドを実施。 なにか聞かれても全部EnterでOK。
[root@test-kusanagi-vm .ssh]# cd /home/kusanagi/.ssh [root@test-kusanagi-vm .ssh]# su kusanagi [kusanagi@test-kusanagi-vm .ssh]$ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/kusanagi/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/kusanagi/.ssh/id_rsa. Your public key has been saved in /home/kusanagi/.ssh/id_rsa.pub. The key fingerprint is: SHA256:hogeHOGEhogeHOGEhogeHOGEhogeHOGE kusanagi@test-kusanagi-vm The key's randomart image is: +---[RSA 2048]----+ | | | | | . | | . o | | ... . +S . O | | .=.P.B*oo | | o.**H*=* . | | **o+** o | | . BBo+++ | +----[SHA256]-----+ [kusanagi@test-kusanagi-vm .ssh]$ ll total 12 -rw-r--r-- 1 root root 822 Oct 12 08:51 authorized_keys -rw------- 1 kusanagi kusanagi 1679 Oct 12 09:01 id_rsa -rw-r--r-- 1 kusanagi kusanagi 407 Oct 12 09:01 id_rsa.pub
これで公開鍵と秘密鍵が生成されたので、それぞれ登録する。
まずは、公開鍵をauthorized_keysに登録
authorized_keysの所有者:グループがrootになっているので、
kusanagi に変更してから登録。
[kusanagi@test-kusanagi-vm .ssh]$ cat id_rsa.pub >> authorized_keys bash: authorized_keys: Permission denied [kusanagi@test-kusanagi-vm .ssh]$ sudo chown kusanagi:kusanagi authorized_keys [kusanagi@test-kusanagi-vm .ssh]$ ll total 12 -rw-r--r-- 1 kusanagi kusanagi 822 Oct 12 08:51 authorized_keys -rw------- 1 kusanagi kusanagi 1679 Oct 12 09:01 id_rsa -rw-r--r-- 1 kusanagi kusanagi 407 Oct 12 09:01 id_rsa.pub [kusanagi@test-kusanagi-vm .ssh]$ cat id_rsa.pub >> authorized_keys
これで公開鍵の設置が完了。
続いて、秘密鍵をローカルに持っておきたい。
[kusanagi@test-kusanagi-vm .ssh]$ cat id_rsa # // 以下からコピー -----BEGIN RSA PRIVATE KEY----- MIIEpAIBAAKCAQEAtt/M9c1BRkVRdY3vK0mDOfhawTnoN/0Acb/FrOafK5iRSezt WziAZ0qDNY5mkizR4RA3/yQZn4kQ07Z940jCFBtg0uG0UplDt07V2Sc/1TGfvgvc fKHrtx1i788tITMK3RRL8NkEq9z25Ewj7CYzisZ5BCnLSobje0+xCqrqViVsiUUc +cUrVleaV432BIFmlzQvnncwoINwwS6mpPICOfxHzDPjBN5cRnCYtksHat8B3NgL hPyUfnS........................... -----END RSA PRIVATE KEY----- # // ここまでコピー
macのターミナルを開いて、任意の名前で登録しておく。
文字化け怖いので、viエディタで記入。
$ vi ~/.ssh/test-kusanagi
で、挿入モードにして、先程の鍵を登録する。
-----BEGIN 〜 KEY--- までをきっちり入れる。
終わったらパーミッションを600にしておく。
$ chmod 600 ~/.ssh/test-kusanagi
その後に ~/.ssh/config ファイルに以下を記述すると楽にターミナルから接続できる。
普通のテキストエディタで開いて記載して大丈夫。
Hostは任意の名前
xx.xx.xx.xxの部分は各自のIPアドレスに置き換える
Portは一旦22で接続。
# -------------- test-kusanagi -------------- Host test-kusanagi HostName xx.xx.xx.xx User kusanagi Port 22 StrictHostKeyChecking no PasswordAuthentication no IdentityFile /Users/[ユーザ名]/.ssh/test-kusanagi IdentitiesOnly yes
できたら保存して終了。
ここまで来たらmacのターミナルで接続。
$ ssh test-kusanagi
Last login: Fri Oct 12 09:00:53 2018
__ ____ _______ ___ _ _____ __________
/ //_/ / / / ___// | / | / / | / ____/ _/
/ ,< / / / /\__ \/ /| | / |/ / /| |/ / __ / /
/ /| / /_/ /___/ / ___ |/ /| / ___ / /_/ // /
/_/ |_\____//____/_/ |_/_/ |_/_/ |_\____/___/
Version 8.4.0-3, Powered by Prime Strategy.
ブラウザ上のGCPのコンソール上の秘密鍵と公開鍵は削除してしまう。
[kusanagi@test-kusanagi-vm .ssh]$ ll total 12 -rw-r--r-- 1 kusanagi kusanagi 1229 Oct 12 09:04 authorized_keys -rw------- 1 kusanagi kusanagi 1679 Oct 12 09:01 id_rsa -rw-r--r-- 1 kusanagi kusanagi 407 Oct 12 09:01 id_rsa.pub [kusanagi@test-kusanagi-vm .ssh]$ rm -rf id_rs* [kusanagi@test-kusanagi-vm .ssh]$ ll total 4 -rw-r--r-- 1 kusanagi kusanagi 1229 Oct 12 09:04 authorized_keys
ファイヤーウォールの設定
GCPはセキュリティ上、ファイヤーウォールの設定が最初からしていてくれて、
必要最低限のものしかポートを開放していない。
よりセキュアなサーバーを構築するためにポート番号を変更しておく。
なので、sshd_configで違うポートを指定した場合は、
自分でファイヤーウォールのポートを開放しないと、ローカルから接続ができなくなるので接続できるように設定をしておく。
メニュー > VPCネットワーク > ファイヤーウォールルール
ルールを作成して、インスタンスに適用させるためにターゲットというものを使って適用させるさせないを指定できる。
なので、ルール作成にターゲットとなる文字を決めて、インスタンスを編集してターゲットを適用させる。
デフォルトで22,80,433,3389あたりが接続できるようになっている。
今回はsshのポートを変更したいので、その番号を開けてあげる。
上部のファイヤーウォールのルールを作成するボタンを押し、以下のように設定する。
名前 : 適当 〜ssh みたいな名前でも良かった。
ターゲット : 指定されたターゲットタグを選択
ターゲット タグ : 任意の入力
ソースIPの範囲 : 0.0.0.0/0
プロトコルとポート: TCPを選択し、任意のポート番号を入力
終わったら作成ボタン。
最後のポート番号のところは、
この番号を使ってサーバーのポート番号の変更をする。
設定したものを開くと以下のようになる。
その後はターゲットタグをインスタンスに設定して、ポート番号を変更して
sshdを再起動して、ローカルから接続できればOK
まずは、ターゲットタグの文字をコピーしておいて、
メニュー > Compute Engine
先程作成したインスタンスを選択して、上部の編集ボタンを押す。
ネットワークタグ欄に、先程のターゲットタグを入れて保存する。
もう一度
メニュー > VPCネットワーク > ファイヤーウォールルール へ戻って、
先程作成したルールを開いてみると以下のように
ターゲットタグを入れたインスタンスが表示されていればOK
[kusanagi@test-kusanagi-vm ~]$ sudo vi /etc/ssh/sshd_config # $OpenBSD: sshd_config,v 1.93 2014/01/10 05:59:19 djm Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. . . . # If you want to change the port on a SELinux system, you have to tell # SELinux about this change. # semanage port -a -t ssh_port_t -p tcp #PORTNUMBER # #Port 22 Port 22222 // 追記する。
追記したら:wqで保存終了して、sshdを再起動する。
[kusanagi@test-kusanagi-vm ~]$ sudo su - 最終ログイン: 2018/10/12 (金) 08:47:52 JST日時 pts/0 [root@test-kusanagi-vm ~]# systemctl restart sshd
~/.ssh/configファイルもポートを変更しておく。
# -------------- test-kusanagi -------------- Host test-kusanagi HostName 35.221.82.154 User kusanagi Port 22222 StrictHostKeyChecking no PasswordAuthentication no IdentityFile /Users/ml200/.ssh/test-kusanagi IdentitiesOnly yes
新たにターミナルのウィンドウを開く。
ML200:material-gcp ml200$ ssh test-kusanagi
Warning: Permanently added '[35.221.82.154]:22222' (ECDSA) to the list of known hosts.
Last login: Fri Oct 12 09:20:47 2018 from fs276ed016.tkyc509.ap.nuro.jp
__ ____ _______ ___ _ _____ __________
/ //_/ / / / ___// | / | / / | / ____/ _/
/ ,< / / / /\__ \/ /| | / |/ / /| |/ / __ / /
/ /| / /_/ /___/ / ___ |/ /| / ___ / /_/ // /
/_/ |_\____//____/_/ |_/_/ |_/_/ |_\____/___/
Version 8.4.0-3, Powered by Prime Strategy.
接続されればOK！
kusanagiのprovisioning
kusanagi は Ruby on Railsもサポートしているためオプションを指定してprovisionigをする。
# kusanagi provision --rails [プロファイル名]
あとは以下の通りに設定していく。 KUSANAGIのプロビジョニング – KUSANAGI
今回はプロファイル名とFQDNはrails.comで進めていく。
あとはデータベースの設定を行う。
後ほど使うので覚えておくかメモしておく。
ブラウザに表示させる。
プロビジョニングが完了したら、hostsファイルを設定してブラウザに設定したFQDNを入力する。
sshでログインしている場合は別のターミナルを開いて、macの設定ファイルを編集する。
$ vi /etc/hosts ※場合によってはsudo権限で行う ## # Host Database # # localhost is used to configure the loopback interface # when the system is booting. Do not change this entry. ## 127.0.0.1 localhost #127.0.0.1 hoge1.com #127.0.0.1 hoge2.com #127.0.0.1 hoge3.com 255.255.255.255 broadcasthost ::1 localhost # 追記分 xx.xx.xx.xx rails.com
で、ブラウザ上に「rails.com」と入力。
すると、エラーになる。
これは、railsのデータベースに接続するための設定が間違えているので出てしまう。
今度はサーバーに入って、
[root@test-kusanagi-vm ~]# vi /home/kusanagi/rails.com/config/database.yml
default: &default
adapter: mysql2
encoding: utf8
pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
username: ENV['RAILS_DB_USER']
password: ENV['RAILS_DB_PASS']
socket: /var/lib/mysql/mysql.sock
.
.
.
production:
<<: *default
database: ENV['RAILS_DB_NAME']
と編集する。
そして、ENV['~~']の中身を.envファイルで定義してあげる。
xxxx...には先程設定したデータベース名などを入れる。
[root@test-kusanagi-vm ~]# vi /home/kusanagi/rails.com/.env RAILS_DB_NAME='xxxxxxx' RAILS_DB_USER='xxxxxxxx' RAILS_DB_PASS='xxxxxxxxxx'
あとはNginxの設定ファイルをいじって、本番環境で起動させる設定を反映させてあげる。
[root@test-kusanagi-vm ~]# vi /etc/nginx/conf.d/rails.com_http.conf
.
.
.
#rails_env development;
rails_env production;
.
.
.
rails_env development;をコメントアウトして、
rails_env production;のコメントアウトを外してあげる。
終わったら、# systemctl restart nginxで再起動。
ブラウザを再読込してあげると。。。
/home/kusanaig/rails.com/public配下にindex.htmlを配置してあげる。
適当にテストって入力して保存する。
ブラウザを再読込させてあげると、、、、できた！
Vagrantでkusanagiを構築
今度はローカル開発環境を立ち上げて、GCPのサーバーと同様のものを作成してあげる。
Vagrantでkusanagiを構築し、開発環境を作成する。
VM上のコードとローカルのコードを同期させる。
ローカルで編集したRailsのコードをVM上で動かし、
アプリケーションを動作させることができる。
つまり開発環境を作成する。
kusanagi環境構築
今度はローカル開発環境を立ち上げて、GCPのサーバーと同様のものを作成してあげる。
こちらを参考にkusanagi initまで進める。
ローカルとVM上を同期させ、開発環境を作成する。
kusanagi initが終わったらローカルフォルダとVMのフォルダを同期する。
まずは、ローカルでGitHubと連携したいリポジトリを作成しておく。
$ mkdir rails.com
vagrant init をした際に生成されていたVagrantfileを編集する。
# config.vm.synced_folder "../data", "/vagrant_data" config.vm.synced_folder "/Users/[ユーザ名]/rails.com", "/home/kusanagi"
保存したらvagrant reloadして、変更を反映する。
kusanagiのprovisioning
もう一度VMにsshでログインして/home/kusanagiまでディレクトリを移動する。
この時点で、ローカルとVMが同期しているので、
どちらかでファイルやディレクトリを作成したらもう片方も作成されていればOK。
$ sudo su -でrootになって、kusanagiのprovisionを行い、GCPで設定した内容と同じものを作る。。
FQDNのみ、test.rails.com や vagrant.rails.com など本番とかぶらないようにつける。
# kusanagi provision --rails [プロファイル名]
provisiongが終わったらログアウトして、
ローカルのVagrantfileを以下のように編集して、vagrant reloadする。
# config.vm.synced_folder "../data", "/vagrant_data" config.vm.synced_folder "/Users/[ユーザー名]/rails.com", "/home/kusanagi/rails.com"
から
# config.vm.synced_folder "../data", "/vagrant_data" config.vm.synced_folder "/Users/[ユーザー名]/rails.com", "/home/kusanagi/rails.com", owner: "kusanagi", group: "kusanagi"
に変更する。
vagrant reloadを行い、同期の確認ができたら、ローカルのリポジトリをgitに登録しておく。
GitHubでもリモートリポジトリを作成しておく。
ドメインにアクセスしたらエラーがでるので、GCPで行ったときと同様に、
config/database.ymlと.envファイル を編集して、
kusanagi restartして画面が表示されればOK。
dotenv-railsを使う場合は、bundleコマンドを入力してから
Rails rootに.env.developmentというファイルを作成して、環境変数を設定する。
このときにpushする前に.gitignoreに.env*を入れないと、環境変数が外部に漏れてしまうので、記載する。
ここまできて、ようやくCIrcle CIに入る。 長くなったので、次回。
コミット & プッシュせずにCircle CIのビルドをテストする。
Circle CI 2.0で環境を構築中、とある記事に出会った。
前からいちいちプッシュするのめんどくさいなーと思っていたので、手を止めて実際にやってみた。
また、以下のエラーにもあるが、
個人用のリポジトリはパブリックなので、環境変数とか使わないとDBのアカウント系がGitHubのpush履歴に
残ってしまうので、不用意にビルドのテストを行えなかった。
なので、これができればいちいちpushして、webサイト見て〜という行為をしなくてもテストができるので、 やってみる価値はすごく高いと思った。
ちなみに現在はCircle CIで以下のようなビルドのエラーが起きている。
Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)
Couldn't create database for {"adapter"=>"mysql2", "encoding"=>"utf8", "pool"=>5, "username"=>nil, "password"=>nil, "socket"=>"/var/lib/mysql/mysql.sock", "database"=>"xxxxxx"}
rake aborted!
これと同じエラーがターミナルで出てくればOK。
本来なら成功例を出したいところであるが。。。
記事と同じように自分もDocker for Mac Dockerの使い方はあまりわかっていない。 ない場合はDockerのアカウントを作成して、インストールしておく。
$ docker -v
Docker version 18.06.1-ce, build e68fc7a
$ curl -o /usr/local/bin/circleci https://circle-downloads.s3.amazonaws.com/releases/build_agent_wrapper/circleci && chmod +x /usr/local/bin/circleci
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 4691 100 4691 0 0 4269 0 0:00:01 0:00:01 --:--:-- 4272
$ circleci -v // こちらはコマンド間違えてるぽいが
Receiving latest version of circleci...
INFO: We've built a brand new CLI for CircleCI! Please run 'circleci switch' to upgrade.
Error: unknown shorthand flag: 'v' in -v
$ circleci switch // upgradeする。
Thank you for your interest in trying the new CLI!
Be sure to read the docs if you get stuck. [https://github.com/CircleCI-Public/circleci-cli#readme]
Are you sure you're ready to upgrade? [y/N]: y
Upgrading CircleCI to the newest version.
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1216 100 1216 0 0 3423 0 --:--:-- --:--:-- --:--:-- 3415
Finding latest release.
Downloading CircleCI v0.1.3093
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 632 0 632 0 0 764 0 --:--:-- --:--:-- --:--:-- 764
100 3432k 100 3432k 0 0 409k 0 0:00:08 0:00:08 --:--:-- 659k
x client/LICENSE
x md_docs/LICENSE
x circleci
Installing to /usr/local/bin/circleci
/usr/local/bin/circleci
$ which circleci
/usr/local/bin/circleci
rails rootまでcdコマンドで移動。
$ circleci config validate -c .circleci/config.yml
Config file at .circleci/config.yml is valid
$ circleci build
Downloading latest CircleCI build agent...
....
Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)
Couldn't create database for {"adapter"=>"mysql2", "encoding"=>"utf8", "pool"=>5, "username"=>nil, "password"=>nil, "socket"=>"/var/lib/mysql/mysql.sock", "database"=>"xxxxxx"}
rake aborted!
もともとビルドミスっている状態だったが、同じエラーが出されていた。感動。
$ circleci version
0.1.3093+2558d82
$ circleci --help
This project is the seed for CircleCI's new command-line application.
Usage:
circleci [command]
Available Commands:
config Operate on build config files
diagnostic Check the status of your CircleCI CLI.
help Help about any command
local Debug jobs on the local machine
namespace Operate on namespaces
orb Operate on orbs
query Query the CircleCI GraphQL API.
setup Setup the CLI with your credentials
update Update the tool
version Display version information
Flags:
-h, --help help for circleci
--host string URL to your CircleCI host (default "https://circleci.com")
--token string your token for using CircleCI
--verbose Enable verbose logging.
Use "circleci [command] --help" for more information about a command.
サーバーの運用を自動的に行うMonitの設定を見てみる(kusanagi環境)
手動で導入も可能みたいだが、kusanagi環境(8.4.0-3)でprovisionで作成されるファイルを見てみる。 https://kusanagi.tokyo/
バージョンは以下の通り
CentOS 7.5
Nginx 1.15.2
Monit 5.25.1
access.logが自動で復活している現象を発見
logrotateの動作確認中にaccess.logを間違えて消してしまったが、少しすると自動的に復活していた。
→ 調べてみるとmonitというデーモンが30秒ごとにaccess.logの存在を監視していて、なければ自動的にリスタートをかけてくれていた。
logrotateでコケるとaccess.logとかが作成されない不具合が起きた場合、monitがそれをサポートしてくれるというのもメリットの一つ。
Monitとは
総合監視デーモンとしてファイルシステムからHTTPレスポンス内容・プロセス監視などの機能を持っています。GPLライセンスでLinux/BSD/Solaris上で動作可能です。CentOSならDAGリポジトリからyum installもでき、configも簡潔ですので15分程度で導入ができます。
15分で始めるmonitによるサーバ監視 より引用
kusanagi環境では初期設定で導入されているので、logrotateと同様にデプロイ関連ツールを導入してログの場所が変わってしまうとmonitも動作しない。
設定ファイル
/etc/monitrc/etc/monit.d/xxxx配下にある
/etc/monitrcを覗いてみる
###############################################################################
## Global section
###############################################################################
##
## Start Monit in the background (run as a daemon):
#
set daemon 30 # check services at 30 seconds intervals
# with start delay 240 # optional: delay the first check by 4-minutes (by
# # default Monit check immediately after Monit start)
#
#
## Set syslog logging. If you want to log to a standalone log file instead,
## specify the full path to the log file
#
set log syslog
(略)
## Monit has an embedded HTTP interface which can be used to view status of
## services monitored and manage services from a web interface. The HTTP
## interface is also required if you want to issue Monit commands from the
## command line, such as 'monit status' or 'monit restart service' The reason
## for this is that the Monit client uses the HTTP interface to send these
## commands to a running Monit daemon. See the Monit Wiki if you want to
## enable SSL for the HTTP interface.
#
set httpd port 2812 and
use address localhost # only accept connection from localhost
allow localhost # allow localhost to connect to the server and
allow admin:monit # require user 'admin' with password 'monit'
#with ssl { # enable SSL/TLS and set path to server certificate
# pemfile: /etc/ssl/certs/monit.pem
#}
(略)
include /etc/monit.d/*
分かる範囲だと
- 30秒ごとに監視している。
/etc/monit.d/*以下も含んでいるので実行できる
なので、/etc/monit.d/以下に名前をつけて独自で設定すれば30秒ごとに監視してくれる。
/etc/monit.d/配下の設定ファイル
こちらはkusanagiでprovisioningをしたあと に自動的に作られる/etc/monit.d/project_nginx.conf
check file project_nginx with path /home/kusanagi/project/log/nginx/access.log
restart program = "/bin/kusanagi restart"
depends on nginx
if match '"(GET|POST) /.* HTTP/.*" 5[0-9][0-9] [0-9]+ ' for 2 cycle then restart
if 5 restarts within 5 cycles then alert
if 5 restarts within 5 cycles then unmonitor
group nginx
check file project_nginx_ssl with path /home/kusanagi/project/log/nginx/ssl_access.log
restart program = "/bin/kusanagi restart"
depends on nginx
if match '"(GET|POST) /.* HTTP/.*" 5[0-9][0-9] [0-9]+ ' for 2 cycle then restart
if 5 restarts within 5 cycles then alert
if 5 restarts within 5 cycles then unmonitor
group nginx
構築した環境によっては、ログの位置が変わったりするので、 monitを利用してサーバーの監視をしたい場合はこちらのファイルのログのパスを編集する。
個人的な解釈としては、
monitが30秒ごと(/etc/monitrcの設定で変更可)に指定したファイルを見に行って、
指定ファイルが存在しなければkusanagi restartされる。
それを5回繰り返したらalert出すし、モニタリングをやめる。
monitの状況確認
２つのコマンドがある。
- # monit status
- # monit summary
どちらも同じような内容?だが、個人的には見やすいので、monit statusを見ている。
monit status
kusanagiでは、自動的にNginxかApacheのどちらで動かしているかを判断して、 片方を監視から外してくれている。
Nginxがwebサーバーとして可動している場合は、以下の記述。
# monit status Monit 5.25.1 uptime: 5d 17h 54m File 'project_nginx' status OK monitoring status Monitored monitoring mode active on reboot start permission 644 uid 1001 gid 1002 size 0 B access timestamp Tue, 02 Oct 2018 03:32:32 change timestamp Tue, 02 Oct 2018 03:32:32 modify timestamp Tue, 02 Oct 2018 03:32:32 content match no data collected Tue, 02 Oct 2018 08:11:16
以下はApacheは起動していないので、kusanagiがあえて最初から監視からはずしてくれている。
また、先程記述した/etc/monit.d/project_nginx.confにあったように
monitが起動しているのに指定のログファイルのパスがおかしい場合、
5回リスタートを繰り返しても不具合がある場合はモニタリングをやめるという記述をしたが、
もし、それに該当するようになった場合はprojct_nginxでも以下のようにNot monitoredという扱いになる。
File 'project_httpd' status Not monitored monitoring status Not monitored monitoring mode active on reboot start data collected Wed, 26 Sep 2018 14:16:35
monit summary
# monit summary Monit 5.25.1 uptime: 5d 18h 1m ┌─────────────────────────────────┬────────────────────────────┬───────────────┐ │ Service Name │ Status │ Type │ ├─────────────────────────────────┼────────────────────────────┼───────────────┤ │ system-1 │ OK │ System │ ├─────────────────────────────────┼────────────────────────────┼───────────────┤ │ project_nginx │ OK │ File │ ├─────────────────────────────────┼────────────────────────────┼───────────────┤ │ project_nginx_ssl │ OK │ File │ ├─────────────────────────────────┼────────────────────────────┼───────────────┤ │ project_httpd │ Not monitored │ File │ ├─────────────────────────────────┼────────────────────────────┼───────────────┤
テーブルを作って、最低限だが表示をしてくれる。
monitのログを見る
kusanagi環境で構築した場合には/var/log/monit.logに記載されている
以下は、projectのログの出力先(nginxのconfファイルで設定)とmonitの設定のログの出力先の整合性が合わない時に、発生。
5回restartを繰り返してもう監視やめまーすという状態。
こうなるとmonit summary or monit status で見た時に、Not monitoredとなる。
[JST Sep 16 12:08:36] error : 'project_nginx' file doesn't exist [JST Sep 16 12:08:36] info : 'project_nginx' trying to restart [JST Sep 16 12:08:36] info : 'project_nginx' restart: '/bin/kusanagi restart' (略) [JST Sep 16 12:09:07] error : 'sleepdays_nginx' service restarted 5 times within 5 cycles(s) - unmonitor
monitの設定変更時
Not monitoredになっている設定を監視開始(再開)したいときは、monit start project_nginxとかで監視を再開できる。
うまくいかない場合はmonit restartとかsystemctl monit restatとかでmonit自体をリスタートかける。
# monit -tで構文チェックもできる。
monitコマンド
以下、参考
# monit -h
Usage: monit [options]+ [command]
Options are as follows:
-c file Use this control file
-d n Run as a daemon once per n seconds
-g name Set group name for monit commands
-l logfile Print log information to this file
-p pidfile Use this lock file in daemon mode
-s statefile Set the file monit should write state information to
-I Do not run in background (needed when run from init)
--id Print Monit's unique ID
--resetid Reset Monit's unique ID. Use with caution
-B Batch command line mode (do not output tables or colors)
-t Run syntax check for the control file
-v Verbose mode, work noisy (diagnostic output)
-vv Very verbose mode, same as -v plus log stacktrace on error
-H [filename] Print SHA1 and MD5 hashes of the file or of stdin if the
filename is omited; monit will exit afterwards
-V Print version number and patchlevel
-h Print this text
Optional commands are as follows:
start all - Start all services
start <name> - Only start the named service
stop all - Stop all services
stop <name> - Stop the named service
restart all - Stop and start all services
restart <name> - Only restart the named service
monitor all - Enable monitoring of all services
monitor <name> - Only enable monitoring of the named service
unmonitor all - Disable monitoring of all services
unmonitor <name> - Only disable monitoring of the named service
reload - Reinitialize monit
status [name] - Print full status information for service(s)
summary [name] - Print short status information for service(s)
report [up|down|..] - Report state of services. See manual for options
quit - Kill the monit daemon process
validate - Check all services and start if not running
procmatch <pattern> - Test process matching pattern
