dodatkowo nie wszyscy chcą ujawniać rzeczywiste IP swojego serwera
ujawnisz publiczne adresy IP i potem dostajesz atak DDoS i klops
@InzynierSieci: @dobrymarcin: to jak ktoś tak bardzo boi się ujawniać publiczne IP to wypadałoby mieć w takim razie zapasowy globalny CDN i w momencie awarii jednego przepiąć się na drugi właśnie przez zmianę w DNS, alternatyw dla Cloudflare jest całkiem sporo
tylko im bardziej poważny i "krytyczny" projekt tym bardziej i tak taka procedura przepięcia na zapasowy CDN powinna być
@some_ONE: no zalezy jaki projekt, aniagotuje czy downdetector widac nie zarabiaja na tyle by to bylo warte. procedure trzeba wdrozyc, czasem jakies synchronizacje utrzymac, dobrze byloby przetestowac raz na pol roku chociaz
bo nigdy nie wiadomo czy awaria zostanie rozwiązana za godzinę, czy za dwanaście godzin
Można spojrzeć na ostatnie 10 lat i daje to jakieś prawdopodobieństwo, że awaria powinna się zamknąć w kilka godzin.
@maur: oczywiście, i tak jak napisałeś dla stronek typu aniagotuje czy downdetector to wystarczające, dla innych może nie być, bo to że nie zdarzyła się awaria dłuższa niż X godzin nie znaczy że jutro nie zdarzy taka która potrwa 4 * X godzin
wystarczy się przepiąć na jakiś Akamai, Imperva, Cloudfront, Fastly itp.
@some_ONE: Nie po to masz deala z CloudFlare, żeby używać innego dostawcy. No i to nie jest homelab albo mała firma, masz procediury, dostawców, legal itp. To nie jest tak, że wybierasz sobie dostawcę w 5 minut, samo sprawdzenie kontraktu to z tydzień dla legala.
No i to nie jest homelab albo mała firma, masz procediury, dostawców, legal itp.
@BreathDeath: no i dlatego właśnie piszę o tym żeby mieć zapasowego dostawcę ;) przy homelab i małej firmie nie jest to potrzebne, przy czymś poważniejszym zazwyczaj takich dostawców i procedury utrzymania ciągłości działania masz
Bo masz skonfigurowane tylko CloudFlare? Używasz API cloudflare. Przecież nie zainstalujesz external-dns dla np. akamai czy innego dostawcy w 5 minut na produkcji bez jakichkolwiek
@some_ONE: To nie zależy ode mnie. Jak klient chce redundancje wszystkiego to ma, jak nie chce to nie ma. To nie jest przecież decyzja techniczna tylko biznesowa. Ja nie zajmuje się decyzjami biznesowymi. Doradzam i pokazuje jakie są opcje, wady i zalety. Decyzje podejmuje klient na podstawie skalkulowanego przez siebie ryzyka. :)
Ja mogę zrobić redundancje wszystkiego, która będzie kosztowała kupę kasy i wtedy jak cloudflare padnie to klient działa
przepięcie w momencie awarii to zazwyczaj nie jest rocket science
@some_ONE: jeszcze tylko dodam, że jak ktoś korzysta z ich ochrony tylko (proxy/cache/security) to spoko, ale CF pododawał w ostatnich latach sporo serwisów - workery, snippery, rules, transforms, bazy danych też w chmurze i inne systemy storage. I o ile zmiana dns/cdn/cache jest prostsza, tak im więcej systemów w użyciu tym trudniejsza i bardziej kosztowna (rachunki + wdrożenie/utrzymanie). To trochę
źródło: Zdjęcie z biblioteki
PobierzAha, bo padła też Ikea XD
@InzynierSieci: @dobrymarcin: to jak ktoś tak bardzo boi się ujawniać publiczne IP to wypadałoby mieć w takim razie zapasowy globalny CDN i w momencie awarii jednego przepiąć się na drugi właśnie przez zmianę w DNS, alternatyw dla Cloudflare jest całkiem sporo
no albo w czasie awarii nie robić
@some_ONE: no zalezy jaki projekt, aniagotuje czy downdetector widac nie zarabiaja na tyle by to bylo warte. procedure trzeba wdrozyc, czasem jakies synchronizacje utrzymac, dobrze byloby przetestowac raz na pol roku chociaz
bo nigdy nie wiadomo czy awaria zostanie rozwiązana za godzinę, czy za dwanaście godzin
@some_ONE: patrzac na
@Ibiryd: no, poczułem się jak w latach 90 ;)
@BreathDeath: jak chcesz być zależny od jednego dostawcy i mieć związane ręce w momencie awarii to i owszem, nie zawsze chcesz ( ͡° ͜ʖ ͡°)
@maur: oczywiście, i tak jak napisałeś dla stronek typu aniagotuje czy downdetector to wystarczające, dla innych może nie być, bo to że nie zdarzyła się awaria dłuższa niż X godzin nie znaczy że jutro nie zdarzy taka która potrwa 4 * X godzin
@some_ONE: Nie po to masz deala z CloudFlare, żeby używać innego dostawcy. No i to nie jest homelab albo mała firma, masz procediury, dostawców, legal itp. To nie jest tak, że wybierasz sobie dostawcę w 5 minut, samo sprawdzenie kontraktu to z tydzień dla legala.
@BreathDeath: no i dlatego właśnie piszę o tym żeby mieć zapasowego dostawcę ;) przy homelab i małej firmie nie jest to potrzebne, przy czymś poważniejszym zazwyczaj takich dostawców i procedury utrzymania ciągłości działania masz
Ja mogę zrobić redundancje wszystkiego, która będzie kosztowała kupę kasy i wtedy jak cloudflare padnie to klient działa
@some_ONE: jeszcze tylko dodam, że jak ktoś korzysta z ich ochrony tylko (proxy/cache/security) to spoko, ale CF pododawał w ostatnich latach sporo serwisów - workery, snippery, rules, transforms, bazy danych też w chmurze i inne systemy storage. I o ile zmiana dns/cdn/cache jest prostsza, tak im więcej systemów w użyciu tym trudniejsza i bardziej kosztowna (rachunki + wdrożenie/utrzymanie). To trochę