TMP
Вынесение шаблонов деплоя в отдельную репу может сильно ускорить релизы.
Да, не всегда просто сделать такой шаблон который учтет все возможные варианты. Но разово настроив мы можем быстро подрубать к новым микросервисам шаблон и быстро катить. Останется только заполнить переменки.
Ну и есть два типа добавления шаблонов.
1. Подключаем как include нужные модули, в самом CI/CD манифесте.
2. Переобределяем дефолтный путь до пайплайна на внешнюю репу.
Чаще удобнее второй вариант, но первый дает возможность нам включать только то что нужно.
Вынесение шаблонов деплоя в отдельную репу может сильно ускорить релизы.
Да, не всегда просто сделать такой шаблон который учтет все возможные варианты. Но разово настроив мы можем быстро подрубать к новым микросервисам шаблон и быстро катить. Останется только заполнить переменки.
Ну и есть два типа добавления шаблонов.
1. Подключаем как include нужные модули, в самом CI/CD манифесте.
2. Переобределяем дефолтный путь до пайплайна на внешнюю репу.
Чаще удобнее второй вариант, но первый дает возможность нам включать только то что нужно.
👍1
SHARED
Иногда мы делаем какую то общую инфру для разных проектов. Что бы условно 3 разные команды с своими проектами могли использовать общую дев/тест инфру.
Тут главное реализовать это инфру так что бы никто никому не мешал. Важно заложить:
- Команде доступен только свой неймспейс
- Для всех отдельные пользаки в БД с своими лимитами коннектов
- Определенный ресурс для каждой команды, исходя из ее потребности
- Разделение доступов до логов и метрик, что бы не было общей помойки
С этими базовыми вещами для каждой команды сможем выделять изоированный кусок общей инфры, так что бы они не мешали друг другу)
Иногда мы делаем какую то общую инфру для разных проектов. Что бы условно 3 разные команды с своими проектами могли использовать общую дев/тест инфру.
Тут главное реализовать это инфру так что бы никто никому не мешал. Важно заложить:
- Команде доступен только свой неймспейс
- Для всех отдельные пользаки в БД с своими лимитами коннектов
- Определенный ресурс для каждой команды, исходя из ее потребности
- Разделение доступов до логов и метрик, что бы не было общей помойки
С этими базовыми вещами для каждой команды сможем выделять изоированный кусок общей инфры, так что бы они не мешали друг другу)
👍1
TMP
Сейчас пишу шаблоны пайплайнов для нового проекта. Там по классике несколько микросервисов которые нужно выкатить.
Люблю новые проекты, там можно сразу применить весь свой опыт и сразу сделать хорошо)
Пока реализовал уже два шаблонных шага:
- Билд jar файла
- Билд и паблиш образа с этим jar файлом
Делаю максимально униврсальные стейджи пайплайна которые можно просто импортировать в проект и оно само поедет)
Сейчас пишу шаблоны пайплайнов для нового проекта. Там по классике несколько микросервисов которые нужно выкатить.
Люблю новые проекты, там можно сразу применить весь свой опыт и сразу сделать хорошо)
Пока реализовал уже два шаблонных шага:
- Билд jar файла
- Билд и паблиш образа с этим jar файлом
Делаю максимально униврсальные стейджи пайплайна которые можно просто импортировать в проект и оно само поедет)
👍2
TEAM
Ща собираем стенд для одного проекта. И это один из редких опытов когда нас на проекте двое девопсов.
Процесс мы выстроили таким образом: Раз в какое то время синкуемся с командой разработки и понимаем глобальную задачу. Создали борду где нарезаем большие задачи на небольшие, из разряда "написать шаблон чарта", "поднять кластер", "написать джобу сборок".
Нарезаем задачи таким образом что бы не блокировать друг друга и можно было делать их в любом порядке.
Ну и что то около кросс ревью, когда смотрим задачи друг друга)
Это редкий момент когда можно так поработать, а не как обычно в одиночку)
Ща собираем стенд для одного проекта. И это один из редких опытов когда нас на проекте двое девопсов.
Процесс мы выстроили таким образом: Раз в какое то время синкуемся с командой разработки и понимаем глобальную задачу. Создали борду где нарезаем большие задачи на небольшие, из разряда "написать шаблон чарта", "поднять кластер", "написать джобу сборок".
Нарезаем задачи таким образом что бы не блокировать друг друга и можно было делать их в любом порядке.
Ну и что то около кросс ревью, когда смотрим задачи друг друга)
Это редкий момент когда можно так поработать, а не как обычно в одиночку)
👍2
NET
Кратенько о том как я настраиваю сетевые политики для нод кластера, для яндекс клауда:
1. Все ноды без белого IP
2. Разрешение всего инпута в контексте локальной сети
3. Вес аутпут через дефолтный nat клауда
4. Все ноды в свое изолированной сети
Это позволяет пускать трафик на ингрес через сетевой балансер и нормально взаимодействовать всем компонентам кластера. Ну и учитывая что это изолированная локалка к самим нодам напрямую никто не сможет обратится, только через апи и по правилам сетевого балансера.
Такой подход дает приемлимый уровень безопасности и позволяет не сильно усложнять сетевые политики)
Кратенько о том как я настраиваю сетевые политики для нод кластера, для яндекс клауда:
1. Все ноды без белого IP
2. Разрешение всего инпута в контексте локальной сети
3. Вес аутпут через дефолтный nat клауда
4. Все ноды в свое изолированной сети
Это позволяет пускать трафик на ингрес через сетевой балансер и нормально взаимодействовать всем компонентам кластера. Ну и учитывая что это изолированная локалка к самим нодам напрямую никто не сможет обратится, только через апи и по правилам сетевого балансера.
Такой подход дает приемлимый уровень безопасности и позволяет не сильно усложнять сетевые политики)
👍1
WALL
Один из способов защиты от DDOS атак это делегирование защиты на специализированные системы.
Как пример можно взять cloudflare. По сути защита там реализованная как обычный балансировщик нагрузки, мы просто включаем DNS в режими проксирования и весь трафик к нашему сайту будет идти сначала через cloudflare.
В базовой версии они берут на себя защиту от DDOS и подобых атак.
Что важно понимать при настройке: cloudflare ставит свой ssl сертификат который отдает пользователям, и по дефолту шлет запросы в нашу систему по http. Что бы настроить ssl между cloudflare и нами нужно для начала сделать сами серты и потом включить настройку ssl full уже на cloudflare.
Один из способов защиты от DDOS атак это делегирование защиты на специализированные системы.
Как пример можно взять cloudflare. По сути защита там реализованная как обычный балансировщик нагрузки, мы просто включаем DNS в режими проксирования и весь трафик к нашему сайту будет идти сначала через cloudflare.
В базовой версии они берут на себя защиту от DDOS и подобых атак.
Что важно понимать при настройке: cloudflare ставит свой ssl сертификат который отдает пользователям, и по дефолту шлет запросы в нашу систему по http. Что бы настроить ssl между cloudflare и нами нужно для начала сделать сами серты и потом включить настройку ssl full уже на cloudflare.
👍1
PROD
Что в идеале надо настраивать на прод стенде, после того как сам проект релизится туда из теста:
- Отключаем дебаг
- Отключаем свагер, актуатор и прочие вещи связанные с разработкой
- Наружу открываем только реально нужные порты, чаще только 80 и 443
- Убеждаемся что наружу не торчит какой то левый урл
Важно понимать, что все что мы делаем ради удобства тестирования и разработки может стать поверхностью атаки на проде)
Что в идеале надо настраивать на прод стенде, после того как сам проект релизится туда из теста:
- Отключаем дебаг
- Отключаем свагер, актуатор и прочие вещи связанные с разработкой
- Наружу открываем только реально нужные порты, чаще только 80 и 443
- Убеждаемся что наружу не торчит какой то левый урл
Важно понимать, что все что мы делаем ради удобства тестирования и разработки может стать поверхностью атаки на проде)
👍1
JUMP
Ssh over jump сервер. Это один из способов тунелирования ссш трафика.
Допусти у нас есть один сервер с внешним ip, к которому у нас есть доступ, и куча серверов внутри сети без прямого доступа с локальной машины.
Допустим мы хотим попасть на сервер из этой внутренней сети. Как это можно решить:
По сути одним простым конфиг файлом для ssh.
Дальше просто подрубаемся так:
Таким образом трафик сначала пойдет на external-host и оттуда уже на internal_host.
Ssh over jump сервер. Это один из способов тунелирования ссш трафика.
Допусти у нас есть один сервер с внешним ip, к которому у нас есть доступ, и куча серверов внутри сети без прямого доступа с локальной машины.
Допустим мы хотим попасть на сервер из этой внутренней сети. Как это можно решить:
По сути одним простым конфиг файлом для ssh.
Host external-host
HostName some_ip
User root
Host internal_host
HostName some_ip
User ops
ProxyJump external-host
Дальше просто подрубаемся так:
ssh internal_host
Таким образом трафик сначала пойдет на external-host и оттуда уже на internal_host.
👍1
BILING
Про неочевидные траты в клауде.
Иногда забывается - в клауде мы платим не только за сами ресурсы но и за операции. Например в S3 бакете мы платим не только за пространство, но и за PUT/GET операции. Проблема в том что из за этого может вырасти расход, даже при небольшом количество данных.
Например какой либо сервис при мисконфигуре может разогнаться и начать слать тысячи запросов к бакету, и по итогу мы будем оплачивать все. Да, одна операция почти ничего не стоит, но если их тысячи в секунду и длиться несколько часов то сумма может выйти большой.
Про неочевидные траты в клауде.
Иногда забывается - в клауде мы платим не только за сами ресурсы но и за операции. Например в S3 бакете мы платим не только за пространство, но и за PUT/GET операции. Проблема в том что из за этого может вырасти расход, даже при небольшом количество данных.
Например какой либо сервис при мисконфигуре может разогнаться и начать слать тысячи запросов к бакету, и по итогу мы будем оплачивать все. Да, одна операция почти ничего не стоит, но если их тысячи в секунду и длиться несколько часов то сумма может выйти большой.
👍1
TMP
Допустим у нас есть несколько одинаковых джоб в гитлабе, допустим для деплоя на разные стенды. Как это сделать красивее? Сделать шаблон и завязываться на него, просто конфгурируя.
Как пример:
Тут мы сделали общий шаблон .deploy, где есть вся общая настройки джобы и мы завязываемся на него через extends. Удобно и красиво)
Допустим у нас есть несколько одинаковых джоб в гитлабе, допустим для деплоя на разные стенды. Как это сделать красивее? Сделать шаблон и завязываться на него, просто конфгурируя.
Как пример:
.deploy:
stage: deploy
image: docker:19.03.8-dind
script:
- ./deploy.sh
tags:
- docker
environment:
name: $CI_COMMIT_BRANCH
deploy_prod:
extends: .deploy
variables:
BRANCH: master
HOST: prod
only:
- master
deploy_dev:
extends: .deploy
variables:
BRANCH: dev
HOST: dev
only:
- dev
Тут мы сделали общий шаблон .deploy, где есть вся общая настройки джобы и мы завязываемся на него через extends. Удобно и красиво)
👍2
SSDLC
Не самая очевидная мысль - жизненный цикл кода заканчивается когда его удаляют с прода.
Из этого следует что безопасность надо проверять не только на этапе разработки но и на проде. Но тут есть хитрый трюк)
Когда мы разрабатываем новые фичи то по пайплайну проходит вообще весь код прложения, и сканировать можно прям вообще все приложение а не только изменения. Таким образом мы проверяем и то что сейчас на проде.
НО, это не отменяет того что на проде может быть легаси которые мы не обновляем, и соотвественно по пайплайну с проверками этот код не проходит. Поэтому от проверок всего прода мы не уйдем, просто трюк с проверкой всего при разработке делает уже сильно лучше)
Не самая очевидная мысль - жизненный цикл кода заканчивается когда его удаляют с прода.
Из этого следует что безопасность надо проверять не только на этапе разработки но и на проде. Но тут есть хитрый трюк)
Когда мы разрабатываем новые фичи то по пайплайну проходит вообще весь код прложения, и сканировать можно прям вообще все приложение а не только изменения. Таким образом мы проверяем и то что сейчас на проде.
НО, это не отменяет того что на проде может быть легаси которые мы не обновляем, и соотвественно по пайплайну с проверками этот код не проходит. Поэтому от проверок всего прода мы не уйдем, просто трюк с проверкой всего при разработке делает уже сильно лучше)
👍1
GITLAB
Хочется немного пожаловаться на систему бекапирования гитлаба.
Сделать полноценный бекап можно только через встроенный механизм гитлаба - gitlab-backup create. И как он работает:
- Создает архивы с дампом всех компонентов по отдельности
- Все эти бекапы формирует в один большой архив
То есть по сути если у нас все данные гитлаба веся 250гб то сначала создаться несколько больших файлов гигов на 200 и потом они сохраняться в один большой файл на те же 200гб. Итого нам надо что бы диск машины был хотя бы гигов в 700.
Это довольно неудачное решение как по мне, так как придется постоянно держать диск занятым не более чем на треть, и платить за 2/3 диска которые почти все время будут простаивать.
Да, в этом есть логика, возможно дробить дампы по компонентам в чем то удобнее, но с точки зрения потребления места это очень больно.
Хочется немного пожаловаться на систему бекапирования гитлаба.
Сделать полноценный бекап можно только через встроенный механизм гитлаба - gitlab-backup create. И как он работает:
- Создает архивы с дампом всех компонентов по отдельности
- Все эти бекапы формирует в один большой архив
То есть по сути если у нас все данные гитлаба веся 250гб то сначала создаться несколько больших файлов гигов на 200 и потом они сохраняться в один большой файл на те же 200гб. Итого нам надо что бы диск машины был хотя бы гигов в 700.
Это довольно неудачное решение как по мне, так как придется постоянно держать диск занятым не более чем на треть, и платить за 2/3 диска которые почти все время будут простаивать.
Да, в этом есть логика, возможно дробить дампы по компонентам в чем то удобнее, но с точки зрения потребления места это очень больно.
👍1
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