Его задача — инстансы гонять. Просто потом этот же товарищ, вконец «уставший» от изучения концепций третьего языка программирования, на котором он никогда не будет писать, пойдет на другую работу. А там… Там, предположим, Ruby… Кхм.
Внезапно выясняется, что нужно работать и что-то сделать получается только кровью и потом, не, лучше запихаю все в контейнеры подальше от глаз, там не видно как оно работает, в волшебном докере фиксики шестеренки крутят и делают плохой софт хорошим.
За иллюзию контроля платят дороже, чем за осознание ограничений своих инструментов на текущий момент времени.
три слабых места pip + venv
Производим артефакт с venv на этапе сборки, gcc остается только на сборочном агенте.
Для доставки есть другие инструменты.
Или вы считаете голый docker полноценным инструментом доставки?
Расскажите, как вы голым докером, без обвязки и оркестрации произведете бесшовное обновление.
«инженеры-эксплуатационщики» изучают npm,
опсы нажимают на кнопку.
Вы считаете, что запрятывание процесса в отдельный namespace избавляет опсов от необходимости понимания его работы?
бедолага инженер по тихой грусти изучает maven, gradle
Бедолагам инженерам в принципе полезно понимать какие бизнес-процессы они обеспечивают, вместо того, чтобы закрываться в своей комнатке, типа мы тут обеспечиваем инфраструктуру cicd.
процесс эксплуатации проекта становится не зависим от стека
Все та же иллюзия контроля, если вы положите предмет в шкаф, он от этого не станет шкафом, он станет предметом в шкафу. Если вы не могли обеспечить его качественную эксплуатацию без шкафа, то и со шкафом вы её не обеспечите.
зачем все-то руками рулить?
Разве я где-то писал про руление руками? Помимо docker есть масса инструментов, которыми вы кстати будете рулить и docker'ом, пока не поймете тленность его использования без оркестрации, но тут нужно учиться на своих ошибках и запороть пару проектов.
«контейнер» — это концепция, понятная обоим сторонам процесса.
systemctl start servicename
systemctl stop servicename
обе стороны процесса только что научились пользоваться systemd, сложнее чем docker?
«не забудь, вот в этом месте должен лежать файлик вот с таким содержимым»
Сложность системы определяется количеством элементов в ней и количеством связей между ними.
Systemd и пакетный менеджер есть практически на любой системе, мы не вводим нового элемента.
Для локалхоста разработчиков, если им нужны dev стенды на локалхостах (что обычно не так), есть vagrant.
зачастую возможны проблемы, когда в системе стоит библиотека версии А, а программе нужна Б, причем обе не могут быть установлены
Статическая линковка для c/cpp? fat jar для java?
Или вы инфраструктурную обвязку в docker крутите? Этот вариант настолько же прекрасен в рамках процессов тестирования/разработки насколько плох в рамках процессов эксплуатации.
И если вы хотите, чтобы хорошо было всем, вам придется поддерживать 2 разных механизма развертывания.
| Сюда же — нормальный менеджмент пакетов у многих экосистем (например, python) отсутствует от слова совсем.
pip + requirements.txt, vitrualenv? не знаю чем вам менеджмент пакетов python не угодил.
есть такой момент, да. Но это характерно для любой современной системы, которая является совокупностью слоев абстракции. Чего уж тогда от виртуализации не отказаться и гонять все на баре-метал? Слоев абстракции меньше — траблшутинг проще (*** не всегда )
Принцип бритвы Оккама. Любая техническая задача, это задача математической оптимизации — минимизируем временные расходы, при заданных ограничениях.
У docker, как у любого инструмента есть свои применения (запуск stateless микросервисов в оркестраторе).
Я не буду спорить, можно и отверткой гвозди забивать при наличии энтузиазма, главное при этом иметь вид достаточно лихой, чтобы потом не спросили за потраченное время и выбитые выскользнувшей отверткой окна.
нормально он читается. Уж всяко лучше, чем переусложненный ruby DSL паппет-манифест или шеф-кукбук.
Разными людьми разные вещи читаются с разной эффективностью, но вы лукавите, говоря, что пачка bash скриптов с обратным слэшем перед переводом строки является эталоном читабельности.
По пунктам 1,2,3 подходят rpm/deb + systemd, которые, в отличии от docker, не добавляют целой пачки сущностей и не усложняют систему.
> 4) документация среды в виде кода
Dockerfile не самая удобочитаемая вещь в мире, тогда сюда же вполне ложится лобой configuration management tool или spec file.
> 5) относительная чистота среды исполнения
Точно так же зависит от приложения, если оно у вас stateless, то среда для него всегда будет чистая, независимо от того, что вокруг него, а если вы запускаете в докере на проде statefull workload, вероятно монтируя его volume'ми — вы значительно усложняете себе жизнь.
Про упрощение жизни опсов также не соглашусь, docker усложняет любой траблшутинг, всегда. Для большинства опсов docker является новой сущностью.
Если речь идет про предоставление единого интерфейса, то тут опять же гораздо лучше подходит systemd.
Docker нужен для запуска микросервисов в оркестраторе.
Микросервисы нужны только тогда, когда руководство разработки и разработка в целом четко понимает для чего они им нужны.
Если вы не знаете для чего конкретно вам нужен docker или микросервисы — они вам не нужны, если не смотря на это, вы хотите их применить — вы действуете не оптимально, и тогда docker для вас игрушка.
Внезапно выясняется, что нужно работать и что-то сделать получается только кровью и потом, не, лучше запихаю все в контейнеры подальше от глаз, там не видно как оно работает, в волшебном докере фиксики шестеренки крутят и делают плохой софт хорошим.
Вы уж простите за сарказм, не сдержался.
За иллюзию контроля платят дороже, чем за осознание ограничений своих инструментов на текущий момент времени.
Производим артефакт с venv на этапе сборки, gcc остается только на сборочном агенте.
Для доставки есть другие инструменты.
Или вы считаете голый docker полноценным инструментом доставки?
Расскажите, как вы голым докером, без обвязки и оркестрации произведете бесшовное обновление.
опсы нажимают на кнопку.
Вы считаете, что запрятывание процесса в отдельный namespace избавляет опсов от необходимости понимания его работы?
Бедолагам инженерам в принципе полезно понимать какие бизнес-процессы они обеспечивают, вместо того, чтобы закрываться в своей комнатке, типа мы тут обеспечиваем инфраструктуру cicd.
Все та же иллюзия контроля, если вы положите предмет в шкаф, он от этого не станет шкафом, он станет предметом в шкафу. Если вы не могли обеспечить его качественную эксплуатацию без шкафа, то и со шкафом вы её не обеспечите.
Разве я где-то писал про руление руками? Помимо docker есть масса инструментов, которыми вы кстати будете рулить и docker'ом, пока не поймете тленность его использования без оркестрации, но тут нужно учиться на своих ошибках и запороть пару проектов.
systemctl start servicename
systemctl stop servicename
обе стороны процесса только что научились пользоваться systemd, сложнее чем docker?
Простите, а зачем?
Сложность системы определяется количеством элементов в ней и количеством связей между ними.
Systemd и пакетный менеджер есть практически на любой системе, мы не вводим нового элемента.
Для локалхоста разработчиков, если им нужны dev стенды на локалхостах (что обычно не так), есть vagrant.
Поэтому да, rpm/deb + systemd — проще чем Docker.
Статическая линковка для c/cpp? fat jar для java?
Или вы инфраструктурную обвязку в docker крутите? Этот вариант настолько же прекрасен в рамках процессов тестирования/разработки насколько плох в рамках процессов эксплуатации.
И если вы хотите, чтобы хорошо было всем, вам придется поддерживать 2 разных механизма развертывания.
| Сюда же — нормальный менеджмент пакетов у многих экосистем (например, python) отсутствует от слова совсем.
pip + requirements.txt, vitrualenv? не знаю чем вам менеджмент пакетов python не угодил.
Принцип бритвы Оккама. Любая техническая задача, это задача математической оптимизации — минимизируем временные расходы, при заданных ограничениях.
У docker, как у любого инструмента есть свои применения (запуск stateless микросервисов в оркестраторе).
Я не буду спорить, можно и отверткой гвозди забивать при наличии энтузиазма, главное при этом иметь вид достаточно лихой, чтобы потом не спросили за потраченное время и выбитые выскользнувшей отверткой окна.
Разными людьми разные вещи читаются с разной эффективностью, но вы лукавите, говоря, что пачка bash скриптов с обратным слэшем перед переводом строки является эталоном читабельности.
> 4) документация среды в виде кода
Dockerfile не самая удобочитаемая вещь в мире, тогда сюда же вполне ложится лобой configuration management tool или spec file.
> 5) относительная чистота среды исполнения
Точно так же зависит от приложения, если оно у вас stateless, то среда для него всегда будет чистая, независимо от того, что вокруг него, а если вы запускаете в докере на проде statefull workload, вероятно монтируя его volume'ми — вы значительно усложняете себе жизнь.
Про упрощение жизни опсов также не соглашусь, docker усложняет любой траблшутинг, всегда. Для большинства опсов docker является новой сущностью.
Если речь идет про предоставление единого интерфейса, то тут опять же гораздо лучше подходит systemd.
Микросервисы нужны только тогда, когда руководство разработки и разработка в целом четко понимает для чего они им нужны.
Если вы не знаете для чего конкретно вам нужен docker или микросервисы — они вам не нужны, если не смотря на это, вы хотите их применить — вы действуете не оптимально, и тогда docker для вас игрушка.