SupervisorでGolangで書かれたアプリケーションのデーモン化をした話

今回は前回の記事に関連してGoで書かれたアプリケーションをSupervisorを使ってデーモン化した時の話を書いていきたい思います。

はじめに

開発環境

  • CentOS 7.3
  • Go 1.8
  • Supervisor 3.3.3

前提条件

Goのアプリケーションがデプロイされている、 go build したバイナリがある

Supervisorとは

そもそもSupervisorってなんぞや?っていう人もいると思うので説明します。
Supervisorはpythonで書かれているプロセス管理ツールです。
Supervisorは設定ファイルをちょこっと書くだけで簡単にデーモンプロセスの生成ができるのでとても楽です。

Supervisor: A Process Control System — Supervisor 3.3.3 documentation

インストール

yumでインストールしておきましょう
yum install supervisor

設定ファイルに新しく追加する

Supervisorがinstallされると /etc/supervisord.conf が作成されています。これが設定ファイルなので編集していきましょう。
設定ファイルの中にはsupervisor自身の設定も含まれています。
早速ですが、これが完成形です。詳しい内容については後述していきます。
※ 今回はSupervisor自身の設定は省きます。

;/etc/supervisord.conf
[unix_http_server]
file = /run/supervisor.sock
chmod = 0777
chown= root:root

[supervisorctl]
serverurl = unix:///run/supervisor.sock

[supervisord]
logfile=/var/log/supervisor/supervisord.log
logfile_maxbytes=50MB
logfile_backups=10
loglevel=info
pidfile=/var/run/supervisord.pid
nodaemon=true
minfds=1024
minprocs=200
user=root
ehildlogdir=/var/log/supervisor/

[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface

; Goアプリの設定
[program: sample]
command=sample-go-app
autostart=true
autorestart=true
user=sample-user
startsecs=5
redirect_stderr=true
stdout_logfile=/var/log/sample-go-app.log

[program:]
アプリをデーモン化する際はこのprogramセクションを使用します。

command
ここで設定したコマンドが起動時に実行されるようになります。
Goはビルドするとそれ自体で実行可能なバイナリになるのでここではバイナリを指定します。

autostart
Supervisor起動時に自動的にprogramセクションが起動するように設定できます。

autorestart
プロセスが死んだ時にSupervisorが自動的に再びプロセスを立ち上げるように設定できます。

user
programセクションを実行するユーザーを指定することができます。

redirect_stderr
エラー出力を標準出力にリダイレクトできます。

stdout_logfile
標準出力のログをファイルを指定することで保存できます。

Supervisorを起動してみる

設定を追加し終わったら次は実際に起動してみましょう。
supervisord を叩くと起動することができます。
もし、本当に起動しているのか確認したい場合は supervisorctl を叩くと確認することができます。

Supervisor自身の自動起動設定

最後にSupervisor自身を自動起動できるようにしましょう。
ありがたいことに起動時のスクリプトを書いてくれている方がいたのでこれをcloneしてきてコピーしましょう

git clone git://github.com/Supervisor/initscripts.git
cd initscripts/
cp redhat-init-jkoppe /etc/init.d/supervisord
cp redhat-sysconfig-jkoppe /etc/sysconfig/supervisord
chkconfig --add supervisord
chkconfig supervisord on

github.com

Golangで書かれたWebアプリをWerckerでVPSにデプロイした話

今回はGoで書かれたWebアプリケーションをWerckerを使ってビルドとデプロイをしたのでその時のWerckerのデプロイ設定などについて書いていきたいと思います。

はじめに

開発環境

前提条件

  • Githubで開発しているリポジトリがあること
  • すでにWercker側でApplicationの作成をしていて、PushするとBuildフェーズが通るようになっていること

Werckerの全体像

WerckerのPipelineという概念があります。 下記画像のようにBoxという仮想環境の中でBuildフェーズとDeployフェーズが順番に実行され、その中でstep と呼ばれる個別の処理で発生します。
今回はmasterにpushされたタイミングでBuildフェーズとDeployフェーズが実行されるように設定します。

f:id:kazumasaSS:20170615124847p:plain

Wercker側でDeployフェーズの追加

werckerのアプリケーションのページに移動します。 開くとWorkFlowsというタブがあるのでそれを選択します。

f:id:kazumasaSS:20170615123440p:plain

続いて選択して移動したページにAdd new pipelineと書いてあるボタンがあるので選択します。

f:id:kazumasaSS:20170615123441p:plain

新しいpipelineのNameを入力します。今回はDeployフェーズの追加なので deploy と入力しましょう。 YML Pipeline Nameも同様で良いです。
Hook Typeですが、今回はBuildフェーズが通った後にDeployフェーズを実行するため Default を選択しましょう。 f:id:kazumasaSS:20170615124319p:plain 必要な項目を全て入力したら Create しましょう。
作成すると下記画像のようにdeployが追加されるので確認してみてください。

f:id:kazumasaSS:20170615133437p:plain

秘密鍵の設定

VPSにログインするために秘密鍵の設定をする必要があります。先ほどの画像の deploy をクリックして詳細のページに飛びます。
詳細のページに移動すると Generate SSH Keys というボタンがあるのでそれを押すと秘密鍵の生成ができます。

f:id:kazumasaSS:20170615123446p:plain

鍵の名前は自由でいいのですが、今回は DEPLOY_KEY とします。 RSAですが、2048と4096がありますが、どちらでも構いません。

f:id:kazumasaSS:20170615133937p:plain

Create を押すと公開鍵と秘密鍵のペアがこのように生成されます。
DEPLOY_KEY_PUBLIC は後でVPSの方で鍵を設定するのに必要なのでコピーしておきます。 f:id:kazumasaSS:20170615134741p:plain

VPS側の設定

VPSの方にSSH接続し、今回Deployする用のユーザーを作成します

#今回はdeploy用のユーザーはwerckerとします
$ adduser wercker

# wheelグループにwerckerを追加
$ gpasswd -a wercker wheel
$ su - wercker
$ cd ~/
$ mkdir .ssh

# ここで先ほどコピーした公開鍵を貼り付ける
$ vi .ssh/authorized_keys
$ chmod -R 700 .ssh
$ chmod 644 .ssh/authorized_keys

# deploy用のディレクトリの用意
$ mkdir /srv/rsync
$ chmod 755 /srv/rsync

これで一旦VPS側の設定は終わります。

wercker.ymlにDeployフェーズを追加

次にwercker.ymlを編集していきます。

box: golang
build:
    steps:
        - setup-go-workspace
#何かしらの処理(今回はBuildフェーズの詳細については省きます)

deploy:
  steps:
# デプロイするファイルの表示
    - script:
        name: deploy info
        code: find .
# VPSのIPもしくはドメインを入力しましょう
    - add-to-known_hosts:
        hostname: IPアドレスもしくはドメイン名
#ここでは先ほど登録した鍵の変数名を入力しましょう
    - add-ssh-key:
        keyname: DEPLOY_KEY

# 今回はrsyncというファイル同期ができるコマンドを使って転送します
    - install-packages:
        packages: rsync

# 転送
    - script:
        name: rsync
        code: rsync -azvv --delete -e "ssh -v -i $DEPLOY_KEY -o StrictHostKeyChecking=no -o UserKnownHostsFile=no" $WERCKER_ROOT/* wercker@ IPアドレスもしくはドメイン名 :/srv/rsync

以上でwercker.ymlの設定は終了です。

Buildフェーズが通ったらDeployフェーズが実行されるようにする

これまででほとんどの設定は終了しました。あとはBuildフェーズ後にDeployフェーズが実行されるようにすればいいだけです。
もう一度アプリケーションのページから WorkFlows のページに飛んでください。 WorkFlowsのページから下記画像のように+ボタンを押してpipelineを追加することができます。
これはWorkFlowと言って1つのCIのプロセスを複数のパイプラインに分割することのできる機能です。これを使ってbuildフェーズの後にdeployフェーズの追加をしてあげます。
on branch でDeployフェーズが実行されるブランチを決めることができます。今回はmasterにします。
Execute pipeline はdeployを選択しましょう。 f:id:kazumasaSS:20170615141419p:plain

これでGithubからmasterにpushされたらdeployされるようになりました。