Непрерывная Интеграция — Тестирование Сборок Образа Докера При Изменении Библиотек Низкого Уровня.

Фон

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

•  myorg/python-app1 

  : produces package myorg/python-lib2
• myorg/python-lib1 : produces package myorg/python-app1
• # Builds image reistry.myorg.com/python-app FROM reistry.myorg.com/python-base:latest COPY . /app # Implicitly gets the latest `myorg.lib1` and `myorg.lib2` from PyPI RUN pip install /app : produces a package myorg/python-app1 , зависит от myorg/python-lib1 и myorg/python-lib1

В нашем КИ для myorg.lib2 and myorg.lib1 мы запускаем модульные тесты, когда приходят PR, и публикуем колеса в PyPI при слияниях с основной веткой.

В нашем КИ для myorg.app we will build test application images when PRs come, deploy them to a test kubernetes cluster, and allow developers to run integration tests against it. It has a Dockerfile like:

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

Проблема

Поскольку мы запускаем интеграционные тесты только для myorg.lib2 , we can't get as much confidence when a change to myorg/python-lib2 and myorg.lib1 happens. We have to wait for the libraries to get published to PyPI and then rebuild the application images. When there's an issue in the library, this usually involves us git reverting and fixing the PyPI version. This is super cumbersome when we have a lot of images that pull in the dependency before we detect it needs to be rolled back.

Я хочу реструктурировать способ создания изображений в myorg/python-lib1 (and other apps that share this pattern) to support pulling in dependencies based off of the PR branches.

Я просмотрел множество инструментов для контейнеризации, но не увидел никаких стратегий создания контейнеров приложений с учетом изменения зависимости более низкого уровня. Мне интересно посмотреть, какие стратегии существуют для этого. Надеемся, что эту стратегию можно будет применить и к другим языкам, где у нас есть аналогичные стратегии для приложений, написанных на таких языках, как Java, Golang и npm.

#docker #непрерывная интеграция #контейнеры #python #тестирование

Поэтому я считаю, что нашел несколько повторно используемое решение этой проблемы, используя Девпи. Это позволяет вам использовать один и тот же Dockerfile для тестового и рабочего образа.

Devpi позволяет мне создавать собственный индекс, который может дублировать мой производственный индекс версиями программного обеспечения, которые не были официально выпущены.

Шаги, чтобы сделать эту работу:

1. Базовый образ от ARG

Сначала я отредактировал свой Dockerfile, чтобы разрешить перезапись используемого базового образа. Это позволит мне создать средний уровень, который настраивает pip для взаимодействия с devpi:

 
 
 
 docker build -t devpi-base -f devpi.Dockerfile .
docker build -t my-app -f Dockerfile --build-arg=BASE=devpi-base .
docker tag my-app reistry.myorg.com/my-app:test1
docker push reistry.myorg.com/my-app:test1
 
 
 
 

2. Загрузите тестовые версии библиотеки.

Для каждого изменения Python:

• Клонировать репозиторий
• FROM reistry.myorg.com/python-base:latest COPY pip.conf /etc/pip.conf the repo
• [global] index-url = http://<some ip>:<some port>/root/dev/+simple/ trusted-host = <some ip> disable-pip-version-check = true [search] index = http://<some ip>:<some port>/root/dev/ the wheels

3. Создайте слой с помощью devpi pip conf.

Создайте конфигурацию pip, которая сможет получить доступ к вашему экземпляру devpi и настроить имя вашего индекса:

И добавьте это в pip conf базовых изображений:

4. Соедините изображения вместе

Теперь, когда pip устанавливает все ваши зависимости, вы можете получить изменения более низкого уровня в пакетах Python. Я думаю, эту концепцию можно будет повторно использовать во многих языках!