Разворачиваем узлы CI через Vagrant, строим сеть из виртуальных машин. Цикл "Многопоточный CI для 1С c Packer, Vagrant и Jenkins", часть 3

Публикация № 1205450

Методология - DevOps

CI Vagrant Linux Ubuntu QA Automation Тестирование

Разворачиваем инфраструктуру для CI из образов виртуальных машин.

 

Схема конфигурации узлов

Расположение Vagrantfile

Структура Vagrantfile

Параметры взаимодействия с виртуальной машиной

Настройка ресурсов, выделяемых машине

Настройка сети

Изменение имени машины, обработка файлов сервера 1С

Прочие действия по конфигурированию в Vagrantfile

Специфичные для каждой машины параметры

Командные файлы запуска

Удаление созданной виртуальной машины

Итоги и проверка результата

Другие части цикла "Многопоточный CI-контур для 1С":

1.  Описание системы и обзор инструментария

2.  Собираем образ виртуальной машины с PostgreSQL и платформой 1С

4.  Jenkins: конфигурируем сервер и подключаем к нему виртуальные машины

5. Пайплайны Jenkins - программирование и настройка. Загружаемые модули

 

 

В прошлой части мы разработали механизм сборки образов виртуальных машин с необходимым программным обеспечением для тестирования клиент-серверных баз 1С. В этот раз мы разберёмся, как из этих образов развернуть необходимое нам количество машин для их работы в качестве узлов CI-контура и обеспечить их уникальную идентификацию в сети. Иными словами, построим сеть из виртуальных машин, развёрнутых из одного или нескольких разных образов Vagrant.

Если Вы предпочли не собирать собственный образ машины через Packer, а решили загрузить уже готовый из облака HashiCorp, то всё написанное далее также будет справедливо, поскольку относится к возможностям именно Vagrant и не зависит от того как именно собран образ. Разумеется, если образ не собирался самостоятельно, то в нём не будет платформы 1С и специальной версии PostgreSQL для 1С - и их нужно будет установить уже после развёртывания.

 

Схема конфигурации узлов

 

Мы уже использовали команду "vagrant up" для запуска виртуальной машины с настройками, заданными в файле Vagrantfile. И в этот раз предстоит сделать то же самое. Но в этот раз управляющий запуском Vagrantfile должен обеспечить настройку виртуальной машины таким образом, чтобы она могла:

  • Подключаться к главному узлу CI-сервера. В нашем случае это Jenkins на хостовой машине.
  • Получать от него команды и выполнять как задачи по эмуляции интерактивных действий пользователя, так и служебные задачи развертывания баз, выгрузки данных из баз 1С и хранилища конфигураций.
  • Загружать необходимые для этого файлы с хостовой машины. И наоборот, размещать результаты своей работы на хостовой машине.

Для этого нам предстоит:

  • Выделить ресурсы виртуальной машине в соответствии с возможностями хостовой машины.
  • Подключить общий для всех виртуальных машин каталог, примонтировав его с хостовой машины.
  • Установить разрешение экрана, пригодное для запуска сценарных тестов на 1С.
  • Загрузить недостающие конфигурационные файлы с хостовой машины.
  • Настроить автозапуск агента CI-сервера, его подключение к мастер-узлу, находящемуся на хостовой машине, и обновление агента при обновлении самого сервера.

 

Также мы обеспечим связь виртуальных машин друг с другом и с внешним окружением через bridge-подключение к физической сетевой карте. При этом необходимо избежать конфликта IP-адресов и присвоить машинам уникальные имена (имена хостов). Такая настройка позволит добиться нескольких целей:

  • Можно будет подключиться с любой машины в подсети по ssh и выполнить мониторинг системы, при этом не придется запускать никаких окон в пользовательском сеансе, выполняющем тестирование. Это позволяет работать с со сборочным узлом и не мешать при этом процессам сценарного тестирования 1С, которые на нём выполняются.
  • Появится возможность скопировать файлы через scp. Даже если графический интерфейс "завис", то такое подключение часто всё ещё можно установить и забрать с узла необходимые логи или артефакты сборки.
  • Также будет возможен поиск клиентских лицензий 1С в локальной сети, в том числе на машинах отличных от хостовой. Для этого достаточно будет копировать преднастроенный файл nethasp.ini с указанием нужного IP-адреса каталог /opt/1C/v8.3/x86_64/conf/ виртуальной машины, аналогично тому, как мы будем делать это с другими конфигурационными файлами.

 

 

В схеме, описанной в первой части этого руководства, все узлы CI-контура полностью изолированы друг от друга. Но обеспечивая связь между ними по сети мы также получаем возможность создать и другую конфигурацию CI-контура.

Например разместить сервер  СУБД и сервер 1С на одной из виртуальных машин или даже на хостовой машине. Остальные машины при этом будут осуществлять подключение к этому серверу. Такая схема менее удобна с точки зрения управления базами при многопоточном CI-процессе. Удаление узла CI ещё не будет означать удаления созданной через него базы. За базами придётся следить, обеспечивать им уникальные имена в алгоритмах сборок и не забывать удалять их вместе с виртуальными машинами. В то же время будет получен значительный выигрыш по скорости развертывания тестовых базы, особенно если в качестве основы для них используются копии больших рабочих баз. Ведь в этом случае процесс развертывания можно настроить и оптимизировать только на одной машине и выделить на ней больше ресурсов под СУБД.

 

Jenkins - на потом

Один названных выше пунктов - настройку автозапуска и обновления агента Jenkins - в этот раз выполнять не будем. Дело в том, что перед этим необходимо рассмотреть процесс конфигурирования самого CI-сервера Jenkins на хостовой машине, чтобы понимать причины и следствия всех выполняемых действий. Этому будет целиком посвящена следующая публикация. Но все остальные действия можно выполнить уже сейчас.

 

Расположение Vagrantfile

 

Вагрантфайл пишется на языке Ruby. Изучение этого языка не является необходимым, и работа с этим файлом возможна также, как и с другими конфигурационными файлами - путем комбинации различных примеров из документации и открытых репозиториев. И судя по документации даже авторы утилиты vagrant предпочитают, чтобы пользователи воспринимали этот файл именно как конструктор, который формируется на основе сниппетов - блоков готового кода, где вы заменяете одни параметры на другие.

Шаблон Вагратфайла создается в текущей директории командой vagrant init.  Файл создаётся фактически пустым, затем его нужно открыть на редактирование и заполнить таким содержимым, которое "объясняет" утилите vagrant из какого образа развернуть виртуальную машину и с какими настройками это сделать:

 

Затем на основе этого файла командой vagrant up разворачивается и загружается виртуальная машина. Напоминаю, что простейший пример, иллюстрирующий эти действия был рассмотрен в конце прошлой публикации.

Файлы самой виртуальной машины хранятся при этом не в этом каталоге, а в том, который задан в настройках гипервизора:

 

В каталоге, где находится Vagrantfile, при запуске машины сохраняются только основные данные о ней. При выполнении команды vagrant up создается подкаталог .vagrant, хранящий:

  • идентификатор виртуальной машины
  • ключ для установки ssh-подключения без пароля
  • и некоторые её метаданные.

 

То есть Vagrantfile и его каталог предназначены только для управления виртуальной машиной - ее запуска, конфигурирования и остановки. А с точки зрения гипервизора созданная виртуальная машина ничем не отличается от созданной вручную, располагается там же и может точно также управляться через стандартный интерфейс гипервизора.

Каталог .vagrant, создаваемый при выполнении команды vagrant up может хранить информацию только об одной машине.

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

В документации (https://www.vagrantup.com/docs/vagrantfile) говорится, что Vagrantfile можно расположить в любой директории верхнего уровня относительно той, где выполняется команда vagrant up. При этом утилита vagrant сама рекурсивно поднимется выше по дереву каталогов, обнаружит где находится этот файл и запустит виртуальную машину на его основе. Но на практике в этом нет большого смысла. Потому что каталог .vagrant всё равно будет создан ровно в том же каталоге, где будет найден Vagrantfile. То есть нельзя просто создать разные подкаталоги для каждой виртуальной машины и создать один общий файл Vagrantfile для них, разместив его на один каталог выше. Этот файл нужно разместить в каждом каталоге для каждой виртуальной машины.

Но наш Vagrantfile по аналогии с JSON-файлом для Packer будет универсальным. Он будет содержать общий код для запуска любой из виртуальных машин, которые предполагается использовать как узлы CI-сервера Jenkins. За параметры запуска при этом будут отвечать небольшие командные файлы специфичные для каждой машины.

Чтобы избежать многократного дублирования кода разместим наш универсальный Vagrantfile в родительском каталоге относительно каталогов, предназначенных для хранения данных отдельных машин. Запуск виртуальных машин организуем через командные файлы (bat-файлы), и в этих файлах перед выполнением команды vagrant up, запускающей машину, будем просто копировать файл из родительского каталога в каталог отдельной виртуальной машины, выполняя команду cp ..\Vagrantfile Vagrantfile.

Можно также "обмануть" утилиту vagrant и вместо копирования файла создавать одноименную символическую ссылку на этот общий Vagrantfile командой mklink Vagrantfile "..\Vagrantfile", однако эту команду обязательно требуется запускать с правами администратора, что может быть неудобно.

Взаимное расположение файлов будет следующим:

Структура Vagrantfile

 

Весь код этого файла обернут в конструкцию следующего вида

 

 Vagrant.configure("2") do |config|

 

#...................

 end

 

 

Эта конструкция говорит, что внутри нее мы работаем с объектом config, предоставляющим доступ к конфигурации виртуальной машины, и структура этого объекта соответствует второй версии конфигурационного объекта. Более подробно это описано в документации https://www.vagrantup.com/docs/vagrantfile/version.html.

Обращаясь через точку к полям этого объекта мы задаем все необходимые параметры для развертывания и запуска виртуальной машины. Например, чтобы сказать, что

  • мы хотим развернуть виртуальную машину из образа, имя которого задается переменной окружения 'box_name',  
  • при этом следует проигнорировать Vagrantfile, включенный в состав этого образа как файл по умолчанию,
  • машина в этом образе относится к классу Linux,
  • по завершении запуска машины нужно вывести в консоль сообщение "Jenkins node started"

нам достаточно задать следующий код:

 

 Vagrant.configure("2") do |config|

 

    config.vm.box = ENV['box_name']

    config.vm.ignore_box_vagrantfile = true 

    config.vm.guest = :linux

    config.vm.post_up_message = "Machine started"

 

 end

 

 

В целом назначение и отдельные блоки этого файла напоминают конфигурационный файл Packer. Можно создать отдельный раздел, определяющий какие ресурсы хостовой машины мы выделяем для гостевой машины. Как и в случае Packer делается это через доступ к свойствам отдельных провайдеров (гипервизоров). В нашем случае нужно обратиться к свойствам VirtualBox:

 

   config.vm.provider :virtualbox do |v, override|

 

        v.gui = true # Display the VirtualBox GUI when booting the machine

        v.customize ["modifyvm", :id, "--memory", ENV['ram_memory_size_mb']]

        v.customize ["modifyvm", :id, "--cpus", ENV['cpu_count']]

        v.customize ["modifyvm", :id, "--vram", 64] # Video memory 64 MB

 

    end

 

Как и в случае с Packer есть "провизионеры" - поставщики. Поставщики добавляются вызовом метода config.vm.provision.  В них мы определяем какие-то действия с уже запущенной виртуальной машиной и то, какой механизм и при каких условиях эти действия будет выполнять.

Сейчас нам необходимы только два типа поставщиков, определяемых параметром type

  • "file" - копирование файла с хостовой машины в виртуальную
  • "shell" - исполнение команды оболочки sh/bash.

Но в отличие от JSON-файла для Packer, используемого один раз при сборке образа виртуальной машины, Vagrantfile используется при каждом ее запуске. Очевидно, что далеко не все команды, заданные в этом файле, имеет смысл выполнять при каждом запуске. Часть команд будет выполнять первоначальное конфигурирование при развертывании машины. Другая часть должна выполняться при каждом запуске. И управлять этим поведением позволяет параметр run.

Можно задать его равным "once"  и команды будут выполнены только при первом развертывании машины, а при последующих запусках будут проигнорированы. Например копировать файл настройки сети из хостовой машины в виртуальную достаточно только один раз в процессе ее развертывания:

 

 

    config.vm.provision "Copying netplan configuration file to VM", type: "file", run: "once" do |f|

        f.source = Dir.pwd + "/netplan_config.yaml"

        f.destination   = "~/netplan_config.yaml"

    end

 

 

Можно задать параметр run равным "always" и тогда команда будет выполняться при каждом запуске виртуальной машины через команду vagrant up. Например при каждом запуске можно устанавливать одинаковое разрешение экрана:

    config.vm.provision "Setting screen resilution via xrandr", type: "shell", run: "always" do |s|

        s.inline = "xrandr  -display :0.0 -s 1600x1200" # sleep 10 - waiting boot process to end and GUI to appear

        s.privileged = false

    end

 

Можно указать run "never" и тогда команды никогда не будут выполняться при запуске виртуальной машины через команду vagrant up.

Тем не менее их можно будет явно вызвать командой vagrant provision --provision-with  имя_блока_provision. Это очень удобная возможность для вывода диагностических сообщений. Например чтобы выполнить команду ps aux | grep "agent.jar" внутри виртуальной машины, но отобразить её вывод в консоли хостовой машины, из консоли хостовой машины достаточно будет выполнить команду vagrant provision --provision-with CheckJenkinsNode.

 

    config.vm.provision "CheckJenkinsNode", type: "shell", run: "never" do |s|

        $checkJenkinsAgentScript =<<-SCRIPT

        sleep 30

        echo "Output of ps aux | grep agent.jar must contain information about running jenkins agent."

        echo "If there is no such information  maybe Jenkins server or Jenkins agent is stopped. The output is below:"

        ps aux | grep agent.jar

        SCRIPT

        s.inline = $checkJenkinsAgentScript 

    end   

 

 

В Vagrantfile можно объявлять переменные. Например в целях отладки тип запуска большинства провизионеров можно задать в переменной $initRunType, а затем вместо констант  "once", "never" или "always" использовать эту переменную. Таким образом можно быстро переключаться между выполнением команд только при первом запуске и выполнением команд при каждом запуске машины. Такой подход позволит упростить отладку Vagrantfile и выполняемых с помощью него действий:

 $initRunType = "once"

 #..............

 

 config.vm.provision "Copying netplan configuration file to VM", type: "file", run: $initRunType do |f|

        f.source = Dir.pwd + "/netplan_config.yaml"

        f.destination   = "~/netplan_config.yaml"

 end

 

 

Параметры взаимодействия с виртуальной машиной

 

Перейдем к детальному рассмотрению содержимого нашего Vagrantfile, ссылки на файл:

Также как и в случае с Packer, взаимодействие с гостевой машиной будем выполнять через ssh-подключение. При запуске машины утилита vagrant будет периодически проверять её доступность и, как только появится возможность, установит с ней связь по ssh.

При этом в отличие от сборки образа с Packer здесь имя пользователя и пароль мы зададим непосредственно в файле  в переменных $ssh_username и $ssh_password. Это единственное место, где они будут задаваться и они одинаковы во всех используемых образах, поэтому нет необходимости выносить эти параметры куда-либо ещё (хотя Вы, конечно, можете сделать более универсальное решение).

Имя образа, из которого происходит создание виртуальной машины, будем передавать через переменную окружения 'box_name' из управляющих командных файлов. Для того чтобы обратиться к переменной окружения следует использовать конструкцию ENV['имя_переменной']:

 

    $ssh_username = "vagrant"

    $ssh_password = "vagrant"

    $initRunType = "once"

   

    config.vm.box = ENV['box_name']

 

    config.vm.communicator = "ssh"

    config.ssh.username = $ssh_username

    config.ssh.password = $ssh_password

 

    config.vm.network :forwarded_port, guest: 22, host: 2222, id: "ssh", auto_correct: true

 

Далее мы указываем общий каталог, который будет монтироваться в виртуальную машину при каждом выполнении команды vagrant up. Исходный каталог хостовой машины и каталог, в который будет производиться монтирование внутри гостевой машины также будем передавать через переменные окружения. Это позволит при необходимости управлять этой настройкой на уровне отдельных машин:

 

 

   config.vm.synced_folder ENV['shared_ci_host_directory'],

                           ENV['shared_ci_guest_directory'],

                           automount: true,

                           create: true,

                           group: "vagrant",

                           owner: "vagrant"

 

 

Из-за особенностей реализации механизма монтирования в Vagrant, каталог будет подключен таким образом, что не будет монтироваться при последующем ручном запуске виртуальной машины из графического интерфейса VirtualBox. Vagrant оставляет пустой точку монтирования в настройках и выполняет монтирование в указанный каталог самостоятельно:

 

В то же время вносить изменения в эти настройки не следует. Если указать точку монтирования вручную, то возникнут проблемы как с правами доступа к этому каталогу из виртуальной машины, так и с последующим его монтированием при запуске через Vagrant. В общем если машина создана с помощью Vagrant, то для ее запуска всегда стоит использовать команду vagrant up, а не GUI-инструменты гипервизора (это действительно важно для корректной работы).

Через этот каталог будет осуществляться доступ к общим для всех машин ресурсам и обеспечиваться публикация результатов сборок на хостовой машине. Например можно выводить сюда отчетность Allure о результатах тестирования и настроить веб-сервер на хостовой машине, чтобы он показывал отчетность из этой папки. Сюда будут выгружаться версии хранилища конфигурации и подготовленные образы тестовых баз.

Здесь же можно разместить фреймворк для сценарного тестирования. Загружать его в каждую виртуальную машину или автоматически обновлять c github-а может быть не лучшим решением. Разработку сценарных тестов и их выполнение лучше вести на одной и той же версии фреймворка, поэтому вариант размещения фреймворка в одном общем каталоге может быть удобен. В этом случае все узлы CI могут обращаться к нему по фиксированному пути:

 

Настройка ресурсов, выделяемых машине

 

Настройка системных ("железных") ресурсов выполняется через поле config.vm.provider.

Также здесь можно определить как машина будет вести себя визуально:

  • Запросить от VirtualBox отображать ее в графическом интерфейсе (показывать окно сразу при запуске), задав параметр gui = true
  • Явно указать имя виртуальной машины , чтобы утилита vagrant не добавляла к нему отметку времени. Удобно если это имя будет совпадать с именем узла CI, которое определяется у нас через переменную окружения: name = ENV['node_name']

По практике почти все настройки в этом блоке можно задавать константами. Всегда удобна возможность использования буфера обмена и механизма перетаскивания - для них стоит включить двунаправленный обмен (bidirectional). Также всегда хватает видеопамяти 64МБ. Такие настройки нет смысла определять в отдельных конфигурационных файлах. А вот количество CPU и объем оперативной памяти может быть удобно задавать разным для разных машин, входящих в один CI-контур. Память и ресурсы процессора имеет смысл менять и в зависимости от того на какой хостовой машине разворачивается CI. Поэтому их будем передавать извне через переменные окружения 'ram_memory_size_mb' и 'cpu_count':

 

   config.vm.provider :virtualbox do |v, override|

       

       v.name = ENV['node_name']

       v.gui = true # Display GUI when booting the machine

 

       v.customize ["modifyvm", :id, "--memory", ENV['ram_memory_size_mb']]

       v.customize ["modifyvm", :id, "--cpus", ENV['cpu_count']]

       v.customize ["modifyvm", :id, "--vram", 64] # Video memory 64 MB

       v.customize ["modifyvm", :id, "--clipboard", "bidirectional"]

       v.customize ["modifyvm", :id, "--draganddrop", "bidirectional"]

       v.customize ["modifyvm", :id, "--accelerate3d", "on"]

   

       v.customize ["modifyvm", :id, "--nic1", "nat"]   #  epn0s3

 

       v.customize ["modifyvm", :id, "--nic2", "bridged"]  # Bridged adapter, epn0s8

       v.customize ["modifyvm", :id, "--bridgeadapter2", ENV['host_phisical_adapter_name_for_bridge_connection']]  #

 

   end

 

 

Настройка сети

 

Согласно документации по Packer и Vagrant для корректного взаимодействия с гостевой машиной по ssh

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

В  Vagrantfile это делается следующим образом:

         v.customize ["modifyvm", :id, "--nic1", "nat"]

Но только сети NAT нам будет недостаточно для возможности взаимодействия машин друг с другом и с компьютерами в локальной сети. Необходимо создать еще один аптер, указав для него тип подключения "bridged".

         v.customize ["modifyvm", :id, "--nic2", "bridged"]

При выборе такого типа подключения нужно также указать имя устройства - физического адаптера на хостовой машине, через который будет осуществляться соединение:

Разумеется это имя будет разным на разных хостовых машинах и его указание непосредственно в Vagrantfile усложнило бы переносимость наших механизмов между хвостовыми машинами. Поэтому передавать имя устройства в Vagrantfile будем через переменную окружения:

         v.customize ["modifyvm", :id, "--bridgeadapter2", ENV['host_phisical_adapter_name_for_bridge_connection']]

Для корректного взаимодействия машин в этой сети им необходимо также назначить разные IP-адреса и имена хостов. Начнем с IP-адресов.

В последних версиях Ubuntu используется утилита для настройки сети Netplan. Ее работа основывается на конфигурационных YML-файлах. Утилита объединяет содержимое всех YML-файлов из каталога /etc/netplan и объединенный текст воспринимается как итоговая конфигурация, которую необходимо применить к системе. Имена файлов при этом не играют роли. В большинстве примеров в сети описывается как работать только одним конфигурационным файлом. И в нашем простейшем случае также будет достаточно одного файла.

Генерировать этот файл программно было бы довольно сложно, поэтому просто создадим шаблон этого файла и будем копировать его в каталог каждой виртуальной машины, заменяя в нем только IP-адрес:

Перед копированием файла в виртуальную машину удалим все существующие файлы, воспользовавшись командой

         find /etc/netplan -maxdepth 1 -type f -exec rm {} \;  

При записи этой команды в Vagrantfile обратный слеш придется экранировать согласно синтаксису Ruby.

Затем используем provisioner  с типом file для передачи файла с хоста в гостевую машину. Скопируем файл сначала в домашний каталог текущего пользователя, что не потребует полных прав. А затем указав необходимость привилегий суперпользователя (s.privileged = true) скопируем его в каталог /etc/netplan.

Всё, что остается сделать после этого для применения изменений и назначения IP адреса - это вызвать команду netplan apply, опять же с правами суперпользователя:

 

   config.vm.provision "Removing current netplan configuration", type: "shell", run: $initRunType do |s|

       s.inline = "find /etc/netplan -maxdepth 1 -type f -exec rm {} \\;"

       s.privileged = true

   end

 

   config.vm.provision "Copying netplan configuration file to VM", type: "file", run: $initRunType do |f|

       f.source = Dir.pwd + "/netplan_config.yaml"

       f.destination   = "~/netplan_config.yaml"

   end

 

   config.vm.provision "Copying netplan configuration file to netplan configuration directory", type: "shell", run: $initRunType do |s|

       s.inline = "cp /home/vagrant/netplan_config.yaml /etc/netplan/netplan_config.yaml"

       s.privileged = true

   end   

 

   config.vm.provision "Applying netplan configuration from file", type: "shell", run: $initRunType do |s|

       s.inline = "netplan apply"

       s.privileged = true

   end

 

 

 

Изменение имени компьютера, обработка файлов сервера 1С

 

При сборке образа виртуальной машины мы определяли имя хоста для нее как "vagrant-ci" (это имя задавалось в параметре boot_command конфигурационного файла Packer). И сейчас при развёртывании машины оно будет именно таким. Но было бы ошибкой оставлять одинаковое имя у каждой машины, входящей в нашу локальную сеть. Имя хоста следует изменить как на постоянной основе, так и для текущего сеанса пользователя. Для этого надо выполнить команды:

hostname новое-имя-хоста

hostnamectl set-hostname новое-имя-хоста

Однако тут мы столкнемся с сервером платформы 1С. Его мы устанавливали при сборке образа виртуальной машины. Сервер 1С привязывается к имени хоста той машины, на которой он выполняется, и если имя хоста начнет отличаться от заданного в его конфигурационных файлах, то сервер перестанет запускаться. Проблема достаточно известная, как известно и её решение. Нам придется выполнить замену имени хоста во всех конфигурационных файлах сервера 1С.

Сделать это можно как и ранее  утилитой sed выполнив команду:

find /home/usr1cv8/.1cv8/1C/1cv8 -type f -not -name '*.lgp' -exec sed -i 's/ текущее-имя-хоста / новое-имя-хоста /g' {} \;

Также потребуется перезапуск служб Avahi и 1С.

Чтобы не выполнять каждую команду в отдельности можно воспользоваться возможностью Vagrantfile по выполнению скриптов. Текст скрипта при этом можно задавать в самом файле:

 

   $changeHostNameScript =<<-SCRIPT

   systemctl stop srv1cv83.service

   systemctl stop avahi-daemon.service

   CURRENT_HOSTNAME=`hostname`

   NEW_HOSTNAME=#{ENV['node_name']}

   echo "Setting hostname to : " $NEW_HOSTNAME

   hostnamectl set-hostname $NEW_HOSTNAME

   hostname $NEW_HOSTNAME

   CHANGE_1C_HOSTNAME_COMMAND="find /home/usr1cv8/.1cv8/1C/1cv8 -type f -not -name '*.lgp' -exec sed -i 's/$CURRENT_HOSTNAME/$NEW_HOSTNAME/g' {} \\;"

   echo $CHANGE_1C_HOSTNAME_COMMAND

   eval "$CHANGE_1C_HOSTNAME_COMMAND"

   systemctl start avahi-daemon.service

   systemctl start srv1cv83.service

   SCRIPT

 

   config.vm.provision "Changing hostname for OS and 1C server", type: "shell", run: $initRunType do |s|

       s.inline = $changeHostNameScript

       s.privileged = true

   end

 

 

 

 

Прочие действия по конфигурированию в Vagrantfile

 

Как и в случае с Packer после старта графической оболочки имеет смысл настроить разрешение экрана:

 

   config.vm.provision "Setting screen resilution via xrandr", type: "shell", run: $initRunType do |s|

       s.inline = "xrandr  -display :0.0 -s 1600x1200" 

       s.privileged = false

   end

 

 

Также при необходимости можно передать с хостовой машины в гостевую файл nethasp.ini. Это имеет смысл если ключи находятся не на хостовой машине, а на другом компьютере в локальной сети, и скорость их поиска через бродкаст Вас не устраивает.

Передать этот файл можно тем же методом, который мы применяли для передачи файла конфигурации Netplan. За образец также можно взять пример копирования файла настроек для эмулятора терминала terminator (его можно увидеть в полном тексте файла в репозитории на github или gitlab).

Единственное отличие будет в том, что после его размещения в каталоге /opt/1C/v8.3/x86_64/conf/ гостевой машины для этого файла необходимо назначить права:

sudo chown usr1cv8:grp1cv8 /opt/1C/v8.3/x86_64/conf/nethasp.ini

Содержимое файла может быть например таким:


 

 [NH_COMMON]

 NH_TCPIP=Enabled

 [NH_TCPIP]

 NH_SERVER_ADDR=192.168.1.40

 NH_PORT_NUMBER=475

 NH_TCPIP_METHOD=UDP

 NH_USE_BROADCAST=Disabled

 

 

Конфигурационные файлы, определяющие специфичные для каждой машины параметры

 

Многие параметры машины в  Vagrantfile мы задавали не константами, а указывали необходимость их установки из переменных окружения. Это позволяет нам внутри каталога каждой виртуальной машины создать небольшой файл, где будут задаваться эти параметры, и при необходимости менять только этот файл.

Таким файлом у нас будет node-settings.bat

Его содержимое может быть следующим:

 

 

 SET node_name=ubuntu-interactive-1

 SET version_of_1c_platform_with_underscores=8_3_15_1656

 SET version_of_vm_os_with_underscore=19_04

 SET version_of_postgresql_with_underscores=10_10_4

 SET host_phisical_adapter_name_for_bridge_connection=NVIDIA nForce (Networking Controller)

 SET ram_memory_size_mb=6144

 SET cpu_count=3

 

 

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

CALL node-settings.bat

В этом файле мы определяем версии нужных нам компонент системы. Но не для этого, чтобы их установить при запуске, а для того, чтобы затем в общем командном файле составить из них "стандартизированное" в рамках нашего репозитория имя образа, из которого будет разворачиваться машина:

 

SET box_name=ci_node_ubuntu_%version_of_vm_os_with_underscore%_1c_%version_of_1c_platform_with_underscores%_pg_%version_of_postgresql_with_underscores%

 

 

Далее определяем количество виртуальных процессоров, объем ОЗУ и имя устройства - сетевого адаптера для создания bridge-подключения. Также задаем имя узла, которое сейчас будет использоваться для установки имени хоста в виртуальной машине, а затем ещё и для подключения машины в качестве узла Jenkins.

Ранее уже упоминалось про переносимость кода между различными хостовыми машинами. Теперь же мы создаем файл, текст которого по идее должен отличаться от узла к узлу, и тем более от сервера к серверу. Если работаем на боевом CI - то его содержимое будет одно, на компьютере разработчика - другое, а если захочется поэкспериментировать с механизмами CI на домашнем компьютере - то третье.

При таком подходе данный файл неправильно помещать в общий репозиторий и его следовало бы добавить его в .gitignore.

Но можно поступить и иначе. Для каждого хостового компьютера, на котором планируется выполнять запуск определить в файле свои параметры, после чего сохранить файл в git-репозитории. В этом случае файл может выглядеть следующим образом:

 

 

 SET node_name=ubuntu-interactive-3

 SET version_of_1c_platform_with_underscores=8_3_16_1063

 SET version_of_vm_os_with_underscore=19_10

 SET version_of_postgresql_with_underscores=11_5_7

 

 if "%computername%"=="SERVER-HOSTNAME" (

 goto :working_server_config

 ) else if "%computername%"=="HOME-HOSTNAME" (

 goto :development_config

 ) else (

 goto :end

 )

 

 :working_server_config

 REM Заменить имя вашего контроллера

 SET host_phisical_adapter_name_for_bridge_connection=NVIDIA nForce (Networking Controller)

 SET ram_memory_size_mb=6144

 SET cpu_count=3

 goto :end

 

 :development_config

 REM Заменить на Ваш IP-адрес, если Linux-машина не видит хостовую по имени компьютера

 SET host_machine_ip_or_hostname=192.168.1.64 

 REM Заменить имя вашего контроллера

 SET host_phisical_adapter_name_for_bridge_connection=Realtek PCIe GBE Family Controller

 SET ram_memory_size_mb=2048

 SET cpu_count=2

 goto :end

 

 :end

 

 

Конечно, это не отменяет того, что файл будет меняться чаще других. Но таким образом можно добиться значительно более постоянного содержимого этого файла.

Здесь мы не помещаем определение параметров в условный оператор if-else, так как в имени сетевого контроллера могут присутствовать скобки. В этом случае задание таких значений внутри условного оператора в bat-файле выглядело бы очень некрасиво: https://stackoverflow.com/questions/12976351/escaping-parentheses-within-parentheses-for-batch-file

 

Командные файлы запуска

 

Команда vagrant up должна выполняться из каталога каждой виртуальной машины в отдельности. Но как и всегда, в сценарии запуска у нас почти весь код будет общим. Поэтому внутри каталога отдельной машины будет находится небольшой файл vagrant-up.bat, содержащий всего две строки :

 

 

SET vagrant_action=up

cmd /C "..\vagrant-up-destroy-common.bat

 

 

Весь исполняемый код вынесем в общий файл vagrant-up-destroy-common.bat, расположенный на один каталог выше.

При этом текущий каталог меняться не будет и все действия фактически будут выполняться внутри каталога отдельной машины:

 

В общем файле сначала читаются переменные окружения, определяющие настройки отдельной машины (файл node-settings.bat  из текущего каталога), затем устанавливается каталог хранения образов виртуальных машин - переменная окружения VAGRANT_HOME. Значение этой переменной окружения устанавливается то же самое, которое мы устанавливали при сборке образа через Packer.

Далее формируется имя образа и задаются прочие параметры, которые являются общими для всех машин: имя хоста (имя хостовой машины), путь к общему каталогу как со стороны хоста, так и со стороны гостевой машины:

 

 CALL node-settings.bat

 cp ..\Vagrantfile Vagrantfile

 SET VAGRANT_HOME=C:/HashiCorp/vagrant_home

 SET box_name=ci_node_ubuntu_%version_of_vm_os_with_underscore%_1c_%version_of_1c_platform_with_underscores%_pg_%version_of_postgresql_with_underscores%

 

 if NOT DEFINED host_machine_ip_or_hostname (

     SET host_machine_ip_or_hostname=%computername%

 )

 if NOT DEFINED shared_ci_guest_directory (

     SET shared_ci_guest_directory=/home/vagrant/shared_ci

 )

 if NOT DEFINED shared_ci_host_directory (

     SET shared_ci_host_directory=%~dp0/shared

 )

 

 time /T

 

 if %vagrant_action%==up (

    vagrant up

 ) else if %vagrant_action%==destroy (

    vagrant destroy -f && rmdir /s /q .vagrant

 )

 

 time /T

 

 

Последней командой выполняется либо vagrant up для запуска машины, либо vagrant destroy для ее удаления (механизм удаления рассмотрим ниже).  

В файле vagrant-up.bat значение переменной vagrant_action задается равным "up", и поэтому запуске данного файла произойдет развертывание машины из образа с именем %box_name% и ее последующий запуск с выполнением команд из Vagrantfile.

 

Удаление созданной виртуальной машины

 

Удаление виртуальной машины, развернутой через Vagrant выполняется командой vagrant destroy.

При выполнении этой команды также читается Vagrantfile и происходит инициализация части параметров, заданных в этом файле.

В результате инициализации параметров утилите vagrant обязательно должно стать известно имя образа и общие каталоги, а у нас они определяются через переменные окружения. Зачем так сделано - не ясно. Ведь уже есть каталог .vagrant , содержащий все необходимые для удаления данные. Но тем не менее с таким поведением команды vagrant destroy приходится мириться.

Поэтому и перед запуском и перед удалением виртуальной машины будем устанавливать одни и те же переменные окружения. Проще всего сделать это, если команды запуска и удаления перенести в общий командный файл, а извне передавать только режим, определяющий действие: "up" - для запуска, "destroy" - для удаления.

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

 

 

 if %vagrant_action%==up (

    vagrant up

 ) else if %vagrant_action%==destroy (

    vagrant destroy -f && rmdir /s /q .vagrant

 )

 

 

Для удаления создадим в каталогах, специфичных для отдельных машин, файл vagrant-destroy.bat, который будет отличаться от vagrant-up.bat только одной строкой:

 

 SET vagrant_action=destroy

 cmd /C "..\vagrant-up-destroy-common.bat

 

 

Конечно всегда может произойти какая-то ошибка и виртуальная машина не будет удалена. В этом случае для освобождения ресурсов ее необходимо будет удалить вручную, выбрав удаление всех ее файлов, и не забыть удалить соответствующий каталог .vagrant:

 

Итоги и проверка результата

 

Итак, мы получили возможность

  • Задавая параметры всего в двух конфигурационных файлах (node-settings.bat и netplan_config.yaml)  разворачивать из подготовленных с помощью Packer образов новые виртуальные машины.
  • Вести простейший реестр хостовых машин прямо в командных файлах, задавая для них разные параметры запуска. Тем самым обеспечивая возможность выделения разных ресурсов виртуальным машинам и их запуска на разных серверах, и даже рабочем или домашнем компьютере.

Код во всех остальных файлах является общим для всех машин.

В файлах Вы обязательно должны задать свои значения:

  • IP-адреса и имени хоста для каждой машины
  • Версии серверного программного обеспечения, из которых механизм развертывания составит имя бокса с образом машины.
  • Имя физического сетевого адаптера, на основе которого будет создаваться bridge-подключение.

В этом случае, каждая из запущенных машин будет включена в общую локальную сеть, иметь уникальный IP адрес и имя хоста. Этого достаточно, чтобы следующим шагом запустить на ней агента CI-сервера Jenkins и подключить машину в качестве сборочного узла. При этом полное пересоздание каждого узла будет занимать менее 10 минут и всего четыре клика мыши.

Можно создать отдельный командный файл для запуска и остановки всех машин разом, но мне кажется что поочередный запуск также достаточно удобен:

Количество узлов, которые можно запускать в процессе разработки и отладки механизмов, будет ограничиваться ресурсами хостовой машины. Если вести разработку на среднем "бытовом" компьютере, то в большинстве случаев получится запустить только два или три узла, выполняющих задачи сборки и тестирования 1С. Для запуска большего их количества потребуется сервер помощнее, иначе на хостовой машине больше ничего не удастся делать :

 

Два узла, исполняющие задачи сборки:

Три узла, исполняющие задачи сборки:

 

Традиционно, ссылки на очередные коммиты в репозиторий на

 

В следующей части мы наконец завершим разработку "инфраструктуры" для CI, перейдем к конфигурированию Jenkins и подключению к нему развернутых машин в качестве сборочных узлов.

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. YPermitin 7759 05.03.20 15:59 Сейчас в теме
(0) солидно!

Жду следующей статьи.

P.S. До какой точки будете описывать весь процесс?
2. Vladimir Litvinenko 2230 05.03.20 16:30 Сейчас в теме
(1) Изначально думал, что будет меньший объем информации ))
Потом поставил себя на место того, к то с темой ещё не знаком и исходные тексты показались бесполезными.

Видимо придётся выкинуть всю тему развёртывания узлов на Windows и MS SQL, которую хотел затронуть. Типа гетерогенная среда Windows + Linux, стильно модно, молодёжно ;)) Но видимо не судьба )) А всё остальное будет.

В следующий раз про Jenkins и его настройку. Потом надо синтаксис пайплайнов рассмотреть - там очень много тонкостей, без которых происходит дублирование кода и куча других граблей. Ну а потом каждую задачу из исходной схемы расписать - выгрузка хранилища, автоматическая подготовка тестовой базы, основной процесс тестирования, публикация отчетности на Apache.

Для публикаций нужны выходные, поэтому чаще чем раз в неделю их точно не будет. Но если Вам тема интересна, то в принципе про все аспекты построения CI сможете прочитать.

Самое замечательное - то что скоро выйдет платформа 8.3.18 и необходимость в отдельном узле для выгрузки хранилища отпадёт совсем )) Можно будет на Linux несколько версий платформы ставить. Хотя большая часть информации останется актуальной, так как для параллельного теста нескольких закладок в хранилище по прежнему несколько узлов нужно будет.
YPermitin; +1 Ответить
3. YPermitin 7759 05.03.20 16:32 Сейчас в теме
(2) А где-нибудь в компании уже удалось такое до продакшена довести? Или может планы есть?
Если удалось, то на сколько прод отличается от окружения в статье?

Если все это не секрет, конечно.
4. Vladimir Litvinenko 2230 05.03.20 16:36 Сейчас в теме
(3) Использую прямо сейчас. На очень небольшом проекте, но на большой конфигурации )) Это же виртуалки. Отличия должны быть только в количестве узлов и выделяемой оперативке. Других быть не должно. Иначе вся эта универсализация была бы ни к чему ))

До этого на Windows всё это дело строил и на двух RDP-сеансах + одном для разработки. Но на той работе под эти задачи большой сервер выделен был и недостатка ресурсов не было совсем. Там на ERP 2.2 тесты были. Сейчас возникал потребность дома потестировать и поразрабатываь CI и соответственно потребность в переносимости механизмов и запуске на слабых машинах. Отсюда Linux. Переделал под него старый код, который для Windows использовал, изменений совсем не много потребовалось.

Но преимущества Linux в этом плане в принципе подробно в первой публикации изложены. С точки зрения лицензирования Windows всё то же самое позволяет сделать. Только на маломощных машинках уже не запустишь в 2-3 потока. Либо придётся под эти задачи машинку целиком отдать и уже ничего другого на ней не сделаешь.

Вообще цель всего этого - расписать как сделать "бюджетно" и самостоятельно. А то много историй про кучу разных серверов или облака Amazon отпугнуть могут )) В большинстве случаев в облаках или разных серверах нет никакой необходимости, достаточно одного физического, но желательно по мощнее. Коллеги вон в телеграм-каналах пишут что вообще в на базе Докера то же самое делают ))
Fox-trot; YPermitin; +2 Ответить
5. YPermitin 7759 05.03.20 16:56 Сейчас в теме
(4) хочу найти время и поиграться на выходных. Разверну у себя 3-4 виртуалки для этого дела.

Продолжайте создавать публикации. Keep calm! :)
6. Vladimir Litvinenko 2230 05.03.20 17:00 Сейчас в теме
7. YPermitin 7759 05.03.20 17:02 Сейчас в теме
8. Vladimir Litvinenko 2230 05.03.20 17:03 Сейчас в теме
(7) Заберу в копилку стикеров ))
YPermitin; +1 Ответить
9. vovast 05.03.20 18:01 Сейчас в теме
При попытке запуска второй машины выдает ошибку:
==> default: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> default: flag to force provisioning. Provisioners marked to run always will still run.

IP-адреса и имена хостов отличаются.
Что я забыл сделать?
10. Vladimir Litvinenko 2230 05.03.20 18:45 Сейчас в теме
(9) О, класс! Значит собрать образ машины через Packer у Вас получилось! ;))

Приведённый Вами текст не является ошибкой. Это просто логи запуска. "default" в данном случае это имя машины. Для запуска IP адреса машины и хоста не обязаны отличаться - это уже для дальнейшего их взаимодействия надо.

Дело в том, что Vagrant позволяет им ещё и имена присваивать для своего собственного реестра https://www.vagrantup.com/docs/virtualbox/configuration.html :

config.vm.provider "virtualbox" do |v|
  v.name = "my_vm"
end


А если не присвоить, то имя будет просто default.

Сообщение о том, что "Machine already provisioned" означает, что машина уже запускалась и провизионеры с типом "once" уже отработали и больше запускаться не будут. Такое сообщение появляется при втором и последующем запуске. В то же время если какой то из провизионеров вы объявите с типом запуска "always", то они запустятся всегда, и при повторной загрузке машины. Об этом сообщает текст "Provisioners marked to run always will still run"

В статье этот вопрос рассматривался в разделе Структура Vagrantfile

Если машина при этом запускается, то всё в порядке. У меня в логах точно такие же строки присутствуют.

Вот если она при этом не запускается, то надо разбираться. Напишите, если она не запускается. Если не запускается, то полный текст логов можно привести выполнив команду vagrant-up.bat | tee log.txt, тогда логи попадут в указанный текстовый файл. Ну или другим способом их можно в текст перебросить. У меня например они такие:

11. vovast 05.03.20 19:03 Сейчас в теме
(10)
vagrant-up.bat | tee log.txt


Нет, не запускается.

Я же правильно понял, что я запускаю vagrant-up из папки "node-1-starter", у меня стартует одна машина, запускаю из "node-2-worker", стартует другая?
А у меня, похоже, получается, что при запуске второй машины она находит первую и считает, что она уже запущена. При этом при запуске vagrant-destroy из папки "node-2-worker" гасится машина, запущенная из "node-1-starter".
Во вложении лог запуска второй машины
Прикрепленные файлы:
log.txt
12. Vladimir Litvinenko 2230 05.03.20 19:21 Сейчас в теме
(11)
Я же правильно понял, что я запускаю vagrant-up из папки "node-1-starter", у меня стартует одна машина, запускаю из "node-2-worker", стартует другая?

Да, именно так. Это поведение записано в gif-анимации в статье.

У меня сейчас пока три предположения.

1) Могла не отработать команда cp ..\Vagrantfile Vagrantfile. В итоге каталог .vagrant создался не в директории отдельной машины, а на каталог выше, так как реестр для машины .vagrant создаётся там, где находится Vagrantfile. Посмотрите пожалуйста, где создался каталог .vagrant и скопировался ли файл Vagrantfile в каталог node-1-starter и node-2-worker. Каталог .vagrant должен быть в каждом из них, точно также как и файл Vagrantfile.

Посмотрите на последней большой гифке в статье - там видно, что .vagrant и Vagrantfile в каждом из подкаталогов появились.

Здесь ещё важно, что cp - это утилита из поставки git. Она должна быть доступна. Иначе нужно заменить команду на аналогичную команду Windows для копирования и замены файла.

2) В Ваших логах есть строка со странной записью расшаренного каталога
D:\Repo\ci-infrastructure-for-1c\jenkins-nodes\/shared
Это видимо мой косяк - я слеш не убрал. Почти уверен, что проблема не в этом, так как такая запись всё равно должна корректно отрабатывать и у меня прямо сейчас работает. Но всё же попробуйте убрать из командного файла лишний слэш в записи %~dp0/shared, чтобы уж совсем исключить эту вероятность.

3) Возможно Vagrant в новой версии ведёт себя иначе. Я дома попробую обновить и запустить этот код. На бою не хочу обновлять, вдруг действительно в этом причина )) Тогда надо будет изменить код, например ещё и назначить машине имя )) У меня сейчас 2.2.6, там уже новая вышла.

Скорее всего причина в пункте 1. У меня было такое поведение, когда вместо копирования файла делал символические ссылки, а они не создавались из-за нехватки прав.
13. Vladimir Litvinenko 2230 05.03.20 23:22 Сейчас в теме
(12) Предположения 2 и 3 не подтвердились. В пути к Shared Folder можно задавать любое количество слешей и бэкслешей перед именем последнего каталога - Vagrant это нормально воспринимает. Также после обновления Vagrant с 2.2.4 и 2.2.6 на 2.2.7 поведение не изменилось и по крайней мере на моих инсталляциях ошибки нет.


Главный подозреваемый получается - команда cp ..\Vagrantfile Vagrantfile, которая не копирует файл из родительской директории во вложенную. Причина - либо отсутствие прав (что маловероятно), либо отсутствие пути к утилите cp в переменной окружения PATH. При этом в логи действительно не выводится сообщение о не найденной команде.

vovast, Вы можете попробовать заменить эту команду на стандартную CPOY /Y. Главное чтобы перед тем как выполняется команда vagrant up в командном файле, в директории отдельного узла уже присутствовал файл Vagrantfile. Его можно для эксперимента и вручную туда скопировать ))
14. vovast 10.03.20 10:57 Сейчас в теме
Да, дело было в этом. исправил на COPY и все заработало. Спасибо.
Vladimir Litvinenko; +1 Ответить
Оставьте свое сообщение

См. также

Готовый сервер 1С с Linux Centos 7 и PostgreSQL 10 на борту

Статья Системный администратор Нет файла 1С:Франчайзи, автоматизация бизнеса Россия Бесплатно (free) Linux

Сейчас все больше и больше возникает вопросов по развертке и настройке 1С на базе Linux и PostgreSQL, так как работать в файловой базе уже почти нереально из-за сложности типовых конфигураций и развитости платформы, а покупать платное ПО довольно дорого, особенно для небольших организаций.

03.04.2020    351    aleksxx    17       

Подборка программ для взаимодействия с ЕГАИС Промо

ЕГАИС (Единая государственная автоматизированная информационная система) - автоматизированная система, предназначенная для государственного контроля за объёмом производства и оборота этилового спирта, алкогольной и спиртосодержащей продукции. Инфостарт рекомендует подборку проверенных решений для взаимодействия с системой.

Визуализация фич Vanessa Automation в StoryMapper

Статья Программист Нет файла ИТ-компания 1С:Франчайзи, автоматизация бизнеса Бесплатно (free) Agile (XP, SCRUM, Канбан) Сценарное тестирование Vanessa Automation

Описан процесс визуального упорядочивания коллекции feature-файлов в виде карты пользовательских историй. Используется инструмент гибкого управления требованиями StoryMapper.

21.03.2020    1281    oleynik.dv    7       

Базовый курс по обмену данными в системе 1С:Предприятие. Онлайн-интенсив с 12 по 28 мая 2020 г. Промо

Данный онлайн-курс предусматривает изучение механизмов платформы “1С:Предприятие”, обеспечивающих обмен данными между различными прикладными 1С-решениями и взаимодействие с другими информационными системами. Курс предназначен для тех, кто уже имеет определенные навыки конфигурирования и программирования в системе “1С:Предприятие”.

5500 рублей

Пайплайны Jenkins - программирование и настройка. Загружаемые модули. Цикл "Многопоточный CI для 1С", часть 5

Статья Системный администратор Программист Нет файла Бесплатно (free) DevOps

Рассмотрим создание пайплайнов Jenkins и библиотек собственных методов, язык Groovy, подходы к хранению настроек и обработке ошибок.

17.03.2020    1917    Vladimir Litvinenko    14       

Jenkins: конфигурируем сервер и подключаем к нему виртуальные машины. Цикл "Многопоточный CI для 1С c Packer, Vagrant и Jenkins", часть 4

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) DevOps CI/CD Jenkins

Выполним основные настройки Jenkins как CI-сервера. Подключим к нему развёрнутые через Vagrant виртуальные машины в качестве сборочных узлов.

13.03.2020    1895    Vladimir Litvinenko    6       

Готовые переносы данных из различных конфигураций 1C Промо

Рекомендуем готовые решения для переноса данных из различных конфигураций 1C. C техподдержкой от разработчиков и гарантией от Инфостарт.

Собираем образ виртуальной машины с PostgreSQL и платформой 1С. Цикл "Многопоточный CI для 1С c Packer, Vagrant и Jenkins", часть 2

Статья Системный администратор Программист Нет файла Linux Бесплатно (free) DevOps CI/CD Linux

Автоматизируем установку и конфигурирование Linux, PostgreSQL, 1C, Apache, Java с возможностью выбора версий дистрибутивов. Упаковываем результат в образ виртуальной машины.

28.02.2020    4533    Vladimir Litvinenko    11       

Технология разветвлённой разработки, использующая git, ci/cd

Статья Программист Нет файла 1С:Франчайзи, автоматизация бизнеса Россия Бесплатно (free) CI/CD Git (GitHub, GitLab, BitBucket) Методология управления разработкой EDT

Адаптация и расширение требований к разветвлённой разработке с использованием git и ci/cd, основанное на стандартах 1С

24.02.2020    3145    check2    10       

Онлайн-курс «Автоматизация процессов управления МТО: методика сбора и формализации требований» с 1 апреля по 13 мая 2020 года. Промо

Цель курса - повысить полноту и качество сбора и формализации требований к автоматизации процессов управления материально-техническим обеспечением. Курс основан на процессном подходе, позволяет в полном объеме выявить и учесть все факторы, влияющие на специфику процессов управления МТО. Участники курса получают теоретические знания в области организации процессов управления МТО и готовый инструментарий для сбора и формализации требований по автоматизации этих процессов (шаблоны, опросники, модели).

40000 рублей

CI/CD для 1С проектов, унифицировано, с кастомизацией

Статья Программист Руководитель проекта Нет файла Бесплатно (free) CI/CD Инструментарий разработчика

Тема CI/CD в связке с 1С не нова, но многих пугает сложность использования и поддержки, необходимость обучения команды. Про то, как унифицировать и упростить поддержку сборочных конвейеров для большого количества решений, в своем докладе на конференции Infostart Event 2019 Inception рассказал начальник отдела компании BIA-Technologies Валерий Максимов.

20.02.2020    2927    theshadowco    11       

Программы для исполнения 54-ФЗ Промо

С 01.02.2017 контрольно-кассовая техника должна отправлять электронные версии чеков оператору фискальных данных - правила установлены в 54-ФЗ ст.2 п.2. Инфостарт предлагает подборку программ, связанных с применением 54-ФЗ, ККТ и электронных чеков.

Рабочее место программиста на Linux. Серия лабораторных работ. Работа 1

Статья Системный администратор Нет файла v8 Linux Бесплатно (free) Linux

В этой лабораторной работе мы сконфигурируем рабочее место программиста на платформе 1С:Предприятие 8. Воспользуемся подсистемой WSL и установим Linux в ОС Windows. Сервер 1С:Предприятие и сервер базы данных установим в Linux. Остальные компоненты установим в Windows.

17.02.2020    5232    infosoft-v    40       

Настройка SoftEther VPN Client на Linux Debian/Ubuntu/Mint (связка Linux-Windows)

Статья Системный администратор Нет файла Россия Linux Бесплатно (free) Администрирование СУБД Windows Linux

На сервере установлен и настроен VPN через программное обеспечение SoftEter VPN Server, настроены клиенты с доступом по сертификату, встала задача настроить доступ клиента из Linux и подключиться по RDP (VNC) в Windows к серверу VPN.

04.02.2020    1191    ClickUp    1       

Онлайн-курс «Практические аспекты внедрения регламентированного учета и расчета себестоимости в 1С:ERP на крупных промышленных предприятиях» с 20 апреля по 15 мая 2020 года. Промо

Курс рассчитан для подготовки экспертов по регламентированному учету и учету затрат для внедрения на крупных промышленных предприятиях с «исторически сложившимся» учетом

9000 рублей

Тестирование: Отлаживаем и тестируем REST интерфейс 1С с помощью SoapUI

Статья Программист Нет файла v8 Бесплатно (free) Сценарное тестирование

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

03.02.2020    3054    ivanov660    2       

Vanessa Automation + СППР

Статья Программист Нет файла v8 Бесплатно (free) Vanessa Automation СППР

Vanessa Automation. Использование автоматизированного тестирования в СППР.

07.11.2019    7554    SvVik    14       

Программы для исполнения 488-ФЗ: Маркировка товаров Промо

1 января 2019 года вступил в силу ФЗ от 25.12.2018 № 488-ФЗ о единой информационной системе маркировки товаров с использованием контрольных (идентификационных) знаков, который позволяет проследить движение товара от производителя до конечного потребителя. Инфостарт предлагает подборку программ, связанных с применением 488-ФЗ и маркировкой товаров.

Vanessa, улучшаем инструкции

Статья Бизнес-аналитик Пользователь Руководитель проекта Нет файла v8 1cv8.cf Windows Бесплатно (free) Vanessa Automation

Vanessa Automation умеет делать хорошие инструкции, давайте посмотрим, какие инструменты для этого есть.

30.10.2019    5624    OPM    4       

RPA: программные роботы работы не боятся

Статья no Нет файла Бесплатно (free) Методология Управление Технологии Скрипты автоматизации

Рутинные задачи отнимают 80% рабочего времени офисных сотрудников, в то время как технология RPA способна автоматизировать большую часть этих процессов с помощью бота, нескольких строк кода и продвинутого девелопера в команде

28.10.2019    8127    bolefirenko    37       

Базовый курс для начинающих 1С-программистов. Онлайн-интенсив со 2 июня по 2 июля 2020 г. Промо

Данный онлайн-курс является начальной ступенью по изучению базовых принципов программирования в системе “1С:Предприятие” и предназначен для обучения 1С-программированию “с нуля”.

4500-9500 рублей

Vanessa, хочу все и сразу

Статья Программист Бизнес-аналитик Руководитель проекта Нет файла v8 Бесплатно (free) Vanessa Automation

Vanessa Automation это инструмент для тестирования прикладных решений на платформе 1С, но он/она может больше, чем только тестирование.

11.10.2019    7590    OPM    12       

DevOps. Как это выглядит у нас

Статья Программист Нет файла v8 1cv8.cf Россия Бесплатно (free) DevOps

DevOps в департаменте разработки 1С в крупной компании.

01.10.2019    9879    Repich    19       

1C:Предприятие для программистов: Расчетные задачи (зарплата). Онлайн-интенсив с 01 по 17 июня 2020 г. Промо

Данный онлайн-курс предусматривает изучение механизмов платформы “1С:Предприятие”, которые предназначены для автоматизации периодических расчетов, а именно - для расчета зарплаты. Курс предназначен для тех, кто уже имеет определенные навыки конфигурирования и программирования в системе “1С:Предприятие”, а также для опытных пользователей прикладного решения “1С:Зарплата и управление персоналом” и прочих прикладных решений, в которых реализован функционал расчета зарплаты.

4900 рублей

Сказ про то, как я DevOps-ом занимался (OneScript, Deployka, Jenkins)

Статья Системный администратор Программист Нет файла v8 1cv8.cf ИТ-компания Бесплатно (free) OneScript DevOps Jenkins

Решаем задачу: автоматизировать обновление тестовых баз 1С из хранилища конфигурации при появлении в нём новых изменений. Данная статья родилась в муках хождения по граблям и поиска безопасного форватора среди подводных камней. Изложение постарался представить в виде инструкции для новичка, в которой собрал всё, с чем пришлось столкнуться. Сам я не DevOps-ер, ни на что не претендую, просто делюсь опытом :)

17.06.2018    19127    stas_ganiev    33       

Запуск Apache 2.4 с модулем 1С внутри Docker контейнера

Статья Системный администратор Программист Нет файла v8 Linux Бесплатно (free) Администрирование данных 1С WEB docker Apache

Про Apache и про Linux слышали, наверное, все. А вот про Docker пока нет, но он сильно набирает популярность последнее время и не зря. Поделюсь своим опытом и дам пошаговую инструкцию настройки веб-сервера Apache с модулем 1С внутри Docker контейнера на Linux хосте. При этом сам сервер 1С может находиться совсем на другой машине и на другой операционной системе. Это не важно, главное чтобы Apache смог достучаться до сервера 1С по TCP. В статье дам подробное пояснение по каждой используемой команде со ссылками на документацию по Docker, чтобы не создавалось ощущение непонятной магии. Также прилагаю git репозиторий с описанием всей конфигурации, можете попробовать развернуть у себя буквально за 10 минут.

04.04.2018    24352    petr.myazin    35       

Новый раздел на Инфостарте - Electronic Software Distribution Промо

Инфостарт напоминает: на нашем сайте можно купить не только ПО, связанное с 1С. В нашем арсенале – ESD-лицензии на ПО от ведущих вендоров: Microsoft, Kaspersky, ESET, Dr.Web, Аскон и другие.

  • Низкие цены, без скрытых платежей и наценок
  • Оперативная отгрузка
  • Возможность оплаты с личного счета (кешбек, обмен стартмани на рубли и т.п.)
  • Покупки идут в накопления для получения скидочных карт лояльности Silver (5%) и Gold (10%)

Создаем Docker-контейнер с 1C-клиентом для Linux

Статья Системный администратор Программист Нет файла Linux Бесплатно (free) Администрирование данных 1С docker

Создаем Docker-контейнер для Linux-версии 1C. Например, чтобы беспрепятственно использовать его на любом Linux дистрибутиве и не держать при этом "дремучих" версий библиотек в системе.

11.09.2016    18301    b00t    48       

Использование Vagrant и Docker при разработке в 1С

Статья Программист Нет файла Бесплатно (free) Практика программирования docker

В предлагаемой статье речь пойдет про такие инструменты виртуализации, как Vagrant и Docker.

19.08.2016    25758    pumbaE    10       

Подборка решений для взаимодействия со ФГИС «Меркурий» Промо

С 1 июля 2019 года все компании, участвующие в обороте товаров животного происхождения, должны перейти на электронную ветеринарную сертификацию (ЭВС) через ФГИС «Меркурий». Инфостарт предлагает подборку программ, связанных с этим изменением.

Собственный виртуальный сервер для 1С на Linux Ubuntu

Статья Системный администратор Программист Нет файла v8 Linux Бесплатно (free) Администрирование данных 1С Linux

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

24.05.2015    17302    spezc    44       

Публикация базы 1С на веб-сервере Apache на сервере Linux

Статья Системный администратор Программист Нет файла v8 1cv8.cf Linux Бесплатно (free) Администрирование данных 1С WEB Apache Linux

В отличие от других подобных публикаций здесь будет описано как опубликовать базу (располагающуюся на сервере windows) на веб-сервере apache (расположенном на соседнем сервере под linux).

20.09.2014    137149    spezc    64