Сообщение Re[23]: Киллер-фичи докера от 15.05.2020 16:44
Изменено 15.05.2020 16:55 Vetal_ca
Re[23]: Киллер-фичи докера
Здравствуйте, Sheridan, Вы писали:
S>Ансиблом можно добиться стандартного окружения. Не только докером единым.
разные ОС?
S>Песочница у вас, докер называется.
Докер (ContainerD), это следующий шаг для тебя, потолок. За ним жизнь только начинается, но ты эту жизнь не видишь.
S>А, я понял. Ты хочешь нанимать работников низкой квалификации за копейки, согласен получать от них кое-как работающий говнокод, который работает исключительно в тепличных условиях. Ну в таком случае докером проще, да.
Дополнительный уровень надежности это не обязательно компенсация ущербности программы. А полезное дополнение. Экономия времени, увеличение надежности сверху. Читай, конкурентное преимущество
V_>>Ансибл не гарантирует правильную работу компонента. Он гарантирует деплой, при условии что playbook написан грамотно.
S>Это и есть гарантия работы компонента.
Как ансибл влияет на компонент после деплоймента?
S>Еще раз: после деплоя у тебя единообразное окружение. В чём проблема? В том что нанятый за копейки работник не осилит?
Возьмем любую задачу, случайно. Допустим, накрылся letsencrypt. И мне нужно выдать список всех сертификатов на выбранном кластере.
Точно так же как вывести все поды без healthcheck или получить этот healthcheck и т.п.
Причем:
— сделать это может любой специалист, работавший с кубернетес и умеющий JQ, в том числе если это его первый день на этой работе
— делается для всего кластера. Можно сделать для всех кластеров
— не зависит от внутреннего формата, документации и прочего
Работающей код — это маленькая часть Его поддерживаемость, стандартность, расширяемость — это осязаемые ценности. Чтобы с продуктом жить, легко вводить в курс дела новичков или выгодно перепродать.
А зависеть от местных yаполеонов, которые думают про "розгами по пальцам", это риск для бизнеса. Потому и ценность их никакая
S>Ансиблом можно добиться стандартного окружения. Не только докером единым.
разные ОС?
S>Песочница у вас, докер называется.
Докер (ContainerD), это следующий шаг для тебя, потолок. За ним жизнь только начинается, но ты эту жизнь не видишь.
S>А, я понял. Ты хочешь нанимать работников низкой квалификации за копейки, согласен получать от них кое-как работающий говнокод, который работает исключительно в тепличных условиях. Ну в таком случае докером проще, да.
Дополнительный уровень надежности это не обязательно компенсация ущербности программы. А полезное дополнение. Экономия времени, увеличение надежности сверху. Читай, конкурентное преимущество
V_>>Ансибл не гарантирует правильную работу компонента. Он гарантирует деплой, при условии что playbook написан грамотно.
S>Это и есть гарантия работы компонента.
Как ансибл влияет на компонент после деплоймента?
S>Еще раз: после деплоя у тебя единообразное окружение. В чём проблема? В том что нанятый за копейки работник не осилит?
Возьмем любую задачу, случайно. Допустим, накрылся letsencrypt. И мне нужно выдать список всех сертификатов на выбранном кластере.
kubectl get certificate --all-namespaces -o json | jq --raw-output ".....
Точно так же как вывести все поды без healthcheck или получить этот healthcheck и т.п.
Причем:
— сделать это может любой специалист, работавший с кубернетес и умеющий JQ, в том числе если это его первый день на этой работе
— делается для всего кластера. Можно сделать для всех кластеров
— не зависит от внутреннего формата, документации и прочего
Работающей код — это маленькая часть Его поддерживаемость, стандартность, расширяемость — это осязаемые ценности. Чтобы с продуктом жить, легко вводить в курс дела новичков или выгодно перепродать.
А зависеть от местных yаполеонов, которые думают про "розгами по пальцам", это риск для бизнеса. Потому и ценность их никакая
Re[23]: Киллер-фичи докера
Здравствуйте, Sheridan, Вы писали:
S>Ансиблом можно добиться стандартного окружения. Не только докером единым.
разные ОС?
S>Песочница у вас, докер называется.
Докер (ContainerD), это следующий шаг для тебя, потолок. За ним жизнь только начинается, но ты эту жизнь не видишь.
S>А, я понял. Ты хочешь нанимать работников низкой квалификации за копейки, согласен получать от них кое-как работающий говнокод, который работает исключительно в тепличных условиях. Ну в таком случае докером проще, да.
Дополнительный уровень надежности это не обязательно компенсация ущербности программы. А полезное дополнение. Экономия времени, увеличение надежности сверху. Читай, конкурентное преимущество
V_>>Ансибл не гарантирует правильную работу компонента. Он гарантирует деплой, при условии что playbook написан грамотно.
S>Это и есть гарантия работы компонента.
Как ансибл влияет на компонент после деплоймента?
S>Еще раз: после деплоя у тебя единообразное окружение. В чём проблема? В том что нанятый за копейки работник не осилит?
Возьмем любую задачу, случайно. Допустим, накрылся letsencrypt. И мне нужно выдать список всех сертификатов на выбранном кластере.
Точно так же как вывести все поды без healthcheck или получить этот healthcheck и т.п.
Причем:
— сделать это может любой специалист, работавший с кубернетес и умеющий JQ, в том числе если это его первый день на этой работе
— делается для всего кластера. Можно сделать для всех кластеров
— не зависит от внутреннего формата, документации и прочего
Работающей код — это маленькая часть Его поддерживаемость, стандартность, расширяемость — это осязаемые ценности. Чтобы с продуктом жить, легко вводить в курс дела новичков или выгодно перепродать.
А зависеть от местных наполеонов, которые думают про "розгами по пальцам", это риск для бизнеса. Потому и ценность их никакая
S>Ансиблом можно добиться стандартного окружения. Не только докером единым.
разные ОС?
S>Песочница у вас, докер называется.
Докер (ContainerD), это следующий шаг для тебя, потолок. За ним жизнь только начинается, но ты эту жизнь не видишь.
S>А, я понял. Ты хочешь нанимать работников низкой квалификации за копейки, согласен получать от них кое-как работающий говнокод, который работает исключительно в тепличных условиях. Ну в таком случае докером проще, да.
Дополнительный уровень надежности это не обязательно компенсация ущербности программы. А полезное дополнение. Экономия времени, увеличение надежности сверху. Читай, конкурентное преимущество
V_>>Ансибл не гарантирует правильную работу компонента. Он гарантирует деплой, при условии что playbook написан грамотно.
S>Это и есть гарантия работы компонента.
Как ансибл влияет на компонент после деплоймента?
S>Еще раз: после деплоя у тебя единообразное окружение. В чём проблема? В том что нанятый за копейки работник не осилит?
Возьмем любую задачу, случайно. Допустим, накрылся letsencrypt. И мне нужно выдать список всех сертификатов на выбранном кластере.
kubectl get certificate --all-namespaces -o json | jq --raw-output ".....
Точно так же как вывести все поды без healthcheck или получить этот healthcheck и т.п.
Причем:
— сделать это может любой специалист, работавший с кубернетес и умеющий JQ, в том числе если это его первый день на этой работе
— делается для всего кластера. Можно сделать для всех кластеров
— не зависит от внутреннего формата, документации и прочего
Работающей код — это маленькая часть Его поддерживаемость, стандартность, расширяемость — это осязаемые ценности. Чтобы с продуктом жить, легко вводить в курс дела новичков или выгодно перепродать.
А зависеть от местных наполеонов, которые думают про "розгами по пальцам", это риск для бизнеса. Потому и ценность их никакая