По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Привет! Для удобства, мы структурировали все материалы по графическому интерфейсу FreePBX в нашей базе знаний в единый файл. Само собой, нами был выбран многофункциональный формат для хранения и распространения электронных публикаций - PDF. Получившееся руководство администратора FreePBX можно получить по ссылке ниже: Скачать
img
В данной статье мы рассмотрим процессы CICD автоматизации. Разберем роль такого продукта, как Jenkins и его аналогов. Программное обеспечение Jenkins написано на языке программирования Java, по отзывам ИТ сообщества, данный продукт написан очень хорошо. Но самое главное данное программное обеспечение полностью бесплатное. Многие энтузиасты в мире для данного продукта пишут плагины, которые расширяют функционал Jenkins. Рассмотрим 2 ключевых понятия CICD Автоматизации. CI – Continuous Integration. Это DevOps модель, в которой разработчики делают commit кода в репозиторий (обычно используется github или gitlab, для хранения кода) и автоматически запускается build или компиляция этого кода, после этого запускаются автоматические тесты кода: Unit Test, Integration Test, Functionality Test. CD – Continuous Delivery and Deployment. Это DevOps модель, в которой разработчики делают commit кода в репозиторий и автоматически запускается build или компиляция этого кода, после этого запускаются автоматические тесты кода и готовый Artifact (скомпилированный код, например если это Java, то артефактом является var, если это Android приложение, то apk файл) делает деплой в Staging и Production, т.е происходит установка кода в развернутую вашу среду в необходимом контуре. Рассмотрим процесс на примере. Процесс CICD автоматизации Первым шагом в процессе является Commit to Source Control (github, gitlab или bitbucket), система определяет наличие нового кода, срабатывает триггер и автоматически запускается следующий этап BuildCompile - компиляция кода. Система скачивает новый код, например, если код попал в master branch (основную ветку). После получения ответа от сборки, что все прошло успешно, запускается следующий этап тестов. Все тесты пишут все те же программисты, для того, чтобы проверить на сколько корректно отработал код. Весь этот процесс называется Continuous Integration. Это классическая схема содержит 3 этапа, иногда включаются дополнительные шаги, но они не принципиальны. В результате данного процесса мы получаем скомпилированный и протестированный код. Давайте рассмотрим последующие шаги. Следующий шаг мы можем сделать deployment кода. По сути это тот же процесс копирования файлов кода на сервера. Процесс деплоя можно делать в разные места, можно делать в AWS или Azure, можно делать в свое частное облако, развернутое на VMware. Весь процесс с добавочными шагами называется Continuous Delivery and Deployment. Получается следующее: за Source Control – отвечает git. За шаг build и compile будет отвечать Jenkins. Следовательно, Jenkins запустится, когда кто-нибудь сделает комит в систему контроля версий, в основную ветку или не основную, смотря как настроено. Следующим шагом Jenkins выполнит все необходимые тесты, которые подготовили программисты. Следующий шаг Deploy так же запустит Jenkins и скопирует код на необходимые сервера, с помощью скрипта или scp если это Linux сервер. Существуют вариации с использованием Puppet или Ansible если мы делаем Deploy артефакта или конфигурации в целом. Существуют альтернативы Jenkins, например, Bamboo, Circleci, Gitlab CICD, TeamCity. Установка Jenkins Для развертывания Jenkins нам понадобится виртуальная машина на Ubuntu версии 18 или выше. Идем на официальный сайт Jenkins,в разделе Download мы можем увидеть 2 версии. На момент написании статьи актуальная версия Jenkins 2.319.2LTS и во второй колонке мы можем увидеть недельные версии Jenkins 2.333 Как видите дистрибутивы есть практически под все операционные системы. Мы будем использовать стабильную версию под UbuntuDebian. Ознакомимся с требованиями к установке продукта Jenkins. Для инсталляции потребуется минимум 256 МБ RAM, места 1 ГБ, а также на сайте написаны рекомендованные требования, с которыми будет достаточно комфортно работать с продуктом. Так как Jenkins написан на Java, то для запуска и работы потребуется непосредственно установленная на сервере Java. Для начала проверим версию java на сервере. java –version Если сервер свежий или Java не установлена, то операционная система сообщит, что такая команда не найдена и предложить установить Java. Java устанавливается достаточно просто: sudo apt update – oбновляем репозиторий sudo apt search openjdk – ищем необходимый пакет sudo apt install openjdk-11-jdk – запускаем установку java в процессе система попросит подтвердить. Чтобы предупреждение не выскочило мы можем запустить установку с ключем –y По окончанию установки мы опять проверяем версию. Система покажет версию и билд Java. Теперь наш сервер готов к началу установки Jenkins. Добавляем ключ и репозиторий в операционную систему: curl -fsSL https://pkg.jenkins.io/debian-stable/jenkins.io.key | sudo tee /usr/share/keyrings/jenkins-keyring.asc > /dev/null echo deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] https://pkg.jenkins.io/debian-stable binary/ | sudo tee /etc/apt/sources.list.d/jenkins.list > /dev/null sudo apt-get update – обновляем репозиторий sudo apt-get install Jenkins – инсталлируем непосредственно сам Jenkins Теперь мы можем сделать пост настроечные мероприятия непосредственно в Jenkins. Открываем браузер и переходим на веб интерфейс http://ipaddr:8080, где вместо ipaddr – подставляем IP адрес сервера. В ответ получаем вот такое сообщение - Unlock Jenkins Система просит ввести дополнительный ключ, который был сгенерирован при установке сервера. Найти его достаточно просто достаточно ввести в консоли сервера sudo cat /var/lib/jenkins/secrets/initialAdminPassword Копируем и вставляем в веб форму. После прохождения этой несложной системы безопасности мы можем начать базовую настройку. Система предлагает выбрать стандартную установку или кастомизированную с выбором плагинов (расширений для различного функционала). Если мы выбираем стандартную установку, установятся только те плагины, которые сами разработчики протестировали и выбрали. Если мы выберем установку с выбором, соответственно система даст возможность установить не только стандартные, но и другие плагины. Выбираем стандартную установку и начинается процесс настройки самого Jenkins. Мы можем видать, что ставится git плагин, LDAP для работы с Active Directory, ssh для взаимодействия по протоколу ssh, расширение E-mail для отправки уведомлений и.т.д После непродолжительного ожидания, система предлагает создать суперпользователя с правами администратора в системе. Заполнение не сложное. Если бы мы выбрали другой вариант установки, то система нам предложила бы выбрать самостоятельно нужные плагины. Примерно вот в такой форме. Форма от версии к версии может отличатся. По окончанию заполнения формы, попадаем на экран где нам предлагают проверить URL, т.к эти данные будет Jenkins использовать, как переменные среды. В итоге мы попадаем на главный экран Jenkins. Данный экран – это основной рабочий стол. С помощью плагинов его можно кастомизировать. Так же можно в джобы добавить много разных параметров.
img
Протокол EIGRP имеет гораздо более быструю сходимость по сравнению с протоколами RIP и IGRP, потому что в отличие от дистанционно – векторных протоколов маршрутизации, которым необходимо передать таблицы маршрутизации для сходимости, в протоколе EIGRP соседи маршрутизаторы обмениваются только “Hello” пакетами. Используя протокол EIGRP, маршрутизаторы узнают друг друга в процессе сходимости, обмениваясь различными параметрами для установления таблиц маршрутизации. Аналогичные процессы происходят в протоколе OSPF и других протокола состояния канала. Два маршрутизатора могут стать соседями только при выполнении следующих условий: Произошел успешный обмен “Hello” сообщениями Интерфейсы находятся в рамках одной автономной системы Используют одинаковые метрики: EIGRP использует полосу пропускания и задержку в качестве метрик по умолчанию. Если вы решите использовать и другие метрики, такие как загрузка, надежность и MTU, то их необходимо настроить на обоих маршрутизаторах. Таймера “Hello” пакетов используют одно и то же значение для следующих значений: Частота, с которой маршрутизаторы отправляют “Hello” пакеты друг другу. Время, в течении которого, маршрутизатор не отвечает на пакеты и маркируется недоступным. «Hello» пакеты отправляются не только во время процесса сходимости, но и после, для отслеживания статуса того, или иного узла маршрутизации. Если маршрутизатор становится недоступен (не отвечает на пакеты «Hello»), то по истечению указанного выше таймера маршрутизатор отмечаются как недоступный. Обновление маршрутов Даже после полной сходимости, EIGRP продолжает обновлять маршруты на основании доступности роутеров – соседей. Это позволяет маршрутизаторам поддерживать свою собственную таблицу «состояния связей», или по другом, link – state. После того, как маршрутизаторы построят таблицу соседей и таблицу состояния связей, они знают своих соседей, топологию сети в своем ближайшем окружении и топологию сети в ближайшем окружении своих соседей. Далее, каждый маршрутизатор рассчитывает параметры и качество каждого маршрута, который находятся в таблице состояния связей. EIGRP использует DUAL (Diffusing Update Algorithm) для расчета качества маршрута. DUAL (Diffusing Update Algorithm) Cisco использует Diffusing Update Algorithm, или DUAL алгоритм для расчет качества сетевого маршрута в рамках протокола EIGRP. Алгоритм DUAL повышает эффективность протокола EIGRP по сравнению с IGRP, предотвращая появление петель маршрутизации. Отметим следующие характеристики алгоритма DUAL: Для каждой сети назначения рассчитывается маршрут через Successor, или другими словами – лучший маршрут, а также, рассчитывается маршрут через Feasible Successor (второй по приоритету маршрут). DUAL поддерживает маски переменной длинны или VLSA (variable-length subnet masking), позволяя EIGRP выполнять маршрутизации в различных подсетях. Алгоритм DUAL очень быстро рассчитывает новый маршрут в пункт назначения, в случаях, если основной маршрут недоступен. DUAL поддерживает две опции, которые обеспечивают быстрый переход на новую маршрутизацию в случаях недоступности: Successor и Feasible Successor маршруты. Для каждого из путей у EIGRP всегда есть резервный путь. Если оба маршрута, Successor и Feasible Successor недоступны, DUAL выполняет опрос соседей маршрутизаторов, для выбора лучшего маршрута. По причине того, что каждый из соседей маршрутизатора так же имеют Successor и Feasible Successor маршруты, новый маршрут в сеть назначения, полученный от них, является наиболее приемлемым и качественным с точки зрения метрик.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59