Из знания теории вам точно понадобятся:
понимание  что такое и как работает VLAN.
Как работает TCP, iSCSI,DNS и FCP.
Что такое SCSI MPIO, что такое round-robin в MPIO.
Сети и дисковая подсистема, это очень больные места у новичков.
Конечно, нужны базовые знания по Linux – начиная от того, что такое ext4 и чем это отличается от LVM, ZFS и BTRFS . И что из этого вам нужно, а что нет.
Бонусом желательно понимать, что такое MS AD и Kerberos. Потому что авторизация на основе SSH сертификатов, открытого и закрытого ключа, это хорошо, и это база из баз, но Kerberos лучше. Когда освоите MS AD / Kerberos, сможете перейти на keycloak.

Окей, поехали.

Для начала, если вы, как я, генерировали SSH пару через Puttygen, то не забудьте что под Windows ключ нужно копировать вручную, или выдергивать со сменой формата из public, и отдельно отредактировать /etc/ssh/sshd_config.
Ну, если вдруг забыли. Я забыл.

Потом, если вам скучно, как мне, то сделайте
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=fiotest --filename=testfio --bs=4k --iodepth=64 --size=8G --readwrite=randrw --rwmixread=75

Заодно посмотриту, как hyper-v работает с дисками изнутри Linux. У меня вышло 270:90, результат ни о чем, при параметре size=8G, меньше размера оперативной памяти.

Git в Docker. Тут все просто, открываем Install using the apt repository и делаем хорошо.
Открываем Install GitLab in a Docker container и делаем. До просветления. В том числе до Configure the external URL for GitLab. И так вплоть до
docker exec -it gitlab /bin/bash
cat /etc/gitlab/initial_root_password

За чаем можно и нужно почитать про Sonatype Nexus Repository. Скучное, но полезное чтение.
Еще более скучное, чем Sonatype Nexus Repository System Requirements.
Или можно не читать,
mkdir -p /srv/nexus-data
chown -R 200 /srv/nexus-data

Про chown вообще не очевидно было, в документации и почти во всех примерах не нашел пункта про chown, а без него грусть, тоска, и невозможность создать файл, что видно хоть через
docker compose logs
хоть через
docker logs (ContainerName), если вы делаете через docker up

Причем docker exec -it nexus3 /bin/bash
не помогает понять, что там не так.

Потом переходим к чтению документации по Ansible, Installing Ansible on specific operating systems.
Или без чтения,
apt-get install ansible
и что в репозиторий насовали, то насовали.

Литература
Introduction to Ansible Builder
Running Ansible Server in Docker Container
Chapter 9. Configuring RAID logical volumes  by using logical volume manager (LVM)
DockerCheatSheet
docker-nginx-nexus-repository
Docker Compose Quickstart
Установка Sonatype Nexus OSS v3 в контейнере Docker
Установка и настройка Nexus Sonatype используя подход infrastructure as code
Install Sonatype Nexus using Docker Compose | Setup Nexus Repository Manager for Node.js Project
Mounting volume from host to docker image of nexus
Deploy Sonatype Nexus Repository OSS v3 with Docker & Traefik v2
Установка приватного Docker репозитория

PS. У меня вышло так: (с хардкодом, не по примеру из руководства)
gitl/docker-compose.yml

services:
gitlab:
image: gitlab/gitlab-ce:latest
container_name: gitlab
restart: always
hostname: 'gitlab.example.com'

environment:
GITLAB_OMNIBUS_CONFIG: 
# Add any other gitlab.rb configuration here, each on its own line
external_url 'https://gitlab.example.com'

ports:
- '80:80'
- '443:443'
- '22:22'

volumes:
- '/srv/gitlab/config:/etc/gitlab'
- '/srv/gitlab/logs:/var/log/gitlab'
- '/srv/gitlab/data:/var/opt/gitlab'

shm_size: '256m'

nexus/docker-compose.yml

services:
nexus-repository:
image: sonatype/nexus3
container_name: nexus3
restart: always
hostname: 'nexus3.local.tw'

ports:
- '8081:8081'

volumes:
- '/srv/nexus-data:/nexus-data'

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

За последний месяц ко мне поступило несколько запросов расширить функционал бота за счёт подключения новых источников трафика. Изначально я думал добавить интеграции с популярными мессенджерами, такими как WhatsApp или Viber. Но в итоге решил, что в первую очередь стоит реализовать API, чтобы вы сами могли подключать любые свои источники.

В этой статье расскажу о новом API для подключения внешних источников — живых чатов, CRM и других систем, а также о других важных обновлениях и планах на будущее.

Предисловие

Для тех, кто не знаком с проектом: TG Support Bot — это бот на Laravel, который объединяет клиентов и менеджеров через Telegram и ВКонтакте, скрывая личные аккаунты и маршрутизируя общение через темы в Telegram-группе.

https://github.com/prog-time/tg-support-bot

Пользователь пишет боту, сообщение автоматически пересылается в выделенную тему для менеджеров, а их ответы возвращаются обратно от имени бота — так сохраняется приватность и удобство общения.

Буду благодарен, если вы поддержите мой проект ⭐ на GitHub!

Руководство по установки

Я записал видео-инструкцию для установки данного решения на VPS с предустановленным Docker Compose.

Youtube - https://youtu.be/yNiNtFWOF2w

Rutube - https://rutube.ru/video/bdd0cc5ab4e13530fd7e0c2413931211/

ВК Видео - https://vkvideo.ru/video-141526561_456239132

Обратная связь

Для улучшения коммуникации с пользователями, я создал группу в Telegram, в которой вы можете задавать свои вопросы и писать предложения по расширению функционала.

https://t.me/pt_tg_support

Также сюда будут публиковаться новости по выпуску обновлений.

API — не альтернатива мессенджерам, а универсальный инструмент

Хочу сразу уточнить: разработка API не заменяет расширение списка поддерживаемых мессенджеров и соцсетей. Я продолжаю работать над интеграциями с ними и буду добавлять новые источники трафика.

Однако API необходим для подключения кастомных источников — живых чатов, CRM-систем, форм на сайте и других нестандартных каналов.

Что входит в первую версию API?

В API реализованы базовые маршруты для работы с сообщениями:

• GET api/external/messages — получение списка сообщений с возможностью фильтрации

• GET api/external/messages/{id_message} — получение конкретного сообщения по ID

• POST api/external/messages — отправка нового сообщения

• PUT api/external/messages — изменение существующего сообщения

• DELETE api/external/messages — удаление сообщения

Для работы с API необходимо создать пользователя и сгенерировать для него API-токен. Рекомендую создавать отдельного пользователя под каждый источник.

Создать пользователя и токен можно командой:

Также нужно прикрепить к источнику ресурс, куда будут поступать сообщения от обработчика.

Как это работает?

Процесс довольно простой:

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

2. При отправке сообщения в тело запроса передаются: ID пользователя, код источника, текст сообщения и, при необходимости, файлы.

3. Система идентифицирует пользователя или создаёт новую запись, если это первое сообщение от него.

4. Сообщение из вашего источника направляется в Telegram-группу поддержки.

Менеджеры в группе, как и раньше, могут отвечать любыми типами сообщений. Текст отправляется как текст, остальные — конвертируются в файлы. В названии темы указывается ID клиента и источник сообщения.

Таким образом, вы легко сможете подключить практически любой внешний источник к вашему боту.

Подробная инструкция по работе с API уже есть в разделе wiki на GitHub.

Добавлены новые консольные команды

Я добавил несколько полезных консольных команд.

php artisan telegram:set-webhook

Artisan команда, которая производит подключения хука бота к вашему проекту. Ранее это делалось через отправку запроса в telegram или по специальной ссылке, а теперь это можно сделать запустив команду в консоле.

php artisan app:generate-token

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

Swagger для API

Для API был разработан генератор swagger документа.

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

Принцип прост! Вы описываете документацию по частям в resources/swagger. Важно граматно подходить к именованию файлов и компонентов.

После создания структуры, вы запускаете artisan команду и документация собирается в единый документ.

На выходе вы получаете 2 версии документации

1. В формате json, которую можно использовать для нейросетей или программ

2. В формате Swagger-ui для просмотра в браузере

Мелкие доработки

• Улучшено логирование ошибок — все логи теперь доступны в Grafana;

• Исправил баги, о которых вы писали в Issues;

• Добавил контейнер redisinsight для просмотра Redis данных через WEB интерфейс;

• Переписал инструкции для подключения и настройки бота;

Спасибо всем за поддержку и обратную связь! Продолжаю работать над улучшениями и буду рад новым предложениям и вопросам.

Если нужно, могу помочь с примерами использования API или подсказать, как правильно настроить интеграцию.

В моём случае будем использовать NAS xpenology.

1. Ставим Container Manager

2. Открываем установленный Container Manager в разделе "Реестр" пишем immisterio/lampac. Далее выбираем latest и загрузить.

3. Переходим в раздел "Образ", выбираем его, нажимаем "Запустить".

4. Здесь ничего не трогаем, нажимаем "Далее"

5. Добавляем порт 9118, больше ничего не трогаем. Нажимаем "Далее".

6. Нажимаем "Выполнено".

7. Переходим в раздел "Контейнер" и здесь появится созданный контейнер.

На этом можно закончить, не будем углубляться в настройки для красноглазиков.

8. Открываем браузер (ip вашего сервера), например http://192.168.1.111:9118 появится окно первого запуска. Нажимаем "Изменить настройки".

9. Теперь берём клубничный смузи и переходим к этапу настройки на Apple TV. Открываем стор и пишем lux. Выбираем приложение с рыбкой.

10. При запуске появится это, подтверждаем.

11. Здесь вводим наш адрес сервера, например: http://192.168.1.111:9118

12. Попадаем в главный экран.

13. Выбираем любой фильм, нажимаем "Смотреть"

14. Здесь "Торренты"

15. Выбираем раздачу

16. Подтверждаем

17. Готово, наслаждаемся фильмом.

Настроить TorrServe можно через http://192.168.1.111:9118/ts например, увеличить кеш.

Подобным образом можно запустить докер контейнер на ПК. Ничего настраивать не нужно. Всё работает бесплатно без СМС и рекламы.

P.S. Да, я знаю про андроид приставки и что там можно это всё запустить и держать локально, по стоимости Apple TV их можно купить ящик. Но есть причины почему я избавился от андроид приставки, а это невозможно в них вывести звук на 2 пары блютус наушников или выводить нормальную HDR картинку без шаманств.

Что касается Unix и FreeBSD, то они где-то, безусловно, есть. В виде той же доживающей HP-UX 11i v3 – EoL 31 декабря 2025 года.

Что же касается фирм, то:
Microsoft разработала свой Azure Linux, и переезжает на него везде, где можно, вместе умершего, и вернувшегося с клатбища дистрибутивов, Centos.
Linux на телефоне существует в каком-то отдельном закутке, даже Huawei не стал ее тащить. HarmonyOS NEXT. – вообще не Linux, хотя openEuler еще как-то Linux, хотя LiteOS вроде и не Linux.
Red Hat был куплен IBM, теперь в эту нишу лезут корейцы с Naver, с их сборкой из OpenELA.
Если посмотреть на List of Linux distributions, то окажется, что осталось не так много веток:
Debian-based, в том числе Ubuntu-based,
«Импортозамещателям» на заметку. Торговой маркой Debian владеет фирма SPI (Software in the Public Interest ), зарегистрированная в штате Нью-Йорк, США).

Red Hat / RHEL / SUSE / openSUSE, Fedora,
ALT Linux,
И всякие «полезные в ограниченных сценариях» - DD-WRT, Alpine.

Само ядро Linux используется много где, с переменным успехом. Windows в схожих сценариях тоже вполне используется, в прошлом году я летал в Китай – там на турникетах в аэропорту стоит Windows 7 (embedded).
Отдельно отмечу кривые руки импортозаместителей, у которых нет представления о том, что под Linux не пишут код так же криво, как под Windows. Но они умудряются. Как следствие, все, покушавшие большой ложкой «импортозамещения», плачут, что больно каждый раз по новому.

За годы развития ряд продуктов, который должен был бороться со злом, примкнул к нему.

Часть продуктов просто остановилась в развитии. Багфикс и добавление еще одного слоя самоотвердевающего эко-био-френдли клея просто добавляют еще один слой клея.

Весь этот горький катаклизм, который я тут наблюдаю, представляет собой итог завершенного процесса доедания Злыми Корпоратами – маленького, но такого свободного сообщества. Движение есть, результат – прибыль корпораций растет, Злая Корпорация, Добрая Корпорация, и Еще Одна Корпорация – продают свободный продукт и его поддержку за дорого, и за очень дорого.

Итогом движения стало появление Linux эникея. Да, Linux эникей может поставить Ubuntu GUI, и даже запустить 1 (один) контейнер по руководству. Не сложнее, чем на телевизоре канал переключить, тем более что на телевизоре тот же Android, который, когда надо, Linux.

Следующая ветка развития ИТ, извращенная хитрым планом Архитектора Судеб – это devops.

DevOps is the integration and automation of the software development and information technology operations.

Изначально идея была понятна. Сложность ПО выросла, стало критично убирать самые большие баги до продакшена, и выделять не основную задачу, deploy – на отдельную ветку специалистов.
Но, работать с багами дорого. Та же VMware, даже пока была VMware, решила, что денег нет, поэтому будем тестировать на пользователях. Тащить непроверенное в прод, экономя на юнит тестах, автотестах, интеграции и ручном тестировании, это не российская традиция. Последними ударно выступили CrowdStrike, хотя и Microsoft выступает раз в квартал. Intel выступает так, что один финн постоянно орет, как потерпевший. Что в 2020, что в 2022, что в 2024. Как будто он что-то понимает.

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

Не тут то было. Дружба это магия, а несанкционированная магия это ересь.

Вся идеология девопс сравнительно быстро выродилась в массах в переименование middle Linux-администраторов, которых привлекали к чему угодно. Ansible, terraform, zabbix, ELK – devops. В последние лет, наверное, 5, тенденция называть любого Linux админа – девопсом, приняла в мире, да и в РФ, какие-то ужасающие масштабы. Конечно, этому способствовали и цыганские курсы

Следующим карго-культом, пришедшим в массы из мира весьма кровавенького энтерпрайза, стали микросервисы

Первый раз я эти микросервисы и конвейер – недоброкер видел еще в 2005 году, и тогда это называлось «костыли на костылях».

Дело, как мне кажется, в деньгах. Большой и действительно сложный монолит рано или поздно перерастает некую сложность кода, и становится сборищем костылей и велосипедов.

Возникает «новая свежая» идея: давайте сделаем Unix-way, много маленьких сервисов, каждый из которых выполняет одну маленькую задачу. Допустим, обслуживает десяток запросов от пользователей. И второй экземпляр сервиса обслуживает еще десяток. И все это за отказоустойчивым балансером. И все это утыкается в базу данных, которая 10 лет подряд дописывалась до того, чтобы ее планировщик оптимизировал кривые планы запросов, и мог сам балансировать очереди, соблюдая при этом ACID (Atomicity, Consistency, Isolation, Durability). Остались три мелочи: скорость, надежность балансировки, надежность и доступность базы данных

В некоторых сценариях не так важно, как быстро будет обработан запрос внутри системы, за 0.01 или за 0.05 секунды, потому что до потребителя ответ будет идти 0.1 -0.2 секунды. Как от меня до части облака в соседнем регионе.
В некоторых сценариях наоборот, рост с 0.01 до 0.02 секунд на каждом этапе обработки, замедляет работу в сотни раз. Почему так, спросите вы? Да потому, простая математика.
Допустим, у вас приложение формировало сетевой запрос к размещенной на этом же сервере базе данных. Скорость обработки, плюс минус, находится в том же порядке скоростей, что и обработка драйвера в оперативной памяти. Это 0.500 – 0.600 наносекунд, см. CAS latency .
Пользуясь случаем, в очередной раз хочу переделать привет любителям душить одноглазую змею при слове «импортозамещение на 350 нм литографе». Память SDRAM имеет Column address strobe latency в 10 ns, DDR SDRAM – в 3000-5000. DDR5 SDRAM – от 0.208 ns, разница не просто на порядки, а на десятки десятичных порядков. Потому что расстояние 30 нанометров волна проходит быстрее, чем 350, а ячейка размерами 90 на 90 нанометров заполняется в разы быстрее, чем ячейка 1050 на 1050 нанометров. Не только поэтому, конечно, но физика имеет значение. Хотя первое слово все равно приезжало через 22, а сейчас через 15, но восьмое слово приезжает не за 75, а за 11-15 ns.

Если сервис базы данных  уезжает на соседний хост, то и это не беда, но запрос теперь выполняется не 1-2 наносекунды, а на 500 – 600 наносекунд дольше, но все равно выполняется асинхронно (если приложение поддерживает асинхронность), и быстро. И то, на новых аристах обещают 3.95ns per hop и 150ns l3.  

И тут кто-то, как начальник того испанца из ролика (Хуан Хойя Борха) говорит: микросервисы.

Все делим, кладем и готово. Про задержки никто не думает, зачастую со словами «ну какие задержки, у нас 10G сеть, а не хватит 10G – соберем LAG и включим Jumbo frame».
Думать головой никто даже не пытается, путая пропускную способность и задержки. Теоретически, это связанные вещи, если говорить про передачу одного пакета в вакууме. Один пакет отправили, подтверждение получили, еще один пакет отправили.
Только это уже 25 лет не так. Уже 25 лет в TCP есть и TCP window scale, и TCP Retransmissions.
Можно очень бодро наступить на детские грабли того вида, что вносимая сетевая задержка при разнесении хостов, и даже вносимая задержка по перекладыванию данных в сетевой стек и обратно, вместо обработки их внутри алгоритмов и структур данных монолитного приложения, вносит задержки, делающие приложение неработоспособным, причем с нелинейным падением производительности. Нелинейное падение – это когда тестер нагружает приложение 100 потоками данных, и приложение работает за, условно, не более 0.1 секунды за поток. В боевых условиях набору микросервисов дают обработать 1000 потоков, и оно должно было бы работать за, хотя бы, 0.2 секунды, а оно работает за 2 секунды, и это очень много. Достаточно чтобы с треском весь набор упал. Потому что некоторые запросы, как оказалось, не асинхронные, а очень даже последовательные, и, пока 100 запросов работали в тесте по 0.01 секунды, было ок – потому что тестовая база и тестовый контейнер были в пределах одного сервера, или хотя бы одной стойки, и одного L2 сегмента. Как реальная база и контейнер уехали, хорошо если в пределы хотя бы одного ЦОД и пары соседних стоек. Но что будет, если у вас не просто метро, а очень длинное метро, или даже не метро, а MPLS, и внутри его еще и VPN ? А запросы, напомню, последовательные?
Отдельно надо рассматривать работу шины \ брокера, вносимые ей задержки и вообще применимость.
Иногда ок. Иногда сойдет. Иногда не годится.

В какой-то степени, иногда, это нивелируется тем, что и память стала работать быстрее, и сетевые карты стали умнее (и глючнее), и SSD перешли от SAS к NVME, и SSD перестали так ужасно тормозить, по сравнению с 3D XPoint (Optane). Иногда наоборот, иногда умелые ручки покупают самые дешевые домашние SSD, с их копеечными буферами, отсутствием защиты по питанию, и прошивкой без постоянной сборки мусора. Втыкают это все через Proxmox, в Proxmox через RAID, и получают, рано или поздно, отсутствие Background garbage collection и Write amplification такого приятного состояния, что око ужаса не просто сжимается, а может перекусить лом.

Проблема, как и 15-20 лет назад, не в девопс, линукс, опенсорс итд, а в том , что архитекторы часто стали забывать, что внизу, под фрейворками и контейнерами, все равно находится железо, и у него есть физические пределы. Некоторые вещи из физического мира все равно надо учитывать, хоть в облаке, хоть обвешавших NVME Kioxa Gen 666. И особенно, если у вас практикуется кроилово везде.

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

Культ Грефневой.
Ничего не буду писать.

Культ Шины.
Хорошо разобран на русском на примере Platfrom V Synapse.

Культ Кролика Убийцы, Rabbit of Caerbannog.

Вы знаете что делать – досчитать до трех.
Допреже всего Пресвятую Чеку извлечь долженствует. Опосля же того, сочти до трех, не более и не менее. Три есть цифирь, до коей счесть потребно, и сочтенья твои суть три. До четырех счесть не моги, паче же до двух, опричь токмо коли продолжишь до трех считать. О пяти и речи быть не может. Аще же достигнешь ты цифири три, что есть и пребудет третьею цифирью.
Книга Вооружения, часть четвертая, стих с 16 по 20.
Then did he raise on high the Holy Hand Grenade of Antioch, saying, "Bless this, O Lord, that with it thou mayst blow thine enemies to tiny bits, in thy mercy." And the people did rejoice and did feast upon the lambs and toads and tree-sloths and fruit-bats and orangutans and breakfast cereals ... Now did the Lord say, "First thou pullest the Holy Pin. Then thou must count to three. Three shall be the number of the counting and the number of the counting shall be three. Four shalt thou not count, neither shalt thou count two, excepting that thou then proceedeth to three. Five is right out. Once the number three, being the number of the counting, be reached, then lobbest thou the Holy Hand Grenade in the direction of thine foe, who, being naughty in my sight, shall snuff it."
A reading from the Book of Armaments, Chapter 4, Verses 16 to 20

Культ Запихивания Невпихуемого Statefull Монолита.
Культ настолько отвратителен, что про него ничего не будет в этой истории. Просто знайте, что он есть. Отличительный знак сторонников культа – медведь, собирающий грибы в лису.

Финал, то есть призыв.

Соблюдайте умеренность. Не надо все рубить на куски с криками «контейнеры для микросервисов, ноды к трону кубера».