Отпуск завершен, доехали до дома. Итого, 17 дней, около 5 тыс. километров, 10 мест ночёвки. У нас это первая такая масштабная поездка с 2017 года.

Основной итог: дети доросли до возраста, когда путешествовать с ними на машине на дальние расстояния в удовольствие, а машина для путешествий у нас близка к идеальной.

За все путешествие было несколько происшествий с машиной:
1. Сегодня с утра под Питером машина перестала реагировать на нажатие педали газа. Перезагрузка помогла, думаю программный сбой.
2. Пару раз мы похоже заправились ослиной мочой плохим бензином: загорался check engine, гас после следущий заправки.
3. Где-то по пути туда у нас начало трескаться лобовое стекло, видимо неудачно отлетел камень.

А так - болота, горы, бороды, бесконечные подъёмы - все препятствия машина преодолела на ура.

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

#отпуск

Небольшая заметка на полях о прометеусе. Оставлю тут, чтобы не утратить обретенные знания.

Раньше я многократно пользовался Прометеусом для отображения метрик приложения. Рантайм шарпа по дефолту экспортирует достаточно информативный набор метрик, в т.ч. потребляемая приложением память, в т.ч. с разбивкой по поколениям сборки мусора. Добавлять кастомные метрики, позволяющие мониторить различные аспекты разрабатываемого приложения - более менее стандартная практика. И тут я задался вопросом, а как разделить метрики на группы (смапленные на разные пути: /metrics, /metrics/critical и т.д.), чтобы можно было опрашивать более критичные метрики с большей периодичностью.

Промучавшись некоторое время, я пришёл к следующему решению:
1. Основную группу метрик маппить стандартным способом, дефолтным .MapMetrics() в Program.cs
2. Для своих метрик создать свой CollectorRegistry, дальше методом Metrics.WithCustomRegistry создать экзмепляр фабрики MetricFactory, который заинжектить в приложение.
3. В местах, где требуются нестандартные метрики забирать MetricFactory и с его помощью создавать экземпляры метрик в нужных местах.
4. Отдачу своих метрик в прометеус осуществлять через самописный контроллер, в который инжектится CollectorRegistry. Дальше метрики в качестве text/plain отдаются контроллером.

#prometheus

Запишу инструкцию по настройке основы самого простого автодеплоя с помощью gitea actions. Она основана на документации, но обходит несколько подводных камней на которые я наткнулся в процессе.

Цель: исполнять bash - команды на удаленном сервере по коммиту в репозиторий, раннер крутится как демон, не в контейнере. При этом, для деплоя нам скорее всего потребуется установленный на сервер докер. Работу без докера я не проверял.

1. Качаем бинарник gitea actions runner с сайта на сервер (для совместимости с доступной мне версией gitea я взял раннер двухлетней давности).

wget https://dl.gitea.com/act_runner/0.2.3/act_runner-0.2.3-linux-amd64

2. Переименовываем скачанный файл в act_runner и разрешаем ему исполняться: chmod +x act_runner

3. Добавляем пользователя act_runner, я выдал ему sudo привилегии.

4. Запускаем ./act_runner register и идём по шагам, вставляя по запросу url gitea, registration token из настроек gitea (settings => actions => runners => Create new Runner), как-то называем раннер, затем нас спрашивают добавить labels для активации. Добавляем my_project_deploy_cmd:host
Это указывает runner-у выполнять джобы, помеченные как my_project_deploy_cmd непосредственно на сервере, а не внутри контейнера.

5. Убеждаемся в интерфейсе gitea - появился ли там созданный раннер.

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

[Unit]
Description=Gitea Actions runner
Documentation=https://gitea.com/gitea/act_runner
After=docker.service

[Service]
ExecStart=/home/my_user/act_runner daemon
ExecReload=/bin/kill -s HUP $MAINPID
WorkingDirectory=/home/my_user
TimeoutSec=0
RestartSec=10
Restart=always
User=act_runner

[Install]
WantedBy=multi-user.target

Дальше как в инструкции:

sudo systemctl daemon-reload

sudo systemctl enable act_runner --now

7. Включаем enable actions в настройках репозитория.
8. Добавляем в корень репозитория папку .gitea, в неё - папку workflows, в нее - файл test.yaml со следующим содержимым:

name: test
on:
  - push

jobs:
  test:
    runs-on: my_project_deploy_cmd
    name: test action
    steps:
      - name: test
        run: echo "Hello from Gitea Action11s!" && docker ps -a

Важно, чтобы в runs-on был указан label, который мы задали в конце шага 4. Будет выполнен вывод текста в командную строку, а затем - запрос вывода статусов всех докер-контейнеров на сервере.

9. Имея в распоряжении командную строку, мы можем проделать любые манипуляции с сервером и завести деплой в том виде, в котором нам удобно.

#gitea
#devops