Re[15]: Первый пошол - Компьютерные священные войны

Здравствуйте, Shmj, Вы писали:

S> Часто ли в вашей практике встречаются типовы сценарии?

Каждый день.

S> К примеру, установить Open VPN.

Один раз в жизни.

S> И как вы эти сценарии отрабатываете?

apt-get install <имя_пакета_для_типовой_задачи>

ну или кнопку нажать в веб-интерфейсе на выкладку оного пакета. Когда-то пользовался поделиями типа pupet/ansible/cfengine, но оно не прижилось, т.к. по сути должно делать то же самое, что выше.

S> А так же додумался ли кто до централизованного сборника готовых решений — чтобы ввел одну команду и получил готовый настроенный LAMP, к примеру или подобное?

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

Здравствуйте, Shmj, Вы писали:

S>А так же додумался ли кто до централизованного сборника готовых решений — чтобы ввел одну команду и получил готовый настроенный LAMP, к примеру или подобное?

А параметры-то откуда возьмутся?

Здравствуйте, kov_serg, Вы писали:

_>Типа такого?

Может быть. Интересно кто чем пользуется на практике.

Здравствуйте, netch80, Вы писали:

N>apt-get install apache mysql-server perl

N>чем тебе не команда?
N>То, что надо контент залить, базы настроить и т.п. — пока проигнорируем

Ну вот наиболее типичный sh-файлик, где бы вначале поправить константы — а дальше просто запустить и все готово.

N>То же и с openvpn — пока не определишь, чего хочется от сервера, нечего строить, а когда определишь — есть готовые образцы.

А что там сильно хотеть от сервера? К примеру типовой сценарий — просто использовать как VPN. И не для 1 клиента а для множества — для каждого свой конфиг.

Здравствуйте, vsb, Вы писали:

vsb>Обычно всё делаю с нуля, но со временем некоторые типовые конфиги скопились и тот же IPsec сервер я нынче настраиваю копированием готового конфига.

Ну вот, у вас только IPsec. А кто давно в отрасли работает — у того, наверное, уже целая папочка готовых сценариев. А может быть это привело и к более разумному решению — что только кнопку нажал, ввел поля на форме, указал имя пользователя+ключ SSH — и сервер готов.

Здравствуйте, Anton Batenev, Вы писали:

S>> И как вы эти сценарии отрабатываете?

AB>apt-get install <имя_пакета_для_типовой_задачи>

На примере OpenVPN — там не прокатит просто apt-get install, чтобы можно было к нему просто подключиться.

Здравствуйте, Pzz, Вы писали:

S>>А так же додумался ли кто до централизованного сборника готовых решений — чтобы ввел одну команду и получил готовый настроенный LAMP, к примеру или подобное?

Pzz>А параметры-то откуда возьмутся?

К примеру, админ введет их в форме. Или константы вначале sh-файлика.

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, Anton Batenev, Вы писали:

S>>> И как вы эти сценарии отрабатываете?

AB>>apt-get install <имя_пакета_для_типовой_задачи>

S>На примере OpenVPN — там не прокатит просто apt-get install, чтобы можно было к нему просто подключиться.

некоторые хостеры предлагают готовые vps-ки с OpenVPN. Там просто после установки системы скрипт запустить надо и пройтись по шагам для генерации ключей.

вот, глянь https://github.com/Nyr/openvpn-install

Здравствуйте, wl., Вы писали:

wl.>некоторые хостеры предлагают готовые vps-ки с OpenVPN. Там просто после установки системы скрипт запустить надо и пройтись по шагам для генерации ключей.

wl.>вот, глянь https://github.com/Nyr/openvpn-install

Ну да, но как то выглядит велосипедом что ли... Есть ли подобные решения для все остальных типовых сценариев? И чтобы как-то более централизованно что ли...

Здравствуйте, Shmj, Вы писали:

S>Ну да, но как то выглядит велосипедом что ли... Есть ли подобные решения для все остальных типовых сценариев? И чтобы как-то более централизованно что ли...

вот не знаю, могу спросить знакомого с работы, когда майские кончатся (6-го), но на мой взгляд, всё руками делают, причем так быстро, как будто уже на рефлексах команды в консоль вбивают

---
- hosts: all
  tasks:
    - name: "install postifx"
      apt:
        name: postfix
    - name: "relay host"
      lineinfile:
        path: /etc/postfix/main.cf
        regexp: '^relayhost ='
        line: relayhost = 172.20.0.1
    - name: "restrict interfaces"
      lineinfile:
        path: /etc/postfix/main.cf
        regexp: '^inet_interfaces = all'
        line: inet_interfaces = loopback-only
    - name: "restart postfix"
      systemd:
        state: restarted
        daemon_reload: yes
        name: postfix
    - name: "add alias"
      lineinfile:
        path: /etc/aliases
        insertafter: '^# See man 5 aliases for format'
        line: 'root: root@mail.mysite.net'
    - name: "update alias db"
      shell: newaliases

ведь обычно кроме настройки установки пакета, как здесь (postfix),
нужно еще поправить строчку в одном конфиге, в другом,
что-нибудь забудешь, придется отлаживаться, а здесь все в одном месте.

Это настройка моего "домашнего" сервера, так конечно, есть секций vars,
которая по разному применяется к разным серверам из группы. Но здесь всего
один сервер, и ip адреса фиксированы, поэтому...

Здравствуйте, Shmj, Вы писали:

S> S>> И как вы эти сценарии отрабатываете?
S> AB>apt-get install <имя_пакета_для_типовой_задачи>
S> На примере OpenVPN — там не прокатит просто apt-get install, чтобы можно было к нему просто подключиться.

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

Судя по контексту ты спрашиваешь не про рабочие, а про личные задачи. Для личного пользования городить колхоз нет смысла, т.к. эти задачи уникальные (просто ради прикола поднимать типовой OpenVPN нет смысла) и разовые (настроил и забыл).

AB>ну или кнопку нажать в веб-интерфейсе на выкладку оного пакета. Когда-то пользовался поделиями типа pupet/ansible/cfengine, но оно не прижилось, т.к. по сути должно делать то же самое, что выше.

А еще есть GUIX, где конфиг целой системы со всеми сервисами задается одной формулой ...

https://www.linux.org.ru/news/gnu/15645632

Что-то похожее, кажется, было у писателей-фантастов, когда весь мир описывался уравнениями?

А еще в GUIX только свободные компоненты с минимумом закладок (если они вообще там есть), даже ядро линукс в GUIX полностью свободное деблобированное Libre Kernel, их репозитарий хостится на Libreboot железке с частично удаленными аппаратными закладками.

И самое главное, в GUIX есть reproducible builds, и для чистоты эксперимента у них пересобирается даже GCC с помощью какого-то хитрой последовательности из более примитивных компиляторов. Вообщем, этот научный дистр GUIX (с козлиным логотипом) должен вызывать ненависть у всех уважающих себя спецслужб мира, пихающих свои шпионские жучки пачками куда ни поподя (включая другие дистры). Настоящая наука для души не терпит коррупции, разлагающей все вокруг себя, включая софт.

Здравствуйте, Shmj, Вы писали:

vsb>>Обычно всё делаю с нуля, но со временем некоторые типовые конфиги скопились и тот же IPsec сервер я нынче настраиваю копированием готового конфига.

S>Ну вот, у вас только IPsec. А кто давно в отрасли работает — у того, наверное, уже целая папочка готовых сценариев. А может быть это привело и к более разумному решению — что только кнопку нажал, ввел поля на форме, указал имя пользователя+ключ SSH — и сервер готов.

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

Здравствуйте, Anton Batenev, Вы писали:

AB>Тут имелось ввиду, что для моих типовых рабочих задач у меня уже собраны пакеты, которые привозят все необходимые зависимости и конфигурации. Будет задача развертывания корпоративного OpenVPN, появится пакет под требуемую конфигурацию OpenVPN.

А что за пакеты? deb?

AB>Судя по контексту ты спрашиваешь не про рабочие, а про личные задачи.

Про рабочие в том числе.

Здравствуйте, Shmj, Вы писали:

S> AB>Тут имелось ввиду, что для моих типовых рабочих задач у меня уже собраны пакеты, которые привозят все необходимые зависимости и конфигурации. Будет задача развертывания корпоративного OpenVPN, появится пакет под требуемую конфигурацию OpenVPN.
S> А что за пакеты? deb?

У меня — да, deb. Но никто не мешает собирать rpm-ки если работаешь с кровавым ынтырпрайзом.

Здравствуйте, Shmj, Вы писали:

S>А так же додумался ли кто до централизованного сборника готовых решений — чтобы ввел одну команду и получил готовый настроенный LAMP, к примеру или подобное?

Я для себя сделал решение на базе докера, образ + небольшая инструкция
https://github.com/scf37/docker-openvpn

Здравствуйте, Shmj, Вы писали:

S>Часто ли в вашей практике встречаются типовы сценарии? К примеру, установить Open VPN. И как вы эти сценарии отрабатываете? Давате на примере того же Open VPN — есть ли готовый скрипт, после запуска которого получаете настроенный VPN-сервер и конфиг клиента? Или каждый раз все вручную вводите?

S>А так же додумался ли кто до централизованного сборника готовых решений — чтобы ввел одну команду и получил готовый настроенный LAMP, к примеру или подобное?
Есть ansible (puppet, chief ...), он позволяет реализовать подход Infrastructure as Code (IaC). Берешь сценарий (например, добавление пользователя в vpn), декомпозируешь его (например, добавить пользователя, сгенерировать сертификаты, чтототам ещё), декомпозированные части расширяешь до полноценной задачи (например, нет пользователя в системе — добавить в систему с выставлением лимитов, прав, квот; просрочен корневой сертификат — сгенерировать новый и разослать участникам). Потом из этих частей (ролей) строишь алгоритм.
Бонус — "если чтото идёт не так" — просто прогоняешь плейбук без ограничений и оно тебе показывает/чинит места, которые оказались изменёнными. Ну, пришол вчера падаван и поменял чтото в конфигах. Юзеры начинают жаловаться. Падаван не помнит. Просто прогоняешь плейбук в чек-режиме и оно тебе показывает что "в вот этот файлик были внесены изменения вот такие"

вот, например, роли ансибла для моей домашней инфраструктуры.

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

Здравствуйте, Михaил, Вы писали:

М>Просмотри docker.
docker это не про настройку инфраструктуры, это про "мы не осилили всё вместе, будем делать по отдельности" как правило. Ну, когда на вопрос "зачем тут докер?" поступают ответы в стиле "эээ... ммм...", "потому что умеем!", "почему нет?" — вот как раз оно.

docker хорош при разработке, особенно фронтенда. Ну то биш для проекта поднял контейнер с nginx и проектом, контейнер с БД, контейнер с тестами, контейнер с pgadmin, контейнер с dns, контейнер с редиской, контейнер с кроликом, контейнер с мониторингом, контейнер с замоченными "внешними" сервисами и пилишь проект. Закончил работу — опустил контейнеры, поднял контейнеры для другого проекта...

А вот для продакшена.... Ну, такое вот. Докер в проде это минус в карму и косые взгляды. Ну, кроме, пожалуй, варианта когда проект гдетотам на сферическом амазоне крутитцца и нужно уметь быстро/автоматически масштабировать мощности в зависимости от нагрузки.

Здравствуйте, Anton Batenev, Вы писали:

AB>У меня — да, deb. Но никто не мешает собирать rpm-ки если работаешь с кровавым ынтырпрайзом.
А как ты пакетами разруливаешь ситуацию типа "впн по сертификатам, надо добавть юзера -> сгенерировать новый сертификат, настройки для пользовательской винды"?
Или "надо в мониторинг добавить хост, настроив сам хост и настроив коллектор"?

Здравствуйте, Sheridan, Вы писали:

S>вот, например, роли ансибла для моей домашней инфраструктуры.

Посмотрел — круть! Вот так примерно я и представлял законченное решение.

Здравствуйте, Sheridan, Вы писали:

М>>Просмотри docker.

S>А вот для продакшена.... Ну, такое вот. Докер в проде это минус в карму и косые взгляды. Ну, кроме, пожалуй, варианта когда проект гдетотам на сферическом амазоне крутитцца и нужно уметь быстро/автоматически масштабировать мощности в зависимости от нагрузки.

Это сразу, "админ отстал от поезда", собеседование прекращаем.

Пример:

имеем девопа, который подымает кластер MongoDB из BitNami MongoDB Charts за минуты (~3-4). Не копаясь в ненужном г-не. Плюс-минус подготовка, подгонка праметров, день, допустим.

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

Это реальный сценарий. Мало того, так кластер еще и распадается на Sharded-HA setup. Обновить монго, так тут, вообще, целая эпопея.

Kubernetes-Clustered, из ссылки выше работает под нагрузкой, ноль проблем. Не распадается. 3 месяца уже как. Пересоздается из бэкапа с нуля (Git + S3) за 40 минут, из них сам mongodb ~4 минуты, остальное — данные. Полностью неквалифицированным Ops-team оператором.

Да, я не лез в дебри MongoDB. Я не знаю особенности настройки реплик или monitoring. По этим граблям прошлись создатели MongoDB charts.

Здравствуйте, Vetal_ca, Вы писали:

S>>А вот для продакшена.... Ну, такое вот. Докер в проде это минус в карму и косые взгляды. Ну, кроме, пожалуй, варианта когда проект гдетотам на сферическом амазоне крутитцца и нужно уметь быстро/автоматически масштабировать мощности в зависимости от нагрузки.

V_>Это сразу, "админ отстал от поезда", собеседование прекращаем.
А я к вам и не собеседовался

V_>имеем девопа, который подымает кластер MongoDB из BitNami MongoDB Charts за минуты (~3-4). Не копаясь в ненужном г-не. Плюс-минус подготовка, подгонка праметров, день, допустим.
Аналогично без докера

V_>Против профессионала старой закалки, который вручную это "на железе" подгоняет. Допустим, старый, без "косых взглядов", стоит раза в 2 дешевле. Но не в 20 же, учитывая реальную скорость!
Зачем "вручную"? С чего это?

V_>Это реальный сценарий. Мало того, так кластер еще и распадается на Sharded-HA setup. Обновить монго, так тут, вообще, целая эпопея.
Один пинок — и всё возвращается на место, можно заодно и обновить следом.

V_>Kubernetes-Clustered, из ссылки выше работает под нагрузкой, ноль проблем. Не распадается. 3 месяца уже как. Пересоздается из бэкапа с нуля (Git + S3) за 40 минут, из них сам mongodb ~4 минуты, остальное — данные. Полностью неквалифицированным Ops-team оператором.
То что вы не осилили нераспадающиеся кластеры и используете чужие знания в виде готовых контейнеров не говорит о том что докер хорош

V_>Да, я не лез в дебри MongoDB. Я не знаю особенности настройки реплик или monitoring. По этим граблям прошлись создатели MongoDB charts.
Я и говорю — не осилили, а используете чужое готовое решение.

Здравствуйте, Sheridan, Вы писали:

S>Здравствуйте, Vetal_ca, Вы писали:

S>А я к вам и не собеседовался

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

S>Аналогично без докера

Давай, пример. Я ссылку на рабочий вариант привел. Без ссылки я уже виждел жалкие потуги

V_>>Против профессионала старой закалки, который вручную это "на железе" подгоняет. Допустим, старый, без "косых взглядов", стоит раза в 2 дешевле. Но не в 20 же, учитывая реальную скорость!
S>Зачем "вручную"? С чего это?

S>Один пинок — и всё возвращается на место, можно заодно и обновить следом.

Пример одного пинка? Только, чтобы реально, одного

cd "$(mktemp -d)" &&\
git clone https://github.com/bitnami/charts.git &&\
cd charts &&\
set_values="mongodbRootPassword={root_pass},mongodbUsername={db_user},mongodbPassword={db_pass},replicaSetKey={replica_key}" &&\
helm template "{env}" --namespace "{ns}" --set mongodbDatabase="{env}" --set "${{set_values}}" \
    --values "{template_file}" bitnami/mongodb-sharded/ | kubectl apply -f -

А то на словах все умелые а по ходу 2 недели с бледным видом

V_>>Kubernetes-Clustered, из ссылки выше работает под нагрузкой, ноль проблем. Не распадается. 3 месяца уже как. Пересоздается из бэкапа с нуля (Git + S3) за 40 минут, из них сам mongodb ~4 минуты, остальное — данные. Полностью неквалифицированным Ops-team оператором.
S>То что вы не осилили нераспадающиеся кластеры и используете чужие знания в виде готовых контейнеров не говорит о том что докер хорош

Старая школа -не осилили. Новая — осилили. Дело сделано.

Подумай, если ли в новом мире старой школе место?

S>Я и говорю — не осилили, а используете чужое готовое решение.

О, типично оторвано-от реальности, айтишное возмущеньице.

Задача сделана, вопрос решен. Это самое главное. Остальное форум-grade бурчание — мусор глубоко под ногами, за которое в кризис никто копейку не даст. Каждый раз надо задаваться вопросом, в чем здесь value для проекта? В переизобретении велосипеда и согревании ЧСВ?

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

Здравствуйте, Sheridan, Вы писали:

S> AB>У меня — да, deb. Но никто не мешает собирать rpm-ки если работаешь с кровавым ынтырпрайзом.
S> А как ты пакетами разруливаешь ситуацию типа "впн по сертификатам, надо добавть юзера -> сгенерировать новый сертификат, настройки для пользовательской винды"?

Данные подобного рода приезжают из inventory. Задача пакета просто привезти обвязку для работы с оным. Конкретно для сертификатов (как для sensitive данных) можно использовать например vault.

S> Или "надо в мониторинг добавить хост, настроив сам хост и настроив коллектор"?

Тут я не очень понимаю суть вопроса. Предположу, что речь идет об auto discovery агентов — например, как это реализовано у zabbix.

Здравствуйте, Vetal_ca, Вы писали:

S>>Аналогично без докера

V_>Давай, пример. Я ссылку на рабочий вариант привел. Без ссылки я уже виждел жалкие потуги
ну вот например. Но я бы предпочёл потратить с неделю на своё, заточенное под реалии проекта, который будет это использовать.
тут и Тут для понимания азов

V_>>>Против профессионала старой закалки, который вручную это "на железе" подгоняет. Допустим, старый, без "косых взглядов", стоит раза в 2 дешевле. Но не в 20 же, учитывая реальную скорость!
S>>Зачем "вручную"? С чего это?
S>>Один пинок — и всё возвращается на место, можно заодно и обновить следом.
V_>Пример одного пинка? Только, чтобы реально, одного
ansible-playbook playbook-mongo.yaml -D

Нервный тик поскипан.

Здравствуйте, Anton Batenev, Вы писали:
Я к тому, что пакетизирование не особо решает проблему деплоя, оно решает только проблему доставки софта/конфигов.
Когда возникает задача при деплое развернуть центр сертификации и его потом использовать для выдачи сертификатов разворачиваемым (на других хостах/облаках) сервисах, то тут уже кмк ой.

Здравствуйте, Sheridan, Вы писали:

S> Я к тому, что пакетизирование не особо решает проблему деплоя, оно решает только проблему доставки софта/конфигов.

Ну так а на хосте и не должно быть ничего кроме софта и конфигов. Или я тебя не понимать.

S> Когда возникает задача при деплое развернуть центр сертификации и его потом использовать для выдачи сертификатов разворачиваемым (на других хостах/облаках) сервисах, то тут уже кмк ой.

Не вижу никаких проблем.

Здравствуйте, Sheridan, Вы писали:

S>Здравствуйте, Михaил, Вы писали:

М>>Просмотри docker.
S>docker это не про настройку инфраструктуры

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

S>docker хорош при разработке, особенно фронтенда. Ну то биш для проекта поднял контейнер с nginx и проектом, контейнер с БД, контейнер с тестами, контейнер с pgadmin, контейнер с dns, контейнер с редиской, контейнер с кроликом, контейнер с мониторингом, контейнер с замоченными "внешними" сервисами и пилишь проект. Закончил работу — опустил контейнеры, поднял контейнеры для другого проекта...

чем apt install/uninstall хуже?

S>А вот для продакшена.... Ну, такое вот. Докер в проде это минус в карму и косые взгляды. Ну, кроме, пожалуй, варианта когда проект гдетотам на сферическом амазоне крутитцца и нужно уметь быстро/автоматически масштабировать мощности в зависимости от нагрузки.

why?

Здравствуйте, Sheridan, Вы писали:

S>ну вот например. Но я бы предпочёл потратить с неделю на своё, заточенное под реалии проекта, который будет это использовать.
S>тут и Тут для понимания азов

Зачем лезть в реалии проекта? Это как доктор одного пациента.

Азы, плюсы и минусы я знаю. Вот, например, нужно добавить тебе mTLS, или swappable log backend. И надо в твою ансибл книгу лезть. Добавим туда какой нибудь SOC-II compliance или network segregation requirements и все, засели намертво.

Потом соберем весь спектр зоопарка операционок и найти для них общий знаменатель?

В общем, "развернутое нутро" vs "blackbox", с ростом сложности первое сливает по экспоненте.

Главный серъезный недостаток Kubernetes это нехватка квалифицированных специалистов.

Здравствуйте, Михaил, Вы писали:

М>>>Просмотри docker.
S>>docker это не про настройку инфраструктуры
М>а что, нельзя в контейнер настройки и все остальное засунуть?
Вместе с контейнерами. Ага.

S>>docker хорош при разработке, особенно фронтенда. Ну то биш для проекта поднял контейнер с nginx и проектом, контейнер с БД, контейнер с тестами, контейнер с pgadmin, контейнер с dns, контейнер с редиской, контейнер с кроликом, контейнер с мониторингом, контейнер с замоченными "внешними" сервисами и пилишь проект. Закончил работу — опустил контейнеры, поднял контейнеры для другого проекта...
М>чем apt install/uninstall хуже?
Для разработки: Когда у тебя таких проектов несколько — со временем оно начинает мешать друг другу. Ну, типа "один легаси проект пользует кролика 1.5 версии а другой хочет 2.8". Задача "на железе" решается тяжко.
Для деплоя: Сделай apt-install'ом развертывание персональных сертификатов от собственного центра сертификации на паре десятков машин.

S>>А вот для продакшена.... Ну, такое вот. Докер в проде это минус в карму и косые взгляды. Ну, кроме, пожалуй, варианта когда проект гдетотам на сферическом амазоне крутитцца и нужно уметь быстро/автоматически масштабировать мощности в зависимости от нагрузки.
М>why?
Потому что это ещё одна шестеренка, которая понижает надёжность системы.

Здравствуйте, Vetal_ca, Вы писали:

S>>ну вот например. Но я бы предпочёл потратить с неделю на своё, заточенное под реалии проекта, который будет это использовать.
S>>тут и Тут для понимания азов
V_>Зачем лезть в реалии проекта? Это как доктор одного пациента.
Потому что возить песок в кабриолете на стройку как то не комильфо.
Я к тому, что "Готовые, универсальные" решения как правило являются монстрами с кучей шестеренок и рычагов (когда рычагов и шестеренок много — это плохо, ненадёжно).
Опять же, разрабатываемый проект может потребовать тюнинга используемого ПО (те-же БД), а нужных рычагов может и не оказаться.
Было у меня на практике — разворачивал ceph клиенту. Готовые решения не подходили по многим причинам (например, ненадёжная связь между нодами). Кастомная роль ансибла оказалась лучшим решением.
Ну и, наконец, создание собственного решения (собственных ролей) не только позволяет получить именно то что нужно кодом малого объёма (читай — простым, понятным), но и поднимает скилл работы с тем ПО которое разворачиваем.

V_>Азы, плюсы и минусы я знаю. Вот, например, нужно добавить тебе mTLS, или swappable log backend. И надо в твою ансибл книгу лезть. Добавим туда какой нибудь SOC-II compliance или network segregation requirements и все, засели намертво.
Не понял что ты хочешь тут сказать... Берём ранее разработанную роль, дописываем в неё таски, разворачиваем... Сложность в добавлении тасков, чтоли? Непонятно как это работает и хочется чорный ящик? Ну такое вот, админы с чорными ящиками работающие как правило еще не закончили школу...

V_>Потом соберем весь спектр зоопарка операционок и найти для них общий знаменатель?
Или ветвить таски в роли в зависимости от операционки. Ну то есть в слаке какой нибудь файлик конфига при деплое пишем в /etc/httpd/httpd.conf а в убунте в /etc/apache2/apache2.conf. Профит в том, что файлик приедет из одного источника.

V_>В общем, "развернутое нутро" vs "blackbox", с ростом сложности первое сливает по экспоненте.
Для программиста черные ящики хороши, бесспорно. Я в первой же песне про докер пел этот куплет. Но двигать это же самое в прод... Не знаю с чем сравнить... Ну вот например — ты пузырьковую сортировку везде используешь или всётаки пытаешься подобрать более походящую под контекст/данные?
В прод проект должен двигать админ/девапс. Который должен выслушать ваши требования и хотелки и реализовать необходимое на выделенные мощности.
Вы вот смеётесь над моим кодом и подходом к программированию. Точно также для админа выглядят попытки программистов админить. Как правило решение выглядит "лишь бы работало".

V_>Главный серъезный недостаток Kubernetes это нехватка квалифицированных специалистов.
Что говорит о том что докер ненужэн. Специалисты и без него прекрасно живут.

Здравствуйте, Sheridan, Вы писали:

S>Потому что возить песок в кабриолете на стройку как то не комильфо.
S>Я к тому, что "Готовые, универсальные" решения как правило являются монстрами с кучей шестеренок и рычагов (когда рычагов и шестеренок много — это плохо, ненадёжно).
S>Опять же, разрабатываемый проект может потребовать тюнинга используемого ПО (те-же БД), а нужных рычагов может и не оказаться.
S>Было у меня на практике — разворачивал ceph клиенту. Готовые решения не подходили по многим причинам (например, ненадёжная связь между нодами). Кастомная роль ансибла оказалась лучшим решением.
S>Ну и, наконец, создание собственного решения (собственных ролей) не только позволяет получить именно то что нужно кодом малого объёма (читай — простым, понятным), но и поднимает скилл работы с тем ПО которое разворачиваем.

S>Не понял что ты хочешь тут сказать... Берём ранее разработанную роль, дописываем в неё таски, разворачиваем... Сложность в добавлении тасков, чтоли? Непонятно как это работает и хочется чорный ящик? Ну такое вот, админы с чорными ящиками работающие как правило еще не закончили школу...

Я к тому, что пока ~~отставшие от поезда~~ чоткие админы старой закалки разберутся и допишут свои таски, рынок уже ушел.

Люди специально разрабатывают компоненты, тратят время. Делают свои операторы (Kubernetes operators) для повторного использования. И некий админ, в процессе глубоко разобравшийся? Да, я видел студентов писавших свою ОС, но, по факту, на этой ОС они не работают. Поэтому идею, что я со всем сам разберусь глубоко воспринимаю с улыбкой.

S>Или ветвить таски в роли в зависимости от операционки. Ну то есть в слаке какой нибудь файлик конфига при деплое пишем в /etc/httpd/httpd.conf а в убунте в /etc/apache2/apache2.conf. Профит в том, что файлик приедет из одного источника.

И так 50 раз для разных компонентов? Потом еще 50 раз на обновление? Кто это будет поддерживать? 50 старых админов по сильному дисконту? Даже электричество не окупится

S>Для программиста черные ящики хороши, бесспорно. Я в первой же песне про докер пел этот куплет. Но двигать это же самое в прод... Не знаю с чем сравнить... Ну вот например — ты пузырьковую сортировку везде используешь или всётаки пытаешься подобрать более походящую под контекст/данные?
S>В прод проект должен двигать админ/девапс. Который должен выслушать ваши требования и хотелки и реализовать необходимое на выделенные мощности.
S>Вы вот смеётесь над моим кодом и подходом к программированию. Точно также для админа выглядят попытки программистов админить. Как правило решение выглядит "лишь бы работало".

Я использую стандартизированный подход. Docker Kubernetes разделяет сложность на подкомпоненты, за стандартными интерфейсами и со стандартными подходами. Намешать все в кучу — тут полный стоп после некоторого, небольшого уровня сложности.

S>Что говорит о том что докер ненужэн. Специалисты и без него прекрасно живут.

На периферии. Где соискатель и собеседующий отстали от поезда. Тут мне знакомый недавно писал, советов по кубернетес просил. Т.к. работодатели требуют от backend разработчика знания в области.

А тут админ ... это... удачи тебе там на тающей льдине

Здравствуйте, Sheridan, Вы писали:

S>А вот для продакшена.... Ну, такое вот. Докер в проде это минус в карму и косые взгляды. Ну, кроме, пожалуй, варианта когда проект гдетотам на сферическом амазоне крутитцца и нужно уметь быстро/автоматически масштабировать мощности в зависимости от нагрузки.
кубер и докер — суровая реальность. в проде в полный рост. а ты продолжаешь быть оторванным от реальности.

Здравствуйте, Farsight, Вы писали:

F>кубер и докер — суровая реальность. в проде в полный рост. а ты продолжаешь быть оторванным от реальности.

В этом-то и есть сила кризисов. Живительная сила голода приобщает оторванных от реальности обратно к прогрессу. Голод — он врожденный рефлекс, а личные тараканы и убеждения — приобретенный, более слабый

Здравствуйте, Sheridan, Вы писали:

М>>а что, нельзя в контейнер настройки и все остальное засунуть?
S>Вместе с контейнерами. Ага.

собрать свой контейнер c нужным ПО и нужными настройками?

М>>why?
S>Потому что это ещё одна шестеренка, которая понижает надёжность системы.

И насколько оно понижает надежность системы, и в чем эта надежность измеряется?

Здравствуйте, Vetal_ca, Вы писали:

S>>Не понял что ты хочешь тут сказать... Берём ранее разработанную роль, дописываем в неё таски, разворачиваем... Сложность в добавлении тасков, чтоли? Непонятно как это работает и хочется чорный ящик? Ну такое вот, админы с чорными ящиками работающие как правило еще не закончили школу...
V_>Я к тому, что пока ~~отставшие от поезда~~ чоткие админы старой закалки разберутся и допишут свои таски, рынок уже ушел.
Рынок никуда не денется. Дискотечный автобус, конечно уедет, но я уже вырос из этого возраста.
А рынку нужны надёжные решения.

V_>Люди специально разрабатывают компоненты, тратят время. Делают свои операторы (Kubernetes operators) для повторного использования. И некий админ, в процессе глубоко разобравшийся? Да, я видел студентов писавших свою ОС, но, по факту, на этой ОС они не работают. Поэтому идею, что я со всем сам разберусь глубоко воспринимаю с улыбкой.
Если у тебя не получилось — значит у всех не получится?

S>>Или ветвить таски в роли в зависимости от операционки. Ну то есть в слаке какой нибудь файлик конфига при деплое пишем в /etc/httpd/httpd.conf а в убунте в /etc/apache2/apache2.conf. Профит в том, что файлик приедет из одного источника.
V_>И так 50 раз для разных компонентов? Потом еще 50 раз на обновление? Кто это будет поддерживать? 50 старых админов по сильному дисконту? Даже электричество не окупится
И так хоть 500 раз для одного компонента, если придётся. И 500 админов тут не нужны. не суди людей по себе.

V_>Я использую стандартизированный подход. Docker Kubernetes разделяет сложность на подкомпоненты, за стандартными интерфейсами и со стандартными подходами. Намешать все в кучу — тут полный стоп после некоторого, небольшого уровня сложности.
Это чотко показывает твою некомпетентность в обсуждаемом вопросе. Ансибл ровно так же разделяет сложность на роли и разделяет каждую роль на цепь ясных и понятных шагов. Ансиблом можно развернуть проект как в контейнерах, так и без оных с тем же самым результатом. А раз результат тот же самый, то лишние компоненты надёжнее выбросить.

S>>Что говорит о том что докер ненужэн. Специалисты и без него прекрасно живут.
V_>На периферии. Где соискатель и собеседующий отстали от поезда. Тут мне знакомый недавно писал, советов по кубернетес просил. Т.к. работодатели требуют от backend разработчика знания в области.
Я уже в поезде, в головных вагонах. И я не вижу вокруг работодателей, которые бегают вслед за модой. Тут работодатели, которым нужна надёжность и проверенные временем решения.

Здравствуйте, Farsight, Вы писали:

S>>А вот для продакшена.... Ну, такое вот. Докер в проде это минус в карму и косые взгляды. Ну, кроме, пожалуй, варианта когда проект гдетотам на сферическом амазоне крутитцца и нужно уметь быстро/автоматически масштабировать мощности в зависимости от нагрузки.
F>кубер и докер — суровая реальность. в проде в полный рост. а ты продолжаешь быть оторванным от реальности.
Я работал раньше с крупными компаниями, у которых свои мощности чуть ли не в каждом городе нашей страны. Ни одного контейнера.
Я сейчас работаю в крупной компании, софт которой используется для критически важных вещей. Тут тоже нет докера.
Странная у вас реальность. Стартапами перебиваетесь?

Здравствуйте, Михaил, Вы писали:

М>>>а что, нельзя в контейнер настройки и все остальное засунуть?
S>>Вместе с контейнерами. Ага.
М>собрать свой контейнер c нужным ПО и нужными настройками?
Я точно так же могу и без контейнера.

Причем даже проще и понятнее, чем описание контейнера.

М>>>why?
S>>Потому что это ещё одна шестеренка, которая понижает надёжность системы.
М>И насколько оно понижает надежность системы, и в чем эта надежность измеряется?
Проведу ликбез. В целом — надёжность системы это функция по надёжности составляющих систему компонентов. Меньше компонентов — выше надёжность. Ты наверняка вычитаешь про параллельное соединение элементов. На что я тебе отвечу что это реализуется и без контейнеров.
Следовательно — использование контейнеров снижает надёжность системы в целом.

Здравствуйте, Sheridan, Вы писали:

S>Рынок никуда не денется. Дискотечный автобус, конечно уедет, но я уже вырос из этого возраста.
S>А рынку нужны надёжные решения.

Да, shmj тебе поставит плюсик, но ты верь. Главное, себя убедить.

S>Если у тебя не получилось — значит у всех не получится?

И к чему ты это написал? Обида? Привыкай, в хвосте не легко

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

(С) Некий Шеридан с Ансиблом

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

V_>>На периферии. Где соискатель и собеседующий отстали от поезда. Тут мне знакомый недавно писал, советов по кубернетес просил. Т.к. работодатели требуют от backend разработчика знания в области.
S>Я уже в поезде, в головных вагонах. И я не вижу вокруг работодателей, которые бегают вслед за модой. Тут работодатели, которым нужна надёжность и проверенные временем решения.

Помню, Негорелое, Беларусь. Там тоже паровозы стояли списанные. Вот там ты и твои работодатели, в головных вагонах. Там все головные, паровозы же.

Только, на свалку их уже увезли, лет 20 как

P.S. Для деплоймента Kubernetes on premises люди больше saltstack используют. Хотя, IMHO, так себе затея кластер поддерживать

Здравствуйте, Sheridan, Вы писали:

S>Я работал раньше с крупными компаниями, у которых свои мощности чуть ли не в каждом городе нашей страны. Ни одного контейнера.
S>Я сейчас работаю в крупной компании, софт которой используется для критически важных вещей. Тут тоже нет докера.
И это о чем-то должно говорить?

S>Странная у вас реальность. Стартапами перебиваетесь?
Конечно. И каждый проваливается из-за контейнеров.

Здравствуйте, Vetal_ca, Вы писали:

S>>Рынок никуда не денется. Дискотечный автобус, конечно уедет, но я уже вырос из этого возраста.
S>>А рынку нужны надёжные решения.
V_>Да, shmj тебе поставит плюсик, но ты верь. Главное, себя убедить.
Что, не нравится? А я и не обещал что будет легко.

S>>Это чотко показывает твою некомпетентность в обсуждаемом вопросе. Ансибл ровно так же разделяет сложность на роли и разделяет каждую роль на цепь ясных и понятных шагов. Ансиблом можно развернуть проект как в контейнерах, так и без оных с тем же самым результатом. А раз результат тот же самый, то лишние компоненты надёжнее выбросить.
V_>(С) Некий Шеридан с Ансиблом

V_>Нет, Ансибл используется, конечно же, для своих задач. Опять же, sjhm- му понятней. Но явно не мейнстрим давно, составная часть, вспомогательный инструмент, не более того. В современном мире явно недостаточно
В современном и любом другом мире явно недостаточно использовать инструмент не понимая как он работает и надеясь что совершенно другие люди всё сделали правильно.
Но ты продолжай верить что крут именно ты.

Здравствуйте, Farsight, Вы писали:

S>>Я работал раньше с крупными компаниями, у которых свои мощности чуть ли не в каждом городе нашей страны. Ни одного контейнера.
S>>Я сейчас работаю в крупной компании, софт которой используется для критически важных вещей. Тут тоже нет докера.
F>И это о чем-то должно говорить?
Сочувствую тем у кого нет слуха и зрения. Печально так жить, когда слышишь только себя.
Да, это должно говорить. Подумай ещё раз.

S>>Странная у вас реальность. Стартапами перебиваетесь?
F>Конечно. И каждый проваливается из-за контейнеров.

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

S>В современном и любом другом мире явно недостаточно использовать инструмент не понимая как он работает

Но ведь именно это ты и делаешь. Постоянно. Используешь инструменты, не понимая, как они работают.

Здравствуйте, Sheridan, Вы писали:

S>Сочувствую тем у кого нет слуха и зрения. Печально так жить, когда слышишь только себя.
S>Да, это должно говорить. Подумай ещё раз.
Ты вот этот поток сознания навалил, потому что у тебя аргументов ноль. Вернее, твоей единственный аргумент — твой же сомнительный опыт.

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

Здравствуйте, Farsight, Вы писали:

S>>Сочувствую тем у кого нет слуха и зрения. Печально так жить, когда слышишь только себя.
S>>Да, это должно говорить. Подумай ещё раз.
F>Ты вот этот поток сознания навалил, потому что у тебя аргументов ноль. Вернее, твоей единственный аргумент — твой же сомнительный опыт.
У тебя вообще аргументов нет, кроме "общеизвестно что..." и "бип... бип..."

Здравствуйте, Sheridan, Вы писали:

S>Здравствуйте, Vetal_ca, Вы писали:

S>>>Рынок никуда не денется. Дискотечный автобус, конечно уедет, но я уже вырос из этого возраста.

Забавно читать, но ты даже не понимаешь причину спора. Дело не в подходе, как таковом.

Понятное дело, подход Google, Uber против похода какого-то там Шеридана. Ну всамом деле, смешно же. Это как в поединке "муха против грузовик на трассе" на муху ставить. Тут достаточно домохозяйкой быть, почитать вакансии на рынке. Все понятно.

Вопрос в том, как так случаются, что люди застревают в своем развитии. Находят оправдания, отстаивают свою точку зрения, при абсолютной очевидности, что позиция маргинальная, прогресс ушел. Осознают ли они это сами, глубоко внутри. Как шел этот процесс, почему он так шел. Как не остановиться в своем развитии и двигаться дальше. Чтобы Кубернетес не стал для меня тем, что такое Ансибл для Шеридана. Чтобы потом списывать увядание и невостребованность на возраст и наклеивать на востребованных ярлык "дискотечный автобус". Это не продуктивно. Я и 30-и летних увядших видел, дело не в возрасте, дело в голове.

Это как читать темы по п..дец типа кто-то там + снотворные таблетки при запое. Или, там, shmj против жены. И в чем притягательность этих тем. Понятное дело, что полный абзац, никто с этим не спорит. Важно, как так случилось и как это обойти.

Вот и с тобой так. Как не остановиться, не заметив окостеневания. Вот в чем суть

Здравствуйте, Sheridan, Вы писали:

S>У тебя вообще аргументов нет, кроме "общеизвестно что..." и "бип... бип..."

Ты прав. Нет. Но в этом виноват ты сам. Тебе не нужны аргументы, которые противоречат твоему обширному опыту и фантазиям. Ты их либо игнорируешь, либо выворачиваешь наизнанку в удобную тебе плоскость. В прошлый раз я в числе многих тебе приводил пример с отчетами в excel. Результат? "ниасилили отчеты, отчеты ДОЛЖНЫ БЫТЬ ЗАВЕРШЕННЫМИ, админ жену увел?". Я искренне удивляюсь терпению некоторых персонажей на форуме, которые продолжают что-то аргументировать в споре с тобой.

Здравствуйте, Farsight, Вы писали:

S>>У тебя вообще аргументов нет, кроме "общеизвестно что..." и "бип... бип..."

F>Ты прав. Нет. Но в этом виноват ты сам. Тебе не нужны аргументы, которые противоречат твоему обширному опыту и фантазиям. Ты их либо игнорируешь, либо выворачиваешь наизнанку в удобную тебе плоскость. В прошлый раз я в числе многих тебе приводил пример с отчетами в excel. Результат? "ниасилили отчеты, отчеты ДОЛЖНЫ БЫТЬ ЗАВЕРШЕННЫМИ, админ жену увел?". Я искренне удивляюсь терпению некоторых персонажей на форуме, которые продолжают что-то аргументировать в споре с тобой.

Ну аргументов я так и не дождался. Что и следовало ожидать. Нет аргументов -> переход на личности -> профит. Нормальная позиция, чо.

S>Ну аргументов я так и не дождался.

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

Здравствуйте, Sheridan, Вы писали:

S>Ну аргументов я так и не дождался. Что и следовало ожидать. Нет аргументов -> переход на личности -> профит. Нормальная позиция, чо.
Я тебе в предыдущем сообщении подробненько расписал, почему их нет. Ну расскажу я тебе, как мы используем контейнеры для разработки и деплоя нашего решения. Но ты скажешь "ансибл ниасилили". Смысл?

Здравствуйте, Farsight, Вы писали:

S>>Ну аргументов я так и не дождался. Что и следовало ожидать.
Тут, что ли? Или тут?
Где?

Здравствуйте, Sheridan, Вы писали:

S>>>Ну аргументов я так и не дождался. Что и следовало ожидать.
S>Тут, что ли? Или тут?
S>Где?
Еще потом говоришь людям, что они читать не умеют. Я же уже написал, что НИГДЕ. Написал, почему НИГДЕ.

Здравствуйте, Farsight, Вы писали:

S>>>>Ну аргументов я так и не дождался. Что и следовало ожидать.
S>>Тут, что ли? Или тут?
S>>Где?
F>Еще потом говоришь людям, что они читать не умеют. Я же уже написал, что НИГДЕ. Написал, почему НИГДЕ.

Дык ясно почему не написал. Нет у тебя аргументов. И поэтому на личности переходишь.

Первый верующий в докер — сдулся. Несите следующего.

Здравствуйте, Sheridan, Вы писали:

S>Дык ясно почему не написал. Нет у тебя аргументов. И поэтому на личности переходишь.

S>Первый верующий в докер — сдулся. Несите следующего.

Ты, главное, верь.

Здравствуйте, Sheridan, Вы писали:

S>Первый верующий в докер — сдулся. Несите следующего.

Кто ты такой, что тебе подносить?

Махнул рукой на Шеридана, и не только я один. Вот поставь себя на место других, зачем кому-то переубеждать какого-то упертого человека? Зачем, если это никак не влияет на свою жизнь и решения? Сам выкарабкивайся, это твоя личная трагедия. Твоя и государства, как трудоустроить людей, не желающих развиваться, но по прежнему желающих есть.

Опять же, надо же кому-то и на периферии ОС устанавливать и картриджи заправлять.

Здравствуйте, Vetal_ca, Вы писали:

S>>Первый верующий в докер — сдулся. Несите следующего.
V_>Кто ты такой, что тебе подносить?

Господин, не трудитесь, холопы не стоят вашего величайшего внимания. Зачем вы им вообще пишете?

V_>Махнул рукой на Шеридана, и не только я один. Вот поставь себя на место других, зачем кому-то переубеждать какого-то упертого человека? Зачем, если это никак не влияет на свою жизнь и решения? Сам выкарабкивайся, это твоя личная трагедия. Твоя и государства, как трудоустроить людей, не желающих развиваться, но по прежнему желающих есть.
Покажи где меня убеждают тут?
Всё что я тут вижу — оскорбления и чтототипа "общеизвестно что..." или "для разработки — круто", причом с последним я не спорю.
Ты так вообще с оскорблений зашол.
То что ты монгу осилил об докер и не осилил без докера — говорит только о твоих способностях. Но ты начинаешь судить о других исходя из собственного опыта. (Заметь, я из собственного опыта сужу о распространённости докеров. А ты судишь о моих навыках.) Более того, ты даже отметаешь саму возможность развернуть монгу без докера, что просто глупо. Ты вообще прямым текстом говоришь "я за блакбокс", что явно читается как "я не хочу ничего изучать, я буду использовать чужой труд". Безотносительно докера такой подход никуда не годится. Инженеры так не желают. Работаешь с чемто — будь добр, выясни как это работает, какие границы применения. Не надо назубок и экзамены. Надо — почитать пару статей, провести пару экспериментов если вопросы возникли. Словил ошибку — выясни что к ней привело и как такого больше не допустить.
Только после того, как ты начнешь применять инженерный подход на практике — ты начнёшь расти как специалист.
Думаешь я в докер не умею? Умею я докер. В кубернетес пока не заглядывал, а об композ вполне себе поднимаю время от времени набор контейнеров под некоторые проекты.

Я понимаю, что фронтендерам кишки особо не нужны, они ближе к художникам, чем к инженерам. Но чёрт побери, ты же зарабатываешь этим деньги, ты же должен быть заинтересован в росте качества своей работы.

V_>Опять же, надо же кому-то и на периферии ОС устанавливать и картриджи заправлять.
Верь в это, тешь своё самолюбие

Здравствуйте, Sheridan, Вы писали:

S>Здравствуйте, Vetal_ca, Вы писали:

S>>>Первый верующий в докер — сдулся. Несите следующего.
V_>>Кто ты такой, что тебе подносить?

S>Господин, не трудитесь, холопы не стоят вашего величайшего внимания. Зачем вы им вообще пишете?

V_>>Махнул рукой на Шеридана, и не только я один. Вот поставь себя на место других, зачем кому-то переубеждать какого-то упертого человека? Зачем, если это никак не влияет на свою жизнь и решения? Сам выкарабкивайся, это твоя личная трагедия. Твоя и государства, как трудоустроить людей, не желающих развиваться, но по прежнему желающих есть.
S>Покажи где меня убеждают тут?
S>Всё что я тут вижу — оскорбления и чтототипа "общеизвестно что..." или "для разработки — круто", причом с последним я не спорю.
S>Ты так вообще с оскорблений зашол.
S>То что ты монгу осилил об докер и не осилил без докера — говорит только о твоих способностях.

Твои способности читать явно ограничены.

Пишу, как для человека с ограниченными способностями к пониманию, раз так:

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

У меня работает Seafile — я в нем не копался. Понимаешь? Wordpress для сайта сестры, зачем тратить жизнь на все это?
Я не копался в настройке своего SAS контроллера на домашнем сервере, docker-megacli. Вызываю по Crl-R, "mega", выпадает "docker run --rm -ti --privileged kamermans/docker-megacli /megacli/show_summary"

Я могу разобраться, но выбираю не копаться в ненужном, при этом программы замечательно работают день и ночь, 24/7.

Это ключевое. Технологии, автоматизация позволяют поднять эффективность, если не застревать в личном развитии. И отсеивать второстепенное, концентрируясь на главном.

S>Покажи где меня убеждают тут?

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

Здравствуйте, Vetal_ca, Вы писали:

V_>Я могу разобраться, но выбираю не копаться в ненужном, при этом программы замечательно работают день и ночь, 24/7.

Ты не инженер. Ты не заинтересован в качестве результата. Работает — и ладно.

Здравствуйте, Sheridan, Вы писали:

S>Ты не инженер. Ты не заинтересован в качестве результата. Работает — и ладно.

Хорошо, 1 пункт ты понял.

Второй, дублирую.

"Ты-ж инженеры" старой школы у нас тоже есть. Они потратили много времени на ручную установку MongoDB. И предупреждали, что у них есть разные проблемы,кластер периодически разваливается и т.п. Не говоря уже про то, что времени это заняло много.

По факту, на кубернетес с контейнерами это получилось быстро, хорошо, не разваливается.

И вот, сдаем мы работу. У местных Шериданов тезис точно такой: "Ты не заинтересован в качестве результата. Работает — и ладно.". Но на деле, плохо и разваливается. Тут хоть 1000 раз на форуме напиши, а в продакшн ставят то что работает.

На кубернетес -не разваливается. Я это объясняю тем, что люди профессионально доводят до ума, занимаются именно своим вопросом. Сделали правильный Dockerfile, Helm Chart. В данном случае, это создатели Bitnami charts и Dockerfile. А, если надо, то и Кубернетес оператор. Google & SIGs профессионально другие люди. А я это профессионально собираю.

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

И работодатели это понимают и принимают, благо насмотрелись на старых админов, хватит уже.

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

Не качественнее оно, проверенно жизнью. Чтобы было быстро и качественно, специализация нужна.

Здравствуйте, Vetal_ca, Вы писали:

V_>Второй, дублирую.
V_>"Ты-ж инженеры" старой школы у нас тоже есть. Они потратили много времени на ручную установку MongoDB. И предупреждали, что у них есть разные проблемы,кластер периодически разваливается и т.п. Не говоря уже про то, что времени это заняло много.
Замените, эти негодные. Кстати, "много" это сколько? А то вдруг окажется что пара часов...

V_>По факту, на кубернетес с контейнерами это получилось быстро, хорошо, не разваливается.
Вот что бывает, когда делают годные инженеры. Рраз — и работает. Замените админов на непротухших.

V_>И вот, сдаем мы работу. У местных Шериданов тезис точно такой: "Ты не заинтересован в качестве результата. Работает — и ладно.". Но на деле, плохо и разваливается. Тут хоть 1000 раз на форуме напиши, а в продакшн ставят то что работает.
Когда надо сдавать а сдавать нечего — понятное дело что всё что угодно сгодится

V_>И работодатели это понимают и принимают, благо насмотрелись на старых админов, хватит уже.
На старых — не насмотрелись. На молодых-горячих — да. Даже у тебя в печонках.

V_>В итоге, в продакшн идут готовые "микросхемы". А не локальные поделки, в стиле "Я не белоручка, сейчас я эту микросхему на транзисторах сваяю, каждый транзистор индивидуально подберу, будет качественнее".
Оооо, пошли агалогии. Давай ещо машину с переборкой движка вспомни.

V_>Не качественнее оно, проверенно жизнью. Чтобы было быстро и качественно, специализация нужна.
Верно. И есть специальные люди, специализированные на деплое: админы/девапсы. Не программисты, нет. Программисты специализируются на написании кода.

	От:	Shmj
	Дата:	03.05.20 14:44
	Оценка:

	От:	Михaил
	Дата:	03.05.20 15:26
	Оценка:

	От:	Shmj
	Дата:	03.05.20 17:27
	Оценка:

	От:	kov_serg
	Дата:	03.05.20 19:21
	Оценка:

От:	netch80	http://netch80.dreamwidth.org/
Дата:	03.05.20 19:49
Оценка:	+2

От:	Anton Batenev	https://github.com/abbat
Дата:	03.05.20 21:06
Оценка:

От:	Pzz	https://github.com/alexpevzner
Дата:	03.05.20 21:41
Оценка:

	От:	Zhendos
	Дата:	04.05.20 10:12
	Оценка:	2 (1) +2

	От:	Дядюшка Ау
	Дата:	04.05.20 11:04
	Оценка:

	От:	Sheridan
	Дата:	07.05.20 08:00
	Оценка:	2 (1) -3

От:	Vetal_ca	http://vetal.ca
Дата:	07.05.20 16:06
Оценка:

От:	Mamut	http://dmitriid.com
Дата:	09.05.20 08:19
Оценка:	+1

	От:	scf
	Дата:	06.05.20 06:37
	Оценка:

	От:	Farsight
	Дата:	08.05.20 20:09
	Оценка: