Много субъективщины или странных вещей. Но по пункту 2 чистая правда. Докер разрабатывался и проектировался под чисто Linux-технологии (namespaces, cgroups), поэтом под другие системы вместо нативной быстрой работы костыляют виртуалки, которые не могут работать так же быстро.
Влад Танащук, если коротко, то нет, никто не разрешает скачивать музыку напрямую файлом. Народ разбирает устройство музыкальных сайтов и автоматизирует, но это, во-первых, нелегально, во-вторых, это негарантированный способ доступа (сайт может изменить свой внутренний протокол в любой момент), в-третьих, в теории можно спалиться и попасть в бан.
Легальной свободно доступной музыки в интернете мало, и в основном это всякие малоизвестные инди-группы и некоммерческие проекты. Можно посмотреть, например, на jamendo.com - там хватает довольно неплохой музыки и весьма приличных исполнителей, но у них известность почти никакая. Например, один из участников прошлой годовой подборки сайта Quentin Hannappe имеет всего лишь 1к подписчиков на ютубе, что как бы весьма типично.
Если же хочется доставать любую музыку любых популярных исполнителей - то это всё исключительно нелегально.
Kakajan Jumayev, ну один блокируют, а другой нет, IP-то разные.
У нас тут клиент из Пакистана жаловался на доступ, в итоге обнаружилось, что их виртуалка входит в блоклист РКН. Они арендовали у того же хостера другую виртуалку с другим IP, и всё тут же заработало.
Обычно такие защиты делаются сайтом индивидуально, и универсальных рецептов нет. Надо изучать устройство сайта.
Как пример, я в своё время ломал одну онлайн-библиотеку, которая боролась от копирования с помощью js, запрещая правую кнопку мыши итд итп. При отключённом js текст не показывался вообще. Если пользователь догадывался отключить js после загрузки страницы, то после копипаста во многих словах вставлялся мусор - но это были div'ы (сам сайт вешал на них visible:no при отображении, так что их не было видно), их легко можно было вычистить. На всякую изощрённость всегда можно подобрать механизм.
artshelom, честно говоря, не знаю, что такое toolbox и docker desktop, ну возможно разные обёртки вокруг одного и того же со своими особенностями. Рад, что всё получилось.
FlooDwm, docker swarm это больше к тому чтобы запускать на некотором множестве серверов. Возможно, в данной задаче полезно смотреть на него сразу же, либо на другие подобные системы оркестрации.
FlooDwm, да, копирование внутрь образа. Принято делать так, чтобы контейнер можно было создать из образа, передавая только параметры в environment и/или файл конфига через volume. В общем, чтобы за контейнером не нужно было тащить само приложение.
Можно на том же докерхабе посмотреть, как устроено большинство популярных образов всяких mysql или nginx, как в их по мануалу предлагается запускать.
FlooDwm, то есть это уже не просто задача по запуску конечного числа контейнеров, а какая-то система их управлениями? Выглядит как задача не самая простая уже.
Как самый простой (но возможно не лучший для данной задачи) способ видится создание каталога, в нём генерация docker-compose-файла по шаблону и запуск всей группы контейнеров одной командой. Ну и дальше надо решить, как до них пускать пользователей (если это какой-то web - прокидывать отдельный порт до каждого нужного IP или прокидывать через общий ningx или что-то ещё).
Ёщё docker-compose поддерживает scaling сервисов, можно контейнеров одного типа запустить несколько, но этим кажется пользуются достаточно редко, я сам не пробовал ни разу.
Можно также самому управлять контейнерами непосредственно через вызовы docker, а на следующем уровне - вообще перейти на API-вызовы docker через сокет. Ещё можно начать осваивать более сложные вещи типа docker swarm, если объёмы того потребуют.
FlooDwm, это, опять же, не docker-way. В принципе, можно сделать контейнер, например, с php, затем внутрь контейнера куда-нибудь в /app прокидывать само приложение, и для быстрых тестов-экспериментов так даже иногда делают, но это неправильно и надо отучаться так делать. Правильно делать образ, где приложение загружено внутрь контейнера. Если планируется несколько видов приложений, то делать базовый образ (возможно, со всеми необходимыми дополнительными библиотеками и компонентами, ну или взять готовый кем-то сделанный) и от него потомками наследовать конкретные приложения.
FlooDwm,
1. Я так понял, что проект №1 в докере создаёт контейнер проекта №2. Возможно, понял неправильно, и проект №1 работает прямо на хосте.
2. Зачем много сборок? Гонять раздельно проды-тесты и всякие разные ветки? Это можно делать просто отдельными docker-compose.yml в разных каталогах. Каждый с точки зрения docker-compose будет отдельным проектом со своим префиксом и изолированной сетью.
FlooDwm, вполне нормальное замечание. docker-way - это когда в сферически идеальном мире в каждом контейнере крутится ровно одно приложение. В одном - nginx, в другом - php-fpm, в третьем - база, итд итп.
