- PVSM.RU - https://www.pvsm.ru -
Всем привет!
Ооочень хочется прям сразу приступить к теме, но правильнее будет немного рассказать про мою историю:
Я программист с опытом разработки frontend одностраничных приложений, scala/java и nodejs на сервере.
Довольно долго (уже точно пару — тройку лет), я придерживался мнения, что docker это манна небесная и вообще очень крутой инструмент и абсолютно каждый разработчик должен уметь пользоваться им. А отсюда вытекает, что и у каждого разработчика должен стоять docker на локальной машине. Да что там про моё мнение, вы полистайте вакансии, которые размещаются на том же hh. В каждой второй есть упоминание про docker и если вы им владеете — это будет вашим конкурентным преимуществом ;)
На своем пути я встечался с многими людьми, с их разным отношением к docker и к его экосистеме. Одни говорили, что это удобная вещь, гарантирующая кроссплатформенность. Вторые не понимали зачем им запускаться в контейнерах и какой профит от этого, третьим было вообще пофиг и они не парились (просто писали код и уходили домой — завидую, кстати, им :) )
Почему я использовал docker? Наверное по следующим причинам:
docker save
и через scp просто скинуть образ… Но это столько телодвижений. И к тому же выглядит "костыльным" решением, пока не появится свой репозиторийdocker-compose
. Он нужен только для запуска контейнеров. И все. Больше ничего он не может. Docker-compose
имеет кучу версий своих файлов, свой синтаксис. Каким декларативным он бы ни был, я не хочу читать их документацию. Мне она больше нигде не понадобится.docker-compose
файлы с базами данных и ничего не персистируют. При этом разработчики гордо заявляют, что docker крут, у них все работает локально и HR важно пишет в вакансии: "Мы используем docker и нам нужен кандидат с таким опытом работы"deprecated
? Если я монтирую директорию то мне нужно убедиться что uid и gid пользователя в контейнере соответствует id пользователя запустившего контейнер, иначе файлы созданные контейнером будут созданы с правами владельца root. Если использую volume
то данные просто буду созданы в каком нибудь /usr/*
и будет такая же история с uid и gid как в первом случае. Если запускаешь сторонний компонент то нужно вчитываться в документацию и искать ответ на вопрос: "а в какие директории контейнера компонент пишет файлы?"Мне всегда не нравилось, что приходится слишком долго возиться с docker-ом на начальном этапе: я придумывал как запускать контейнеры, из каких образов запускаться, делал Makefile, которые содержали алиасы к длинным docker командам. Терпеть не мог docker-compose, потому что не хотел учить еще один инструмент экосистемы docker. И docker-compose up
меня напрягала, особенно, если там еще встречались build
конструкции, а не уже собранные образы. Все, что я реально хотел — это просто делать продукт эффективно и быстро. Но я никак не мог разложить по полочкам использование docker.
Недавно (тройку месяцев назад), я поработал с DevOps командой, почти каждый участник которой, негативно относился к docker. По причинам:
На той же работе я и познакомился с еще одним инструментом — Ansible. Когда-то я слышал о нем, но не пробовал писать свои плейбуки. А теперь я начал писать свои таски и тут мое видение поменялось окончательно! Потому что я понял: у Ansible есть модули для запуска тех же docker контейнеров, сборок образов, сетей и пр., при этом контейнеры можно запустить не только локально, но и на удаленных серверах! Моему восторгу не было предела — я нашел НОРМАЛЬНЫЙ инструмент и выбросил свои Makefile и docker-compose файлы, они были заменены на yaml таски. Был уменьшен код за счет использования конструкций типа loop
, when
, etc.
Недавно я познакомился с ssh тунелями. Оказалось, что очень просто "пробросить" порт удаленного сервера на локальный порт. Удаленный сервер может быть как машиной в облаке, так и виртуальной машиной, запущенной в VirtualBox. Если мне или моему коллеге нужна бд (или какой нибудь другой сторонний компонент), можно просто запустить сервер с этим компонентом и загасить, когда сервер не нужен. Проброс портов дает такой же эффект, как и бд, запущенная в docker контейнере.
Эта команда пробрасывает мой локальный порт на удаленный сервер с postgresql:
ssh -L 9000:localhost:5432 user@example.com
Использование удаленного сервера решает проблему с разработкой в команде. Таким сервером могут пользоваться сразу несколько разработчиков, им не нужно уметь настраивать postgresql, разбираться c docker и с прочими изощрениями. На удаленном сервере можно установить ту же бд в самом docker, если поставить спецефичную версию трудно. Все что будет нужно разработчикам — это выдать ssh доступ!
Недавно прочитал что SSH тунели это ограниченая функиональность обычного VPN! Можно просто настоить OpenVPN или другие реализации VPN, настроить инфраструктуру и дать ее в пользование разработчикам. Это ведь так круто!
Благо, AWS, GoogleCloud и прочие, дают год бесплатного использования, так используйте их! Они копеечные, если их гасить, когда не используются. Я всегда задумывался, в каких целях мне бы понадобился удаленный сервер типа gcloud, кажется что я нашел их.
В качестве виртуальной машины на локали можно использовать тот же Alpine который активно используется в docker контейнерах. Ну или какие нибудь другие облегченные дистрибутивы чтобы побыстрее загружалась машина.
Итог: запускать бд и прочие инфрастуктурные плюшки можно и нужно на удаленных серверах или в virtualbox. мне не нужен docker для этих целей.
Я уже писал статью [1] в которой хотел донести, что использование docker образов не дает никакой гарантии. Docker образы нужны только для того чтобы создать docker контейнер. Если вы зашиваетесь на docker образ значит вы зашиваетесь на использование docker контейнеров и вы будете только с ними.
Вы видели где нибудь чтобы разработчики ПО портировали свои продукты только в docker образе?
Результат большинства продуктов это бинарные файлы под определенную платформу, именно их просто добавляют в docker образ который наследуется от нужной платформы. Вы не задумывались, почему в dockerhub так много похожих образов? Вбейте например nginx, вы увидите 100500 образов от разных людей. Эти люди не разрабатывали сам nginx, они просто в свой docker образ добавили официальный nginx и приправили своими конфигами для удобства запуска контейнеров.
Вообщем хранить можно просто в tgz, если кому то понадобится запускать это в docker то пусть в Dockerfile добавляют tgz, наследуются от нужного окружения и создают дополнительные плюшки которые не меняют самого приложения в tgz. Тот, кто будет создавать docker образ, будет знать, что это за tgz и что ему нужно для работы. Именно так я использую docker тут [2]
Итог: мне не нужен docker registry, воспользуюсь каким нибудь S3 или просто файловым хранилищем типа google drive/dropbox
Все компании, в которых я работал, похожи друг на друга. Они, как правило, продуктовые. То есть у них есть какое то одно приложение, один стек технологий (ну может пара — тройка языков программирования).
Эти компании используют docker на своих серверах где запускается CI процесс. Вопрос — зачем нужно собирать проекты в docker контейнере на своих серверах? Почему просто не подготовить окружение для сборки, например написать Ansible плейбук который будет ставить нужные версии nodejs, php, jdk, копировать ssh ключи и пр. на сервер, в котором будет происходить сборка?
Сейчас я понимаю, что это стрельба себе по ногам, потому что docker не приносит никакого профита со своей изоляцией. Проблемы с CI в docker с которыми я столкнулся:
Разработчики не собирают проекты в docker контейнерах ( я когда то был таким фанатом правда, жалко себя в прошлом xD ). В java есть возможность иметь несколько версий и менять одной командой на ту которая нужна сейчас. В nodejs тоже самое, есть nvm.
Я считаю что docker очень мощщный и гибкий инструмент, в этом его недостаток (звучит странно, да). С помощью него компании легко "подсаживаются" на него, используют где нужно и не нужно. Разработчики запускают свои контейнеры, какое то свое окружение, потом это все плавно перетекает в CI, продакшн. DevOps команда пишет какие то велосипеды чтобы запустить эти контейнеры.
Используйте docker только на самом последнем этапе в вашем рабочем процессе, не тащите его в проект в начале. Он не решит ваших бизнес проблем. Он только сдвинет проблемы на ДРУГОЙ уровень и будет предлагать свои варианты решения, вы будете делать двойную работу.
Когда docker нужен: пришел к мысли что docker очень хорош в оптимизации поставленного процесса но не в построении базового функционала
Если вы все-таки решили использовать docker, то:
PS:
Спасибо что дочитали, желаю вам прозрачных решений в ваших делах и продуктивных рабочих дней!
Автор: Alexander Kondaurov
Источник [5]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/programmirovanie/314599
Ссылки в тексте:
[1] статью: https://habr.com/ru/post/443136/
[2] тут: https://github.com/kondaurovDev/dockerfile
[3] packer: https://www.packer.io/
[4] тоже про docker, интересная статья: http://www.smashcompany.com/technology/docker-is-a-dangerous-gamble-which-we-will-regret
[5] Источник: https://habr.com/ru/post/445914/?utm_source=habrahabr&utm_medium=rss&utm_campaign=445914
Нажмите здесь для печати.