В своей практике каждый начинающий и опытный IT-специалист сталкивался с необходимостью подготовить среду запуска для какого-то определённого приложения или сервиса. И прежде, чем эта среда заработает в штатном режиме обычно приходится знатно потанцевать с бубном устанавливая все необходимые для работы зависимости. Так для того, чтобы поднять Nginx, нужно сначала развернуть Linux, установить туда пакетный менеджер Nginx, затем поставить SystemD сервис, чтобы он работал на постоянной основе, открыть порты и напоследок останется только грустно посмотреть на часы.

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

Бессмысленно, бесполезно и просто уныло. А значит нам нужно каким-то образом оптимизировать данную процедуру.

Zip File, мамкины хаЦкеры. Вы на канале самого душного IT-спеца всея интернета. Меня зовут Денчик, и я тот самый сын подруги вашей мамули, который реально шарит за технологии. 

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

Узнаем какие проблемы своим появлением вызвала контейнеризация и какую боль она закрывает. Короче скучно точно не будет, поэтому устраивайтесь по удобней и погнали учиться.

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

Реально ли IT-специалисту переехать в Великобританию без работы, образования и знания английского языка? Ответ: да!

Виза «ГлОбал ТЕлент» не требует наличия оффера, открытия бизнеса, высшего образования и углубленного знания английского.

Эта виза имеет срок действия до 5 лет и позволяет вам работать в любой компании, фрилансить, открывать свой бизнес, релоцировать семью, а также претендовать на получение паспорта!

Все, что нужно для получения такой визы - показать свои достижения в сфере IT. Это самый надежный способ иммиграции в 2024, и поэтому «ГлОбал ТЕлент» открыла путь в Великобританию уже для десятков тысяч IT-спецов.

Срок получения визы составляет 4-5 месяцев. А это, на минуточку, рекордный срок для получения ВНЖ на данный момент. И если вы ищите максимально быстрый способ для релокации, то этот вариант точно для вас.

Компания «РелокОд» работает с «ГлОбал ТЕлент» более трех лет. С помощью «РелокОд» в Великобританию смогли переехать 300 человек, а процент одобрений по их кейсам составляет аж 90%.

Так что если ты IT-специалист и хочешь переехать в Великобританию, то приходи к «РелокОд» на бесплатную консультацию.

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

Все контакты найдёшь в описании к этому ролику. Чекай скорей и повышай свои шансы на переезд вместе с компанией «РелокОд».

Аппаратная виртуализация и внешние сервисы

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

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

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

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

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

Полностью развёрнутая инфраструктура на базе гостевой операционной системы называется виртуальной машиной. В рамках данного видео мы подробно рассмотрим технологию аппаратной виртуализации и контейнеризацию.

Аппаратная виртуализация реализуется благодаря различным технологиям. Это технологии VirtualBox, VmWare и Hyper-V от вендера Microsoft.

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

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

К гипервизору второго типа относятся решения, которые запускаются на базе хостовой операционной системы и являются сугубо программными решениями.

Это наверняка знакомые вам Virtual Box от Oracle, VMWare Workstation и Parallels Desktop, если речь заходит о MacOS. Такие решения позволяют на базе хостовой операционной системы организовать полноценное решение для поднятия гостевых операционных систем.

В гостевой операционной системе мы можем развернуть абсолютно любое решение и задействовать его для реализации наших задач. Однако важно помнить и о проблемах аппаратной виртуализации.

Их собственно у нас всего две. Первая – это необходимость наличия команды, которая будет функционировать в качестве специалистов постоянно поддерживающих ресурсы.

А вторая – необходимость в предварительной установке и настройке этой истории. В качестве первичного решения проблем были предложены VDS Virtual Dedicated Server и VPS Virtual Private Server.

Данные серверы реализовываются удалённо в рамках облачной инфраструктуры. Это позволяет перенести часть задач на ответственных за железную составляющую и просто использовать удалённо ресурсы для своих нужд.

Само собой это подразумевает определённую плату. Однако за счёт удобства такой подход пользуется значительной популярностью. Ведь используя ресурсы облачных провайдеров мы платим только за фактическое потребление.

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

Ибо в программном обеспечении на сервере, который находится в чужом ЦОД могут быть уязвимости. Также стоит помнить о том, что отдавая услугу на аутсорс мы рискуем потерять данные из-за несоблюдения договора о соблюдении качества услуг.

В таком случае мы получим материальную компенсацию, однако часть данных возможно будет утеряна безвозвратно. Да, конечно, все ЦОДы сейчас проектируются по принципам отказоустойчивости, но ситуацию форс-мажора никогда нельзя списывать со счетов.

Контейнеризация

Контейнеризация – это упаковка всех необходимых зависимостей в единый образ с минимальным набором окружения и среды.

В рамках среды запуска лучше всего использовать операционную систему Linux, т.к. большинство контейнеров работает на базе данной операционной системы.

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

Данный момент реализуется за счёт технологии контейнеризации. И вся эта история может быть запущена только на линуксовой операционной системе c с соответствующим ядром.

Однако есть специальные обёртки, которые позволяют запускать ядро хостовой операционной системы Linux на хостовой операционной системе Windows или MacOS.

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

При этом будет задействован минимальный набор памяти в отличие от гостевой операционной системы на примере виртуализации. Для лучшего понимания давайте рассмотрим схему отличия контейнеризации от виртуализации.

Во втором случае применяется хостовая операционная система или инфраструктурный гипервизор для поднятия гостевых ОС. С точки зрения запуска на них приложений ресурсы задействуются не оптимально.

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

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

Ведь у нас есть и инфраструктурные задачи, которые должны быть реализованы. Допустим надо поднимать серверы отвечающие за использование домена, которые могут функционировать только на Windows.

Это значит что инфраструктура должна быть комбинирована. И в части разработки используется вариант с контейнерами, а для инфраструктурных задач применяют виртуализацию.

На сегодняшний день самой популярной системой контейнеризации является Docker. Его интерфейс очень удобен, а открытая инфраструктура Docker Hub позволяет скачать необходимый нам сервис.

Также Docker является кросс-платформенным и может быть запущен на MacOS или Windows. Перейдя на Docker Hub можно увидеть большое количество образов, как для разработки, так и для инфраструктурных задач и задач безопасности.

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

Основная идея контейнеризации и открытой инфраструктуры Docker заключается в возможности быстрого развертывания контейнеров для задач разработки, тестирования, безопасности и промышленной эксплуатации.

Общая архитектура развёртывания Docker образа подразумевает наличие 3 сущностей. Первая сущность – это клиент, который имеет программный интерфейс для запуска всех необходимых команд и контейнеров.

Вторая сущность – это Docker хост. Docker Хост может быть, как на сервере, так и на хостовой операционной системе. Реализацией же занимается некий Docker Demon. Он же Докер служба, которая преобразует наш образ в контейнер.

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

Для того, чтобы развернуть нужный нам контейнер мы обращаемся в Registry (реджистри). В нашем случае реджистри это и есть Docker Hub с которого мы можем скачать тот или иной образ, развернуть его в нашей инфраструктуре или на нашем хосте.

Предварительно мы его сохраняем в локальном репозитории наших имеджей, которых хранится на хосте на котором поднят Докер. Данный репозиторий так и называется «локальный Докер репозиторий».

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

Например, есть у вас на жёстком диске файл notepad.exe. Это образ или инструкция которая описывает, как приложению запускаться. Т.е. что нужно включить, какие службы импортировать, что откуда взять и т.д.

А само работающее приложение используемое процесс это контейнер. С интерфейсом пользователя, с возможностью ввода информации посредством клавиш и прочими прелестями оконечного приложения.

На базе одного образа можно создать сколько угодно контейнеров. Однако образ никак нельзя изменить в процессе функционирования контейнера. Основная файловая система отвечающая за функционирование всех утилит в образе неизменна.

Можно написать или удалить файлы, но изменить базовые компоненты образа невозможно. По сути это как раньше были CD и DVD-R диски не имеющие возможность перезаписи после полного заполнения.

Перед запуском контейнера его сначала нужно создать. После запуска его можно остановить и удалить его из файловой системы и хранилища образов. Для реализации всех этих манипуляций используется программный интерфейс Docker.

Причём каждая манипуляция осуществляется с помощью одной короткой команды. Также стоит отметить, что образ состоит из 2 частей. Первая часть это некий снапшот системы, который необходим для работы самого контейнера.

Вторая часть – это команда для запуска на базе которой запускается контейнер. Хорошим тоном является запуск контейнера решающего какую-то одну конкретную задачу.

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

Мы можем запускать команды, которые ожидают выполнения тех или иных действий. Или запускать непрерывные команды, как например в случае с реализацией веб-сервера.

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

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

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

И указывая название того или иного образа Image скачиваем в локальное хранилище данный образ. Далее на базе команды Docker Create мы можем создать из образа нужный контейнер прописав соответствующие флаги.

Создав контейнер он будет ожидать с нашей стороны запуска. Для этого мы должны прописать Docker контейнер старт или Докер контейнер стоп для остановки контейнера.

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

Айди тоже генерируется автоматически на базе SHA 256 и мы никак не можем управлять его присвоением. Для обращения к контейнеру можно использовать как первый, так и второй показатель.

Если обобщить сказанное, то сценарий запуска контейнера следующий. Сначала мы скачиваем образ в локальное хранилище, далее на базе образа мы запускаем контейнер, контейнер начинает функционировать исполняя задачу и завершает свою работу в случае, если не должен функционировать непрерывно.

Возвращаясь к показанной ранее схеме видим, что прописав команду Docker Pull мы отправляем запрос в публичный Registry Докера. Запускаем образ предварительно его скачав и создаём из него контейнер.

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

Используя команду Docker Run мы можем в одну команду скачать образ и запустить его как контейнер не используя Docker Start, Create и Pull. Используя команду Run и запустив на её базе контейнер мы не попадём внутрь контейнера и не сможем выполнять внутри контейнера различные команды.

Для того, чтобы попасть в терминал контейнера необходимо прописать флаг –it. По дефолту откроется Shell, но мы можем управлять оболочкой дописав в конце команды bin/bash или bin/sh.

Прописав флаг name мы дадим имя контейнеру, делать это нужно всегда, т.к. работать с рандомным именем контейнера не очень удобно.

Для возможности быстрого просмотра контейнеров мы можем использовать утилиту ls и флаг all для отображения всех наших образов или контейнеров. В частности Docker image ls all покажет все имэджи, которые хранятся в локальном репозитории.

А команда Docker контейнер ls, покажет все контейнеры, которые запущены в данный момент. Для отображения всех незапущенных необходимо добавить флаг all.

Дополнительные команды можно найти воспользовавшись справкой доступной по флагу help.

Помимо прочего во время запуска контейнера можно применять различные конфигурации. В частности это касается переменных среды, которые мы передаём в качестве флага при запуске контейнеров.

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

Также у нас есть возможность передать Volume. Что означает проброс нашей файловой системы извне, т.е. из хостовой операционной системы во внутрь контейнера.

Благодаря этому мы можем содержать файлы, которые находятся внутри контейнера в нашей хостовой операционной системе и не бояться после удаления контейнера потерять файлы.

Что касается переменных среды. Данные переменные задаются разработчиками на этапе создания контейнера. Ну и само собой это прописано на сайте докер-хаба.

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

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

Переменные окружения обозначаются флагом «Е». Указывая его мы можем передать энваермент переменные, которые базово заданы разработчиками на сайте докер-хаба образа-контейнера.

Для сервисов требующих непрерывной функциональности аля ЭнДжеНеикс есть способ запуститься не занимая консоль. Нужно лишь воспользоваться флагом –D.

Для переноса строк при прописывании команды для запуска контейнеров мы можем использовать слеш. А для биндинга портов и передачи трафика извне в контейнер мы можем использовать флаг –P.

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

Тут стоит помнить, что Docker функционирует на едином сетевой интерфейсе и контейнеры внутри Докера запросто могут общаться между собой без порт-биндинга.

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

Команда exec позволяет перейти внутрь контейнера. В том числе в интерактивном режиме. Для этого достаточно указать флаг –it. Он также работает и с командой docker container run.

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

Использование Вольюмс по большей части помогает нам сохранить данные во вне контейнера, потому что во время падения контейнера есть риск их потери.

Для создания Вольюма используется флаг –V. Изначально мы указываем директорию, которую мы хотим пробросить во внутрь контейнера, а далее ту что хотим использовать снаружи.

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

В случае указания рид-онли мы не сможем получить доступ на запись внутри контейнера. Их получится только прочесть.

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

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

Познакомились с инструментарием для контейнеризации и его программным интерфейсом, а также узнали о принципах сборки контейнеров на примере Docker.

В следующем сюжете мы продолжим изучение данной темы и рассмотрим средство многоконтейнерной сборки Docker Compose и механизмы управления ресурсами на примере Namespaces (НеймСпейсис) и Cgroups (СиГроупс).

Так что обязательно подпишитесь, чтобы не пропустить. И лайк прожмите если понравилось видео. Ну а я с вами прощаюсь на этой ноте. До новых встреч, мои кайфные друже. Всем пока.