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

13.03.20

Разработка - DevOps и автоматизация разработки

Разворачиваем инфраструктуру для 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 и подключению к нему развернутых машин в качестве сборочных узлов.

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

См. также

Автотесты для типовых конфигураций ERP Управление предприятием 2 и Комплексная автоматизация 2 (для vanessa automation)

Тестирование QA DevOps и автоматизация разработки Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х Россия Бухгалтерский учет Налоговый учет Платные (руб)

Готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарии возможно использовать как для vanessa-automation, так и для СППР. Поддерживаемые версии конфигураций ERP2 и КА2: 2.5.15.111.

2220 руб.

04.07.2022    6732    26    0    

23

Системы контроля версий для 1С-разработчиков.

1С-программирование DevOps и автоматизация разработки Групповая разработка (Git, хранилище) DevOps для 1С Платформа 1С v8.3 Платные (руб)

Основы командной разработки на 1С. Использование систем контроля версий при разработке на платформе 1С:Предприятие 8

4900 руб.

29.06.2022    9151    78    4    

110

Автотесты для типовых конфигураций Бухгалтерия предприятия КОРП 3.0 и Бухгалтерия предприятия 3.0 (vanessa automation)

Тестирование QA DevOps и автоматизация разработки Платформа 1С v8.3 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Налоговый учет Платные (руб)

Готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Бухгалтерия предприятие 3.0 и версии КОРП: 3.0.144.49.

1728 руб.

20.01.2022    6592    10    0    

9

Автоматическое подтверждение легальности обновления базы или как обновить 100 типовых баз 1С за 5 часов

DevOps и автоматизация разработки Обновление 1С Платформа 1С v8.3 Конфигурации 1cv8 1С:Бухгалтерия 3.0 1С:Зарплата и Управление Персоналом 3.x Абонемент ($m)

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

2 стартмани

08.05.2019    24220    54    VPanin56    26    

26

1С, СППР и Архитектура как код

DevOps и автоматизация разработки Бесплатно (free)

Можно ли идеи подхода «Архитектура как код» положить на 1С или иную платформу, чтобы не изобретать ещё какой-то язык и сразу получить множество готовых библиотек функций и инструмент достижения главной цели подхода AaC.

01.02.2024    2468    roman72    9    

7

TCP прокси-сервер хранилища конфигурации 1С

DevOps и автоматизация разработки Групповая разработка (Git, хранилище) OneScript Платформа 1С v8.3 Бесплатно (free)

Продолжение истории с прокси хранилища, но уже не на HTTP, а на TCP и без падений по памяти веб-сервера. Проверяем комментарии хранилища, вызываем веб-хуки, старты пайплайнов, gitsync по событию помещения версии в хранилище. И все это полностью на знакомом и понятном OneScript.

17.01.2024    2784    kamisov    17    

57

Infrastructure as code: кнопка «Сделать всё», или Упаковываем наше окружение в 5 кБ текста

DevOps и автоматизация разработки Бесплатно (free)

Когда под каждый проект нужно развернуть отдельный стенд разработки и сборочную линию для его обслуживания, велик риск влияния человеческого фактора. О том, как зафиксировать инженерный опыт в скриптах и унифицировать необходимые настройки для автоматизированного разворачивания инфраструктуры с помощью Terraform и Ansible, пойдет речь в статье.

01.11.2023    1326    Libelle    5    

13

Обработка для подготовки файла настройки дымовых тестов измененных объектов конфигурации

DevOps и автоматизация разработки Тестирование QA Россия Абонемент ($m)

В статье приведен пример обработки, которая на основании измененных файлов git-репозитория готовит специальный файл настройки xUnitParams.json для последующего выполнения дымовых тестов (xUnitFor1C/add) только для измененных объектов конфигурации

1 стартмани

09.10.2023    711    5    ICL-Soft    0    

3
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. пользователь 05.03.20 15:59
(0) солидно!

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

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

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

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

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

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

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

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

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

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

Продолжайте создавать публикации. Keep calm! :)
6. Vladimir Litvinenko 2869 05.03.20 17:00 Сейчас в теме
7. пользователь 05.03.20 17:02
8. Vladimir Litvinenko 2869 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 2869 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 2869 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 2869 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 и все заработало. Спасибо.
user836085; Vladimir Litvinenko; +2 Ответить
15. user836085 21.07.22 22:26 Сейчас в теме
Спасибо. Впечатляет по системному подходу, подробности и дотошности (все части), как и более ранние статьи
по тестированию и VA . Сравнить редко с кем можно, имхо :)
Оставьте свое сообщение