Как установить надлежащий контроль моих сервисов автоматизированным способом? Так, чтобы, если один катастрофический отказ это автоматическое включение перезапуски мухи?

Более позднее редактирование: только этот делает то, в чем нуждается январь: спасибо Гюйгенс;

find . -exec file {} \; | grep -i elf

3
14.05.2013, 17:46
5 ответов

Существуют различные инструменты, чтобы сделать это (которых, кроме daemontools и perp, у меня нет большого опыта с):

  • daemontools более или менее "классическая" реализация, которая породила большинство других современных реализаций
  • supervisord
  • minit
  • s6
  • runit

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

4
27.01.2020, 21:11
  • 1
    , "поощренный" или "порожденный", не "поощренный", конечно? И наличие большего количества инструментов в инструментарии не обязательно делает инструментарий неподходящим. Это - то, что делают отдельные инструменты. большое спасибо –  JdeBP 04.01.2015, 19:41
  • 2
    @JdeBP Это - опечатка для "порожденного", благодарит сообщить мне для исправления его! :-) –  Chris Down 04.01.2015, 21:04

В дополнение к тому, что записал Chris Down, я также рекомендую monit. Это может особенно проверить, если порт, если открытый (например, 80) и перезапускают соответствующий сервис (например, httpd), если этот порт закрывается. Посмотрите этот пример для sshd:

check process sshd with pidfile /var/run/sshd.pid
start program  "/etc/init.d/sshd start"
stop program  "/etc/init.d/sshd stop"
if failed port 22 protocol ssh then restart
if 5 restarts within 5 cycles then timeout

Monit использует другой подход, чем perp или daemontools: это не только гарантирует, что процесс выполняет, а скорее проверяет, является ли порт открытым портом или если файл существует (мог бы быть сокет UNIX). Могло быть легче настроить и немного менее навязчивый (Вы не должны удостоверяться, что monit правильно взаимодействует с Вашей init системой), чем daemontools или perp. Это может также быть настроено для отправки электронных писем, если этому постоянно не удается перезапустить сервис.

1
27.01.2020, 21:11
  • 1
    На самом деле действительно необходимо удостовериться, что это правильно взаимодействует с init системой. Они start program и stop program строки в Вашем примере - то, где он взаимодействует с Вашей init системой, и по иронии судьбы они будут проблематичны с init системами кроме Системы 5 rc. (Нет никакой гарантии, что собственный systemd SSH сервис будет startable или stoppable таким образом всего для одного примера.) –  JdeBP 04.01.2015, 19:39

Существует также Бог.

Бог является легким для конфигурирования, легкий расширить контролирующую платформу, записанную в Ruby.

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

Запишите простой сервер, simple.rb:

loop do
  puts 'Hello'
  sleep 1
end

Теперь создайте сценарий, simple.god, это наблюдает за демоном:

God.watch do |w|
  w.name = "simple"
  w.start = "ruby /full/path/to/simple.rb"
  w.keepalive
end

Теперь запустить контролирующий сценарий:

god -c path/to/simple.god -D

Бог может наблюдать больше, чем просто рубиновые приложения, это могло наблюдать Ваш httpd или mysqld и названный соответствием /etc/init./d/... напишите сценарий по мере необходимости.

0
27.01.2020, 21:11

Марионетка позволяет Вам определять, какие сервисы должны работать на Вашей системе.

Марионетка является программным обеспечением автоматизации IT, которое помогает системным администраторам управлять инфраструктурой в течение ее жизненного цикла от настройки и конфигурации к управлению исправлениями и соответствию. Используя Марионетку, можно легко автоматизировать повторяющиеся задачи, быстро развернуть важные приложения и заранее управлять изменением, масштабирующимся с 10-х серверов к 1000-м, на месте или в облаке.

Например:

service { 'apache2':
    ensure => running,
    enable => true,
    require => Package['apache2'],
    subscribe => File['/etc/apache2/httpd.conf'],
}

Эта конфигурация (названный декларацией в контексте Марионетки) удостоверится apache2 услуга работает, который она запускает во время начальной загрузки, что она не пытается справиться с сервисом если apache2 пакет установлен, и что он перезапускает если /etc/apache2/httpd.conf изменяется.

С Марионеткой можно не только справиться с сервисными процессами, но также и их зависимостями и конфигурационными файлами.

1
27.01.2020, 21:11

Корневой каталог (/root/) не должен содержать ничего, и обычно его содержимое поступает из программ, выполняемых пользователем root , которые сохраняют свои предпочтения/историю/whatnot для последующего повторного использования.

в соответствии с предложением других пользователей, .bashrc и .profile , возможно, необходимо сохранить.

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

Если вы не знаете, что некоторые из этих выполненных программ могут содержать необходимую информацию или настройки, вы можете удалить их содержимое без проблем, в противном случае просто создайте копию желаемого, прежде чем стирать все (что-то в соответствии с tar -cvjpf/mnt/backup/backup-root- $ (дата +% F-% H-% M) .tar.bz2 ~/

-121--217492-

Имеется космос между «ro» и «remount». Попробуй без этого места.

-121--217496-

Как упоминалось в других ответах, daemontools Дэна Бернстайна начали целое семейство наборов инструментов, которые используют одни и те же исходные механизмы:

Под в значительной степени любым из них, каждый пишет пробег программа, которая управляет / dæmon, и процесс менеджера по сервису или наблюдателя просто контролирует его как разветвленный дочерний процесс, используя нормальный механизм Unix и Linux. Для Apache и MySQL вы занимаетесь тем, где много людей раньше попирали, и есть много примеров того, как запустить эти серверы под управлением daemontools-family service management. Вот лишь некоторые:

Крис Даун (Chris Down) предполагает, что более крупные наборы инструментов могут оказаться неподходящими. На самом деле это не так. Хотя все эти инструменты являются согласованными и самосогласованными, ни один из них не требует, чтобы один из них использовал какие-либо другие инструменты, кроме тех, которые необходимы в любой конкретной ситуации. Можно также смешать и сопоставить. Можно использовать execlineb Лорана Берко и все его утилиты под руководством исполнителя, или мой nosh интерпретатор сценариев и все его утилиты под управлением; точно так же, как можно в равной степени использовать chpst Геррита Папе под моим сервисным менеджером .

Одинаково,Вы можете запустить Apache и MySQL из systemd (только для Linux) или запустить (если вы используете MacOS 10). Файл конфигурации запуска является довольно сложным и громоздким по сравнению с другими упомянутыми системами. системные файлы единиц, однако, находятся в том же порядке простоты, что и запускать скрипты:

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

Все они обеспечивают базовую основу для запуска dâmon при bootstrap, остановки и запуска под управлением администратора/автоматизированного управления во время работы системы и автоматического перезапуска в различных случаях отказа. Xion345 делает ошибку, объединяя это с монитом. Как видно из ответа xyr, подложкой для мониторинга и управления является dâmon System 5 rc . В равной степени это могла быть система или нос. (На самом деле, если бы в примере Xion345 использовалась команда service вместо того, чтобы пытаться запускать скрипты init.d напрямую, что не является хорошей идеей по этой и нескольким другим причинам, она бы работала практически как есть с systemd, upstart или nosh.)

Где монит принадлежит в слое выше . monit использует подложку запуска/остановки/контроля и контролирует фактически предоставленную услугу , которая в дополнение к осуществляет контроль процесса dâmon с помощью dâmon supervisor. На этом слое можно найти связанные инструменты, такие как nagios. (Можно довольно легко поместить nagios в daemontools-family-monitored diremon, и проверить состояние процесса и время работы через daemontools API. Мой набор инструментов для носа даже поставляется с одним базовым наджиосом для этого.)

2
27.01.2020, 21:11

Теги

Похожие вопросы