Статьи

Проблема частичной сборки проекта в системе CI/CD может быть довольно сложно решаемой. Она затрагивает несколько аспектов, но самыми важными из них являются два – время, затрачиваемое на сборку проекта при обнаружении изменений, и влияние развертывания артефактов на продуктовую и тестовые системы.

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

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

• отслеживание зависимостей вручную;
• сборка и развертывание на основе Dockerfile;
• автоматическое управление зависимостями на основе контрольного суммирования.

Все эти подходы имеют свои преимущества и недостатки и требуют тщательного анализа перед применением. Давайте кратко рассмотрим каждый из них.

Статья является переводом и адаптацией англоязычной статьи автора Rafael Benevides из Red Hat.

Если вы используете контейнеры, то скорее всего обнаружили, что они решают множество проблем и имеют следующие преимущества:

Неизменяемость. ОС, версии библиотек, конфигурации, каталоги и приложения зафиксированы внутри контейнера. Это гарантирует, что тот же образ, который был протестирован QA, в промышленной среде будет демонстрировать то же поведение.

Легковесность. Объем памяти, используемый контейнером, небольшой. Вместо сотен или тысяч Mбайт, контейнер будет занимать память, необходимую для выполнения его процесса.

Скорость запуска. Запустить контейнер можно так же быстро, как и обычный процесс Linux. Запуск контейнера занимает несколько секунд вместо нескольких минут.

Однако, многие пользователи используют контейнеры как обычные виртуальные машины и забывают, что они обладают важным свойством: после создания образа контейнер не должен изменяться.

QCOW2 – очень популярный формат дисков виртуальных машин. Он широко применяется провайдерами сервисов, организациями и частными лицами, благодаря тому, что в нем используется тонкое выделение (thin provisioning) для пространства и поддерживается создание внутренних снимков. Тома – это обычные файлы, которые можно хранить в локальных файловых системах или удаленных хранилищах NFS. Эти характеристики сделали его фактическим стандартом для использования с гипервизором KVM, который также широко применяется.

Несмотря на достаточно высокую надежность, время от времени диски в формате QCOW2 могут повреждаться. Наш опыт показывает, что проблема часто возникает в тех случаях, когда пользователь пытается создать снимок с диска виртуальной машины, во время высокой нагрузки I/O на диск или все файловое хранилище. Иногда, это ведет к поломке дисков – их нельзя присоединить к виртуальной машине, а машину с ними нельзя запустить.

Данная статья является переводом статьи автора Wes Cossick из Sparksuite.

При работе с любой системой непрерывной интеграции огромное значение имеет скорость выполнения задач интеграции и развертывания. Некоторое время назад мы начали рефакторинг процессов CI, чтобы сделать их максимально быстрыми. Вы cможете сделать то же самое, следуя нашим советам.

При создании сервисов разработчики часто сталкиваются с необходимостью оптимизировать образы Docker, чтобы уcкорить их сборку. Один из путей оптимизации заключается в использовании .dockerignore. Данная статья является переводом и адаптацией англоязычной статьи Алексея Леденева.