83 lines
3.3 KiB
Text
83 lines
3.3 KiB
Text
|
# distbuild
|
|||
|
Домашнее задание 2
|
|||
|
|
|||
|
## Цели второго ДЗ
|
|||
|
|
|||
|
- Написать _сложную_ систему
|
|||
|
- Без _сложных_ алгоритмов
|
|||
|
- Но с большим числом движущихся частей
|
|||
|
|
|||
|
- Написать подсистему исполнения джобов
|
|||
|
|
|||
|
- Написать клиент + сервер
|
|||
|
|
|||
|
## Современная сборка
|
|||
|
|
|||
|
Что происходит, когда вы запускаете `go build ./cmd/gitfame`?
|
|||
|
|
|||
|
.image graph.avif _ 900
|
|||
|
|
|||
|
## Современная сборка
|
|||
|
|
|||
|
Что происходит, когда вы запускаете `go build ./cmd/gitfame`?
|
|||
|
|
|||
|
1. `go build` строит граф сборки
|
|||
|
- Вершина графа - файл + команда для его сборки (compile/link)
|
|||
|
- Ребра - входные файлы для команды / зависимости
|
|||
|
- Чтобы слинковать исполняемый файл, нужно скомпилировать все пакеты
|
|||
|
- Чтобы запустить тест, нужно собрать исполняемый файл теста
|
|||
|
- Все зависимости явно указаны в графе (герметичность). <s>`./run-whatever.sh`</s>
|
|||
|
2. Граф сборки исполняется
|
|||
|
- Команды в вершинах исполняются параллельно, если это возможно
|
|||
|
- Результаты складываются в кэш
|
|||
|
- Вместо исполнения команды, результат могут взять из кеша
|
|||
|
|
|||
|
## Современная сборка
|
|||
|
|
|||
|
.image jobs.avif _ 900
|
|||
|
|
|||
|
## Как работает кэш
|
|||
|
|
|||
|
Обычный кэш `key -> value`.
|
|||
|
|
|||
|
- `value` - директория с файлами
|
|||
|
- Как сформировать ключ?
|
|||
|
- `"./cmd/gitfame"` - не подходит
|
|||
|
- Можно использовать хеш `sha1` от всех входных файлов и от всех команд вершины.
|
|||
|
- Хеш входного файла можно заменить на ключ вершины, которая его породила.
|
|||
|
|
|||
|
## Как работает кэш
|
|||
|
|
|||
|
.image hash.avif _ 900
|
|||
|
|
|||
|
## Задача distbuild
|
|||
|
|
|||
|
- Граф сборки дан на вход
|
|||
|
- Нужно исполнить этот граф в распределённой системе и закешировать результат
|
|||
|
|
|||
|
- Система состоит из 3-х компонент:
|
|||
|
* Клиент
|
|||
|
* Координатор
|
|||
|
* Воркер
|
|||
|
|
|||
|
## Клиент
|
|||
|
|
|||
|
* Представьте, что он работает внутри команды `go build`
|
|||
|
* Вам дают граф сборки.
|
|||
|
* Нужно залить граф на координатор, вместе с исходными файлами.
|
|||
|
* После этого, стримить результаты исполнения с координатора.
|
|||
|
|
|||
|
## Воркер
|
|||
|
|
|||
|
* В цикле просит с координатора следующий джоб и исполняет его.
|
|||
|
* Хранит кеш артефактов.
|
|||
|
|
|||
|
## Координатор
|
|||
|
|
|||
|
* Общается с клиентом и воркером.
|
|||
|
* Решает на каком воркере запускать какой джоб.
|
|||
|
|
|||
|
## Links
|
|||
|
|
|||
|
- [How bazel works](https://sluongng.hashnode.dev/bazel-caching-explained-pt-1-how-bazel-works)
|