Документ описывает переход на использование Windows Docker для оптимизации процессов сборки в компании с увеличивающимся числом продуктов и необходимостью различных сборочных окружений. Проблемы прежней схемы включали нестабильность сборок и сложность в изменениях, которые теперь решаются с помощью Docker, предлагающего более эффективное управление образами и инфраструктурой. Обсуждаются технологии установки, версионирование образов и необходимость улучшения процессов для интеграционного тестирования.

1. Как мы собираем проекты в выделенном
окружении в Windows Docker
Алексей Буров
CI-инженер
aburov@ptsecurity.com

2. Содержание
1. Как было раньше
2. Проблемы
3. Решение
4. С чем столкнулись

3. Про текущие процессы

4. Что мы имеем
• Компания по разработке ПО
• Увеличивающееся количество продуктов
• Требуется различное сборочное окружение для команд
• Группа поддержки процессов Continuous Integration
• Поддержка новых и старых релизов

5. Как было раньше
• Группировка проектов по используемым технологиям
• Создание идентичного окружения на пуле серверов
• Процесс изменения окружения:
• Изменения вносятся вручную на одном сборочном сервере
• Смотрим, что ничего не сломалось
• Вносим изменения на все сервера
• Чиним то, что сломалось позже
• Делается для экономии ресурсов и отказоустойчивости
• Используется 2 сервера:
• 16CPU
• 256GB RAM
• SSD ~ 3TB

6. Проблема
Как поддерживать зоопарк окружения

7. Проблемы
1. Сборочное окружение ломается
2. Командам нужно изменять окружение самостоятельно
3. Иногда не соблюдается требование отказоустойчивости
4. Не сохраняется сборочное окружение прошлых релизов
5. Неполная утилизация ресурсов виртуальных машин

8. Решение
Windows Docker

9. Долгожданный
• Docker показал себя эффективным инструментом для решения озвученных
проблем
• Опыт работы в системе сборки с Docker Linux > 4 лет
• Своя инфраструктура Docker Registry (Artifactory)
• Windows Docker анонсирован в сентябре 2016 года

10. Сложность установки ПО: но это же Windows
• Linux
• Windows (Пример отсюда)

11. Сложность установки ПО: облегчаем жизнь
Упрощаем

12. Сложность установки ПО: облегчаем жизнь

13. Размер ПО: делаем как в Linux
Linux
• У каждой команды свой docker образ (и не один)
• У каждой компоненты может быть свой docker образ
• Допускается создание фича-веток docker образов
• На сборочных серверах вычищаются все docker образы по ночам

14. Размер ПО: делаем как в Linux
Критерий Linux Windows
Размер образа с основным
набором ПО для компиляции
до 5 GB до 45 GB
Среднее время сборки образа с
нуля
до 20 минут до 70 минут
Среднее время pull до 3 минуты до 50 минут

15. Размер ПО: делаем по своему
Windows
• Есть базовые образы, с предустановленным часто используемым ПО
o Python
o Visual Studio Build Tools
o SDKs
• У каждой команды есть свой образ, где они могут добавлять ПО
• Тестирование новых образов происходит строго на одном сервере
• Docker образы очищаются редко, практически вручную

16. Размер ПО: делаем по своему
vc140
Visual Studio 2015
SDKs
Other
vc150
Visual Studio 2017
SDKs
Other
team1
FROM: vc140
PostgreSQL
Python 3.6 x64
team2
FROM: vc150
.NET Core 2.0
Python 2.7 x86

17. Процесс внесения изменений: установка ПО
• Сохранить exemsi на сервер по адресу yourstorage.example.ru/win/packages
— храним установщики, чтобы меньше зависить от интернета (не всегда
получается, как, например, с msbuild-tools)
• С помощью USSF (Universal Silent Switch Finder) найти ключи для установки
в silent mode
• Добавляем строчку с помощью скрипта install-web.ps1 (или download-and-
unpack) по аналогии с существующими
Примеры Dockerfile доступны по ссылке: github.com/allburov/docker-windows

18. Прочие особенности Windows Docker

19. GetFinalPathNameByHandle
• GetFinalPathNameByHandle отображает относительные и прочие пути в
полный путь используя ? синтаксис
• Неправильно отображает подключенные пути

20. 260 символов хватит всем
• Win32 API MAX_PATH=260 — имя файла не больше 260 символов
• В Windows Docker проблема появляется. Если к запускаемому докеру
подключать директорию, то она подключается как symlink
• c:build =>
• ?ContainerMappedDirectories30FA5B39-9158-4785-A3A9-0435BFF32D2B
• Даже если в хостовой системе путь допустимый и меньше 260 символов, то
в docker он превращается в более длинный путь
• Обещали в локальных политиках дать возможность отключить ограничение
на количество символов в имени

21. У каждого слоя свой hostname
Проблема установки служб
1. Устанавливается в слое rabbitmq
2. В следующем — запускается
3. Проходят еще шаги
4. Запускается контейнер — но у него уже другой hostname
5. Rabbitmq отказывается запускаться
Hostname mismatch: node "rabbit@202fd51f02fd" believes its host is different.
Please ensure that hostnames resolve the same way locally and on
"rabbit@202fd51f02fd"

22. Silent install & GUI
Не всё ПО поддерживает Silent install mode
• gvim (vim для Windows) — ранее не поддерживал silent-установку,
пришлось править инсталлятор
Не всё ПО (даже установщик) может работать без интерфейса
• NET SDK 4.0 — устанавливается только в GUI-режиме

23. Что дальше

24. Дальнейшее развитие
1. Версионирование docker образов
• Нужно для сохранения при релизах наших продуктов
2. Устанавливать продукты в docker и запускать интеграционные тесты
3. Поставлять dev-окружение контейнерами
4. Поставлять production docker образы
Текст доклада и примеры Dockerfile: github.com/allburov/docker-windows

25. Итоги
1. Как было раньше
• только группа Continuous Integration имеет доступ к серверам
2. Проблемы
• долго
• ломалось и нет версионирования
• неэкономно
3. Решение
• упрощение установки — скрипты, фиксированный процесс
• своя схема для Windows
4. С чем столкнулись
• Symbolic Links
• Silent install mode

26. Спасибо!
Вопросы?
Алексей Буров
CI-инженер
aburov@ptsecurity.com