diff --git a/README.md b/README.md index 66ff976..b356707 100644 --- a/README.md +++ b/README.md @@ -1 +1 @@ -Ever wonder why PowerShell is a thing, or find yourself having to explain it to someone else? Here's a concise guide that does just that. \ No newline at end of file +Ви коли небудь замислювались чому саме PowerShell, або були в ситуації коли вам необхідно пояснити це комусь іншому? До вашої уваги короткий довідник який містить саме цю інформацію. \ No newline at end of file diff --git a/SUMMARY.md b/SUMMARY.md index 22f4bc7..5985419 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -1,10 +1,10 @@ -# Summary +# Зміст * [ReadMe](README.md) -* [About this Book](manuscript/About.md) -* [A Brief Overview](manuscript/chapter1.md) -* [Why Scripting? Why a Shell?](manuscript/chapter2.md) -* [Why PowerShell?](manuscript/chapter3.md) -* [The Business Story](manuscript/chapter4.md) -* [Where Can You Learn More?](manuscript/chapter5.md) -* [Why PowerShell Remoting? (While we're answering "Whys")](manuscript/chapter6.md) \ No newline at end of file +* [Про книгу](manuscript/About.md) +* [Короткий опис](manuscript/chapter1.md) +* [Навіщо писати скрипти? Чому саме Shell?](manuscript/chapter2.md) +* [Чому саме PowerShell?](manuscript/chapter3.md) +* [Бізнес історія](manuscript/chapter4.md) +* [Де дізнатися більше?](manuscript/chapter5.md) +* [Віддалене керування через PowerShell? ( Відповідаємо на всі гарячі питання)](manuscript/chapter6.md) diff --git a/manuscript/About.md b/manuscript/About.md index 1664aad..96a3311 100644 --- a/manuscript/About.md +++ b/manuscript/About.md @@ -1,21 +1,21 @@ -# Why PowerShell? +# Чому саме PowerShell? -By Warren Frame and Don Jones +Уоррен Фрейм та Дон Джонс. --- -An incredibly concise look at why Windows PowerShell is important, from both a technical and business perspective. +Неймовірно стислий виклад на тему чому Windows PowerShell є важливим, як з технічної, так і з бізнес точки зору. --- -This guide is released under the Creative Commons Attribution-NoDerivs 3.0 Unported License. The authors encourage you to redistribute this file as widely as possible, but ask that you do not modify the document. +Даний довідник випущений під ліцензією Creative Commons Attribution-NoDerivs 3.0. Автори заохочують розповсюдження даного файлу якомога більше, але без внесення змін до документу. -**Was this book helpful?** The author(s) kindly ask(s) that you make a tax-deductible (in the US; check your laws if you live elsewhere) donation of any amount to [The DevOps Collective](https://devopscollective.org/donate/) to support their ongoing work. +**Чи була ця книга корисною?** Автор(и) люб'язно просять зробити пожертву, яка підлягає оподаткуванню (в США; уважно читайте закони, якщо живете в інших куточках світу) будь-якого розміру для [The DevOps Collective](https://devopscollective.org/donate/) для підтримки їхньої поточної роботи. -**Check for Updates!** Our ebooks are often updated with new and corrected content. We make them available in three ways: +**Перевірте наявність оновлень!** Наші електронні книжки часто оновлюються новим та виправленим вмістом. Ми розповсюджуємо їх трьома способами: -* Our main, authoritative [GitHub organization](https://github.com/devops-collective-inc), with a repo for each book. -* Our [GitBook page](https://www.gitbook.com/@devopscollective), where you can browse books online, or download as PDF, EPUB, or MOBI. Using the online reader, you can link to specific chapters. -* On [LeanPub](https://leanpub.com/u/devopscollective), where you can download as PDF, EPUB, or MOBI (login required), and "purchase" the books to make a donation to DevOps Collective. You can also choose to be notified of updates. +* Наша основна, авторитетна [GitHub організація](https://github.com/devops-collective-inc), яка містить окремий репозиторій для кожної книги. +* Наша [GitBook сторінка](https://www.gitbook.com/@devopscollective), де ви можете переглядати книги онлайн або завантажити у форматі PDF, EPUB або MOBI. Використовуючи онлайн-читач, ви можете посилатися на конкретний розділ книги. +* На [LeanPub](https://leanpub.com/u/devopscollective), де ви можете завантажити PDF, EPUB або MOBI (необхідний логін) та "придбати" книги, щоб зробити пожертву для DevOps Collective. Ви також можете отримувати повідомлення про оновлення. -GitBook and LeanPub have slightly different PDF formatting output, so you can choose the one you prefer. LeanPub can also notify you when we push updates. Our main GitHub repo is authoritative; repositories on other sites are usually just mirrors used for the publishing process. GitBook will usually contain our latest version, including not-yet-finished bits; LeanPub always contains the most recent "public release" of any book. +GitBook та LeanPub мають дещо різне форматування PDF, тому ви можете вибрати той, який вам більше до вподоби. LeanPub також може повідомляти вас, коли ми публікуємо оновлення. Наш головний GitHub репозиторій є авторитетним; репозиторії на інших сайтах, як правило, є лише дзеркалами, які використовуються для процесу публікації. GitBook зазвичай міститиме останню версію, включаючи ще не закінчені уривки; LeanPub завжди містить найновіший "публічний реліз" будь-якої книги. diff --git a/manuscript/chapter1.md b/manuscript/chapter1.md index 41d8e96..5c1afbd 100644 --- a/manuscript/chapter1.md +++ b/manuscript/chapter1.md @@ -1,9 +1,10 @@ -# A Brief Overview +# Короткий опис -PowerShell enthusiasts often find themselves explaining why someone with responsibilities on the Microsoft side of the IT shop should learn PowerShell. We decided to write this as a reference going forward. +PowerShell eнтузіасти часто опиняються в ситуації коли потрібно пояснити чому хтось хто відповідальний за Microsoft інфраструктуру повинен вчити PowerShell. Ми вирішили написати цю книгу як довідку для майбутніх звернень. -We won’t be arguing for PowerShell over other Microsoft languages such as VBScript or batch, or general purpose languages such as Python or Perl. There is a place for all of these languages, but if you work with the Microsoft and surrounding ecosystems, PowerShell is an important language to learn. +Ми не будемо сперечатися щодо PowerShell та інших мов Microsoft, таких як VBScript або batch, а також мов програмування загального призначення, таких як Python або Perl. +Всі ці мови мають право на існування, але якщо ви працюєте з Microsoft та прилеглими екосистемами, PowerShell є важливою мовою для вивчення. -What's also important to understand is that _Microsoft has made an enormous commitment to PowerShell_. It isn't going away, and indeed the company is building more and more of their management solutions on top of it. To a degree, Microsoft is even backing off from building management tooling, knowing that you can use PowerShell to build your own tools. That's significant. +Також важливо зрозуміти, що _Microsoft взяли на себе величезні зобов'язання щодо PowerShell_. PowerShell нікуди не пропаде і справді компанія будує все більше і більше своїх рішень для керування на ньому. Певною мірою Microsoft навіть відступає від створення інструментів управління, знаючи, що ви можете використовувати PowerShell для створення власних інструментів. Цей факт має досить велике значення. -But let's move on. +Але давайте перейдемо до наступного розділу. diff --git a/manuscript/chapter2.md b/manuscript/chapter2.md index d4bbd17..75fc7be 100644 --- a/manuscript/chapter2.md +++ b/manuscript/chapter2.md @@ -1,16 +1,16 @@ -# Why Scripting? Why a Shell? +# Навіщо писати скрипти? Чому саме Shell? -Before we dive into PowerShell itself, let’s tackle the importance of scripting and automation, an integral facet of PowerShell. +Перш ніж ми зануримось у PowerShell, давайте розглянемо його невід'ємний аспект, важливість скриптування та автоматизації. -You’ve probably seen this [XKCD comic](http://xkcd.com/1205/) or something similar to justify scripting. While saving time is certainly a factor behind the importance of scripting and automation, it is hardly the only justification. +Напевно, ви бачили цей [комікс з XKCD](http://xkcd.com/1205/) або щось подібне, для зображення важливості скриптування. Безумовно економія часу є важливим фактором в підтримку скриптування та автоматизації, але далеко не єдиним. -Here are a few others to consider: +Ось декілька інших на які потрібно звернути увагу: -* **Consistency**. A scripted solution will run the exact same script every time. No risk of typos, forgetting to complete the task, or doing the task incorrectly. _Reduce human error_. -* **Audit trail**. There are many tasks where having an audit trail would be helpful, perhaps including what task was performed, important results, errors that occurred, when the task ran, who ran it, and so forth. Scripts can provide this trail, and in PowerShell v5 and later, the shell itself features extensive logging capabilities. -* **Modular code**. You might spend more time on a particular function than time savings justify, but you can generally re-use or borrow ideas from the code later. -* **Documentation**. Is there documentation for the task? Is it up to date? A well written and commented script can generally serve as a helpful base level of documentation that might not exist for a manual task. In some cases, the script can document the process that it automates, helping to preserve institutional knowledge. -* **Education**. Administrators who can automate tasks are almost always more well-versed in the technology as a result. That makes them better planners, architects, troubleshooters, and operators, all of which convey benefit to the organization. -* **Delegation**. With a scripted solution, you can typically delegate more functions closer to the teams best equipped to handle them. With PowerShell v3 and later specifically, scripts can enable extremely granular delegation of tasks, helping the overall IT team become more efficient and responsive. +* **Послідовність**. Розроблене рішення буде запускати ту саму послідовність дій кожного разу. Немає ризику опечаток, виконання завдання не повністю або неправильно. _Зменшення впливу людського фактору_. +* **Записи для аудиту**. Існує багато завдань, де присутність аудиту була б корисною, наприклад яке завдання було виконано, важливі результати, помилки, які виникли під час виконання, хто його виконував тощо. Скрипти можуть забезпечити ці записи, і PowerShell v5 та пізніші версії мають широкі можливості для логування. +* **Модульний код**. Ви можете витратити більше часу на певну функцію ніж зекономити, але, як правило, ви можете повторно використати чи запозичити ідеї з коду функції в майбутньому. +* **Документація**. Чи існує документація на завдання? Вона актуальна? Добре написаний та прокоментований скрипт, як правило є корисним базовим рівнем документації, яка не завжди існує для завдання яке виконується вручну. У деяких випадках скрипт документує процес, який він автоматизує, допомагаючи зберегти інституційні знання. +* **Навчання**. Адміністратори які можуть автоматизовувати завдання, як правило більше розуміються в технології. Це робить їх кращими планувальниками, архітекторами, тими хто вирішує проблеми та операторами, що в свою чергу приносить користь організації. +* **Делегування**. Зазвичай, за допомогою розробленого рішення можна делегувати більше функцій командам, які найбільше готові для вирішення проблем. Починаючи з PowerShell v3 скрипти забезпечують надзвичайно детальне делегування завдань, допомагаючи загальній ІТ-команді стати більш ефективною та адаптивною. -The moral of the story is that scripting and automation is important, which is just one factor behind the value of learning PowerShell. +Мораль розповіді полягає в тому, що скриптування та автоматизація є важливими, і є лише одним із факторів, що стоять за цінністю вивчення PowerShell. diff --git a/manuscript/chapter3.md b/manuscript/chapter3.md index 0b02623..2457c4b 100644 --- a/manuscript/chapter3.md +++ b/manuscript/chapter3.md @@ -1,45 +1,45 @@ -# Why PowerShell? +# Чому саме PowerShell? -Microsoft describes PowerShell as “a task-based command-line shell and scripting language… built on the .NET Framework.” What is so great about PowerShell? Why should you use it? +Microsoft описує PowerShell як "оболонка командного рядка орієнтована на виконнання завдань та мова скриптування ..., побудована на .NET Framework". Що такого прекрасного в PowerShell? Навіщо його використовувати? -## PowerShell is both a command-line shell and scripting language +## PowerShell - це оболонка командного рядка і мова скриптування -Fight fires quickly using existing or custom PowerShell commands or scripts at the shell, no need to compile code. Develop your code at the command line before creating a function or script around it. Write quick and dirty scripts that you will use a single time or a handful of times. Write formal, readable, production level scripts that will maintain your services for years. +Гасіть пожежі швидко , використовуючи існуючі або власні команди PowerShell чи скрипти в оболонці, без компіляції коду. Розробляйте свій код у командному рядку, перш ніж створити навколо нього функцію чи скрипт. Пишіть швидкі та недосконалі скрипти, які ви будете використовувати один чи декілька разів. Пишіть формальні, читабельні скрипти виробничого рівня, які підтримуватимуть ваші сервіси роками. -What is the cost of this investment? Learning PowerShell. Pretty reasonable, considering you will likely need to do so regardless of your current language of choice, assuming you work with the Microsoft ecosystem. +Яка вартість цієї інвестиції? Вивчення PowerShell. Досить розважливе рішення, враховуючи що вам скоріше за все прийдеться це зробити незалежно від вашого поточного вибору мови скриптування, якщо ви працюєте з екосистемою Microsoft. -## PowerShell can interact with a dizzying number of technologies. +## PowerShell взаємодіє з запаморочливою кількістю технологій. -The .NET Framework, the Registry, COM, WMI, ADSI. Exchange, Sharepoint, Systems Center, Hyper-V, SQL. VMware vCenter, Cisco UCS, Citrix XenApp and XenDesktop. REST APIs, XML, CSV, JSON, websites, Excel and other Office applications. C# and other languages, DLLs and other binaries, including Linux or Unix tools. A language that can work with and integrate these various technologies can be incredibly valuable. +.NET Framework, реєстр, COM, WMI, ADSI. Exchange, Sharepoint, Systems Center, Hyper-V, SQL. VMware vCenter, Cisco UCS, Citrix XenApp and XenDesktop. REST API, XML, CSV, JSON, вебсайти, Excel та інші програми Office. C# та інші мови, DLL та інші бінарні файли, включаючи інструменти Linux чи Unix. Мова, котра може працювати та інтегрувати різні технології, може бути неймовірно цінною. -Windows is not text based. Sooner or later you will need to do something that you can’t do with -nix tools and other text based languages. Many of the technologies that PowerShell can interact with simply do not have text based interfaces, and may not even be directly accessible from more formal languages like Perl or Python. +Windows не базується на текстовій основі. Рано чи пізно вам потрібно буде зробити щось, чого ви не можете зробити за допомогою інструментів -nix та інших мов побудованих на текстовій основі. Багато технологій, з якими PowerShell може взаємодіяти, не мають інтерфейсів на текстовій основі та не можуть бути безпосередньо доступними за домогою офіційних мов, таких як Perl або Python. -The moral here is that PowerShell is the best "glue" Microsoft has ever provided us for tying together disparate systems. It's better than previous Windows-based shells because it understands, and works with, the API-based nature of Windows itself, which is vastly different from what previous text-based shells did. +Мораль - PowerShell найкращий «клей» створений Microsoft для з’єднання разом різних систем. Це краще, ніж попередні оболонки на основі Windows, оскільки PowerShell розуміє і працює з самою системою Windows на основі API, що сильно відрізняється від попередніх оболонок на текстовій основі. -## PowerShell is object-based. -This gives us incredible flexibility. Filter, sort, measure, group, compare or take other actions on objects as they pass through the pipeline. Work with properties and methods rather than raw text. +## Об'єкти є основою PowerShell +Це дає нам неймовірну гнучкість. Фільтрувати , сортувати, вимірювати, групувати, порівнювати чи проводити інші дії над об’єктами під час їхнього проходження через пайплайн. Працювати з властивостями та методами, а не з необробленим текстом. -If you have spent time deciphering and programmatically working with text based output, you know how frustrating it can be. What delimiter do I split on? Is there even a delimiter? What if a particular result has a blank entry for a column? Do I need to count characters in each column? Will this count vary depending on the output? With objects, this is all done for you, and makes it quite simple to tie together commands and data across various technologies. +Якщо ви витрачали час на розшифрування та програмну роботу з текстовим виводом, ви прекрасно знаєте, як це може дратувати.Який розділювач використовувати для розбивання? Чи існує розділювач взагалі? Що робити, якщо для певний результат має порожній запис в стовпці? Чи потрібно мені рахувати символи в кожному стовпчику? Чи буде кількість змінюватися залежно від результату? З об’єктами це все вже зроблено для вас, і спрощує з'єднанання команд та даних поміж різних технологій. -## PowerShell isn’t going away. -Microsoft is putting its full weight behind PowerShell. +## PowerShell нікуди не пропаде +Microsoft повністю підтримує та просуває PowerShell. -PowerShell support is a requirement in the Microsoft Common Engineering Criteria, and a Server product cannot be shipped without a PowerShell interface. That means very few Microsoft server products can't be managed by PowerShell - and the few that can't, will be able to soon. +Підтримка PowerShell є вимогою в загальних інженерних критеріях Microsoft, і серверний продукт не випускається без інтерфейсу PowerShell. Це означає, що дуже мало серверних продуктів Microsoft не підтримують керування через PowerShell, але навіть дані продукти будуть підтримувати його незабаром. -Vendors other than Microsoft have strong support for PowerShell. This includes IBM, Cisco, Citrix, VMware, NetApp, Dell, and dozens more. +Окрім Microsoft інші виробники також мають сильну підтримку PowerShell. Такі як IBM, Cisco, Citrix, VMware, NetApp, Dell та ще десятки інших. -In many cases Microsoft uses PowerShell to build the GUI management consoles for its products. Some tasks can’t be performed in the GUI and can only be completed in PowerShell. This is a big deal: In an increasing number of situations, _you can't manage the product fully unless you use PowerShell._ That applies to cloud-based offerings like Azure and Office 365, too. +У багатьох випадках Microsoft використовує PowerShell для побудови консолей управління з графічним інтерфейсом для своїх продуктів. Деякі завдання не можливо виконати в графічному інтерфейсі, натомість їх можна виконати лише в PowerShell. Це дуже важлива деталь: у зростаючій кількості ситуацій ви _не можете керувати продуктом повноцінно, якщо не використовуєте PowerShell_. Це також стосується хмарних послуг, таких як Azure та Office 365. -## Consolidate and multiply your learning +## Зміцніть та розширте ваше навчання -Your reward for learning PowerShell is the improved ability to control and automate the many technologies it integrates with. You can use the same set of commands to filter, export, redirect, modify, extend, and perform actions against output for all of these technologies. You can pick up PowerShell skills and take them in any direction you need - Hyper-V, vCenter, SQL, AD, XenApp, and more. +Нагородою за вивчення PowerShell - є вдосконалена здатність контролювати та автоматизувати безліч технологій, з якими вона інтегрується. Ви можете використовувати один і той же набір команд для фільтрування, експорту, перенаправлення, модифікації, розширення та виконання маніпуляцій з виводом з усіх цих технологій. Ви можете вивчити основи PowerShell та спямувати їх у будь-якому потрібному вам напрямку - Hyper-V, vCenter, SQL, AD, XenApp тощо. -Your reward for learning specific tools or executables such as net.exe or schtasks.exe, is the ability to work with those specific tools. With PowerShell, your learning investment blossoms into an enormous ecosystem of capability. +Нагородою за вивчення конкретних інструментів або програм, таких як net.exe або schtasks.exe є можливість працювати тільки з цими конкретними інструментами. Завдяки PowerShell, ваші інвестиції в навчання перетворюються на величезну екосистему здібностей. -## In Windows, PowerShell's really the only option -VBScript is deprecated, and you're not going to see further development. VBScript was already anemic in terms of the things it could "touch," making it a poor "glue" for connecting systems and processes. +## В Windows, PowerShell - це єдиний варіант +VBScript застарілий, і ви не побачите його подальший розвиток. VBScript був не надто потужним з точки зору речей, до яких він міг "торкатися", що робить його недосконалим "клеєм" для підключення систем і процесів. -And nothing else even came close to VBScript. Python, Perl, you name it - they're great on Linux, a predominantly text-based OS, but they were nigh-useless on Windows, since they couldn't access the many and varied APIs Windows uses for management. +Більше ніяка технологія навіть не змогла наблизитись до функціоналу VBScript. Python, Perl, та інші - є чудовими для Linux (переважно текстова ОС), але вони були майже непотрібними в Windows, оскільки вони не могли отримати доступ до багатьох та різноманітних API, які Windows використовує для управління. -PowerShell consolidates all of those APIs into a single, largely-consistent interface that's focused on systems operations and administration. +PowerShell об'єднує всі ці API в єдиний, значною мірою сумісний інтерфейс, орієнтований на системні операції та адміністрування. diff --git a/manuscript/chapter4.md b/manuscript/chapter4.md index 7f63979..0718d71 100644 --- a/manuscript/chapter4.md +++ b/manuscript/chapter4.md @@ -1,17 +1,18 @@ -# The Business Story +# Бізнес історія -If you've ignored PowerShell up until now, or were skeptical about it, let's look at what Microsoft has done. +Якщо ви досі ігнорували PowerShell або ставились до цього скептично, давайте розглянемо, що зробили Microsoft. -In **version 1**, PowerShell emerged as a the first management interface specifically designed for administrative automation. +У **версії 1**, PowerShell з'явився як перший інтерфейс управління, спеціально розроблений для автоматизації адміністративних задач. -In **version 2**, PowerShell gained native remote management capabilities, enabling remote management of any server or client running PowerShell. PowerShell's "reach" extended to hundreds of management APIs, enabling real-world management. The product also matured a deceptively simple, powerful scripting language that can be used to build professional-grade units of automation. +У **версії 2** PowerShell отримав вбудовані можливості віддаленого управління, котрв дозволяють віддалене управління будь-яким сервером чи клієнтом, який підтримує PowerShell. Охоплення PowerShell поширилось на сотні API управління, які дозволяли управління в існуючому середовищі. +Продукт досягнув зрілості як на перший погляд проста, потужна мова скриптування, яку можна використовувати для створення одиниць автоматизації професійного рівня. -In **version 3**, PowerShell learned to run long-running tasks in a disconnected, stateless fashion - called _workflows_. The product's reach extended even further, covering all major Microsoft server platforms, and pushing into Microsoft's cloud offerings. By this version, PowerShell was a very real thing, so much so that many Microsoft native GUIs began to use PowerShell "under the hood." +У **версії 3** PowerShell навчився виконувати довготривалі завдання за домогою способів відключення та відсутності даних про попередній стан, які називаються робочі цикли. Доступність продукту ще більше розширилась, охоплюючи всі основні серверні платформи Майкрософт і ініціативно проштовуючи хмарні пропозиції Microsoft. В часи цієї версії PowerShell був настільки цінним та важливим, що багато рідних графічних інтерфейсів Microsoft почали використовувати PowerShell "під капотом". -In **version 4**, PowerShell was extended with even more "reach," and gained a new technology: Desired State Configuration. DSC lets administrators describe, in more-or-less plain text, how a computer should be configured. Leveraging the existing investment in PowerShell, DSC then puts the machine into that state, and _keeps_ it there. +У **версії 4** PowerShell був розширений ще більшим "охопленням" та отримав нову технологію: Бажана Конфігурація Стану. DSC (Desired State Configuration Бажана Конфігурація Стану - прим. перекладача) дозволяє адміністраторам описати більш-менш простим текстом, як повинен бути налаштований комп'ютер. Використовуючи існуючий функціонал PowerShell DSC переводить машину в бажаний стан та _зберігає_ її в ньому. -In **version 5**, PowerShell matured DSC and extended its "tool making" capabilities into professional developer space. With support in Visual Studio, PowerShell started to span a much broader spectrum of user, from entry-level administrators to advanced developers. +У **версії 5** PowerShell DSC досягнув зрілості та розширив свої можливості "створення інструментів" для професійних розробників. З підтримкою в Visual Studio, PowerShell почав охоплювати значно ширший спектр користувачів, від адміністраторів початкового рівня до досвідчених розробників. -The point is that Microsoft has _clearly_ been building PowerShell since its v1 release in 2006. They've done so in a way that _they've never done before_ in languages like VBScript, and they've done so while maintaining consistency and efficiency. +Справа в тому, що Microsoft _очевидно_ розвивав PowerShell з моменту випуску v1 в 2006 році. Вони зробили це в такий спосіб, який _раніше не використовували_ на таких мовах, як VBScript, зберігаючи послідовність та ефективність. -What's more, PowerShell has inspired a broad ecosystem of supporting vendors, and an enthusiastic global community. Administrators are, more than ever, able to get assistance, answers, and even ready-made solutions from those vendors and that community. +Більше того, PowerShell надихнув широку екосистему підтримки виробників та завзяту глобальну спільноту. Як ніколи, адміністратори можуть отримати допомогу, відповіді та навіть готові рішення від виробників та громади. diff --git a/manuscript/chapter5.md b/manuscript/chapter5.md index b69fffb..1ce6716 100644 --- a/manuscript/chapter5.md +++ b/manuscript/chapter5.md @@ -1,9 +1,9 @@ -# Where can you learn more? +# Де дізнатись більше? -There is a wealth of information on PowerShell. +Існує багато інформації про PowerShell. -* Start at [PowerShell.org](http://powershell.org), a community-owned and operated web site that hosts a friendly Q&A forum. The organization also offers numerous [free ebooks](http://powershell.org/wp/ebooks), runs the annual [PowerShell Summit](http://powershellsummit.org) event in North America and Europe, hosts a DSC GitHub repository, runs an annual Scripting Games contest, and much more. -* Anyone with development or scripting experience should pick up [PowerShell in Action v2](http://www.manning.com/payette2/). It’s written by the co-designer and principle author of PowerShell, Bruce Payette, and is the standard reference. It provides the best depth you will get short of verbose articles on the web, gives insight into some of the design decisions behind the language, and is perfectly applicable today despite being written for PowerShell v2. Windows PowerShell for Developers is more narrowly focused but a good read for the experienced. -* Those without scripting or development experience might want to start with lighter reading, such as [Learn Windows PowerShell in a Month of Lunches](http://manning.com/jones3/). -* Want to learn on the fly? PowerShell includes everything you need to learn directly from the shell. Get-Command, Get-Help, Get-Member, and Select-Object will get you exploring and learning PowerShell. -* Prefer videos? Product inventor Jeffrey Snover and Jason Helmick hosted two free PowerShell sessions that have proven quite popular: [Getting Started with PowerShell 3.0](http://channel9.msdn.com/Series/GetStartedPowerShell3) and [Advanced Tools and Scripting with PowerShell 3.0](http://channel9.msdn.com/Series/advpowershell3). Or, check out the [PowerShell.org YouTube channel](http://youtube.com/powershellorg), featuring technical videos and session records from every PowerShell Summit event. +* Почніть з [PowerShell.org](http://powershell.org), веб-сайту, що належить громаді, і де розміщується дружній форум питань та відповідей. Організація також пропонує численні безкоштовні електронні книги, проводить щорічну подію PowerShell Summit у Північній Америці та Європі, володіє репозиторієм DSC GitHub, проводить щорічний конкурс Scripting Games та багато іншого. +* Будь хто з досвідом розробки або скриптування, повинен прочитати [PowerShell in Action v2](http://www.manning.com/payette2/). Книга написана співавтором архітектури та основи PowerShell, Брюсом Пайєт, і є стандартним довідником. Вона надає дуже детальні дані, котрі ви не знайдете навіть в статтях в Інтернеті, пояснює деякі дизайнерські рішення, що стоять за цією мовою, і є цілком актуальною сьогодні, незважаючи на те, що написана вона була для PowerShell v2. Windows PowerShell для розробників є більш вузько спеціалізованою, але є хорошим матеріалом для прочитання для досвідчених. +* Ті, хто не має досвіду скриптування чи розробки, можуть почати з легшого матеріалу, такого як [Learn Windows PowerShell in Month Lunches](http://manning.com/jones3/). +* Бажаєте вчитися на льоту? PowerShell включає все необхідне для навчання безпосередньо з оболонки Get-Command, Get-Help, Get-Member та Select-Object допоможуть вам пізнати та вивчити PowerShell. +* Віддаєте перевагу відео? Винахідник продукту Джеффрі Сновер та Джейсон Хелмік провели дві безкоштовні сесії PowerShell, які виявилися досить популярними: [Getting Started with PowerShell 3.0](http://channel9.msdn.com/Series/GetStartedPowerShell3) та [Advanced Tools and Scripting with PowerShell 3.0](http://channel9.msdn.com/Series/advpowershell3). Або перегляньте [YouTube канал PowerShell.org](http://youtube.com/powershellorg), на якому представлені технічні відео та записи сесій з усіх подій PowerShell Summit. diff --git a/manuscript/chapter6.md b/manuscript/chapter6.md index 1330454..b5a8da5 100644 --- a/manuscript/chapter6.md +++ b/manuscript/chapter6.md @@ -1,33 +1,33 @@ -# Why PowerShell Remoting? (While We're Answering "Whys") +# Віддалене керування через PowerShell? ( Відповідаємо на всі "Чому") -Another big question that comes along is, "why should we enable PowerShell Remoting?" +Ще одне велике питання, яке виникає - "чому ми повинні включати віддалене керування через PowerShell ?" -First, understand a couple of things - which are going to seem a bit rude. Sorry. -- PowerShell Remoting has been around since 2008. If you're seriously just asking yourself this now, then you're doing a poor job of managing your IT environment. Also released since 2008 were smart watches, Microsoft (formerly Windows) Azure, the Tesla Roadster, Disney's "Frozen," affordable LED light bulbs, and the iPhone 3G, 3GS, 4, 4S, 5, 5S, and 6 models. Just in case you missed those as well. -- Information technology is an industry of change. The perfectly reasonable decisions you made in 2003 are going to need to be periodically revisited, due to aforementioned change. +Спершу зрозумійте пару речей - які здадуться трохи грубими. Вибачте. +- Віддалене керування через PowerShell існує з 2008 року. Якщо ви серйозно задаєтесь цим питанням лише зараз, значить ви погано справляєтесь з управлінням свого ІТ-середовища. Також з 2008 року були випущені смарт-годинники, Microsoft (раніше Windows) Azure, Тесла Родстер, "Крижане серце" від Діснея, доступні світлодіодні лампочки, а також iPhone моделі 3G, 3GS, 4, 4S, 5, 5S та 6. Про всяк випадок, якщо ви раптом і їх пропустили. +- Інформаційні технології - це галузь змін. Цілком розважливі рішення, які ви прийняли у 2003 році, необхідно періодично переглядати через вищезазначені зміни. -With that out of the way, let's briefly talk about... -## What is PowerShell Remoting? -Remoting is simply a way for management tools on one computer to talk to services on another computer, so that you can remotely manage those services. +Так з цим розібрались, тепер давайте коротко поговоримо про... +## Що таке віддалене керування через PowerShell? +Віддалене керування - це простий спосіб для інструментів управління на одному комп'ютері спілкуватись з сервісами на іншому комп'ютері дозволяючи вам віддалене керування цими сервісами. -Remoting is based on HTTP, and uses a protocol called WS-Management (WS-MAN). It requires servers to have a single open port, and routes all incoming management traffic through that one port. WS-MAN traffic can be logged, can be proxied through security servers (provided by third parties), and can be completely encrypted by means of SSL. +Віддалене керування базується на HTTP та використовує протокол під назвою WS-Management (WS-MAN). Він вимагає, щоб сервери мали єдиний відкритий порт, і маршрутизували весь вхідний трафік для управління через цей один порт. Трафік WS-MAN може логуватись, маршрутизуватись через сервери безпеки (надані третьою стороною) і може бути повністю зашифрований за допомогою SSL. -Like all HTTP traffic, Remoting is essentially transmitting text back and forth. Remoting simply specifies a way for that text to be laid out (predominantly in an XML variant) so that tools and services can understand each other. +Як і увесь HTTP трафік , віддалене керування по суті передає текст туди і назад. Віддалене керування просто визначає спосіб представлення цього тексту (переважно у XML варіанті ), щоб інструменти та служби могли зрозуміти один одного. -Remoting does not in any way affect the security of your network under default conditions. It does not, by default, transmit usernames or passwords - encrypted or otherwise. In a non-domain environment, you can create an environment where passwords would be transmitted, but it really wants that to be encrypted by SSL, so you'd be using HTTPS. +Віддалене керування жодним чином не впливає на безпеку вашої мережі при налаштуваннях за замовчуванням. За замовчуванням імена користувачів чи паролі (зашифровані чи в якомусь іншому вигляді) не передаються. У недоменному середовищі ви можете створити середовище, в якому будуть передаватися паролі, але вимагається, щоб вони було зашифровані SSL, тобто ви будете використовувати HTTPS. -Remoting doesn't in any way give anyone special privileges. The technology literally can't let someone do something they don't have permission to do, unless you've gone through a rather complex setup for something called _delegated administration_. In that case, you can enable specific users to perform specific tasks that they wouldn't normally be able to - but only through the specific channel and interface you've set up. +Віддалене керування ні в якому разі не надає нікому особливих прав. Технологія буквально не може дозволити комусь робити те, на що вони не мають дозволу, звичайно якщо ви не пройшли досить складну процедуру для налаштування делегованого адміністрування. У такому випадку ви можете дозволити конкретним користувачам виконувати конкретні завдання, які для них зазвичай не є дозволеними, але лише через визначений канал та інтерфейс, який ви створили. -## Comparing Remoting to what came before -Before Remoting, most Windows remote management was conducted over Remote Procedure Calls, or RPCs. These usually employed port-hopping, making them incredibly difficult to manage through a firewall. Contrast that with the one port you have to deal with in Remoting. +## Порівняння віддаленого керування з тим, що було раніше +До появи віддаленого керування більшість дистанційного керування у Windows здійснювалося через віддалений виклик процедур або RPC. Зазвичай вони застосовують перехідні порти, що значно ускладнює їхнє управління через брандмауер. На відміну від одного порта з яким доведеться мати справу під час використання віддаленого керування. -A lot of organizations today simply install management tools on servers, and then use Remote Desktop to "remotely manage." That's an incredibly poor idea, and is a major reason why Windows Server take so many patches, so many reboots, and other maladies. The code needed to support a full GUI, and therefore RDP, is massive - and that means patches are inevitable. Running management tools _on the server_, usually under administrator credentials, is opening the door to an attack. +Багато організацій в наш час просто встановлюють інструменти управління на сервери, а потім використовують віддалений робочий стіл для "віддаленого управління". Це неймовірно погана ідея і основна причина чому Windows Server отримує стільки патчів, стільки перезавантажень та інших захворювань. Код необхідний для підтримки повного графічного інтерфейсу, а отже, і RDP, є дуже громіздким, а це означає що патчі є неминучими. Запуск інструментів управління _на сервері_, як правило, з повноваженнями адміністратора, відкриває двері для атаки. -In short, most organizations seem to be worred about the security "implications" of PowerShell Remoting. The implications are **significant** - Remoting is **much** more secure than what you've been doing. It's also more efficient, imposes less overhead on servers, and lets servers run with a leaner operating system that will require fewer patches, fewer reboots, and fewer service packs. Those servers will also boot faster, run fewer processes, run fewer services, and consume less storage space for the OS. Those servers will require less memory overhead for the OS, meaning you can pack more of 'em into a virtualization host. Sounds horrible, right? +Коротше кажучи, виглядає так, що більшість організацій, стурбовані безпекою через "наслідки" від віддаленого керування PowerShell. Наслідки **значні** - віддалене керування **набагато** безпечніше, ніж те, що ви робили раніше. Воно також є більш ефективним, приносить менше накладних витрат на сервери і дозволяє серверам працювати з більш компактною операційною системою, яка вимагатиме менше патчів, менше перезавантажень і менше сервіс паків. Також ці сервери завантажуватимуться швидше, запускатимуть меншу кількість процесів, запускатимуть менше сервісів та будуть споживати менше місця для зберігання ОС. Ці сервери вимагатимуть менших накладних витрат на операційну систему, тобто ви можете пакувати більше серверів у хості віртуалізації. Звучить жахливо, правда? -## But here's the best reason -Quite simply, the main reason to enable Remoting is that _you haven't got any choice._ Microsoft has moved firmly in this direction, and enables Remoting by default on Windows Server 2012 and later. The company _disables_ Remote Desktop by default, which should tell you something. +## Але ось найкраща причина +Простіше кажучи, головна причина увімкнення віддаленого керування - це те, що _у вас немає вибору_. Microsoft твердо рухається в цьому напрямку та включає віддалене керування за замовчуванням на Windows Server 2012 та пізніших версіях. Компанія за замовчуванням _відключає_ віддалений робочий стіл, немовби натякаючи вам на щось. -Further, in Nano Server, _logging onto the console isn't even an option_, whether you use Remote Desktop or not. There _is_ no local login. Remoting _is literally your only option_ for managing the server. That's going to be the case going forward. +Крім того, на Nano Server _консольний логін навіть не є можливим_, використовуєте ви віддалений робочий стіл чи ні. Локального логіну немає. Віддалене керування, _буквально, єдиний варіант_ управління сервером. Саме так все і залишиться надалі. -Running a Windows environment without enabling Remoting - at least on servers - is like driving a car without wanting to depress the accelerator. It isn't much fun, and you aren't going to get very far. +Працювати в середовищі Windows, не вмикаючи віддалене керування - принаймні на серверах - це як керувати автомобілем, не бажаючи натискати на газ. Це не дуже весело, і ви не заїдете дуже далеко. diff --git a/ua/ua.md b/ua/ua.md new file mode 100644 index 0000000..8178c76 --- /dev/null +++ b/ua/ua.md @@ -0,0 +1 @@ +readme