Щас у сеньер ямл девелоперов бомбанет))) как?? Как без докера? На Антона нашлют анафему и отлучат от контейнеров :) А если серьезно, современная тенденция пихать везде докер это ужасно, попахивает больше маркетингом, чем профессионализмом. Везде нужен трезвый подход и расчет. За частую девопс != Архитектор
Спасибо за видео. За балансеры и базы - поддерживаю. Остальное очень сугубо ситуативно и зависит от миллиона параметров таких как - организация докерфайла, СИ, дискового пространста. Докер прежде всего помогает разработчикам приложения, организации им окружения для разработки, тестирования и т.д.. что бы вне зависимости ни от чего, все могли использовать твой код с окружением вместе, а не перекидывать либы как файлы для установки. А там где ты его раскатаешь и какими средствами - это уже дело такое.
@@pavlenkoat Все верно. Мало того, его использование не только может быть архитектурно не оправдано, а может быть еще и опасно - в свете последних событий запуска контейнера из под рута по умолчанию ))
Не знаю какие нюансы есть в эксплуатации, тут админам реально виднее. Но, в разработке контейнеризация себя отлично показывает (со всеми зависимостями, конфигурациями, быстрым развёртыванием при расширении команды). А если кому сложно по неопытности - попробуйте laradock, им можно и попользоваться и подглядывать как там люди делают...).
@@pavlenkoat и без микросервисов он топ, как разработчику локально вести разработку ? СУБД нужна, веб сервер нужен, окружение что на продакшене что на локалке должно быть одно и тоже, ни куда от использования контейнеров не уйти. Поэтому да, всё пихаем в докер, докер даёт повторяемость. Докер не нужен если ты проверяешь идею, если не собираешься раскатывать на прод, то да, докер не нужен, если не собираешься совместно с кем то вести разработку, или тестирование, то да докер не нужен, когда в разработке приложения начинает принимать участи больше одного человека - это становиться поводом для контейнеризации, когда команда территориально распределена, я не знаю как без докера работать.
Я очень плотно использую докер во время разработки. И это очень удобно. Ты получаешь механизм, который может обеспечить повторяемость созданных тобой условий. Не важно, слетит ли у тебя ОС. Или поломаются зависимости. Или ты захочешь разрабатывать не в одно лицо. Всё становится намного проще, когда ты ВЕСЬ ПРОЕКТ, со всеми его сервисами можно запустить одной единственной командой. А что, если мне нужны разные версии разного софта, если проект не один? Все эти проблемы с потерей данных в контейнерах решаются через volumes (я даже хз, кто на полном серьёзе хранит такие данные в самом контейнере). Так же и вскод и продукты от JB умеют аттачиться в эти самые контейнеры и разрабатывать внутри них, не требуя устанавливать и захламлять свой дистр всяким инструментарием.
Еще есть ограничение когда приложение помещается на минимальной вдс, но на 86х по памяти помещается а вот на 64 уже впритык. Так что ансиблом удобнее и ... выгоднее в случае десятков-сотен таких инстансов)
8:41 - вот в этом моменте интересно, какие образы он использовал ? Можно взять базовый образ Ubuntu на 128МБайт, в Dockerfile через RUN установить Apache, за счёт чего образ ещё раздуется до (примерно) 248 МБайт, через COPY закинуть в образ ещё пару сотен мегабайт файлов для папки /var/www/html )) А потом назапускать штук так 100 таких контейнеров, и смотреть, в каких адских муках будет корячиться бедный Docker-сервер, если ему повезёт остаться в живых ))
Спасибо за видео, нам с посонами всё понравилось, мы кстати все выглядим как персонаж ваши скетчей - волосатые прогеры, нас 244ре человека Подскажите, пожалуйста, вот там на схеме вы меняете докер на 3 инстанса приложения на какой-то "Виртуальной машине". Что подразумевается под "Виртуальной машиной" в этом случае? И есть ли решения для скалабилити без докера, если к примеру вам не всегда надо 3 машины а только в пик нагрузки? В конце видео вы говорите, что "Все эти сайты - вынести на хост", речь о том что в рамках одной машины было куча докер контейнеров, а вы просто выносите их на апач который крутится на машине напрямую?
Докер не помогает, если нужна изоляция на уровне ядра. Например, если вы разрабатываете драйвер и вам нужно его протестировать. (формально, в докере это возможно, если использовать нестандартный runtime, являющийся виртуалкой, но это - отдельная тема)
У нас всегда какая-то часть системы остаётся в реальном режиме, и соответственно любые Кернел тесты и ТД.. это только виртуализация той области памяти где надо работать. Соответственно либо на живом железе, либо на виртуалке где полноценная бинарная трансляция и начинаем делить всю память по новому.
+1 лайк, но вот интересно, второй участник ролика, который программист, и отстаивает докер вообще может объяснить как он работает? Или он как тот пацак "говорит на языках, продолжения которых не знает"... Первый-то явно знает ;) Спасибо! Утро вроде началось хорошо... Может теперь и поработать удастся, плодотворно...
Ну в видео много пробелов в плане разных ситуаций есть, и большая часть примеров приведенных на тему того что не нужно заворачивать, при определенных событиях сменяются на полностью противоположные. Например когда на одном сервере нужно 2 и более СУБД разных версий поднять, или например когда надо запустить несколько jvm приложений при этом с разной версией java и с разными настройками окружения
@@SpiritVoodoo честно говоря, две разные jvm относительно легко разносятся через JAVA_PATH, это не аргумент конкретно для docker. А две разные нагруженные СУБД на одной машине - это больно, и побочные эффекты от их сожительства на одном ядре - сложно решать (там надо тюнить структуры в ядре под семафоры и shared memory), на отдельных VM - проще. А если не нагруженные - может там вообще СУБД была не нужна... И такая БД в эксплуатации должна быть на отдельном сервере где живут все слабонагруженные БД. В процессе разработки - да, очень удобно, чтобы показать как разработчик видит конфигурацию СУБД - да, но отвечает за долгосрочную ее эксплуатацию DBA, и хороший DBA не станет доверять мнению программиста. И даже архитектора, ибо это ему с этим жить долгие годы. Впрочем, не будем холиварить, у меня вообще вообще docker нет, у меня jail, и я не компетентен ;) возможно там все уже лучше, чем я думаю, просто я в это ещё not trust. Ах, не надо было мне лезть с комментариями - простите, увлекся, просто хотелось автора поддержать положительной обратной связью ;) Автору - Респект, все - я работать!
Про переборку контейнера с nginx при изменении конфига - не актуально. А как же volumes? Если запускаем в kubernetes, то для этих целей есть ConfigMap. В контейнеры не смысла пихать лишь тяжелые stateful приложения по типу высоконагруженных баз или всякие ceph кластера. Имхо
По мне если можно лучше не использовать лишьний слой абстракции. Это и усложняет поиск проблем и увеличивает контекст свичинг, потребления ресурсов и тп. На высокой нагрузке это проявляется очень хорошо, но да докер кубер и т.п. это удобно.
@@pavlenkoat если выбить у руководства лишнее ядро и пару гигов памяти - это сложно, то конечно лучше избавиться от лишнего слоя абстракции. Ну и если проект небольшой. А вот если проект большой и ресурсы позволяют, то со stateless приложениями Docker + Kubernetes это просто must have. Тут и удобное управление приложениями, автомасштабирование, zero downtime deployment (blue/green, rolling update, canary), service discovery, мониторинг и логирование почти из коробки, и много много других преимуществ если умеешь с этим работать :) Но, в любом случае, за контейнерными архитектурами будущее. Как в свое время был прорыв у виртуализации, так сейчас делает прорыв контейнеризация и оркестрация всего этого добра. Мы сейчас просто напросто имеем среду/платформу для получения удобного API к нашей инфраструктуре. Декларативное описание нашей инфры и наших приложений. Ну а без контейнеризации это реализовать сложно.
А как же оркестраторы и их преимущества в паре с докером? Не стоит пихать в докер вордпрес к примеру. Плохо когда в контейнере больше одного процесса. Некоторые умудряются стартовать в контейнере несколько приложений запущеных через какой то супервизор а то и баш скрипт. А есть уникумы пихающие в один контейнер приложение, апачь и мускул. 1 контейнер = 1 процес, всё. База в контейнерах тоже плохое решение и в первую очередь в плане производительности. По поводу балансировки в амазоне я бы заюзал ALB вместо Nginx на инстансе. Но вообще да. В некоторых случаях systemd будет лучшим решением нежели докер.
vps одна досталась. пару прогеров допиливали модуль для джумлы. клиент начал жаловаться - mysql падал. может раз в неделю может раз в сутки. ребутит впс и все работает (у него знаний было только на ребут). оказывается озу не хватало. а докер внутри контейнера киллил mysql. прикол в том что после выноса с докера базы, nginx - все стало работать как надо. с теми же ресурсами.
8:20, когда компания не доверяет сотруднику - валить надо оттуда. Странное решение - так тормозило то от чего? Выбирать докер или нет - зависит от типа проекта. У нас порядка 20 однотипных сайтов в контейнерах вполне себе крутятся в докерах, БД для каждого - свой контейнер, с примапленной папкой. Все живут на одной машине в swarm кластере (если понадобится php распараллелить, когда нагрузка вырастет), поэтому для каждого сервиса, настроено ограничение по памяти и cpu, чтобы какой-то дикий проект не смог утащить за собой всех из-за неправльного SQL запроса. Все деплоится через CI\CD, работает сносно, но нагрузки там не большие. Другое дело высоконагруженный проект и экосистема из разных сервисов. Вот там да - БД master-slave на отдельных машинах, 2 nginx балансера, тоже отдельно. Консул - отдельно, а вот микросервисы уже в контейнерах, причем это java микросервисы. И не раз спасало, когда одна из нод приказывала долго жить - swarm - переводил трафик на другой контейнер просто. Если инфраструктура продумана правильно, то и работать все будет без тормозов и спать станет легче. По поводу истерии, по мне так это просто удобный инструмент, на заре виртуалок все тоже сначала кричали - only bare metal. А так да, докер внутри виртуалок, разве что для разработки и стендов. У нас даже тестировщики научились локально стек разворачивать с актуальной БД и после тестирования пересоздавать контейнеры из образов.
Его и уволили... обидно досадно, на душе кошки скоибут, но он сам довел руководство. Да и я узнал что есть админ после подписания договора. Я ж в начале сказал докер это классно, но пихать его везде бездумно как минимум не профессионально. Я привел кейсы когда его не нужно пихать и почему. Да в любом случае вам это делать никто не запрещает.
@@pavlenkoat Сейчас другой тренд, везде пихают kubernetes, а он для прода имхо еще сыроват, ну и порог вхождения выше. У swarm вначале было много косяков, когда приходилось откатываться на старую версию, когда в новой был сломан функционал, который мы юзали, но сейчас он хотя бы "вылизан". Нам тут проект недавно передали, там хоть и bare metal, но кубер старый, который с новыми апи не совместим и надо заново конфиги перелопачивать. При собеседованиях везде практически, спрашивают - знаю ли я кубернетес. Такое ощущение, что все думают, как будто если перевести свой древний легаси проект на кубер, то все будет летать...
Кстати написать хороший код, это вообще такой длинный холивар с Статик линкед обджектами, динамическими линковками, и матерщина, когда по 8-9 дебиан все ок, а потом выходит новый дебиан, а маты потому что лдконфиг сошки не видит из за того что инсталлятор кривой... И вот таких матершинных историй, хватит на целую библиотеку... Так что сейчас в продакшн, как инструмент переносимости, контейнеры это оч удобно ))). А то вот один и тот же продукт из исходников если собирать, такие постоянно проблемы с зависимостями и ТД. Ужос. Так что все зависит от ситуации. Скоро все равно все будут бегать не с контейнерами, а с юникернел. А вообще сайды, от этих всех докеров, это самый контекст свитчинг. Так что это всегда либо удобно, либо быстро. Вечная проблема. Удобство-скорость
@@pavlenkoat А вот из за этого то и идёт большой делэй по io. Пусть даже в ос у нас, очень грамотная реализация всего ввода, вывода, но... Когда количество протокола в памяти больше и больше.. больше и больше.. и больше и ещё больше... Ну вот и посчитайте сколько раз надо в случае Кэш промахов, контроллеру памяти сделать выборку адреса, потом все это в регистры и так же на каждый поток... И вот в целом, чем больше у нас абстракций, тем больше вот таких операций... И какой бы быстрый процессор не был, и сколько ты там ядер не было.. но всему есть предел. И мы опять приходим к вечному вопросу: Нафиг это все, я руками знаю как быстро все пропатчить ))). Ну а если есть заказчик у которого есть админ который только как выкатить и запустить, остановить контейнера. А если там уже под куб все заточено и решать мелкие проблемы - это на аутсорсинге.. Иногда мне кажется что выбор диктует просто мода и какие-то веяния рынка, а не инженерные изыскания или требования к задаче. Но все равно технология то удобная, надо просто адекватно оценивать ситуацию.
Все это я знаю, но ролики делаю за день. Поэтому иногда не упомню.... Ролик и снят, чтобы показать, что новая модная удобная технология не всегда уместна
@@pavlenkoat Кстати!!! Топ идея для нового ролика, в Туду лист. Сейчас же хайп вокруг искусственного интеллекта.... Можно делать скетчи как люди верят, в то что конечный автомат (просто очень быстрый) будет сам писать новые алгоритмы для замены алгоритмов в самом себе... Ну то есть сейчас же люди уверены что скоро будет восстание машин, ии, он сам будет думать за людей (ну вот как конь, у него же голова большая), и вот это тоже топ прикол. Сейчас же люди верят что смарт Асистанты - это ии. Или что будет супер компьютер который будет править миром (ну то есть он как живой, супер умный и ТД).. тоже хороший стёб над хайповой темой. Обыватель же не знает что такое рекуррентные сети и вычислительная машина с конечным набором состояний. Ну и поэтому быстрые выборки, округления, сигнатурные сравнения и прочие задачи для нейронок, с комплексом которых сейчас много хайпа, люди же думают что это искусственный интеллект.. мне кажется очень весело можно снять )). Про восстание машин и ТД. Все хотят искусственный интеллект, не замечая что есть же иногда и настоящий, а он на мой взгляд лучше чем искусственный ;)).
Эээ авффтар... докер не добавляет ниразу уровня абстракции. В том его плюсоминус что приложение в докере работают на одном оровне абстракции что и приложения на хосте.
Как по мне докер вообще для боевого сайта не подходит. На windows подсистеме wsl2 + ubuntu установил докер и на нем запустил 1с-битрикс. Запросы к базе данных делаются долго как будто у меня 1 миллион товаров и не настроен кеш, не знаю как запросы к остальным серверам работают. Когда у меня битрикс стоит на чистом linux без docker,то запросы к базе с нормальной скоростью работают как и положено.
@@pavlenkoat Что за мода пошла,нет однозначных ответов. Вроде бы докер это плохо,но и в то же время хорошо для продакшена. Даже в книгах по высоконагруженным приложениям дают однозначные ответы.
@@pavlenkoat , я,понимаю,нужно же ответственность нести за однозначные ответы,а так как с гуся вода. Конекретных советов не было и предраться не к чему.
Мне задали вопрос где докер можно не использовать в видео я ответил. Но даже в этих моментах приложения можно завернуть в докер. Для упаковки и доставки кода удобная штука, но сейчас идёт тенденция что для многих молодых докер это как черная коробка и что в ней мы смотреть не будем и разбираться тоже.
все проходит, и мания на докер тоже пройдет. Верно, сейчас докер лепят надо и не надо. Проблема в квалифицированных айтишниках, а докер дает возможность сэкономить на них и унифицировать технологию.
Я так понимаю речь во втором примере про БД - без учета существования кубернетиса? Просто в таком случае же проще настроить отказоустойчивость и баллансировку нагрузки в целом. Или для отказоустойчивости мобирать кластер из виртуалок (просто для БД целый сервак - жирно, как по мне) - а потом делать делать... да я хз что делать. Бессмысленно. В моем представлении кубернетис - экономия ресурсов. По классике можно гнать данные с БД по фтп на файловую помойку с рейдом 10 - а СУБД пустить в общую пачку с другими приложениями на кластер в виде контейнера.
к сожалению актуальное видео. Недавно я пытался объяснить одному чудаку что docker это система виртуализации и не надо запускать через docker-compose микросервисы которые ты тестируешь/разрабатываешь.
Вы не правы контейнер это изоляция на уровне ядра. Посмотрите виде на каких столпах стоит докер. Там я рассказываю В чем отличие и как это стало возможно
@@pavlenkoat "Виртуализа́ция - предоставление набора вычислительных ресурсов или их логического объединения, абстрагированное от аппаратной реализации, и обеспечивающее при этом логическую изоляцию друг от друга вычислительных процессов, выполняемых на одном физическом ресурсе." (Википедия). Разве docker этим не занимается?
@@ПуляевГригорий Я рассказывал в чем отличие в ролики "На каких столпах стоих Docker". Если вкратце: контейнеры изолируют на уровне ядра, а виртуализация на аппаратном уровне, т.е. полностью эмулирует железо.
Спасибо наконец то правильный взгляд насчет докер. Мне этот докер не сдалось вообще не вижу смысла ставить докер в linux если сам ОС является средой для всего, что нужно. Это тоже самое, что взять рыб в океане и в самом океане сделать аквариум и поместить их туда, согласитесь глупость. Другое дело если аквариум в офис ну или там где не могут жить рыбы как пример Windows.
@@pavlenkoat да, людям серьезным уже любым способом не донесешь если они постарели (ну состояние когда надо корчить умников, т.е. мозг закрывается от принятие нового) и еще этого не знают) а стажерам заходит наура - спасибо!)
![เจ็บที่ยังฮัก - ม่อน วรวิทย์ [ Official Mv ] จอนนี่มิวสิค](http://i.ytimg.com/vi/KALIGSRSjFs/mqdefault.jpg)
Интересно :)
Сначала я скептически относился к вашему каналу, но сейчас видео нравятся. Спасибо!
И вам спасибо что смотрите.
- надо бы mysql развернуть... где бы это можно было делать...
- в докере, сейчас всё модно разворачивать в докере...
(с) с Баша
Я выбираю докер!
Спасибо за видео:)почему-то Вы у меня ассоциируетесь с "сумасшедшим учёным" в хорошем смысле этого слова.
Кто вы? Он тут один!
@@АлексейПрищепа-ы9щ, прошу прощения, что смутил))огрехи моего воспитания - привык к людям, с кем не знаком близко, обращаться на Вы.
Самое сложное приложение, которое я разрабатывал - это калькулятор на делфи. Не думаю что ему нужен докер)))
Щас у сеньер ямл девелоперов бомбанет))) как?? Как без докера? На Антона нашлют анафему и отлучат от контейнеров :) А если серьезно, современная тенденция пихать везде докер это ужасно, попахивает больше маркетингом, чем профессионализмом. Везде нужен трезвый подход и расчет. За частую девопс != Архитектор
Уже бомбят в личку))))
Согласен, хочу подметить насчет маркетинга я точно не сомневаюсь, а ваш комментарий еще больше подтвердил мои мысли.
Антох, все круто!) Мне нравится, что и юморные видео и информативные одновременно)
Спасибо
Думаю что во многих ситуациях использование джокера просто нецелесообразно.
Спасибо за видео. За балансеры и базы - поддерживаю.
Остальное очень сугубо ситуативно и зависит от миллиона параметров таких как - организация докерфайла, СИ, дискового пространста.
Докер прежде всего помогает разработчикам приложения, организации им окружения для разработки, тестирования и т.д.. что бы вне зависимости ни от чего, все могли использовать твой код с окружением вместе, а не перекидывать либы как файлы для установки.
А там где ты его раскатаешь и какими средствами - это уже дело такое.
Для тестовых сред и микросервисов он идеален. Я не Хейтер докера. Я против его использования где не надо
@@pavlenkoat Все верно. Мало того, его использование не только может быть архитектурно не оправдано, а может быть еще и опасно - в свете последних событий запуска контейнера из под рута по умолчанию ))
Не знаю какие нюансы есть в эксплуатации, тут админам реально виднее. Но, в разработке контейнеризация себя отлично показывает (со всеми зависимостями, конфигурациями, быстрым развёртыванием при расширении команды).
А если кому сложно по неопытности - попробуйте laradock, им можно и попользоваться и подглядывать как там люди делают...).
Да и в эксплуатации в микросервисной архитектуре он топ. Просто сейчас его везде пихают
@@pavlenkoat и без микросервисов он топ, как разработчику локально вести разработку ? СУБД нужна, веб сервер нужен, окружение что на продакшене что на локалке должно быть одно и тоже, ни куда от использования контейнеров не уйти. Поэтому да, всё пихаем в докер, докер даёт повторяемость.
Докер не нужен если ты проверяешь идею, если не собираешься раскатывать на прод, то да, докер не нужен, если не собираешься совместно с кем то вести разработку, или тестирование, то да докер не нужен, когда в разработке приложения начинает принимать участи больше одного человека - это становиться поводом для контейнеризации, когда команда территориально распределена, я не знаю как без докера работать.
@@SbWereWolf Ansible прекрасно умеет настраивать любые окружения в 2 клика.
Отлично! ППКС. Ждем видео про священный Кубернетес, без которого, как известно, жизни нет ;)
Я с ним очень мало работаю. К сожалению
Спасибо! Отличное видео. Хотелось бы подробнее узнать о том что делалось в плане "подтюнить сервер и сайты залетали".
Люблю видео про здравый смысл. Правда иногда не сразу понятно когда серьезно, а когда сарказм)
Ну я толстотролил
Антон. Спасибо что сделал видео про докер. Про кровавый энтерпрайс классную подсветку сделал. Лайк однозначно.
Так он такой и есть. И вам спасибо
Я очень плотно использую докер во время разработки. И это очень удобно.
Ты получаешь механизм, который может обеспечить повторяемость созданных тобой условий. Не важно, слетит ли у тебя ОС. Или поломаются зависимости. Или ты захочешь разрабатывать не в одно лицо. Всё становится намного проще, когда ты ВЕСЬ ПРОЕКТ, со всеми его сервисами можно запустить одной единственной командой.
А что, если мне нужны разные версии разного софта, если проект не один?
Все эти проблемы с потерей данных в контейнерах решаются через volumes (я даже хз, кто на полном серьёзе хранит такие данные в самом контейнере).
Так же и вскод и продукты от JB умеют аттачиться в эти самые контейнеры и разрабатывать внутри них, не требуя устанавливать и захламлять свой дистр всяким инструментарием.
"При съемке видеоролика ни один компот не пострадал!"
Одну банку выпил))))
Еще есть ограничение когда приложение помещается на минимальной вдс, но на 86х по памяти помещается а вот на 64 уже впритык. Так что ансиблом удобнее и ... выгоднее в случае десятков-сотен таких инстансов)
Антон, спасибо за контент. И за улучшившийся звук + картинку тоже.
Это спасибо тем кто донатит и спонсирует видео.
Спасибо за видео. Хорошие примеры и на злобу дня)
С вам спасибо
Лучший остросюжетный видос января 2020))
Спасибо
Антон! Про настройку CORS, Access-Control-Allow-Origin на сервере, когда видео будет=)?
Будет время сделаю. Не хочется цитировать вики
Спасибо большое. Очень познавательно, а гшавное доходчиво.
И вам спасибо
Я Антон Павленко и в этой ситуации может помочь Докер)))
Я тут тоже выпал
как всегда на высоте
много полезной информации
Спасибо
8:41 - вот в этом моменте интересно, какие образы он использовал ? Можно взять базовый образ Ubuntu на 128МБайт, в Dockerfile через RUN установить Apache, за счёт чего образ ещё раздуется до (примерно) 248 МБайт, через COPY закинуть в образ ещё пару сотен мегабайт файлов для папки /var/www/html )) А потом назапускать штук так 100 таких контейнеров, и смотреть, в каких адских муках будет корячиться бедный Docker-сервер, если ему повезёт остаться в живых ))
Не помню. Уже полтора года прошло.
Спасибо за видео, нам с посонами всё понравилось, мы кстати все выглядим как персонаж ваши скетчей - волосатые прогеры, нас 244ре человека
Подскажите, пожалуйста, вот там на схеме вы меняете докер на 3 инстанса приложения на какой-то "Виртуальной машине".
Что подразумевается под "Виртуальной машиной" в этом случае?
И есть ли решения для скалабилити без докера, если к примеру вам не всегда надо 3 машины а только в пик нагрузки?
В конце видео вы говорите, что "Все эти сайты - вынести на хост", речь о том что в рамках одной машины было куча докер контейнеров, а вы просто выносите их на апач который крутится на машине напрямую?
Есть api у облачных провайдеров. Амазона digital ocean, яндек слауд и тд. Через них можно создавать доп виртуалки или на лету управлять ресурсами
Шикарный материал!
Докер не помогает, если нужна изоляция на уровне ядра.
Например, если вы разрабатываете драйвер и вам нужно его протестировать.
(формально, в докере это возможно, если использовать нестандартный runtime, являющийся виртуалкой, но это - отдельная тема)
Да и это тоже)))
У нас всегда какая-то часть системы остаётся в реальном режиме, и соответственно любые Кернел тесты и ТД.. это только виртуализация той области памяти где надо работать. Соответственно либо на живом железе, либо на виртуалке где полноценная бинарная трансляция и начинаем делить всю память по новому.
но собирать модули ядра и драйверы в докере не составляет труда.
+1 лайк, но вот интересно, второй участник ролика, который программист, и отстаивает докер вообще может объяснить как он работает? Или он как тот пацак "говорит на языках, продолжения которых не знает"... Первый-то явно знает ;)
Спасибо! Утро вроде началось хорошо... Может теперь и поработать удастся, плодотворно...
Зачем? Ему просто удобно.
Ну в видео много пробелов в плане разных ситуаций есть, и большая часть примеров приведенных на тему того что не нужно заворачивать, при определенных событиях сменяются на полностью противоположные.
Например когда на одном сервере нужно 2 и более СУБД разных версий поднять, или например когда надо запустить несколько jvm приложений при этом с разной версией java и с разными настройками окружения
@@SpiritVoodoo честно говоря, две разные jvm относительно легко разносятся через JAVA_PATH, это не аргумент конкретно для docker.
А две разные нагруженные СУБД на одной машине - это больно, и побочные эффекты от их сожительства на одном ядре - сложно решать (там надо тюнить структуры в ядре под семафоры и shared memory), на отдельных VM - проще. А если не нагруженные - может там вообще СУБД была не нужна... И такая БД в эксплуатации должна быть на отдельном сервере где живут все слабонагруженные БД.
В процессе разработки - да, очень удобно, чтобы показать как разработчик видит конфигурацию СУБД - да, но отвечает за долгосрочную ее эксплуатацию DBA, и хороший DBA не станет доверять мнению программиста. И даже архитектора, ибо это ему с этим жить долгие годы.
Впрочем, не будем холиварить, у меня вообще вообще docker нет, у меня jail, и я не компетентен ;) возможно там все уже лучше, чем я думаю, просто я в это ещё not trust.
Ах, не надо было мне лезть с комментариями - простите, увлекся, просто хотелось автора поддержать положительной обратной связью ;) Автору - Респект, все - я работать!
Про переборку контейнера с nginx при изменении конфига - не актуально. А как же volumes?
Если запускаем в kubernetes, то для этих целей есть ConfigMap.
В контейнеры не смысла пихать лишь тяжелые stateful приложения по типу высоконагруженных баз или всякие ceph кластера. Имхо
По мне если можно лучше не использовать лишьний слой абстракции. Это и усложняет поиск проблем и увеличивает контекст свичинг, потребления ресурсов и тп. На высокой нагрузке это проявляется очень хорошо, но да докер кубер и т.п. это удобно.
@@pavlenkoat если выбить у руководства лишнее ядро и пару гигов памяти - это сложно, то конечно лучше избавиться от лишнего слоя абстракции. Ну и если проект небольшой.
А вот если проект большой и ресурсы позволяют, то со stateless приложениями Docker + Kubernetes это просто must have. Тут и удобное управление приложениями, автомасштабирование, zero downtime deployment (blue/green, rolling update, canary), service discovery, мониторинг и логирование почти из коробки, и много много других преимуществ если умеешь с этим работать :) Но, в любом случае, за контейнерными архитектурами будущее. Как в свое время был прорыв у виртуализации, так сейчас делает прорыв контейнеризация и оркестрация всего этого добра. Мы сейчас просто напросто имеем среду/платформу для получения удобного API к нашей инфраструктуре. Декларативное описание нашей инфры и наших приложений.
Ну а без контейнеризации это реализовать сложно.
@@miky7miky я ж писал в микросервисной архитектуре, да это удобно. В остальных случаях в большенстве своем это избыточно.
@@pavlenkoat так микросервисная архитектура - основной тип архитектуры в современной и уважающей себя IT (а уже и не только IT) компании.
@@miky7miky Видимо вы недавно на этом пути. И микросервисная архитектура даже не у 50% процентов продуктов.
А как же оркестраторы и их преимущества в паре с докером? Не стоит пихать в докер вордпрес к примеру. Плохо когда в контейнере больше одного процесса. Некоторые умудряются стартовать в контейнере несколько приложений запущеных через какой то супервизор а то и баш скрипт. А есть уникумы пихающие в один контейнер приложение, апачь и мускул. 1 контейнер = 1 процес, всё. База в контейнерах тоже плохое решение и в первую очередь в плане производительности. По поводу балансировки в амазоне я бы заюзал ALB вместо Nginx на инстансе. Но вообще да. В некоторых случаях systemd будет лучшим решением нежели докер.
Каждому решению свое предназначения. Аркестрация хороша для микросервисов, но для тяжеленного приложения будет ей не очень.
@@pavlenkoat Ну как бы да но от монолитов сейчас стараются наоборот уйти.
@@vitalii5473 Но не везде это экономически выгодно.
Молодчина за видео. Я юзаю vm. Докеры не юзаю так как работаю с базами данных.
Нет жизни без Kubernetes :)
Докер весьма проблематичен с точки зрения безопасности.
Suid root без сброса привелегий, крайне не хорошая идея.
Бля, дайте ему уже оскар
Это похвала или желания чтобы я ушел с радара?
похвала
@@fodezargames спасибо
Полностью с тобой согласен. )
Мощное видео, жалко что мало лайков
Спасибо за ролик. И вправду везде популяризируют кубернетикс докер. Неужели это такая халява и ничего взамен
vps одна досталась.
пару прогеров допиливали модуль для джумлы. клиент начал жаловаться - mysql падал. может раз в неделю может раз в сутки. ребутит впс и все работает (у него знаний было только на ребут). оказывается озу не хватало. а докер внутри контейнера киллил mysql. прикол в том что после выноса с докера базы, nginx - все стало работать как надо. с теми же ресурсами.
Базу в докер надо класть аккуратно.
Не ну это уже троллинг)
Сатира
хороший натуральный макияж, чуть-чуть не под цвет рубашки, но как так можно не высыпаться и при том иметь довольно складную речь? загадка
Есть один секрет. Делать много дублей)))
Спасибо отличное видео.
8:20, когда компания не доверяет сотруднику - валить надо оттуда.
Странное решение - так тормозило то от чего? Выбирать докер или нет - зависит от типа проекта. У нас порядка 20 однотипных сайтов в контейнерах вполне себе крутятся в докерах, БД для каждого - свой контейнер, с примапленной папкой. Все живут на одной машине в swarm кластере (если понадобится php распараллелить, когда нагрузка вырастет), поэтому для каждого сервиса, настроено ограничение по памяти и cpu, чтобы какой-то дикий проект не смог утащить за собой всех из-за неправльного SQL запроса. Все деплоится через CI\CD, работает сносно, но нагрузки там не большие.
Другое дело высоконагруженный проект и экосистема из разных сервисов. Вот там да - БД master-slave на отдельных машинах, 2 nginx балансера, тоже отдельно. Консул - отдельно, а вот микросервисы уже в контейнерах, причем это java микросервисы. И не раз спасало, когда одна из нод приказывала долго жить - swarm - переводил трафик на другой контейнер просто. Если инфраструктура продумана правильно, то и работать все будет без тормозов и спать станет легче.
По поводу истерии, по мне так это просто удобный инструмент, на заре виртуалок все тоже сначала кричали - only bare metal. А так да, докер внутри виртуалок, разве что для разработки и стендов. У нас даже тестировщики научились локально стек разворачивать с актуальной БД и после тестирования пересоздавать контейнеры из образов.
Его и уволили... обидно досадно, на душе кошки скоибут, но он сам довел руководство. Да и я узнал что есть админ после подписания договора.
Я ж в начале сказал докер это классно, но пихать его везде бездумно как минимум не профессионально. Я привел кейсы когда его не нужно пихать и почему. Да в любом случае вам это делать никто не запрещает.
@@pavlenkoat Сейчас другой тренд, везде пихают kubernetes, а он для прода имхо еще сыроват, ну и порог вхождения выше. У swarm вначале было много косяков, когда приходилось откатываться на старую версию, когда в новой был сломан функционал, который мы юзали, но сейчас он хотя бы "вылизан". Нам тут проект недавно передали, там хоть и bare metal, но кубер старый, который с новыми апи не совместим и надо заново конфиги перелопачивать. При собеседованиях везде практически, спрашивают - знаю ли я кубернетес. Такое ощущение, что все думают, как будто если перевести свой древний легаси проект на кубер, то все будет летать...
Это просто тренд. Об этом надо тоже снимать
@@koi-157c8 k8s под прод давно не сыроват.
@@NikitaGorlov есть личный опыт?
Кстати написать хороший код, это вообще такой длинный холивар с Статик линкед обджектами, динамическими линковками, и матерщина, когда по 8-9 дебиан все ок, а потом выходит новый дебиан, а маты потому что лдконфиг сошки не видит из за того что инсталлятор кривой... И вот таких матершинных историй, хватит на целую библиотеку...
Так что сейчас в продакшн, как инструмент переносимости, контейнеры это оч удобно ))).
А то вот один и тот же продукт из исходников если собирать, такие постоянно проблемы с зависимостями и ТД. Ужос. Так что все зависит от ситуации.
Скоро все равно все будут бегать не с контейнерами, а с юникернел.
А вообще сайды, от этих всех докеров, это самый контекст свитчинг. Так что это всегда либо удобно, либо быстро. Вечная проблема. Удобство-скорость
Ой, про контекст свичинг я и забыл.
@@pavlenkoat
А вот из за этого то и идёт большой делэй по io. Пусть даже в ос у нас, очень грамотная реализация всего ввода, вывода, но... Когда количество протокола в памяти больше и больше.. больше и больше.. и больше и ещё больше... Ну вот и посчитайте сколько раз надо в случае Кэш промахов, контроллеру памяти сделать выборку адреса, потом все это в регистры и так же на каждый поток... И вот в целом, чем больше у нас абстракций, тем больше вот таких операций... И какой бы быстрый процессор не был, и сколько ты там ядер не было.. но всему есть предел.
И мы опять приходим к вечному вопросу:
Нафиг это все, я руками знаю как быстро все пропатчить ))).
Ну а если есть заказчик у которого есть админ который только как выкатить и запустить, остановить контейнера. А если там уже под куб все заточено и решать мелкие проблемы - это на аутсорсинге..
Иногда мне кажется что выбор диктует просто мода и какие-то веяния рынка, а не инженерные изыскания или требования к задаче.
Но все равно технология то удобная, надо просто адекватно оценивать ситуацию.
Все это я знаю, но ролики делаю за день. Поэтому иногда не упомню....
Ролик и снят, чтобы показать, что новая модная удобная технология не всегда уместна
@@pavlenkoat
Засекайте годик другой, будет хайп вокруг юникернел.
@@pavlenkoat
Кстати!!! Топ идея для нового ролика, в Туду лист. Сейчас же хайп вокруг искусственного интеллекта.... Можно делать скетчи как люди верят, в то что конечный автомат (просто очень быстрый) будет сам писать новые алгоритмы для замены алгоритмов в самом себе... Ну то есть сейчас же люди уверены что скоро будет восстание машин, ии, он сам будет думать за людей (ну вот как конь, у него же голова большая), и вот это тоже топ прикол. Сейчас же люди верят что смарт Асистанты - это ии. Или что будет супер компьютер который будет править миром (ну то есть он как живой, супер умный и ТД).. тоже хороший стёб над хайповой темой.
Обыватель же не знает что такое рекуррентные сети и вычислительная машина с конечным набором состояний. Ну и поэтому быстрые выборки, округления, сигнатурные сравнения и прочие задачи для нейронок, с комплексом которых сейчас много хайпа, люди же думают что это искусственный интеллект.. мне кажется очень весело можно снять )). Про восстание машин и ТД.
Все хотят искусственный интеллект, не замечая что есть же иногда и настоящий, а он на мой взгляд лучше чем искусственный ;)).
А где линуксовые идолы на системнике!? Отрёкся и перестал на них молиться? (В каких случаях докер все-таки нужен)
Просто убрал лишнее из кадра
Эээ авффтар... докер не добавляет ниразу уровня абстракции. В том его плюсоминус что приложение в докере работают на одном оровне абстракции что и приложения на хосте.
пора уже про докер кино снимать
Да вот снял пару роликов они как-то не зашли.
Как по мне докер вообще для боевого сайта не подходит. На windows подсистеме wsl2 + ubuntu установил докер и на нем запустил 1с-битрикс. Запросы к базе данных делаются долго как будто у меня 1 миллион товаров и не настроен кеш, не знаю как запросы к остальным серверам работают. Когда у меня битрикс стоит на чистом linux без docker,то запросы к базе с нормальной скоростью работают как и положено.
На нем куча высоконагруженных серверов работает. Видимо не правильно настроили. Да и докер под виндой такое себе.
@@pavlenkoat Что за мода пошла,нет однозначных ответов. Вроде бы докер это плохо,но и в то же время хорошо для продакшена. Даже в книгах по высоконагруженным приложениям дают однозначные ответы.
@@pavlenkoat , я,понимаю,нужно же ответственность нести за однозначные ответы,а так как с гуся вода. Конекретных советов не было и предраться не к чему.
Мне задали вопрос где докер можно не использовать в видео я ответил. Но даже в этих моментах приложения можно завернуть в докер.
Для упаковки и доставки кода удобная штука, но сейчас идёт тенденция что для многих молодых докер это как черная коробка и что в ней мы смотреть не будем и разбираться тоже.
Всегда "любил" такую буффонаду ) смешно и глупо. Как всегда ) а основная претензия - вода на воде и водой погоняет )
вместо Docker юзай Pod в Kubernetes
класс!
все проходит, и мания на докер тоже пройдет. Верно, сейчас докер лепят надо и не надо. Проблема в квалифицированных айтишниках, а докер дает возможность сэкономить на них и унифицировать технологию.
Посмотрим.
Так вы определитесь: это веяние моды или докер даёт бизнесу ощутимые преимущества?)
ахах. кроваво.... кроваво.. кроваво-интерепрайзное решение)))
Рад что понравилось.
Вижу что в Digital боль не уходит...
Все стабильно))))
Я так и не понял
Какже похож на Михаила Сидорычева!
Хм. На атлета?
Да. Внешне. Просто ты умный а он тупой
Вы похожи на Егор Григорьевич Крутоголов
Это хто?
@@pavlenkoat ru.wikipedia.org/wiki/%D0%9A%D1%80%D1%83%D1%82%D0%BE%D0%B3%D0%BE%D0%BB%D0%BE%D0%B2,_%D0%95%D0%B3%D0%BE%D1%80_%D0%93%D1%80%D0%B8%D0%B3%D0%BE%D1%80%D1%8C%D0%B5%D0%B2%D0%B8%D1%87
@@cyborg6294 Спасибо. Не вспомнил :-)
@@pavlenkoat Пожалуйста
Я так понимаю речь во втором примере про БД - без учета существования кубернетиса? Просто в таком случае же проще настроить отказоустойчивость и баллансировку нагрузки в целом. Или для отказоустойчивости мобирать кластер из виртуалок (просто для БД целый сервак - жирно, как по мне) - а потом делать делать... да я хз что делать. Бессмысленно. В моем представлении кубернетис - экономия ресурсов. По классике можно гнать данные с БД по фтп на файловую помойку с рейдом 10 - а СУБД пустить в общую пачку с другими приложениями на кластер в виде контейнера.
к сожалению актуальное видео. Недавно я пытался объяснить одному чудаку что docker это система виртуализации и не надо запускать через docker-compose микросервисы которые ты тестируешь/разрабатываешь.
Вы не правы контейнер это изоляция на уровне ядра. Посмотрите виде на каких столпах стоит докер. Там я рассказываю В чем отличие и как это стало возможно
@@pavlenkoat Ну и в чём я не прав?
@@ПуляевГригорий В этом: "docker это система виртуализации "
@@pavlenkoat "Виртуализа́ция - предоставление набора вычислительных ресурсов или их логического объединения, абстрагированное от аппаратной реализации, и обеспечивающее при этом логическую изоляцию друг от друга вычислительных процессов, выполняемых на одном физическом ресурсе." (Википедия). Разве docker этим не занимается?
@@ПуляевГригорий Я рассказывал в чем отличие в ролики "На каких столпах стоих Docker". Если вкратце: контейнеры изолируют на уровне ядра, а виртуализация на аппаратном уровне, т.е. полностью эмулирует железо.
Спасибо наконец то правильный взгляд насчет докер. Мне этот докер не сдалось вообще не вижу смысла ставить докер в linux если сам ОС является средой для всего, что нужно. Это тоже самое, что взять рыб в океане и в самом океане сделать аквариум и поместить их туда, согласитесь глупость. Другое дело если аквариум в офис ну или там где не могут жить рыбы как пример Windows.
Докер хороший инструмент. Но не всегда он нужен. Но сейчас он везде.
Денег нет
Держитесь там))))
ЭнжинИкс, а не Ингинкс, Карл! Кровь из ушей.
Какой вы нежный. Это когда-то в одной компании так называли все не могу отучится.
Nginx читается как "энжиникс"
Он абсолютно не нужен... Решает только тепроблемы котопые сами создали прякриворукие разработчики.. Реальные Проблемы совместимости он решить не может
Антон, прекрати кривляться. Инфа у тебя полезная и годная, но почему бы как-то более непринужденно не рассказать? нам же тут не по 9 лет
Наверно, потому что я художник, я так вижу. Да и обучения стажёров показывает, что так понятнее обычно и хорошо усваивается инфа.
Как раз такое кривляние и показывает современный девопс 😂
@@pavlenkoat да, людям серьезным уже любым способом не донесешь если они постарели (ну состояние когда надо корчить умников, т.е. мозг закрывается от принятие нового) и еще этого не знают) а стажерам заходит наура - спасибо!)
@@vasya_pipkin Согласен :)
Так это же фишка канала... Мне как бы инфа про докер не так интересна, как на Антона посмотреть
Из-за кривляний, информация хуже воспринимается. ИМХО
Сочувствую
@@pavlenkoat Нее бро, ты не думай что хейтю. Это чисто фидбэк. А там сам уже думай как лучше контент делать. А так ,удачи каналу. Надеюсь разовьется
Я не думаю. Просто таких как ты мало)))