内定先のインターンでTAをしてきた話

今日は内定先で行われたインターンでTAをしてきたのでTA業で思ったことについて書いていきたいと思います。 読者が今度どこかのイベントなどでTAなどをするときに参考にしてもらえると幸いです。

はじめに

僕は内定先であるVOYAGE GROUPで行われるTreasureというインターンに参加してきました。 Treasureは「Go言語を使って学ぶ、価値のあるもの創りとチーム開発」をテーマとして3週間でユーザーにとって価値あるサービスをトップエンジニアのサポートを受けつつ開発します。インターンについての詳しいことは下記のリンクに書いてあるので割愛します。 今回僕はTreasureの中でも前半8日間で行われるトップエンジニアによる講義のTAをしてきました。僕自身去年のTreasureに参加しています。 TAとして参加したのも去年の経験からTreasure参加生にとってかけがえのない経験をするサポートをしたいという思いがあったからというのもあります。 voyagegroup.com

基本的な業務内容

TAとしての基本的な業務は前半に行われる講義の内容に関して参加者がわからないところがあった場合や演習の際に詰まったときにサポートをして参加者が滞りなく講義を受けれる状態にすることです。

講義について

Treasureの講義内容としては

1日目 ~ 3日目 Goの講義 by @suzu_v

4日目 Web APIの講義 by @gomachan46 @brtriver

5日目 中間課題

6日目 中間課題の発表、セキュリティの講義 by @co3k

7日目 データベースの講義 by @hironomiu @larufa @takeru0911

8日目 チーム開発の講義 by @katzchang @ara_ta3

となっています

Web APIの講義は公開されています speakerdeck.com

わからなくてもなかなか質問できない子がいる

Treasureの参加者には様々なバックグラウンドの人がいるので、人によってスッと理解できる子もいれば初めて聞く内容だという子もいます。 こちらとしてはわからなかったら気軽にTAに質問してくださいと言っていますが、なかなか質問できない子はいます。また、わからないことがわからないという子も一定層いるのでそういう子たちが置いていかれないようにTAがサポートしてあげる必要があります。具体的には

参加者に「今何してるの?」って声をかけてみる

定期的に参加者のことを見回るのもいいのですが、参加者が警戒していて質問できない場合もあるのでこちらから警戒をといてあげるという意味で気軽に声をかけてみると意外と詰まっていたりします。

わからなくても一緒に悩んで解決方法を探す

TA自身も人なので質問された内容全てに対して答えられない場合もあると思います。そういう場合はわからないと突き放すのではなく、質問者と一緒に調べたり、解決策を探ることで少しでも質問者の不安を解消してあげましょう。 相談に気軽に乗る姿勢 ってすごい大事だと思いました。

講師に参加者の状況を報告する

講義を受けている人数が多いとどうしても参加者側からの反応が薄かったりするので、TAが講師にどのくらい参加者が理解しているかなどを都度報告してあげることで講義がより良いものになると思いました。また、前もってTAには次の講義内容を伝えておくことで講義全体を把握しつつ、詰まりそうなポイントがわかるのでサポートしやすく講義がスムーズになるのではないかと思いました。

さいごに

色々ありましたが、Treasure参加生にとって最高の3週間になって欲しいです。また、今後Treasureに応募しようとしている人も、僕たちVOYAGE GROUPのクルーは参加者にとってかけがえのない経験になるよう全力を尽くしているので是非受けてみてください。

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 -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されるようになりました。

追記

デプロイ用に作ったユーザーのロックされているとデプロイできないです。

passwd -S デプロイ用のユーザー

passwdコマンドでユーザーがロックされていないか確認して見ましょう