Вопросы Теги

совершенствуя удаленный сервер мерзавца repo

Посмотрите в истории задания (щелчок правой кнопкой по заданию, Истории Представления), и необходимо видеть записи для каждого из тех заданий. Посмотрите на запись в течение рассматриваемого времени и посмотрите, какой идентификатор инициировал задания в то время. Мое предположение, кто-то вручную сбросил их с ноги.

3
задан 21 March 2014 в 12:22
3 ответа

Хотя я сам не использовал его, исходя из моего понимания марионетки http://puppetlabs.com/ , вы можете сделать это.

Каждый раз марионетка запускается, если что-то изменится, оно будет автоматически перенесено на другие серверы в зависимости от того, что такое золотой образ. И если у вас есть большое количество серверов после создания золотого образа, вы можете создать марионетку базовой установки на другом, и новый сервер получит остальную часть конфигурации с главного сервера.

0
ответ дан 3 December 2019 в 05:13

Обе проблемы (автоматическая обработка развертывания и избежание бесполезной работы, например, выполнение задачи grunt, если ничего не изменилось) для чего предназначены git hooks.

Поэтому я бы посоветовал полностью избавиться от задач cron и перейти к управлению вашими репозиториями с помощью hooks как можно быстрее.

Способ, которым это обычно делается, подробно описан здесь , и в основном требует наличия голого репозитория (например, hub repo) для переноса и извлечения извлекаемой версии одного и того же repo (live repo), расположенного в соответствующем пути, скажем /srv/www/html.

Мне нравится использовать гитолит3 для обработки hub repo, но это не является требованием, хотя довольно удобно иметь тонкозернистый контроль доступа, связанный с вашим LDAP по выбору , если это необходимо. Также хорошей практикой является ограничение возможностей пользователя gitolite3 с помощью sudo, а также обработка крюков с помощью вызовов sudo. Это рабочий пример использования gitolite3 hooks (не стесняйтесь адаптировать их - или усилить/улучшить - в соответствии с вашими потребностями):

  • hub repo post-update hook:

    #!/bin/sh

отголосок "****"
эхо "**** Вызов издателя - Hub2live сценарий [Hub's postкрючок для обновления]"
отголосок "****"

sudo /usr/local/sbin/publisher-hub2live "/srv/www/html" "root:apache" "2750" "640"

выход 0

  • publisher-hub2live script:

    #!/bin/sh

отголосок "****"
echo "**** Pulling changes into Live [publisher-hub2live]"
отголосок "****"

компакт-диск "$1" || выход
маска 0022
отменить GIT_DIR
/внутрь/втулка/выталкивающая втулка ведущий

# пользовательские действия здесь
# например, вызывать хрюканье
/бин/чаун -Р "$2" "$1"
/bin/find "$1" - type d -exec chmod "$3" {} +
/bin/find "$1" - type f -exec chmod "$4" {} +
/bin/chmod u+x "$1" /.git/hooks/ post-commit
/sbin/restorecon -R -v "$1"
exec /usr/bin/git update-server-info

выход 0

  • Крюк live repo post-commit тоже может пригодиться, если вы когда-нибудь внесете изменения в проверенное рабочее дерево репо live repo и захотите синхронизировать концентратор.

Эта инфраструктура требует следующих записей (или эквивалентных им) в вашем файле sudoers:

Cmnd_Alias        GITOLITE_CMDS = /usr/bin/git, /bin/chown, /bin/find, /bin/chmod, /sbin/restorecon, /usr/local/sbin/publisher-hub2live
Defaults:gitolite3 !requiretty
Defaults:gitolite3 lecture=never
gitolite3                ALL = (root)NOPASSWD: GITOLITE_CMDS

Также, блок Match в вашем sshd_config был бы полезен, в зависимости от того, как вы управляете идентификацией в ваших машинах: 

 Match Group gitolite3
  Banner /etc/issue.empty
  RequiredAuthentications2 publickey

После всего этого, нажатие на hub repo вызывает крюк post-update, гарантируя, что Ваши пользовательские действия будут выполнены только , когда появится что-то новое.

4
ответ дан 3 December 2019 в 05:13

Я думаю, что вы можете решить эту проблему просто сделав это: 

*/1 * * * * cd /my/sites/staging && git pull -q origin master|grep -v "up-to-date" && grunt production
3
ответ дан 3 December 2019 в 05:13

Теги

Похожие вопросы