= 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 в предопределённом каталоге, и собирать по ним билд-имидж приложения и иерархию продакшена.