Gitlab: Как работать с кешами размером более 5 ГБ с автоматически масштабируемым раннером с S3 - PullRequest
0 голосов
/ 21 октября 2018

Я настроил свой проект yocto на использование автоматически масштабируемого gitlab-runner для запуска на AWS, и теперь я заметил, что по мере роста проекта кэш не загружается каждый раз.

Uploading cache.zip to https://build-yocto.s3.amazonaws.com/project/default 
WARNING: Retrying...                               
Uploading cache.zip to https://build-yocto.s3.amazonaws.com/project/default 
FATAL: Received: 400 Bad Request                   
Failed to create cache

cache содержит каталог sstate-cache для ускорения перестройки, которая вначале работала как чудо, но теперь не работает, поскольку (по крайней мере, таков мой вывод) каталог sstate вырос до> 10 ГБ.

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

Есть ли обходной путь для этой проблемы?как предварительная обработка sstate-кеша и загрузка нескольких кешей?

1 Ответ

0 голосов
/ 22 октября 2018

Gitlab в настоящее время не поддерживает многоэтапную загрузку на S3, поэтому он может обрабатывать только кэши размером до 5 ГБ.Но, прежде чем продолжить чтение, ознакомьтесь с предложением по этой проблеме / функции по этой теме!

Поэтому я создал себе грязный обходной путь, но будьте осторожны!Любой, кто запускает сборку на этом средстве запуска, может просто напечатать AWS AccessKey / SecretKey в журнал сборки!

По сути, я просто повторил извлечение и извлечение кеша из S3 и выполняю это вручную до и послемой buildjob.

В моем gitlab runner config.toml я добавил следующую строку в раздел [[runners]]:

environment = ["AWS_ACCESS_KEY_ID=<AccessKey>", "AWS_SECRET_ACCESS_KEY=<SecretKey>", "AWS_DEFAULT_REGION=<region>", "AWS_DEFAULT_OUTPUT=<json,text or table>"]

Таким образом, установлены переменные evrionment и в aws cli есть все, что нужноНужны.

В моем Dockerfile мне нужно было добавить эти пакеты:

# Install AWS CLI and tools
RUN apt-get install -y awscli tar pigz

Сценарий загрузки:

#!/bin/bash
mkdir <path to cache>
aws s3 cp s3://<bucket name>/cache - | pigz -dc | tar -xf - -C <path to cache>

Сценарий загрузки:

#!/bin/bash
tar cf - -C <path to cache> . | pigz | aws s3 cp - s3://<bucket name>/cache --expected-size 7516192768

--expected-size - приблизительный размер кэша.Это необходимо, так как aws cp s3 необходимо выбрать размер частей кэша, и если он выберет слишком маленький размер для загрузки, он превысит максимальный лимит частей многочастной загрузки.В моем примере использовалось 7 ГБ.

Мой .gitlab-ci.yaml теперь выглядит так:

build:
  script:
    - ./download_cache.sh
    - ./build.sh
    - ./upload_cache.sh
...