Что потребуется: Любой домашний сервер или ПК с докером, Apple TV и приложение Luxo Video Player. На всё это уйдёт 10 минут времени. Вся информация предоставлена для образовательных целях.
Что получится в итоге? Личный сервер Lampa + TorrServe, на приставке смотрим фильмы без загрузки. Как это будет выглядеть:
Фото из проектора
В моём случае будем использовать NAS xpenology.
Ставим 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 картинку без шаманств.
Для лиги лени: Ничего не делать. Дурака учить — только портить.
Лет, наверное, 10-15 назад, давно – может в 2010, может в 2015, где-то в далекой-далекой галактике происходила очередная битва. Эпические сказания доносят до нас, хотя и в несколько нудноватой форме, величественную картину колоссальных сражений на пустом месте. Остались с той поры лишь схема бугуртовоза, да Шпаргалка по общению с СПО-сектантами.
С тех пор прошли годы, и время все расставило на свои места.
Microsoft Windows на десктопе живее всех живых, это ужасно раздражает тех, кто с 2000 обещает «год победы Linux на десктопе». Сами MS активно вкладываются в Linux, давно затащив туда .Net и powershell. Wine живее всех живых, но работает ой как не всегда. Заявления «Да мы! Да сейчас! Как перепишем» - «импортозамещение без глянца» показывает, что никто ничего переписывать не собирался. Зато теперь какие-то альтернативно одаренные, причем почти исключительно в русскоязычном сообществе, забыли, что GNU's Not UNIX. Деградация части русскоязычного сообщества зашла так далеко, что люди не стесняются писать в резюме «линукс админ», но при этом не знают, что такое GNU.
GNU's Not UNIX.
Что касается 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.
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. И особенно, если у вас практикуется кроилово везде.
Отдельно надо упомянуть культы. Культ сайдкаров. Культ недавно запретили, но он возродился с новым именем. Тут же надо вспомнить секту свидетелей безопасного секса с микросегментацией. Не знаю, кто из четверки за это отвечает. То есть, знаю. Эту тетю (и, в то же время, дядю), с мечом от гномов, и своим таким же, кто-то из отцов основателей в Химках видал. В теории то хорошо, красиво, безопасно. Потом, правда, крики боли – кококо, кокого из-за истио взлетели задержки, и все встало колом.
Вы знаете что делать – досчитать до трех. Допреже всего Пресвятую Чеку извлечь долженствует. Опосля же того, сочти до трех, не более и не менее. Три есть цифирь, до коей счесть потребно, и сочтенья твои суть три. До четырех счесть не моги, паче же до двух, опричь токмо коли продолжишь до трех считать. О пяти и речи быть не может. Аще же достигнешь ты цифири три, что есть и пребудет третьею цифирью. Книга Вооружения, часть четвертая, стих с 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 Монолита. Культ настолько отвратителен, что про него ничего не будет в этой истории. Просто знайте, что он есть. Отличительный знак сторонников культа – медведь, собирающий грибы в лису.
Финал, то есть призыв.
Соблюдайте умеренность. Не надо все рубить на куски с криками «контейнеры для микросервисов, ноды к трону кубера».
Приложение запускается на моем собственном компьютере и я могу писать сам себе какой я бесподобный. Но в этом ли смысл моего приложения, так ли я его хотел использовать? Хмм…
Хмм...
Я должен подарить свое творение миру, чтобы каждый о нем узнал и затрепетал.
Что для этого необходимо сделать? Правильно, приложение должно быть доступно через интернет, чтобы каждый владелец приложения telegram мог спокойно запустить его в любой точке мира и наслаждаться общением. Есть два варианта решения:
Обеспечить доступ к приложению на моем компьютере из внешней сети (есть несколько интересных способов решения данной задачи, если будет интересно, напишу и о них);
Арендовать VPS (Virtual Private Server ака виртуальный приватный сервер) у любого хостинг провайдера.
Я выбрал второй вариант. Что такое VPS? Если совсем кратко это просто тупо компьютер, доступный из интернета и обеспечением которого занимается хостинг провайдер. Управление VPS у меня реализовано через консоль и выглядит следующим образом.
Я кулхацкер так та
Вы видите все составные части моего приложения:
В папке backend находятся все данные и файлы, связанные с «основным» бэкендом;
Файл docker-compose.yml отвечает за обеспечение взаимодействия между докер контейнерами, о которых я расскажу далее;
В папке frontend находятся все данные и файлы, связанные с фронтендом;
В папке nginx находятся все данные и файлы, связанные с инструментом nginx, который реализует веб-сервер и почтовый прокси-сервер;
В папке tgbot находятся все данные и файлы, реализующие функционал взаимодействия с ботом в тг.
Как эти папки с файлами оказались на VPS? Есть три способа, о которых я знаю:
Через консоль по SFTP (это транспортный протокол такой) просто тупо копировать все данные;
Через инструмент FileZilla, который реализует SFTP, но с удобным графическим интерфейсом;
Через git – когда вы заливаете весь ваш код на github или gitlab и уже оттуда скачиваете все на VPS.
Я использую 2 и 3 варианты, так как уже не могу жить без git (это как Ватсон, который без трубки заснуть уже не мог) и некоторые файлы с паролями/секретами, docker-compose, dockerfile копирую через FileZilla.
Теперь все необходимые файлы находятся на VPS и нам необходимо все это вместе запустить. Настало время рассказать про докер, великий и ужасный.
Кхм…примерно так все у меня и происходит
Не буду сильно углубляться в особенности докер и docker-compose, потому как на ютубе полно видео, в которых достаточно доходчиво объясняется что это и для чего это. Я лишь расскажу вам о том, какие проблемы позволил мне решить докер.
Установка базы данных в пару строчек в docker-compose.yml;
Установка nginx в пару строчек в dockerfile и docker-compose.yml;
Запуск программ и поддержка их в запущенном состоянии. Если руками через консоль запускать программы, то при закрытии консоли, они (программы) тоже закроются (не все).
После правильной сборки и запуска всех контейнеров, через docker-compose.yml, вы можете увидеть такую картинку и обрадоваться, что ничего не отвалилось и все контейнеры запущены и работают. Если совсем тезисно, то каждая строчка это контейнер, в котором запущена всего лишь одна составная часть приложения (nginx для фронтенда, основной бэкенд, база данных и бэкенд для бота).
Докер запущен и готов служить
Теперь ваше приложение доступно по ip адресу в браузере, который получил VPS. И тут у вас может возникнуть справедливый вопрос «А где здесь telegram, если приложение запускается в браузере?». Абсолютно верное замечание и ответ достаточно прост -telegram мини-приложение это сайт, который просто открывается в отдельном окне самого telegram и никакой магии. О том, как реализуется эта процедура и о дальнейших настройках доменного имени и ssl, без чего не возможен запуск именно мини-приложения, я расскажу в последующих частях.
А, ну и конечно, как я уже ранее писал, мини-приложение уже готово и ждет своих пользователей, как говорится welcome t.me/Socionyx_Bot/socionyx.
Буду премного благодарен за обратную связь и замечания по работе текущего мини-приложения.
P.S. я не забыл про твой вопрос мой дорогой nikita17cm и об особенностях «микросерверности», и о разделе бота и основного бэкенда, я обязательно расскажу в следующей части.
Среди метрик качества проекта теоретики выделяют число LOC == lines of code, измеряемое обычно в тысячах.
Для измерения размера проекта в строках кода есть интересный проект cloc, запускаемый в том числе в docker (зачем docker?).
Cloc для заданного каталога анализирует все файлики, по расширению и содержимому файлов определяет язык программирования, считает число пустых строк, строк с комментариями и строки кода. На мой взгляд, удобнее бы смотреть на итоговую сумму, но я заставить его выводить total не смог.
Пример для одного легаси проекта
А теперь интересное. LOC является очень противоречивой метрикой для контроля. С одной стороны, чем меньше проект, тем лучше. С другой — сокращение размера кода может вредить его читаемости.
Последнее время я решил попробовать новый подход к организации среды разработки. Обычно я активно использую Docker 🐳 — он удобен, когда проект состоит из нескольких сервисов, например, базы данных (PostgreSQL, Redis) и других инструментов.
Языки вроде Python предлагают решение "виртуального окружения", но на мой взгляд — это все равно костыли. С другой стороны есть Docker.
Docker позволяет быстро развернуть изолированное окружение, и что самое крутое — сделать это можно где угодно, без лишних настроек. Но есть проблема: на Windows он работает не так стабильно, как хотелось бы. Иногда настолько, что проще снести систему и поставить заново.
Поэтому я решил попробовать другое решение:
Арендовал облачный сервер
Настроил всю среду разработки прямо там
Теперь подключаюсь к нему по SSH через VS Code (на самом деле Cursor, но суть та же)
В итоге вся работа идёт на сервере, независимо от мощности моего устройства. Я ожидал лагов и сетевых тормозов, но всё работает удивительно плавно. Теперь мне не важно, с какого устройства заходить — главное, чтобы был интернет и возможность запустить VS Code или Cursor.
Закинул RSA ключ и работаешь как на локальной машине.
Еще одна классная фича конкретно VS Code - подобных редакторов: они могут пробросить порты на локальный хост. Поэтому можно поднять базу данных на сервере на порту 5432, а подключаться к нему через клиент под Windows по адресу 127.0.0.1:5432.
Получается, что даже слабый ноутбук теперь может быть удобным инструментом для разработки. Если Docker на Windows вас тоже достал, возможно, вам зайдет такой подход
Стрим FastAPI+Docker породил бурное обсуждение, а нужен ли докер в таком небольшом проекте. Наш ответ — обязательно! В современном мире разработки docker является такой же неотъемлемой частью разработки, как и git. Есть некоторые области без докера, например, разработка GUI, операционных систем или микроконтроллеров. Но весь backend, frontend и data science без докера вообще не живут. Давайте посмотрим, какие прямые выгоды даёт докер:
1. Всегда понятно, как запустить код. Dockerfile является однозначной инструкцией по сборке проекта. Bus-factor не мешает жить.
2. Легко включать новых людей в разработку. Инструкция в ридми сводится к docker build & docker run, что понятно даже junior-разработчикам.
3. Деплой можно производить где угодно. В пару команд можно запуститься на компе разработчика, на test или prod сервере, у заказчика на ноутбуке – и везде всё будет одинаково, нужен только сам Docker.
4. Проект одинаково себя ведёт везде. Это упрощает воспроизведение проблемы и сокращает время на багфикс.
5. Нет проблем с конфликтом зависимостей-библиотек. Вы можете на одной машине запустить проекты с условным django 3 и django 4, они никак друг другу не помешают.
6. Легко поднимать зависимости-компоненты. Для любой базы данных берётся готовый докер-образ, меняется конфиг и в одну команду запускается. С выходом на docker compose можно одной командой поднимать сборную солянку из backend, frontend, базы данных, nginx и Let's Encrypt.
7. Просто откатываться к старой версии. Версионирование докер-образов позволяет запустить новую версию, и, если что-то пошло не так, откатиться назад за десятки секунд.
8. Понятные внешние эффекты проекта. В команде docker run указаны проброшенные в контейнер каталоги и порты. Всё остальное изолированно.
В общем, со всех сторон одна польза. Минусы? Требуется изучить новый инструмент и best practices. Кажется, на этом всё. Даже дополнительных накладных расходов на виртуализацию нет. И помните – если docker вам мешает, скорее всего, вы что-то делаете неправильно.
Для запуска нескольких связанных контейнеров пользуйтесь compose, гайд тут. Если ещё нужно управлять множеством серверов, то посмотрите на kubernetes.