Cборка rootfs

Процесс сборки имиджа состоит из двух фаз:

• сборка файлового дерева (root file system, rootfs)
• упаковка rootfs и вместе с конфигурационной информацией в файл.

В этом документе речь пойдет только о фазе сборки rootfs

Минимальный имидж

В Докере имидж "билдит сам себя". То есть, берётся базовый имидж, в него добавляются билд-тулзы, затем добавляются исходники, выполняется компиляция и добавляются результаты билда. И всё это заливается на продакшен.

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

Структура контейнеров и инкрементальных имиджей

Будет два контейнера:

• контейнер сборки
• контейнер продакшена

И 2 иерархии имиджей:

• иерархия сборки
  • корневой имидж
  • билд-имидж ноды (нода + gcc/node-gyp)
  • билд-имидж приложения

• иерархия продакшена
  • нода
  • системные зависимости нодовских либ
  • node_modules
  • приложение

Идея в том, что "промежуточные" имиджи делаются один раз и являются опенсорсными (все имиджи выше кроме имиджа и билд-имиджа приложения).

Корневой имидж

Задача корневого имиджа - собирать другие имиджи. Хочу использовать существующую инфраструктуру, т.е. не лепить dependency management и config file generation из говна и палок, а использовать:

• готовый package manager
• готовый configuration manager

Configuration manager хочу декларативный (по идее нет еботни с порядком), из популярных такой один - puppet. Вопрос только в том, насколько удастся очистить имидж приложения от следов паппета (который для продакшена в общем случае не нужен).

По идее, package manager должен использоваться не напрямую, а через configuration manager.

Билд-имиджи стеков

Предполагается, что будут билд-имиджи "для ноды" и "для хаскеля".

Соответственно, они будут искать package.json и *.cabal в предопределённом каталоге, и собирать по ним билд-имидж приложения и иерархию продакшена.