Медленная сборка Docker образа

На прошлой неделе начались заметил очень медленную сборку Docker образов на базе Ubuntu. Скорость загрузки с archive.ubuntu.com / security.ubuntu.com была в районе 400kB/s и ping до этих хостов был в районе 250ms. Поскольку на аналогичную проблему жаловался и коллега, то маловероятно что проблема с моим подключением к Internet (тем более что speedtest.net не показал ничего криминального).

Решить эту проблему можно несколькими способами:

1. Использовать местное зеркало Ubuntu (потребует редактирования Dockerfile)
2. Использовать кеширующий прокси сервер в конфигурации APT (потребует редактирования Dockerfile)
   
3. Использовать альтернативный DNS сервер, который будет резолвить archive.ubuntu.com/security.ubuntu.com на IP адрес зеркала (при условии что в sources не используется HTTPS)

Времени было мало и потому пошёл путём наименьшего сопротивления - использовал аргумент --add-host для команды docker build

$ docker build --add-host=archive.ubuntu.com:<IP> \
               --add-host=security.ubuntu.com:<IP> -t image-name .

Пакеты всё ещё скачивает из Internet, но зато подходит для большинства случаев и не требует дополнительных сервисов.

YAML грабли

Есть мнение что YAML это простой и дружелюбный формат (этакий JSON с комментами), противоположное мнение тоже существует.

Сегодня наступил на грабли с Helm в котором функция toYaml теряет кавычки из значений и таким образом меняет тип данных. Этот баг завели еще 4 года назад, но закрыли без решения проблемы. Каждый выкручивается как может - мне пришлось заменить

{{- with .Values.extraEnvVars }}
{{- toYaml . | nindent 10 }}
{{- end }}

на вариант с range

{{- range .Values.extraEnvVars }}
- name: {{ .name }}
  value: {{ .value | quote }}
{{- end }}

В других случаях (вроде аннотаций) будут свои особенности.

Совместный доступ исходникам

Моя проффесиональная деятельность в основном связана с Linux, хотя последние 6 лет на рабочем компьютере установлена Windows. Я делал несколько попыток пользоваться WSL, когда он только появился в Windows, но каждый раз опыт был негативный. Частые зависания подсистемы Linux и приходилось перезагружать Windows. Не работал Docker и некоторые другие программы. В то же время у меня появилась виртуальная машина VirtualBox с Debian внутри, которая после нескольких обновлений работает и по сей день. Вначале я пользовался shared folders в VirtualBox чтобы была возможность запускать IDE в Windows, но запускать программы в Linux. Это работало, но с определенными проблемами.

Поскольку в Windows выполнялось только редактирование файлов, то рациональным решением стало переносом их на сторону файловой системы Linux, а Windows становилась клиентом. Для этого я настроил NFS сервер в Linux и подключал его через NFS клиент Windows. С таким подходом тоже были нюансы, но такая схема успешно продержалась до прошлого года. Определенную головную боль приносило создание директорий в Windows (т.к. при монтировании в Windows использовалась опция -o fileaccess=644, то директории создавались, но зайти в них было нельзя), но если создавать их в Linux, то все работало нормально. Еще где-то полгода назад появилась проблема с сохранением файлов из Windows (ругалось что файл занят и запись невозможна, но кроме Windows с этим файлом никто не работал) - возможно виноват какой-то из дополнительных "агентов", которые установлены на рабочем компьютере.

Midnight Commander 4.8.29

Собрал пакеты Midnight Commander 4.8.29 для Debian/Ubuntu с архитектурами i386, amd64, armel, armhf и arm64. Пакеты для i386 и armel есть только в тех дистрибутивах, где они поддерживаются официально (в Ubuntu есть не все):

• Debian Buster (i386, amd64, armel, armhf, arm64)
• Debian Bullseye (i386, amd64, armel, armhf, arm64)
• Debian Bookworm (i386, amd64, armel, armhf, arm64)
• Debian Sid (i386, amd64, armel, armhf, arm64)
• Ubuntu Trusty (i386, amd64, armhf, arm64)
• Ubuntu Xenial (i386, amd64, armhf, arm64)
• Ubuntu Bionic (i386, amd64, armhf, arm64)
• Ubuntu Focal (amd64, armhf, arm64)
• Ubuntu Jammy (amd64, armhf, arm64)
  

Инструкция по подключению репозитария. Больше информации о бинарных сборках Midnight Commander можно найти на странице https://midnight-commander.org/wiki/Binaries.

По причине отсутствия доступа к серверу ночных сборок (которые не делались с прошлого года), я удалил их поддержку и пока не планирую возвращать ее в ближайшем будущем. Из приятного - добавлена поддержка Debian Bookworm, который уже на стадии заморозки.

P.S. Судя по истории моих правок странички https://midnight-commander.org/wiki/Binaries собирать каждый релиз новый mc я начал больше 11 лет назад.

Тест работает локально, но не работает в CI пайплайне

В процессе прикручивания Continuous Integration (CI) к приложению столкнулся с ситуацией когда end-to-end сценарий тестирования не работает в пайплайне. В то же время он корректно отрабатывает на локальной машине. У окружения CI отстутствует прямой доступ в Internet, но это не должно играть никакой роли т.к. сценарий написан таким образом, что приложение не предполагает ходить за пределы локальной машины.

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

Подключаюсь к Spark UI и вижу что задание обработки данных напрочь отсутвует. Далее смотрю логи компонента, который отвечает за его создание, но там никакого криминала нет. Иду в контейнер Spark Worker и начинаю медитировать на логи, а точнее их практически полное отсутствие.

VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component MachineWrap, interface IMachine

Столкнулся с тем, что Vagrant не может запустить виртуальную машину VirtualBox в headless режиме на Windows 10

==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["startvm", "df70e47d-8ba3-4103-b826-8bbfadff8794", "--type", "headless"]

Stderr: VBoxManage.exe: error: The virtual machine 'dev-workstation_default_1673686308201_10549' has terminated unexpectedly during startup with exit code -1073741819 (0xc0000005)
VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component MachineWrap, interface IMachine

К Vagrant эта проблема не имеет отношения, т.к. сама команда VBoxManage startvm df70e47d-8ba3-4103-b826-8bbfadff8794 --type headless завершается с такой же ошибкой

C:\Program Files\Oracle\VirtualBox>VBoxManage startvm df70e47d-8ba3-4103-b826-8bbfadff8794 --type headless
Waiting for VM "df70e47d-8ba3-4103-b826-8bbfadff8794" to power on...
VBoxManage.exe: error: The virtual machine 'dev-workstation_default_1673686308201_10549' has terminated unexpectedly during startup with exit code -1073741819 (0xc0000005)
VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component MachineWrap, interface IMachine

Версия VirtualBox 6.1.40 r154048, если запускать виртуальную машину с GUI, то ошибки не вознимает. В качестве решения попробовал перезагрузиться и переустановить VirtualBox, но это не помогло. Сейчас под рукой нет другой Windows 10 чтобы проверить возникает ли проблема там.

На форуме VirtualBox есть тема с похожими симптомами (Unable to headless start and detachable start), но там речь про Windows 11 и я не уверен что это тот же случай.

В баг трекере есть #17679 (Error on trying to run VM in headless mode), которому уже 5 лет. Во всех схожих случаях просят VBoxHardening.log, но никакие логи не появляются при этой ошибке.

В качестве временного решения сконфигурировал Vagrant запускать виртуальную машину с GUI.

Обновлено 15/01/2023: Попробовал запустить виртуальную машину на VirtualBox 7.0.4 - результат аналогичный. И логов все еще не пишет.

[Решено] Не устанавливается Vagrant на Windows

Не получилось установить Vagrant 2.3.4 на машинку с Windows 10 из-за ограничений UAC

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

Без особой надежды сообщил о проблеме на форуме Hashicorp где оперативно указали на https://github.com/hashicorp/vagrant/issues/13051.

Выполнил команду certutil -URLCache CRL delete но сертификат все еще значится как отозванный. Попробую подождать до завтра, т.к. в комментариях было упоминание что спустя какое-то время все начинает работать.

Обновлено 12/01/2023

На следующий день проверил состояние сертификата - "This digital signature is OK".

Просто нужно было подождать некоторое время после очистки кэша CRL. После этого UAC не мешал установке Vagrant.