Оглавление

• Исходные данные
• Базовые настройки
• Установка PostgreSQL
• Wireguard
• Файерволл
• Postfix
• Apache
• Docker
• Jenkins
• GitLab
• Установка и лицензирование 1С
• Настройка хранилищ 1С
• Установка Oproxy
• Установка GitSync
• Перенос баз

 

Преамбула

Я выполнял миграцию сервера с одной машины, где установлена CentOS 7, на другой сервер с Ubuntu 24.04.

Я долго не мог решиться на переезд по двум причинам: сложный план работ, можно что-то забыть, а также вероятные проблемы на ровном месте. Данная статья представляет собой, по сути, лог настройки с отдельными комментариями, где у меня возникали проблемы и как они были решены. Надеюсь, кому-то поможет лог (как план работ), скрипты для миграции баз данных, а также решение проблем.

Персональные данные (имена пользователей, имена и адреса серверов, пароли и ключи) удалены или заменены на примеры.

Приведенные команды НЕЛЬЗЯ выполнять копипастом: в них есть специфичные для моей ситуации пути, а также некоторые команды нужно выполнять по отдельности. Вообще лучше не выполнять чужие команды копипастом) Где лично мне нужны были напоминания о том, что нужно поменять что-то - я отметил. Задачу сделать все универсальным я на себя не брал.

Многие команды и, особенно, скрипты, писались Кодексом, поэтому предоставляются "как есть".

 

Исходные данные

На сервере работали такие службы, как:

• Сервер приложений 1С
• Сервер БД PostgreSQL
• Jenkins
• Gitlab
• Сервер хранилищ 1С
• Oproxy для работы с хранилищами
• Apache для доступа к публикациям 1С, Jenkins и Gitlab.

Стояли задачи:

• Выполнить миграцию данных
• Повысить безопасность работы (Максимально исключить открытые вовне порты, организовать VPN; Установить новую ОС с необходимыми обновлениями безопасности вместо той, которая давно снята с поддержки).
• Перенести Jenkins и Gitlab в докер-контейнеры, чтобы изолировать используемые порты (при настройке на старом сервере я хапнул с этим много проблем) и окружение (для Jenkins и для 1C требуются разные версии Java).
• В целом сделать службы более упорядоченными
• Получить доступ к современному ядру системы и актуальным пакетам программ, т.к. на старом сервере был ряд проблем, начиная от устаревшей версии Git (новую можно было получить, но из неофициальных репозиториев и со слишком большими сложностями)

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

• Арендуем аналогичный сервер на месяц;
• Настраиваю его, формирую лог настройки, выполняю тестовую миграцию
• Выполняю чистую установку ОС, настраиваю заново по логу
• Выполняем рабочую миграцию на тестовый сервер, пользователи переходят туда.
• Неделю работаем, смотрим, ничего ли не сломалось и не забыли ли что-то перенести.
• Таким же образом производим второй этап миграции обратно на старый сервер (потому что он дешевле).

 

Базовые настройки

В консоли управления сервером установил пароль root Зашел через git bash с паролем под root Сменил имя хоста:

 hostnamectl set-hostname 1c-dept
 nano /etc/hosts

В открывшемся файле сменил хост на 1c-dept, сохранил, дальше сделал reboot Запустил apt-get upgrade Добавил пользователя

adduser userivan
usermod -aG sudo userivan
#Проверка
groups userivan

Со своего компа выполняю копирование ssh-ключа:

ssh-copy-id -i "/c/Users/ivang/.ssh/id_rsa" userivan@111.111.111.111

Аналогично нужно сделать на старом сервере (чтобы с него копировать данные на новый):

ssh-copy-id -i ~/.ssh/id_rsa userivan@111.111.111.111

Далее подключаюсь по ssh под своим пользователем, отключаю доступ на сервер по паролю и перезапускаю службу ssh

sudo nano /etc/ssh/sshd_config
#Находим PasswordAuthentication, раскомментируем, меняем на yes
sudo systemctl restart ssh

Пробую в другой консоли зайти под рутом, получаю отказ, т.к. по паролю нельзя, а ключ для рута я не задавал. Добавил пользователя usr1cv8. Для запуска конфигуратора в пакетном режиме установил xvfb

sudo apt install xvfb

 

Установка PostgreSQL

На новом сервере:

mkdir ~/Distrib

Скачал пакет Postgresql с сайта 1с. Их там два: патчи и дистрибутив под убунту специально. Там же есть ссылка на инструкция для установки. Копирую оба скачанных ахрива на сервер. На своем компе:

scp postgresql_15.16_1_sources.tar.bz2 userivan@111.111.111.111:~/Distrib
scp postgresql_15.16_1_ubuntu_24.04_x86_64_package.tar.bz2 userivan@111.111.111.111:~/Distrib

Переключаюсь на рута sudo -i и делаю почти по инструкции от 1С, но в папку с темп распаковал оба архива, а не один, как указано:

export DEBIAN_FRONTEND=noninteractive  
apt-get update -y  
apt-get install -y bzip2  
mkdir -p "/tmp/postgresql-distrib-1c" 

tar --extract --directory "/tmp/postgresql-distrib-1c" --file /home/userivan/Distrib/postgresql_15.16_1_sources.tar.bz2

tar --extract --directory "/tmp/postgresql-distrib-1c" --file /home/userivan/Distrib/postgresql_15.16_1_ubuntu_24.04_x86_64_package.tar.bz2

apt-get install -y /tmp/postgresql-distrib-1c/libecpg6_15.16-1.1C_amd64.deb /tmp/postgresql-distrib-1c/libecpg-compat3_15.16-1.1C_amd64.deb /tmp/postgresql-distrib-1c/libpgtypes3_15.16-1.1C_amd64.deb /tmp/postgresql-distrib-1c/libpq5_15.16-1.1C_amd64.deb /tmp/postgresql-distrib-1c/postgresql-client-15_15.16-1.1C_amd64.deb /tmp/postgresql-distrib-1c/postgresql-15_15.16-1.1C_amd64.deb /tmp/postgresql-distrib-1c/postgresql-client-common_*.deb /tmp/postgresql-distrib-1c/postgresql-common_*.deb /tmp/postgresql-distrib-1c/postgresql-common-dev_*.deb

Проверяю версию:

psql --version
# Выдает: psql (PostgreSQL) 15.16 (Ubuntu 15.16-1.1C)

Для корректной сортировки строк в базе требуется установить правильную локаль. Проверил, есть ли русская локаль (ее нет) и создал новую:

locale -a | grep -i ru_RU #проверка ничего не нашла
sudo locale-gen ru_RU.UTF-8
sudo update-locale

Посмотрим созданный по дефолту кластер pgsql и удалим его, тк он на неправильной локали, и создадим новый:

pg_lsclusters
sudo pg_dropcluster --stop 15 main
sudo pg_createcluster --locale=ru_RU.UTF-8 --encoding=UTF8 15 main --start

Проверим, что теперь применились русские настройки:

sudo -u postgres psql -c "show lc_collate;"
sudo -u postgres psql -c "show lc_ctype;"
sudo -u postgres psql -c "show lc_messages;"
sudo -u postgres psql -c "show data_directory;"

Создаю пользователя СУБД (не Linux - его мы создали раньше) для 1С:

sudo -u postgres createuser --createdb --login --pwprompt usr1cv8
#Для того, чтобы пользователь мог создавать базы, ему нужно дать привилегии суперпользователя.
sudo -u postgres psql -c "ALTER USER usr1cv8 WITH SUPERUSER;"

Подключение через сокет должно быть автоматически, но проверяю:

sudo -u postgres psql -c "show unix_socket_directories;"
# unix_socket_directories
#-------------------------
# /var/run/postgresql
#(1 row)
ls -ld /var/run/postgresql
#drwxrwsr-x 2 postgres postgres 100 May 20 17:45 /var/run/postgresql

Все верно. Теперь настроим доступ:

#Ищем месторасположение pg_hba.conf
sudo -u postgres psql -c "show hba_file;"
#              hba_file
# -------------------------------------
# /etc/postgresql/15/main/pg_hba.conf
#(1 row)
sudo nano /etc/postgresql/15/main/pg_hba.conf

Для пользователя 1С нужно добавить строку:

local   all             usr1cv8                                  scram-sha-256

Теперь сделаем override для postgresql.conf, применив рекомендации 1С по настройке PostgreSQL. Сама возможность оверрайда по умолчанию прописана в postgresql.conf в строке:

include_dir = 'conf.d'

Создать файл оверрайда одной командой:

sudo tee /etc/postgresql/15/main/conf.d/1c.conf > /dev/null <<'EOF'
# 1C:Enterprise override for PostgreSQL 15

# Network / local access
listen_addresses = 'localhost'
ssl = off

# Connections
max_connections = 300

# Memory
shared_buffers = 16GB
temp_buffers = 128MB
work_mem = 128MB
maintenance_work_mem = 2GB
effective_cache_size = 48GB

# WAL / commit
fsync = on
synchronous_commit = off
checkpoint_completion_target = 0.9
min_wal_size = 4GB
max_wal_size = 8GB
commit_delay = 1000
commit_siblings = 5

# Background writer / I/O
bgwriter_delay = 20ms
bgwriter_lru_maxpages = 400
bgwriter_lru_multiplier = 4.0
effective_io_concurrency = 2
random_page_cost = 1.2
max_files_per_process = 8000

# Autovacuum
autovacuum = on
autovacuum_max_workers = 4
autovacuum_naptime = 20s

# Planner / statistics
default_statistics_target = 300
from_collapse_limit = 20
join_collapse_limit = 6
geqo = on
geqo_threshold = 12

# 1C compatibility
max_locks_per_transaction = 512
row_security = off
standard_conforming_strings = off
escape_string_warning = off

# Locale / formatting
datestyle = 'iso, dmy'
timezone = 'Europe/Moscow'
log_timezone = 'Europe/Moscow'
lc_messages = 'ru_RU.UTF-8'
lc_monetary = 'ru_RU.UTF-8'
lc_numeric = 'ru_RU.UTF-8'
lc_time = 'ru_RU.UTF-8'
default_text_search_config = 'pg_catalog.russian'
EOF

Проверяем, что оверрайд виден:

sudo pg_conftool 15 main show all

Перезапускаем Постгри:

sudo systemctl restart postgresql

Проверяем, что он запустился. Причем сам postgresql.service может быть status exited, но это лишь обертка. Поэтому нужно проверять конкретный кластер:

sudo systemctl status postgresql@15-main

Проверяем, что локаль реально применилась (везде должно быть ru_RU):

sudo -u postgres psql -c "show shared_buffers;"
sudo -u postgres psql -c "show work_mem;"
sudo -u postgres psql -c "show max_connections;"
sudo -u postgres psql -c "show lc_messages;"
sudo -u postgres psql -c "show default_text_search_config;"

 

Wireguard

sudo apt install -y wireguard-tools

Сгенерировал ключи, установил корректные права доступа

sudo sh -c 'wg genkey | tee /etc/wireguard/server.key | wg pubkey > /etc/wireguard/server.pub'
sudo chmod 600 /etc/wireguard/server.key
#Приватный ключ сервера
sudo cat /etc/wireguard/server.key
#Публичный ключ сервера
sudo cat /etc/wireguard/server.pub

Создаю конфиг

sudo nano /etc/wireguard/wg0.conf

Публичные ключи клиентов нужно предварительно сгенерировать на клиентах, просто через приложение Wireguard VPN

[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = <Приватный ключ сервера>

# включаем маршрутизацию
#PostUp = sysctl -w net.ipv4.ip_forward=1

#Публичные ключи и IP клиентов
[Peer1]
PublicKey = ***
AllowedIPs = 10.10.0.2/32

[Peer2]
PublicKey = ***
AllowedIPs = 10.10.0.3/32

[Peer3]
PublicKey = ***
AllowedIPs = 10.10.0.4/32

Запускаю Wireguard как службу

sudo systemctl enable --now wg-quick@wg0

 

Файерволл

sudo ufw default deny incoming 
sudo ufw default allow outgoing

sudo ufw allow 22/tcp 
sudo ufw allow 51820/udp

sudo ufw enable 
sudo ufw status verbose

#apache
sudo ufw allow 80/tcp  
sudo ufw allow 443/tcp
#Службы 1С на портах 15хх (платформа 27)
sudo ufw allow in on wg0 from 10.10.0.0/24 to 10.10.0.1 port 1540 proto tcp
sudo ufw allow in on wg0 from 10.10.0.0/24 to 10.10.0.1 port 1541 proto tcp
sudo ufw allow in on wg0 from 10.10.0.0/24 to 10.10.0.1 port 1545 proto tcp
sudo ufw allow in on wg0 from 10.10.0.0/24 to 10.10.0.1 port 1560:1591 proto tcp
#SSH-порт гитлаба
sudo ufw allow in on wg0 from 10.10.0.0/24 to 10.10.0.1 port 2222 proto tcp
# Прокси хранилища на порту 8001 
sudo ufw allow in on wg0 from 10.10.0.0/24 to 10.10.0.1 port 8011 proto tcp

 

Postfix

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

sudo apt install -y postfix mailutils

Открывается меню настройки:

1. Выбираем Local only
2. Указываем имя сервера (оставляем как есть)

Если ошиблись, то sudo dpkg-reconfigure postfix Проверим почту:

#send mail
echo "Test mail body" | mail -s "Postfix local test" userivan
#check mail
mail

Прочитать письмо можно по номеру, выйти - q.

 

Apache

У меня есть личное доменное имя, управляемое через Cloudflare. Для временного сервера буду использовать его. В целом это нужно только если мы хотим использовать https. Первым делом в Cloudflare сделал поддомен и направил его на IP сервера, дальше будем работать с 1c.mydomain.ru. Устанавливаем апач:

sudo apt install -y apache2
#Запускаем и ставим в автозагрузку
sudo systemctl enable --now apache2
sudo systemctl status apache2

Проверяем. Если все хорошо, то ставим certbot. ВАЖНО перед получением сертификата нужно отключить проксирование в Cloudflare.

sudo apt update
sudo apt install -y snapd
sudo snap install core
sudo snap refresh core
sudo snap install --classic certbot
sudo ln -sf /snap/bin/certbot /usr/bin/certbot
#Выпускаем сертификат
sudo certbot certonly --webroot \
  -w /var/www/html \
  -d 1c.mydomain.ru
#Certificate is saved at: /etc/letsencrypt/live/1c.mydomain.ru/fullchain.pem
#Key is saved at:         /etc/letsencrypt/live/1c.mydomain.ru/privkey.pem

Проверим таймер автообновления:

systemctl list-timers | grep certbot
#Thu 2026-05-21 07:40:00 MSK            10h -                                      - snap.certbot.renew.timer       snap.certbot.renew.service

Включаем проксирование в Cloudflare и тестируем автообновление:

sudo certbot renew --dry-run

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

Создаем сайт. Он предназначен для доступа к Jenkins и Gitlab по путям https://1c.mydomain.ru/jenkins https://1c.mydomain.ru/gitlab с перенаправлением на специальный порт, который слушается соответствующим приложением. Также он позволяет использовать эту схему для подключения Jenkins агентов (это часть с RewriteEngine).

sudo tee /etc/apache2/sites-available/1c.mydomain.ru.conf > /dev/null <<'EOF'
<VirtualHost *:80>
    ServerName 1c.mydomain.ru

    RewriteEngine On
    RewriteRule ^ https://1c.mydomain.ru%{REQUEST_URI} [R=301,L]
</VirtualHost>

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerName 1c.mydomain.ru
    DocumentRoot /var/www/html

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/1c.mydomain.ru/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/1c.mydomain.ru/privkey.pem

    SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite HIGH:!aNULL:!MD5
    SSLHonorCipherOrder off

    ProxyPreserveHost On
    AllowEncodedSlashes NoDecode

    RequestHeader set X-Forwarded-Proto "https"
    RequestHeader set X-Forwarded-Port "443"
    RequestHeader set X-Forwarded-Ssl "on"

    ProxyPass /gitlab http://127.0.0.1:8090/gitlab
    ProxyPassReverse /gitlab http://127.0.0.1:8090/gitlab

    ProxyPass /jenkins http://127.0.0.1:8091/jenkins nocanon
    ProxyPassReverse /jenkins http://127.0.0.1:8091/jenkins

    RewriteEngine On
    RewriteCond %{HTTP:Upgrade} websocket [NC]
    RewriteCond %{HTTP:Connection} upgrade [NC]
    RewriteRule ^/jenkins/?(.*) ws://127.0.0.1:8091/jenkins/$1 [P,L]

    ErrorLog ${APACHE_LOG_DIR}/1c.mydomain.ru_ssl_error.log
    CustomLog ${APACHE_LOG_DIR}/1c.mydomain.ru_ssl_access.log combined
</VirtualHost>
</IfModule>
EOF

Включаем дополнительные модули:

sudo a2enmod ssl
sudo a2enmod proxy
sudo a2enmod proxy_http
sudo a2enmod proxy_wstunnel
sudo a2enmod rewrite
sudo a2enmod headers
sudo systemctl restart apache2

Удаляем дефолтный сайт и создаем новый, предварительно проверив конфиг

sudo a2dissite 000-default.conf
sudo a2ensite 1c.mydomain.ru.conf
sudo apache2ctl configtest

sudo systemctl reload apache2
sudo systemctl status apache2

Устанавливаем имя сервера:

echo 'ServerName 1c.mydomain.ru' | sudo tee /etc/apache2/conf-available/servername.conf > /dev/null
sudo a2enconf servername

и перезапускаем апач

sudo systemctl reload apache2
sudo systemctl restart apache2
sudo systemctl status apache2

 

Docker

sudo apt install -y ca-certificates curl

Добавить официальный ключ Docker:

sudo install -m 0755 -d /etc/apt/keyrings 
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc 
sudo chmod a+r /etc/apt/keyrings/docker.asc

Добавить официальный репозиторий Docker:

sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

Установить Docker:

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Проверить:

sudo systemctl status docker
docker --version
docker compose version

Создадим пользователя, от имени которого будут запускаться контейнеры. Это, по сути, root права, поэтому под этим пользователем запрещено подключаться к серверу и вообще работать.

sudo adduser --disabled-password --gecos "" dockeruser
sudo usermod -aG docker dockeruser
sudo passwd -l dockeruser

 

Jenkins

Установка

Подготовим каталог Jenkins:

sudo mkdir -p /opt/docker/jenkins
sudo chown -R dockeruser:dockeruser /opt/docker
cd /opt/docker/jenkins

Теперь создаем докер-файл:

sudo -iu dockeruser -- bash -lc 'nano /opt/docker/jenkins/docker-compose.yml'

Содержимое:

services:
  jenkins:
    image: jenkins/jenkins:lts-jdk21
    container_name: jenkins
    restart: unless-stopped

    ports:
      - "127.0.0.1:8091:8080"

    environment:
      - JENKINS_OPTS=--prefix=/jenkins

    extra_hosts:
      - "host.docker.internal:host-gateway"

    volumes:
      - jenkins_home:/var/jenkins_home

volumes:
  jenkins_home:

Важно, что пробрасываем host.docker.internal:host-gateway: в результате докер-контейнер сможет для выполнения задач подключаться к хосту (к нашему серверу) по имени host.docker.internal. Запускаем в сессии пользователя userivan, но команда должна быть выполнена от имени dockeruser:

sudo -iu dockeruser -- bash -lc 'cd /opt/docker/jenkins && docker compose up -d'

Проверяем, отвечает ли Дженкинс локально:

sudo -iu dockeruser -- bash -lc 'cd /opt/docker/jenkins && docker compose ps'
sudo ss -ltnp | grep 8091
curl -I http://127.0.0.1:8091/jenkins
curl -I http://127.0.0.1:8091/jenkins/login

Заходим на сайт Дженкинса и делаем первичную настройку. Пароль можно взять так:

sudo -iu dockeruser -- bash -lc 'docker exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword'

Устанавливаем рекомендуемые плагины. Создаем пользователя Administrator. Подтверждаем предложенный адрес Jenkins https://1c.mydomain.ru/jenkins/

Настройка

Здесь используются ssh ключи, скрипты для пайплайнов и .gitconfig со старого сервера. Если вам требуется просто настроить новый сервер с нуля, то ssh ключи нужно будет просто сгенерировать, .gitconfig настроить в соответствии с требованиями, ну и пайплайны, конечно, тоже индивидуальные.

На новом сервере создадим в домашней папке своего пользователя каталог для файлов jenkins со старого сервера.

mkdir -p ~/jenkins_files/.ssh ~/jenkins_files/job_scripts ~/jenkins_files/GitSyncTempDir

Со старого сервера копируем файлы

sudo scp -p -i /home/userivan-old/.ssh/id_rsa /home/jenkins/.gitconfig userivan@111.111.111.111:~/jenkins_files/

sudo scp -p -i /home/userivan-old/.ssh/id_rsa /home/jenkins/.ssh/id_rsa /home/jenkins/.ssh/id_rsa.pub userivan@111.111.111.111:~/jenkins_files/.ssh/

sudo scp -p -i /home/userivan-old/.ssh/id_rsa \
/home/jenkins/gitsync_unload_extension.sh \
/home/jenkins/gitsync_unload_main.sh \
userivan@111.111.111.111:~/jenkins_files/job_scripts/

На новом сервере создаем пользователя и раскладываем ему файлы:

sudo adduser --disabled-password --gecos "" jenkins

sudo install -d -m 700 -o jenkins -g jenkins /home/jenkins/.ssh
sudo install -d -m 755 -o jenkins -g jenkins /home/jenkins/job_scripts
sudo install -d -m 755 -o jenkins -g jenkins /home/jenkins/GitSyncTempDir

sudo cp -a /home/userivan/jenkins_files/.gitconfig /home/jenkins/
sudo cp -a /home/userivan/jenkins_files/.ssh/. /home/jenkins/.ssh/
sudo cp -a /home/userivan/jenkins_files/job_scripts/. /home/jenkins/job_scripts/

sudo chown -R jenkins:jenkins /home/jenkins
sudo chmod 700 /home/jenkins/.ssh
sudo chmod 600 /home/jenkins/.ssh/id_rsa
sudo chmod 644 /home/jenkins/.ssh/id_rsa.pub
sudo chmod 644 /home/jenkins/.gitconfig
sudo bash -lc 'chmod 755 /home/jenkins/job_scripts/*.sh'

Стратегия использования ключей такая:

1. У пользователя Linux jenkins, и у пользователя, работающего в докер-контейнере jenkins, будут одинаковые ssh-ключи.
2. Соответственно, чтобы изнутри докер-контейнера пользователь мог подключаться к хосту, то пользователю Linux jenkins необходимо в ~/.ssh/authorized_keys добавить публичную часть ключа.
3. В known_hosts внутри докер-контейнера нужно добавить fingerprint хоста

Добавим ssh ключ пользователя jenkins к нему же в authorized_keys, чтобы докер-контейнер мог подключаться к пользователю jenkins хоста с тем же ключом:

sudo -u jenkins touch /home/jenkins/.ssh/authorized_keys
sudo bash -lc 'cat /home/jenkins/.ssh/id_rsa.pub >> /home/jenkins/.ssh/authorized_keys'
sudo chown jenkins:jenkins /home/jenkins/.ssh/authorized_keys
sudo chmod 600 /home/jenkins/.ssh/authorized_keys

Теперь настраиваем ключи внутри докер-контейнера:

sudo docker exec -u 0 jenkins mkdir -p /var/jenkins_home/.ssh

sudo docker cp /home/jenkins/.ssh/id_rsa jenkins:/var/jenkins_home/.ssh/id_rsa
sudo docker cp /home/jenkins/.ssh/id_rsa.pub jenkins:/var/jenkins_home/.ssh/id_rsa.pub

sudo docker exec -u 0 jenkins sh -lc 'chown -R jenkins:jenkins /var/jenkins_home/.ssh && chmod 700 /var/jenkins_home/.ssh && chmod 600 /var/jenkins_home/.ssh/id_rsa && chmod 644 /var/jenkins_home/.ssh/id_rsa.pub'

Проверим, что имя хоста резолвится из контейнера:

sudo docker exec jenkins sh -lc 'getent hosts host.docker.internal' 
#172.17.0.1      host.docker.internal

Добавим ключ хоста в known_hosts докер-контейнера:

sudo docker exec jenkins sh -lc 'ssh-keyscan -H host.docker.internal >> /var/jenkins_home/.ssh/known_hosts && chmod 644 /var/jenkins_home/.ssh/known_hosts'

И проверяем:

sudo docker exec jenkins sh -lc 'ssh -i /var/jenkins_home/.ssh/id_rsa jenkins@host.docker.internal hostname'
#1c-dept

 

GitLab

Установка

Создадим каталоги:

sudo mkdir -p /opt/docker/gitlab/{config,logs,data}
sudo chown -R dockeruser:dockeruser /opt/docker/gitlab

Добавляем докер-файл. Важно: при переносе со старого сервера нужно уточнить, какой дистрибутив гитлаба использовался, и использовать точно такой же. В моем случае - это 17.7.7-ce.

sudo tee /opt/docker/gitlab/docker-compose.yml > /dev/null <<'EOF'
services:
  gitlab:
    image: gitlab/gitlab-ce:17.7.7-ce.0
    container_name: gitlab
    hostname: 1c.mydomain.ru
    restart: unless-stopped
    shm_size: "1g"

    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'https://1c.mydomain.ru/gitlab'

        letsencrypt['enable'] = false

        nginx['listen_port'] = 80
        nginx['listen_https'] = false

        gitlab_rails['gitlab_shell_ssh_port'] = 2222
        gitlab_rails['trusted_proxies'] = ['127.0.0.1']

    ports:
      - "127.0.0.1:8090:80"
      - "10.10.0.1:2222:22"

    volumes:
      - ./config:/etc/gitlab
      - ./logs:/var/log/gitlab
      - ./data:/var/opt/gitlab
EOF

Запускаем и можно проверить:

sudo -iu dockeruser -- bash -lc 'cd /opt/docker/gitlab && docker compose up -d'
sudo -iu dockeruser -- bash -lc 'cd /opt/docker/gitlab && docker compose ps'
sudo -iu dockeruser -- bash -lc 'cd /opt/docker/gitlab && docker compose ps'

Если все ок, то логин по умолчанию root, а пароль можно посмотреть так:

sudo -iu dockeruser -- bash -lc 'docker exec gitlab cat /etc/gitlab/initial_root_password'

Проверяем подключение к gitlab из Jenkins и добавляем ключ хоста в known_hosts:

sudo -u jenkins ssh -T -p 2222 git@10.10.0.1

Поскольку содержимое БД GitLab еще не перенесли (где добавлены ключи разработчиков), то ожидаем сообщение permission denied (public_key) - это означает, что соединение есть, но ключ не подошел (и не должен был).

Перенос

На старом сервере сделать backup

sudo bash -lc 'rm -rf /var/opt/gitlab/backups/*'
sudo gitlab-backup create

Копируем файлы НЕ ЗАБЫТЬ ПОМЕНЯТЬ ИМЯ БЕКАПА:

sudo ls /var/opt/gitlab/backups/
sudo scp -i /home/userivan-old/.ssh/id_rsa /var/opt/gitlab/backups/1779461166_2026_05_22_17.7.7_gitlab_backup.tar userivan@111.111.111.111:~
sudo scp -i /home/userivan-old/.ssh/id_rsa /etc/gitlab/gitlab-secrets.json userivan@111.111.111.111:~

На новом сервере перемещаем скачанное в нужные папки и устанавливаем права НЕ ЗАБЫТЬ ПОМЕНЯТЬ ИМЯ БЕКАПА:

sudo mv ~/1779461166_2026_05_22_17.7.7_gitlab_backup.tar /opt/docker/gitlab/data/backups/
sudo mv ~/gitlab-secrets.json /opt/docker/gitlab/config/

sudo -iu dockeruser -- bash -lc 'docker exec -u 0 gitlab bash -lc "
chown root:root /etc/gitlab/gitlab-secrets.json &&
chmod 600 /etc/gitlab/gitlab-secrets.json &&
chown -R git:git /var/opt/gitlab/backups &&
chmod 700 /var/opt/gitlab/backups &&
chmod 600 /var/opt/gitlab/backups/*.tar
"'

Убедимся, что контейнер жив:

sudo -iu dockeruser -- bash -lc 'docker exec gitlab gitlab-rake gitlab:env:info'

Потом остановить процессы, которые держат БД, но не весь контейнер:

sudo -iu dockeruser -- bash -lc 'docker exec gitlab gitlab-ctl stop puma' 
sudo -iu dockeruser -- bash -lc 'docker exec gitlab gitlab-ctl stop sidekiq'

Проверить:

sudo -iu dockeruser -- bash -lc 'docker exec gitlab gitlab-ctl status'

Запустиv restore. Нужен именно backup-id, то есть часть имени файла до

_gitlab_backup.tar

Пример:

BackupId=1779461166_2026_05_22_17.7.7 
sudo -iu dockeruser -- bash -lc "docker exec -e GITLAB_ASSUME_YES=1 -t gitlab gitlab-backup restore BACKUP=${BackupId}"

Если restore пройдет успешно, затем:

sudo -iu dockeruser -- bash -lc 'docker exec gitlab gitlab-ctl reconfigure' 
sudo -iu dockeruser -- bash -lc 'docker exec gitlab gitlab-ctl restart'

Проверка после восстановления

sudo -iu dockeruser -- bash -lc 'docker exec gitlab gitlab-rake gitlab:check SANITIZE=true' 
sudo -iu dockeruser -- bash -lc 'docker exec gitlab gitlab-rake gitlab:env:info'

 

Установка технологической платформы

Качаю с releases сборку в виде zip-архива Технологическая платформа 1С:Предприятия (64-bit) для Linux

Передаю на сервер в свою домашнюю папку:

scp server64_8_3_27_1688.zip userivan@111.111.111.111:~/Distrib/server64_8_3_27_1688.zip

Разархивирую

unzip /home/userivan/Distrib/server64_8_3_27_1688.zip -d /home/userivan/Distrib/1s-distr

Устанавливаю

sudo /home/userivan/Distrib/1s-distr/installAsRoot

Выбираю все нужные компоненты, включая Liberica JRE (она нужна для утилиты лицензирования). После установки шаблоны служб копирую в системд и запускаю:

sudo cp /opt/1cv8/x86_64/8.3.27.1688/srv1cv8-8.3.27.1688@.service /etc/systemd/system/
sudo cp /opt/1cv8/x86_64/8.3.27.1688/ras-8.3.27.1688.service /etc/systemd/system/

Запускаем службы:

sudo systemctl daemon-reload
sudo systemctl enable --now srv1cv8-8.3.27.1688@default
sudo systemctl enable --now ras-8.3.27.1688

Так как порты в файерволле уже открыты, подключаюсь со своего компьютера по Wireguard и добавляю сервер 1с на 10.10.0.1. Кластер по умолчанию удаляю, т.к. он создался с локальным именем сервера, которое система не может прочитать с удаленной панели. Пересоздаю с IP адресом 10.10.0.1 и портом 1541.

 

Лицензирование

Несколько моментов про лицензии, которые лично для меня постоянно ускользают из понимания.

1. Если запускаем экземпляр сервера на том же компьютере, на котором зарегистрирована лицензия, то можно запускать сколько угодно экземпляров сервера, в том числе - на разных платформах.
2. Если хотим запустить экземпляр сервера на виртуалке или докер-контейнере, то каждый экземпляр будет расходовать отдельную лицензию.
3. Лицензия на запуск клиентского сеанса расходуются на каждый сеанс, поэтому имеет смысл вынести их на отдельный компьютер/виртуалку, чтобы на рабочий сервер можно было бы докидывать ресурсов без риска потери лицензий. Но у меня все будет на одном сервере.
4. Очень важно! Лицензирование через графический интерфейс (когда при первом запуске 1С возникает окно с лицензией) привязывает лицензию к клиентскому компьютеру. Лицензировать таким образом удаленный сервер невозможно! Поэтому для установки лицензии на сервер без графического интерфейса будем использовать утилиту ring.
5. От предыдущего админа мне достался файл с регистрационными номерами и пин-кодами лицензий, но без пояснения, какие пин-коды уже использованы. Это можно запросить в 1С. Для того, чтобы запросить статус пин-кодов в письме, нужен только регистрационный номер. Важно, что у меня в рамках одной лицензии и одного рег. номера была и лицензия на сервер, и лицензия на клиент. 1С по умолчанию почему-то присылает только данные по клиентской части, а по серверной нужно запрашивать явно.
6. Если пинкоды закончились (активирован третий из трех), то можно в письме же и запросить новый, предоставив полный набор цифр активного пин-кода.
7. На Linux лицензии хранятся по умолчанию в /var/1C/licenses и файлы лицензий должны быть доступны пользователю, под которым работает 1С.

Если у вас зарегистрирована проф/корп версия продукта, то на портале самообслуживания можно активировать тестовую лицензию на сервер, которая будет действовать две недели. https://portal.1c.ru/software/registration - раздел "Получить бесплатно".

 

Установка ring

На новом сервере скачиваю утилиту ring

cd ~/Distrib
wget https://dl02.1c.ru/public/file/get/bc063de8-9653-4c8f-ba78-c18973c407d1

Распаковываю и устанавливаю

tar -xf 1c_enterprise_license_tools_0.15.0_2_linux_x86_64.tar.gz
sudo ./1ce-installer-cli install

Могут возникнуть проблемы с указанием Java. Поскольку на этапе установки платформы мы ее ставили, то для данного сеанса можно добавить в PATH:

export JAVA_HOME=/opt/1cv8/x86_64/8.3.27.1688/jre
export PATH="$JAVA_HOME/bin:$PATH"

При необходимости произвести установку и на старом сервере. Это потребуется только для получения регистрационных данных владельца.

 

Лицензии на старом сервере

В первую очередь нужно получить регистрационные данные владельца лицензии. Сначала получим перечень лицензий:

ring license list

Однако для текущего пользователя не доступен каталог лицензий, а для root неизвестно расположение ring и java. Поэтому сначала найдем путь к ring, затем укажем его и путь к java:

command -v ring
#/opt/1C/1CE/components/1c-enterprise-ring-0.19.5+12-x86_64/ring
sudo env JAVA_HOME="$JAVA_HOME" \
  /opt/1C/1CE/components/1c-enterprise-ring-0.19.5+12-x86_64/ring license list

Система вернет перечень лицензий, где сначала идет имя лицензии в стандартном виде (пинкод-регномер). Вот эти имена нам и нужны. Далее используем ring license info для получения регистрационных данных:

sudo env JAVA_HOME="$JAVA_HOME"   /opt/1C/1CE/components/1c-enterprise-ring-0.19.5+12-x86_64/ring license info <Имя лицензии>

Далее необходимо удалить лицензии на старом сервере (это официальная рекомендация 1С - иначе обе могут быть заблокированы). Я их не удалял, а сменил владельца так, чтобы сервер не мог их использовать. Например:

sudo chown -R userivan-old:userivan-old /var/1C/licenses

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

 

Лицензии на новом сервере

Выполняем команду как в справке 1С, подставляя полученные на предыдущем шаге данные (или если они у вас были). Важные моменты:

1. Если страну выбирали из списка - то значение отличается от представления. Например, нужно писать не Российская Федерация, а RU.
2. Вне зависимости от "необязательности" полей, нужно указать все, которые были указаны при первичной активации, иначе будет ошибка о несовпадении.

RING_BIN="$(command -v ring)"
sudo env JAVA_HOME=/opt/1cv8/x86_64/8.3.27.1688/jre \
  PATH="$JAVA_HOME/bin:$PATH" \
  "$RING_BIN" license activate \
  --first-name 'Иванов' \
  --middle-name 'Иван' \
  --last-name 'Иванович' \
  --email 'ivan@romaska.ru' \
  --company 'ООО "Ромашка"' \
  --country 'RU' \
  --zip-code '111111' \
  --region 'Москва' \
  --town 'Москва' \
  --street 'Тверская ул' \
  --house '1' \
  --apartment '1' \
  --serial '800000000' \
  --pin '111-111-111-111-111' \
  --previous-pin '111-111-111-111-111' \
  --validate

Устанавливаем корректные права на лицензии, чтобы сервер мог их прочитать:

sudo chown root:grp1cv8 /var/1C/licenses
sudo chmod 775 /var/1C/licenses
sudo bash -lc 'chown root:grp1cv8 /var/1C/licenses/*.lic'
sudo bash -lc 'chmod 664 /var/1C/licenses/*.lic'

При запуске базы 1С лично меня встретил ошибкой:

HTTP: Forbidden  
Ошибка при выполнении запроса POST к ресурсу /e1cib/login:  
по причине:  
Операция не может быть выполнена с текущим составом лицензий.  
Сервер 1С:Предприятия использует лицензию для разработчиков. Запуск клиентского приложения Тонкий клиент с лицензией ПРОФ или КОРП запрещён. Обратитесь к техническому специалисту для решения вопросов получения и установки лицензий уровня ПРОФ или КОРП.

Помогло перезапустить сервер и пересоздать кластер.

 

Настройка хранилищ 1С

Создал папку хранилища и установил права сначала для своего пользователя, чтобы туда перенести бекап:

sudo mkdir -p /var/1C/store/extension_git /var/1C/store/main_git
sudo chown userivan:userivan /var/1C/store/

На старом сервере выполняю: сначала скопирую каталог с хранилищами, потом удалю оттуда каталоги git, а потом заархивирую.

cd /var/1C/
cp -a store store_backup
cd /var/1C/store_backup
# Почистить лишнее 
cd /var/1C/
#Перед продолжением переключимся в tmux, чтобы сеанс не прервался
tmux
tar -czvf store.tar.gz ./store_backup

Копирую на новый сервер (тоже в tmux продолжаем):

scp store.tar.gz userivan@111.111.111.111:/var/1C/store

Разархивирую:

sudo tar -xzf /var/1C/store/store.tar.gz -C /var/1C/store/
sudo rsync -av --remove-source-files /var/1C/store/store_backup/ /var/1C/store/
sudo find /var/1C/store/store_backup -type d -empty -delete
sudo rm /var/1C/store/store.tar.gz

Меняю права на целевые:

sudo groupadd -f 1s_store
sudo usermod -aG 1s_store usr1cv8
sudo usermod -aG 1s_store jenkins

sudo setfacl -m g:1s_store:rx /var/1C

sudo chgrp -R 1s_store /var/1C/store
sudo find /var/1C/store -type d -exec chmod 2770 {} \;
sudo chmod -R g+rwX /var/1C/store

sudo chown -R jenkins:1s_store /var/1C/store/extension_git /var/1C/store/main_git
sudo find /var/1C/store/extension_git /var/1C/store/main_git -type d -exec chmod 2770 {} \;
sudo chmod -R g+rwX /var/1C/store/extension_git /var/1C/store/main_git

Создание службы сервера хранилищ. Здесь важно указать корректный LimitNOFILE. Если он будет недостаточен, то подключение к хранилищу уровня ERP будет вызывать ошибку "too many open files"

StoreName=store1
StorePort=8001
PlatformVer=8.3.27.1688

sudo mkdir -p /var/1C/store/$StoreName

sudo tee /etc/systemd/system/crserver-${StoreName,,}.service > /dev/null <<EOF
[Unit]
Description=1C Configuration Repository Server (${StoreName})
After=network.target

[Service]
Type=simple
User=usr1cv8
Group=grp1cv8
LimitNOFILE=524288
ExecStart=/opt/1cv8/x86_64/${PlatformVer}/crserver -port ${StorePort} -d /var/1C/store/${StoreName}
Restart=always
RestartSec=1

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now crserver-${StoreName,,}.service
sudo systemctl status crserver-${StoreName,,}.service

 

Установка Oproxy

Если используется. У меня в VPN опубликован порт Oproxy, который уже внутри сервера перенаправляется в порт сервера хранилищ. Если вам не нужен Oproxy, то при настройке файерволла нужно опубликовать порт сервера хранилищ. Установим OneScript. Скачаем пакет и установим:

cd ~/Distrib/
wget https://oscript.io/downloads/lts/x64/onescript-engine_1.9.4_all.deb
sudo apt install -y ./onescript-engine_1.9.4_all.deb
sudo opm install oproxy

Создаем каталоги:

sudo -u usr1cv8 mkdir /home/usr1cv8/Oproxy

Настраиваем конфиг:

su usr1cv8
cd ~/Oproxy
oproxy init
nano ПроверкиПроксиСервера.os
#Вводим файл c требуемыми настройками

Выходим из usr1cv8. Теперь создадим службу прокси хранилища:

sudo nano /etc/systemd/system/oproxy-mes-reference.service
#Вводим файл
sudo systemctl daemon-reload
sudo systemctl enable --now oproxy-mes-reference.service
systemctl status oproxy-mes-reference.service

 

Установка GitSync

sudo opm install gitsync

Поскольку папки Gitsync у нас уже выложены в Gitlab, просто скачаем их в уже подготовленные на моменте создания каталогов хранилищ 1С директории. Важно: адрес из веб-интерфейса репозитория в гитлабе по ssh надо менять на 10.10.0.1, т.к. gitlab слушает только интерфейс wg0

sudo -u jenkins bash -lc 'GIT_SSH_COMMAND="ssh -o StrictHostKeyChecking=accept-new" git clone ssh://git@10.10.0.1:2222/group/extension-project.git /var/1C/store/extension_git'
sudo -u jenkins bash -lc 'GIT_SSH_COMMAND="ssh -o StrictHostKeyChecking=accept-new" git clone ssh://git@10.10.0.1:2222/group/main-project.git /var/1C/store/main_git'

Переключаемся на ветку develop в обоих репозиториях:

cd /var/1C/store/extension_git
sudo -u jenkins git checkout develop
cd /var/1C/store/main_git
sudo -u jenkins git checkout develop

 

Перенос баз

Используются приложенные скрипты. Стратегия следующая (можно ее использовать, чтобы сгенерировать свои скрипты с нуля, а не разбираться в прикрепленных):

1. В yaml указываем настройки, а также перечень баз (имена как в СУБД);

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

3. На старом сервере запускаем backup_shipper, он делает по очереди для каждой базы из списка:

1. Дамп;
2. Разбиение файла на заданный объем (у меня 10 GB)
3. Передачу на новый сервер, проверку по контрольной сумме, что передача успешна
4. Отправку на новый сервер json с тем, что такая-то база готова к рестору
5. Удаляет выгруженные и успешно отправленные файлы для очистки места
6. При ошибке делает еще одну попытку выгрузки.
7. При успехе добавляет в лог базу в перечень успешно выгруженных, при ошибке - в список неуспешных.

4. Рестор на новом сервере:

1. Ждет сообщения, что база со старого сервера передана в полном объеме;
2. Выполняет рестор и проверку;
3. В случае успешного рестора удаляет бекап для освобождения места
4. При успехе добавляет в лог базу в перечень успешно восстановленных, при ошибке - в список неуспешных.

Подготовка

На своем компьютере редактирую yaml с настройками, затем копирую на оба сервера:

scp pg_backup_common.py pg_backup_pipeline.example.yaml pg_backup_shipper.py userivan-old@old-server.net:~

scp pg_backup_common.py pg_backup_pipeline.example.yaml pg_restore_from_queue.py userivan@111.111.111.111:~/pg_backup_queue

На новом сервере:

sudo mkdir -p /home/userivan/pg_backup_queue
sudo chown -R userivan:userivan /home/userivan/pg_backup_queue
sudo chmod 755 /home/userivan
sudo chmod 755 /home/userivan/pg_backup_queue
sudo -u postgres psql -h /var/run/postgresql -p 5432 -U postgres -d postgres -c "select current_user, version();"
sudo setfacl -R -m u:postgres:rwX /home/userivan/pg_backup_queue
sudo setfacl -R -d -m u:postgres:rwX /home/userivan/pg_backup_queue
getfacl /home/userivan/pg_backup_queue

На старом сервере:

 mkdir -p /home/userivan-old/pg_backup_shipper_work

 

Выполнение

На старом сервере:

tmux
python3 ~/pg_backup_shipper.py ~/pg_backup_pipeline.example.yaml 2>&1 | tee /home/userivan-old/pg_backup_shipper_work/backup_run.log

на новом сервере:

tmux
sudo -u postgres python3 ~/pg_backup_queue/pg_restore_from_queue.py ~/pg_backup_queue/pg_backup_pipeline.example.yaml 2>&1 | tee /home/userivan/pg_backup_queue/restore_run.log