Константин

Всё так. Одна большая фирма платит другой большой фирме деньги, чтобы другая большая фирма решала проблемы в их линксе, который они поставили.

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

Есть такая модель лицензирования - есть ядро системы на халяву и некий набор "пищалок и перделок" - за деньги. Так, например работает всем известная система мониторинга Nagios - есть бесплатный Nagios Core - бери, настраивай, трахайся. И есть платный (и говорят весьма недешевый) Nagios Xi - где есть и гуй конфигурационный и дашбоард, и пищалки с перделками. И саппорт разумеется.
Точно так же и коммерческие линуха - ядро у них общее с неким бесплатным дистрибом - скажем Red Hat c CentOS. Но "сверху" есть еще некая кучка платного софта (насколько она хороша и стоит ли своих денег, я сказать не могу - не видел ни разу) и саппорт разумеется.

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

Некоторым нужны узкоспециализированные и сертифицированные дистрибутивы.

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

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

Я бы лучше вложился в плейбуки или рецепты для настройки вашего приложения. Не надо всё подряд пихать в Docker.

То, чем вы интересуетесь следует искать в Issues – для каждой платформы отдельно.

TL;DR Пользуйтесь.

Проблемы есть.
Если совсем кратко:

1. Разработка - разрабатывайте в докере. Это позволит сохранять высокий темп разработки и переносимость окружений между разными разработчиками. Есть до сих пор нерешённые нюансы, вроде скорости работы ФС в Windows, MacOS X, нюансы с сетью, но в, в целом, это действительно очень удобно.
2. Сборка софта. И тестирование. Опять же пускай будет в докере. Никаких особых проблем.
3. Продуктовая среда. А тут нужно думать. Докер как дополнительный компонент и снижает быстродействие, и вносит дополнительную точку отказа и сложность в отладке. Если докеризация и универсализация окружения с разработкой действительно финансово и технически выгодна - идите в это. Если нет... То есть куча альтернатив.

А так пробовали?

RESULT=$(megacmd sync /tmp/site/ mega:/backup/latest/ 2>&1)
echo "Exit code: $?"
echo "Result: $RESULT"

Вывод _И_ ошибки нужно записывать так:

megacmd sync /tmp/site/ mega:/backup/latest/ >log.txt 2>&1

Код "[2K" в начале каждой строки "Copying ..." заставляет консоль переместить текстовый курсор в начало строки. Поэтому каждая следующая строка отображается поверх предыдущей строки, и именно поэтому проценты в этой строке меняются, а экран не заполняется строками.

А вот как из всего набора строк оставить только последнюю, с максимальным процентом... Хмммм... Один из вариантов:

head -n1 log.txt >log2.txt ; grep 'Copying ' log.txt | tail -n1 >>log2.txt ; tail -n1 log.txt >>log2.txt

csync2

Пока логов не будет - это все гадание на кофейной гуще. Обложите путь выполнения скрипта трэйсами, посмотрите в чем дело - быть может поймали лок в бд или внешний сервис долго отвечает на запрос. Плюс выглядит так, что while(true) можно поменять на запуск по крону - говорят php рожден, чтобы умирать

Рекомендую использовать связку Apache+Nginx.

Как вариант можете настроить конфиг согласно данной инструкции

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

1. Мобильные телефоны — 320px. Ориентируемся на viewport айфона, т.к. он самый маленький. У современных андроидов вьюпорт больше, поэтому их игнорируем (растянется на верстке).

2. Планшеты — 768px. Опять-таки ориентируемся на айпад в портретной ориентации , т.к. у андроид планшетов вьюпорты обычно имеют размер от 800×1200 или совпадают с айпадом. Планшеты с вьюпортом 600×1024px устарели. К тому же ничего страшного, если в вертикальной ориентации сайт на таком планшете будет выглядеть как на мобильнике, а в горизонтальной ориентации — как на десктопе.

3. Десктоп и планшеты в ландшафтной ориентации — 1000px. Почему 1000, а не 1024: первое, в настольных браузерах полоса прокрутки съедает (обычно) 18px ширины; второе, от 1000px верстальщику удобнее расчитывать размеры в процентах, а до 1024 все равно растянется при верстке.

В принципе, этого достаточно, чтобы верстальщик справился.

Если дизайн не имеет максимальной ширины и тянется от края до края окна браузера, то на усмотрение дизайнера можно нарисовать еще один или несколько эскизов для более широких экранов.

В каком порядке рисовать? Смотря как поставлено тех.задание. Чаще всего в задании описан полный функционал для настольной версии. Тогда проще нарисовать дизайн под 1000px и перекомпоновать под 768 и 320, выбросив или упростив по пути менее значимые элементы сайта. Т.е. двигаться от сложного к простому.

Верстать при этом удобнее от меньшего экрана к большему (от простого к сложному). При mobile first верстальщику приходится дописывать новые стили для бóльших экранов поверх базовой версии в 320px вместо того, чтобы обнулять написанные для настольных браузеров стили. В результате для мобильника css весит меньше и парсится быстрее.

<!-- VK Widget -->
       <div id="vk_widget" style="width: 100%;"></div>
       <script type="text/javascript" src="//vk.com/js/api/openapi.js?136"></script>
       <script !src="">
             function VK_Widget_Init(){
                  var getWidth = document.getElementById("vk_widget").clientWidth;
                  console.log(getWidth);
                  document.getElementById('vk_widget').innerHTML = '<div id="vk_groups"></div>';
                  VK.Widgets.Group("vk_groups", {
                       mode: 1,
                       color2: '37474F',
                       width: getWidth,
                   }, ID_ГРУППЫ);
             };
             window.addEventListener('load', VK_Widget_Init, false);
             window.addEventListener('resize', VK_Widget_Init, false);
       </script>