Prosty deploy przez GITa

2 kwietnia 20174 kwietnia 2017 Mirosław Okoński komentarzy 14 deploy, DSP2017, git, vps

Total: 61
48
1
0
10
2

Temat wypychania aplikacji na produkcję jest dosyć szeroki. Mamy sporo możliwości, choćby korzystając z takiego oprogramowania jak chyba najpopularniejsze Capistrano, Mina, czy wspomagając się narzędziami typu Ansible. Ale nie zawsze potrzebujemy strzelać z armaty do muchy. Przy mini projektach przesyłanych na naszego VPSa można to zrobić w banalnie prosty sposób przy wykorzystaniu GITa, którego i tak używamy.

Żeby było ciekawiej GITa do deploymentu można użyć na kilka sposobów ale dzisiaj opowiem wam o tym, moim zdaniem, najprostszym z możliwych.

Założenia

Przyjmuję, że mamy na localhoście jakiś mały projekt, który nie potrzebuje żadnych wymyślnych czynności i w zasadzie jego cały deploy sprowadza się do przesłania plików na serwer. Projekt oczywiście jest w gicie – nie wyobrażam sobie, że ktoś jeszcze w obecnych czasach pracuje bez tego. Z drugiej strony mamy swojego VPSa lub hosting z dostępem do SSH i GITa.

I cały proces polega na tym, że na VPS robimy nowe repozytorium GITa, w którym podpinamy pod hooka akcję przenoszącą kod na docelowe miejsce. Z kolei z localhosta wypychamy kod na to repozytorium i tyle. Magia dzieje się w tle 😉 Zobaczmy jakie to jest proste w implementacji.

Konfiguracja na VPS

Tutaj potrzebujemy dwa miejsca: jedno to docelowy katalog odpalany przez serwer. Przyjmijmy, że to jest /home/webmastah/app/public_html. Drugie to miejsce gdzie założymy sobie nasze nowe repozytorum GITA – /home/webmastah/repo.

Przechodzimy do tego katalogu i zakładamy owe repo:

cd /home/webmastah/repo
mkdir webmastah.git && cd webmastah.git
git init --bare

cd /home/webmastah/repo

mkdir webmastah.git && cd webmastah.git

git init --bare

Opcja --bare oznacza, że nie chcemy trzymać w nim bieżącej kopii do pracy – wszak nie będziemy nic tam robić. Polecam dokładniejsze wyjaśnienie na StackOverflow.

Tworzymy hooka

W utworzonym repozytorium GITa znajdziesz katalog hooks. W środku będzie kilka przykładowych plików dla danych akcji. GIT ma ich kilka, m.in. pre-commit, pre-rebase, update, dokładniejsze wyjaśnienie znajdziesz w dokumentacji. Nas interesuje post-receive który jak sama nazwa wskazuje jest odpalany w momencie jak zawartość PUSHa w komplecie dotarła do repozytorium.

Ok, wejdźmy do tego katalogu i stwórzmy naszego hooka.

cd hooks
cat > post-receive

1 2	cd hooks cat > post-receive

Użyj swojego ulubionego edytora lub jeżeli nie wiesz jak to robić użyj powyższego cat > post-receive. Po klepnięciu entera będziesz mógł wpisać zawartość do tego pliku, a całość zakończyć poprzez skrót control-d.

Do pliku wstaw:

#!/bin/sh
git --work-tree=/home/webmastah/app/public_html --git-dir=/home/webmastah/repo/webmastah.git checkout -f

1 2	#!/bin/sh git --work-tree=/home/webmastah/app/public_html --git-dir=/home/webmastah/repo/webmastah.git checkout -f

Gdzie --work-tree wskazuje na nasz katalog gdzie odpalana jest aplikacja, a --git-dir na nasze utworzone przed chwilą repo.

Po wyjściu nie zapomnij nadać odpowiednich praw do tego pliku chmod +x post-receive

Tym sposobem za każdym razem jak to repozytorium otrzyma kod automatycznie przeniesie go na docelowe miejsce z naszą aplikacją.

Konfiguracja na localhoście

Przechodzimy do katalogu z naszym projektem i dodajemy do GITa nasze zewnętrzne repozytorium:

git remote add live ssh://user@mydomain.com/home/webmastah/repo/webmastah.git

1	git remote add live ssh://user@mydomain.com/home/webmastah/repo/webmastah.git

live tutaj jest dowolną nazwą, równie dobrze może to być dev czy prod. Zresztą w ten sam sposób możesz skonfigurować sobie środowisko testowe i później w zależności od potrzeb pchać zmiany w odpowiednie miejsce.

I robimy deploya

Działamy standardowo z naszym projektem. W momencie jak będziemy chcieli nasze zmiany wypchnąć na produkcję robimy po prostu git push live i gotowe. Prawda, że proste?

Wersja Video

Wkrótce video tutorial z całego tego procesu krok po kroku. Chcesz zobaczyć? SUBSKRYBUJ!

Jakub Skałecki

Dobry, prosty sposób 🙂 Czy gdybyśmy mieli nieco bardziej skomplikowany deploy, i chcielibyśmy otrzymać info po zrobieniu pusha czy wszystko jest ok, to da się to zrobić? Tzn „wysłać” z post-receive wiadomość do naszego terminala?

Dodatkowo jeszcze słyszałem (nie używałem) że fajnym i dość prostym rozwiązaniem jest Dokku (http://dokku.viewdocs.io/dokku/)
- nrm
  
  O, ciekawe pytanie zadałeś. Nigdy nie szukałem bo samo popchnięcie mi wystarcza, nie za bardzo ma się tam coś wywalić. Nie znalazłem w dokumentacji jak zrobić żeby push na remote zwrócił wynik swojego działania z remote konsoli.
  - Piotr
    
    Napisałem kiedyś taki skrypcik.
    Jeżeli push jest do mastera, wszystko idzie live. W innym wypadku idzie na instancję testową, trzymaną obok 🙂
    
    Można do oczywiście ulepszyć i tworzyć osobne instancje testowe per-branch, ale w tym projekcie to było zbędne.
    
    Dodatkowo cały output wraca, mam więc info czy poprawnie wygenerował assety i wyczyścił cache
    
    PS. Da się tutaj formatować kod? 😀
    
    #!/bin/bash
    while read oldrev newrev refname do branch=$(git rev-parse --symbolic --abbrev-ref $refname) if [ "master" == "$branch" ]; then PREFIX="/home/user/web" else PREFIX="/home/user/test" fi echo "Updating files" git --work-tree=$PREFIX --git-dir=/home/user/git checkout $branch -f cd $PREFIX echo "Generating assets" "$PREFIX/node_modules/.bin/gulp"
    echo "Clearing cache" redis-cli flushall done
    - Jakub Skałecki
      
      „Dodatkowo cały output wraca, mam więc info czy poprawnie wygenerował assety i wyczyścił cache”
      
      Dzięki, właśnie o to mi chodziło!
    - nrm
      
      Super!
      
      ps. tagi html pre/post, poprawiłem Ci komentarz. DZIEKI!!!
Jakub Stephan

Dobry artykuł 🙂

Mam tylko pytanie czy update triggeruje się przy każdym pushu na brancha live, i czy live jest to nastwa brancha ?

Czy budowanie wykonuje się z default czyli pewnie z mastera ?
- nrm
  
  Tak, przy każdym bo na zdalnym to jest hook który działa automatycznie jak coś dostanie. No i jest to prosty hook który w zasadzie nic więcej nie robi, nie sprawdza, nie ma żadnej dodatkowej logiki. Tylko przerzuca do katalogu wykonywalnego.
  
  Tak, z mastera bo to jest skrót od git push live master i tym samym możesz zrobić sobie z innych branchy czy też zrobić kilka środowisk. Ogólnie to jest taki prosty sposób na mini projekty więc zakładam, że raczej nikt poza takie proste użīcie nie wyjdzie ale może się mylę.
  - Jakub Stephan
    
    Ten trigger wywołuje się również przy mergowaniu przez GitLaba na przykład z brancha development do mastera ?
    - Paweł Podolski
      
      Hooki można „oszukać” na wiele prostych sposobów, bo robią tylko i aż to, pod co są „zahaczone”. Możesz zrobić merge(lub rebase), a potem reset indeksu do wcześniejszego mastera, commit i git push live. Dla znających gerrita to żadna nowość. Tutaj jest hook na post receive. Można dodać na post-merge, ale ja bym się bał, bo czasem się zdarza, że po merge i tak trzeba posprzątać i zrobić drugiego pusha;) uff
  - Jakub Stephan
    
    Mam pytanie odnośnie tego sposobu: jak zrobić push’a na zdalne repozytorium o nazwie test z brancha test2 (wychodzi z mastera) ?
    
    Jest to poprawnie? = git push test test2
    Pliki zostają przesłane:
    [html]
    Counting objects: 3, done.
    Delta compression using up to 4 threads.
    Compressing objects: 100% (2/2), done.
    Writing objects: 100% (3/3), 306 bytes | 0 bytes/s, done.
    Total 3 (delta 0), reused 0 (delta 0)
    To ssh://….
    8d5d4c5..3bb4274 test2 -> test2
    [/html]
    
    Jednak jeśli chodzi o pliki to nie następuje podmiana.
Michał Kortas

Proste. Korzystam z tego przy prostych projektach.
Sergiusz Gieszczyk

Nie lepiej zainstalować git ftp?
- nrm
  
  nie.
Marcin Sromek

Bardzo fajny sposób 🙂 Dzięki wielkie!

________________
http://e-prom.com.pl