В dapp при сборке образов используются следующие кэши:

  • Сборочный кэш приложения — образы в docker.
  • Кэш из build-директории:

Сборочный кэш приложения

Сборочный кэш приложения — это набор docker-образов, который определяется стадиями приложения: одной стадии соответствует один docker-образ.

Любая стадия в dapp имеет идентификатор содержимого стадии, называемый сигнатурой стадии. Сигнатура стадии зависит от правил её сборки и представляет собой контрольную сумму от этих правил. Если разные стадии имеют одинаковую сигнатуру — это означает, что содержимое этих образов одинаково. Соответственно стадии, имеющие одинаковую сигнатуру представлены одним docker образом.

Стандартный процесс сборки приложения через dapp представляет собой сборку набора docker-образов. В процессе сборки docker-образы тех стадий, которые собрались остаются “невидимыми” пользователю dapp, они имеют только временный идентификатор в docker. Только после успешной сборки всех стадий приложения, docker-образы попадают в сборочный кэш приложения. Технически docker-образ попадает в сборочный кэш в тот момент, когда dapp тегирует этот образ специальным образом: используя dimgstage-<имя-репозитория-приложения> в качестве имени образа и сигнатуры стадии в качестве тега образа.

Важно. В случае возникновения ошибки в правилах сборки образа все собранные на данный момент “временные” docker-образы будут удалены и не попадут в сборочный кэш. Dapp поддерживает специальный отладочный режим работы, в котором docker-образы тегируются и попадают в отдельный сборочный кэш сразу после успешной сборки стадии приложения. Подробнее об этом описано в разделе debug.

Для примера, docker-образы из сборочного кэша приложения dapp-example-chef-for-advanced-build-2 будут выглядеть так:

REPOSITORY                                         TAG                                                                IMAGE ID            CREATED             SIZE
dimgstage-dapp-example-chef-for-advanced-build-2   5ca21f76a99a4a9ac1995d9a8a9c20779795c1c6eb2f8ed64bd773cb9f976589   363f6a74a9d3        25 hours ago        696.4 MB
dimgstage-dapp-example-chef-for-advanced-build-2   dd1eeec8047f1734873a5774b1a6c5b420d20fd285565d25251ded257abe5c29   d7634201dc13        25 hours ago        696.4 MB
dimgstage-dapp-example-chef-for-advanced-build-2   e91bc27414fe2dd8a5d5caf3c76e734a675111ccd7e3857e9e62389bb6d7c566   3a38f7584edf        25 hours ago        696.4 MB
dimgstage-dapp-example-chef-for-advanced-build-2   ea1be67f7231595de75d6c7b523cd3f800be6d56aa3892b65d4b55f9750566bb   fe17f466c4bc        25 hours ago        696.4 MB
dimgstage-dapp-example-chef-for-advanced-build-2   d85001d96adf7b7f8db44deb7d9f299004a64dde382c5ffa4aff03909760e33f   003334f54a59        25 hours ago        696.4 MB
dimgstage-dapp-example-chef-for-advanced-build-2   54adf11783b64cf173d289110b686e1c59cf260bc8f0229d23d556d235d78dc6   3cad59340388        25 hours ago        696.4 MB
dimgstage-dapp-example-chef-for-advanced-build-2   712f10136d4f3eebe0323d60c32f55983b0e3cc7a0c26e2f24f2f8ed1907ce34   89d1b78e46f8        25 hours ago        696.4 MB
dimgstage-dapp-example-chef-for-advanced-build-2   0de3ccb420da3c0933afeb6da5e3cb4e8bb4fef9cd1cb972d9e0e5ffa7fdb250   17745eedc11d        25 hours ago        696.4 MB
dimgstage-dapp-example-chef-for-advanced-build-2   68cfaf347f8a36d82e760f0beabe0010cff0a36414a91f961572858de862f146   058cad43eaee        25 hours ago        696.4 MB
dimgstage-dapp-example-chef-for-advanced-build-2   0f9f8bf59e0c41c356f421c7172fbb986bc7f0ab44ffda994368ffefcbbbd694   38436caa71c0        25 hours ago        696.4 MB
dimgstage-dapp-example-chef-for-advanced-build-2   572c4398a323ee3c4381537652969b90bd15a9f01c3fc18dc49aa7686073e580   1bc8cc41f341        25 hours ago        696.4 MB
dimgstage-dapp-example-chef-for-advanced-build-2   334e64203908c61c3f9b5a52f277730f4e322a832fe3808a42b90c4fcc2339d9   01c35cfa9f1c        25 hours ago        696.4 MB
dimgstage-dapp-example-chef-for-advanced-build-2   d5f44f46d94b344fd2eacf8ec6e92aee3e106dcaeff14e81bade0553cc235f31   2ebbf65b0968        25 hours ago        696.4 MB
dimgstage-dapp-example-chef-for-advanced-build-2   ba1e802a942cbc09b361a5dc9572911e98644e63d1aa501fe6a464e3a546a8c3   33a7862bf459        25 hours ago        696.4 MB
dimgstage-dapp-example-chef-for-advanced-build-2   79d5a4ccbd4fbc1db248037b5b333145574030f5c4d666d4056f562abff456fc   84fd57136bad        25 hours ago        696.4 MB
dimgstage-dapp-example-chef-for-advanced-build-2   b4eabf30cbfb46e6f4448eef6bd8460de40708213cfce81e9c2a7712c8b93694   90926f90755d        25 hours ago        681.3 MB
dimgstage-dapp-example-chef-for-advanced-build-2   dc86cf4c0af49a1c6250e83b7eab1b7632a851caedad5abe5cc98ff004127aaf   c14050f50d63        25 hours ago        681.3 MB
dimgstage-dapp-example-chef-for-advanced-build-2   25d9ad1d8304c4e1d9b23bda1ee42bcc239cb8a9ca11c47ba1bc5a7b9a1a6e63   2dfae5f84164        25 hours ago        681.3 MB
dimgstage-dapp-example-chef-for-advanced-build-2   ff48395b0d95ea1047e0f9ce96f48deefe98aa66aebe1f12d9376cce336b15f0   93256ff2c00e        25 hours ago        681.3 MB
dimgstage-dapp-example-chef-for-advanced-build-2   7454175f0f7915026bf78852bab47d49c1fdbe3586ec7c8528252059969b8d34   e0baa72ddbac        25 hours ago        681.3 MB

Docker-образы разных dimg, собираемых через один Dappfile, будут иметь одинаковые имена образов, различаться будут только теги. В имени образа используется:

  • либо имя репозитория, в котором находится Dappfile (при этом Dappfile не обязательно должен находиться в корне этого репозитория);
  • либо имя директории, в которой находится Dappfile.

Соответственно в примере выше dapp-example-chef-for-advanced-build-2 — это имя репозитория тестового проекта https://github.com/flant/dapp-example-chef-for-advanced-build-2.

Что надо чистить в обычном рабочем процессе

В процессе использования dapp наступает момент, когда неактуальные docker-образы надо удалять, т.к. они занимают место.

Процесс сборки и публикации образа в распределенном окружении включает в себя:

  • На сборочном сервере:
    • Скачивание кэша сборки приложения.
    • Сборка образов.
  • Выкат образа приложения вместе со сборочным кэшем в registry.

Локальные образы на сборочном сервере синхронизируются с образами в registry. Registry является первичным источником информации о том, какие образы лишние.

Неактуальный кэш приложений

Набор связанных с dapp приложением образов в registry состоит из:

  • Конечных образов приложений, о схеме их именования см подробнее в разделе registry.
    • При этом на сборочной машине такие образы не создаются, т.к. не нужны.
  • Образов сборочного кэша, связанных с конечными образами приложений.

Пользователь dapp управляет очисткой кэша удаляя конечные образы приложения из registry. Для удаления конкретных конечных образов приложения не существует специальных команд в dapp — пользователь делает это самостоятельно.

Удаление же связанных с этими конечными образами приложения образов кэша сборки — по сути синхронизация сборочного кэша с реально существующими версиями приложения — происходит с помощью использования команд dapp.

  • dapp dimg stages cleanup local --improper-repo-cache удаляет те локальные образы, которые не связаны ни с одним образом конечного приложения из registry.
  • dapp dimg stages cleanup repo --improper-repo-cache удаляет то же самое, но в самом registry.

Примечание. Для обеих команд первичным источником информации о существующих конечных образах приложения является registry. Как следствие, запуск dapp dimg stages cleanup local --improper-repo-cache до публикации собранного приложения в registry удалит весь локальных кэш (т.к. registry пуст).

Образы от старых версий сборщика dapp

Docker-образы, которые создает dapp могут стать неактуальными после обновления версии dapp. Но такое происходит только в случае, если в dapp произошли существенные изменения в логике сборки и требуется пересборка уже собранных ранее образов. От пользователя требуется периодически запускать специальные команды очистки таких образов.

Аналогично, предыдущему разделу, есть 2 команды для удаления локальных образов и образов в registry.

  • dapp dimg stages cleanup local --improper-cache-version удалит локальные docker-образы более не актуальные для текущей версии dapp.
  • dapp dimg stages cleanup repo --improper-cache-version удалит docker-образы более не актуальные для текущей версии dapp из registry.

Некорректный сборочный кэш из-за использования git rebase

Допустим, пользователь собрал для приложения, использующего git-артефакт некоторый образ. А затем, для git-артефакта был сделан rebase, была поменяна история коммитов и использовавшийся в кэше сборки идентификатор коммита перестал существовать в git-репозитории. Попытка сборки при наличии такого кэша приведет к ошибкам.

Поэтому существуют специальные команды удаления кэша, который более не валиден из-за изменений в связанных git-репозиториях:

  • dapp dimg stages cleanup local --improper-git-commit — локально;
  • dapp dimg stages cleanup repo --improper-git-commit — в registry.

На данный момент автоматической инвалидации подобных образов не предусмотрено.

Промежуточные docker-образы, которые по каким-либо причинам были собраны dapp’ом, но не были протегированы — т.е. не попали в сборочный кэш

Если прервать работу сборщика, убив процесс — все собранные стадии останутся в docker непротегированными в следующем виде:

REPOSITORY                                         TAG                                                                IMAGE ID            CREATED             SIZE
<none>                                             <none>                                                             b482808d6b36        14 seconds ago      130 MB
<none>                                             <none>                                                             6fa6a4d13396        31 seconds ago      130 MB

Чтобы избавиться от этих образов есть команда dapp dimg cleanup.

В результате ее работы будут удалены нетегированные docker-образы, только связанные с данным проектом. Технически dapp может идентифицировать эти образы по специальной метке, которая проставляется на все образы, создаваемые при сборке.

Принудительная очистка кэша приложения

Если требуется принудительно сбросить сборочный кэш приложения, есть отдельная подкоманда flush:

  • dapp dimg stages flush local — локально;
  • dapp dimg stages flush repo — в registry.

Подсказка. Cleanup — очистка лишнего. Flush — принудительный сброс.

Режим разработчика и сборочный кэш

Для режима разработчика, подробнее о котором рассказано в отдельном разделе, существует опция --dev, добавляемая во все команды сборки и очистки образов. В этом режиме создается отдельный кэш образов, никак не пересекающийся от кэша не в режиме разработчика. Все описанные команды кроме mrproper применимы и для режима разработчика при дополнительном указании опции --dev.

TODO: очистка dev-кэша через mrproper

TODO: dapp dimg mrproper: зачем нужен, когда используется

Кэш из build-директории

Кэш из build-директории включает в себя:

TODO: когда, при каких изменениях происходит переустановка cookbook’ов.

Для очистки данного кэша — достаточно удалить директорию .dapp_build (может быть переопределена на нестандартную).

Перенос кэша dapp на другую машину

Dapp предоставляет команды для переноса сборочного кэша и кэша из build-директории с машины на машину. Процесс переноса представляет собой следующие шаги:

Экспорт кэша

Экспорт кэша — это создание набора архивов с помощью команды dapp dimg build-context export. По умолчанию экспорт создает в текущей директории набор архивов: build.tar (build-директория) и images.tar (сборочный кэш из docker).

Импорт кэша

После переноса build.tar и images.tar на другую машину в директорию проекта, загрузка осуществляется следующей командой: dapp dimg build-context import.

Примечание. Для экспорта и импорта можно переопределить директорию, содержащую архивы с помощью опции --build-context-directory.