mantendo um servidor remoto atualizado com o git repo

Question

Então, estou ciente dos git hooks, e vou olhar para os próximos, mas quero escrever um simples script bash, executado via cron, para manter um repositório atualizado em um servidor remoto. Eu imagino que funciona assim:

• o cron executa myupdatescript.sh
• myupdatescript.sh irá:
  1. copie para / my / sites / staging
  2. git pull -q mestre de origem
  3. se algo foi removido, então:
     • execute grunhido para construir a fonte
     • yadda yadda yadda

Atualmente, tenho esse trabalho como uma tarefa do cron que se parece com:

*/1 * * * * cd /my/sites/staging && git pull -q origin master && grunt production

Estou tentando evitar ter que executar meu build grunhido se nada mudar. Eu acho que tudo se resume a como eu posso dizer se git pull realmente puxou alguma coisa, e usar isso como uma condição para executar o meu grunhido construir. Servidor Ubuntu, a chave está instalada no github, todas essas coisas boas. Obrigado por qualquer ajuda!

    

Answer 1

Ambos os problemas (manipular automaticamente suas implantações e evitar o trabalho inútil, por exemplo, executar uma tarefa grunt se nada mudar) são para os quais git hooks servem.

Então, meu conselho seria livrar-se de cron tarefas e mudar para o gerenciamento de seus repositórios via ganchos o mais rápido possível.

A maneira como isso geralmente é feito é descrita em detalhes aqui e basicamente exige que você ter um repositório bare (um repositório hub ) para enviar / extrair e uma versão com check-out do mesmo repositório (um live repo) localizado no repositório caminho apropriado, por exemplo, /srv/www/html , por exemplo.

Eu gosto de usar gitolite3 para lidar com o repositório hub , mas isso não é um requisito, embora seja bastante conveniente ter fine -grained controle de acesso vinculado ao seu LDAP de escolha se for necessário.

Também é uma boa prática limitar as capacidades do usuário gitolite3 via sudo e manipular os ganchos por meio de sudo chamadas. Este é um exemplo de trabalho usando gitolite3 hooks (sinta-se livre para adaptá-los - ou aprimore / corrija - para atender às suas necessidades):

• hub repo post-update hook:

  #!/bin/sh
  
  echo "****"
  echo "**** Calling publisher-hub2live script [Hub's post-update hook]"
  echo "****"
  
  sudo /usr/local/sbin/publisher-hub2live "/srv/www/html" "root:apache" "2750" "640"
  
  exit 0
  

• publisher-hub2live script:

  #!/bin/sh
  
  echo "****"
  echo "**** Pulling changes into Live [publisher-hub2live]"
  echo "****"
  
  cd "$1" || exit
  umask 0022
  unset GIT_DIR
  /usr/bin/git pull hub master
  
  # custom actions here
  # e.g call grunt tasks
  /bin/chown -R "$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
  
  exit 0
  

• Um live repo post-commit hook também pode ser útil, se você fizer alterações na árvore de trabalho com check-out do live repo e quiser sincronize o hub.

Esta infraestrutura requer as seguintes entradas (ou equivalentes) no seu arquivo 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

Além disso, um bloco Match no seu sshd_config seria útil, dependendo de como você gerencia a identidade em suas máquinas:

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

Com tudo isso funcionando, o envio para o repo hub aciona o gancho post-update , garantindo que suas ações personalizadas sejam executadas somente quando houver algo novo.

    

Answer 2

Acho que você pode resolver esse problema simplesmente fazendo isso:

*/1 * * * * cd /my/sites/staging && git pull -q origin master|grep -v "up-to-date" && grunt production

    

Answer 3

Embora eu não tenha usado o meu conhecimento sobre o link dos fantoches, você pode fazer isso.

Cada vez que o fantoche é executado, se algo mudar, ele será enviado para os outros servidores de forma automática, com base no que é a imagem de ouro. E se você tiver um grande número de servidores depois de criar a imagem de ouro, você poderá criar um fantoche de instalação de base em outro e o novo servidor obterá o restante da configuração do servidor mestre.