Глава 11. Контейнеры приложений и Docker

Что это значит, содержать некое приложение? В наши дни у нас имеется достаточно хорошее понятие содержания серверов, что означает виртуализацию. Взять физическое оборудование и включить его в хост виртуализации - например, Hyper-V - а затем исполнять множество виртуальных машин поверх него в виде помещения вовнутрь таких ВМ. По существу, мы обманываем их заставляя поверить, что они являются самостоятельными сущносстями, совершенно не информируя их о том, что они совместно используют ресурсы и оборудование наряду с другими работающими на этом хосте ВМ. Одновременно с совместным применением аппаратных ресурсов мы также можем предоставлять сильные уровни изоляции между ВМ, так как нам необходимо быть уверенными, что доступ и полномочия не могут растекаться по ВМ. В особенности в случае поставщика облачных услуг, так как это сулило бы беду.

Контейнерные приложения являются той же самой идеей, но на другом уровне. Вместо создания ВМ, мы создаём контейнеры, причём намного меньшего размера. Затем мы выполняем внутри таких контейнеров приложения, а эти приложения обманываются, полагая что они работают поверх выделенного экземпляра операционной системы. Почему это важно? Давайте обсудим ряд ответов на этот вопрос.

В точности также, как мы обсуждаем расделение оборудования между ВМ, контейнерные приложения означают, что мы получаем физические фрагменты оборудования и делим их между контейнерами. Это позволяет нам исполнять множество контейнеров на одном и том же сервере - будь то сервер физический или виртуальный. Однако если брать только это само по себе, оно не предоставляет никаких преимуществ над ВМ, так как мы также просто совместно используем аппаратуру. Вот когда мы на самом деле начинаем ощущать преимущества применения контейнеров над отдельными ВМ для всех наших приложений, так это когда все наши контейнеры могут совместно использовать один и тот же образ операционной системы. Мало того, что они раскручиваются из одного и того же базового набора, что делает их чрезвычайно быстрыми для приведения новых контейнеров в рабочее состояние, это также означает, что они применяют одни и те же ресурсы ядра. Каждый экземпляр операционной системы имеет свой собственный набор процессов пользователей, причём совместное исполнение множества приложений на серверах достаточно хитроумное дело, так как эти приложения обычно имеют доступ к одним и тем же процессами имеют потенциал негативного воздействия на эти процессы. Другими словами, существует причина чтобы мы стремились раскручивать в наши дни столько серверов, чтобы предоставлять каждому приложению свой собственный сервер, чтобы они не могли причинять вред друг другу. Порой приложения не любят смешиваться. Само ядро Windows Server 2016 было расширено таким образом, чтобы оно могло обрабатывать множество копий процессов пользовательского режима.

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

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

Другой стороной изоляции является аспект её безопасности. Имеется та же самая история обо множестве виртуальных машин, исполняющихся на одном и том же хосте, в особенности в облачном окружении. Для вас желательно существование границ безопасности между такими машинами, так как по большей части вы не хотите чтобы они знали о пристутствии друг друга в каком бы то ни было виде. Вам даже желательны изоляция и разделение между такими виртуальными машинами и самой операционной системой хоста, так как вы несомненно не хотите чтобы ваш поставщик услуг общедоступных облачных услуг подсматривал изнутри за вашими ВМ. Та же самая идея применяется к контейнерам приложений. Выполняющиеся внутри контейнера приложения не видны операционной системе хоста, даже несмотря на то, что они потребляют ресурсы этой операционной системы. Контейнеры поддерживают два различных вида изоляции. Существует изоляция пространства имён, которая означает, что контейнеры ограничены своей собственной файловой системой и реестром. Затем также существует изоляция ресурса, означающая что мы можем определять какие особенные аппаратные ресурсы доступны различным контейнерам, причём они не доступны для кражи друг у друга. Короче говоря, мы будем обсуждать две различные категории контейнеров, а именно: контейнеры Windows Server и контейнеры Hyper-V. Эти два типа контейнеров выполняют изоляцию различными путями, поэтому оставайтесь с нами для получения дополнительной информации по этой теме.

Мы знаем, что контейнеры совместно используют ресурсы и раскручивваются из одного и того же базового образа, причём в то же время сохраняя свои процессы разделёнными с тем, чтобы лежащая в их основе операционная система не могла отрицательно воздействовать на такое приложение, а также чтобы это приложение не могло заполнить всю операционную систему. Но как такая изоляция обрабатывается со стороны сетевой среды? Да, контейнеры приложений используют технологию виртуалного коммутатора Hyper-V чтобы сохранять всё без искажений со стороны сетевой среды. Фактически, когда вы начинаете применять контейнеры, вы обнаружите, что каждый контейнер имеет некий уникальный назначенный ему адрес IP для сопровождения изолированности на данном уровне.

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

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

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

Гипервизор, такой как Hyper-V или VMware, предоставляет вам возможность раскручивать множество различных виртуальных машин. Столько ВМ, сколько может обрабатывать ваше оборудование. К сожалению, общее число ВМ, которое вы можете раскрутить может быть существенно ограничено из- за того, что каждая виртуальная машина исполняет целую операционную систему. Всё от самой загрузки ядра до подключаемой файловой системы и процессов, содержатся внутри всех и каждой виртуальной машины. Это также означает, что каждая ВМ уязвима на уровне атак на операционную систему, а также потребляет ещё больше ресурсов, когда вы начинаете добавлять в неё защитников, таких как антивирус. Очень просто раскручивать ВМ когда вам нужны новые серверы, однако если вы начинаете выделять каждой из своих ВМ 8 ГБ оперативной памяти, вы вскорости переполните даже самые большие серверы гипервизора.

Именно здесь врываются в действие контейнеры и сохраняют день. Поскольку контейнеры совместно используют загружаемое ядро вашей операционной системы, нет необходимости реплицировать их снова и снова, как вы это делаете с ВМ. Вы можете раскручивать контейнер за контейнером и за контейнером, и никогда не устанавливать при этом новый экземпляр своей операционной системы. Да, контейнер всё ещё имеет свои собственные сетевую среду, файловую систему и процессы, так как онb должны выполнять своё задание изоляции и предохранять и сами приложения, и имеющуюся операционную систему от перемешивания. Однако, я слышал, что наличие возможности совместно использовать такие ресурсы ядра позволяет раскручивать в четыре- шесть раз больше контейнеров на отдельном сервере в сравнении с общим числом виртуальных машин, которое вы бы могли исполнять на том же самом сервере.

Много людей полагают что контейнеры планируют заменить виртуальные машины, но это просто не так. ВМ им контейнеры полностью отличны. Поэтому если вы являетесь администратором ВМ, не беспокойтесь, что контейнеры отнимут у вас ежедневную работу. Необходимость в в полных ВМ несомненно продолжит оставаться для работы в наших центрах обработки данных, я почти уверен, что они всё ещё будут составлять основную часть нашей инфраструктуры. Однако контейнеры выполняют великое задание по разрешению полного сопротивдения между разработчиками и ИТ. Предположим, некий разработчик создаёт какое- то приложение и проверяет его безошибочную работу на своём ноутбуке. Он вручает это исключительное приложение с нулевыми проблемами ИТ парням для размещения на каком- то сервере, и оно, естественно, не работает. Это гигантская проблема и великая головная боль для каждого разработчика. Контейнеры решают эту проблему, так как его окружение работы при разработке в точности то же самое, что и окружение, в котором данное приложение собирается жить в долговременной перспективе. Вся разработка и вся работа происходят внутри некоторого контейнера!

Если существует орбатная сторона, которая будет иметься в контейнерах в сравнении с ВМ, так это гибкость. В случает сервера гипервизора мы можем просто легко раскрутить некий сревре Linux, так же как мы можем это сделать с сервером Windows, мы даже можем раскручивать их оба одновременно, причём на одной и той же платформе и без каких- либо проблем между ними. Контейнеры же, с другой стороны, так как они совместно используют ядро имеющейся операционной системы, могут работать только если они исполняются под управлением одной и той же операционной системы. Это может быть ограничительным фактором, в зависимости от того какие приложения вы ищете и что вы надеетесь осуществлять с контейнерами. Разработчики приложений полюбять наличие изоляции и стандартизации вычислительной среды, предоставляемые контейнерами, а администраторы среверов полюбят стабильность и низкое использование ресурсов которое дают контейнеры.

Другим гигантским преимуществом от использования контейнеров состоит в сплочённости, которую они создают между имеющимися командами разработчиков и операторов. Мы постоянно слышим о термине DevOps в наши дни, что является объединением процессов разработки и сопровождения, которое делает весь процесс накатки всего приложения более эффективным. Применение контейнеров намерено иметь гигантское воздействие на образ мыслей DevOps, так как разработчики теперь могут выполнять своё задание - разработку приложения - без необходимости приспособления к операционной стороне вещей. Когда приложение построено, оператор может взять такой контейнер, внутри которого находится данное приложение, и просто раскрутить его внутри своей инфраструктуры контейнеров, не заботясь о том, что данное приложение вознамерится прервать работу серверов или получить проблемы совместимости.

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

Когда Microsoft заставил людей начать тестирование и использование контейнеров, то что они обнаружили, так это что во многих местах были развёрнуты только полдному контейнеру на ВМ. Ну, это несколько глупо - пребывая в уверенности что они получают выгоды DevOps от использования подхода с контейнерами, однако при этом вы не получаете никакой выгоды от совместного применения ресурсов и малого размера контейнера. После того как они слегка покопаются в этом, они обнаруживают, что компании делают это, поскольку контейнеры естественным образомразделяют ядро. В то время как это является обязательным для исполнения контейнеров, это является проблемой для изоляции, и организации неохотно развёртывают множество контейнеров в пределах одной виртуальной машины. Итак, Microsoft создал компромисс.

Когда вы раскручиваете свои контейнеры, важно знать, что в настоящее время имеются две категории контейнеров, которые вы можете исполнять в Windows Server 2016. Все обсуждавшиеся нами до сих пор стороны контейнерных приложений применимы и к Контейнерам Windows Server, и к Контейнерам Hyper-V. Как и Контейнеры Windows Server, Контейнеры Hyper-V могут исполнять один и тот же код или образы внутри себя, и при этом сохранять их сильную изолированность, гарантирующую уверенность в том, что их важное наполнение остаётся разделённым. Принятие решения между Контейнером Windows Server или Контейнером Hyper-V будет скорее всего сжиматься до того, каким уровем безопасности вам необходимо сопровождать свои контейнеры. Давайте обсудим различия между этими двумя, чтобы вы могли лучше осознать тот выбор, перед которым вы стоите. Важно отметить, что те разработчики, которые строят приложения внутри ваших контейнеров не нуждаются в осознании или заботе о том, в каком виде контейнера данное приложении разместится. Это целиком решение ИТ, причём оно совершенно не относится к тому как данное приложение ведёт себя внутри данного контейнера или как нужно его строить.

В точности тем же самым образом, как контейнеры Linux совместно используют файлы ядра операционной системы своего хоста, Контейнеры Windows Server могут применять эти совместные ресурсы чтобы сделать такие контейнеры эффективными. Однако, это означает, что хотя хотя изоляция пространства имён, файловой системы и сетевой среды готовы к применению для сохранения всех контейнеров раздельными друг от друга, всё же существует некий потенциал для уязвимости между различными работающими в сервере контейнерами. Например, если вы были зарегистрированы в операционной системе данного хоста в вашем сервере контейнера, вы бы имели возможность просматривать список исполняющихся процессов самого контейнера. Сам контейнер не имеет возможности просматривать свой хост или прочие контейнеры и всё ещё изолирован от самого хоста различными способами, однако знание того, что сам хост имеет возможность просматривать процессы внутри имеющегося в нём контейнера, отображает для нас тот факт, что на данном уровне совместного использования имеется некоторое взаимодействие. Контейнеры Windows Server предназначены быть наиболее полезными в обстоятельствах, при которых ваш сервер хоста контейнеров и контейнеры сами по себе находятся внутри одной и той же границы доверительности (trust boundary). В большинстве случаев это означает, что Контейнеры Windows Server будут наиболее полезными для серверов, которые находятся в полном владении компании и исполняют только контейнеры, которыми владеет сама компания и которые нанаходятся в её доверительном отношении. Если вы доверяете и своему серверу хоста, и вашим контейнерам и они согласны с такими сущностями доверия друг другу, тогда развёртывание обычных Контейнеров Windows Server является наиболее эффективным вариантом применения ваших аппаратных ресурсов.

Если вы находитесь в поиске увеличения значений изолированности и усилении ограждения, именно здесь вы осуществляете набег на Контейнеры Hyper-V. Контейнеры Hyper-V больше похожи на сверхоптимизированную версию виртуальной машины. Хотя ресурся ядра всё ещё совместно используются Контейнерами Hyper-V, вследствии чего они намного более производительные нежели полные виртуальные машины, каждый контейнер Hyper-V получает свою собственную оболочку Windows, внутри которой может исполняться некий отдельный контейнер. Это означает, что у вас имеется изолированность между Контейнерами Hyper-V, которая больше равна изоляции между ВМ и всё ещё способна раскручивать новые контейнеры по желанию и причём очень быстро, так как вся контейнерная инфраструктура всё ещё готова к применению в её основании. Контейнеры Hyper-V предназначаются более полезными для инфраструктур со множеством аредаторов (multitenant), в которой вы желаете гарантировать, что никакой код или активность не имеют возможности перетекать между таким контейнером и хостом, либо между двумя различными контейнерами, которыми могут обладать две различные сущности. Всего минуту назад мы обсуждали, что операционная система хоста может наблюдать за процессами, исполняющимися внутри Контейнеров Windows Server, однако это не так в случае с Контейнерами Hyper-V. Операционная система хоста не имеет никакой информации и не имеет возможности пролезать в те службы, которое исполняются внутри таких Контейнеров Hyper-V. Эти процессы теперь являются невидимыми.

Важно знать, что вы можете изменить обычный Контейнер Windows Server так, чтобы превратить его в Контейнер Hyper-V простой командй PowerShell. Таким образом, если вы исполняете контейнер и позже осознали, что вы создали его неверно, или просто решите что другой режим лучше соответствует вашему варианту использования приложения, вы просто останавливаете этот контейнер и применяете PowerShell для его преобразования. В следующем разделе данной главы мы применим PowerShell для запуска нового контейнера, а также мы взглянем на cmdlet Set-Container для замены такого контейнера вперёд и назад между Контейнером Windows Server и Контейнером Hyper-V.

Доступность Контейнеров Hyper-V означает, что даже если у вас имеется приложение, которое должно быть строго изолировано, вам больше не нужно выделять такому приложению полную ВМ Hyper-V. Вы теперь можете раскрутить Контейнер Hyper-V, запустить нужно приложение в этом контейнере, и получить полную изоляцию для данного приложения, хотя в то же самое время продолжать совместно использовать ресурсы и предоставлять лучшую, более масштабируемую практику для такого приложения.

Все те из вас, кто имел практику работы с контейнерами уже знают, что заголовок данного раздела вводит в заблуждение. Я сделал это с определённой целью, так как вы вскоре увидите, что мы можем использовать PpowerShell в качестве своей консоли командной строки для выполнения всей работы, однако что мы в действительности совсем не используем под капотом PowerShell для исполнения нашей работы с контейнерами в настоящее время. Давайт посмотрим вместе и увидим как на самом деле просто начать применять контейнеры внутри Windows Server 2016. Первая нужная вам вещь, естественно, ваш сервер. У меня имеется только что установленный работающий Windows Server 2016. имеется пара моментов, которые мы должны исполнить на этом сервере чтобы подготовить его к работе с контейнерами.

Я хочу отметить, что данный процесс всё ещё развивается, и может продолжать развиваться на протяжении взросления Windows Server 2016. На момент написания данного текста, существует некий процесс быстрого запуска, которым мы собираемся воспользоваться, что делает процедуру вашего ознакомления с данными командами и раскруткой вашего первого контейнера достаточно простой, но даже эта процедура может измениться в ближайшем будущем.

Чтобы начать использовать контейнеры на своём сервере, имеется простое свойство, которое необходимо установить, и оно имеет название Containers. Инсталляция этого свойства устанавливает cmdlet-ы PowerShell и функции, необходимые для запуска контейнеров и управления ими на вашем сервере. Помимо этого, если вы собираетесь применять Контейнеры Hyper-V, то вам также необходимо убедится, что роль Hyper-V также была установлена на вашем сервере хостинга контейнеров. Выполнив такой обычный подход установки роли, вы, тем не менее, в конечном итоге не получите реальной возможности запуска контейнера, так как у вас нет никаких базовых образов из которых вы можете запускать новые контейнеры. Чтобы сделать наш сервер более крепким и готовым к реальному запуску некоторого образа, мы также собираемся установить нечто с наименованием Docker. Если вы не знакомы с Docker, далее в этой главе имеется раздел, который предоставит вам некоторые подробности о самом Docker. Однако для наших целей раскрутки вашего первого контейнера, вам просто нужно следовать указаниям, которые установят его для вас.

Прежде чем мы начнём, я хотел бы потратить минутку и погнаться далее петлистым кроличьим следом. На данный момент вы можете быть удивлены, но если мой сервер хостинга контейнеров должен иметь установленной роль Hyper-V, должно ли это означать, что он должен быть неким физическим сервером? Вы не можете устанавливать роль Hyper-V на виртуальную машину, так? Нет, не так. Windows Server 2016 поддерживает нечто, называемое встраиваемой виртуализацией, которая в действительности была добавлена для целей контейнеров. Как вы видите, требование физического оборудования становится в наши дни ограничительным моментом для ИТ подразделений, так как почти всё выполняется из виртуальных машин. Понятно, что компании хотели бы развёртывать контейнеры, однако они хотели бы, чтобы их серверы контейнеров были ВМ, причём со множеством контейнеров исполняющихся внутри такой ВМ. Таким образом, чтобы сделать это возможным потребовалась встроенная виртуализация. Если вы работаете под управлением гипервизора физического сервера Windows Server 2016, а виртуальная машина Windows Server 2016 находится внутри такого сервера, вы теперь можете обнаружить, что у вас имеется возможность успешно установить роль Hyper-V в такой ВМ. Я же говорю вам, что виртуальные машины были настолько популярны, что они теперь применяются для исполнения в них других виртуальных машин!

Основным ресурсом Microsoft по контейнерам является https://aka.ms/windowscontainers. Проверьте данный сайт чтобы найти самые последние практические способы и подтвердить путь установки для подготовки ваших серверов хостинга контейнеров.

Я уже установил роль Hyper-V на свой новый сервер, теперь я собираюсь установить свойство Containers воспользовавшись следующим cmdlet:

Install-WindowsFeature Containers
 	   

После установки нашего нового свойства контейнеров не забудьте перезагрузить свою систему.

Теперь, когда контейнеры готовы к работе внутри Windows, предоставляя нам основное ядро "под капотом" функциональности, нам необходим специальный набор инструментов с названием Docker для взаимодействия с такими контейнерами. Файлы Docker могут быть загружены здесь: https://download.docker.com/components/engine/windows-server/cs-1.12/docker.zip. {Прим. пер.: На момент преревода доступна версия 1.13.}

Теперь стоит отметить что в действительности нет установщика, который вам необходимо исполнить. Вместо этого раскройте полученный архив этих файлов и поместите его куда- нибудь в вашу систему, например, внутри C:\Program Files\Docker.

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

Чтобы установить путь:

[Environment]::SetEnvironmentVariable("Path", $env:Path + ";C:\Program Files\Docker", [EnvironmentVariableTarget]::Machine)
 	   

Для установки службы Docker:

Dockerd.exe –register-service
 	   

А чтобы запустить новую службу:

Start-Service docker
 	   

Теперь, когда наш Windows Server 2016 был подготовлен для того чтобы иметь возможность исполнения контейнеров, давайте запрыгнем вперёд и запустим один. Мы будем делать это из приглашения PowerShell. Прежде чем мы сможем запустить некий контейнер, на м нужно решить какой базовый образ мы собираемся применять чтобы построить этот контейнер. Вы можете применить команду docker images, чтобы просмотреть доступные в наcтоящий момент в нашей системе образы.

Да это выглядит как целый набор из ничего. У нас нет ни одного базового образа контейнера в нашей системе по умолчанию, поэтому это выглядит так, как будто нам нужно куда- то обратиться и получить его. Воспользовавшись интеграцией с Docker, который мы только что установили, мы получаем простые, лёгкие в применении команды, которые мы можем применять для вытаскивания примеров базовых образов из некоторого репозитория, о котором мы будем говорить в конце данной главы и который называется Docker Hub. Microsoft имеет репозиторий в Docker hub, который позволяет нам вытаскивать предварительно созданные образы, которые мы можем применять для запуска новых контейнеров. В качестве примера я собираюсь следовать командам, которые вытащат образ контейнера, который основан на Сервере ядра и получить установленной роль IIS:

Docker run –it –p 80:80 Microsoft/IIS cmd
 	   

Так как у меня не было данного образа в моей системе ранее, его загрузка из репозитория может потребовать нескольких минут. Когда она завершится, этот контейнер автоматически запустится и IIS будет поднят и работать в данном контейнере. Мой сервер не очень мощный и даже процесс всего лишь запуска этого контейнера потребует нескольких секунд для завершения. Но всё равно это намного быстрее чем раскрутка новой виртуальной машины внутри Диспетчера Hyper-V!

Другой способ получения базовых образов в ваш Server 2016, без автоматического запуска контейнеров, состоит в исполнении команды docker pull, которая сообщит вашей машине о необходимости вытаскивания базового образа Microsoft либо Сервера ядра, либо Нано сервера. Вот эти команды:

docker pull microsoft/windowsservercore
docker pull microsoft/nanoserver
 	   

После загрузки этих базовых образов, вы можете воспользоваться командами, подобными приведённой ниже, для раскрутки новых экземпляров Контейнеров Windows Server:

docker run –it windowsservercore cmd
 	   

Или, если вы желаете запустить Контейнер Hyper-V, вы просто добавляете один флаг в данную команду:

docker run –it –isolation=hyperv nanoserver cmd
 	   

Я выполнил некоторые из этих команд в своей системе, загрузив базовые образы Server Core - IIS и Nano Server, и теперь если я повторно выполню docker images, я увижу эти базовые образы в своей системе.

Вы можете быть удивлены, зачем нам нужно использовать команду docker чтобы делать всё это? Где cmdlet PowerShell? Это особенно сбивающий с толку вопрос, так как в ранних версиях Technical Preview Server 2016 имелись cmdlet PowerShell, при помощи которых вы могли создавать контейнеры, запускать контейнеры и взаимодействовать с контейнерами. Однако в определённый момент данного процесса, Microsoft принял решение пересмотра данной платформы, и в настоящий момент я не смог найти хорошей информации о том, будет или нет PowerShell взаимодействовать с контейнерами в будущем. Все текущие пункты документации применяют Docker в явном виде, поэтому, на текущий момент, мы делаем предположение, что управление Docker будет вашим первичным и, возможно, единственным доступным, способом взаимодействия с вашими контейнерами.

Вероятно, вы удивитесь почему мы ждали обсуждения Docker до сих пор, когда мы уже установили его и использовали соответствующие команды для взаимодействия с контейнерами. Причина, по которой я погрузился сразу в их применение и объясняю позже состоит в том, что много ИТ народу, который начнёт читать нечто про набор инструментов с названием Docker, который является open source, работающим с Linux, и так далее - мгновенно тускнеют и пропускают этот раздел в любом случае. Я знаю, сам такой. Так вы теперь можете ясно увидеть, что Docker является механизмом управления, с кторым нам нужно быть знакомыми, если мы планируем работать с контейнерами, надеюсь, ваш инерес пошёл вверх, а не растворился. Поэтому давайте скажем всего лишь несколько слов о том чем на самом деле является Docker.

Docker является проектом с открытым исходным кодом - набор инструментов, в действительности - который первоначально разрабатывался для помощи с исполнением контейнеров в операционных системах Linux. Подождите минутку, что? Слова "Linux" и "open source" в Microsoft книге! Куда катится мир? Как вы видите, Microsoft полагает, что контейнеры будут большим кушем, по праву. Я всё ещё думаю, что они вернут назад cmdlet PowerShell, которые могут применяться для создания, управления и наблюдения за контейнерами, однако я ломаю голову что нас ожидает впереди. Однако уже наметились установившиеся приверженцы интенсивно применяющие платформу Docker уже при разработке контейнеров, и Microsoft принял решение встроить в Windows Server 2016 совместимость в движком Docker прямо в саму операционную систему. В конце концов, вы можете и, скорее всего, будете в конечном итоге использовать комбинацию из команд PowerShell и инструментов Docker, но если вы заинтересованы в тесном знакомстве и применением контейнерных приложений в своих Windows Server, не забудьте установить Docker и изучить предоставляемые им расширенные возможности.

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

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

Действительная причина, по которй мы обсуждаем Docker здесь, состоит в том, что это инструментарий, который никогда ранее не применялся в операционной системе Microsoft, но всё это изменилось в Windows Server 2016. Теперь вы можете устанавливать Docker прямо на сервер хостинга контейнеров Server 2016 и применять его для создания и взаимодействия с вашими выполняющимися на этом сервере контейнерами, как вы это уже видели в приводимых ранее примерах. На самом деле, много народу может обнаружить, что инструменты Docker достаточно выразительны для того чтобы вам не нужно было использовать PowerShell при постронении новых контейнеров и могут работать исключительно в мире Docker.

мы уже выполнили некоторые команды для переноса базовых образов на сервер контейнеров Server 2016, но мы не раскручивали новй контейнер из одного из этих образов. Давайте воспользуемся командами Docker сделать именно это. Вначале мы можем взглянуть на все доступные нам базовые образы контейнеров при помощи команды docker images:

И мы можем создать новый контейнер с именем Cont6, воспользовавшись следующей командой Docker:

docker run –name Cont6 –it nanoserver cmd
 	   

Одно важное замечание, которое стоит иметь ввиду, раз мы начинаем размывать строки между Windows и Linux - демон Docker, кторый работает в Windows Server 2016 не предназначается для возможности исполнять контейнеры Linux! Это в разработке, поскольку здесь не происходит обмана виртуализации. Docker в Windows Server 2016 повторно использует ядро операционной системы хоста, в точности так же, как это делает Docker в мире Linux. Это означает, операционные системы между вашим сервером хостинга контейнеров и самими контейнерами очень нужны. Вы не можете выполнять контейнеры Windows в серверах Linux, почему бы существовала возможность исполнения контейнеров Linux поверх сервера Windows?

Когда вы работаете с контейнерами, вы строите образы контейнеров, которые применимы в любом экземпляре сервера, работающего с той же самой операционной системой хоста - это сущность того, что могут делать для вас контейнеры. Когда вы раскручиваете новые экземпляры контейнеров, вы всего лишь вытаскиваете новую копию в точности того же самого образа, который содержит всё. Такой вид мировосприятия стандартизованных образов делает хороший вклад в сообщество совместно используемых образов, так называемый репозиторий уже построенных народом образов, которые могли бы принести пользу другим. В конце концов, Docker является сообществом открытого исходного кода. Имеется ли такой совместный ресурс, который вы можете посещать чтобы перехватить файлы образов контейнеров для тестирования, или длже для выгрузки своих собственных образов, которые вы создали самостоятельно и желаете поделиться ими со всем миром? Безусловно! Причём как часть упражнений к данной главе, и вы уже начали его применять когда вытаскивали базовые образы из Microsoft. А называется он Docker Hub, и доступен по адресу http://hub.docker.com.

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

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

Именно здесь Docker Trusted Registry (Реестр доверенных Docker) может оказаться чем-то тем, что вы ищете. Реестр доверенных Docker является системой репозитория образов контейнеров, которую вы можете размещать внутри вашей сетевой среды, позади ваших собственных межсетевых экранов и систем безопасности. Это предоставляет вам систему репозитория образов контейнеров без какой- либо опасности разделить чувствительную информацию с остальным миром.

По существу два момента выносятся на общий стол вместе с контейнерами - возможность выполнения большего числа приложений на ваших серверах, чем вы это делали до сегодняшнего дня и способность простой разработки приложений некоторым стандартным способом, способом, который подготавливает их как к масштабируемости, так и к использованию в облачных решениях. Удобство контейнеров в реальном мире было значительно расширено проектом Docker. Народ в Docker является фаворитом в этом пространстве, что оказалось достаточным чтобы Microsoft принял решение включить в свой состав применение Docker - проекта с открытым исходным кодом, разработанный парнями Linux! - прямо в Windows Server 2016. Теперь мы можем использовать и движок Docker для исполнения контейнеров в наших серверах Windows, и набор инструментария Docker для управления контейнерами и манипуляций с ними внутри Windows в точности так же, как мы можем работать с контейнерами в мире Linux.

Контейнеры Linux и Контейнеры Windows Server имеют очень много общего, и во многом работают схожим образом. Если бы мы искали только Контейнеры Windows Server после выхода Windows Server 2016, я не думаю, что ажиотаж вокруг этой темы было бы столь большим, каким он имеется на сей день. Гениальная идея Microsoft по созданию дополнительной сферы контейнеров, а именно Контейнеров Hyper-V, приносит надёжный ответ на большинство вопросов по общей безопасности, которые внутренне присущи им при рассмотрении всей идеи контейнеров в целом. В наши дни все интенсивно применяют виртуальные машины, я полагаю, никто не будет отрицать этого. Если предположить, что применение контейнеров превращается в нечто, что просто реализовать и чем лего управлять, я думаю, мы на самом деле могли увидеть применение Контейнеров Hyper-V во многих местах, в которых мы на текущий момент применяем виртуальные машины Hyper-V. Это сохранит время, затраты и пространство серверов.

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