Мучение с no_proxy в hadoop-aws

Про боль с настройками прокси для разных приложений в своё время хорошо написали в блоге GitLab. Я лишь немного добавлю про комбинацию Docker, HTTP Proxy и Hadoop-AWS, который мы используем в Apache Spark для записи данных в объектное хранилище.

Ранее я уже писал про тестовое окружение в котором чтобы скачать что-либо за пределами VPC нужно использовать корпоративный прокси-сервер. На CI сервере прокси настроен в Docker и этого достаточно чтобы собирались образы. Настройки прокси пробрасываются внутрь контейнеров в виде переменных окружения (подробности тут). Чтобы прокси не использовался там где не нужно задана переменная окружения "no_proxy" в которой перечислены все исключения на сервисы тестируемого приложения, ядром которого является Apache Spark.

Убрать начальный ноль из месяца, часа, минуты или секунды в date

В генераторе данных для нагрузочного тестирования ETL используется команда date чтобы получить часы, минуты и секунды. По-умолчанию они имеют "0" в качестве префикса что с свою очередь приведет к ошибкам в "математике" bash

$ echo $(( 60 - $(date +%S) ))
-bash: 60 - 09: value too great for base (error token is "09")

Можно использовать sed чтобы убрать начальный ноль

$ echo $(( 60 - $(date +%S | sed -e 's/^0//') ))

Но на StackOverflow нашлось более красивое решение - использовать padding modifiers в date

$ echo $(( 60 - $(date +%-S) ))

Полный список модификаторов есть в man date.

Установка Prometheus Node Exporter на Raspberry PI 3 OpenELEC

Это пошаговое руководство описывает установку Prometheus Node Exporter v1.5.0 на Raspberry PI 3 с OpenELEC 9.2.8.

Скачиваем дистрибутив Prometheus Node Exporter для Linux с архитектурой armv7 (BCM2835 не поддерживает arm64) в /storage (в OpenELEC все пользовательские изменения должны сохраняться в /storage).

# cd /storage

# curl -fsSLO https://github.com/prometheus/node_exporter/releases/download/v1.5.0/node_exporter-1.5.0.linux-armv7.tar.gz

# tar -xzf node_exporter-1.5.0.linux-armv7.tar.gz

# mkdir /storage/node_exporter/

# install -o root -m 755 node_exporter-1.5.0.linux-armv7/node_exporter /storage/node_exporter/node_exporter

# rm -fr /storage/node_exporter-1.5.0.linux-armv7 node_exporter-1.5.0.linux-armv7.tar.gz

Генератор данных для нагрузочного тестирования ETL

На текущем проекте для нагрузочного тестирования ETL нужен постоянный поток данных от телекоммуникационного оборудования. Размер сетей, тип и объём данных в метриках (сети 3g/4g/5g, оборудование разных вендоров) различается от клиента к клиенту и пока сетевики занимаются организацией доступа в сеть заказчика нужно определить системные требования и посчитать стоимость ресурсов чтобы заложить бюджет. Далее будет развёртывание окружения под клиента и оценка надёжности его работы сверх ожидаемой нагрузки (чтобы был запас по прочности на случай если у заказчика метрик станет заметно больше, чем планировалось).

Для функционального тестирования достаточно загрузить тестовый набор данных от клиента (чтобы убедиться что ETL корректно разбирает данные метрик), но это не подходит для нагрузочного тестирования, когда нужно проверить какую максимальную нагрузку выдержит система прежде чем мы перестанем соответствовать SLO (Service Level Objective).

Медленная сборка 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 с этим файлом никто не работал) - возможно виноват какой-то из дополнительных "агентов", которые установлены на рабочем компьютере.