GitLab Container Registry

https://about.gitlab.com/2016/05/23/gitlab-container-registry/
  • Перевод

В мае этого года вышел релиз ГитЛаба 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. Будет здорово, если поделитесь опытом использования в комментариях.


Перевод с английского выполнен переводческой артелью «Надмозг и партнеры», http://nadmosq.ru. Над переводом работал sgnl_05.

Метки:
Softmart 65,37
Компания
Поделиться публикацией
Похожие публикации
Комментарии 21
  • 0
    Немного не по теме, но о самом GitLab.
    сколько у него требования по памяти?

    одно время хотел опробовать CI, поставил Jenkins, потребление памяти под 700 с учетом что оно пустое, сразу заставило меня его удалить.
    а как дело тут?

    PS: все это для себя и своих проектов.
    • 0

      Для ГитЛаба нужно минимум 2 гигабайта оперативки. Если экономите память, можно поставить легковесный gogs.io
      Ну или просто на GitLab.com зарегистрироваться и пользоваться там, если все таки нужен именно GitLab.

      • +2

        Если не ошибаюсь, в gogs нет и не будет CI (https://github.com/gogits/gogs/issues/1232).

        • 0
          да просто не хотелось бы чтоб память тратилась в пустую ни на что.
          сам gitLab радует по возможностям(сырой git то настроен итак).

          регистрация не подходит, скажем так, свои принципы:)
          (иначе бы на bitbucket так и остался)

          в общем, попробую проще.
          • +1
            возможно вас утешит: free memory — wasted memory
            • 0
              по сути да, но я не хочу оказаться в ситуации, что просто не смогу войти на сервис.

              в общем поставил, в idle все устраивает, буду настраивать.
              • 0
                Если честно, то я свой локальный gitlab засунул в слайс с одним гигабайтом памяти. Засунул всё — sidekiq, unicorn, backup, mailroom, workhorse. Работает, причём шустро. Воркеры CI, конечно, отдельно.
                • +1
                  Вот скриншотик для интересующихся. Недавно добавил памяти до 2х гигабайтов, но как видно — за неделю аптайма gitlab всё ещё не вылез даже за гигабайт. Включены все фичи, кроме упомянтого docker container registry.
                  • 0
                    Ну вы же понимаете, что чудес не бывает — запустите какой-то крутой diff и оперативка уйдет как сон.
                    • 0
                      Ну я и не говорю, что гигабайта хватит вообще при любом раскладе. Я лишь говорю, что мелкий gitlab инстанс без особо больших проектов вполне может уместится и на гигабайте.
        • +1

          А вот рабочий и нагруженный Jenkins ест 900-1000.


          Вы недовольны тем, что сложные приложения потребляют память?

          • 0
            я недоволен тем что оно потребляет просто потому что оно есть.
            • +2

              Как-то получилось так, что абсолютное большинство сложных приложений так делают. И jenkins в большом списке таких приложений где-то в конце.


              А 700 мб для CI системы не так много. Скорее всего, если для вас 700 МБ памяти много, возможно, вам и не нужно CI.

              • 0
                поискал на сервере такие приложения, поискал на своей машине(запущенная студия с WPF проектом, хром с 10 вкладками, игрушка(Sots2), не смог в принципе найти приложение чтоб заняло более 600 метров(причем в работе, не на пустом месте)

                может, конечно, все просто и мое мировозрение не совпадает с оным у Jenkins, но для меня это много.
                • 0
                  Хром с 15 вкладками жрет 4.2 Гб, из них 600 Мб- вкладка gmail. Следующй по списку Atom с 300 Мб при 2х открытых файлах на пару кб каждый. Все любят память.
                  • 0

                    Для нормальной ide (idea, vs), например, стоит иметь 8+ GiB на хосте, если проекты приличного размера или необходимо иметь отрытыми несколько инстансов ide.


                    На серверах — очень зависит от задач. Некоторые вещи вполне могут требовать 16-64 GiB RAM на процесс. Иногда и поболее.

                    • 0

                      Насчет студии у меня крупные сомнения, что вы не ошиблись. К сожалению, долго ей не пользовался, но столько весить открытый проект в памяти не может. Возможно, у вас урезанная версия?
                      Насчет хрома — у него вкладка в памяти минимум 50 мб отжирает (это если вкладка полностью статическая), а еще есть отдельные процессы, которые он запускает для своих нужд.Тут по минималкам больше 600 получается. А в реальности и того больше.


                      может, конечно, все просто и мое мировозрение не совпадает с оным у Jenkins, но для меня это много.

                      Тут еще накладывается то, что Jenkins работает на JVM. Она при запуске выделяет себе столько памяти (можно ограничить), но использует не всю сразу.

                      • 0
                        Может играет роль то что у меня нет решарпера на студии?
                        сама студия 2015 Community Update 3.

                        для хрома я сложил все его процессы.
                  • 0
                    так Линукс тоже так делает.
              • 0
                А где бы ссылку на оригинал найти?

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое