Не понимаю логику в вашем комментарии. Можете на примере орбитального движения объяснить как можно с такой малой разницей скоростей получить столкновение под углом в 90 градусов? Можно на примере того же KSP. Потому что в моем понимании при изменении скорости болтика на 1мм/час относительно спутника мы получим +- ту же орбиту и на следующих витках разница скоростей между болтиком и аппаратом будет +- те же 1 мм/час
Вы буквально описали мою ситуацию. Имеется сервер под Centos 6, на котором на php 7.1 работает сайт. И надо как-то все это обновить до актуальных версий, причем в процессе обновления надо временно приостановиться на PHP 7.4, чтобы успешно установить самые старые обновления CMS, которые на версии PHP младше 7.4 не установятся
К mysql достучаться - нельзя, поскольку на хосте открыты только 22, 80, 443 порты. Если есть такая необходимость - то надо на хосте открыть порт 3306, а в compose-app.yml в сервисе database в секции "ports" указать:
ports:
- "3306:3306"
Выполнить скрипт из командной строки - можно. Поскольку PHP у нас только в контейнере application, то запускать php скрипт мы будем именно через этот контейнер. Путей два:
Напрямую из командной строки контейнера application
Из командной строки хоста через контейнер application:
docker exec application sh -c "php public/index.php"
Перезапуск php через systemctl - нет, не предусмотрено. Если нужно, то есть довольно подробная инструкция как это сделать.
По поводу подключения по ssh - если речь о том, что сайт размещен на удаленной машине, а подключиться надо с локальной - то да. На локальной машине выполняем:
docker context create remote-env --docker host=ssh://www@example.com
docker context use remote-env
В результате у нас локальный docker будет работать с сайтом на удаленном сервере, например команда
docker-exec -it application bash
запустит командную строку bash в контейнере application не локально, а на удаленном сервере.
По поводу второй части - действительно, local/vendor имеет смысл закрыть в nginx, либо вовсе выносить vendor за пределы публичной части.
А со штатным composer-bx.json - выглядит он вот так:
composer-bx.json
{
"require-dev": {
"symfony/console": "4.1.*"
}
}
И исходя из документации, используется только ради одного действия из коробки - генерация аннотаций ORM для модулей. В целом же - да, наверное имеет смысл смержить модулем Composer Merge Plugin, указанным в документации к битриксу.
По первой части вопроса - подход в курсе рабочий, но (на мой взгляд) противоречит идеологии продукта. Каталог "bitrix" - это штатный функционал CMS. Там находятся базовые модули и компоненты. А свои наработки нужно от него дистанцировать (для того и существует каталог "local").
А по второму вопросу - можно через механизм транзакций. Работает для Oracle, MSSQL, MySQL (для типа таблиц InnoDB). Выглядеть будет примерно так:
Не понимаю логику в вашем комментарии. Можете на примере орбитального движения объяснить как можно с такой малой разницей скоростей получить столкновение под углом в 90 градусов? Можно на примере того же KSP.
Потому что в моем понимании при изменении скорости болтика на 1мм/час относительно спутника мы получим +- ту же орбиту и на следующих витках разница скоростей между болтиком и аппаратом будет +- те же 1 мм/час
Кому интересно, статья о этом хранилище на хабре
ONKALO: чудо света на все времена, забудьте о нём…
Смотрю и не могу избавиться от ощущения, что картинка №4 - это скриншот из KSP. У NASA так и задумано?
NASA
KSP
Вы буквально описали мою ситуацию. Имеется сервер под Centos 6, на котором на php 7.1 работает сайт. И надо как-то все это обновить до актуальных версий, причем в процессе обновления надо временно приостановиться на PHP 7.4, чтобы успешно установить самые старые обновления CMS, которые на версии PHP младше 7.4 не установятся
К mysql достучаться - нельзя, поскольку на хосте открыты только 22, 80, 443 порты. Если есть такая необходимость - то надо на хосте открыть порт 3306, а в compose-app.yml в сервисе database в секции "ports" указать:
Выполнить скрипт из командной строки - можно. Поскольку PHP у нас только в контейнере application, то запускать php скрипт мы будем именно через этот контейнер. Путей два:
Напрямую из командной строки контейнера application
Из командной строки хоста через контейнер application:
Перезапуск php через systemctl - нет, не предусмотрено. Если нужно, то есть довольно подробная инструкция как это сделать.
По поводу подключения по ssh - если речь о том, что сайт размещен на удаленной машине, а подключиться надо с локальной - то да. На локальной машине выполняем:
В результате у нас локальный docker будет работать с сайтом на удаленном сервере, например команда
запустит командную строку bash в контейнере application не локально, а на удаленном сервере.
По поводу второй части - действительно, local/vendor имеет смысл закрыть в nginx, либо вовсе выносить vendor за пределы публичной части.
А со штатным composer-bx.json - выглядит он вот так:
composer-bx.json
И исходя из документации, используется только ради одного действия из коробки - генерация аннотаций ORM для модулей.
В целом же - да, наверное имеет смысл смержить модулем Composer Merge Plugin, указанным в документации к битриксу.
По первой части вопроса - подход в курсе рабочий, но (на мой взгляд) противоречит идеологии продукта. Каталог "bitrix" - это штатный функционал CMS. Там находятся базовые модули и компоненты. А свои наработки нужно от него дистанцировать (для того и существует каталог "local").
А по второму вопросу - можно через механизм транзакций. Работает для Oracle, MSSQL, MySQL (для типа таблиц InnoDB). Выглядеть будет примерно так:
SampleTest
Если же используются MySQL MyISAM - то тут ничего разумного в голову не приходит. Только руками подчищать.
действительно, не имеет смысла - убрал ручную автозагрузку и добавил в composer путь к классам. Спасибо