GITLAB
Сейчас занимаюсь переездом с одного инстанса гитлаба на другой, с новым доменом и полностью новой инфрой.
Какие основные сложности могут возникнуть:
- Диск. Тот же прикол что и с бекапированием, о котором вчера писал, с рестром бекапа та же история
- Конфигурация. Для того что бы все нормально переехало нужно воссоздать конфигурацию на 100 процентов такую же как на старом гитлабе
- Время. Большую часть времени ты просто ждешь, спустя пару часов может просто появится ошибка, и придется все делать с начала
- Раннеры. После рестора почти гарантировано придется делать новые раннеры
- Домены. Тут могут возникнуть проблемы в CI/CD если не была заявязка на переменные с адресами
В остальном, это хорошее время что бы взять техработы и настроить все как надо)
Сейчас занимаюсь переездом с одного инстанса гитлаба на другой, с новым доменом и полностью новой инфрой.
Какие основные сложности могут возникнуть:
- Диск. Тот же прикол что и с бекапированием, о котором вчера писал, с рестром бекапа та же история
- Конфигурация. Для того что бы все нормально переехало нужно воссоздать конфигурацию на 100 процентов такую же как на старом гитлабе
- Время. Большую часть времени ты просто ждешь, спустя пару часов может просто появится ошибка, и придется все делать с начала
- Раннеры. После рестора почти гарантировано придется делать новые раннеры
- Домены. Тут могут возникнуть проблемы в CI/CD если не была заявязка на переменные с адресами
В остальном, это хорошее время что бы взять техработы и настроить все как надо)
👍1
FRONT
Сейчас появляется модный паттерн проектирования фронтенда - микрофронты.
Логика тут в целом как и на бекенде, максимадно разделяем функциональность по разным приложениям. В контексте фронта у нас есть какой то основной индекс, который делает запросы на разные фронтовые ресурсы, а мы уже роутим эти запросы на нужные микрофронты.
Под копотом у таких фронтов может быть что угодно, хоть ssr на ноде хоть просто статика на nginx.
Логика тут такая же как и на беке:
- Распределение нагрузки
- Скейл только нужной функциональности
- Отказоустойчивость
На практике пока очень редко это видел. Но все больше обсуждается такой подход)
Сейчас появляется модный паттерн проектирования фронтенда - микрофронты.
Логика тут в целом как и на бекенде, максимадно разделяем функциональность по разным приложениям. В контексте фронта у нас есть какой то основной индекс, который делает запросы на разные фронтовые ресурсы, а мы уже роутим эти запросы на нужные микрофронты.
Под копотом у таких фронтов может быть что угодно, хоть ssr на ноде хоть просто статика на nginx.
Логика тут такая же как и на беке:
- Распределение нагрузки
- Скейл только нужной функциональности
- Отказоустойчивость
На практике пока очень редко это видел. Но все больше обсуждается такой подход)
👍1
PUBLIC
В рамках контура разработки проекты мы можем делать свои public докер образы.
У нас может быть много системных образов, например базовые для сборок, деплоя, тестирования. И иногда больно каждый раз авторизовываться в регистри ради них, особенно на разных серверах.
Поэтому нормальной практикой будет сделать регистри блоб в своей сети, где эти образы будут публичными на чтение. А изменять их только с нужными правами и авториацией.
Тут главное правило - делать эти образы максимально чистыми. Там не должно быть ничего сенсетив типа кред, каких то секретных сертов и ключей. Просто системные образы с нужными зависимостями. Тогда это будет безопасно)
В рамках контура разработки проекты мы можем делать свои public докер образы.
У нас может быть много системных образов, например базовые для сборок, деплоя, тестирования. И иногда больно каждый раз авторизовываться в регистри ради них, особенно на разных серверах.
Поэтому нормальной практикой будет сделать регистри блоб в своей сети, где эти образы будут публичными на чтение. А изменять их только с нужными правами и авториацией.
Тут главное правило - делать эти образы максимально чистыми. Там не должно быть ничего сенсетив типа кред, каких то секретных сертов и ключей. Просто системные образы с нужными зависимостями. Тогда это будет безопасно)
👍1
FREEZE
Впереди длинные выходные. Хочется поговорить про то как готовится к ним.
По хорошему, если мы разрабатываем и поддерживаем прод системы то перед праздниками лучшей идеей будет код фриз.
По сути это момент когда мы за недели две до праздников стопаем релизы в прод. Это поможет нам оставить систему в точно стабильно состоянии и уменьшить вероятность инцидентов. Ведь риск очень большой, в праздники не всегда возможно выдернуть нужных людей которые будут фиксить инциденты.
Мониторинг. Повезло если есть статистики на праздничные дни за несколько лет. Это поможет спрогнозировать нагрузку и заранее отмасштабировать систему.
Ну и техдолг. Если есть проблемы которые влияют на стабильность прода то хорошо бы их решить заранее)
Всех с наступающим, желаю стабильно прода и минимум инцидентов)
Впереди длинные выходные. Хочется поговорить про то как готовится к ним.
По хорошему, если мы разрабатываем и поддерживаем прод системы то перед праздниками лучшей идеей будет код фриз.
По сути это момент когда мы за недели две до праздников стопаем релизы в прод. Это поможет нам оставить систему в точно стабильно состоянии и уменьшить вероятность инцидентов. Ведь риск очень большой, в праздники не всегда возможно выдернуть нужных людей которые будут фиксить инциденты.
Мониторинг. Повезло если есть статистики на праздничные дни за несколько лет. Это поможет спрогнозировать нагрузку и заранее отмасштабировать систему.
Ну и техдолг. Если есть проблемы которые влияют на стабильность прода то хорошо бы их решить заранее)
Всех с наступающим, желаю стабильно прода и минимум инцидентов)
👍1
SHOW SERVER
Про сервера снежинки.
Это конечно не прям термин из компьютер сайнс, это скорее мемное выражение. Так называют сервера которые могут упасть у каждого чиха и никто уже их не поднимет.
Часто это бывает когда у нас есть один большой сервер в который пихается вообще все, от сайта и хранилища до 1С. Часто такие системы настраивают руками, и количество компонентов там может накапливаться годами. Плюс проблема в том что делает это несколько поколений админов.
Что тут можно пойти не так? По моему очевидно что если установить или обновить какой то один компонент на этом сервере то это может задеть все остальное и мы уже ничего не востоновим.
Как исправить? Ну лучше этого совсем не допускать. Распредлеять компоненты по небольшим серверам и поднимать их декларативно, с максимально автоматизацией и переносимостью. Тут основная проблема в ручных дейтвиях.
Но если этот сервер уже появился то можно потихоньку распиливать его и делать как описано выше)
Про сервера снежинки.
Это конечно не прям термин из компьютер сайнс, это скорее мемное выражение. Так называют сервера которые могут упасть у каждого чиха и никто уже их не поднимет.
Часто это бывает когда у нас есть один большой сервер в который пихается вообще все, от сайта и хранилища до 1С. Часто такие системы настраивают руками, и количество компонентов там может накапливаться годами. Плюс проблема в том что делает это несколько поколений админов.
Что тут можно пойти не так? По моему очевидно что если установить или обновить какой то один компонент на этом сервере то это может задеть все остальное и мы уже ничего не востоновим.
Как исправить? Ну лучше этого совсем не допускать. Распредлеять компоненты по небольшим серверам и поднимать их декларативно, с максимально автоматизацией и переносимостью. Тут основная проблема в ручных дейтвиях.
Но если этот сервер уже появился то можно потихоньку распиливать его и делать как описано выше)
👍2
MIGRATE
Сегодня переносил один из прод серверов.
Смысл был в том что бы максимально просто и безболезненно обновится но новой версии убунты. И в тему прошлого поста, этот переезд был максимально быстрым и безболезненным:
- Поднял новый сервер с нужной версией убунты
- Сделал базовую настройку
- Накатил приложеньку через CI/CD
- Переключил трафик
На все про все не больше 10 минут)
Такой автоматизированный шаблонный процесс настройки систем позволяет нам довольно быстро прыгать между разными серверами и клаудами)
Сегодня переносил один из прод серверов.
Смысл был в том что бы максимально просто и безболезненно обновится но новой версии убунты. И в тему прошлого поста, этот переезд был максимально быстрым и безболезненным:
- Поднял новый сервер с нужной версией убунты
- Сделал базовую настройку
- Накатил приложеньку через CI/CD
- Переключил трафик
На все про все не больше 10 минут)
Такой автоматизированный шаблонный процесс настройки систем позволяет нам довольно быстро прыгать между разными серверами и клаудами)
👍2
FEDORA
Те кто внимательно читает мой канал могли заметить - я очень люблю fedora. Я все еще считаю его лучшим дистрибутивом линукса.
Но в работе почти в 100 процентах случаев использую серверную убунту. Есть много факторов почему так сложилось, наверно главный в том что это стандарт для сферы где я работаю.
Но когда возникает возможность поэкспериментировать я стараюсь ставить на сервера последнюю федору. Как сегодня, мне надо было поднять сервер с loki для хранения логов, и решил делать это на 37 федоре. Из того от чего я отвык при пользовании убунты - быстрый пакетный менеджер, отсутствие лишних пакетов, отзывчивость системы)
Вообщем буду продолжать экспериментировать по возможности, ставя самые последние версии)
Те кто внимательно читает мой канал могли заметить - я очень люблю fedora. Я все еще считаю его лучшим дистрибутивом линукса.
Но в работе почти в 100 процентах случаев использую серверную убунту. Есть много факторов почему так сложилось, наверно главный в том что это стандарт для сферы где я работаю.
Но когда возникает возможность поэкспериментировать я стараюсь ставить на сервера последнюю федору. Как сегодня, мне надо было поднять сервер с loki для хранения логов, и решил делать это на 37 федоре. Из того от чего я отвык при пользовании убунты - быстрый пакетный менеджер, отсутствие лишних пакетов, отзывчивость системы)
Вообщем буду продолжать экспериментировать по возможности, ставя самые последние версии)
👍1
CLOUD INIT
По сути система конфигурации. В облаках, когда мы выбираем ось, то ее образ не собирается под нас а просто подтягивается шаблонный. Но когда мы конфижим машину в интерфейсе (или где то еще) то мы выбираем разные параметры типа:
- Имя машины
- Пользователи
- Добавляем ключи
- Делаем какие то настройки сети
Cloud init дает нам возможность при первом запуске получить такую машину которую мы сконфижили. По сути это простой yaml манифест с описанием настроек машины и интерпритатор написанный на питоне, который парсит и применяет этот манифест. И по итогу мы получаем такую машину как мы хотим из шаблонного образа операционки.
Большенство задач которые описаны в этом манифесте выполняются только при первом запуске. Но некоторые могут запускаться и после ребута, по сути мы можем добавлять их в манифест уже после создания машины.
По логике это очень похоже на ansible, просто специализированный именно под первоначальную настройку в клауде и сильно проще)
По сути система конфигурации. В облаках, когда мы выбираем ось, то ее образ не собирается под нас а просто подтягивается шаблонный. Но когда мы конфижим машину в интерфейсе (или где то еще) то мы выбираем разные параметры типа:
- Имя машины
- Пользователи
- Добавляем ключи
- Делаем какие то настройки сети
Cloud init дает нам возможность при первом запуске получить такую машину которую мы сконфижили. По сути это простой yaml манифест с описанием настроек машины и интерпритатор написанный на питоне, который парсит и применяет этот манифест. И по итогу мы получаем такую машину как мы хотим из шаблонного образа операционки.
Большенство задач которые описаны в этом манифесте выполняются только при первом запуске. Но некоторые могут запускаться и после ребута, по сути мы можем добавлять их в манифест уже после создания машины.
По логике это очень похоже на ansible, просто специализированный именно под первоначальную настройку в клауде и сильно проще)
👍2
FLOW
Думаю важно понимать - нет какого то определенного правильного гит флоу в разработке.
Наверно можно сказать что есть самые поулярные вариант типа:
feature-N -> dev -> test -> main -> tag
Но это не прибито гвоздями. Каждая команда может сама решать как удобно. Например у меня на одном из проектов все фичи сливаются в main ветку, откуда катится на дев стенд, и уже с main создается продный тег, и всем удобно)
Сложные флоу нужны там где есть много разработчиков и множество стендов, но и там можно сделать попроще.
Гибкие методологии разработки на то и гибкие, что позволяют нам делать удобно конкретно для нас)
Думаю важно понимать - нет какого то определенного правильного гит флоу в разработке.
Наверно можно сказать что есть самые поулярные вариант типа:
feature-N -> dev -> test -> main -> tag
Но это не прибито гвоздями. Каждая команда может сама решать как удобно. Например у меня на одном из проектов все фичи сливаются в main ветку, откуда катится на дев стенд, и уже с main создается продный тег, и всем удобно)
Сложные флоу нужны там где есть много разработчиков и множество стендов, но и там можно сделать попроще.
Гибкие методологии разработки на то и гибкие, что позволяют нам делать удобно конкретно для нас)
👍1
INTERPRETATION
Современные инструменты конфигурирования и инфраструктуры как кода часто представляют из себя интерпретаторы.
Нам предоставляется определенный синтаксис, чаще всего на yaml. И сам инструмент парсит его, проверят синтаксис на коректность и по своей логике выполняет сам манифест. Да, это не прям стандартный интерпритатор как у питона, где идет пошаговая jit компиляция и выполнение, это что то похожее на интерпретацию dsl.
Но понимание что это просто интерпретация манифеста дает нам понимание как правильно встраивать новые модули, например в ансибл. По сути мы просто обьявляем новые директивы в синтаксис манифеста и исполняем определенные инструкции если нашли их)
Современные инструменты конфигурирования и инфраструктуры как кода часто представляют из себя интерпретаторы.
Нам предоставляется определенный синтаксис, чаще всего на yaml. И сам инструмент парсит его, проверят синтаксис на коректность и по своей логике выполняет сам манифест. Да, это не прям стандартный интерпритатор как у питона, где идет пошаговая jit компиляция и выполнение, это что то похожее на интерпретацию dsl.
Но понимание что это просто интерпретация манифеста дает нам понимание как правильно встраивать новые модули, например в ансибл. По сути мы просто обьявляем новые директивы в синтаксис манифеста и исполняем определенные инструкции если нашли их)
👍1
SYSTEMD
После загрузки ядра линукса нам нужно поднят всю остальную систему, которая может состоять из множества компонентов.
Для этого сейчас, чаще всего, используется systemd. По сути это набор манифестов и рантайм который позволяет поднять все так как нам нужно. Там описывается:
- Путь до компонента
- Политика старта/рестарта
- Пользователь
- Рабочая директория
И множество других полезных директив.
После загрузки ядро передает управление в systemd и он уже поднимает все в нужном порядке.
Раньше в большенстве дистрибутивов использовался init. Но его основной минус в том что он запускает все поочередно и имеет менее гибкую настройку. В то время как systemd может запускать все паралельно и имеет большой уровень кастомизации
После загрузки ядра линукса нам нужно поднят всю остальную систему, которая может состоять из множества компонентов.
Для этого сейчас, чаще всего, используется systemd. По сути это набор манифестов и рантайм который позволяет поднять все так как нам нужно. Там описывается:
- Путь до компонента
- Политика старта/рестарта
- Пользователь
- Рабочая директория
И множество других полезных директив.
После загрузки ядро передает управление в systemd и он уже поднимает все в нужном порядке.
Раньше в большенстве дистрибутивов использовался init. Но его основной минус в том что он запускает все поочередно и имеет менее гибкую настройку. В то время как systemd может запускать все паралельно и имеет большой уровень кастомизации
👍2
ASISTENT
Яндекс клауд выкатил превью версию AI асистента.
Пока это бесплатная версия которая не так много умеет, но уже дает прикольные возможности. Например сегодня я описал ему что мне нужна группа безопасности с определенными правилами, он спроектировал ее и спросил можно ли ее создать, я апрувнул и он ее сделал. И еще сейчас с его помощью провожу ревизию клауда, что бы вытащить все ресурсы которые не используются либо используются не на полную.
Пока что он ограничен, например он не может снять метрики с managed постгри. Но уже может по mcp цепляться к кубу.
Думаю за этим определенное будущее, и в какой то мере замена саппорта клауда)
Яндекс клауд выкатил превью версию AI асистента.
Пока это бесплатная версия которая не так много умеет, но уже дает прикольные возможности. Например сегодня я описал ему что мне нужна группа безопасности с определенными правилами, он спроектировал ее и спросил можно ли ее создать, я апрувнул и он ее сделал. И еще сейчас с его помощью провожу ревизию клауда, что бы вытащить все ресурсы которые не используются либо используются не на полную.
Пока что он ограничен, например он не может снять метрики с managed постгри. Но уже может по mcp цепляться к кубу.
Думаю за этим определенное будущее, и в какой то мере замена саппорта клауда)
👍1
LAMBDA
Некоторые клауды предоставляют услуги безсерверных вычислений. Часто это называется lambda функциями.
Суть состоит в том что мы просто закидываем свой код в специальную систему, и когда туда приходит запрос то просто происходит само вычесление этого кода с пришедшими данными. Смысл тут в том что мы платим только за тот компьют который использовали, это выгодна когда нужно поднять что то что будет очень редко вызыватьяс.
Из минусов:
- Долгий ответ, так как код не всегда запущен а поднимается только при вызове
- Нет прозрачности, мы не контролируем то где код запускается
- Сложность, что бы все верно настроить нужна большая экспертиза в конкретном клауде
Ну и мне никогда не нравился термин "безсерверные вычисления", как по мне куда уместнее называть это "облачные вычисления", так как это просто функция облака которая запускается на серверах)
И кстати, по концепции чем то схоже с lambda функциями в программировании, концептуально это просто функция которая зависит только от входных параметров и отдает определенный результат)
Некоторые клауды предоставляют услуги безсерверных вычислений. Часто это называется lambda функциями.
Суть состоит в том что мы просто закидываем свой код в специальную систему, и когда туда приходит запрос то просто происходит само вычесление этого кода с пришедшими данными. Смысл тут в том что мы платим только за тот компьют который использовали, это выгодна когда нужно поднять что то что будет очень редко вызыватьяс.
Из минусов:
- Долгий ответ, так как код не всегда запущен а поднимается только при вызове
- Нет прозрачности, мы не контролируем то где код запускается
- Сложность, что бы все верно настроить нужна большая экспертиза в конкретном клауде
Ну и мне никогда не нравился термин "безсерверные вычисления", как по мне куда уместнее называть это "облачные вычисления", так как это просто функция облака которая запускается на серверах)
И кстати, по концепции чем то схоже с lambda функциями в программировании, концептуально это просто функция которая зависит только от входных параметров и отдает определенный результат)
👍1
SSH
Как сделать второй фактор при аутификации по ссш?
Самый простой способ это использовать гугл аутенфикатор. После настройки при аутенфикации нужно будет ввести и пароль и второй фактор из приложения (но с ключами полноценно пока не работает, все равно придется вводить пароль).
Как реализовать:
1. Ставим пакет
2. Для нужно пользака, под которым будем ходить, генерим код командой
дальше добавляем этот код в приложение гугл аутификатора
3. В файле /etc/pam.d/sshd добляем строку
4. В /etc/ssh/sshd_config добавим
5. Рестарутем ssh
На этом все, при следующем логине система попросит нас ввести пароль и код)
Как сделать второй фактор при аутификации по ссш?
Самый простой способ это использовать гугл аутенфикатор. После настройки при аутенфикации нужно будет ввести и пароль и второй фактор из приложения (но с ключами полноценно пока не работает, все равно придется вводить пароль).
Как реализовать:
1. Ставим пакет
apt install libpam-google-authenticator
2. Для нужно пользака, под которым будем ходить, генерим код командой
google-authenticator
дальше добавляем этот код в приложение гугл аутификатора
3. В файле /etc/pam.d/sshd добляем строку
auth required pam_google_authenticator.so
4. В /etc/ssh/sshd_config добавим
ChallengeResponseAuthentication yes
5. Рестарутем ssh
service ssh restart
На этом все, при следующем логине система попросит нас ввести пароль и код)
👍1
K8S
Возьмем для примера кластер, куда будет развертывать разные стенды приложений - дев, тест и прод. Все стенды в своих неймспейсах, изолированных политиками доступа и выделеными ресурсами.
И вот что лучше, несколько больших нод или много маленьких?
Почти всегда много маленьких. Потому что каждая конкретная нода будет нести меньше полезной нагрузки, она будет сильно размазана, и вот почему это лучше:
- При падении одной ноды куда быстрее перераспределить нагрузки с нее когда ее мало
- Нет сильной потери в производительности при падении какого то процента нод
- Каждая нода меньше тротлит и нагружается по IO, что дает плюс в производительности
Все это работает на масштабе сотен подов и хоть какой то нагрузки, понятно что если у нас штук 10 подов и 20 rps к ним то можно взять хоть одну ноду)
Важно еще упомянуть, если мы возьмем 10 и 20 нод, с одинаковым общим ресурсом то 20 чаще будет дороже.
Возьмем для примера кластер, куда будет развертывать разные стенды приложений - дев, тест и прод. Все стенды в своих неймспейсах, изолированных политиками доступа и выделеными ресурсами.
И вот что лучше, несколько больших нод или много маленьких?
Почти всегда много маленьких. Потому что каждая конкретная нода будет нести меньше полезной нагрузки, она будет сильно размазана, и вот почему это лучше:
- При падении одной ноды куда быстрее перераспределить нагрузки с нее когда ее мало
- Нет сильной потери в производительности при падении какого то процента нод
- Каждая нода меньше тротлит и нагружается по IO, что дает плюс в производительности
Все это работает на масштабе сотен подов и хоть какой то нагрузки, понятно что если у нас штук 10 подов и 20 rps к ним то можно взять хоть одну ноду)
Важно еще упомянуть, если мы возьмем 10 и 20 нод, с одинаковым общим ресурсом то 20 чаще будет дороже.
👍1
Заметка:
Когда обновляешь версию убунты на сервере гитлаба то нужно обновить гитлабовские deb репозитории до актуальной версии)
Когда обновляешь версию убунты на сервере гитлаба то нужно обновить гитлабовские deb репозитории до актуальной версии)
IDENPODENT
Часто в iac системах мы делаем все иденпотентно.
Это значит что мы не выполняем то что уже выполнено. Например:
- Не перезаписываем файлы
- Не пытаемся установить пакеты заново
- Не перезапускам без необходимости
Это позволяет нам делать все максимально быстро и безшовно, и уменьшить риск сломать то что уже работает)
Часто это делается с помощью какого либо стейта, либо с помощью хеширования операций.
Часто в iac системах мы делаем все иденпотентно.
Это значит что мы не выполняем то что уже выполнено. Например:
- Не перезаписываем файлы
- Не пытаемся установить пакеты заново
- Не перезапускам без необходимости
Это позволяет нам делать все максимально быстро и безшовно, и уменьшить риск сломать то что уже работает)
Часто это делается с помощью какого либо стейта, либо с помощью хеширования операций.
👍1
INCLIDE
Сейчас пишим общие пйплайны для микросервисов. Флоу такой:
- На МР запускаются линтер и юнит тесты
- С develop ветки катится дев стенд, с main ветки тест стенд
- С тегов в прод
На дев и тест пайлпанй выглядит так:
1. Билд jar файла
2. Оборачивание в докер образ
3. Sca сканирование образа
4. Деплой на дев/тест
Для прода плинируем тегировать тест образ продовым тегом и катить уже.
Архитектурно это выглядит так:
Отдельная ci/cd репа, каждый шаг описан в отдельном файле, для того что бы в конкретную репу мы могли инклюдить только то что нужно. В самом репозитории сервиса делаем правки для деплоя, что бы можно было кастомизировать переменки, просто через extend общего шага из ci/cd репы.
Сейчас пишим общие пйплайны для микросервисов. Флоу такой:
- На МР запускаются линтер и юнит тесты
- С develop ветки катится дев стенд, с main ветки тест стенд
- С тегов в прод
На дев и тест пайлпанй выглядит так:
1. Билд jar файла
2. Оборачивание в докер образ
3. Sca сканирование образа
4. Деплой на дев/тест
Для прода плинируем тегировать тест образ продовым тегом и катить уже.
Архитектурно это выглядит так:
Отдельная ci/cd репа, каждый шаг описан в отдельном файле, для того что бы в конкретную репу мы могли инклюдить только то что нужно. В самом репозитории сервиса делаем правки для деплоя, что бы можно было кастомизировать переменки, просто через extend общего шага из ci/cd репы.
👍2