В мае этого года вышел релиз ГитЛаба 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)


  1. ColdPhoenix
    02.09.2016 17:53

    Немного не по теме, но о самом GitLab.
    сколько у него требования по памяти?

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

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


    1. nem
      02.09.2016 17:56

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


      1. SirEdvin
        02.09.2016 18:10
        +2

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


      1. ColdPhoenix
        02.09.2016 18:11

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

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

        в общем, попробую проще.


        1. Taller
          02.09.2016 19:23
          +1

          возможно вас утешит: free memory — wasted memory


          1. ColdPhoenix
            02.09.2016 19:26

            по сути да, но я не хочу оказаться в ситуации, что просто не смогу войти на сервис.

            в общем поставил, в idle все устраивает, буду настраивать.


            1. Prototik
              03.09.2016 06:20

              Если честно, то я свой локальный gitlab засунул в слайс с одним гигабайтом памяти. Засунул всё — sidekiq, unicorn, backup, mailroom, workhorse. Работает, причём шустро. Воркеры CI, конечно, отдельно.


              1. Prototik
                03.09.2016 06:51
                +1

                Вот скриншотик для интересующихся. Недавно добавил памяти до 2х гигабайтов, но как видно — за неделю аптайма gitlab всё ещё не вылез даже за гигабайт. Включены все фичи, кроме упомянтого docker container registry.


                1. Ipeacocks
                  03.09.2016 11:39

                  Ну вы же понимаете, что чудес не бывает — запустите какой-то крутой diff и оперативка уйдет как сон.


                  1. Prototik
                    03.09.2016 14:56

                    Ну я и не говорю, что гигабайта хватит вообще при любом раскладе. Я лишь говорю, что мелкий gitlab инстанс без особо больших проектов вполне может уместится и на гигабайте.


    1. SirEdvin
      02.09.2016 18:08
      +1

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


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


      1. ColdPhoenix
        02.09.2016 18:12

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


        1. SirEdvin
          02.09.2016 18:41
          +2

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


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


          1. ColdPhoenix
            02.09.2016 18:49

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

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


            1. larrabee
              02.09.2016 19:10

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


            1. grossws
              02.09.2016 19:25

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


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


            1. SirEdvin
              02.09.2016 21:47

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


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

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


              1. ColdPhoenix
                02.09.2016 22:34

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

                для хрома я сложил все его процессы.


        1. Ipeacocks
          03.09.2016 11:39

          так Линукс тоже так делает.


  1. svladimiri
    03.09.2016 07:18

    А где бы ссылку на оригинал найти?


    1. nem
      03.09.2016 07:19

      Под постом же она есть.
      Ну или вот: https://about.gitlab.com/2016/05/23/gitlab-container-registry/