źródło obrazu: infografika wektor stworzony przez pikisuperstar — www.freepik.com

sieci dostarczania treści (CDN) są zwykle używane przez witryny i aplikacje do przyspieszania ładowania elementów statycznych. Osiąga się to poprzez buforowanie plików na serwerach CDN zlokalizowanych w różnych regionach świata. Po zażądaniu danych przez CDN, użytkownik otrzymuje je z najbliższego serwera.

podstawowe zasady CDN i ich funkcjonalność są w przybliżeniu takie same dla wszystkich z nich. Po otrzymaniu żądania o plik, serwer CDN pobiera go raz z serwera origin, a następnie przesyła go do użytkownika i przechowuje jego kopię na pewien czas. Dalsze żądania danych są obsługiwane za pomocą pamięci podręcznej. Wszystkie CDN mają opcje wstępnego ładowania plików, czyszczenia pamięci podręcznej, czasu przechowywania pamięci podręcznej i wiele więcej.

czasami, z różnych powodów, można znaleźć się w potrzebie zbudowania własnego CDN, dlatego przedstawiamy poniższy przewodnik, jak go zrealizować.

kiedy potrzebujesz własnego CDN?

przyjrzyjmy się sytuacjom, w których może być konieczne utworzenie własnego CDN:

• gdy próbujesz zaoszczędzić pieniądze, a nawet niedrogie rozwiązania, takie jak BunnyCDN, kosztują Cię setki dolarów miesięcznie
• gdy chcesz uzyskać stałą pamięć podręczną lub potrzebujesz gwarantowanej przepustowości i zasobów
• istniejące CDN nie mają wyskakujących okienek w regionie docelowym
• potrzebujesz specjalnych ustawień dostarczania treści
• chcesz przyspieszyć up dostarczania treści dynamicznych poprzez serwowanie go bliżej użytkowników
• jesteś zaniepokojony CDN osób trzecich może nielegalnie zbierać i wykorzystywać dane użytkowników (Hej tam, serwery, które nie są Zgodnie z RODO) lub angażować się w inne nielegalne działania

w większości innych przypadków bardziej opłacalne jest wykorzystanie istniejących gotowych rozwiązań.

stwórzmy własny CDN

aby zbudować nawet prostą sieć dostarczania treści, potrzebujesz następujących:

• nazwa domeny lub subdomeny
• co najmniej dwa serwery w różnych regionach. Serwery mogą być dedykowane lub wirtualne
• narzędzie geoDNS. Dzięki niemu użytkownik wysyłający żądanie do domeny zostanie skierowany na najbliższy serwer

Rejestracja domeny i zamawianie serwerów

Rejestracja nazwy domeny jest łatwa — wystarczy zarejestrować ją w dowolnej strefie domeny. W przypadku CDN możesz użyć również subdomeny, takiej jak cdn.domainname.com. tak jest w przypadku następującego przykładu.

jeśli chodzi o serwery, powinieneś wynająć te w regionach i krajach, w których znajduje się twoja grupa docelowa. Jeśli twój projekt jest intercontinental, wygodnie jest wybrać spośród dostawców hostingu oferujących serwery na całym świecie, takich jak OVH, Leaseweb i 100tb (dla serwerów dedykowanych) lub Vultr i DigitalOcean (dla serwerów wirtualnych i w chmurze).

dla naszego prywatnego CDN, zamówmy trzy wirtualne serwery na różnych kontynentach. Vultr oferuje nam 25 GB miejsca na dysku SSD i 1 TB ruchu za $ 5 / miesiąc. Podczas instalacji wybierz najnowszy Debian. Oto nasze serwery:

• Frankfurt, ip: 199.247.18.199

• Chicago, ip: 149.28.121. * 123

• Singapur, ip: 157.230.240.216

Konfigurowanie geoDNS

aby upewnić się, że klienci są kierowani na właściwe (najbliższe) serwery po wysłaniu żądań do naszej domeny lub subdomeny, będziemy potrzebować serwera DNS z funkcjonalnością geoDNS.

oto jak działa geoDNS:

1. pobiera IP klienta (jeśli wysłał żądanie DNS) lub IP rekurencyjnego serwera DNS, który jest używany do przetwarzania żądania. Ogólnie rzecz biorąc, takie rekurencyjne serwery są zwykle DNSs dostawców Internetu.
2. przez IP klienta identyfikuje jego kraj lub region. Ta operacja wymaga użycia bazy danych GeoIP, które są dostępne bez niedoborów. Istnieją nawet przyzwoite darmowe opcje.
3. w zależności od lokalizacji klienta, geoDNS zwraca mu adres IP najbliższego serwera CDN.

serwer DNS z funkcjonalnością geoDNS to coś, co możesz zbudować samodzielnie, ale lepiej jest użyć gotowych rozwiązań, które mają serwery na całym świecie i gotową opcję Anycast:

• ClouDNS, od $ 9 .95 / miesiąc, Pakiet GeoDNS, jedno przełączanie awaryjne DNS jest dostarczane domyślnie
• Zilore, od $25 / miesiąc, zawiera przełączanie awaryjne DNS
• Amazon Route 53, od $35/miesiąc dla 50 milionów żądań geograficznych. Przełączanie awaryjne DNS jest wyceniane osobno
• łatwe DNS, Od $125 / miesiąc, z przełączaniem awaryjnym DNS 10
• Cloudflare, funkcja sterowania Geo jest dostępna w pakietach korporacyjnych

zamawiając geoDNS, musisz zwrócić uwagę na liczbę żądań zawartych w pakiecie i pamiętać, że rzeczywista liczba żądań może znacznie przekroczyć Twoje oczekiwania. W każdej chwili działają miliony robotów, skanerów, spamerów i innych diabłów.

prawie wszystkie usługi DNS zawierają przydatną funkcję budowania CDN – przełączanie awaryjne DNS. Dzięki niemu możesz skonfigurować monitorowanie aktywności tak, aby w przypadku awarii serwera system automatycznie przekierowywał klientów na działające serwery.

w przypadku naszego CDN użyjmy ClouDNS i jego pakietu GeoDNS.

w profilu Dodaj nową strefę DNS i podaj nazwę domeny. Jeśli używasz subdomeny, a domena główna jest w użyciu, nie zapomnij dodać istniejących rekordów DNS natychmiast po dodaniu strefy. Następnym krokiem jest utworzenie kilku rekordów A dla domeny/subdomeny CDN, z których każdy będzie używany dla określonego regionu. Możesz wyznaczyć kontynenty lub kraje jako regiony, a opcje podregionów są dostępne dla USA i Kanady.

w naszym przykładzie CDN będzie działał na cdn.sayt.in subdomena. Po dodaniu sayt.in zone, Utwórz pierwszy rekord a dla subdomeny i skieruj wszystkich klientów NA serwer Chicago:

powtórz ten krok dla innych regionów i nie zapomnij utworzyć jednego rekordu dla regionów domyślnych. Oto jak wygląda efekt końcowy:

ostatni domyślny rekord oznacza żądania ze wszystkich nieokreślonych Regionów (Europa, Afryka, użytkownicy internetu satelitarnego itp.) mają być kierowane na serwer we Frankfurcie.

to kończy podstawową konfigurację DNS. Wszystko, co pozostało, to przejść do strony REJESTRATORA i zastąpić bieżące serwery nazw tymi dostarczonymi przez ClouDNS. Gdy będą aktualizowane, ustawimy serwery.

instalacja certyfikatów SSL

nasz CDN będzie działał przy użyciu HTTPS, więc jeśli masz już certyfikaty SSL dla domeny lub subdomeny, prześlij je na wszystkie serwery, na przykład do katalogu/etc/ssl/ yourdomain/.

jeśli nie masz żadnych certyfikatów, możesz je pobrać za darmo z Let ’ s Encrypt. Skrypt powłoki ACME jest świetnym rozwiązaniem. Posiada przyjaznego dla Użytkownika Klienta i, co ważniejsze, pozwala na przeprowadzenie walidacji domeny / subdomeny za pośrednictwem DNS przy użyciu API przez ClouDNS.

zainstalujemy acme.sh tylko na jednym serwerze — europejskim (199.247.18.199), a z niego certyfikaty zostaną skopiowane do wszystkich pozostałych. Aby go zainstalować, uruchom następujące polecenie:

root@cdn:~# wget -O - https://get.acme.sh | bash; source ~/.bashrc

podczas instalacji zostanie utworzone zadanie CRON do automatycznej aktualizacji certyfikatów.

weryfikacja Domeny po wystawieniu certyfikatu będzie przeprowadzana za pośrednictwem DNS przy użyciu API, więc w profilu ClouDNS, w sekcji Reseller API, utwórz nowego użytkownika API i podaj hasło do niego. Wprowadź wynikowy identyfikator auth-id wraz z hasłem do następującego pliku:~/. acme.sh/dnsapi/dns_cloudns.sh (nie mylić z dns_clouddns.sh). oto linie, które musisz odkomentować i edytować:

CLOUDNS_AUTH_ID=<auth-id>CLOUDNS_AUTH_PASSWORD="<password>"

teraz zażądajmy wydania certyfikatu SSL dla cdn.sayt.na

root@cdn:~# acme.sh --issue --dns dns_cloudns -d cdn.sayt.in --reloadcmd "service nginx reload"

do wykorzystania w przyszłości w parametrach pozostawiliśmy polecenie automatycznego restartu konfiguracji po każdym odnowieniu certyfikatu.

proces uzyskania certyfikatu może potrwać do dwóch minut, więc nie przerywaj go. W przypadku wystąpienia błędu walidacji domeny spróbuj ponownie uruchomić polecenie. Na koniec zobaczymy, gdzie zostały pobrane certyfikaty.

Zapamiętaj te ścieżki, musimy je określić podczas kopiowania Certyfikatów na inne serwery i musimy je określić w ustawieniach serwera. Zignoruj błąd przeładowania konfiguracji Nginx, — nie wystąpi on na w pełni skonfigurowanym serwerze podczas odnawiania certyfikatu.

jeśli chodzi o certyfikat SSL, pozostało nam jedynie skopiować go na dwa inne serwery, zapisując ścieżki certyfikatów. Utwórz identyczne katalogi na każdym serwerze, a następnie skopiuj pliki certyfikatów:

root@cdn:~# mkdir -p /root/.acme.sh/cdn.sayt.in/root@cdn:~# scp -r [email protected]:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/

aby zautomatyzować odnowienie certyfikatu, musisz utworzyć codzienne zadanie CRON na obu serwerach. Poniżej znajduje się polecenie, które należy dodać do zadań CRON:

scp -r [email protected]:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/ && service nginx reload</pre>

należy pamiętać, że połączenie ze zdalnym serwerem origin wymaga dostępu za pomocą klucza bez wprowadzania hasła. Nie zapomnij go stworzyć.

instalacja i konfiguracja Nginx

do dostarczania statycznej zawartości użyjemy Nginx, skonfigurowanego jako buforujący serwer proxy. Zaktualizuj listę pakietów i zainstaluj ją na wszystkich trzech serwerach:

root@cdn:~# apt updateroot@cdn:~# apt install nginx

zamiast domyślnej konfiguracji użyj poniższej:

nginx.conf

user www-data;worker_processes auto;pid /run/nginx.pid;events { worker_connections 4096; multi_accept on;}http { sendfile on; tcp_nopush on; tcp_nodelay on; types_hash_max_size 2048; include /etc/nginx/mime.types; default_type application/octet-stream; access_log off; error_log /var/log/nginx/error.log; gzip on; gzip_disable "msie6"; gzip_comp_level 6; gzip_proxied any; gzip_vary on; gzip_types text/plain application/javascript text/javascript text/css application/json application/xml text/xml application/rss+xml; gunzip on; proxy_temp_path /var/cache/tmp; proxy_cache_path /var/cache/cdn levels=1:2 keys_zone=cdn:64m max_size=20g inactive=7d; proxy_cache_bypass $http_x_update;server { listen 443 ssl; server_name cdn.sayt.in; ssl_certificate /root/.acme.sh/cdn.sayt.in/cdn.sayt.in.cer; ssl_certificate_key /root/.acme.sh/cdn.sayt.in/cdn.sayt.in.key; location / { proxy_cache cdn; proxy_cache_key $uri$is_args$args; proxy_cache_valid 90d; proxy_pass https://sayt.in; } }}

w config, edytujmy:

• max_size — rozmiar pamięci podręcznej nie przekraczający dostępnego miejsca na dysku
• nieaktywny — czas retencji dla nieprzepytanych danych w pamięci podręcznej
• ssl_certificate i ssl_certificate_key — ścieżki do certyfikatu SSL i klucza
• proxy_cache_valid — czas retencji dla danych w pamięci podręcznej
• proxy_pass — adres serwera początkowego, z którego CDN zażąda danych do buforowania. Dla naszego przykładu jest to sayt.in

jak widać, to żadna fizyka. Jedyną trudnością jest skonfigurowanie czasu retencji, biorąc pod uwagę podobieństwa między parametrami nieaktywnymi i proxy_cache_valid. Przyjrzyjmy się bliżej. Oto co dzieje się z inactive=7d i proxy_cache_valid=90d:

• jeśli żądanie nie zostanie powtórzone w ciągu 7 dni, dane zostaną usunięte z pamięci podręcznej
• jeśli żądanie zostanie powtórzone nawet raz w ciągu 7 dni, Pamięć podręczna zostanie uznana za nieaktualną po 90 dniach, a następne żądanie spowoduje, że Nginx zaktualizuje je z serwera origin

za pomocą nginx.conf obsługiwane, przeładować konfigurację:

root@cdn:~# service nginx reload

nasz CDN jest gotowy do użycia! Za $15 / miesiąc mamy Pop na trzech kontynentach i 3TB ruchu: 1TB dla każdego regionu.

sprawdzanie naszego CDN

rzućmy okiem na ping do naszego CDN z różnych lokalizacji. Wszelkie usługi ping zrobią w tym przypadku.

wyniki są dobre. Teraz umieśćmy obraz testowy zatytułowany test.jpg na głównym serwerze i sprawdź jak szybko się ładuje przez CDN. Załatwione. Ładowanie jest szybkie.

zróbmy mały skrypt na wypadek, gdybyśmy musieli wyczyścić pamięć podręczną w punkcie CDN.

purge.sh

#!/bin/bashif then echo "Purging all cache" rm -rf /var/cache/cdn/*else echo "Purging " FILE=`echo -n "" | md5sum | awk '{print }'` FULLPATH=/var/cache/cdn/${FILE:31:1}/${FILE:29:2}/${FILE} rm -f "${FULLPATH}"fi

aby wyczyścić całą pamięć podręczną na serwerze, po prostu uruchom skrypt. Jeśli potrzebujesz wyczyścić jakiś plik, po prostu podaj jego ścieżkę:

root@cdn:~# ./purge.sh /test.jpg 

aby wyczyścić pamięć podręczną, skrypt musi być uruchomiony na wszystkich serwerach CDN.

zamiast wniosków

na koniec chciałbym dać kilka przydatnych wskazówek, abyś mógł uniknąć wpadnięcia w pułapki, które już wyczyściłem:

• zastanów się nad opłacalnością i kosztami utrzymania przyszłego CDN. W większości przypadków zakup taniego CDN jest znacznie wydajniejszy i łatwiejszy, co najprawdopodobniej będzie bardziej stabilne i lepszej jakości.
• aby poprawić odporność na błędy CDN, zaleca się skonfigurowanie przełączania awaryjnego DNS, które pozwoliłoby na szybkie przełączanie rekordu a w przypadku awarii serwera. Możesz to zrobić w Panelu sterowania rekordami DNS.
• strony o szerokim zasięgu wymagają dużej ilości Popów, ale nie przesadzają. Najprawdopodobniej użytkownik nie zauważy różnicy między Twoim CDN a płatnym, jeśli masz serwery w 6-7 lokalizacjach (Europa, Ameryka Północna (Wschód), Ameryka Północna (Zachód), Singapur, Australia, Hong Kong lub Japonia).
• czasami dostawcy hostingu nie zezwalają na korzystanie z wynajętych serwerów dla CDN. Jeśli więc chcesz utworzyć usługę CDN, zapoznaj się z warunkami dostawcy usług hostingowych.
• zapoznaj się z mapą kabli podmorskich, aby zrozumieć, w jaki sposób kontynenty są połączone i wykorzystać tę wiedzę podczas budowania CDN.
• spróbuj pingować swoje serwery z różnych lokalizacji. W ten sposób możesz wykryć regiony najbliżej Twoich wyskakujących okienek, co pomoże Ci skonfigurować GeoDNS.