ВСЕ ЧТО НУЖНО ЗНАТЬ ПРО LINUX transcript

Всем привет. Вы на канале Просто Devоops. Мы часто говорим слово Linux, подразумевая операционную систему Убунту, Центоз, Debн, но с инженерной точки зрения это неверно. Linux - это ядро. По сути кусок кода, который управляет железом. А всё, что мы видим на экране, всё, с чем мы взаимодействуем - это просто набор программ, которые крутятся поверх этого ядра. И в этом видео мы разберёмся, как этот самый Linux устроен. Начнём с самого низа, а именно с железа. Нажимаем кнопку питания на сервере. Пошёл ток. Процессор просыпается, но в этот момент он пока что тупой кусок кремния. Он не знает, что такое Linux. Он не знает, что такое файлы. Он даже не знает, сколько у него оперативной памяти. Он просто ищет первую инструкцию по жёстко заданному адресу. Первый стартует прошивка материнской платы BIOS или же Wi-Fi. Её задача - привести железо в чувство. Она запускает пост power on self-теest, проверяет, есть ли память, работает ли видеокарта, инициализировался ли процессор, нашёл ли он оперативку и так далее. Затем она начинает опрашивать устройство и ищет, с кого можно загрузиться. Допустим, она нашла жёсткий диск, но BIOS сам не умеет читать файловые системы. Он не знает, что такое XT4 или XFS. Он не может просто взять и открыть файл, поэтому он считывает самые первые 512 байт диска. Это MBR или же смотрит в специальный Ефии раздел. А там живёт загрузчик. В мире Linux - это почти всегда Граб 2. Граб - это маленькая, но умная программа. Её единственная способность, она умеет читать файловую систему. Заглядывает в раздел boot. Там лежат два критически важных файла, без которых никакой магии не случится. Первый файл - это VM Linux. По сути, и есть тот самый Linux. Это само ядро, сжатое в бинарный файл. Буква Z в конце означает zip, то есть сжатый. Граб берёт этот файл, распаковывает его прямо в оперативную память и передаёт ему управление. Всё. С этого момента BI уходит курить в сторонку, загрузчик умирает. Теперь в системе только один босс - это ядро. И [музыка] вот тут ядро сталкивается с главной инженерной проблемой, проблемой курицы и яйца. Ядро загрузилось в память. Его задача смонтировать наш основной диск, чтобы запустить систему. Но чтобы смонтировать диск, нужны драйверы файловой системы и контроллера диска. А где лежат драйверы? Правильно, на том самом диске, который мы ещё не можем прочитать, потому что у нас нет драйверов. Замкнутый круг. Именно для этого Граб загрузил второй файл InitramfS. Это маленький временный архив, который разворачивается в оперативной памяти как виртуальный диск. Внутри него лежит мини-версия Линукса с минимальным набором драйверов. Соответственно, что происходит? Ядро монтирует Иit Ram FS как временный корень. Оттуда оно подгружает драйверы для нашего реального железа. Рейд-контроллеры, NVME, LVM и так далее. Далее оно находит настоящий большой диск и делает трюк под названием Pvot root, то есть смена корня. Ядро выкидывает временный диск из памяти и заменяет его настоящим. Если сервер виснет на этапе загрузки с ошибкой, которую вы видите на экране, это значит, что ядро застряло именно в этом моменте. Оно либо не нашло ИitромFS, либо внутри него не оказалось нужного драйвера для диска. Итак, загрузчик отработал, драйверы подгрузились, мы попадаем в knalel Space. С точки зрения архитектуры процессора мы находимся в кольце защиты RН. Здесь разрешено всё: любая инструкция процессора или любой адрес памяти.

Linux - это монолитное ядро, а не набор разрожденных сервисов. Драйвер видеокарты, сетевой стек TCPIP, драйвер файловой системы XT4. Всё это варится в одном гигантском котле в едином адресном пространстве. И это даёт дикую производительность, потому что нет накладных расходов на общение между компонентами. Но это повышает риски. Если драйвер кривой видеокарты упадёт, он утащит за собой весь сервер в KNAL Pic. [музыка] А у самого ядра есть три основных задачи. Сейчас посмотрим на каждую из них. Первое - это управление памяти. И на самом деле здесь главная задача ядра - врать. Оно врёт нашим программам. Когда условный Инжинс или Python просит память, он думает, что единственный в системе. Для него [музыка] всё выглядит как красивая непрерывная лента адресов. Хотя на самом деле физическая память фрагментирована, и куски данных разбросаны хаотично. Ядро использует механизм виртуальной памяти. Оно ведёт гигантскую таблицу, где записано: "Виртуальный адрес X для процесса Ins на самом деле лежит в физической ячейке Y. И это даёт две вещи. Первое - изоляция. Один процесс физически не может залезть в память другого. А второе - это свопинг. То есть ядро может незаметно выгрузить часть данных на диск, если оперативка закончилась. Но если память кончилась совсем и своп тоже забит, то приходит омкиллер. И он неспроста так назван. Это буквально киллер, который нанял ядро. Он просыпается, сканирует таблицу процессов и находит того, кто ест больше всех и имеет при этом низкий приоритет, и пускает ему пулю в лоб. Например, в том же Кубере это происходит постоянно. Если мы неправильно настроим лимиты в кодах, то омкилillлер будет приходить и молча убивать наше приложение. Вторая задача ядрать время между процессами. И для этого существует так называемый планировщик процессор. Допустим, у нас на сервере четыре ядра, а запущено 500 процессов. Как они работают одновременно?

[музыка] Никак. Это иллюзия. Ядро использует вытесняющую многозадачность. Оно даёт процессу проработать несколько миллисекунд, так называемый квант времени. а потом жёстко его останавливает, и происходит свитч контекста. То есть ядро сохраняет состояние регистров процессора [музыка] для текущей задачи, загружает состояние для следующей задачи и нажимает Play. И это происходит тысячи раз в секунду. Если мы видим в мониторинге высокий LТ average, но процессор не загружен на 100%, возможно, система тратит всё время не на работу, а на бесконечное переключение контекста между тысячами процессов. А про Load average у нас, кстати, было видео. Вот оно. Ну и третья задача ядра - это абстракция оборудования. Если говорить по простому, то ядро выступает в качестве переводчика. Программы, которые запущены в юзерспейсе, то есть наши программы пользовательские, не знают железа. Вот условно у нас есть программа на Питоне, которая записывает одно слово в файл, но только Python не знает, куда он записывает. На самсунговскую сиздишку, на какой-то старый жёсткий диск или вообще на сетевую шару. У каждого диска свой протокол, свои вольтажи, свои команды контроллера, а ядро предоставляет универсальный интерфейс. Программа буквально говорит: "Пиши в этот файл". А драйвер ядра переводит это в электрические сигналы. И благодаря этому наш код работает одинаково на любом железе. Двигаемся выше. У нас есть ядро, которое всем управляет. И есть наши программы, которые хотят что-то сделать: прочитать файл, отправить пакет или вывести текст на экран. Но есть проблема. Между режимом пользователя, где живут наши программы, и режимом ядра. Стоит бетонная [музыка] стена. Процессор физически запрещает коду из юзерспейса обращаться к оборудованию. И если наша программа пытается напрямую обратиться к диску, процессор немедленно её убьёт с ошибкой Segmentation Fold. И как же нам быть? На самом деле, в этой стене есть однаединственная бронированная дверь. Она называется системный вызов. Это строго регламентированный АПИ. Ядро говорит, что оно не пустит нас к диску, но если мы вежливо попросим через специальную функцию, то оно сделает это за нас. И давайте рассмотрим это на примере того же Питона. Вот мы пишем Print Hello World, но происходит целая цепочка событий. Интерпретатор питона вызывает стандартную библиотеку C gpc. Библиотека формирует системный вызов Rightй. Она кладёт аргументы в регистры процессора и генерирует специальное программное прерывание. Процессор останавливает программу, переключает режим в ринг ноль, тот самый режим бога, о котором мы говорили в самом начале, и передаёт управление ядру. Ядро проверяет, а есть ли у этого юзера права писать в этот файл. И если всё о'кей, то ядро рисует пиксели на экране или пишет байты на диск, а дальше возвращает управление программе. И на самом деле системных вызовов великое множество, их в районе 300-400. Но основные сисколы, которые нужно знать, на которых держится вся база, сейчас у вас на экране. Это Fork Exeg, это Open и Close, это Rit и Right, это Socket и Connect. Но зачем это знать именно Divпсу? А потому что программы часто врут. Логи могут быть пустыми, а ошибки неинформативными. Но программа не может врать [музыка] ядру. Она обязана давать все ссколы, чтобы хоть что-то сделать. И здесь на сцену выходит самый главный инструмент отладки Sraйс. Это прослушка для сисколов. Мы запускаем Sraйс на какой-то процесс и видим всю подноготную, что он пытался сделать, [музыка] что он получил или на чём он завис.

Sraйс - это рентген. Он показывает нам, что программа пытается сказать ядру на самом деле. И если вы умеете читать выводст, то для вас не существует непонятных багов. Продолжаем двигаться вверх по стеку. Ядро загрузилось, инициализировало память и драйверы, но сервер всё ещё пустой. В нём нет ни СШ, ни консоли, ни сети. Чтобы система ожила, ядро должно запустить самый первый процесс в пространстве пользователя. И для этого оно ищет на диске исполняемый файл по адресу sbin/it и запускает его. Этот процесс получает ПиIT 1, его уникальный айдишник. Все остальные процессы в системе Пит 2, 3, 4.000, 10.000 будут потомками этого процесса. Если первый процесс умрёт или завершится, яро решит, что система сломалась и вывалится в KNAL Pic и сервер встанет. А в современном Линуксе роль первого процесса выполняет System D. А почему именно System D? Раньше, во времена CSway и процессы запускались тупо по очереди. Сначала сеть, потом диск, потом база. Это было долго.

System D работает как менеджер зависимостей. Он строит направленный граф, кстати, как в тероформе. Условно говоря, он видит так: зависит от сети, пагress зависит от диска, а SSH ни от чего не зависит и запускает всё это параллельно, максимально утилизируя процессор при загрузке. А что физически делает Systemd при старте? Во-первых, он монтирует реальные диски в дерево каталогов. Во-вторых, он определяет цель загрузки и, в-третьих, [музыка] начинает поднимать юниты. запускает SSHD, чтобы мы могли подключиться, запускает демон докера, чтобы поднялись контейнеры, и так далее. При этом мы, как админ, не можем просто сказать процессу: "Запустись". Мы общаемся с пиtit System CTL. Когда мы пишем System CTL start Engines, по сути, мы отправляем команду System D через определённый сокет.

System D, есть ли у нас права, смотрит в зависимости инжинкса и выполняет системный вызов Fork, то есть создаёт копию себя, и exeg, то есть заменяет копию на бинарник Инжнкса. Так рождается процесс веб-сервера. Он ребёнок систем D. Итак, процессы запущены, но процессы в вакууме бесполезны. Им нужно читать конфиги, писать логи, сохранять картинки. Мы поднимаемся ещё на следующий уровень абстракции файловой системы. И здесь царит главная философия Unix. Всё есть файл. Но давайте разберём это не как лозунг, а как инженерное решение. В винде все привыкли к буквам дисков C, D, E, F и так далее. Это физическое разделение устройств. В Линуксе подход другой.

[музыка] Здесь существует единое дерево каталогов. Оно всегда начинается с корня, то есть символа слыша. Процессу плевать, сколько у нас дисков. Он видит только дерево. Ну и, соответственно, как это работает физически. Внутри ядра есть прослойка VFS. Виртуальная файловая система. Это точно также универсальный интерфейс. Мы берём условный SSD-диск и говорим ядру. Примонтирую его в папку boot. Потом берём сетевой диск и говорим примонтировать его в другой каталог. Берём оперативную память и монтируем её в RН. Для программы всё это выглядит одинаково.

[музыка] Она просто пишет файлы по путям, а ВФэска сама на лету решает, куда отправить эти байты. По кабелю SAD или по сетевому кабелю на другой сервер. Это и есть прозрачность абстракции. Теперь спускаемся ниже. Что такое файл физически? Для нас [музыка] это просто какое-то название, условно photo. JPG, но для ядра имя - это пустой звук. Просто набор байт для удобства кожаного мешка. Для ядра файл - это iнода, индекс нода. Каждый файл в системе - это просто номер. В айноде хранится вся метаинформация, кроме имени: кто владелец, какие права доступа, размер файла, тайм-стампы и самое главное, указатели на сектора диска, где физически лежат нулее единицы. А что тогда такое имя файла? Имя живёт в каталоге. И технически каталог, то есть папка - это тоже файл, но внутри него лежит простая таблица из двух колонок: имя файла и номерноды. И когда мы, например, выполняем команду C и передаём ей имя файла, то ядро в этот момент читает каталог, находит имя, берёт соответствующий номер иноды, потом идёт в таблицу ит, смотрит права и сектора диска и после этого начинает читать данные. Ну, а теперь давайте раскроем концепцию всё есть файл на полную. Помните, мы говорили, что VFS - это абстракция? Так, разработчики Линукса подумали: "А зачем нам ограничиваться дисками? Давайте представим само ядро в виде файлов". Итак, появились папки проs и SIS. В них нет файлов на диске. Размер этих файлов 0 байт. Это иллюзия, но это прямой интерфейс доступа к структурам данных ядра в оперативной памяти. И, например, когда мы читаем файл процpu ядро не идёт на диск, оно опрашивает процессор и генерирует текст ответа на литу. И самое крутое - это работает в обе стороны. Мы можем писать в эти файлы. Хотим включить маршрутизацию пакетов, то есть стать роутером. Нам не надо искать никакую галочку ни в какой панели управления. Мы просто пишем цифру один вот в этот файл, который показан на экране. Ядро перехватывает эту запись и меняет переменную в своём коде. Вот что значит всё есть файл. Это универсальный апи для управления системой. Мы разобрались с хранением, то есть с нашими файловыми системами. Теперь переходим к исполнению. Что такое запущенная программа? Это процесс. Процесс - это изолированный контейнер в памяти, у которого есть свой PID, свои переменные и свои ресурсы. Но процесс в вакууме бесполезен. Ему нужно получать данные и отдавать результат. И здесь снова работает правило, всё есть файл. Когда ядро запускает любой процесс, оно автоматически открывает для него три файла, то есть три канала связи. В таблице файловых дескрипторов они всегда занимают первые три строчки. Первый из них, хотя, вернее сказать, нулевой - это DDIN, то есть стандартный ввод. По умолчанию этот файл привязан к нашей клавиатуре. Процесс читает оттуда то, что мы печатаем. Второй - это D out, то есть стандартный вывод. По умолчанию этот файл привязан к нашему экрану, ну или же терминалу. Сюда летит результат. Иdr, стандартный вывод ошибок тоже привязан к экрану, но это отдельный поток. А зачем разделили stdout и stdr? На самом деле, чтобы мы могли отличить мух от котлет. Если программа работает и сыпет ошибками, мы можем сказать оболочки. Полезные данные, то есть первый индекс, записать в файл data.txt, а ошибки, то есть второй индекс, просто выкинуть в defnal чёрную дыру. В девопсе это база логирования. А теперь переходим к главной магии Linux, символу вертикальной черты Pйpe. Это механизм межпроцессного взаимодействия. Возьмём вот эту команду. Как она работает? Ядро запускает процесс C и процесс греп одновременно, но для CAT оно подменяет stdout, то есть выход, и вместо экрана оно направляет его в специальный буфер памяти пайп. А для ГЕБ ядро подменяет его, то есть вход. И вместо клавиатуры он подключает его к тому же самому буферу. И в чём гениальность? Процессы КТ и ГП не знают о существовании друг друга. Кэт думает, что пишет на экран, а Греб думает, что читает с клавиатуру. Ядро просто переткнуло провода, и это позволяет строить конвейеры любой длины. Вот посмотрите на экран. Пять глупых маленьких программ, соединённых пайпами, превращаются в мощный инструмент аналитики. Это и есть подход Юникса. писать программы, которые делают одну вещь, но хорошо, и научить их работать вместе через текстовые потоки. Мы разобрались, как процессы работают и как данные летают по пайпам. Но кто решает, кому можно читать файл, а кому нельзя? Мы поднимаемся [музыка] на уровень безопасности. В Линуксе безопасность - это не магия антивируса, это простая проверка битов в Вайноде. Когда мы логинимся в систему, мы думаем, что пользуемся админкой. Но ядро не знает слов. Ядро знает только цифры. Наше имя транслируется в UID, user ID. Наша группа транслируется в Git, Group ID. Это база данных соответствии лежит в простых текстовых файлах PVD и etcoup. И помните, мы говорили пройноды. В каждой аноде записано: "Этим файлом владеет UID такой-то, группа [музыка] такая-то. И там же записаны три набора прав: usеer, то есть, что может делать владелец, group, то есть, что может делать группа, иers, что может делать любой другой рандомный процесс. А сами действия примитивны: read, [музыка] то есть читать, write, то есть изменять, и execute, то есть сказать ядру, загрузить [музыка] этот файл в память и исполнить как процесс. И каждое действие имеет своё число. read 4, write 2, execute 1. Почему именно это? Это не случайные цифры. Это битовая маска в двоичной системы. Чтение - это 100, запись - это 0,10, исполнение - это 01. И когда мы пишем условно чмот 755, мы просто складываем биты. 7 - это 4 + 2 + 1. Владелец [музыка] может всё. 5 - это 4 + 0 + 1. То есть группа может читать и исполнять, но [музыка] не писать. Ну и ещё раз пятёрка для всех остальных. И здесь есть важный нюанс. Право [музыка] X, то есть execute для каталога означает не запуск, а возможность в него попасть. Если у нас есть права на чтение папки, но нет права на вход, то мы можем увидеть список файлов, но не можем прочитать их метаданные. Но у всех правил есть исключение.

[музыка] В Линуксе есть один пользователь, для которого ядро отключает проверку прав. Это [музыка] root. У него всегда UID0. Когда процесс UID0 делает CS call open, ядро не смотрит в айноду, оно просто открывает файл. Root может читать etcad, где лежат хэши паролей, может убить процессы и ниты, положить сервер, может отформатировать диск на живой системе, поэтому сидеть под рутом - это дурной тон и риск. Для администрирования используется [музыка] механизм суда. Это утилита с особым битом SUID, которая временно повышает наш UID до нуля, выполняет одну команду и, что критически важно, записывает это в лок аудита. Так мы получаем безопасность без потери контроля. И вот мы поднялись на самый верхний уровень userspace. У нас есть [музыка] ядро, есть файловая система, есть права, но система всё ещё голая. Нужен софт, веб-серверы, база данных, утилиты. Как программы попадают в Linux? В Виндоусе все привыкли делать, как идём на сайт, качаем экзэшник, кликаем Next, и каждая программа тащит с собой свои собственные библиотеки. В Линуксе принят инженерный подход. Централизованные репозитории. Это проверенные склады бинарных пакетов, которые поддерживаются разработчиками вашего дистрибутива. Здесь работает пакетный менеджер АТ, Яма, ПК. Когда мы пишем APT installings, происходит не просто скачивание. Пакетный менеджер - это умный архиватор с базой данных. Он скачивает топ или то rpm пакет, распаковывает файлы строго по стандарту FHS, то есть бинарник [музыка] кладёт в userbin, configги в etc, сервисный файл в lipstem [музыка] D system. Ну а самое важное, он проверяет, есть ли у нас нужны библиотеки. Почему это важно? Потому что Linux экономит ресурсы. Программы в Линуксе почти всегда динамически слинкованы. Это значит, что бинарник Джинкса весит копейки. В нём нет кода шифрования, в нём нет кода сжатия. Вместо этого он просто [музыка] при запуске говорит ядру: "Мне нужна такая-то библиотека". И ещё вот такая. А сами эти библиотеки шареные. Они лежат в системе в одном экземпляре, обычно в Userер и когда мы запускаем условный Engin SSH клиент и Python Script, все они используют один и тот же файл библиотеки. Ядро загружает её в оперативную память один раз, и все процессы просто получают ссылку на этот участок памяти. И это колоссально экономит оперативку, но при этом создаёт сложность. Версии библиотек должны совпадать. Именно поэтому нам нужен пакетный менеджер, а не ручное скачивание файлов. Он следит, чтобы версия библиотеки в системе подходила всем установленным программам. А если этот карточный домик рушится, это называется Dependency Hell, то есть ад зависимостей.

[музыка] Но в современных дистрибутивах это случается крайне редко. Ну и теперь давайте соберём этот пазл воедино. Мы прошли путь от холодного кремния до нашей клавиатуры. Теперь у вас в голове должна быть не каша из команд, а чёткая вертикальная структура. Смотрите на Linux как инженер. Внизу лежит тупое железо, которое разбудил BIOS. Над ним стоит диктатор. Ядро. Оно врёт программам про память, нарезает время процессора и управляет драйверами. Между ядром и миром бетонная стена с одним окошком. Никто не проходит мимо. Ядро запускает первого рабочего, который строит всё окружение юзерспейса. И всё это пространство организовано в единое дерево, где каждый файл - это просто номер с правами доступа. И на самой вершине сидим мы. Если держать в голове эту схему, магия исчезает. Остаётся чистая, сухая логика. Больше не придётся гуглить ошибки вслепую. Увидим проблему Permission Dight и поймём, что это не просто Linux абстракт на ругается, а это ядро при выполнении Cisc Open, сверило наш UID с битами в айноде и вернула код ошибки. А когда сервер тормозит, то есть высокий loadт average, мы понимаем, что это не процессор устал, а это очередь процессоров в планировщике стала слишком длинной, и система тратит ресурсы на переключение контекста. А когда нас спрашивают про докер, мы улыбаемся, потому что знаем, что нет никакого докера. Есть просто грамотное использование [музыка] неймспейсов и сигрупсов, которые ядро предоставляет любому процессу. Это и есть инженерное мышление. Иникейщик учит команды наизусть, а инженер понимает, как текут байты. Команду можно нагуглить за 5 секунд, а понимание архитектуры нагуглить нельзя, его можно только наработать. И у нас в Телеге мы подготовили для вас полную карту архитектуры Linux одним пдфом. Там расписаны основные сисколы, структура файловой системы и этапы загрузки. Это ваша шпаргалка, чтобы картинка всегда была перед глазами. Забираете её в нашем Телеграме, ссылка в описании. Перестаньте быть просто пользователями, становитесь инженерами, смотрите в корень. И пока-пока. По