Глава 8. Сервер ядра

Зачем я всё же начинаю говорить об Сервере ядра? Разве его не бло ещё начиная с 2008? Да, именно поэтому я и говорю об этом. В качестве варианта операционной системы Windows Server Сервер ядра присутствует с некоторых пор, однако очевидно, что многие администраторы боятся доверять ему. Я работал во многих различных компаниях в большом разнообразии сфер деятельности. Все они имеют один большой общий знаменатель - они используют большое число Windows Server, однако все эти Windows Server работают с полным GUI (С практикой рабочего стола). Слышали ли они про Сервер ядра? Естественно. Проверяли ли они его у себя в лаборатории? Иногда. Все они склонны иметь слегка различный уровень опыта с Сервером ядра, однако крайне редко можно найти хотя бы один в промышленном применении. Может быть я просто разговаривал не с теми людьми, но я вынужден предположить, что большинство из нас, включая меня самого, нуждаемся в том, чтобы начать применение Сервера ядра на более постоянной основе.

Зачем нам нужно начинать использовать Сервер ядра? Потому что освобождённые от GUI сервера являются нашим будущим, говорит Microsoft. Можете ли вы поверить, что в предварительных просмотрах Windows Server 2019 варианта Практики с рабочим столом (Desktop Experience) даже не было в них? Вы не могли работать в полной GUI оболочке рабочего стола в Server 2019, даже если бы захотели, за исключением квази-, мини- оболочки, которую можно прилепить поверх Сервера ядра. Microsoft получил так много шумихи по этому поводу, что полная опция Практики с рабочим столом (Desktop Experience) была добавлена обратно в одной из очередных массовых рассылок Технического предварительного просмотра. Но вы всё ещё можете заметить, что Сервер ядра является вариантом по умолчанию при установке данной операционной системы. Помните, когда мы в самом начале нашей книги быстро просматривали действительную установку Server 2019? Вариантом по умолчанию вовсе был не вариант Практики с рабочим столом (Desktop Experience), а именно, самой верхней опцией в приведённом ниже снимке экрана был вариант для установки Сервера ядра, управляемого из командной строки:

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

Существуют и другие очевидные преимущества исполнения всех ваших серверов в качестве такой лимитированной, ограниченной версии. Сервер ядра хвалится уменьшением пространства дисковых устройств, уменьшением потребления оперативной памяти, а также уменьшением поверхности для атак по сравнению с обычным, полностью надутым сервером. Теперь вы можете видеть почему я сделал вынужденное тяжёлое замечание, минуту назад, что мы все должны начинать чувствовать себя более уверенно с Сервером ядра! На самом деле, давайте взглянем на такое уменьшение отпечатка в памяти. Некий базовый Server 2019 Standard с исполнением Практики рабочего стола потребляет порядка 10 ГБ дискового пространства; я только что проверил это, посмотрев на свойтсва своего файла виртуального жёсткого диска, используемого моим сервером CA1. CA1 представляет собой некий стандартный Windows Server 2019, исполняемый с полной Практикой Рабочего стола. Теперь я только что завершил исполнение у3становки своей первой операционной системы Сервера ядра и мы можем обнаружить в своём следующем снимке экрана, что тот файл VHDX, который применяется этой новой виртуальной машиной составляет лишь 5.8 ГБ, 40% уменшение пространства:

Существует очень важное замечание которое я бы хотел здесь отметить. Те, кто работал с Сервером ядра в Windows Server 2012 R2, знают, что у нас была возможность изменения сервера на лету. Я здесь имею в виду то, что если вы создаёте новый сервер как обладающий полной опцией Практики с рабочим столом (Desktop Experience), позже вы можете изменить его на Сервер ядра. Обратный подход был в точности так же возможен, вы могла взять Сервер ядра и перебросиь его в полной Практикой рабочего стола.

Больше это не так! Такая возможность перемещения сервера назад и вперёд между платформами была удалена/ затёрта/ уничтожена/ обнулена. Я повторяю, это больше не возможно. Поэтому тщательно планируйте с текущего момента свою установку операционной системы. Если вы установите некий Сервер ядра, этот пацан собирается навсегда оставаться Сервером ядра на протяжении всей своей жизни. {Прим. пер.: в рецепте Переключение между Сервером ядра и Снабжённым рабочим столом?, доступного в нашем переводе Книги рецептов Windows Server 2016 Джордана Краузе, приводятся последовательности действий, которые могут вам помочь обнаружить такую возможность, если он всё- таки вернётся в Windows Server 2016 в последующих выпусках.}

После выполнения своей первой установки Сервера ядра, вам будет предстален такой блокированный экран:

Это на самом деле окно приглашения Командной строки, которое сообщает Нажмите Ctrl-Alt-Del для разблокировки? Да, да, это так. Обычно это вызывает некий смех про себя, когда некий администратор видит это впервые. Я знаю, это относится и ко мне, в любом случае. Это слегка напоминает мне то время, когда мы применяли для кодированя игр если/ то свои калькляторы TI-83 в процессе обучения в старших математических классах. Нажмите Ctrl + Alt + Del и вы получите приглашение изменить пароль администратора в этом первом входе, в точности так же, как в случае с полной GUI версией Windows Server. За исключением того, конечно, что вы делаете это в окне приглашения Командной строки используя только клавиатуру. Когда вы официально зарегистрируетесь в своём сервере, вы обнаружите себя находящимся в обычном приглашении C:\Windows\system32\cmd.exe с мигающим курсором в ожидании инструкций:

Занимательно, что окно приглашения Командной строки не окупирует весь экран, совершенно очевидно, что имеется чёрный фон поверх которого взгромоздился этот cmd.exe. Я всего лишь нашёл это интересным, потому что вы можете сказать, что операционная система Ядра сама по себе является чем- то другим чем приглашение Командной строки и что cmd.exe всего лишь автоматически запускающееся приложение. Вы даже можете воспользоваться своеё мышью здесь и изменить размер или переместить это окно Командной строки. Я буду удивлён, если и когда это будет заменено на приглашение PowerShell по умолчанию и если оно будет занимать весь экран в последующих версиях.

Ещё более интересно и приятно узнать, что вы можете запускать некоторые реальные GUI- подобные приложения из этого приглашения. Например, вы можете открыть Записную книжку (Notepad) и воспользоваться ею, причём применяя как клавиатуру, так и мышь, в точности как если бы это происходило в любой версии Windows. Если у вас имеется открытая Записная книжка, созлайте некую запись и сохраните её; вы можете видеть, что на самом деле имеется реальная файловая структура и относительно нормально выглядящая система папок. Так что в отличие от некоторой формы чёрной магии, Сервер ядра в действительности является самой настоящей операционной системой, обёрнутой в более или менее безопасный пакет:

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

Что является первым делом, которое мы обычно выполняем на новых серверах? Конечно, присваиваем ему некий IP адрес. Без связи с сетью мы ничего больше не сможем делать с этим сервером. Вы можете назначить информацию IP адреса для NIC применив PowerShell на любом новом Windows Server, однако большинство из нас не имеют такой привычки. Так как мы не можем просто открыть Панель управления (Control Panel) и войти в Центр сетевой среды и совместных ресурсов (Network and Sharing Center), как мы это можем делать изнутри своего Снабжённого рабочим местом GUI Windows Server, где мы начинаем делать сетевые настройки такого нового Сервера ядра?

Применение cmdlet для управления адресами IP

Здесь присутствуют cmdlet, которые вы можете использовать для просмотра и манипулирования настройками IP адреса изнутри PowerShell. Опять же, те же самые cmdlet могут применяться в версии Windows Server с полным GUI или из Сервера ядра.

В настоящий момент мы работаем с Сервером ядра, в котором у нас имеется доступным для нас только интерфейс командной строки, поэтому данные приводимые ниже cmdlet-ы существенны для подключения к сети нашего нового сервера:

Давайте быстро пройдём по настройке статического IP адреса на моём новом экземпляре Сервера ядра чтобы убедиться, что всё это работает. Я хочу назначить IP адрес 10.10.10.12 этому новому серверу, однако вначале мне нужно найти для какого номера идентификатора интерфейса NIC он должен быть назначен. Вывод Get-NetIPInterface сообщает нам, что тот ifIndex, которым я интересуюсь, имеет номер 4:

Теперь, когда мне известен номер интерфейса, давайте построим команду, которая назначит новые установки IP адреса имеющемуся NIC. Я собираюсь применить одну команду для назначения IP адреса, префикса маски подсети и шлюза по умолчанию. Я применю вторую команду чтобы назначит адреса DNS сервера:

New-NetIPAddress –InterfaceIndex 4 –IPAddress 10.10.10.12 –PrefixLength 24 –DefaultGateway 10.10.10.1
Set-DNSClientServerAddress –InterfaceIndex 4 –ServerAddresses 10.10.10.10,10.10.10.11
 	   

Теперь, все эти настройки должны быть готовы к работе в данном NIC. Давайте повторно проверим это при помощи cmdlet Get-NetIPConfiguration. В качестве альтернативы вы можете воспользоваться старой доброй ipconfig для проверки данных настроек, однако какая в этом радость?

Установка имени хоста сервера

Теперь, когда у нас имеется связь с сетевой средой, хорошим следующим шагом будет настройка имени хоста нашего сервера и его подключение к домену. Первейшее из первых, давайте посмотрим на текущее имя данного сервера и изменим его на нечто отвечающее нашим стандартам. Когда вы заново установили Windows, он самостоятельно получает автоматическое имя хоста для данного сервера. Вы можете ознакомиться с текущим именем хоста просто набрав hostname и нажав Enter:

Чтобы изменить имя хоста своего сервера, нам нужно воспользоваться PowerShell. Перейдите в приглашение PowerShell если вы ещё не там и всё что вам нужно сделать, это применть cmdletRename-Computer чтобы установить новое имя хоста. Я решил присвоить своему серверу имя WEB4, потому что позднее мы установим в нём некую роль Веб службы и разместим некий вебсайт. Помните, что после переименования вашего компьютера в точности как и с версией GUI Windows Server, необходим перезапуск системы чтобы изменение вступило в силу. Поэтому следующей командой вслед за Rename-Computer вы должны выполнить Restart-Computer для перезагрузки своего ящика:

Rename-Computer WEB4
Restart-Computer
 	   

Присоединение к вашему домену

Следующим логичным шагом, конечно же, является подключение к вашему домену. Это стандартные функции, которые мы могли бы выполнить на любом сервере в нашей среде, однако мы выполним их таким образом, с которым вы никогда не сталктвались ранее, так как вы всё выполняем строго из интерфейсов Командной строки и PowerShell. Для присоединения некоторого Сервера ядра к своему домену проследуйте в PowerShell и затем воспользуйтесь cmdlet Add-Computer. Вы получите запрос на определение как самого имени домена, так и полномочий для подключения к этому домену, той же само информации, которую вы бы определяли если бы вам пришлось подключаться к некоторому домену в режиме Практики с рабочим столом (Desktop Experience) Windows Server 2019. Прежде всего вы задаёте необходимые для подключения к этому домену подтверждения полномочий:

Затем вы сообщаете к какому домену вы бы хотели подключиться:

В качестве альтернативы вы можете применить параметр –DomainName в комбинации с первоначальным cmdlet Add-Computer чтобы определить необходимое имя в этой первоначальной команде. И, естественно, после подключения к домену вам необходимо снова Restart-Computer чтобы завершить это изменение.

Удалённый PowerShell

Раз наш сервер снабжён IP адресом, имеет название и подключён к домену, мы можем начать выполнять с этим новым экземпляром Сервера ядра некое практическое администрирование. Вы несомненно можете продолжать регистрироваться в нём и взаимодействовать напрямую через его консоль, однако как и в случае управления всеми прочими серверами в вашей среде должны иметься способы делать это удалённо, так? Одним из способов взаимодействия с Сервером ядра без необходимости усаживаться перед ним является применение удалённого подключения PowerShell.

Более подробно мы рассмотрим весь процесс удалённого применения PowerShell для манипуляций с серверами (как с GUI, так и с выхолощенными) в Главе 10, PowerShell, здесь мы лишь мимолётно представим те команды и возможности, которые требуются вам чтобы иметь способность устанавливать удалённый сеанс из приглашения PowerShell в некоторой рабочей станции изнутри подключаемой к домену среды.

Откройте PowerShell из другой системы - это может быть даже операционная система клиента. Такое окно PowerShell, очевидно, откроется с контекстом той машины, в которой вы зарегистрированы, а все вызываемые вами команды PowerShell подразумевают некий отклик от этой самой системы. Чтобы прицепить PowwerShell к экземпляру Сервера ядра WEB4, я вызову приводимую далее команду. После её исполнения у меня будет запрошен ввод пароля, соответствующего имеющейся учётной записи с правами администратора, а затем будет получена возможность вызывать удалённые команды PowerShell к нашему Серверу ядра:

Enter-PSSession -ComputerName WEB4 -Credential administrator
		

Теперь вам представлено приглашение PowerShell, удалённо подключённое к имеющейся коробке Сервера ялра WEB4. Вы можете наблюдать его (WEB4) приводимым слева от вашего приглашения. Возможно вы слегка не доверяете этому небольшому указателю и желаете проверить что это окно PowerShell теперь имеет доступ и удалённо манипулирует сервером WEB4? Давайте вызовем пару быстрых команд, таких как hostname и ipconfig чтобы доказать что та информация, которая представляется нам в данном сеансе PowerShell на самом деле поступает к нам от нашего нового сервера WEB4:

Теперь, когда у нас имеется удалённое подключение PowwerShell к этому новому Серверу ядра, мы достаточно много чего можем делать с этим сервером прямо из этой консоли.

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

Я хочу установить некую роль на свой новый сервер WEB4. Я могу сделать это прямо из консоли своего сервера, но вместо этого я попытаюсь добавить WEB4 в Диспетчер сервера, который работает на другом моём сервере. Я собираюсь зарегистрироваться на сервере WEB3 и воспользоваться Диспетчером сервера на нём. В точности так же, как мы это уже видели, я могу добавить новый сервер в Диспетчер сервера при помощи меню Управления (Manage) и выбрать Add Servers:

Добавьте новый сервер WEB4 в наш список управляемых машин, и он теперь может управляться изнутри этого экземпляра Диспетчера сервера. Возвращаясь назад к имевшемуся у меня изначально намерению, я желаю установить роль Веб сервера (IIS) на WEB4. Если я воспользуюсь функцией Add roles and features внутри Диспетчера сервера, я могу теперь выбрать для манипуляций свой сервер WEB4:

В точности так же, как при работе с версией Windows Server, с полной Практикой рабочего стола (Desktop Experience), мы теперь можем завершить проход по мастеру установки выбранной роли и такая новая роль будет установлена на WEB4.

Также верным является и тот факт, что вы можете управлять экземплярами Сервера ядра при помощи RSAT (Remote Server Administration Tools, Инструментов удалённого администрирования сервером) в Windows 10. RSAT по существу просто является копией Диспетчера сервера, которая разработана для работы в имеющейся клиентской операционной системе. В нашем случае у меня уже имеется машина в Windows 10, на которой я установил RSAT ранее в этой книге, поэтому я проверю это зарегистрировавшись на этом парне и добавив WEB4 в свой интерфейс. Я только закончил устанавливать свою роль IIS на WEB4 в своём предыдущем задании, поэтому я должен иметь возможность увидеть её пречисленной внутри RSAT, когда я подключусь к WEB4.

Если вы ранее не применяли RSAT и не читали тот раздел в нашем тексте, важно зать что не существует приложения с названием Remote Server Administration Tools (Инструментов удалённого администрирования сервером). Вместо этого, по окончанию установки RSAT загляните вовнутрь своего меню Пуск (Start) и отыщите приложение, называющееся Диспетчером сервера (Server Manager). Именно его вы применяете в клиенте Windows 10 для удалённого управления экземплярами Windows Server 2016.

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

Если я кликну правой кнопкой по имени сервера WEB4, из данной консоли RSAT, вы можете увидеть, что у меня имеется множество доступных мне функций, которые я могу применять к этому удалённому экземляру Сервера ядра:

Таким образом, вы можете отметить, что существуют варианты применения инструментария GUI для управления вашими не имеющими GUI экземплярами Windows Server. Это всего лишь вопрос включения вашего сознания в работу, при которой вы представляете себе серверы выхолощенными (headless), а при этом инструментам навроде PowerShell или Диспетчера сервера на самом деле всё равно будет ли изменяемый вами сервер локальным или удалённым. В любом случае процессы и инструменты будут одинми и теми же. Вы можете видеть на предыдущем снимке экрана, что я даже могу здесь щёлкнуть чтобы запустить удалённое подключение PowerShell к WEB4. Клик по этой кнопке немедленно запускает PowerShell, который удалённо связан с нашим сервером WEB4, даже несмотря на то что я в настоящее время зарегистрирован только на своей рабочей станции Windows 10. Это даже проще чем вызывать cmdlet Enter-PSSession изнутри PowerShell.

Давайте рассмотрим ещё один момент прямо из консоли Сервера ядра; это распространённое препятсвие, о которое вы спотыкаетесь, если только вы не пользовались интенсивно Сервером ядра ранее. У нас имеется стремление закрывать окна и приложения, которыми мы больше не используем, и так же точно вы можете неосознанно закрыть своё окно приглашения Командной строки, которое обслуживает всё ваше административное присутствие в рамках некоторого сеанса Сервера ядра. Теперь вы сидите за большим пустым экраном при кажущемся полном отсутствии какого- либо интерфейса и места, откуда можно было бы получить его.

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

Существует простой способ для возврата приглашения Командной строки назад, заключающегося в применении Диспетчера задач (Task Manager) для запуска нового экземпляра приглашения Командной строки. Когда вы находитесь перед пустым чёрным экраном некоторой консоли Сервера ядра, вы можете нажать Ctrl + Alt + Del и вам будут предложены следующие варианты:

На самом деле имеется всего несколько различных функций которые вы можете здесь выполнить, что достаточно классно. Однако, чтобы получить наше окно приглашения Командной строки обратно, пройдитесь стрелкой вниз до Диспетчера задач (Task Manager) и нажмите Enter. Это запустит приложение Диспетчера задач, с которым вы все знакомы. Теперь кликните по Дополнительным подробностям (More details) чтобы раскрыть окно Диспетчера задач. Раскройте вниз меню Файлы (File) и кликните по Выполнить новую задачу (Run new task):

В блоке Создания новой задачи (Create new task) наберите cmd и кликните OK:

В качестве альтернативы вы можете определить для запуска любое приложение напрямую в этом приглашении Создания новой задачи (Create new task). Если вы заинтересованы в переходе сразу к PowerShell, вместо набора cmd просто введите это приглашение powershell и оно будет открыто напрямую:

В то время как Приглашение из командной строки в консоли, удалённые подключения PowerShell, удалённое администрирование Диспетчером сервера и даже исполняемый под рабочей станцией Windows 10 инструментарий RSAT всё это допустимые и мощные инструменты для администрирования нашими экземплярами Сервера ядра, они все отодвигаются на заднюю сцену выпуском Windows Admin Center (WAC, Центра администрирования Windows). Вы уже изучали что Центр администрирования Windows способен делать для централизованного управления всей вашей инфраструктурой сервера, однако то на что мы обязаны указать тут, это то что WAC можно применять как для серверов с графическим интерфейсом, так и без него.

Я общался со множеством администраторов Windows Server по вопросам Сервера ядра и одним из наиболее блокирующих моментов для реализации этих более эффективных и безопасных серверных платформ выступает опасение что будучи настроенными, при последующем администрировании и сопровождении этих серверов их будет труднее обрабатывать. Те администраторы, которым удобно работать внутри Windows Server с Практикой Рабочего стола в точности знают что следует делать что выполнять для своих повседневных задач, однако удалите такой интерфейса укажи- и- кликни и внезапно их рабочий день станет намного более сложным.

К счастью, вам не требуется запоминать всё руководство по PowerShell чтобы применять Сервер ядра! Центр администрирования Windows воспринимает экземпляры Сервера ядра точно так же как он это делает и для серверов с исполняющейся Практикой Рабочего стола. Это просто работает!

У нас уже имеется установленным на сервере в нашей лаборатории проверок WAC, поэтому давайте откроем его и поднимем мой новый сервер WEB4 для административного управления им и рассмотрим какие вараинты доступны для повседневного сопровождения данного сервера.

Когда мы впервые подключаемся к WEB4 через свою консоль WAC, на самом деле ничто даже и не указывает нам на то, что это экземпляр Сервера ядра, здесь у нас имеются доступными для клика все инструменты и утилиты:

Давайте опробуем из WAC пару моментов. Увас, естественно, имеется мощные средства контроля питанием прямо рядом с верхней частью экрана, из которых вы легко можете останавливать или перезапускать этот сервер. Это намного проще и быстрее чем устанавливать некое удалённое подключение PowerShell чтобы вызывать команды для осуществления тех же самых действий. Также имеются измерения производительности в его домашнем экране (если вы отмотаете вниз), отображающее потребление вами ресурсов CPU, Memory и Networking. Без наличия WAC вам бы приходилось регистрироваться в WEB4 и запускать Диспетчер задач (Task Manager) чтобы рассматривать эти статистические данные:

Уходя с этого домашнего экрана, который и сам по себе полезен, попробуйте кликнуть по одному из перечисленных совместно с левой стороны этого крана Tools, например по Events. Без WAC, если вам хотелось устранять неисправности в Сервере ядра при наличии проблем, вам бы пришлось рассматривать Журналы событий Windows в этом сервере, но как вы представляете это себе в интерфейсе командной строки? Я предполагаю, что вы могли бы зарегистрироваться в консоли этого Сервера ядра и воспользоваться Диспетчером задач для запуска EventVwr, однако открытие WAC и щелчок по Events намного проще:

Прочими примерами полезных функций внутри WAC, в особенности при работе с экземпляром Сервера ядра, будут применение Files для навигации по структуре жёсткого диска файлов и папок WEB4, либо использование здесь функции Firewall для создания или удаления правил Межсетевого экрана для WEB4. Также имеется инструментарий Network, в котором вы имеете возможность манипулирования настройками адресации IP.

Хотя внутри вашего WAC имеется множество дополнительных инструментов, последнее на что я бы хотел обратить ваше внимание, это снова то, что у нас имеется вариант PowerShell (аналогичный тому, который мы можем загружать из Диспетчера сервера). Эта кнопка PowerShell вызовет и отобразит для нас некое удалённое подключение PowerShell к нашему экземпляру Сервера ядра WEB4 и нам потребуется углубиться под его капот чтобы выполнить что- нибудь из командного интерфейса. А самое лучшее это то, что вам на самом деле никогда не придётся запускать PowerShell! Это всё происходит прямо внутри окна вашего интернет браузера:

Имеется ещё много чего что мы имеем возможность выполнять изнутри своего Центра администрирования Windows. Изменять Registry, добавлять Roles & Features, проверять состояние ваших Services и даже взаимодействовать с Windows Update. Если вы ещё не используете WAC, вы упускаете свою лодку!

Теперь мы намерены сделать шаг назад и проверить тот инструмент, который доступен внутри Сервера ядра, но при этом обычно полезен только когда вы работаете с самой консоли вашего сервера. Как вы уже видели, всякий раз когда вы выполняете перезагрузку некого Сервера ядра, вы приземляетесь внутри некого окна с командной строкой, из которой вы имеете возможность свернуть в PowerShell и затем воспользоваться обычными cmdlet Windows для настройки своего экземпляра Сервера ядра.

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

Непосредственно сразу после раскрутки некого нового экземпляра Сервера ядра вы обнаружите себя в приглашении Командной строки, ожидающей вашего ввода. Внутри этого экрана вы просто набираете Sconfig и нажимаете Enter; вы должны стать свидетелем быстрой смены чёрного на синее и увидеть следующий экран:

Все доступные внутри Sconfig варианты достаточно неплохо поясняют себя сами, но мы рассмотрим наиболее распространённые задачи, выполняемые отсюда. Напомним снова, что это все те вещи, которые вы можете вместо этого осуществлять через cmdlet PowerShell, но мне кажется более простым выполнять подход, предлагаемый Sconfig. Наиболее распространённым вариантом применения данного интерфейса является настройка начальных сетевых установок через нажатие 8 либо настройка имени хоста и участия в домене при помощи вариантов 2 и 1.

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

Теперь я желаю проверить сетевые настройки. Нажатие на 8 с последующим Enter переносит меня к Network Settings, где я могу видеть что текущим IP адресом NIC моего WEB4 установлен 10.10.10.12. Это правильно, но давайте изменим этот адрес просто чтобы пройтись по реальным изменениям настроек Sconfig.

Для началя я выбираю индекс своего сетевого адаптера, которым в моём случае был номер один. Мне теперь представлена дополнительная информация относительно того что я уже настроил эту NIC и имею возможности изменить эти данные. Выбор варианта номер один снова позолит мне Set Network Adapter Address (Установить адрес сетевого адаптера):

Введите букву S, что укажет Sconfig что вы желаете ввести некий статический IP и затем введите новое значение IP, которое вы желаете настроить для этой NIC. Я изменю WEB4 с тем, чтобы он превратился в 10.10.10.30, просто чтобы убедиться что это работает. После ввода указанного IP адреса я также должен определить некую новую маску подсети и адрес шлюза:

NIC WEB4 немедленно изменит значение своего IP на 10.10.10.30, что будет отображено в результате вывода. Несмотря на то, что посещение Sconfig может быть не самым распространённым явлением, этот инструмент позволяет вам экономить время при его применении для начальной настройки сети и параметров именования всякого нового Сервера ядра.

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

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

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

Что же осталось после выдирания из сферы Нано сервера всех жтих функций? Он мёртв? Может быть Нано сервер НИЧЕГО не делает?

Ответом являются контейнеры. Если вам интересно применение контейнеров для построения и размещения готовых к облачному применению приложений, именно над этим теперь и сосредоточены Нано. Мы обсудим дополнительно сведения о контейнерах и том факте, что Нано сервер окончательно соединился с ними в Главе 11, Контейнеры и Нано сервер,

Я должен быть честен с вами, написание этой главы было как пинок под зад, что я должен начать думать о сокращении своих собственных серверов. Я в той же лодке, что и многие из вас. Я знаю, что такое Сервер ядра и я игрался с ним, однако никогда не предпринимал реальных шагов к его применению в поддерживаемых мной промышленных средах. Теперь, когда нам доступны такие инструменты как Sconfig и новый Windows Admin Center, у меня с формальной точки зрения совершенно нет оправданий почему бы мне не развёртывать новые роли в коробках с Сервером ядра. Хотя освоение чего бы то ни было нового никогда не повредит, применение Сервера ядра больше не требует обязательного владения PowerShell. Первые годы Сервера ядра прошли под знаменем того, что вам следовало быть на самом деле плавающими как рыба в PowerShell, посколку это был единственный надёжный способ настройки и взаимодействия с вашими крошечными серверами, но эти новые инструменты позволяют ввам применять платформу меньшего размера и осуществлять администрирование ею без запоминания кучи cmdlet.

Самой первейшей причиной по которой вам следует рассматривать Сервер ядра в качестве некого нового стандарта является безопасность. Графический интерфейс Windows добавляет кучу кода и предоставляет множество возможностей тем, кто подключён к вашим серверам, например, просматривать Интернет. Это открывает все разновидности дверей для уязвимостей, которые просто отсутствуют в Сервере ядра. Наша следующая глава рассматривает избыточность Windows Server 2019.