STORAGE
Какие основные функции файлового хранилища я хочу видеть.
Так как чаще всего я использую их для бекапов то нужно:
1. Гибкие настройки доступа
2. Cli интерфейс для клиента
3. Ротация, что бы не забивать стор старыми файлами
4. Лимиты, возможность настроить типа хранилища и ограничения на место/запросы
5. Мониторинг, по используемому месту и запросам
По опыту, вообще не все предоставляют это. Только несколько провайдеров которые делают S3 хранилки.
Какие основные функции файлового хранилища я хочу видеть.
Так как чаще всего я использую их для бекапов то нужно:
1. Гибкие настройки доступа
2. Cli интерфейс для клиента
3. Ротация, что бы не забивать стор старыми файлами
4. Лимиты, возможность настроить типа хранилища и ограничения на место/запросы
5. Мониторинг, по используемому месту и запросам
По опыту, вообще не все предоставляют это. Только несколько провайдеров которые делают S3 хранилки.
👍1
BUFER
Про более низкоуровневую вещь.
Когда мы принимаем сетевые пакеты то не всегда можем обрабатывать их в реальном времени. Допустим при скачках трафика.
Для этого есть буферизация, когда пакеты сначала кладутся в память и обрабатываются по освобождению ресурсов. Это позволяет нам сглаживать спайки и не отказывать в обслуживании. В случае переполнения буфера мы можем отклонять пакет и просить клиента сделать ретрай.
Тут могут возникнуть проблемы. Например если мы принимаем UDP пакеты и буфер переполнился то, по логике UDP, клиент не будет пробовать отправить пакет еще раз.
Или же при больших спайках часть пакетов в буфере может быть уже не актуальной, но все равно занимать очередь.
Это решается размером, TTL и таймаутами. Главное подойти к проектированию с умом, что бы не создать больше проблем)
Про более низкоуровневую вещь.
Когда мы принимаем сетевые пакеты то не всегда можем обрабатывать их в реальном времени. Допустим при скачках трафика.
Для этого есть буферизация, когда пакеты сначала кладутся в память и обрабатываются по освобождению ресурсов. Это позволяет нам сглаживать спайки и не отказывать в обслуживании. В случае переполнения буфера мы можем отклонять пакет и просить клиента сделать ретрай.
Тут могут возникнуть проблемы. Например если мы принимаем UDP пакеты и буфер переполнился то, по логике UDP, клиент не будет пробовать отправить пакет еще раз.
Или же при больших спайках часть пакетов в буфере может быть уже не актуальной, но все равно занимать очередь.
Это решается размером, TTL и таймаутами. Главное подойти к проектированию с умом, что бы не создать больше проблем)
👍1
SAAS
Есть настоящий и псевдо saas.
Настоящий - под каждого клиента поднимаем изолированный инстанас приложения. Со своей база данных, всей инфрой и контейнерами приложения.
Псевдно - у нас одна система и разделяем клиентов по схемам в одной бд. Ничего отдельного ему не поднимаем.
Оба варианта рабочие.
Настоящий.
Плюсы:
- Реальная изоляция
- Меньше логики разделения на приложении
- Безопасность
Минусы:
- Дороже по инфре
- Больше времени перед отдачей клиенту
- Сложно релизить новые версии
Псевдо.
Плюсы:
- Быстрее поднимаем
- Дешевле по инфре
- Легче вносить изменения
Минусы:
- Менее безопасно
- Сложная логика разделения на приложении
- Не так безопасно
Есть настоящий и псевдо saas.
Настоящий - под каждого клиента поднимаем изолированный инстанас приложения. Со своей база данных, всей инфрой и контейнерами приложения.
Псевдно - у нас одна система и разделяем клиентов по схемам в одной бд. Ничего отдельного ему не поднимаем.
Оба варианта рабочие.
Настоящий.
Плюсы:
- Реальная изоляция
- Меньше логики разделения на приложении
- Безопасность
Минусы:
- Дороже по инфре
- Больше времени перед отдачей клиенту
- Сложно релизить новые версии
Псевдо.
Плюсы:
- Быстрее поднимаем
- Дешевле по инфре
- Легче вносить изменения
Минусы:
- Менее безопасно
- Сложная логика разделения на приложении
- Не так безопасно
👍1
LLM
Один из кейсов где можно приминять небольшие локальные модели это сокращение отчетов.
Сейчас с популярностью appsec процессов в одном пайплайне может быть огромное количество текстовых отчетов сканирований от разных инструментов.
Вычитывать каждый раз огромные портянки не вариант. Это долго и есть шанс упустить что то важное. А вот LLM тут ложится прям хорошо.
Правильно запромтив и пихая в модель данные частями можно явно убрать мусор и дублирования, и сделать какую то приоритизацию. Плюс мы не отправляем свои данные куда то внешние системы а обрабатываем все внутри.
Один из кейсов где можно приминять небольшие локальные модели это сокращение отчетов.
Сейчас с популярностью appsec процессов в одном пайплайне может быть огромное количество текстовых отчетов сканирований от разных инструментов.
Вычитывать каждый раз огромные портянки не вариант. Это долго и есть шанс упустить что то важное. А вот LLM тут ложится прям хорошо.
Правильно запромтив и пихая в модель данные частями можно явно убрать мусор и дублирования, и сделать какую то приоритизацию. Плюс мы не отправляем свои данные куда то внешние системы а обрабатываем все внутри.
👍1
BASH
Мне не нравится bash.
Казалось бы, я постоянно работаю с линуксом и пора бы уже привыкнуть к нему. И да, я привык и довольно неплохо знаю его. Но это не отменяет того что он очень неудобный и нечитаемый.
Да, на нем некоторые вещи можно сделать короче и быстрей, особенно то что касается простой работы с файлами. Но если нужно сделать что то более сложное то все, приходится выдумывать всякое.
Например кейс: мне нужно скачать файл бекапа из s3, поднять контейнер с бд и залить туда бекап. Потом поделать несколько запросов и удалить этот контейнер. Процесс тестирования бекапов.
И на баш можно написать все это. Но он не даст такой простоты работы с s3 и запросами как тот же самый питон.
Или например, нам нужно сделать поиск по содержимому лог файла. До какого то уровня нам хватит простого grep. Но если мы захотим собрать какую то статистику или сделать более сложное обьядинение то на баше опять придется страдать)
Поэтому для себя я выбрал баш только для самых простых операций в системе. А если мне нужно написать какую то автоматизацию то только питоне)
Мне не нравится bash.
Казалось бы, я постоянно работаю с линуксом и пора бы уже привыкнуть к нему. И да, я привык и довольно неплохо знаю его. Но это не отменяет того что он очень неудобный и нечитаемый.
Да, на нем некоторые вещи можно сделать короче и быстрей, особенно то что касается простой работы с файлами. Но если нужно сделать что то более сложное то все, приходится выдумывать всякое.
Например кейс: мне нужно скачать файл бекапа из s3, поднять контейнер с бд и залить туда бекап. Потом поделать несколько запросов и удалить этот контейнер. Процесс тестирования бекапов.
И на баш можно написать все это. Но он не даст такой простоты работы с s3 и запросами как тот же самый питон.
Или например, нам нужно сделать поиск по содержимому лог файла. До какого то уровня нам хватит простого grep. Но если мы захотим собрать какую то статистику или сделать более сложное обьядинение то на баше опять придется страдать)
Поэтому для себя я выбрал баш только для самых простых операций в системе. А если мне нужно написать какую то автоматизацию то только питоне)
👍1
UPDATE
Сегодня обновлял одну систему развернутую в контейнерах. На одну мажорную версию.
Какая случилисаь проблема - нужно было обновить mongo с версии 6.0 до 8.3. Плюс к этому вендор системы выбрал для этого новый образ монги и добавил дополнительные скрипты при старте.
Что пришлось делать:
- Берем обновленный образ и поднимаем его с версией седьмой версией монги
- Снимаем дамп с актуальной монги
- Заливаем ее в 7 версию
- Поднимаем целевую 8.3 версию
- Снимаем дамп с 7 версии
- Заливаем его в 8.3
- Поднимаем версию приложения
Такие финты пришлось делать потому что между 6 и 8 версии монги нет совместимости, пришлось делать перенос данных через 7, которая совместима со обеими.
На месте вендора, для удобства клиентов, я бы все же автоматизировал миграцию между версиями. Чисто контейниризация тут не решает)
Сегодня обновлял одну систему развернутую в контейнерах. На одну мажорную версию.
Какая случилисаь проблема - нужно было обновить mongo с версии 6.0 до 8.3. Плюс к этому вендор системы выбрал для этого новый образ монги и добавил дополнительные скрипты при старте.
Что пришлось делать:
- Берем обновленный образ и поднимаем его с версией седьмой версией монги
- Снимаем дамп с актуальной монги
- Заливаем ее в 7 версию
- Поднимаем целевую 8.3 версию
- Снимаем дамп с 7 версии
- Заливаем его в 8.3
- Поднимаем версию приложения
Такие финты пришлось делать потому что между 6 и 8 версии монги нет совместимости, пришлось делать перенос данных через 7, которая совместима со обеими.
На месте вендора, для удобства клиентов, я бы все же автоматизировал миграцию между версиями. Чисто контейниризация тут не решает)
👍3
DATA
Есть правило - не засорять данными отчеты.
Они должны быть читаемы и иметь минимум мусора. Если, допустим, сканирование безопасности генерит отчет на 30 страниц то никто не будет вчитываться. Или же с мониторингом, не надо делать алерты по каждому чиху.
Сейчас есть обходной путь, еспользовать llm. Если есть избыток текстовых данных то можно прогонять их через модели и просить убрать мусор и показать только важное.
Но тут риск, модель не эксперт и может упустить что то важное. Поэтому тут очень важно тестирование и правильный промтинг. Описав гипер подробный промт и снизив температуру можно добиться хороших результатов. Но модель все еще остается довольно вероятностной штукой.
Поэтому этот подход с вычещеним данных можно использовать не на самых критичных данных.
Есть правило - не засорять данными отчеты.
Они должны быть читаемы и иметь минимум мусора. Если, допустим, сканирование безопасности генерит отчет на 30 страниц то никто не будет вчитываться. Или же с мониторингом, не надо делать алерты по каждому чиху.
Сейчас есть обходной путь, еспользовать llm. Если есть избыток текстовых данных то можно прогонять их через модели и просить убрать мусор и показать только важное.
Но тут риск, модель не эксперт и может упустить что то важное. Поэтому тут очень важно тестирование и правильный промтинг. Описав гипер подробный промт и снизив температуру можно добиться хороших результатов. Но модель все еще остается довольно вероятностной штукой.
Поэтому этот подход с вычещеним данных можно использовать не на самых критичных данных.
👍1
DISK
Как я обычно подбираю тип и размер диска:
1. Сервер приложения.
Например обычная виртуалка с контейнерами или нода в кубе где будет крутится приложение. Тут хватит минимального hdd диска. Так как в таких случаях сервер баз данных и файловое хранилище вынесены наружу, то взаимодействие диском минимальное. Чаще приложенеи выгружается в ram при старте и работает уже там.
2. Небольшой сервер хранения.
Например s3 или база данных. При небольших нагрузках тут хватит обычного ssd диска, обьем выбираем по необходимости. Тут пока не надо сильно запариваться, при небольших нагрузках все будет хорошо.
3. Нагруженный сервер хранения.
Тут уже лучше сразу думать про nvme. Так же в клаудах, да и в целом в любых системах, IOPS и скорость чтения/записи зависит от размера диска - чем больше тем выше. Поэтому тут имеет смысл перезакладывать размер диска и подбирает с максималными характеристиками. Ну и конфигурировать размеры блоков, подбирать файловую систему и больше мониторить его состояние.
Современные клауды предоставляют большой выбор и довольно гибкую настройку. И в дефолте там все довольно хорошо, сильно запариваться имеет смысл только в третьем случае)
Как я обычно подбираю тип и размер диска:
1. Сервер приложения.
Например обычная виртуалка с контейнерами или нода в кубе где будет крутится приложение. Тут хватит минимального hdd диска. Так как в таких случаях сервер баз данных и файловое хранилище вынесены наружу, то взаимодействие диском минимальное. Чаще приложенеи выгружается в ram при старте и работает уже там.
2. Небольшой сервер хранения.
Например s3 или база данных. При небольших нагрузках тут хватит обычного ssd диска, обьем выбираем по необходимости. Тут пока не надо сильно запариваться, при небольших нагрузках все будет хорошо.
3. Нагруженный сервер хранения.
Тут уже лучше сразу думать про nvme. Так же в клаудах, да и в целом в любых системах, IOPS и скорость чтения/записи зависит от размера диска - чем больше тем выше. Поэтому тут имеет смысл перезакладывать размер диска и подбирает с максималными характеристиками. Ну и конфигурировать размеры блоков, подбирать файловую систему и больше мониторить его состояние.
Современные клауды предоставляют большой выбор и довольно гибкую настройку. И в дефолте там все довольно хорошо, сильно запариваться имеет смысл только в третьем случае)
👍1
UPTIME
Сама по себе кластеризация и дублирование всех серверов не ведет к высокому аптайму. Важно что бы само приложение было готово к этому.
Что важно учитывать:
- Ретраи всего. Если реплика бд упала при обращении то нужно сделать запрос на другую
- Очередь. Запрос должен быть в очереди, что бы не пропасть если упадет один сервер приложения
- Синхронная репликация. Что бы при записи данных они гарантированно оказались везде и не потерялись
- Хелсчеки. Если реплика приложения упала то сразу убирается из балансировки
- Днс балансировка. Если один из внешних балансеров упал то не отправляем запросы на него
Тут можно говорить очень долго, но главное понимать - просто засунув все в кубер мы не повысим uptime)
Сама по себе кластеризация и дублирование всех серверов не ведет к высокому аптайму. Важно что бы само приложение было готово к этому.
Что важно учитывать:
- Ретраи всего. Если реплика бд упала при обращении то нужно сделать запрос на другую
- Очередь. Запрос должен быть в очереди, что бы не пропасть если упадет один сервер приложения
- Синхронная репликация. Что бы при записи данных они гарантированно оказались везде и не потерялись
- Хелсчеки. Если реплика приложения упала то сразу убирается из балансировки
- Днс балансировка. Если один из внешних балансеров упал то не отправляем запросы на него
Тут можно говорить очень долго, но главное понимать - просто засунув все в кубер мы не повысим uptime)
👍1
TBD
В транке важно иметь фича тоглы. Ведь все фичи идут в прод по готовности, но бизнесово не всегда можно включать их сразу.
Плюс иногда мы хотим потестить фичи только на ограниченном количестве людей, тут тоглы тоже помогут.
Как это делать? У популярный фреймворков часто есть такая функциональность. По логике это выглядит так:
- Прожимаем кнопки с фичами в админке
- Фронт получает информацию о том что включено и отрисовывает новые кнопки/функции
- Апи эндпоинты на беке становятся доступными
- При А/Б тестах выбирается скоп пользаков которым это доступно
- При выключение все тоже самое
В контексте транка все фичи, по дефолту, идут в прод выключенными. А решение о включении принимается уже бизнесово)
В транке важно иметь фича тоглы. Ведь все фичи идут в прод по готовности, но бизнесово не всегда можно включать их сразу.
Плюс иногда мы хотим потестить фичи только на ограниченном количестве людей, тут тоглы тоже помогут.
Как это делать? У популярный фреймворков часто есть такая функциональность. По логике это выглядит так:
- Прожимаем кнопки с фичами в админке
- Фронт получает информацию о том что включено и отрисовывает новые кнопки/функции
- Апи эндпоинты на беке становятся доступными
- При А/Б тестах выбирается скоп пользаков которым это доступно
- При выключение все тоже самое
В контексте транка все фичи, по дефолту, идут в прод выключенными. А решение о включении принимается уже бизнесово)
👍1
CACHE
В ответу пользаку не всегда важна огромная точность. Например если пользак делает запрос на получение данных по определенному условия, и в бд попали новые данные, то нам не обязательно сразу же отдавать их. Лаг в несколько секунд часто допустим.
Если мы идем в эту историю то нам можно выполнять запрос один раз и класть его в кеш. И если эти данные запрашиваются десятки раз в секунду то нам можно скратить запросы в бд до одного раза. И потом отдавать их просто из кеша. Это сильно снизить нагрузку)
В ответу пользаку не всегда важна огромная точность. Например если пользак делает запрос на получение данных по определенному условия, и в бд попали новые данные, то нам не обязательно сразу же отдавать их. Лаг в несколько секунд часто допустим.
Если мы идем в эту историю то нам можно выполнять запрос один раз и класть его в кеш. И если эти данные запрашиваются десятки раз в секунду то нам можно скратить запросы в бд до одного раза. И потом отдавать их просто из кеша. Это сильно снизить нагрузку)
👍1
GPU
Если мы берем маленькие языковые модели то в подборе gpu важнее память. Если есть взять карту более старого поколения но с бОльшем количеством памяти то лучше взять ее.
Ведь сами расчеты там в любом случае будут занимать секунды, и отличие в 10-15 процентов не сыграют большой роли. А вот помещать большее количество параметров в память очень важно. Ведь постоянно дозапрашивать их с диска будет дольше чем разово выгрузить их в память.
В большенстве доступных карт сейчас не больше 16гб, в редких случаях 24 или 32. И вот выбрать более старую карту с 16гб будет куда лучше чем самую новую с 12.
Если мы берем маленькие языковые модели то в подборе gpu важнее память. Если есть взять карту более старого поколения но с бОльшем количеством памяти то лучше взять ее.
Ведь сами расчеты там в любом случае будут занимать секунды, и отличие в 10-15 процентов не сыграют большой роли. А вот помещать большее количество параметров в память очень важно. Ведь постоянно дозапрашивать их с диска будет дольше чем разово выгрузить их в память.
В большенстве доступных карт сейчас не больше 16гб, в редких случаях 24 или 32. И вот выбрать более старую карту с 16гб будет куда лучше чем самую новую с 12.
👍1🎄1
PARALEL
Для больших команд которые разрабатывают кучу микросерисов нужно сделать удобное окружение. Один из важных моментов это паралельность CI/CD. Что бы не было такого что один сервер с раннором 24/7 обрабатывает очередь и люди ждут сборки по несколько часов.
Тут хорошо ложится автоскейл кубера. Тут под каждую задачу будет выделяться нода, подключаться к кластеру и обрабатывать задачу. После завершения задачи она либо берет следующую из очереди либо гасится по ненадобности.
Это неплохой баланс в мощности и стоимостью. Не нужно держать десятку нод и платить за их простой.
Но главное не забывать про лимиты, что бы кубер не раздул кластер до сотен нод)
Для больших команд которые разрабатывают кучу микросерисов нужно сделать удобное окружение. Один из важных моментов это паралельность CI/CD. Что бы не было такого что один сервер с раннором 24/7 обрабатывает очередь и люди ждут сборки по несколько часов.
Тут хорошо ложится автоскейл кубера. Тут под каждую задачу будет выделяться нода, подключаться к кластеру и обрабатывать задачу. После завершения задачи она либо берет следующую из очереди либо гасится по ненадобности.
Это неплохой баланс в мощности и стоимостью. Не нужно держать десятку нод и платить за их простой.
Но главное не забывать про лимиты, что бы кубер не раздул кластер до сотен нод)
👍1
GPU
Изначально эти чипы создавались ради обработки графики. Так как там есть высокая паралельность, при умении делать простые операции.
Это значит что бы можем паралельно делать простые преобразования над матрицами, чем и является работа с графикой. Но внезапно оказалось что подобные вычесления подходят и для задач связанных с AI. А если совместить обработку графики и ИИ то альтернатив почти нет, никакие другие типы чипов не вывезут.
Например вчера вечером собрал небольшой проект, который обрабатывает видеопоток с камеры и вытаскивает оттуда обьекты заданные в промте. Для одного потока в десятки fps вполне хватает 4080 super на 16гб, и даже остается много ресурса на другие модели)
Изначально эти чипы создавались ради обработки графики. Так как там есть высокая паралельность, при умении делать простые операции.
Это значит что бы можем паралельно делать простые преобразования над матрицами, чем и является работа с графикой. Но внезапно оказалось что подобные вычесления подходят и для задач связанных с AI. А если совместить обработку графики и ИИ то альтернатив почти нет, никакие другие типы чипов не вывезут.
Например вчера вечером собрал небольшой проект, который обрабатывает видеопоток с камеры и вытаскивает оттуда обьекты заданные в промте. Для одного потока в десятки fps вполне хватает 4080 super на 16гб, и даже остается много ресурса на другие модели)
👍1
K8S
Для меня основной минус кубера в том что все делают его по своему.
От проекта к проекту каждый кластер будет уникален, особенно если используются разные провайдеры или это селф хостед. Там будут разные storage clases, ингресы, работа с сертами и переменными. Это создает дополнительнюу сложность когда вы разрабатываете дистрибутив приложения под кубер.
Это, чаще всего, решает вельюс файлом. Когда клиент может определить свои настройки. Но это усложняет сам процесс поставки софта клиенту, ведь ему придется самому донастраивать что то.
В этом плане обычная виртуалка с докером куда проще, можно предоставить клиенту docker compose со всем необходимым и у него все сразу заработает)
Для меня основной минус кубера в том что все делают его по своему.
От проекта к проекту каждый кластер будет уникален, особенно если используются разные провайдеры или это селф хостед. Там будут разные storage clases, ингресы, работа с сертами и переменными. Это создает дополнительнюу сложность когда вы разрабатываете дистрибутив приложения под кубер.
Это, чаще всего, решает вельюс файлом. Когда клиент может определить свои настройки. Но это усложняет сам процесс поставки софта клиенту, ведь ему придется самому донастраивать что то.
В этом плане обычная виртуалка с докером куда проще, можно предоставить клиенту docker compose со всем необходимым и у него все сразу заработает)
👍1
DEPENDENCY
Даже если мы в своем проекте используем минимум зависимостей, только известные большие библиотеки, то это не значит что на проде их будет не много. Каждая более менее большая библиотека тянет за собой зависимости поменьше, в свою очередь они тянут другие. Может получится что явно включив в проект 5 библиотек в конечной сборке их будет десятки и сотни.
В чем тут проблема? В конечном итоге в сборку могут попасть устаревшие и плохо защищенные зависимости. А отследить это будет очень сложно, для этого нужно разбирать вообще все что тянут библиотеки на каждом уровне зависимости.
Так же есть популярный способ атак: отследив все зависимости больших библиотек мы почти гарантированно найдем какой ни будь репозиторий с древними либами за которым уже никто не следит. И чаще сам софт репозитория будет плохо защищен. Поломав его и подменив либу на уязвимый код мы автоматически атакуем все проекты которые используют изначальную большую библиотеку.
Такие случаи уже были с npm репозиториями, когда в какой то пакет внедряли RCE.
Даже если мы в своем проекте используем минимум зависимостей, только известные большие библиотеки, то это не значит что на проде их будет не много. Каждая более менее большая библиотека тянет за собой зависимости поменьше, в свою очередь они тянут другие. Может получится что явно включив в проект 5 библиотек в конечной сборке их будет десятки и сотни.
В чем тут проблема? В конечном итоге в сборку могут попасть устаревшие и плохо защищенные зависимости. А отследить это будет очень сложно, для этого нужно разбирать вообще все что тянут библиотеки на каждом уровне зависимости.
Так же есть популярный способ атак: отследив все зависимости больших библиотек мы почти гарантированно найдем какой ни будь репозиторий с древними либами за которым уже никто не следит. И чаще сам софт репозитория будет плохо защищен. Поломав его и подменив либу на уязвимый код мы автоматически атакуем все проекты которые используют изначальную большую библиотеку.
Такие случаи уже были с npm репозиториями, когда в какой то пакет внедряли RCE.
👍1
DNS
При покупке домена нам нужно им как то управлять. Для этого нам нужен dns сервер.
Обычно, регистраторы предоставляют эту услугу за отдельную плату. Но чаще всего это не удобно, ведь разные наши домены могут быть у разных регистраторов, и тут либо мигрировать все в один либо менеджить несколько днс на разыных сервисах.
Для решения этой боли обычно использую cloudflare. Он прендоставляет бесплатный днс, который можно указать для всех доменов на всех регистраторов. По итогу получается единое место где мы можем добавлять запись и они будут супер быстро обновляться. Плюс cloudflare предоставляет довольно много фичей по защите и фильтрации трафика.
При покупке домена нам нужно им как то управлять. Для этого нам нужен dns сервер.
Обычно, регистраторы предоставляют эту услугу за отдельную плату. Но чаще всего это не удобно, ведь разные наши домены могут быть у разных регистраторов, и тут либо мигрировать все в один либо менеджить несколько днс на разыных сервисах.
Для решения этой боли обычно использую cloudflare. Он прендоставляет бесплатный днс, который можно указать для всех доменов на всех регистраторов. По итогу получается единое место где мы можем добавлять запись и они будут супер быстро обновляться. Плюс cloudflare предоставляет довольно много фичей по защите и фильтрации трафика.
👍1
K8S
Уже покритиковал кубер за то что он слишком настраиваемый и у всех разный. Время похвалить.
С одной из сторон эта настраиваемость позволяет положить куб на любую инфру. В каждой компании и облаке может быть своя система виртуализации, хранения данных, балансировки нагрузки и тд. И куб встанет почти куда угодно.
Это дает нам важное приемущество - верхнеуровнево у всех будет один интерфейс работы с инфрой, это сам куб. Будут различия в настройки pvc, ингрессов, сетевого взаимодействия и тд, но это мелочи по сравнению с тем что все остальное будет идентичным.
При переходе между проектами с разным кубом нужно сильно меньше времени на погружение в инфру, чем без куба)
Ну и как писал раньше, это иногда вызвает и сложности)
Уже покритиковал кубер за то что он слишком настраиваемый и у всех разный. Время похвалить.
С одной из сторон эта настраиваемость позволяет положить куб на любую инфру. В каждой компании и облаке может быть своя система виртуализации, хранения данных, балансировки нагрузки и тд. И куб встанет почти куда угодно.
Это дает нам важное приемущество - верхнеуровнево у всех будет один интерфейс работы с инфрой, это сам куб. Будут различия в настройки pvc, ингрессов, сетевого взаимодействия и тд, но это мелочи по сравнению с тем что все остальное будет идентичным.
При переходе между проектами с разным кубом нужно сильно меньше времени на погружение в инфру, чем без куба)
Ну и как писал раньше, это иногда вызвает и сложности)
👍1
SEC
В контексте безопасности нужно донастраивать наши фреймворки.
Например - спринг по дефоту запускает актуатор на том же порту что и приложение, и можно снаружи обратится на него. Самое невинное что грозит - раскрытие информации про инфру.
И вот таких моментов может быть много. Лучший вариант тут это закрыть все и открывать по мере необходимости. Ну и использовать специализированные DAST сканеры которые протыкают все возможные открытые эндпоинты.
В контексте безопасности нужно донастраивать наши фреймворки.
Например - спринг по дефоту запускает актуатор на том же порту что и приложение, и можно снаружи обратится на него. Самое невинное что грозит - раскрытие информации про инфру.
И вот таких моментов может быть много. Лучший вариант тут это закрыть все и открывать по мере необходимости. Ну и использовать специализированные DAST сканеры которые протыкают все возможные открытые эндпоинты.
👍1
NET
В плане сети логика должна быть такой: все что не разрешено должно быть запрещено.
Внешний балансер по дефолту не прокидывает ничего, и мы явно должно прописать проксирование, открытые порты и внутренние локейшены.
Сейчас просто сталкиваюсь с тем что в открытом доступе многих проектов валяется минио, нексус, кейклок и так далее. Где то с дефолтными кредами, где то с анонимным доступом и прочими косяками.
Чаще проблема тут в том что люди забывают и забивают на это, главное что бы основной сервис работал)
В плане сети логика должна быть такой: все что не разрешено должно быть запрещено.
Внешний балансер по дефолту не прокидывает ничего, и мы явно должно прописать проксирование, открытые порты и внутренние локейшены.
Сейчас просто сталкиваюсь с тем что в открытом доступе многих проектов валяется минио, нексус, кейклок и так далее. Где то с дефолтными кредами, где то с анонимным доступом и прочими косяками.
Чаще проблема тут в том что люди забывают и забивают на это, главное что бы основной сервис работал)
👍1
MOBILE
Последнии дни тыкал мобильные приложения на безопасность.
И хочется сказать, приложения под IOS сильно безопаснее. Даже же что бы влететь в него и проверить базовые вещи нужно постараться куда сильнее чем на андроиде.
Условно декомпилить apk сборку занимает минут 5, и еще 5 минут что бы просканить на самые очевидные проблемы с хардкодом. На ios сборках это займет сильно больше времени, и бесплатными решениями тут не обойтись.
НО, это все не спасает от ошибок разработчиков в хардкоде и ошибках в логике. Условно декомпилить в асемблер и сделать поиск сигнатур не очень сложно.
Последнии дни тыкал мобильные приложения на безопасность.
И хочется сказать, приложения под IOS сильно безопаснее. Даже же что бы влететь в него и проверить базовые вещи нужно постараться куда сильнее чем на андроиде.
Условно декомпилить apk сборку занимает минут 5, и еще 5 минут что бы просканить на самые очевидные проблемы с хардкодом. На ios сборках это займет сильно больше времени, и бесплатными решениями тут не обойтись.
НО, это все не спасает от ошибок разработчиков в хардкоде и ошибках в логике. Условно декомпилить в асемблер и сделать поиск сигнатур не очень сложно.
👍1