JUMP

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.

BILING

Про неочевидные траты в клауде.
Иногда забывается - в клауде мы платим не только за сами ресурсы но и за операции. Например в S3 бакете мы платим не только за пространство, но и за PUT/GET операции. Проблема в том что из за этого может вырасти расход, даже при небольшом количество данных.
Например какой либо сервис при мисконфигуре может разогнаться и начать слать тысячи запросов к бакету, и по итогу мы будем оплачивать все. Да, одна операция почти ничего не стоит, но если их тысячи в секунду и длиться несколько часов то сумма может выйти большой.

TMP

Допустим у нас есть несколько одинаковых джоб в гитлабе, допустим для деплоя на разные стенды. Как это сделать красивее? Сделать шаблон и завязываться на него, просто конфгурируя.
Как пример:

.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. Удобно и красиво)

SSDLC

Не самая очевидная мысль - жизненный цикл кода заканчивается когда его удаляют с прода.
Из этого следует что безопасность надо проверять не только на этапе разработки но и на проде. Но тут есть хитрый трюк)
Когда мы разрабатываем новые фичи то по пайплайну проходит вообще весь код прложения, и сканировать можно прям вообще все приложение а не только изменения. Таким образом мы проверяем и то что сейчас на проде.
НО, это не отменяет того что на проде может быть легаси которые мы не обновляем, и соотвественно по пайплайну с проверками этот код не проходит. Поэтому от проверок всего прода мы не уйдем, просто трюк с проверкой всего при разработке делает уже сильно лучше)

GITLAB

Хочется немного пожаловаться на систему бекапирования гитлаба.
Сделать полноценный бекап можно только через встроенный механизм гитлаба - gitlab-backup create. И как он работает:
- Создает архивы с дампом всех компонентов по отдельности
- Все эти бекапы формирует в один большой архив
То есть по сути если у нас все данные гитлаба веся 250гб то сначала создаться несколько больших файлов гигов на 200 и потом они сохраняться в один большой файл на те же 200гб. Итого нам надо что бы диск машины был хотя бы гигов в 700.
Это довольно неудачное решение как по мне, так как придется постоянно держать диск занятым не более чем на треть, и платить за 2/3 диска которые почти все время будут простаивать.
Да, в этом есть логика, возможно дробить дампы по компонентам в чем то удобнее, но с точки зрения потребления места это очень больно.

GITLAB

Сейчас занимаюсь переездом с одного инстанса гитлаба на другой, с новым доменом и полностью новой инфрой.
Какие основные сложности могут возникнуть:
- Диск. Тот же прикол что и с бекапированием, о котором вчера писал, с рестром бекапа та же история
- Конфигурация. Для того что бы все нормально переехало нужно воссоздать конфигурацию на 100 процентов такую же как на старом гитлабе
- Время. Большую часть времени ты просто ждешь, спустя пару часов может просто появится ошибка, и придется все делать с начала
- Раннеры. После рестора почти гарантировано придется делать новые раннеры
- Домены. Тут могут возникнуть проблемы в CI/CD если не была заявязка на переменные с адресами

В остальном, это хорошее время что бы взять техработы и настроить все как надо)

FRONT

Сейчас появляется модный паттерн проектирования фронтенда - микрофронты.
Логика тут в целом как и на бекенде, максимадно разделяем функциональность по разным приложениям. В контексте фронта у нас есть какой то основной индекс, который делает запросы на разные фронтовые ресурсы, а мы уже роутим эти запросы на нужные микрофронты.
Под копотом у таких фронтов может быть что угодно, хоть ssr на ноде хоть просто статика на nginx.
Логика тут такая же как и на беке:
- Распределение нагрузки
- Скейл только нужной функциональности
- Отказоустойчивость
На практике пока очень редко это видел. Но все больше обсуждается такой подход)

PUBLIC

В рамках контура разработки проекты мы можем делать свои public докер образы.
У нас может быть много системных образов, например базовые для сборок, деплоя, тестирования. И иногда больно каждый раз авторизовываться в регистри ради них, особенно на разных серверах.
Поэтому нормальной практикой будет сделать регистри блоб в своей сети, где эти образы будут публичными на чтение. А изменять их только с нужными правами и авториацией.
Тут главное правило - делать эти образы максимально чистыми. Там не должно быть ничего сенсетив типа кред, каких то секретных сертов и ключей. Просто системные образы с нужными зависимостями. Тогда это будет безопасно)

FREEZE

Впереди длинные выходные. Хочется поговорить про то как готовится к ним.
По хорошему, если мы разрабатываем и поддерживаем прод системы то перед праздниками лучшей идеей будет код фриз.
По сути это момент когда мы за недели две до праздников стопаем релизы в прод. Это поможет нам оставить систему в точно стабильно состоянии и уменьшить вероятность инцидентов. Ведь риск очень большой, в праздники не всегда возможно выдернуть нужных людей которые будут фиксить инциденты.
Мониторинг. Повезло если есть статистики на праздничные дни за несколько лет. Это поможет спрогнозировать нагрузку и заранее отмасштабировать систему.
Ну и техдолг. Если есть проблемы которые влияют на стабильность прода то хорошо бы их решить заранее)

Всех с наступающим, желаю стабильно прода и минимум инцидентов)

SHOW SERVER

Про сервера снежинки.
Это конечно не прям термин из компьютер сайнс, это скорее мемное выражение. Так называют сервера которые могут упасть у каждого чиха и никто уже их не поднимет.
Часто это бывает когда у нас есть один большой сервер в который пихается вообще все, от сайта и хранилища до 1С. Часто такие системы настраивают руками, и количество компонентов там может накапливаться годами. Плюс проблема в том что делает это несколько поколений админов.
Что тут можно пойти не так? По моему очевидно что если установить или обновить какой то один компонент на этом сервере то это может задеть все остальное и мы уже ничего не востоновим.
Как исправить? Ну лучше этого совсем не допускать. Распредлеять компоненты по небольшим серверам и поднимать их декларативно, с максимально автоматизацией и переносимостью. Тут основная проблема в ручных дейтвиях.
Но если этот сервер уже появился то можно потихоньку распиливать его и делать как описано выше)

MIGRATE

Сегодня переносил один из прод серверов.
Смысл был в том что бы максимально просто и безболезненно обновится но новой версии убунты. И в тему прошлого поста, этот переезд был максимально быстрым и безболезненным:
- Поднял новый сервер с нужной версией убунты
- Сделал базовую настройку
- Накатил приложеньку через CI/CD
- Переключил трафик
На все про все не больше 10 минут)
Такой автоматизированный шаблонный процесс настройки систем позволяет нам довольно быстро прыгать между разными серверами и клаудами)

По моему лучшая социальная реклама)

FEDORA

Те кто внимательно читает мой канал могли заметить - я очень люблю fedora. Я все еще считаю его лучшим дистрибутивом линукса.
Но в работе почти в 100 процентах случаев использую серверную убунту. Есть много факторов почему так сложилось, наверно главный в том что это стандарт для сферы где я работаю.
Но когда возникает возможность поэкспериментировать я стараюсь ставить на сервера последнюю федору. Как сегодня, мне надо было поднять сервер с loki для хранения логов, и решил делать это на 37 федоре. Из того от чего я отвык при пользовании убунты - быстрый пакетный менеджер, отсутствие лишних пакетов, отзывчивость системы)
Вообщем буду продолжать экспериментировать по возможности, ставя самые последние версии)

Офигенный меседж при переходе в рут в федоре)

CLOUD INIT

По сути система конфигурации. В облаках, когда мы выбираем ось, то ее образ не собирается под нас а просто подтягивается шаблонный. Но когда мы конфижим машину в интерфейсе (или где то еще) то мы выбираем разные параметры типа:
- Имя машины
- Пользователи
- Добавляем ключи
- Делаем какие то настройки сети
Cloud init дает нам возможность при первом запуске получить такую машину которую мы сконфижили. По сути это простой yaml манифест с описанием настроек машины и интерпритатор написанный на питоне, который парсит и применяет этот манифест. И по итогу мы получаем такую машину как мы хотим из шаблонного образа операционки.
Большенство задач которые описаны в этом манифесте выполняются только при первом запуске. Но некоторые могут запускаться и после ребута, по сути мы можем добавлять их в манифест уже после создания машины.

По логике это очень похоже на ansible, просто специализированный именно под первоначальную настройку в клауде и сильно проще)

FLOW

Думаю важно понимать - нет какого то определенного правильного гит флоу в разработке.
Наверно можно сказать что есть самые поулярные вариант типа:
feature-N -> dev -> test -> main -> tag
Но это не прибито гвоздями. Каждая команда может сама решать как удобно. Например у меня на одном из проектов все фичи сливаются в main ветку, откуда катится на дев стенд, и уже с main создается продный тег, и всем удобно)
Сложные флоу нужны там где есть много разработчиков и множество стендов, но и там можно сделать попроще.
Гибкие методологии разработки на то и гибкие, что позволяют нам делать удобно конкретно для нас)

INTERPRETATION

Современные инструменты конфигурирования и инфраструктуры как кода часто представляют из себя интерпретаторы.
Нам предоставляется определенный синтаксис, чаще всего на yaml. И сам инструмент парсит его, проверят синтаксис на коректность и по своей логике выполняет сам манифест. Да, это не прям стандартный интерпритатор как у питона, где идет пошаговая jit компиляция и выполнение, это что то похожее на интерпретацию dsl.
Но понимание что это просто интерпретация манифеста дает нам понимание как правильно встраивать новые модули, например в ансибл. По сути мы просто обьявляем новые директивы в синтаксис манифеста и исполняем определенные инструкции если нашли их)

SYSTEMD

После загрузки ядра линукса нам нужно поднят всю остальную систему, которая может состоять из множества компонентов.
Для этого сейчас, чаще всего, используется systemd. По сути это набор манифестов и рантайм который позволяет поднять все так как нам нужно. Там описывается:
- Путь до компонента
- Политика старта/рестарта
- Пользователь
- Рабочая директория
И множество других полезных директив.
После загрузки ядро передает управление в systemd и он уже поднимает все в нужном порядке.
Раньше в большенстве дистрибутивов использовался init. Но его основной минус в том что он запускает все поочередно и имеет менее гибкую настройку. В то время как systemd может запускать все паралельно и имеет большой уровень кастомизации

ASISTENT

Яндекс клауд выкатил превью версию AI асистента.
Пока это бесплатная версия которая не так много умеет, но уже дает прикольные возможности. Например сегодня я описал ему что мне нужна группа безопасности с определенными правилами, он спроектировал ее и спросил можно ли ее создать, я апрувнул и он ее сделал. И еще сейчас с его помощью провожу ревизию клауда, что бы вытащить все ресурсы которые не используются либо используются не на полную.
Пока что он ограничен, например он не может снять метрики с managed постгри. Но уже может по mcp цепляться к кубу.
Думаю за этим определенное будущее, и в какой то мере замена саппорта клауда)

LAMBDA

Некоторые клауды предоставляют услуги безсерверных вычислений. Часто это называется lambda функциями.
Суть состоит в том что мы просто закидываем свой код в специальную систему, и когда туда приходит запрос то просто происходит само вычесление этого кода с пришедшими данными. Смысл тут в том что мы платим только за тот компьют который использовали, это выгодна когда нужно поднять что то что будет очень редко вызыватьяс.
Из минусов:
- Долгий ответ, так как код не всегда запущен а поднимается только при вызове
- Нет прозрачности, мы не контролируем то где код запускается
- Сложность, что бы все верно настроить нужна большая экспертиза в конкретном клауде
Ну и мне никогда не нравился термин "безсерверные вычисления", как по мне куда уместнее называть это "облачные вычисления", так как это просто функция облака которая запускается на серверах)

И кстати, по концепции чем то схоже с lambda функциями в программировании, концептуально это просто функция которая зависит только от входных параметров и отдает определенный результат)

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

На этом все, при следующем логине система попросит нас ввести пароль и код)