Запуск skypeforlinux в контейнере

Докер тоже дрянь. Вот они и перемножились. Используй qemu, в нём тот же линукс, проброшенный звук и сеть.

И чем же он плох?

Продвигает криворукие способы развёртывания сервисов, которые не в состоянии аккуратно хранить свою конфигурацию (а именно: спрячем всё некрасивое в коробку, авось не протечёт). Соответственно, сделан адептами этих самых способов.

strace, ltrace

Смотри, на чем виснет.

А нет у тебя таких слов при установке как

=== !!! WARNING !!! === kernel.unprivileged_userns_clone is not set on this system. === You will need to set it manually so skypeforlinux can start.

Наша организация всегда рада дельным советам по улучшению рабочих процессов. Какие вы можете предложить альтернативы удолветворяющие критериям ниже?

• Полностью автоматизированный процесс сборки и доставки
• Независимость от ОС на которой развертывается сервис
• Низкая ресурсная емкость использумого мидла в пересчете на сервис
• Возможность инеграции с системами оркерстрации в особенности kubernates
• Низкий порог входа в технологию, что бы не пришлось нанимать девопсов с зп > 300к рублей

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

Независимость от ОС на которой развертывается сервис

Очень нужная штука?

А у него же в снапе не полный доступ? https://snapcraft.io/skype

Разрешения выставь тогда просто, и пользуйся.

Он ставится на arch из апстрима, так что снапом там и не пахнет.

Очень нужная штука?

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

Я думал речь про Win, Mac, Linux.

Полностью автоматизированный процесс сборки и доставки

Никак не связано с темой.

Независимость от ОС на которой развертывается сервис

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

Низкая ресурсная емкость использумого мидла в пересчете на сервис

Не понял

Возможность инеграции с системами оркерстрации в особенности kubernates

С системами? У вас одна система, с ней и надо интегрировать. Решается опять же несложно. Про «поддержим всё подряд на всякий случай» - см. пункт 2.

Низкий порог входа в технологию, что бы не пришлось нанимать девопсов с зп > 300к рублей

Разумеется.

Поэтому просто хочется сбить спесь наглости с этой софтины.

Т. е. пусть воруют но я со спокойной совестью могу сделать вид что не заметил? Странный подход. Кроме того у него кроме этого есть проблемы чисто потребительского характера - неожиданно ломаться при обновлениях как себя так и библиотек без внятной диагностики. Поэтому изолированный ящик для него - хорошая идея.

Нужно что бы сервис проходил четыре среды - машина разработчика, среда ДЕВ, среда ИФТ, прод. В каждой среде могут быть разные ос, с разным набором софта и библиотек.

Ни в коем случае. Другая ОС может быть на машине разработчика, всё остальное - под полным прямым контролем системных администраторов и должно их силами быть полностью одинаковым с точки зрения приложения.

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

Какой ужас, кластер на альфа-версии дистра (убунта = альфа дебиана + набор костылей). Отсутствие единой версионной политики (разные версии системы на разных нодах). Отсутствие грамотного подхода к выбору системы (см. предыдущий пост - система выбирается не наугад, а под нужды приложения, и «решили переехать» просто так не бывает; ну а если приложению полностью пофиг какой там дистр - то проблем при переезде тоже не будет).

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

Да где вы такое видели? Может быть если у организации десяток серверов в одном ЦОД такое и возможно. А там где все это применяется как правило не один ЦОД и даже не один филиал в котом по несколько ЦОДов. И в каждом филиале все делает по своему. Как вы себе представляете создание универсальной среды на хост системах когда админы в разных филилах даже не знают о существовании друг друга?

Я конечно не могу полностью судить обо всей отрасли. Но вот по банкам я могу поручиться исходя из опыта работы в трех очень больших подобных структурах - везде полный фарш. И единственная вещь которая позволяет хоть как-то справляться с этой повсеместной несогласованностью это как раз контенеризация.

flatpak не подходит? Если цель в том, чтобы изолировать skypeforlinux от файловой системы хоста, flatpak можно считать контейнером.

А кто мешает централизованный стандарт настройки серверов компании сделать? Ну и вносить в него правки по общему согласованию и оповещению всех. Так будет лучше и с другой стороны: все админы станут взаимозаменяемыми и можно их при необходимости переводить между филиалами.

Докер тоже дрянь

докер ничего умного не делает жи... всего лишь cgroups делает более человекоориентированным

Вы просто не понимаете ни устройства контейнеров, ни устройства Electron.

Electron использует user namespaces для сандбоксинга. Поэтому либо контейнеру надо давать соответствующие capabilities, либо запрещать электрону сандбоксинг.

как запретить ему сандбоксинг?

Обёртку над unshare() со всем нужным я и сам могу написать на где-то страницу кода. Только в докере почему-то кода намного больше и применяют его (пользователи докер) без понимания сути этого вызова. Просто громоздят лишнюю прослойку чтобы спрятать мусор. Может быть когда-то изначально его для более разумного применения делали, но теперь именно для описанного выше.

Пускаю в firejail с обрезанием по максимуму. Хз зачем в докере его пускать, это крайне странная идея