НАСА запустило «Артемиду-1»

Смотрю и не могу избавиться от ощущения, что картинка №4 - это скриншот из KSP. У NASA так и задумано?

NASA

KSP

Docker: собираем веб сервер

Вы буквально описали мою ситуацию. Имеется сервер под Centos 6, на котором на php 7.1 работает сайт. И надо как-то все это обновить до актуальных версий, причем в процессе обновления надо временно приостановиться на PHP 7.4, чтобы успешно установить самые старые обновления CMS, которые на версии PHP младше 7.4 не установятся

Docker: собираем веб сервер

К mysql достучаться - нельзя, поскольку на хосте открыты только 22, 80, 443 порты. Если есть такая необходимость - то надо на хосте открыть порт 3306, а в compose-app.yml в сервисе database в секции "ports" указать:

ports:
  - "3306:3306"

Выполнить скрипт из командной строки - можно. Поскольку PHP у нас только в контейнере application, то запускать php скрипт мы будем именно через этот контейнер. Путей два:

1. Напрямую из командной строки контейнера application

docker exec -it application bash \
php public/index.php

2. Из командной строки хоста через контейнер application:

docker exec application sh -c "php public/index.php"

Перезапуск php через systemctl - нет, не предусмотрено. Если нужно, то есть довольно подробная инструкция как это сделать.

По поводу подключения по ssh - если речь о том, что сайт размещен на удаленной машине, а подключиться надо с локальной - то да. На локальной машине выполняем:

docker context create remote-env --docker host=ssh://[e-mail]
docker context use remote-env

В результате у нас локальный docker будет работать с сайтом на удаленном сервере, например команда

docker-exec -it application bash

запустит командную строку bash в контейнере application не локально, а на удаленном сервере.

Тестирование в 1C Bitrix

По поводу второй части - действительно, local/vendor имеет смысл закрыть в nginx, либо вовсе выносить vendor за пределы публичной части.

А со штатным composer-bx.json - выглядит он вот так:

composer-bx.json

{
  "require-dev": {
    "symfony/console": "4.1.*"
  }
}

И исходя из документации, используется только ради одного действия из коробки - генерация аннотаций ORM для модулей.
В целом же - да, наверное имеет смысл смержить модулем Composer Merge Plugin, указанным в документации к битриксу.

Тестирование в 1C Bitrix

По первой части вопроса - подход в курсе рабочий, но (на мой взгляд) противоречит идеологии продукта. Каталог "bitrix" - это штатный функционал CMS. Там находятся базовые модули и компоненты. А свои наработки нужно от него дистанцировать (для того и существует каталог "local").

А по второму вопросу - можно через механизм транзакций. Работает для Oracle, MSSQL, MySQL (для типа таблиц InnoDB). Выглядеть будет примерно так:

SampleTest

<?php

namespace MyProject;

use PHPUnit\Framework\TestCase;
use Bitrix\Main\Application;
use CUser;

class SampleTest extends TestCase
{
	public function testDatabaseWriting(): void
	{
		$email = '[e-mail]';

		$connection = Application::getConnection();
		$connection->StartTransaction();

		$fields = [
			'NAME'              => 'Сергей',
			'LAST_NAME'         => 'Иванов',
			'EMAIL'             => $email,
			'LOGIN'             => 'ivan',
			'LID'               => 'ru',
			'ACTIVE'            => 'Y',
			'GROUP_ID'          => [1],
			'PASSWORD'          => '123456',
			'CONFIRM_PASSWORD'  => '123456'
		];
		$user = new CUser();
		$userId = $user->Add($fields);

		$userIdFromDatabase = 0;
		$filter = ['EMAIL' => $email];
		$dbResult = CUser::GetList(($by='id'), ($order='asc'), $filter);
		if ($record = $dbResult->fetch()) {
			$userIdFromDatabase = $record['ID'];
		}
    
		$connection->rollbackTransaction();
		
		$this->assertEquals($userId, $userIdFromDatabase);
	}
}

Если же используются MySQL MyISAM - то тут ничего разумного в голову не приходит. Только руками подчищать.

Тестирование в 1C Bitrix

действительно, не имеет смысла - убрал ручную автозагрузку и добавил в composer путь к классам. Спасибо