company_banner

Видео докладов с DevOps Meetup про Docker

    Недавно в офисе Badoo проходил DevOps Meetup про Docker и контейнерную виртуализацию. Делимся с вами видео докладов.

    1. «Docker в Badoo: от восторгов к внедрению».
    Антон banuchka Турецкий, Раудсепп Илья, Badoo.




    2. «Teaching Dockers to use CRanes»/«Оснастите свои доки кранами».
    Павел Емельянов, Parallels.




    3. «Sysadmin tasks (backups, logging, remote access, debugging, network analysis...) with Docker, aka „life without SSH“.
    Jérôme Petazzoni, Docker.

    Badoo
    Big Dating

    Similar posts

    Comments 5

      +2
      Звук как-то «интересно» записан. На отдельные микрофоны для видео звук писался? Гул стоит страшный конечно, когда спикер говорит в микрофон в руке еще.
      :(
        0
        confd?
          0
          1. А как у вас организовано ли CI контейнеров? Как собираются контейнеры для тестирования?
          2. У вас в контейнерах с php-кодом в качестве entrypoint'а/cmd выступает php-fpm?
          3. Как у вас организован service discovery? Или повсеместно используются etcd/confd?
          4. Как ваша система деплоя понимает, где и в каких количествах нужно разворачивать контейнеры определенного типа?
            0
            На второй вопрос ответ уже получил из видео.
              +1
              Добрый день,

              попробую ответить на ваши вопросы:

              1. У нас для сборки «тестовых»(а потом уже и не тестовых, после тестирования) образов на той машине, где происходит сборка осуществляется поддержка структуры каталогов для сборки через Puppet. Я понимаю, что это может быть не самое красивое решение, но нам для переходного этапа, когда часть сервисов в контейнере, а часть по прежнему на «голом железе» этот вариант кажется самым предпочтительным. Т.е. у нас получается так:
              Build_Directory/
              — service_name/
              — Dockerfile
              — file1
              — file2


              т.е. автоматически наполняем Dockerfile и всю необходимую структуру.
              Далее, когда в build системе происходит сборка бинаря/приложения, то оно на основании «шаблона» собирает образ. Тут есть 2 варианта: собралось/не собралось. Если собралось, то тегируем образ, пушим в registry, сообщаем команде тестирования о том, что есть новый образ и нужно начать его тестировать(образ оказывается на нужной для тестирования машины, в задаче на тестирования присутствуют все нужные параметры для запуска контейнера из образа).
              2. тут вы уже сами ответ нашли.
              3. У нас нет как такого глобального service discovery. У нас есть «карта сервисов», на основании которой мы регулируем то, на каком хосте и кто/что у нас должно работать.
              etcd/confd используется уже на отдельновзятом хосте, если мы точно знаем о том, что сервис может быть перезапущен с переключением нагрузки на второй/третий/… инстанс. Да, не все сервисы, к сожалению, умеют так делать. Многим нужен корректный shutdown перед тем, как запустить вторую копию и прочее. Именно поэтому реализация «плавного» перезапуска у нас сделана «поштучно».
              4. У нас есть «карта» сервисов, которая поддерживается инженером, на основании которой уже и происходит принятие решений о том кого где и сколько. Т.е. вариант «вот тебе вычислительные мощности — запусти мне где-нить 10-ку инстансов и мне все равно где...» нам не подходит.

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