По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В интернете всегда можно легко найти информацию о веб-службах, которые базируются на SOAP и XML-RPC, а вот REST, почему-то, обделен вниманием. В рамках этой статьи будет рассмотрен базис этой архитектуры и ее практическое применение.
REST: что это?
REST является стилем архитектуры ПО для систем распределения (пример - всем известная www). Обычно с его помощью строят веб-службы. Рой Филдинг, который имеет прямое отношение к созданию протокола HTTP, ввел термин REST в начале века. После этого любую систему, которая поддерживала его, стали называть RESTFul. Доступный интерфейс контроля без ненужных слоев - вот что из себя представляет эта архитектура. Глобальный ID, а именно URL, определяет каждую очередную информационную единицу. Сам же URL характеризуется форматом, который находится в жестких рамках.
Что такое API
REST на практике
Если нет пустых прослоек, данные будут переданы в виде, аналогичном им самим. "Заворачивание" информации в XML не происходит, как в случае с SOAP и XML-RPC, также не используется и AMF, как это бывает с Flash. По сути, происходит чистая передача.
URL, на деле, является базовым ключом для единицы данных. Пример: вторая книга из стопки, лежащей на столе, будет интерпретирована как /book/2, а 145 страница в этой книге - /book/2/page/145. Это достаточно жесткий формат. Самое интересное, что он может присутствовать в любом внешнем источнике, будь то HTML или doc-файл.
Контроль информации сервиса
Протокол передачи данных - основа контроля и управления. Самый часто используемый протокол - это, само собой, HTTP, и для него команды действий выглядят так:
GET (получение);
PUT (добавление);
POST (изменение);
DELETE (удаление).
Поэтому Create/Read/Update/Delete-действия будут выполнены и с 4 указанными алгоритмами, и посредством GET и POST. Это позволит в некоторых случаях обойти негативные эффекты с использованием непринятых PUT и DELETE.
REST в построении веб-сервисов
Веб-сервис - приложение, которое работает в www с доступом, предоставленным через HTTP-протокол. Информационный обмен в рамках веб-сервиса осуществляется посредством формата XML. А это значит, что все данные из тела запросов будут всегда в аналогичном формате.
Для любой информационной единицы можно задать 5 вариантов действия:
GET /info/ (Index) используется для получения списка объектов. Конечно, полученный список будет ограничен заданным идентификатором.
GET /info/{id} (View) позволяет получить всю информацию об объекте.
PUT /info/ или POST /info/ (Create) осуществляет создание нового объекта.
POST /info/{id} или PUT /info/{id} (Edit) производит замену данных, соответствующих введенному идентификатору.
DELETE /info/{id} (Delete) удаляет данные, выделенные идентификатором.
Итоги
Очевидно, что REST, как архитектура, обладает интуитивными алгоритмами и отличается простотой в использовании. Если запрос получен, то определить, что именно он делает, можно немедленно, без форматных разбирательств. При передаче не используются дополнительные слои, что обеспечивает REST особую ресурсоемкость.
Для чего можно использовать?
Основное достоинство сервисов REST - дружественность. Рабочая связка с сайтом, flash, программой? Не важно, ведь алгоритмы парсинга XML и обработка запросов HTTP есть буквально везде. REST значительно упрощает все связанные с этим задачи. Конечно, на практике описанных здесь алгоритмов недостаточно, так как отсутствует защита данных. Но ввести в систему авторизацию и аутентификацию всегда можно при помощи HTTP Authentication.
Сегодня в статье рассказываем про плагин kubectl, который использует tmux, чтобы быстрее устранить неполадки Kubernetes.
Kubernetes - это процветающая платформа для взаимодействия контейнеров с открытым исходным кодом, которая обеспечивает масштабируемость, высокую доступность, надежность и отказоустойчивость приложений. Одной из его многочисленных функций является поддержка запуска пользовательских сценариев или двоичных файлов через основной двоичный файл клиента, kubectl. Kubectl очень мощный, и позволяет пользователям делать с ним все, что они могли бы сделать непосредственно в кластере Kubernetes.
Устранение неполадок с псевдонимами Kubernetes
Каждый, кто использует Kubernetes для управления контейнерами, знает о его особенностях - а также о сложности, причиной которого является его дизайн. Например, существует острая необходимость упростить поиск и устранение неисправностей в Kubernetes с помощью чего-то более быстрого и практически не требующего ручного вмешательства (за исключением критических ситуаций).
Существует много сценариев, которые следует учитывать при устранении неполадок. В одном сценарии вы знаете, что нужно запускать, но синтаксис команды - даже если она может выполняться как одна команда - чрезмерно сложен, или для работы может потребоваться один-два входа.
Например, если часто требуется перейти в запущенный контейнер в пространстве имен System, вы можете неоднократно писать:
kubectl --namespace=kube-system exec -i -t <your-pod-name>
Для упрощения поиска и устранения неисправностей можно использовать псевдонимы этих команд в командной строке. Например, можно добавить следующие файлы dotfiles (.bashrc или .zshrc):
alias ksysex='kubectl --namespace=kube-system exec -i -t'
Это один из многих примеров из хранилища общих псевдонимов Kubernetes, который показывает один из способов упрощения функций в kubectl. Для чего-то простого, подобного этому сценарию, достаточно псевдонима.
Переключение на подключаемый модуль kubectl
Более сложный сценарий устранения неполадок включает в себя выполнение множества команд, одной за другой, для исследования среды и выведения заключения. Одних псевдонимов недостаточно для этого варианта использования; необходима воспроизведение логического узла и корреляция между многими частями развертывания Kubernetes. На самом деле вам нужна автоматизация для получения нужного результата за меньшее время.
Рассмотрим пространства имен от 10 до 20 или даже от 50 до 100, содержащие различные микросервисы в вашем кластере. Что поможет вам начать устранение неполадок в этом сценарии?
Вам потребуется что-то, что может быстро определить, какой модуль в каком пространстве имен вызывает ошибки.
Вам понадобится что-то, что сможет просматривать журналы всех модулей в пространстве имен.
Также может потребоваться просмотр журналов определенных модулей в определенном пространстве имен, в котором были обнаружены ошибки.
Любое решение, охватывающее эти вопросы, было бы очень полезно при изучении производственных проблем, а также в ходе циклов разработки и тестирования.
Чтобы создать нечто более мощное, чем простой псевдоним, можно использовать плагины kubectl. Плагины подобны автономным сценариям, написанным на любом языке сценариев, но предназначены для расширения функциональных возможностей главной команды при работе в качестве администратора Kubernetes.
Чтобы создать плагин, необходимо использовать правильный синтаксис kubectl- < имя-плагина > для того, чтобы скопировать сценарий в один из экспортированных путей в $PATH и предоставить ему исполняемые разрешения chmod+x.
После создания плагина и перемещения его в свой путь, вы можете немедленно запустить его. Например, у меня на пути есть kubectl-krwl и kubectl-kmux:
$ kubectl plugin list
The following compatible plugins are available:
/usr/local/bin/kubectl-krawl
/usr/local/bin/kubectl-kmux
$ kubectl kmux
Теперь давайте изучим, как выглядит обеспечение работы Kubernetes с tmux.
Использование силы tmux
Tmux - очень мощный инструмент, на который полагаются многие команды для устранения проблем, связанных с упрощением работы - от разделения окон на панели для выполнения параллельной отладки на нескольких машинах до мониторинга журналов. Одним из основных его преимуществ является то, что его можно использовать в командной строке или в сценариях автоматизации.
Я создал плагин kubectl, который использует tmux, чтобы сделать поиск и устранение неисправностей гораздо проще. Я буду использовать аннотации, чтобы пройти через логику за плагином (и оставить его для вас, чтобы пройти через полный код плагина):
#NAMESPACE is namespace to monitor.
#POD is pod name
#Containers is container names
# initialize a counter n to count the number of loop counts, later be used by tmux to split panes.
n=0;
# start a loop on a list of pod and containers
while IFS=' ' read -r POD CONTAINERS
do
# tmux create the new window for each pod
tmux neww $COMMAND -n $POD 2>/dev/null
# start a loop for all containers inside a running pod
for CONTAINER in ${CONTAINERS//,/ }
do
if [ x$POD = x -o x$CONTAINER = x ]; then
# if any of the values is null, exit.
warn "Looks like there is a problem getting pods data."
break
fi
# set the command to execute
COMMAND=”kubectl logs -f $POD -c $CONTAINER -n $NAMESPACE”
# check tmux session
if tmux has-session -t <session name> 2>/dev/null;
then
<set session exists>
else
<create session>
fi
# split planes in the current window for each containers
tmux selectp -t $n ;
splitw $COMMAND ;
select-layout tiled ;
# end loop for containers
done
# rename the window to identify by pod name
tmux renamew $POD 2>/dev/null
# increment the counter
((n+=1))
# end loop for pods
done< <(<fetch list of pod and containers from kubernetes cluster>)
# finally select the window and attach session
tmux selectw -t <session name>:1 ;
attach-session -t <session name>;
После запуска скрипта плагина он будет выдавать выходные данные, аналогичные изображению ниже. Каждый модуль имеет собственное окно, и каждый контейнер (если их несколько) разделяется панелями в окне модуля в потоковые журналы по мере их поступления. Преимущество tmux можно увидеть ниже; При правильной конфигурации можно даже увидеть, какое окно активно (см. белые вкладки).
Заключение
Псевдонимы всегда полезны для простого устранения неполадок в средах Kubernetes. Когда среда становится более сложной, плагин kubectl является мощным вариантом для использования более продвинутых сценариев. Ограничения в выборе языка программирования, который можно использовать для записи плагинов kubectl, нет. Единственное требование состоит в том, чтобы соглашение об именовании в пути являлось исполняемым и не имело того же имени, что и существующая команда kubectl.
Прочитать полный код или попробовать плагины можно тут
С чего начинается Linux? LPI (Linux Professional Institute) считает, что изучение необходимо начинать с темы “Обнаружение и настройка комплектующих”. Это работа с “железом”, работа с комплектующими, вся аппаратная часть, то что мы видим и настраиваем. На сайте LPI (www.lpi.org) мы можем найти, что должен знать обучающийся Linux.
Включение и отключение встроенного “железа”
Настройка системы с помощью или без помощи внешних устройств.
Разница между устройствами хранения информации
Разница между устройствами, поддерживающими “Горячую замену”
Выделение аппаратных ресурсов для устройств
Инструменты и утилиты для просмотра списка оборудования
Инструменты и утилиты для работы с USB
Разбор понятий sysfs, udev, dbus.
Далее возьмем для простоты Ubuntu 20.04.
Директория /sys – тут содержится вся информация о подключенных устройствах. В данную директорию монтируется файловая система sysfs. Sysfs — виртуальная файловая система в операционной системе Linux. Экспортирует в пространство пользователя информацию ядра Linux о присутствующих в системе устройствах и драйверах. В данной директории есть определенных набор основных папок:
devices/ - все устройства ядра
bus/ - перечень шин зарегистрированных в ядре. Шина - это общий путь, по которому информация передается от одного компонента к другому
drivers/ - каталог драйверов
block/ - каталог блочных устройств. В данном случае под устройством понимается совокупность физического устройства и драйвера. То есть, если при подключении USB-драйва некоторое новое устройство в /sys/devices/ появится всегда (можно говорить о наличии физического устройства), то появление каталога /sys/block/sda зависит ещё и от наличия в памяти необходимых драйверов (usb-storage, sd_mod и т.д. - включая все драйвера, необходимые для поддержки usb)
class/ - группировка устройств по классам
Навигацию по папкам осуществляем с помощью команды cd. Учитывая вложенность папок переход на уровень вверх, т.е в родительскую папку используем cd .., где двоеточие обозначает родительский каталог. А также переход в любую папку, например, cd /sys/bus. Чтобы посмотреть все что находится в каталоге используем команду ls
Следующий момент, если мы зайдем в папку с устройствами, то мы можем увидеть, как ОС наша видит устройства.
Не очень удобно. Чтобы удобнее было работать с устройствами, используется udev. Это менеджер устройств, который позволяет ОС предоставлять устройства в удобно используемом виде, чтобы было понятно нам.
Далее папка /proc - она находится в корне нашей ОС и содержит информацию о всех запущенных процессах. Она создается в оперативной памяти при загрузке ПК. Количество файлов зависит от конфигурации данной системы. Для работы с файлами необходимы права суперпользователя.
Внесенные изменения сохраняются только до конца сеанса. Cеанс - это каждая терминальная оболочка, запущенная процессами пользователя
В данную папку монтируется виртуальная система procfs. В ней находится информация о состоянии ядра и вообще операционной системе в целом. Термин виртуальная система - это некая абстракция, которая позволяет философии Linux говорить, что “все является файлом”, а вообще если рассматривать понятие файловая система - это иерархическое хранилище данных, которые собраны в соответствии с определенной структурой.
Вот так выглядит данная папка.
Мы можем посмотреть всю информацию, которая нам известна о процессоре. Данная информация содержится в файле cpuinfo. Для вывода информации содержащейся в файле используем команду cat [имя_файла]. Результат работы команды cat cpuinfo ниже.
Есть еще интересный файл mounts. Он показывает все смонтированные файловые системы.
Результат вывода будет примерно такой.
Можно увидеть, когда мы просматриваем содержимое каталога командой ls, то файлы подсвечиваются белым цветом, а каталоги синим.
Переходим немного глубже по дереву каталогов файловой системы cd /prox/sys в данной папке все о настройках и процессах, происходящих с нашей текущей файловой системой. В данной директории есть несколько подпапок.
И зайдем в подпапку, относящуюся к файловой системе fs.
Посмотрим например file-max в данном файле информация о том сколько файлов одновременно может открыть пользователь.
В последней версии число таких фалов увеличилось. До версии 20.04, число файлов было по умолчанию 204394. Можно изменить число или данные, например, с помощью команды echo 10000000000 > file-max
Все изменения, которые мы делаем в данной директории они сохраняются только до перезагрузки. Это надо учитывать.
Еще одна основная папка в корневой директории папка /dev – она в себе содержит интерфейсы работы с драйверами ядра.
/dev/sd [буква] - жесткий диск (в системах на ядре Linux)
/dev/sd [буква][номер] – раздел диска
/dev/sr [номер] (/dev/scd [номер]) – CD-ROM
/dev/eth [номер] – cетевой интерфейс Ethernet
/dev/wlan [номер] – cетевой интерфейс Wireless
/dev/lp [номер] – принтер
/dev/video [номер] - устройство изображений, камеры, фотоаппараты
/dev/bus/usb/001/[номер] – устройство номер на шине USB
/dev/dsp – звуковой вывод
Набор оборудования, команды вывода перечня устройств.
Lsmod – информация о модуле ядра
Lspci - информация об устройствах PCI
Lspcmcia - информация об устройствах PCMCIA
Lsusb - информация о шине USB
Lshw – детальная информация о комплектующих.
Команда Lsmod – утилита которая показывает нам модули ядра. Модуль ядра — это объект, который содержит код позволяющий расширить функционал ядра. Вот так выглядит ее вывод.
По сути, если проводить аналогию с ОС Windows это драйвера.
Вывод команды lshw
Данная команда сканирует все устройства и выводит подробную информацию по ним и достаточно детально.
Утилиты для работы с модулем ядра или утилиты управления модулями ядра.
Lsmod – информация о модулях ядра
Modinfo - информация о конкретном модуле
Rmmod - удаление модуля ядра
Insmod – установка модуля ядра
Modprobe – деликатное удаление или добавление модуля ядра
Фактически эти команды используются для добавления и удаления “драйверов” устройств в Linux системе. В большинстве случаев ОС самостоятельно подключит устройство, но бывает такое, что устройство не стандартное и требуется добавить модель, для того чтобы ядро ОС, корректно работало с данным устройством.
Rmmod и insmod - команды грубые и не умеют работать с зависимостями, поэтому необходимо использовать Modprobe с различными ключами.
Взаимодействие с CPU, основные понятия:
IRQ - механизм прерываний
IO адреса – обмен информацией между устройствами и CPU
DMA – обращение к ОЗУ минуя CPU
Выделение ресурсов. IRQ - механизм прерываний это система которая сообщает центральному процессору о наступлении какого либо события, на которое процессор должен отреагировать. Есть определенные адреса прерываний, их можно увидеть в биосе ПК. Есть стандартные номера прерываний. Ранее была необходимость при конфликте устройств назначать в ручном режиме данные прерывания, в настоящее время с появлением технологии Plug and Play, данная потребность исчезла.
IO адреса – это область памяти в которой процессор считывает информацию об устройствах и туда же ее записывает. Это выделенный диапазон. Вообще она бывает в памяти и адресация по портам.
DMA - технология появилась относительно недавно и позволяет устройствам обращаться к памяти минуя процессор. Существенно повышает быстродействие.
Все технологии настраиваются автоматически.
Устройства хранения:
PATA – параллельный интерфейс
SATA - последовательный интерфейс
SCSI - стандарт передачи данных
SAS – замена SCSI
Современные SATA, SAS нужно понимать есть устройства поддерживающие горячую замену и устройства не поддерживающие горячую замену.
Устройства, которые можно выдернуть из ПК, безболезненно, и это не обрушит систему, причем ОС не подвиснет, не перезагрузится, это устройства поддерживающие горячую замену, например, USB.
Устройство, которое не поддерживает горячую замену, например, оперативная память. Если мы ее выдернем из материнской платы, ОС однозначно обрушится.
Команда blkid показывает какие устройства у нас смонтированы.
Нужно отметить, что у каждого устройства есть уникальный UUID (универсальный уникальный идентификатор), что udev умеет читать UUID, и он монтирует в понятном виде нам.