Ключевые аспекты хорошего Dockerfile

— Порядок команд важен. Вверху редко меняющиеся сущности (ставим зависимости apt-get, pip), внизу – часто меняющиеся (копируем ваш код)
— Слои нарастают и не удаляются. Если слой генерирует «мусор» – удалять нужно в этом же слое, иначе место не уменьшится
— Пользуемся готовыми образами на dockerhub

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

И помните – если docker вам мешает, скорее всего, вы что-то делаете неправильно.
#skills #sudo #devfm

Online resources to learn how to code

Основной источник знаний — это техническая документация. В целом, man — всему голова. Отсюда возникает необходимость в английском языке, как интернациональном языке разработчиков. Это как латынь у медиков — в IT без английского никуда. По крайней мере, пока нас не поработят китайцы.

А ваш проект должен содержать подробное readme.

#sudo

Databases среди Professional Developers. Всегда переключаем на Professional Developers, потому что лучшее надо смотреть у лучших. Те, кто Learning to Code, вам подсказать не смогут

Неплохо бы знать парочку баз данных отсюда. Имеет смысл изучить реляционную (например, PostgreSQL) и документную (например, MongoDB) базы.

Во всех опросах можно было выбирать несколько галочек, так что сумма больше 100%

#sudo

Other tools среди Professional Developers

Варианты, мягко говоря, странные. Менеджеры пакетов npm, yarn, homebrew я бы исключил (это что-то уровня IDE), как и платформы для игр Unity, Unreal Engine (они должны идти в frameworks).

Среди оставшегося доминирует контейнерная виртуализация Docker и система управления контейнерами Kubernetes. Без докера никуда, господа.

#sudo

Version control systems среди Professional Developers

Git 97%, SVN 6%. Варианты "без системы контроля версий" и mercurial менее 3% в сумме.

Не умеешь в Git? Ты не разработчик

#sudo

Когда код не работает, то понять проблему помогут следующие способы:
1. Метод пристального взгляда. Полезное упражнение для мозга – попытаться в голове построчно воспроизвести код и состояния всех переменных
2. Отладка. Воспользоваться IDE или сторонними инструментами для пошагового запуска с контролем выбранных переменных. Этот способ следует освоить, пользоваться горячими клавишами и точками останова. Незаменим при разборе чужого кода или сложных структур данных
3. Юнит-тесты. Вместе с кодом важно писать изолированные тесты, покрывающие ту функцию, над которой вы сейчас работаете. Выгодное отличие от отладки – накопительный эффект. Чем больше уже написано тестов, тем меньше область поиска ошибки
4. Отладочные принты. Выводить нужные переменные. Детский способ вникания в код. Почему детский? Есть альтернатива лучше по всем параметрам
5. Логгирование. Это отладочная печать на стероидах. Можно сконфигурировать выводимое сообщение (добавить время и дату, добавить название вызываемого модуля и функции и многое другое). Можно настроить уровень предупреждений. В info писать важное (например, изменение состояния в базе данных), в error писать ошибки, а в debug – нужное для отладки. Прелесть в том, что debug убирать не придётся. В конфиге настраиваем писать только info и выше, и в результате debug выполняться не будут. Удобно
Про логгирование недавно был пост в канале по питону

Наилучшим сочетанием я считаю 3, 5, 1 – именно в таком порядке. Всегда писать тесты, часто использовать логгирование и использовать мозг

#sudo #procode #devfm

Одним из вариантов безопасной пересылки данных является передача зашифрованного rar/zip архива с паролем. В rar есть удобная галочка "шифровать имена файлов", когда названия файлов внутри архива не показываются. Но rar формат проприетарный, что плохо с точки зрения криптографии и является дурным тоном. Берём zip.

О пароле можно договориться заранее. Если пересылка регулярная, на помощь может прийти одноразовый блокнот. Менее безопасным является пересылка архива по одному каналу связи (мессенджер), а пароля – по другому (СМС, почта, другой мессенджер).

Надёжный пароль состоит не менее, чем из 20 символов. Отличный пароль – набор из 4+ английских слов. Изменение регистра и спецсимволы приветствуются. Примеры хороших паролей:

HowAwesomeHumanBrain
ComputerGamesAreNotBad
Many%Coders%Can%Code%Windows

Такие пароли легко запомнить и сложно перебрать (и bruteforce, и перебор по словарю за разумное время не производится).

PS: Идеальным будет пароль вроде JVoZlEoHk~?rsnJFCZ1pJ%IEp, но его невозможно запомнить и тяжело набирать. Тут могут помочь менеджеры паролей, но это другая тема.

#sudo #skills #devfm

Как сформировать надёжный мастер-пароль для менеджера паролей, о которых мы писали ранее? Самым простым, при этом самым неломаемым вариантом будет кусок стихотворения со всей пунктуацией.

Я вас любил: любовь ещё, быть может,

Это почти идеальный пароль. Можно ещё добавить спецсимволов вместо пробелов или ещё как-то усложнить текст одному вам понятным образом.

PS: Не используйте свои любимые цитаты. Выбранный фрагмент должен иметь нулевую связь с вами, как личностью.
#skills #sudo #devfm

Год назад на хабре вышла занятная статья Письмо преподавателям вузов. Хватит губить будущее ИТ. В ней модератор хабра поднимает следующую проблему. Кто-то из преподавателей сделал автомат за зачёт при публикации на хабре, которая набрала +4 рейтинга. В результате на хабр набежала толпа студентов с материалами разного уровня, в том числе со слёзными просьбами пропустить статью из песочницы.

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

Хотите я расскажу, что из вуза реально нужно в работе?

— Умение работать с литературой, источниками и технической документацией, отличать фуфло от профессиональных материалов, уметь определять актуальность и совместимость информации с реальной рабочей задачей.
— Знание фундаментальных основ специальности и специализации. В ИТ знания нужно обновлять быстро и непрерывно, поэтому важно иметь хорошую основу, на которую будет ложиться актуальная теория и практика.
— Умение анализировать, синтезировать, декомпозировать идеи и задачи, выделять главное.
— Способность представить свой труд — на конференции, в статье на Хабре, в печатном издании, на ковре у директора, на митинге перед тимлидом.
— Навык здравой оценки своих знаний и пробела в них.

Такие вот дела. Напомню, что мы рассказывали правильный порядок анализа предметной области.
#edu #sudo

Посмотрим на свежую статью по сравнению брокеров сообщений — систем, реализующих шаблон издатель-подписчик (pub/sub, publisher-subscriber). Шаблон позволяет реализовать асинхронную обработку сообщений с множественными писателями и читателями. Например, загрузка видео на youtube требует его переконвертацию под множество размеров (144p, 240p и так далее). Такое поведение можно реализовать на брокере сообщений — вкинули пул заданий на преобразование, и эти задания будут обрабатывать те сервера, которые сейчас свободны. Полученную схему можно относительно легко масштабировать, добавляя новые узлы-обработчики или сервисы-загрузчики новых видео.

Статья A Fair Comparison of Message Queuing Systems сравнивает Kafka, RabbitMQ, RocketMQ, ActiveMQ и Pulsar. Статья является отличным примером правильного сравнительного анализа. Дан обширный ввод в предметную область. Обзор публикаций маловат, но это единственный недочёт. Далее выдвинуты обоснованные критерии сравнения, разделённые на блоки: особенности (язык, сообщество, протоколы, ...), качество обслуживания (надёжность, масштабируемость, ...), производительность (задержки и пропускная способность). Для каждого из критериев написан абзац текста с описанием и обоснованием важности. Ранее мы критиковали статью с хабра за невнятные критерии. Теперь у нас есть отличный пример правильной формулировки критериев сравнения. Следом идёт сжатое описание каждой из сравниваемых систем, по каждой сформулированы плюсы и минусы.

Следом описана методика тестирования и конфигурация оборудования стенда. После приведены графики измеряемых параметров, даны рассуждения "кого когда лучше применять" и краткое заключение.

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

#sudo #edu #devfm

Корчеватель ломает науку

Любую нетривиальную задачу по разработке следует начинать с анализа предметной области (наш пример разбора статей в области видеоаналитики) и просмотра доступных альтернатив на github и gitlab. Анализ предметной области по рецензируемым научным изданиям позволяет получить защиту от переизобретения велосипеда, сразу взять хорошее решение и дорабатывать его.

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

Но не все научные издания одинаково хороши. Как оценить "хорошесть" издания? Неплохой вариант выявления плохих — продемонстрировать, что журнал принимает к изданию фигню. Но просто написать фигню — на наш вариант. Давайте фигню сгенерируем. Так родился Корчеватель, написанный преимущественно на perl проект по генерации псевдонаучных текстов. Он есть на github (без документации, как мы любим). Но результаты хороши — статья с наукообразным текстом, графиками и литературой, которая была неоднократно принята к изданию с положительными отзывами рецензентов у нас и за рубежом. Таким способом можно выявлять плохих рецензентов и ужасные журналы.

Нельзя не упомянуть яндекс.рефераты. Выбираете набор тематик и получаете фрагмент безумного текста. Залипательно. Маркетинг&Математика выдаёт тексты, похожие на половину пресс-релизов компаний:

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

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

#edu #sudo #devfm

Мы сняли часовой стрим по созданию небольшого проекта на python для начинающих разработчиков. Идея проста — прочитать в csv-файле ФИО и login и проверить существование этого login на gitlab. Но тут vim, проект на gitlab, консольный git, исключения, google docstring, правильная структура проекта и тесты — всё слилось в едином экстазе.

Все покрытые темы — в описании под видео.

#youtube #python #devfm #sudo

Навигация по каналу

#sudo — наиболее важные посты. Начать знакомство с каналом рекомендуем с них.
#devfm — материалы собственного производства. Не просто аннотации, а наши мысли, статьи и видеоролики.

#python — фокусируемся на самом языке и его библиотеках.
#codereview — разбираем код, находим и устраняем проблемы, превращаем плохой код в хороший.
#procode — о профессиональной разработке и тестировании вне зависимости от языка.
#skills — о смежных с разработкой технических навыках, необходимых для работы и резюме. Инструменты (в том числе git, bash, docker), командная работа, безопасность и прочие фундаментальные вещи.
#systemdesign — проектирование систем и построение архитектуры.
#tools — полезные инструменты для работы.
#edu — полезные нетехнические навыки. Об обучении, продуктивности, английском, умении искать и обосновывать решения.
#youtube — видеоматериалы.
#fun — пятничное развлекательное и культурный код. Обзор художественных фильмов #films, книг #books, комиксов #xkcd и прочего.

#backup — лучшие посты месяца.

Какие знания нужны разработчику?

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

Одним из вариантов визуализации подобных знаний является roadmap. Это такая "дорожная карта" с пометками, что следует освоить.

Самым популярным проектом является roadmap.sh. В их github 215к звёзд, настолько это общее место для индустрии. Прописаны roadmap для самых разных специализаций и технологий. Недавно к каждому навыку они стали прикреплять пачку статей и видео из изучения.

Roadmap позволяет выявить пробелы в текущих знаниях и наметить актуальные вопросы для изучения.
#sudo #edu

Преодолеваем постоянное откладывание дел

Для разгрузки оперативной памяти я все будущие задачи вношу в таск-менеджер. Независимо от объёма задачи всё должно быть записано, чтобы не держать в голове. Но дальше возникает большая проблема — некоторые задачи после внесения в таск-менеджер я не делаю никогда, постоянно отодвигая на "когда-нибудь потом". Это приводит к большим неудобствам. Например, вторая часть стрима python student уже три месяца откладывается. Проблема в том, что назначение подобной задачи "на сегодня" плохо помогает, так как задача большая и сложная, подступиться к ней сложно.
Мой опыт преодоления такой:

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

Давайте на примере. Задача "снять ролик python students, часть 2". Декомпозируем:
— решить, какие темы включить в ролик
— прописать сценарий
— прописать текст
— снять ролик
— смонтировать ролик
— расставить текстовые подсказки по ролику
— подкорректировать аудиодорожку
— выложить ролик

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

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

Для меня главный фактор откладывания задачи — её неясность. Дробление задачи позволяет неясность устранить. Задачи должны быть такого размера, чтобы минимизировать напряжение мозга: взял и сделал.

Еще один житейский пример: в машине загорелась лампочка "долить охлаждающую жидкость".
Уже на опыте я не заношу задачу: "Съездить в сервис и долить жидкость". Куда ехать? Когда ехать? — вот такие вопросы у меня будут возникать и я точно буду её откладывать.

Я ставлю задачи:
— Выбрать сервис для замены жидкости (смотрю отзывы на картах)
— Позвонить и договориться о времени (узнать цену, сколько займёт по времени, после разговора записать адрес)
— Поехать в сервис на замену жидкости <— по факту это та же задача, но только теперь у меня нет к ней вопросов, просто беру и делаю.

Обратите внимание на подсказки в скобках, они позволяют в момент решения задачи дополнительно не думать: А как выбрать сервис? А что нужно дополнительно уточнить, когда буду звонить?

Полезны ещё несколько аспектов:
✅ При составлении плана учитываю будущую загрузку, не планирую 40 задач по часу каждая на воскресенье. Приходит с опытом. Или не приходит.

✅ Учитываю приоритет задачи. Если задача важная / выгодная / полезная, то планирую её пораньше.

✅ Умеряю перфекционизм. Часто надо сделать хорошо, а не идеально. Опускаться до уровня "кое-как" не всегда оправданно, но иногда и это годится.

✅ Для меня ещё работает практика начать чуть-чуть. Если к чему-то не могу приступить, просто ставлю себе установку — начну и 15 минут поделаю. Обычно после такого начала продолжаю делать задачу. А если нет, то не расстраиваюсь, значит задача не такая нужная.

В дополнение вспомним про хорошую и плохую прокрастинацию от Пола Грэма. Это когда ты занят, но не тем.

А еще я каждый день анализирую список своих задач, но это тема отдельного поста.
#sudo #devfm #edu

Принципы, которыми стоит руководствоваться

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

Эти принципы даются с высоты Solution Architect. Мы выделили принципы, применимые для любого специалиста и которые сами постоянно применяем на практике.

Идти нужно от проблемы
Если для проблемы есть типовое решение — применяйте его. Не нужно пытаться что-то изобретать и применять какую-то новомодную штуку.

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

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

Мы добавим, что не нужно пытаться продумать на 100 шагов вперед. Это внесёт излишнюю и ненужную сложность в систему, а когда требования кардинально поменяются (а они точно поменяются) окажется, что сложность накручена не там.

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

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

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

Многое, о чём говорит автор — знакомо и понятно. В статье есть еще несколько советов, а приятное изложение благоволит к прочтению :)
#sudo #edu

ООП на простых примерах

В 40-минутном видео аккуратно объясняют три кита объектно-ориентированного программирования. Примеры даны на TypeScript, но понятны любому разработчику. Автор аккуратно иллюстрирует необходимость ООП, рассказывает про инкапсуляцию, наследование и полиморфизм. Покрыты даже относительно сложные вещи вроде параметрического и ad-hoc полиморфизма.

На трёх китах ООП автор не заканчивает. Вторая половина ролика повествует о композиции и агрегации на примере автомобиля с двигателем и колёсами, об абстрактных классах и интерфейсах, и даже немного о дженериках. Завершает изложение реализация паттернов Dependency Injection и Singleton. При этом Singleton во многих случаях является антипаттерном и мы не рекомендуем его применять.

Обратите внимание, как автор умело использует IDE для автогенерации сеттеров и геттеров. Не забывайте, что IDE — ваш добрый друг, который много чего умеет.

Про нюансы getattr и setattr в питоне мы делали отдельные посты.

#sudo #youtube #procode

Составляем документацию разработчика пошагово без диет и тренировок

Мы уже писали о своём опыте документирования проектов.

Теперь заход от больших ребят, в несколько другой плоскости.

Начинается статья с интересной блок-схемы, где отображены типичные вопросы по документации:
— Есть ли у вас документация?
— Актуальна ли она?
— Легко ли её найти?
— Читает ли её кто-то?
— В одном ли месте всё собрано?

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

Часто полезная информация разбросана по разным источникам. Как подключиться к инфре писали в общем чате, нюансы работы с сервисом написали в личку, R&D таки зафиксировали в конфлюенс. Поэтому на первом шаге рекомендуется собрать всё вместе.

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

Чтобы понять, о чём реально стоит писать, соберите обратную связь. Прошерстите чатики, комменты под инструкциями. Если часто спрашивают, как поменять конфиги там-то — отлично, именно об этом и стоит писать.

Неочевидный, но важный момент. Вход в документацию начинается с поиска. Если где-то будет написано: кронджоба, джоба, cron, то нужный материал не найдётся. Поэтому договоритесь о единой терминологии и стиле написания. У нас, например, простое правило: любые термины пишем в их каноническом виде на английском языке.

Стоит позаботиться также о читабельности. Тут все банально — на текст должно быть приятно смотреть. В статье на этот счёт есть конкретный набор советов.

Чтобы документация читалась, и активно поддерживалась — её нужно распространять, чтобы каждый знал, куда смотреть и где искать. Недостаточно один раз скинуть ссылку в чатик и думать, что все теперь оповещены. Сообщайте о ней из всех утюгов: сделайте закрепы в общих чатах, в личных сообщениях и везде, где у вас тусуется народ.

И в заключение: с документацией, как с тестами. Не стоит думать, что, если проект не покрыт тестами, то и смысла писать их нет. Нужно просто начать покрывать тестами новый код и это уже будет хорошо. Если документация устаревшая или её вообще нет, начните с малого — начните писать её к новым разработкам.
#sudo #skills

Правильная структура ответа на собеседовании

Классический анекдот. Студент сдаёт экзамен по зоологии, а подготовился только к вопросу про блох. Тянет билет — там про собак. Начинает отвечать, что собака — млекопитающее, у неё есть голова, 4 лапы, хвост, всё это обильно покрыто шерстью, а в шерсти — блохи! И подробнейшим образом про блох. Преподаватель прерывает и просит рассказать про кошек. Студент снова: голова, усики, лапы, хвост и много шерсти, в которой — блохи, и опять про блох. Преподаватель снова прерывает и просит рассказать про рыб. Студент: тааак, рыбы., рыбы... плавают в воде, дышат жабрами, покрыты чешуёй. В чешуе блохи не водятся. Это спасает рыб от проблем с блохами. И снова про блох...

Рекомендуем версию этого анекдота с интересной историей из жизни про экзамен в РХТУ им. Менделеева. К чему это мы?

При ответе на собеседовании или на экзамене важно показать обширность и глубину ваших знаний. Выгодно максимально подробно отвечать, даже если ответ не совсем по теме. Забыли, что значит D в SOLID? Постарайтесь построить ответ так, чтобы максимально подробно рассказать про знакомые буквы. В процессе вспомнили другие темы, например, аббревиатуры, связанные с исходным вопросом? Пускайте в ход DRY, YAGNI, KISS, NIH-синдром, bus-factor и кучу другого материала, по возможности вплетая его в повествование. Высока вероятность, что собеседник забудет, что вы не до конца ответили на поставленный вопрос. Чем уместнее вы притянули смежные темы, тем менее заметна попытка скрыть незнание. Если тема совсем не к месту, то будет обратный эффект с обнаружением вашего незнания.

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

Но не злоупотребляйте таким приёмом. В работе важно уметь честно признать, что чего-то не знаешь. Нельзя знать всего, надо учиться у коллег, в том числе на правильном code review.

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

#devfm #sudo #edu #резюме

Docker в каждый дом

Стрим FastAPI+Docker породил бурное обсуждение, а нужен ли докер в таком небольшом проекте. Наш ответ — обязательно! В современном мире разработки docker является такой же неотъемлемой частью разработки, как и git. Есть некоторые области без докера, например, разработка GUI, операционных систем или микроконтроллеров. Но весь backend, frontend и data science без докера вообще не живут. Давайте посмотрим, какие прямые выгоды даёт докер:

1. Всегда понятно, как запустить код. Dockerfile является однозначной инструкцией по сборке проекта. Bus-factor не мешает жить.

2. Легко включать новых людей в разработку. Инструкция в ридми сводится к docker build & docker run, что понятно даже junior-разработчикам.

3. Деплой можно производить где угодно. В пару команд можно запуститься на компе разработчика, на test или prod сервере, у заказчика на ноутбуке – и везде всё будет одинаково, нужен только сам Docker.

4. Проект одинаково себя ведёт везде. Это упрощает воспроизведение проблемы и сокращает время на багфикс.

5. Нет проблем с конфликтом зависимостей-библиотек. Вы можете на одной машине запустить проекты с условным django 3 и django 4, они никак друг другу не помешают.

6. Легко поднимать зависимости-компоненты. Для любой базы данных берётся готовый докер-образ, меняется конфиг и в одну команду запускается. С выходом на docker compose можно одной командой поднимать сборную солянку из backend, frontend, базы данных, nginx и Let's Encrypt.

7. Просто откатываться к старой версии. Версионирование докер-образов позволяет запустить новую версию, и, если что-то пошло не так, откатиться назад за десятки секунд.

8. Понятные внешние эффекты проекта. В команде docker run указаны проброшенные в контейнер каталоги и порты. Всё остальное изолированно.

В общем, со всех сторон одна польза. Минусы? Требуется изучить новый инструмент и best practices. Кажется, на этом всё. Даже дополнительных накладных расходов на виртуализацию нет. И помните – если docker вам мешает, скорее всего, вы что-то делаете неправильно.

Для запуска нескольких связанных контейнеров пользуйтесь compose, гайд тут. Если ещё нужно управлять множеством серверов, то посмотрите на kubernetes.

#skills #sudo #devfm