Полезности

1. Логин в Яндекс Регистре с помощью iam токена

docker login \
         --username iam \
         --password <IAM_TOKEN> \
         cr.yandex

Вместо <IAM_TOKEN> подставляем свой токен вида 

t1.9euelZqSkZmXkszJlsuSy8eWy5ORk-3rnpWaj4uJmc6WnsiLyImVm82Yl8fl8_dEA2hx-e8lWDdX_t3z9wQyZXH57yVYN1f-zef1656VmoydmJTJkIubx8idm5zJmc-O7_0.hw-uRRvhkdkC7gG-scE-fyWbBl2fLQMvOCQZlb-Har-M2Y_OCISA52AA_MqQbVnB4K1Z94cP4ZPncOrZGo8QBQ

2. Healthchecks

У трех докер контейнеров есть хелсчеки, это admin, portal and export-service. В некоторых ситуациях, например, при чрезмерной загрузке ресурсов сервера, healthchecks могут вызывать перезапуски этих контейнеров. Ниже пример из platform.yml для увеличения интервалов и кол-ва попыток для принудительного предотвращения перезапуска контейнеров.

Пример из YML

admin:
    image: ${DOCKER_REPO_PREFIX}${ADMIN_TAG}
    healthcheck:
        test: ["CMD", "curl", "-f", "http://localhost:80/health"]
        interval: 30s
        timeout: 960s
        retries: 50
        start_period: 40s
    depends_on:
      - proxy
      - mongodb
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - database-backups:/visiology/database_backups
      - hardwareid:/visiology/admin/app/license/keys/hardwareid
      - /docker-volume/admin/portalImages:/visiology/admin/portalImages
      - /docker-volume/admin/useFiscalCalendar:/visiology/admin/useFiscalCalendar
    environment:
      - VPROXY_URL=${PLATFORM_URL:-proxy}
      - POLICY=${POLICY}
    labels:
      component: "admin"
    secrets:
      - MONGO_AUTH_USER
      - MONGO_AUTH_PASSWORD
    << : *deploy_platform
    << : *logging_options
  portal:
    image: ${DOCKER_REPO_PREFIX}${PORTAL_TAG}
    healthcheck:
        test: ["CMD", "curl", "-f", "http://localhost:80/health"]
        interval: 30s
        timeout: 960s
        retries: 50
        start_period: 40s
    depends_on:
      - dashboard-viewer
    volumes:
      - /etc/localtime:/etc/localtime:ro
    labels:
      component: "portal"
    << : *deploy_platform
    << : *logging_options

3. Скрипты, упрощающие работу

install-docker-ubuntu.sh | Установка последней версии Docker и Docker-Compose на Ubuntu. После выполнения установки нужно перезайти в терминал.
remove_visiology.sh | Удаление Visiology (сервисы, подсети, тома, образы). Подходит только, если на Docker работает исключительно платформа, т. к. может удалить ваши дополнительные Docker ресурсы.

4. Долгий запуск докер сервисов в закрытом контуре

Если сервер платформы не имеет выхода в интернет, то есть вероятность, что докер сервисы будут стартовать очень долго. Связано это с недоступностью DNS серверов.

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

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

2. В ином случае много зависит от инфраструктуры, через что запросы на DNS проходят (фаерволлы, маршрутизаторы). Здесь уже большая вероятность в необходимости ожидания таймаута. В разных средах запуск одного сервера может занимать от секунды до десятка секунд и выше. Если умножить на кол-во Docker сервисов, то такие такое время перезапуска платформы может быть не приемлемо.

3. По всей видимости при создании сервисов Docker обращается по своим делам в реестр. В случае с платформой на момент написания этой заметки используется Яндекс регистр образов с адресом cr.yandex.

Выбор решения зависит от предпочтений администратора сервера. Универсальных быстрых решения два:

1. Прописать в /etc/hosts сервера с платформой следующую строчку:

   127.0.0.1 cr.yandex

2. Добавить параметр к разворачиванию стека --resolve-image never в run.sh. Кусочек скрипта с добавленным флагом ниже:

   eval ${ENVIRONMENT_VARIABLES} docker stack deploy --resolve-image never ${composeFilesString} ${STACK_NAME}

5. Проверка SMTP

https://adminkit.net/smtp_diag_tool.aspx | Для случаев, если не удается настроить SMTP клиент в платформе, и нужно понять, какие параметры поддерживает почтовый сервер.

6. Список всех опубликованных дашбордов

Для просмотра списка всех опубликованных дашбордов, можно воспользоваться следующим запросом:
GET http://адрес_платформы/admin/api/webAppDashboards

7. Favicon

Чтобы поменять иконку, можно в nginx в каждом location, где своя иконка, прописать

sub_filter '/папка_модуля/favicon.ico' '/viewer/custom/favicon.ico'

А сам favicon.ico положить в customjs папку

8. Проблема с часовыми поясами в ViQube

Бывает происходит такая ситуация, что при запросе данных в каком-то менеджере СУБД из SQL вы получаете одни данные, а при запросе тех же данных в загрузчике ViQube вы получаете другие данные (итоговое значение меньше).
Как выяснилось это происходит из-за того, что ваш СУБД менеджер как правило работает под вашим локальным часовым поясом, а загрузчик ViQube работает в GMT поясе (Гринвич). Если быть конкретнее, то функции, которые используются в SQL запросе, например now() покажут разное время и в следствии чего запрос вернёт различные данные. Сам же сервер СУБД обычно работает в вашем же поясе, либо данные которые ему поступают идут с датой и временем из вашего пояса.

Например вы хотите вернуть суммарные значения за предыдущий час, ваш часовой пояс МСК, вы выполняете в менеджере:

select sum(value) from "testTimeZones" ttz
where date > now() - interval '1 hours'

В ответ получаете ожидаемое значение.
Далее выполняете такой-же запрос в загрузчике и что происходит. JDBC драйвер в загрузчике выполняет функцию now() из под пояса GMT, т.е. он -3 с МСК. Запрос который отправится на сервер будет иной, т.к. now() будет -3 часа и собственно данные которые придут в ответ будут другие, значение будет меньше.

Чтобы этого избежать, можно прокинуть файл timezone в контейнер ViQube, т.к. Java машина ориентируется на него. После этого JDBC драйвер будет знать ваш часовой пояс и now() будет возвращать такую же дату как и в менеджере.
Чтобы это сделать, необходимо открыть файл viqube.yml и в блок volumes в конец добавить строчку:

- /etc/timezone:/etc/timezone:ro

Далее перезапускаем платформу и проверяем.

9. Скрипт для быстрого восстановления БД на основе имеющегося дампа

BKP_PATH='v2.26.3177-2022-06-09 08-12-28'
rm -r /docker-volume/mongodb/*
docker service update visiology_mongodb
ID=$(docker ps | grep visiology.admin | awk '{print $1}')
MONGO_USER=$(docker exec -t $ID sh -c "cat secrets/MONGO_AUTH_USER")
MONGO_PAS=$(docker exec -t $ID sh -c "cat secrets/MONGO_AUTH_PASSWORD")
mkdir /docker-volume/mongodb/dump
cp -r "/var/lib/docker/volumes/visiology_database-backups/_data/$BKP_PATH/VisiologyVA" /docker-volume/mongodb/dump
docker exec -t $(docker ps --format "{{.ID}} {{.Names}}" | grep mongodb | awk '{print $1}') sh -c "mongo VisiologyVA -u $MONGO_USER -p "$MONGO_PAS" --eval "printjson(db.dropDatabase())" && mongorestore -u $MONGO_USER -p "$MONGO_PAS" --db VisiologyVA data/db/dump/"