Глава 11. Контейнеры и Нано сервер

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

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

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

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

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

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

Одним из гигантских преимуществ контейнерных приложений является то, что разработчики способны собирать свои приложения внутри некоторого контейнера, запуская это на своём собственном рабочем месте! Машиной хоста для размещения контейнеров может быть Windows Server, либо это может быть рабочая станция Windows 10. {Прим. пер.: или даже macOS либо Linux!} При сборке внутри песочницы такого контейнера, разработчики будут знать, что их приложение содержит все требующиеся ему необходимые пути, части и зависимости для надлежащей работы и что оно запускается таким образом, что не требует никаких дополнительных компонентов от лежащей в основе операционной системы. Это означает, что разработчик может собирать данное приложение, убедившись что оно работает в его локальной среде и затем легко передвинув этот контейнер приложения в серверы хостинга, где оно будет раскручено и готово к промышленному применению. Такой промышленный сервер может быть даже неким ресурсом облачного решения, но само приложение это никак не затрагивает. Такая изолированность контейнера от операционной системы помогает поддерживать данное приложение стандартным образом с тем, чтобы оно обладало простой мобильностью и перемещаемостью и сберегало время и головную боль своего разработчика, так как ему не приходится сосредотачиваться на отличиях в лежащих в основе операционных системах на протяжении всего процесса разработки.

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

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

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

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

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

Данная тема вновь возвращает нас обратно к нашему обсуждению относительно Нано сервера и того почему он в частности исчез в качестве варианта установки Windows Server. Прежде чем обсуждать те цели, которые теперь обслуживает Нано сервер, давайте по- быстрому рассмотрим структуру контейнера на основе Windows. Вот некое графическое представление, позаимствованное из колоды общедоступных слайдов, которые являются частью презентации Microsoft Ignite:

Самый нижний уровень контейнера - это его базовая операционная система. При раскрутке некого контейнера вам требуется некий базовый набор кода и ядро, из которого происходит сборка. Такой базовой операционной системой может быть либо Server Core, либо Nano Server {Прим. пер.: либо Linux, например, привычный Ubuntu 16.04, и это будет тот же самый Docker внутри Windows - здесь не без волшебства! Вы теперь имеете возможность размещать контейнеры Linux поверх Windows Server 2019.}.

Следующим уровнем контейнера является уровень персонализации. Именно здесь сосредоточены те технологии, которые в конечном итоге будут расположены применяемые вашим приложением. Например, наши контейнеры могут содержать IIS для размещения некого вебсайта, PowerShell, или даже нечто подобное .NET. Все эти наборы инструментов располагаются на этом уровне.

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

Хотя Сервер ядра является великолепной операционной системой для построения небольших и действенных серверов, он всё ещё тяжеловсен по сравнению с Нано сервером. Нано настолько потрясающе отличается и настолько невероятно крошечный, что их на самом деле нельзя сравнивать. Вы скорее всего помните, что когда ранее мы устанавливали Сервер ядра, мы выдавали некий жёсткий диск порядка 6 ГБ. Хотя это и намного меньше чем версия Windows Server с Рабочим столом, задумайтесь над этим. Базовый образ Нано сервера может составлять менее 500 МБ!

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

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

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

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

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

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

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

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

Docker - это контейнерная платформа. Это означает, что она предоставляет соответствующие команды и инструменты, необходимые для выгрузки, создания, упаковки, распространения и запуска контейнеров. Docker для Windows полностью поддерживается для работы как в Windows 10, так и в Windows Server 2019. Устанавливая Docker для Windows вы получаете все те инструменты, которые требуются для начала использования контейнеров для расширения изоляции и масштабирвоания ваших контейнеров.

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

{Прим. пер.: работа с контейнерами требует переосмысления многих парадигм программирования, которыми вы пользовались при традиционной разработке приложений. Если у вас есть острый интерес к тому чтобы понять зачем они нужны и в чём причины их популярности, советуем ознакомиться с великолепным руководством по приобретению навыков работы с контейнерами Docker в нашем переводе вышедшей в феврале 2019 книги Docker для разработчиков Rails Роба Айзенберга. Не стоит пугаться указания Rails в заголовке. Даже если вы не знакомы с Rails и не собираетесь разрабатывать с его помощью приложения, это руководство снабдит вас пониманием ключевых особенностей сборки прикладных приложений со множеством пакетов программного обеспечения промежуточного уровня - баз данных, веб- серверов, средств аутентификации, служб ключ- значение, средств обмена сообщениями, балансировщиков нагрузки и т.п. - в единое целое приложение на основе контейнеров. Вооружившись пониманием того из- за чего весь сыр- бор, знакомство с Kubernetes пойдёт значительно быстрее. У вас появится цельная картина обсуждаемой предметной области, которую может быть сложно уловить если начинать знакомство сразу с этой книги, практически, претендующей на роль монографии.}

{Прим. пер.: одной из самых необычных сторон контейнеров является их уровень абстракции относительно операционной системы под которой они исполняются. Это, естественно, требует больших усилий от самих разработчиков операционных систем, но в конечном итоге приводит к тому, что очень примечательно отметил с своей вышедшей в октябре 2018 автор книги Профессиональный SQL Server поверх Linux, Боб Вордс, приведя свой диалог: "Я вспоминаю как не так давно спросил своего коллегу, Трэвиса Райта, одного из ключевых руководителей программ по выпуску SQL Server Linux, относительно поддержки SQL Server для контейнеров Windows. Его первый ответ озадачил меня. Он сказал: 'Боб, почему это тебя волнует?' Его мысль состояла в том, что было бы неплохо попасть в тот мир, в котором основное внимание уделяется контейнеру базы данных, в том числе SQl Server, саму базу данных и все фрагменты зависимостей вместо того чтобы беспокоиться о самой операционной системе в таком образе контейнера. Я никогда не думал об этом таким образом, и скорее всего мы пока не готовы к этому, но его идея очевидна. Это одна из перспектив контейнеров.". Конкретно это обсуждение касалось именно баз данных, но в большой степени относится и к прочему программному обеспечению промежуточного уровня, на основе которого и собираются в конечном счёте приложения в контейнерах.}

Имеется некое важное обновление, которое находится в продолжающейся стадии разработки что касается возможностей, которыми обладает Windows Server 2019 для взаимодействия с различными типами контейнеров. Ранее в Сервере 2016 сервер размещения контейнеров Windows мог исполнять только контейнеры на основе Windows, так как контейнеры Windows Server разделяли своё ядро с самой операционной системой хоста, поэтому не было способа которым вы бы могли раскручивать некий контейнер Linux в хосте Windows. {Прим. пер.: не совсем так, имелась возможность устанавливать Docker для Windows, который как и Docker для macOS, применял возможности имеющегося гипервизора хоста для запуска ядра Linux подробнее.... Впрочем, никто не отменял эту способность самого Docker с поддержкой Linux со стороны какого- то гипервизора, но в таком случае у вас будут исполняться только контейнеры на основе ядра Linux (MobyVM).}

Времена меняются, и теперь у нас имеется несколько созидательных новых способностей в Server 2019 для отработки таких ситуаций как контейнеры Linux. Хотя эти свойства всё ещё шлифуются, существуют некие новые возможности, именуемые как Moby VM и LCOW, которые позволят контейнерам Linux запускаться в неком хосте контейнеров Windows Server, даже исполняясь бок о бок с контейнерами Windows!

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

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

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

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

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

И именно в таком случае стоит рассмотреть нечто подобное Docker Trusted Registry. Доверенный реестр Docker является некой системой репозитория образов контейнеров, которая аналогична Docker Hub, но при этом это нечто что вы можете содержать внутри своей собственной сетевой среды, за вашими собственными межсетевыми экранами и системами безопасности. Это предоставляет вам некую систему репозитория образов контейнеров без какого бы то ни было риска отпустить в совместное использование со всем остальным миром чувствительную для вас информацию.

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

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

Microsoft осознал его популярность и предпринял шаги для того чтобы гарантировать полную поддержку Kubernetes в Windows Server 2019.

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

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

Существует множество подвижных частей, которые работают совместно чтобы превращать в реальность контейнеры в вашей среде, но на самом деле всё не так уж и сложно чтобы начать с ними работать. Давайте пройдёмся по начальной настройке для превращения Windows Server 2019 в мега- машину исполнения контейнеров.

Общий объём работы, который вам предстоит здесь выполнить зависит от того желаете ли вы запускать контейнеры Windows Server, Hyper-V контейнеры, или оба типа. Самое первое свойство, которое вам надлежит проверить на предмет установки это Containers, которое можно установить либо при помощи ссылки Add roles and features внутри Диспетчера сервера (Server Manager), либо вызвав следующую команду PowerShell:

Add-WindowsFeature Containers
		

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

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

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

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

именно в этот момент становится важной регистрационная запись в Docker Hub. Если вы работаете через неё чтобы проверять контейнеры на своём собственном рабочем месте и вам нужно установить Рабочее место Docker для Windows в своём клиенте Win10, самый простой способ состоит в посещении Docker Hub, регистрации в нём и поиске требуемого программного обеспечения клиента Docker. Вот ссылка на это программное обеспечение (именно этот инструментарий требуется вам если вы выполняете установку в Windows 10).

Тем не менее, поскольку я нахожусь в Windows Server 2019, моя лицензия на сервер также содержит лицензию на Docker Enterprise, который может быть вытащен и запущен без необходимости посещения Docker Hub. Если я открою некое поднятое приглашение PowerShell и запущу приводимые ниже две команды, и мой сервер отыщет и вытянет Docker Enterprise, а затем установит его в моём сервере:

Install-Module -Name DockerMsftProvider -Repository PSGallery -Force
Install-Package -Name docker -ProviderName DockerMsftProvider -Force -RequiredVersion 18.03
		

После завершения установки пакета в вашем сервере теперь настроен в виде службы Docker, но эту службу требуется запустить при помощи такой команды:

Start-Service docker
		

Команды Docker

После того как Docker установлен в вашей системе, работаете ли вы в Windows Server 2019, либо в машине Windows 10, у вас в машине теперь имеется механизм Docker (Docker Engine) и он готов получать некие команды для начала работы с контейнерами. Если и есть слово которое стоит запомнить при работе с контейнерами, это слово Docker. Это потому, что все команды, которые вы вызываете для взаимодействия с контейнерами будут начинаться с этого слова docker. {Прим. пер.: ну, если учесть что с него же начинается и docker-compose, то да.}. Давайте рассмотрим некоторые наиболее употребимые команды, с которыми вы будете работать.

docker --help

Это некий вид подобный вызову docker /?, как если бы это была реальная команда. Эта функция help для Docker выработает некий список всех доступных для запуска команд docker. Это хорошая точка старта для вашего начала.

docker images

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

docker search

Применение данной функции search позволит вам отыскать имеющиеся репозитории контейнеров (подобные Docker Hub) для базовых образов контейнеров, которые вы можете пожелать использовать в своей среде. Например, чтобы выполнить поиск и найти образы, предоставляемые изнутри репозитория Microsoft Docker Hub, вызовите следующее:

docker search microsoft
		

docker pull

Для вытаскивания к себе образов контейнеров из доступных в реальном режиме репозиториев, мы можем применять docker pull. Существует множество репозиториев из которых вы можете получать образы контейнеров. Чаще всего мы будем работать с образами Docker Hub, из которого мы вскорости и вытащим образ некого контейнера. Тем не менее, существуют и прочие репозитории из которых вы можете получать образы контейнеров, такие как общедоступный реестр контейнеров Microsoft, имеющий название MCR.

Вот некие образцы команд docker pull, которые показывают как вытаскивать образы контейнеров из Docker Hub, а также из MCR:

docker pull Microsoft\nanoserver
docker pull Microsoft\windowsservercore
docker image pull mcr.microsoft.com/windows/servercore:1809
docker image pull mcr.microsoft.com/windows/nanoserver:1809
		

docker run

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

docker run -it --rm Microsoft\windowsservercore:ltsc2019
		

В нашей предыдущей команде переключатель -it создаёт некую оболочку из которой мы взаимодействуем с контейнером, что полезно при построении и проверке контейнеров, которые были на 100% готовы для обслуживания приложений, --rm является неким переключателем очистки, означающим что после выхода из данного конкретного контейнера сам этот контейнер и его локальная файловая система будут автоматически уничтожены. {Прим. пер.: на самом деле -it это комбинация двух переключателей -i и -t в нашем переводе вы можете подробнее ознакомиться с запуском приложений в контейнере.}

docker ps -a

Когда вы хотите просмотреть все запущенные в настоящее время в вашей системе контейнеры, вы применяете docker ps.

docker info

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

Самая первая команда, которую мы запустим в своём вновь созданном хосте контейнера это docker images, которая отобразит нам все те контейнеры, которые в настоящее время находятся в нашей системе; их у нас нет:

Естественно, ещё пока нет никаких образов контейнеров, поскольку мы их пока не выгружали. Давайте выудим парочку, чтобы было что попробовать. Существует некий образец файла образа контейнера, предоставляемого командой .NET, который показывает возможности приложения .NET внутри некого контейнера Нано сервера - это звучит как некий забавный способ для начала проверки того что я могу успешно исполнять контейнеры в этом новом сервере хостинга. Для начала мы можем воспользоваться docker search чтобы убедиться что текущие образы контейнеров находятся внутри репозитория Microsoft Docker Hub. После того как мы отыщем тот образ, который мы желаем выгрузить, мы применим docker pull для его выгрузки в свой сервер:

docker search microsoft
docker image pull microsoft/nanoserver
		

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

docker image pull microsoft/dotnet-samples:dotnetapp-nanoserver-1809
		

После того как выгрузки завершатся, запустите ещё раз docker images, чтобы отобразить нам теперь доступные новые образы контейнеров Нано сервера и образца .NET:

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

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

docker run microsoft/dotnet-samples:dotnetapp-nanoserver-1809
		

Данный контейнер запустится и исполнит содержащийся в нём код и мы обнаружим некий весёлый вывод:

Этот котейнер демонстрирует, что все необходимые для исполнения данного приложения .NET компоненты содержатся внутри данного контейнера. Этот контейнер основан на Нано сервере, что означает что он имеет невообразимо малый отпечаток. На самом деле, оглядываясь на несколько страниц назад, когда мы исполнили самую последнюю команду Docker, я смог увидеть, что этот образ контейнера составляет всего 417 МБ! Какая экономия ресурсов по сравнению с запуском этого приложения в обычном веб сервере IIS!

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

{Прим. пер.: изложенный в данной главе материал может не дать вам возможности ощутить все прелести работы с контейнерами и слишком краток для того чтобы послужить руководством к весьма необычной практике работы с ними. Рекомендуем ознакомиться с нашим переводом вышедшей в феврале 2019 книги Роба Айзенберга Docker для разработчиков Rails. Пусть вас не смущает слово Rails, вы вольны заменить его на .NET, что не изменит основы: изложенных в этой великолепной книге практических приёмов построения контейнерного приложения, в том числе составляемого из нескольких контейнеров. Ознакомитесь с пропущенным в данной главе инструментарием Compose, как раз и служащим таким целям. Помимо собственно практических приёмов работы с контейнерами вы, например, ознакомитесь с принципами организации их взаимодействия, продвижением в промышленной применение и многим другим вещам из этой новой захватывающей технологии.}

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

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

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