CLOUD
Современные облака очень облегчаю нам жизнь, позволяют быстро поднимать инфру и подстраиваться под нагрузку.
Но есть один момент который сильно мешает, это ролевая модель и выдача токенов доступа. Вот условно можно за 10 минут поднять кубер и потом часа два шарахаться по документации что бы понять как создать токен доступа.
И я понимаю зачем это сделано, в клаудах можно очень гибко настроить доступа и разрешения. Но вот когда нужно просто быстро поднять инфру и что то выкатить это мешает.
Помню у селектела раньше можно было быстро поднять кластер и сразу получить kube config с нужными кредами и сразу начать деплоить. Было удобно. А вся эта возня с сервисными акаунтами и миллионами ролей только усложняет старт проекта.
Современные облака очень облегчаю нам жизнь, позволяют быстро поднимать инфру и подстраиваться под нагрузку.
Но есть один момент который сильно мешает, это ролевая модель и выдача токенов доступа. Вот условно можно за 10 минут поднять кубер и потом часа два шарахаться по документации что бы понять как создать токен доступа.
И я понимаю зачем это сделано, в клаудах можно очень гибко настроить доступа и разрешения. Но вот когда нужно просто быстро поднять инфру и что то выкатить это мешает.
Помню у селектела раньше можно было быстро поднять кластер и сразу получить kube config с нужными кредами и сразу начать деплоить. Было удобно. А вся эта возня с сервисными акаунтами и миллионами ролей только усложняет старт проекта.
👍2
USER
В тему безопасности.
Если у нас на сервере что то торчит наружу - оно должно запускаться под минимальным пользаком.
Например как это делает nginx, запускает свои процессы под пользаком www-data, и даже при компромитации самого nginx мы минимизируем риски.
Да, если хакер попал на сервер даже под минимальным пользаком то это уже плохо и опасно. Но не надо упрощать им жизнь)
Поэтому для таких пользаков нужно выдовать доступы только до тех файлов которые точно нужны и больше не выдавать ничего. Никаких capabilities и возможности выполнять что либо под sudo.
В тему безопасности.
Если у нас на сервере что то торчит наружу - оно должно запускаться под минимальным пользаком.
Например как это делает nginx, запускает свои процессы под пользаком www-data, и даже при компромитации самого nginx мы минимизируем риски.
Да, если хакер попал на сервер даже под минимальным пользаком то это уже плохо и опасно. Но не надо упрощать им жизнь)
Поэтому для таких пользаков нужно выдовать доступы только до тех файлов которые точно нужны и больше не выдавать ничего. Никаких capabilities и возможности выполнять что либо под sudo.
👍2
CLUSTER
Один из неплохих подходов это иметь в кубер кластере две группы, основную с постяонными нодами и вторую с автоскейл.
Основная группа для постоянной нагрузки, которая будет стабильной и постоянной. А вспомогательная будет в нуле по количеству нод и поднимать их под необходимость.
Почему не сделать одну автоскейл? Для предсказуемости, чаще есть какое то количество ресурсов которое прям точно необходимо и надежнее сразу поднять их и не отдавать на откуп логике скейлинга кластера. А вот вспомогательная легко может переварить всплески)
Один из неплохих подходов это иметь в кубер кластере две группы, основную с постяонными нодами и вторую с автоскейл.
Основная группа для постоянной нагрузки, которая будет стабильной и постоянной. А вспомогательная будет в нуле по количеству нод и поднимать их под необходимость.
Почему не сделать одну автоскейл? Для предсказуемости, чаще есть какое то количество ресурсов которое прям точно необходимо и надежнее сразу поднять их и не отдавать на откуп логике скейлинга кластера. А вот вспомогательная легко может переварить всплески)
👍2
CLUSTER
Немного исторической справки о том как появилась вся эта история с кластерами приложений и баз данных.
Да, в том числе это дает нам возможность. Но главная причина в том что нельзя вечно наращивать ресурсы конкретных узлов.
Раньше не было такого количество нагрузки и данных, поэтому хватало простых серверов парой ядер и парой гб оперативки. Все было хорошо.
Но со временем пришлось обрабатывать сильно больше трафика, и мы пришли к тому что даже самый мощных процессор с 96 ядрами 192 потоками уже перестает справляться. А еще для ускорения расчетов все больше начали использовать кеширование данных в RAM, все дошло до того что на одном сервере может не хватать и 1тб оперативки.
Кластерные решения стали единственным выходом. Теперь мы можем взять кучу средне мощных серверов и паралелить всю нагрузку на них. Получая хоть тысячи ядер и десятки терабайт оперативки)
Немного исторической справки о том как появилась вся эта история с кластерами приложений и баз данных.
Да, в том числе это дает нам возможность. Но главная причина в том что нельзя вечно наращивать ресурсы конкретных узлов.
Раньше не было такого количество нагрузки и данных, поэтому хватало простых серверов парой ядер и парой гб оперативки. Все было хорошо.
Но со временем пришлось обрабатывать сильно больше трафика, и мы пришли к тому что даже самый мощных процессор с 96 ядрами 192 потоками уже перестает справляться. А еще для ускорения расчетов все больше начали использовать кеширование данных в RAM, все дошло до того что на одном сервере может не хватать и 1тб оперативки.
Кластерные решения стали единственным выходом. Теперь мы можем взять кучу средне мощных серверов и паралелить всю нагрузку на них. Получая хоть тысячи ядер и десятки терабайт оперативки)
🔥2👍1
BILLING
В тему облаков.
В билинге ресурсов клатера бывают расходы которые сложно учесть с самого начала. К примеру:
- Внешний трафик
- Запросы в S3
- Возможный расширенный сапорт
Простой совет - заложить несколько процентов от цены ресурсов которые мы арендуем.
Совет посложнее - оптимизировать под реализацию клауда, например чаще внутренний трафик дешевле чем внешний. Можно еще кешировать файлы из S3.
Тут главное смотреть логи бюджета, там может быть много интересной инфы которая поможет снизить косты на ифру)
В тему облаков.
В билинге ресурсов клатера бывают расходы которые сложно учесть с самого начала. К примеру:
- Внешний трафик
- Запросы в S3
- Возможный расширенный сапорт
Простой совет - заложить несколько процентов от цены ресурсов которые мы арендуем.
Совет посложнее - оптимизировать под реализацию клауда, например чаще внутренний трафик дешевле чем внешний. Можно еще кешировать файлы из S3.
Тут главное смотреть логи бюджета, там может быть много интересной инфы которая поможет снизить косты на ифру)
👍1🔥1
STAND
Про разделение и конфигурацию стендов.
Самое простое это дев и тест стенды. Их вполне можно поднимать на одной общей инфре и давать более менее полные доступы командам разработки и тестирования. Главное это подлив данных для тестирования с прод стенда, важно их обезличивать.
На счет пре-прод стенда. В идеале он должен быть максимально близок к прод стенду, может только с меньшими ресурсами. Тут разграничение доступов должен быть более серьезным, что бы обеспечить тестирование близкое к реальным условиям.
Ну и на счет прода. Тут в идеале доступы должны быть только у инфровой команды, возможно у лидов команд. И чем он больше похож на препрод тем более качественные релизы мы можем выпускать)
Про разделение и конфигурацию стендов.
Самое простое это дев и тест стенды. Их вполне можно поднимать на одной общей инфре и давать более менее полные доступы командам разработки и тестирования. Главное это подлив данных для тестирования с прод стенда, важно их обезличивать.
На счет пре-прод стенда. В идеале он должен быть максимально близок к прод стенду, может только с меньшими ресурсами. Тут разграничение доступов должен быть более серьезным, что бы обеспечить тестирование близкое к реальным условиям.
Ну и на счет прода. Тут в идеале доступы должны быть только у инфровой команды, возможно у лидов команд. И чем он больше похож на препрод тем более качественные релизы мы можем выпускать)
👍1
SEC
Поверхность атаки.
С точки зрения системы это все что торчит наружу, и к чему имеет доступ внешний пользователь. Это может быть хоть vpn сервер для доступа к инфре, хоть эндпоинт авторизации в системе.
Если мы решаем сделать систему более устойчивой то начинать нужно именно с этого. Посмотреть до чего вообще можно дотянуться и попытаться эксплуатировать. Это может быть забытый порт приложения, или хардкод токена на фронте, что угодно.
Ну и хорошей идеей будет организовать ред тим внутреннию, которая сама попробоует атаковать нас как блекбокс. Чаще всего найдется что то интересное)
Поверхность атаки.
С точки зрения системы это все что торчит наружу, и к чему имеет доступ внешний пользователь. Это может быть хоть vpn сервер для доступа к инфре, хоть эндпоинт авторизации в системе.
Если мы решаем сделать систему более устойчивой то начинать нужно именно с этого. Посмотреть до чего вообще можно дотянуться и попытаться эксплуатировать. Это может быть забытый порт приложения, или хардкод токена на фронте, что угодно.
Ну и хорошей идеей будет организовать ред тим внутреннию, которая сама попробоует атаковать нас как блекбокс. Чаще всего найдется что то интересное)
👍1
K8S
Про главные плюс managed куба в облаке. Это возможность эксперементировать с параметрами нод.
У мен есть кластер в яндексе, на котором крутится под 200 подов. И стабильно раз в неделю - две я настраиваю новую группу нод с другой конфигурацией и перетаскиваю полезную нагрузку на нее, и дропаю старую.
Это позволяет в рамках одного бюджета на вычеслительные ресурсы подбирать более подходящие ресурсы. Например в недавней итерации перетащил все на AMD процы. Сейчас перетаскиваю на автоскейл группу. Иногда играюсь с соотношением CPU/RAM и уже вывел что для этого проекта идеальное соотношение 4gb RAM на 1 CPU.
И главное, это все делается без привешения бюджетов и без простоя. Кубер довольно умный, он может закардонить старые ноды и потионьку перебросить всю нагрузку на новые ноды)
Про главные плюс managed куба в облаке. Это возможность эксперементировать с параметрами нод.
У мен есть кластер в яндексе, на котором крутится под 200 подов. И стабильно раз в неделю - две я настраиваю новую группу нод с другой конфигурацией и перетаскиваю полезную нагрузку на нее, и дропаю старую.
Это позволяет в рамках одного бюджета на вычеслительные ресурсы подбирать более подходящие ресурсы. Например в недавней итерации перетащил все на AMD процы. Сейчас перетаскиваю на автоскейл группу. Иногда играюсь с соотношением CPU/RAM и уже вывел что для этого проекта идеальное соотношение 4gb RAM на 1 CPU.
И главное, это все делается без привешения бюджетов и без простоя. Кубер довольно умный, он может закардонить старые ноды и потионьку перебросить всю нагрузку на новые ноды)
👍2
AGENT
Инфра это последнее место куда бы я пускал AI.
Да, он сейчас хорошо пишет код, даже неплохие инфровые манифесты может написать. Но пускать агентов деплоить что то в прод пока рано. А особенно пускать в рут прод сервера и просить что то поправить)
Не спорю что современные AI модели очень умные, даже локальные. И можно дать агенту тулинг для дипсерча в интернете.
Но тут основной вопрос в архитектуре всей инфры в целом. Редко бывает что у нас всего один сервер и все завязано на него. А погрузить в агента всю архитектуру и документацию не так уж и просто, даже если построить раг и класть часть доки в системный промт то будет проблема с затуханием контекста. И в какой то момент модель может попытаться сделать что то, что находится вне запроса.
Ну и базово, страшно пускать на прод даже джунов, не то что блекбокс какой то)
Инфра это последнее место куда бы я пускал AI.
Да, он сейчас хорошо пишет код, даже неплохие инфровые манифесты может написать. Но пускать агентов деплоить что то в прод пока рано. А особенно пускать в рут прод сервера и просить что то поправить)
Не спорю что современные AI модели очень умные, даже локальные. И можно дать агенту тулинг для дипсерча в интернете.
Но тут основной вопрос в архитектуре всей инфры в целом. Редко бывает что у нас всего один сервер и все завязано на него. А погрузить в агента всю архитектуру и документацию не так уж и просто, даже если построить раг и класть часть доки в системный промт то будет проблема с затуханием контекста. И в какой то момент модель может попытаться сделать что то, что находится вне запроса.
Ну и базово, страшно пускать на прод даже джунов, не то что блекбокс какой то)
👍1
TMP
Вынесение шаблонов деплоя в отдельную репу может сильно ускорить релизы.
Да, не всегда просто сделать такой шаблон который учтет все возможные варианты. Но разово настроив мы можем быстро подрубать к новым микросервисам шаблон и быстро катить. Останется только заполнить переменки.
Ну и есть два типа добавления шаблонов.
1. Подключаем как include нужные модули, в самом CI/CD манифесте.
2. Переобределяем дефолтный путь до пайплайна на внешнюю репу.
Чаще удобнее второй вариант, но первый дает возможность нам включать только то что нужно.
Вынесение шаблонов деплоя в отдельную репу может сильно ускорить релизы.
Да, не всегда просто сделать такой шаблон который учтет все возможные варианты. Но разово настроив мы можем быстро подрубать к новым микросервисам шаблон и быстро катить. Останется только заполнить переменки.
Ну и есть два типа добавления шаблонов.
1. Подключаем как include нужные модули, в самом CI/CD манифесте.
2. Переобределяем дефолтный путь до пайплайна на внешнюю репу.
Чаще удобнее второй вариант, но первый дает возможность нам включать только то что нужно.
👍1
SHARED
Иногда мы делаем какую то общую инфру для разных проектов. Что бы условно 3 разные команды с своими проектами могли использовать общую дев/тест инфру.
Тут главное реализовать это инфру так что бы никто никому не мешал. Важно заложить:
- Команде доступен только свой неймспейс
- Для всех отдельные пользаки в БД с своими лимитами коннектов
- Определенный ресурс для каждой команды, исходя из ее потребности
- Разделение доступов до логов и метрик, что бы не было общей помойки
С этими базовыми вещами для каждой команды сможем выделять изоированный кусок общей инфры, так что бы они не мешали друг другу)
Иногда мы делаем какую то общую инфру для разных проектов. Что бы условно 3 разные команды с своими проектами могли использовать общую дев/тест инфру.
Тут главное реализовать это инфру так что бы никто никому не мешал. Важно заложить:
- Команде доступен только свой неймспейс
- Для всех отдельные пользаки в БД с своими лимитами коннектов
- Определенный ресурс для каждой команды, исходя из ее потребности
- Разделение доступов до логов и метрик, что бы не было общей помойки
С этими базовыми вещами для каждой команды сможем выделять изоированный кусок общей инфры, так что бы они не мешали друг другу)
👍1
TMP
Сейчас пишу шаблоны пайплайнов для нового проекта. Там по классике несколько микросервисов которые нужно выкатить.
Люблю новые проекты, там можно сразу применить весь свой опыт и сразу сделать хорошо)
Пока реализовал уже два шаблонных шага:
- Билд jar файла
- Билд и паблиш образа с этим jar файлом
Делаю максимально униврсальные стейджи пайплайна которые можно просто импортировать в проект и оно само поедет)
Сейчас пишу шаблоны пайплайнов для нового проекта. Там по классике несколько микросервисов которые нужно выкатить.
Люблю новые проекты, там можно сразу применить весь свой опыт и сразу сделать хорошо)
Пока реализовал уже два шаблонных шага:
- Билд jar файла
- Билд и паблиш образа с этим jar файлом
Делаю максимально униврсальные стейджи пайплайна которые можно просто импортировать в проект и оно само поедет)
👍2
TEAM
Ща собираем стенд для одного проекта. И это один из редких опытов когда нас на проекте двое девопсов.
Процесс мы выстроили таким образом: Раз в какое то время синкуемся с командой разработки и понимаем глобальную задачу. Создали борду где нарезаем большие задачи на небольшие, из разряда "написать шаблон чарта", "поднять кластер", "написать джобу сборок".
Нарезаем задачи таким образом что бы не блокировать друг друга и можно было делать их в любом порядке.
Ну и что то около кросс ревью, когда смотрим задачи друг друга)
Это редкий момент когда можно так поработать, а не как обычно в одиночку)
Ща собираем стенд для одного проекта. И это один из редких опытов когда нас на проекте двое девопсов.
Процесс мы выстроили таким образом: Раз в какое то время синкуемся с командой разработки и понимаем глобальную задачу. Создали борду где нарезаем большие задачи на небольшие, из разряда "написать шаблон чарта", "поднять кластер", "написать джобу сборок".
Нарезаем задачи таким образом что бы не блокировать друг друга и можно было делать их в любом порядке.
Ну и что то около кросс ревью, когда смотрим задачи друг друга)
Это редкий момент когда можно так поработать, а не как обычно в одиночку)
👍2
NET
Кратенько о том как я настраиваю сетевые политики для нод кластера, для яндекс клауда:
1. Все ноды без белого IP
2. Разрешение всего инпута в контексте локальной сети
3. Вес аутпут через дефолтный nat клауда
4. Все ноды в свое изолированной сети
Это позволяет пускать трафик на ингрес через сетевой балансер и нормально взаимодействовать всем компонентам кластера. Ну и учитывая что это изолированная локалка к самим нодам напрямую никто не сможет обратится, только через апи и по правилам сетевого балансера.
Такой подход дает приемлимый уровень безопасности и позволяет не сильно усложнять сетевые политики)
Кратенько о том как я настраиваю сетевые политики для нод кластера, для яндекс клауда:
1. Все ноды без белого IP
2. Разрешение всего инпута в контексте локальной сети
3. Вес аутпут через дефолтный nat клауда
4. Все ноды в свое изолированной сети
Это позволяет пускать трафик на ингрес через сетевой балансер и нормально взаимодействовать всем компонентам кластера. Ну и учитывая что это изолированная локалка к самим нодам напрямую никто не сможет обратится, только через апи и по правилам сетевого балансера.
Такой подход дает приемлимый уровень безопасности и позволяет не сильно усложнять сетевые политики)
👍1
WALL
Один из способов защиты от DDOS атак это делегирование защиты на специализированные системы.
Как пример можно взять cloudflare. По сути защита там реализованная как обычный балансировщик нагрузки, мы просто включаем DNS в режими проксирования и весь трафик к нашему сайту будет идти сначала через cloudflare.
В базовой версии они берут на себя защиту от DDOS и подобых атак.
Что важно понимать при настройке: cloudflare ставит свой ssl сертификат который отдает пользователям, и по дефолту шлет запросы в нашу систему по http. Что бы настроить ssl между cloudflare и нами нужно для начала сделать сами серты и потом включить настройку ssl full уже на cloudflare.
Один из способов защиты от DDOS атак это делегирование защиты на специализированные системы.
Как пример можно взять cloudflare. По сути защита там реализованная как обычный балансировщик нагрузки, мы просто включаем DNS в режими проксирования и весь трафик к нашему сайту будет идти сначала через cloudflare.
В базовой версии они берут на себя защиту от DDOS и подобых атак.
Что важно понимать при настройке: cloudflare ставит свой ssl сертификат который отдает пользователям, и по дефолту шлет запросы в нашу систему по http. Что бы настроить ssl между cloudflare и нами нужно для начала сделать сами серты и потом включить настройку ssl full уже на cloudflare.
👍1
PROD
Что в идеале надо настраивать на прод стенде, после того как сам проект релизится туда из теста:
- Отключаем дебаг
- Отключаем свагер, актуатор и прочие вещи связанные с разработкой
- Наружу открываем только реально нужные порты, чаще только 80 и 443
- Убеждаемся что наружу не торчит какой то левый урл
Важно понимать, что все что мы делаем ради удобства тестирования и разработки может стать поверхностью атаки на проде)
Что в идеале надо настраивать на прод стенде, после того как сам проект релизится туда из теста:
- Отключаем дебаг
- Отключаем свагер, актуатор и прочие вещи связанные с разработкой
- Наружу открываем только реально нужные порты, чаще только 80 и 443
- Убеждаемся что наружу не торчит какой то левый урл
Важно понимать, что все что мы делаем ради удобства тестирования и разработки может стать поверхностью атаки на проде)
👍1
JUMP
Ssh over jump сервер. Это один из способов тунелирования ссш трафика.
Допусти у нас есть один сервер с внешним ip, к которому у нас есть доступ, и куча серверов внутри сети без прямого доступа с локальной машины.
Допустим мы хотим попасть на сервер из этой внутренней сети. Как это можно решить:
По сути одним простым конфиг файлом для ssh.
Дальше просто подрубаемся так:
Таким образом трафик сначала пойдет на external-host и оттуда уже на internal_host.
Ssh over jump сервер. Это один из способов тунелирования ссш трафика.
Допусти у нас есть один сервер с внешним ip, к которому у нас есть доступ, и куча серверов внутри сети без прямого доступа с локальной машины.
Допустим мы хотим попасть на сервер из этой внутренней сети. Как это можно решить:
По сути одним простым конфиг файлом для ssh.
Host external-host
HostName some_ip
User root
Host internal_host
HostName some_ip
User ops
ProxyJump external-host
Дальше просто подрубаемся так:
ssh internal_host
Таким образом трафик сначала пойдет на external-host и оттуда уже на internal_host.
👍1
BILING
Про неочевидные траты в клауде.
Иногда забывается - в клауде мы платим не только за сами ресурсы но и за операции. Например в S3 бакете мы платим не только за пространство, но и за PUT/GET операции. Проблема в том что из за этого может вырасти расход, даже при небольшом количество данных.
Например какой либо сервис при мисконфигуре может разогнаться и начать слать тысячи запросов к бакету, и по итогу мы будем оплачивать все. Да, одна операция почти ничего не стоит, но если их тысячи в секунду и длиться несколько часов то сумма может выйти большой.
Про неочевидные траты в клауде.
Иногда забывается - в клауде мы платим не только за сами ресурсы но и за операции. Например в S3 бакете мы платим не только за пространство, но и за PUT/GET операции. Проблема в том что из за этого может вырасти расход, даже при небольшом количество данных.
Например какой либо сервис при мисконфигуре может разогнаться и начать слать тысячи запросов к бакету, и по итогу мы будем оплачивать все. Да, одна операция почти ничего не стоит, но если их тысячи в секунду и длиться несколько часов то сумма может выйти большой.
👍1
TMP
Допустим у нас есть несколько одинаковых джоб в гитлабе, допустим для деплоя на разные стенды. Как это сделать красивее? Сделать шаблон и завязываться на него, просто конфгурируя.
Как пример:
Тут мы сделали общий шаблон .deploy, где есть вся общая настройки джобы и мы завязываемся на него через extends. Удобно и красиво)
Допустим у нас есть несколько одинаковых джоб в гитлабе, допустим для деплоя на разные стенды. Как это сделать красивее? Сделать шаблон и завязываться на него, просто конфгурируя.
Как пример:
.deploy:
stage: deploy
image: docker:19.03.8-dind
script:
- ./deploy.sh
tags:
- docker
environment:
name: $CI_COMMIT_BRANCH
deploy_prod:
extends: .deploy
variables:
BRANCH: master
HOST: prod
only:
- master
deploy_dev:
extends: .deploy
variables:
BRANCH: dev
HOST: dev
only:
- dev
Тут мы сделали общий шаблон .deploy, где есть вся общая настройки джобы и мы завязываемся на него через extends. Удобно и красиво)
👍2
SSDLC
Не самая очевидная мысль - жизненный цикл кода заканчивается когда его удаляют с прода.
Из этого следует что безопасность надо проверять не только на этапе разработки но и на проде. Но тут есть хитрый трюк)
Когда мы разрабатываем новые фичи то по пайплайну проходит вообще весь код прложения, и сканировать можно прям вообще все приложение а не только изменения. Таким образом мы проверяем и то что сейчас на проде.
НО, это не отменяет того что на проде может быть легаси которые мы не обновляем, и соотвественно по пайплайну с проверками этот код не проходит. Поэтому от проверок всего прода мы не уйдем, просто трюк с проверкой всего при разработке делает уже сильно лучше)
Не самая очевидная мысль - жизненный цикл кода заканчивается когда его удаляют с прода.
Из этого следует что безопасность надо проверять не только на этапе разработки но и на проде. Но тут есть хитрый трюк)
Когда мы разрабатываем новые фичи то по пайплайну проходит вообще весь код прложения, и сканировать можно прям вообще все приложение а не только изменения. Таким образом мы проверяем и то что сейчас на проде.
НО, это не отменяет того что на проде может быть легаси которые мы не обновляем, и соотвественно по пайплайну с проверками этот код не проходит. Поэтому от проверок всего прода мы не уйдем, просто трюк с проверкой всего при разработке делает уже сильно лучше)
👍1