Pewnie wszyscy znacie powiedzonko „Ludzie dzielą się na tych, co robią backupy i tych co dopiero będą je robić…”. I jak to w życiu bywa, większość osób przed mniejszą/większą utratą danych zalicza się do drugiej grupy. Ja do dzisiaj stałem „rozkrokiem”… 
Od kilku miesięcy regularnie backupuję z desktopa (M$ Windows) całą bibliotekę zdjęć (obecnie ok. 33GB) używając DragonDisk – Amazon S3 Client. Ale jakoś ciągle brakowało mi czasu/chęci aby zorganizować backup/archiwum projektów z serwera deweloperskiego. Aż do dzisiaj, gdy podczas robienia drobnych porządków, skasowałem sobie repozytorium jednego z archiwalnych projektów…
Idea podłączenia usługi Amazon S3 jako dysku (za pomocą s3fs), chodziła mi po głowie od dłuższego czasu. Takie rozwiązanie ma dwie zasadnicze zalety:
- dostępność – nie wymaga uruchamiania klienta, logowania, kopiowania danych na lokalny system plików i wgrywania ich z powrotem gdy coś zmodyfikujemy
- lokalny cache – domyślnie nie jest włączony – dzięki tej opcji praca na pliku wykonywana jest w lokalnym systemie plików a zmiany wprowadzane są automatycznie do S3 jak tylko plik zostanie zwolniony
Dla równowagi natury rzeczy istnieją też dwa istotne ograniczenia:
- Eventual Consistency - w skrócie oznacza to, że po wykonaniu operacji zapisu, zmiany mogą nie być natychmiast dostępne dla następującej po niej operacji odczytu. Innymi słowy, mamy do czynienia z rozproszonym systemem plików i nie możemy wymagać od niego tego samego, czego wymaga się od lokalnej pamięci. Ważne aby podczas tworzenia „wiaderka” wybrać region US-West lub EU ponieważ rozwiązują one jeden z problemów spójności, a dokładniej „read-after-write” (nadal należy się liczyć z problemami „read-after-delete” i „read-after-update”)
- brak zarządzania dostępem – albo zawartość dysku jest dostępna tylko dla root’a, albo dla wszystkich użytkowników systemu
Przejdźmy więc do konkretów. Najpierw upewniamy się, że mamy zainstalowane niezbędne pakiety:
apt-get install build-essential libfuse-dev fuse-utils libcurl4-openssl-dev libxml2-dev mime-support
Pobieramy, kompilujemy i instalujemy s3fs:
wget http://s3fs.googlecode.com/files/s3fs-1.61.tar.gz tar xvzf s3fs-1.61.tar.gz cd s3fs-1.61/ ./configure --prefix=/usr make make install
Dane dostępowe do usługi Amazon S3 możemy podać podczas montowania dysku, stworzyć plik .passwd-s3fs w lokalnym katalogu użytkownika, zdefiniować zmienne środowiskowe AWSACCESSKEYID i AWSSECRETACCESSKEY lub zapisać w globalnym pliku konfiguracyjnym /etc/passwd-s3fs. Osobiście najbardziej przypadła mi do gustu ostatnia opcja:
touch /etc/passwd-s3fs chmod 640 /etc/passwd-s3fs echo "bucketName:accessKeyId:secretAccessKey" | tee /etc/passwd-s3fs
Montujemy dysk z opcją cache oraz dostępem dla zwykłych użytkowników:
mkdir /mnt/bucketName mkdir /var/lib/s3fs s3fs bucketName /mnt/bucketName/ -o use_cache=/var/lib/s3fs -o allow_other
W katalogu /mnt/bucketName powinna pojawić się zawartość „wiaderka” z S3. Jeśli jeszcze nic do niego nie wrzucaliśmy możemy dla pewności przetestować polecenie w stylu echo "foo bar baz" | tee /mnt/bucketName/test.txt i sprawdzić w konsoli AWS czy plik został dodany. Jeśli wszystko działa jak powinno możemy uprościć montowanie naszego dysku dodając odpowiedni wpis w /etc/fstab
umount /mnt/bucketName cp -a /etc/fstab /etc/fstab.bak echo "s3fs#bucketName /mnt/bucketName fuse use_cache=/var/lib/s3fs,allow_other 0 0" | tee -a /etc/fstab mount /mnt/bucketName
Pewnie zastanawiacie się jak taki dysk można wykorzystać poza zwykłym rsync’owaniem do niego ważnych katalogów/plików. Ja postanowiłem sprawdzić jak s3fs poradzi sobie z przechowywaniem repozytoriów Git. Odpaliłem kopię Gitolite i mam zamiar push’ować do niego źródła projektu esmoke, który dłubię w wolnych chwilach. Jak będę miał jakieś przemyślenia z chęcią się z Wami podzielę.
