По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В данной статье мы рассмотрим процессы 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. Данный экран – это основной рабочий стол. С помощью плагинов его можно кастомизировать. Так же можно в джобы добавить много разных параметров.
Есть разные причины, по которым все идет не так в наших сетях: люди делают ошибки в своих настройках, оборудование может выйти из строя, обновления программного обеспечения могут включать ошибки, а изменение структуры трафика может вызвать перегрузку в наших сетях. Для устранения этих ошибок существуют различные подходы, и некоторые из них более эффективны, чем другие.
Устранение неполадок состоит из 3 этапов:
Все это начинается, когда кто-то или что-то сообщает о проблеме. Часто это будет пользователь, который звонит в службу поддержки, потому что что-то работает не так, как ожидалось, но также возможно, что вы обнаружите проблемы из-за мониторинга сети (Вы ведь контролируете свою сеть?). Следующий шаг - это диагностика проблемы, и очень важно найти ее корень. Как только вы обнаружите проблему, вы реализуете (временное) решение.
Диагностика проблемы является одним из самых важных шагов, чтобы устранить неполадки в сети. Для начала нам нужно найти первопричину проблемы. И для этого, необходимо выполнить ряд действий:
Сбор информации: в большинстве случаев отчет о проблеме не дает нам достаточно информации. Пользователи просто нам сообщают, что "сеть не работает" или "Мой компьютер не работает", но это нам ничего не дает. Мы должны собирать информацию, задавая нашим пользователям подробные вопросы, или мы используем сетевые инструменты для сбора информации.
Анализ информации: как только мы собрали всю информацию, мы проанализируем ее, чтобы увидеть, что не так. Мы можем сравнить нашу информацию с ранее собранной информацией или другими устройствами с аналогичными конфигурациями.
Устранение возможных причин: нам нужно подумать о возможных причинах и устранить потенциальные причины проблемы. Это требует досконального знания сети и всех протоколов, которые в ней задействованы.
Гипотеза: после определения возможных причин, вы в конечном итоге получите список этих причин, которые могут вызывать проблему работу сети. Мы выберем самую наиболее вероятную причину возникновения проблемы.
Проверка гипотезы: мы проверим нашу гипотезу, чтобы увидеть, правы мы или нет. Если мы правы, у нас есть победа...если мы ошибаемся, мы проверяем наши другие возможные причины.
Если вы применяете структурированный подход для устранения неполадок, вы можете просто "следовать интуиции" и запутаться, потому что вы забыли, что вы уже пробовали или нет. Это упрощает поиск проблемы, если вы работаете вместе с другими сетевыми администраторами, потому что вы можете поделиться шагами, которые вы уже выполнили.
Вот шаги поиска проблемы в хорошей блок-схеме. Мы называем это структурированным подходом к устранению неполадок.
Вместо того чтобы выполнять все различные этапы структурированного подхода к устранению неполадок, мы также можем перейти от этапа "сбор информации" непосредственно к шагу "гипотеза" и пропустить этапы "анализ информации" и "устранение возможных причин". По мере того, как вы наберётесь опыта в устранении неполадок, вы сможете пропустить некоторые шаги.
Шаги, которые мы пропускаем, выделены синим цветом. Если вас ваши интуиция подведет, то вы потеряете много времени. Если вы правы, то вы сэкономите много времени.
Устранение возможных причин является важным шагом в процессе устранения неполадок, и есть несколько подходов, как вы можете это сделать.
Вот они:
Сверху вниз;
Снизу вверх;
Разделяй и властвуй;
Отследить путь трафика;
Поиск отличий;
Замена компонентов.
Давайте пройдемся по разным подходам один за другим!
Метод "сверху вниз"
"Сверху вниз" означает, что мы начинаем с верхней части модели OSI (прикладной уровень) и продвигаемся дальше вниз. Идея заключается в том, что мы проверим приложение, чтобы увидеть, работает ли оно, и предположим, что если определенный уровень работает, то все нижеперечисленные уровни также работают. Если вы посылаете эхо-запрос с одного компьютера на другой (ICMP), то можете считать, что уровни 1,2 и 3 работают. Недостатком этого подхода является то, что вам нужен доступ к приложению, в котором устраняете неполадки.
Метод "снизу вверх"
"Снизу вверх" означает, что мы начинаем с нижней части модели OSI и будем продвигаться вверх. Мы начнем с физического уровня, который означает, что мы проверяем наши кабели и разъемы, переходим к канальному уровню, чтобы увидеть, работает ли Ethernet, связующее дерево работает нормально, безопасность портов не вызывает проблем, VLAN настроены правильно, а затем переходим на сетевой уровень. Здесь мы будем проверять наши IP-адреса, списки доступа, протоколы маршрутизации и так далее. Этот подход является очень тщательным, но и отнимает много времени. Если вы новичок в устранении неполадок рекомендуется использовать этот метод, потому что вы устраните все возможные причины проблем.
"Разделяй и властвуй"
Разделяй и властвуй означает, что мы начинаем с середины OSI-модели. Вы можете использовать эту модель, если не уверены, что нисходящее или восходящее движение более эффективно. Идея заключается в том, что вы попытаетесь отправить эхо-запрос с одного устройства на другое. Если ping работает, вы знаете, что уровень 1-3 работает, и вы можете продвинуться вверх по модели OSI.
Если эхо-запрос терпит неудачу, то вы знаете, что что-то не так, и вы будете причину проблемы в нижней части модели OSI.
"Путь трафика"
Изучение путь следования трафика очень полезно. Сначала мы попытаемся отправить эхо-запрос с хоста A на хост B. В случае сбоя мы проверим все устройства на его пути. Сначала мы проверим, правильно ли настроен коммутатор A, и, далее, мы перейдем на коммутатор B, проверим его, а затем перейдем к маршрутизатору A.
"Поиск отличий"
Этот подход вы, скорее всего, делали и раньше. Поиск отличий в конфигурации или вывод команд show может быть полезным, но очень легко что-то пропустить. Если у вас есть несколько маршрутизаторов филиала с похожей конфигурацией, и только один не работает, вы можете заметить отличие в конфигурациях. Сетевые администраторы, которые не имеют большого опыта, обычно используют этот подход. Возможно, вам удастся решить проблему, но есть риск, что вы на самом деле не знаете, что делаете.
"Замена компонентов"
Последний подход к решению нашей проблемы - это замена компонентов. Допустим, у нас есть сценарий, в котором компьютер не может получить доступ к сети. В приведенном выше примере мы можем заменить компьютер, чтобы устранить любую вероятность того, что компьютер является проблемой. Мы можем заменить кабель, и, если мы подозреваем, что коммутатор не работает или неверно настроен, мы можем заменить его на новый и скопировать старую конфигурацию, чтобы увидеть, есть ли какие-либо проблемы с оборудованием.
Веб-сервер - это серверное приложение, предназначенное для обработки HTTP-запросов между клиентом и сервером. HTTP - это базовый и широко используемый сетевой протокол.
Apache HTTP Server сыграл важную роль в разработке веб-сайтов. Только у него доля рынка 37,3%. Nginx занимает второе место в списке, с долей рынка 32,4%. Microsoft IIS и LiteSpeed с долей рынка 7,8% и 6,9% занимают 3 и 4 места соответственно.
Но недавно я наткнулся на веб-сервер с названием Caddy. Когда развернул его для тестирования и попытался узнать о его функциях, был приятно удивлён. Это переносимый веб-сервер с минимальной конфигурацией. Я решил, что это очень крутой проект и захотел поделиться им с вами.
Что такое Caddy?
Caddy с его простотой в настройках и использовании является альтернативой популярному веб-серверу Apache. Мэтью Холт - руководитель проекта Caddy утверждает, что их продукт является веб-сервером общего назначения, и он предназначен для обычных людей, и, вероятно, является единственным в своем роде.
Caddy является первым и единственным веб-сервером, который может автоматически получать и обновлять сертификаты SSL/TLS с помощью сервиса Let 's Encrypt.
Функции Caddy
Быстрое выполнение HTTP-запросов с использованием HTTP/2.
Веб-сервер с наименьшей конфигурацией и беспрепятственным развертыванием.
TLS шифрование обеспечивает безопасную связь между приложениями и пользователями через Интернет. Вы можете использовать собственные ключи и сертификаты.
Простота развертывания/использования. Только один файл без зависимости от платформы.
Установка не требуется.
Портативные исполняемые файлы.
Запуск нескольких ЦП/ядер.
Усовершенствованная технология WebSockets - интерактивный сеанс связи между браузером и сервером.
Разметка документов на лету.
Полная поддержка нового протокола IPv6.
Создает журнал в пользовательском формате.
Поддержка Fast CGI, обратного прокси, перезаписи и перенаправления, чистый URL-адрес, сжатия Gzip, просмотра каталогов, виртуальных хосты и заголовков.
Доступно для всех известных платформ - Windows, Linux, BSD, Mac, Android.
Чем отличается Caddy?
Caddy стремится обслуживать интернет, как это должно быть в 2020 году, а не в традиционном смысле.
Обладает новейшими функциями - HTTP/2, IPv6, Маркдаун, WebSockets, CreateCGI, шаблоны и другие стандартные функции.
Запуск исполняемые файлы без установки.
Подробная документация с наименьшим техническим описанием.
Разработан с учетом потребностей конструкторов, разработчиков и блоггеров.
Поддержка виртуального хоста можете создавать любое количество сайтов.
Подходит для всех - независимо от того, является ли ваш сайт статическим или динамическим.
Вы фокусируетесь на том, чего достичь, а не на том, как этого добиться.
Доступность поддержки большинства платформ - Windows, Linux, Mac, Android, BSD.
Обычно на каждый сайт приходится по одному файлу Caddy.
Возможность настройки буквально за 1 минуту, даже для тех, кто не сильно дружит с компьютером.
Тестовая среда
Я буду тестировать его на сервере CentOS, а также на сервере Debian, но те же инструкции работают и на дистрибутивах RHEL и Debian. Для обоих серверов я буду использовать 64-разрядные исполняемые файлы.
Установка веб-сервера Caddy на Linux
Независимо от используемой платформы и архитектуры Caddy предоставляет готовые установщики, которые можно запустить с помощью встроенного в систему пакетного менеджера.
Установка Caddy на Fedora, RedHat, CentOS
Мы установим последнюю версию веб-сервера Caddy из репозитория CORP на Fedora и RHEL/CentOS8.
# dnf install 'dnf-command(copr)'
# dnf copr enable @caddy/caddy
# dnf install caddy
На RHEL/CentOS 7 используйте следующие команды:
# yum install yum-plugin-copr
# yum copr enable @caddy/caddy
# yum install caddy
Установка Caddy на Debian и Ubuntu
$ echo "deb [trusted=yes] https://apt.fury.io/caddy/ /"
| sudo tee -a /etc/apt/sources.list.d/caddy-fury.list
$ sudo apt update
$ sudo apt install caddy
Установив веб-сервер Caddy, с помощью следующих команд systemctl его можно запустить, активировать или же проверить статус:
# systemctl start caddy
# systemctl enable caddy
# systemctl status caddy
Теперь откройте браузер и введите следующий адрес, и вы должны увидеть страницу приветствия Caddy:
http://Server-IP
OR
http://yourdomain.com
Настройка доменов в Caddy
Чтобы настроить домен, сначала необходимо указать DNS-записи A/AAAA домена на этом сервере на панели управления DNS. Затем создайте корневой каталог документа для веб-сайта "example.com" в папке/var/www/html, как показано на рисунке.
$ mkdir /var/www/html/example.com
При использовании SELinux необходимо изменить контекст безопасности файлов для веб-содержимого.
# chcon -t httpd_sys_content_t /var/www/html/example.com -R
# chcon -t httpd_sys_rw_content_t /var/www/html/example.com -R
Теперь откройте и отредактируйте файл конфигурации caddy по адресу /etc/caddy/Caddyfile.
# vim /etc/caddy/Caddyfile
Замените :80 на название вашего домена и измените корень сайта на /var/www/html/example.com, как показано на рисунке.
Чтобы изменения вступили в силу перезапустите службу Caddy:
# systemctl reload caddy
Теперь создайте какую-нибудь HTML-страницу (можно создать собственную) и сохраните её в корневом каталоге веб-сайта.
# touch /var/www/html/example.com/index.html
Добавьте следующий HTML-код в только что созданный файл.
# echo '<!doctype html><head><title>Caddy Test Page at TecMint</title></head><body><h1>Hello, World!</h1></body></html>' | sudo tee /var/www/html/index.html
А теперь перезагрузите страницу, и вы должны увидеть нечто подобно скриншоту ниже:
Если все настроено правильно, домен будет доступен по протоколу HTTPS, что означает на вашем сайте настроено безопасное SSL подключения.
Заключение
Если вы новичок и хотите настроить веб-сервер, не заморачиваясь долгой настройкой, этот инструмент идеально подходит для вас. Даже если вы опытный пользователь, который нуждается в мгновенном и простом веб-сервере, то стоит обратить внимание на Caddy. Если необходим более навороченный сервер с расширенными возможностями, то можно с минимальными конфигурациями задать разрешения на папки, управлять аутентификацией, страницей ошибок, архивацией, перенаправлением HTTP запросов и другими настройками.
Конечно же нельзя воспринимать Кэдди в качестве замены Apache или Nginx. Caddy не предназначен для работы в среде с высоким трафиком. Но он хорошо подойдёт в тех случаях, где нужно быстро настроить надежный веб-сервер.