суббота, 4 января 2025 г.

Заметки о сосуществовании сервера GitLab и кластер Kubernetes

Забавно было пропасть на 3 года.

Ниже приведены заметки и личный субъективный опыт отработки взаимодействия k8s кластера и сервера GitLab - каждому своё.

  • в своей лаборатории я разносил namespace для gitlab-agent и gitlab-runner, из плюсов - атамарное управление разными уровнями функциональной нагрузки:

[ladmin@k8sm01 k8sdemo]$ kubectl get namespaces | grep gitlab

gitlab-agent-k8s    Active   36d

gitlab-runners-ns   Active   52m

  • правильные настройки в values.yaml  для установки gitlab-runner на k8s в части репозитария и образа:
image:
  registry: registry.gitlab.com
  image: gitlab-org/gitlab-runner
  tag: alpine-v17.6.0
версия образа - будет меняться по необходимости.

  •  я использовал  встроенный в GitLab сервер Container Registry без использования SSL сертификатов - лень было делать в лаборатории. В результате я получал ImagePullBackOff при попытке развернуть что-либо с детализацией ошибки "server gave HTTP reply to HTTPS client". Исправил это путём модификации /etc/containerd/config.toml каждого узла кластера k8s.
        
    
    далее следует выполнить:
sudo systemctl restart containerd.service
  • после обновления GitLab сервер необходимо также обновить GitLab agent на кластере k8s.

helm upgrade <release_name> gitlab/gitlab-agent  --namespace <k8s_namespace_name> --set image.tag=vX.Y.Z --set config.token=<your_token>  --set config.kasAddress=ws://devops.test-lab.ru/-/kubernetes-agent/ --set replicas=1

            Если забыть указать токен, то вы получите ошибку 

kubectl logs  k8s-gitlab-agent-v2-56777f97d6-dnbqq  -n gitlab-agent-k8s

{"time":"2025-01-04T10:21:36.816484327Z","level":"ERROR","msg":"Program aborted","error":"token file: open /etc/agentk/secrets/token: no such file or directory"}

  • при конфигурации GitLab сервер для использования Container Registry я допустил ошибку, использовав один и тот же порт для нескольких элементов GitLab. Ошибку удалось вычислить по записи в /var/log/gitlab/registry/current.
sudo cat /var/log/gitlab/registry/current | tail -10

 

"2024-12-26_08:22:56.55672 time="2024-12-26T11:22:56.556+03:00" level=fatal msg="listen tcp 127.0.0.1:5005: bind: address already in use"

          Что было исправлено:


    Далее необходимо выполнить команды ниже, иначе ошибка никуда не уйдёт (по-моему, "gitlab-ctl reconfigure" будет достаточно):

sudo systemctl restart gitlab.target

sudo gitlab-ctl restart nginx

sudo gitlab-ctl reconfigure

sudo gitlab-ctl status


  • если в секции ниже в values.yaml для gitlab runner значения параметров  "allowPrivilegeEscalation", "privileged" будут иметь разные значения - получите ошибку "cannot set `allowPrivilegeEscalation` to false and `privileged` to true". 

securityContext:
  allowPrivilegeEscalation: true
  readOnlyRootFilesystem: false
  runAsNonRoot: true
  privileged: true
  capabilities:
    drop: ["ALL"]

суббота, 19 февраля 2022 г.

Нюанс работы с задачей " Azure Key Vault" в Azure DevOps

В своём проекте я столкнулся с необходимостью извлекать секреты из Azure Key Vault (AKV), который изолирован внутри виртуальной сети. Если коротко, то это очень частый сценарий, используемый для повышения безопасности сервисов Azure и AKV в частности.

Заметка: Self-hosted агент мы не рассматриваем.

Агенты Azure DevOps (AzDO) не являются доверенным сервисом для Azure, поэтому настройка "Allow Trusted Microsoft Services to bypass this firewall." для агентов AzDO не работает. 

Если вы использовали Variable groups для инъекции секретов в Pipelines/Release - они, при использовании изолированного AKV, работать перестанут.

В этом случае поможет комбинация задач, из которых: 

первая добавит публичный адрес агента AzDO  в список разрешенных на AKV, затем необходимо использовать отдельную задачу "Azure Key Vault" для извлечения списка секретов и их содержимого, ну и третья задача должна удалить публичный адрес агента из списка разрешенных.

Есть нюанс: обратите внимание на настройку "Make secrets available to whole job"





При сценарии, описанном выше, необходимо её выключить, иначе извлечения секретов будет выполняться как пред-задача, которая запуститься до того, как будут сделаны настройки файрвола AKV. Соотвественно вы получите ошибку ниже.




среда, 6 октября 2021 г.

Неожиданные символы при работе с ARM template для API management

В одном из сценариев автоматизации мне понадобилось "на лету" менять значения в шаблонах для нескольких API, которые в последствии разворачивались в другое окружение.

Неожиданно для себя я получил какое-то невменяемое сообщение об ошибке а-ля неопознанные команды и т.д. Сначала я заглянул в шаблон через Notepad, но ничего не обнаружил, однако, каково было моё удивление, когда я открыл тот же шаблон в Visual Studio Code.


Изменения производились через PowerShell скрипт и он был всему виной. Другого объяснения у меня не было. 

Происходила замена символа одинарной кавычки на код.

Очень интересно то, что кодированные кавычки появлялись уже после чтения файла, а не после его сохранения.

Проблема решилась достаточно банально.






Get-AzApiManagementPolicy не возвращает политику для области API при наличии параметра -ApiId

Краткая заметка о работе с PowerShell Cmdlets для API management.

Замечено, что команда Get-AzApiManagementPolicy -ApiId "<api_id"> -Context $apimContext может не вернуть ничего в случае, когда политика для конкретного API имеет конфигурацию по-умолчанию.

Стоит добавить что-либо разумное и команда начинает возвращать состав политики.

пятница, 23 апреля 2021 г.

Неправильный артифакт может скачиваться с Bamboo при определённых обстоятельствах

Забавный баг обнаружился при работе с Google Chrome и Bamboo.

Несмотря на то, что был доступен новый артифакт размером в 1 МБ в пайплайне, браузер упорно скачивал старый в 5 МБ. Помогло только использование Incognito режима. Вероятно что-то с кэшем.



 

понедельник, 22 марта 2021 г.

Smart Screen выдаёт "Publisher: Unknown" при попытке установить собранный MSI или Exe файл

Очень часто встречался с ситуацией, когда люди подписав MSI или EXE с помощью signtool.exe из Windows SDK жаловались на то, что Windows Smart Screen выдаёт в сообщении   "Publisher: Unknown".

Проблема решается достаточно легко даже для самоподписанного сертификата:

Вам необходимо, чтобы рабочая станция или сервер, где запускается ПО, доверяли сертификату подписи.










среда, 10 марта 2021 г.

Ошибка "ServiceExists" при развёртывании Azure API management с помощью ARM template

Можно столкнуться с подобной проблемой при переразвёртывании окружений с помощью ARM templates.

Вызывается данная проблема из-за фунеционала "Soft delete" для сущностей APIM, который реализован в Azure. По умолчанию, удалённый объект сохраняется до 48 часов, чтобы его можно было восстановить, если удаление было случайным.

В тоже время, это мешает развернуть APIM  с таким же именем.

Решить эту проблему можно перейдя по ссылке API ниже и выполнив пару простых действий (указать регион, где был размещён APIM и его имя). Это API позволяет вычистить всё удалённые сущности.

https://docs.microsoft.com/en-us/rest/api/apimanagement/2020-06-01-preview/deletedservices/purge#code-try-0

Кстати, замечу, что для многих сервисов Azure есть разные интересные API,  которые могут помочь решить проблему, если az cli, PowerShell или портал не позволяют добиться желаемого.