На параметр нагрузки LA влияет также и ожидание ввода-вывода (параметр wa в утилите top) в дисков и задержка сети. Данные параметры могут не влиять на работу основных сервисов в системе, но учитываются при расчете общей нагрузки на систему.

top - название утилиты.

21:29:24 - текущее время системы.

up 14:18 - сколько часов:минут система работает с момента последнего запуска.

1 user - количество пользователей авторизованных в системе.

load average: 0,78, 1,48, 1,10 - параметр средней нагрузки на систему за период времени 1 минута, 5 минут, 15 минут.

277 total - всего процессов в системе.

3 running - количество процессов в работе.

274 sleeping - количество процессов в состоянии sleeping: ожидает какого-либо события или сигнала.

0 stopped - количество приостановленных процессов сигналом STOP или выполнением трассировки.

0 zombie - количество зомби-процессов, которые завершили своё выполнение, но присутствующие в системе, чтобы дать родительскому процессу считать свой код завершения.

KiB Mem - количество оперативной памяти в кибибайтах (кратно 1024): 7106404 total -- всего доступно оперативной памяти в системе, 306972 free -- свободно оперативной памяти для использования, 3127144 used -- использовано оперативной памяти, 3672288 buff/cache -- буферизовано/закешировано оперативной памяти.

KiB Swap - количество swap-памяти в кибибайтах (кратно 1024), которые выделено на диске: 8191996 total - всего выделено swap-памяти, 8191996 free - свободно swap-памяти 0 used - использовано swap-памяти, 3270520 avail Mem - доступно для использования swap-памяти.

В утилите top нажать 1, чтобы отобразить все ядра в системе.

В утилите top нажать c, чтобы отобразить команды, которыми были запущены процессы.

Когда вы вводите адрес сайта в браузере, он спрашивает у сервера, установлен ли для сайта сертификат. В ответ сервер отправляет общую информацию об SSL-сертификате и публичный ключ, то есть сам сертификат. Браузер сверяет информацию со списком авторизованных центров сертификации. Если всё в порядке, браузер генерирует сеансовый ключ, зашифровывает его публичным ключом и отправляет на сервер. Сервер расшифровывает сообщение и сохраняет сеансовый ключ. После этого между браузером и сайтом устанавливается безопасное соединение через протокол HTTPS.

TCP – транспортный протокол передачи данных в сетях TCP/IP, предварительно устанавливающий соединение с сетью. Ориентирован на соединение, используется для передачи данных (электронная почта, файлы, сообщения). При определении потери пакетов будет выполнен перезапрос потерянных пакетов.

UDP – транспортный протокол, передающий сообщения-датаграммы без необходимости установки соединения в IP-сети. Не ориентирован на установление соединения, используется в потоковой передаче данных (IPTV, VoIP). При потере пакетов перезапроса потерянных пакетов не происходит.

Нельзя сказать, что TCP лучше UDP, т.к. данные транспортные протоколы используются для различных типов передачи трафика.

1. Клиент, который намеревается установить соединение, посылает серверу сегмент с номером последовательности и флагом SYN. Дальнейший алгоритм: Сервер получает сегмент, запоминает номер последовательности и пытается создать сокет (буферы и управляющие структуры памяти) для обслуживания нового клиента; В случае успеха сервер посылает клиенту сегмент с номером последовательности и флагами SYN и ACK, и переходит в состояние SYN-RECEIVED; ​В случае неудачи сервер посылает клиенту сегмент с флагом RST.

2. Если клиент получает сегмент с флагом SYN, то он запоминает номер последовательности и посылает сегмент с флагом ACK. Дальнейший алгоритм: Если он одновременно получает и флаг ACK (что обычно и происходит), то он переходит в состояние ESTABLISHED; Если клиент получает сегмент с флагом RST, то он прекращает попытки соединиться; Если клиент не получает ответа в течение 10 секунд, то он повторяет процесс соединения заново.

3. Если сервер в состоянии SYN-RECEIVED получает сегмент с флагом ACK, то он переходит в состояние ESTABLISHED. В противном случае после тайм-аута он закрывает сокет и переходит в состояние CLOSED. Процесс называется «трёхэтапным рукопожатием» (англ. three way handshake), так как несмотря на то что возможен процесс установления соединения с использованием четырёх сегментов (SYN в сторону сервера, ACK в сторону клиента, SYN в сторону клиента, ACK в сторону сервера), на практике для экономии времени используется три сегмента.

• 1XX — информационные коды. Они отвечают за процесс передачи данных. Это временные коды, они информируют о том, что запрос принят и обработка будет продолжаться.
• 2XX — успешная обработка. Запрос был получен и успешно обработан сервером.
• 3XX — перенаправление (редирект). Эти ответы сервера гласят, что нужно предпринять дальнейшие действия для выполнения запроса. Например, сделать запрос по другому адресу.
• 4XX — ошибка пользователя. Это значит, что запрос не может быть выполнен по его вине.
• 5XX — ошибка сервера. Эти коды возникают из-за ошибок на стороне сервера. В данном случае пользователь всё сделал правильно, но сервер не может выполнить запрос. Для кодов этого класса сервер обязательно показывает сообщение, что не может обработать запрос и по какой причине.

Два наиболее часто используемых видов HTTP запросов это: GET и POST.

GET - запрашивает данные с определенного ресурса (сайта). POST - отправляет данные на сервер для последующей их обработки.

Особенности GET запроса:

• Может быть закэширован
• Остается в истории браузера
• Может быть закладкой в браузере
• Не должен использоваться при работе с крайне важными данными
• Имеет ограниченную длину
• Должен применяться только для получения данных

Особенности POST запроса:

• Не кэшируется
• Не может быть закладкой в браузере
• Не остаётся в истории браузера
• Нет ограничений по длине запроса

• Inodes не содержат имён файлов, только другие метаданные файла.
• Каталоги Unix представляют собой списки ассоциативных структур, каждая из которых содержит одно имя файла и один номер индекса.
• Драйвер файловой системы должен найти каталог, ищущий определенное имя файла, а затем преобразовать имя файла в правильный соответствующий номер индекса.

Таким образом имя файла/директории хранится в информационной структуре каталов.

Посмотреть полную информацию по дискриптору возможно командой stat <path_to_file>. Время модификации:

stat --format=%y dira

Переменная окружения PATH содержит абсолютные пути директорий, в которых производится поиск исполняемых файлов при вводе команд

Установить утилиту sysstat, проверить нагрузку на диски iostat -xtc.

Необходимо спросить у клиента какую ошибку он наблюдает при неудачном запросе сайта, в какое время. Если проблема периодическая, то возможно проблема на стороне провайдера клиента. Необходимо запросить у клиента анализ сети с помощью утилит traceroute, mtr с того узла, где он наблюдает проблему и до сайта

127.0.0.1 адрес или localhost доменное имя, а также зарезервированная сеть 127.0.0.1/8 частных IP адресов предназначены для тестирования программы на той же физической машине, где она запускается.

Использование адреса 127.0.0.1 позволяет устанавливать соединение и передавать информацию для программ-серверов, работающих на том же компьютере, что и программа-клиент, независимо от конфигурации аппаратных сетевых средств компьютера (не требуется сетевая карта, модем, и прочее коммуникационное оборудование, интерфейс реализуется при помощи драйвера псевдоустройства в ядре операционной системы)

Так же адрес 127.0.0.1 устанавливается для запрета доступа к сервису из внешней сети. Например:

docker run -d -p 127.0.0.1:3306:3306 mysql

Файлы - это объекты, в которые мы записываем информацию и наши данные, исполняемые файлы, но кроме этих привычных нам понятий здесь есть файлы специального назначения - файлы устройств, файлы туннелей, сокетов и многое другое.

Типы файлов в Linux:

• Обычные файлы, для хранения информации;
• Специальные файлы - для устройств и туннелей;
• Директории.

RAID (Redundant Array of Independent Disks) - избыточный массив независимых дисков, технология виртуализации данных для объединения нескольких физических дисковых устройств в логический модуль для повышения отказоустойчивости и производительности.

В зависимости от количества дисков и класса отказоустойчивости существуют следующие основные типы RAID: RAID 0: RAID 1: RAID 5: RAID 6: RAID 10:

2 диска.

Системный вызов - обращение программы к ядру операционной системы для выполнения какой-либо операции.

В Unix, Unix-like и других POSIX-совместимых операционных системах популярными системными вызовами являются:

• open,
• read,
• write,
• close,
• wait,
• exec,
• fork,
• exit,
• kill.

Сигнал - в Unix-like операционных системах - асинхронное (в случайное время) уведомление процесса для обработки какого-либо события. Один из основных способов взаимодействия между процессами.

Посылка сигналов от одного процесса к другому обычно осуществляется при помощи системного вызова kill. Его первый параметр – PID процесса, которому посылается сигнал; второй параметр – номер сигнала.

kill(1111, SIGTERM);

Стандарт POSIX определяет 28 сигналов. Некоторые из них:

Процесс-зомби - дочерний процесс в Unix-системе, завершивший своё выполнение, но ещё присутствующий в списке процессов операционной системы, чтобы дать родительскому процессу считать код завершения.

Удаление зомби возлагается на родительский процесс или системный вызов wait() также может это выполнить, поэтому перед ее вызовом не нужно проверять, продолжает ли выполняться требуемый дочерний процесс. Если родительский процесс не удалит своих потомков, то они останутся в состоянии зомби.

Убить зомби-процесс невозможно. Чтобы убить зомби-процесс нужно найти родительский процесс и завершить его или перезапустить. Найти зомби-процессы и их родителей можно следующей командой:

ps ajx | grep -w Z

PID'ы процессов родителей в 3 колонке. Убить процесс следующей командой:

kill -9 <PID процесса родителя>

Процесс-сирота - — в семействе операционных систем UNIX вспомогательный процесс, чей основной процесс (или связь с ним) был завершен нештатно (не подав сигнала на завершение работы).

Отличие в том, что процесс-сирота (orphan process) всё еще активен. Его родительский процесс был по какой-либо причине прерван, и сирота теперь переходит под руководство init, чей ID процесса равен 1. PPID orphan процесса получит значение 1. Пользователь также может создать подобный процесс, отсоединив его от терминала. Сиротские процессы используют много ресурсов, их легко найти с помощью top или htop.

В отличии от процесса-сироты, зомби-процесс неактивен, но контролируется родительским процессом, пока тот не решит, что статус выхода дочерних процессов больше не нужен. Он не использует ресурсы и не может быть запланирован для выполнения. Иногда родительский процесс удерживает дочерний процесс в состоянии зомби, чтобы гарантировать, что будущие дочерние процессы не получат тот же PID. Если вы уничтожите родителя зомби-процесса, зомби-процесс тоже умрет. Для этого найдите родительский PID (PPID) зомби и отправьте ему сигнал SIGCHLD (17): kill -17 ppid.

Файловый дескриптор - неотрицательное целое число, которое используется в интерфейсе между пространством пользователя и пространством ядра (kernel) для идентификации ресурсов файла / сокета. Когда создаётся новый поток ввода-вывода, ядро возвращает процессу, создавшему поток ввода-вывода, его файловый дескриптор.

buff/cache память - рассчитанная память, которая зарезервирована, но может быть освобождена при необходимости и используется для быстрого доступа программами к данным, которые находятся в оперативной памяти (быстрой памяти).

buffers — буферы в памяти — страницы памяти, зарезервированные системой для выделения их процессам, когда они затребуют этого, так же известна как heap-memory; cached — файлы, которые недавно были использованы системой/процессами и хранящиеся в памяти на случай если вскоре они снова потребуются.

Основные DNS записи:

DomainKeys Identified Mail (DKIM) — метод E-mail аутентификации, разработанный для обнаружения подделывания сообщений, пересылаемых по email. Метод дает возможность получателю проверить, что письмо действительно было отправлено с заявленного домена. DKIM упрощает борьбу с поддельными адресами отправителей, которые часто используются в фишинговых письмах и в почтовом спаме.

Domain-based Message Authentication, Reporting and Conformance (идентификация сообщений, создание отчётов и определение соответствия по доменному имени) или DMARC — это техническая спецификация, созданная группой организаций, предназначенная для снижения количества спамовых и фишинговых электронных писем, основанная на идентификации почтовых доменов отправителя на основании правил и признаков, заданных на почтовом сервере получателя.

Информация о DKIM и DMARC устанавливается в TXT записи домена.

Round-robin - алгоритм распределения нагрузки распределенной вычислительной системы методом перебора и упорядочения её элементов по круговому циклу.

Round-robin DNS работает, отвечая на запросы не только одним IP-адресом, а списком из нескольких адресов серверов, предоставляющих идентичный сервис. Порядок, в котором возвращаются IP-адреса из списка, основан на алгоритме Round-robin. То есть на практике на доменное имя назначаются несколько IP адресов серверов, которые отвечают на запросы.

• Total. Эта цифра представляет всю существующую память.
• Used вычисление общего значения оперативной памяти системы за вычетом выделенной свободной, разделяемой, буферной и кэш-памяти.

used = total - free - buff/cache

• Free – свободная память в системе.
• Shared – память, используемая (преимущественно) в tmpfs
• Buffer, и Cache идентифицируют память, используемую для нужд ядра / операционной системы. Буфер и кеш складываются вместе, а сумма указывается в разделе «buff/cache».
• Available – примерное количество оперативной памяти, доступное для запуска новых приложений без использования ими раздела подкачки. В отличие от поля free, это поле принимает в расчёт страницу cache и также то, что не вся рекуперируемая (пригодная для повторного использования) память будет возвращена для рекуперации из-за того, что элементы используются в данный момент.

Любой URL содержит следующую структуру <протокол>/<хост>/путь, например https://yandex.ru/pogoda/samara. Также URL может содержать данные для отображения страницы.

1. При вводе URL браузер смотрит на протокол запроса. Если протокол в URL не указан, то браузер смотрит на список HSTS (HTTP Strict Transport Security - механизм, принудительно активирующий защищенное соединение через протокол HTTPS), если хост есть в данном списке, то браузер отправит запрос по протоколу HTTPS, если нет, то по HTTP.

2. Для того, чтобы установить соединение с сервером, необходим его IP адрес. Так как мы используем домен, то необходимо установить соответствие домена и IP адреса сервера, где размещается ресурс. При запросе мы обращаемся к DNS. Cначала проверяется кеш DNS. Приоритет опроса DNS кеша следующий:

• Кеш браузера,
• Проверяется hosts файл ,
• Кеш ОС,
• Кеш роутера,
• Кеш интернет-провайдера Если данных о данном запрашиваеомом хосте в кеше нет, то:
• DNS интернет провайдера отправляет запрос к контевому серверу DNS (.),
• Если корневой сервер не знает запрашиваемого домена, то он отправляет запрос серверу ответственному за зону (.ru), в которому привязан домен,
• Если DNS сервер зоны не знает запрашиваемого домена, то запрос отправляется к NS серверу домена. IP адрес хоста, при его наличии у DNS сервера, возвращается обратно по цепочке

3. После того, как IP адрес хоста получили, необходимо сформировать на прикладном уровне запрос к серверу. К запросу добавляются следующие заголовки:

• Прикладной уровень: протокол запроса (HTTP/S, FTP и т.д),
• Транспортный (TCP/UDP): порт, по которому обращаемся к серверу.
• Сетевой уровень: IP адрес пакета
• Канальный уровень: определяет есть ли такой адрес в сети. Если нет, то пакет передаётся шлюзу. Устройство шлюза проверяет свою таблицу маршрутизации и направляет пакет в нужном направлении.

4. Далее выполняется следующий алгоритм действий установления соединения:

• После того, как запрос достиг сервера, клиент отправляет клиенту запрос (client hello) и свою версию протокола TLS на защищенное соединение.
• Сервер отвечает клиенту (server hello) с информацией о выбранной версии TLS, методом шифрования, методом компресии и публичный сертификат сервера, подписанный центром сертификации. Сертификат содержит публичный ключ, который будет использован клиентом для шифрования данных.
• Клиент подтверждает сертификат сервера с помощью своего списка центров сертификации. Если сертификат подписан центром из списка, то серверу можно доверять.
• Клиент шифрует данные публичным ключем и отправляет серверу зашифрованное сообщение.
• Сервер расшифровывает сообщение с помощью своего приватного ключа и генерирует симметричный мастер-ключ и отправляет его клиенту.
• Клиент отправляет серверу сообщение о финише, шифруя хэш передачи с помощью симметричного ключа.
• Сервер генерирует собственный хеш, а затем расшифровывает полученный от клиента хэш, чтобы проверить совпадает ли хэш клиента с хэшом сервера. Если совпадение обнаружено, то сервер отправляет клиенту сообщение о финише.

После этого защищенное соединение с сервером установлено.

5. Далее необходимо сформировать запрос серверу:

• Клиент формирует запрос HTTP, в котором участвует метод (например GET), URL и версию протокола. Например GET /pogoda/samara HTTP/2.
• Следующий заголовок клиента HOST, в котором указывается к какому хосту необходимо обратиться. Например HOST: yandex.ru. По заголовку HOST сервер может определить к какому сайту на сервере необходимо обратиться.
• Запрос может также содержать и другие заголовки. Необходимо только, чтобы сервер смог понять эти заголовки.

GitFlow - модель ветвления Git.

Ключевые идеи:

1. Данная модель отлично подходит для организации рабочего процесса на основе релизов,
2. Gitflow предлагает создание отдельной ветки для исправлений ошибок в продуктовой среде.

Последовательность работы при использовании модели Gitflow:

1. Из master создается ветка develop.
2. Из develop создаются ветки feature.
3. Когда разработка новой функциональности завершена, она объединяется с веткой develop.
4. Из develop создается ветка release.
5. Когда ветка релиза готова, она объединяется с develop и master.
6. Если в master обнаружена проблема, из нее создается ветка hotfix.
7. Как только исправление на ветке hotfix завершено, она объединяется с develop и master.

• git merge - выполняет слияние коммитов из одной ветки в другую. В этом процессе изменяется только целевая ветка. История исходных веток остается неизменной.

  

  Преимущества:

  1. Простота,
  2. Сохраняет полную историю и хронологический порядок,
  3. Поддерживает контекст ветки.

  Недостатки:

  1. История коммитов может быть заполнена (загрязнена) множеством коммитов,
  2. Отладка с использованием git bisect может стать сложнее.

• git rebase - сжимает все изменения в один патч. Затем интегрирует патч в целевую ветку. В отличии от merge, rebase перезаписывает историю, потому что она передаётся завершенную работу из одной ветки в другую. В процессе устраняется нежелательная история.

  

  Преимущества:

  1. Упрощает потенциально сложную историю,
  2. Упрощение манипуляций с единственным коммитом,
  3. Избежание слияния коммитов в занятых репозиториях и ветках,
  4. Очищает промежуточные коммиты, делая их одним коммитом, что полезно для DevOps команд.

  Недостатки:

  1. Сжатие фич до нескольких коммитов может скрыть контекст
  2. Перемещение публичных репозиториев может быть опасным при работе в команде,
  3. Появляется больше работы,
  4. Для восстановления с удаленными ветками требуется принудительный пуш. Это приводит к обновлению всех веток, имеющих одно и то же имя, как локально, так и удаленно.

И tag и branch представляют собой указатели на коммиты.

• Ветка представляет собой отдельный поток разработки, который может выполняться одновременно с другими разработками в той же кодовой базе. Коммит в ветке указывает на изменения, которые добавляются в новых коммитах
• Тег представляет собой версию определенной ветки в определенный момент времени.

Tag представляет собой версию той или иной ветки в определенный момент времени. Branch представляет собой отдельный поток разработки, который может выполнятся одновременно с другими разработками в той же кодовой базе.

Необходимо найти хеш этого коммита и выполнить следующую комманду в ветке, в которую нужно перенести коммит.

git cherry-pick <commit_hash>

Continuous Integration (непрерывная интеграция) - практика интеграции изменений кода из ветки разработки в основную ветку путём инструментов для интеграции.

Continuous Delivery (непрерывная доставка) - практика содержания кода в репозитории в состоянии пригодным для разворачивания на рабочее окружение.

Continuous Deployment (непрерывное разворачивание) - практика доставки каждого изменения в коде продукта на рабочее окружение.

Разница между Continuous Delivery и Continuous Deployment очень маленькая. Представим два пайплайна для одного и того же приложения. В каждом есть шаги:

1. Source Control - внесение изменений в систему контроля версий ПО.
2. Build - сборка приложения и прогон unit тестов
3. Staging - деплой на тестовое окружение, прогон интеграционных, нагрузочных и других тестов
4. Production - деплой на окружение с пользователями

Каждый пайплайн запускается автоматически по триггеру из системы контроля версий. В случае Continuous Deployment каждый следующий шаг, будет выполнен автоматически если предыдущий был успешный, включая деплой на Production.

Если же у вас Continuous Delivery, то шаги будут выполняться автоматически только в безопасной среде, а перед деплоем на Production пайплайн остановится и будет ждать ручного подтверждения. Механизм, как это будет реализовано может быть разным. От самого простого, когда ответственный человек должен зайти в пайплайн и нажать кнопку Next, до интерактивного бота с кнопками в корпоративном мессенджере.

Ресурсы облачного провайдера, а также провижининг для создаваемых ресурсов.

Например, можно хранить tfstate в git-репозитории команды. Другой вариант - хранить в специализированном Terraform Backend.

Зависит от требованиям к хранению состояния.

• AWS S3 — Standard (с locking через DynamoDB). Сохраняет состояние в виде заданного ключа в заданном сегменте на Amazon S3. Этот бэкэнд также поддерживает блокировку состояния и проверку согласованности через DynamoDB.

• terraform enterprise — Standard (без блокировки).

• etcd — Standard (без лока). Сохраняет состояние в etcd 2.x по заданному пути.

• etcdv3 — Standard (с блокировкой). Сохраняет состояние в хранилище etcd в виде K/V с заданным префиксом.

• gcs — Standard (с локом). Сохраняет состояние как объект в настраиваемом префиксе в заданном сегменте в Google Cloud Storage (GCS). Этот бэкэнд также поддерживает блокировку состояния.

Существуют также и другие Backend для Terraform.

terraform import [options] ADDRESS ID

1. Например, создаем директорию и инициализируем будущую инфраструктуру:

mkdir terraform-test
cd terraform-test
terraform init
vi main.tf

2. Добавляем в файл main.tf следующий код:

provider "aws" {
  region = "us-west-1"
  profile = "tyx-local"
}
resource "aws_s3_bucket" "sample_bucket" {
  bucket = "tyx-local-bucket"
  acl = "public"
}

3. Выполняем импорт ресурса:

terraform import aws_s3_bucket.sample_bucket tyx-local-bucket

Команда terraform taint пометит ресурс инфраструктуры, который будет удален и заново создан при следующем применении команды terraform apply.

terraforn plan выполнит проверку действующего кода. Работу с облачными ресурсами выполнит

!!! Написать полный ответ позже !!!

!!! Написать полный ответ позже !!!

Docker - программное обеспечение для автоматизации развёртывания и управления приложениями в средах с поддержкой контейнеризации.

Образ - шаблон приложения, который содержит слои файловой системы в режиме "только-чтение".

Контейнер - запущенный образ приложения, который кроме нижних слоев в режиме "только чтение" содержит верхний слой в режиме "чтение-запись".

Инструкции CMD и ENTRYPOINT выполняются в момент запуска контейнера, тольо инструкция CMD позволяет переопределить передаваемые команде аргументы.

Пример 1. CMD: Опишем сборку образа в Dockerfile.

FROM alpine  
CMD ["ping", "8.8.8.8"]  

В инструкцию CMD передаются 2 аргумента. Выполним сборку образа docker build -t test . и запустим контейнер.

$ docker run test
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=43 time=32.976 ms
64 bytes from 8.8.8.8: seq=1 ttl=43 time=31.998 ms
64 bytes from 8.8.8.8: seq=2 ttl=43 time=31.843 ms
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 31.708/33.316/36.823 ms

Теперь передадим 2 новых аргумента для запуска контейнера.

$ docker run test traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 46 byte packets
 1  172.17.0.1 (172.17.0.1)  0.017 ms  0.016 ms  0.009 ms
 2  192.168.168.1 (192.168.168.1)  0.996 ms  1.553 ms  2.069 ms
 3  *  *  *
 4  lag-2-435.bgw01.samara.ertelecom.ru (85.113.62.125)  1.454 ms  1.427 ms  1.984 ms
 5  172.68.8.3 (172.68.8.3)  19.685 ms  15.722 ms  15.565 ms
 6  172.68.8.2 (172.68.8.2)  15.846 ms  22.696 ms  35.093 ms
 7  one.one.one.one (1.1.1.1)  17.439 ms  17.670 ms  24.202 ms

ping заменен на traceroute, IP адрес заменен на 1.1.1.1.

Пример 2. ENTRYPOINT: Опишем сборку образа в Dockerfile.

FROM alpine  
ENTRYPOINT ["ping", "8.8.8.8"]

В инструкцию ENTRYPOINT передаются 2 аргумента. Выполним сборку образа docker build -t test . и запустим контейнер.

$ docker run test2
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=43 time=36.189 ms
64 bytes from 8.8.8.8: seq=1 ttl=43 time=44.120 ms
64 bytes from 8.8.8.8: seq=2 ttl=43 time=44.584 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 36.189/41.631/44.584 ms

Теперь передадим изменим один из аргументов для запуска контейнера.

$ docker run test2 ping 1.1.1.1
BusyBox v1.31.1 () multi-call binary.

Usage: ping [OPTIONS] HOST

Send ICMP ECHO_REQUEST packets to network hosts

	-4,-6		Force IP or IPv6 name resolution
	-c CNT		Send only CNT pings
	-s SIZE		Send SIZE data bytes in packets (default 56)
	-i SECS		Interval
	-A		Ping as soon as reply is recevied
	-t TTL		Set TTL
	-I IFACE/IP	Source interface or IP address
	-W SEC		Seconds to wait for the first response (default 10)
			(after all -c CNT packets are sent)
	-w SEC		Seconds until ping exits (default:infinite)
			(can exit earlier with -c CNT)
	-q		Quiet, only display output at start
			and when finished
	-p HEXBYTE	Pattern to use for payload

Как видим, аргумент передать контейнеру нельзя.

Пример 3. ENTRYPOINT и CMD: Опишем сборку образа в Dockerfile.

FROM alpine  
ENTRYPOINT ["ping"]
CMD ["8.8.8.8"]

В инструкцию ENTRYPOINT передаётся аргумент ping, в CMD передаётся аргумент 8.8.8.8. Выполним сборку образа docker build -t test . и запустим контейнер.

$ docker run test3
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=43 time=41.176 ms
64 bytes from 8.8.8.8: seq=1 ttl=43 time=32.875 ms
64 bytes from 8.8.8.8: seq=2 ttl=43 time=40.395 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 32.875/38.148/41.176 ms

Пробуем изменить 2 аргумента.

$ docker run test3 traceroute 1.1.1.1
BusyBox v1.31.1 () multi-call binary.

Usage: ping [OPTIONS] HOST

Send ICMP ECHO_REQUEST packets to network hosts

	-4,-6		Force IP or IPv6 name resolution
	-c CNT		Send only CNT pings
	-s SIZE		Send SIZE data bytes in packets (default 56)
	-i SECS		Interval
	-A		Ping as soon as reply is recevied
	-t TTL		Set TTL
	-I IFACE/IP	Source interface or IP address
	-W SEC		Seconds to wait for the first response (default 10)
			(after all -c CNT packets are sent)
	-w SEC		Seconds until ping exits (default:infinite)
			(can exit earlier with -c CNT)
	-q		Quiet, only display output at start
			and when finished
	-p HEXBYTE	Pattern to use for payload

Изменить 2 аргумента невозможно. Заменим аргумент инструкции CMD.

$ docker run test3 1.1.1.1    
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: seq=0 ttl=58 time=31.412 ms
64 bytes from 1.1.1.1: seq=1 ttl=58 time=19.400 ms
64 bytes from 1.1.1.1: seq=2 ttl=58 time=15.814 ms
^C
--- 1.1.1.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 15.814/22.208/31.412 ms

При такой сборке образа команды ENTRYPOINT и CMD при запуске контейнера будут запущены последовательно, но аргумент возможно изменить только для CMD.

Инструкция COPY копируют файлы и директории с хостовой машины внутрь контейнера, инструкция ADD копирует файлы и директории с хостовой машины внутрь контейнера и может распаковывать .tar архивы.

1. Стараться объединять несколько команд RUN в одну для уменьшения количества слоёв образа.
2. Частоизменяемые слои образа необходимо располагать ниже по уровню, чтобы ускорить процесс сборки, т.к. при изменении верхнего слоя, все нижеследующие слои будут пересобираться.
3. Указывать явные версии образов в инструкции FROM, чтобы избежать случая, когда выйдет новая версия образа с тегом latest.
4. При установке пакетов указывать версии пакетов.
5. Очищать кеш пакетного менеджера и удалять ненужные файлы после выполненной инструкции.

Модуль raw отличается от command и shell тем, что не выполняет дополнительную обработку выполнения команды. Эти дополнительные обработки присутствуют в почти любом модуле Ansible. Модуль raw передает команду, как есть, в "сыром" (raw) виде без проверок. Модули command и shell отличаются тем, что в модуле command команда выполняется без прохождения через командную оболочку /bin/sh. Поэтому переменные определенные в оболочке и перенаправления - конвееры работать не будут. Модуль shell выполняет команды через оболочку по умолчанию /bin/sh. Поэтому там будут доступны переменные оболочки и перенаправления.

1. Использовать модуль authorized_key для добавления ключей.
2. Использовать модуль shell, чтобы вручную с использованием команды cat {{ PUBLIC_SSH_KEY }} >> /home/{{ USER }}/.ssh/authorized_keys добавить ключ. В данном случае шаблоны Jinja2 PUBLIC_SSH_KEY и USER должны быть заданы.

Сгруппировать сервера, на которых должны заводиться группы пользователей, в инвентори или написать в плейбуке условие, которому передаётся список серверов, на которых необходимо выполнить задачу.

Использовать модуль raw, которому необходимо передать команду для установки python на сервере. Модуль raw принимает команду без дополнительной обработки Python и выполняет её на сервере.

Ansible роль представляет собой структурированный плейбук, содержащий, как минимум, набор задач (tasks) и дополнительно - обработчики событий (handlers), переменных (default и vars), файлов (files), шаблонов (templates), описание и зависимости (metadata) и тесты (tests).

Ansible применяет порядок приоритета переменных. Ниже представлен список в порядке повышения приоритета.

1. command line values (for example, -u my_user, these are not variables)
2. role defaults (defined in role/defaults/main.yml)
3. inventory file or script group vars
4. inventory group_vars/all
5. playbook group_vars/all
6. inventory group_vars/*
7. playbook group_vars/*
8. inventory file or script host vars
9. inventory host_vars/*
10. playbook host_vars/*
11. host facts / cached set_facts
12. play vars
13. play vars_prompt
14. play vars_files
15. role vars (определяемые в role/vars/main.yml)
16. block vars (только для задач в block)
17. task vars (только для задач)
18. include_vars
19. set_facts / registered vars
20. role (и include_role) params
21. include params
22. extra vars (например, -e "user=my_user")(всегда приоритетнее)

Соответственно переменные в vars будут приорететнее, чем в defaults.

files - содержит файлы, которые будут скопированы на настраиваемые хосты; так же — может содержать скрипты, которые позже будут запускаться на хостах.

templates - содержит шаблоны файлов с переменными.

https://www.redhat.com/cms/managed-files/cl-openshift-and-kubernetes-ebook-f25170wg-202010-en.pdf

1. Openshift имеет более строгие политики безопасности и модели аутентификации.
2. Openshift поддерживает полную интеграцию CI/CD Jenkins.
3. Openshift имеет веб-консоль по-умолчанию. В Kubernetes консоль необходимо дополнительно устанавливать консоль.
4. В Kubernetes возможно устанавливать сторонние сетевые плагины. В Openshift используется собственное сетевое решение Open vSwitch, которое предоставляет 3 различный плагина.
5. Kubernetes может быть установлен практически на любой дистрибутив Linux. Openshift имеет ограничения на устанавливаемые дистрибутивы, преимущественно используются RH-дистрибутивы.
6. Kubernets доступен в большинстве облачных платформ - GCP, AWS, Azure, Yandex.Cloud. Openshift доступен на облачной платформе Azure и облаке от IBM.
7. По-умолчанию, в Opemshift поды в кластере могут быть запущены только под обычным пользователем, чтобы запустить под под пользователем root необходимо выдать права для сервисного аккаунта. В Kubernetes по-умолчанию поды могут быть запущены по пользователем root.

ReplicationController гарантирует, что указанное количество реплик подов будут работать одновременно. Другими словами, ReplicationController гарантирует, что под или набор подов всегда активен и доступен.

ReplicaSet - это следующее поколение Replication Controller. Единственная разница между ReplicaSet и Replication Controller - это поддержка селектора. ReplicaSet поддерживает множественный выбор в селекторе, тогда как ReplicationController поддерживает в селекторе только выбор на основе равенства.

DaemonSet является контроллером, основным назначением которого является запуск подов на всех нодах кластера. Если нода добавляется/удаляется — DaemonSet автоматически добавит/удалит под на этой ноде.

DaemonSet подходят для запуска приложений, которые должны работать на всех нодах, например — екпортёры мониторинга, сбор логов и так далее.

Необходимо настроить podAntiAffinity. Данное указание определяет, что для определенных подов следует использовать их размещание на разных нодах.

Никак. Под - минимальная и неделимая сущность, Kubernetes оперирует подами, а не отдельными контейнерами.

Когда узлу (node) кластера не хватает памяти или дискового пространства, он активирует флаг, сигнализирующий о данной проблеме. Данное действие блокирует любое новое выделение ресурсов на ноде и запускает процесс "выселения" (evicted) пода с ноды.

В этот момент kubelet начинает восстанавливать ресурсы, удаляя контейнеры и объявляя поды, как Failed, пока использование ресурсов снова не станет ниже порога "выселения".

Сначала kubelet пытается освободить ресурсы узла, особенно диск, путем удаления мертвых модулей и их контейнеров, а затем неиспользуемых образов. Если этого недостаточно, kubelet начинает выселять поды конечных пользователей в следующем порядке:

1. Best Effort.
2. Burstable поды, использующие больше ресурсов, чем запрос истощенного ресурса.
3. Burstable поды, использующие меньше ресурсов, чем запрос истощенного ресурса.

Чтобы под не был удален при "выселении", необходимо настроить политики QoS для пода как Guaranteed.

Подробнее в документации Kubernetes: Create a Pod that gets assigned a QoS class of Guaranteed

Кроме того, можно использовать сущность кубернетиса PodDisruptionBudget, которая позволит регулировать количество вытесняемых подов и обеспчивать гарантированную доступность для конкретного микросервиса https://kubernetes.io/docs/tasks/run-application/configure-pdb/

Kube-proxy отвечает за взаимодействие между сервисами на разных нодах кластера.

• Kube-apiserver отвечает за оркестрацию всех операций кластера.
• Controller-manager (Node controller + Replication Controller) Controller отвечает за функции контроля за нодами, репликами.
• ETCD cluster (распределенное хранилище ключ-значение) ETCD хранит информацию о кластере и его конфигурацию.
• Kube-sheduler отвечает за планирование приложений и контейнеров на нодах.

По-умолчанию на master ноде не размещаются контейнеры приложений, но данный фунционал возможно настроить.

• Kubelet слушает инструкции от kube-apiserver и разворачивает или удаляет контейнеры на нодах.
• Kube-proxy отвечает за взаимодействие между сервисами на разных нодах кластера.

На worker нодах по-умолчанию размещаются контейнеры приложений. На каждой ноде кластера устанавливается Docker или другая платформа контейнеризации (например RKT или containterd). На Master ноде также устанавливается Docker, если необходимо использовать компоненты Kubernetes в контейнерах.

1. Следовать инструкции установки kubeadm.

2. Установка с использованием kubespray.

!!! Написать точную инфу тут !!!

Операторы -- это программные расширения Kubernetes,призванное автоматизировать выполнение рутинных действий над объектами кластера при определённых событиях.

Оператор работает по подписке на события к API Kubernetes.

DaemonSet гарантирует, что определенный под будет запущен на всех нодах кластера. При наличии DaemonSet в кластере на любой из существующих и будущих нод в кластере зарезервированы ресурсы для пода на ноде.

Здесь стоит сделать оговорку насчет того, что DaemonSet может работать не на всех нодах кластера, а на некоторых, выбранных, например, по nodeSelector. К примеру, у нас есть GPU ноды и нам нужно на все эти ноды задеплоить микросервис выполняющий вычисления на GPU.

Если на другой ноде нет ресурсов для размещения пода или нет сетевой доступности до ноды.

Controller выполняет постоянный процесс мониторинга состояния кластера и различных компонент.

Controller-manager (Node controller + Replication Controller) - Controller отвечает за функции контроля за нодами, репликами.

!!! Написать полный ответ позже !!!

!!! Записать полный ответ тут !!!

Router Openshift использует haproxy, как прокси-вебсервер. Ingress как в Kubernetes, так и OpenShift может быть разным (nginx, haproxy, caddy, etc).

!!! Вставить сюда таблицу со сравнением !!!

Планировщик Kubernetes определяет наилучший доступный узел для развертывания вновь созданных модулей. Если в хост-системе разрешена подкачка памяти, это может привести к проблемам с производительностью и стабильностью в Kubernetes. По этой причине Kubernetes требует, чтобы вы отключили swap в хост-системе.

Минимальная сущность в Kubernetes и является абстракцией над контейнерами. Pod представляет собой запрос на запуск одного или более контейнеров на одном узле.

По умолчанию при запуске одного контейнера в одном поде запускается еще pause контейнер. Итого, в одном поде может быть запущено n+1 контейнеров.

Контейнер pause запускается первым в поде и создаёт сетевое пространство имен для пода. Затем Kubernetes выполняет CNI плагин для присоединения контейнера pause к сети. Все контейнеры пода используют сетевое пространство имён (netns) этого pause контейнера.

!!! Написать полный ответ позже !!!

https://kubernetes.io/ru/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

Node Affinity - это свойство подов, которое позволяет нодам выбирать необходимый под. Node Affinity позволяет ограничивать для каких узлов под может быть запланирован, на основе меток на ноде. Node Affinity требует указания nodeSelector для пода с необходимым label ноды кластера.

Типы Node Affinity: <Требование 1><Момент 1><Требование 2><Момент 2> requiredDuringSchedulingRequiredDuringExecution

Существуют определенные операторы nodeAffinity: In, NotIn, Exists, DoesNotExist, Gt или Lt.

Taints - это свойство нод, которое позволяет поду выбирать необходимую ноду. Tolerations применяеются к подам и позволяют (но не требуют) планировать модули на нодах с соответствующим Taints.

Установить для ноды Taints:

kubectl taint nodes <node-name> key=value:taint-effect

Taint-effect принимает значения - NoSchedule, PreferNoSchedule, NoExecute.

Пример:

kubectl taint nodes node1 app=blue:NoSchedule

• NoSchedule означает, что пока в спецификации пода не будет соответствующей записи tolerations, он не сможет быть развернут на ноде (в данном примере node10).

• PreferNoSchedule— упрощённая версия NoSchedule. В этом случае планировщик попытается не распределять поды, у которых нет соответствующей записи tolerations на ноду, но это не жёсткое ограничение. Если в кластере не окажется ресурсов, то поды начнут разворачиваться на этой ноде.

• NoExecute — этот эффект запускает немедленную эвакуацию подов, у которых нет соответствующей записи tolerations.

Taints и Tolerations работают вместе, чтобы гарантировать, что поды не запланированы на несоответствующие ноды. На ноду добавляется один или несколько Taints и это означает, что нода не должна принимать никакие поды, не относящиеся к Taints.

Taints и Tolerations не гарантирует, что определенный под будет размещен на нужной ноде. NodeAffinity - не гарантирует, что на определенной ноде, кроме выбранных подов, не будет размещены другие поды.

Стратегия обновления Rolling Update в Deployment предполагает последовательное обновление подов: сначала будет создан новый под, затем будет переключен трафик на новый под и затем удален старый под.

Стратегия обновления Rolling Update в StatefulSet предполагает обновление подов в обратном порядке, то есть под сначала будет удален, а потом установлен новый.

!!! Добавить описание !!! Выжимку отсюда можно взять: https://habr.com/ru/post/267721/

Скрипт проверки. Запускать ./script.sh <путь до файла с URLs>

#!/usr/bin/env bash

set -xueo pipefail

FILE_URLS=${1:-}
if [[ -z "${FILE_URLS}" ]]; then
  echo "File with URLs list do not defined."
  exit 1
fi

function checkUrls() {
  local URLS=$1
  for URL in $(cat $URLS); do
    STATUS=`curl -LI "${URL}" -o /dev/null -w '%{http_code}' -s`
    if [[ "${STATUS}" == "500" ]] || [[ "${STATUS}" == "400" ]]; then
      echo "URL ${URL} unavailable!"
      exit 1
    else
      echo "URL ${URL} available."
    fi
  done
}

checkUrls "${FILE_URLS}"

location /memcache {
  access_log syslog:server=unix:/dev/log,tag=nginx_memcache;
  error_log syslog:server=unix:/dev/log,tag=nginx_memcache;
}

location /dynamic {
  access_log syslog:server=unix:/dev/log,tag=nginx_dynamic;
  error_log syslog:server=unix:/dev/log,tag=nginx_dynamic;
}

/static - соответственно. Вывод в определенный файл syslog можно указать опцией :syslogtag