BALANCE
Конфигурация сервера должна быть сбалансированна.
Нет смысла брать огромное количество ядер в ущерб скорости диска, сети и ram. По сути почти любой запрос к системе это не только вычисления малого обьема данных на чипе. Чаще нужно сходить в какую то интеграцию, считать что с диска, подержать промежуточный итог в оперативке и тд. А делаю упор только на проц он будет в простое и постоянно ожидать IO. По сути мы просто заплатим за проц который не будет выполнять полезную нагрузку.
Чаще сервер на 4 ядра будет справляться лучше чем сервер на 8, если все остальное у него лучше)
Конфигурация сервера должна быть сбалансированна.
Нет смысла брать огромное количество ядер в ущерб скорости диска, сети и ram. По сути почти любой запрос к системе это не только вычисления малого обьема данных на чипе. Чаще нужно сходить в какую то интеграцию, считать что с диска, подержать промежуточный итог в оперативке и тд. А делаю упор только на проц он будет в простое и постоянно ожидать IO. По сути мы просто заплатим за проц который не будет выполнять полезную нагрузку.
Чаще сервер на 4 ядра будет справляться лучше чем сервер на 8, если все остальное у него лучше)
👍1
SPLIT BRAIN
Чаще это относится к базам данных. Ситуация когда нарушается кворум при сетевых сбоях и в системе может появится два мастера.
Проблема в том куда именно будет писать приложение, при нарушении балансировки может случится ситуация когда запись данных пойдет в два разных места. Опасно это тем что потом будет очень сложно смержить все эти изменения.
Как избежать? Ну для начала сделать нормальную сеть. А так, смотреть на балансировку, в момент времени должен быть только один мастер. При развале кластера по сети старый мастер желательно прям прибить, некоторые физически убивают питание сервера.
Но мне нравится другой вариант. В принципе не включать автопереключение мастера, при сбоях переводить сбор кластера в ручное управление. Тогда можно гарантировать что не случится два мастера.
Чаще это относится к базам данных. Ситуация когда нарушается кворум при сетевых сбоях и в системе может появится два мастера.
Проблема в том куда именно будет писать приложение, при нарушении балансировки может случится ситуация когда запись данных пойдет в два разных места. Опасно это тем что потом будет очень сложно смержить все эти изменения.
Как избежать? Ну для начала сделать нормальную сеть. А так, смотреть на балансировку, в момент времени должен быть только один мастер. При развале кластера по сети старый мастер желательно прям прибить, некоторые физически убивают питание сервера.
Но мне нравится другой вариант. В принципе не включать автопереключение мастера, при сбоях переводить сбор кластера в ручное управление. Тогда можно гарантировать что не случится два мастера.
👍1
CLEAR
Иногда можно перекладывать патерны из программирования на пайплайны.
Например чистые функции. В максимальном приближении в джобах это может быть так:
- Одни входные данные = один результат
- Без побочных эффектов = тут сложно, смысл пайплайнов в изминениях, но можно делать их минимально
- Композиции = собирать джобу из разных шаблонов
- Явность = никаких добавочных данных которые не передавались в саму джобу
- Декларативность = описываем финальный результат
- Ленивость = не вычисляем пока это не нужно
Понятно, это только экстраполяция, сделать джобы на 100 процентов функциональными не получится, это не совсем классический код. Но применять подходы может помочь)
Иногда можно перекладывать патерны из программирования на пайплайны.
Например чистые функции. В максимальном приближении в джобах это может быть так:
- Одни входные данные = один результат
- Без побочных эффектов = тут сложно, смысл пайплайнов в изминениях, но можно делать их минимально
- Композиции = собирать джобу из разных шаблонов
- Явность = никаких добавочных данных которые не передавались в саму джобу
- Декларативность = описываем финальный результат
- Ленивость = не вычисляем пока это не нужно
Понятно, это только экстраполяция, сделать джобы на 100 процентов функциональными не получится, это не совсем классический код. Но применять подходы может помочь)
👍1
IO
В современных системах есть довольно много ожидания ввода и вывода.
Одна фича может не делать много вычислений, но собирать много информации. Например сходить в кеш, в базу, до внешней интеграции и тд. По итогу у нас может быть большое количество одновременных коннектов которые просто ожидают чего либо.
Что из этого следует?
То что важно учитывать это при проектировании инфры. Например:
- Настраивать быстрые кеши ближе к приложению
- По возможности делать быструю сеть
- Паралелизм важнее чем мощные ядра
- Быстрые диски на бд и сторедже
- Кеширование на клиенте
Это поможет просто снизить время ожидания, соответсвенно в целом нагрузку на систему. Мы сможем быстро отдавать клиенту то что он запрашивает.
В современных системах есть довольно много ожидания ввода и вывода.
Одна фича может не делать много вычислений, но собирать много информации. Например сходить в кеш, в базу, до внешней интеграции и тд. По итогу у нас может быть большое количество одновременных коннектов которые просто ожидают чего либо.
Что из этого следует?
То что важно учитывать это при проектировании инфры. Например:
- Настраивать быстрые кеши ближе к приложению
- По возможности делать быструю сеть
- Паралелизм важнее чем мощные ядра
- Быстрые диски на бд и сторедже
- Кеширование на клиенте
Это поможет просто снизить время ожидания, соответсвенно в целом нагрузку на систему. Мы сможем быстро отдавать клиенту то что он запрашивает.
👍2
K8S
Куб можно рассматривать как операционную систему более высокого уровня, распределенную.
По сути роль куба примерно такая же как у обычных ОС. Это запуск приложений и абстрагирование. Да и интерфейс взаимодействия чем то похож на линукс, просто CLI с определенным синтаксисом, которая под копотом делает определенные вызовы системы.
Да, это экстраполяция. Но с такой ментальной моделью мне проще воспринимать куб, как просто один из слоев абстракции от железа)
Куб можно рассматривать как операционную систему более высокого уровня, распределенную.
По сути роль куба примерно такая же как у обычных ОС. Это запуск приложений и абстрагирование. Да и интерфейс взаимодействия чем то похож на линукс, просто CLI с определенным синтаксисом, которая под копотом делает определенные вызовы системы.
Да, это экстраполяция. Но с такой ментальной моделью мне проще воспринимать куб, как просто один из слоев абстракции от железа)
👍2
NET
Сетевые политики это одна из важных частей безопасности.
Тут главная концепция - запрещено все что не разрешено. Сетевые доступы куда либо должны быть открыты только до нужных интеграций.
Например в базу данных могут обратится только те сервисы которые явно должны с ней работать, что бы избежать доступа из скомпромитированных сервисов. Типа что бы завладев одним подом мы не смогли пройтись по всей сети, ограничение поверхности атаки.
Сетевые политики это одна из важных частей безопасности.
Тут главная концепция - запрещено все что не разрешено. Сетевые доступы куда либо должны быть открыты только до нужных интеграций.
Например в базу данных могут обратится только те сервисы которые явно должны с ней работать, что бы избежать доступа из скомпромитированных сервисов. Типа что бы завладев одним подом мы не смогли пройтись по всей сети, ограничение поверхности атаки.
👍1
TMP
Шаблоны пайплайнов и манифестов могут как усложнить жизнь так и сделать ее сильно проще.
Как сделать проще:
- По дефолту все компоненты выключены, включаем только то что нужно
- Никаких жесткий зависимостей компонентов между собой
- Там где можно используем паралельное выполнение
- Включаем дефолтный флоу
- Минимум переменных, все что можно генерим на лету
Так мы сможем быстро включить нужные шаги и компоненты, задать несоклько базовых переменок и сразу полететь уже)
Шаблоны пайплайнов и манифестов могут как усложнить жизнь так и сделать ее сильно проще.
Как сделать проще:
- По дефолту все компоненты выключены, включаем только то что нужно
- Никаких жесткий зависимостей компонентов между собой
- Там где можно используем паралельное выполнение
- Включаем дефолтный флоу
- Минимум переменных, все что можно генерим на лету
Так мы сможем быстро включить нужные шаги и компоненты, задать несоклько базовых переменок и сразу полететь уже)
👍1
CI/CD
На сколько сильно нужно шаблонизировать пайплайны?
Как по мне до уровне что бы запустить джобу нужно добавить 2-3 переменки окружения (не приложения и для джобы).
Потому что если начать шаблонизировать вообще все то что бы запустить джобу нужно будет написать текста почти столько же сколько и для обычной джобы. Да, остается единая точка для исправления пайплайнов везде. Но сильно повышается комбинаторика вариантов, и учесть все будет слишком сложно. Ну и пользоваться этим будет не удобно, теряется быстрый запуск проектов)
На сколько сильно нужно шаблонизировать пайплайны?
Как по мне до уровне что бы запустить джобу нужно добавить 2-3 переменки окружения (не приложения и для джобы).
Потому что если начать шаблонизировать вообще все то что бы запустить джобу нужно будет написать текста почти столько же сколько и для обычной джобы. Да, остается единая точка для исправления пайплайнов везде. Но сильно повышается комбинаторика вариантов, и учесть все будет слишком сложно. Ну и пользоваться этим будет не удобно, теряется быстрый запуск проектов)
👍1
MANUAL
Некоторые вещи нужно оставлять в полу ручном режиме.
Например тестирование бекапов. Я сейчас практикую это так:
- Скрипт поднимает контейнер с бд
- Заливает туда последний бекап
- Итеративно сравнивает количество записей в бекапе и проде по каждой таблице
- Присылает мне отчет
И вот отчет я просматриваю уже своими глазами.
Если оставить это полностью автоматически, типа скрипт просто присылает что ок или не ок то можно легко забыть про это. Может случится что скрипт вообще упадет и перестанет что либо присылать, и про это можно вообще забыть.
А когда ты по графику запускаешь его сам, например раз в 2 недели, то шанс ошибки сильно уменьшается.
Некоторые вещи нужно оставлять в полу ручном режиме.
Например тестирование бекапов. Я сейчас практикую это так:
- Скрипт поднимает контейнер с бд
- Заливает туда последний бекап
- Итеративно сравнивает количество записей в бекапе и проде по каждой таблице
- Присылает мне отчет
И вот отчет я просматриваю уже своими глазами.
Если оставить это полностью автоматически, типа скрипт просто присылает что ок или не ок то можно легко забыть про это. Может случится что скрипт вообще упадет и перестанет что либо присылать, и про это можно вообще забыть.
А когда ты по графику запускаешь его сам, например раз в 2 недели, то шанс ошибки сильно уменьшается.
👍1
OLD SCHOOL
Периодично встречаю странные конфигурации инфры.
На пример:
- Есть только прод, без теста
- Один сервер приложения
- Джанга катится напрямую на сервер
- Поднимается через systemd
- Но при этом используется managed постгрес
- Есть клауд s3
- App Load Balancer на уровне клауда
Странное сочитание современных решений и чего то очень старого)
Периодично встречаю странные конфигурации инфры.
На пример:
- Есть только прод, без теста
- Один сервер приложения
- Джанга катится напрямую на сервер
- Поднимается через systemd
- Но при этом используется managed постгрес
- Есть клауд s3
- App Load Balancer на уровне клауда
Странное сочитание современных решений и чего то очень старого)
👍1
LINUX
Все еще эксперементирую с последней версией fedora десктопной.
Одна из проблем - что бы сделать некоторые вещи нужны расширения, но не всегда они работают стабильно.
Например вчера я захотел сделать сокрытие топ бара при полноэкранном режиме, и что бы он открывался при наведении на него курсора. Как на макке.
И даже нашел несколько расширений. Более менее рабочими оказались два. Но в первом при наведении курсора на топ баре он начинал дрожать и становился нечитаемым, во втором наведение вообще не работало.
И это один из примеров, приходится часто идти на компромисы подобные.
Все еще эксперементирую с последней версией fedora десктопной.
Одна из проблем - что бы сделать некоторые вещи нужны расширения, но не всегда они работают стабильно.
Например вчера я захотел сделать сокрытие топ бара при полноэкранном режиме, и что бы он открывался при наведении на него курсора. Как на макке.
И даже нашел несколько расширений. Более менее рабочими оказались два. Но в первом при наведении курсора на топ баре он начинал дрожать и становился нечитаемым, во втором наведение вообще не работало.
И это один из примеров, приходится часто идти на компромисы подобные.
👍1
OPENSOURCE
Открытые исходники часто дают только илюзию безопасности.
Есть мнение - если код открыт то его проверяет комьюнити, значит он безопасен. Но тут вопрос именно в качестве этой проверки, до сих пор бывают случаи когда находят проблемы которые жили в коде с нулевых.
И да, есть важные открытые проекты, ревью которых могут делать професионала из больших компаний. То же самое ядро линукса, есть куча комерческих компаний которые заинтересованы в том что бы ядро было безопасным. Но даже это не гарантия, даже там могут быть проблемы)
Ну и вопрос, кто когда читал исходники опенсорса в последний раз?)
Открытые исходники часто дают только илюзию безопасности.
Есть мнение - если код открыт то его проверяет комьюнити, значит он безопасен. Но тут вопрос именно в качестве этой проверки, до сих пор бывают случаи когда находят проблемы которые жили в коде с нулевых.
И да, есть важные открытые проекты, ревью которых могут делать професионала из больших компаний. То же самое ядро линукса, есть куча комерческих компаний которые заинтересованы в том что бы ядро было безопасным. Но даже это не гарантия, даже там могут быть проблемы)
Ну и вопрос, кто когда читал исходники опенсорса в последний раз?)
👍1
RELEASE
Сейчас занимаемся тем что асап переносим проект в новую инфру.
Тут хорошо подходит упрощение пайплайна доставки. В проекте который уже как то развивается всегда есть шаги по типу тестов, линтеров, проверок безы, разные условия для мерджа и тд. Но когда нужно взять текущее состояние и просто переместить его в другую инфру эти джобы только мешают.
Поэтому мы максимально упростили пайплайн только до билда и деплоя. И сделали это еще и итеративно:
- Сначала прогнали сборки на новой инфре, с новыми раннерами и регистри
- Отключили сборки, что бы не задерживали
- Переписали и дебажили чисто деплой на новый стенд
Вроде уже все более менее стабилизировали. Поэтому включили сборку и потихонку включаем все остальные шаги)
Сейчас занимаемся тем что асап переносим проект в новую инфру.
Тут хорошо подходит упрощение пайплайна доставки. В проекте который уже как то развивается всегда есть шаги по типу тестов, линтеров, проверок безы, разные условия для мерджа и тд. Но когда нужно взять текущее состояние и просто переместить его в другую инфру эти джобы только мешают.
Поэтому мы максимально упростили пайплайн только до билда и деплоя. И сделали это еще и итеративно:
- Сначала прогнали сборки на новой инфре, с новыми раннерами и регистри
- Отключили сборки, что бы не задерживали
- Переписали и дебажили чисто деплой на новый стенд
Вроде уже все более менее стабилизировали. Поэтому включили сборку и потихонку включаем все остальные шаги)
👍1
STATE
Для иденпотентности IAC систем нужно иметь стейт с изменениями которые мы уже сделали.
Тут есть два подхода и главные их представители:
- Statefull - terraform и pulumi, требую сохранения стейта где то во вне.
- Stateless - ansible, вычисляет стейт во время каждого исполнения.
В плане надежности stateless всегда лучше, чем меньше данных нужно хранить тем лучше. Ну и плюс он не требует изменения только через манифест, экстренная правка руками ничего не сломает, стейт просто пересчитается с учетом этих изменений)
Для иденпотентности IAC систем нужно иметь стейт с изменениями которые мы уже сделали.
Тут есть два подхода и главные их представители:
- Statefull - terraform и pulumi, требую сохранения стейта где то во вне.
- Stateless - ansible, вычисляет стейт во время каждого исполнения.
В плане надежности stateless всегда лучше, чем меньше данных нужно хранить тем лучше. Ну и плюс он не требует изменения только через манифест, экстренная правка руками ничего не сломает, стейт просто пересчитается с учетом этих изменений)
👍1
MEMORY
Как говорится "Аполлон полетел на луну с 4кб оперативной памяти, а твоему реакту нужны десятки магабайт".
Это одна из частых проблем, иногда сборки приложений весят очень много. Условный бекенд на питоне, со всеми зависимостями, может весить 500мб в виде образа. А статика фронта, которую нужно скачать в браузер, весить мегабайты.
Вообще, сейчас все это стараются решать. На бекенде использовать минималистичные базовые образы и оптимизированные сборки, ну и меньше зависимостей тянем в сборку. На фронте через оптимизации, кеширование, ssr и прочие приблуды. Сейчас не 2020 год, когда все пихали в сборку все и сразу, и надеялись на быстрый интернет у клиена и бесконечные сервера на беке)
Ну и тот же самые golang показал, продовая сборка бекенда может весить 10мб))
Как говорится "Аполлон полетел на луну с 4кб оперативной памяти, а твоему реакту нужны десятки магабайт".
Это одна из частых проблем, иногда сборки приложений весят очень много. Условный бекенд на питоне, со всеми зависимостями, может весить 500мб в виде образа. А статика фронта, которую нужно скачать в браузер, весить мегабайты.
Вообще, сейчас все это стараются решать. На бекенде использовать минималистичные базовые образы и оптимизированные сборки, ну и меньше зависимостей тянем в сборку. На фронте через оптимизации, кеширование, ssr и прочие приблуды. Сейчас не 2020 год, когда все пихали в сборку все и сразу, и надеялись на быстрый интернет у клиена и бесконечные сервера на беке)
Ну и тот же самые golang показал, продовая сборка бекенда может весить 10мб))
👍1
TOOL
Тулы, особенно поиск, может сильно помочь в интеграции небольших моделей. Ну и сделать всю систему безопаснее.
Как пример - сумаризация отчетов безопасности.
Часто сканеры вываливают нам огромные отчеты, а если их несколько то их становится сильно больше чем мы сможем прочитать, тем более для скана каждой фичи.
Выплевывать эти отчеты в большие внешние модели такое себе, просто так отдаем внешним чуваками инструкцию как нас ломать. Но и небольшие on-prem модели могут не очень качествено отработать их.
А вот поднять агента с небольшой модель и дать ему возможность собирать информацию в интернете поможет более качественно отработать каждый файндинг. Условно агент получил список из 100 файндингов, и найдя информацию выкинул мусор и показал нам только реальные проблемы. А если еще и давать контекст нашей архитектуры то сумаризация может стать еще более точной)
Тулы, особенно поиск, может сильно помочь в интеграции небольших моделей. Ну и сделать всю систему безопаснее.
Как пример - сумаризация отчетов безопасности.
Часто сканеры вываливают нам огромные отчеты, а если их несколько то их становится сильно больше чем мы сможем прочитать, тем более для скана каждой фичи.
Выплевывать эти отчеты в большие внешние модели такое себе, просто так отдаем внешним чуваками инструкцию как нас ломать. Но и небольшие on-prem модели могут не очень качествено отработать их.
А вот поднять агента с небольшой модель и дать ему возможность собирать информацию в интернете поможет более качественно отработать каждый файндинг. Условно агент получил список из 100 файндингов, и найдя информацию выкинул мусор и показал нам только реальные проблемы. А если еще и давать контекст нашей архитектуры то сумаризация может стать еще более точной)
👍1
CODE
Так все же IAC это код или описание? Ну зависит от того как мы его делаем)
Если по классике - берем манифест и приминяем его к инфре то нет, это не код. Это декларативное описание, которое исполняет рантайм. По сути описание желаемой конфигурации.
Есть и другие подходы, как в каком ни будь pulumi. Там мы можем описывать уже все как реальный код, с функциями, расчетами и тд. Так что это уже не совсем чистоя декларативное описание.
Вообще, я всегда за чистые декларативные stateless подходы, без дополнительного кода. Но иногда приходится идти на компромисы и смотреть на какой ни будь pulumi, который противоположен всему что мне нравится. Это стейтфул и не совсем чистое декларативное описание, но иногда в нем есть функциональность которой ни в одной другой системе.
Так все же IAC это код или описание? Ну зависит от того как мы его делаем)
Если по классике - берем манифест и приминяем его к инфре то нет, это не код. Это декларативное описание, которое исполняет рантайм. По сути описание желаемой конфигурации.
Есть и другие подходы, как в каком ни будь pulumi. Там мы можем описывать уже все как реальный код, с функциями, расчетами и тд. Так что это уже не совсем чистоя декларативное описание.
Вообще, я всегда за чистые декларативные stateless подходы, без дополнительного кода. Но иногда приходится идти на компромисы и смотреть на какой ни будь pulumi, который противоположен всему что мне нравится. Это стейтфул и не совсем чистое декларативное описание, но иногда в нем есть функциональность которой ни в одной другой системе.
👍2
HELM IMPORT
Один из подходов деплоя стендов это импорнт шаблона чарта и подставление туда вельюса под стенд.
Условно у нас в отдельной репе лежат шаблоны под все микросервисы, и рядом с ними values-dev.yaml и values-prod.yaml. И при деплое мы просто подставляем в них нужный тег образа и применяем чарт с нужным вельюс.
Из плюсов:
- Единое место с чартами
- Четкое разделение по стендам
- Легче отслеживать изменения
Из минусов:
- Сложнее версионировать сам шаблон
- Усложненный шаблон (включать/выключать директивы под стенды)
В целом подход рабочий, особенно для систем с большим количеством микросервисов.
Один из подходов деплоя стендов это импорнт шаблона чарта и подставление туда вельюса под стенд.
Условно у нас в отдельной репе лежат шаблоны под все микросервисы, и рядом с ними values-dev.yaml и values-prod.yaml. И при деплое мы просто подставляем в них нужный тег образа и применяем чарт с нужным вельюс.
Из плюсов:
- Единое место с чартами
- Четкое разделение по стендам
- Легче отслеживать изменения
Из минусов:
- Сложнее версионировать сам шаблон
- Усложненный шаблон (включать/выключать директивы под стенды)
В целом подход рабочий, особенно для систем с большим количеством микросервисов.
👍1
OFFLINE
Иногда в закрытых контурах нужно делать что то без доступа к интернету.
Это отдельная задача на подумать, так как многие инструменты по дефоту обращаются на свои сервера за чем либо. Например semgrep ходит за базами cve и рулзами, или же сборки образа качают зависимости из интернета.
Чаще всего тут можно использовать нексус. Использовать прокси кеш репы с зависимостями и регистри с готовыми оффлайн сборками.
Главная проблема тут - акутальность. Что бы не выпускать проекты с древними версиями пакетов, и сканером с старыми правилами безами, нужно постоянно держать нексус актуальном.
Вариант это сервисная тачка с интернетом, у которой в нашей сети доступ только к нексусу. Ну и крон задачи по обновлению на ней)
Иногда в закрытых контурах нужно делать что то без доступа к интернету.
Это отдельная задача на подумать, так как многие инструменты по дефоту обращаются на свои сервера за чем либо. Например semgrep ходит за базами cve и рулзами, или же сборки образа качают зависимости из интернета.
Чаще всего тут можно использовать нексус. Использовать прокси кеш репы с зависимостями и регистри с готовыми оффлайн сборками.
Главная проблема тут - акутальность. Что бы не выпускать проекты с древними версиями пакетов, и сканером с старыми правилами безами, нужно постоянно держать нексус актуальном.
Вариант это сервисная тачка с интернетом, у которой в нашей сети доступ только к нексусу. Ну и крон задачи по обновлению на ней)
👍1