В мае этого года вышел релиз ГитЛаба 8.8. Частью этого релиза был запуск встроенного Docker Container Registry. Ниже перевод майской статьи, посвященной этому.
Недавно нами был выпущен GitLab версии 8.8, в которой поддержка CI стала еще лучше. Теперь в GitLab можно строить конвейеры (pipelines) для визуализации сборок, тестов, развертывания и любых других этапов жизненного цикла вашего ПО. Сегодня мы представляем вам следующий этап: GitLab Container Registry .
GitLab Container Registry — это безопасный приватный реестр для образов (images) Docker, разработанный с помощью ПО с открытым кодом. GitLab Container Registry полностью интегрирован в GitLab.
Ключевыми особенностями GitLab являются непрерывность процесса разработки и взаимная интеграция различных элементов; эти принципы сохраняются и при работе с нашим реестром. Теперь при помощи GitLab Container Registry вы можете использовать ваши Docker-образы для GitLab CI, создавать специальные образы для отдельных тегов и веток, а также многое другое.
Стоит отметить, что GitLab Container Registry является первым реестром Docker, полностью интегрированным в систему управления Git-репозиториями. Кроме того, GitLab Container Registry не требует отдельной установки, так как является частью GitLab 8.8; c его помощью можно легко скачивать и загружать образы на GitLab CI. И еще он бесплатный.
Для того, чтобы узнать, как включить использование GitLab Container Registry, обратитесь к документации для администратора.
Основы Docker
Основной единицей работы с Docker является образ, в котором содержится все необходимое для запуска и работы приложения. Зачастую образы создаются автоматически, как часть процесса непрерывной интеграции — то есть они обновляются при каждом изменении кода. В случаях, когда образы создаются для совместного использования, их нужно где-то хранить. Как раз для этого и применяется реестр образов.
Реестр позволяет хранить образы для дальнейшего переиспользования и категоризовать их, используя теги. Хорошей идеей является создание реестра для хранения приватных образов, используемых только внутри компании, или, к примеру, образов для запуска и прогона тестов. При использовании GitLab Container Registry не нужно настраивать и поддерживать дополнительные сервисы или использовать публичные реестры.
Тесная интеграция с GitLab
GitLab Container Registry полностью интегрирован в GitLab, что позволяет разработчикам с легкостью создавать, тестировать и запускать образы Docker, используя GitLab CI или другие инструменты, совместимые с Docker.
- Для аутентификации и разграничения доступа используются пользователи и группы из вашего инстанса GitLab.
- Нет необходимости создавать дополнительные репозитории для работы с реестром – реестр является частью вашего проекта в GitLab.
- В проекте появляется новая вкладка Container Registry, в которой перечислены все образы, относящиеся к данному проекту.
- У каждого проекта может быть собственный реестр образов (опционально, может быть отключено для любого отдельного проекта).
- Можно легко скачивать и загружать образы на GitLab CI.
- Не нужно скачивать и устанавливать дополнительный софт.
Упростите ваш рабочий процесс
Работа с GitLab Container Registry проста и безопасна. Вот несколько примеров того, как использование GitLab Container Registry может упростить процесс разработки и развертывания ПО:
- Проводите сборку образов Docker с помощью GitLab CI с последующим их хранением в GitLab Container Registry.
- Привязывайте образы к веткам, тегам исходного кода или используйте любой другой способ, подходящий для вашего процесса разработки. Созданные образы можно быстро и легко сохранить на GitLab.
- Используйте собственные образы сборок, хранящиеся в вашем реестре, для тестирования приложений.
- Пусть остальные участники команды также участвуют в разработке образов. Это не потребует от них дополнительных усилий, так как используется тот же рабочий процесс, к которому они привыкли. GitLab CI позволяет проводить автоматическую сборку образов, унаследованных от ваших, что в свою очередь позволяет с легкостью добавлять фиксы и новые фичи в базовый образ, используемый вашей командой.
- Настройте CaaS на использование образов напрямую из GitLab Container Registry, получив таким образом процесс непрерывного развертывания кода. Это позволит проводить автоматическое развертывание приложений в облако (Docker Cloud, Docker Swarm, Kubernetes и т. п.) каждый раз, когда вы собираете или тестируете образ.
С чего начать?
В первую очередь, попросите вашего системного администратора подключить GitLab Container Registry так, как описано в документации для администратора..
После этого вы сможете включить опцию Container Registry в вашем проекте.
Для того, чтобы начать использовать реестр, сперва нужно залогиниться:
docker login registry.example.com
После этого можно просто собирать и пушить образы на GitLab:
docker build -t registry.example.com/group/project .
docker push registry.example.com/group/project
Также GitLab предоставляет простой интерфейс для управления контейнерами. Нажмите на Container Registry в вашем проекте — в открывшемся окне вы увидите все теги в вашем репозитории и легко сможете удалить любой из них.
Для получения более подробной информации обратитесь к GitLab Container Registry user guide.
Используйте совместно с GitLab CI
Встроенный интерфейс для управления CI GitLab’а можно использовать для сборки, пуша и развертывания созданных образов.
Внимание: для этого требуется GitLab Runner 1.2.
Внимание: Для того, чтобы использовать Docker в образах Docker, необходимо установить флаг privileged в конфигурации Runner’а.Пока что это невозможно сделать в общих (shared) Runner’ах на GitLab.com. Мы планируем добавить этот флаг в ближайшее время, а пока что стоит использовать собственные Runner’ы.
Вот пример конфигурационного файла GitLab CI (.gitlab-ci.yml
), который собирает образ, запускает тесты и, в случае их успешного прохождения, присваивает билду тег и загружает билд в реестр образов:
build_image:
image: docker:git
services:
- docker:dind
script:
- docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.example.com
- docker build -t registry.example.com/my-group/my-project .
- docker run registry.example.com/my-group/my-project /script/to/run/tests
- docker push registry.example.com/my-group/my-project:latest
only:
- master
Пример более сложного образа, который разделяет задания на 4 стадии, в рамках которых два теста исполняются параллельно. Билд сохраняется в реестре образов и используется на последующих стадиях, автоматически скачивая образ при необходимости. Изменениям в мастер-ветку присваиваются тег latest
, после чего происходит развертывание этих изменений с использованием индивидуального для данного приложения скрипта:
image: docker:git
services:
- docker:dind
stages:
- build
- test
- release
- deploy
variables:
CONTAINER_TEST_IMAGE: registry.example.com/my-group/my-project:$CI_BUILD_REF_NAME
CONTAINER_RELEASE_IMAGE: registry.example.com/my-group/my-project:latest
before_script:
- docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.example.com
build:
stage: build
script:
- docker build -t $CONTAINER_TEST_IMAGE .
- docker push $CONTAINER_TEST_IMAGE
test1:
stage: test
script:
- docker run $CONTAINER_TEST_IMAGE /script/to/run/tests
test2:
stage: test
script:
- docker run $CONTAINER_TEST_IMAGE /script/to/run/another/test
release-image:
stage: release
script:
- docker pull $CONTAINER_TEST_IMAGE
- docker tag $CONTAINER_TEST_IMAGE $CONTAINER_RELEASE_IMAGE
- docker push $CONTAINER_RELEASE_IMAGE
only:
- master
deploy:
stage: deploy
script:
- ./deploy.sh
only:
- master
Подводя итоги
GitLab Container Registry — последнее на данный момент дополнение к встроенному набору инструментов для цикла разработки ПО GitLab. Это дополнение доступно начиная с версии GitLab 8.8. С использованием этой функциональности проводить тестирование и развертывание образов Docker стало гораздо проще. GitLab Container Registry идет в комплекте с GitLab CE и GitLab EE без какой-либо доплаты и устанавливается поверх той же инфраструктуры, что настроена у вас для GitLab.
Container Registry доступен на GitLab.com, он абсолютно бесплатен, и вы можете начать пользоваться им прямо сейчас!
Важно: Для того, чтобы использовать Docker в образах Docker необходимо установить флаг privileged в настройках Runner’а.Пока что это невозможно сделать в общих Runner’ах на GitLab.com. Мы планируем добавить этот флаг в ближайшее время.Все уже ок.
P.S. Будет здорово, если поделитесь опытом использования в комментариях.
Комментарии (21)
svladimiri
03.09.2016 07:18А где бы ссылку на оригинал найти?
nem
03.09.2016 07:19Под постом же она есть.
Ну или вот: https://about.gitlab.com/2016/05/23/gitlab-container-registry/
ColdPhoenix
Немного не по теме, но о самом GitLab.
сколько у него требования по памяти?
одно время хотел опробовать CI, поставил Jenkins, потребление памяти под 700 с учетом что оно пустое, сразу заставило меня его удалить.
а как дело тут?
PS: все это для себя и своих проектов.
nem
Для ГитЛаба нужно минимум 2 гигабайта оперативки. Если экономите память, можно поставить легковесный gogs.io
Ну или просто на GitLab.com зарегистрироваться и пользоваться там, если все таки нужен именно GitLab.
SirEdvin
Если не ошибаюсь, в gogs нет и не будет CI (https://github.com/gogits/gogs/issues/1232).
ColdPhoenix
да просто не хотелось бы чтоб память тратилась в пустую ни на что.
сам gitLab радует по возможностям(сырой git то настроен итак).
регистрация не подходит, скажем так, свои принципы:)
(иначе бы на bitbucket так и остался)
в общем, попробую проще.
Taller
возможно вас утешит: free memory — wasted memory
ColdPhoenix
по сути да, но я не хочу оказаться в ситуации, что просто не смогу войти на сервис.
в общем поставил, в idle все устраивает, буду настраивать.
Prototik
Если честно, то я свой локальный gitlab засунул в слайс с одним гигабайтом памяти. Засунул всё — sidekiq, unicorn, backup, mailroom, workhorse. Работает, причём шустро. Воркеры CI, конечно, отдельно.
Prototik
Вот скриншотик для интересующихся. Недавно добавил памяти до 2х гигабайтов, но как видно — за неделю аптайма gitlab всё ещё не вылез даже за гигабайт. Включены все фичи, кроме упомянтого docker container registry.
Ipeacocks
Ну вы же понимаете, что чудес не бывает — запустите какой-то крутой diff и оперативка уйдет как сон.
Prototik
Ну я и не говорю, что гигабайта хватит вообще при любом раскладе. Я лишь говорю, что мелкий gitlab инстанс без особо больших проектов вполне может уместится и на гигабайте.
SirEdvin
А вот рабочий и нагруженный Jenkins ест 900-1000.
Вы недовольны тем, что сложные приложения потребляют память?
ColdPhoenix
я недоволен тем что оно потребляет просто потому что оно есть.
SirEdvin
Как-то получилось так, что абсолютное большинство сложных приложений так делают. И jenkins в большом списке таких приложений где-то в конце.
А 700 мб для CI системы не так много. Скорее всего, если для вас 700 МБ памяти много, возможно, вам и не нужно CI.
ColdPhoenix
поискал на сервере такие приложения, поискал на своей машине(запущенная студия с WPF проектом, хром с 10 вкладками, игрушка(Sots2), не смог в принципе найти приложение чтоб заняло более 600 метров(причем в работе, не на пустом месте)
может, конечно, все просто и мое мировозрение не совпадает с оным у Jenkins, но для меня это много.
larrabee
Хром с 15 вкладками жрет 4.2 Гб, из них 600 Мб- вкладка gmail. Следующй по списку Atom с 300 Мб при 2х открытых файлах на пару кб каждый. Все любят память.
grossws
Для нормальной ide (idea, vs), например, стоит иметь 8+ GiB на хосте, если проекты приличного размера или необходимо иметь отрытыми несколько инстансов ide.
На серверах — очень зависит от задач. Некоторые вещи вполне могут требовать 16-64 GiB RAM на процесс. Иногда и поболее.
SirEdvin
Насчет студии у меня крупные сомнения, что вы не ошиблись. К сожалению, долго ей не пользовался, но столько весить открытый проект в памяти не может. Возможно, у вас урезанная версия?
Насчет хрома — у него вкладка в памяти минимум 50 мб отжирает (это если вкладка полностью статическая), а еще есть отдельные процессы, которые он запускает для своих нужд.Тут по минималкам больше 600 получается. А в реальности и того больше.
Тут еще накладывается то, что Jenkins работает на JVM. Она при запуске выделяет себе столько памяти (можно ограничить), но использует не всю сразу.
ColdPhoenix
Может играет роль то что у меня нет решарпера на студии?
сама студия 2015 Community Update 3.
для хрома я сложил все его процессы.
Ipeacocks
так Линукс тоже так делает.