2016年12月30日金曜日

AWS EC2 に GitLab をインストールする(メールの送信テスト編)

オフィス狛 技術部です。

前回 、AWS EC2 に GitLab をインストールしましたが、
メールの送信設定について補足しておきたいと思います。
GitLabでは、ユーザーを作成したり、ユーザー情報を更新したりすると、
該当のユーザーへメールが送信されます。
前回、メール送信の設定については説明しましたが、送信テストの実施方法について触れていませんでした。
実際にユーザーを作ったり、更新しないとメールのテストが出来ないのは不便すぎますからね。

メールテスト送信の手順

まずは、以下のコマンドで、コンソールを起動します。(起動まで、ちょっと時間掛かります)
sudo gitlab-rails console

続いて以下コマンドでメールをテスト送信します。
Notify.test_email('xxxx@hoge.co.jp', 'Message Subject', 'Message Body').deliver_now
はい、これだけです。
1番目の引数が、送信先のメールアドレス、
2番目の引数が、メールの件名、
3番目の引数が、メールの本文です。

これで送信出来ない場合は、どこか設定が間違っている、という事になります。


, , ,

2016年12月27日火曜日

AWS EC2 に GitLab をインストールする

オフィス狛 技術部です。

弊社は、今まで Git へのアクセス制御は Gitolite を使用していました。
それでも特に困ってはいなかったのですが、
Pull Request(Merge Request) による管理をしたい、というのと、
Slack との連携を簡単にしたい、という事で、
Amazon EC2(OS は Amazon Linux)に GitLab をインストールして、
今ある Git リポジトリを移行する事にしました。

以降がインストールの方法です・・・と言いたいところですが、
本家サイトに、丁寧にインストール方法が記載されているので、
本家サイトの補足を記載していこうと思います。

※本家サイトには Amazon Linux 用の説明が無く、
一番近いのが CentOS なので、その辺の違いも書いていきます。

1)必要な依存ライブラリのインストールと設定

(本家サイト: Install and configure the necessary dependencies)

本家サイトでは
sudo yum install curl policycoreutils openssh-server openssh-clients
sudo systemctl enable sshd
sudo systemctl start sshd
となっていますが、
Amazon Linux は既に該当プラグインが設定されているので、この手順はスルーします。

続いて、GitLab からのメール送信する為の設定になります。
本家サイトの通り、以下のコマンドでインストールを行います。
$ sudo yum install postfix

続いて、postfix を有効にします。
本家サイトでは、
sudo systemctl enable postfix
sudo systemctl start postfix
となっていますが、
Amazon Linux には既に sendmail がインストールされているので、
sendmail を無効にする必要があります。
$ sudo /etc/init.d/postfix stop
$ sudo /etc/init.d/sendmail stop
sm-client を停止中:                                        [  OK  ]
sendmail を停止中:                                         [  OK  ]
$ sudo /etc/init.d/postfix start
postfix を起動中:                                          [  OK  ]

ついでに、メールの自動起動設定を変更しておきます。
$ sudo chkconfig postfix on
$ sudo chkconfig sendmail off

続いて、MTAも切り替えます。
$ sudo alternatives --config mta

2 プログラムがあり 'mta' を提供します。

  選択       コマンド
-----------------------------------------------
*+ 1           /usr/sbin/sendmail.sendmail
   2           /usr/sbin/sendmail.postfix

Enter を押して現在の選択 [+] を保持するか、選択番号を入力します:2

念の為、設定の確認をしておきます。
$ alternatives --display mta
mta - ステータスは手動です。
リンクは現在 /usr/sbin/sendmail.postfix を指しています。

2)GitLab のインストール

(本家サイト: Add the GitLab package server and install the package)

ようやくGitLab のインストールです。ここは本家サイト通り進めます。
$ curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash
$ sudo yum install gitlab-ce

3)GitLab の設定と開始

(本家サイト: Configure and start GitLab)

後は、「gitlab-ctl reconfigure」して完了なのですが、
その前に、メールの設定を行っておきます。

※ ここからは、Amazon SES の設定が完了している事を前提とします。

以下のコマンドで、設定ファイルを開きます。
$ sudo vi /etc/gitlab/gitlab.rb
設定箇所は、本家サイトの SMTP setting - Amazon SES に詳しく書いてあります。

★その他、変更した箇所
SMTPの設定以外でも、external_url は自サイトのドメインへ、
gitlab_rails['time_zone'] はデフォルトが UTC になっているので、 Asia/Tokyo に変えました。

ここまでで、設定は完了したので、以下のコマンドで変更内容を反映させます。
$ sudo gitlab-ctl reconfigure

4)GitLab へログイン

(本家サイト: Browse to the hostname and login)

いざ、external_url に設定したURLに接続すると・・・


画面が表示されました。
デフォルトのユーザーが「root」で作られているので、
初めはそのユーザーでログインすることになります。
(まずはパスワード設定)

パスワードを設定してログインすると・・・・


おっと 502 エラーに。

調べて見ると、どうやらサーバーのメモリが足りないようです。

GitLab の構築には、1GBのメモリが推奨されているようなので、
EC2 インスタンスは「t2.small」にしたのですが・・・

とりあえず、「t2.medium」に変更した後、再度ログインしたところ上手くいきました。
(こういうスケールアップが簡単に出来るのが、AWS の良いところですね。)

ここまでで、インストール・設定・起動が完了したので、次回は、Git リポジトリの移行を行いたいと思います。

次回:AWS EC2 の GitLab へリポジトリを移行する


, , ,

2016年12月9日金曜日

Redmineのバージョンアップ 2.5 → 3.3 その2

オフィス狛 技術部です。

前回(Redmineのバージョンアップ 2.5 → 3.3 その1)でようやく前準備が出来たので、
今回は Redmine 自体のバージョンアップを進めて行きます。

1)Redmine の本体をダウンロード・配置

まず、本家サイトから、 redmine-3.3.1.tar.gz をダウンロードします。

Redmineのインストールディレクトリ( /var/lib )に展開します。
$ tar xvf redmine-3.3.1.tar.gz
$ sudo mv redmine-3.3.1 /var/lib/

ディレクトリを /var/lib へ移動します。
$ cd /var/lib

前バージョンの設定ファイルを新バージョンの config ディレクトリにコピーします。
$ cp -p redmine/config/configuration.yml redmine-3.3.1/config
$ cp -p redmine/config/database.yml redmine-3.3.1/config

前バージョンに添付したファイルを新バージョンへコピーします。
$ cp -pr redmine/files redmine-3.3.1

※今回はプラグインを前もって全て削除しているので必要ありませんが、
削除していない場合は、プラグインも新バージョンへコピーする必要があります。

※自分で追加したテーマも新バージョンでも使いたい場合はコピーする必要があります。
今回は、アップグレード後に改めてテーマを入れる予定なので、旧バージョンからの移行はしていません。

2)アップグレード

新バージョンのディレクトリに移動します。
$ cd /var/lib/redmine-3.3.1

インストールを実施します。
$ bundle install --without development test

ここでエラーが出ました。
Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native extension.
(中略)
/usr/bin/ld: -lmysqlclient が見つかりません
collect2: error: ld returned 1 exit status
make: *** [mysql2.so] エラー 1
(中略)
An error occurred while installing mysql2 (0.3.21), and Bundler cannot continue.
Make sure that `gem install mysql2 -v '0.3.21'` succeeds before bundling.

共有ライブラリが見つからない、と怒られています。
というわけで、共有ライブラリへのリンクを作ります。
$ sudo ln -s /usr/lib64/mysql/libmysqlclient.so.18.0.0 /usr/lib64/libmysqlclient.so

再度インストールを実行します。
$ bundle install --without development test
Your bundle is complete!
Gems in the groups development and test were not installed.
Use `bundle show [gemname]` to see where a bundled gem is installed.
今度は成功しました。

続いて鍵の生成を行います。
$ bundle exec rake generate_secret_token
rake aborted!
LoadError: incompatible library version - /home/ofkomamanage/.gem/ruby/2.0/gems/nokogiri-1.6.8.1/lib/nokogiri/nokogiri.so
またエラーになりました。

足りないライブラリがあるようなので、
ここで一度、必要なライブラリをインストールします。(パスの指定が必要です)
$ bundle install --path=vendor/bundle

再度、コマンド(鍵の生成)を実行します。
$ bundle exec rake generate_secret_token

3)データベースの更新

マイグレーションを行います。
$ bundle exec rake db:migrate RAILS_ENV=production

※今回はプラグインを前もって全て削除しているので必要ありませんが、
削除していない場合、以下のコマンドにてプラグイン分のマイグレーションも行う必要があります。
$ bundle exec rake redmine:plugins:migrate RAILS_ENV=production

4)クリーン

キャッシュとセッションのクリアを行います。
$ bundle exec rake tmp:cache:clear tmp:sessions:clear

5)Passenger のセットアップ

Passenger は、Rails を使って作られたWebアプリケーションをApacheで動かす為のモジュールです。
では、早速 Passenger をインストールします。
$ rbenv exec gem install passenger --no-rdoc --no-ri

セットアップを続けます。
$ passenger-install-apache2-module

Please edit your Apache configuration file, and add these lines:

   LoadModule passenger_module /home/officekoma/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/passenger-5.0.30/buildout/apache2/mod_passenger.so
   
     PassengerRoot /home/officekoma/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/passenger-5.0.30
     PassengerDefaultRuby /home/officekoma/.rbenv/versions/2.3.1/bin/ruby
   

Apacheの「conf.d」ディレクトリ内に、「passenger.conf」というファイルを作成し、
上記の「LoadModule passenger_module」以降の部分をそのまま貼り付けます。

6)Webサーバー(Apache)の設定変更と再起動

この辺は、各環境によって設定方法は変わってくると思いますが、
弊社の場合、Redmineが動いているサーバーでは、他のWebシステムは動いていません。
なので、DocumentRoot を「/var/lib/redmine/public」から、
「/var/lib/redmine-3.3.1/public」に直接変更し、再起動します。
$ sudo /etc/init.d/httpd restart

いざ接続してみると、「Internal Server Error」に・・・。
ログを確認してみます。
DEPRECATION WARNING: You didn't set `secret_key_base`. Read the upgrade documentation to learn more about this new config option. (called from validate_secret_key_config! at /home/officekoma/.gem/ruby/2.0/gems/railties-4.2.7.1/lib/rails/application.rb:530)

Secret Key を設定しなくてはいけないようです。
$ rake secret
上記コマンドを実行すると、長い文字列が表示されるので、それをコピーしておきます。
そして、下記コマンドで Secret Key 設定ファイルを開きます。
$ vi /var/lib/redmine-3.3.1/config/initializers/secret_token.rb

下記「xxxxxxxxx」の部分を先程コピーした Secret Key で置き換えます。
RedmineApp::Application.config.secret_key_base = 'xxxxxxxxx'
これでエラーは出なくなりました。

長い道のりでしたが、これでRedmineのバージョンアップは完了です。
(これでも思ったよりはスムーズに行きました。)
後はしばらく稼働させて様子見です。

2016年12月8日木曜日

Redmineのバージョンアップ 2.5 → 3.3 その1

オフィス狛 技術部です。

弊社のRedmineは、平日は終日使用されていて、
バージョンアップを行うタイミングは土日に限られてしまうのですが、
以前実施した時に、見事に失敗して、そこからずっと再実施するタイミングがありませんでした。

今回、ようやく実施出来るタイミングを作れたので、
今度は成功するまで頑張ってみようと思います。

1)作業前バックアップ

弊社Redmineは、AWS(Amazon Web Services)上に構築しているので、
作業前のバックアップも、各データごとに取得する訳ではなく、
マシンイメージ(AMI)ごと取得しています。
よって、細かいバックアップの手順は記載しません。
必要であれば、本家サイトを参照して下さい。

2)バージョンアップ前準備(プラグインの削除)

プラグインがRedmineの新しいバージョンに対応していないと、
バージョンアップに失敗する事がある、と聞いていたので、
念の為、プラグインは削除しておこうと思います。

現在使用しているのは以下の二つです。(思ったより少なかった)

Parent issue filter plugin (parent_issue_filter)
 →チケットを親チケットでフィルタ出来るプラグインです。
  Redmineの3.1から、プラグインなしでも親チケットによるフィルタが実装されたようなので、
  このプラグインは削除しようと思います。

Redmine Gantt With Date plugin (redmine_gantt_with_date)
 →ガントチャートに日付を表示するプラグインです。
  こちらはRedmine3.2からプラグインなしでも日付が表示されるようになったようなので、
  このプラグインも削除しようと思います。

削除は、下記のコマンドを実行します。
$ rake redmine:plugins:migrate  NAME=xxxxxx VERSION=0 RAILS_ENV=production
「xxxxxx」の部分に、プラグインの名称を設定します。

例えば、Parent issue filter pluginを削除する際は、
$ rake redmine:plugins:migrate  NAME=parent_issue_filter VERSION=0 RAILS_ENV=production
というコマンドを実行します。

ちなみに、上記コマンドは「Rakefile」が存在する場所で実行する必要があります。
(「Rakefile」はRedmineのHomeディレクトリに存在します。)
「Rakefile」が無いと、以下のようなエラーメッセージが出ます。
rake aborted!
No Rakefile found (looking for: rakefile, Rakefile, rakefile.rb, Rakefile.rb)
また、コマンドを実行した後、
$ rm -rf [Redmine HOME]/plugins/parent_issue_filter
というコマンドを実行する事で。実体のファイルも削除する必要があります。
※[Redmine HOME]は適宜環境によって書き換えて下さい。

3)バージョンアップ前準備(Rubyのバージョンアップ)

Redmine 3.3 から、Ruby 2.3 に対応しているようなので、Rubyもバージョンアップしようと思います。
(EC2でインスタンス作成時、Amazon Linuxの場合、Ruby2.0がインストール済みとなってるので、
「rbenv」を使用して、バージョン2.3をインストールします)

rbenvは、GitHubからクローンする必要があるので、gitがインストールされていない場合はインストールします。

$ sudo yum install git

※弊社は、同一インスタンスでGitのリポジトリも管理しているので、gitはインストールしてある状態でした。
・・・この同一インスタンス内で色々なシステムを導入しているのが、今回のバージョンアップになかなか踏み切れなかった要因です。

gitがインストール済みかどうかは、下記のコマンドで確認できます。
$ yum list installed | grep 'git'

さて、rbenvのインストールのやり方は、
https://github.com/rbenv/rbenv#installation
の通りに実行していくだけです。
(homeディレクトリで実施するのが良さそうです)

Githubからチェックアウト。
$ git clone https://github.com/rbenv/rbenv.git ~/.rbenv

環境設定ファイルにパスを追加。
$ echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bash_profile

initコマンドを呼び出すように設定します。
$ echo 'eval "$(rbenv init -)"' >> ~/.bash_profile

パスの変更を有効する為に、一度ターミナルの接続を切り、再接続します。

動作確認は以下のコマンドで行います。
$ rbenv -v

rbenvは、rubyのバージョン切り替えツールなので、
次はrubyのインストールを簡単にするプラグイン(ruby-build)をインストールします。
$ git clone git://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build

以下のコマンドで、インストール可能なバージョンを確認します。
$ rbenv install -l

現時点(2016/11/12)最新安定版のバージョン 2.3.1 をインストールします。
$ rbenv install 2.3.1

ここでエラーが出ました。
Downloading ruby-2.3.1.tar.bz2...
-> https://cache.ruby-lang.org/pub/ruby/2.3/ruby-2.3.1.tar.bz2
Installing ruby-2.3.1...

BUILD FAILED (Amazon Linux AMI 2016.09 using ruby-build 2016xxxx-xx-xxxxxxxxx)

Inspect or clean up the working tree at /tmp/ruby-build.2016xxxxxxxx.xxxxx
Results logged to /tmp/ruby-build.2016xxxxxxxx.xxxxx.log

Last 10 log lines:
installing rdoc:              /home/officekoma/.rbenv/versions/2.3.1/share/ri/2.3.0/system
installing capi-docs:         /home/officekoma/.rbenv/versions/2.3.1/share/doc/ruby
The Ruby readline extension was not compiled.
ERROR: Ruby install aborted due to missing extensions
Try running `yum install -y readline-devel` to fetch missing dependencies.

Configure options used:
  --prefix=/home/officekoma/.rbenv/versions/2.3.1
  LDFLAGS=-L/home/officekoma/.rbenv/versions/2.3.1/lib 
  CPPFLAGS=-I/home/officekoma/.rbenv/versions/2.3.1/include

ここはエラーメッセージの通り、
$ sudo yum install -y readline-devel
を実行し、その後無事にインストール成功しました。

インストールに成功したところで、バージョンを切り替えます。
まずは、現在の選択されているRubyのバージョンを確認します。
$ rbenv versions
* system (set by /home/officekoma/.rbenv/version)
  2.3.1
systemが選択されています・・・バージョンが分からない、という事で、
$ ruby -v
ruby 2.0.0p648 (2015-12-16) [x86_64-linux]
現在選択されているのは「2.0」だということが分かりました。

さて、バージョンを変えてみます。
$ rbenv global 2.3.1
再度、現在の選択されているRubyのバージョンを確認します。
$ rbenv versions
  system
* 2.3.1 (set by /home/ofkomamanage/.rbenv/version)

$ ruby -v
ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-linux]
現在の選択バージョンが「2.3.1」になりました。

ようやく、Redmineのアップグレードですが・・・長くなってきたので、次回に持ち越します。

次回:Redmineのバージョンアップ 2.5 → 3.3 その2


2016年12月4日日曜日

Raspberry Pi 3 でウォッチドッグタイマーを使った自動再起動。


オフィス狛 技術部です。

IoT関連のプロジェクトでは、多く使われている Raspberry Pi 。
弊社でも、BLEソリューションや、その他実証実験などで、使っています。

Raspberry Pi 3 になって、性能も良くなっているのですが、
たまに不安定になって、フリーズしてしまう事があります。

メモリ不足になっているとか、要因は色々あるのですが、
常時稼働すべき用途の場合、フリーズしてしまうのは困ってしまいます。

と言う事で、ウォッチドッグタイマーの出番です。

ウォッチドッグタイマーとは

メインのプログラムがハングアップなどの不正な状態に陥ってしまい、規則的なウォッチドッグ操作(「犬をなでる」とも呼ばれる「サービスパルス」の書き込み)が行なわれなかった(タイムアウト)場合に、例外処理が実行される。例外処理は、ハングアップしたシステムを正常動作に戻すことを目的としてシステムをリセットする場合が多いが、電源切断によりシステムを強制停止させるものや電源を切断した後に再投入するものもある。
タイマーはソフトウェアではなく、ハードウェアを用いる。これは、ソフトウェアで実装してしまうと、ソフトウェア自体が故障した際にタイマーの役割を果たさなくなったり、リセット信号を発生できなくなってしまう恐れがあるためである。
障害を引き起こした問題のデバッグに役立つ情報などを媒体に保存する機能を持つ場合、ウォッチドッグタイマーはより複雑なこともある。たとえば、最初のウォッチドッグタイマーのタイムアウトによって開始された情報の保存処理がある時間内に完了しなかった場合、情報が保存されていてもいなくても、2番目のシンプルなウォッチドッグタイマーがシステムを確実にリセットさせる。ウォッチドッグタイマーが最も多く使われているのは組み込みシステムで、マイクロコントローラに内蔵されていることも多い。
「ウォッチドッグタイマー」『フリー百科事典 ウィキペディア日本語版』より。
2016年3月21日 (月) 08:29‎ UTC
URL: https://ja.wikipedia.org/wiki/ウォッチドッグタイマー

ウォッチドッグタイマーのインストールと設定

以降のコマンドは、root権限で実行してください。
(「su」でrootになるか、「sudo」をコマンドの頭に付ける)
また、OSは「Raspbian Jessie Kernel version:4.4」を想定しています。

以下のコマンドで、watchdogをインストールします。
$ apt-get install watchdog

サービスの登録を行う為に、「watchdog.service」ファイルを編集します。
$ vi /lib/systemd/system/watchdog.service
※「[Install]」の下に下記を追加して、保存後、ファイルを閉じます。
WantedBy=multi-user.target

自動起動設定を行います。
$ update-rc.d watchdog enable

カーネルモジュールをロードします。
$ modprobe bcm2708_wdog

watchdog.conf の編集を行います。
$ vi /etc/watchdog.conf
※以下の部分のコメントを外し、保存後、ファイルを閉じます。
#watchdog-device = /dev/watchdog

/etc/default/watchdog の編集を行います。
$ vi /etc/default/watchdog
※watchdog_module="none"の「none」を「bcm2708_wdog」に変え、保存後、ファイルを閉じます。

再起動します。
$ reboot

再起動後、以下のコマンドを実行し、自動で再起動すればOKです。
$ :(){ :|:& };:

今回、下記サイトを参考にしたのですが、ちょっと情報が古かったり、やり方がサイトによって微妙に異なっていたりしたので、
Raspberry Pi 3 の「Raspbian Jessie Kernel version:4.4」で、問題なく動作した方法を記載しています。

【参考】
http://ivis-mynikki.blogspot.jp/2015/03/raspberry-pi.html
http://ecoday.jp/881/raspberry-pi-2-にウォッチドッグタイマーを導入する%E3%80%82/
http://machiawasepoint.com/raspberry-pi-jessieにwatchdogをインストール/