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
HOT RELOAD
Механизм hot reload часто используется в системах в которых недопустим простой.
В классических релизных системах поднимается паралельное приложение с новой версией кода, новые клиенты переходят туда, и старая версия убивается. Но проблема состоит в том что старые клиенты теряют коннект к приложению, так как старая версия убивается.
Hot reload в свою очередь поднимает новую версию в рамках текущего прод рантайма. Новых клиентов так же сразу отправляет в новую версию. Но перед тем как прибить старую дожидается пока на ней не остаенстя ни одного клиента.
Такая реализация есть, например, в виртуальной машине erlang. Ну и в nginx)
Механизм hot reload часто используется в системах в которых недопустим простой.
В классических релизных системах поднимается паралельное приложение с новой версией кода, новые клиенты переходят туда, и старая версия убивается. Но проблема состоит в том что старые клиенты теряют коннект к приложению, так как старая версия убивается.
Hot reload в свою очередь поднимает новую версию в рамках текущего прод рантайма. Новых клиентов так же сразу отправляет в новую версию. Но перед тем как прибить старую дожидается пока на ней не остаенстя ни одного клиента.
Такая реализация есть, например, в виртуальной машине erlang. Ну и в nginx)
👍1
DOCKER
Одна из причин почему я люблю докер - можно оживить проект который был на фризе несколько месяцев.
Даже если проект был на фризе год то главное что бы образ нормально собрался, а дальше уже по быстрому его выкатить. А если остались уже собранные образы то вообще изи)
Ну и проблемы с сборками чаще всего связаны с устаревшими версиями зависимостей приложений, поэтому и это пофиксить можно быстро.
Так что докер спасает нас от мучений с воссозданием нужного окружения)
Одна из причин почему я люблю докер - можно оживить проект который был на фризе несколько месяцев.
Даже если проект был на фризе год то главное что бы образ нормально собрался, а дальше уже по быстрому его выкатить. А если остались уже собранные образы то вообще изи)
Ну и проблемы с сборками чаще всего связаны с устаревшими версиями зависимостей приложений, поэтому и это пофиксить можно быстро.
Так что докер спасает нас от мучений с воссозданием нужного окружения)
👍2
DELIVERY
Про доствку до прода клиента.
Допустим мы сделали какое то приложение и хотим доставить его на сервера клиента. Есть несколько вариантов.
Простой:
Директория с кодом и скриптами. Клиент загружает ее на сервер, запускает скрипт который соберет образы и поднимет контейнеры через композ. Максимально просто, но подходит только если мы готовы показывать код.
Сложный:
Собираем образы с обфусцированным кодом. Клиенту даем чарт и разовый токен для нашего регистри. При поднятии прложение должно будет опрашивать нашу админку по специальным сертам, что бы иметь возможность работать.
Про доствку до прода клиента.
Допустим мы сделали какое то приложение и хотим доставить его на сервера клиента. Есть несколько вариантов.
Простой:
Директория с кодом и скриптами. Клиент загружает ее на сервер, запускает скрипт который соберет образы и поднимет контейнеры через композ. Максимально просто, но подходит только если мы готовы показывать код.
Сложный:
Собираем образы с обфусцированным кодом. Клиенту даем чарт и разовый токен для нашего регистри. При поднятии прложение должно будет опрашивать нашу админку по специальным сертам, что бы иметь возможность работать.
👍1
RENDER
Сам по себе шаблон манифеста или пайплайна это просто текст.
В рантайме мы передаем туда нужные параметры. И рантайм уже рендерит итоговый манифест, по сути разворачивает шаблон с входными параметрами и у нас получается полный файл со всем нужным.
И после рендера рантайм уже интерпритирует развернутый манифест на реальную инфру.
Это удобно, можно на лету расчитывать манифест и не хранить кучу стейта.
Сам по себе шаблон манифеста или пайплайна это просто текст.
В рантайме мы передаем туда нужные параметры. И рантайм уже рендерит итоговый манифест, по сути разворачивает шаблон с входными параметрами и у нас получается полный файл со всем нужным.
И после рендера рантайм уже интерпритирует развернутый манифест на реальную инфру.
Это удобно, можно на лету расчитывать манифест и не хранить кучу стейта.
👍1
LLM
Инструменты для вайбкода очень хороши для генерации манифестов.
Гитхаб заполнен примерами хороших манифестов, на которых модельки и обучались. А если еще скормить свой эталонный манифест то модель легко сгенерит то что ты хочешь.
Вчера этим и заинмался. Есть три репозитория, с разными компонентами система - бек, фронт, бот. И мне нужно было по сути разово их установить. Склонировал все три репы в одну директорию, открыл в курсоре ее и попросил набросать чарт. Потом просто заполнил вельюс с нужными переменками и образами и установил его в кластер. Ну и немного подебажил. Профит.
А вот года два назад мне понадобилось бы часа 2-3 что бы набросать этот чарт, что бы дойти до установки и дебага.
Инструменты для вайбкода очень хороши для генерации манифестов.
Гитхаб заполнен примерами хороших манифестов, на которых модельки и обучались. А если еще скормить свой эталонный манифест то модель легко сгенерит то что ты хочешь.
Вчера этим и заинмался. Есть три репозитория, с разными компонентами система - бек, фронт, бот. И мне нужно было по сути разово их установить. Склонировал все три репы в одну директорию, открыл в курсоре ее и попросил набросать чарт. Потом просто заполнил вельюс с нужными переменками и образами и установил его в кластер. Ну и немного подебажил. Профит.
А вот года два назад мне понадобилось бы часа 2-3 что бы набросать этот чарт, что бы дойти до установки и дебага.
👍2
RULES
Есть любители все усложнять. Например сделать флоу пайплайна из десятков стро рулзов.
Из разряда "если запуск с кнопки в вебе и на определенной ветке но нужно добавить эту переменную, иначе ничего не заработает".
Иногда, канеш, в этом прослеживается капелька логики. Но чаще все можно заменить несколькими only, except и env окружениями. И это даст сильно более прозрачный и читаемы процесс.
Есть любители все усложнять. Например сделать флоу пайплайна из десятков стро рулзов.
Из разряда "если запуск с кнопки в вебе и на определенной ветке но нужно добавить эту переменную, иначе ничего не заработает".
Иногда, канеш, в этом прослеживается капелька логики. Но чаще все можно заменить несколькими only, except и env окружениями. И это даст сильно более прозрачный и читаемы процесс.
👍1
PVC
Как в современных клаудах работают вольюмы в кубе:
- Запрос на создание pvc в апи куба
- Запрос на создание сетевого топа в клауде от куба
- Поднятие пода которому нужен pvc
- Создание сетевого тома
- Маунт тома к ноде кластера
- Маунт директории пода к этому тому
Профит, мы можем сохранять данные из нашего пода в клаудном томе)
Как в современных клаудах работают вольюмы в кубе:
- Запрос на создание pvc в апи куба
- Запрос на создание сетевого топа в клауде от куба
- Поднятие пода которому нужен pvc
- Создание сетевого тома
- Маунт тома к ноде кластера
- Маунт директории пода к этому тому
Профит, мы можем сохранять данные из нашего пода в клаудном томе)
👍1
FLOW
Сегодня немного погрумили релизный флоу разработки.
Пришли к чему то близкому к gitlab flow:
- main ветка как основная dev версия
- c main ветки катимся на dev стенд
- фича ветки берутся от main
- с main уходит релизную ветку
- с релизной ветки катим stage
- вливаем релизную ветку в prod ветку
- с prod ветки катимся в прод
- гасим релизную ветку
Главный принцип: минимум веток которые живут больше нескольких дней.
Да, выглядит замудренно, но если уложить это в голову то становится понятно и удобно)
Сегодня немного погрумили релизный флоу разработки.
Пришли к чему то близкому к gitlab flow:
- main ветка как основная dev версия
- c main ветки катимся на dev стенд
- фича ветки берутся от main
- с main уходит релизную ветку
- с релизной ветки катим stage
- вливаем релизную ветку в prod ветку
- с prod ветки катимся в прод
- гасим релизную ветку
Главный принцип: минимум веток которые живут больше нескольких дней.
Да, выглядит замудренно, но если уложить это в голову то становится понятно и удобно)
👍1
OS
Операционная система это по сути набор софта.
В юникс мире есть четкое разделение на ядро и дистрибутив, и под операционными системами подразумивается как раз дистрибутив.
Что в него входит?
- Загрузчик, который поднимает ядро при старте
- Инит система, какой ни будь systemd который запускает окружение на ядре
- Файловая система, инструменты по работе с диском
- DE, который поднимается инит системой
- Предустановленный пользовательский софт
И под эту картину подпадают очень разные системы, от линукса и макоси, заканчивая андроидом и авесом. Глобально тут только винда придумывает свой путь, отсюда и такое отличие в логике взаимодействия.
Операционная система это по сути набор софта.
В юникс мире есть четкое разделение на ядро и дистрибутив, и под операционными системами подразумивается как раз дистрибутив.
Что в него входит?
- Загрузчик, который поднимает ядро при старте
- Инит система, какой ни будь systemd который запускает окружение на ядре
- Файловая система, инструменты по работе с диском
- DE, который поднимается инит системой
- Предустановленный пользовательский софт
И под эту картину подпадают очень разные системы, от линукса и макоси, заканчивая андроидом и авесом. Глобально тут только винда придумывает свой путь, отсюда и такое отличие в логике взаимодействия.
👍1