Z racji tego, że jest to pierwszy wpis na tym blogu, postanowiłem zacząć od czegoś szybkiego, prostego i w pełni funkcjonalnego. Z tego wpisu dowiesz się w jaki sposób możesz udostępnić swoją statyczną stronę publicznie w internecie za pośrednictwem usługi S3. Mówiąc statyczną mamy na myśli taką, która składa się jedynie z plików html, arkuszy styli czy też plików Java Script. Do tej kategori zaliczają się wszelkie strony typu wizytówki, portfolia czy też landing page.
Czy jest S3 ?
Chmura kojarzy nam się z możliwościami i szerokim wachlarzem usług i narzędzi, które dostawca oferuje nam w swoim portfolio. W przypadku AWSa mamy możliwość skorzystania z podstawowych ciężkich assetów jak serwery, storage, bazy danych, platformy do zarządzania kontenerami jak i bardzo wielu usług pomocniczych takich jak np. SQS (Simple Queue Service) system do messagingu czy np SES (Simple Email Service) usługi służącej do wysyłki maili. Simple Storage Service, bo tak rozwija się skrót S3 jest usługą storagową. Serwis ten pozwala nam przechowywać nieograniczoną liczbę plików co oznacza, że nie musimy tutaj określać jak wielkiej przestrzeni potrzebujemy. Usługa ta jest bardzo prosta w obsłudze i stosunkowo tania, gdyż płacimy tutaj jedynie za wykorzystane zasoby. Na koszt składają się:
- ilość danych przechowywana w S3
- operacje na plikach – żądanie GET, PUT, LIST na obiektach w buckecie
- transfer danych poza region, w którym bucket został utworzony
Po szczegółowy kosztorys odsyłam na oficjalną stronę AWSa. Dodam jedynie że w ramach AWS free tier mamy możliwość przez rok skorzystania z darmowej przestrzeni do 5 GB z transferem wychodzącym do 15GB
https://aws.amazon.com/s3/pricing/
Większość firm wykorzystuje S3 do przechowywania rozmaitych danych, głównie są to backupy serwerów i baz danych, logi aplikacyjne, statyczne pliki takie jak zdjęcia, filmy oraz właśnie jako hosting do statycznych stron internetowych i właśnie ten przypadek przedstawimy sobie w dalszej części wpisu
Podstawowe pojęcia związane z S3
Zanim zabierzemy się do działania i udostępniania naszej strony postaram się przybliżyć podstawowe pojęcia związane z usługą S3, aby dalsza część wpisu była również zrozumiałą dla osób dopiero zaczynających swoją przygodę z AWS.
Bucket – czyli tak zwany kubełek jest to główny katalogiem w którym będziemy umieszczać nasze pliki. W jego przestrzeni mamy możliwość tworzenia struktury naszych plików, podzielenia ich na podkatalogi itp. Należy jednak pamiętać że foldery, które tworzymy wewnątrz głównego katalogu nie są już bucketami. Na poziomie bucketu mamy możliwość skonfigurowania opcji związanych np. z kontrolą dostępu. Bucket tworzymy w wybranym regionie, ale jego nazwa musi być globalnie unikalna, niezależnie od regionu.
Obiekt – podstawowy byt w S3, jest to nic innego jak nasz plik plus metadane, które go opisują. S3 w momencie wrzucania plik do bucketa opisuje go atrybutami, są to m. in. data ostatniej modyfikacji, rozmiar, czy też wersja (tylko w momencie gdy mamy włączone wersjonowanie plików)
Klucz – jest to unikalny identyfikator obiektu w danym buckecie. Jeśli w naszym buckecie cloud-box w regionie Ireland utworzymy folder photos a następnie dodamy do niego plik holidays01.jpg to będzie on dostępny pod adresem https://cloud-box.s3.eu-west-1.amazonaws.com/photos/holidays01.jpg , a kluczem obiektu będzie własnie jego pełna ścieżka z kubełka a więc photos/holidays01.jpg
Region – jest to geograficzna lokalizacja data center, w której AWS przechowuje nasze pliki. Większość usług w AWS jest właśnie region-specific co oznacza, że musimy sprecyzować w jakiej lokalizacji mają zostać utworzone nasze zasoby, czyli gdzie fizycznie się one znajdują. Dobrą praktyką jest to, abyśmy tworząc nasze zasoby myśleli o tym w jakim części świata będą one wykorzystywane, gdyż ma to wpływ na opóźnienia w przesyłaniu danych.
Domena dla naszej strony
Ważną informacją, którą należy uwzględnić jeszcze przed zdecydowaniem się na korzystanie z S3 jako hostingu dla naszej statycznej strony jest to, że jeżeli chcemy aby strona była dostępna pod posiadaną przez nas domeną, musimy mieć pewność, że bucket o takiej nazwie nie istnieje w infrastrukturze AWSa. Skąd takie wymaganie ? S3 podczas generowania bucketu tworzy adres url, który posiada jego nazwę, przykładowo dla bucketu example.pl, otrzymamy adres https://example.pl.s3.eu-west-1.amazonaws.com. Abyśmy mogli w późniejszym etapie dodać rekord CNAM w DNS by mógł wskazywać on docelową domenę na nasz bucket niezbędna jest tutaj spójność hostnamów. Nie możliwe jest bowie przekierowanie domeny example.pl na obcą domenę np. google.pl przy pomocy serwera DNS, takie żądanie zostanie odrzucone przez serwer googla.
Na potrzeby tego artykułu zarejestrowałem domenę cloud-box.co.pl w serwisie https://www.aftermarket.pl oraz upewniłem się, że bucket o nazwie cloud-box.co.pl oraz www.cloud-box.co.pl nie zostały już utworzony w S3.
Tworzenie bucketu i przesłanie plików do S3
Logujemy się do naszej konsoli w aws.amazon.com, a następnie w wyszukiwarce usług odnajdujemy usługę S3.
Naszym oczom ukaże się konsola S3 przedstawiająca listę wszystkich bucketów utworzonych w ramach naszego konta AWS. Klikamy przycisk Create bucket w celu utworzenia naszego kubełka, w który będzie przechowywać pliki naszej strony
W oknie dialogowym podajemy nazwę bucketu zgodną z nazwą naszej domeny oraz region, w którym nasz bucket ma zostać utworzony. Przyjęło się, że dla zasobów wykorzystywanych w Polsce, najbardziej efektywnymi regionami są Irlandia (eu-west-1) oraz Frankfurt (eu-central-1). W przypadku hostowania statycznej strony AWS rekomenduje utworzenie dwóch kubełków, jeden z naszą naked domain (cloud-box.co.pl) w którym będziemy udostępniać pliki naszej strony, oraz drugi z subdomeną www (www.cloud-box.co.pl). Drugi bucket nie będzie przechowywał plików, a jedynie będzie odpowiedzialny za to, by przekierować nasz ruch gdyby ktoś chciał dostać się do naszej strony wpisując address właśnie z przedrostkiem www. Jest to już old-schoolowe podejście, od którego wiele nowoczesnych portali odchodzi, jednak wciąż wiele stron przekierowuje ruch na swoją subdomenę www m.in. Facebook czy Google
Będąc w wiaderku z cloud-box.co.pl mamy możliwość wgrania plików naszej strony. Na potrzeby tego artykułu możemy skorzystać z darmowych szablonów możliwych do pobrania ze strony https://www.free-css.com/free-css-templates. Po pobraniu i rozpakowaniu przykładowego szablonu możemy przesłać pliki strony metodą drag and drop zaznaczając je i przeciągając je bezpośrednio do okna konsoli S3. Nie zawracając sobie głowy dodatkową konfiguracją potwierdzamy przesłanie plików klikając Upload. Przypominam raz jeszcze, pliki naszej strony wrzucamy jedynie do bucketa z naszą naked domain, bucket z przedrostkiem www pozostaje pusty. Pliki możemy również wrzucić za pomocą AWS CLI.
Mając już nasze pliki w odpowiednim miejscu mamy możliwość podejrzenia ich atrybutów, między innymi adresu url, pod którym nasze dane są dostępne. AWS udostępnia dwa adresy, pod którymi nasze pliki są dostępne
- https://nazwa-bucketu.s3.Region.amazonaws.com/klucz
- https://s3.Region.amazonaws.com/nazwa-bucketu/klucz
W tym momencie jeśli spróbujemy otworzyć adres url naszego pliku w przeglądarce otrzymamy status 403 z informacją AccessDenied, dzieje się tak dlatego, że wszystkie buckety domyślnie są prywatne, co oznacza, że nikt bez uprawnień nie jest wstanie dostać się do nich z internetu. Jest to bardzo ważna i zalecana praktyka, aby nie upubliczniać naszych bucketów na świat. Wyjątkiem od tej reguły jest jedynie hostowanie statycznych strony, dlatego w dalszej części artykułu pokaże w jaki sposób skonfigurować publicznym dostępem do bucketa.
Konfiguracja bucketów S3 do publicznego serwowania statycznej strony
Wracamy do listy naszych bucketów i wybierając ten z naked domain przechodzimy do ustawień dostępu klikając w Permission.
Pierwszym krokiem do upublicznienia zasobów w naszym buckecie jest wyłączenie blokady publicznego dostępu, czyli tak zwana konfiguracja ACL(Access Control List) dla kubełka. Aby to zrobić przechodzimy do podzakładki Block Public Access odznaczamy główny checkbox i klikamy Save i potwierdzamy zmianę w oknie dialogowy wpisując confirm.
Kolejnym krokiem jest dodanie policy dla naszego kubełka. Za pomocą Bucket Policy mamy możliwość nadania uprawnień do konkretnych akcji na naszym buckecie, dla konkretnych kont AWS, bądź IAM userów. W naszym przypadku potrzebujemy skonfigurować politykę tak, aby wszyscy byli uprawnieni tylko i wyłącznie do odczytu danych, a więc mogli wykonać jedynie operacje s3:GetObject. Wklejamy więc poniższą politykę w formacie json do konfiguracji zwracając uwagę na to, że w parametrze Resource należy podać nazwę naszego bucektu.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PublicReadGetObject",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::cloud-box.co.pl/*"
}
]
}Zatwierdzamy zmiany klikając Save. Po wprowadzeniu powyższej polityki zauważymy komunikat z ostrzeżeniem, że nasz bucket jest od tego momentu dostępny dla wszystkich z internetu. Tak jak wcześniej wspomniałem, hostowanie statycznej strony to jedyne odstępstwo od reguły, która mówi o tym, że nie należy nadawać publicznego dostępu bucketom. Historia zna wiele przypadków, gdzie firmy nie dbając o restrykcyjną kontrolę dostępu dla kubełków, padły ofiarą wycieków danych. Dlatego miejcie to proszę na uwadzę. Jako ciekawostkę wklejam link opisujący jeden z takich przypadków https://zaufanatrzeciastrona.pl/post/kilkaset-cv-polakow-zgromadzonych-przez-injobs-bylo-dostepnych-w-sieci/
Gdy nasze konfiguracja ACL oraz polityka bucketu zostały poprawnie skonfigurowane nasza dane są już publicznie dostępne z internetu. Możem już teraz spróbować dostać się do naszego pliku index.html z adresu S3 https://s3-eu-west-1.amazonaws.com/cloud-box.co.pl/index.html
Ostatnią konfiguracją, która musimy wykonać po stronie serwisu S3 jest włączenie opcji hostowania statycznej strony. Wracamy do listy naszych kubełków wybieramy w pierwszej kolejności bucket z naked domain i przechodzimy do jego właściwości. Klikamy opcję Static website hosting zaznaczając pierwszą z opcji, podajemy nazwę pliku, który jest naszą główna stroną, w tym przypadku jest to plik index.html. Na górze tego okna wyświetla nam się adres pod którym będzie dostępna nasza strona w internecie. Po zatwierdzeniu zmian strona będzie już dostępna pod wskazanym adresem. Zapisujemy sobie ten adres, gdyż przyda się on nam w ostatnim kroku gdy będziemy chcieli przekierować naszą docelową domenę na ten adres poprzez serwer DNS.
Dla bucketu z przedrostkiem www powtarzamy powyższe kroki z tą różnicą, że tym razem wybieramy opcje przekierowania wskazując bucket z naked domain, w którym to są pliki naszej strony. Jako protokół wpisujemy http. Owa konfiguracja zapewni nam to, że gdy dla docelowej domeny podamy przedrostek www, nasza strona również będzie osiągalna
Konfiguracja DNS domeny
Teraz przyszedł czas na ostateczną konfigurację, która sprawi, że nasz strona umieszczona w S3 będzie dostępna poprzez naszą zarejestrowaną domenę.
W tym celu musimy zalogować się do panelu administracyjnego serwisu, w którym zarejestrowaliśmy naszą domenę, w moim przypadku jest to https://www.aftermarket.pl. Aby nasza domena kierował prawidłowo do usługi S3 musimy dodać dwa wpisy w DNS
- Rekord CNAME dla naked domain (nie dodajemy przedrostka dla sumbdomeny) a jako wartość podajemy url bucketu
- Rekord CNAME sumbdomena www a jako wartość podajemy naked domain – to spowoduje, że wchodząc na stronę z przedrostkiem www również zostaniem przekierowani w odpowiednie miejsce.
Konfiguracja zakończona, pozostaje jedynie poczekać, aż wpis w DNS zostanie rozpropagowany po internecie, zwykle jest to od kilku do kilkunastu godzin, nie mamy już wpływu na ten proces, jedyne co możemy zrobić to wyczyścić nasz lokalny cash DNS, aby mieć pewność, wartość nie została cachowana na naszej maszynie. Po więcej informacji związanych z propagacją DNS odsyłam https://www.siteground.com/kb/what_is_dns_propagation_and_why_it_takes_so_long/
Podsumowanie
Po wykonaniu wszystkich powyższych kroków nasza statyczna strona powinna być już dostępna pod docelową domeną. Dostęp do niej będziemy mieć jedynie po nieszyfrowanym protokole http. Aby zabezpieczyć naszą stronę protokołem https musielibyśmy wygenerować bądź zakupić certyfikat SSL, ale aby go zainstalować potrzebowalibyśmy już jakiejś usługi hostingowej. W jednym z kolejnych artykułów pokażę, jak możemy zabezpieczyć naszą stronę za pomocą usługi Route 53 przekierowując naszą domenę na serwery DNS Route 53 a następnie generując darmowy certyfikat za pomocą usługi ACM
