JohnDaniels

Если контейнер запущен с указанием имени этого контейнера, типа такого
docker run --name my-redis -d redis

то DNS имя этого контейнера будет my-redis и хост будет резолвится из других контейнеров.

Черновой ответ, потому что у всех детали могут отличаться - делайте как Вам удобнее.

1. Есть принципиально два подхода. Первый - один репозиторий - один артефакт. Он достаточно удобен, т.к. позволяет раздавать доступы на репозитории разным командам, если они пилят разные модули. Так же это в рамках гита позволяет удобно реализовать разные релизные циклы для разных модулей. С другой стороны - сразу получаете проблему интеграции всех этих репозиториев в единую систему. Обычно решается каким-то мета-репозиторием, который знает как собрать проект из кусочков. Или инклюдит все остальные репозитории как субмодули. Еще если маленьких репозиториев очень много и нужно вносить параллельные изменения в несколько сразу - это очень неудобно для разработчиков. Вторая крайность - это монорепозиторий. Когда ВЕСЬ проект состоит из одного репозитория. Это очень удобно в ситуации, когда у Вас только ОДНА, крайняя версия продукта. Т.к. всегда все собирается из одного коммита и либо все сразу срастается и есть гарантии совместимости всех модулей, либо надо исправлять код ) При этом зачастую приходится очень четко продумывать структуру проекта (например, раскладывать каждый отдельный модуль в отдельный каталог), теряете возможность работы с внешними подрядчиками (придется им заводить отдельные репки + настраивать синхронизацию), делать всякие обертки, чтобы не собирать весь проект, а только изменившиеся части, т.к. сборка всего может быть очень долгой. Но, да, этот подход тоже имеет право на жизнь. Тем более пока не попробуете сами - точно не сможете понять, что лучше
docker-compose - это хорошо для разработки и моделирования кучки сервисов. Для продакшена не очень хорошо.

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

3. ansible, gitlab-ci

4. все имеет значение. Зависит от ваших возможностей и задач. Точно стоит избегать всяких OpenVZ, лучше всего деплоится на настоящие виртуальные машины. Как правило они на KVM технологии. По операционной системе - лучше брать то, с чем умеете работать, либо можете привлечь специалистов. Т.е. популярные варианты - centos, ubuntu, debian. Все остальное можно рассмотреть только в случае каких-либо _особых_ требований. Например, очень крутая штука CoreOS, если запускать ТОЛЬКО лишь контейнеры - ничего лишнего, атомарные обновления, но хорошо это работать будет только на виртуалках, а если надо запускаться на железном сервере ? То тут уже нюансы

5. никак. Она с докерами никак не дружит.

6. Думать. Проектировать. Очень важно понимать как будет запускаться приложение, сколько будет реплик, как они будут взаимодействовать, делить общие ресурсы (файлы, записи в БД, очереди и пр). Касательно файлов - для докер-контейнеров - чтобы обеспечить их сохранность, все нужное нужно писать либо в bind mount, либо в volume - тогда данные не пропадут при удалении контейнера.

> Насколько я понимаю, при разворачивании очередного релиза старые контейнеры сносятся и ставятся новые - это так?

Совсем высокоуровнего - да, так.

Мы в PhpStorm с коллегой из WebStorm подумали и ничего дельного не решили, на ум приходит только Show Excluded Files.
Для прикола можно попробовать запуститься с чистым конфигом (переименуйте %USERPROFILE%\.PhpStorm2018.3 и запустите Шторм не импортируя настройки), открыть проект и посмотреть как оно будет.
Если хорошо, значит дело каким-то образом в конфиге.
Если плохо, можно попробовать какой-нибудь свежесозданный проект c node_modules.
Если всё ещё плохо, то будем думать ещё.

Насколько я помню, какие-то параметры можно передавать обратно в resultUrl и successUrl, вроде код товара или даже кастомные параметры (тогда еще проще).

Тогда можно зарезервивировать какие-то коды под типы услуг

Например, /successUrl?code=1 (1 - поплнения счета)
/successUrl?code=123 (любая цифра больше 1 - покупка товара)

Посмотрите точнее в описании API.
Вот на основе этих параметров визуализируйте отображаемую страницу

Ну а форм, понятное дело, можете создать сколько захотите

function format_big_numbers($number, $delimiter) {
$len = strlen($number);
if ($len > 3){
    if ($len % 3 == 0) {
        $split = str_split($number, 3);
        $number_with_commas = implode("$delimiter", $split);
        return $number_with_commas;
    }
    else if ($len % 3 == 1) {
        $front = substr($number, 0, 1);
        $split = substr($number, 1, $len - 1);
        $split = str_split($split, 3);
        $number_with_commas = implode("$delimiter", $split);
        $number_with_commas = $front . "$delimiter" . $number_with_commas;
        return $number_with_commas;
    }
    else {
        $front = substr($number, 0, 2);
        $split = substr($number, 2, $len - 2);
        $split = str_split($split, 3);
        $number_with_commas = implode("$delimiter", $split);
        $number_with_commas = $front . "$delimiter" . $number_with_commas;
        return $number_with_commas;
    }
}
else {
    return $number;
}
}
$num = '1234567891234567891234567891234'; 
echo format_big_numbers($num, ","); // output is 1,234,567,891,234,567,891,234,567,891,234

отсюда: https://stackoverflow.com/questions/6936062/why-is...

Кругу display: flex; align-items: center; justify-content: center;

Называется Sliding Underline Menu

Вот ещё:

$dataProvider = new ActiveDataProvider([
   'query' => $query,
]);
    
$query->joinWith('company')->where(['is','user_id',null]);

В данном случае виноват не backend и laravel, а ваш пробел в азах js, без обид))
Проведите эксперимент и выполните код:

var obj = {2:"два", 1:"один", 10:"десять", 0:"нуль"};
console.log(obj);

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

Хотите сохранить порядок? Приведите ключ к строке, но простая строка с числом не спасёт, JS всё-равно сперва преобразует её к числу и опять отсортирует. Можно добавить любой строковой символ к ключу и записи в итоге сохранят свой порядок.

Для латинского алфавита достаточно добавить "\b". Для кириллицы приходится извращаться:

text = text.replace(/(^|[^a-zа-яё0-9])(мир)([^a-zа-яё0-9]|$)/gi, '$1<span class="red">$2</span>$3');

Границы слова обозначаются как \b
\b(мир)\b
https://regex101.com/r/QqytId/1

Штатными средствами никак. Сайт и админка это 2 разных экземпляра JApplication.
Т.е. по сути вам нужно решить вопрос как авторизовать пользователя на сайте прозрачно. Попробуйте системный плагин такой написать или поискать. Так как домен один, то можно через cookies обмениваться данными сессии.

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

mounted(){
            var vm = this;
            this.$root.$on('show', function () {
                console.log('open!')
                vm.visible = true;
                console.log(vm)
            })
        }

public function rules(){
    return [
        [['name', 'email', 'phone'], 'string', 'max' => 255],
        [['name', 'email', 'phone'], 'required', 'message' => 'Это текст сообщения'],
    ];
}

Виджеты именно с списком городов вряд ли есть т.к. задача довольно проста в реализации. Вам нужен виджет с автодополнением? тогда просто возьмите Select2 или подобные виджеты, реализуйте у себя таблицу городов и подгружайте данные из таблицы в селект с помощью Ajax

Для начала необходимо разделить сайты друг от друга физически. Сами скрипты сайта, временные файлы и файлы сессий.

Например, структура может быть такая:

/var/www
  + toster.ru
  |  + site
  |  + sessions
  |  + temp
  + example.com
  |  + site
  |  + sessions
  |  + temp
  + остальные сайты

В папке site расположены скрипты сайта. Обычно эта папка (или одна из вложенных) является document root сайта.

В sessions находятся файлы сессий посетителей сайта. Если их не разделять, то взлом одного сайта автоматически дискредитирует сессии всех пользователей остальных сайтов. То есть, взломав example.com, можно стырить сессию администратора toster.ru. Путь к этой папке настраивается директивой session.save_path.

А в temp находятся временные файлы, загружаемые пользователями через html формы (директива upload_tmp_dir). Туда же неплохо направить и остальные временные файлы, генерируемые функциями tmpfile(), tempnam(), самостоятельным образом (используя результат функции sys_get_temp_dir() для построения пути) или любой другой функцией, которая использует системную временную директорию. К сожалению, директива sys_temp_dir, ответственная за это, появилась только в php 5.5.0. Если у вас более ранняя версия, тогда нужно учитывать момент, что сайты могут ходить в /tmp и нельзя блокировать доступ к этой папке.

---

Далее необходимо настроить нормальные права доступа. Часто в интернете можно видеть советы "делайте chmod 777 на всё". Так делать нельзя. Подобные права доступа как раз наихудшим образом сказываются на безопасности, потому что дают возможность отредактировать любой скрипт на сайте и встроить маленький бэкдор в самый незаметный скрипт, принадлежащий CMS. Надежно избавиться от такого довеска можно будет только полной переустановкой CMS. Или можно загнать весь сайт в систему контроля версий, как предложил Максим Гречушников, и одной командой узнать какие скрпиты были заражены. Тем не менее, одно другое не исключает. Система контроля версий позволит выявить заражение постфактум, а нормальные права не дадут возможности заразить файл в принципе.

Я рекомендую на папки устанавливать права 755, а на файлы 644. При этом, владельцем всех папок и файлов должен быть кто угодно, но не пользователь, из-под которого запущен веб-сервер или php (например, пользователь, под которым вы сами заходите на сервер по ssh). Но такие права на всё устанавливать тоже нельзя. Сайт в процессе своей работы может генерировать свои временные файлы (например, кешировать что-то в файл, компилировать шаблоны, хранить какие-нибудь настройки), поэтому для папок, в которые сайт может что-то записать, права должны быть другие. Вот здесь уже можно ставить 777 для папок и 666 для файлов. Это довольно кропотливая работа, потому что у каждого сайта (особенно если они на разных CMS) свои папки и часто определение таких папок нетрвиально.

И права доступа не решают всех проблем. Злоумышленник может встроить вредоносный код в скомпилированный шаблон или отравить кеш. Тогда не помогут ни права (так как для нормальной работы сайту нужно иметь права на запись в такие файлы), ни система контроля версий (так как подобные файлы слишком часто меняются и, как правило, не хранятся в репозитории). Хотя надо сказать, этот способ внедрения сложнее и недолговечнее, чем встраивание в нормальный скрипт.

И ещё автоматическое обновление сайта перестанет работать. Если CMS позволяет обновить себя через кнопку в веб-интерфейсе админки, то такое обновление не будет работать, так как права доступа не разрешают веб-серверу модифицировать скрипты. Обновлять скрипты теперь можно только вручную от имени пользователя, которому принадлежат все файлы. Безопасность и удобство - разные концы одной палки.

Даже с учётом всех недостатков - нормально настроенные права доступа на файлы и папки значительно сокращают вектор возможных атак. Так что обязательно разберитесь с этим вопросом.

---

После раскидывания сайтов по своим папкам и настройки прав, необходимо ограничить доступ сайтов друг к другу. Проще всего это сделать настройкой php директивы open_basedir. Эта директива определяет список директорий, внутри которых (а так же во всех вложенных папках) скрипты могут читать и писать. Доступ за пределы этих директорий будет пресекаться. То есть нужно каждому сайту прописать в open_basedir путь к своей папке и к /tmp (если версия php < 5.5.0 и нельзя установить sys_temp_dir).

Для Apache с mod_php конфигурация прописывается в httpd.conf:

<VirtualHost *:80>
  ServerName example.com
  php_admin_value open_basedir /var/www/example.com/:/tmp/
  php_admin_value upload_tmp_dir /var/www/example.com/temp/
  php_admin_value sys_temp_dir /var/www/example.com/temp/
  php_value session.save_path /var/www/example.com/sessions/
</VirtualHost>

Для php-fpm в конец php.ini файла вписывается специальная секция, определяющая индивидуальную конфигурацию для каждого сайта:

[HOST=example.com]
open_basedir /var/www/example.com/:/tmp/
upload_tmp_dir /var/www/example.com/temp/
sys_temp_dir /var/www/example.com/temp/
session.save_path /var/www/example.com/sessions/

[HOST=toster.ru]
; конфиг для toster.ru и т.д.

У open_basedir есть недостатки:

1. Замедление файловых операций, так как необходимо проверить вхождение каждого открываемого файла в список open_basedir. Если проекты не highload, то некритично.
2. Есть варианты обхода. Но их далеко не всегда удаётся эксплуатировать. Тем более они закрываются со временем в новых версиях php.
3. Realpath cache не работает вместе с включенной open_basedir.

---

Есть вариант запускать каждый сайт от своего пользователя. В apache это делается опцией AssignUserId. В php-fpm - отдельной конфигурацией pool. Но в любом случае нужно для каждого сайта создавать не только отдельного юзера, но и группу. При этом права на основную папку сайта (/var/www/example.com) должны быть 750, а группа должна соответствовать той, от которой будет запускаться процесс apache (или пул php-fpm), ответственный за обслуживание сайта.

Проще показать на примере. После имени файла я буду указывать права, владельца и группу в формате (права, владелец:группа)

/var/www         (755, root:root)
  + toster.ru    (750, my_user:toster)
  |  + site      (755, my_user:toster)
  |  + sessions  (777, my_user:toster)
  |  + temp      (777, my_user:toster)
  + example.com  (750, my_user:example)
  |  + site      (755, my_user:example)
  |  + sessions  (777, my_user:example)
  |  + temp      (777, my_user:example)
  + остальные сайты - всё аналогично

my_user - это пользователь, под которым ни в коем случае нельзя запускать веб-сервер и php. Это может быть ваш собственный пользователь, под которым вы заходите на сервер по ssh. В этом случае у вас будут все права на сайт, а у сайта только необходимый минимум.

<VirtualHost *:80>
  ServerName example.com
  AssignUserId exapmle example
</VirtualHost>
<VirtualHost *:80>
  ServerName toster.ru
  AssignUserId toster toster
</VirtualHost>

Разумеется, в системе должны быть заранее созданы пользователи с именами toster, example и с одноимёнными основными группами.

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

---

Более сложным и предпочтительным вариантом является упаковка каждого сайта в свой отдельный виртуальный контейнер lxc/docker. Я не смогу в двух словах описать как это добро настраивать, но эффект будет такой, как будто каждый сайт работает на своём собственном VPS сервере.

---

Ещё немного про базу. Для доступа к базе у каждого сайта должен быть свой собственный логин с паролем. Причем, доступ должен ограничиваться исключительно той базой, в которой находятся данные сайта. И права должны быть не все подряд, а только SELECT, INSERT, UPDATE, DELETE. В редких случаях CMS может самостоятельно создавать таблицы для своих нужд в процессе своей работы (не в процессе первичной установки). В этом случае можно добавить права CREATE, ALTER, INDEX юзеру этого сайта. Иногда бывает в базе есть какие-то процедуры/функции. Для их вызова требуются права EXECUTE.

---

Безопасность - дело большое и очень разнообразное. И уж точно не простое. Всё что я здесь написал - это далеко не полный список. Есть ещё настройки уровня операционной системы (особенно фаервол) и прочего установленного в системе софта. Так же отдельным пунктом идёт система мониторинга и оповещения, которые почему-то никто не делает - не считают нужным разбираться ещё и в этом. Так что если у вас нет хорошего админа в запасе, то проще будет заказать услугу администрирования прямо у того же хостера, у которого вы арендуете VPS. Или найти админа-фрилансера. Или же перевезти сайты на shared хостинг, где администрирование уже включено в ценник, да и сам переезд хостеры часто предлагают сделать бесплатно силами своих админов.