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