По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Для управления новой ОС Windows Server 2019 можно использовать различные инструменты, такие как PowerShell, консоль управления Microsoft (MMC) и диспетчер сервера. Все эти инструменты уже встроены в операционную систему. По этой ссылке с сайта Microsoft дополнительно можно загрузить Центр Администрирования Windows (Windows Admin Center).
Общая философия администрирования систем Microsoft заключается в том, что, хотя с помощью графического интерфейса, Центра администрирования Active Directory или консоль диспетчера серверов можно выполнять практически все задачи, но задачи, которые неоднократно выполняются, необходимо автоматизировать с помощью Windows PowerShell и рекомендуется, чтобы почти все задачи администрирования выполнялись удаленно.
Необходимо уметь пользоваться средствами удаленного подключения, и по возможности, исключать использование Удаленного рабочего стола. Открытие RDP не безопасно и отнимает много времени. Допустим, нужно сбросить пароль локального пользователя на 30-50 или более серверах. Для выполнения этой задачи при использовании RDP потратиться много времени.
Автоматизируйте задачи там, где это возможно. Windows Admin Center (WAC) представляет собой веб-консоль, через которую можно удаленно управлять Windows Server 2019, Windows Server 2016, Windows Server 2012, Windows Server 2012 R2. Для управления Windows Server 2008 R2 имеется ограниченный набор задач.
Центр Администрирования можно открывать с помощью Edge, Firefox и Google Chrome, а устанавливать на компьютерах под управлением Windows 10, Windows Server 2016 или Windows Server 2019.
Если установка WAC будет происходить на Windows 10, сервис будет «слушать» порт 6516, а иконка для запуска будет находиться на Рабочем столе.
Центр администрирования Windows можно установить на редакцию Server Core, используя команду msiexec, указав порт и необходимые дополнительные параметры.
Синтаксис в этом случае будет такой:
msiexec /i WindowsAdminCenter2009.msi /qn /L*v log.txt SME_PORT=<port>
SME_THUMBPRINT=<thumbprint> SSL_CERTIFICATE_OPTION=installed
SME_PORT - это порт, который вы будете использовать, а SME_THUMBPRINT – хэш установленного сертификата SSL (TLS).
Установить на Домен контроллер не получится, о чем инсталлятор предупредит.
Принятие лицензии, использовать или Windows Update для установки важных обновлений.
Выбор порта для сайта Windows Admin Center.
На конечном этапе инсталлятор покажет адрес, по которому будет открываться WAC.
Главное окно Windows Admin Center.
Когда вы подключились к WAC, добавьте все необходимые сервера. Для этого имеется кнопку Добавить, затем выберите тип ресурса, который хотите создать или добавить. Это могут быть виртуальные машины Azure, сервера Windows или кластеры серверов.
После выбора, появится диалоговое окно с запросом на ввод учетных данных с административными правами на добавляемом сервере.
Из Центра Администрирования можно управлять облачными службами, такими как Azure Backup, Azure Software Update, Azure Site Recovery и другими.
В Windows Admin Center имеются расширения, которые расширяют его возможности. Он отображает расширения, опубликованные в официальном канале Microsoft NuGet. Эти расширения одобрены корпорацией Microsoft или опубликованы доверенными сторонними поставщиками.
На данный момент WAC дополняет, а не полностью заменят средства RSAT. Возможно, в дальнейшем все больше и больше функций перейдет именно в него, и он станет единственным средством для удаленного управления Windows Server.
Основная цель любого проекта по разработке ПО – получить прибыль за счет автоматизации бизнес-процессов. Чем быстрее вы начнете выпускать новые версии, тем лучше для компании. Но как же научиться выпускать новые версии максимально быстро? Конечно же, все можно делать вручную. Например, подключить удаленный сервер через SSH, клонировать клонировать репозиторий с новым кодом, собрать его и запустить через командную строку. Да, такой способ работает, но он малоэффективен. Сегодня мы поговорим об автоматизации процесса разработки и выхода новых версий.
CI и CD – это два сокращения, которые означают Continuous Integration (Непрерывная интеграция) и Continuous Delivery (Непрерывное развертывание).
CI
CI описывает процесс добавления изменений в репозиторий. Ниже схематически представлен простой пример коллективной разработки.
Одновременно может работать целая группа людей, но все изменения передаются в главную ветку master поэтапно. Хотя даже в такой простой схеме возникает несколько вопросов.
Как мы узнаем, что код, который идет в ветку master, компилируется?
Мы хотим, чтобы разработчики писали тесты для кода. Как быть уверенными в том, что тестовое покрытие не уменьшится?
Все сотрудники команды должны форматировать код в соответствие с определенным стилем. Как отследить возможные нарушения?
Конечно же, все это можно проверить вручную. Но такой подход весьма хаотичен. Кроме того, по мере разрастания команды выполнять подобные проверки становится сложнее.
CI используется для автоматизации выше обозначенных пунктов.
Начнем с первого пункта. Как можно проверить, что новые изменения не сломают сборку? Для этого нам потребуется еще один блок в схеме.
Большинство CI-процессов можно описать по следующему алгоритму.
При открытии каждого Pull Request (запроса на включение изменений) и отправке новых изменений, Git-сервер отправляет уведомление CI-серверу.
CI-сервер клонирует репозиторий, проверяет исходную ветку (например bugfix/wrong-sorting) и сливает ее с основной веткой master.
Затем запускается скрипт сборки. Например ./gradlew build.
Если команда возвращает код «0», то сборка прошла успешно. Все остальные значения считаются ошибкой.
CI-сервер отправляет запрос на Git-сервер с результатом сборки.
Если сборка прошла без ошибок, то Pull Request разрешается слить. В противном случае он блокируется.
Данный процесс гарантирует, что код, попадающий в ветку master, не сломает дальнейшие сборки.
Проверка тестового покрытия
Давайте немного усложним задачу. Предположим, нам захотелось установить минимальный охват тестового покрытия. Это означает, что в любой момент времени покрытие ветки master должно быть не менее 50%. Плагин Jacoco идеально справляется с этой задачей. Вы просто настраиваете его так, чтобы при охвате тестового покрытия ниже допустимого, сборка уходила в ошибку.
Реализовать такой подход проще некуда. Но есть небольшая оговорка. Этот метод работает только при условии, что плагин настраивался на старте проекта.
Представим ситуацию: вы работаете над проектом, которому уже 5 лет. С момента первого коммита никто не проверял тестовое покрытие. Разработчики добавляли тесты в случайном порядке и без какой-либо организации. Но вот однажды вы решаете увеличить количество тестов. Вы настраиваете плагин Jacoco на минимальную планку в 60%. Спустя какое-то время разработчик открывает новый Pull Request. Затем разработчики вдруг понимают, что покрытие – всего лишь 30%. Так что для успешного закрытия задачи нужно покрыть не менее 30% кода продукта. Как вы можете догадаться, для проекта 5-летней давности – это практически неразрешимая проблема.
Но что, если будут проверяться только будущие изменения в коде, а не весь продукт? Если в Pull Request разработчик изменит 200 строк, то нужно будет охватить не менее 120 из них (при тестовом покрытии в 60%). Тогда не придется проходить по множеству модулей, которые не относятся к задаче. В принципе, проблема решаема. Но как применить все это к проекту? К счастью, есть решение.
Отчет Jacoco отправляется на сервер тестового покрытия.
Одно из самых популярных решений – SonarCloud.
Сервер хранит статистику по предыдущим вычислениям. Это очень удобно: вычислять тестовое покрытие не только всего кода, но и будущих изменений. Затем результат анализа отправляется на CI-сервер, который перенаправляет его на Git-сервер.
Такая рабочая модель позволяет применять культуру обязательного тестирования на любой стадии развития продукта, поскольку проверяется лишь часть изменений.
Если говорить о стиле оформления кода, то отличий практически нет. Можете попробовать плагин Checkstyle. Он автоматически отклоняет сборку, которая нарушает любое из заявленных требований. Например, в коде есть неиспользованный импорт. Кроме того, вы можете присмотреться к облачным сервисам, которые выполняют анализ кода и визуально отображают результаты в виде графиков (SonarCloud это тоже умеет).
CD
CD описывает процесс автоматического развертывания новой версии продукта.
Давайте еще немного подкорректируем схему CI. Вот так конвейерный процесс CI/CD мог бы выглядеть в реальном проекте.
Первое отличие – теперь CI-сервер называется CI/CD-сервером. Дело в том, что зачастую оба процесса (CI и CD) выполняются одним и тем же диспетчером задач. Так что мы будем рассматривать именно этот случай.
Но так бывает не всегда. Например, задачи по интеграции могут делегироваться на GitLab CI, а задачи по доставке – отдаваться в Jenkins.
Правая часть схемы изображает CI. Мы обсудили ее выше. Слева показана CD. Задача по CD создает проект (или повторно использует артефакты, полученные на стадии CI) и развертывает его на конечном сервере.
Стоит отметить, что сервер в нашем случае – это понятие абстрактное. Например, развертывание может выполняться в кластер Kubernetes. Так что самих серверов может быть несколько.
Обычно после стадии развертывания на почту приходят сообщения о выполнении. Например, CD-сервер может уведомлять подписчиков об успешном развертывании/ошибках.
В любом случае, возникает важный вопрос. В какой момент мы должны запускать задачи по CD? Триггеры могут быть разными.
Развертывание после каждого слияния Pull Request.
Развертывание по расписанию.
Развертывание после каждого слияния Pull Request с определенной веткой.
Сочетание нескольких вариантов.
В первом пункте процесс выстроен так, что задачи по CI и CD всегда выполняются последовательно. Данный подход весьма популярен при разработке программ с исходным кодом. Библиотека Semantic Release помогает настроить проект для прозрачной интеграции данной модели.
Важно помнить о трактовке понятия deploy (развертывание). Это не всегда «что-то где-то запустить». Например, при разработке библиотеки, нет никакого запуска. В данном случае процесс развертывания означает выпуск новой версии библиотеки.
Второй пункт не зависит от процесса CI, ведь проект развертывается по определенному расписанию. Например, ежедневно в 01:00.
Третий пункт аналогичен первому, но с небольшими отличиями. Предположим, в репозитории у нас есть 2 основные ветки: develop и master. В develop содержатся самые последние изменения, а в master – только релизы версий. Если мы хотим развертывать только ветку master, то не нужно вызывать CD-задачу по слиянию в develop.
Последний пункт – это сочетание подходов. Например, ветку develop можно развертывать по расписанию в среду разработки. А ветку master – в реальную среду по каждому слиянию Pull Request.
Инструменты
На рынке доступно множество решений по автоматизации процессов CI/CD. Ниже представлено несколько продуктов.
Jenkins. Один из самых востребованных инструментов CI/CD в мире. Свою популярность он заслужил, благодаря политике открытого кода (open-source). То есть вам не нужно ни за что платить. В Jenkins вы можете императивно описывать конвейеры сборки с помощью Groovy. С одной стороны это достаточно гибкое решение, но с другой – требует более высокого уровня квалификации.
GitHub Actions. Этот инструмент для CI/CD доступен для GitHub и GitHub Enterprise. В отличие от Jenkins, GitHub Actions предлагает декларативные сценарии сборки с YAML-конфигурацией. Кроме того, в данном решении доступна интеграция с различными системами обеспечения качества (например SonarCube). Таким образом, сборку можно описать в нескольких текстовых строках.
GitLab CI. Во многом похож на GitHub Actions, но со своими особенностями. Например, GitLab CI может указывать на определенные тесты, вызывающие ошибку в сборке.
Travis CI. Облачный CI/CD-сервис. Предлагает множество возможностей, не требующих сложных настроек. Например, шифрование данных, которые следует скрыть в публичном репозитории. Есть и приятный бонус в том, что Travis CI можно совершенно бесплатно использовать в публичных open-source проектах на GitHub, GitLab и BitBucket.
Развитие компьютерных сетей проходит ошеломляющими темпами. Обилие устройств в компьютерных сетях порождает ряд проблем, таких, например, как необходимость объединять в отдельные изолированные подсети машины, которые подключены к различным коммутаторам. Иными словами, развитие сетей породило необходимость создания так называемых виртуальных локальных сетей, или VLAN.
Что же такое виртуальная компьютерная сеть? VLAN дословно расшифровывается как Virtual Local Area Network, или виртуальная локальная сеть. По факту – это функция устройств связи, например, коммутаторов или маршрутизаторов, которая позволяет объединять устройства в одну или несколько виртуальных локальных подсетей в рамках одного физического сетевого интерфейса, такого как Wi-fi или Ethernet. Стоит отметить, что виртуальная логическая топология сети никак не пересекается с физической топологией и, соответственно, не зависит от нее.
Несколько примеров использования виртуальной локальной сети
Создание отдельных подсетей для групп устройств, подключенных к одному и тому же коммутатору:
Если к одному коммутатору или маршрутизатору подключены несколько компьютеров в рамках одного офиса, то их можно разделить на отдельные подсети. Это актуально для малых предприятий, таких как, например, небольшая компания по разработке компьютерных игр. В этом случае будет рациональным объединить в отдельные подсети рабочие станции художников и программистов, поскольку обмен данными между сотрудниками одного отдела в рамках работы будет более эффективным. Специалисты каждого отдела будут видеть компьютеры только своей подгруппы, а руководители отделов, в свою очередь, будут объединены в свою сеть или подсеть, стоящую выше по сетевой иерархии.
Создание виртуальной сети для устройств, подключенных к разным коммутаторам:
Допустим, во взятой нами за пример компании по разработке компьютерных игр произошло расширение штата – наняли нескольких новых работников – программистов и художников. Их разместили в соседнем кабинете, и, соответственно, выделили им для работы свой коммутатор. В данном случае можно также создать виртуальные сети для отделов организации, в которых появились новые рабочие станции, даже если они физически подключены к другому коммутатору. В этом случае работники разных отделов не будут видеть в сети компьютеры сторонней группы, даже если они физически находятся в одном кабинете.
Распределение Wi-fi сети для различных групп пользователей:
Пусть в нашей организации стоит роутер, который физически имеет одну точку доступа Wi-fi. VLAN позволяет создать несколько виртуальных точек Wi-fi для разных отделов, в том числе отдельную гостевую точку доступа. Это удобно для руководства предприятия, так как позволяет проконтролировать расход трафика и выяснить, например, что программист Вася, вместо того чтобы писать код, смотрит в соцсетях фото с котиками. Да и для безопасности это также полезно – например, устройства подключаемые через гостевую точку доступа, не будут видеть рабочие компьютеры организации.
Заключение
Таким образом, к достоинствам VLAN можно отнести:
Меньшее количество используемых для создания внутренней сети организации проводов (и меньше головной боли для сетевого администратора);
Более безопасную и контролируемую связь между устройствами – рабочие станции в рамках одной подсети не будут «видеть» устройства из других подсетей;
Более эффективное использование трафика в различных подсетях общей сети, за счет возможности управления трафиком в различных подгруппах;
Повышение эффективности работы отделов через создание новых подгрупп устройств, для чего VLAN предоставляет широчайшие возможности;