Mutual standby mode built by gitlab

Mutual standby mode built by gitlab

Currently, gitlab is deployed on a local machine by default. To improve the reliability and stability of the gitlab environment, a set of mutual standby construction scheme must be established: the mirror function of gitolilte can be used to implement this function;

Build Environment:

Two servers -- RedHat 5.4

Kernel version-Linux 2.6.18 x86_64

Summary:

1. Set up two gitlab standard environments

2. Build the mutual standby mode

1. Set up two gitlab standard environments

Refer to previous blog: http://www.cnblogs.com/lenolix/archive/2013/02/06/2906466.html

Assume that the two gitlab environments are A and B respectively. In the following section, $ A: indicates the operation in machine A, and $ B: indicates the operation in machine B.

2. Configure mutual access permissions for Environment A and environment B

For more information about gitolite mirror, see the official documentation: http://gitolite.com/gitolite/mirroring.html.

1. clone a local gitolite-admin.git

$A: sudo -u gitlab -H git clone [email protected]:gitolite-admin.git  /home/gitlab/gitolite-admin
$B: sudo -u gitlab -H git clone [email protected]:gitolite-admin.git  /home/gitlab/gitolite-admin

2. Modify. gitolilte. RC to set the hostname.

$ A: Sudo-u Git-h vi/home/git /. gitolite. RC modify hostname => 'hosta ', $ B: Sudo-u Git-H VI/home/git /. gitolite. RC modifies hostname => 'hostb ',

3. Update gitolite configuration and add mutual access permissions for host a and host B.

# Update the configurations of gitlab accounts on host a and host B. This step is very important because gitlab accounts exist in gitolite account systems of host a and host B, but their ssh-key is different, if the data is synchronized to the same value, a set of gitlab loops will be affected.
# The solution is to change the username of the gitlab account and add the gitlab account to both A and B to avoid synchronous overwriting.
$ 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 [email protected]:/home/git/. gitolite/keydir/
$ A: Sudo-u git VI/home/git/. gitolite/CONF/gitolite. conf
Add:
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 [email protected]:/home/git/. gitolite/keydir
$ B: Sudo-u git VI/home/git/. gitolite/CONF/gitolite. conf
Add:
Repo gitolite-Admin
RW + = gitlab-Hosta
RW + = gitlab-hostb

# Add git account mutual access permissions on host a and host B
$ 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 [email protected]: Home/git /. gitolite/keydir/
$ A: Sudo-u Git-h vi/home/git/. gitolite/CONF/gitolite. conf
Add:
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 [email protected]: Home/gitlab/. gitolite/keydir/
$ B: Sudo-u Git-H VI/home/git/. gitolite/CONF/gitolite. conf
Add:
Repo @ All
RW + = gitlab-host47
RW + = gitlab-host48
RW + = server-host47
RW + = server-host48

# Reinstall gitolite and update Conf
$ A: Sudo-u git/home/git/bin/gitolite setup
$ B: Sudo-u git/home/git/bin/gitolite setup

# Installing the SSH key is strange. You can only update the authorization configuration with setup, but cannot update the key in keydir.
$ A: sudo CD/home/gitlab/gitolite-Admin
$ A: Sudo-u gitlab-H git pull (Here you will find that CONF/gitolite. conf has been updated, but there is no new file in 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 push

4. Configure the SSH Config File

$A: sudo -u git -H vi /home/git/.ssh/confighost 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/confighost 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

Test connectivity

$A: sudo -u git ssh hostB$B: sudo -u git ssh hostA

If "Hello server-Hosta/B, this is..." is displayed, the connectivity between A and B is normal.

Test gitlab account Configuration

$A :sudo -u gitlab -H git clone [email protected]:gitolite-admin.git /tmp/gitolite-admin$A: rm -rf /tmp/gitolite-admin$B :sudo -u gitlab -H git clone [email protected]:gitolite-admin.git /tmp/gitolite-admin$B: rm -rf /tmp/gitolite-admin

If the clone is normal, the configuration is correct.

3. Use post-receive hooks for Real-Time Synchronization

$ A: Sudo-u Git-h vi home/git /. gitolite/hooks/common/post-receive added: 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 added: 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

Modify the gitolite Code to remove one permission restriction:

$ A: Sudo-u git/home/git/gitolite/src/commands/mirror modify: Sub valid_slave {My ($ host, $ repo) = @_; _ die "invalid repo '$ repo'" Unless $ repo = ~ $ Reponame_patt; # comment out the following lines # 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. Test

Create a repository root/P1 in Environment A, and then submit the code. You will find that repository/root/P1 is also created on Repository B, and then modify the repository code through repository B, we can see that the code above a has also been modified.

If this test is successful, congratulations! gitlab's mutual backup mode has been built successfully!

5. Follow-up

Problem to be resolved:

1. Although the repository can be synchronized, satellites cannot be synchronized, so that the online submission function will not be available.

Temporary solution: During master-slave switchover, you must manually run rake gitlab: enable_automerge rails_env = production to regenerate satellites.

2. The disadvantage of the active/standby mode is that the resource utilization is low and there is always a server in idle state.

Optimization solution: distributed deployment is implemented based on the mutual standby mode, and loadblance is implemented through VIP to provide machine utilization and system performance. (In progress ...)

3. Currently, the database is in master-slave mode, but automatic failover is not implemented. Manual support is required.

6. Additional Questions

1. I found a strange problem when submitting code using the HTTP protocol. I redirected the error output to/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

Error message found:

Fatal: errors found before logfile cocould be created

Fatal: Unknown host Hosta

...

By tracking the execution process of the mirror command of gitolite, the problem is found:

The HTTP code submission function is supported by gilab's web server, while gitlab's Web service runs as a gitlab user, as a result, the post-receive hook script is also called as a gitlab user. This will execute the script in the context of the gitlab user, so it will trigger a strange problem.

Solution:

VI/home/git/. gitolite/hooks/common/post-receive

Change:

# Forcibly specify the home variable
Export Home =/home/gitrepo_name = 'pwd' repo _ name =$ {repo_name # */home/git/repositories/} repo_name =$ {repo_name %. Git *}
# The host address of SSH is also specified here, you cannot use SSH/config of the git account to configure/home/git/bin/gitolite mirror push [email protected]'s IP $ repo_name>/dev/null 2> & 1

VI/home/git/gitolite/src/lib/gitolite/common. PM

Change the gitolite source code, modify the access permissions of log files, and allow the GIT group account to write

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/[\ n \ r] +/<newline>/g; my $ Ts = gen_ts (); my $ tid = $ ENV {gl_tid} | |=$ $; my $ FH; logger_plus_stderr ("errors found before logging cocould be setup", "$ MSG ") if not $ ENV {gl_logfile}; chmod 0664, $ ENV {gl_logfile}; # change the Log Access attribute open my $ lfh, "> ", $ ENV {gl_logfile} Or logger_plus_stderr ("errors found before logfile cocould be created", "$ MSG "); print $ lfh "$ ts \ t $ TID \ t $ MSG \ n"; close $ lfh ;}

Mutual standby mode built by gitlab