Docker, как показатель зрелости

Когда мы были детьми, мы многого не понимали, что на данный момент является абсолютно очевидным. "Почему я не могу есть одни конфеты? Почему бутерброды — не еда, я же это ем? Почему я не могу спать с хомяком? Зачем чистить зубы каждый день, да еще целых два раза?!" Действительно, зачем? Но будучи взрослыми, зрелыми людьми, мы не задаемся подобными вопросами.


Похожая ситуация происходит и в мире IT (возможно, это касается любой профессиональной деятельности). Многих вещей на начальных стадиях мы можем не понимать. "Зачем, да и вообще кому нужны всякие Symfony, если есть WordPress? Зачем тратить время на автоматическое тестирование, если и так все работает? Git? Linux? SOLID, DRY, DDD, TDD? Что за страшные слова?". Новичкам сложно понять, зачем нужно так много всего. Осознание приходит со временем и вскоре такие вещи становятся не только понятными, но и очевидными.


Хочу рассказать свою историю того, как я дорос до Docker и что этому поспособствовало.


Дисклеймер
Эта статья всего-лишь повествование, в котором могут быть как объективные, так и субъективные мысли. Если я в чем-то не прав или сильно заблуждаюсь, пожалуйста, скажите мне об этом. Я люблю здравую, адекватную критику и готов принять конструктивные замечания.

Docker достаточно простая вещь. Но вы когда-нибудь пытались объяснить простому смертному, что это такое? Я пытался. Не получилось. Я и сам долгое время не понимал, зачем нужна эта штука. Я слышал про него, пытался вникнуть, но каждый раз бросал. Видимо, было еще рано — не созрел. Но в определенный момент произошла "Эврика"! Это был достаточно долгий путь, о котором я хотел бы рассказать другим. Возможно, эта статья поможет Вам сократить свой путь и начать пользоваться этим замечательным инструментом как можно раньше.


Этап 1. FTP или что-то подобное


Когда я начал работать веб-разработчиком, я попал в одну очень маленькую контору. Опыта у меня было 0, мы разрабатывали простые сайты на собственной, как мы это называли, "CMS". Слово OpenSource для меня было незнакомым, все функции писались руками, архитектуры не было никакой. Дыры в безопасности были подобны черным дырам. Если сайты типа "Блог", "Самый простой интернет-магазин" или "Новостная лента" были еще как-то реализуемы, то вещи чуть сложнее вызывали дикую боль и страдания. Работали мы через FTP, из-за чего возникали серьезные проблемы, когда два человека работали над одним и тем же файлом. Если кто-то что-то сломал или случайно затер, это пропадало на веки вечные.


И тут к нам пришел заказчик, по совместительству мой хороший друг, с одним незаурядным на фоне всех других наших работ проектом. Мы приступили за работу, но вскоре контора закрылась и я стал напрямую работать с этим проектом один. Тогда у меня и появилась возможность сделать все по-человечески...


Этап 2. LAMP


На втором этапе было принято несколько решений, порядок которых я уже и не помню. Скорее всего они происходили одновременно.


Во-первых, весь код я стал хранить в приватном Git репозитории на Bitbucket. Это, пожалуй, первое, чему стоит научиться любому разработчику. Это повысило защищенность кода от стороннего вмешательства. VPS мог сломаться, его могли взломать, просто не успели заплатить. Думаю, мысль ясна. Помимо этого, я закрыл FTP и деплой происходил по Git Push Webhook из ветки release или test.


Во-вторых, вместо одного сайта, было запущено два почти одинаковых. Первый — релиз, который обслуживал реальных клиентов. Второй — тестовый, который был запаролен, имел все самые последние нестабильные фичи. Последний нужен для того, чтобы не выкатывать в продакшн то, что не проверено и может работать не правильно. Хоть и работали эти два сайта на одном хосте, но были независимы.


В-третьих, что самое главное, разработка стала вестись локально. На ноутбук устанавливался стек LAMP, все это дело настраивалось, проект запускался локально на поддомене .dev (UPD Этот домен как оказалось занят и использовать его не стоит. Спасибо alexkbs, за комментарий). Это значительно ускорило разработку, позволило работать offline, пропала боязнь что-то сломать и жить стало чуточку проще.


Но вдруг я накосячил и пришлось переустановить Ubuntu. Заново приходится устанавливать и настраивать весь этот стек… Это дело можно было автоматизировать bash скриптом, но будет жесткая привязка к системе. Пусть я работаю один, но у начальства есть планы нанять второго, поэтому хотелось бы упростить жизнь и ему, и себе. После нескольких таких косяков я все таки нашел решение.


Этап 3. Vagrant


Vagrant — проще говоря, это инструмент, который дает Вам возможность настраивать VirtualBox скриптом. То есть, если написать правильный конфиг, то одной командой vagrant up можно загрузить готовый образ Debian, установить туда необходимый софт, настроить и получить готовое тестовое окружение.


Ну не чудо ли? На самом деле чудо! Это заметно упростило процесс разворачивания среды разработки, очистило основную систему от ненужных пакетов, и, благодаря виртуализации, я смог настроить машину как можно ближе к настройкам хостинга.


Виртуализация здорово подходит для разработки. Но в продакшн оно не годится. Это лютый овехед для системы. К тому же этот метод не решает несколько проблем:


  • Окружение хостинга и виртуальной машины похоже, но не одинаково. Поэтому все еще всплывали баги жанра "У меня все работает"
  • Окружение хоста и виртуалки нужно было поддерживать в актуальном состоянии. Если что-то менялось на сервере, нужно было менять и в виртуалке
  • Смена хостинга или переустановка системы в VPS еще та боль. Хостинг все еще приходилось настраивать вручную.
  • Обновлять некоторые пакеты не так-то просто. Попробуйте обновить PHP с версии 5.6 на 7.x. Это возможно. Но вероятность напортачить с зависимостями или сломать apache2 все же присутствует. Особенно, если Вы не сисадмин, а просто веб-разработчик, который любит и немного знает линукс.
  • Попробуйте запустить на одном хостинге два проекта с разными версиями MySQL и PHP. Почему-то я сомневаюсь, что это вообще возможно. Это может быть полезно, если нужно протестировать, как работает сайт на новой версии PHP, при этом продакшн оставить на старой версии. Вероятность что-то сломать при подобной настройке очень велика.

Да и лишними несколько гигабайт оперативки никогда не бывает.


Этап 4. Docker!


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


Что такое Docker? В интернете очень много сравнений с контейнерами, которые используются для транспортировки товара. Это верно.


Но представьте себе большой зал и много людей, которые над чем-то работают. Не обязательно, что они делают одно и то же. Бухгалтера, юристы, плотники, маляры, аналитики, программисты. Да, они иногда взаимодействуют. Но из-за того, что у них нет личного рабочего пространства, такая работа больше похожа на хаос. Беда с документами, кто-то у кого-то ручку стащил, кто-то сел на чужой стул, притронулся к не своему компу и п.р. Но если поставить перегородки, каждому человеку или группе людей выделить личное рабочее место, то и жить становится проще. Каждый занимается своим делом, пользуется своими ресурсами, никому не мешает. Взаимодействие происходит через выделенные каналы — почту, архивы или двери.


Также и Docker. Большой зал — это Ваша система (в действительности, всё немного сложнее, но для общего понимания концепций можно и упростить). Docker может создать изолированное пространство для процесса или группу процессов, делающих свою работу. Взаимодействие происходит путем открытых портов, общих файлов, внутренних и внешних сетей. Никто никому не мешает. Таким образом, Вы можете на одном хосте иметь хоть 20 версий PHP или еще чего-нибудь. А благодаря образам (images) Вы можете, образно говоря, заказать готовый офис со всеми плюшками.


Подключение к проекту новых компонентов стало вопросом нескольких строк благодаря docker-compose. Вот несколько примеров:


  #Подключение PHPMyAdmin
  pma:
    image: phpmyadmin/phpmyadmin:4.7
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: ${DB_PASSWORD}
    depends_on:
      - db
    ports:
      - "181:80"

  #Подключение MySQL
  db:
    image: mysql:5.7.20
    restart: always
    environment:
      MYSQL_DATABASE: ${DB_NAME}
      MYSQL_ROOT_PASSWORD: ${DB_PASSWORD}
    volumes:
      - db-data:/var/lib/mysql

Нужно обновить версию MySQL? Сколько времени и усилий пришлось бы приложить, чтобы сделать это на обычном VPS хостинге? Тут это вопрос 3-4 символов.


Благодаря тому, что Docker работает внутри рабочей системы, а не создает новую, он не сильно нагружает машину для разработки и вполне пригоден для прода. И это большой плюс, потому что код, запущенный на машине разработчика с Ubuntu, будет работать ровно также, как и на сервере с Debian


Еще одна польза от такого решения — автоматическое тестирование стало значительно проще. Проверка происходит внутри изолированных контейнеров, которые создаются перед каждым запуском. Поэтому тесты стабильны и выполняются или не выполняются всегда.


Заключение


Docker понять не просто, несмотря на его простоту. Для этого нужно подрасти. У меня не было надежного руководства, поэтому все приходилось постигать самому. Возможно кто-то как я благодаря этой статье сможет вырасти немного быстрее.


Постскриптум

Хочу отметить одну мысль. Внедрение Docker может быть порой избыточным. Если у Вас личный блог, одностраничник или какой-либо другой простой проект, то настройка сервера съест у Вас время и ресурсы, а на выхлопе профита либо не будет, либо он будет отрицательным. Но если это крупный и долгосрочный проект, до Docker скорее всего будет правильным решением. Это как автоматические тесты. Для маленьких проектов они не нужны, тогда как для крупных обязательны.




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

Поделиться публикацией
Похожие публикации
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 137
  • +12
    Докер… Зрелось… А сами зачем-то PHPMyAdmin в 2017-м юзаете.
    • –4

      Прежде, чем я что-то буду говорить, можно, пожалуйста, аргументы? Что Вы имеете против PMA и какие есть альтернативы помимо консоли или аналогичных инструментов аля Adminer?

      • 0
        Ну например официальное приложение MySQL Workbench :)
        • +2
          Не могу не порекомендовать HeidiSQL.
          П.С. Зря поленился обновить комментарии.
          • –7

            Использую Ubuntu. Желания корячится с Wine нет

            • +1
              Друг, оно (workbench) есть для Linux…
              Выбрать и скачать тут. По личному опыту скажу — пма лишняя нагрузка на сервер и трата времени на настройку.
              • +1

                Я использовал workbench какое-то время. Но мне он не нравится. Раньше частенько вылетал посреди работы.
                Вариант с "PHPStorm с встроенным в него DataGrip" мне нравится больше. И мне этого пока что достаточно.
                Про Wine я имел в виду, чтобы использовать HeidiSQL. По крайней мере готовый DEB пакет я не нашел.

                • 0
                  Странно. У нас есть БД с 2 млн. записей и воркбенч нормально их переваривает. 2 млн это конечно не хайлоад, но все же.
                  • 0

                    У нас даже таких объемов нет. Таблицы в среднем по 1000 строк. Помимо прочего, у меня 14.04 версия убунты. Новая версия (6.3.10) может не запуститься (пробовал как-то), а вот как раз старая (6.2.5), которые предназначены для моей версии, запускается. Но она не стабильна и в специфичных местах вылетает

                    • 0
                      Вот кстати воркбенч при работе с Марией часто проявлял нестабильность(пол года назад примерно с него ушёл), но он поддержку Марии и не обещает. Сейчас сижу на смеси хейди и дбивера. Очень странно конечно что такого интуитивно правильного функционала как подстановка дропдауна со значениями если поле — внешний ключ, при редактировании таблиц, кроме хейди никто и не предлагает.
                      По крайней мере я больше ни у кого это не встретил, допускаю что плохо искал.
                  • +2

                    PMA — это никакой траты времени на настройку. Зайти, запустить конфиг и… все.
                    В плане сервера — профиль php-fpm и mknod 3 раза, чтобы в chroot сие работало.
                    Вот и все. Объяснять клиенту, как прокинуть порт на сервер по ssh (+прописывать правила в iptables чтобы они не могли прокидывать другие порта) — оно никому не нужно.

                • +2

                  Сам юзаю heidi, в том числе и через wine. Только она багованная до ужаса (и под вин и "под линукс"). Но нормальных и бесплатных альтернатив нет.


                  На счет phpmyadmin — вполне себе нормальный продукт, когда надо сделать кому-то доступ к базе через веб.

                  • 0

                    Или простая админа для системы :)

                • 0
                  Считаю, что стоит также сюда добавить dbforge. Пользуюсь дома Ubuntu и Macos на работе, но ничего более функционального для MySQL не нашел. Позволяет удобно работать с Views и хранимыми процедурами, посмотреть другую таблицу по ключу и выбрать значение прямо на месте, редактор с нормальным форматированием, удобно анализировать производительность запросов. Для специфических задач держу зафризенный Virtualbox с Windows и данным приложением наготове.
                  Под убунтой приходится пользоваться Datagrip, под Macos — Sequel Pro. В нем всего один фильтр можно использовать в таблице, форматирования нет вообще при просмотре кода. В отличии от Datagrip видит хранимые процедуры.
                  В PMA можно случайно не туда ткнуть во время загрузки и грохнуть таблицу, даже спрашивать не будет.
                • 0
                  Что Вы имеете против PMA?

                  Как минимум то, что у вас на каждый проект разворачивается по PMA. А если вам нужен доступ к базе на продакшн? Вы там тоже будете разворачивать PHPMyAdmin?

                  какие есть альтернативы

                  Heidisql
                  PHPStorm с встроенным в него DataGrip
                  Workbench, прости, господи.

                  В любом из этих инструментов вы подключаетесь к сторонней базе. Соответственно, если подключение к БД возможно только с локальной машины (а это в 99% случаев будет так), пользуйтесь ssh-туннелями, благо это сейчас умеет любой современный бд-клиент.
                  • –1
                    Как минимум то, что у вас на каждый проект разворачивается по PMA.

                    Это… Как сказать, не совсем прям аргумент против самого PMA, как к способу его подключения.


                    Heidisql

                    Windown only. Как написал выше "Использую Ubuntu. Желания корячится с Wine нет"


                    Workbench

                    Не стабилен. Постоянно вылетает. Почему-то. В любом случае, мне он не нравится


                    PHPStorm с встроенным в него DataGrip

                    Его и использую преимущественно.


                    Но аргументов против PMA я так и не увидел. С чем я могу согласиться, что еще один торчащий наружу сторонний проект, который я не могу контролировать, который использует ROOT доступ к базе — это лишняя угроза.

                    • +2
                      Вы в последнем предложении разнесли в пух и прах PMA. Если для вас безопасность приложения не является аргументом, я с вами спорить не буду.
                      • 0

                        Но это мой аргумент) И это причина по которой я не исползую PMA в продакшене. Мне было интересно узнать, что скажут мне на это люди. В итоге, единственный адекватный аргумент против использования PMA был, что это "лишняя нагрузка на сервер". Остальные были в духе "он морально устарел используй XXX"

                      • 0
                        Совершенно необязательно давать туда рут
                      • +1
                        Как минимум то, что у вас на каждый проект разворачивается по PMA.

                        А играть в "назови мне логин и пароль" не пробовали? PMA в это умеет.

                      • 0
                        navicat лет десять как использую… еще frontmysql лет 5 назад пользовался.
                      • 0
                        DBeaver для ubuntu отлично работает. В одном флаконе доступ к mysql, postgres, каким-то nosql решениям (не помню к каким). Рекомендую. PMA подходит для проектов, которые вы в конце статьи описали как «очень простые».
                    • +7
                      База в докере? Серьезно?
                      • –3

                        Это не похоже на конструктивную критику. В чем проблема базы в докере? Окей, может быть для нагруженных проектов имеет смысл вынести базу в хост машину или даже на отдельный сервер. Но overhead от использования в докере не такой большой, чтобы как-то сильно запариваться. Производительность в худшем случае будет 91%, а в лучшем 96% от использования базы на хост машине. С другой стороны, благодаря тому, что именованных томов (volumes) хранятся в одном месте, проще настроить backup один раз, и забыть. Или я чего-то не знаю? Буду благодарен, если просветите.

                        • +3
                          Проблема не в производительности, а в стабильности.
                          На тестом сервере или при локальном разработке база в докере это замечательно и удобно.
                          Но не в проде. Тут рассказывают почему. Пункт «Запрещено использовать в DBA.»
                          • 0

                            Стоит учитывать, что это перевод довольно истеричной статьи 2016 года.


                            Например, там упоминаются aufs, overlay и overlay2, но не devicemapper, btrfs, vfs или zfs. Тот же devicemapper на мой вкус куда более приятен чем aufs, "стабильность" которого меня поразила в своё время наповал. В итоге, в проде у меня были только devicemapper, btrfs (только для экспериментов) и overlay (т. к. прод на CentOS 7 с небольшой примесью CentOS 6). Использовать в проде overlay поверх чего-то кроме ext4 крайне не рекомендую.


                            Базы, которые у меня в проде живут в контейнерах используют исключительно bind mount на нормальные фс (xfs, ext4) поверх lvm2. Естественно, эти fs должны быть изолированны от /var/lib/docker (или где у вас живёт docker graph).


                            В 2015 докер был ещё сильно сырой и использовать его в продакшне было опасно. В частности, были баги в cgroups, которые приводили к паникам (на centos6). В современном мире уже всё не настолько страшно.


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

                            • +1
                              devicemapper, серьёзно? Контейнеров хотя бы 40 на хост, ci/cd jenkins/teamcity/bamboo для деплоя в паралельку (ну хотя бы штуки по 3 одновременно) с docker api, и вот тут начинается веселье с локами, а ещё можно ждать docker rm -f в несколько минут. Удачи в проектах покрупнее. А вот оверлей и его братик с индексом 2 очень хороши, желательно ещё ядро 4 накинуть. И лучше кубернетесом приправить :)
                              • 0

                                overlay вёл себя нестабильно на redhat'овском 2.6.32 некоторое время назад, особенно поверх xfs. Более нестабильно, чем btrfs, с kernel oops'ами в недрах xfs. Сейчас у меня на проде на centos7 overlay поверх ext4.


                                UPD: засомневался, что у меня на 2.6.32 был overlay, но сейчас уже не проверю, того сервера уже нет. Возможно, это было на ранних ядрах 7 centos'а.


                                dm у меня вполне себе жил (на железном lvm, не на loop, как оно по умолчанию) без особых проблем в сравнении с overlay поверх xfs. При количестве контейнеров ~30-50.


                                Отвечу сразу shurshur, у меня с dm таких проблем не было поверх lvm на железе, но как выше писал, в основном у меня живёт overlay поверх ext4.

                                • 0
                                  Так у нас dm вылез из-за того, что какая-то версия докера для centos по умолчанию использовала именно dm, а часть серверов на проде выкатывались чуть раньше, в итоге у нас часть серверов без проблем, а часть — докер раз в неделю в несознанке.
                                  • 0

                                    Проблемы сырого продукта, никуда не деться. Но сейчас уже всё не столь болезненно. Хотя, что сейчас с dm в этом плане — без понятия.

                              • 0
                                Не надо использовать dm в проде, с ним обязательно что-то случается время от времени, и временами ничего лучше полного ребута сервера не помогает.
                          • +2
                            популярное решение.
                            отдельно монтируется директория с данными, на реальной файловой системе.
                            имеет место быть.
                            • 0
                              Не подскажете, как решить проблему с владельцем файлов БД? Postgres в докере отказывается запускаться, если владелец не postgres. Но хотелось бы иметь доступ к базе и с хоста (не отдоновременно с docker-ом конечно).
                              Есть какое-то решение как при монтировании volume сменить владельца файлов и потом обратно?
                              • 0

                                Какого рода вам нужен доступ к базе? Возможность запустить бд еще и с хостовой системы или просто доступ по psql?
                                Второе и так работает, для получения первого нужно шаманить с uid.

                                • +1
                                  Сейчас база как раз на хосте. Перенести её в docker можно, но придётся менять uid, и обратно тоже. Автоматически это нельзя делать? Какой-нибудь командой RUN в dockerfile или опциями монтирования, может ещё как?
                                  • +2

                                    Стандартный образ postgres для docker делает chown для файлов базы перед запуском, если с правами что-то не так.

                                    • 0
                                      Хм… проверю, спасибо.
                                      • 0
                                        Последний раз, когда пробовал работать с официальным образом PostgreSQL, также были проблемы с доступом к файлам. Плюс было не очень понятно, как из docker-compose.yml универсально прокидывать юзера не хардкодя его UID — ведь этот конфиг могут запускать люди с разными UID, а не только 1000.
                                        С того момента, правда, вышла уже третья версия схемы compose. Возможно, там это решено — нужно посмотреть.
                                        • +1
                                          Плюс было не очень понятно, как из docker-compose.yml универсально прокидывать юзера не хардкодя его UID

                                          А зачем? Особенно учитывая, что сам docker вполне может быть на удалённой машине.

                                          • +1
                                            по-моему вы как-то докер пытаетесь неправильно готовить.
                                            • +2

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

                                      • 0
                                        не надо ничего менять потом, если я правильно вас понял
                                        for Dockerfile:
                                        #Hate docker volumes
                                        && usermod -u 10001 «posgresuser» && groupmod -g 10001 «posgresuser» && chown -R «datadir»
                                        но лучше воздержаться от БД в докере
                                        • 0
                                          «Потом» — это если захочется отказаться от докера.
                                    • 0
                                      Разве что для тестирования в изолированном окружении.
                                      • –1

                                        Данные на внешней системе лежат, том пробрасывается в докер.

                                        • 0
                                          А что не так, собственно? Если мы говорим о разработке, естественно.
                                          У меня сейчас на ноуте крутится гроздь контейнеров, и среди них 4 — базы данных(mariaDB, Redis, ClickHouse, Couchbase). Данные хранятся в папке приложения и линкуются внутрь контейнеров, поэтому при перезапуске или пересборке контейнеров я не теряю данные. На производительность тоже не жалуюсь — для разработки вполне хватает, всё очень шустро бегает) А на проде весь этот зоопарк разбит по нескольким серверам с репликацией, и этим рулит админ.
                                        • 0

                                          -

                                          • +3
                                            Для этого нужно подрасти. У меня не было надежного руководства, поэтому все приходилось постигать самому. Возможно кто-то как я благодаря этой статье сможет вырасти немного быстрее.

                                            Это действительно проблема, материалов по Docker в русскоязычном сегменте мало, приходится много времени проводить за мануалами на не родном языке. Но ваша статья не решает эту проблему, очередная вода с неполным листингом docker-compose

                                            P.S. Пользуясь случаем прошу подсказать возможные способы деплоя docker проекта на 1 сервер (без оверинжиниринга вроде kubernetes).
                                            • 0
                                              • Я в начале статьи написал, что это рассказ о моем опыте. Обещания дать много инфы я не давал. Это статья о понимании Docker'а, как инструмента, а не инструкция по его использованию. Более содержательные статьи об использовании Docker будут в будущем. Есть идеи, которые в интернете как-то совсем не раскрыты.
                                              • Это не листинг docker-compose, а строки, которые нужно добавить, чтобы подключить БД или PMA. Как мне кажется, фраза "Подключение к проекту новых компонентов стало вопросом нескольких строк" на это мягко намекает. Специально разделил эти два куска, чтобы (возможно) было яснее. Писать полный конфиг compose в этой статье я не вижу смысла.
                                              • На самом деле… Простых инструментов деплоя я не знаю. В Bitbucket есть pipelines. Можно сделать примерно так:


                                                • Упаковать нужные файлы в архив вместе с docker-compose файлом
                                                • Отправить файл на сервер по ssh
                                                • Распаковать его
                                                • Запустить build и up
                                                • Убраться за собой (удалить архив, остаточные файлы и т.п.)

                                                Не самый идеальный способ, но как-то работает. Для малых и средних проектов, я думаю, подойдет.


                                              • 0
                                                самое простое решение, как по мне, использовать посредником docker hub,

                                                1. готовишь релиз application с тестами и т.п.
                                                2. собираешь ducker image
                                                3. пушишь в свой hub
                                                4. создаешь web-хук на хабе, который даст сигнал серверу, на котором хук расположен, стянуть обновленный билд нужного docker image
                                                5. запустить тесты и все остальное что проверяет работоспособность полученного image

                                                в двух словах примерно так и сделали, не доросла наша компания до использования готовых инструментов CI/CD, которых, к слову, не счесть… а понять что подходит лучше — по немногу в каждом надобно разбираться.
                                              • +4
                                                Позволю себе немного язвы, поправьте, если я не прав.
                                                Виртуализация здорово подходит для разработки. Но в продакшн оно не годится.

                                                Странное заявление. Вы понимаете, как работают дата центры? В которых, в общем-то, может использоваться тот же Docker, которой является системой виртуализации :) Без виртуализации понятие «масштабирование» означало бы процесс физического наращивания мощности сервера. Т.е. по клику у хостера «добавить контейнер» происходила бы закупка оборудования, чувак бы нес все эти железки, устанавливал в ферму и т.д. И процесс бы занимал недели.
                                                Vagrant — проще говоря, это инструмент, который дает Вам возможность настраивать VirtualBox скриптом.

                                                В общем-то тоже самое делает и докер. Только вряд ли он для этого предназначен.

                                                П.С.
                                                1. Странное занятие — использовать Docker для разработки. Нет, я не отрицаю, что, например, если у вас в компании трудится 100 человек и вы разрабатываете на сервере, то быстро развернуть проект для нового сотрудника или для форка можно и докером, только зачем? Вы же сами написали про вагрант. Туда можно засунуть те же параметры деплоя, закинуть все в архив вместе с файлами проекта и кому-то отдать. Можно это все запрограммировать на уровне скриптов. Резюмируя — не о том здесь описан Docker, не о том :)
                                                2. Если уже говорить о нормальном деплое и Continous Integration (CI), то уместнее было упомянуть стек: контроль версий (GIT, SVN, TFS), сервер CI (Teamcity, Jenkins).
                                                3. Что я вынес из этой статьи
                                                image
                                                • 0
                                                  Докер не является средством виртуализации, а использовать его для локальной разработки обычная практика.
                                                  • –2
                                                    Docker — программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы.… Изначально использовал возможности LXC, с 2015 года применял собственную библиотеку, абстрагирующую виртуализационные возможности ядра Linux — libcontainer.
                                                    (с) Wiki

                                                    Виртуализация на уровне операционной системы позволяет запускать изолированные и безопасные виртуальные машины на одном физическом узле, но не позволяет запускать операционные системы с ядрами, отличными от типа ядра базовой операционной системы. При виртуализации на уровне операционной системы не существует отдельного слоя гипервизора. Вместо этого сама хостовая операционная система отвечает за разделение аппаратных ресурсов между несколькими виртуальными машинами и поддержку их независимости друг от друга. Среди реализаций:
                                                    • Solaris Containers/Zones
                                                    • FreeBSD Jail
                                                    • Linux-VServer[en]
                                                    • LXC (Linux Containers)
                                                    • FreeVPS[en]
                                                    • OpenVZ
                                                    • Virtuozzo
                                                    • iCore Virtual Accounts

                                                    Зачем использовать докер для локальной разработки? В чем его преимущество перед той же VB, которая умеет делать снимок виртуалки, который можно установить на любой комп? Или тот же вагрант? Мне все же кажется, что докер немного не про это.
                                                    • +2
                                                      Виртуализация на уровне ядра — это как морская свинка. :)

                                                      Навскидку, по личному опыту, виртуальные машины слишком сильно изолированы от хоста и друг друга для эффективного разворачивания сложной системы локально. Зачастую резервируют излишние ресурсы, оставляя их мало для собственно разработки. При этом на продакшене практически не используются, то есть надо поддерживать минимум два слабо связанных окружения. Практика показывает, что если на продакшене используется докер, то на вагранты часто забивают, накапливается разница в окружениях.
                                                      • 0
                                                        Виртуализация на уровне ядра все равно виртуализация)
                                                        Не совсем понял про слабо связанное окружение. Разве нельзя настроить одну среду на докере и вагранте? Я согласен, что здесь имеет место быть человеческий фактор, но в таком случае нужно говорить о CI, а не о докере\вагранте. В моем понимании докер востребован только тогда, когда у тебя облако\удаленный сервер и\или хайлоад. Причем я бы рассматривал его только в случае масштабирования, т.к., на мой взгляд, разработка должна вестись на локальной машине, уходить в систему контроля версий, а от туда разворачивать проект через систему непрерывной интеграции. Хотя допускаю, что разрабатывать можно на докере, форкаться и тд, потом через контроль версий заливать готовый проект в контейнер докера, там пробегать все тесты и через CI заливать контейнер с проектом. Но… если нужно обновить 1 файл в проекте, смысл все пересобирать? В общем, в данном вопросе у меня нет однозначного ответа. Могу лишь утверждать, что для себя я определил докер, как систему быстрого развертывания идентичной среды для нагруженного проекта.
                                                        • 0
                                                          Ну так в разработке желательно иметь среду максимально близкую к продакшену, чтобы избегать ситуаций «а у меня всё работает». Локально проверяешь, что образа билдятся, что работают как надо, а потом коммитишься и дальше уже пошло по принятому флоу. Но результат твоей работы не только исходный код на ЯП, но и докерфайлы, конфиги сервисов типа веб-сервера и СУБД, описания/скрипты процессов деплоя и т. п. Можно это делать наобум, отправляя изменения в vcs, и ожидая результата от пайплайнов CI, проверяя работу где-то, куда они её раскатали, но при наличии возможности проверить локально, почему это не делать? А докер в этом плане более простой и легковесный, и чем более сложная система, тем преимущества виднее для меня. По крайне мере пока всей системе из десятков сервисов хватает ресурсов локальной машины.
                                                          • 0
                                                            Подождите. При деве необходимо на локальной машине эмулировать среду продакшена, а не наоборот. Зачем деплоить настройки среды на продакшн?
                                                            • 0

                                                              Так они идентичные, единственное отличие сред (продакшен, CI, стейджинг, лоакльная) в параметрах типа DNS имён ендпоинтов и количества воркеров. Грубо, все отличия сред только в environment переменных, читаемых из какого-нибудь .env файла, который в репозиторий не вносится. Плюс для локальной можно примонтировать каталоги с локальными кодами, чтобы не билдить/рестартовать контейнер на каждый чих, только на какие-то глобальные изменения.

                                                              • 0
                                                                Это понятно. У меня тогда вопрос, чем отличается среда на ВБ с Debian 9.1\PHP7.1\MySQL5.7.20 от среды на проде с тем же стеком? Я не думаю, что в вопросах данного стека принципиально железо и сопутствующие ему драйвера. Иными словами, весь этот стек штатно работает на обоих машинах, поэтому и код должен работать одинаково. Разве нет?
                                                                • 0

                                                                  Скорее всего, на проде это будет минимум два отдельных сервера, а то и больше. А на ВБ, скорее всего, одна виртуалка. Процедуры обновления скорее всего будут разные — на проде автоматизированная, а на виртуалке часто ставят что-то ручками, забывая занести в вагрантфайл.

                                                                  • 0
                                                                    Согласен. Тут вопрос в размере проекта.
                                                      • 0

                                                        Возможно, я попутал термины. Подумаю, что можно сделать, чтобы не переписывать всю статью.
                                                        Основное преимущество Docker перед VB в первую очередь в том, что он не ест столько оперативки и не требует целой кучи ресурсов.
                                                        У меня всего 8гб, на плечи которых лежит PHPstorm со всеми плюшками, Chrome с десятком плагинов, Webpack с запущенным на нем Hot reload и ещё несколько инструментов. Чтобы запустить и держать в рабочем состоянии VB рядом со всем этим добром, нужно ресурсов гораздо больше. В итоге, ОЗУ заканчивалась, процессы лезли в swap и насиловали мой HDD, после чего разработка становится невыносимой и приходилось от чего-то отказываться.
                                                        VB запускает всю систему целиком со всеми ее процессами, которых не так уж и мало. В свою очередь Docker запускает только то, что мне нужно.
                                                        Docker запускается намного быстрее. Подключать дополнительные компоненты удобно. Тестировать хорошо, так как можно быстро поднять новый, чистый контейнер. Selenium работает из коробки без всяких танцев с бубном.
                                                        Для себя я нашел много преимуществ. Если их не находите Вы, это может говорить об одном — Вам он (Docker) просто не нужен.

                                                        • 0
                                                          Странно, что VB у вас ест все ресурсы хоста. ВБ это гипервизор, он жестко ограничивает использование виртуалкой ресурсов хоста. Иными словами, вы выделили виртуалке 1гб озу и 1 ядро, оно больше этого и не может использовать. Если у вас проблемы с ВБ, попробуйте Hyper-V, если конечно у вас хост на винде.
                                                          Мне докер нужен, но для предназначения, которое написано на официальном сайте проекта :) Для разработки есть масса удобных и более удобных инструментов. Тот же пхпшторм. У него из коробки идет плагин для вагранта.
                                                          На вкус и цвет конечно. Мой вопрос лишь в том, что не стрельба ли это по воробьям из танка?
                                                          • 0
                                                            В случае вагранта ресурсы определяет разработчик вагрантфайла. Сказал нужно 2 гига и
                                                            • 0
                                                              и переопределить локально затруднительно.
                                                                • 0

                                                                  Это разве не в вагрант файле хранится?

                                                                  • 0
                                                                    Да, в нем. Я не совсем тогда понимаю, что вы подразумеваете под
                                                                    и переопределить локально затруднительно.
                                                                    • 0

                                                                      Обычно, вагрант файл лежит в репозитории проекта или где-то рядом, с параметрами подходящими его автору, у которого, например, 32Гб оперативы и 4 физических ядра плюс HT. Вот и даст одно физическое ядро и 4 Гб, чтобы избегать малейших тормозов. А у тебя 8Гб оперативы и 2 физических ядра. Эта виртуалочка скушает половину ресурсов. А пулл реквест на изменение автор не примет. Придётся изменить и как-то следить чтобы в репу не закоммитить эти изменения, а изменения из апстрима прилетали.

                                                  • +2
                                                    Docker невозможно установить на VPS поднятом на OpenVZ если ядро linux ниже минимальной версии требуемой докером. У меня вот весьма хороший тариф на VPS, но докер я юзать не могу из-за этого ограничения, а платить в 2 раза дороже за аналогичную конфигурацию с SSD на борту вместо HDD как-то не хочется.
                                                    Т.е. не каждый VPS поддерживает докер. В итоге получаем неработающую «серебряную пулю».
                                                    • 0

                                                      Если говорить про нормальный vps/vds, а не контейнер в openvz/lxc, то вы сами выбираете нужный дистрибутив, ядро и т. п.


                                                      Другое дело, что многим мелким проектам это просто не нужно и никогда не понадобится.

                                                    • +3
                                                      Посмотрите ещё в сторону ansible. Его также можно связать с докером, иногда вместо, иногда вместе. Как раз очень прост в плане настройки, хоть и требует некоторого внимания к деталям.
                                                      • 0

                                                        Много говорят про ansible. Обязательно посмотрю, раз его так любят

                                                      • 0

                                                        Не утверждаю, что здесь что-то плохое, но позволю себе чутка возразить на некоторые части поста


                                                        Это [Bitbucket] повысило защищенность кода от стороннего вмешательства. VPS мог сломаться, его могли взломать, просто не успели заплатить.

                                                        За VPS не следите — сами виноваты, не обеспечели безопасность — сами виноваты, не заплатили — опять же сами виноваты. А вот на битбакет теоретически может прийти крымнаш, вам прикроют ваш репозиторий из-за санкций россиянам (это я ещё роскомнадзор не вспоминаю), и вы побежите доставать репозиторий из бэкапов прошлогодней давности стаить Gogs на VPS как миленький :)


                                                        Попробуйте запустить на одном хостинге два проекта с разными версиями MySQL и PHP.

                                                        Разные версии PHP лично запускал (не на дебиане, правда, а на арче, но всё равно никаких трудностей, всё разделено по папочкам php5 и php7). А зачем может понадобиться ставить разные версии MySQL?


                                                        Если что-то менялось на сервере, нужно было менять и в виртуалке

                                                        Выше уже упомянули Ansible. Всё меняться должно только через него, и подобная проблема перестанет существовать, хоть с докером, хоть без


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

                                                        Такой перегородкой во многих случаях может послужить банальное разделение по разным пользователям. Хотя, конечно, беспроблемно поставить двадцать версий PHP это не даст, однако это и нужно редко


                                                        Нужно обновить версию MySQL? Сколько времени и усилий пришлось бы приложить, чтобы сделать это на обычном VPS хостинге?

                                                        sudo apt-get update && sudo apt-get dist-upgrade. Можно загнать в алиас размером в 3-4 символа. Что я делаю не так?


                                                        код, запущенный на машине разработчика с Ubuntu, будет работать ровно также, как и на сервере с Debian

                                                        Ох-ох

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


                                                        Кстати, докеры и прочие виртуалки ещё и место занимают на образы базовых ОС, минималистичный Alpine в качестве базы юзают далеко не все, а на моём VPS сейчас свободно всего четыре гига, так что докер я не могу себе позволить даже если бы хотел)

                                                        • 0
                                                          А вот на битбакет теоретически может прийти крымнаш, вам прикроют ваш репозиторий из-за санкций россиянам (это я ещё роскомнадзор не вспоминаю), и вы побежите доставать репозиторий из бэкапов прошлогодней давности стаить Gogs на VPS как миленький :)

                                                          В чём проблема добавить новый remote и запушить актуальный репозиторий? Чай не svn/cvs.


                                                          Разные версии PHP лично запускал (не на дебиане, правда, а на арче, но всё равно никаких трудностей, всё разделено по папочкам php5 и php7). А зачем может понадобиться ставить разные версии MySQL?

                                                          Это пока вам не понадобится держать, скажем, php 5.5 и 5.3 одновременно. Или что-нибудь ещё в таком роде. Другое дело, что поправить PKGBUILD не составляет труда. Но на prod я бы arch ставить не стал, а большинство дистрибутивов вам не позволят держать несколько минорных версий того же php одновременно. Мейнтейнить это барахло самому может быть слишком дорого.


                                                          Говоря же про несколько версий баз приведу два примера. У меня одновременно работают 4 версии MongoDB (2.6, 3.0, 3.2 и 3.4), более 20 инстансов. Так сложилось исторически и некоторые из них мигрировать на новые версии либо не имеет смысла, либо просто дорого по времени и ресурсам. Проще и безопаснее иметь несколько запущенных версий. Мейнтейнить несколько пакетов под это просто неоправдано: их сборка, поддержка и тестирование будут съедать большое количество времени и сил без значительных преимуществ относительно нескольких версий, запущенных в разных контейнерах с bind mount для актуальных данных. Другой пример — несколько инстансов postgres с различными бинарными расширениями. Причём тех версий, которых просто нет в CentOS 7.4.


                                                          Выше уже упомянули Ansible. Всё меняться должно только через него, и подобная проблема перестанет существовать, хоть с докером, хоть без

                                                          С этим сложно поспорить. Хотя ansible местами тоже та ещё боль. Если интересно, я чуток упоминал.


                                                          sudo apt-get update && sudo apt-get dist-upgrade. Можно загнать в алиас размером в 3-4 символа. Что я делаю не так?

                                                          Вы это на нормальном проде без предварительного тестирования делаете? Тогда всё делаете не так, если речь не идёт о личном бложике.


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

                                                          Соберите пару-тройку пакетов, требующих C++11 с фиксированной версией, скажем boost'а или poco под CentOS 7. Потом вместе посмеёмся.


                                                          Кстати, докеры и прочие виртуалки ещё и место занимают на образы базовых ОС, минималистичный Alpine в качестве базы юзают далеко не все, а на моём VPS сейчас свободно всего четыре гига, так что докер я не могу себе позволить даже если бы хотел)

                                                          Никто не мешает написать свои dockerfiles, положить их на github/bitbucket, настроить на dockerhub automated build и использовать минималистичные образы. Тот же centos:7 весит всего 74M, а дальше его можно использовать как базу для всех нужных образов. Или alpine, если его хватает.

                                                          • 0
                                                            4 версии MongoDB

                                                            Ну nosql-хипсторы уже ССЗБ) Мои проекты успешно работают на всём разнообразии версий MySQL и MariaDB за последние пять лет (а скорее всего и больше, но я просто не пробовал). Хотя про постгрес мне ответить нечего, окей


                                                            Вы это на нормальном проде без предварительного тестирования делаете?

                                                            Зачем же, есть staging-сервер, идентичный проду. Хотя вообще да, лично у меня просто условный личный бложик, и мне обновляться без подготовки на проде в общем-то не страшно) Но для страшных действий staging всё равно есть


                                                            C++11

                                                            Ой, тут я не компетентен. У меня в питонах подобной ереси нет)

                                                            • 0
                                                              Ну nosql-хипсторы уже ССЗБ) Мои проекты успешно работают на всём разнообразии версий MySQL и MariaDB за последние пять лет (а скорее всего и больше, но я просто не пробовал). Хотя про постгрес мне ответить нечего, окей
                                                              Ну nosql-хипсторы уже ССЗБ) Мои проекты успешно работают на всём разнообразии версий MySQL и MariaDB за последние пять лет (а скорее всего и больше, но я просто не пробовал). Хотя про постгрес мне ответить нечего, окей

                                                              Ну тогда и не стоит использовать ad hominem. MongoDB и Apache Cassandra в определённых областях очень удобны и заменить их на MySQL/MariaDB невозможно.


                                                              Ой, тут я не компетентен. У меня в питонах подобной ереси нет)

                                                              Вероятно, вам просто везёт, что не используются бинарные расширения, написанные на C++11 и выше. В питонячем мире на это нарваться сложнее, но тоже бывает.

                                                        • +1
                                                          Я, наверно, тоже не дорос до Docker'а — Использую ProxMox: OpenVZ контейнеры легко копируются, а снепшоты позволяют спокойно откатываться на любую резервную копию или вообще отдельную ветку с совсем другим софтом/окрежением/проектом.
                                                          Ну и Git для кода, разумеется. (С сервером в отдельном контейнере и резервными копиями каждый час на отдельный диск)
                                                          • +3
                                                            По мне, так наоборот, докер — показатель «подросткового возраста» в it. Пару лет назад я его везде использовал, потом повзрослел, и теперь только в некоторых специфических задачах его юзаю.
                                                            • 0

                                                              Сильно зависит от задач, да. Для некоторых вещей оверхед от использования докера будет больше, чем польза от оного. Для деплоя в проде это может быть способом избавиться от большого количества головной боли, но потребует вложения определенного количества сил и средств в соответствующую систему оркестрации (будь то банальный docker swarm, или более тяжелые kubernetes с openshift'ом).

                                                              • 0

                                                                Жду тогда от Вас статью "Docker, как показатель подросткового возраста")

                                                                • 0

                                                                  Поясните, пожалуйста, подробнее. Нутром чувствую, что с вашим комментом согласен, но надо убедиться)

                                                                • +2
                                                                  У меня сложилось устойчивое мнение, что Docker это костыль решающий вечные проблемы скриптовых языков когда скрипт может сломаться на ровном месте или, к примеру, какой нить JodeJS может устареть, а проект уже никто переписывать не будет.

                                                                  Короче Docker только новые проблемы пораждает.

                                                                  Я реально слабо представляю нафига он в том же ASP.NET или Go нужен.
                                                                  • 0
                                                                    Первое, что делает докер — изолирует процессы друг от друга, используя различные маппинги. Второе, что он делает — фиксирует окружение (как билд, так и рантайм), только версия ядра и самого докера не зависит от автора докерфайла, а так он контролирует каждый файл в своей ФС без конфликтов с другими приложениями на том же хосте.

                                                                    И полезен он прежде всего для компилируемых языков. Это в скриптовых можно залезть и поправить, например, порт, который будет слушать процесс в простом текстовом редакторе, а в компилируемых так не выйдет.
                                                                    • 0
                                                                      Нормальные приложения имеют текстовые конфиги.
                                                                      А для изоляции есть LXC.
                                                                      • 0
                                                                        Докер позволяет эти конфиги вынести из приложения и конфигурировать всё в едином месте и формате.
                                                                        • 0
                                                                          Докер и есть настройка над LXC) Но, по моему субъективному впечталению, с докером и его аналогами работать удобнее, чем с голым LXC
                                                                          • +1
                                                                            Proxmox позволяет на проде делать контейнеры LXC, что получается довольно удобно.
                                                                            • 0
                                                                              Скрипт на баше в 20 строк тоже может создавать полноценные контейнеры, но это не значит, что он будет также хорош, как Docker.
                                                                            • 0
                                                                              Докер был надстройкой на LXC пару лет назад, но не сейчас.
                                                                              • 0

                                                                                Это было года 2-3 назад. Потом появился libcontainer и docker отказался от использования lxc, а использует namespaces и cgroups напрямую.

                                                                        • +5
                                                                          Пожалуйста, не надо так.
                                                                          Как только у вас возникло желание обвинить кого бы то ни было в незрелости — это отличный маячок, что статью писать не надо.
                                                                          Ваши доводы уже разбили в комментах. Но это не важно. Ваша ошибка — в самом начале статьи и остальное уже неважно.

                                                                          Пожалуйста, если хотите рассазать о технологиях — рассказывайте о технологиях, а не о том, что «тот кто не использует, тот нуб!»
                                                                          • 0

                                                                            Я думаю, Вы и без моих оправданий прекрасно понимаете, что цели кого-то унизить или обвинить у меня не было. Я сам новичок в этом и мне многое что не известно. Вот, люди указали на Ansible. Я с удовольствием посмотрю, когда будет время.
                                                                            Мотивы мои чисты и искренни. Мне хотелось поделиться своим небольшим опытом и полученными знаниями.
                                                                            Мне понравился Docker. Он вызывает сейчас у меня такой же восторг, как в свое время вызвал Git, Vagrant и открытия мира Open Source. В моей ситуации Docker решает много проблем. И я не считаю его серебряной пулей, которая способна решить все проблемы.
                                                                            Но если найдется хоть один, кому я смог помочь, пусть статья не столь информативна, я буду очень рад.
                                                                            В любом случае, это мой первый опыт в написании статей. И учитывая, что рейтинг статьи, благо, ещё в плюсе, а 28 человек добавило её в закладки, есть те, кто оценил мою поэзию положительно)

                                                                            • +2
                                                                              Мне понравился Docker. Он вызывает сейчас у меня такой же восторг, как в свое время вызвал Git,

                                                                              Проблема в том, что многие здесь не только попробовали Docker, но уже и наелись проблем с ним. Вы только погружаетесь в тему, а для тех кто пользуется им давно подобный заголовок как красная тряпка. Многие на Хабре хорошо осведомлены как устроен Docker и как он работает. И не все от этих знаний в таком же восторге как вы.

                                                                          • +1
                                                                            «Зачем, да и вообще кому нужны всякие Symfony, если есть WordPress?» А что плохого в Wordpress? Как раз использование фреймворков там, где это не надо и есть изврат. В Америке и Европе большинство проектов как раз и строятся на CMS них, а не пишутся на фреймворках. Просто потому, что поддержка для клиента более предсказуема и выгодна в материальном плане. Нужен блог — берут Wordpress, нужен магазин — берут Magento или Woocommerce.
                                                                            • 0
                                                                              А потом ищут спецов, которые к вордпрессе прикрутят магазин, а к магенте блог. Или обеспечат прозрачную интеграцию вордпресса и магенты.
                                                                              • 0
                                                                                Woocommerce — это и есть магазин для Wordpress. из коробки. Ну и интеграция Magento и Wordpress решается установкой модуля. И найти спецов по CMS гораздо легче и дешевле, чем по фреймворку. Гораздо хуже, когда для Landing Page или 10 страничного сайта разработчик Laravel или Symphony использует.
                                                                              • 0

                                                                                А я разве сказал, что WordPress — это плохо и его не нужно использовать? Напротив, он здорово справляется со своей задачей. Я говорю про то, что новичкам сложно понять, зачем нужны фреймворки. И в особенности Symfony, у которого уровень абстракции гораздо выше, чем у многих других фреймворков.
                                                                                Скажу про себя: я действительно не понимал, к чему такая сложность. Сейчас сижу и жалею, что выбрал не его. Гибкий компонентный подход был бы очень кстати. И почувствовал это я, когда начал тестировать. Но раньше я этого не мог понять по причине недостатка опыта.

                                                                                • 0
                                                                                  Фреймворки для типичных задач — это зло. Всегда легче использовать CMS, чем писать «с нуля». Просто потому, что CMS изначально заточена под решение задач и содержит какие то вещи, которые вы просто можете не учесть и её поддержка для клиента в дальнейшем выйдет дешевле. Это на самом деле какие то реалии российского рынка, когда у каждой студии своя самописная CMS, на которой они строят все сайты, независимо от того подходит она или нет. Для нестандартных задач — бесспорно надо использовать фреймворк, но если присмотреться, в общей массе их не так много.
                                                                                  • 0

                                                                                    CMS изначально заточена под одну задачу — управление контентом. Фреймворки заточены, как правило, под две задачи — предоставление типичной инфраструктуры, чтобы не писать её с нуля, и быстрое создание прототипов/MVP. CMS решает одну бизнес-задачу, фреймворк не решает ни одну, это инструмент для создания решений.

                                                                              • +1

                                                                                .dev — домен верхнего уровня в собственности у Google. Не стоит им пользоваться.

                                                                                • 0

                                                                                  Да сколько можно? Ранее пользовался local, в форуме мне намекнули, что не нужно, потому что это зарезервированный домен. Начал пользоваться dev. Да нет же, его тоже решили занять… Хорошо, что test, как оказалось, тоже зарезервированный, но для разработчиков.
                                                                                  Спасибо больше за ссылку. Добавил пояснение в статью.

                                                                                  • 0

                                                                                    *.localhost обычно пользуюсь локально.

                                                                                    • 0
                                                                                      Тоже не всегда подходит, потому что некоторые хромы принудительно приписывают ему 127.0.0.1, даже если в файле hosts переопределить. Мне как-то раз приспичило вёрстку в хроме под виндой проверить, поставил их в виртуалбокс — а dev.localhost не открывается (причём с IE/Edge в той же виртуалке отлично открывается), пришлось менять конфиги сайта, отвязывая его от домена, и по айпишнику 10.0.2.1 ходить
                                                                                      • 0

                                                                                        Странно, не встречаля. Хотя может в винде дело.

                                                                                • 0
                                                                                  Статья интересная, с точки зрения развития инструментов CI/CD. Другое дело что это все полезно в более менее крупных проектах.
                                                                                  • 0
                                                                                    В последнем связке Virtualbox+Vagrant+Laravel Homestead каждому сайту легко можно указать версию php(5.6б, 7.0, 7.1), вот так:
                                                                                    sites:
                                                                                    — map: test.app
                                                                                    to: /home/vagrant/Code/test.app
                                                                                    php: «5.6»
                                                                                    • 0
                                                                                      Меня помножило на ноль вот этой фразой
                                                                                      Нужно обновить версию MySQL? Сколько времени и усилий пришлось бы приложить, чтобы сделать это на обычном VPS хостинге? Тут это вопрос 3-4 символов.
                                                                                      • –1
                                                                                        Благодаря тому, что Docker работает внутри рабочей системы, а не создает новую, он не сильно нагружает машину для разработки и вполне пригоден для прода

                                                                                        Вообще-то, он конкретно съедает ресурс памяти. А проброс потоков между контейнерами — вообще отдельный гемор.
                                                                                        • +1

                                                                                          Конкретно это сколько? Вот сейчас на 33 контейнера dockerd меньше 300 метров ест.

                                                                                          • 0
                                                                                            Вот что конкретно сейчас в этих контейнерах крутится?
                                                                                        • 0
                                                                                          Время расти дальше и представив себе что сайт вашего блога просматривают столько же людей сколько просматривают habrahabr.ru растирожировать его на несколько серверов.
                                                                                          Представляю себе решение с использованием docker =D.
                                                                                          • +1
                                                                                            Такое решение надо предствалять с помощью kubernetes'a. Там такое делается просто.
                                                                                            • 0
                                                                                              host:~docker swarm init
                                                                                              host1:~apt install docker-ce && docker swarm join ...
                                                                                              host2:~apt install docker-ce && docker swarm join ...
                                                                                              ...
                                                                                              host<N>:~apt install docker-ce && docker swarm join ...
                                                                                              host:~docker service scale blog-app-http=<N*3>
                                                                                              host:~docker service scale blog-app-fpm=<N*6>

                                                                                              На каждом из серверов запустится (примерно) по три контейнера с nginx и по шесть с fpm с балансировкой. Про MySQL отдельный вопрос, но это вопрос прежеде всего к Oracle.

                                                                                            • 0
                                                                                              Популяризация Docker осуществляется крупными компаниями для обеспечения кадрового резерва программистов, знакомых с этой технологией. Это не плохо.
                                                                                              Однако ясно, что Docker не обеспечит значительных преимуществ для небольшого и среднего бизнеса.
                                                                                              Docker больше подходит для крупных компаний в качестве одной из оптимизаций системы непрерывной интеграции, сокращая за счет большей унификации среды исполнения, потребность контроля за корректностью деплоя, упрощая смену площадки / вендора серверов и софта.
                                                                                              Знание Docker для лиц не работающих в описанных выше компаниях – признак любознательности и стремления быть в корпоративных трендах. Однако практическую пользу оно может сыграть в основном в виде фактора, учитываемого при трудоустройстве в одну из таких компаний.
                                                                                              • 0

                                                                                                Docker как раз обеспечивает значительные преимущества для небольшого и среднего бизнеса, который не имеют возможности содержать команды девопсов и наборы кластеров для целей разработки и тестирования, для внедрения CI/CD. Если для большого бизнеса докер во многом удобное средство масштабирования, то для малого прежде всего удобное средство доставки фич от разработчика к пользователю.

                                                                                                • 0
                                                                                                  Согласен. Мир программирования, типы команд и бизнес-процессов в нем очень разнообразны. В результате прохождения отличающихся путей профессионального опыта можно совершенно по разному воспринимать одну технологию.
                                                                                                  • 0

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

                                                                                                    • 0
                                                                                                      Фраза «работает локально у разработчика» намекает, что разработчик либо работает над проектом в одиночку и без админа, либо процесс развертывания приложения при использовании контейнеров выглядит излишне усложненным для небольшой команды в сравнении (например) с Capistrano, забирающим код из репозитория.
                                                                                                      Понятно, что при деплое с Capistrano приложение с некоторой вероятностью может «упасть», но тут мы возвращаемся к «запускать тысячи инстансов приложения особо не заботясь о процессе запуска», что неактуально для малого бизнеса.

                                                                                                      На примере Rails и малого проекта:
                                                                                                      cap staging deploy
                                                                                                      # погоняли функциональные тесты
                                                                                                      cap production deploy
                                                                                                      # production готов, на одном или нескольких серверах

                                                                                                      Не нужно практически ничего настраивать на машинах разработчиков. Сервера готовит админ своими ansible-скриптами. Все просто, удобно и интуитивно понятно. Зачем здесь Docker?
                                                                                                      Ожидаемый downtime среднего проекта (2-3 сервера) по причине ошибок деплоя новых версий по схеме выше я оценил бы в «один час раз в два года». А затраты на обучение команды, смену тех.процессов, документирование, отработку новых внештатных ситуаций – в десятки и сотни раз дороже.
                                                                                                      • +1
                                                                                                        правильно, зачем теги и бранчи, зачем роллбэк, тестовая/стейжевая/продовая среды, уютненько работаете ;)
                                                                                                        • 0
                                                                                                          Бранчи в репозитории. Деплой всегда с master. Роллбэк без проблем:
                                                                                                          cap production deploy:rollback ROLLBACK_RELEASE=20171129121359
                                                                                                          Тесты локально и на staging, чтобы не держать лишний сервер.
                                                                                                          В примере выше как раз две команды — staging и production.
                                                                                                          Уютно, надежно, быстро и главное эффективно ;)
                                                                                                          Кстати, как с роллбэком у Docker-powered систем? Если не Alpine, то приходится закачивать на сервера гигабайтные контейнеры?
                                                                                                          • 0
                                                                                                            Роллбэк без проблем

                                                                                                            А кстати, как дела с откатом миграций БД?

                                                                                                            • 0
                                                                                                              Наверное так же сложно, как и в случае с Docker. Ясно, что делать откат миграций автоматически в большинстве случаев не следует.
                                                                                                              Откатить работающую под нагрузкой базу – сложная задача для команды из админа, DBA и пары разработчиков.
                                                                                                              Именно поэтому:
                                                                                                              1. Изменения в схемах базы данных согласовываются с DBA и по возможности строятся так, чтобы обеспечить обратную совместимость.
                                                                                                              2. Проводятся тесты: локально на копии БД, а также функциональные тесты staging сервере.
                                                                                                              3. Если случайно прошла лишняя миграция вида «создать ненужную таблицу», то ее не откатывают, а удаляют новой миграцией в следующем релизе.
                                                                                                              4. Мажорные релизы со значительными изменениями в структуре базы данных, которые на мой взгляд малому бизнесу нужны крайне редко, целесообразно разворачивать по совершенно другой схеме. Возможно, в другом репозитории, с деплоем на другой сервер[а] и постепенным переводом пользователей на него.
                                                                                                              Вероятность форс-мажора с базой данных даже при необходимости отката на предыдущий релиз невысока.
                                                                                                              А как вы откатываете миграции в случае с Docker?
                                                                                                              • 0
                                                                                                                Я докером не пользуюсь, просто из интереса спросил) и вообще свои базы руками обновляю, но не будем о грустном
                                                                                                                • 0
                                                                                                                  На своем Pet project'е я тоже использую связку «руки + SequelPro», которая уже годы не подводит при нагрузке 15-20 тысяч пользователей в день. Остальное на мой взгляд было бы уже Overengineering )

                                                                                                                  Другое дело, когда по работе приходится иметь дело с чужими деньгами в виде проекта, час простоя которого имеет свою цену, иногда сравнимую с зарплатой разработчика за месяц. Тогда схема с одним staging сервером и деплоем Capistrano похоже самое то.

                                                                                                                  Есть проекты, где время простоя неприлично дорогое. Там Docker вероятно приносит большую пользу.
                                                                                                                • 0
                                                                                                                  а не было такого (тьфу-тьфу), есть test с с тестами stage с qa, куда копируется база с прода, делается db:migrate.
                                                                                                                  В случае факапа в проде только db:migrate:redo, во что я не сильно верю, тут косяк, но мы надеемся, что первые две среды позволят заметить ошибку, наивные мы :)
                                                                                                                  Добавление пары контейнеров с автодеплоем на пару сред пока себя оправдывает.
                                                                                                                  • 0
                                                                                                                    Технический прогресс это хорошо :)
                                                                                                                    Средства оркестрации типа Kubernetes в последнее время также неплохо развиваются. Вполне возможно со временем использование контейнеров станет стандартом индустрии и большинство коллективов придут к их использованию.
                                                                                                                    Насколько я могу оценивать по динамике развития подходов к разработке, экономическая целесообразность массового перехода к контейнеризации проектов для малого бизнеса наступит через 4-5 лет. А до тех пор интересно почитать статьи на хабре, посмотреть на чужой опыт.
                                                                                                                    • 0

                                                                                                                      Во сколько вы оцениваете стоимость перехода малого бизнеса к контейнеризации, как с точчи зрения затрат на разработку, так и с точки затрат на эксплуатацию? Ну вот совсем малый бизнес: один разработчик, который пилит корпоративный сайт с функциями CRM, и один админ который обеспечивает деплой и работу, логи там смотрит, метрики и т. п… Развёрнуто три окружения: локально у разработчика, прод и тестовое, на котором бизнес апрувит деплой на продакшен. Худо бедно настроено даже CI/CD на баш-скриптах. Но время от времени происходят инциденты по типу: разработчик установил что-то себе локально, а админу забыл сообщить. Или ввёл новый параметр конфигурации и тоже забыл сообщить. Или админ как-то ночью залез руками в конфиги сервера, чтобы какой-то параметр изменить, но разработчику не сообщил, и конфигурации стали расходиться.

                                                                                                                      • –1
                                                                                                                        1. В человеко-часах (первый год):
                                                                                                                        — обучение 20 часов тимлида + по 8 часов на каждого разработчика в команде,
                                                                                                                        — устранение багов Docker (см. статью habrahabr.ru/post/332450) примерно по 8 часов тимлида и админа в год.
                                                                                                                        — риски простоя приложения (downtime) примерно 4 часа в год.

                                                                                                                        2. Рассогласование действий с админом случается. Особенно когда админ удаленный и редко доступен. Для защиты от описанных вами случаев существует staging сервер (он же тестовый, для небольших проектов). Такой сервер должен быть идентичен production. Если приложение упало на staging, то деплой на production не проводится. «Забывать сообщить» недопустимо в бизнес-процессах.
                                                                                                                        • –1
                                                                                                                          вы на эту статью сколько ещё ссылаться собираетесь, ей уже больше года, в мире devops'а это уже много.
                                                                                                                          • 0
                                                                                                                            Открытых issues с тех пор стало больше. Уже 2888.
                                                                                                                            github.com/moby/moby/issues
                                                                                                                            Старые баги убавились, появились новые.
                                                                                                                            Я поддерживаю мнение, что у Docker есть перспективы.
                                                                                                                            Но нужно позаботиться и о деньгах клиентов.
                                                                                                                            В сфере давно и успешно работающих веб-проектов малого и среднего бизнеса уравнение
                                                                                                                            x = плюсы_Docker — (стоимость_рисков * вероятность_рисков) — расходы_на_смену_технологии
                                                                                                                            пока не выглядит положительно.
                                                                                                                          • 0
                                                                                                                            1. Вот по опыту перехода на докер гораздо больше времени экономится на сокращении числа рутинных операций по сихронизации трёх окружений.


                                                                                                                            2. Из-за разности конфигураций и окружений приложение может падать не сразу, а в каких-то редких кейсах, а то и вообще не падать, а просто вести себя по другому, не так как должно. А насчёт "недопустимо" — описанных бизнес-процессов передачи из разработки в эксплуатацию может не быть вовсе, не говоря о контроле за их соблюдением. Докер — не единственное средство автоматизации, снижающее влияние человеского фактора на подобные процессы, но он им является.
                                                                                                            • 0
                                                                                                              Фраза «работает локально у разработчика» намекает...

                                                                                                              Фраза намекает на то, что разработчик предпочитает сначала локально проверить код в работе, а лишь потом пушить его в репозиторий, отдавая на растерзание CI/CD, ревьюверам, тестировщикам, приёмщикам и т. д. Ничего более.


                                                                                                              либо процесс развертывания приложения при использовании контейнеров выглядит излишне усложненным для небольшой команды в сравнении (например) с Capistrano, забирающим код из репозитория.

                                                                                                              Грубо, процесс разворачивания проекта на кластер сводится (есть разные варианты, но для себя выбрал такой) к трём командам:


                                                                                                              docker-compose build
                                                                                                              docker-compose push
                                                                                                              docker stack deploy

                                                                                                              хоть на локальной машине разработчика (docker-compose push не требуется), хоть на CI/CD — сервере, хоть на на продакшене


                                                                                                              Не нужно практически ничего настраивать на машинах разработчиков.

                                                                                                              давно не работал с рельсами, но навскидку нужно настроить даже для небольшого монолита:


                                                                                                              • СУБД
                                                                                                              • веб-сервер
                                                                                                              • кэш-сервер
                                                                                                              • собственно приложение
                                                                                                                Это не считая различных компиляторов и транспиллеров для Script, SS и т. п. и єто для простого монолита. А если у нас хотя бы сервис аутентификации вынесен в отдельное приложение, то количество настроек даже не в два раза больше увеличивается.
                                                                                                              • 0
                                                                                                                Как думаете, будет ли ваш способ развертывания так же удобен, если число разработчиков, имеющих право коммита в master и деплоя, увеличится до двух-трех? Я не спорю с этим, хотелось бы узнать ваше мнение.
                                                                                                                с рельсами… нужно настроить
                                                                                                                Всё правильно. Но среду разработки умеют настраивать на рефлексах большинство специалистов на рынке труда. А Docker больше знаком Devops'ам. Разработчиков придется обучать и ждать пока они пройдутся по всем граблям для набора опыта.
                                                                                                                • +1

                                                                                                                  Он станет ещё более удобен при росте команды. Конечно, при условии, что эти два-три человека понимают что делают, что без докера их бы допустили до написания скриптов деплоя на продакшен.


                                                                                                                  Но среду разработки умеют настраивать на рефлексах большинство специалистов на рынке труда.

                                                                                                                  Развернуть один монолитный проект на одной машине с рутовым доступом — да, каждый, практически может за часок-другой, а то и быстрее. А вот когда проект усложняется, да одновременно надо развернуть несколько, причём все на стандартных портах, да с разными версиями — уже дни могут тратиться.

                                                                                                    • 0
                                                                                                      ошибся веткой, del

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