CI/CD

Webhook環境構築はこちらへ：Webhookで自動デプロイ–ステップ１ Webhookで簡単デプロイの設定手順はこちらへ：Webhookで自動デプロイ-ステップ２ Webhookで自動デプロイすることが前回まで既にできました。でも、まだ完成とは言えません。 残りの問題： 更新は失敗した場合、どこに引っかかっているかわからない 設定ファイルさえないので、新しいWebhookを導入する時、gitlab.phpをいじらなければいけないため、人為的なミスが発生する確率が高くなる LAMP環境とデプロイ用のgitlab.phpなどを１コマンドでデプロイサーバに展開できればいいかなと。。 問題１について： a. GUIで管理して、履歴をDBへ保存する b. ログの追加 デプロイプロジェクトをGUI化にしたら、そこそこのコストがかかります。 開発、メンテナンスにも手間が必要です。 もし履歴などを（自動テスト結果とかも）管理したければ、Webhookではなく、CI/CDを利用したほうが断然コストが低いし、安定性も高いので、選択肢aをパスしました。 選択肢bを実装しましょう。 function writeLog($logPath, $msg) { /* create open log */ $fs = fopen($logPath, ‘a’); $nowDate = date(“Y-m-d H:i:s”); try { fwrite($fs, “[$nowDate]: $msg”.PHP_EOL); } finally { $fs and fclose($fs); } } 問題２： a. gitlab.phpの自動テストを実装する b. env.iniでコントロールする 「こんな簡単なgitlab.phpのためにテストを書いて、毎回編集してテストするもんか」という感じで、bを選びました。 PHPで.iniファイルの読み込みはとりあえず簡単です。 $ENV = parse_ini_file(‘./env.ini’, true); そして、外へ出すべきな変量を洗い出しましょう。 セキュリティトークン： token ホワイトIPリスト：allow_ip_list ログファイルパス：log ブランチ：branch [security] ;secret token token=”enter_my_security_token” ;space for …

ステップ１でWebhook専用の環境が用意できたと思います。 していない場合こちらへ：Webhookで自動デプロイ–ステップ１ では、ソースコードをgitlabサーバのリポジトリにプッシュしたら デプロイサーバ側： gitlabサーバからの通知を受信したら、デプロイ作業を行う。 gitlabサーバ側： gitlabのWebhookを利用して、デプロイサーバへ通知する デプロイサーバ側： まずデプロイサーバのLAMP環境に、gitlab.phpを追加します。 中身は下記のように入れます。   １．gitlabからのWebhookから受信したことを判断する（x_gitlab_token） $env_token = ‘enter_your_own_secret_token’; $clientenv_token = isset($_SERVER[‘HTTP_X_GITLAB_TOKEN’]) ? $_SERVER[‘HTTP_X_GITLAB_TOKEN’] : ”; if ($clientenv_token !== $env_token) { header(“HTTP/1.1 403 Forbidden”); echo “Forbidden”; exit(0); }   ２．IPアドレスフィルターの追加（特定なIPからのプッシュのみ許可するように） $env_allow_ip = array(“123.123.123.123”, “234.234.234.234”); $client_ip = $_SERVER[‘REMOTE_ADDR’]; if ( count($env_allow_ip) > 0 && !in_array($client_ip, $env_allow_ip)) { header(“HTTP/1.1 503 Service Temporarily Unavailable”); echo “Service Temporarily Unavailable”; exit(0); }   ３．イベントタイプの判断（プッシュイベントのみ） $postdata = file_get_contents(‘php://input’); $data …

そもそもWebhookは何でしょうか？ Wikiによると、 Webhooks are “user-defined HTTP callbacks“. They are usually triggered by some event, such as pushing code to a repository or a comment being posted to a blog. ユーザー定義したhttpのcallbacksである。特定なイベントでキックされる。例えば：リポジトリにプッシュされること、ブログにコメントが投稿されること。 サンプルとして下記の環境でステップバイステップで自動デプロイを実現する予定です。 レポジトリとwebhook側（githubとgitbucketはほとんど同じ） Git: gitlab.com サーバ側（Conoha） OS: CentOS7.4 WebServer: Apache2.4 Language: PHP7.1 まずは環境構築： echo “必要なパッケージをインストール[git, httpd, php7.1]” sudo yum install git httpd -y yes yes | sudo yum install epel-release sudo rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-7.rpm yes yes | sudo yum install …

Dockerを利用してデプロイする場合、デプロイユーザにroot権限を与えたり、sudoグループに追加したりすることはセキュリティにはよいとは言えないでしょう。 デプロイユーザにDockerコマンドの実行権限をあげれば一番いいと考えます。 ユーザー「deployer」を例として: echo "dockerグループはすでにあるはずだけど念の為" sudo groupadd docker echo "現在のユーザーをdockerグループに入れる" sudo usermod -aG docker deployer