По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Итак, вы хотите стать DevOps-инженером? Это впечатляющий, сложный и высокооплачиваемый вариант карьеры, но такая ключевая роль объединяет разработку программного обеспечения и его эксплуатацию. Мы составили дорожную карту DevOps, которая включает в себя все шаги, которые необходимы для того, чтобы занять место эксперта DevOps.
Как вы знаете, DevOps – это набор практик и инструментов для интеграции и автоматизации процессов между IT-командами и командами разработчиков программного обеспечения. Поэтому он фокусируется на общении и сотрудничестве между командами, используя лучшие инструменты автоматизации, доступные для повышения эффективности.
Следующий акцент делается на объединении тех, кто работает в области разработки программного обеспечения с развертыванием ПО, а также на обеспечении высокого уровня структурной и технической поддержки.
Это все означает, что DevOps-инженеры должны знать свое дело, чтобы справиться с этой неподъемной задачей. А что же тогда такое «их дело»? Оказывается, что это не просто их дело, но и дело всех остальных.
Конечно, это может звучать, как что-то невероятное, что мало кто может преодолеть. DevOps-инженеры действительно являются экспертами высокого уровня, и стать одним из них также практически невозможно. Вместе с тем, данное руководство поможет вам четко понять, какие шаги необходимо предпринять, прежде чем начать свое путешествие по DevOps.
Давайте посмотрим.
Зачем вам нужна дорожная карта DevOps?
В нашей статье о DevOps рассказывается о том, почему стать DevOps-инженером так сложно, ведь DevOps-команды включают в себя разработчиков и IT-специалистов, работающих рука об руку на протяжении всего жизненного цикла проекта.
И поэтому, дорожная карта DevOps предполагает высокие навыки и необходимые шаги, которые помогают повысить скорость и качество разработки и развертывания и предотвратить организационную разрозненность. Иногда команды объединяются, чтобы максимизировать эффективность, при этом инженеры работают на протяжении всего жизненного цикла продукта или приложения.
Итак, каковы же эти требования? Вот этот исчерпывающий список для того, чтобы получить эту дорожную карту, которая направит вас на верный путь.
Как стать DevOps-инженером за 14 шагов
1. Изучайте языки программирования
Первый шаг к тому, чтобы стать DevOps-инженером, - это владение одним или несколькими языками программирования. Конечно, вы не будете интегрировать базы данных или автоматизировать процессы разработки и развертывания, отлаживать базы данных, отлаживать код и исправлять возникающие проблемы, но в результате вы должны внести свой вклад в поддержание конвейера непрерывной интеграции/поставки в рабочем состоянии.
Если вы читаете эту статью, то мы можем предположить, что вы владеете хотя бы одним из «больших» языков программирования, таких как Java, JavaScript или Python. Но если все же нет, то мы рекомендуем вам повысить уровень знания до высокого как минимум двух или трех языков программирования из списка ниже:
Python
Perl
Java
JavaScript
Go
Ruby
Rust
C
C++
2. Научитесь работать с разными ОС
DevOps-инженеру необходимо знать, как работают разные операционные системы, а также различия между ними, в основном потому, что вы будете запускать приложения на серверах. В связи с этим, оптимальным решением для такого рода вещей, как правило, является Linux – ее используют большинство компаний и поставщиков серверов. Если вы используете веб-приложение, то оно, вероятнее всего, находится на сервере Linux.
Есть и другие операционные системы, которые не помешает знать:
Windows
Unix
Debian
SUSE Linux
Fedora
Ubuntu
CentOS
RHEL
macOS
FreeBSD
OpenBSD
NetBSD
3. Концепция ОС
Так вот, операционные системы – это лишь часть дорожной карты DevOps. Также вы должны быть в состоянии углубиться, понимая базовую инфраструктуру ОС, которая позволяет вам запускать приложение. Это называется «концепцией операционной системы», и вы должны быть знакомы с:
Управлением запуском
Управлением процессом
Сокетами
Front-end разработкой
Потоками и параллелизмом
Управлением вводом/выводом
Основами POSIX
Виртуализацией
Файловыми системами
Памятью и хранилищем
Управлением службами
Сетью
4. Сетевая безопасность и протоколы
Как DevOps-инженер, вы должны быть всегда спокойны. Сетевая безопасность и протоколы помогут вам обеспечить целостность и безопасность ваших данных. Они определяют процессы и методологии, которые вы будете использовать для защиты вашей сети от попыток несанкционированного доступа.
Вот протоколы, о которых вам следует знать:
HTTP
HTTPS
FTP
Межсетевые экраны
SSH
SSL/TTS
IPsec и VPN
Переадресация портов
AT-TLS
SNMP
Аутентификация OSFP
Прокси-доступ
5. Терминалы – ваш новый дом
Консоль позволяет разработчикам автоматизировать, создавать сценарии и выполнять системные задачи без использования графического пользовательского интерфейса.
В следствие чего, вы должны уметь работать с текстом, создавать bash-сценарии, отслеживать процессы, производительность системы, работать в сети, компилировать приложения из исходника, Vim, Nano, Emacs и Powershell.
Мы готовы поспорить, что, если вы уже привыкли, и вам удобно, создавать файлы .cfg в выбранной вами FPS, то здесь вы будете как дома. И вам в любом случае нужно будет это делать.
6.Веб-серверы
Когда пользователь запрашивает информацию, сервер выполняет запрос. На веб-сервере может размещаться один или несколько веб-сайтов с использованием одного и того же оборудования и ресурсов. Он взаимодействует с веб-браузером через HTTP/HTTPS. Быть DevOps-инженером означает знать, как контролировать сервер.
Вот некоторые распространенные веб-серверы, о который вам стоит узнать:
Apache
Nginx
IIS
Tomcat
Caddy
Istio
Envoy
Consul
Linkerd
7. Инструменты непрерывной интеграции/непрерывной поставки
Конвейер непрерывной интеграции/поставки (CI/CD) необходим для разработки программного обеспечения в рамках DevOps. Как было сказано в предыдущей статье, непрерывная интеграция – это методика разработки программного обеспечения, при которой разработчики объединяют все изменения кода, которые они вносят, в единый репозиторий.
В то время как, непрерывная поставка реализует изменения кода, которые автоматически создаются, тестируются и подготавливаются в производственному выпуску. Ее можно рассматривать как расширение непрерывной интеграции.
Вот некоторые из инструментов, которые вы можете использовать для этой цели:
TravisCI
GitHub
GitLab
Bamboo
Jenkins
TeamCity
Azure DevOps
8. Изучите инфраструктуру как код (IaC)
Пожалуй, это одно из основных направлений работы DevOps-инженеров. Поэтому неудивительно, что эта тема довольно обширная и разнообразная. Знание таких контейнеров, как Kubernetes и Docker, а также различных инструментов управления конфигурацией имеет жизненно важное значение для вашего собственного развития и успеха проектов, которые вы возглавляете.
Вот некоторые DevOps-инструменты, о которых вам следует знать:
Docker
Containers
LXC
Ansible
Salt
Chef
Puppet
Mesos
Kubernetes
Docker Swarm
Nomad
Istio
Service Mesh
Linkerd
Consul Connet
Maesh
Kuma
Terraform
9. Управление приложениями
Управление приложениями относится к процессу измерения доступности, возможностей и производительности приложения. Данные, собираемые в процессе, позволяют выявлять и устранять баги и ошибки до того, как у пользователей возникнут проблемы. Обычно используется такое программное обеспечение, как:
AppDynamic
Instana
New Relic
Jaeger
OpenTracing
10. Управление инфраструктурой
Эта часть дорожной карты DevOps влечет за собой процесс получения как можно большего количества данных о вашей инфраструктуре с целью принятия обоснованных оперативных решений.
В этой связи, используются данные, генерируемые помимо прочего приложениями, серверами и сетевыми устройствами, с целью отслеживание таких показателей, как мощность оборудования, пропускная способность сети и время работоспособности. В свою очередь, эта информация помогает повысить эффективность и устранять ошибки, показывая, какие области требуют большего внимания.
Вот некоторые хорошие инструменты для управления инфраструктурой:
Grafana
Prometheus
Zabbix
Nagios
Datadog
11. Шаблон облачного проектирования
Этот шаблон помогает создавать масштабируемые, надежные и безопасные приложения в облаке. Однако для этого необходимо быть знакомым с одним ли несколькими шаблонами облачного проектирования. На наш взгляд, одними из самыми важными являются следующие:
Источники событий
Посредник
CQRS
Агрегирование на шлюзе
Консолидация вычислительных ресурсов
Внешнее хранилище конфигурации
Уровень защиты от повреждений
Каналы и фильтры
Перенесение в шлюз
Маршрутизация шлюза
Расширение за счет внешних устройств
12. Управление логами
Логи помогают составлять список событий, происходящих в системе, и изучать их детали. Благодаря этому, управление журналами поможет вам, то есть начинающему DevOps-инженеру, улучшить службы и процессы, предотвратить уязвимости и выявить узкие места.
Вот некоторые из инструментов, которые вы так или иначе будете использовать:
Splunk
Elastic stack
Graylog
Papertrail
13. Поставщики облачных услуг и пакеты услуг
Как мы уже поняли, облачные услуги – это то, с чем обязательно нужно быть знакомым DevOps-инженеру. Кроме того, вам необходимо понимать преимущества и особенности каждого поставщика облачных услуг для того, чтобы ваша организация могла сделать верный осознанный выбор. Некоторые из популярных заслуживают того, чтобы их изучили, например:
Google Cloud
AWS
Azure
Digital Ocean
Linode
Alibaba
Конечно, стоит отметить, что эти провайдеры редко работают по фиксированной стоимости. Как правило, цены на эти услуги зависят от необходимого количества доменов и памяти и SSL-сертификатов, требуемых ЦП.
14. Другие технологии
Это лишь краткий список того, что вам нужно сделать, чтобы получить знания на пути к тому, чтобы стать DevOps-инженером.
Таблица кэша
Обратный прокси-сервер
Прокси-сервер переадресации
Межсетевой экран
Балансировка нагрузки
Сервер кэширования
Заключение
Дорожная карта DevOps предназначена для того, чтобы направить вас на правильный путь к профессиональным навыкам DevOps. Конечно, это не означает, что он уже устоявшийся и не подлежит изменению. Технологии меняются ежедневно, и вы должны постоянно быть в курсе новых инструментов и решений. Еще один пункт на пути к становлению DevOps-инженером – это обучение и адаптация, и, пожалуй, самое важное – хорошо выполнять свою работу.
Если вы следуете этой дорожной карте и у вас уже есть солидная база знаний в области компьютерных наук, то вам потребуется всего каких-то шесть месяцев для того, чтобы сдвинуться с той точки, в которой вы сейчас, и дойти до начала своей карьеры DevOps-инженера.
Не забудьте добавить следующие пункты в список того, что нужно выучить:
Языки программирования
Концепции ОС
Терминалы
Сеть и безопасность
Инструменты CI/CD
Веб-сервер
Инфраструктура как код
Управление приложением
Управление инфраструктурой
Шаблон облачного проектирования
Управление журналом
Поставщики облачных услуг и управление службами
Другие технологии
Часто задаваемые вопросы
Чем занимается DevOps-инженер?
DevOps-инженер использует инструменты, процессы и методологии, чтобы удовлетворить все потребности в процессе разработки программного обеспечения, разработки оболочки пользовательского интерфейса и кодирования для развертывания, обслуживания и обновлений.
Сколько времени нужно, чтобы стать DevOps-инженером?
Если у вас уже есть опыт работы с Linux и сетями, и вы следуете дорожной карте DevOps-инженера, то это займет примерно шесть месяцев.
Что такое CI/CD в DevOps?
Это передовая методология DevOps, которая использует автоматизацию разработки приложений, позволяя увеличить скорость разработки и развертывания приложений. CI/CD относится к непрерывной интеграции, поставке и развертыванию.
Метрические веса TOS K1 K2 K3 K4 K5, выданные командой в режиме конфигурации маршрутизатора EIGRP, может быть использована для установки K-значений, используемых EIGRP в своем расчете. Параметр TOS был предназначен для использования маркировки качества обслуживания (где TOS обозначает тип служебного байта в заголовке IPv4). Однако параметр TOS должен быть равен 0. На самом деле, если вы введете число в диапазоне 1 - 8 и вернетесь назад, чтобы изучить свою текущую конфигурацию, вы обнаружите, что Cisco IOS изменила это значение на 0. Пять оставшихся параметров в команде metric weights - это пять K-значений, каждое из которых может быть задано числом в диапазоне от 0 до 255.
Предыдущие статьи из цикла про EIGRP:
Часть 1. Понимание EIGRP: обзор, базовая конфигурация и проверка
Часть 2. Про соседство и метрики EIGRP
Следующие статьи из цикла:
Часть 3. Конвергенция EIGRP – настройка таймеров
Часть 4. Пассивные интерфейсы в EIGRP
Часть 5. Настройка статического соседства в EIGRP
Часть 6. EIGRP: идентификатор роутера и требования к соседству
Например, представьте, что в нашем проекте мы обеспокоены тем, что нагрузка на наши линии может быть высокой в разы, и мы хотим, чтобы EIGRP учитывал уровень насыщения линии при расчете наилучшего пути. Изучая полную формулу расчета метрики EIGRP, мы замечаем, что наличие ненулевого значения для K2 приведет к тому, что EIGRP будет учитывать нагрузку. Поэтому мы решили установить K2 равным 1, в дополнение к K1 и K3, которые уже установлены в 1 по умолчанию. Значения К4 и К5 сохранится на уровне 0. В приведенном ниже примере показано, как можно настроить такой набор K-значений.
OFF1#conf term
Enter configuration commands, one per line. End with CNTL/Z .
OFF1(config)#router eigrp 1
OFF1(config-router)#metric weights 0 1 1 1 0 0
OFF1(config-router)#end
Первый 0 в команде metric weights 0 1 1 1 0 0, показанной в приведенном выше примере, задает значение TOS равное 0. Следующие пять чисел задают наши пять K-значений: K1 = 1, K2 = 1, K3 = 1, K4 = 0, K5 = 0. Этот набор K-значений теперь будет учитывать не только пропускную способность и задержку, но и нагрузку при выполнении расчета метрики. Однако есть проблема. Обратите внимание на сообщения консоли, появляющиеся после нашей конфигурации. Оба наших соседства были разрушены, потому что маршрутизатор OFF1 теперь имеет другие K-значения, чем маршрутизаторы OFF2 и OFF3. Напомним, что соседи EIGRP должны иметь соответствующие K-значения, а это означает, что при изменении K-значений на одном EIGRP-спикер маршрутизаторе, вам нужен идентичный набор K-значений на каждом из его соседей EIGRP. Как только вы настроите соответствующие K-значения на этих соседях, то каждый из этих соседей должен соответствовать K-значениям. Как вы можете видеть, в большой топологии может возникнуть значительная административная нагрузка, связанная с манипуляцией K-значением.
Преемник и возможные маршруты преемников
Одна из причин, по которой EIGRP быстро восстанавливает соединения в случае сбоя маршрута, заключается в том, что EIGRP часто имеет резервный маршрут, готовый взять на себя управление, если основной маршрут уходит в down. Чтобы убедиться, что резервный маршрут не зависит от основного маршрута, EIGRP тщательно проверяет резервный маршрут, убедившись, что он соответствует условию осуществимости EIGRP. В частности, условие осуществимости гласит:
Маршрут EIGRP является возможным маршрутом-преемником, если его сообщенное расстояние (RD) от нашего соседа меньше возможного расстояния (FD) маршрута-преемника.
Например, рассмотрим топологию, показанную на следующем рисунке, и соответствующую конфигурацию, приведенную ниже. Обратите внимание, что сеть 10.1.1.8/30 (между маршрутизаторами OFF2 и OFF3) доступна из OFF1 через OFF2 или через OFF3. Если маршрутизатор OFF1 использует маршрут через OFF2, он пересекает канал связи 1 Гбит/с, чтобы достичь целевой сети. Однако маршрут через OFF3 заставляет трафик пересекать более медленное соединение со скоростью 100 Мбит/с. Поскольку EIGRP учитывает пропускную способность и задержку по умолчанию, мы видим, что предпочтительный маршрут проходит через маршрутизатор OFF2. Однако, что делать, если связь между маршрутизаторами OFF1 и OFF2 обрывается? Есть ли возможный преемственный маршрут, который может почти сразу заработать? Опять же, мы видим, что маршрутизатор OFF1 будет использовать возможный маршрут преемника через маршрутизатор OFF3. Однако, прежде чем мы убедимся в этом, мы должны подтвердить, что путь через OFF3 соответствует условию осуществимости.
Возможное условие преемника выполнено на маршрутизаторе OFF1
Просто в силу того, что маршрут через маршрутизатор OFF3 (то есть через 10.1.1.6) появляется в выходных данных команды show ip eigrp topology, выполненной на маршрутизаторе OFF1, мы делаем вывод, что путь через OFF3 действительно является возможным маршрутом-преемником. Однако давайте рассмотрим выходные данные немного более внимательно, чтобы определить, почему это возможный маршрут-преемник.
Во-первых, рассмотрим запись из выходных данных в приведенном выше примере, идентифицирующую последующий маршрут (то есть предпочтительный маршрут):
via 10.1.1.2 (3072/2816), GigabitEthernet0/1
Часть выходных данных via 10.1.1.2 говорит, что этот маршрут указывает на адрес следующего прыжка 10.1.1.2, который является маршрутизатором OFF2. На интерфейсе GigabitEthernet0/1 часть выходных данных указывает, что мы выходим из маршрутизатора OFF1 через интерфейс Gig0/1 (то есть выходной интерфейс). Теперь давайте рассмотрим эти два числа в скобках: (3072/2816). Стоимость 2816 называется зафиксированная дистанция (reported distance (RD). В некоторых литературных источниках это значение также называется advertised distance (AD). Эти термины, синонимы, относятся к метрике EIGRP, сообщенной (или объявленной) нашим соседом по EIGRP. В данном случае значение 2816 говорит нам, что метрика маршрутизатора OFF2 (то есть расстояние) до cети 10.1.1.8/30 равна 2816. Значение 3072 на выходе - это допустимое расстояние маршрутизатора OFF1 (FD). FD вычисляется путем добавления RD нашего соседа к метрике, необходимой для достижения нашего соседа. Поэтому, если мы добавим метрику EIGRP между маршрутизаторами OFF1 и OFF2 к RD маршрутизатора OFF2, мы получим FD (то есть общее расстояние), необходимое для того, чтобы OFF1 добрался до 10.1.1.8/30 через маршрутизатор OFF2. Кстати, причина, по которой маршрутизатор OFF1 определяет наилучший путь к сети 10.1.1.8/30, - это via via router OFF2 (то есть 10.1.1.2) В отличие от маршрутизатора OFF3 (то есть 10.1.1.6), потому что FD пути через OFF1 (3072) меньше, чем FD пути через OFF2 (28,416).
Далее рассмотрим запись для возможного последующего маршрута из приведенного выше примера:
via 10.1.1.6 (28416/2816), GigabitEthernet0/2
Часть выходных данных via 10.1.1.6 говорит, что этот маршрут указывает на адрес следующего прыжка 10.1.1.6, который является маршрутизатором OFF3. На интерфейсе GigabitEthernet0/2 часть результатов показывает, что мы выходим из маршрутизатора OFF1 через интерфейс Gig0/2. Эта запись имеет FD 28 416 и RD 2816. Однако прежде, чем EIGRP просто слепо сочтет этот резервный путь возможным преемником, он проверяет маршрут на соответствие условию осуществимости. В частности, процесс EIGRP на маршрутизаторе OFF1 запрашивает, является ли RD от маршрутизатора OFF3 меньше, чем FD последующего маршрута. В этом случае RD от маршрутизатора OFF3 составляет 2816, что действительно меньше, чем FD преемника 3072. Поэтому маршрут через маршрутизатор OFF3 считается возможным преемником маршрута.
Чтобы утвердить эту важную концепцию, рассмотрим топологию, показанную ниже. Процесс EIGRP на маршрутизаторе OFF1 изучил три пути для достижения сети 10.1.1.0/24. Однако далее EIGRP должен определить, какой из этих путей является маршрутом-преемником, какие (если таковые имеются) пути являются возможными маршрутами-преемниками, а какие (если таковые имеются) пути не являются ни преемником, ни возможным маршрутом-преемником. Результаты расчетов EIGRP приведены в таблице ниже.
Примеры расчетов Feasible Successor
Используя приведенную выше таблицу в качестве рассмотрения, сначала рассмотрим путь маршрутизатора OFF1 к сети 10.1.1.0/24 через маршрутизатор OFF2. С точки зрения маршрутизатора OFF2, расстояние до сети 10.1.1.0/24 - это расстояние от OFF2 до OFF5 (которое равно 5000) плюс расстояние от OFF5 до сети 10.1.1.0/24 (которое равно 1000). Это дает нам в общей сложности 6000 для расстояния от маршрутизатора OFF2 до сети 10.1.1.0/24. Это расстояние, которое маршрутизатор OFF2 сообщает маршрутизатору OFF1. Таким образом, маршрутизатор OFF1 видит RD 6000 от маршрутизатора OFF2. Маршрутизатор OFF1, затем добавляет расстояние между собой и маршрутизатором OFF2 (который равен 10 000) к RD от OFF2 (который равен 6000), чтобы определить его FD для достижения сети 10.1.1.0/24 составляет 16 000 (то есть 10 000 + 6000 = 16 000). Процесс EIGRP на маршрутизаторе OFF1 выполняет аналогичные вычисления для путей к сети 10.1.1.0/24 через маршрутизаторы OFF3 и OFF4. Ниже приведены расчеты, которые привели к значениям, приведенным в таблице.
Затем маршрутизатор OFF1 проверяет результаты этих вычислений и определяет, что кратчайшее расстояние до сети 10.1.1.0/24 проходит через маршрутизатор OFF2, поскольку путь через OFF2 имеет самый низкий FD (16 000). Этот путь, определяемый как кратчайший, считается следующим маршрутом. Затем маршрутизатор OFF1 пытается определить, соответствует ли любой из других маршрутов условию выполнимости EIGRP. В частности, маршрутизатор OFF1 проверяет, чтобы увидеть, что RD от маршрутизаторов OFF3 или OFF4 меньше, чем FD последующего маршрута. В случае OFF3 его RD в 11 000 действительно меньше, чем FD последующего маршрута (который составляет 16 000). Таким образом, путь к сети 10.1.1.0 /24 через OFF3 квалифицируется как возможный маршрут-преемник. Однако маршрут через OFF4 не подходит, потому что RD OFF4 из 18 000 больше, чем 16 000 (FD последующего маршрута). В результате путь к сети 10.1.1.0/24 через маршрутизатор OFF4 не считается возможным маршрутом-преемником.
Мы изучили K - значения, теперь почитайте про конвергенцию EIGRP и настройку таймеров
В версиях Asterisk начиная с версии 1.4 периодически наблюдались проблемы с утечкой памяти, которые лечились с помощью перезагрузки сервера. Так как никто не застрахован от вероятных неизвестных багов, лучше для перестраховки перезагружать сервер IP - АТС раз в неделю (или чаще) с помощью скрипта. В статье расскажем про создание bash скрипта и его настройку в cron.
Скрипт перезагрузки
По факту, в скрипте достаточно одной команды перезагрузки. Сделаем немного информативной нагрузки – добавим запись в лог – файл: мы будем записывать дату и время ребута с лог – файл. Итак, создаем файл reboot.sh:
[root@asterisk ~]# touch reboot.sh
Далее открываем этот файл для редактирования через vim редактор:
[root@asterisk ~]# vim reboot.sh
Открыв файл, нажмите «О» для редактирования. Вставьте код, указанный ниже:
#!/bin/sh
LOGFILE=/home/admin/log_mail.txt
DATE="`date +%d.%m.%Y" "%H:%M:%S`"
echo "REBOOT :: $DATE :: Reboot is in progress" >> "$LOGFILE"
shutdown -r now
После этого нажимаем комбинацию «:x!» для сохранения конфигурации. В данном скрипте:
LOGFILE - переменная, которая указывает на лог – файл;
DATE - записываем дату и время в указанную переменную;
echo "…" - записываем в лог – файл отметку о перезагрузке;
shutdown -r now - команда перезагрузки сервера;
Получаем простенький скрипт для осуществления перезагрузки. Осталось только сделать его работу по расписанию. Для этого, мы воспользуемся планировщиком cron:
* * * * * команда для выполнения
- - - - -
| | | | |
| | | | +----- день недели (0 - 6) (Воскресенье=0)
| | | +------- месяц (1 - 12)
| | +--------- день месяца (1 - 31)
| +----------- час (0 - 23)
+------------- минута (0 - 59)
Зашедулим скрипт на выполнение каждую полночь в воскресение. Для этого, открываем для редактирования crontab файл:
[root@asterisk ~]# crontab -e
В открывшийся файл добавляем:
0 0 * * 0 /bin/bash /home/reboot.sh >/dev/null
Где /home/reboot.sh - полный путь к скрипту перезагрузки сервера. Нажимаем F2 и далее Yes. Задача на выполнение сохранена.
Примеры планирования в cron
Разберем пару примеров того, по какому расписанию можно планировать выполнение скрипта:
15 0 1 1,3,6,9,12 * - выполнение скрипта каждое 1 число января, марта, июня, сентября и декабря в 00:15 ночи;
0 20 * 8 1-5 - выполнение скрипта каждый будний день в 20:00 в августе;
0 0 1,15,25 * * - выполнение скрипта в полночь каждого месяца первого, пятнадцатого и двадцать пятого числа;