├── Docs └── cl-openshift-and-kubernetes-ebook-f25170wg-202010-en.pdf ├── README.md └── questions ├── ansible.md ├── cicd.md ├── databases.md ├── docker.md ├── git.md ├── imgs ├── cicdcd.jpg ├── docker-bridge.png ├── example-request.jpg ├── git-merge.png ├── git-rebase.png ├── https.png ├── inf_struct_catalogs.gif └── tcp-connection.png ├── kubernetes.md ├── linux.md ├── networks.md ├── practice.md ├── terraform.md └── theoryDevOps.md /Docs/cl-openshift-and-kubernetes-ebook-f25170wg-202010-en.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rmntrvn/adm_linux_ops_questions/808b803b382217b5d47be2e3880f09f8dbf2461a/Docs/cl-openshift-and-kubernetes-ebook-f25170wg-202010-en.pdf -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Вопросы для собеседования на позицию администратора Linux и DevOps инженера. 2 | 3 | В данном репозитории представлены вопросы для собеседований по основным темам Linux инженера и/или DevOps инженера. 4 | 5 | ## Основные темы: 6 | 1. [Linux](questions/linux.md) 7 | 2. [Сети](questions/networks.md) 8 | 3. [Базы данных](questions/databases.md) 9 | 4. [Теория DevOps](questions/theoryDevOps.md) 10 | 5. [Git](questions/git.md) 11 | 6. [CI/CD](questions/cicd.md) 12 | 7. [Terraform](questions/terraform.md) 13 | 8. [Docker](questions/docker.md) 14 | 9. [Ansible](questions/ansible.md) 15 | 10. [Kubernetes / Openshift](questions/kubernetes.md) 16 | 11. [Тестовые практические задания](questions/practice.md) 17 | -------------------------------------------------------------------------------- /questions/ansible.md: -------------------------------------------------------------------------------- 1 | ## Ansible 2 | 3 | 1. Чем отличаются Ansible модули *raw*, *command* и *shell*? 4 | 5 |
6 | Ответ 7 | 8 | Модуль *raw* отличается от *command* и *shell* тем, что не выполняет дополнительную обработку выполнения команды. Эти дополнительные обработки присутствуют в почти любом модуле Ansible. Модуль *raw* передает команду, как есть, в "сыром" (raw) виде без проверок. 9 | Модули *command* и *shell* отличаются тем, что в модуле *command* команда выполняется без прохождения через командную оболочку `/bin/sh`. Поэтому переменные определенные в оболочке и перенаправления - конвееры работать не будут. Модуль *shell* выполняет команды через оболочку по умолчанию `/bin/sh`. Поэтому там будут доступны переменные оболочки и перенаправления. 10 | 11 |
12 | 13 | 2. На всех серверах должен быть набор пользователей, с доступом по ssh-ключу, стандартный модуль user не позволяет вносить ssh ключ в authorized_keys. Предложите решение. 14 | 15 |
16 | Ответ 17 | 18 | 1. Использовать модуль `authorized_key` для добавления ключей. 19 | 2. Использовать модуль `shell`, чтобы вручную с использованием команды `cat {{ PUBLIC_SSH_KEY }} >> /home/{{ USER }}/.ssh/authorized_keys` добавить ключ. В данном случае шаблоны Jinja2 PUBLIC_SSH_KEY и USER должны быть заданы. 20 | 21 |
22 | 23 | 3. Есть группы пользователей, которые должны заводиться не на всех серверах. Как ограничить заведение пользователей? 24 | 25 |
26 | Ответ 27 | 28 | Сгруппировать сервера, на которых должны заводиться группы пользователей, в инвентори или написать в плейбуке условие, которому передаётся список серверов, на которых необходимо выполнить задачу. 29 | 30 |
31 | 32 | 4. На новом сервере не установлен Python, который требуется для работы Ansible. Как выполнить установку Python на сервере используя Ansible? 33 | 34 |
35 | Ответ 36 | 37 | Использовать модуль `raw`, которому необходимо передать команду для установки python на сервере. Модуль `raw` принимает команду без дополнительной обработки Python и выполняет её на сервере. 38 | 39 |
40 | 41 | 5. Что такое роль в Ansible? Что содержит в себе Ansible роль? 42 | 43 |
44 | Ответ 45 | 46 | Ansible роль представляет собой структурированный плейбук, содержащий, как минимум, набор задач (tasks) и дополнительно - обработчики событий (handlers), переменных (default и vars), файлов (files), шаблонов (templates), описание и зависимости (metadata) и тесты (tests). 47 | 48 |
49 | 50 | 6. В Ansible роли есть директории *vars* и *default*. Что они содержат и чем отличаются? 51 | 52 |
53 | Ответ 54 | 55 | Ansible применяет порядок приоритета переменных. Ниже представлен список в порядке повышения приоритета. 56 | 57 | 1. command line values (for example, -u my_user, these are not variables) 58 | 2. role defaults (defined in role/defaults/main.yml) 59 | 3. inventory file or script group vars 60 | 4. inventory group_vars/all 61 | 5. playbook group_vars/all 62 | 6. inventory group_vars/* 63 | 7. playbook group_vars/* 64 | 8. inventory file or script host vars 65 | 9. inventory host_vars/* 66 | 10. playbook host_vars/* 67 | 11. host facts / cached set_facts 68 | 12. play vars 69 | 13. play vars_prompt 70 | 14. play vars_files 71 | 15. role vars (определяемые в role/vars/main.yml) 72 | 16. block vars (только для задач в `block`) 73 | 17. task vars (только для задач) 74 | 18. include_vars 75 | 19. set_facts / registered vars 76 | 20. role (и include_role) params 77 | 21. include params 78 | 22. extra vars (например, -e "user=my_user")(всегда приоритетнее) 79 | 80 | Соответственно переменные в *vars* будут приорететнее, чем в *defaults*. 81 | 82 |
83 | 84 | 7. В Ansible роли есть директории *file* и *templates*. Что они содержат и чем отличаются? 85 | 86 |
87 | Ответ 88 | 89 | *files* - содержит файлы, которые будут скопированы на настраиваемые хосты; так же — может содержать скрипты, которые позже будут запускаться на хостах. 90 | 91 | *templates* - содержит шаблоны файлов с переменными. 92 | 93 |
94 | 95 | 8. По-умолчанию, в Ansible все задачи из списка выполняются параллельно на всех хостах, которые указаны в `hosts`. Как сделать так, чтобы задачи выполнялись последовательно по хостам? 96 | 97 |
98 | Ответ 99 | 100 | Необходимо установить параметр `serial: 1`, чтобы определить количество хостов, на которых будут выполняться паралелльно задачи. Значение 1 будет значить, что все задачи будут проходить параллельно по 1 хосту за раз. 101 | 102 | Ссылка на документацию: https://docs.ansible.com/ansible/latest/user_guide/playbooks_strategies.html#setting-the-batch-size-with-serial 103 | 104 |
-------------------------------------------------------------------------------- /questions/cicd.md: -------------------------------------------------------------------------------- 1 | ## CI / CD 2 | 3 | 1. Чем отличается Continuous Integration от Continuous Delivery от Continuous Deployment? 4 | 5 |
6 | Ответ 7 | 8 | Continuous Integration (непрерывная интеграция) - практика интеграции изменений кода из ветки разработки в основную ветку путём инструментов для интеграции. 9 | 10 | Continuous Delivery (непрерывная доставка) - практика содержания кода в репозитории в состоянии пригодным для разворачивания на рабочее окружение. 11 | 12 | Continuous Deployment (непрерывное разворачивание) - практика доставки каждого изменения в коде продукта на рабочее окружение. 13 | 14 | ![](imgs/cicdcd.jpg) 15 | 16 | Разница между Continuous Delivery и Continuous Deployment очень маленькая. Представим два пайплайна для одного и того же приложения. В каждом есть шаги: 17 | 18 | 1. Source Control - внесение изменений в систему контроля версий ПО. 19 | 2. Build - сборка приложения и прогон unit тестов 20 | 3. Staging - деплой на тестовое окружение, прогон интеграционных, нагрузочных и других тестов 21 | 4. Production - деплой на окружение с пользователями 22 | 23 | Каждый пайплайн запускается автоматически по триггеру из системы контроля версий. В случае Continuous Deployment каждый следующий шаг, будет выполнен автоматически если предыдущий был успешный, включая деплой на Production. 24 | 25 | Если же у вас Continuous Delivery, то шаги будут выполняться автоматически только в безопасной среде, а перед деплоем на Production пайплайн остановится и будет ждать ручного подтверждения. Механизм, как это будет реализовано может быть разным. От самого простого, когда ответственный человек должен зайти в пайплайн и нажать кнопку Next, до интерактивного бота с кнопками в корпоративном мессенджере. 26 | 27 |
28 | 29 | 2. Что означает конструкция `when: always` в stage блоке в gitlab CI? 30 | 31 |
32 | Ответ 33 | 34 | Данная конструкция означает, что stage будет запущен вне зависимости от успешности предыдущего шага. 35 | 36 |
37 | 38 | 3. Что выполняет конструкция `extends: .plan` в gitlab CI? 39 | 40 |
41 | Ответ 42 | 43 | `extends` используется для повторного использования секции пайплайна (аналог фунции). `.plan` указывает на имя повторяемой секции в пайплайне. Первым в шаге выполняется скрипт из `extends`. 44 | 45 |
46 | 47 | 4. В gitlab CI необходимо, чтобы джоба выполнялась всегда только при ручной активации. Что для этого необходимо сделать? 48 | 49 |
50 | Ответ 51 | 52 | Необходимо добавить `when: manual` в описание заданной джобы. По-умолчанию при использовании `when: manual` параметр `allow_failure` установлен в `true`, поэтому данная джоба будет запускаться автоматически. Чтобы такого не было необходимо также установить параметр `allow_failure: false`. 53 | 54 |
55 | -------------------------------------------------------------------------------- /questions/databases.md: -------------------------------------------------------------------------------- 1 | 1. Как настроить master-slave репликацию в mysql (кратко)? 2 | 3 |
4 | Ответ 5 | 6 | Необходимы 2 сервера: master и slave. 7 | 8 | 1. На обеих сервера устанавливаем сервер MySQL одинаковой версии. 9 | 2. Включаем сервер базы данных на обеих серверах. 10 | 3. Настраиваем master - в `/etc/my.cnf` устанавливаем слеюущие значения: 11 | ``` 12 | # выбираем ID сервера, произвольное число, лучше начинать с 1 13 | server-id = 1 14 | # путь к бинарному логу 15 | log_bin = /var/log/mysql/mysql-bin.log 16 | # название Вашей базы данных, которая будет реплицироваться 17 | binlog_do_db = newdatabase 18 | ``` 19 | Перезапускаем сервер базы данных. 20 | 4. Подключаемся к master серверу, создаем пользователя и назначаем ему права для выполнения репликации. 21 | ``` 22 | mysql -u root -p <пароль root сервера БД> 23 | GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%' IDENTIFIED BY 'password'; 24 | FLUSH PRIVILEGES; 25 | ``` 26 | 5. На master сервере делаем дамп базы данных c блокировкой таблиц. 27 | ``` 28 | mysqldump -u root -p --lock-all-tables newdatabase > newdatabase.sql 29 | ``` 30 | 6. Переносим дамп базы на slave сервер, создаем базу данных с таким же именем и импортируем базу. 31 | ``` 32 | CREATE DATABASE newdatabase; 33 | mysql -u root -p newdatabase < newdatabase.sql 34 | ``` 35 | 7. Настраиваем slave в `/etc/my.cnf`: 36 | ``` 37 | # ID Слейва, удобно выбирать следующим числом после Мастера 38 | server-id = 2 39 | # Путь к relay логу 40 | relay-log = /var/log/mysql/mysql-relay-bin.log 41 | # Путь к bin логу на Мастере 42 | log_bin = /var/log/mysql/mysql-bin.log 43 | # База данных для репликации 44 | binlog_do_db = newdatabase 45 | ``` 46 | Перезапускаем сервер базы данных. 47 | 8. Запускаем репликацию на slave сервере. 48 | ``` 49 | CHANGE MASTER TO MASTER_HOST='10.10.0.1', MASTER_USER='slave_user', MASTER_PASSWORD='password', 50 | MASTER_LOG_FILE = 'mysql-bin.000001', MASTER_LOG_POS = 107; 51 | ##Указанные значения мы берем из настроек Мастера 52 | После этого запускаем репликацию на Слейве: 53 | START SLAVE; 54 | ``` 55 | 9. Проверяем статус репликации: 56 | ``` 57 | SHOW SLAVE STATUSG 58 | ``` 59 | 60 |
61 | 62 | 2. Какой тип базы данных использует Prometheus? 63 | 64 |
65 | Ответ 66 | 67 | Prometheus использует TSDB (time series database). 68 | 69 |
70 | 71 | 3. Что такое VACUUM в PostgreSQL? 72 | 73 |
74 | Ответ 75 | 76 | VACUUM высвобождает пространство, занимаемое «мёртвыми» кортежами. При обычных операциях PostgreSQL кортежи, удалённые или устаревшие в результате обновления, физически не удаляются из таблицы; они сохраняются в ней, пока не будет выполнена команда VACUUM. Таким образом, периодически необходимо выполнять VACUUM, особенно для часто изменяемых таблиц. 77 | 78 | Без параметра команда VACUUM обрабатывает все таблицы в текущей базе данных, которые может очистить текущий пользователь. Если в параметре передаётся имя таблицы, VACUUM обрабатывает только эту таблицу. 79 | 80 | Простая команда VACUUM (без FULL) только высвобождает пространство и делает его доступным для повторного использования. Эта форма команды может работать параллельно с обычными операциями чтения и записи таблицы, так она не требует исключительной блокировки. Однако освобождённое место не возвращается операционной системе (в большинстве случаев); оно просто остаётся доступным для размещения данных этой же таблицы. VACUUM FULL переписывает всё содержимое таблицы в новый файл на диске, не содержащий ничего лишнего, что позволяет возвратить неиспользованное пространство операционной системе. Эта форма работает намного медленнее и запрашивает исключительную блокировку для каждой обрабатываемой таблицы. 81 | 82 |
-------------------------------------------------------------------------------- /questions/docker.md: -------------------------------------------------------------------------------- 1 | ## Docker 2 | 3 | 1. Что такое Docker? В чем отличие контейнера от образа? 4 | 5 |
6 | Ответ 7 | 8 | Docker - программное обеспечение для автоматизации развёртывания и управления приложениями в средах с поддержкой контейнеризации. 9 | 10 | Образ - шаблон приложения, который содержит слои файловой системы в режиме "только-чтение". 11 | 12 | Контейнер - запущенный образ приложения, который кроме нижних слоев в режиме "только чтение" содержит верхний слой в режиме "чтение-запись". 13 | 14 |
15 | 16 | 2. Какие инструкции есть у Dockerfile? 17 |
18 | Ответ 19 | 20 | | Инструкция | Описание | 21 | |------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| 22 | | FROM | Задаёт базовый (родительский) образ. | 23 | | LABEL | Описывает метаданные. Например — сведения о том, кто создал и поддерживает образ. | 24 | | ENV | Устанавливает постоянные переменные среды. | 25 | | RUN | Выполняет команду и создаёт слой образа. Используется для установки в контейнер пакетов. | 26 | | COPY | Копирует в контейнер файлы и директории. | 27 | | ADD | Копирует файлы и директории в контейнер, может распаковывать локальные .tar-файлы. | 28 | | CMD | Описывает команду с аргументами, которую нужно выполнить когда контейнер будет запущен. Аргументы могут быть переопределены при запуске контейнера. В файле может присутствовать лишь одна инструкция CMD. | 29 | | WORKDIR | Задаёт рабочую директорию для следующей инструкции. | 30 | | ARG | Задаёт переменные для передачи Docker во время сборки образа. | 31 | | ENTRYPOINT | Предоставляет команду с аргументами для вызова во время выполнения контейнера. Аргументы не переопределяются. | 32 | | EXPOSE | Указывает на необходимость открыть порт. | 33 | | VOLUME | Создаёт точку монтирования для работы с постоянным хранилищем. | 34 | 35 |
36 | 37 | 3. Чем отличается *CMD* от *ENTRYPOINT* в Dockerfile? 38 | 39 |
40 | Ответ 41 | 42 | Инструкции CMD и ENTRYPOINT выполняются в момент запуска контейнера, тольо инструкция CMD позволяет переопределить передаваемые команде аргументы. 43 | 44 | **Пример 1. CMD:** 45 | Опишем сборку образа в Dockerfile. 46 | ``` 47 | FROM alpine 48 | CMD ["ping", "8.8.8.8"] 49 | ``` 50 | В инструкцию CMD передаются 2 аргумента. Выполним сборку образа `docker build -t test .` и запустим контейнер. 51 | ``` 52 | $ docker run test 53 | PING 8.8.8.8 (8.8.8.8): 56 data bytes 54 | 64 bytes from 8.8.8.8: seq=0 ttl=43 time=32.976 ms 55 | 64 bytes from 8.8.8.8: seq=1 ttl=43 time=31.998 ms 56 | 64 bytes from 8.8.8.8: seq=2 ttl=43 time=31.843 ms 57 | --- 8.8.8.8 ping statistics --- 58 | 3 packets transmitted, 3 packets received, 0% packet loss 59 | round-trip min/avg/max = 31.708/33.316/36.823 ms 60 | ``` 61 | Теперь передадим 2 новых аргумента для запуска контейнера. 62 | ``` 63 | $ docker run test traceroute 1.1.1.1 64 | traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 46 byte packets 65 | 1 172.17.0.1 (172.17.0.1) 0.017 ms 0.016 ms 0.009 ms 66 | 2 192.168.168.1 (192.168.168.1) 0.996 ms 1.553 ms 2.069 ms 67 | 3 * * * 68 | 4 lag-2-435.bgw01.samara.ertelecom.ru (85.113.62.125) 1.454 ms 1.427 ms 1.984 ms 69 | 5 172.68.8.3 (172.68.8.3) 19.685 ms 15.722 ms 15.565 ms 70 | 6 172.68.8.2 (172.68.8.2) 15.846 ms 22.696 ms 35.093 ms 71 | 7 one.one.one.one (1.1.1.1) 17.439 ms 17.670 ms 24.202 ms 72 | ``` 73 | `ping` заменен на traceroute, IP адрес заменен на 1.1.1.1. 74 | 75 | **Пример 2. ENTRYPOINT:** 76 | Опишем сборку образа в Dockerfile. 77 | ``` 78 | FROM alpine 79 | ENTRYPOINT ["ping", "8.8.8.8"] 80 | ``` 81 | В инструкцию ENTRYPOINT передаются 2 аргумента. Выполним сборку образа `docker build -t test .` и запустим контейнер. 82 | ``` 83 | $ docker run test2 84 | PING 8.8.8.8 (8.8.8.8): 56 data bytes 85 | 64 bytes from 8.8.8.8: seq=0 ttl=43 time=36.189 ms 86 | 64 bytes from 8.8.8.8: seq=1 ttl=43 time=44.120 ms 87 | 64 bytes from 8.8.8.8: seq=2 ttl=43 time=44.584 ms 88 | ^C 89 | --- 8.8.8.8 ping statistics --- 90 | 3 packets transmitted, 3 packets received, 0% packet loss 91 | round-trip min/avg/max = 36.189/41.631/44.584 ms 92 | ``` 93 | Теперь передадим изменим один из аргументов для запуска контейнера. 94 | ``` 95 | $ docker run test2 ping 1.1.1.1 96 | BusyBox v1.31.1 () multi-call binary. 97 | 98 | Usage: ping [OPTIONS] HOST 99 | 100 | Send ICMP ECHO_REQUEST packets to network hosts 101 | 102 | -4,-6 Force IP or IPv6 name resolution 103 | -c CNT Send only CNT pings 104 | -s SIZE Send SIZE data bytes in packets (default 56) 105 | -i SECS Interval 106 | -A Ping as soon as reply is recevied 107 | -t TTL Set TTL 108 | -I IFACE/IP Source interface or IP address 109 | -W SEC Seconds to wait for the first response (default 10) 110 | (after all -c CNT packets are sent) 111 | -w SEC Seconds until ping exits (default:infinite) 112 | (can exit earlier with -c CNT) 113 | -q Quiet, only display output at start 114 | and when finished 115 | -p HEXBYTE Pattern to use for payload 116 | ``` 117 | Как видим, аргумент передать контейнеру нельзя. 118 | 119 | **Пример 3. ENTRYPOINT и CMD:** 120 | Опишем сборку образа в Dockerfile. 121 | ``` 122 | FROM alpine 123 | ENTRYPOINT ["ping"] 124 | CMD ["8.8.8.8"] 125 | ``` 126 | В инструкцию ENTRYPOINT передаётся аргумент `ping`, в CMD передаётся аргумент 8.8.8.8. Выполним сборку образа `docker build -t test .` и запустим контейнер. 127 | ``` 128 | $ docker run test3 129 | PING 8.8.8.8 (8.8.8.8): 56 data bytes 130 | 64 bytes from 8.8.8.8: seq=0 ttl=43 time=41.176 ms 131 | 64 bytes from 8.8.8.8: seq=1 ttl=43 time=32.875 ms 132 | 64 bytes from 8.8.8.8: seq=2 ttl=43 time=40.395 ms 133 | ^C 134 | --- 8.8.8.8 ping statistics --- 135 | 3 packets transmitted, 3 packets received, 0% packet loss 136 | round-trip min/avg/max = 32.875/38.148/41.176 ms 137 | ``` 138 | Пробуем изменить 2 аргумента. 139 | ``` 140 | $ docker run test3 traceroute 1.1.1.1 141 | BusyBox v1.31.1 () multi-call binary. 142 | 143 | Usage: ping [OPTIONS] HOST 144 | 145 | Send ICMP ECHO_REQUEST packets to network hosts 146 | 147 | -4,-6 Force IP or IPv6 name resolution 148 | -c CNT Send only CNT pings 149 | -s SIZE Send SIZE data bytes in packets (default 56) 150 | -i SECS Interval 151 | -A Ping as soon as reply is recevied 152 | -t TTL Set TTL 153 | -I IFACE/IP Source interface or IP address 154 | -W SEC Seconds to wait for the first response (default 10) 155 | (after all -c CNT packets are sent) 156 | -w SEC Seconds until ping exits (default:infinite) 157 | (can exit earlier with -c CNT) 158 | -q Quiet, only display output at start 159 | and when finished 160 | -p HEXBYTE Pattern to use for payload 161 | ``` 162 | Изменить 2 аргумента невозможно. Заменим аргумент инструкции CMD. 163 | ``` 164 | $ docker run test3 1.1.1.1 165 | PING 1.1.1.1 (1.1.1.1): 56 data bytes 166 | 64 bytes from 1.1.1.1: seq=0 ttl=58 time=31.412 ms 167 | 64 bytes from 1.1.1.1: seq=1 ttl=58 time=19.400 ms 168 | 64 bytes from 1.1.1.1: seq=2 ttl=58 time=15.814 ms 169 | ^C 170 | --- 1.1.1.1 ping statistics --- 171 | 3 packets transmitted, 3 packets received, 0% packet loss 172 | round-trip min/avg/max = 15.814/22.208/31.412 ms 173 | ``` 174 | При такой сборке образа команды ENTRYPOINT и CMD при запуске контейнера будут запущены последовательно, но аргумент возможно изменить только для CMD. 175 | 176 |
177 | 178 | 4. Чем отличается *COPY* от *ADD* в Dockerfile? 179 | 180 |
181 | Ответ 182 | 183 | Инструкция *COPY* копируют файлы и директории с хостовой машины внутрь контейнера, инструкция *ADD* копирует файлы и директории с хостовой машины внутрь контейнера и может распаковывать .tar архивы. 184 | 185 |
186 | 187 | 5. Какие есть best practices для написания Dockerfile? 188 | 189 |
190 | Ответ 191 | 192 | 1. Запускать только один процесс на контейнер. 193 | 2. Стараться объединять несколько команд RUN в одну для уменьшения количества слоёв образа. 194 | 3. Частоизменяемые слои образа необходимо располагать ниже по уровню, чтобы ускорить процесс сборки, т.к. при изменении верхнего слоя, все нижеследующие слои будут пересобираться. 195 | 4. Указывать явные версии образов в инструкции FROM, чтобы избежать случая, когда выйдет новая версия образа с тегом latest. 196 | 5. При установке пакетов указывать версии пакетов. 197 | 6. Очищать кеш пакетного менеджера и удалять ненужные файлы после выполненной инструкции. 198 | 7. Использовать multistage build для сборки артифакта в одном контейнере и размещении его в другом. 199 | 200 |
201 | 202 | 6. Какие типы сетевых драйверов используются в docker? 203 | 204 |
205 | Ответ 206 | 207 | Основные драйвера сетей docker: bridge, host, overlay, ipvlan, macvlan, none 208 | 209 | **bridge:** это сетевой драйвер по умолчанию. Бридж сеть используется, когда ваши приложения запускаются в автономных контейнерах, которые должны взаимодействовать между собой. 210 | ![docker-bridge](imgs/docker-bridge.png) 211 | Взаимодействие с хостом выполняется через мост docker0 и конфигурацию таблицы iptables nat. В этом режиме будет выделено сетевое пространство имен, задан IP-адрес для каждого контейнера, а контейнер Docker на хосте будет подключен к виртуальному мосту. Виртуальный мост работает как физический коммутатор, поэтому все контейнеры на хосте подключены к сети уровня 2 через коммутатор. 212 | 213 | **host:** использует сеть хоста напрямую без изоляции контейнера и хоста. 214 | 215 | **none:** этот режим помещает контейнер в свой собственный сетевой стек, но не выполняет никакой настройки. Фактически, этот режим отключает сетевую функцию контейнера, что полезно в следующих двух ситуациях: контейнер не требует сети (например, только для пакетной задачи записи дисковых томов). 216 | 217 | **macvlan:** в режиме Macvlan Bridge каждый контейнер имеет уникальный MAC-адрес, который используется для отслеживания сопоставления MAC-адреса с портом хоста Docker. Сеть драйвера Macvlan подключается к родительскому интерфейсу хоста Docker. Примерами являются физические интерфейсы, такие как eth0, субинтерфейс eth0.10 для тегирования VLAN 802.1q (.10 означает VLAN 10) или даже связанный хост-адаптер, который объединяет два интерфейса Ethernet в единый логический интерфейс. Назначенный шлюз является внешним по отношению к хосту, предоставляемому сетевой инфраструктурой. Каждая сеть Docker в режиме Macvlan Bridge изолирована друг от друга, и только одна сеть может быть подключена к родительскому узлу одновременно. Каждый хост-адаптер имеет теоретический предел, и каждый хост-адаптер может подключаться к сети Docker. Любой контейнер в той же подсети может взаимодействовать с любым другим контейнером в той же сети без шлюзового моста macvlan. Та же сетевая команда docker применяется к драйверу vlan. В режиме Macvlan без внешней маршрутизации процессов между двумя сетями / подсетями контейнеры в разных сетях не могут получить доступ друг к другу. Это также относится к нескольким подсетям в одной и той же терминальной сети. 218 | 219 | **overlay:** Оверлейные сети соединяют несколько демонов Docker вместе и позволяют сервисам swarm взаимодействовать друг с другом. Вы также можете использовать оверлейные сети для облегчения связи между сервисом swarm и автономным контейнером или между двумя автономными контейнерами в разных демонах Docker. Эта стратегия устраняет необходимость выполнять маршрутизацию между этими контейнерами на уровне ОС. 220 | 221 | **ipvlan:** Сети ipvlan предоставляют пользователям полный контроль над адресацией IPv4 и IPv6. Драйвер VLAN построен на основе этой возможности, предоставляя операторам полный контроль над тегированием VLAN уровня 2 и даже маршрутизацией IPvlan L3 для пользователей. 222 | 223 |
224 | 225 | 7. Что такое эфемерные контейнеры? 226 | 227 |
228 | Ответ 229 | 230 | [Эфемерные контейнеры](https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/) стали бета-функцией в Kubernetes v1.23 и теперь включены по умолчанию. 231 | Эфемерные контейнеры предназначены для транзитных задач, когда вам нужно временно [подключить дополнительный контейнер к существующему поду](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container). Это идеально подходит для отладочных операций, когда вы хотите проверить поды, не затрагивая живые экземпляры контейнеров. 232 | 233 |
-------------------------------------------------------------------------------- /questions/git.md: -------------------------------------------------------------------------------- 1 | ## Git 2 | 3 | 1. Что такое GitFlow? 4 | 5 |
6 | Ответ 7 | 8 | GitFlow - модель ветвления Git. 9 | 10 | *Ключевые идеи*: 11 | 1. Данная модель отлично подходит для организации рабочего процесса на основе релизов, 12 | 2. Gitflow предлагает создание отдельной ветки для исправлений ошибок в продуктовой среде. 13 | 14 | *Последовательность работы при использовании модели Gitflow*: 15 | 16 | 1. Из *master* создается ветка *develop*. 17 | 2. Из *develop* создаются ветки *feature*. 18 | 3. Когда разработка новой функциональности завершена, она объединяется с веткой *develop*. 19 | 4. Из *develop* создается ветка *release*. 20 | 5. Когда ветка релиза готова, она объединяется с *develop* и *master*. 21 | 6. Если в *master* обнаружена проблема, из нее создается ветка *hotfix*. 22 | 7. Как только исправление на ветке *hotfix* завершено, она объединяется с *develop* и *master*. 23 | 24 |
25 | 26 | 2. Чем `merge` отличается от `rebase`? 27 | 28 |
29 | Ответ 30 | 31 | - `git merge` - выполняет слияние коммитов из одной ветки в другую. В этом процессе изменяется только целевая ветка. История исходных веток остается неизменной. 32 | 33 | ![git-merge](imgs/git-merge.png) 34 | 35 | *Преимущества*: 36 | 1. Простота, 37 | 2. Сохраняет полную историю и хронологический порядок, 38 | 3. Поддерживает контекст ветки. 39 | 40 | *Недостатки*: 41 | 1. История коммитов может быть заполнена (загрязнена) множеством коммитов, 42 | 2. Отладка с использованием git bisect может стать сложнее. 43 | 44 | 45 | - `git rebase` - сжимает все изменения в один патч. Затем интегрирует патч в целевую ветку. В отличии от *merge*, *rebase* перезаписывает историю, потому что она передаётся завершенную работу из одной ветки в другую. В процессе устраняется нежелательная история. 46 | 47 | ![git-rebase](imgs/git-rebase.png) 48 | 49 | *Преимущества*: 50 | 1. Упрощает потенциально сложную историю, 51 | 2. Упрощение манипуляций с единственным коммитом, 52 | 3. Избежание слияния коммитов в занятых репозиториях и ветках, 53 | 4. Очищает промежуточные коммиты, делая их одним коммитом, что полезно для DevOps команд. 54 | 55 | *Недостатки*: 56 | 1. Сжатие фич до нескольких коммитов может скрыть контекст 57 | 2. Перемещение публичных репозиториев может быть опасным при работе в команде, 58 | 3. Появляется больше работы, 59 | 4. Для восстановления с удаленными ветками требуется принудительный пуш. Это приводит к обновлению всех веток, имеющих одно и то же имя, как локально, так и удаленно. 60 | 61 |
62 | 63 | 3. Чем `tag` отличается от `branch`? 64 | 65 |
66 | Ответ 67 | 68 | И *tag* и *branch* представляют собой указатели на коммиты. 69 | - Ветка представляет собой отдельный поток разработки, который может выполняться одновременно с другими разработками в той же кодовой базе. Коммит в ветке указывает на изменения, которые добавляются в новых коммитах 70 | - Тег представляет собой версию определенной ветки в определенный момент времени. 71 | 72 | *Tag* представляет собой версию той или иной ветки в определенный момент времени. *Branch* представляет собой отдельный поток разработки, который может выполнятся одновременно с другими разработками в той же кодовой базе. 73 | 74 |
75 | 76 | 4. В ветке *develop* есть коммит с изменениями, которые нужно перенести в ветку *master*. Как это сделать? 77 | 78 |
79 | Ответ 80 | 81 | Необходимо найти хеш этого коммита и выполнить следующую комманду в ветке, в которую нужно перенести коммит. 82 | ```sh 83 | git cherry-pick 84 | ``` 85 | 86 |
87 | 88 | 5. Для чего нужна команда `git commit --amend`? 89 | 90 |
91 | Ответ 92 | 93 | `commit --ammend` используется для исправления сообщения последнего коммита. Также возможно использовать, чтобы добавить файлы в индекс (`git add`), после добавить файлы в коммит `git commit --ammend`. 94 | 95 |
96 | 97 | 6. Что такое Trunk-based development? 98 | 99 |
100 | Ответ 101 | 102 | Trunk-based Development (TBD) - модель ветвления, в которой разработчики совместно работают над кодом в одной ветви, называемой "стволом" (trunk). При этом другие ветви имеют короткий срок жизни благодаря использованию документированных методов. 103 | 104 |
105 | 106 | 7. Состояние репозитория ушло на много коммитов вперед. Как откатить весь репозиторий к определенному коммиту? 107 | 108 |
109 | Ответ 110 | 111 | git reset --hard 112 | 113 |
114 | 115 | 8. В репозиторий запушен коммит с изменениями в двух файлах. Как откатить изменения этого коммита? 116 | 117 |
118 | Ответ 119 | 120 | git revert 121 | 122 |
-------------------------------------------------------------------------------- /questions/imgs/cicdcd.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rmntrvn/adm_linux_ops_questions/808b803b382217b5d47be2e3880f09f8dbf2461a/questions/imgs/cicdcd.jpg -------------------------------------------------------------------------------- /questions/imgs/docker-bridge.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rmntrvn/adm_linux_ops_questions/808b803b382217b5d47be2e3880f09f8dbf2461a/questions/imgs/docker-bridge.png -------------------------------------------------------------------------------- /questions/imgs/example-request.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rmntrvn/adm_linux_ops_questions/808b803b382217b5d47be2e3880f09f8dbf2461a/questions/imgs/example-request.jpg -------------------------------------------------------------------------------- /questions/imgs/git-merge.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rmntrvn/adm_linux_ops_questions/808b803b382217b5d47be2e3880f09f8dbf2461a/questions/imgs/git-merge.png -------------------------------------------------------------------------------- /questions/imgs/git-rebase.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rmntrvn/adm_linux_ops_questions/808b803b382217b5d47be2e3880f09f8dbf2461a/questions/imgs/git-rebase.png -------------------------------------------------------------------------------- /questions/imgs/https.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rmntrvn/adm_linux_ops_questions/808b803b382217b5d47be2e3880f09f8dbf2461a/questions/imgs/https.png -------------------------------------------------------------------------------- /questions/imgs/inf_struct_catalogs.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rmntrvn/adm_linux_ops_questions/808b803b382217b5d47be2e3880f09f8dbf2461a/questions/imgs/inf_struct_catalogs.gif -------------------------------------------------------------------------------- /questions/imgs/tcp-connection.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/rmntrvn/adm_linux_ops_questions/808b803b382217b5d47be2e3880f09f8dbf2461a/questions/imgs/tcp-connection.png -------------------------------------------------------------------------------- /questions/kubernetes.md: -------------------------------------------------------------------------------- 1 | ## Kubernetes 2 | 3 | 1. Чем отличается Kubernetes от Openshift? 4 | 5 |
6 | Ответ 7 | 8 | https://www.redhat.com/cms/managed-files/cl-openshift-and-kubernetes-ebook-f25170wg-202010-en.pdf 9 | 10 | 1. Openshift имеет более строгие политики безопасности и модели аутентификации. 11 | 2. Openshift поддерживает полную интеграцию CI/CD Jenkins. 12 | 3. Openshift имеет веб-консоль по-умолчанию. В Kubernetes консоль необходимо дополнительно устанавливать консоль. 13 | 4. В Kubernetes возможно устанавливать сторонние сетевые плагины. В Openshift используется собственное сетевое решение Open vSwitch, которое предоставляет 3 различный плагина. 14 | 5. Kubernetes может быть установлен практически на любой дистрибутив Linux. Openshift имеет ограничения на устанавливаемые дистрибутивы, преимущественно используются RH-дистрибутивы. 15 | 6. Kubernets доступен в большинстве облачных платформ - GCP, AWS, Azure, Yandex.Cloud. Openshift доступен на облачной платформе Azure и облаке от IBM. 16 | 7. По-умолчанию, в Openshift поды в кластере могут быть запущены только под обычным пользователем, чтобы запустить под под пользователем root необходимо выдать права для сервисного аккаунта. В Kubernetes по-умолчанию поды могут быть запущены по пользователем root. 17 | 18 |
19 | 20 | 2. Чем отличаются *ReplicationController* от *ReplicaSet*? 21 | 22 |
23 | Ответ 24 | 25 | ReplicationController гарантирует, что указанное количество реплик подов будут работать одновременно. Другими словами, ReplicationController гарантирует, что под или набор подов всегда активен и доступен. 26 | 27 | ReplicaSet - это следующее поколение Replication Controller. Единственная разница между ReplicaSet и Replication Controller - это поддержка селектора. ReplicaSet поддерживает множественный выбор в селекторе, тогда как ReplicationController поддерживает в селекторе только выбор на основе равенства. 28 | 29 |
30 | 31 | 3. Если на каждой ноде Kubernetes кластера нужно запустить контейнер, то какой ресурс Kubernetes вам подойдет? 32 | 33 |
34 | Ответ 35 | 36 | DaemonSet является контроллером, основным назначением которого является запуск подов на всех нодах кластера. Если нода добавляется/удаляется — DaemonSet автоматически добавит/удалит под на этой ноде. 37 | 38 | DaemonSet подходят для запуска приложений, которые должны работать на всех нодах, например — екпортёры мониторинга, сбор логов и так далее. 39 | 40 |
41 | 42 | 4. Как поды разнести на разные ноды? 43 | 44 |
45 | Ответ 46 | 47 | Необходимо настроить podAntiAffinity. Данное указание определяет, что для определенных подов следует использовать их размещание на разных нодах. 48 | 49 |
50 | 51 | 5. В облаке есть 3 зоны доступности. Как сделать так, чтобы поды приложения распределились по этим зонам доступности равномерно? 52 | 53 |
54 | Ответ 55 | 56 | Необходимо настроить [podAntiAffinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#an-example-of-a-pod-that-uses-pod-affinity). Либо, более новый вариант для данной задачи, настроить [topologySpreadConstraints](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/) с указание ключа лейбла зон. 57 | 58 |
59 | 60 | 6. Как контейнеры одного пода разнести на разные ноды? 61 | 62 |
63 | Ответ 64 | 65 | Никак. Под - минимальная и неделимая сущность, Kubernetes оперирует подами, а не отдельными контейнерами. 66 | 67 |
68 | 69 | 7. Как обеспечить, чтобы поды никогда не перешли в состояние Evicted на ноде? 70 | 71 |
72 | Ответ 73 | 74 | Когда узлу (node) кластера не хватает памяти или дискового пространства, он активирует флаг, сигнализирующий о данной проблеме. Данное действие блокирует любое новое выделение ресурсов на ноде и запускает процесс "выселения" (evicted) пода с ноды. 75 | 76 | В этот момент kubelet начинает восстанавливать ресурсы, удаляя контейнеры и объявляя поды, как Failed, пока использование ресурсов снова не станет ниже порога "выселения". 77 | 78 | Сначала kubelet пытается освободить ресурсы узла, особенно диск, путем удаления мертвых модулей и их контейнеров, а затем неиспользуемых образов. Если этого недостаточно, kubelet начинает выселять поды конечных пользователей в следующем порядке: 79 | 80 | 1. Best Effort. 81 | 2. Burstable поды, использующие больше ресурсов, чем запрос истощенного ресурса. 82 | 3. Burstable поды, использующие меньше ресурсов, чем запрос истощенного ресурса. 83 | 84 | Чтобы под не был удален при "выселении", необходимо настроить политики QoS для пода как Guaranteed. 85 | 86 | Подробнее в документации Kubernetes: [Create a Pod that gets assigned a QoS class of Guaranteed](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/#create-a-pod-that-gets-assigned-a-qos-class-of-guaranteed) 87 | 88 | Кроме того, можно использовать сущность кубернетиса PodDisruptionBudget, которая позволит регулировать количество вытесняемых подов и обеспчивать гарантированную доступность для конкретного микросервиса https://kubernetes.io/docs/tasks/run-application/configure-pdb/ 89 | 90 |
91 | 92 | 8. За что отвечает kube-proxy? 93 | 94 |
95 | Ответ 96 | 97 | Kube-proxy отвечает за взаимодействие между сервисами на разных нодах кластера. 98 | 99 |
100 | 101 | 9. Что находится на master ноде? 102 | 103 |
104 | Ответ 105 | 106 | - Kube-apiserver отвечает за оркестрацию всех операций кластера. 107 | - Controller-manager (Node controller + Replication Controller) Controller отвечает за функции контроля за нодами, репликами. 108 | - ETCD cluster (распределенное хранилище ключ-значение) ETCD хранит информацию о кластере и его конфигурацию. 109 | - Kube-sheduler отвечает за планирование приложений и контейнеров на нодах. 110 | 111 | По-умолчанию на master ноде не размещаются контейнеры приложений, но данный фунционал возможно настроить. 112 | 113 |
114 | 115 | 10. Что находится на worker ноде? 116 | 117 |
118 | Ответ 119 | 120 | - Kubelet слушает инструкции от kube-apiserver и разворачивает или удаляет контейнеры на нодах. 121 | - Kube-proxy отвечает за взаимодействие между сервисами на разных нодах кластера. 122 | 123 | На worker нодах по-умолчанию размещаются контейнеры приложений. На каждой ноде кластера устанавливается Docker или другая платформа контейнеризации (например RKT или containterd). На Master ноде также устанавливается Docker, если необходимо использовать компоненты Kubernetes в контейнерах. 124 | 125 |
126 | 127 | 11. Как установить Kubernetes? 128 | 129 |
130 | Ответ 131 | 132 | 1. Следовать инструкции [установки kubeadm](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/). 133 | 134 | 2. Установка с [использованием kubespray](https://github.com/kubernetes-sigs/kubespray). 135 | 136 |
137 | 138 | 12. Чем отличается *StatefulSet* от *Deployment*? 139 | 140 |
141 | Ответ 142 | 143 | *Deployment* - ресурс Kubernetes предназнваенный для развертывания приложения без сохранения состояния. При использовании PVC все реплики будут использовать один и тот же том, и ни один из них не будет иметь собственного состояния. 144 | 145 | *StatefulSet* - поддерживают состояние приложений за пределами жизненного цикла отдельных модулей pod, например для хранилища. Используется для приложений с отслеживанием состояния, каждая реплика модуля будет иметь собственное состояние и будет использовать свой собственный том. 146 | 147 |
148 | 149 | 13. Что такое *операторы* в понятиях Kubernetes? 150 | 151 |
152 | Ответ 153 | 154 | Операторы -- это программные расширения Kubernetes,призванное автоматизировать выполнение рутинных действий над объектами кластера при определённых событиях. 155 | 156 | Оператор работает по подписке на события к API Kubernetes. 157 | 158 |
159 | 160 | 14. Почему *DaemonSet* не нужен scheduler? 161 | 162 |
163 | Ответ 164 | 165 | DaemonSet гарантирует, что определенный под будет запущен на всех нодах кластера. При наличии DaemonSet в кластере на любой из существующих и будущих нод в кластере зарезервированы ресурсы для пода на ноде. 166 | 167 | Здесь стоит сделать оговорку насчет того, что DaemonSet может работать не на всех нодах кластера, а на некоторых, выбранных, например, по nodeSelector. К примеру, у нас есть GPU ноды и нам нужно на все эти ноды задеплоить микросервис выполняющий вычисления на GPU. 168 | 169 |
170 | 171 | 15. В каких случаях не отработает перенос пода на другую ноду? 172 | 173 |
174 | Ответ 175 | 176 | Если на другой ноде нет ресурсов для размещения пода или нет сетевой доступности до ноды. 177 | 178 |
179 | 180 | 16. Что делает *ControllerManager*? 181 | 182 |
183 | Ответ 184 | 185 | Controller выполняет постоянный процесс мониторинга состояния кластера и различных компонент. 186 | 187 | Controller-manager (Node controller + Replication Controller) - Controller отвечает за функции контроля за нодами, репликами. 188 | 189 |
190 | 191 | 17. Администратор выполняет команду `kubectl apply -f deployment.yaml`. Опишите по порядку что происходит в каждом из узлов Kubernetes и в каком порядке. 192 | 193 |
194 | Ответ 195 | 196 | Клиент kubectl обращается к мастер-серверу kube-apiserver (стандартно на порт 6443), адрес мастер сервер задан в *.config* файле. В запросе передаётся информация, которую нужно применить в кластере обращения. API-сервер обращается к etcd хранилищу, проверяет наличие конфигурации запрашиваемого ресурса. Если конфигурация в хранилище etcd есть, то API-сервер сравнивает новую конфигурацию с конфигурацией в базе данных: если конфигурация одинаковая, то изменений в кластере не происходит, клиенту отдается ответ об успешности запрашиваемого действия, если конфигурации нет в etcd, то если требуемое действие касается создания сущностей, которые требуют ресурсов кластера (создания подов, хранилища pv/pvc и т.д.), scheduler проверяет возможность размещения подов на нодах и после чего происходит создание подов, при этом controll-manager контроллирует создание нужного поличества реклик сущности. После создания трубуемой сущности, происходит запись в etcd, controll-manager продолжает отслеживать состояние сущностей на протяжении всего цикла его жизни. 197 | 198 |
199 | 200 | 18. Как выполнить обновление Kubernetes в контуре где нет интернета? 201 | 202 |
203 | Ответ 204 | 205 | Предварительно с рабочего кластера с новой версией Kubernetes и доступом в Интернет необходимо скачать требуемые пакеты kubeadm и образы api, controllmanager, etcd, scheduler, kubelet, docker-ce. Скачать пакеты с разрешением зависимостей возможно командой `yumdownloader --resolve kubeadm`. Образы скачиваются локально в архив `docker save <имя_образа> > <имя_образа>`.tar. 206 | 207 | 1. Удалить приложения из кластера. 208 | ```sh 209 | helm delete --purge all 210 | ``` 211 | 212 | 2. После того, как все необходимые компоненты скачены и загружены в контур без Интернета, выполняет команду сброса kubeadm. 213 | ``` 214 | kubeadm reset 215 | ``` 216 | 217 | 3. Удаляем CNI-плагин Kubernetes. 218 | ``` 219 | yum remove kubernetes-cni-plugins 220 | ``` 221 | 222 | 4. Локально устанавливаем необходимые пакеты. 223 | ``` 224 | yum install ./kubernetes_packages/*.rpm 225 | ``` 226 | 227 | 5. Загружаем образы сервисов Kubernetes. 228 | ``` 229 | docker load < <имя_образа>.tar 230 | ``` 231 | 232 | 6. Отключаем SELinux. 233 | ```sh 234 | setenforce 0 235 | sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config 236 | ``` 237 | 238 | 7. Определяем IP адрес master сервера. 239 | ``` 240 | IP=$(ip route get 1 | awk '{print $NF;exit}') 241 | ``` 242 | 243 | 8. Инициализируем кластер Kubernetes. 244 | ``` 245 | kubeadm init --apiserver-advertise-address=$IP 246 | ``` 247 | 248 | 9. Далее необходимо установить CNI-плагин, например Weave. 249 | 250 | 10. Разрешить на master ноде запускать контейнеры приложения. 251 | ``` 252 | kubectl taint nodes --all node-role.kubernetes.io/master- 253 | ``` 254 | 255 | На worker ноде выполняются аналогичные действия, кроме того, что устанавливается только kubelet. При инициализации master ноды выдаётся token для подключения worker нод, его необходимо сохранить, чтобы позже включить woker ноду в кластер. 256 | 257 |
258 | 259 | 19. Чем Router в Openshift отличается от Ingress в Kubernetes? 260 | 261 |
262 | Ответ 263 | 264 | Router Openshift использует haproxy, как прокси-вебсервер. Ingress как в Kubernetes, так и OpenShift может быть разным (nginx, haproxy, caddy, etc). 265 | 266 |
267 | 268 | 20. Почему для установки Kubernetes требуется отключить swap? 269 | 270 |
271 | Ответ 272 | 273 | Планировщик Kubernetes определяет наилучший доступный узел для развертывания вновь созданных модулей. Если в хост-системе разрешена подкачка памяти, это может привести к проблемам с производительностью и стабильностью в Kubernetes. По этой причине Kubernetes требует, чтобы вы отключили swap в хост-системе. 274 | 275 |
276 | 277 | 21. Что такое *Pod* в Kubernetes? 278 | 279 |
280 | Ответ 281 | 282 | Минимальная сущность в Kubernetes и является абстракцией над контейнерами. Pod представляет собой запрос на запуск одного или более контейнеров на одном узле. 283 | 284 |
285 | 286 | 22. Сколько контейнеров запускается в одном поде? 287 | 288 |
289 | Ответ 290 | 291 | По умолчанию при запуске одного контейнера в одном поде запускается еще *pause* контейнер. Итого, в одном поде может быть запущено *n+1* контейнеров. 292 | 293 |
294 | 295 | 23. Для чего нужен *pause* контейнер в каждом поде? 296 | 297 |
298 | Ответ 299 | 300 | Контейнер *pause* запускается первым в поде и создаёт сетевое пространство имен для пода. Затем Kubernetes выполняет CNI плагин для присоединения контейнера *pause* к сети. Все контейнеры пода используют сетевое пространство имён (netns) этого *pause* контейнера. 301 | 302 |
303 | 304 | 24. Чем отличается *Deployment* от *DeploymentConfig* (Openshift)? 305 | 306 |
307 | Ответ 308 | 309 | https://docs.openshift.com/container-platform/4.1/applications/deployments/what-deployments-are.html 310 | 311 |
312 | 313 | 25. Для чего нужны *Startup*, *Readiness*, *Liveness* пробы? Чем отличаются? 314 | 315 |
316 | Ответ 317 | 318 | Kubelet использует **Liveness** пробу для проверки, когда перезапустить контейнер. Например, Liveness проба должна поймать блокировку, когда приложение запущено, но не может ничего сделать. В этом случае перезапуск приложения может помочь сделать приложение доступным, несмотря на баги. 319 | 320 | Kubelet использует **Readiness** пробы, чтобы узнать, готов ли контейнер принимать траффик. Pod считается готовым, когда все его контейнеры готовы. 321 | 322 | Одно из применений такого сигнала - контроль, какие Pod будут использованы в качестве бекенда для сервиса. Пока Pod не в статусе ready, он будет исключен из балансировщиков нагрузки сервиса. 323 | 324 | Kubelet использует **Startup** пробы, чтобы понять, когда приложение в контейнере было запущено. Если проба настроена, он блокирует Liveness и Readiness проверки, до того как проба становится успешной, и проверяет, что эта проба не мешает запуску приложения. Это может быть использовано для проверки работоспособности медленно стартующих контейнеров, чтобы избежать убийства kubelet'ом прежде, чем они будут запущены. 325 | 326 |
327 | 328 | 26. Чем отличаются *Taints* и *Tolerations* от *Node Afiinity*? 329 | 330 |
331 | Ответ 332 | 333 | *Node Affinity* - это свойство подов, которое позволяет нодам выбирать необходимый под. Node Affinity позволяет ограничивать для каких узлов под может быть запланирован, на основе меток на ноде. Node Affinity требует указания nodeSelector для пода с необходимым label ноды кластера. 334 | 335 | Типы Node Affinity: 336 | `<Требование 1><Момент 1><Требование 2><Момент 2> 337 | requiredDuringSchedulingRequiredDuringExecution` 338 | 339 | | Тип \ Момент | DuringScheduling | DuringExecution | 340 | |-|-|-| 341 | | Тип 1 | Required | Ignored | 342 | | Тип 2 | Preferred | Ignored | 343 | | Тип 3 | Required | Required | 344 | 345 | Существуют определенные операторы nodeAffinity: In, NotIn, Exists, DoesNotExist, Gt или Lt. 346 | 347 | --- 348 | 349 | *Taints* - это свойство нод, которое позволяет поду выбирать необходимую ноду. Tolerations применяеются к подам и позволяют (но не требуют) планировать модули на нодах с соответствующим Taints. 350 | 351 | Установить для ноды Taints: 352 | ``` 353 | kubectl taint nodes key=value:taint-effect 354 | ``` 355 | Taint-effect принимает значения - NoSchedule, PreferNoSchedule, NoExecute. 356 | 357 | Пример: 358 | ``` 359 | kubectl taint nodes node1 app=blue:NoSchedule 360 | ``` 361 | 362 | - NoSchedule означает, что пока в спецификации пода не будет соответствующей записи tolerations, он не сможет быть развернут на ноде (в данном примере node10). 363 | 364 | - PreferNoSchedule— упрощённая версия NoSchedule. В этом случае планировщик попытается не распределять поды, у которых нет соответствующей записи tolerations на ноду, но это не жёсткое ограничение. Если в кластере не окажется ресурсов, то поды начнут разворачиваться на этой ноде. 365 | 366 | - NoExecute — этот эффект запускает немедленную эвакуацию подов, у которых нет соответствующей записи tolerations. 367 | 368 | Taints и Tolerations работают вместе, чтобы гарантировать, что поды не запланированы на несоответствующие ноды. На ноду добавляется один или несколько Taints и это означает, что нода не должна принимать никакие поды, не относящиеся к Taints. 369 | 370 | --- 371 | 372 | Taints и Tolerations не гарантирует, что определенный под будет размещен на нужной ноде. NodeAffinity - не гарантирует, что на определенной ноде, кроме выбранных подов, не будет размещены другие поды. 373 | 374 |
375 | 376 | 27. Чем отличаются *Statefulset* и *Deployment* в плане стратегии обновления подов Rolling Update? 377 | 378 |
379 | Ответ 380 | 381 | Стратегия обновления Rolling Update в **Deployment** предполагает последовательное обновление подов: сначала будет создан новый под, затем будет переключен трафик на новый под и затем удален старый под. 382 | 383 | Стратегия обновления Rolling Update в **StatefulSet** предполагает обновление подов в обратном порядке, то есть под сначала будет удален, а потом установлен новый. 384 | 385 |
386 | 387 | 28. Для чего в Kubernetes используются порты 2379 и 2380? 388 | 389 |
390 | Ответ 391 | 392 | 2379 и 2380 - порты, которые используются etcd. 393 | 2379 используется для взаимодействия etcd с компонентами control plane. 2380 используется только для взаимодействия компонентов etcd в кластере, при наличии множества master нод в кластере. 394 | 395 |
396 | 397 | 29. Задан следующий yaml файл для создания пода Test. Как сделать так, чтобы контейнеры nginx и redis пода test были размещены разных нодах кластера при условии, что существуют лейблы нод `disk=ssd` и `disk=hard`? 398 | ``` 399 | apiVersion: v1 400 | kind: Pod 401 | metadata: 402 | name: Test 403 | spec: 404 | containers: 405 | - name: nginx 406 | image: nginx 407 | - name: redis 408 | image: redis 409 | nodeSelector: 410 | disk: ssd 411 | ``` 412 | 413 |
414 | Ответ 415 | 416 | Никак. Контейнеры одного пода могут размещаться только на одной ноде. Под является неделимой сущностью Kubernetes. 417 | 418 |
419 | 420 | 30. Какую функцию выполняют `indent` и `nindent` в Helm чартах? 421 | 422 |
423 | Ответ 424 | 425 | `indent` делает отступ каждой строки в заданном списке до указанной ширины отступа. 426 | `nindent` аналогична функции `indent`, но добавляет символ новой строки в начало каждой строки в списке. 427 | 428 |
429 | 430 | 31. Чем отличается *Deployment* от *ReplicaSet*? 431 | 432 |
433 | Ответ 434 | 435 | ReplicaSet гарантирует, что определенное количество экземпляров подов (Pods) будет запущено в кластере Kubernetes. 436 | 437 | Deployment предоставляет возможность декларативного обновления для объектов типа поды (Pods) и наборы реплик (ReplicaSets). 438 | 439 | Deployment - уровень абстрации над ReplicaSet. Deployment будет создавать объект ReplicaSet, но с возможностью rolling-update и rollback. 440 | 441 | Чтобы сохранить состояние при разворачивании Deployment необходимо установить ключ `--record` при применении манифеста. 442 | 443 |
444 | 445 | 32. Чем отличается *Deployment* от *StatefulSet*? 446 | 447 |
448 | Ответ 449 | 450 | Deployment выполняет обновление подов и RelicaSets, и является наиболее используемым ресурсом Kubernetes для деплоя приложений, как правило – stateless приложений, но если подключить Persistent Volume – приложение можно использовать как stateful, но все поды деплоймента будут совместно использовать это хранилище и данные из него. Для PVC можно указать режим доступа как `ReadWriteMany`, так и `ReadOnlyMany`. 451 | 452 | StatefulSet используются для управления stateful-приложениями. Создаёт не ReplicaSet, а Pod напрямую с уникальным именем. В связи с этим – при использовании StatefulSet нет возможности выполнить откат версии, но можно его удалить или выполнить скейлинг. При обновлении StatefulSet – будет выполнено RollingUpdate всех подов. StatefulSet использует `volumeClaimTemplates` для описания хранилища и при использовании PVC для каждого пода будет создан уникальный PVC и режимом доступа `ReadWriteOnce`. 453 | 454 |
455 | 456 | 33. Что такое HPA (Horizontal Pod Autoscaling)? Как он работает и что для этого нужно? 457 | 458 |
459 | Ответ 460 | 461 | [HPA](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) - механизм, который позволяет указать нужную метрику(и) настроить автоматический порог масштабирования Pod’ов в зависимости от изменения её значений. 462 | 463 | Чтобы HPA работал необходимо, чтобы в кластере был установлен metrics-server, чтобы считывать меетрики потребления ресурсов. По умолчанию HPA можно настроить для метрики потребления CPU и/или памяти. Возможно расширение функционала HPA с помощью [keda](https://keda.sh/). 464 | 465 |
466 | 467 | 34. Что такое Headless сервис? 468 | 469 |
470 | Ответ 471 | 472 | При указании `ClusterIP: None` для сервиса мы создаём "безголовый сервис", у данного сервиса не будет виртуального IP адреса. Headless сервис это просто А-запись в системе DNS, таким образом имя сервиса преобразуется не в виртуальный IP сервиса, а сразу в IP пода. Headless сервисы полезны, когда приложение само должно управлять тем, к какому Pod подключаться. Например, gRPC-клиенты держат по одному соединению с сервисами и сами управляют запросами, мультиплексируя запросы к одному серверу. В случае использования ClusterIP клиент может создать одно подключение и нагружать ровно один Pod сервера. 473 | 474 |
475 | 476 | 35. Что такое ExternalName сервис? 477 | 478 |
479 | Ответ 480 | 481 | Сервис типа ExternalName добавляет запись типа CNAME во внутренний DNS сервер Kubernetes. Например: 482 | ``` 483 | apiVersion: v1 484 | kind: Service 485 | metadata: 486 | name: ya-ru 487 | spec: 488 | type: ExternalName 489 | externalName: ya.ru 490 | ``` 491 | Для сервиса `ya-ru` не создаётся endpoint. Поэтому сразу переходим к запросам к DNS. 492 | ``` 493 | ya-ru.default.svc.cluster.local. 5 IN CNAME ya.ru. 494 | ``` 495 | 496 |
497 | 498 | 36. Что такое ExternalIP сервис? 499 | 500 |
501 | Ответ 502 | 503 | При определении сервиса можно добавить поле externalIPs, в котором можно указать IP адрес машины кластера. При обращении на этот IP и указанный в сервисе порт, запрос будет переброшен на соответствующий сервис. 504 | Например: 505 | ``` 506 | apiVersion: v1 507 | kind: Service 508 | metadata: 509 | name: external-svc-nginx 510 | labels: 511 | app: nginx 512 | spec: 513 | ports: 514 | - name: http-main 515 | port: 8080 516 | protocol: TCP 517 | targetPort: 8090 518 | selector: 519 | app: nginx 520 | externalIPs: 521 | - 192.168.218.178 522 | ``` 523 | При обращении к 192.168.218.178:8080 запрос будет переброшен к сервису external-svc-nginx:8080 524 | 525 |
526 | 527 | 37. Что такое NodePort сервис? 528 | 529 |
530 | Ответ 531 | 532 | Сервисы типа NodePort открывают порт на каждой ноде кластера на сетевых интерфейсах хоста. Все запросы, приходящие на этот порт, будут пересылаться на endpoints, связанные с данным сервисом. 533 | Диапазон портов, который можно использовать в NodePort — 30000-32767. Но его можно изменить при конфигурации кластера. 534 | 535 |
536 | 537 | 38. Что такое capabilities? Для чего нужно их описывать? 538 | 539 |
540 | Ответ 541 | 542 | [Capabilities](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container) - это разрешения на уровне ядра, которые позволяют гранулярно управлять разрешениями на вызовы ядра, вместо того, чтобы запускать все от имени пользователя root. Capabilities позволяют изменять права доступа к файлам, управлять сетевой подсистемой и выполняет общесистемные функции администрирования. 543 | 544 |
545 | -------------------------------------------------------------------------------- /questions/linux.md: -------------------------------------------------------------------------------- 1 | ## Linux. Basic 2 | 3 | 1. Что такое LA? В каких единицах измеряется? 4 |
5 | Ответ 6 | LA (load average) -- параметр, определяющий среднюю нагрузку на систему за период времени (1 мин, 5 минут, 15 минут). Изменяется в количестве задач на одно ядро процессора. На нагрузку системы также влияет количество задач ввода-вывода и задержка сети. Также влияние на расчета LA оказывает: 1. Технология Hyper-Threading, которая делит одно физическое ядро на 2 логических, 2. Технология Turbo Bust, которая позволяет разгонять тактовую частоту процессора и работать на частоте выше заявленной, т.е. выше номинальной частоты (время на обработку одной задачи уменьшается). 7 |
8 | 9 | 2. Что будет если на сервере LA = 100? 10 |
11 | Ответ 12 | Вероятно, что на сервере будет наблюдаться замедленная работа сервисов, но если параметр LA равен количеству ядер в системе или количеству потоков в системе, то данная нагрузка является нормальной. 13 |
14 | 15 | 3. Почему при высоких показателях значения LA на сервере может не наблюдаться проблем (консоль ssh отзывается, сервисы работают в обычном режиме)? 16 |
17 | Ответ 18 | 19 | На параметр нагрузки LA влияет также и ожидание ввода-вывода (параметр *wa* в утилите *top*) в дисков и задержка сети. Данные параметры могут не влиять на работу основных сервисов в системе, но учитываются при расчете общей нагрузки на систему. 20 | 21 |
22 | 23 | 4. Представлен вывод команды *top*. Что означает каждая запись в выводе? 24 | ``` 25 | top - 21:29:24 up 14:18, 1 user, load average: 0,78, 1,48, 1,10 26 | Tasks: 277 total, 3 running, 274 sleeping, 0 stopped, 0 zombie 27 | %Cpu(s): 12,4 us, 2,5 sy, 0,1 ni, 84,8 id, 0,1 wa, 0,0 hi, 0,1 si, 0,0 st 28 | KiB Mem : 7106404 total, 306972 free, 3127144 used, 3672288 buff/cache 29 | KiB Swap: 8191996 total, 8191996 free, 0 used. 3270520 avail Mem 30 | ``` 31 | 32 |
33 | Ответ 34 | 35 | *top* - название утилиты. 36 | 37 | *21:29:24* - текущее время системы. 38 | 39 | *up 14:18* - сколько часов:минут система работает с момента последнего запуска. 40 | 41 | *1 user* - количество пользователей авторизованных в системе. 42 | 43 | *load average: 0,78, 1,48, 1,10* - параметр средней нагрузки на систему за период времени 1 минута, 5 минут, 15 минут. 44 | 45 | *277 total* - всего процессов в системе. 46 | 47 | *3 running* - количество процессов в работе. 48 | 49 | *274 sleeping* - количество процессов в состоянии sleeping: ожидает какого-либо события или сигнала. 50 | 51 | *0 stopped* - количество приостановленных процессов сигналом STOP или выполнением трассировки. 52 | 53 | *0 zombie* - количество зомби-процессов, которые завершили своё выполнение, но присутствующие в системе, чтобы дать родительскому процессу считать свой код завершения. 54 | 55 | | Параметр | Описание | 56 | |-------------------------------|------------------------------------------------------------------------------------------------| 57 | | us (user) | Использование процессора пользовательским процессами | 58 | | sy (system) | Использование процессора системным процессами | 59 | | ni (nice) | Использование процессора процессами с измененным приоритетом с помощью команды nice | 60 | | id (idle) | Простой процессора. Можно сказать, что это свободные ресурсы | 61 | | wa (IO-wait) | Говорит о простое, связанным с вводом/выводом | 62 | | hi (hardware interrupts) | Показывает сколько процессорного времени было потрачено на обслуживание аппаратного прерывания | 63 | | si (software interrupts) | Показывает сколько процессорного времени было потрачено на обслуживание софтверного прерывания | 64 | | st (stolen by the hypervisor) | Показывает сколько процессорного времени было «украдено» гипервизором | 65 | 66 | KiB Mem - количество оперативной памяти в кибибайтах (кратно 1024): 67 | *7106404 total* -- всего доступно оперативной памяти в системе, 68 | *306972 free* -- свободно оперативной памяти для использования, 69 | *3127144 used* -- использовано оперативной памяти, 70 | *3672288 buff/cache* -- буферизовано/закешировано оперативной памяти. 71 | 72 | *KiB Swap* - количество swap-памяти в кибибайтах (кратно 1024), которые выделено на диске: 73 | *8191996 total* - всего выделено swap-памяти, 74 | *8191996 free* - свободно swap-памяти 75 | *0 used* - использовано swap-памяти, 76 | *3270520 avail Mem* - доступно для использования swap-памяти. 77 | 78 |
79 | 80 | 5. Как в утилите top в Linux посмотреть нагрузку на каждое ядро процессора? 81 | 82 |
83 | Ответ 84 | 85 | В утилите top нажать `1`, чтобы отобразить все ядра в системе. 86 | 87 |
88 | 89 | 6. Как в утилите top в Linux посмотреть какой командой был запущен процесс? 90 | 91 |
92 | Ответ 93 | 94 | В утилите top нажать `c`, чтобы отобразить команды, которыми были запущены процессы. 95 | 96 |
97 | 98 | 7. Где хранятся имена файлов/директорий? 99 |
100 | Ответ 101 | 102 | - Inodes не содержат имён файлов, только другие метаданные файла. 103 | - Каталоги Unix представляют собой списки ассоциативных структур, каждая из которых содержит одно имя файла и один номер индекса. 104 | - Драйвер файловой системы должен найти каталог, ищущий определенное имя файла, а затем преобразовать имя файла в правильный соответствующий номер индекса. 105 | 106 | Таким образом имя файла/директории хранится в информационной структуре каталов. 107 | ![Структура каталогов](imgs/inf_struct_catalogs.gif) 108 | 109 |
110 | 111 | 8. Как удалить файл с именем `-rf`? 112 | 113 |
114 | Ответ 115 | 116 | ``` 117 | rm ./-rf 118 | ``` 119 | 120 |
121 | 122 | 9. Как посмотреть описание дискриптора? Как посмотреть время последней модификации файла? 123 | 124 |
125 | Ответ 126 | 127 | Посмотреть полную информацию по дискриптору возможно командой `stat `. 128 | Время модификации: 129 | ``` 130 | stat --format=%y dira 131 | ``` 132 | 133 |
134 | 135 | 10. Для чего нужна переменная окружения PATH? 136 | 137 |
138 | Ответ 139 | 140 | Переменная окружения PATH содержит абсолютные пути директорий, в которых производится поиск исполняемых файлов при вводе команд 141 | 142 |
143 | 144 | 11. Как посмотреть нагрузку на диски? 145 | 146 |
147 | Ответ 148 | 149 | Установить утилиту `sysstat`, проверить нагрузку на диски `iostat -xtc`. 150 | 151 |
152 | 153 | 12. Что такое файл в понятиях Unix-like операцинных системах? 154 | 155 |
156 | Ответ 157 | 158 | Файлы - это объекты, в которые мы записываем информацию и наши данные, исполняемые файлы, но кроме этих привычных нам понятий здесь есть файлы специального назначения - файлы устройств, файлы туннелей, сокетов и многое другое. 159 | 160 | Типы файлов в Linux: 161 | - Обычные файлы, для хранения информации; 162 | - Специальные файлы - для устройств и туннелей; 163 | - Директории. 164 | 165 |
166 | 167 | 13. Что такое RAID? Какие массивы бывают? 168 | 169 |
170 | Ответ 171 | 172 | RAID (Redundant Array of Independent Disks) - избыточный массив независимых дисков, технология виртуализации данных для объединения нескольких физических дисковых устройств в логический модуль для повышения отказоустойчивости и производительности. 173 | 174 | В зависимости от количества дисков и класса отказоустойчивости существуют следующие основные типы RAID: 175 | RAID 0: 176 | RAID 1: 177 | RAID 5: 178 | RAID 6: 179 | RAID 10: 180 | 181 |
182 | 183 | 14. При каком количестве одновременно вышедших из строя дисков обеспечивает работоспособность RAID 6? 184 | 185 |
186 | Ответ 187 | 188 | 2 диска. 189 | 190 |
191 | 192 | 15. В чем разница между объявлением переменной `export VAR="VALUE"` и `VAR="VALUE"` в bash? 193 | 194 |
195 | Ответ 196 | 197 | При объявлении переменной через export - переменная будет доступна в любых других процессах, при обычном объявлении переменной - переменная будет доступна только в запущенном процессе. 198 | 199 |
200 | 201 | 16. Как остановить выполнение скрипта в bash при возникновении ошибки в команде? 202 | 203 |
204 | Ответ 205 | 206 | Команда `set -e` завершит скрипт с ошибкой, в случае, если в нижеследующем bash коде будет обнаружена ошибка. По-умолчанию bash скрипт продолжает работу, если в ходе выполнения возникла ошибка. 207 | 208 |
209 | 210 | 17. Что в bash скрипте означает команда `set -euo pipefail`? 211 | 212 |
213 | Ответ 214 | 215 | Команда `set` устанавливает аттрибуты оболочки с опеределенных опций. 216 | Опция `-e` - означает, что скрипт будет остановлен, когда произойдет ошибка в ходе его выполнения. 217 | Опция `-u` - означает, что скрипт будет остановлен, если в ходе скрипта, будет обнаружена переменная, которая не определена. 218 | Опция `-o pipefail` - означает, что скрипт будет остановлен, если в ходе пайплайна команд будет выявлена ошибка. 219 | 220 |
221 | 222 | 18. Как активировать debug режим в bash? 223 | 224 |
225 | Ответ 226 | 227 | Команда `set -x` в начале скрипта активирует вывод в консоль debug информации. 228 | 229 |
230 | 231 | 19. Что значит `$@` в bash? 232 | 233 |
234 | Ответ 235 | 236 | `$@` - все параметры переданные скрипту. 237 | 238 |
239 | 240 | 20. Какой код сигнала будет выполнен при исполнении команды `kill `? 241 | 242 |
243 | Ответ 244 | 245 | Сигнал SIGTERM (код 15) - это сигнал по-умолчанию отправляемый при вызове команды kill. Это указывает процессу на завершение работы и обычно считается сигналом для использования при чистом завершении работы. 246 | 247 |
248 | 249 | 21. Как выполнить фильтрацию вывода команды, чтобы на экран были выведены только ошибки (STDERR), игнорируя STDOUT? 250 | 251 |
252 | Ответ 253 | 254 | ``` 255 | cmd 2>&1 >/dev/null | grep pattern 256 | ``` 257 | 258 |
259 | 260 | 22. Какую команду необходимо выполнить, чтобы посмотреть какие пользователи вошли в систему в систему? 261 | 262 |
263 | Ответ 264 | 265 | Команда `w` покажет список пользователей, которые вошли на сервер. 266 | 267 |
268 | 269 | 23. Какой файл необходимо отредактировать, чтобы отключить ssh аутентификацию по паролю? 270 | 271 |
272 | Ответ 273 | 274 | Необходимо редактировать файл `/etc/ssh/sshd_config`, отвечающий за конфигурацию сервиса ssh. 275 | 276 |
277 | 278 | 24. В каком файле находится информация о смонтированных каталогах в файловую систсему? 279 | 280 |
281 | Ответ 282 | 283 | Файл `/etc/fstab` содержит информацию о смонтированных каталогах в файловую систему. 284 | 285 |
286 | 287 | 25. Что выведет команда `cat a` и почему? 288 | ``` 289 | mkdir /tmp/abc 290 | cd /tmp/abc 291 | ls >a 2>b 292 | cat a 293 | ``` 294 | 295 |
296 | Ответ 297 | 298 | `cat a` выведет 299 | ``` 300 | a 301 | b 302 | ``` 303 | Обработка команды идёт справа налево. Сначала создается файл *b*, потом создается файл *a*, команда `ls` отображает список файлов в текущей директории (файлы *a* и *b* уже созданы) в одну колонну и перенаправляет стандартный поток вывода (`>`) в файл *a*, а стандартный поток ошибок `2` в файл *b*. 304 | 305 |
306 | 307 | 26. В bash-скрипте указан аттрибут оболочки `set -x`. В одной из команд происходит ошибка и скрипт завершает свою работу. Как сделать, чтобы при возникновении ошибки в определенной команде скрипт продолжил свою работу? 308 | 309 |
310 | Ответ 311 | 312 | 1 вариант: указать `|| true` после выполнения команды с ошибкой. 313 | ```sh 314 | || true 315 | ``` 316 | 317 | 2 вариант: до выполнения данной команды указать `set +e` для игнорирования ошибок, начиная со следующей строки и после выполнения команды указать `set -e` для завершения работы скрипта в случае ошибки, начиная со следующей строки. 318 | ```sh 319 | set -e 320 | 321 | 322 | set +e 323 | 324 | set -e 325 | ``` 326 | 327 |
328 | 329 | 27. Что такое системный вызов, какие они бывают? 330 | 331 |
332 | Ответ 333 | 334 | Системный вызов - обращение программы к ядру операционной системы для выполнения какой-либо операции. 335 | 336 | В Unix, Unix-like и других POSIX-совместимых операционных системах популярными системными вызовами являются: 337 | - open, 338 | - read, 339 | - write, 340 | - close, 341 | - wait, 342 | - exec, 343 | - fork, 344 | - exit, 345 | - kill. 346 | 347 |
348 | 349 | 28. Что такое сигнал в Unix, зачем они нужны и разница между 9 и 15 сигналами? 350 | 351 |
352 | Ответ 353 | 354 | Сигнал - в Unix-like операционных системах - асинхронное (в случайное время) уведомление процесса для обработки какого-либо события. Один из основных способов взаимодействия между процессами. 355 | 356 | Посылка сигналов от одного процесса к другому обычно осуществляется при помощи системного вызова *kill*. Его первый параметр – PID процесса, которому посылается сигнал; второй параметр – номер сигнала. 357 | ``` 358 | kill(1111, SIGTERM); 359 | ``` 360 | 361 | Стандарт POSIX определяет 28 сигналов. Некоторые из них: 362 | 363 | | Сигнал | Код | Описание | 364 | |-|-|-| 365 | | SIGTERM | 15 | Сигнал завершения (сигнал по умолчанию для утилиты kill) | 366 | | SIGKILL | 9 | Безусловное завершение | 367 | | SIGSTOP | 23 | Остановка выполнения процесса | 368 | | SIGHUP | 1 | Закрытие терминала (перечитать конфигурацию) | 369 | | SIGINT | 2 | Сигнал прерывания (Ctrl-C) с терминала | 370 | 371 |
372 | 373 | 29. Что такое inode? Какая информация там хранится? 374 | 375 |
376 | Ответ 377 | 378 | Inode (индексный дескриптор) - структура данных, в которой хранятся метаданные файла и перечислены блоки с данными файла. Хранит всю информацию, кроме имени файла и данных. Каждый файл в данном каталоге является записью с именем файла и номером индекса. Вся остальная информация о файле извлекается из таблицы индексов путем ссылки на номер индекса. Номера inodes уникальны на уровне раздела. Каждый раздел как собственная таблица индексов. Если у вас закончились inode, вы не можете создавать новые файлы, даже если у вас есть свободное место на данном разделе. 379 | 380 | Inodes хранит метаданные о файле, к которому он относится. Эти метаданные содержат всю информацию об указанном файле. 381 | - Размер. 382 | - Разрешение. 383 | - Владелец/группа. 384 | - Расположение жесткого диска. 385 | - Дата/время. 386 | - Любая другая необходимая информация. 387 | 388 |
389 | 390 | 30. Что такое hard link? В чем разница между hard link и soft link? Примеры их практического применения. 391 | 392 |
393 | Ответ 394 | 395 | **Hard link**: 396 | Ссылка на файл в файловой системе с использованием такого же inode идентификатора, как у файла, на который ссылаемся. 397 | Создадим файл *realFile*. 398 | ``` 399 | touch realFile 400 | ``` 401 | Создадим hard link командой `ln <целевой_файл> <файл_ссылка>`: 402 | ``` 403 | ln realFile hardLink 404 | ``` 405 | Проверим, что inode у файла *realFile* и hard ссылке *hardLink* имеют одинаковый идентификатор. 406 | ``` 407 | $ ls -li 408 | итого 0 409 | 2359720 -rw-r--r-- 2 rmntrvn rmntrvn 0 апр 25 23:24 hardLink 410 | 2359720 -rw-r--r-- 2 rmntrvn rmntrvn 0 апр 25 23:24 realFile 411 | ``` 412 | Как видно realFile и hardLink имеют одинаковый идентификатор inode. 413 | 414 | **Soft link**: 415 | Создадим soft ссылку на файл *realFile*. 416 | ``` 417 | ln -s realFile softLink 418 | ``` 419 | Проверим, что чистовой идентификатор *softLink* отличается от числового идентификатора *realFile*. 420 | ``` 421 | $ ls -li 422 | итого 0 423 | 2359720 -rw-r--r-- 2 rmntrvn rmntrvn 0 апр 25 23:24 hardLink 424 | 2359720 -rw-r--r-- 2 rmntrvn rmntrvn 0 апр 25 23:24 realFile 425 | 2366763 lrwxrwxrwx 1 rmntrvn rmntrvn 8 апр 25 23:29 softLink -> realFile 426 | ``` 427 | 428 | Некоторые нюансы: 429 | - Soft ссылки используют различные номера inode, чем основные файлы. 430 | - Soft ссылки становятся полезными, если исходный файл был удален. 431 | - Soft ссылки могут быть созданы из каталогов. 432 | - Soft ссылка может быть создана на пересечении файловых систем. 433 | 434 | - Hard ссылка может размещаться только на том же логическом разделе, что и оригинальный файл. Это связано с независимой идентификацией файлов на разных разделах. 435 | - Создание жестких ссылок не поддерживается для папок — только для файлов. 436 | - Файловая система должна поддерживать работу с hard ссылками. 437 | 438 |
439 | 440 | 31. Какие состояния процессов существуют? Что значит состояние процесса D? 441 | 442 |
443 | Ответ 444 | 445 | | **Статус** | **Описание** | 446 | |:----------------------------------------------:|:---------------------------------------:| 447 | | R (running or runnable) | Выполняется или готов к выполнению | 448 | | D (uninterruptible sleep) | Ожидает записи на диск | 449 | | S (interruptible sleep) | Неактивен (< 20 s) | 450 | | T (stopped by job control signal) | Остановлен или трассируется отладчиком | 451 | | Z (zombie) | зомби | 452 | | W (paging (not valid since the 2.6.xx kernel)) | Процесс выгружен на диск | 453 | | < | Процесс имеет повышенный приоритет nice | 454 | | N | Процесс имеет пониженный приоритет nice | 455 | | L (locked) | Некоторые страницы блокированы в ядре | 456 | | s | Процесс является лидеров сеанса | 457 | 458 |
459 | 460 | 32. Что такое процесс-зомби и процесс-сирота? Можно ли самостоятельно сделать зомби? 461 | 462 |
463 | Ответ 464 | 465 | *Процесс-зомби* - дочерний процесс в Unix-системе, завершивший своё выполнение, но ещё присутствующий в списке процессов операционной системы, чтобы дать родительскому процессу считать код завершения. 466 | 467 | Удаление зомби возлагается на родительский процесс или системный вызов `wait()` также может это выполнить, поэтому перед ее вызовом не нужно проверять, продолжает ли выполняться требуемый дочерний процесс. Если родительский процесс не удалит своих потомков, то они останутся в состоянии зомби. 468 | 469 | Убить зомби-процесс невозможно. Чтобы убить зомби-процесс нужно найти родительский процесс и завершить его или перезапустить. Найти зомби-процессы и их родителей можно следующей командой: 470 | ``` 471 | ps ajx | grep -w Z 472 | ``` 473 | PID'ы процессов родителей в 3 колонке. Убить процесс следующей командой: 474 | ``` 475 | kill -9 476 | ``` 477 | 478 | *Процесс-сирота* — в семействе операционных систем UNIX вспомогательный процесс, чей основной процесс (или связь с ним) был завершен нештатно (не подав сигнала на завершение работы). 479 | 480 | --- 481 | 482 | Отличие в том, что процесс-сирота (orphan process) всё еще активен. Его родительский процесс был по какой-либо причине прерван, и сирота теперь переходит под руководство init, чей ID процесса равен 1. PPID orphan процесса получит значение 1. Пользователь также может создать подобный процесс, отсоединив его от терминала. Сиротские процессы используют много ресурсов, их легко найти с помощью top или htop. 483 | 484 | В отличии от процесса-сироты, зомби-процесс неактивен, но контролируется родительским процессом, пока тот не решит, что статус выхода дочерних процессов больше не нужен. Он не использует ресурсы и не может быть запланирован для выполнения. Иногда родительский процесс удерживает дочерний процесс в состоянии зомби, чтобы гарантировать, что будущие дочерние процессы не получат тот же PID. Если вы уничтожите родителя зомби-процесса, зомби-процесс тоже умрет. Для этого найдите родительский PID (PPID) зомби и отправьте ему сигнал SIGCHLD (17): kill -17 ppid. 485 | 486 |
487 | 488 | 33. Что такое файловый дескриптор? Какая информация там хранится? 489 | 490 |
491 | Ответ 492 | 493 | *Файловый дескриптор* - неотрицательное целое число, которое используется в интерфейсе между пространством пользователя и пространством ядра (kernel) для идентификации ресурсов файла / сокета. Когда создаётся новый поток ввода-вывода, ядро возвращает процессу, создавшему поток ввода-вывода, его файловый дескриптор. 494 | 495 |
496 | 497 | 34. Что такое buffer/cache память? Для чего нужна? 498 | 499 |
500 | Ответ 501 | 502 | buff/cache память - рассчитанная память, которая зарезервирована, но может быть освобождена при необходимости и используется для быстрого доступа программами к данным, которые находятся в оперативной памяти (быстрой памяти). 503 | 504 | buffers — буферы в памяти — страницы памяти, зарезервированные системой для выделения их процессам, когда они затребуют этого, так же известна как heap-memory; 505 | cached — файлы, которые недавно были использованы системой/процессами и хранящиеся в памяти на случай если вскоре они снова потребуются. 506 | 507 |
508 | 509 | 35. Представлен вывод команды `free`. 510 | ``` 511 | $ free -m 512 | total used free shared buff/cache available 513 | Mem: 6930 3598 843 183 2489 2919 514 | Swap: 15999 4 15995 515 | ``` 516 | Почему доступной (available) памяти сейчас 2919, если свободной (free) памяти 843? 517 | 518 |
519 | Ответ 520 | 521 | - Total. Эта цифра представляет всю существующую память. 522 | - Used вычисление общего значения оперативной памяти системы за вычетом выделенной свободной, разделяемой, буферной и кэш-памяти. 523 | ``` 524 | used = total - free - buff/cache 525 | ``` 526 | - Free – свободная память в системе. 527 | - Shared – память, используемая (преимущественно) в tmpfs 528 | - Buffer, и Cache идентифицируют память, используемую для нужд ядра / операционной системы. Буфер и кеш складываются вместе, а сумма указывается в разделе «buff/cache». 529 | - Available – примерное количество оперативной памяти, доступное для запуска новых приложений без использования ими раздела подкачки. В отличие от поля free, это поле принимает в расчёт страницу cache и также то, что не вся рекуперируемая (пригодная для повторного использования) память будет возвращена для рекуперации из-за того, что элементы используются в данный момент. 530 | 531 |
532 | 533 | 36. Порядок загрузки дистрибутива Linux. 534 | 535 |
536 | Ответ 537 | 538 | 1. Включение компьютера кнопкой. 539 | 2. Загрузить BIOS / UEFI из NVRAM. 540 | 3. Собрать сведения об аппаратуре. 541 | 4. Выбрать устройства для запуска (диск, сеть). 542 | 5. Идентифицировать системный раздел EFI. 543 | 6. Загрузить BIOS / UEFI из NVRAM. 544 | 7. Определить какое ядро загрузить. 545 | 8. Загрузить ядро. 546 | 9. Создать структуры данных ядра. 547 | 10. Запустить init / systemd как PID 1. 548 | 11. Выполнить сценарии запуска. 549 | 12. Запустить систему. 550 | 551 |
552 | -------------------------------------------------------------------------------- /questions/networks.md: -------------------------------------------------------------------------------- 1 | 1. Что такое протокол IP? 2 | 3 |
4 | Ответ 5 | 6 | IP (Internet Protocol) - протокол сетевого уровня стека TCP/IP. 7 | 8 | Основной задачей протокола является доставка датаграмм между хостами сетей TCP/IP через произвольное число промежуточных узлов (маршрутизаторов). 9 | 10 | Функции, реализуемые IP: 11 | - Основа передачи данных. 12 | - Адресация. 13 | - Маршрутизация. 14 | - Фрагментация датаграмм. 15 | Протокол IP не гарантирует надежной доставки пакета: пакеты могут прийти в неправильном порядке, пакет может быть утерян, пакет может продублироваться или оказаться поврежденным. За надежность доставки пакетов отвечают протоколы транспортного уровня. 16 | 17 | На данный момент наиболее распространена четвертая версия протокола (IPv4), однако ведутся активные работы по внедрению более совершенного IPv6. 18 | 19 |
20 | 21 | 2. Сколько адресов в следующих подсетях? 22 | ``` 23 | 192.168.5.0/24 24 | 192.168.5.0/23 25 | 192.168.5.0/19 26 | ``` 27 | 28 |
29 | Ответ 30 | 31 | 32 | `2^(32-N)-2`, где 33 | - N маска: `/24`, `/23`, `/19`; 34 | - 32 бит в маске; 35 | - `-2` зарезервированных адреса: 1 адрес сети и 1 broadcast. 36 | 37 | **Следовательно:** 38 | 39 | сеть | математика | ответ 40 | -----------------|---------------|------------- 41 | 192.168.5.0/`24` | 2^(32-`24`)-2 | = 254 хостов 42 | 192.168.5.0/`23` | 2^(32-`23`)-2 | = 510 хостов 43 | 192.168.5.0/`19` | 2^(32-`19`)-2 | = 8190 хостов 44 | 45 |
46 | 47 | 3. Что такое 127.0.0.1 адрес? Для чего нужен? 48 | 49 |
50 | Ответ 51 | 52 | 127.0.0.1 адрес или localhost доменное имя, а также зарезервированная сеть 127.0.0.1/8 частных IP адресов предназначены для тестирования программы на той же физической машине, где она запускается. 53 | 54 | Использование адреса 127.0.0.1 позволяет устанавливать соединение и передавать информацию для программ-серверов, работающих на том же компьютере, что и программа-клиент, независимо от конфигурации аппаратных сетевых средств компьютера (не требуется сетевая карта, модем, и прочее коммуникационное оборудование, интерфейс реализуется при помощи драйвера псевдоустройства в ядре операционной системы) 55 | 56 | Так же адрес 127.0.0.1 устанавливается для запрета доступа к сервису из внешней сети. Например: 57 | ``` 58 | docker run -d -p 127.0.0.1:3306:3306 mysql 59 | ``` 60 | 61 |
62 | 63 | 4. Вы вводите в строке браузера yandex.ru. Опишите процесс от нажатия клавиши до загрузки страницы. 64 | 65 |
66 | Ответ 67 | 68 | ![](imgs/example-request.jpg) 69 | 70 | Любой URL содержит следующую структуру `<протокол>/<хост>/путь`, например `https://yandex.ru/pogoda/samara`. Также URL может содержать данные для отображения страницы. 71 | 72 | 1. При вводе URL браузер смотрит на протокол запроса. Если протокол в URL не указан, то браузер смотрит на список HSTS (HTTP Strict Transport Security - механизм, принудительно активирующий защищенное соединение через протокол HTTPS), если хост есть в данном списке, то браузер отправит запрос по протоколу HTTPS, если нет, то по HTTP. 73 | 74 | 2. Для того, чтобы установить соединение с сервером, необходим его IP адрес. Так как мы используем домен, то необходимо установить соответствие домена и IP адреса сервера, где размещается ресурс. При запросе мы обращаемся к DNS. Cначала проверяется кеш DNS. Приоритет опроса DNS кеша следующий: 75 | - Кеш браузера, 76 | - Проверяется hosts файл , 77 | - Кеш ОС, 78 | - Кеш роутера, 79 | - Кеш интернет-провайдера 80 | Если данных о данном запрашиваеомом хосте в кеше нет, то: 81 | - DNS интернет провайдера отправляет запрос к контевому серверу DNS (.), 82 | - Если корневой сервер не знает запрашиваемого домена, то он отправляет запрос серверу ответственному за зону (.ru), в которому привязан домен, 83 | - Если DNS сервер зоны не знает запрашиваемого домена, то запрос отправляется к NS серверу домена. 84 | IP адрес хоста, при его наличии у DNS сервера, возвращается обратно по цепочке 85 | 86 | 3. После того, как IP адрес хоста получили, необходимо сформировать на прикладном уровне запрос к серверу. К запросу добавляются следующие заголовки: 87 | - Прикладной уровень: протокол запроса (HTTP/S, FTP и т.д), 88 | - Транспортный (TCP/UDP): порт, по которому обращаемся к серверу. 89 | - Сетевой уровень: IP адрес пакета 90 | - Канальный уровень: определяет есть ли такой адрес в сети. Если нет, то пакет передаётся шлюзу. Устройство шлюза проверяет свою таблицу маршрутизации и направляет пакет в нужном направлении. 91 | 92 | 4. Далее выполняется следующий алгоритм действий установления соединения: 93 | - После того, как запрос достиг сервера, клиент отправляет клиенту запрос (client hello) и свою версию протокола TLS на защищенное соединение. 94 | - Сервер отвечает клиенту (server hello) с информацией о выбранной версии TLS, методом шифрования, методом компресии и публичный сертификат сервера, подписанный центром сертификации. Сертификат содержит публичный ключ, который будет использован клиентом для шифрования данных. 95 | - Клиент подтверждает сертификат сервера с помощью своего списка центров сертификации. Если сертификат подписан центром из списка, то серверу можно доверять. 96 | - Клиент шифрует данные публичным ключем и отправляет серверу зашифрованное сообщение. 97 | - Сервер расшифровывает сообщение с помощью своего приватного ключа и генерирует симметричный мастер-ключ и отправляет его клиенту. 98 | - Клиент отправляет серверу сообщение о финише, шифруя хэш передачи с помощью симметричного ключа. 99 | - Сервер генерирует собственный хеш, а затем расшифровывает полученный от клиента хэш, чтобы проверить совпадает ли хэш клиента с хэшом сервера. Если совпадение обнаружено, то сервер отправляет клиенту сообщение о финише. 100 | 101 | После этого защищенное соединение с сервером установлено. 102 | 103 | 5. Далее необходимо сформировать запрос серверу: 104 | - Клиент формирует запрос HTTP, в котором участвует метод (например GET), URL и версию протокола. Например `GET /pogoda/samara HTTP/2`. 105 | - Следующий заголовок клиента HOST, в котором указывается к какому хосту необходимо обратиться. Например `HOST: yandex.ru`. По заголовку HOST сервер может определить к какому сайту на сервере необходимо обратиться. 106 | - Запрос может также содержать и другие заголовки. Необходимо только, чтобы сервер смог понять эти заголовки. 107 | 108 |
109 | 110 | 5. Чем отличается TCP от UDP? Что лучше? 111 | 112 |
113 | Ответ 114 | 115 | TCP – транспортный протокол передачи данных в сетях TCP/IP, предназначен для управления передачей данных интернета. Пакеты в TCP называются сегментами. 116 | Ориентирован на соединение, используется для передачи данных (электронная почта, файлы, сообщения). При определении потери пакетов будет выполнен перезапрос потерянных пакетов. 117 | 118 | UDP – транспортный протокол, передающий сообщения-датаграммы без необходимости установки соединения в IP-сети. Не ориентирован на установление соединения, используется в потоковой передаче данных (IPTV, VoIP). При потере пакетов перезапроса потерянных пакетов не происходит. 119 | 120 | Нельзя сказать, что TCP лучше UDP, т.к. данные транспортные протоколы используются для различных типов передачи трафика. 121 | 122 |
123 | 124 | 6. Как происходит соединение TCP? 125 | 126 |
127 | Ответ 128 | 129 | ![TCP_Handshake](imgs/tcp-connection.png) 130 | 131 | 1. Клиент, который намеревается установить соединение, посылает серверу сегмент с номером последовательности и флагом SYN. 132 | Дальнейший алгоритм: 133 | Сервер получает сегмент, запоминает номер последовательности и пытается создать сокет (буферы и управляющие структуры памяти) для обслуживания нового клиента; 134 | В случае успеха сервер посылает клиенту сегмент с номером последовательности и флагами SYN и ACK, и переходит в состояние SYN-RECEIVED; 135 | ​В случае неудачи сервер посылает клиенту сегмент с флагом RST. 136 | 2. Если клиент получает сегмент с флагом SYN, то он запоминает номер последовательности и посылает сегмент с флагом ACK. 137 | Дальнейший алгоритм: 138 | Если он одновременно получает и флаг ACK (что обычно и происходит), то он переходит в состояние ESTABLISHED; 139 | Если клиент получает сегмент с флагом RST, то он прекращает попытки соединиться; 140 | Если клиент не получает ответа в течение 10 секунд, то он повторяет процесс соединения заново. 141 | 142 | 3. Если сервер в состоянии SYN-RECEIVED получает сегмент с флагом ACK, то он переходит в состояние ESTABLISHED. 143 | В противном случае после тайм-аута он закрывает сокет и переходит в состояние CLOSED. 144 | Процесс называется «трёхэтапным рукопожатием» (англ. three way handshake), так как несмотря на то что возможен процесс установления соединения с использованием четырёх сегментов (SYN в сторону сервера, ACK в сторону клиента, SYN в сторону клиента, ACK в сторону сервера), на практике для экономии времени используется три сегмента. 145 | 146 |
147 | 148 | 7. Как происходит HTTPS соединение? 149 | 150 |
151 | Ответ 152 | 153 | Когда вы вводите адрес сайта в браузере, он спрашивает у сервера, установлен ли для сайта сертификат. В ответ сервер отправляет общую информацию об SSL-сертификате и публичный ключ, то есть сам сертификат. Браузер сверяет информацию со списком авторизованных центров сертификации. Если всё в порядке, браузер генерирует сеансовый ключ, зашифровывает его публичным ключом и отправляет на сервер. Сервер расшифровывает сообщение и сохраняет сеансовый ключ. После этого между браузером и сайтом устанавливается безопасное соединение через протокол HTTPS. 154 | 155 | ![https-process](imgs/https.png) 156 | 157 |
158 | 159 | 8. Какие стандартные коды ответов есть у веб-серверов? 160 | 161 |
162 | Ответ 163 | 164 | - 1XX — информационные коды. Они отвечают за процесс передачи данных. Это временные коды, они информируют о том, что запрос принят и обработка будет продолжаться. 165 | - 2XX — успешная обработка. Запрос был получен и успешно обработан сервером. 166 | - 3XX — перенаправление (редирект). Эти ответы сервера гласят, что нужно предпринять дальнейшие действия для выполнения запроса. Например, сделать запрос по другому адресу. 167 | - 4XX — ошибка пользователя. Это значит, что запрос не может быть выполнен по его вине. 168 | - 5XX — ошибка сервера. Эти коды возникают из-за ошибок на стороне сервера. В данном случае пользователь всё сделал правильно, но сервер не может выполнить запрос. Для кодов этого класса сервер обязательно показывает сообщение, что не может обработать запрос и по какой причине. 169 | 170 |
171 | 172 | 9. Какие существуют основные типы запросов HTTP? 173 | 174 |
175 | Ответ 176 | 177 | Два наиболее часто используемых видов HTTP запросов это: GET и POST. 178 | 179 | GET - запрашивает данные с определенного ресурса (сайта). 180 | POST - отправляет данные на сервер для последующей их обработки. 181 | 182 | Особенности GET запроса: 183 | - Может быть закэширован 184 | - Остается в истории браузера 185 | - Может быть закладкой в браузере 186 | - Не должен использоваться при работе с крайне важными данными 187 | - Имеет ограниченную длину 188 | - Должен применяться только для получения данных 189 | 190 | Особенности POST запроса: 191 | - Не кэшируется 192 | - Не может быть закладкой в браузере 193 | - Не остаётся в истории браузера 194 | - Нет ограничений по длине запроса 195 | 196 | | Заголовок | Описание | 197 | |-----------|---------------------------------------------------------------------------------------------| 198 | | HEAD | Тоже самое что GET, однако возвращает только HTTP заголовки и не возвращает тело документа. | 199 | | DELETE | Удаляет определенный ресурс. | 200 | | PUT | Загружает представление определенного URI. | 201 | | OPTIONS | Возвращает список видов запросов, поддерживаемых веб-сервером. | 202 | | CONNECT | Создает прозрачный TCP/IP туннель для передачи запросов. | 203 | 204 |
205 | 206 | 10. Клиент пишет, что заходит на свой сайт и он к нему подключается через раз. Что делать, что спрашивать от клиента? 207 | 208 |
209 | Ответ 210 | 211 | Необходимо спросить у клиента какую ошибку он наблюдает при неудачном запросе сайта, в какое время. Если проблема периодическая, то возможно проблема на стороне провайдера клиента. Необходимо запросить у клиента анализ сети с помощью утилит `traceroute`, `mtr` с того узла, где он наблюдает проблему и до сайта 212 | 213 |
214 | 215 | 11. Какой транспортный протокол использует DNS? В каком случае DNS работает по UDP, а в каком по TCP? 216 | 217 |
218 | Ответ 219 | 220 | Все реализации DNS серверов должны поддерживать использование обоих протоколов транспортного уровня (TCP и UDP). Большинство DNS-запросов будет обрабатываться с использованием протокола UDP, исключение составляют трансфер зоны (Query type AXFR) и ответы сервера, превышающие 512 байт на одно сообщение. На вопрос "зачем?" ответ простой -- чтобы не использовались для DDoS. 221 | 222 |
223 | 224 | 11. Какие DNS записи бывают? Что такое DKIM, DMARC, PTR? 225 | 226 |
227 | Ответ 228 | 229 | Основные DNS записи: 230 | 231 | | Тип | Расшифрока | Описание | 232 | |-|-|-| 233 | | A | Address | Адресная запись, соответствие между именем и IP-адресом. | 234 | | AAAA | Address v6 | Аналог A записи для IPv6 адресов. | 235 | | CNAME | Canonical Name | Каноническое имя для псевдонима (одноуровневая переадресация) | 236 | | MX | Mail Exchanger | Адрес почтового шлюза для домена. Состоит из двух частей — приоритета (чем число больше, тем ниже приоритет), и адреса узла. | 237 | | NS | Authoritative name server | Адрес узла, отвечающего за доменную зону. Критически важна для функционирования самой системы доменных имён. | 238 | | PTR | Pointer | Соответствие адреса имени — обратное соответствие для A и AAAA. | 239 | | SOA | Start of authority | Указание на авторитетность информации, используется для указания на новую зону. | 240 | | TXT | Text string | Запись произвольных двоичных данных, до 255 байт в размере. | 241 | | SPF | Sender Policy Framework | Указывает серверы, которые могут отправлять почту с данного домена. | 242 | 243 | DomainKeys Identified Mail (DKIM) — метод E-mail аутентификации, разработанный для обнаружения подделывания сообщений, пересылаемых по email. Метод дает возможность получателю проверить, что письмо действительно было отправлено с заявленного домена. DKIM упрощает борьбу с поддельными адресами отправителей, которые часто используются в фишинговых письмах и в почтовом спаме. 244 | 245 | Domain-based Message Authentication, Reporting and Conformance (идентификация сообщений, создание отчётов и определение соответствия по доменному имени) или DMARC — это техническая спецификация, созданная группой организаций, предназначенная для снижения количества спамовых и фишинговых электронных писем, основанная на идентификации почтовых доменов отправителя на основании правил и признаков, заданных на почтовом сервере получателя. 246 | 247 | Информация о DKIM и DMARC устанавливается в TXT записи домена. 248 | 249 |
250 | 251 | 12. Что такое RoundRobin DNS как работает? 252 | 253 |
254 | Ответ 255 | 256 | Round-robin - алгоритм распределения нагрузки распределенной вычислительной системы методом перебора и упорядочения её элементов по круговому циклу. 257 | 258 | Round-robin DNS работает, отвечая на запросы не только одним IP-адресом, а списком из нескольких адресов серверов, предоставляющих идентичный сервис. Порядок, в котором возвращаются IP-адреса из списка, основан на алгоритме Round-robin. То есть на практике на доменное имя назначаются несколько IP адресов серверов, которые отвечают на запросы. 259 | 260 |
261 | -------------------------------------------------------------------------------- /questions/practice.md: -------------------------------------------------------------------------------- 1 | ## Тестовые практические задания 2 | 3 | 1. Необходимо проходить по списку URL'ов и проверять их доступность. Условия: 4 | - Список URL'ов находится в файле /urls.txt; 5 | - Доступный URL - значит код ответа не 5XX или 4XX; 6 | - Проверка должна быть оформлена в виде функции bash, которая должна вызываться внутри скрипта; 7 | - Функция должна принимать в качестве входного параметра путь к файлу с URL'ами; 8 | - При любом ответе недоступности от сервиса - прерывать дальнейшую проверку. 9 | Временное ограничение 20 мин. 10 | 11 |
12 | Ответ 13 | 14 | Скрипт проверки. Запускать `./script.sh <путь до файла с URLs>` 15 | ```bash 16 | #!/usr/bin/env bash 17 | 18 | set -xueo pipefail 19 | 20 | FILE_URLS=${1:-} 21 | if [[ -z "${FILE_URLS}" ]]; then 22 | echo "File with URLs list do not defined." 23 | exit 1 24 | fi 25 | 26 | function checkUrls() { 27 | local URLS=$1 28 | for URL in $(cat $URLS); do 29 | STATUS=`curl -LI "${URL}" -o /dev/null -w '%{http_code}' -s` 30 | if [[ "${STATUS}" == "500" ]] || [[ "${STATUS}" == "400" ]]; then 31 | echo "URL ${URL} unavailable!" 32 | exit 1 33 | else 34 | echo "URL ${URL} available." 35 | fi 36 | done 37 | } 38 | 39 | checkUrls "${FILE_URLS}" 40 | ``` 41 | 42 |
43 | 44 | 2. Есть две изолированные сети /25 - 192.168.1.0 (gw: 192.168.1.1), 192.168.1.128 (gw: 192.168.1.129). 45 | Есть два сервера со следующими таблицами маршрутизации 46 | ``` 47 | 192.168.1.3 48 | routes 49 | 0.0.0.0/0 192.168.1.1 50 | 51 | 192.168.1.146 52 | routes 53 | 192.168.1.128/24 192.168.1.129 54 | ``` 55 | Что нужно сделать, чтобы эти сервера "видели" друг друга? 56 | 57 | 3. В конфиге nginx некоторого проекта есть два десятка различных location, которые делятся на три базовых типа - memcache, dynamic, static. Лог проекта единый, но для анализа требуется различать записи в логе каким-либо способом. По именам файлов тип location различить нельзя, разделить на три лога также нельзя. Предложите решение. 58 | 59 |
60 | Ответ 61 | Использовать вывод в syslog и определить tag. 62 | Например: 63 | 64 | ``` 65 | location /memcache { 66 | access_log syslog:server=unix:/dev/log,tag=nginx_memcache; 67 | error_log syslog:server=unix:/dev/log,tag=nginx_memcache; 68 | } 69 | 70 | location /dynamic { 71 | access_log syslog:server=unix:/dev/log,tag=nginx_dynamic; 72 | error_log syslog:server=unix:/dev/log,tag=nginx_dynamic; 73 | } 74 | ``` 75 | 76 | /static - соответственно. Вывод в определенный файл syslog можно указать опцией `:syslogtag` 77 |
78 | -------------------------------------------------------------------------------- /questions/terraform.md: -------------------------------------------------------------------------------- 1 | ## Terraform 2 | 3 | 1. Что содержит код Terraform? 4 | 5 |
6 | Ответ 7 | 8 | Ресурсы облачного провайдера, а также провижининг для создаваемых ресурсов. 9 | 10 |
11 | 12 | 2. Как хранить состояние инфраструктуры в Terraform? 13 | 14 |
15 | Ответ 16 | 17 | Например, можно хранить tfstate в git-репозитории команды. Другой вариант - хранить в специализированном Terraform Backend. 18 | 19 |
20 | 21 | 3. Terraform Backend. Какой лучше? 22 | 23 |
24 | Ответ 25 | 26 | Зависит от требованиям к хранению состояния. 27 | 28 | - AWS S3 — Standard (с блокировкой через DynamoDB). Сохраняет состояние в виде заданного ключа в заданном сегменте на Amazon S3. Этот бэкэнд также поддерживает блокировку состояния и проверку согласованности через DynamoDB. 29 | 30 | - terraform enterprise — Standard (без блокировки). 31 | 32 | - etcd — Standard (без блокировки). Сохраняет состояние в etcd 2.x по заданному пути. 33 | 34 | - etcdv3 — Standard (с блокировкой). Сохраняет состояние в хранилище etcd в виде K/V с заданным префиксом. 35 | 36 | - gcs — Standard (с блокировкой). Сохраняет состояние как объект в настраиваемом префиксе в заданном сегменте в Google Cloud Storage (GCS). Этот бэкэнд также поддерживает блокировку состояния. 37 | 38 | - Gitlab Terraform state (с блокировкой). Хранит состояние в Gitlab Terraform state хранилище, используя HTTP протокол и права Gitlab для доступа. 39 | 40 | Существуют также и другие Backend для Terraform. 41 | 42 |
43 | 44 | 4. Как добавить имеющиеся ресурсы в tfstate? 45 | 46 |
47 | Ответ 48 | 49 | ``` 50 | terraform import [options] ADDRESS ID 51 | ``` 52 | 1. Например, создаем директорию и инициализируем будущую инфраструктуру: 53 | ``` 54 | mkdir terraform-test 55 | cd terraform-test 56 | terraform init 57 | vi main.tf 58 | ``` 59 | 2. Добавляем в файл main.tf следующий код: 60 | ``` 61 | provider "aws" { 62 | region = "us-west-1" 63 | profile = "tyx-local" 64 | } 65 | resource "aws_s3_bucket" "sample_bucket" { 66 | bucket = "tyx-local-bucket" 67 | acl = "public" 68 | } 69 | ``` 70 | 3. Выполняем импорт ресурса: 71 | ``` 72 | terraform import aws_s3_bucket.sample_bucket tyx-local-bucket 73 | ``` 74 | 75 |
76 | 77 | 5. Зачем нужен `terraform taint`? 78 | 79 |
80 | Ответ 81 | 82 | Команда `terraform taint` пометит ресурс инфраструктуры, который будет удален и заново создан при следующем применении команды `terraform apply`. 83 | 84 |
85 | 86 | 6. Как проводить тестирование terraform? 87 | 88 |
89 | Ответ 90 | 91 | `terraforn plan` выполнит проверку действующего кода. Работу с облачными ресурсами выполнит 92 | 93 |
94 | 95 | 7. Что такое модуль в terraform? Для чего он нужен? 96 | 97 |
98 | Ответ 99 | 100 | Модуль в Terraform - пакет конфигурации Terraform, который можно использовать при повторной конфигурации компонентов инфраструктуры, а также базовой организации кода Terraform в директориях. При подключения модуля, ему даётся имя. 101 | 102 |
103 | 104 | 8. Как хранить переменные в terraform? 105 | 106 |
107 | Ответ 108 | 109 | *main.tf* - основной конфигурационный файл, описывающий какие инстансы необходимо создать. 110 | *variables.tf* - конфигурация с описанием переменных и значениями по-умолчанию. Если значения по-умолчанию не задано, то они являются обязательными. 111 | *terraform.tfvars* - конфигурация со значениями переменных. Часто является секретным файлом, поэтому нужно с осторожностью пушить в публичные репозитарии. 112 | *outputs.tf* - описание выходных переменных. Необязательный файл, но очень удобно выделять нужные параметры из созданного инстанса, например IP созданного в облаке инстанса. 113 | 114 |
115 | 116 | 9. Как конвертировать Kubernetes yaml-манифест в HCL средствами Linux и terraform? 117 | 118 |
119 | Ответ 120 | 121 | Например: 122 | ``` 123 | echo 'yamldecode(file("filename.yaml"))' | terraform console 124 | ``` 125 | 126 |
127 | 128 | 10. Что такое Workspaces в Terraform? 129 | 130 |
131 | Ответ 132 | 133 | [Workspaces](https://developer.hashicorp.com/terraform/language/state/workspaces#using-workspaces) в Terraform - это возможность управления state файлами. Workspace содержит все что необходимо для управления набором инфраструктуры, а отдельные рабочие области функционируют как полностью отдельные рабочие каталоги. С помощью Workspaces возможно управлять несколькими средами инфраструктуры. 134 | 135 |
136 | 137 | 11. Для чего нужен terragrunt? 138 | 139 |
140 | Ответ 141 | 142 | Terragrunt — это обертка для Terraform, позволяющая решать проблемы, связанные с масштабированием и переиспользованием кода для настройки инфраструктуры. Он позволяет повторно использовать конфигурационные параметры и поддерживает многоуровневые конфигурации и зависимости. 143 | 144 |
145 | 146 | 12. Чем отличается `count` от `for_each`? 147 | 148 |
149 | Ответ 150 | 151 | `count` — это итерация по списку, который содержит целочисленные элементы, `for_each` — это итерация по корневым ключам словаря, которые могут содержать данные любого типа. 152 | 153 | ``` 154 | resource "aws_instance" "web" { 155 | count = 3 156 | 157 | instance_type = "t2.micro" 158 | ami = data.aws_ami.debian_buster.id 159 | tags = { 160 | Name = "WebServer-${count.index + 1}" 161 | } 162 | } 163 | ``` 164 | Описание ресурса выше создаст 3 одинаковых EC2 инстанса, изменив имя с указанием номера текущего состояния счётчика. `count` начинает отсчет с 0, поэтому чтобы 1 EC2 инстанс был с индексом 1 в имени ему прибавили `1`. 165 | 166 | ``` 167 | resource "aws_instance" "server" { 168 | for_each = { 169 | web = { type = "t2.micro", public_ip = true }, 170 | db = { type = "m5.large", public_ip = false } 171 | } 172 | 173 | instance_type = each.value["type"] 174 | ami = data.aws_ami.debian_buster.id 175 | associate_public_ip_address = each.value["public_ip"] 176 | tags = { 177 | Name = "each.key" 178 | } 179 | } 180 | ``` 181 | Ресурс выше создаст 2 EC2 инстанса с итерацией по ключам `each.key` и использовав значения вложенных словарей в конфигурации EC2. 182 | 183 |
184 | -------------------------------------------------------------------------------- /questions/theoryDevOps.md: -------------------------------------------------------------------------------- 1 | ## Теория DevOps 2 | 3 | 1. Что такое DevOps? 4 | 5 | 2. Что такое Scrum и Kanban? Чем они отличаются? 6 | 7 | 3. Какие инструменты использует DevOps? 8 | 9 | 4. Теорема САР. Что это такое? 10 | 11 |
12 | Ответ 13 | 14 | Теорема CAP (известная также как теорема Брюера) — эвристическое утверждение о том, что в любой реализации распределённых вычислений возможно обеспечить не более двух из трёх следующих свойств: 15 | 16 | - Согласованность данных (англ. consistency) — во всех вычислительных узлах в один момент времени данные не противоречат друг другу; 17 | - Доступность (англ. availability) — любой запрос к распределённой системе завершается корректным откликом, однако без гарантии, что ответы всех узлов системы совпадают; 18 | - Устойчивость к разделению (англ. partition tolerance) — расщепление распределённой системы на несколько изолированных секций не приводит к некорректности отклика от каждой из секций. 19 | 20 |
21 | 22 | --------------------------------------------------------------------------------