Хранение конфигурационных файлов в Git (Gitlab)

Было время не хранил я ничего в гите, и было это не торт. Один неверный символ мог съесть уйму времени!

Годы шли и однажды прислушался к совету друга программиста использовать гитлаб.

 

Сервисы которые по своей идеологии не пересекаются я стараюсь ставить запускать в изолированных средах. Итак gitlab устанавливаем в виртуалку ака lxc. Создаем контейнер:

# lxc-create -n GITLAB -t ubuntu -B lvm --fssize 10G

...

# ln -s /var/lib/lxc/GITLAB/config /etc/lxc/auto/GITLAB

# lxc-start -d -n GITLAB
# lxc-console -n GITLAB

 

Вот так, минута и окружение готово!

 

В установке самого gitlab нету ничего сложного, делается все в пошаговой инструкции за 20 минут копипаста.

Первым делом обновим репы и систему и заодно проверим правильность работы резолвера:

root@GITLAB:~# apt-get update && yes | apt-get upgrade

 

На всякий случай сделаем снэпшот, и приступим к настройке:

# lxc-shutdown -wn GITLAB &&  lvcreate -s /dev/lxc/GITLAB -n GITLAB_SNAPSHOT -L 1G && lxc-start -dn GITLAB

 

Но есть способ еще и для саамых ленивых  https://github.com/gitlabhq/gitlabhq/issues/3626  🙂

Я — ленив. Копирую, вставляю, запускаю, и выпив чай-кофе получаю готовый гитлаб! Процедура, не быстрая, минут 15-20 на свободном двухпроцессорном E5620 с 8гб памяти. На двадцатой минуте будет задан вопрос на который необходимо ответить yes и нажать энтэр!  Мы получили готовую виртуалку с гитлабом!

Остался пустяк, поставить фронтэнд, с нжинксом. Автор скрипта не сделал установки нжинкса по причине того что на этом сервере возможно крутится что угодно, и уже имеется установленный веб сервер. Другого объяснения для себя не придумал.

root@GITLAB:~# apt-get install nginx

root@GITLAB:~# service  nginx start

root@GITLAB:~# update-rc.d nginx enable

root@GITLAB:~# cat > /etc/nginx/sites-enabled/gitlab
server {

listen 80 default_server; # e.g., listen 192.168.1.1:80;
server_name git.casp.ru/old; # e.g., server_name source.example.com;
root /home/gitlab/gitlab/public;

# individual nginx logs for this gitlab vhost
access_log /var/log/nginx/gitlab_access.log;
error_log /var/log/nginx/gitlab_error.log;

location / {
# serve static files from defined root folder;.
# @gitlab is a named location for the upstream fallback, see below
try_files $uri $uri/index.html $uri.html @gitlab;
}

# if a file, which is not found in the root folder is requested,
# then the proxy pass the request to the upsteam (gitlab unicorn)
location @gitlab {
proxy_read_timeout 300; # https://github.com/gitlabhq/gitlabhq/issues/694
proxy_connect_timeout 300; # https://github.com/gitlabhq/gitlabhq/issues/694
proxy_redirect off;

proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;

proxy_pass https://localhost:3000;
}
}

 

Если же не работает этот метод, то есть отличная официальная статья, где все те же самые шаги расписаны на простом но непонятном английском языке:

https://github.com/gitlabhq/gitlabhq/blob/5-2-stable/doc/install/installation.md

 

 

Логин-пароль по умолчанию после установки:

admin@local.host.

5iveL!fe

 

Далее заводим нового пользователя, в веб интерфейсе, и генерим ему ключ:

root@GITLAB:/home/git/gitlab/config# ssh-keygen -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): gitkey
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in gitkey.
Your public key has been saved in gitkey.pub.
The key fingerprint is:
9f:c6:8a:59:c8:40:f8:60:12:9a:7e:98:a1:77:d3:93 root@GITLAB
The key's randomart image is:
+--[ RSA 4096]----+
|. |
|.o . |
|+.+ . |
|oo++ . . |
|.+..= E S |
| ... + o o . |
| o . = |
| + o |
| o . |
+-----------------+
root@GITLAB:/home/git/gitlab/config# ls -l gitkey*
-rw------- 1 root root 3247 Jun 13 16:36 gitkey
-rw-r--r-- 1 root root 737 Jun 13 16:36 gitkey.pub
root@GITLAB:/home/git/gitlab/config# cat gitkey.pubssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDqrL7Tkopj6t3aX0gWyErCP08h3MiQM+G3s/+OmRzQHq5Dau/MmraJ9b9b4X1DpITDM+gD5xPu8FActk+DKIoNccV4wBSajeB/Nw9FjDPgZXOLzgi6gHLHkGtz1+1a76nmuk5D3HH4CUZfbKeFdPKvkJuc6TKA9Gh/J0Mk5WrP9hxuxBI0eUoZa16xuRF3lY/TfrKPnbf7YSIKQyO3uSEIA25JmaqJS8IaBLSs/CEJw1qXPKDIdyok0VCPkxbfDlS4AAP3R8nqnx3ySQPrNVpoD2/7RDfpqVS4apd4oNNhZLd24LpcJYyMUidisBlazLg80y6rFuByu1oqWp7xamv8+2AEzomG7wzTtOSjwOq01I7xtuZvKlo+ZiqrD5sjYDQG2euJaehWXjeCurzetXiMJsRBmWoidZZ+rV8/S8P/bmr8/F9CqknnonZc+DavzWXSffrZo54RY3K75lDlUQLHS1eoR2GBCs+Xs/uZ9AVQxl3Wnlmh3/mBJTxCd7N/OARiW/cIoNhe65hqINdZXoL7zGVg0V4vNMmrA0HDEvVV9/e8mLhXdfkB2aPC6NAUdxWWeAo/GbD0Bdkus5W8/siN0qzrkW/M1wL9ulR9ba1wxf5wHP7SzMqReRLD0XjqId/jD8xnuSWFXtq9bkCRGSPddyZOlRcaTQV7n7jwn3X+7w== root@GITLAB

 

Далее копируем текст публичного ключа к пользователю («SSH Keys» в профиле).
Создаем новый репозиторий, для тестов начнем с каталога /etc самого гитового сервера.
«Create new Project» -> «Project name is» -> «etc config gitlab».

Для удобства запускаем ssh-agent и добавляем в него ключ авторизации, который мы только что нагенерировали:

root@GITLAB:~# eval `ssh-agent`
Agent pid 2067
root@GITLAB:~# ssh-add gitkey
Identity added: gitkey (gitkey)

 

 

Переходим к основному: начинаем работать с гитом. Дабы не плодить репозитории, работаю с ветками внутри одного.

# git init
# git remote add origin git@gitlab.myadresgitlabserver.com:root/cfgetc.git
# git fetch
# git checkout -b ETC/GITLAB origin/master
# git add .
# git commit -a -m "AUTOCOMMIT DATE: $(date)"
# git push origin HEAD

 

 

Таким вот образом я отправляю каждую ночь в 0 часов и 0 минут все что небыло добавлено автоматически.

0 0 * * * eval `ssh-agent` && ssh-add /etc/scripts/GITLAB && cd /etc && git add . && git commit -a -m "AUTOCOMMIT DATE: $(date)" && git push origin HEAD

 

Если же изменений не было то данный однострочник дальше второй команды не продвинется.

 

 

Другие новости
21.05.2019
Настойка satis для пакетов composer в docker

Настрройка satis satis — кеширующий сервер для пакетов php composer. Для настройки репозитория будем использовать официальный docker. Разработчикам понадобится редактировать файла конфигурации satis.json, для этого поднимем отдельный контейнер с sftp и ftp серверами внутри. Файл конфиргурации в нашем случае должен

27.07.2018
Лечим wordpress https err_too_many_redirects

По какой логике wordpress понимает что к нему пришел https не понятно, но часто сталкиваемся с проблемой когда стили и js вордпресс отдает  по http и изза mixed content браузеры их режут. Если в настройках (Настройки -> Общие) жестко указали