Pull to refresh

Comments 3

Каким образом контролируется версионированость тулов или у Вас пока нет привязки к конкретной версии?
Для хранения образов используете свой docker-registry или dockerhub?
У нас версии тулов такие, которые сбилдились в образы. Так что все, кто будет использовать пайплайн, будут работать с одними и теми же версиями тулов.

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

Для хранения образов мы используем hockerhub.

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


По поводу Docker части: можно попробовать положить весь процесс обработки данных в докер, используя multi-stage build, доступный в версиях 17.05+. В идеале:


  1. Делаем по образу на каждую тулзу, без привязки к конкретной задаче (или берем готовые).
  2. Делаем отдельный multi-stage образ, который на каждом шаге:
    1. Наследует образ нужной утилиты.
    2. Копирует данные из предыдущего уровня.
    3. Запускает тулзу с нужными параметрами.
  3. Далее костыль для извлечения данных, т.к. в build-time у нас нет volume'ов: последним стейджем в multi-stage образе делаем тупой контейнер, который:
    1. В build-time копирует данные из предыдущего контейнера внутрь себя.
    2. В run-time копирует данные из себя в volume.
  4. Делаем docker-compose файл:
    1. С единственным контейнером, который будет собираться на ходу (параметр build), а не image.
    2. С volume'ом, куда надо положить данные на выходе.
  5. Каждый раз, когда нам надо прогнать данные делаем:
    docker-compose up --build

При таком подходе докер образ будет еще более переносимый, а кэширование образов должно сохраниться. Буду рад критике )

Sign up to leave a comment.

Articles