コミット & プッシュせずに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
エンジニアになって3ヶ月目を振り返る
業務
Server
SSL
SSL(Let's encrypt)の取得〜自動更新
Nginxの設定と証明書取得の流れを理解できた。
logrotate
- ログの肥大化によるディスク溢れを防止する
- ログの世代管理やサイズ制限できる
monit
- サーバー監視ツールの設定
- サービスを監視しサービスがダウンしていた場合に、自動でサービスの復旧を行える
Nginx
Digest認証
- ウェブサイトの閲覧制限をBASIC認証より安全に行える
cron
- 特定のスクリプトやコマンドを自動化し、サーバーの保守運用を行える
Docker
CircleCIでDockerが動いているみたいなので、体験した。
GCP
- インスタンス生成〜複製
- immutable deployment と Blue Green Deployment のサーバー運用(厳密にはどちらとも異なる)。
- ダウンタイムの最小化を実現
- immutable deployment と Blue Green Deployment のサーバー運用(厳密にはどちらとも異なる)。
Program
Ruby
まだひよこ状態 dotinstall完了
PHP
こちらもひよこ状態 dotinstall完了 コード見てなんとなく修正はできる
Wordpress
- キャッシュの制御(ハードとソフト?)をし、変更後にリロードもさせずに「あれ、変わっていませんよ？」を防止する。
Tools
Google Tag Manager
- 基本的なタグとトリガーの設定し、今後も増加するタグの一元管理を行う
- タグをバージョン管理することで、いつ、何の目的でタグを入れたかが明確になり、属人的な面から開放される & 管理が楽になる。
OWASP ZAP / Burp Suite
- OWASP ZAPをインストール、プロキシとして動作させてHTTP通信を観察
- Firefoxの拡張期である「FoxyProxy-statdard」を追加して、VirtualBox上で動作する特別な環境のみにプロキシを設定させる。
