gitlab構築の相互準備モード
9884 ワード
gitlab構築の相互準備モード
前言:gitlabの現在のデフォルトの配置方式はローカルの単機配置であり、gitlab環境の信頼性と安定性を高めるために、gitolilteのmirror機能を利用してこの機能を実現するために、相互準備構築方案を構築する必要がある.
構築環境:
2台のサーバ--RedHat 5.4
カーネルバージョン--linux 2.6.18 x 86_64
概要:
1.2セットのgitlab標準環境を構築する
2.相互準備モードの構築
1.2セットのgitlab標準環境を構築する
参考前のブログ:http://www.cnblogs.com/lenolix/archive/2013/02/06/2906466.html
ここで、2台のgitlab環境はそれぞれAとBであり、以下、$A:Aマシンで動作することを表し、$B:Bマシンで動作することを表す
2.A、B環境の相互訪問権限の設定
gitoliteのmirror機能については、公式ドキュメントを参照してください.http://gitolite.com/gitolite/mirroring.html
1. ローカルgitolite-adminをクローンします.git
2. 修正gitolilte.rc設定hostname
3.gitoliteの構成を更新し、A、Bホストの相互アクセス権限を追加
4. sshのconfigファイルの構成
接続性のテスト
「hello server-hostA/B、this...」A、Bの連通性に問題がないことを示す
gitlabアカウントの構成をテストする
正常なcloneがあれば、構成が正しいことを示します.
3. post-receive hooksによるリアルタイム同期
gitoliteのコードを変更し、権限制限を削除します.
4. テスト
Aの環境で倉庫root/p 1を作成し、コードを提出すると、Bの上にも/root/p 1倉庫が作成されていることに気づき、Bで倉庫コードを修正することで、Aの上のコードも修正することがわかります.
もしこのテストに合格すれば、gitlabの相互準備モードが構築されたことをおめでとうございます.
5. に続く
解決すべき問題:
1. 倉庫は同期できますが、satellitesは同期できません.そうするとオンラインでコミットする機能は使えません.
一時的な解決策:プライマリ・スタンバイの切り替え時に、rake gitlab:enable_を手動で実行する必要があります.automerge RAILS_ENV=production,satellitesを再生成する
2. プライマリ・スタンバイ・モードの欠点は、リソースの使用率が低く、常に1台のサーバがアイドル状態にあることです.
最適化方案:互いにモードの基礎の上で分布式の配置を実現して、VIPを通じてLoadBlanceをして、機械の利用率とシステムの性能を提供します.(進行中…)
3. データベースは現在マスターマスターモード(master-master)ですが、マスターの自動切り替えは実現されず、手動でサポートする必要があります.
6. 補足問題
1. Httpプロトコルを使用してコードをコミットすると、奇妙な問題が発見され、エラー出力を/tmp/mirrorにリダイレクトしました.log
vi/home/git/.gitolite/hooks/common/post-receive
/home/git/bin/gitolite mirror push hostA $repo_name >/tmp/mirror.log 2>&1
エラーメッセージを検出:
FATAL: errors found before logfile could be created
FATAL:unknown host hostA
...
gitoliteのmirrorコマンド実行プロセスを追跡することで、問題点を特定します.
httpプロトコルコミットコードの機能はgilabのwebサーバでサポートされていますが、gitlabのWEBサービスはgitlabのユーザーとして実行され、post-receiveというフックスクリプトもgitlabのユーザーとして呼び出され、gitlabユーザーのコンテキスト環境でスクリプトが実行されるため、奇妙な問題が発生します
ソリューション:
vi /home/git/.gitolite/hooks/common/post-receive
変更:
vi/home/git/gitolite/src/lib/Gitolite/Common.pm
gitoliteソースコードを変更し、ログファイルのアクセス権を変更し、gitグループアカウントの書き込みを許可します.
前言:gitlabの現在のデフォルトの配置方式はローカルの単機配置であり、gitlab環境の信頼性と安定性を高めるために、gitolilteのmirror機能を利用してこの機能を実現するために、相互準備構築方案を構築する必要がある.
構築環境:
2台のサーバ--RedHat 5.4
カーネルバージョン--linux 2.6.18 x 86_64
概要:
1.2セットのgitlab標準環境を構築する
2.相互準備モードの構築
1.2セットのgitlab標準環境を構築する
参考前のブログ:http://www.cnblogs.com/lenolix/archive/2013/02/06/2906466.html
ここで、2台のgitlab環境はそれぞれAとBであり、以下、$A:Aマシンで動作することを表し、$B:Bマシンで動作することを表す
2.A、B環境の相互訪問権限の設定
gitoliteのmirror機能については、公式ドキュメントを参照してください.http://gitolite.com/gitolite/mirroring.html
1. ローカルgitolite-adminをクローンします.git
$A: sudo -u gitlab -H git clone git@localhost:gitolite-admin.git /home/gitlab/gitolite-admin
$B: sudo -u gitlab -H git clone git@localhost:gitolite-admin.git /home/gitlab/gitolite-admin2. 修正gitolilte.rc設定hostname
$A: sudo -u git -H vi /home/git/.gitolite.rc
HOSTNAME => 'hostA',
$B: sudo -u git -H vi /home/git/.gitolite.rc
HOSTNAME => 'hostB',
3.gitoliteの構成を更新し、A、Bホストの相互アクセス権限を追加
# A、B gitlab ， ， A、B gitolite gitlab ， ssh-key ， ， gitlab
# ， gitlab ， A、B gitlab ，
$A: sudo -u git mv /home/git/.gitolite/keydir/gitlab.pub /home/git/.gitolite/keydir/gitlab-hostA.pub
$A: sudo -u git scp /home/git/.gitolite/keydir/gitlab-hostA.pub git@hostB:/home/git/.gitolite/keydir/
$A: sudo -u git vi /home/git/.gitolite/conf/gitolite.conf
：
repo gitolite-admin
RW+ = gitlab-hostA
RW+ = gitlab-hostB$B: sudo -u git mv /home/git/.gitolite/keydir/gitlab.pub /home/git/.gitolite/keydir/gitlab-hostB.pub
$B: sudo -u git scp /home/git/.gitolite/keydir/gitlab-hostB.pub git@hostA:/home/git/.gitolite/keydir
$B: sudo -u git vi /home/git/.gitolite/conf/gitolite.conf
：
repo gitolite-admin
RW+ = gitlab-hostA
RW+ = gitlab-hostB # A、B git
$A: sudo -u git -H ssh-keygen
$A: sudo cp /home/git/.ssh/id_rsa.pub /tmp/server-hostA.pub
$A: sudo -u git -H cp /tmp/server-hostA.pub /home/git/.gitolite/keydir/
$A: sudo scp /tmp/server-hostA.pub git@B:home/git/.gitolite/keydir/
$A: sudo -u git -H vi /home/git/.gitolite/conf/gitolite.conf
：
repo @all
RW+ = gitlab-host47
RW+ = gitlab-host48
RW+ = server-host47
RW+ = server-host48$B: sudo -u git -H ssh-keygen
$B: sudo cp /home/git/.ssh/id_rsa.pub /tmp/server-hostB.pub
$B: sudo -u git-H cp /tmp/server-hostB.pub /home/git/.gitolite/keydir
$B: sudo scp /tmp/server-hostB.pub git@A:home/gitlab/.gitolite/keydir/
$B: sudo -u git -H vi /home/git/.gitolite/conf/gitolite.conf
：
repo @all
RW+ = gitlab-host47
RW+ = gitlab-host48
RW+ = server-host47
RW+ = server-host48# gitolite， conf
$A: sudo -u git /home/git/bin/gitolite setup
$B: sudo -u git /home/git/bin/gitolite setup
# ssh key， ， setup ， keydir key， ，
$A: sudo cd /home/gitlab/gitolite-admin
$A: sudo -u gitlab -H git pull ( ，conf/gitolite.conf ， keydir/ )
$A: sudo cp /home/git/.gitolite/keydir/* keydir/
$A: sudo chown -R gitlab:git keydir/
$A: sudo -u gitlab git add keydir/*
$A: sudo -u gitlab git commit -m "update"
$A: sudo -u gitlab git push
$B: sudo cd /home/gitlab/gitolite-admin
$B: sudo -u gitlab -H git pull
$B: sudo cp /home/git/.gitolite/keydir/* keydir/
$B: sudo chown -R gitlab:git keydir/
$B: sudo -u gitlab git add keydir/*
$B: sudo -u gitlab git commit -m "update"
$B: sudo -u gitlab git push4. sshのconfigファイルの構成
$A: sudo -u git -H vi /home/git/.ssh/config
host hostB
user git
hostname hostB's ip/hostname
port 22
identityfile ~/.ssh/id_rsa
$A: sudo -u git -H chmod 644 /home/git/.ssh/config
$B: sudo -u git -H vi /home/git/.ssh/config
host hostA
user git
hostname hostA's ip/hostname
port 22
identityfile ~/.ssh/id_rsa
$B: sudo -u git -H chmod 644 /home/git/.ssh/config接続性のテスト
$A: sudo -u git ssh hostB
$B: sudo -u git ssh hostA
「hello server-hostA/B、this...」A、Bの連通性に問題がないことを示す
gitlabアカウントの構成をテストする
$A :sudo -u gitlab -H git clone git@localhost:gitolite-admin.git /tmp/gitolite-admin
$A: rm -rf /tmp/gitolite-admin
$B :sudo -u gitlab -H git clone git@localhost:gitolite-admin.git /tmp/gitolite-admin
$B: rm -rf /tmp/gitolite-admin
正常なcloneがあれば、構成が正しいことを示します.
3. post-receive hooksによるリアルタイム同期
$A: sudo -u git -H vi home/git/.gitolite/hooks/common/post-receive
：
repo_name=`pwd`
repo_name=${repo_name#*/home/git/repositories/}
repo_name=${repo_name%.git*}
/home/git/bin/gitolite mirror push hostB $repo_name > /dev/null 2>&1
$B: sudo -u git -H vi home/git/.gitolite/hooks/common/post-receive
：
repo_name=`pwd`
repo_name=${repo_name#*/home/git/repositories/}
repo_name=${repo_name%.git*}
/home/git/bin/gitolite mirror push hostA $repo_name > /dev/null 2>&1
gitoliteのコードを変更し、権限制限を削除します.
$A: sudo -u git /home/git/gitolite/src/commands/mirror
：
sub valid_slave {
my ( $host, $repo ) = @_;
_die "invalid repo '$repo'" unless $repo =~ $REPONAME_PATT;
#
#my $ref = git_config( $repo, "^gitolite-options\\.mirror\\.slaves.*" );
#my %list = map { $_ => 1 } map { split } values %$ref;
#_die "'$host' not a valid slave for '$repo'" unless $list{$host};
}
4. テスト
Aの環境で倉庫root/p 1を作成し、コードを提出すると、Bの上にも/root/p 1倉庫が作成されていることに気づき、Bで倉庫コードを修正することで、Aの上のコードも修正することがわかります.
もしこのテストに合格すれば、gitlabの相互準備モードが構築されたことをおめでとうございます.
5. に続く
解決すべき問題:
1. 倉庫は同期できますが、satellitesは同期できません.そうするとオンラインでコミットする機能は使えません.
一時的な解決策:プライマリ・スタンバイの切り替え時に、rake gitlab:enable_を手動で実行する必要があります.automerge RAILS_ENV=production,satellitesを再生成する
2. プライマリ・スタンバイ・モードの欠点は、リソースの使用率が低く、常に1台のサーバがアイドル状態にあることです.
最適化方案:互いにモードの基礎の上で分布式の配置を実現して、VIPを通じてLoadBlanceをして、機械の利用率とシステムの性能を提供します.(進行中…)
3. データベースは現在マスターマスターモード(master-master)ですが、マスターの自動切り替えは実現されず、手動でサポートする必要があります.
6. 補足問題
1. Httpプロトコルを使用してコードをコミットすると、奇妙な問題が発見され、エラー出力を/tmp/mirrorにリダイレクトしました.log
vi/home/git/.gitolite/hooks/common/post-receive
/home/git/bin/gitolite mirror push hostA $repo_name >/tmp/mirror.log 2>&1
エラーメッセージを検出:
FATAL: errors found before logfile could be created
FATAL:unknown host hostA
...
gitoliteのmirrorコマンド実行プロセスを追跡することで、問題点を特定します.
httpプロトコルコミットコードの機能はgilabのwebサーバでサポートされていますが、gitlabのWEBサービスはgitlabのユーザーとして実行され、post-receiveというフックスクリプトもgitlabのユーザーとして呼び出され、gitlabユーザーのコンテキスト環境でスクリプトが実行されるため、奇妙な問題が発生します
ソリューション:
vi /home/git/.gitolite/hooks/common/post-receive
変更:
# HOME
export HOME=/home/git
repo_name=`pwd`
repo_name=${repo_name#*/home/git/repositories/}
repo_name=${repo_name%.git*}
# ssh host ， git ssh/config
/home/git/bin/gitolite mirror push git@hostA's ip $repo_name > /dev/null 2>&1vi/home/git/gitolite/src/lib/Gitolite/Common.pm
gitoliteソースコードを変更し、ログファイルのアクセス権を変更し、gitグループアカウントの書き込みを許可します.
sub gl_log {
# the log filename and the timestamp come from the environment. If we get
# called even before they are set, we have no choice but to dump to STDERR
# (and probably call "logger").
# tab sep if there's more than one field
my $msg = join( "\t", @_ );
$msg =~ s/[
\r]+/<<newline>>/g;
my $ts = gen_ts();
my $tid = $ENV{GL_TID} ||= $$;
my $fh;
logger_plus_stderr( "errors found before logging could be setup", "$msg" ) if not $ENV{GL_LOGFILE};
chmod 0664,$ENV{GL_LOGFILE}; #
open my $lfh, ">>", $ENV{GL_LOGFILE}
or logger_plus_stderr( "errors found before logfile could be created", "$msg" );
print $lfh "$ts\t$tid\t$msg
";
close $lfh;
}