По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Сегодня речь в статье пойдет о Docker. Все, кто хоть как-то касаются сферы IT слышали про Docker, но не все знают, что же это такое. Итак, сегодня мы простыми словами расскажем о том, что такое Docker, чем это отличается от виртуализации, покажем подробный процесс инсталляции на CentOS 7 и установим просто графический интерфейс Portainer, для управления контейнерами. Также немного коснемся команд для использования Docker.
Что такое Docker?
Docker - это платформа, которая может “упаковать” приложение, его зависимости, middleware и так далее в так называемый “контейнер”, после чего у вас появится возможность развернуть данный контейнер на любом сервере, на котором установлен Docker - причем буквально за доли секунды, одной командой.
Благодаря этим решается сразу несколько задач - в первую очередь, процесс запуска приложения на сервере многократно упрощается, во вторую - какие-либо баги в контейнеризированном приложении никак не повлияют на сам сервер, также как и специфические настройки сервера не повлияют на приложение.
И хоть кажется, что Docker выглядит и работает как виртуальная машина, на самом деле они очень разные: виртуальная машина эмулирует сервер целиком, включая все аппаратные ресурсы, а контейнер изолирует приложение, процессы, юзеров и файловую систему. При этом все контейнеры используют общее Linux ядро хоста и запускается в нативном режиме только на Linux машинах, но зато на одной машине можно запустить примерно в 5-6 раз больше контейнеров, чем виртуальных машинах. Ниже на схеме показаны различия:
Установка Docker
Как было упомянуто в начале статьи, устанавливать Докер мы будем на CentOS 7 - процесс установки крайне простой и быстрый.
Итак, сначала необходимо установить с помощью yum несколько пакетов:
yum install -y yum-utils
device-mapper-persistent-data
Lvm2
Далее необходимо установить stable репозиторий для Докера, который вам понадобится, даже если вы захотите устанавливать билды из edge и test репозиториев:
yum-config-manager
--add-repo
https://download.docker.com/linux/centos/docker-ce.repo
Затем устанавливаем сам Docker:
yum install docker-ce
И, наконец, запускаем Docker:
systemctl start docker
Проверяем, что Docker запустился и работает в два шага:
systemctl status docker
Вы должны увидеть следующий вывод:
После этого пробуем развернуть контейнер hello-world:
docker run hello-world
Если все шаги были выполнены корректно, то на экране должно появится следующее:
Установка Portainer
Portainer - это очень удобный графический интерфейс для управления Docker или Docker Swarm. Устанавливается он практически в одно действие - так как сам точно также является контейнером. Итак:
Создаем разметку для Portainer:
docker volume create portainer_data
И затем запускаем сам контейнер:
docker run -d -p 9000:9000 -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer
После чего заходите на сетевой адрес вашего сервера на порт 9000, и вы должны увидеть окно с предложением установить пароль администратора:
Далее выбираем где находится наш Докер - на этом же сервере, или на другом (в нашем случае - Local) и кликаем Connect.
После чего вас встретит красивый дэшборд:
Я предлагаю вам попробовать разобраться со всем многообразием дэшборда самим и задавать нам вопросы в комментариях - а мы пока продемонстрируем несколько фич.
Итак, сначала кликните на Containers - вы увидите все имеющиеся контейнеры с информацией о них:
Как вы можете видеть, у нас на данный момент запущен только один контейнер - Portainer, и доступ к нему открыт по порту 9000 (столбец Published Ports), и адрес во внутренней сети Docker - 172.17.0.2.
Далее кликните на App Templates в меню справа - и вы увидите весь список приложений, который можно запустить одним кликом:
Зайдем во вкладку Httpd:
Сперва, назовите данный контейнер как-нибудь - мы назвали test-merionet. Затем, можете кликнуть на Show advanced options и вы увидите возможность выбора какой порт, протокол и том будет использоваться данным контейнером. Затем просто нажмите на Deploy the container.
Пройдет буквально несколько секунд и вас должно перекинуть обратно на вкладку Containers, но, с уже вторым запущенным контейнером:
Отсюда вы увидите, что httpd сервер доступен на 32768 порту. Итак, пробуем зайти на данный сервер через браузер:
Вы должны будете увидеть надпись It works! так же как на скриншоте выше - дальнейшую настройку httpd мы пока оставляем за кадром.
Донастройка Docker и полезные команды
Итак, вы уже познакомились с Docker и получили представление о его возможностях. Ниже в тексте мы опишем действия, которые также необходимо сделать после установки и некоторые команды, без которых буквально трудно жить, если активно используешь Докер.
Первым делом, настройте автозапуск для сервиса Docker:
systemctl enable docker
Затем, вы можете проверить запущенные контейнеры в консоли (на случай если вам не нравится идея использования GUI) с помощью команды
docker ps
Теперь немного о командах и синтаксисе - будем показывать на примерах:
Допустим, нам нужно запустить CentOS и выполнить в нем команду echo:
docker run centos echo “Hello from Merion Networks”
Запустить CentOS и подключиться к его терминалу:
docker run -t-i centos /bin/bash
Можете сразу указать нужные порты с помощью ключа -p и запустить контейнер в бэкграунде с помощью ключа --d:
docker run -p 80:80 --d nodejs-app
Итак, совсем немного об опциях для команды docker run - полный список можно найти по ссылке https://docs.docker.com/engine/reference/commandline/run/#description
-p - открываем конкретные порты через пробел - порт доступа и порт на контейнере, к примеру docker run -p 9876:80 %imagename%
-P - открываем сразу все порты;
-t - подключение к терминалу контейнера;
-i - интерактивный режим, STDIN все время будет открыт;
Обязательно посетите Docker Hub, так как там можно найти кучу интересных контейнеров с примерами их установки и доступом к Docker-файлу, это что-то вроде GitHub только для контейнеров.
Заключение
На этом всё, спасибо за внимание! Пишите в комментариях, что еще вам интересно узнать про Докер - в следующих статьях мы покроем такие темы как: создание своего собственного Докер-файла и образа, как подключить папку файловой системы с вашего хоста, интересное на Docker Hub и так далее.
В данной главе рассматриваются вопросы технической диагностики системы автоматического мониторинга ВОЛС, необходимость в которой возникает из-за сложности этой системы.
Техническое диагностирование - процесс определения технического состояния изделия с определенной точностью. Цель технического диагностирования это поддержание достаточного уровня надежности.
При наступлении отказа диагностирование предполагает обнаружение факта отказа и его локализацию. Система технического диагностирования (СТД) - совокупность средств, осуществляющих измерение количественных значений параметров (диагностических параметров ДП), анализ и обработку результатов измерений по установленным алгоритмам. Техническим средством диагностирования являются автоматические измерительные системы, рассмотренные в главе 2. Одним из основных методов решения задач диагностирования является моделирование объекта технического диагностирования и выделение взаимосвязей в этих моделях. Модель объекта - это формализованная сущность, характеризующая определенные свойства реального объекта в удобной и желательно для инженера в наглядной форме.
Существуют аналитические модели, в которых модель строится на основе уравнений, связывающих различные параметры; графоаналитические, основанные на представлении диаграмм (в частности направленных графов) прохождения сигналов; информационные модели представляют собой информационные описания в терминах энтропия, информация и т.п.
Чаще всего используемым в практических целях и наиболее наглядным являются функционально-логические модели, которые реализуются различными способами, определяемыми особенностью функциональной схемы диагностируемого изделия.
В настоящей работе применяется диагностирование, основанное на функционально-логическом моделировании и реализуемое инженерным способом. В соответствии с решаемой задачей выбирается та или иная "функция предпочтения". В данном случае решается задача поиска неисправности, для которой выбирается W4 функция предпочтения о которой ниже.
Разработка алгоритма диагностирования
Считаем, что объект диагностирования задан следующей функциональной схемой (рисунок 1).
После построения функциональной модели необходимо определить множество возможных состояний объекта, который диагностируется. Общее число состояний при N функциональных элементов при двоичных исходах проверок (1 исправно, 0 неисправно) равно при диагностировании системы 2N - 1. Предполагается, что одновременное появление двух независимых отказов маловероятно, поэтому число сочетаний из N элементов по одному, равно N. Число всех возможных различных состояний аппаратуры, которая диагностируется, одновременно с учетом отказов одного функционального - сводятся в таблицу состояний (матрицу исправностей, матрицу неисправностей и т. п.), которая используется при разработке программы (алгоритма) поиска неисправностей.
Матрица состояний строится по следующим правилам:
S0 - строка, соответствующая работоспособному состоянию;
Sj - строка, соответствующая состоянию в котором оказался j-тый элемент модели.
Например, состояние S4 = 0 означает событие, при котором отказал 4-ый четвертый элемент модели; S2 = 0- второй и т.п.). Этому событию соответствует недопустимое значение сигнала Zi, и тогда на пересечении пишется 0. Если любой другой i - й элемент также недопустимое значение Zi, то на пересечении j ой строки и Zi - ого столбца таким же образом записывается "0"; при этом, если значение параметра будет находиться в допуске, то на пересечении пишется "1". Считается, что значения всех внешних входных сигналов xi всегда будут находиться в пределах допуска, а линии связи между элементами абсолютно надежны. Если есть сомнение в надежности линии, то её принимают за функциональный элемент.
Транспонируем матрицу (таблица 1). Так как мы осуществляем построение алгоритма поиска неисправности, то первую строку S0, означающее исправное состояние исключаем. Последний столбец функция предпочтения W4, которую установили из следующих соображений.
Так как матрица заполнена нулями и единицами, то равенство некоторого ij элемента соответствует тому, отказ i-го элемента влияет на j-ый выходной параметр j-го элемента, если контролировать выходной параметр Zj можно определить, в каком именно состоянии находится i-ый элемент. Следовательно, чем больше "0" в строке Zj матрицы, тем более большое количество информации может нести этот параметр о состоянии объекта, который находится под контролем. Для этого в качестве предпочтительной функции решении данной задачи контроля работоспособности необходимо принимать функцию вида:
Где ;
- означает количество нулей в I-ой строке матрицы.
Если для объекта контроля известны вероятности состояний P(Zi):
Также заданы C(Zi) стоимости контроля параметров:
Так как строится алгоритм нахождения неисправности, то функция предпочтения будет:
где суммы означают количество нулей и единиц соответственно в I-той строке транспонированной матрицы состояний. Значения W4(Zi) для каждой строки приведены в последнем столбце транспонированной матрицы (таблица 3.2).
Последовательность решения следующая:
1) Выбираем ту строку, в которой функция предпочтения W4(Zi) минимальна, так как эта строка несет максимальное количество информации, разбивая все возможные состояния объекта на две равные части.
2) Минимально значение для 6,7,13 и 14 строк, т.е. по этому критерию они равнозначны. Для контроля выбираем строку 7. Итог контроля по этому параметру W4(Zi) разбивает матрицу на равные части W4(Z7) - первое разложение:
2.1) Эти состояния не влияют на данный выходной параметр функционального элемента;
2.2) Значения параметра не в допуске, что говорит о неисправности объекта.
3) Дальше аналогично анализируются обе получившиеся части (3-е, 4-е и последующие разложения (как показано на рисунке 6).
4) Процедура продолжается, пока множество N=14 возможных состояний объекта диагностирования не будут разделены на отдельные состояния.
Чтобы упорядочить для дальнейшего осколки введём следующее обозначение для каждого конкретного осколка:
Где m - номер разбиения;
"H" - принимает значение 1 или 0 в зависимости от состояния строки матрицы;
n - номер осколка, считая, что осколки всегда располагаются, начиная с "1".
Например, обозначение 3«0»6 значит, что это осколок при третьем разбиении для значения "0". (впрочем, "1" всегда соответствуют нечетные значения "n", а «0» - четные)
Ниже представлены результаты анализа для принятой конкретной функциональной модели на рисунке 3.
Первое разбиение по строке Z7, имеющая W7 = 0
z7, имеющая W7 = 0
В таблице 3.3. представлена матрица (осколок) после первого разбиения для результатов проверки «1», т.е. при введенных обозначениях: 1«1»1. Для второго разбиения взята строка Z11, имеющая меньшее значение функции предпочтения W4 = 1
В таблице 3.4 представлена таблица после первого разбиения с «0»,, т.е. 1«0»,1.
Дальше "заливкой" показаны строчки, выбранные для следующих разбиений.
Для первого разбиения матрицы взята строка Z11, функция предпочтения которой W4 = 1.
S8
S9
S10
S11
S12
S13
S14
W4
z8
0
1
1
1
1
1
1
5
z9
1
0
1
1
1
1
1
5
z10
1
1
0
1
1
1
1
5
z11
1
1
0
0
0
1
1
1
z12
1
1
0
0
0
1
1
1
z13
1
1
0
0
0
0
1
1
z14
1
1
0
0
0
1
0
1
Таблица 3. - 1«1»1
S1
S2
S3
S4
S5
S6
S7
W4
z1
0
1
1
1
1
1
1
5
z2
0
0
0
1
1
1
1
1
z3
1
1
0
1
1
1
1
1
z4
1
1
0
0
0
1
1
1
z5
1
1
0
0
0
1
1
3
z6
1
1
0
0
0
0
1
7
z7
1
1
0
0
0
1
0
7
Таблица 4. - 1«0»1
Матрица после второго разбиения при «1». Для 3-го разбиения взята строка Z13
Результаты третьего разбиения:
Результаты четвертого разбиения:
По результатам разбиений получаем номера ФБ для контроля:
результат третьего разбиения:
3«0»2→13;
3«1»4→11 и 12;
3«0»4→10;
3 «1»5→6 и 7;
3«0»6→5;
3 «1»7→4.
Результат четвертого разбиения:
4«0»2 → 9.
Результат пятого разбиения:
5«1»1 → 8;
5«0» →14;
5«1»15 → 2 и 3;
5«0»16 →1.
По полученным в результате анализа матрицы состояний номерам контролируемых ФБ для определения неисправного блока строим алгоритм контроля.
Алгоритм контроля
Рисунок 2. Как видно из алгоритма, максимальное количество элементарных проверок для нахождения неисправного ФБ равно 5 (в данном случае ФБ 8 и 14)
Заключение
1.На основе функционально-логической модели и инженерного способа разработан оптимальный алгоритм диагностирования гипотетической систем, которая моделирует систему автоматического контроля и мониторинга.
2. Проведен расчет и в результате получен алгоритм. Для принятой модели максимальное число элементарных испытаний равно 5.
В предыдущем материале мы рассмотрели, как работает Интернет на базовом уровне, включая взаимодействие между клиентом (вашим компьютером) и сервером (другим компьютером, который отвечает на запросы клиента о веб-сайтах).
В этой же части рассмотрим, как устроены клиент, сервер и веб-приложение, что мы можем удобно серфить в Интернете.
Модель клиент-сервер
Эта идея взаимодействия клиента и сервера по сети называется моделью «клиент-сервер». Это делает возможным просмотр веб-сайтов (например, сайт wiki.merionet.ru) и взаимодействие с веб-приложением (как Gmail).
На самом деле, модель клиент-сервер - это ни что иное, как способ описать отношения между клиентом и сервером в веб-приложении. Это детали того, как информация переходит от одного конца к другому, где картина усложняется.
Базовая конфигурация веб-приложения
Существует сотни способов настройки веб-приложения. При этом большинство из них следуют одной и той же базовой структуре: клиент, сервер, база данных.
Клиент
Клиент - это то, с чем взаимодействует пользователь. Так что «клиентский» код отвечает за большую часть того, что на самом деле видит пользователь. Это включает в себя:
Определение структуры веб-страницы
Настройка внешнего вида веб-страницы
Реализация механизма пользовательского взаимодействия (нажатие кнопок, ввод текста и т.д.)
Структура: Макет и содержимое веб-страницы определяются с помощью HTML (обычно HTML 5, если речь идет о современных веб-приложениях, но это другая история.)
HTML означает язык гипертекстовой разметки (Hypertext Markup Language). Он позволяет описать основную физическую структуру документа с помощью HTML-тэгов. Каждый HTML-тэг описывает определенный элемент документа.
Например:
Содержимое тега «<h1>» описывает заголовок.
Содержимое тега «<p>» описывает абзац.
Содержимое тега «<button>» описывает кнопку.
И так далее...
Веб-браузер использует эти HTML-тэги для определения способа отображения документа.
Look and Feel: Чтобы определить внешний вид веб-страницы, веб-разработчики используют CSS, который расшифровывается как каскадные таблицы стилей (Cascading Style Sheets). CSS - это язык, который позволяет описать стиль элементов, определенных в HTML, позволяя изменять шрифт, цвет, макет, простые анимации и другие поверхностные элементы.
Стили для указанной выше HTML-страницы можно задать следующим образом:
Взаимодействие с пользователем: Наконец, для реализации механизма взаимодействия с пользователем, на сцену выходит JavaScript.
Например, если вы хотите что-то сделать, когда пользователь нажимает кнопку, вы можете сделать что-то подобное:
Иногда взаимодействие с пользователем, может быть реализовано без необходимости обращения к вашему серверу - отсюда и термин "JavaScript на стороне клиента". Другие типы взаимодействия требуют отправки запросов на сервер для обработки.
Например, если пользователь публикует комментарий в потоке, может потребоваться сохранить этот комментарий в базе данных, чтобы весь материал был структурирован и собран в одном месте. Таким образом, вы отправляете запрос на сервер с новым комментарием и идентификатором пользователя, а сервер прослушивает эти запросы и обрабатывает их соответствующим образом.
Сервер
Сервер в веб-приложении прослушивает запросы, поступающие от клиента. При настройке HTTP-сервера он должен прослушивать конкретный номер порта. Номер порта всегда связан с IP-адресом компьютера.
Вы можете рассматривать порты как отдельные каналы на каждом компьютере, которые можно использовать для выполнения различных задач: один порт может быть использован для серфинга на wiki.merionet.ru, в то время как через другой получаете электронную почту. Это возможно, поскольку каждое из приложений (веб-браузер и клиент электронной почты) использует разные номера портов.
После настройки HTTP-сервера для прослушивания определенного порта сервер ожидает клиентские запросов, поступающие на этот порт, выполняет все действия, указанные в запросе, и отправляет все запрошенные данные через HTTP-ответ.
База данных
Базы данных – это подвалы веб-архитектуры - большинство из нас боятся туда спускаться, но они критически важны для прочного фундамента. База данных - это место для хранения информации, чтобы к ней можно было легко обращаться, управлять и обновлять.
Например, при создании сайта в социальных сетях можно использовать базу данных для хранения сведений о пользователях, публикациях и комментариях. Когда посетитель запрашивает страницу, данные, вставленные на страницу, поступают из базы данных сайта, что позволяет нам воспринимать взаимодействие пользователей в реальном времени как должное на таких сайтах, как Facebook или в таких приложениях, как Gmail.
Как масштабировать простое веб-приложение
Вышеописанная конфигурация отлично подходит для простых приложений. Но по мере роста приложения один сервер не сможет обрабатывать тысячи - если не миллионы - одновременных запросов от посетителей.
Чтобы выполнить масштабирование в соответствии с этими большими объемами, можно распределить входящий трафик между группой внутренних серверов.
Здесь все становится интересно. Имеется несколько серверов, каждый из которых имеет собственный IP-адрес. Итак, как сервер доменных имен (DNS) определяет, на какой экземпляр вашего приложения отправить трафик?
Ответ очевиден - никак. Управление всеми этими отдельными экземплярами приложения происходит через средство балансировки нагрузки.
Подсистема балансировки нагрузки действует как гаишник, который маршрутизирует клиентские запросы по серверам как можно быстрее и эффективнее, насколько это возможно.
Поскольку вы не можете транслировать IP-адреса всех экземпляров сервера, вы создаете виртуальный IP-адрес, который транслируется клиентам. Этот виртуальный IP-адрес указывает на подсистему балансировки нагрузки. Таким образом, когда DNS ищет ваш сайт, он указывает на балансировщик нагрузки. Затем подсистема балансировки нагрузки перескакивает для распределения трафика на различные внутренние серверы в реальном времени.
Возможно, вам интересно, как подсистема балансировки нагрузки узнаёт, на какой сервер следует отправлять трафик. Ответ: алгоритмы.
Один популярный алгоритм, Round Robin, включает равномерное распределение входящих запросов по ферме серверов (все доступные серверы). Вы обычно выбираете такой подход, если все ваши серверы имеют одинаковую скорость обработки и память.
С помощью другого алгоритма, Least Connections, следующий запрос отправляется на сервер с наименьшим количеством активных соединений.
Существует гораздо больше алгоритмов, которые вы можете реализовать, в зависимости от ваших потребностей.
Теперь поток трафика выглядит следующим образом:
Службы
Итак, мы решили проблему трафика, создав пулы серверов и балансировщик нагрузки для управления ими.
Но одной репликация серверов может быть недостаточно для обслуживания приложения по мере его роста. По мере добавления дополнительных функциональных возможностей в приложение необходимо поддерживать тот же монолитный сервер, пока он продолжает расти. Для решения этой проблемы нам нужен способ разобщить функциональные возможности сервера.
Здесь и появляется идея служб. Служба является просто другим сервером, за исключением того, что она взаимодействует только с другими серверами, в отличие от традиционного веб-сервера, который взаимодействует с клиентами.
Каждая служба имеет автономную единицу функциональности, такую как авторизация пользователей или предоставление функции поиска. Службы позволяют разбить один веб-сервер на несколько служб, каждая из которых выполняет отдельные функции.
Основное преимущество разделения одного сервера на множество сервисов заключается в том, что он позволяет масштабировать сервисы полностью независимо.
Другое преимущество здесь заключается в том, что он позволяет командам внутри компании работать независимо над конкретной услугой, а не иметь 10, 100 или даже 1000 инженеров, работающих на одном монолитном сервере, который быстро становится кошмаром для менеджера проекта.
Краткое примечание: эта концепция балансировщиков нагрузки и пулов внутренних серверов и служб становится очень сложной, поскольку вы масштабируете все больше и больше серверов в вашем приложении. Это особенно сложно с такими вещами, как, например, сохранение сеанса, обработка отправки нескольких запросов от клиента на один и тот же сервер в течение сеанса, развертывания решения для балансировки нагрузки. Такие продвинутые темы не будет затрагивать в данном материале.
Сети доставки контента (Conten Delivery Network – CDN)
Все вышеперечисленное отлично подходит для масштабирования трафика, но приложение все еще централизовано в одном месте. Когда ваши пользователи начинают посещать ваш сайт из других концов страны или с другого конца мира, они могут столкнуться с длительной задержкой из-за увеличенного расстояния между клиентом и сервером. Ведь речь идет о "всемирной паутине" - не о "местной соседней паутине".
Популярная тактика решения этой проблемы - использование сети доставки контента (CDN). CDN - это большая распределенная система «прокси» серверов, развернутая во многих центрах обработки данных. Прокси-сервер - это просто сервер, который действует как посредник между клиентом и сервером.
Компании с большим объемом распределенного трафика могут платить CDN-компаниям за доставку контента конечным пользователям с помощью серверов CDN. CDN имеет тысячи серверов, расположенных в стратегических географических точках по всему миру.
Давайте сравним, как веб-сайт работает с CDN и без него.
Как мы уже говорили в разделе 1, для типичного веб-сайта доменное имя URL преобразуется в IP-адрес сервера хоста.
Однако если клиент использует CDN, доменное имя URL преобразуется в IP-адрес пограничного сервера, принадлежащего CDN. Затем CDN доставляет веб-контент пользователям клиента, не затрагивая серверы клиента.
CDN может сделать это, сохраняя копии часто используемых элементов, таких как HTML, CSS, загрузки программного обеспечения и медиаобъектов с серверов клиентов.
Главная цель - расположить контент сайта как можно ближе к конечному пользователю. В итоге пользователь получает более быструю загрузку сайта.