пїЅпїЅпїЅпїЅпїЅ
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В этой серии лекций продолжается рассмотрение распределенных плоскостей управления, добавляя к изучению еще три протокола маршрутизации. Два из них являются протоколами состояния канала, а третий – единственный, широко распространенный протокол вектора пути, Border Gateway Protocol (BGP) v4.
В этих лекция мы уделим внимание тому, почему каждый из этих протоколов реализован именно так. Очень легко увлечься и запутаться в изучении мельчайших деталей работы протоколов, но нам гораздо важнее помнить о проблемах, для решения которых эти протоколы были разработаны, и о диапазоне возможных решений. Каждый изучаемый вами протокол будет представлять собой комбинацию умеренно ограниченного набора доступных решений: существует очень мало доступных новых решений. Существуют различные комбинации решений, реализованных иногда уникальными способами для решения конкретных наборов проблем.
Изучая эти принципы работы протокола, вы должны попытаться выбрать общие решения, которые они реализуют. Затем отразить эти решения обратно в набор проблем, которые должна решить любая распределенная плоскость управления, чтобы устранить проблемы в реальных сетях.
Краткая история OSPF и IS-IS
Протокол Intermediate System to Intermediate System (IS-IS или IS to IS) был разработан в 1978 году.
Open Shortest Path First (OSPF) изначально задумывался как альтернатива IS-IS, предназначенная специально для взаимодействия с сетями IPv4. В 1989 году первая спецификация OSPF была опубликована Internet Engineering Task Force, а OSPFv2, значительно улучшенная спецификация, была опубликована в 1998 году как RFC2328. OSPF, безусловно, был более широко используемым протоколом, причем ранние реализации IS-IS практически не применялись в реальном мире. Были некоторые аргументы за и против, и многие функции были «позаимствованы» из одного протокола в другой (в обоих направлениях).
В 1993 году компания Novell, в то время крупный игрок в мире сетевых технологий, использовала протокол IS-IS как основу для замены собственного протокола маршрутизации Netware. Протокол транспортного уровеня Novell, Internet Packet Exchange (IPX), в то время работал на большом количестве устройств, и возможность использования одного протокола для маршрутизации нескольких транспортных протоколов была решающим преимуществом на сетевом рынке (EIGRP, также может маршрутизировать IPX). Этот протокол замены был основан на IS-IS. Чтобы реализовать новый протокол Novell, многие производители просто переписали свои реализации IS-IS, значительно улучшив их в процессе. Это переписывание сделало IS-IS привлекательным для крупных провайдеров Интернет-услуг, поэтому, когда они отказались от протокола RIP, они часто переходили на IS-IS вместо OSPF.
Intermediate System to Intermediate System Protocol
В протоколе Intermediate System to Intermediate System (IS-IS) маршрутизатор называется Intermediate System (Промежуточной системой (IS), а хост- End System (Конечной системой (ES). Оригинальный дизайн набора состоял в том, чтобы каждое устройство, а не интерфейс, имело один адрес. Службы и интерфейсы на устройстве будут иметь точку доступа к сетевым службам (Network Service Access Point - NSAP), используемую для направления трафика к определенной службе или интерфейсу. Таким образом, с точки зрения IP, IS-IS изначально был разработан в рамках парадигмы маршрутизации хоста. Промежуточные и конечные системы связываются непосредственно с помощью протокола End System to Intermediate System (ES-IS), позволяющего IS-IS обнаруживать службы, доступные в любой подключенной конечной системе, а также сопоставлять адреса нижних интерфейсов с адресами устройств более высокого уровня.
Еще один интересный аспект дизайна IS-IS - он работает на канальном уровне. Разработчикам протокола не имело большого смысла запускать плоскость управления для обеспечения доступности транспортной системы через саму транспортную систему. Маршрутизаторы не будут пересылать пакеты IS-IS, поскольку они параллельны IP в стеке протоколов и передаются по локальным адресам связи. Когда была разработана IS-IS, скорость большинства каналов была очень низкой, поэтому дополнительная инкапсуляция также считалась расточительной. Каналы связи также довольно часто выходили из строя, теряя и искажая пакеты. Следовательно, протокол был разработан, чтобы противостоять ошибкам при передаче и потере пакетов.
Адресация OSI
Поскольку IS-IS был разработан для другого набора транспортных протоколов, он не использует адреса Internet Protocol (IP) для идентификации устройств. Вместо этого он использует адрес взаимодействия открытых систем (Open Systems Interconnect - OSI) для идентификации как промежуточных, так и конечных систем. Схема адресации OSI несколько сложна, включая идентификаторы для органа, распределяющего адресное пространство, идентификатор домена, состоящий из двух частей, идентификатор области, системный идентификатор и селектор услуг (N-селектор). Многие из этих частей адреса OSI имеют переменную длину, что еще больше затрудняет понимание системы. Однако в мире IP используются только три части этого адресного пространства.
Authority Format Identifier (AFI), Initial Domain Identifier (IDI), High-Order Domain Specific Part (HO-DSP) и область, где все обрабатывается как одно поле.
Системный идентификатор по-прежнему рассматривается как системный идентификатор.
N Selector, или NSAP, обычно игнорируется (хотя есть идентификатор интерфейса, который похож на NSAP, используемый в некоторых конкретных ситуациях).
Таким образом, промежуточные системные адреса обычно принимают форму, показанную на рисунке 1.
На рисунке 1:
Точка разделения между системным идентификатором и остальной частью адреса находится в шестом октете или если отсчитать двенадцать шестнадцатеричных цифр с правой стороны. Все, что находится слева от шестого октета, считается частью адреса области.
Если N-селектор включен, это один октет или две шестнадцатеричные цифры справа от идентификатора системы. Например, если для адреса A был включен N-селектор, это могло бы быть 49.0011.2222.0000.0000.000A.00.
Если в адрес включен N-селектор, вам нужно пропустить N-селектор при подсчете более шести октетов, чтобы найти начало адреса области.
A и B находятся в одном домене flooding рассылки, потому что у них одни и те же цифры от седьмого октета до крайнего левого октета в адресе.
C и D находятся в одном flooding domain.
A и D представляют разные системы, хотя их системный идентификатор одинаков. Однако такая адресация может сбивать с толку и поэтому не используется в реальных развертываниях IS-IS (по крайней мере, вдумчивыми системными администраторами).
Вы посчитать эту схему адресации более сложной, чем IP, даже если вы регулярно работаете с IS-IS в качестве протокола маршрутизации. Однако есть большое преимущество в использовании схемы адресации, отличной от той, которая используется на транспортном уровне в сети. Гораздо проще различать типы устройств в сети и гораздо проще отделить узлы от адресатов, если продумать алгоритм Дейкстры по кратчайшему пути (SPF).
Маршаллинг данных в IS-IS
IS-IS использует довольно интересный механизм для маршалинга данных для передачи между промежуточными системами. Каждая IS генерирует три вида пакетов:
Hello-пакеты
Пакеты с порядковыми номерами (PSNP и CSNP)
Одиночный пакет состояния канала (Link State Packet - LSP)
Единый LSP содержит всю информацию о самой IS, любых доступных промежуточных системах и любых доступных адресатах, подключенных к IS. Этот единственный LSP форматируется в Type Length Vectors (TLV), которые содержат различные биты информации. Некоторые из наиболее распространенных TLV включают следующее:
Типы 2 и 22: достижимость к другой промежуточной системе
Типы 128, 135 и 235: достижимость до пункта назначения IPv4
Типы 236 и 237: достижимость к адресату IPv6
Существует несколько типов, потому что, IS-IS изначально поддерживал 6-битные метрики (большинство процессоров на момент появления протокола могли хранить только 8 бит за раз, и два бита были «украдены» из размера поля, чтобы нести информацию о том, был ли маршрут внутренним или внешним, а также другую информацию). Со временем, по мере увеличения скорости связи, были введены различные другие метрические длины, включая 24 - и 32-битные метрики, для поддержки широких метрик.
Одиночный LSP, несущий всю информацию о доступности IS, IPv4 и IPv6, а также, возможно, теги MPLS и другую информацию, не поместится в один пакет MTU. Для фактической отправки информации по сети IS-IS разбивает LSP на фрагменты. Каждый фрагмент рассматривается как отдельный объект в процессе лавинной рассылки. Если изменяется один фрагмент, лавинной рассылкой по сети распространяется только измененный фрагмент, а не весь LSP. Благодаря этой схеме IS-IS очень эффективен при лавинной рассылке информации о новой топологии и достижимости без использования полосы пропускания, превышающей минимальную требуемую.
Обнаружение соседей и топологии
Хотя IS-IS изначально был разработан, чтобы узнать о доступности сети через протокол ES-IS, когда IS-IS используется для маршрутизации IP, он «действует так же, как протоколы IP», и узнает о достижимых местах назначения через локальную конфигурацию каждого из них. устройства и путем перераспределения из других протоколов маршрутизации. Следовательно, IS-IS - это проактивный протокол, который изучает и объявляет достижимость без ожидания пакетов, которые будут переданы и переадресованы через сеть.
Формирование соседей в IS-IS довольно просто. Рисунок 2 иллюстрирует этот процесс.
На рисунке 2:
IS A передает приветствие в сторону B. Это приветствие содержит список соседей, от которых получен сигнал, который будет пустым. Настройку времени удержания (hold time) B следует использовать для A, и добавляется к максимальному блоку передачи (MTU) локального интерфейса для канала связи. Пакеты приветствия дополняются только до завершения процесса формирования смежности. Не каждый пакет приветствия дополняется MTU канала.
IS B передает приветствие к A. Это приветствие содержит список соседей, от которых получен ответ, который будет включать A. Настройку времени удержания A следует использовать для B. Добавляется к MTU локального интерфейса.
Поскольку A находится в списке «слышимых соседей» B, A рассмотрит B и перейдет к следующему этапу формирования соседей.
Как только A включил B в список «услышанных соседей» хотя бы в одно приветствие, B рассмотрит A и перейдет к следующему этапу формирования соседа.
B отправит полный список всех записей, которые он имеет в своей таблице локальной топологии (B описывает LSP, которые он имеет в своей локальной базе данных). Этот список отправляется в Complete Sequence Number Packet (CSNP).
A проверит свою локальную таблицу топологии, сравнив ее с полным списком, отправленным B. Любые записи в таблице топологии (LSP), которых он не имеет, он будет запрашивать у B с использованием Partial Sequence Number Packet (PSNP).
Когда B получает PSNP, он устанавливает флаг Send Route Message (SRM) для любой записи в его локальной таблице топологии (LSP), запрошенной A.
Позже процесс лавинной рассылки будет проходить по таблице локальной топологии в поисках записей с установленным флагом SRM. Он заполнит эти записи, синхронизируя базы данных в A и B.
Примечание. Описанный здесь процесс включает изменения, внесенные в RFC5303, который определяет трехстороннее рукопожатие, и дополнение приветствия, которое было добавлено в большинство реализаций примерно в 2005 году.
Установка флага SRM отмечает информацию для лавинной рассылки, но как на самом деле происходит лавинная рассылка?
Надежная лавинная рассылка.
Для правильной работы алгоритма SPF Дейкстры (или любого другого алгоритма SPF) каждая IS в flooding domain должна совместно использовать синхронизированную базу данных. Любая несогласованность в базе данных между двумя промежуточными системами открывает возможность зацикливания маршрутизации. Как IS-IS гарантирует, что подключенные промежуточные системы имеют синхронизированные базы данных? В этой лекции описывается процесс создания point-to-point каналов. Далее будут описаны модификации, внесенные в процесс flooding domain по каналам с множественным доступом (например, Ethernet).
IS-IS полагается на ряд полей в заголовке LSP, чтобы гарантировать, что две промежуточные системы имеют синхронизированные базы данных. Рисунок 3 иллюстрирует эти поля.
На рисунке 3:
Длина пакета (packet length) содержит общую длину пакета в октетах. Например, если это поле содержит значение 15 , длина пакета составляет 15 октетов. Поле длины пакета составляет 2 октета, поэтому оно может описывать пакет длиной до 65 536 октетов - больше, чем даже самые большие MTU канала.
Поле оставшегося времени жизни (remaining lifetime) также составляет два октета и содержит количество секунд, в течение которых этот LSP действителен. Это вынуждает периодически обновлять информацию, передаваемую в LSP, что является важным соображением для старых технологий передачи, где биты могут быть инвертированы, пакеты могут быть усечены или информация, передаваемая по каналу связи, может быть повреждена. Преимущество таймера, который ведет обратный отсчет, а не на увеличение, состоит в том, что каждая IS в сети может определять, как долго ее информация должна оставаться действительной независимо от каждой другой IS. Недостаток в том, что нет четкого способа отключить описанный функционал. Однако 65 536 секунд - это большое время - 1092 минуты, или около 18 часов. Повторная загрузка каждого фрагмента LSP в сети примерно каждые 18 часов создает очень небольшую нагрузку на работу сети.
LSP ID описывает сам LSP. Фактически, это поле описывает фрагмент, поскольку оно содержит идентификатор исходной системы, идентификатор псевдоузла (функцию этого идентификатора рассмотрим позже) и номер LSP, или, скорее, номер фрагмента LSP. Информация, содержащаяся в одном фрагменте LSP, рассматривается как «один блок» во всей сети. Отдельный фрагмент LSP никогда не «рефрагментируется» какой-либо другой IS. Это поле обычно составляет 8 октетов.
Порядковый номер (Sequence Number) описывает версию этого LSP. Порядковый номер гарантирует, что каждая IS в сети имеет одинаковую информацию в своей локальной копии таблицы топологии. Это также гарантирует, что злоумышленник (или «кривая» реализация) не сможет воспроизвести старую информацию для замены новой.
Контрольная сумма (Checksum) гарантирует, что информация, передаваемая во фрагменте LSP, не была изменена во время передачи.
Лавинная рассылка описана на рисунке 4.
На рисунке 4:
А подключен к 2001: db8: 3e8: 100 :: / 64. A создает новый фрагмент, описывающий этот новый достижимый пункт назначения.
A устанавливает флаг SRM на этом фрагменте в сторону B.
Процесс лавинной рассылки в какой-то момент (обычно это вопрос миллисекунд) проверит таблицу топологии и перезальет все записи с установленным флагом SRM.
Как только новая запись будет помещена в свою таблицу топологии, B создаст CSNP, описывающий всю свою базу данных, и отправит его в A.
Получив этот CSNP, A удаляет свой флаг SRM в направлении B.
B проверяет контрольную сумму и сравнивает полученный фрагмент с существующими записями в своей таблице топологии. Поскольку нет другой записи, соответствующей этой системе и идентификатору фрагмента, он поместит новый фрагмент в свою таблицу локальной топологии. Учитывая, что это новый фрагмент, B инициирует процесс лавинной рассылки по направлению к C.
А как насчет удаления информации? Есть три способа удалить информацию из системы IS-IS flooding:
Исходящая IS может создать новый фрагмент без соответствующей информации и с более высоким порядковым номером.
Если весь фрагмент больше не содержит какой-либо действительной информации, исходящая IS может заполнить фрагмент с оставшимся временем жизни (lifetime) равным 0 секунд. Это приводит к тому, что каждая IS в домене лавинной рассылки повторно загружает фрагмент zero age и удаляет его из рассмотрения для будущих вычислений SPF.
Если таймер lifetime во фрагменте истекает в любой IS, фрагмент заполняется лавинной рассылкой с zero age оставшегося времени жизни. Каждая IS, получающая этот фрагмент с zero age, проверяет, что это самая последняя копия фрагмента (на основе порядкового номера), устанавливает оставшееся время жизни для своей локальной копии фрагмента на ноль секунд и повторно загружает фрагмент. Это называется удалением фрагмента из сети.
Когда IS отправляет CNSP в ответ на полученный фрагмент, она фактически проверяет всю базу данных, а не только один полученный фрагмент. Каждый раз, когда фрагмент лавинно рассылается по сети, вся база данных проверяется между каждой парой промежуточных систем.
Подведение итогов об IS-IS
IS-IS можно описать как:
Использование лавинной рассылки для синхронизации базы данных в каждой промежуточной системе в flooding domain (протокол состояния канала).
Расчет loop-free -путей с использованием алгоритма SPF Дейкстры.
Изучение доступных пунктов назначения через конфигурацию и локальную информацию (проактивный протокол).
Проверка двусторонней связи при формировании соседей путем переноса списка «замеченных соседей» в своих пакетах приветствия.
Удаление информации из домена лавинной рассылки с помощью комбинации порядковых номеров и полей оставшегося времени жизни (lifetime) в каждом фрагменте.
Проверка MTU каждой линии связи путем заполнения первоначально обмененных пакетов приветствия.
Проверка правильности информации в синхронизированной базе данных с помощью контрольных сумм, периодического перезапуска и описаний базы данных, которыми обмениваются промежуточные системы.
IS-IS - это широко распространенный протокол маршрутизации, который доказал свою работоспособность в широком диапазоне сетевых топологий и эксплуатационных требований.
В наше время безопасность – это крайне важный компонент разработки программного обеспечения и приложения, а также управления серверами.
Если вы пользуетесь Linux, то вам повезло! У него есть отличная функция под названием SELinux, которая может позволить вам добавить дополнительный уровень безопасности.
Что такое SELinux?
SELinux был разработан АНБ (Агентством национальной безопасности). Цель его создания – выполнение правительственных задач в области обеспечения безопасности.
SELinux расшифровывается как Security Enhanced Linux (Linux с улучшенной безопасностью). Он дает системным администраторам больше контроля над предоставлением доступа к файлам и процессам. В рамках SELinux администраторы могут определять некий контекст, помечать соответствующим образом файлы и допускать их использование только в соответствии с этим контекстом.
Доступ и полномочия, как правило, наследуются с точки зрения групп пользователей. Но есть такие источники (например, веб-серверы или некие процессы), которым необходим доступ к сетевым портам и процессам на уровне ядра. Как правило, они порождаются привилегированным пользователем или пользователями с доступом высшего уровня. С помощью SELinux вы можете ограничить доступ к этим особым процессам.
Как работать с SELinux?
SELinux по умолчанию является частью большинства дистрибутивов Linux. В этой статье я буду работать с Fedora.
Только учтите, что для того, чтобы работать с SELinux, вам потребуются права доступа привилегированного (
root
) или суперпользователя (
sudo
).
Файл конфигурации SELinux располагается здесь:
/etc/sysconfig/selinux
. Давайте взглянем на его содержимое:
Режимы SELinux
Файл конфигурации SELinux
Внутри файла конфигурации вы можете выбрать любой из режимов:
Enforced
– этот режим включен по умолчанию, фильтры завязаны на определенных политиках.
Permissive
– политики не используются, но все попытки получения доступа записываются в лог-файлы. Этот режим полезен при устранении неисправностей.
Disabled
– SELinux полностью отключен. Лучше всего такой режим не выбирать, так как ваша система будет под угрозой. Кроме того, возврат к режиму Enforced может создать некоторые несоответствия.
Вы можете проверить текущий режим SELinux с помощью следующих команд:
getenforce
sestatus
Если вам нужно сменить режим только для текущего сеанса, то вам понадобятся следующие команды:
sudo setenforce 0
– устанавливает режим Permissive для текущего сеанса
sudo setenforce 1
– устанавливает режим Enforced для текущего сеанса
Политики SELinux
В SELinux доступ к пользователям определяют политики. Пользователи устанавливают доступ к ролям, а роли – доступ к доменам. А домены, в свою очередь, предоставляют доступ к определенным файлам.
Политики SELinux
Вы можете изменить доступы. Для этого определены логические значения (переключатели).
Как управлять политиками SELinux с помощью логических переключателей
Как вы уже знаете, политики SELinux управляются посредством логических переключателей.
Давайте взглянем на рабочий пример того, как можно просмотреть и установить логические переключатели. В рамках данного примера мы будет устанавливать переключатели для
httpd
.
Для начала выведем список всех переключателей, характерных для
httpd
:
getsebool -a | grep httpd
.
Здесь флаг
-a
перечисляет все логические переключатели.
Список логических переключателей
Теперь давайте выберем и изменим переключатель, который мы выделили желтым цветом в коде выше:
getsebool httpd_can_connect_ftp
Установим значение на «разрешено» (
on
).
setsebool -P httpd_can_connect_ftp 1
Вот что происходит в команде выше:
флаг
-P
нужен для того, что изменение сохранилось даже после перезагрузки
1
включает логический переключатель
Теперь, когда вы запросите список снова, значение будет установлено на «разрешено».
Значение логического переключателя – «on»
Структура SELinux
Ниже приведена диаграмма, на которой показано, как SELinux проверяет попытку источника получить доступ:
Устранение неисправностей и журналы SELinux
SELinux создает очень подробные журналы для каждой попытки получения доступа. Журналы можно найти здесь:
/var/log/audit
.
При устранении неисправностей вам следует выбрать режим Permissive для того, чтобы все события записывались в журнал. Несмотря на то, что политики не применяются, все попытки получения доступа записываются в журнал.
Как включать и отключать SELinux?
Полностью отключать SELinux не стоит, это не самый хороший вариант. Но есть определенные сценарии, которые позволяют обойти политики, например, устранение неисправностей.
Вместо того, чтобы отключать SELinux в ситуации, когда вы столкнулись с небольшой проблемой, лучше потратить немного времени на то, чтобы устранить неисправность.
Но если вам действительно нужно отключить SELinux, то выполните следующие шаги:
Измените режим с Enforced на Permissive.
Измените режим с Permissive на Disabled.
Заключение
SELinux определенно стоит того, чтобы потратить время на его изучение. Он обладает бесконечными возможностями, которые вы можете освоить.
За счет SELinux администраторы получают высокий уровень контроля. Так почему бы не изучить его и не повысить, таким образом, уровень своей безопасности?
Введение
Разработчик при написании кода должен быть максимально продуктивным. Однако бывают ситуации, когда им приходится выполнять работу не по профилю или реализовывать повторяющиеся задачи. Для того, чтобы сэкономить время, стоит внедрить автоматизацию выполнения этих повторяющихся задач. Таким образом, можно повысить производительность разработчиков.
По мере того, как развивались технологии CI/CD (Continous Integration / Continous Deployment – непрерывная интеграция и развертывание ПО), процесс автоматизации задач стал намного проще. С помощью CI мы можем интегрировать код в общедоступный репозиторий и запускать автоматизированные тесты для того, чтобы выявлять ошибки на ранних стадиях разработки. Вместе с этим, CD позволяет автоматизировать процесс развертывания в соответствии с внесенными в код изменениями и переменными среды. Цель данной технологии – быстро и надежно доставить код.
У GitHub есть свой собственный конвейер CI/CD для автоматизации задач. Он называется GitHub Actions. Его задача состоит в том, чтобы помочь разработчикам автоматизировать жизненный цикл разработки ПО. Так что, сегодня мы рассмотрим некоторые аспекты GitHub Actions.
Давайте начнем.
GitHub Actions
Впервые GitHub Actions был анонсирован в 2018 году. А в 2019 году он появился в открытом доступе как конвейер CI/CD для автоматизации различных аспектов SDLC прямо из репозитория GitHub. Код, который отвечает за автоматизацию, расположен в YAML-файле. Это удобный для восприятия язык сериализации данных, который можно использовать для написания файлов конфигурации.
Триггером для запуска GitHub Actions могут быть команды pull, push или любой другой внешний триггер. Вы можете запускать GitHub Actions для того, чтобы создавать, тестировать и развертывать веб-сайты.
Давайте создадим Action для того, чтобы лучше понять, как они работают.
Создание GitHub Action
Процесс создания GitHub Action довольно прост. Перейдите в свой репозиторий GitHub через веб-страницу GitHub, либо через локальный репозиторий. Создайте в корневом каталоге каталог
.github/workflow
. Теперь в каталоге, который вы только что создали, вы можете создать YAML-файл с любым именем. Расширение YAML-файла -
.yml
. Итак, теперь имя файла выглядит так:
name.yml
.
Стандартная структура YAML-файла
Наверху в YAML-файле мы должны указать название нашего Action (через ключевое слово
name
).
name: GitHub Actions
После этого мы можем добавить триггер. Триггером могут быть команды pull, push или же он может просто срабатывать в какой-то момент времени. Для того, чтобы определить триггер, нам понадобиться ключевое слово
on
.
Если мы говорим о событиях, определенных в GitHub, например, pull, то можно использовать синтаксис, приведенный ниже. При этом вы можете добавить несколько триггеров.
// single { // один }
on: [push]
// multiple { // несколько }
on: [push, fork]
Для запуска по времени мы можем воспользоваться ключевыми словами
schedule
и
cron
.
on:
schedule:
- cron: "0 */12 * * *"
Выражение, записанное после ключевого слова
cron
, можно разбить и объяснить следующим образом:
0
: первое поле – это минуты. Оно указывает на то, что Action запуститься на 0-й минуте часа.
*/12
: это поле часов. Оно указывает на то, что Action будет запускаться каждые 12 часов. */12 говорит о том, что задачи (jobs) будут выполняться каждые 12 часов, если же вы укажите просто 12, то они будут выполняться в 12АМ (12:00) и в 12PM (00:00). Вы также можете указать время, исходя из 24 часов в сутках, например, записать 23, что будет означать 11PM.
«*»
: это день запуска. Это поле указывает на то, что задачи будут выполняться каждый день.
«*»
: вторая звездочка обозначает месяц. Это поле указывает на то, что задачи будут выполняться каждый месяц.
«*»
: последняя звездочка определят день недели. Это поле указывает на то, что задачи будут выполняться каждый день недели. День недели указывается в виде числа, где первый день недели – это воскресенье, то есть
0
. Дни недели разделяются запятыми, например,
0,2,3
.
Таким образом, самый примитивный синтаксис выглядит так:
cron: "Minute Hour Day Month Day_of_Week"
А теперь нам нужно добавить конкретную функцию, которая будет выполняться при запуске сценария. В YAML есть ключевое слово
jobs
, которое используется для определения различных задач.
Давайте посмотрим на полный синтаксис и после этого разберем его подробнее:
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Setup Node.js
uses: actions/setup-node@v2
with:
node-version: '14'
- name: Install dependencies
run: npm install
- name: Run tests
run: npm test
update-readme
- это имя задачи. Внутри нее находятся исполнители задач, которые определяются ключевым словом
runs-on
. Это машина, на которой будет запускаться команда.
Теперь мы переходим к ключевому слову
steps
, с помощью которого определяются все шаги, которые должны быть выполнены в процессе выполнения сценария. Вы можете определить порядок
steps
с помощью двух основных ключевых слов:
name
и
uses
. Ключевое слово
name
используется для предоставления описательного имени для определенного шага сценария. Ключевое слово
uses
используется для определения действия или содержимого Docker, которое должно быть запущено для выполнения задачи.
Первый шаг использует действие
action/checkout
, которое вызывает репозиторий, извлекает ссылку, например, ветку, тег или SHA-коммит, и подготавливает рабочую область для дальнейших шагов. Следующим шагом будет использование настройки инструмента, которое требует запуска команды. В нашем случае это Node.js. После этого мы должны запустить команду для установки зависимостей.
Последний шаг – это запуск кода, который выдаст результат. В нашем случае мы запускаем команду
npm test
для запуска тестирования. Помимо этого, вы можете запустить любой Node-файл, который есть в репозитории.
- name: Update README
- run: node update-readme.js
А теперь давайте посмотрим на весь код YAML-файла:
name: GitHub Actions
on:
schedule:
- cron: "0 */12 * * *"
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Setup Node.js
uses: actions/setup-node@v2
with:
node-version: '14'
- name: Install dependencies
run: npm install
- name: Run tests
run: npm test
Отладка и устранение неисправностей
При написании Actions вы можете столкнуться с такими ошибками, как неудачное выполнение задания или недопустимый синтаксис. А так как в YAML нет встроенного отладчика, исправить ошибку будет не так просто. Однако есть несколько методов и инструментов, которые могут помочь отладить Actions. Вот они:
Расширение для GitHub Actions
. У GitHub есть официальное расширение для Actions для VS Code. С его помощью вы можете управлять и выполнять Actions. Кроме того, у него есть такие функции, как проверка и автодополнение кода, которые помогут вам не допускать ошибок в синтаксисе.
Условная отладка
. Данный метод работает не только с YAML, но и с другими языками. При таком подходе вы используете условия для того, чтобы выборочно запускать шаги. Таким образом, вы можете найти причину ошибки. Для их проверки вы можете использовать if-условия.
Журналы сценариев
. GitHub при выполнении Actions создает журналы. В этих журналах подробно описано выполнение каждого шага. Таким образом, вы можете узнать, какие шаги были выполнены неудачно. Просмотреть журналы можно в своем репозитории, нажав на вкладку «Actions».
Act
. Это терминал, с помощью которого можно запускать GitHub Actions локально. Таким образом, вы можете для начала протестировать Actions локально, а потом уже отправлять их на GitHub. Это поможет вам сэкономить время, так как вам не нужны будут никакие push/fork/pull для того, чтобы вызвать Action.
А вот несколько преимуществ использования GitHub Actions:
Cron-задания
. GitHub Actions могут выполнять cron-задания. Вы можете определить в файле код и с помощью GitHub Actions запускать его в определенный момент времени.
Богатая экосистема
. GitHub предоставляет экосистему Git, которая помогает беспрепятственно интегрировать Actions в сценарий. Триггеры, связанные с pull, push или fork, можно легко использовать в GitHub. Кроме того, у него есть рынок готовых Actions, где вы можете найти огромное количество полезных вариантов для вашего проекта.
Масштабируемость
. Как вы уже знаете, GitHub позволяет управлять как большими проектами, так и не очень. Вместе с этим, GitHub позволяет создавать несколько сценариев и Actions для запуска различных заданий, зависящих от триггера.
Безопасность
. ****Вы можете определить секреты GitHub, например, ключи API, в настройках репозитория. У YAML будет доступ к этим секретам, что сделает их безопасными для использования переменными среды. получить доступ к секрету можно с помощью следующего кода:
- name: Update README
run: node update-readme.js
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} # accessing the secret { // получение доступа к секрету }
Заключение
Как мы увидели в этой статье GitHub Actions могут выполнять различные задачи в соответствии с вашими требованиями. Мы изучили сами Actions, их синтаксис и то, как их можно определить. И напоследок мы узнали о некоторых преимуществах их использования. Кроме того, мы узнали, что существует специальный рынок готовых Actions, который упрощает процесс их добавления в ваш сценарий.
Я надеюсь, что, прочитав эту статью, вы смогли понять, что такое GitHub Actions. Спасибо за внимание.