Как жить с Docker, или почему лучше с ним, чем без него?



    Эта статья предназначена для тех, кто уже знает про Docker, знает для чего он. А вот что делать с этим дальше не знает. Статья носит рекомендательный характер и не посягает на звание «лучшая практика».

    Итак, возможно вы прошли docker tutorial, докер кажется простым и полезным, но вы пока не знаете, как он может вам помочь с вашими проектами.

    Обычно с деплоем возникает три проблемы:
    1. Как мне доставить код на сервера?
    2. Как мне запустить код на серверах?
    3. Как мне обеспечить одинаковость окружения, в котором запускается и работает мой код?


    Как с этим поможет Docker под катом. Итак начнем не с docker, а с того, как мы жили без него.

    Как мне доставить код на сервера?


    Первое, что приходит на ум, это собрать все в пакет. RPM или DEB не играет роли.

    Пакеты


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

    • Доставить файлы проекта на сервер, из некоторого хранилища
    • Удовлетворить зависимости (библиотеки, интерпретатор и т.д.)
    • Удалить файлы предыдущей версии и доставить файлы текущей.

    На практике это работает, пока… Представим себе ситуацию. Вы DevOps на постоянной основе. Т.е. вы целыми днями занимаетесь автоматизацией рутинной деятельности, которой занимались админы. У вас есть небольшой парк машинок, на котором вы не разводите зоопарк из дистрибутивов. Например, вы любите Centos. И она всюду. Но тут к вам приходит задачка: вам нужно для одного из проектов заменить libyy (который найти под Centos само по себе квест) на libxx. Почему заменять — вам не ведомо. Скорее всего «как обычно криворукий» разработчик написал только для libxx, и вместе с libyy оно не работает. Ну что, берем в руки vim и пишем rpmspecи для libxx, параллельно для новых версий библиотек, которые нужны для сборки. И примерно 2-3 дня упражнений, и вот один из результатов:

    1. libxx собрался, все хорошо, задача выполнена
    2. libxx не собрался, не т.к., скажем, в системе установлен libyy, который придется удалить, а от него зависит что-то еще на сервере
    3. libxx не собрался, не хватает библиотеки, которая конфиликтует с какой-то еще библиотекой


    Итого вероятность справиться с задачей примерно 30% (хотя на практике всегда выпадают варианты 2 или 3). И если со второй ситуацией еще можно как-то справиться (виртуалка там или lxc), то третья ситуация или добавит в ваш зверинец еще одного зверя, или собираем ручками в /usr/local привет нулевые/слакваяря и т.д.

    В целом, эта ситуация называется dependency hell. Вариантов решения этому масса, от простых chroot до сложных проектов, типа NixOs.


    К чему это я. Ах, ну да. Как только вы начинаете собирать все в пакеты и гонять их на одной и той же системе, у вас ситуация dependency hell обязательно будет. Решить ее можно по-разному. Или под каждый проект городить новый репозиторий плюс новую виртуалку/hardware, или ввести ограничения. Под ограничениями я имею ввиду некий набор политик компании, вроде: «У нас тут только libyy-vN.N. Кому не нравится, в отдел кадров с заявлением.». Про N.N я тоже не просто так сказал, некоторые библиотеки не могут жить на одном сервере в двух версиях. Ограничения ничего не дают в конечном итоге. Бизнес, да и здравый смысл, быстро разрушат их все.

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

    Деплой через GIT


    Неплохо подходит для интерпретируемых языков. Не годится для чего-то, что нужно скомпилировать. И также не избавляют от dependency-hell.

    Как мне запустить код на серверах?


    На этот вопрос придумано много всего: daemontools, runit, supervisor. Считаем, что этот вопрос имеет как минимум один верный ответ.

    Как мне обеспечить одинаковость окружения, в котором запускается и работает мой код?


    Представим себе банальную ситуацию, вы все тот же DevOps, к вам приходит задача, нужно развернуть проект «Eniac» (имя взято из генератора имен для проектов) на N серверах, где N больше 20.

    Вы тащите Eniac из GIT, он на известной вам технологии (Django/RoR/Go/1C), собираете его привычным методом, запускаете и… не работает. Связываетесь с разработчиком, ругаете его по первое число, что он как обычно «криворук». А он вам все обратно, и «криворук» уже вы. У разработчика все работает. С точки зрения вашего начальника, вы не можете запустить проект. Именно вы. Так как тестировщики, проект, развернутый на компьютере разработчика, все приняли.

    Понимаете проблему. Идем дальше, вам удается запустить Eniac на одном сервере, и не получается еще на N-1.

    Как же Docker поможет мне?



    Ну, во-первых давайте разберемся, как Docker использовать как средство доставки проектов на «железо».

    Приватный Docker Registry

    Что такое Docker Registry? Это то, что хранит ваши данные, подобно WEB серверу, который раздает deb-пакеты и файлы с метаданными для них. Docker Hub вы можете установить на виртуалке в Amazon и хранить данные в Amazon S3, или же поставить на свою инфраструктуру и хранить данные в Ceph или на ФС.

    Сам docker registry тоже можно запустить dockerом. Это всего лишь приложение на python (видимо, на go не осилили написать библиотеки к хранилищам, коих большое количество поддерживает registry).

    А как в это хранилище попадет наш проект, разберем позже.

    Как мне запустить код на серверах?


    Сейчас сравним, как мы доставляем проект обычным менеджером пакетов. Например apt:

    apt-get update && apt-get install -y myuperproject

    Эта команда годится для автоматизации. Она сама все тихо сделает, останется перезапустить наше приложение.

    Теперь пример для Docker:

    docker run -d 192.168.1.1:80/reponame/mysuperproject:1.0.5rc1 superproject-run.sh

    И все. Docker скачает с вашего docker registry, расположенного по адресу 192.168.1.1 и слушающим порт 80 (у меня тут nginx), все что нужно для запуска, и запустит superproject-run.sh внутри образа.

    Что случится, если в образе 2 программы, которые мы запускаем, и, скажем, в следующем релизе одна из них поломалась, однако другая напротив, набрала фич, которые нужно выкатить. Нет проблем:

    
    docker run -d 192.168.1.1:80/reponame/mysuperproject:1.0.10 superproject-run.sh
    docker run -d 192.168.1.1:80/reponame/mysuperproject:1.0.5rc1 broken-program.sh
    

    И теперь у нас уже 2 разных контейнера, и внутри их может быть совершенно разные версии системных библиотек файлов и т.д.

    Как мне обеспечить одинаковость окружения в котором запускается и работает мой код?


    В случае со стандартными виртуальными машинами или вообще реальными системами придется следить за всем самому. Ну или изучать Chef/Ansible/Puppet или что-то еще из подобных решений. Иначе никак не гарантировать что xxx-utils одинаковой версии на всех N серверах.

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

    Сборка контейнеров


    Для того, чтобы ваш код попал в docker registry (ваш или глобальный не имеет значения), вам придется его туда запушить.

    Можно заставить разработчика собирать контейнер самостоятельно:

    • Разработчик пишет Dockerfile
    • Делает docker tag $imageId 192.168.1.1:80/reponame/mysuperproject:1.0.5rc1
    • И пушит docker push 192.168.1.1:80/reponame/mysuperproject:1.0.5rc1


    Или же собирать автоматически. Я не нашел ничего, что собирает контейнеры, поэтому вот, есть мною собранный велосипед под названием lumper

    Суть в следующем:
    • Устанавливаем на сервер 3 компонента lumper и RabbitMQ
    • Слушаем порт для github hooks.
    • Настраиваем в github web-hook на нашу инсталляцию lumper
    • Разработчик делает git tag v0.0.1 && git push --tags
    • Получает email с результатами сборки


    Dockerfile


    На самом деле нет ничего сложного. Например соберем lumper с помошью Dockerfile.

    
    FROM                ubuntu:14.04
    MAINTAINER          Dmitry Orlov <me@mosquito.su>
    
    RUN                 apt-get update && \
    					apt-get install -y python-pip python-dev git && \
    					apt-get clean
    
    ADD                 . /tmp/build/
    RUN                 pip install --upgrade --pre /tmp/build && rm -fr /tmp/build
    
    ENTRYPOINT          ["/usr/local/bin/lumper"]
    


    Здесь FROM говорит о том, на каком образе основывается образ. Далее RUN запускает команды подготавливая окружение. ADD помещает код в /tmp/build, далее ENTRYPOINT указывает точку входа в наш контейнер. Т.о при запуске написав docker run -it --rm mosquito/lumper --help увидим вывод --help entrypoint.

    Заключение


    Для того, чтобы запускать контейнеры на серверах есть несколько путей, можно или написать init-script или посмотреть на Fig который может разворачивать целые решения из ваших контейнеров.

    Также я намеренно обошел стороной темы пробросов портов, и ip маршрутизации контейнеров.

    Также, так как технология молодая, у docker огоромное community. И прекрасная документация. Спасибо за внимание.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 41

      +13
      Еххъ, куда не зайдешь посмотреть, все такие весёлые вещи про докер рассказывают…

      А самое интересное — распределение портов, развертывание частей приложения на нескольких серверах (multi-host networking & overlay networking), service discovery, оркестровка — почти не обсуждается.

      Сырой он пока, к сожалению. Из того, на что натыкался — случайные падения контейнеров при запуске, отваливание volume'ов при обновлении докера. Была ещё одна хорошая ядерная бага с неудачным уничтожением netns при остановке контейнера, приводящая к kernel panic, но это дистроспецифичное.
        0
        Не могу сказать, что пост очень полезный, в нем явно побывал КО. Но то «самое интересное», о чем вы написали (сети, orchestration, discovery) — достаточно специфичные вопросы, не имеющие прямого отношения к докеру. Для каждой из этих проблем есть свои готовые и очень работоспособные решения. Нужны сети — можно смотреть weave или flannel. Нужен discovery — берете etcd, zookeeper и всякие прочие consul'ы. Orchestration — вообще отдельная тема, и контейнеры тут, по-сути, не вносят ничего нового — в крайнем случае, никто не мешает раскатывать контейнеры тем же ansible или puppet/mcollective. Все эти вопросы каждый решает по-разному, и скорее всего, исходит из уже имеющейся инфраструктуры.

        А что за бага с уничтожением netns? Мы в контексте докера долго бились с багами в OOMKiller'е. Его приход с ненулевой вероятностью мог завесить хост намертво. А вот про уничтожение netns как-то не слышали пока ничего.
          +7
          Про KO вы правы, но KO побывал до того и у вас, и теперь вам это очевидно. Статья для тех, у кого КО не частый гость. Да и если заходит, про Docker не беседует.
            0
            А я ж не против. Я отнюдь не критикую ваш пост, и более того, считаю его достаточно полезным в плане расстановки акцентов. Докер сейчас каждый интерпретирует как угодно и пытается им заткнуть любые свои проблемы. Вы вполне конкретно делаете упор на то, что докер — средство доставки релизов на сервер. Капитанское утверждение? Я думаю, что да. Но тем не менее, люди пытающиеся использовать докер, почему-то часто игнорируют это самое основное предназначение докера. И я уверен, что с этой точки зрения Ваш пост окажется этим людям полезен.
            Я (неявно) подразумевал лишь то, что про докер, как про новую, сырую технологию, лучше писать не в духе «как Вам нужно сделать», а «как мы сами сделали, что у нас было изначально, и почему в итоге у нас получилось так, как есть» =)
              0
              Статья носит рекомендательный характер и не посягает на звание «лучшая практика».

              Простите, но я еще до ката сказал об этом.

              Но тем не менее, люди пытающиеся использовать докер, почему-то часто игнорируют это самое основное предназначение докера

              И спасибо за ваше видение положения дел :-).
            0
            А что за бага с уничтожением netns? Мы в контексте докера долго бились с багами в OOMKiller'е. Его приход с ненулевой вероятностью мог завесить хост намертво. А вот про уничтожение netns как-то не слышали пока ничего.


            bugzilla.kernel.org/show_bug.cgi?id=65191
            bugs.centos.org/view.php?id=8039
            bug info
            0008039: kernel crash in netns cleanup_net (nf_nat_cleanup_conntrack)

            Kernel crashes after several days (about 3-4 days in my case). I have some short-lived docker containers (created and destroyed every 15 mins), so it's netns is destroyed every 15 mins.

            [289778.843818] Call Trace:
            [289778.843865] [] __nf_ct_ext_destroy+0x44/0x60 [nf_conntrack]
            [289778.843923] [] nf_conntrack_free+0x25/0x60 [nf_conntrack]
            [289778.843976] [] destroy_conntrack+0xbd/0x110 [nf_conntrack]
            [289778.844031] []? nf_conntrack_helper_fini+0x30/0x30 [nf_conntrack]
            [289778.844102] [] nf_conntrack_destroy+0x17/0x20
            [289778.844168] [] nf_ct_iterate_cleanup+0xcb/0x160 [nf_conntrack]
            [289778.844237] [] nf_ct_l3proto_pernet_unregister+0x1d/0x20 [nf_conntrack]
            [289778.844308] [] ipv4_net_exit+0x19/0x50 [nf_conntrack_ipv4]
            [289778.844368] [] ops_exit_list.isra.1+0x39/0x60
            [289778.844423] [] cleanup_net+0x110/0x260
            [289778.844480] [] process_one_work+0x17b/0x460
            [289778.844524] [] worker_thread+0x11b/0x400
            [289778.844574] []? rescuer_thread+0x400/0x400
            [289778.844624] [] kthread+0xcf/0xe0
            [289778.844669] []? kthread_create_on_node+0x140/0x140
            [289778.844730] [] ret_from_fork+0x7c/0xb0
            [289778.844773] []? kthread_create_on_node+0x140/0x140
            +3
            Ну про оркестровку я пожалуй, в понедельник пост попробую выкатить, когда n+ сервер и надо этим всем управлять, у меня немного наработок на эту тему есть
            0
            Приватный docker registry, скажу я вам, штука оч. сырая. Как его, например почистить? Удалить ненужные образы. А хрена с два!!! Текущая версия 0.9, а удаление обещают только в 2.0…
              +2
              С удалением там вопрос топологической сортировки. Обещать не буду, но сделаю им pull request наверное.
                +3
                Было бы неплохо, дружище. А то сейчас периодически приходится в продакшин-кластере очищасть s3-бакет полностью.
                0
                В Artifactory есть поддержка Docker repository. Там ипо идее все это уже можно. К сожалению лично не проверял
                +1
                У меня вот такой чайниковый вопрос. Я с докером пока не работал, вполне допускаю, что вопрос имеет простой ответ, но сходу я как-то его не нашёл.

                Предположим, у есть 100500 сервисов, каждый в своём контейнере, всё работает. Внезапно в openssl находят критический баг, нужно его срочно обновить. Openssl используется, скажем, в 100400 из 100500 контейнеров. Как правильно произвести обновление?
                  0
                  Самый очевидный ответ, это перебилдить образы из которых развернуты контейнеры. И перенакатить контейнеры. В реальной жизни 100400 контейнеров в которых уязвимость можно эксплуатировать не бывает. Придется скорее всего обновить пару тройку образов, и просто запутить их. Ну это все задачаспецифично.
                    0
                    Спасибо!
                      +1
                      И как этот процесс выглядит в реальной жизни? В той, в которой интернет сломан, и обновлять образы из соображений безопасности нередко нужно практически ежедневно (во время shellshock у меня пакет с bash обновился, по-моему, 4 раза за одни сутки).

                      Сейчас у нас есть, предположим, 3-4 группы однотипно настроенных серверов. И внутри каждой группы гетерогенность среды поддерживается не ради ленивого DevOps, а потому, что абсолютно нереально уследить за настройками, безопасностью и стабильностью обновлений нескольких десятков серверов если все они разные. И здесь не имеет абсолютно никакого значения, физические это сервера, или виртуальные — если в каждом, фактически, полноценная ОС с полным окружением и при этом она настроена под специфические нужды одного работающего в ней приложения, то с точки зрения обновления ОС мы имеем необходимость регулярно обновлять столько разных ОС, сколько у нас используется разных приложений и разных версий одного приложения.
                      0
                      Создать новые образы, запустить инстансы с новых образов, завернуть на них траффик, стопнуть инстансы каждого старого образа, дропнуть старые образы,
                      0
                      Или же собирать автоматически. Я не нашел ничего, что собирает контейнеры, поэтому вот, есть мною собранный велосипед под названием lumper


                      packer.io/docs/builders/docker.html
                        –1
                        Вы его пробывали? Как ваши ощущения? Как работа с Docker Registry? Если быть честным, я не нашел ничего что собирает контейнеры как мне нужно. Потому и еще один велосипед на гитхабе. И я честное слово, никому его не навязываю. Наоборот — вскользь упоминаю.
                          0
                          Я оставил ссылку с целью обратить Ваше внимание и внимание читателей на этот проект, а не высмеивать Ваш велосипед. Я по началу так же сел писать скрипт, но потом нашел вот этот проект.

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

                          Исходя из статьи, Вам нужно немногим более, чем tag и push. Это все отлично делается через пост-процессоры. Логин и тп настройки поддерживаются, так что с приватным хабом проблем не будет.

                          Имейлы не шлет, это да :-)
                        0
                        «Вы DevOps на постоянной основе.… Почему заменять — вам не ведомо. Скорее всего «как обычно криворукий» разработчик написал только для libxx, и вместе с libyy оно не работает.

                        Представим себе банальную ситуацию, вы все тот же DevOps,… собираете его привычным методом, запускаете и… не работает. Связываетесь с разработчиком, ругаете его по первое число, что он как обычно «криворук». А он вам все обратно, и «криворук» уже вы. У разработчика все работает. С точки зрения вашего начальника, вы не можете запустить проект. Именно вы. Так как тестировщики, проект, развернутый на компьютере разработчика, все приняли.»


                        Хм, не пробовали DevOps?

                        en.wikipedia.org/wiki/DevOps
                        > DevOps is a software development method that stresses communication, collaboration, integration, automation and measurement cooperation between software developers and other information-technology (IT) professionals.
                          0
                          Хм, не пробовали DevOps?

                          Пробовали, именно поэтому так и написал. Когда в вашей компании уже есть админы, их сложно переквалифицировать в программистов, которые работают по методу DevOps. Да и NOC все равно не будет программировать, а любой компании где есть железо просто необходим NOC. Отсюда и получаются «DevOps на постоянной основе». Хотите, давайте назовем их программисты инфрастуктуры?

                          automation and measurement cooperation between software developers and other information-technology (IT) professionals
                          Почему этим не может заниматься отдельный человек?
                            0
                            Почему этим не может заниматься отдельный человек?

                            Судя по википедии девопс это взаимодействие, интеграция, и кооперация. Для всех этих вещей нужно как минимум 2 субъекта. Поэтому этим не может заниматься отдельный человек.

                            Программировать инфраструктуру один человек конечно может.
                              0
                              Вы походу не поняли в чем смысл этой концепции. Она не про то, что админы должны программировать, она про то, что админы и программисты — часть одной комманды, а не двух, которые вечно футболят друг друга с резолюшном «проблема не на моей стороне».
                                +1
                                Как в эту концепцию укладываются ребята, делающие IPSecи и Cisco IOSы для инфраструктуры? Концепцию я прекрасно понимаю, и стараюсь всем разработчикам вокруг себя задавать вопросы на митингах вроде:

                                А как это должно взлетать? А сколько компонентов требуется для тестирования? А как это масштабировать горизонтально? А как ты думаешь, что в твоем решении бутылочное горлышко? А что мы будем резервировать, и как твой модуль будут работать с этим «резервированием»?

                                Просто DevOps из википедии, как методика, работает только в стартапах. В компаниях чаще всего нет ресурсов чтобы каждой команде нанаять девопса. Обычно есть штат девопсов и их вводят в команду разработчиков так: «Ребята, это Вася. Он наш девопс и будет заниматься CI и деплоем. А еще он будет вместе с вами писать для этого код.»

                                Опять-же чисто личный опыт. Вы просто представьте, вот есть у вас junior. Он пишет вам JS. Расскажете ему как ваши бекенды раздают его js? Или расскажите как настраивать nginxы? Конечно нет, вы скажете Васе: «Вася, поможешь автоматизировать деплой статики для нашего junior фронтендера?»

                                И в конечном итоге, DevOps не работает.
                                  0
                                  И в конечном итоге, DevOps не работает.
                                  Просто он из методологии для программистов и админов, которая может сработать в некоторых компаниях, вырождается в отдельную профессию, которая сработает везде.
                                    0
                                    У нас в стартапе был админ, к которому пришли и сказали: теперь ты девопс. И, вы знаете, он очень быстро стал разбираться в тонкостях разработки и при этом понимал администрирование. Админ, естественно, тоже появился, но другой человек.
                                    И вы ещё забываете про отдел тестирования, с ним тоже нужно уметь взаимодействовать.

                                    По вашим сообщениям я понимаю, что у вас просто неправильно их, DevOps'ов готовили. Либо же люди не смогли переключиться с разработки/администрирования/тестирования/DBA/NOC на менеджмент. Я лично знаю нескольких бывших руководителей, которые добровольно ушли в обычных программистов, т.к. осознали, что не могут заниматься менеджментом.

                                    DevOps — это маленький технический директор, если корректно проводить параллели.
                              0
                              Насчет dependency hell — всё решаемо, вот только затратно по времени. Можно пакет обозвать как libxxx2 вместо libxxx-2, положить саму библиотеку в /usr/lib64/libxxx.so.2 вместо /usr/lib64/libxxx.so. Да, придется программистам сказать, чтобы при сборке приложения явно указывали версию.

                              Вопрос любителям Docker'а, а многие ли используют Docker + rpm/deb? Если собирать приложение/библиотеку непосредсвтенно в контейнере из исходников, то получаем большой оверхед по *-dev зависимостям, кои нам не очень то и нужны при работе в production. Пакетировние же помогает этих зависимостей избежать.
                                0
                                Я использую Docker + пакеты. Делаю два отдельных образа: сборочный со всеми зависимостями для сборки (в том числе RPM/deb) и образ для запуска приложения (только runtime зависимости). Второй, конечно же, будет заметно меньше первого.
                                  +1
                                  Насчет dependency hell — всё решаемо, вот только затратно по времени.
                                  Вы же знаете, что это самый дорогой и невосполнимый ресурс?
                                  +1
                                  Я использую Docker для сборки проектов (не самая очевидная, но очень удобная идея: скачав из локальной корп. сети заранее подготовленный сборочный образ можно собрать проект на любой машине с Docker), быстрого разворачивания демо-стендов и интеграционного тестирования.
                                    0
                                    Интересно, как сама эволюция библиотечного подхода сейчас «расщепляется» на два варианта. Изначально была простая идея, что реюзать библиотеку — это круто. Сохраняет место. Упрощает админинье (пофиксил openssl — и у тебя все что с openssl — сразу «само» пофиксилось).

                                    А Докер, virtualenv и прочие — в обратную сторону идут. И тоже вроде логично и обоснованно, ибо самая свежая либа не всегда так уж однозначно лучше предыдущей.
                                      +1
                                      С сетью конечно там пока печально
                                        0
                                        А зачем вам там сеть, если не секрет? Мне кажется, что то, что там есть сейчас полностью покрывает все кейсы его применения.
                                          0
                                          Как я помню он настройки днс не сохраняет, да и хостнейм, это так на вскидку. В общем если проще ту нужно велосипеды прикручивать чтоб всё гладко работало, я не говорю что это плохо, не поймите меня не правильно, просто пока ещё не доросли до конкурентоспособного решения, я конечно буду на него посматривать регулярно, но пока увы на уровне эксперимента.
                                            0
                                            Хостнейм не должен пробрасываться, поскольку докер явно изолирует сеть для контейнера. Если очень нужен хостнейм сервера, его несложно пробросить внутрь приложения, например, флагом.
                                            С DNS сложнее, в нашем случае пришлось явно в маунтах пробрасывать для контейнера сокет nscd.

                                            Крупный продакшн, всё работает.
                                        +1
                                        поскольку Docker registry это, мягко говоря, кусок не очень хорошего приложения, рекомендую посмотреть на Artifactory, настоящий бинарный репозиторий с полной поддержкой Docker. (дисклеймер — я оттуда).
                                          0
                                          Класс. Было бы круто, если бы вы или сами написали, как это развернуть у себя на сервере (с поддержкой докера разумеется). Или дали годный tutorial. С огромным удовольствием добавил бы это в саму статью.
                                            +3
                                            В принципе Артифактори ставится простым unzip-ом.
                                            Но, конечно, с Докером всё непросто. Из-за достаточно странного решения, что хост: порт откуда скачивать и куда заливать являются частью тэга, поддержка нескольких репозиториев в одном менеджере становится сложной.
                                            Артифактори по дефолту устанавливается под host:port/artifactory/название-репозитория, a в докере можно только host:port.
                                            Решается это с помощью апача/нжникса с virtual host, это всё достаточно подробно прописано, но всё равно не фан ни разу.

                                            Хорошие новости состоят в том, что на следующей неделе можно будет просто установить Docker image Артифактори, полностью сконфигурированным под Докер (ждем поддержку Докера в Бинтрее, чтобы скачивать оттуда).

                                            Я скину линк, когда будет.
                                              0
                                              Артифактори по дефолту устанавливается под host:port/artifactory/название-репозитория, a в докере можно только host:port.
                                              Странно докеровцы как раз говорят что host:port/repo/project. Зачем host:port/artifactory/ ???
                                                0
                                                Эти repo/project будут уже в рамках docker registry (также можно использовать просто project, если вы держите свой репозиторий).

                                                Т. е. докер считает, что репозиторий доступен от корня (host:port), а artifactory разносит разные репозитории (например, докер и мавен) по разным путям.

                                                Пусть докер-репозиторий доступен на artifactory-host:port/docker/. Если выполнить docker pull artifactory-host:port/docker/some-project, то докер побежит дергать artifactory-host:port/v1/_ping, что не даст ему ожидаемого ответа, после чего решит, что это не репозиторий. Вообще, федерализация и доступ к репозиториям — одна из важных причин возникновения appc/rocket.
                                          –1
                                          Получается что artefactiory не совсем поддердивает докер.

                                          Only users with full accounts can post comments. Log in, please.