https://infostart.ru/1c/articles/810851/

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

Создадим директорию для нашего проекта и скачаем в неё дистрибутив 1С Сервер для Linux: https://releases.1c.ru -> Технологическая платформа 8.3 -> Cервер 1С:Предприятия (64-bit) для DEB-based Linux-систем Скачается файл с расширением .tar.gz - переименуем его в deb64.tar.gz.

Создадим файл с настройками подключения к 1С: default.vrd

Я привожу пример минимального vrd файла в котором по умолчанию опубликованы все веб-сервисы, все http сервисы и стандартный REST интерфейс (OData).

<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
		xmlns:xs="http://www.w3.org/2001/XMLSchema"
		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
		base="/ut114"
		ib="Srvr=serverl;Ref=ut114;">
	<standardOdata enable="false"
			reuseSessions="autouse"
			sessionMaxAge="20"
			poolSize="10"
			poolTimeout="5"/>
	<analytics enable="true"/>
</point>

Обратите внимание на строку подключения, замените имя сервера 1С (Serv1C) и имя информационной базы (BuhBase) на свои. Если вы ранее уже публиковали свою базу на веб-сервере (не важно на каком: IIS или Apache, Windows или Linux, с помощью конфигуратор или с помощью webinst), у вас точно должен быть .vrd файл, поищите в публичных директориях веб-сервера и используйте его.

Возьмём стандартный конфиг от Apache (httpd.conf) и добавим к нему несколько строк в конец (полный пример: https://github.com/pqr/docker-apache-1c-example/blob/master/httpd.conf)

LoadModule _1cws_module /opt/1cv8/i386/8.3.18.1741/wsap24.so

# 1c publication
Alias "/BuhBase" "/usr/local/apache2/htdocs/ut114/"
<Directory "/usr/local/apache2/htdocs/ut114/">
    AllowOverride All
    Options None
    Require all granted
    SetHandler 1c-application
    ManagedApplicationDescriptor "/usr/local/apache2/htdocs/ut114/default.vrd"
</Directory>

Таким образом мы указываем веб-северу, что запросы по пути /BuhBase нужно обслуживать с помощью обработчика (SetHandler) 1c-application. Тут же указывается и путь к default.vrd. На данном этапе всех этих путей пока нет (и не будет, они будут внутри Docker контейнера).

Создадим файл с именем Dockerfile (без расширения) со следующим содержанием:

FROM httpd:2.4
# Данный образ базируется на стандартном образе Debian+Apache 2.4: https://store.docker.com/images/httpd

# Копируем дистрибутив в директорию dist
COPY deb64.tar.gz /dist/deb64.tar.gz

# Разархивируем дистрибутив
RUN tar -xzf /dist/deb64.tar.gz -C /dist \
  # и устанавливаем пакеты 1С в систему внутри контейнера
  && dpkg -i /dist/*.deb \
  # и тут же удаляем исходные deb файлы дистрибутива, которые нам уже не нужны
  && rm /dist/*.deb

# Копируем внутрь контейнера заранее подготовленный конфиг от Apache
COPY httpd.conf /usr/local/apache2/conf/httpd.conf

# Копируем внутрь контейнера заранее подготовленный конфиг с настройками подключения к серверу 1С
COPY default.vrd /usr/local/apache2/htdocs/BuhBase/default.vrd

Собираем образ командой:

docker build -t my-apache-1c . Опция -t my-apache-1c присваивает собранному образу имя, чтобы в дальнейшем его было удобнее запуcкать. Если не указать -t, то запускать придётся по сгенерированному уникальному ID образа, что не очень удобно.

Также обратите внимание, что в конце идёт пробел и точка. Эта точка обязательна - это так называемый «контекст». В данном случае мы указываем, что контекстом является текущая директория. Более подробно, что такое контекст и зачем он нужен подробно описано в документации: https://docs.docker.com/engine/reference/builder/

Запускаем контейнер из только что созданного образа командой:

docker run --add-host Serv1C:192.168.1.15 --publish 80:80 my-apache-1c Разберём эту строку по частям:

--add-host Serv1C:192.168.1.15 – здесь мы явно указали докеру, что за именем сервера Serv1C скрывается IP адрес 192.168.1.15 (подставьте свои значения). Имя сервера Serv1C мы использовали выше в default.vrd. Этот эквивалентно тому, как если бы мы прописали эту связь в знаменитый hosts файл. Но внутри контейнера нельзя поправить hosts файл, нужно действовать через параметр командной строки --add-host.

А почему бы сразу не указать IP адрес в default.vrd? Я пробовал, но при проверке в браузере платформа 1С выдавала ошибку и, честно говоря, я не разобрался в проблеме. При подключении по имени хоста (Serv1C) проблем не было.

--publish 80:80 – сообщаем докеру, запросы к хост-машине на порт 80 нужно перенаправлять в контейнер на порт 80 (внутри контейнера слушает Apache). Иногда на хост-машине порт 80 может быть уже занят, например, на этом же Linux сервере запущен какой-то сайт или на машине разработчика стоит локальный веб-сервер, тогда делаем так: --publish <любой свободный порт на хост-машине>:80, например: --publish 8000:80

Последним параметром идёт имя образа (my-apache-1c) на основе которого запускать контейнер. Образ с таким именем мы уже создали на предыдущем шаге.

После запуска этой команды в окне терминала появятся логи процесса Apache. Терминал не закрываем. Если закрыть, контейнер будет остановлен.

Проверяем. Сначала проверяем Apache в целом: http://localhost – должны увидеть сообщение «It Works!»

Почему localhost? Мы сейчас находимся на своей собственной машине (на компьютере разработчика) где запустили Docker контейнер, соответственно для нас он запущен локально.

Если все эксперименты проводятся сразу на Linux сервере, то пробовать нужно, соответственно, по адресу Linux сервера, например, http://192.168.1.10 или http://linux-host

Если при запуске контейнера был указан какой-то особый порт для хост-машины, то проверять нужно на нём, например, http://localhost:8000

Далее проверим как открывается пользовательский веб-интерфейс информационной базы: http://localhost/BuhBase/

Проверим стандартный REST интерфейс (OData): http://localhost/BuhBase/odata/standard.odata/

Попробуем какой-нибудь веб-сервис (если в конфигурации такие есть): http://localhost/BuhBase/ws/MyWebService?wsdl

Всё должно отработать!

Теперь можно останавливать контейнер: Ctrl+C

Мы только что развернули Apache с модулем 1С в Docker контейнере на локальной машине (на машине разработчика). На деле это всё должно крутиться где-то на специально отведённом Linux сервере в виде демона.

Удобнее всего запускать контейнер на сервере с помощью утилиты docker-compose. Но для начала протестируем этот docker-compose опять же на локальной машине.

Устанавливаем docker-compose: https://docs.docker.com/compose/install/

Всё в той же директории проекта (где у нас уже есть Dockerfile, httpd.conf, и др.) создаём файл docker-compose.yml:

version: '3.4'
services:
  apache-1c:
    build: .
    restart: always
    ports:
      - 80:80
    extra_hosts:
      - "Serv1C:192.168.1.15"

По сути здесь всё те же параметры, которые мы передавали в команду docker run.

Отличий три:

Мы больше не придумываем и не указываем имя для нашего образа типа (my-apache-1c), вместо этого используем параметр build: . , т.е. docker-compose будет собирать образ на основе текущей директории (помните про контекст?) и тут же запускать контейнер на основе собранного образа restart: always - если по каким-то причинам Apache упадёт или весь сервер перезагрузится, то Docker автоматически перезапустит контейнер extra_hosts - это тоже самое, что и --add-host в параметрах команды docker run. Да, есть некая неконсистентность. И запускаем контейнер с помощью новой для нас команды:

docker-compose up -d Контейнер должен запуститься и уйти в фоновый режим (флаг -d). Проверяем все адреса в браузере как на предыдущем шаге.

Останавливаем контейнер (эту команду нужно выполнять в терминале, находясь в директории проекта):

docker-compose down

В реальности, пока мы тестировали сборку образов, меняли настройки, запускали контейнеры, мы наверняка прошли по шагам 3-7 много раз. При этом docker не удаляет с жесткого диска старые версии образов и контейнеров, они копились всё это время и теперь занимают место. Пришло время прибраться на машине (подробности в документации https://docs.docker.com/config/pruning/)

docker system prune