2015年5月26日火曜日

RedmineとGitLabの連携。PushでチケットのStatusを変更

gitlab_redmineRedmineとGitLabのプロジェクトを連携させたときの覚書。

環境: CentOS 6.6, Redmine 3.0.3, GitLab 7.10.4

 

目次

  1. RedmineのプロジェクトにGitのリポジトリを指定
  2. GitLabの「Redmine issue tracker」を有効
  3. GitLabにWeb hooksを設定してPushと同時にRedmineへ通知
  4. 「匿名ユーザー」になるのを調査
  5. 「redmine_github_hook」プラグインをインストール
  6. 原因はTortoiseGitの設定

 


1.RedmineのプロジェクトにGitのリポジトリを指定

GitLabは内部でBareリポジトリとして管理しているので、このパスを指定するだけ。

Redmine → (プロジェクト) → 設定 → リポジトリ → 新しいリポジトリ

リポジトリのパスは
/var/opt/gitlab/git-data/repositories/suganuma/hoge-web.git
のような感じ。

登録後は「リポジトリ」で履歴を参照できる。

image

 


2.GitLabの「Redmine issue tracker」を有効

公式Wikiを参考に。

GitLabにrootでログイン後、
Admin area → Service Templates → Redmine

Active: Check
Description: Redmine issue tracker
Project url: http://dev.hoge.jp/projects/[project_id]
Issues url: http://dev.hoge.jp/issues/:id
New issue url: http://dev.hoge.jp/projects/[project_id]/issues/new

あとは各プロジェクトのSettings → Services → Redmineで[project_id]を置き換える。

これでコミットログに「#123」とチケット番号を書くとGitLabからRedmineへ自動リンクが生成される。

 


3.GitLabにWeb hooksを設定してPushと同時にRedmineへ通知

GitLabにPushするとRedmineのチケットと自動連携する機能

まずはRedmineの管理画面で受け取る準備。

管理 → リポジトリ

下記のように設定。APIキーを生成しておく。

image

「参照用キーワード」はアスタリスク(*)を追加しておくと便利。

 

次はGitLabのプロジェクトの設定

Settings → Web Hooks

URLにRedmineの通知用URLを入力して「Add Web Hook」

  • http://redmine.hoge.jp/sys/fetch_changesets?key=(API Key)

試しに「完了しました。fixed #884 @3h」とコミット&プッシュすると下記のように反映される。

image

なぜか「匿名ユーザー」。作業時間も反映されない。
→ TortoiseGitの設定だった。

さらにCustom Git Hooksを利用するとRubyスクリプトでいろいろ出来る。

 


4.「匿名ユーザー」になるのを調査

ログを見るとログイン処理が走っているように見える。
# less /opt/redmine/log/production.log

Processing by WelcomeController#index as */*
Settings cache cleared.
  Current user: anonymous
Redirected to http://redmine.hoge.jp/login?back_url=http%3A%2F%2Fredmine.hoge.jp%2F
Filter chain halted as :check_if_login_required rendered or redirected
Completed 302 Found in 4ms (ActiveRecord: 0.5ms)
TimeEntry could not be created by changeset 408: ["ユーザー を入力してください。"]
  Rendered text template (0.0ms)

「omniauth」プラグインを使ってGoogleアカウントでログイン出来るようにしているのが原因かもしれない

 


5.「redmine_github_hook」プラグインをインストール

GitHubと連携するプラグインがあるのでインストールして試す。

# cd /opt/redmine/plugins/
# git clone git://github.com/koppen/redmine_github_hook.git

Redmine再起動
# /etc/rc.d/init.d/redmine restart

GitLabのWeb hooksを変更 → Pushしてみても結果は同じ「匿名ユーザー」

 


6.原因はTortoiseGitの設定

再度ログを見るとコミットのauthorとして送信しているのがTortoiseGitに登録してある名前であることに気付いた。これを修正。

右クリック → TortoiseGit → Settings Git → Edit global .gitconfig

NameとEmailをGitLabに登録してある情報と合わせる。

これでPushしてみるとユーザーが正しく表示されて作業時間も反映された。

「redmine_github_hook」プラグインは削除して3の方法に戻した。

 

< Related Posts >

2015年5月25日月曜日

既存のディレクトリ(フォルダ)にgit cloneして上書きしたい

git_cloneSubversionのリポジトリをGitLabに移行後、今まで開発していたフォルダでgit cloneしてみるとエラー。

fatal: destination path 'api' already exists and is not an empty directory.

環境: CentOS 6.6, git 1.7.1

 

一旦フォルダごと削除して、git cloneし直せばいいのだけれど、権限の設定や本番環境でも削除してgit cloneはやりたくない。

gitの仕組みを理解すれば簡単なことだった。

腑に落ちるまで時間がかかった。

 


<2015/07/06 Modified>
実機コンソールでコマンド実行すること。Windowsから共有ファイル経由で実行すると時間が掛かり過ぎる(失敗する)。

本番環境でブランチとマージしたときに実行したコマンド
# cd /path/to/project/
# git init
# git remote add origin git@gitlab.hoge.jp:suganuma/project-wordpress.git
# git fetch origin
# git checkout -b branch-name
# git checkout origin/branch-name -- .gitignore
# git add --all
# git add -f wp-config.php
# git merge origin/branch-name

エラーになったらブランチ上のファイルで上書き。移行した直後ならこれをやらなくてもいいはず。
# git checkout origin/branch-name -- /path/to/file

# git merge origin/branch-name

svnとお別れする
# rm -rf .svn/


< 2016/03/31 追加 >
上のやり方でマージできなかったので「theirs」を使った方法

途中までは一緒
# cd /path/to/project/
# git init
# git remote add origin git@gitlab.hoge.jp:suganuma/project-wordpress.git
# git fetch origin
# git checkout -b branch-name
# git checkout origin/branch-name -- .gitignore

何かあった時でも戻せるように一度コミット
# git add --all
# git commit -m 'Before convert to git'

リポジトリを優先で更新。最後の「.」(ドット)がポイント
# git checkout --theirs origin/branch-name .

コミット
# git commit -m 'Merge with branch-name'

git pullできるようにしておく
# git branch --set-upstream-to=origin/branch-name branch-name

確認
# git pull

コミットを一つにまとめる
# git rebase -i

やっぱりフォルダを削除してgit cloneした方が早い。権限の設定が必要なら別ファイルにまとめておく。


 

まずは開発ディレクトリをgitローカルリポジトリにする
# cd /path/to/project/
# git init

「origin」という名前でリモートリポジトリを追加
# git remote add origin git@gitlab.hoge.jp:suganuma/project-api.git

ローカルリポジトリを最新にする
# git fetch origin

確認
# git branch -a

「origin/master」とマージする
# git merge origin/master

確認
# git branch -a

ローカルリポジトリが「master」ブランチになっているはず。

試しにファイルを追加してみる
# vi test.txt
# git status

# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       .svn/
#       test.txt
nothing added to commit but untracked files present (use "git add" to track)

ファイルをローカルリポジトリに追加
# git add test.txt
# git status

# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   test.txt
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       .svn/

なかったことにする
# git reset
# git status

# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       .svn/
#       test.txt
nothing added to commit but untracked files present (use "git add" to track)

git resetに関しては下記記事がわかりやすい。

 


Mac上にあるTitaniumプロジェクトでmergeしようとしたらエラー。

環境: OS X Yosemite 10.10.3, git 2.3.2 (Apple Git-55)

$ git merge origin/master

error: Untracked working tree file 'CHANGELOG.txt' would be overwritten by merge.
fatal: read-tree failed

svnからそのまま変換しただけなので一緒のはず。

まずは.gitignoreを作成
$ vi .gitignore

/.project
/.settings
/.svn
/build
/node_modules

確認
$ git status

追加してマージ
$ git add --all
$ git merge origin/master

確認
$ git status

svnコマンドも使える
$ svn status

.gitignoreをコミット
$ git commit -m 'add files for git'

アカウントを確認してプッシュ
$ git config --list
$ git push origin master

 


< 2015/06/05 Modified >

別プロジェクトで下記エラーになったとき。

$ git add --all
$ git merge origin/master

error: Entry '.gitignore' would be overwritten by merge. Cannot merge.
fatal: read-tree failed

ブランチ作成
# git checkout -b develop

developにコミット
# git commit -m 'add files for merge'

masterに切り替え
# git checkout master

確認
# git status

この状態がmasterと同期している。

developにある「.gitignore」を取ってきて、プッシュ。
# git checkout develop -- .gitignore
# git commit -m 'modified .gitignore'
# git push origin master

無事完了。developブランチは削除してもいいはず。

試しにこの状態でdevelopブランチとマージしてみた。
# git merge --no-ff develop

コンフリクトがいっぱい。。。するんじゃなかった。。。

ファイルは一緒のはず。

たぶんssh経由のCentOS上でgitコマンド叩いたのと共有ファイル経由でWindowsからgitコマンド叩いてたので、ファイルの権限が変わったからだと思う。

svnが残っているのでそっちで差分を確認。git diffでもok。
# svn status

変更(コンフリクト)になっていたのを修正してadd
# git add --all
# git status

すると(内容を)変更したファイルだけになった。一安心。これでプッシュ
# git commit -m 'merge with develop'
# git push origin master

GitLab上は下図のようになった。最後のコメントを「merge with subversion」とすれば分かりやすかったと思う。

image

developブランチは削除
# git branch -d develop

 

< Related Posts >

2015年5月22日金曜日

SubversionからGit(GitLab)へ移行

subversion_gitメインの開発はGitに移行したときの覚書。

一つのsvnリポジトリでドキュメント、Web・アプリ用のソースコードを管理していたので、コードの部分だけGitに移行してドキュメントはSubversionに残す。

目標はGitHub Flowの実現。

クライアント環境: Windows 8.1 x64, Git-1.9.5-preview20150319, TortoiseGit-1.8.14.0-64bit
サーバー環境: CentOS 6.6, Ruby 2.2.2, Git 2.4.1, GitLab 7.10.4

 

参考

 

目次

  1. 移行しやすいようにsvnリポジトリのディレクトリ構成を変える
  2. GitLabに移行先プロジェクト作成
  3. svnユーザーとgitユーザーのマッピングファイルを作る
  4. Subversionリポジトリから変換(git svn clone)
  5. Subversionリポジトリから変換(svn2git)
  6. GitLabにPush

 

 


1.移行しやすいようにsvnリポジトリのディレクトリ構成を変える

1つのリポジトリでドキュメント、ウェブ、アプリを管理していたので、ブランチも多階層になってた。

「git svn init --ignore-paths="(/hoge)"」などで頑張ったけど、うまい正規表現が書けなかったので、ウェブとアプリでsvnリポジトリを分けて、git svnしやすいリポジトリに変更することにした。

まずは元のリポジトリをコピー
# cd /home/svn/Repositories/
# svnadmin hotcopy hoge_project/ hoge_project_web --clean-logs
# chown apache. -R hoge_project_web/

あとはTortoiseSVNのリポジトリブラウザで削除したりコピーしたりする。

 


2.GitLabに移行先プロジェクト作成

GitLabでプロジェクトを新規作成しておく。

GitLabのインストールは前の記事を参考に。

 


3.svnユーザーとgitユーザーのマッピングファイルを作る

ユーザー一覧のファイルを出力する。適当なsvn checkoutしている開発環境で下記コマンドを実行。
# svn log ^/ --xml | grep -P "^<author" | sort -u | perl -pe 's/<author>(.*?)<\/author>/$1 = /' > users.txt

出力されたユーザー一覧をコピーしてきて編集。

daiki = suganuma <suganuma@hoge.jp>

 

 


4.Subversionリポジトリから変換(git svn clone)

svn2gitを使うことにしたので、この章はただのログ。

Windows上でGit Bashを起動して作業用フォルダに移動
$ cd /d/Documents/Projects/GitLab/

svn initして変換先の準備
$ git svn clone http://svn.hoge.jp/repos/hoge_project_web/ --no-metadata --trunk=trunk/source_web --authors-file=users.txt --prefix=origin/ --stdlayout hoge_project_web

削除した分までログを取得しているみたいで処理に時間がかかる。

タグの変換
$ cd hoge_project_web
$ git for-each-ref refs/remotes/tags | cut -d / -f 4- | grep -v @ | while read tagname; do git tag "$tagname" "tags/$tagname"; git branch -r -d "tags/$tagname"; done

ブランチの変換
$ git for-each-ref refs/remotes | cut -d / -f 3- | grep -v @ | while read branchname; do git branch "$branchname" "refs/remotes/$branchname"; git branch -r -d "$branchname"; done

確認
$ git branch -a
$ git tag -n

タグがブランチになっている。

svn2gitを使うといい感じに変換してくれそうだったのでこちらを試すことにした。

 


5.Subversionリポジトリから変換(svn2git)

インストール方法は公式サイトを参考に。

GitLabがインストールされたサーバーで実行した。Rubyのインストールは前の記事を参考に。

作業ディレクトリを作る
# mkdir /home/svn
# cd /home/svn

インストール
# gem install svn2git

ユーザーの変換ファイルを作る
# vi users.txt

オプションの詳細は公式サイトを参考に。

# mkdir hoge_project_web
# cd hoge_project_web

タグが必要ない場合
# svn2git http://svn.hoge.jp/repos/hoge_web/ --authors ../users.txt --trunk trunk/source_web --notags

途中で止まった。「commnad failed: git gc」あるのでやってみる。
# git gc

移行自体は成功した様子。

確認
# git branch -a
# git tag -n

削除したはずの余計なブランチがあるので削除
# git branch -d hoge

マージしてないブランチを強制的に削除
# git branch -D hoge

「svn」リモートブランチは気にしない

@のついたタグを削除
# git tag -l | grep @ | xargs git tag -d

関係ないタグを削除
# git tag -l | grep source_hoge | xargs git tag -d

 


6.GitLabにPush

GitLabにPushするためにSSHの設定

Windowsで作成したプライベートキーを変換するツールのインストール
# yum install putty

プライベートキーをid_rsa.gitlab.ppkとして保存。OpenSSH形式に変換
# cd ~/.ssh/
# puttygen id_rsa.gitlab.ppk -O private-openssh -o id_rsa.gitlab
# chmod 600 ~/.ssh/id_rsa.gitlab

SSH Configの設定
# vi config

Host gitlab.hoge.jp
        HostName gitlab.hoge.jp
        User git
        IdentityFile ~/.ssh/id_rsa.gitlab
        Port 22

GitLabのプロジェクトをリモートリポジトリとして追加
# git remote add origin git@gitlab.hoge.jp:suganuma/hoge-web.git

確認
# git remote -v

Push
# git push origin --all
# git push origin --tags

GitLab上で確認

 

< Related Posts >

2015年5月21日木曜日

WindowsにGitの環境を構築(msysGit + TortoiseGit)してGitLabにPush

windows8_gitWindowsにGitの環境を構築して、GitLabにPushするまでの覚書。

環境: Windows8.1 x64

 

目次

  1. msysGit(Git for Windows)をインストール
  2. TortoiseGitをインストール
  3. 公開鍵を生成してGitLabに登録
  4. TortoiseGitでCloneしてPushしてみる

 


1.msysGit(Git for Windows)をインストール

Gitの公式サイトmsysGitのページからダウンロードする。どちらも同じ。歴史的な理由で「msysGit」となっているだけ。

インストール時に選択した項目

  • Use Git from Git Bash only
  • Checkout as-is, commit as-is

 


2.TortoiseGitをインストール

公式サイトからダウンロード。

 


3.公開鍵を生成してGitLabに登録

Windowsキーを押して「puttygen」と入力するとTortoiseGitと一緒にインストールされた「Putty Key Generator」が出てくる。

「Generate」→ (パスフレーズなしで)「Save private key」

GitLabへログイン後、Profile → SSH Keys → Add SSH Key

登録するとgitユーザーのホームディレクトリになっている
/var/opt/gitlab/

.ssh/authorized_keys
が作られる。

これでgitユーザーでSSHログインが可能になった。

 


4.TortoiseGitでCloneしてPushしてみる

GitLabにテスト用「hello-world」プロジェクトを作成。

Windowsエクスプローラーの適当なフォルダで右クリック → Git Clone...

GitLabに表示されているSSHアドレスをURLに入力。

「Load Putty Key」に先ほど生成したSSHプライベートキーを指定。

Clone完了。

「README.mb」を作ってCommit → Push

成功すればGitLabでも確認できる。

 

 

< Related Posts >

2015年5月20日水曜日

RedmineとGitLabにGoogle Appsアカウントでログイン

google-account_redmine_gitlabGitLabを導入してRedmineのアカウントと連携するために、両方Google Appsのアカウントでログイン出来るように設定したときの覚書。

環境: CentOS 6.6, Redmine 3.0.3, GitLab 7.10.4

 

目次

  • Redmineにプラグインをインストール
  • GitLabで「omniauth」を有効にする

 


1.Redmineにプラグインをインストール

プラグインのサイトにしたがってインストールと設定。

こちらは古いのでRedmine 3.0に対応しているのを使う

# cd /opt/redmine/plugins
# git clone https://github.com/yamamanx/redmine_omniauth_google.git
# cd ../
# bundle install --without development test

再起動
# /etc/rc.d/init.d/redmine restart

管理者でログインして
プラグイン → Redmine Omniauth Google plugin
Google Developers Consoleで取得した値を入れる。

Available domains: (ログイン制限したいドメイン)
Oauth authentification: (チェック)

これでGoogle Appsにログインした状態でログイン画面の「Login via Google」ボタンをクリックすると認証後にログインする。

すでにメールアドレスが登録されていればそのユーザーでログインする。

 


2.GitLabで「omniauth」を有効にする

GitLabは設定ファイルを編集すればいい。詳しくは前の記事を参考に。

 

< Related Posts >

2015年5月19日火曜日

CentOSにGitLabをInstallして設定

gitlab前回前々回でRedmineのインストールまで出来たので、今回はGitLabをインストール。

環境: CentOS 6.6 x86_64, Ruby 2.2.2, Git 2.4.1, GitLab 7.10.4

 

目次

  1. GitLabのインストール
  2. 設定:接続URLを変更
  3. 設定:Google Appsアカウントでログイン出来るようにする(omniauth)
  4. 設定:MariaDBを使う。GitLab付属のPostgreSQLを使う
  5. 設定:メール送信はGoogle Appsアカウント経由にする
  6. 設定:GitLab付属のUnicornを使う
  7. 設定:GitLab付属のRedisを使う
  8. 既存のNginxからプロキシする
  9. GitLab再設定、起動

 


1.GitLabのインストール

公式ページを参考に。

必要なパッケージのインストール
# yum install openssh-server postfix cronie

全てインストール済み。postfixも起動している状態。

GitLabのレポジトリを追加
# curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | bash

YUM経由でインストール
# yum install gitlab-ce

設定
# gitlab-ctl reconfigure

エラー

[2015-05-14T18:40:00+09:00] ERROR: Running exception handlers
Running handlers complete
[2015-05-14T18:40:00+09:00] ERROR: Exception handlers complete
[2015-05-14T18:40:00+09:00] FATAL: Stacktrace dumped to /opt/gitlab/embedded/cookbooks/cache/chef-stacktrace.out
Chef Client failed. 81 resources updated in 23.560077797 seconds
[2015-05-14T18:40:00+09:00] ERROR: Chef::Exceptions::MultipleFailures
[2015-05-14T18:40:00+09:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)

どうやら設定が必要らしい。

/etc/gitlab/gitlab.rbを読みながら編集していく。

 


2.設定:接続URLを変更

external_url 'http://gitlab.hoge.jp'

 

 


3.設定:Google Appsアカウントでログイン出来るようにする(omniauth)

ドキュメントを参考にapp_idとapp_secretを取得する

gitlab_rails['omniauth_enabled'] = true
gitlab_rails['omniauth_allow_single_sign_on'] = true
gitlab_rails['omniauth_block_auto_created_users'] = true
gitlab_rails['omniauth_providers'] = [
  {
    "name" => "google_oauth2",
    "app_id" => "123-abc.apps.googleusercontent.com",
    "app_secret" => "****",
    "args" => { "access_type" => "offline", "approval_prompt" => "", "hd" => "hoge.jp" }
  }
]

 

「hd」はログインを制限するGoogle Appsドメインを指定する。

「omniauth_block_auto_created_users」は、登録後Block状態となるので、rootで「Unblock」する必要がある。

 


4.設定:MariaDBを使う。GitLab付属のPostgreSQLを使う

インストール済みのMariaDBを使うように設定する。

と思ったけど、MySQLを使えるのはEnterprise EditionだけでCommunity EditionはPostgreSQLだけだった。

postgresql['enable'] = true
postgresql['listen_address'] = nil
postgresql['port'] = 5432
postgresql['data_dir'] = "/var/opt/gitlab/postgresql/data"
postgresql['shared_buffers'] = "512MB"

 

 


5.設定:メール送信はGoogle Appsアカウント経由にする

gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.gmail.com"
gitlab_rails['smtp_port'] = 587
gitlab_rails['smtp_user_name'] = "info@hoge.jp"
gitlab_rails['smtp_password'] = "pass"
gitlab_rails['smtp_domain'] = "smtp.gmail.com"
gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_enable_starttls_auto'] = true
# gitlab_rails['smtp_tls'] = false
# gitlab_rails['smtp_openssl_verify_mode'] = 'none'

 


6.設定:GitLab付属のUnicornを使う

RedmineのUnicornを使いまわそうか迷ったけど、とりあえずGitLab付属のUnicornを使うようにする。

unicorn['worker_timeout'] = 60
unicorn['worker_processes'] = 2

## Advanced settings
unicorn['listen'] = '127.0.0.1'
unicorn['port'] = 8080
unicorn['socket'] = '/var/opt/gitlab/gitlab-rails/sockets/gitlab.socket'
unicorn['pidfile'] = '/opt/gitlab/var/unicorn/unicorn.pid'
unicorn['tcp_nopush'] = true
unicorn['backlog_socket'] = 1024
# We do not recommend changing this setting
# unicorn['log_directory'] = "/var/log/gitlab/unicorn"

 


7.設定:GitLab付属のRedisを使う

redis['enable'] = true
redis['username'] = "gitlab-redis"
redis['uid'] = nil
redis['gid'] = nil

 


8.既存のNginxからプロキシする

GitLab付属のnginxは起動しないように設定。

nginx['enable'] = false

既存のNginx設定ファイルを編集
# vi /etc/nginx/conf.d/04_gitlab.conf

server {
    listen       80;
    server_name  gitlab.firstsec.jp;

    access_log /var/log/nginx/gitlab.access.log;
    error_log /var/log/nginx/gitlab.error.log;

    location = /robots.txt  { access_log off; log_not_found off; }
    location = /favicon.ico { access_log off; log_not_found off; }

    ### Reverse Proxy for Redmine on Unicorn
    location / {
        rewrite ^/(.*)$ /$1 break;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_pass http://127.0.0.1:8080;
    }
}

再読み込み
# /etc/rc.d/init.d/nginx configtest
# /etc/rc.d/init.d/nginx reload

Basic認証で制限をかける

 


9.GitLab再設定、起動

今までの設定を反映させる。
# gitlab-ctl reconfigure

状態を確認
# gitlab-ctl status

再起動するとき
# gitlab-ctl restart

ブラウザでアクセスして確認。

まずはrootでログイン。パスワードは「5iveL!fe」。

パスワードを設定して再ログイン。Emailアドレスを変えておく。

なぜかOverviewに表示されているRubyのバージョンが違う。

image

 

次は既存のSubversionをGitに移行

 

< Related Posts >

2015年5月18日月曜日

CentOS6にRedmine 3.0をInstallして2.5から移行

redmine_2.5-3前回GitとRubyをインストールしたので、今回はRedmineをセットアップ。

環境: CentOS 6.6 x86_64, Ruby 2.2.2, Git 2.4.1

 

目次

  1. Redmineのインストールに必要なパッケージのインストール
  2. Redmineのインストール
  3. 初期設定
  4. Railsサーバー「unicorn」のインストール
  5. nginxにリバースプロキシの設定
  6. データの移行

 


1.Redmineのインストールに必要なパッケージのインストール

公式サイトを参考に。

ImageMagickをインストール
# yum install ImageMagick ImageMagick-devel ipa-pgothic-fonts

Rubyのbundlerをインストール
# gem install bundler --no-rdoc --no-ri

MariaDBはインストール済み。デフォルトのcharacter_setは「utf8mb4」

「redmine」(utf8_general_ci)データベースと接続ユーザーを作っておく。

 


2.Redmineのインストール

これも公式サイトを参考に。前にRedmine 2.5.2をインストールした記事も参考に。

# cd /opt
# curl -O
http://www.redmine.org/releases/redmine-3.0.3.tar.gz
# tar -xzvf redmine-3.0.3.tar.gz
# mv redmine-3.0.3 redmine
# cd redmine

データベースへの接続設定
# vi config/database.yml

production:
  adapter: mysql2
  database: redmine
  host: localhost
  username: redmine
  password: pass
  encoding: utf8

Gemパッケージのインストール
# bundle install --without development test --path vendor/bundle

エラー

An error occurred while installing nokogiri (1.6.6.2), and Bundler cannot
continue.
Make sure that `gem install nokogiri -v '1.6.6.2'` succeeds before
bundling.

参考サイト

# yum install libxml2-devel libxslt-devel
# gem install nokogiri -- --use-system-libraries=true --with-xml2-include=/usr/include/libxml2/

# bundle install --without development test --path vendor/bundle

同じエラー

今度はこちらを参考に。

# bundle config build.nokogiri --use-system-libraries
# bundle install --without development test --path vendor/bundle

無事完了。

環境変数PKG_CONFIG_PATHのエラーは今回表示されなかった。

 


3.初期設定

セッショントークン作成
# bundle exec rake generate_secret_token

テーブル作成
# RAILS_ENV=production bundle exec rake db:migrate


 


4.Railsサーバー「unicorn」のインストール

前の記事と同じ。

インストール
# gem install unicorn

設定。プロセス数とか環境に合わせて設定する。
# vi config/unicorn.rb

起動スクリプト。これに起動ポート番号(5001)が書いてある。rbenvを読み込む処理を追加した。
# vi /etc/rc.d/init.d/redmine

# chmod 755 /etc/rc.d/init.d/redmine

Gemfileに記述しないとエラーになる。
# vi Gemfile

gem "unicorn"

# bundle install --without development test --path vendor/bundle

起動して、自動起動するようにしておく。
# /etc/rc.d/init.d/redmine start
# chkconfig --add redmine
# chkconfig redmine on

 


6.nginxにリバースプロキシの設定

前の記事と同じ。

# vi /etc/nginx/conf.d/03_redmine.conf

server {
    listen       80;
    server_name  redmine.hoge.jp;

    access_log /var/log/nginx/redmine.access.log;
    error_log /var/log/nginx/redmine.error.log;

    location = /robots.txt  { access_log off; log_not_found off; }
    location = /favicon.ico { access_log off; log_not_found off; }

    ### Reverse Proxy for Redmine on Unicorn
    location / {
        rewrite ^/(.*)$ /$1 break;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_pass http://127.0.0.1:5001;
    }
}

# /etc/rc.d/init.d/nginx configtest
# /etc/rc.d/init.d/nginx reload

ブラウザでアクセスしてredmineの画面が表示出来るか確認。

 


7.データの移行

前の記事と実行コマンドが少し違う。

テーブルを全削除して、phpMyAdminでデータをインポート、エクスポート。

データベースの更新
# cd /opt/redmine
# bundle exec rake db:migrate RAILS_ENV=production
# bundle exec rake redmine:plugins:migrate RAILS_ENV=production

キャッシュとセッションのクリア
# bundle exec rake tmp:cache:clear tmp:sessions:clear

添付ファイルの移行
# tar -czvf redmine_files.tgz files/

移行先へコピーして展開
# tar -xzvf redmine_files.tgz

メール送信用の設定をコピー
# vi config/configuration.yml

再起動
# /etc/rc.d/init.d/redmine restart

ブラウザでアクセスして確認

 

 

< Related Posts >

2015年5月15日金曜日

GitをSourceからBuildしてRubyの最新版をInstall

git_rubyGit → Ruby → Redmine → GitLabとインストールしたときの覚書。今回はRubyのインストールまで。

環境: CentOS 6.6 x86_64

目次

  1. Gitをインストール
  2. rbenv + ruby-buildをインストール
  3. Rubyをインストール

 


1.Gitをインストール

yumでインストールしようと思ったけど、後々GitLabをインストールしたいのでGitLabの動作条件を確認するとGit 1.7.10+。yumにあるのは1.7.1だったので最新バージョンをビルドすることにした。

公式サイトの通りにインストール。
# yum install curl-devel expat-devel gettext-devel openssl-devel zlib-devel

# curl -O https://www.kernel.org/pub/software/scm/git/git-2.4.1.tar.gz

# tar -xzvf git-2.4.1.tar.gz
# cd git-2.4.1
# make configure

/usrにインストール。
# ./configure --prefix=/usr
# make all

エラー

/usr/bin/perl Makefile.PL PREFIX='/usr' INSTALL_BASE='' --localedir='/usr/share/locale'
Can't locate ExtUtils/MakeMaker.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at Makefile.PL line 3.
BEGIN failed--compilation aborted at Makefile.PL line 3.
make[1]: *** [perl.mak] エラー 2
make: *** [perl/perl.mak] エラー 2

必要なソフトをインストールして再実行
# yum install perl-ExtUtils-MakeMaker
# make clean
# ./configure --prefix=/usr
# make all
# make install

# git --version

git version 2.4.1

 

次回以降のアップデート環境も作っておく。
# cd /opt/software/
# git clone git://git.kernel.org/pub/scm/git/git.git
# cd git
# make configure
# ./configure --prefix=/usr
# make all
# make install

# git --version

git version 2.4.1.168.g1ea28e1

 


2.rbenv + ruby-buildをインストール

rbenv + ruby-buildを使うと複数のRubyのバージョンを管理できるらしい。node.jsのバージョン管理ソフトnvmみたいなもの。

公式サイトの通りにインストール。

# cd /opt/software/
# git clone
https://github.com/sstephenson/rbenv.git ~/.rbenv
# echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bash_profile
# echo 'eval "$(rbenv init -)"' >> ~/.bash_profile
# source ~/.bash_profile

# rbenv --version

rbenv 0.4.0-148-g5b9e4f0

今度はruby-buildをインストール
# git clone https://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build

 


< 2016/05/09 追記 >
rbenvをアップデートしてRubyを再インストールした。
# cd ~/.rbenv/
# git pull
# cd ~/.rbenv && src/configure && make -C src

Ruby Buildも最新に
# cd ~/.rbenv/plugins/ruby-build/
# git pull

Rubyを再インストール
# rbenv install --force 2.2.4

 


3.Rubyをインストール

インストール可能なリスト一覧
# rbenv install -l

RedmineもGitLabもRuby 2.2に対応したらしい。
# rbenv install 2.2.2
# rbenv global 2.2.2

# ruby --version

ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-linux]

インストールされているRubyのバージョンを確認
# rbenv versions

* 2.2.2 (set by /root/.rbenv/version)

 

 

< Related Posts >

2015年5月7日木曜日

既存のWordPressサイトをGoogle App Engineに移行

google-app-engine_wordpressWordPressで作ったホームページをGoogle App Engineに移行したときの覚書。サイトはこちら。

スケジュールはGoogle カレンダーを使ってるし、写真はFacebookページのアルバムを表示しているので、管理画面にログインして何か作業をする必要はない(記事、画像をアップロードしない)。

運用してみて月額1000円以上かかるなら、おとなしくVPSを借りる予定。

環境: Windows 8.1 x64, WordPress 4.2.2

参考サイト

 

目次

  1. Google Cloud SDKをインストール
  2. Google Developers Consoleでプロジェクト作成
  3. Google Cloud SQLにインスタンスを作成
  4. WordPress用のテンプレートをダウンロードして上書き
  5. デプロイ
  6. phpMyAdminをインストール
  7. カスタムドメインの設定
  8. 管理画面にアクセス。GAE用のプラグインを導入。
  9. キャッシュの設定
  10. 費用面などを考慮して今後もGAEを使うか

 


1.Google Cloud SDKをインストール

公式サイトからダウンロード、インストール。

Python 2.7.6 64bitもインストールされた。

Google Cloud SDK Shellを起動。

サインイン
> gcloud auth login

ブラウザで認証完了。

PHP用App Engineパッケージをインストール(更新)。
> gcloud components update gae-python

All components are up to date.

 

 


2.Google Developers Consoleでプロジェクト作成

Google Developers Consoleにアクセスして「プロジェクト作成」

プロジェクト作成後、プロジェクトの概要へ自動で遷移する。

 

 


3.Google Cloud SQLにインスタンスを作成

次にWordPressをインストールするデータベースを作成する。

Google Developers Console → ストレージ → Cloud SQL → インスタンスを作成する

インスタンスID: jka-sg: wordpress
地域: アジア 米国
階層: D0 - 128 MB RAM

詳細を開いて料金プランは「パッケージ」を選択。詳しくは公式サイトで。

地域を「米国」にしないとApp Engineから接続できない(プロジェクトを作成するときに地域を「米国データセンター」と選択しているから)。

インスタンス作成後、詳細画面でデータベースを作成。

「アクセス制御」からroot@localhostのバスワードを変更。App Engineからのアクセスは常にroot@localhostになるらしい。

 

 


4.WordPress用のテンプレートをダウンロードして上書き

GAEでWordPressを動かすためのテンプレートがあるのでダウンロードする。

wordpressフォルダを移行するWordPressで置き換える。

wp-config.phpだけテンプレートので上書きして、必要な項目を編集。

app.yamlを編集。「version」はピリオドを使えない。わかりやすい名前にしておく。

application: jka-sg
version: jka-sg-1
runtime: php55
api_version: 1

databasesetup.sqlは削除

 

 


5.デプロイ

Google App Engine Launcherを起動。

File → Add Existing Application...

app.yamlが置いてあるフォルダを選択。

一覧のアプリケーションを選択して「Deploy」

04:37 PM Uploading 547 files and blobs.

プログレスバーがないので進行中なのか心配になる。

Task Managerを見ると「pythonw.exe」がネットワークを使っているので多分これ。

アップロードが終わるとエラーになった。

04:46 PM Uploaded 547 files and blobs.
04:46 PM Compilation starting.
04:47 PM Compilation completed.
04:47 PM Starting deployment.
04:47 PM Rolling back the update.
Error 400: --- begin server output ---

Client Error (400)
The request is invalid for an unspecified reason.
--- end server output ---
2015-05-06 16:47:02 (Process exited with code 1)

You can close this window now.

Google Cloud SQLへの接続かなと調べてみてもわからず。

もう一度「Deploy」してみると今度は成功。

成功するとコンソール画面の計算処理 → App Engine → ダッシュボードに表示される。

「http://jka-sg.appspot.com/」に接続しても真っ白。データベースへの接続は成功しているみたい。失敗すると下記エラーになるはず。

Error establishing a database connection

接続できない場合はCloud SQLのアクセス制御 → 承認の「App Engine アプリケーション ID」に値があるか確認。

(追記)真っ白になってたのはwp-content/object-cache.phpがあって、redisに接続しようとしてたから。削除したら無事表示された。

 

 


6.phpMyAdminをインストール

管理はphpMyAdminで出来ると何かと便利。公式サイトにチュートリアルがあった。

Google App Engineの「モジュール」という機能を使う。

app.yamlの最初はこんな感じになる。

application: jka-sg
version: phpmyadmin-1
module: phpmyadmin
runtime: php55
api_version: 1

デプロイすると「http://phpmyadmin.jka-sg.appspot.com/」へアクセス可能になるはず。

phpMyAdmin-4.4.5-englishを使った。

移行するDBをエクスポート&インポート。

 

 


7.カスタムドメインの設定

計算処理 → App Engine → 設定 → カスタムドメイン

Google Appsに登録済みのドメインでないとSSLは使えないみたい。

エイリアスとして登録してあるドメインも選択肢に出てこなかったので、プライマリで登録してあるドメインでないとダメらしい。

 

 


8.管理画面にアクセス。GAE用のプラグインを導入。

デフォルトで管理画面へはSSLでないとアクセスできないので、app.yamlを編集してデプロイし直す。

#secure: always

メールの送信などをGoogle App Engine向けに最適化してくれるプラグインがあるので導入。

アクティベートすると、このプラグイン内でSSLを強制するコードが書かれているので、管理画面が表示されなくなった。

テーマのfunctions.phpに下記コードを書いて回避。

function func_init() {
    // Disalbe SSL for Google App Engine
    // This will enable by "Google App Engine" plugin.
    add_filter( 'secure_auth_redirect', '__return_false' );
    force_ssl_admin( false );
}
add_action('init', 'func_init');

このプラグインの有効性はよく分からない。

 


9.キャッシュの設定

WordPress用のテンプレートに
wp-content/advanced-cache.php
wp-content/object-cache.php
があって、よろしくキャッシュしてくれそうだったのでこれらをコピーしてデプロイ。

いい感じに速くなった。

 


10.費用面などを考慮して今後もGAEを使うか

メリットとデメリットを考えてみた。

 

<メリット>

  • 表示が速い
  • アクセス過多時の安定感
  • サーバーのメンテナンス不要
  • プロジェクトを編集できるメンバーを簡単に編集できるので複数人で管理しやすい

 

<デメリット>

  • レンタルサーバーより割高
  • httpsを使うためにはGoogle Appsが必須
  • まだGAEのPHP対応はベータ版
  • ファイルを更新するときの技術的な壁

 

料金はGoogle Cloud SQL分だけ。他は無料枠に収まる。

Cloud SQL インスタンスの料金プランを「パッケージ」にした場合は
$0.36 x 30日 = $10.8(月額1,295円)

料金プランを「従量制」にしてバックアップをせず、cron.yamlも削除した(追記:削除ではダメ詳細は後述)場合は
22時間経過した時点で$0.55
で明らかに予算オーバー。

従量制の場合はインスタンスにアクセスがあった場合にだけ1時間単位で課金される。

詳しくは公式サイトを参考に。

 

このサイトは基本変更しないので、キャッシュする時間を24時間にしてみた。

wp-config.phpを編集してデプロイ。

$batcache = [
  'seconds'=>0,
  'max_age'=>24*60*60, // 24 hours
  'debug'=>false
];

 

< 2015/05/21 Modified >
キャッシュの設定をしても思ったように金額が減らないと思ったらcron.yamlを削除してもcronの設定を削除できない。

cron.yamlを編集

cron:

にしてデプロイ。

 

< 2015/05/22 Modified >
まだcronが動いているみたい。コマンドラインで実行してみた。

Google Cloud SDK Shellを起動

まずはSDKのアップデート
C:> gcloud auth login
C:> gcloud components update gae-python

プロジェクトの設定、確認
C:> gcloud config set project jka-sg
C:> gcloud info

プロジェクトのアップデート
C:>appcfg.py update D:\Documents\Projects\dksg\jka_hp\GAE\jka-sg\

cronのアップデート
C:>appcfg.py update_cron D:\Documents\Projects\dksg\jka_hp\GAE\jka-sg\

 

< 2015/06/02 Modified >
1時間1回くらいwp-loginに対してPOSTされていたので、毎日$0.6課金される。WP Google Authenticatorを導入したらこれらのアクセスもなくなった。

これでもう少し様子見。

 

< 2015/06/04 Modified >
それでも1時間に1回くらいはデータベースへのアクセスが発生してしまう。パッケージプランにして毎日$0.36運用の方が断然安いので、GAEを使うと月額1,295円ぐらいかかることが確定。

安いVPS借りて定期バックアップする運用からは抜け出せないのか。。。

 

< Related Posts >

2015年5月4日月曜日

CentOS7を最小構成からセットアップ

centos7_setup開発用にCentOS7を最小構成から設定したときの覚書。今まで使ってたコマンドが使えなくなって戸惑った。

環境:CentOS 7.1.1503

目次

  1. ホスト名変更
  2. ファイヤーウォール設定
  3. 時刻同期
  4. SELinuxを無効
  5. sambaをインストールしてファイル共有
  6. YUMにREMIリポジトリを追加する
  7. その他開発環境を整える

 


1.ホスト名変更

# vi /etc/hostname

 


2.ファイヤーウォール設定

デフォルトでfirewalldというサービスになったみたい。でも、iptablesが慣れているのでYUM経由でインストールする
# yum install iptables-services

firewalldを停止してiptables.servicesを使う。自動起動はenableすればいい。
# systemctl stop firewalld
# systemctl disable firewalld
# systemctl start iptables
# systemctl enable iptables

80番(http)と443番(https)を開ける
# vi /etc/sysconfig/iptables

# sample configuration for iptables service
# you can edit this manually or use system-config-firewall
# please do not ask us to add additional ports/services to this default configuration
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

 

iptablesを再起動
# systemctl reload iptables

他のサーバーからポートスキャンして確認。
# nmap 1.2.3.4

PORT    STATE  SERVICE
22/tcp  open   ssh
80/tcp  closed http
443/tcp closed https

 


3.時刻同期

ntpからchronyというサービスに変わったらしい。

インストールされているか確認
# systemctl -a | grep chrony

インストール
# yum install chrony

確認
# systemctl list-unit-files -t service | grep chrony

日本のNTPサーバーを追加して起動
# vi /etc/chrony.conf

server ntp.nict.jp iburst

# systemctl start chronyd
# systemctl enable chronyd

同期状態を確認
# chronyc sources

 


4.SELinuxを無効

# vi /etc/selinux/config

SELINUX=disabled

再起動
# reboot

 


5.sambaをインストールしてファイル共有

YUM経由でインストール。
# yum install samba

設定。前の記事を参考に。

# vi /etc/samba/smb.conf

        workgroup = VM
        server string = Samba %v
        netbios name = vm-dev2
        hosts allow = 127. 192.168.

        security = user
        passdb backend = tdbsam

        public = yes
        map to guest = Bad User
        guest account = nobody

        load printers = no
;       cups options = raw
        printcap name = /dev/null
        disable spoolss = yes

[opt]
        comment = Option Directory
        path = /opt
        browseable = yes
        writable = yes

起動
# systemctl start smb
# systemctl enable smb
# systemctl start nmb
# systemctl enable nmb

samba用のポートを開ける。
# less /etc/sysconfig/iptables

-A INPUT -m state --state NEW -m udp -p udp --dport 137 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 138 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 139 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 445 -j ACCEPT

再起動して確認。
# reboot

 


6.YUMにREMIリポジトリを追加する

まずはEPELをインストール。YUMに置いてあった。
# yum install epel-release

Remi公式サイトからrpmをダウンロード

# curl -O http://rpms.famillecollet.com/enterprise/remi-release-7.rpm
# rpm -ivh remi-release-7.rpm

デフォルトで有効にしておく。
# vi /etc/yum.repos.d/remi.repo

[remi]
enabled=1

アップデート
# yum update

 


7.その他開発環境を整える

nginx, php, node.jsとかは前の記事を参考に。

 

 

< Related Posts >

Related Posts Plugin for WordPress, Blogger...

Blog Archives