По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Каждое семейство операционных систем производит загрузку по-своему. Это связанно с различной архитектурой ядра операционной системы, разными инструкциями по работе с подключенными устройствами. В данной статье попробую разобрать загрузку популярной операционной системы на ядре Linux Ubuntu.
Схематично процесс загрузки можно отобразить следующим образом.
Загружаемся
Итак, Нажимаем кнопку включения компьютера, и центральный процессор переходит на адрес BIOS. BIOS или UEFI, в более современных компьютерах, проводит систему проверок и выбирает носитель информации с которого будет производится загрузка операционной системы. На носителе находится MBR (Master Boot Record) или GPT (Guid Partition table) на новых компьютерах в которых находится загрузчик. А дальше уже в зависимости от настройки. Загрузчик может самостоятельно загружать операционную систему, а может передавать управление следующему загрузчику. Например, если Windows и Linux установлены на одном компьютере и находятся на разных разделах жесткого диска.
В любом случае, если идет речь о Linux у нас есть первая стадия с небольшой частью кода, которая загружает у нас загрузчик. Загрузчик знает где лежит ядро операционной системы, загружает ядро, загружает initial run disk, там находятся необходимые файлы и модули для загрузки ядра. Далее уже ядро берет процесс управления на себя. Происходит инициализация устройств, конфигурирование процессов памяти и так далее. После всех этих процессов ядро запускает процесс init.
Вернемся к вопросу загрузчиков, для каждой операционной системы разработан свой загрузчик, а иногда и несколько. NTLDR - Загрузчик операционной системы Windows, LILO - один из стандартных загрузчиков для Linux и BSD системы. GRUB - загрузчик операционной системы от проекта GNU. Нас интересуют последние два. Данные загрузчики работают в два этапа. На первом этапе у них крошечный код на MBR или GPT, который запускает исполнение кода второго этапа.
Перейдем непосредственно к самой загрузке.
Данное меню мы можем получить при загрузке если зажать клавишу Shift. Как видно на картинке в данном примере загрузчик GRUB версии 2.04. У нас есть несколько вариантов. Загрузка Ubuntu по умолчанию и вариант загрузки с расширенными опциями. В нашем случае расширенные опции не дают многого, а всего лишь позволяют начать загрузку в режиме восстановления recovery mode. Данная опция не является целью стати, и мы ее опустим. Вернемся к первому пункту загрузки. Выбираем, нажимаем "e" получаем следующую картину загрузки.
На данной картинке можно увидеть, что корневой раздел монтируется по uuid, он будет корневым root и непосредственно сам id. ID раздела можно посмотреть после загрузки операционной системы командой blkid. Можно часть параметров отредактировать или большинство. Более подробно можно поискать в интернете. По нажатию F10 осуществляется продолжение загрузки операционной системы.
После загрузки операционной системы, мы можем с помощью команды dmesg посмотреть, сообщения ядра, все что происходило с ядром. Нужно различать сообщения ядра и лог ядра. Который можно посмотреть cat /var/log/dmesg. Данный файл содержи информацию только о загрузке операционной системы. В данном файле содержится информация с самого начала загрузки операционной системы и до конца. Если событие происходит позднее, то в данном файле этой информации вы не найдете.
Система инициализации ОС
Есть такое понятие Init - это первый или родительский процесс, который запускает все последующие процессы. Это может быть проверка и монтирование файловых систем запуск служб и.т.д. Существует 3 варианта работы этого родительского процесса.
Init в стиле SysV - родительский процесс инициализации системы на одном из заданных уровней запуска (runlevel); Т.е. есть несколько уровней загрузки (runlevel) обычно их 7 штук. Один из них - это обычный многопользовательский режим. Другие это выключение компьютера, перезагрузка, режим восстановления и т.д.
Init в стиле systemd - родительский процесс инициализации системы в ускоренном режиме, за счёт параллельного запуска задач; Ускоренный режим достигается за счет использования процессора в частности Intel, который позволяет запускать процессы инициализации параллельно. К этому режиму есть еще куча софта библиотек, которые расширяют функционал.
Init в стиле Upstart - родительский процесс инициализации системы на основе отслеживания событий; Данный режим используется на Ubuntu уже давным - давно, тут не только запускаются скрипты инициализации, но и запускаются скрипты отслеживания событий и реагирования на них. Т.е. это более гибкий процесс инициализации, например, если какая-то служба не запустилась или упала в процессе загрузки то, upstart умеет это отследить и запустить это повторно
В операционной систему Ubuntu можно посмотреть дерево процессов использую команду pstree. В результате ее вывода мы можем увидеть, что родительским процессом являлся процесс systemd. Который запускал уже свои, какие-то дочерние процессы. Перейдем в корневую директорию boot.
Здесь мы можем увидеть директорию загрузчика grub. Ядра линуксовые vmlinuz (ссылка на ядро) и до обновления старое ядро vmlinux.old (ссылка на старое ядро). Соответственно пара initrd* - файлы диска, эти файлы содержат диск, который грузится в оперативную память, данный диск содержит файлы необходимые самому ядру Linux для нормальной загрузки.
Перейдя в директорию grub, мы можем найти конфигурационный файл grub.cfg и несколько вспомогательных, но не менее важных фалов. Соответственно мы можем внести изменения в данный файл на постоянной основе и соответственно данный код будет выполнятся при каждой загрузке операционной системы.
В данной статье мы рассмотрим процессы 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. Данный экран – это основной рабочий стол. С помощью плагинов его можно кастомизировать. Так же можно в джобы добавить много разных параметров.
Одним из ключевых факторов, которые следует учитывать при разработке веб-сайта или веб-приложения, является пропускная способность, которая потребуется вашему сетапу для правильной работы.
Знание требований к пропускной способности поможет вам выбрать правильного хостинг-провайдера и составить план в соответствии с вашими потребностями.
В этом руководстве мы покажем вам, как рассчитать пропускную способность, необходимую для вашего веб-сайта или веб-приложения.
Что такое пропускная способность?
Пропускная способность представляет собой максимальную емкость данных, которые могут быть переданы по сети за одну секунду. Наименьшая единица измерения выражается в битах в секунду. С развитием технологий интернет-провайдеры теперь используют мегабит в секунду (Мбит/с) или гигабит в секунду (Гбит/с).
Пропускная способность - это термин, который описывает объем трафика между вашим сайтом и пользователями через Интернет. Не путайте пропускную способность со скоростью соединения, поскольку они не совпадают.
Пропускная способность против передачи данных
Термин пропускная способность иногда используется как синоним передачи данных. На самом деле это две очень разные вещи.
Пропускная способность определяет максимальный потенциальный объем данных, который вы можете передавать за единицу времени между вашим сайтом и пользователями. Этот термин отражает не фактические данные, которые вы передаете, а теоретический объем данных, который вы можете обработать за одну секунду.
С другой стороны, под передачей данных понимается фактический общий объем данных, которые вы передаете за период, обычно за месяц. Единицы измерения - килобайты (КБ), мегабайты (МБ), гигабайты (ГБ), а для больших приложений - терабайты (ТБ).
Важность пропускной способности
Расчет правильной полосы пропускания для вашего веб-приложения имеет решающее значение на этапе разработки и для обеспечения стабильной производительности. Обязательно учитывайте внезапные всплески трафика. Хорошее правило - на 50% превышать прогнозируемую потребность в пропускной способности.
Однако при выборе веб-хостинга расчет может показаться ненужным, поскольку большинство хостинг-провайдеров предлагают планы с «неограниченной» пропускной способностью.
Примечание: ваша система может со временем расширяться, и требования к пропускной способности могут возрасти. Поэтому выберите масштабируемый план, позволяющий при необходимости изменять пропускную способность.
Что такое неограниченная пропускная способность
Многие провайдеры рекламируют планы с «неограниченной» пропускной способностью. Эта формулировка подразумевает, что вы можете передавать столько данных, сколько вам нужно. Здесь веб-хостинг предлагает фиксированную ставку, которая упрощает покупку и поиск решения для хостинга.
Однако правда в том, что хостинговые компании не могут предложить действительно неограниченную пропускную способность. Затраты и технологические требования были бы слишком высокими для этого.
По этой причине планы с неограниченной пропускной способностью предлагают достаточную пропускную способность, чтобы удовлетворить потребности большинства клиентов. Таким образом, планы кажутся неограниченными для этих пользователей. В большинстве случаев обычные планы покрывают стандартные требования к веб-приложениям. Есть также планы для более продвинутых клиентов, обеспечивающие скорость, превышающую ту, которую предлагают обычные безлимитные планы.
Расчет требований к пропускной способности
Прежде чем рассчитывать требования к пропускной способности, вы должны знать средний размер страницы на вашем веб-сайте.
Чтобы определить размер, используйте тест времени загрузки и учитывайте данные как минимум для десяти страниц. Затем рассчитайте средний размер страницы для вашего сайта.
Имея эту информацию, вам необходимо учесть еще два элемента:
Количество посещений ваших страниц.
Дополнительная пропускная способность может потребоваться в случае всплеска трафика. Это предотвращает потенциальные проблемы с производительностью или даже простои.
Есть две формулы для расчета необходимой пропускной способности.
Требования к пропускной способности веб-сайта без скачиваний пользователем
Если ваш веб-сайт не предлагает посетителям загружаемый контент, используйте следующую формулу для расчета необходимой пропускной способности:
Пропускная способность = Средний размер страницы * Среднее количество просмотров страницы * Среднее количество посетителей в день * 30 * Избыточность
Средний размер страницы - это средний размер вашей веб-страницы.
Среднее количество просмотров страницы - среднее количество просмотров страницы на посетителя.
Среднее количество посетителей в день - среднее количество посетителей в месяц.
30 - число дней в месяце.
Избыточность - фактор безопасности для предотвращения скачков трафика. Диапазон от 1,3 до 1,8.
Расчет немного отличается, когда ваш сайт предлагает загружаемый контент.
Требования к пропускной способности веб-сайта со скачиванием
Чтобы рассчитать необходимую пропускную способность, когда ваш веб-сайт предлагает загружаемый контент, используйте следующую формулу:
Пропускная способность = [(Средний размер страницы * Среднее количество просмотров страницы * Среднее количество посетителей в день) + (Средняя загрузка в день * Средний размер файла)] * 30 * Избыточность
Новые параметры в этой формуле:
Среднее количество загрузок в день - представляет собой среднее количество загружаемых файлов в день.
Средний размер файла - это средний размер загружаемых файлов.
С помощью этого расчета вы знаете прогнозируемые требования к пропускной способности для пользовательских загрузок.