TBD

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

Пару лет назад уже кидал сюда, но снова залип на концерты в Берлинской филармонии)

https://www.youtube.com/watch?v=GnyAgOWhMnk

Ну и как уж не закончить вечер на shortparis)
https://www.youtube.com/watch?v=IMRxAi8_xx0

DOCKER

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

Погнали)

FEDORA

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

DOCKER

В контексте контейниризации нам больше важно ядро а не сам дистрибутив.
Ведь она использует миханимы ядра, cgroups и неймспейсы. Тут весь остальной дистрибутив играет роль, но больше в контексте стабильности, что бы система просто не падала.
Поэтому мы можем быстро мигрировать контейнеры между дистрибутивами линукса, и идеале использовать минималистичные. Есть например fedora coreos, в которой нет почти ничего, кроме вещей нужных для контейнеров)
Для меня тут оснавная красота в том, что мы можем собрать образ в котором есть только бинарник и запустить его на системе в которой нет почти ничего кроме ядра. Очень минималистично)

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

Если что вот
https://www.youtube.com/watch?v=Wkl-lqf6ZU8&t

INFRA

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

AI

Есть тенденция на разработку эффективных федеративных систем обучения моделей.
Проблематика - не все хотят отдавать свои данные куда то во вне, но готовы что бы на них обучались модели. Тогда пригодится этот алгоритм, когда модель может обучаться одновременно в разных местах на разных данных и потом смерживаться в одну модель.
Это выглядит примерно так: Есть десятки компаний с данными, они ставят у себя ресурсы для обучения и запускают его. Результы обучения сваливаются в одно место и мержаться в одну модель.
Профит тут в безопасности данных (при правильном обучении) и распределенных вычислених.

FEDORA

Сегодня у меня небольшой челендж - просидеть весь день на федоре,
Пока успешно, поделал задачи и сейчас занимаюсь своими делами. Самое главное для меня - при грамотной настройке федора под гномом может быть максимально удобной для перехода с макоси. Очень близкий дизайн и флоу работы.
С прошлых моих эксперементов с федорой, пару лет назад, особо ничего не изменилось но стало просто чуть удобнее.
Из плюсов:
- Удобнее работать с файлами
- Реальный контроль над системой
- Один основной способ установки софта
- НАТИВНЫЙ ДОКЕР
Из минусов - сама железка. Все же макбук для меня это эталон как сама железяка)

Пересел за мак обратно)
Тактильно приятно, плавная работа и большая герцовка экрана. Что еще нужно для счастья?)

BOOT

Зачем нужны зашрузчики оси.
Затем что операционка может загружаться разными способами. Да, есть дефолтный путь где после биоса загружается ядро и потом сама система. В этом случае мы даже не замечаем загрузчик, просто нажимаем кнопку и система поднимается.
Но есть случаи когда у нас есть несколько вариантов ядер и варинтов загрузки. Тогда мы после загрузки биоса попадаем в загрузчик и выбираем способ загрузки системы.
Задача загрузчика по сути в том что бы правильно стартануть систему с нужными нам настройками. В линукс мире чаще всего используется grub. У него довольно гибка конфигурация которая позволяет писать разные флоу загрузки и подстраиваться под системы с множеством ядер и дистрибутивов.

WINDOWS

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

TRIAGE

В appsec есть такой процесс как триаж.
Он состоит в том что бы отрезать ложные срабатывания.
Например если сканер находит проблему с открытой переменкой с паролем, но это просто пример в ридми. Любой сканер сработает на это, покажет что это критичная уязвимость. Но все мы понимаем что это просто пример для разработчиков.
Поэтому при настройке процессов нужно отсекать такие находки. Что бы снизить количество шума и сделать процесс удобнее)

FILE TRANSFER

Для загрузки больших файлов в хранилища лучше использовать специализированные протоколы.
Напримре, если у нас есть бекап бд на 100-200гб то не стоит грузить его по http апи через curl. Он не предназначен для этого и будет падать чаще чем специализированный софт.
Тут можно использовать утилиты для работы с ftp и s3. Это все специально написанные протоколы для работы с файлами которые обеспечивают стабильную загрузку и отказоустойчивость.
Я сам сейчас, чаще всего, использую самописные скрипты которые грузят по s3 через boto3. Стабильно и довольно быстро)

DOCKER

Сегодня который раз убедился что не стоит использовать alpine.
Мы собираем образы на раннерах в кубере, и у него есть такое поведение что он маунтит в рантайм джобы свои ресурсы, типа сервисных акков.
И вот при сборке образов приложений мы обновляем его базовые зависимости (appsec, все тако) . В alpine пакетный менеджер при обновлении выполняет свои скрипты, и в ряде зависимостей эти скрипты пытаются обратится по пути ресурсов к которым примаунчены кубовые ресурсы. Тут и встает проблема, что они маунтятся как ридонли и не дают возможность делать что либо в директорияъ даже на уровень ниже.
Как я не воевал с этим, ничего не вышло. Пришлось переходить на базовые образы основанные на deb.
По итоге, эти новые образы нормально встали со всеми обновлениями и итоговый образ аналогичен по размеру)

TEST

Почему нет процесса тестирования задач девопсов обычными тестерами?
Оно есть, но косвенно.
Где могут возникнуть ошибки и как это отслеживается:
1. Не верный билд и деплой. Это будет заметно при тестировании функционала.
2. Открытые ресурсы которые должны быть закрыты. Сетевики и команда ИБ.
3. Отказоустойчивость и производительность. Нагрузочное тестирование.
4. Бекапы. Тут да, девопсы должны сами настраивать проверку.
5. Опасные изменения в релизном процессе. Для этого по процессу все проходит через дев/тест стенды.

То есть да, нет такого кто команда QA прям беерет тестить задачи девопсов. Но тестирование функционала и системы в целом покрывает тестирование наших задач)

APPSEC

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

Ну и продолжаю отправлять сюда клипы моей любимой Российской группы)

https://www.youtube.com/watch?v=8nXo65cd9Ck