K

iedy korzystamy z polecenia git zazwyczaj dotyczy ono przepływu pracy typowego dla kontroli wersji. Mamy lokalne repozytorium na swoim komputerze, na którym pracujemy i zdalne, gdzie trzymamy wszystko w synchronizowanym stanie i możemy pracować z innymi członkami zespołu lub z innych maszyn. Jednak narzędzia git można też użyć do wdrożenia aplikacji / konfiguracji na dowolne środowisko – testowe / produkcyjne. Wyobraźmy sobie następujący przykład:

Posiadamy dwa serwery frontowe (varnish1.front.dev oraz varnish2.front.dev), na których zainstalowany jest akcelerator http varnish. Wdrożenia jego konfiguracji będziemy przeprowadzali z użytkownika ubuntu, który jest standardowy dla dystrybucji o tej samej nazwie w środowiskach chmur obliczeniowych.

1. Repozytorium

Poniższe polecenia należy wykonać na każdym z dwóch serwerów, logując się na konto użytkownika ubuntu

mkdir varnish.git varnish_vcl
cd varnish.git
git init --bare

Opcja --bare oznacza, że folder varnish.git nie będzie posiadał żadnych plików źródłowych, a jedynie kontrolę wersji. Właśnie do tak stworzonych repozytoriów będziemy wysyłać z naszego lokalnego komputera pliki konfiguracyjne.

2. Hook

Każde z wyżej stworzonych repozytoriów posiada katalog ‘hooks’. Posiada on przykładowe pliki, które możemy podpiąć dla konkretnych akcji. Dokumentacja narzędzia git opisuje trzy możliwe hooki: ‘pre-receive’, ‘post-receivce’ oraz ‘update’. Nas będzie interesować ‘post-receive’, który jest wykonywany, jak tylko zakończy się ‘push’ do repozytorium.

cd hooks
cat > post-receive << EOF
#!/bin/bash

IP="$(ip addr show eth0 | grep 'inet ' | cut -f2 | awk '{ print $2}')"
VCL_PATH=/home/ubuntu/varnish_vcl

echo "Welcome to '${HOSTNAME}' - (${IP})"
echo
echo "Checking out new files..."

GIT_WORK_TREE=$VCL_PATH git checkout -f master

echo "Checking VCL syntax."

RETVAL=$(sudo /usr/sbin/varnishd -C -f $VCL_PATH/default.vcl &> /dev/null; echo $?)
if [ $RETVAL -ne 0 ]; then
     echo "Varnish syntax check failed."
     exit $RETVAL
fi

echo "Restarting varnish."
sudo /etc/init.d/varnish restart
EOF
chmod +x post-receive

Jak możemy wyczytać z skryptu ‘GIT_WORK_TREE’ jest katalogiem, gdzie zostaną przetransferowane nasze pliki konfiguracyjne, które “wypchniemy” do repozytorium. Przed restartem serwera varnish zostanie przeprowadzone sprawdzanie składni, aby mieć pewność, że restart powiedzie się. W tym celu należy nadać uprawnienia sudo dla użytkownika ubuntu do uruchamiania daemona varnishd oraz wykonywania restartów za pomocą skryptu init. W zależności od polityki czyszczenia pamięci cache – restart możemy zastąpić na wyrażenie reload. Aby serwer varnish korzystał z plików konfiguracyjnych wdrażanych do repozytorium należy utworzyć link symboliczny do nich prowadzący z standardowej ścieżki konfiguracji:

ln -sf /etc/varnish/default.vcl /home/ubuntu/varnish_vcl/default.vcl

3. Stacja klienta

Na komputerze, z którego będziemy wykonywać wdrożenie stwórzmy lokalne repozytorium.

cd push_to_deploy
mkdir varnish
git init

Następnie skonfigurujmy zdalne serwery, do których będziemy wysyłać kod:

git config --add remote.dev.url ssh://ubuntu@varnish1.front.dev/home/ubuntu/varnish.git
git config --add remove.dev.url ssh://ubuntu@varnish2.front.dev/home/ubuntu/varnish.git

Ze względu na to, że komunikujemy się z serwerami za pomocą protokołu SSH ułatwieniem jest ustawienie wspólnego klucza SSH i poinformowanie klienta SSH, aby używał zdefiniowanego użytkownika i wspólnego klucza (~/.ssh/config) dla naszych serwerów:

Host varnish*.front.dev
    User ubuntu
    IdentityFile ~/.ssh/keys/varnish_dev.pem

Po tak przygotowanej konfiguracji jesteśmy gotowi, aby wykonać pierwsze wdrożenie plików konfiguracyjnych dla serwera varnish. W katalogu stworzonego repozytorium umieszczamy plik z konfiguracją i wydajemy polecenia:

git add .
git commit -m "Varnish configuration v0.1"

Etapem kończącym całą procedurę jest wysłanie wszystkiego na serwery frontowe:

git push dev master

Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 315 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Welcome to 'varnish1.front.dev' - (10.1.1.1/16)
remote:
remote: Checking out new files...
remote: Already on 'master'
remote: Checking VCL syntax.
remote: Restarting varnish.
remote:  * Stopping HTTP accelerator varnishd
remote:    ...done.
remote:  * Starting HTTP accelerator varnishd
remote:    ...done.
To ssh://ubuntu@varnish1.front.dev/home/ubuntu/varnish.git
   6b8d8c5..de512e7  master -> master
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 315 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Welcome to 'varnish2.front.dev' - (10.1.1.1/16)
remote:
remote: Checking out new files...
remote: Already on 'master'
remote: Checking VCL syntax.
remote: Restarting varnish.
remote:  * Stopping HTTP accelerator varnishd
remote:    ...done.
remote:  * Starting HTTP accelerator varnishd
remote:    ...done.
To ssh://ubuntu@varnish2.front.dev/home/ubuntu/varnish.git
   6b8d8c5..de512e7  master -> master

W ten sposób na lokalnej stacji rejestrujemy wszystkie zmiany, mamy możliwość cofania się do konkretnych wersji plików i pracy grupowej – jednocześnie posiadając możliwość od razu wdrażania swoich dokonań na serwery, czy to w środowisku testowym, czy produkcyjnym.

Więcej informacji: Setting up Push-to-Deploy with git