🇺🇦 DevOps простыми словами

Join DevOpsDays #StandWithUkraine on May 17-18! During the conference, we would love to talk about DevOps during the crisis, incident, and business continuity management with our friends – Patrick Debois, Kris Nova, Kelsey Hightower, Lena Hall, Andrew Clay Shafer, and others. 18 talks from the world DevOps community are in the program and you’re welcome to Open Space Discussions as well, to share experience on complex cases with your peers. When? May 17-18 Where? Online 👉 Sign up for free & find out the agenda here: https://devopsdays.com.ua

ДЛЯ ОРДИ ПОШИРЮЙТЕ: Евросоюз запретил поставлять в РФ евробанкноты Также запрещено инвестировать, участвовать или иным образом содействовать будущим проектам, финансируемым совместно Российским фондом прямых инвестиций. #stoprussia #StopRussianAggression #RussiaInvadedUkraine https://t.me/operativnoZSU @operativnoZSU

ДЛЯ ОРДИ ПОШИРЮЙТЕ: Евросоюз запретил поставлять в РФ евробанкноты Также запрещено инвестировать, участвовать или иным образом содействовать будущим проектам, финансируемым совместно Российским фондом прямых инвестиций. #stoprussia #StopRussianAggression #RussiaInvadedUkraine https://t.me/operativnoZSU @operativnoZSU

Ban Russia from the Cloudflare Repost + vote + comment 👇 Давайте девопсовые войска, погнали https://www.linkedin.com/posts/bukovskyi-kostiantyn_cloudflare-and-lets-encrypt-josh-aas-and-activity-6904022489488601088-eNDM

Тримаємося разом, зберігаємо спокій, віримо в ЗСУ!🇺🇦

Cache-Poisoned Denial-of-Service (CPDoS). Часть 2 Так, ну сейчас все используют CDNы! Мне бояться такого на продакшне или нет? Хорошая новость тут в том, что атака известна с 2019 года, и многие крупные CDN научились с ней бороться. Несмотря на то, что должно совпасть несколько условий со стороны ориджин сервера и CDN провайдера, наиболее уязвимым оказался AWS CloudFront, т.к. их настройки позволяли укладывать на лопатки в основном с помощью HHO и HMC огромную часть фреймворков и веб-серверов, включая S3 🙃. В итоге, они просто запретили кешировать ошибочные ответы от ориджина. Впрочем, большинство провайдеров начали делать тоже самое, либо выставляют очень маленькое время кеширования ошибочных ответов. Также были уязвимы Cloudflare, Akamai, CDN77, Fastly, но только в связке с IIS, ASP.NET, Flask и Play 1. Еще один способ бороться с этим самостоятельно - это выставлять на все свои ошибочные ответы/страницы хедер Cache-Control: no-store. Третий способ - выставить WAF перед вашим бекендом. Так, ну мы вообще не используем никаких кешей перед бекендом, мне эти ваши CPDoSы побоку! А вот и нет! Например известная опенсорс CMS Drupal имеет внутренний кеш, который подвержен подобным атакам. Только там все игрища происходят вокруг X-Forwarded-Host и Host хедеров, в которые можно вставить как свой хост, так и JS скрипты. Ресерчеры также накопали всякие более извращенные отравления типа DOM, CORS и прочих.

RUM DNS Traffic Steering. Часть 2 Ха, да я такое на nginx+GeoIP построю, и надо мне вот это заморачиваться? Построите, вопросов нет. Но, будут вопросы к аккуратности определения геолокации вашего юзера по этим базам. В общем, это слабенько будет коррелировать с самым коротким путем к вашем контенту. А что делают когда из одной точки два CDN провайдера отдают приблизительно одинаковые результаты? Такое вполне реально учитывая распространенность точек крупных CDN. В таком случае на клиент ставят cookies, которые говорят о том, что для него есть какой-то primary CDN, secondary и т.д. Это в том числе позволяет не нагружать только одну ближайшую точку присутствия всеми клиентами сразу. Ок, мои сайты не такие крупные, но завтра мы получим миллиард $ инвестиций и нужно срочно сделать всем хорошо, куда бежать? Есть несколько топ-компаний, которые на этом строят свой бизнес: NS1, Constellix, Dyn, Cedexis. Ну, если и без чужих SaaS круты, то можно и самому, например на базе https://github.com/akamai/boomerang

RUM DNS Traffic Steering. Часть 1 Что такое RUM? Думаю многие знакомы с RUM, он же Real User Monitoring. Но, если нет, то существует два типа замеров производительности вашего сайта: • Synthetic. Этот функционал делают миллион разных “пингалок”: Pingdom, site24x7, StatusCake, Pingdom, Uptimerobot, etc. Они C разных локаций заходят к вам на сайт, и условно через curl -H 'Cache-Control: no-cache' -Lw "DNS Lookup: %{time_namelookup} seconds \nRedirects: %{time_redirect} seconds with %{num_redirects} redirects \nFirst Byte: %{time_starttransfer} seconds \nConnect Time: %{time_connect} seconds \nTotal Time: %{time_total} seconds\n" -so /dev/null http://apple.com/ рисуют вам эти же значения в красивый UI. Все ок, но локации как правило статические, так же они находятся в датацентрах, что совсем не тоже самое, что юзерский интернет. • RUM. Это подключаемая к вам на сайт js-библиотека, которая при каждой загрузке страницы отправляет кучу перфоманс данных в сторону коллектора, и вам рисуют красивые данные в UI. Только точность тут гораздо выше, т.к. собирается все это прямо в браузере клиента, со всеми его особенностями той самой Last mile. Вроде понятно. Причем тут DNS? Зайдем издалека, и поговорим с желтой 🦆 о вот какой проблеме. - Уточка, хочу стать поближе и побыстрее к своим клиентам? Что посоветуешь? - Уточка: конечно же подключить CDN! - А какой CDN подключаем? Akamai, CloudFront, Google, CloudFlare? Кто из них будет лучше для всех регионов сразу и даже стран? - Уточка: а давай подключим все сразу? - А давай! Правда все еще непонятно какой CDN для какой страны использовать! Кто там у нас лучше всех перформит в Индии? - Уточка: но CDN же крутые, они используют Anycast, он все сам разрулит! - Хм, но меньшее количество хопов ≠ лучшее latency! - Уточка: ....ладно, что же делать? И вот тут в игру вступает DNS Traffic Steering based on RUM. В свой(не обязательно) сайт ставляем js-ку, но, очень обрезанную по-сравнению с классическим RUM. Меряем мы только latency и какие-то еще performance штуки до ближайших точек PoP ваших CDN в этом регионе, берем эти цифры и отправляем в сторону вашего коллектора, условного хадупа. Обрабатываем данные, и постоянно перестраиваем “таблицу маршрутизации” на основании того, кто лучше перформит конкретно в этой локации, соотвественно, кого и в какую точку отправлять с помощью наших днсов. Как пример, для Ирландии мы выставили использовать Akamai и CloudFlare, и вот флара взяла и отправила точку на обслуживание, и весь трафик у них начал ходить через Лондон, latency увеличилась, и все органически перетечет в Akamai. Причем настолько быстро насколько низкие у вас TTL. Тоже самое сработает при полном отказе одного из CDN, да такое тоже бывает 😉 Самые внимательные спросят: так ведь мы уже зашли на сайт, резолвы где-то там позади? По-факту замер RUM и клиентские резолвы не обязательно связаны. В целом, есть всего два сценария: - Клиент использует EDNS, и присылает вместе с днс реквестом свою сабнет сеть, а значит и Autonomous System (AS). В базе резолвера за счет других клиентов уже есть перфоманс информация о вашей AS, и вам сразу же отдают правильные ip адреса PoP, CDN и прочее, используя т.н. “таблицу маршрутизации”, которая обновляется постоянно, практически реал-тайм. - Клиент не использует EDNS, тогда берется IP резолвера например и отдается лучший вариант из агрегированной статистики для клиентов, которые находятся за этим резолвером и уже присылали какую-то статистику. Не редко крупные провайдеры могут шарить между собой обезличенные базы, чтобы лучше покрывать такие кейсы. А также вы можете принести свои данные, или community-sourced, чтобы лучше управлять своим трафиком. Пруфов не предоставлю, т.к. давно было, но тот же AWS CloudFront на заре своего запуска использовал данные RUM, которые они собирали с Amazon.com, и таким образом сильно повысили качество своего CDN.

macOS виртуализация с криповым именем. Anka. Часть 2 CI/CD integration Как и писал выше, есть плагины под разные системы CI/CD, посмотреть и попробовать поиграться можно тут https://docs.veertu.com/anka/intel/ci-plugins-and-integrations/. Триал на 30 дней можно получить просто зарегавшись, на этапе скачивания! Поэтому я сразу побежал посмотреть пример с Github Actions. И вот как это поверхностно работает: GHA Agent + Anka on Host: - Ставим Anka на self-hosted мак-мини - Туда же ставим GHA агента - Добавлям .github/workflows/{whatever}.yml с их action, туда же внутрь команды, которые хотите отправить в виртуалку, и через GHA агента, они прилетят через anka run дальше. Живой пример https://github.com/veertuinc/github-actions-examples/actions Выглядит вполне неплохо, однако, есть очевидные минусы! Чтобы делать параллельные запуски на одной железке вам надо будет плодить несколько GHA агентов, что выглядит так себе в плане автоматизации, если честно. Anka on Host + GHA Agent inside VM: Берем виртуалки, ставим туда GHA агента, и когда виртуалка поднимается, то у вас джобы автоматически подхватывают такого агента из пула. Здесь нет никакого anka run, сам GHA агент ранит команды так, как-будто бы он просто стоит на self-hosted чем угодно. Удобнее? Да, но также имеет свой минус: кто-то должен снаружи на хосте уметь тушить и поднимать ваши виртуалки. Но, это попроще первого варианта, имхо, и уже больше похоже на cloud что-ли. Damn it API: Самый жирный, но придуманный не Anka девелоперами, а моим коллегой! 😎 Вся эта связка умеет работать через API контроллера, кроме anka run на произвольную машину. Эту фичу они обещают в ближ месяцы запилить, и тогда управление всем процессом можно производить на контроллере, через API и забыть про агенты на стороне макоси. Performance Начитавшись разного в интернетах, я побаивался, что несмотря на кучу плюшек виртуализации, реджистри и прочего, производительность будет сильно проседать. Я провел Geebench тесты, которые показали что страдает в основном Multi-Core. За результатами сходите в комменты к посту. Синтетические тесты хорошо, но я пошел проверять на наших реальных билдах, с юнит-тестами и сборкой разных пакетов. Итог меня честно говоря удивил, т.к. результат на Bare-Metal и в внутри одиночной виртуалки практически не отличались между собой. И даже больше - если запускать 2 виртуалки в параллель поделив пополам CPU и RAM на них, то они будут быстрее на 33% по скорости билда, по сравнению с последовательными шагами на Bare-Metal. VM Templates automation Следуюшим вызовом будет тема автоматизации самих виртуалок и базовых темплейтов/имеджей. Но, думаю, это врядли будет так интересно, т.к. packer+ansible известен всем, и мне кажется, многим понятно как это будет выглядеть, учитывая, что у Anka есть плагин под Packer.