E-Book
7 Tage kostenlos im Abo
E-Book
12,99 €

PowerShell: практическая автоматизация E-Book

Мэтью Доуст

0,0

Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.

Herausgeber: Питер
Kategorie: Wissenschaft und neue Technologien
Sprache: Russisch

Beschreibung

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

Details

Sie lesen das E-Book in den Legimi-Apps auf:

Android

iOS

von Legimi
zertifizierten E-Readern

Kindle™-E-Readern
(für ausgewählte Pakete)

Seitenzahl: 419

Veröffentlichungsjahr: 2024

Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:

Android

iOS

Bewertungen

0,0

Rezensionen(0 Rezensionen)

Leseprobe

Переводчик А. Бойков

Мэтью Доуст

PowerShell: практическая автоматизация. — СПб.: Питер, 2024.

ISBN 978-5-4461-2213-4

Предисловие

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

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

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

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

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

Благодарности

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

Я также хотел бы выразить признательность Кэмерону Фуллеру (Cameron Fuller), чье наставничество и поддержка помогли мне стать тем, кто я есть сейчас, и остальным коллегам по Quisitive, которые вдохновляли и поддерживали меня на протяжении всей этой работы. Особо хочется выделить среди них Грега Тейта (Greg Tate) и Дэвида Стайна (David Stein) за их бесценные отзывы, которые я получил по программе MEAP1.

Я вряд ли бы написал эту книгу без помощи моих редакторов: Коннора О'Брайена (Connor O’Brien) и Майкла Лунда (Michael Lund). Спасибо, Коннор, за то, что работал со мной и научил меня доносить свои мысли до других людей. Я думал, что многое знаю о писательстве, но твое терпение и увлеченность моими идеями помогли мне сделать книгу лучше, чем я мог себе представить. Спасибо, Майкл, за технические комментарии и рекомендации, которые очень помогли мне в процессе работы над книгой.

Благодарю всех рецензентов и тех, кто оставил отзывы по программе MEAP. Эти отзывы были мне крайне полезны. Спасибо всем рецензентам — Александру Николичу (Aleksandar Nikolic), Алисе Чанг (Alice Chang), Андреасу Шабусу (Andreas Schabus), Анне Эпштейн (Anne Epstein), Антону Херцогу (Anton Herzog), Бруно Соннино (Bruno Sonnino), Чарльзу Майку Шелтону (Charles Mike Shelton), Чаку Куну (Chuck Coon), Эрику Дики (Eric Dickey), Фредрику Рагнару (Fredric Ragnar), Джулиано Латини (Giuliano Latini), Глену Томпсону (Glen Thompson), Гленну Суонку (Glenn Swonk), Гонсало Уэрте Канепе (Gonzalo Huerta Cánepa), Ховарду Уоллу (Håvard Wall), Яну Винтербергу (Jan Vinterberg), Иеремие Грисволду (Jeremiah Griswold), Жерому Безе-Торресу (Jérôme Bezet-Torres), Иржи Пику (Jiri Pik), Кенту Спиллнеру (Kent Spillner), Майку Халлеру (Mike Haller), Милану Саренаку (Milan Sarenac), Муралидхарану Т.Р. (Muralidharan T R), Мустафе Озетину (Mustafa Özçetin), Нику Римингтону (Nik Rimington), Орландо Мендесу Моралесу (Orlando Méndez Morales), Пшемыславу Хмелецкому (Przemysław Chmielecki), Ранджиту С. Сахаи (Ranjit S. Sahai), Роману Левченко, Сандеру Зегвельду (Sander Zegveld), Сатею Кумару Саху (Satej Kumar Sahu), Шону Болану (Shawn Bolan), Сильвене Мартель (Sylvain Martel), Уэйну А. Боазу (Wayne A Boaz), Вернеру Ниндлу (Werner Nindl) и Зохебу Айнапоре (Zoheb Ainapore). Ваши предложения помогли сделать эту книгу лучше.

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

1 MEAP — Manning Early Access Program, программа раннего доступа к книгам издательства Manning (https://www.manning.com/meap-program). — Примеч. ред.

О книге

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

Для кого эта книга

Эта книга предназначена для всех, кто знаком с PowerShell и хочет создавать системы автоматизации для применения в реальных условиях. Изложенные на этих страницах концепции пригодятся всем: от новичков до экспертов, но все-таки, чтобы польза от книги была максимальной, нужно иметь хотя бы некоторое представление о PowerShell: знать, как устанавливать модули, писать скрипты (.ps1), использовать основные конструкции, такие как условные операторы, сплаттинг (splatting) и циклы.

Структура книги

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

Первая часть — это разговор о том, с чего начинается автоматизация:

• В главе 1 мы посмотрим на PowerShell с точки зрения автоматизации, проверим и подготовим к работе нужные инструменты.

• В главе 2 поговорим про организацию скриптов и модулей с возможностью их повторного использования.

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

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

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

• В главе 5 рассмотрим разные способы удаленного запуска PowerShell и как их применять в реальных условиях.

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

• В главе 7 написанный нами скрипт будет взаимодействовать с бэкендом базы данных — удобная замена Excel- и CSV-файлов для хранения информации.

• В главе 8 для выполнения скриптов и управления ими мы задействуем Azure и объединим многие из рассмотренных ранее концепций в единую платформу.

• В главе 9 поговорим о взаимодействии PowerShell с другими инструментами. Например, о том, как создавать документы Word из PowerShell, осуществлять коммуникацию с веб API и даже о том, как вызывать скрипты, написанные на Python, и обмениваться данными между скриптами.

• В главе 10 познакомимся с лучшими практиками автоматизации PowerShell.

Третья часть посвящена совместному использованию и обслуживанию скриптов:

• В главе 11 мы используем SharePoint в качестве пользовательского интерфейса для скриптов PowerShell и поговорим о разработке скриптов для работы на устройствах конечных пользователей.

• В главе 12 научимся применять GitHub для контроля за исходным кодом и предоставления доступа к скриптам другим разработчикам.

• В главе 13 узнаем, как при помощи Pester проводить модульное и комплексное тестирование скриптов на соответствие сценариям, для которых они были созданы.

• В главе 14 вернемся к написанному ранее скрипту и внесем в него изменения. Поговорим о том, что нужно учесть заранее, а также об автоматическом тестировании скриптов средствами GitHub.

О коде

За небольшими исключениями весь код в этой книге написан на PowerShell 7.2 или выше. Если какой-то фрагмент нужно выполнить в Windows PowerShell 5.1, об этом указывается в примечании. Стремясь сделать книгу как можно более информативной, я постарался свести к минимуму зависимость от сторонних платформ. Любые инструменты и платформы, которые используются в этой книге, бесплатны либо имеют бесплатную пробную версию, функционала которой достаточно для отработки приведенных примеров. Для работы не потребуется даже таких простых вещей, как Active Directory.

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

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

Пример кода

Пример выводимого текста

Исполняемые фрагменты кода можно взять из электронной версии книги (liveBook), которая доступна по адресу https://livebook.manning.com/book/practical-automation-with-powershell. Весь код из примеров можно загрузить с сайта издательства Manning (www.manning.com) или из специального репозитория на GitHub (https://github.com/mdowst/Practical-Automation-with-PowerShell).

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

Форум liveBook

Приобретая книгу «Практическая автоматизация в PowerShell», вы также получаете бесплатный доступ к платформе для онлайн-чтения liveBook (на английском языке), где можно оставлять комментарии о книге, задавать технические вопросы и получать помощь от автора и других пользователей. Чтобы получить доступ к форуму, откройте страницу https://livebook.manning.com/book/practical-automation-with-powershell/discussion. Правила поведения на форумах издательства Manning приведены на сайте https://livebook.manning.com/discussion.

В рамках своих обязательств перед читателями издательство Manning предоставляет ресурс для содержательного общения читателей и авторов. Эти обязательства не подразумевают конкретную степень участия автора, которое остается добровольным (и неоплачиваемым). Задавайте автору хорошие вопросы, чтобы он не терял интереса к происходящему! Форум и архивы обсуждений доступны на веб-сайте Manning, пока книга продолжает издаваться.

Об авторе

Мэтью Доуст — управляющий консультант и ведущий архитектор в группе управляемой автоматизации компании Quisitive (ранее Catapult Systems). Последние десять лет он активно работает с PowerShell, помогая малому и крупному бизнесу в автоматизации насущных производственных задач. Кроме того, Мэтью принимает активное участие в жизни сообщества PowerShell: ведет блоги, работает над авторскими модулями, выступает на онлайн-форумах. Он также является автором рассылки PowerShell Weekly — еженедельного обзора новостей о PowerShell.

Иллюстрация на обложке

Иллюстрация на обложке книги «Практическая автоматизация в PowerShell» представляет собой рисунок Habitante de Frascati («Жительница Фраскати») из коллекции Жака Грассе де Сен-Совера (Jacques Grasset de Saint-Sauveur), опубликованной в 1797 году. Все рисунки в сборнике созданы и раскрашены вручную.

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

От издательства

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

Ваши замечания, предложения, вопросы отправляйте по адресу comp@piter.com (издательство «Питер», компьютерная редакция).

Мы будем рады узнать ваше мнение!

На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.

О научном редакторе русского издания

Никита Каравцев — DevOps-инженер компании КРОК. Занимается проектированием, установкой и настройкой IT-инфраструктуры, а также автоматизацией и оптимизацией процессов разработки программного обеспечения.

Часть 1

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

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

1. Автоматизация при помощи PowerShell

В этой главе

• Как сформулировать потребности в автоматизации

• Почему стоит использовать PowerShell

• Как определить, что PowerShell подходит для работы

• Как начать автоматизировать уже сегодня

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

Уверен, что вы уже пробовали бескодовые платформы автоматизации: IFTTT, Flow, Zapier или другие. Но если мы с вами похожи, возможности этих платформ, скорее всего, показались вам, как и мне, довольно примитивными. Они хороши для небольших персональных задач, но для решения реальных проблем уровня предприятия требуют настройки, которая невозможна при помощи их простого графического интерфейса.

И здесь на помощь придет PowerShell — фреймворк с простым, интуитивно понятным языком для написания скриптов автоматизации, который также позволяет объединять операции в логические цепочки. При помощи командлетов (cmdlets) PowerShell можно выполнять операции из консолей администратора и управлять всей экосистемой Microsoft (Azure, Office 365, Microsoft Dynamics и др.) и другими платформами, в том числе Linux и Amazon Web Services. Обуздав возможности PowerShell и освоив несколько базовых принципов, ИТ-специалист может стать настоящим гуру автоматизации.

Сегодня ИТ-специалисты не только должны делать больше при меньших затратах: вся ИТ-индустрия переходит к модели «инфраструктура как код». У меня есть уникальный опыт работы в компании, которая оказывает услуги консалтинга в области инфраструктуры и создает специализированные приложения. Имея возможность работать над проектами автоматизации в рамках обеих этих сфер, я понял, что, обладая знаниями в каждой из них, можно стать настоящим экспертом.

Если вы системный администратор или другой ИТ-специалист, то, вероятно, уже умеете работать с интерфейсом командной строки (CLI), пакетными файлами и скриптами PowerShell. Поэтому шаг к написанию кода, заточенного под задачи автоматизации, будет не так уж велик. В то же время, скорее всего, у вас нет ряда полезных навыков, таких как управление исходным кодом и проведение модульных тестов. И в этом данная книга вам поможет.

С другой стороны, далеко не все опытные программисты хорошо знают тонкости системного администрирования. Однако сильная сторона PowerShell — независимость от архитектуры предприятия. Запустить скрипт на сервере так же легко, как и на локальной машине. Эта книга покажет, как можно использовать PowerShell в организациях любого размера, как создавать в ней надежные, легкие в обслуживании и безопасные системы автоматизации.

1.1. Что вы узнаете из этой книги

Эта книга не только о том, как написать скрипт в PowerShell. Программированию посвящено множество ресурсов. Мы поговорим о том, как сделать PowerShell инструментом для автоматизации:

• Как автоматизировать повторяющиеся задачи.

• Как избежать распространенных ловушек при автоматизации.

• Как сопровождать скрипты и работать над ними совместно с командой.

• Как передавать скрипты конечным пользователям.

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

1.2. Практическая автоматизация

Читатели этой книги, скорее всего, уже задавались вопросом: что автоматизировать? Ответ «все!», о котором подумают многие, неверен. В общем случае принято считать, что автоматизировать нужно любую повторяющуюся задачу при условии, что на ее автоматизацию уйдет меньше времени, чем на ручное выполнение. Однако не все так просто, как и многое в ИТ-индустрии. Чтобы определить, стоит ли автоматизировать какую-то задачу, нужно учесть множество факторов, а не только затраты времени.

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

• Время: сколько времени уходит на выполнение задачи?

• Частота: как часто выполняется задача?

• Актуальность: как долго будет нужна задача и автоматизация?

• Реализация: сколько времени потребуется для автоматизации задачи?

• Обслуживание: сколько времени потребуется на обслуживание системы и поддержание ее в рабочем состоянии?

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

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

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

Время × Частота × Актуальность > Реализация + (Обслуживание × Актуальность).

Затраты на ручное выполнение > Затраты на автоматизацию.

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

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

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

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

Лучший способ начать — это найти простую, но часто выполняемую задачу и автоматизировать ее. Такая задача не обязательно должна быть сложной или нетипичной. Достаточно подумать о том, на чем можно сберечь время.

Автоматизация может помочь более продуктивно решать повседневные задачи, отвлекающие от основной работы. Например, я не всегда успеваю разбирать почту: прочитываю сообщения, но они остаются в папке «Входящие» и копятся там в больших количествах. Для этой цели можно использовать правила Outlook, но с ними я не уверен, что не пропущу важное оповещение, особенно когда нахожусь не на рабочем месте. Поэтому я написал скрипт, который делает все за меня: перемещает письма в определенные папки по электронным адресам или ключевым словам. Благодаря этому я не только экономлю время, но и работаю более продуктивно и получаю удовлетворение от того, что моя почта остается в порядке.

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

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

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

• цель;

• триггеры;

• действия;

• обслуживание.

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

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

1.2.1. Цель автоматизации

Цель автоматизации — это задача, которую требуется решить путем автоматизации. Может показаться, что определить цель очень просто. Однако необходимо точно учесть все, что предстоит сделать.

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

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

1.2.2. Триггеры

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

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

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

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

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

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

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

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

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

1.2.3. Действия

Действия — это то, что чаще всего и понимается под автоматизацией. Это операции, которые выполняет система автоматизации для достижения поставленной цели. В рамках одной системы может осуществляться множество действий (этапов). Действия можно разделить на три категории: логика, задачи и логирование. Действия, которые нужно выполнить для автоматизации удаления логов, показаны на рис. 1.1.

Логика управляет порядком работы системы. К ней можно отнести условные конструкции (например, if/else), циклы, ожидания, перехват/обработку ошибок, анализ переменных и других данных. Задачи — это действия, выполняемые при выполнении определенных условий, то есть все, что не относится к логике или регистрации. Можно сказать, что логика — это мозг системы, а задачи — ее руки.

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

Рассматривая наш пример, можно определить состав и типы действий, которые нужно выполнить:

1. Поиск логов старше 30 дней (логика).

2. Создание файла архива, имя которого содержит метку времени (задача).

3. Добавление старых логов в архив (задача).

4. Удаление старых логов с диска (задача).

5. Запись удаленных логов и имени файла архива (логирование).

6. Загрузка файла архива в хранилище Azure Blob для долгосрочного хранения (задача).

Рис. 1.1. Этапы автоматизации удаления логов и их классификация

7. Проверка результатов загрузки (логика). В случае ошибки — завершение работы и отправка уведомления.

8. Запись данных о местоположении архива (логирование).

9. Удаление архивного файла из локальной файловой системы (задача).

1.2.4. Обслуживание

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

В то время все пользователи были в одной, общей группе. Однако со временем все изменилось: компания расширилась, появились группы пользователей, которые теперь размещались в отдельных папках. Через какое-то время обнаружилось, что новые пользователи не регистрируются во внутреннем приложении. Но разработчик автоматизации давно ушел из компании, а кроме него никто не знал, как она работает. Поэтому пользователей сначала добавляли в общую папку, ждали синхронизации с приложением (которая выполнялась раз в час), а затем распределяли пользователей по другим папкам. То, что раньше экономило 60 минут одному человеку, теперь обходилось его коллегам в несколько дополнительных минут на каждого нового пользователя. Со временем автоматизация стала тратить времени больше, чем экономила.

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

В рассматриваемом нами примере действия начинаются с поиска старых логов, созданных 30 и более дней назад. Первое, о чем нужно подумать, — не будет ли диск заполняться быстрее. Тогда удалять логи придется каждые две недели. Насколько сложно будет внести такое изменение? Если для отбора по времени используется переменная — совсем не сложно. Если же цифра жестко закодирована, может потребоваться много работы.

Другой возможный сценарий развития системы — появление еще одной папки с логами. Насколько это вероятно? Если вероятность велика, нужно сразу подумать о том, чтобы скрипт умел работать с набором папок. А если она мала, можно запускать программу несколько раз, для каждой отдельной папки.

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

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

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

1.3. Процесс автоматизации

В начале работы над проектом автоматизации существует риск взвалить на себя непосильное бремя. Часто приходится слышать о принципе «не усложняй» (KISS), но придерживаться его на практике не всегда получается, особенно когда необходимо работать с несколькими связанными системами, использовать сложную логику, да еще и при постоянно меняющихся требованиях. На помощь приходят концепции стандартных блоков и этапов, которые позволяют разбить сложные задачи на небольшие, простые этапы.

1.3.1. Стандартные блоки

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

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

1.3.2. Этапы

Существует поговорка: «Прежде чем начать бегать, нужно научиться ходить». Она идеально подходит к автоматизации. Первые несколько скриптов, которые вы напишете, вряд ли будут хороши: совсем как первый рисунок или первое школьное сочинение. Для развития навыков нужны время и опыт. Но это не означает, что ваши первые программы будут бесполезны.

Разбив проект на этапы, можно двигаться к цели постепенно. Представьте себе, что нужно добраться из раздела А в раздел Б. Конечно, лучше всего сесть на автомобиль. Но что поделать, если вы не знаете, как его собрать? Поэтому начните с малого и двигайтесь вперед: сначала это будет скейтборд, потом скутер, велосипед, мотоцикл и, наконец, автомобиль. Преимущества такого подхода показаны на рис. 1.2. На каждом этапе вы будете вносить улучшения и развивать свою программу. Более того, она будет приносить пользу с самого начала. Если же сразу взяться за автомобиль, придется ходить пешком до завершения работы.

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

На каждом этапе работы вы, вероятно, создадите несколько стандартных блоков, которые можно использовать на разных этапах, а также постепенно усовершенствовать. Например, на первом этапе рис. 1.2 у вас получилось колесо. Далее на этапе 2, углубив знания, вы можете его улучшить.

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

1.3.3. Сочетание стандартных блоков и этапов

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

1. Создание виртуальной машины.

2. Установка операционной системы.

3. Настройка операционной системы.

Было бы хорошо написать такой скрипт целиком, за один прием. Но это большая работа, эффект от которой будет виден лишь после завершения. Поэтому лучше работать над каждым этапом в отдельности и сразу пользоваться результатами. Начнем с этапа 1 — создания виртуальной машины. В нем можно выделить несколько стандартных блоков:

1. Выбор хост-компьютера.

2. Создание пустой виртуальной машины.

3. Выделение памяти и мощности процессора.

4. Подключение сетевой карты к соответствующей подсети.

5. Создание и подключение виртуальных жестких дисков.

По завершении этапа 1 (создание виртуальной машины, рис. 1.3) можно перейти к этапу 2, а полученные результаты использовать для продолжения работы.

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

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

1. Подключение к подсети для развертывания операционной системы.

2. Включение виртуальной машины.

3. Ожидание установки операционной системы.

4. Подключение к рабочей подсети.

Рис. 1.3. Поэтапный подход к созданию и настройке виртуальных машин (этап 1)

Созданный на этапе 1 блок для подключения ВМ к подсети можно использовать и на этом этапе (действия 1 и 4). Я не случайно выделил подключение к подсети в отдельный блок: мне уже приходилось решать похожие задачи, и я не раз сталкивался с аналогичной ситуацией. Если объединить все операции, то есть настройку процессора, памяти, сетевой карты и виртуального жесткого диска в один блок, его нельзя будет использовать на других этапах. Повторная настройка процессора и памяти хоть и будет напрасной тратой времени, пройдет без последствий. А вот подключение уже подключенного диска приведет к ошибке. Если вы не учтете этот момент и решите создать единый блок для всех операций, ничего страшного. В любом случае этот опыт будет полезен. Я до сих пор иногда совершаю такие промахи. К тому же, написав отдельный стандартный блок для подключения к подсети, можно вернуться на прошлый этап и обновить соответствующий код.

Развитие проекта на этапе 2 показано на рис. 1.4.

Итак, в работе уже два этапа, и их результаты видны пользователям. Можно собрать от них обратную связь и выяснить, какие настройки включить в план реализации на этапе 3 (рис. 1.5). Например, можно назначить статический IP-адрес, подключить дополнительные диски или выполнить другие действия, которые ранее не планировались. Этап 3 не обязательно должен быть последним. Например, можно предложить этап 4, на котором будут автоматически устанавливаться приложения.

Рис. 1.4. Поэтапный подход к созданию и настройке виртуальных машин (этап 2) с общими элементами

Рис. 1.5. Поэтапный подход к созданию и настройке виртуальных машин (этап 3) с общими элементами

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

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

1.4. Выбор инструмента для работы

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

Например, я не рекомендую использовать Python для настройки ресурсов в Azure. Не потому, что Python плохой инструмент (это совсем не так), а потому, что Python не имеет встроенной поддержки Azure. Конечно, из скрипта на Python можно вызвать Azure CLI, но этот подход не лишен недостатков. Для запуска такого скрипта необходимо установить Azure CLI на компьютер. Но так как это отдельное приложение, а не пакет для Python, потребуются специальные проверки доступности нужных файлов. Кроме того, применение скрипта будет ограничено платформами, на которые можно установить и Python, и Azure CLI. Таким образом, проект усложняется и становится менее переносимым.

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

Я не берусь утверждать, что PowerShell — это универсальный инструмент, но он подойдет для реализации многих проектов. Кроме того, с появлением PowerShell Core круг задач, которые можно автоматизировать при помощи PowerShell, постоянно расширяется. И все-таки в некоторых случаях применение PowerShell не оптимально. Например, если скрипт должен производить вычисления и рисовать графики, лучше использовать Python и библиотеку pandas. Ее возможности на порядок превосходят доступные в PowerShell.

1.4.1. Дерево принятия решений для автоматизации

Как же определить, подходит ли PowerShell для работы над тем или иным проектом? Один из способов показан на рис. 1.6.

Рис. 1.6. Дерево принятия решений, которое позволяет определить, подходит ли PowerShell для конкретного проекта

Используя это дерево, следует рассмотреть все части планируемого проекта. Вернемся к предыдущему примеру с удалением логов и загрузкой архивов в хранилище Azure Blob. Начнем с поиска файлов месячной давности. Анализ этого этапа будет выглядеть примерно так:

• Имеются ли встроенные средства для решения поставленной задачи? Да, в PowerShell есть встроенные средства для работы с файловыми системами.

Поскольку уже на первый вопрос мы ответили «Да», отвечать на другие нет смысла. Таким же образом можно проанализировать несколько следующих действий. Например, для создания файла архива можно задать вопрос:

• Имеются ли встроенные средства для решения поставленной задачи? Да, командлет Compress-Archiveвстроен в PowerShell.

Однако с некоторыми действиями не все так просто. Рассмотрим, например, загрузку файлов в хранилище Azure Blob:

• Имеются ли встроенные средства для решения поставленной задачи? Нет.

• Существуют ли разработанные производителем дополнительные модули для решения поставленной задачи? Да, у Microsoft есть официальный модуль для работы с Azure Blob.

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

1. Имеются ли встроенные средства для решения поставленной задачи? Нет.

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

3. Существуют ли сторонние дополнительные модули для решения поставленной задачи? Да. Модуль dbatools доступен в каталоге PowerShell.

а. Они хорошо поддерживаются и обновляются? Репозиторий GitHub насчитывает более 15 тысяч коммитов и 200 участников. Модули регулярно обновляются.

4. Можно ли создать нужный функционал собственными силами? Можно выполнять запросы SQL непосредственно из PowerShell при помощи встроенного в .NET класса System.Data.SqlClient.

а. Можно ли поддерживать их собственными силами? Между классами SqlClient в .NET и .NET Core есть отличия.

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

1.4.2. Не нужно изобретать велосипед

Одна из замечательных особенностей PowerShell — наличие обширного сообщества, члены которого любят делиться знаниями. На момент написания этой книги в официальном каталоге PowerShell доступно более 6400 дополнительных модулей. PowerShell посвящено множество сайтов, форумов и блогов. Велика вероятность того, что кто-то уже решал такую же или аналогичную задачу.

Нет необходимости создавать скрипты с нуля. Я рекомендую изучить, что сделали другие. Учитесь на их ошибках и опыте. Я сбился со счета, сколько раз я видел код для какой-то задачи и думал: «Почему именно так?» Потом я писал по-своему, сталкивался с проблемами и понимал, почему мне советовали сделать так, а не иначе.

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

1.4.3. Дополнительные инструменты

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

Мы часто будем говорить о том, что нет причин не использовать разные инструменты. Например, в главе 3 мы рассмотрим несколько планировщиков задач, а в главе 11 используем SharePoint, чтобы создать для скрипта интерфейс.

Планировщик задач

В PowerShell нет встроенного планировщика задач. До версии 6.0 поддерживался командлет Register-ScheduledJob, при помощи которого можно было настроить скрипт для запуска планировщиком задач Windows. Затем этот командлет был удален, чтобы обеспечить кросс-платформенную поддержку PowerShell Core. Конечно, можно по-прежнему использовать планировщик задач Windows и Cron в Linux, но есть и другие инструменты, специально предназначенные для автоматизации.

Те, кто уже работает с Jenkins, Ansible, Control-M и другими подобными средствами, смогут использовать их для выполнения скриптов PowerShell. При этом система автоматизации не будет зависеть от конкретной платформы. Созданный, например, в IFTTT или System Center Orchestrator проект нельзя перенести на другую платформу. И если выбранная платформа устареет, изменится ее функциональность или схема лицензирования, единственным выходом станет создание нового проекта при помощи других средств. Если же изначально использовать PowerShell и Jenkins, готовые скрипты можно будет с минимальными усилиями перенести, например, на Ansible.

Интерфейс

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

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

1.5. Что необходимо для начала работы

Несмотря на то что PowerShell Core — это кросс-платформенный инструмент, большинство примеров из этой книги будут выполняться в Windows. Я рекомендую использовать Windows 11 или Windows Server 2022, но можно работать и в других версиях с поддержкой Windows PowerShell 5.1 и PowerShell 7. В отсутствие дополнительных указаний следует считать, что все примеры написаны на PowerShell 7.

Для написания кода также понадобится интегрированная среда разработки. Много лет в качестве таковой применялась PowerShell ISE, но она не поддерживает PowerShell 7. Поэтому я настоятельно рекомендую перейти на Visual Studio Code (VS Code). В отличие от традиционной Visual Studio, VS Code — это бесплатный и легкий редактор с открытым исходным кодом, кросс-платформенный и с активным сообществом пользователей. Кроме того, он поддерживает большинство распространенных языков программирования и сценариев, в том числе Windows PowerShell и PowerShell, с которыми можно работать одновременно.

PowerShell — универсальный язык, который можно использовать на разных платформах, включая Windows, Linux, macOS, серверы, контейнеры, сторонние платформы и многие облачные системы. Можно создавать скрипты не только для запуска на этих платформах, но и для управления ими. На момент написания этой книги особой популярностью пользуются контейнеры. Однако никто не знает, что будет через год или даже месяц. Поэтому все примеры из следующих глав рассчитаны на локальные ресурсы.

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

Выбранные для рассмотрения примеров облачные и сторонние платформы, в том числе Jenkins, Azure, SharePoint и GitHub, либо бесплатны, либо предоставляют пробный бесплатный доступ. Более подробные сведения об использованных средах и инструментах приведены в приложении.

Итоги

• PowerShell — это мощный язык высокого уровня, специально предназначенный для автоматизации. Его очень просто освоить и начать применять.

• При помощи PowerShell можно создавать стандартные блоки, которые потом можно повторно использовать в других скриптах, в том числе разработанных другими членами команды.

• Для успешной автоматизации важно уметь осмысливать процесс и планировать будущее.

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

• PowerShell можно использовать вместе с другими инструментами и платформами, что значительно расширяет его возможности.

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

2. Начало автоматизации

В этой главе

• Применение концепции поэтапной автоматизации

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

• Сохранение функций в виде модуля

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

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

2.1. Удаление старых файлов (первые стандартные блоки)

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

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

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

Рис. 2.1. Алгоритм скрипта для удаления файлов (первый этап): определение параметров и выполнение необходимых действий — поиск, архивация и удаление файлов

Сначала необходимо понять, какие переменные будут нужны. Это поможет определить параметры будущего скрипта. В данном случае нам потребуются:

• папка, в которой находятся логи;

• место для сохранения файла с архивом;

• имя файла с архивом;

• время хранения лога до переноса в архив.

Первые два вопроса — о папке с логами и месте хранения архива — довольно просты. В обоих случаях нужно ввести пути к папкам. Другие вопросы требуют более тщательного обдумывания.

Известно, что нужно отфильтровать логи по дате, чтобы отправить в архив только то, что следует. Чтобы выбрать файлы старше 30 дней, можно отнять 30 от текущей даты. В PowerShell для этого можно передать отрицательное число методу AddDays объекта DateTime. Чтобы создать код, пригодный для применения в других скриптах, значение для фильтра по дате следует передавать в виде параметра. Однако при этом нужно учесть еще несколько моментов.

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

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

Все перечисленные способы могут работать, но мы используем самый простой, а потому наиболее защищенный от ошибок согласно принципу KISS (keep it short and simple)2. Если в дальнейшем окажется, что пользователи часто запускают скрипт с отрицательным параметром, можно изменить код и усложнить проверку. Именно в этом и состоит поэтапный подход: готовый скрипт всегда можно развить и дополнить.

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

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