DOCKER

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

DELIVERY

Про доствку до прода клиента.
Допустим мы сделали какое то приложение и хотим доставить его на сервера клиента. Есть несколько вариантов.

Простой:
Директория с кодом и скриптами. Клиент загружает ее на сервер, запускает скрипт который соберет образы и поднимет контейнеры через композ. Максимально просто, но подходит только если мы готовы показывать код.

Сложный:
Собираем образы с обфусцированным кодом. Клиенту даем чарт и разовый токен для нашего регистри. При поднятии прложение должно будет опрашивать нашу админку по специальным сертам, что бы иметь возможность работать.

RENDER

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

LLM

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

RULES

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

PVC

Как в современных клаудах работают вольюмы в кубе:
- Запрос на создание pvc в апи куба
- Запрос на создание сетевого топа в клауде от куба
- Поднятие пода которому нужен pvc
- Создание сетевого тома
- Маунт тома к ноде кластера
- Маунт директории пода к этому тому

Профит, мы можем сохранять данные из нашего пода в клаудном томе)

Давно не кидал музыку
Поэтому вот вам классика

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

FLOW

Сегодня немного погрумили релизный флоу разработки.
Пришли к чему то близкому к gitlab flow:
- main ветка как основная dev версия
- c main ветки катимся на dev стенд
- фича ветки берутся от main
- с main уходит релизную ветку
- с релизной ветки катим stage
- вливаем релизную ветку в prod ветку
- с prod ветки катимся в прод
- гасим релизную ветку

Главный принцип: минимум веток которые живут больше нескольких дней.
Да, выглядит замудренно, но если уложить это в голову то становится понятно и удобно)

OS

Операционная система это по сути набор софта.
В юникс мире есть четкое разделение на ядро и дистрибутив, и под операционными системами подразумивается как раз дистрибутив.
Что в него входит?
- Загрузчик, который поднимает ядро при старте
- Инит система, какой ни будь systemd который запускает окружение на ядре
- Файловая система, инструменты по работе с диском
- DE, который поднимается инит системой
- Предустановленный пользовательский софт
И под эту картину подпадают очень разные системы, от линукса и макоси, заканчивая андроидом и авесом. Глобально тут только винда придумывает свой путь, отсюда и такое отличие в логике взаимодействия.

CHIP

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

Чип так же может обращаться в свою изолированную память, и просто отдавать True/False, например для авторизации для биометрии.
Плюс минус классическая клиент серверная архитектура, только на более низком уровне)

ASIC

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

CPU

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

Небльшой оффтоп. Тут nvidia и шмайкрасофт выпустили новые arm процы и винду оптимизированную под него. Очень жду осени что бы посмотреть что получилось)

SOC

Системы на чипе очень неплохо подходят для локальных маделей.
Прикол в том что основные вычесления там проходят на GPU ядрах, и когда этим ядрам доступна общая RAM всего чипа то это сильно повышает доступный размер моделей. Если брать стандартные GPU которые стоят не миллионы рублей то больше чем 24гб памяти сложно найти. И поднять там модель на 120 миллиардов параметров там не выйдет.
А вот современные M процы от эпла, и новые чипы от nvidia решают эту проблему. Там на одном чипе спокойно может быть хоть 128гб памяти, и можно поместить довольно большие модели.

FRONT

Одна из сложностей в фронтенде это енв.
Часто переменки с настройками можно задать только при билде. И если нам нужно, например, изменить бекенд урл то обычно приходится пересобирать весь фронт.
Это можно обойти. Например указать в entrypoint разные скрипты которые при старте будут подбирать енв и заменять значения во всей статики. Но это очень больно и костыльно.

SSR это когда зумеры переизабрели php шаблоны

FLOW

Флоу разработки не говорит нам как и когда релизить.
Гит флоу, транк, гитлаб флоу и что угодно это по сути способ доставки изменений до прод вети или тега. В теории мы можем использовать любой флоу только с одним прод стендом и все. Ведь они не заставляют деплоить что либо.
Мы можем взять любой флоу и положить на него любой способ релизов и любые дев/тест стенды. Главное что бы было просто удобно)

SH

Шмайкрософт выпустила пакет для винды который расширяет cli юниксовыми командами.
Теперь на винде можно спокойно использовать ls, cp, grep и тд. Раньше для этого приходилось поднимать wcl, по сути почти вм с линукс ядром.
Ну чтож, ждем перехода на юниксовое ядро)

ENV

Цепочка доступа до переменных.
Как переменка из хранилища доходит до приложения на стенде в классическом случае:
- Переменка лежит в ci системе или вольте
- При деплое она подставляется в манифест
- Прокидывается в окружение контейнера
- Приложение подтягивает ее из окружения

Все это точки доступа для компромитации, слишком много мест где нужно строго контролировать доступ.

Пока самое сесурити решение:
- Переменная в вольте рядом с приложением
- Доступ к нему только у одного человека
- Приложение при старте само обращается к вольту и подбирает переменные
- Только приложение по фингерпринту моджет прочесть переменки

Это сильно уменьшает поверхность атаки.