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.

    • +32
    • 15,4k
    • 5

    Badoo

    305,00

    Big Dating

    Поделиться публикацией

    Похожие публикации

    Комментарии 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-ку инстансов и мне все равно где...» нам не подходит.

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

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