Как стать автором
Обновить
0
0

DevOps, Solutions Architect

Отправить сообщение
Тут такое, если говорить по уровням мониторинга, то по большому счету их не так много:
1. Метрики железа (как раз условный NRPE\Nagios, NodeExporter\Prometheus и аналоги)
2. Метрики условных томкатов и т.п., то есть мониторинг приложений, времени ответа API например
3. Мониторинг бизнес-процесса, который реализуется с помощью ПО, например очередь заявок на обработку и т.п.

И что касается аутсорса, то первые два уровня, действительно, довольно просто отдать, но вот третий уровень это как раз взаимодействие разработки, системных администраторов и т.д., иначе говоря DevOps история, где важен работающий продукт\результат. Здесь уже мало дать доступ на сервер и знать как написать конфиг, здесь нужно понимать что происходит в вашей системе «под капотом», тут аутсорс вряд ли ответит на все вопросы.
А еще:
1. сборку статики лучше сделать отдельно в предстоящих шагах CI, и в контейнер забрать готовую — Сборка отдельно \ продакшн отдельно

2. скриптом запускать всё же как-то не камильфо, стартуем 1 процесс

3. а точно ли нам нужен целый образ большой убунты? пока так не выглядит
Мало написать плейбуки\кукбуки и что угодно еще, гораздо сложнее сделать так, чтобы все изменения выполнялись через систему контроля версий и только через SCM. Учитывая самый низкий порог вхождения, Ansible — фаворит, ибо настолько всё прозрачно и просто, что въехать в тему может за пару дней почти любой специалист.
Разработать бы ИИ способную разбирать почерк врачей в карточках и рентгенах. Вот это ценность была бы для отечественной медицины!

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

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

PS Извините уж за мой однобокий взгляд на Alpine.
Ну не знаю, после танцев с настройками приложений в Alpine для себя решил, что Alpine буду использовать только для сборки контейнеров (где процессы как правило воспроизводимы и более-менее типичны), а вот сами контейнеры уже на машине с CentOS\RHEL\Ubuntu\чем-угодно-полноценным. По крайней мере пока.

В общем история про микроскоп и гвозди работает в обе стороны.
сделать следующую структуру:

/project_cat
  • node_modules/
  • app_sources/
  • package.json


package.json
  "scripts": {
    "start": "node server.js"
  },
К сожалению, с k8s в локальной инфраструктуре, все действительно не так просто, если говорить про HA развертывание с несколькими мастерами, kubeadm до сих пор разворачивает только кластер с 1 мастером, kubespray тот еще самолет с огромным количеством багов (печальный опыт и количество issue на GitHub от других испытателей), kops не дружит с Bare Metal, так что это проблема. Если есть удачный опыт в этой части буду крайне признателен.

Но при этом относительно Swarm Kubernetes — просто следующий уровень, лично я большой его фанат.

Информация

В рейтинге
Не участвует
Откуда
Россия
Дата рождения
Зарегистрирован
Активность