From 91b155fd4435c2afc9a156a9d61732374324ca61 Mon Sep 17 00:00:00 2001 From: Andrii Holovin Date: Wed, 14 Aug 2024 15:25:40 +0300 Subject: [PATCH] Add Ukrainian translation for Helm documentation Signed-off-by: Andrii Holovin --- config.toml | 37 + content/uk/docs/_index.md | 17 + .../uk/docs/chart_best_practices/_index.md | 11 + .../docs/chart_best_practices/conventions.md | 42 + .../custom_resource_definitions.md | 38 + .../docs/chart_best_practices/dependencies.md | 62 + .../uk/docs/chart_best_practices/labels.md | 36 + content/uk/docs/chart_best_practices/pods.md | 66 + content/uk/docs/chart_best_practices/rbac.md | 68 + .../uk/docs/chart_best_practices/templates.md | 217 ++ .../uk/docs/chart_best_practices/values.md | 135 ++ .../uk/docs/chart_template_guide/_index.md | 18 + .../chart_template_guide/accessing_files.md | 206 ++ .../chart_template_guide/builtin_objects.md | 46 + .../control_structures.md | 385 ++++ .../docs/chart_template_guide/data_types.md | 18 + .../uk/docs/chart_template_guide/debugging.md | 32 + .../chart_template_guide/function_list.md | 2044 +++++++++++++++++ .../functions_and_pipelines.md | 206 ++ .../chart_template_guide/getting_started.md | 216 ++ .../chart_template_guide/helm_ignore_file.md | 56 + .../chart_template_guide/named_templates.md | 286 +++ .../docs/chart_template_guide/notes_files.md | 49 + .../subcharts_and_globals.md | 206 ++ .../docs/chart_template_guide/values_files.md | 161 ++ .../uk/docs/chart_template_guide/variables.md | 132 ++ .../docs/chart_template_guide/wrapping_up.md | 26 + .../chart_template_guide/yaml_techniques.md | 294 +++ content/uk/docs/community/_index.md | 8 + content/uk/docs/community/developers.md | 109 + content/uk/docs/community/history.md | 20 + content/uk/docs/community/localization.md | 110 + content/uk/docs/community/related.md | 76 + .../uk/docs/community/release_checklist.md | 378 +++ content/uk/docs/faq/_index.md | 10 + content/uk/docs/faq/changes_since_helm2.md | 278 +++ content/uk/docs/faq/installing.md | 26 + content/uk/docs/faq/troubleshooting.md | 132 ++ content/uk/docs/faq/uninstalling.md | 22 + content/uk/docs/glossary/_index.md | 118 + content/uk/docs/helm/_index.md | 10 + content/uk/docs/helm/helm.md | 113 + content/uk/docs/helm/helm_completion.md | 48 + content/uk/docs/helm/helm_completion_bash.md | 69 + content/uk/docs/helm/helm_completion_fish.md | 63 + .../docs/helm/helm_completion_powershell.md | 58 + content/uk/docs/helm/helm_completion_zsh.md | 61 + content/uk/docs/helm/helm_create.md | 65 + content/uk/docs/helm/helm_delete.md | 7 + content/uk/docs/helm/helm_dependency.md | 82 + content/uk/docs/helm/helm_dependency_build.md | 55 + content/uk/docs/helm/helm_dependency_list.md | 53 + .../uk/docs/helm/helm_dependency_update.md | 57 + content/uk/docs/helm/helm_env.md | 48 + content/uk/docs/helm/helm_get.md | 56 + content/uk/docs/helm/helm_get_all.md | 50 + content/uk/docs/helm/helm_get_hooks.md | 51 + content/uk/docs/helm/helm_get_manifest.md | 51 + content/uk/docs/helm/helm_get_metadata.md | 46 + content/uk/docs/helm/helm_get_notes.md | 49 + content/uk/docs/helm/helm_get_values.md | 51 + content/uk/docs/helm/helm_history.md | 63 + content/uk/docs/helm/helm_init.md | 9 + content/uk/docs/helm/helm_inspect.md | 7 + content/uk/docs/helm/helm_install.md | 164 ++ content/uk/docs/helm/helm_lint.md | 60 + content/uk/docs/helm/helm_list.md | 82 + content/uk/docs/helm/helm_package.md | 66 + content/uk/docs/helm/helm_plugin.md | 48 + content/uk/docs/helm/helm_plugin_install.md | 49 + content/uk/docs/helm/helm_plugin_list.md | 44 + content/uk/docs/helm/helm_plugin_uninstall.md | 44 + content/uk/docs/helm/helm_plugin_update.md | 44 + content/uk/docs/helm/helm_pull.md | 71 + content/uk/docs/helm/helm_push.md | 55 + content/uk/docs/helm/helm_registry.md | 46 + content/uk/docs/helm/helm_registry_login.md | 55 + content/uk/docs/helm/helm_registry_logout.md | 48 + content/uk/docs/helm/helm_repo.md | 51 + content/uk/docs/helm/helm_repo_add.md | 55 + content/uk/docs/helm/helm_repo_index.md | 55 + content/uk/docs/helm/helm_repo_list.md | 45 + content/uk/docs/helm/helm_repo_remove.md | 44 + content/uk/docs/helm/helm_repo_update.md | 57 + content/uk/docs/helm/helm_rollback.md | 61 + content/uk/docs/helm/helm_search.md | 47 + content/uk/docs/helm/helm_search_hub.md | 59 + content/uk/docs/helm/helm_search_repo.md | 73 + content/uk/docs/helm/helm_show.md | 49 + content/uk/docs/helm/helm_show_all.md | 61 + content/uk/docs/helm/helm_show_chart.md | 61 + content/uk/docs/helm/helm_show_crds.md | 62 + content/uk/docs/helm/helm_show_readme.md | 61 + content/uk/docs/helm/helm_show_values.md | 61 + content/uk/docs/helm/helm_status.md | 61 + content/uk/docs/helm/helm_template.md | 98 + content/uk/docs/helm/helm_test.md | 53 + content/uk/docs/helm/helm_uninstall.md | 60 + content/uk/docs/helm/helm_upgrade.md | 114 + content/uk/docs/helm/helm_verify.md | 53 + content/uk/docs/helm/helm_version.md | 68 + content/uk/docs/howto/_index.md | 13 + .../uk/docs/howto/chart_releaser_action.md | 79 + .../howto/chart_repository_sync_example.md | 89 + .../uk/docs/howto/charts_tips_and_tricks.md | 237 ++ content/uk/docs/intro/CheatSheet.md | 141 ++ content/uk/docs/intro/_index.md | 8 + content/uk/docs/intro/install.md | 145 ++ content/uk/docs/intro/quickstart.md | 114 + content/uk/docs/intro/using_helm.md | 441 ++++ content/uk/docs/topics/_index.md | 8 + content/uk/docs/topics/advanced.md | 160 ++ content/uk/docs/topics/architecture.md | 54 + content/uk/docs/topics/chart_repository.md | 230 ++ content/uk/docs/topics/chart_tests.md | 85 + content/uk/docs/topics/charts.md | 874 +++++++ content/uk/docs/topics/charts_hooks.md | 152 ++ content/uk/docs/topics/kubernetes_apis.md | 84 + content/uk/docs/topics/kubernetes_distros.md | 76 + content/uk/docs/topics/library_charts.md | 351 +++ .../topics/permissions_sql_storage_backend.md | 45 + content/uk/docs/topics/plugins.md | 286 +++ content/uk/docs/topics/provenance.md | 225 ++ content/uk/docs/topics/rbac.md | 148 ++ content/uk/docs/topics/registries.md | 233 ++ content/uk/docs/topics/release_policy.md | 45 + content/uk/docs/topics/v2_v3_migration.md | 83 + content/uk/docs/topics/version_skew.md | 62 + i18n/uk.toml | 223 ++ 129 files changed, 14595 insertions(+) create mode 100644 content/uk/docs/_index.md create mode 100644 content/uk/docs/chart_best_practices/_index.md create mode 100644 content/uk/docs/chart_best_practices/conventions.md create mode 100644 content/uk/docs/chart_best_practices/custom_resource_definitions.md create mode 100644 content/uk/docs/chart_best_practices/dependencies.md create mode 100644 content/uk/docs/chart_best_practices/labels.md create mode 100644 content/uk/docs/chart_best_practices/pods.md create mode 100644 content/uk/docs/chart_best_practices/rbac.md create mode 100644 content/uk/docs/chart_best_practices/templates.md create mode 100644 content/uk/docs/chart_best_practices/values.md create mode 100644 content/uk/docs/chart_template_guide/_index.md create mode 100644 content/uk/docs/chart_template_guide/accessing_files.md create mode 100644 content/uk/docs/chart_template_guide/builtin_objects.md create mode 100644 content/uk/docs/chart_template_guide/control_structures.md create mode 100644 content/uk/docs/chart_template_guide/data_types.md create mode 100644 content/uk/docs/chart_template_guide/debugging.md create mode 100644 content/uk/docs/chart_template_guide/function_list.md create mode 100644 content/uk/docs/chart_template_guide/functions_and_pipelines.md create mode 100644 content/uk/docs/chart_template_guide/getting_started.md create mode 100644 content/uk/docs/chart_template_guide/helm_ignore_file.md create mode 100644 content/uk/docs/chart_template_guide/named_templates.md create mode 100644 content/uk/docs/chart_template_guide/notes_files.md create mode 100644 content/uk/docs/chart_template_guide/subcharts_and_globals.md create mode 100644 content/uk/docs/chart_template_guide/values_files.md create mode 100644 content/uk/docs/chart_template_guide/variables.md create mode 100644 content/uk/docs/chart_template_guide/wrapping_up.md create mode 100644 content/uk/docs/chart_template_guide/yaml_techniques.md create mode 100644 content/uk/docs/community/_index.md create mode 100644 content/uk/docs/community/developers.md create mode 100644 content/uk/docs/community/history.md create mode 100644 content/uk/docs/community/localization.md create mode 100644 content/uk/docs/community/related.md create mode 100644 content/uk/docs/community/release_checklist.md create mode 100644 content/uk/docs/faq/_index.md create mode 100644 content/uk/docs/faq/changes_since_helm2.md create mode 100644 content/uk/docs/faq/installing.md create mode 100644 content/uk/docs/faq/troubleshooting.md create mode 100644 content/uk/docs/faq/uninstalling.md create mode 100644 content/uk/docs/glossary/_index.md create mode 100644 content/uk/docs/helm/_index.md create mode 100644 content/uk/docs/helm/helm.md create mode 100644 content/uk/docs/helm/helm_completion.md create mode 100644 content/uk/docs/helm/helm_completion_bash.md create mode 100644 content/uk/docs/helm/helm_completion_fish.md create mode 100644 content/uk/docs/helm/helm_completion_powershell.md create mode 100644 content/uk/docs/helm/helm_completion_zsh.md create mode 100644 content/uk/docs/helm/helm_create.md create mode 100644 content/uk/docs/helm/helm_delete.md create mode 100644 content/uk/docs/helm/helm_dependency.md create mode 100644 content/uk/docs/helm/helm_dependency_build.md create mode 100644 content/uk/docs/helm/helm_dependency_list.md create mode 100644 content/uk/docs/helm/helm_dependency_update.md create mode 100644 content/uk/docs/helm/helm_env.md create mode 100644 content/uk/docs/helm/helm_get.md create mode 100644 content/uk/docs/helm/helm_get_all.md create mode 100644 content/uk/docs/helm/helm_get_hooks.md create mode 100644 content/uk/docs/helm/helm_get_manifest.md create mode 100644 content/uk/docs/helm/helm_get_metadata.md create mode 100644 content/uk/docs/helm/helm_get_notes.md create mode 100644 content/uk/docs/helm/helm_get_values.md create mode 100644 content/uk/docs/helm/helm_history.md create mode 100644 content/uk/docs/helm/helm_init.md create mode 100644 content/uk/docs/helm/helm_inspect.md create mode 100644 content/uk/docs/helm/helm_install.md create mode 100644 content/uk/docs/helm/helm_lint.md create mode 100644 content/uk/docs/helm/helm_list.md create mode 100644 content/uk/docs/helm/helm_package.md create mode 100644 content/uk/docs/helm/helm_plugin.md create mode 100644 content/uk/docs/helm/helm_plugin_install.md create mode 100644 content/uk/docs/helm/helm_plugin_list.md create mode 100644 content/uk/docs/helm/helm_plugin_uninstall.md create mode 100644 content/uk/docs/helm/helm_plugin_update.md create mode 100644 content/uk/docs/helm/helm_pull.md create mode 100644 content/uk/docs/helm/helm_push.md create mode 100644 content/uk/docs/helm/helm_registry.md create mode 100644 content/uk/docs/helm/helm_registry_login.md create mode 100644 content/uk/docs/helm/helm_registry_logout.md create mode 100644 content/uk/docs/helm/helm_repo.md create mode 100644 content/uk/docs/helm/helm_repo_add.md create mode 100644 content/uk/docs/helm/helm_repo_index.md create mode 100644 content/uk/docs/helm/helm_repo_list.md create mode 100644 content/uk/docs/helm/helm_repo_remove.md create mode 100644 content/uk/docs/helm/helm_repo_update.md create mode 100644 content/uk/docs/helm/helm_rollback.md create mode 100644 content/uk/docs/helm/helm_search.md create mode 100644 content/uk/docs/helm/helm_search_hub.md create mode 100644 content/uk/docs/helm/helm_search_repo.md create mode 100644 content/uk/docs/helm/helm_show.md create mode 100644 content/uk/docs/helm/helm_show_all.md create mode 100644 content/uk/docs/helm/helm_show_chart.md create mode 100644 content/uk/docs/helm/helm_show_crds.md create mode 100644 content/uk/docs/helm/helm_show_readme.md create mode 100644 content/uk/docs/helm/helm_show_values.md create mode 100644 content/uk/docs/helm/helm_status.md create mode 100644 content/uk/docs/helm/helm_template.md create mode 100644 content/uk/docs/helm/helm_test.md create mode 100644 content/uk/docs/helm/helm_uninstall.md create mode 100644 content/uk/docs/helm/helm_upgrade.md create mode 100644 content/uk/docs/helm/helm_verify.md create mode 100644 content/uk/docs/helm/helm_version.md create mode 100644 content/uk/docs/howto/_index.md create mode 100644 content/uk/docs/howto/chart_releaser_action.md create mode 100644 content/uk/docs/howto/chart_repository_sync_example.md create mode 100644 content/uk/docs/howto/charts_tips_and_tricks.md create mode 100644 content/uk/docs/intro/CheatSheet.md create mode 100644 content/uk/docs/intro/_index.md create mode 100644 content/uk/docs/intro/install.md create mode 100644 content/uk/docs/intro/quickstart.md create mode 100644 content/uk/docs/intro/using_helm.md create mode 100644 content/uk/docs/topics/_index.md create mode 100644 content/uk/docs/topics/advanced.md create mode 100644 content/uk/docs/topics/architecture.md create mode 100644 content/uk/docs/topics/chart_repository.md create mode 100644 content/uk/docs/topics/chart_tests.md create mode 100644 content/uk/docs/topics/charts.md create mode 100644 content/uk/docs/topics/charts_hooks.md create mode 100644 content/uk/docs/topics/kubernetes_apis.md create mode 100644 content/uk/docs/topics/kubernetes_distros.md create mode 100644 content/uk/docs/topics/library_charts.md create mode 100644 content/uk/docs/topics/permissions_sql_storage_backend.md create mode 100644 content/uk/docs/topics/plugins.md create mode 100644 content/uk/docs/topics/provenance.md create mode 100644 content/uk/docs/topics/rbac.md create mode 100644 content/uk/docs/topics/registries.md create mode 100644 content/uk/docs/topics/release_policy.md create mode 100644 content/uk/docs/topics/v2_v3_migration.md create mode 100644 content/uk/docs/topics/version_skew.md create mode 100644 i18n/uk.toml diff --git a/config.toml b/config.toml index e2e2c0f11..d6b70ff41 100644 --- a/config.toml +++ b/config.toml @@ -400,6 +400,43 @@ weight = 5 [languages.ru.params] language_alternatives = ["en"] +# Ukrainian +[languages.uk] +title = "Helm" +description = "Helm — Менеджер Пакунків Kubernetes." +contentDir = "content/uk" +languageName = "Українська" +weight = 9 + +[[languages.uk.menus.main]] +name = "Головна" +url = "/" +weight = 1 + +[[languages.uk.menus.main]] +name = "Документація" +url = "/docs" +weight = 2 + +[[languages.uk.menus.main]] +name = "Чарти" +url = "https://artifacthub.io/" +weight = 3 +external = "yes" + +[[languages.uk.menus.main]] +name = "Блог" +url = "https://helm.sh/blog" +weight = 4 + +[[languages.uk.menus.main]] +name = "Спільнота" +url = "https://github.com/helm/community" +weight = 5 + +[languages.uk.params] +language_alternatives = ["en"] + # Chinese [languages.zh] title = "Helm" diff --git a/content/uk/docs/_index.md b/content/uk/docs/_index.md new file mode 100644 index 000000000..15e7132a3 --- /dev/null +++ b/content/uk/docs/_index.md @@ -0,0 +1,17 @@ +--- +title: "Документація" +description: "Все, що вам потрібно знати про те, як організована документація." +--- + +# Ласкаво просимо {#welcome} + +Ласкаво просимо до документації [Helm](https://helm.sh/). Helm — це менеджер пакунків для Kubernetes, і ви можете прочитати детальну довідкову інформацію у [звіті CNCF Helm Project Journey](https://www.cncf.io/cncf-helm-project-journey/). + +# Як організована документація {#how-the-documentation-is-organized} + +Helm має багато документації. Загальний огляд того, як все організовано допоможе вам зрозуміти, де шукати певні речі: + +- [Підручники](chart_template_guide/getting_started/) проведуть вас через низку кроків для створення вашого першого чарту Helm. Почніть тут, якщо ви новачок у Helm. +- [Тематичні посібники](topics) обговорюють ключові теми та концепції на досить високому рівні та надають корисну довідкову інформацію та пояснення. +- [Настанови для спільноти](community) обговорюють теми, повʼязані зі спільнотою Helm. Почніть тут, якщо ви хочете дізнатися більше про процес розробки Helm і про те, як ви можете до нього долучитися. +- [Посібники](howto) — це рецепти. Вони проведуть вас через кроки, повʼязані з розвʼязанням ключових проблем та варіантів використання. Вони більш докладні, ніж підручників і передбачають певні знання про те, як працює Helm. diff --git a/content/uk/docs/chart_best_practices/_index.md b/content/uk/docs/chart_best_practices/_index.md new file mode 100644 index 000000000..fbeff59bc --- /dev/null +++ b/content/uk/docs/chart_best_practices/_index.md @@ -0,0 +1,11 @@ +--- +title: "Найкращі практики" +sidebar: true +weight: 4 +--- + +# Посібник з найкращих практик створення чартів + +Цей посібник охоплює найкращі практики, рекомендовані командою Helm, для створення чартів. Основна увага приділяється тому, як повинні бути структуровані чарти. + +Ми зосереджуємось головним чином на найкращих практиках для чартів, які можуть бути опубліковані публічно. Ми розуміємо, що багато чартів використовуються виключно для внутрішніх потреб, і автори таких чартів можуть вважати, що їхні внутрішні інтереси переважають наші рекомендації тут. diff --git a/content/uk/docs/chart_best_practices/conventions.md b/content/uk/docs/chart_best_practices/conventions.md new file mode 100644 index 000000000..1ea935a20 --- /dev/null +++ b/content/uk/docs/chart_best_practices/conventions.md @@ -0,0 +1,42 @@ +--- +title: "Загальні домовленості" +description: "Загальні домовленості для чартів." +weight: 1 +--- + +Ця частина Посібника з найкращих практик пояснює загальні домовленості. + +## Назви чартів {#chart-names} + +Назви чартів повинні складатися з літер нижнього регістру та цифр. Слова _можуть_ бути розділені дефісами (-): + +Приклади: + +```none +drupal +nginx-lego +aws-cluster-autoscaler +``` + +У назвах чартів не можна використовувати великі літери та підкреслення. Також не слід використовувати крапки. + +## Номери версій {#version-numbers} + +По можливості, Helm використовує [SemVer 2](https://semver.org) для позначення номерів версій. (Зверніть увагу, що теґи Docker-образів не завжди відповідають SemVer і тому вважаються невдалим винятком з правила.) + +Коли версії SemVer зберігаються в мітках Kubernetes, ми умовно змінюємо символ `+` на `_`, оскільки мітки не допускають використання знака `+` як значення. + +## Форматування YAML {#formatting-yaml} + +Файли YAML повинні використовувати відступи у _два пробіли_ (і ніколи табуляцією). + +## Використання слів Helm і Chart {#usage-of-the-words-helm-and-chart} + +Існує кілька конвенцій щодо використання слів _Helm_ і _helm_. + +- _Helm_ відноситься до проєкту в цілому +- `helm` відноситься до клієнтської команди +- Термін `chart` не потрібно писати з великої літери, оскільки це не власна назва +- Однак `Chart.yaml` необхідно писати з великої літери, оскільки назва файлу чутлива до регістру + +У разі сумніву використовуйте _Helm_ (з великої літери "H"). diff --git a/content/uk/docs/chart_best_practices/custom_resource_definitions.md b/content/uk/docs/chart_best_practices/custom_resource_definitions.md new file mode 100644 index 000000000..a7cd3d4a2 --- /dev/null +++ b/content/uk/docs/chart_best_practices/custom_resource_definitions.md @@ -0,0 +1,38 @@ +--- +title: "Custom Resource Definitions" +description: "Як створювати та використовувати CRD (Custom Resource Definitions)." +weight: 7 +--- + +Цей розділ посібника з найкращих практик розглядає створення та використання обʼєктів Custom Resource Definition (CRD). + +При роботі з CRD важливо розрізняти два різні аспекти: + +- Існує декларація CRD. Це YAML файл, який має `kind: CustomResourceDefinition`. +- Потім є ресурси, які _використовують_ CRD. Наприклад, якщо CRD визначає `foo.example.com/v1`, будь-який ресурс, який має `apiVersion: example.com/v1` і `kind: Foo`, є ресурсом, що використовує цей CRD. + +## Встановлення декларації CRD перед використанням ресурсу {#install-a-crd-declaration-before-using-the-resource} + +Helm оптимізований для швидкого завантаження якомога більшої кількості ресурсів у Kubernetes. За дизайном Kubernetes може обробити цілий набір маніфестів і активувати їх усі (це називається циклом узгодження). + +Але є різниця з CRD. + +Для CRD декларація повинна бути зареєстрована до того, як будь-які ресурси цього типу CRD можуть бути використані. Процес реєстрації іноді займає кілька секунд. + +### Метод 1: Нехай `helm` зробить це за вас {#method-1-let-helm-do-it-for-you} + +З приходом Helm 3 ми видалили старі `crd-install` хуки на користь простішої методології. Тепер існує спеціальна тека `crds`, яку ви можете створити у вашому чарті для зберігання CRD. Ці CRD не підлягають шаблонізації, але будуть стандартно встановлені під час виконання `helm install` для чарту. Якщо CRD вже існує, його буде пропущена з попередженням. Якщо ви бажаєте пропустити крок встановлення CRD, ви можете використовувати прапорець `--skip-crds`. + +#### Декілька застережень (і пояснень) {#some-caveats-and-explanations} + +Зараз не підтримується оновлення або видалення CRD за допомогою Helm. Це було зроблено після тривалого обговорення у спільноті через небезпеку випадкової втрати даних. Крім того, наразі немає консенсусу в спільноті щодо того, як управляти CRD та їх життєвим циклом. Як це буде розвиватися, Helm додасть підтримку для цих випадків. + +Прапорець `--dry-run` для `helm install` і `helm upgrade` наразі не підтримується для CRD. Мета "Dry Run" полягає в перевірці того, що вивід чарту дійсно працюватиме, якщо буде надіслано на сервер. Але CRD є модифікацією поведінки сервера. Helm не може встановити CRD під час сухого запуску, тому клієнт виявлення не дізнається про цей Custom Resource (CR), і перевірка не пройде. Ви можете перемістити CRD до окремого чарту або використовувати `helm template` замість цього. + +Ще один важливий момент, який слід врахувати в обговоренні підтримки CRD, — це те, як обробляється рендеринг шаблонів. Одним з відмінних недоліків методу `crd-install`, що використовувався в Helm 2, була неспроможність правильно перевіряти чарти через зміну доступності API (CRD фактично додає ще один доступний API до вашого кластера Kubernetes). Якщо чарт встановлював CRD, `helm` більше не мав дійсного набору версій API, з якими можна було працювати. Це також є причиною видалення підтримки шаблонізації для CRD. З новим методом `crds` для встановлення CRD ми тепер забезпечуємо, що `helm` має абсолютно достовірну інформацію про поточний стан кластера. + +### Метод 2: Окремі чарти {#method-2-separate-charts} + +Ще один спосіб зробити це — помістити визначення CRD в один чарт, а потім розмістити будь-які ресурси, які використовують цей CRD, в _іншому_ чарті. + +В цьому методі кожен чарт потрібно встановлювати окремо. Однак цей робочий процес може бути більш корисним для адміністраторів кластерів, які мають права адміністратора на кластер. diff --git a/content/uk/docs/chart_best_practices/dependencies.md b/content/uk/docs/chart_best_practices/dependencies.md new file mode 100644 index 000000000..c5e6f97a0 --- /dev/null +++ b/content/uk/docs/chart_best_practices/dependencies.md @@ -0,0 +1,62 @@ +--- +title: "Залежності" +description: "Охоплює найкращі практики для залежностей Charts." +weight: 4 +--- + +Цей розділ посібника охоплює найкращі практики для `залежностей`, оголошених у `Chart.yaml`. + +## Версії {#versions} + +По можливості використовуйте діапазони версій замість привʼязки до точної версії. Рекомендоване стандартне значення — це використання відповідності на рівні патчу: + +```yaml +version: ~1.2.3 +``` + +Це буде відповідати версії `1.2.3` та будь-яким патчам для цього випуску. Іншими словами, `~1.2.3` є еквівалентом `>= 1.2.3, < 1.3.0`. + +Для повної синтаксичної відповідності версій див. [документацію semver](https://github.com/Masterminds/semver#checking-version-constraints). + +### Попередні версії {#prereleases-versions} + +Вищезгадані обмеження версій не будуть відповідати попереднім версіям. Наприклад, `version: ~1.2.3` буде відповідати `version: ~1.2.4`, але не `version: ~1.2.3-1`. Наступне забезпечує відповідність як попередніх версій, так і на рівні патчу: + +```yaml +version: ~1.2.3-0 +``` + +### URL-адреси репозиторіїв {#repository-urls} + +По можливості використовуйте URL-адреси репозиторіїв `https://`, далі `http://`. + +Якщо репозиторій був доданий до файлу індексу репозиторіїв, імʼя репозиторію може бути використане як псевдонім URL. Використовуйте `alias:` або `@`, за яким слідують імена репозиторіїв. + +URL-адреси файлів (`file://...`) вважаються "особливим випадком" для чартів, які збираються фіксованим процесом розгортання. + +При використанні [втулків завантажувача]({{< ref "../topics/plugins#downloader-plugins" >}}) схема URL буде специфічною для втулка. Зверніть увагу, що користувачеві чарту буде потрібно мати втулок, що підтримує схему, встановлений для оновлення або побудови залежності. + +Helm не може виконувати операції управління залежностями для залежності, коли поле `repository` залишено порожнім. У цьому випадку Helm припускатиме, що залежність знаходиться в підтеці теки `charts` з іменем, яке відповідає властивості `name` для залежності. + +## Умови та теґи {#conditions-and-tags} + +Умови або теґи слід додавати до будь-яких залежностей, які _є необовʼязковими_. + +Бажана форма умови є такою: + +```yaml +condition: somechart.enabled +``` + +Де `somechart` є іменем чарту залежності. + +Коли кілька субчартів (залежностей) разом забезпечують необовʼязкову або замінну функцію, ці чарт можуть мати спільні теґи. + +Наприклад, якщо як `nginx`, так і `memcached` разом забезпечують оптимізації продуктивності для основного застосунку в чарті та вони потрібні, щоб обидва були присутні, коли ця функція увімкнена, то вони повинні мати розділ теґів як цей: + +```yaml +tags: + - webaccelerator +``` + +Це дозволяє користувачеві вмикати або вимикати цю функцію за допомогою одного теґу. diff --git a/content/uk/docs/chart_best_practices/labels.md b/content/uk/docs/chart_best_practices/labels.md new file mode 100644 index 000000000..3f0b44259 --- /dev/null +++ b/content/uk/docs/chart_best_practices/labels.md @@ -0,0 +1,36 @@ +--- +title: "Мітки та Анотації" +description: "Охоплює найкращі практики використання міток та анотацій у вашому Chart." +weight: 5 +--- + +Цей розділ посібника з найкращих практик обговорює найкращі практики для використання міток та анотацій у вашому чарті. + +## Це мітка чи анотація? {#is-it-a-label-or-an-annotation} + +Елемент метаданих слід вважати міткою за таких умов: + +- Він використовується Kubernetes для ідентифікації цього ресурсу +- Він корисний для експонування операторам з метою запиту системи. + +Наприклад, рекомендується використовувати `helm.sh/chart: NAME-VERSION` як мітку, щоб оператори могли зручно знаходити всі екземпляри конкретного чарту. + +Якщо елемент метаданих не використовується для запитів, його слід встановити як анотацію. + +Helm hooks завжди є анотаціями. + +## Стандартні Мітки {#standard-labels} + +Наступна таблиця визначає загальні мітки, які використовуються в Helm чарті. Helm сам по собі ніколи не вимагає наявності конкретної мітки. Мітки, які позначені як REC, є рекомендованими та _повинні_ бути розміщені в чарті для глобальної узгодженості. Ті, що позначені як OPT, є необовʼязковими. Це ідіоматичні або часто використовувані мітки, але не є критично важливими для операційних цілей. + +| Назва | Статус | Опис | +|-------|--------|------| +| `app.kubernetes.io/name` | REC | Це повинно бути імʼя застосунку, яке відображає весь застосунок. Зазвичай використовується `{{ template "name" . }}`. Це використовується багатьма маніфестами Kubernetes і не є специфічним для Helm. | +| `helm.sh/chart` | REC | Це повинно бути імʼя чарту та версія: `{{ .Chart.Name }}-{{ .Chart.Version \| replace "+" "_" }}`. | +| `app.kubernetes.io/managed-by` | REC | Це завжди повинно бути встановлено як `{{ .Release.Service }}`. Це для знаходження всього, що управляється Helm. | +| `app.kubernetes.io/instance` | REC | Це повинно бути `{{ .Release.Name }}`. Це допомагає відрізняти різні екземпляри одного й того ж застосунку. | +| `app.kubernetes.io/version` | OPT | Версія застосунку і може бути встановлена як `{{ .Chart.AppVersion }}`. | +| `app.kubernetes.io/component` | OPT | Це загальна мітка для позначення різних ролей, які елементи можуть відігравати в застосунку. Наприклад, `app.kubernetes.io/component: frontend`. | +| `app.kubernetes.io/part-of` | OPT | Коли кілька чартів або програмних частин використовуються разом для створення одного застосунку. Наприклад, програмне забезпечення та база даних для створення вебсайту. Це можна встановити на рівні основного застосунку, що підтримується. | + +Ви можете знайти більше інформації про мітки Kubernetes, що починаються з `app.kubernetes.io`, в [документації Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/). diff --git a/content/uk/docs/chart_best_practices/pods.md b/content/uk/docs/chart_best_practices/pods.md new file mode 100644 index 000000000..54ba8d086 --- /dev/null +++ b/content/uk/docs/chart_best_practices/pods.md @@ -0,0 +1,66 @@ +--- +title: "Pods та PodTemplates" +description: "Обговорює форматування частин Pod та PodTemplate у маніфестах Chart." +weight: 6 +--- + +Цей розділ посібника з найкращих практик обговорює форматування частин Pod та PodTemplate у маніфестах чарту. + +Наступний (неповний) список ресурсів використовує PodTemplates: + +- Deployment +- ReplicationController +- ReplicaSet +- DaemonSet +- StatefulSet + +## Образи {#images} + +Образи контейнера повинні використовувати фіксовану мітку або SHA образу. Не слід використовувати мітки `latest`, `head`, `canary` або інші мітки, які призначені для "плаваючих" версій. + +Образи _можуть_ бути визначені у файлі `values.yaml`, щоб спростити заміну образів. + +```yaml +image: {{ .Values.redisImage | quote }} +``` + +Образи та мітка _можуть_ бути визначені в `values.yaml` як два окремих поля: + +```yaml +image: "{{ .Values.redisImage }}:{{ .Values.redisTag }}" +``` + +## ImagePullPolicy + +`helm create` стандартно встановлює `imagePullPolicy` на `IfNotPresent`, роблячи це у вашому `deployment.yaml`: + +```yaml +imagePullPolicy: {{ .Values.image.pullPolicy }} +``` + +А у `values.yaml`: + +```yaml +image: + pullPolicy: IfNotPresent +``` + +Аналогічно, Kubernetes стандартно встановлює `imagePullPolicy` на `IfNotPresent`, якщо він зовсім не визначений. Якщо вам потрібне інше значення, просто оновіть його в `values.yaml` на потрібне значення. + +## PodTemplates повинні оголошувати селектори + +Усі секції PodTemplate повинні вказувати селектор. Наприклад: + +```yaml +selector: + matchLabels: + app.kubernetes.io/name: MyName +template: + metadata: + labels: + app.kubernetes.io/name: MyName +``` + +Це гарна практика, оскільки вона робить відносини між набором і pod чіткішими. + +Але це ще важливіше для таких наборів, як Deployment. Без цього, _весь_ набір міток використовується для вибору відповідних pod, і це може зламатися, якщо ви використовуєте мітки, які змінюються, такі як версія або дата релізу. diff --git a/content/uk/docs/chart_best_practices/rbac.md b/content/uk/docs/chart_best_practices/rbac.md new file mode 100644 index 000000000..be5dfed39 --- /dev/null +++ b/content/uk/docs/chart_best_practices/rbac.md @@ -0,0 +1,68 @@ +--- +title: "Role-Based Access Control" +description: "Обговорює створення та форматування RBAC ресурсів у маніфестах чарта." +weight: 8 +--- + +Цей розділ посібника з найкращих практик розглядає створення та форматування ресурсів RBAC у маніфестах чарту. + +Ресурси RBAC це: + +- ServiceAccount (обмежений простором імен) +- Role (обмежений простором імен) +- ClusterRole +- RoleBinding (обмежений простором імен) +- ClusterRoleBinding + +## Конфігурація YAML {#yaml-configuration} + +Конфігурація RBAC та ServiceAccount повинна здійснюватися під окремими ключами. Це окремі речі. Розділення цих двох концепцій у YAML знімає неоднозначність і робить це ясніше. + +```yaml +rbac: + # Вказує, чи повинні бути створені ресурси RBAC + create: true + +serviceAccount: + # Вказує, чи повинен бути створений ServiceAccount + create: true + # Імʼя ServiceAccount для використання. + # Якщо не вказано і create дорівнює true, імʼя генерується за допомогою шаблону fullname + name: +``` + +Цю структуру можна розширити для складніших чартів, які потребують кількох ServiceAccount. + +```yaml +someComponent: + serviceAccount: + create: true + name: +anotherComponent: + serviceAccount: + create: true + name: +``` + +## Ресурси RBAC повинні бути стандартно створені {#rbac-resources-should-be-created-by-default} + +`rbac.create` має бути булевим значенням, яке контролює, чи створюються ресурси RBAC. Стандартне значення має бути `true`. Користувачі, які бажають самостійно управляти контролем доступу RBAC, можуть встановити це значення в `false` (у цьому випадку дивіться нижче). + +## Використання ресурсів RBAC {#using-rbac-resources} + +`serviceAccount.name` має бути встановлено на імʼя ServiceAccount, яке буде використовуватися доступними ресурсами, створеними чартом. Якщо `serviceAccount.create` дорівнює true, то ServiceAccount з цим імʼям має бути створено. Якщо імʼя не вказано, то імʼя генерується за допомогою шаблону `fullname`. Якщо `serviceAccount.create` дорівнює false, то ServiceAccount не створюється, але він має бути асоційований з тими ж ресурсами, щоб пізніше створені вручну ресурси RBAC, що посилаються на нього, функціонували правильно. Якщо `serviceAccount.create` дорівнює false та імʼя не вказано, то використовується стандартний ServiceAccount. + +Для ServiceAccount слід використовувати наступний допоміжний шаблон. + +```yaml +{{/* +Створіть імʼя ServiceAccount для використання +*/}} +{{- define "mychart.serviceAccountName" -}} +{{- if .Values.serviceAccount.create -}} + {{ default (include "mychart.fullname" .) .Values.serviceAccount.name }} +{{- else -}} + {{ default "default" .Values.serviceAccount.name }} +{{- end -}} +{{- end -}} +``` diff --git a/content/uk/docs/chart_best_practices/templates.md b/content/uk/docs/chart_best_practices/templates.md new file mode 100644 index 000000000..62e2d2b1f --- /dev/null +++ b/content/uk/docs/chart_best_practices/templates.md @@ -0,0 +1,217 @@ +--- +title: "Шаблони" +description: "Ближче ознайомлення з найкращими практиками щодо шаблонів." +weight: 3 +--- + +Ця частина посібника з найкращих практик фокусується на шаблонах. + +## Структура `templates/` {#structure-of-templates} + +Теку `templates/` слід структурувати наступним чином: + +- Файли шаблонів повинні мати розширення `.yaml`, якщо вони генерують YAML-вихід. Розширення `.tpl` можна використовувати для файлів шаблонів, які не генерують форматований контент. +- Імена файлів шаблонів повинні використовувати дефіси (`my-example-configmap.yaml`), а не camelCase. +- Кожне визначення ресурсу повинно бути у власному файлі шаблону. +- Імена файлів шаблонів повинні відображати тип ресурсу в імені. Наприклад, `foo-pod.yaml`, `bar-svc.yaml`. + +## Імена визначених шаблонів {#names-of-defined-templates} + +Визначені шаблони (шаблони, створені всередині директиви `{{ define }}`) є глобально доступними. Це означає, що чарт і всі його субчарти матимуть доступ до всіх шаблонів, створених з `{{ define }}`. + +З цієї причини _усі імена визначених шаблонів повинні бути просторово іменовані_. + +Правильно: + +```yaml +{{- define "nginx.fullname" }} +{{/* ... */}} +{{ end -}} +``` + +Неправильно: + +```yaml +{{- define "fullname" -}} +{{/* ... */}} +{{ end -}} +``` + +Рекомендується, щоб нові чарти створювалися за допомогою команди `helm create`, оскільки імена шаблонів автоматично визначаються відповідно до цієї найкращої практики. + +## Форматування шаблонів {#formatting-templates} + +Шаблони повинні мати відступи у _два пробіли_ (ніколи не табуляцією). + +Директиви шаблону повинні мати пробіл після відкриваючих дужок і перед закриваючими дужками: + +Правильно: + +```go +{{ .foo }} +{{ print "foo" }} +{{- print "bar" -}} +``` + +Неправильно: + +```go +{{.foo}} +{{print "foo"}} +{{-print "bar"-}} +``` + +Шаблони повинні обрізати пробіли, де це можливо: + +```yaml +foo: + {{- range .Values.items }} + {{ . }} + {{ end -}} +``` + +Блоки (такі як контрольні структури) можуть мати відступи для вказівки потоку коду шаблону. + +```go +{{ if $foo -}} + {{- with .Bar }}Hello{{ end -}} +{{- end -}} +``` + +Однак, оскільки YAML є мовою, орієнтованою на пробіли, часто неможливо, щоб відступи коду слідували цій конвенції. + +## Пробіли у згенерованих шаблонах {#whitespace-in-generated-templates} + +Бажано мінімізувати кількість пробілів у згенерованих шаблонах. Особливо слід уникати численних порожніх рядків, які йдуть один за одним. Але випадкові порожні рядки (особливо між логічними секціями) допустимі. + +Це краще: + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: example + labels: + first: first + second: second +``` + +Це прийнятно: + +```yaml +apiVersion: batch/v1 +kind: Job + +metadata: + name: example + + labels: + first: first + second: second + +``` + +Але це слід уникати: + +```yaml +apiVersion: batch/v1 +kind: Job + +metadata: + name: example + + + + + + labels: + first: first + + second: second + +``` + +## Коментарі (Коментарі YAML vs. Коментарі шаблонів) {#comments-yaml-comments-vs-template-comments} + +Як YAML, так і шаблони Helm мають маркери коментарів. + +Коментарі YAML: + +```yaml +# Це коментар +type: sprocket +``` + +Коментарі шаблонів: + +```yaml +{{- /* +Це коментар. +*/}} +type: frobnitz +``` + +Коментарі шаблонів слід використовувати для документування функцій шаблону, наприклад, пояснюючи визначений шаблон: + +```yaml +{{- /* +mychart.shortname надає скорочену версію імені релізу до 6 символів. +*/}} +{{ define "mychart.shortname" -}} +{{ .Release.Name | trunc 6 }} +{{- end -}} + +``` + +Всередині шаблонів коментарі YAML можуть використовуватися, коли це корисно для користувачів Helm (можливо) бачити коментарі під час налагодження. + +```yaml +# Це може спричинити проблеми, якщо значення більше ніж 100Gi +memory: {{ .Values.maxMem | quote }} +``` + +Вищенаведений коментар видимий, коли користувач виконує `helm install --debug`, тоді як коментарі, вказані в секціях `{{- /* */}}`, не видно. + +Остерігайтеся додавання `#` коментарів YAML у секції шаблону, що містять значення Helm, які можуть бути потрібні для деяких функцій шаблону. + +Наприклад, якщо функція `required` вводиться у наведеному вище прикладі, і `maxMem` не встановлено, коментар `#` YAML спричинить помилку рендерингу. + +Правильно: `helm template` не рендерить цей блок + +```yaml +{{- /* +# Це може спричинити проблеми, якщо значення більше ніж 100Gi +memory: {{ required "maxMem must be set" .Values.maxMem | quote }} +*/ -}} +``` + +Неправильно: `helm template` повертає `Error: execution error at (templates/test.yaml:2:13): maxMem must be set` + +```yaml +# Це може спричинити проблеми, якщо значення більше ніж 100Gi +# memory: {{ required .Values.maxMem "maxMem must be set" | quote }} +``` + +Огляньте [Налагодження шаблонів](../chart_template_guide/debugging.md) для іншого прикладу цієї поведінки того, як коментарі YAML залишаються недоторканими. + +## Використання JSON у шаблонах і виході шаблонів {#use-of-json-in-templates-and-template-output} + +YAML є надмножиною JSON. У деяких випадках використання синтаксису JSON може бути більш читабельним, ніж інші представлення YAML. + +Наприклад, цей YAML ближчий до звичайного методу представлення списків у YAML: + +```yaml +arguments: + - "--dirname" + - "/foo" +``` + +Але його легше читати, коли його стисло представлено у стилі списку JSON: + +```yaml +arguments: ["--dirname", "/foo"] +``` + +Використання JSON для підвищення читабельності є корисним. Однак синтаксис JSON не слід використовувати для представлення cкладніших конструкцій. + +При роботі з чистим JSON, вбудованим всередині YAML (наприклад, конфігурація контейнера ініціалізації), звичайно, доречно використовувати формат JSON. diff --git a/content/uk/docs/chart_best_practices/values.md b/content/uk/docs/chart_best_practices/values.md new file mode 100644 index 000000000..9875d5f3e --- /dev/null +++ b/content/uk/docs/chart_best_practices/values.md @@ -0,0 +1,135 @@ +--- +title: "Значення" +description: "Орієнтовано на те, як ви повинні структурувати та використовувати значення." +weight: 2 +--- + +Ця частина посібника з найкращих практик охоплює використання значень. Ми надаємо рекомендації щодо структурування та використання значень, зосереджуючись на дизайні файлу `values.yaml` чарту. + +## Домовленості щодо назв {#naming-conventions} + +Назви змінних повинні починатися з малої літери, а слова мають розділятися верблюжим регістром (camelCase): + +Правильно: + +```yaml +chicken: true +chickenNoodleSoup: true +``` + +Неправильно: + +```yaml +Chicken: true # початкова велика літера може конфліктувати з вбудованими змінними +chicken-noodle-soup: true # не використовуйте дефіси в назвах +``` + +Зверніть увагу, що всі вбудовані змінні Helm починаються з великої літери, щоб їх легко було відрізнити від користувацьких значень: `.Release.Name`, `.Capabilities.KubeVersion`. + +## Пласкі або вкладені значення {#flat-or-nested-values} + +YAML — це гнучкий формат, і значення можуть бути вкладеними або пласкими. + +Вкладені: + +```yaml +server: + name: nginx + port: 80 +``` + +Пласкі: + +```yaml +serverName: nginx +serverPort: 80 +``` + +У більшості випадків слід віддавати перевагу пласким структурам над вкладеними. Це зумовлено тим, що їх простіше використовувати розробникам шаблонів та користувачам. + +Для забезпечення максимальної безпеки вкладене значення має перевірятися на кожному рівні: + +```go +{{ if .Values.server }} + {{ default "none" .Values.server.name }} +{{ end }} +``` + +Для кожного шару вкладення необхідно виконувати перевірку на наявність. Однак для пласкої конфігурації такі перевірки можна пропустити, що спрощує читання та використання шаблону. + +```go +{{ default "none" .Values.serverName }} +``` + +Коли існує велика кількість пов’язаних змінних і хоча б одна з них є обов’язковою, вкладені значення можуть використовуватися для підвищення зручності читання. + +## Чітке визначення типів {#make-types-clear} + +Правила перетворення типів YAML іноді можуть бути неінтуїтивними. Наприклад, `foo: false` не те саме, що і `foo: "false"`. Великі цілі числа, такі як `foo: 12345678`, у деяких випадках будуть перетворюватися на наукову нотацію. + +Найпростіший спосіб уникнути помилок перетворення типів — бути явним щодо рядків і неявним щодо всього іншого. Або, коротко кажучи, _беріть всі рядки в лапки_. + +Часто для уникнення проблем із перетворенням чисел наукової нотації вигідно зберігати ваші цілі числа у вигляді рядків і використовувати `{{ int $value }}` у шаблоні для перетворення з рядкового значення назад на ціле число. + +У більшості випадків явні типи поважаються, тому `foo: !!string 1234` має обробляти `1234` як рядок. _Проте_ парсер YAML споживає теґи, тому дані про типи втрачаються після одного аналізу. + +## Розгляд використання ваших значень користувачами {#consider-your-values-used-by-users} + +Існує три потенційні джерела значень: + +- Файл `values.yaml` чарту +- Файл значень, переданий за допомогою `helm install -f` або `helm upgrade -f` +- Значення, передані з прапорцем `--set` або `--set-string` під час `helm install` або `helm upgrade` + +При проєктуванні структури ваших значень майте на увазі, що користувачі вашого чарту можуть захотіти перевизначити їх за допомогою прапорця `-f` або опції `--set`. + +Оскільки `--set` більш обмежений у виразності, перше правило написання файлу `values.yaml` — _зробіть його зручним для перевизначення за допомогою `--set`_. + +З цієї причини часто краще структурувати файл значень, використовуючи map. + +Важко використовувати з `--set`: + +```yaml +servers: + - name: foo + port: 80 + - name: bar + port: 81 +``` + +Вищенаведене не можна виразити за допомогою `--set` у Helm `<=2.4`. У Helm 2.5 доступ до порту на foo здійснюється через `--set servers[0].port=80`. Не тільки це важче зрозуміти для користувача, але це ще й схильне до помилок, якщо пізніше порядок серверів зміниться. + +Легко використовувати: + +```yaml +servers: + foo: + port: 80 + bar: + port: 81 +``` + +Отримання доступу до порту foo стає набагато очевиднішим: `--set servers.foo.port=80`. + +## Документуйте `values.yaml` {#document-valuesyaml} + +Кожна визначена властивість у `values.yaml` повинна бути задокументована. Рядок документації повинен починатися з назви властивості, яку він описує, а потім надавати принаймні одне речення опису. + +Неправильно: + +```yaml +# назва хосту для веб-сервера +serverHost: example +serverPort: 9191 +``` + +Правильно: + +```yaml +# serverHost - це назва хосту для веб-сервера +serverHost: example +# serverPort - це порт HTTP-сервера для веб-сервера +serverPort: 9191 +``` + +Початок кожного коментаря з назви параметра, який він документує, дозволяє легко знаходити документацію та дозволяє інструментам документації надійно співвідносити рядки документації з параметрами, які вони описують. diff --git a/content/uk/docs/chart_template_guide/_index.md b/content/uk/docs/chart_template_guide/_index.md new file mode 100644 index 000000000..c160a36a1 --- /dev/null +++ b/content/uk/docs/chart_template_guide/_index.md @@ -0,0 +1,18 @@ +--- +title: "Шаблони чартів" +weight: 5 +--- + +# Посібник розробника шаблонів чартів + +Цей посібник надає введення в шаблони чартів Helm, з акцентом на мову шаблонів. + +Шаблони генерують файли маніфестів, які є YAML-форматованими описами ресурсів, які Kubernetes може зрозуміти. Ми розглянемо, як структуровані шаблони, як їх можна використовувати, як писати шаблони на Go і як налагоджувати вашу роботу. + +Цей посібник зосереджений на наступних концепціях: + +- Мова шаблонів Helm +- Використання значень +- Техніки роботи з шаблонами + +Цей посібник орієнтований на вивчення особливостей мови шаблонів Helm. Інші посібники надають вступні матеріали, приклади та найкращі практики. diff --git a/content/uk/docs/chart_template_guide/accessing_files.md b/content/uk/docs/chart_template_guide/accessing_files.md new file mode 100644 index 000000000..3f6bc7bdc --- /dev/null +++ b/content/uk/docs/chart_template_guide/accessing_files.md @@ -0,0 +1,206 @@ +--- +title: "Доступ до файлів всередині шаблонів" +description: "Як отримати доступ до файлів зсередини шаблону." +weight: 10 +--- + +У попередньому розділі ми розглянули кілька способів створення та доступу до іменованих шаблонів. Це полегшує імпорт одного шаблону в інший шаблон. Але іноді корисно імплементувати _файл, який не є шаблоном_ і вбудувати його вміст без використання рендерера шаблонів. + +Helm надає доступ до файлів через обʼєкт `.Files`. Перш ніж переходити до прикладів шаблонів, є кілька моментів, які слід врахувати: + +- Можна додавати додаткові файли до вашого Helm чарту. Ці файли будуть упаковані. Але будьте обережні. Чарти мають бути меншими за 1М через обмеження зберігання обʼєктів Kubernetes. +- Деякі файли не можна отримати через обʼєкт `.Files`, зазвичай з міркувань безпеки. + - Файли в `templates/` не можна отримати. + - Файли, виключені за допомогою `.helmignore`, не можна отримати. + - Файли поза Helm-застосукном [subchart]({{< ref "/docs/chart_template_guide/subcharts_and_globals.md" >}}), включаючи файли батьківського чарту, не можна отримати. +- Чарти не зберігають інформацію про режим UNIX, тому дозволи на рівні файлу не вплинуть на доступність файлу в обʼєкті `.Files`. + + + + + +- [Базовий приклад](#basic-example) +- [Помічники оброки шляхів](#path-helpers) +- [Шаблони Glob](#glob-patterns) +- [Утиліти для ConfigMap і Secrets](#configmap-and-secrets-utility-functions) +- [Кодування](#encoding) +- [Рядки](#lines) + + + +## Базовий приклад {#basic-example} + +З урахуванням цих застережень, напишемо шаблон, який читає три файли в наш ConfigMap. Для початку додамо три файли до чарту, розміщуючи всі три безпосередньо в теці `mychart/`. + +`config1.toml`: + +```toml +message = Hello from config 1 +``` + +`config2.toml`: + +```toml +message = This is config 2 +``` + +`config3.toml`: + +```toml +message = Goodbye from config 3 +``` + +Кожен з цих файлів є простим TOML-файлом (згадайте про старі INI-файли Windows). Ми знаємо імена цих файлів, тому можемо використовувати функцію `range`, щоб перебрати їх і вставити їх вміст у наш ConfigMap. + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + {{- $files := .Files }} + {{- range tuple "config1.toml" "config2.toml" "config3.toml" }} + {{ . }}: |- + {{ $files.Get . }} + {{- end }} +``` + +Цей ConfigMap використовує кілька технік, обговорених у попередніх розділах. Наприклад, ми створюємо змінну `$files`, щоб зберегти посилання на обʼєкт `.Files`. Ми також використовуємо функцію `tuple`, щоб створити список файлів, які ми перебираємо. Потім ми виводимо кожне імʼя файлу (`{{ . }}: |-`) після чого йде вміст файлу `{{ $files.Get . }}`. + +Запуск цього шаблону створить один ConfigMap з вмістом усіх трьох файлів: + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: quieting-giraf-configmap +data: + config1.toml: |- + message = Hello from config 1 + + config2.toml: |- + message = This is config 2 + + config3.toml: |- + message = Goodbye from config 3 +``` + +## Помічники оброки шляхів {#path-helpers} + +При роботі з файлами може бути дуже корисно виконувати деякі стандартні операції з самими шляхами файлів. Для цього Helm імплементує багато функцій з пакета Go [path](https://golang.org/pkg/path/). Вони всі доступні з такими ж іменами, як у пакеті Go, але з маленькою першою літерою. Наприклад, `Base` стає `base` і т.д. + +Імпортовані функції: + +- Base +- Dir +- Ext +- IsAbs +- Clean + +## Шаблони glob {#glob-patterns} + +Коли ваш чарт зростає, ви можете знайти необхідність організувати ваші файли більше, і тому ми надаємо метод `Files.Glob(pattern string)` для допомоги у витягуванні певних файлів з усією гнучкістю [шаблонів glob](https://godoc.org/github.com/gobwas/glob). + +`.Glob` повертає тип `Files`, тому ви можете викликати будь-які методи `Files` на повернутому обʼєкті. + +Наприклад, уявіть структуру директорій: + +```none +foo/: + foo.txt foo.yaml + +bar/: + bar.go bar.conf baz.yaml +``` + +У вас є кілька варіантів з Globs: + +```yaml +{{ $currentScope := .}} +{{ range $path, $_ := .Files.Glob "**.yaml" }} + {{- with $currentScope}} + {{ .Files.Get $path }} + {{- end }} +{{ end }} +``` + +Або + +```yaml +{{ range $path, $_ := .Files.Glob "**.yaml" }} + {{ $.Files.Get $path }} +{{ end }} +``` + +## Утиліти для ConfigMap і Secrets {#configmap-and-secrets-utility-functions} + +(Доступні з Helm 2.0.2 і пізніше) + +Дуже часто потрібно помістити вміст файлів як у ConfigMaps, так і в Secrets, для монтування в ваші podʼи під час виконання. Для цього ми надаємо кілька методів утиліт для типу `Files`. + +Для подальшої організації особливо корисно використовувати ці методи разом з методом `Glob`. + +Задана структура теки з прикладу [Glob](#glob-patterns): + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: conf +data: +{{ (.Files.Glob "foo/*").AsConfig | indent 2 }} +--- +apiVersion: v1 +kind: Secret +metadata: + name: very-secret +type: Opaque +data: +{{ (.Files.Glob "bar/*").AsSecrets | indent 2 }} +``` + +## Кодування {#encoding} + +Ви можете імплементувати файл і змусити шаблон закодувати його в base-64, щоб забезпечити успішну передачу: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: {{ .Release.Name }}-secret +type: Opaque +data: + token: |- + {{ .Files.Get "config1.toml" | b64enc }} +``` + +Вищенаведене візьме той самий файл `config1.toml`, який ми використовували раніше, і закодує його: + +```yaml +# Source: mychart/templates/secret.yaml +apiVersion: v1 +kind: Secret +metadata: + name: lucky-turkey-secret +type: Opaque +data: + token: |- + bWVzc2FnZSA9IEhlbGxvIGZyb20gY29uZmlnIDEK +``` + +## Рядки {#lines} + +Іноді потрібно отримати доступ до кожного рядка файлу у вашому шаблоні. Ми надаємо зручний метод `Lines` для цього. + +Ви можете перебрати `Lines`, використовуючи функцію `range`: + +```yaml +data: + some-file.txt: {{ range .Files.Lines "foo/bar.txt" }} + {{ . }}{{ end }} +``` + +Немає можливості передавати файли, що знаходяться поза чартом, під час `helm install`. Тому, якщо ви просите користувачів надати дані, їх потрібно завантажити за допомогою `helm install -f` або `helm install --set`. + +Це обговорення завершує наше занурення в інструменти та техніки написання шаблонів Helm. У наступному розділі ми побачимо, як можна використовувати один спеціальний файл, `templates/NOTES.txt`, для надсилання інструкцій після установки користувачам вашого чарту. diff --git a/content/uk/docs/chart_template_guide/builtin_objects.md b/content/uk/docs/chart_template_guide/builtin_objects.md new file mode 100644 index 000000000..8882d87cb --- /dev/null +++ b/content/uk/docs/chart_template_guide/builtin_objects.md @@ -0,0 +1,46 @@ +--- +title: "Вбудовані обʼєкти" +description: "Вбудовані обʼєкти, доступні для шаблонів." +weight: 3 +--- + +Обʼєкти передаються в шаблон з рушія обробки шаблонів. І ваш код може передавати обʼєкти далі (ми побачимо приклади, коли розглянемо оператори `with` та `range`). Є навіть кілька способів створити нові обʼєкти всередині ваших шаблонів, як, наприклад, з функцією `tuple`, яку ми розглянемо пізніше. + +Обʼєкти можуть бути простими та мати лише одне значення. Або вони можуть містити інші обʼєкти чи функції. Наприклад, обʼєкт `Release` містить кілька обʼєктів (наприклад, `Release.Name`), а обʼєкт `Files` має кілька функцій. + +У попередньому розділі ми використовували `{{ .Release.Name }}`, щоб вставити імʼя релізу в шаблон. `Release` — один з обʼєктів верхнього рівня, до якого ви можете отримати доступ у своїх шаблонах. + +- `Release`: Цей обʼєкт описує сам реліз. Він містить кілька обʼєктів: + - `Release.Name`: Імʼя релізу + - `Release.Namespace`: Простір імен, у який буде здійснено реліз (якщо маніфест не перевизначить) + - `Release.IsUpgrade`: Це значення буде `true`, якщо поточна операція є оновленням або відкатом. + - `Release.IsInstall`: Це значення буде `true`, якщо поточна операція є встановленням. + - `Release.Revision`: Номер ревізії для цього релізу. Під час встановлення це 1, і він збільшується з кожним оновленням або відкатом. + - `Release.Service`: Сервіс, який обробляє поточний шаблон. У Helm це завжди `Helm`. +- `Values`: Значення, передані в шаблон з файлу `values.yaml` і з файлів, наданих користувачем. Стандартно `Values` порожній. +- `Chart`: Вміст файлу `Chart.yaml`. Будь-які дані в `Chart.yaml` будуть доступні тут. Наприклад, `{{ .Chart.Name }}-{{ .Chart.Version }}` виведе `mychart-0.1.0`. + - Доступні поля перелічені в [довіднику по Chart]({{< ref "/docs/topics/charts.md#the-chartyaml-file" >}}) +- `Subcharts`: Надає доступ до області дії (.Values, .Charts, .Releases тощо) субшаблонів з батьківського шаблону. Наприклад, `.Subcharts.mySubChart.myValue`, щоб отримати доступ до `myValue` у шаблоні `mySubChart`. +- `Files`: Це надає доступ до всіх не-спеціальних файлів у шаблоні. Ви не можете використовувати його для доступу до шаблонів, але можете використовувати його для доступу до інших файлів у шаблоні. Див. розділ [Доступ до файлів]({{< ref "/docs/chart_template_guide/accessing_files.md" >}}) для отримання додаткової інформації. + - `Files.Get` — це функція для отримання файлу за іменем (`.Files.Get config.ini`). + - `Files.GetBytes` — це функція для отримання вмісту файлу у вигляді масиву байтів, а не рядка. Це корисно для таких речей, як образи. + - `Files.Glob` — це функція, яка повертає список файлів, імена яких відповідають заданому шаблону оболонки. + - `Files.Lines` — це функція, яка зчитує файл рядок за рядком. Це корисно для ітерації по кожному рядку у файлі. + - `Files.AsSecrets` — це функція, яка повертає вміст файлів у вигляді Base64-кодованих рядків. + - `Files.AsConfig` — це функція, яка повертає вміст файлів у вигляді YAML map. +- `Capabilities`: Надає інформацію про можливості, які підтримує кластер Kubernetes. + - `Capabilities.APIVersions` — це набір версій. + - `Capabilities.APIVersions.Has $version` вказує на те, чи доступна версія (наприклад, `batch/v1`) або ресурс (наприклад, `apps/v1/Deployment`) у кластері. + - `Capabilities.KubeVersion` і `Capabilities.KubeVersion.Version` — це версія Kubernetes. + - `Capabilities.KubeVersion.Major` — це основна версія Kubernetes. + - `Capabilities.KubeVersion.Minor` — це мінорна версія Kubernetes. + - `Capabilities.HelmVersion` — це обʼєкт, який містить деталі версії Helm, це той самий вивід, що і `helm version`. + - `Capabilities.HelmVersion.Version` — це поточна версія Helm у форматі semver. + - `Capabilities.HelmVersion.GitCommit` — це Git-ідентифікатор SHA1 для Helm. + - `Capabilities.HelmVersion.GitTreeState` — це стан дерева git для Helm. + - `Capabilities.HelmVersion.GoVersion` — це версія компілятора Go, який використовувався. +- `Template`: Містить інформацію про поточний шаблон, який виконується. + - `Template.Name`: Іменований шлях до поточного шаблону (наприклад, `mychart/templates/mytemplate.yaml`). + - `Template.BasePath`: Іменований шлях до теки шаблонів поточного шаблону (наприклад, `mychart/templates`). + +Вбудовані значення завжди починаються з великої літери. Це відповідає угоді про найменування у Go. Коли ви створюєте власні імена, ви можете використовувати угоду, яка підходить вашій команді. Деякі команди, як і багато тих, чиї шаблони ви можете бачити на [Artifact Hub](https://artifacthub.io/packages/search?kind=0), обирають використовувати лише початкові малі літери, щоб відрізнити локальні імена від вбудованих. У цьому посібнику ми дотримуємося цієї угоди. diff --git a/content/uk/docs/chart_template_guide/control_structures.md b/content/uk/docs/chart_template_guide/control_structures.md new file mode 100644 index 000000000..f9ec47372 --- /dev/null +++ b/content/uk/docs/chart_template_guide/control_structures.md @@ -0,0 +1,385 @@ +--- +title: "Керування потоком" +description: "Швидкий огляд структури керування потоком в шаблонах." +weight: 7 +--- + +Структури керування (називаються "діями" в термінології шаблонів) надають вам, автору шаблонів, можливість контролювати потік генерації шаблону. Мова шаблонів Helm надає такі структури керування: + +- `if`/`else` для створення умовних блоків +- `with` для визначення області видимості +- `range`, який надає цикл "for each" + +Окрім цих, є кілька дій для оголошення та використання іменованих сегментів шаблону: + +- `define` оголошує новий іменований шаблон всередині вашого шаблону +- `template` імплементує іменований шаблон +- `block` оголошує спеціальний тип заповнювальної області шаблону + +У цьому розділі ми розглянемо `if`, `with` та `range`. Інші дії будуть розглянуті в розділі "Іменовані шаблони" пізніше в цьому посібнику. + +## If/Else + +Перша структура керування, яку ми розглянемо, використовується для умовного включення блоків тексту в шаблоні. Це блоки `if`/`else`. + +Основна структура блоку з умовою виглядає так: + +```none +{{ if PIPELINE }} + # Щось зробити +{{ else if OTHER PIPELINE }} + # Зробити щось інше +{{ else }} + # Стандартне значення +{{ end }} +``` + +Зверніть увагу, що тепер ми говоримо про _пайплайни_ замість значень. Причина в цьому полягає в тому, щоб уточнити, що структури керування можуть виконувати цілий пайплайн, а не лише оцінювати значення. + +Пайплайн вважається _хибним_, якщо значення є: + +- булевим хибним +- числовим нулем +- порожнім рядком +- `nil` (порожнім або null) +- порожньою колекцією (`map`, `slice`, `tuple`, `dict`, `array`) + +У всіх інших умовах умова є істинною. + +Додамо просту умовну конструкцію до нашого ConfigMap. Ми додамо ще одне налаштування, якщо напій встановлений на каву: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + drink: {{ .Values.favorite.drink | default "tea" | quote }} + food: {{ .Values.favorite.food | upper | quote }} + {{ if eq .Values.favorite.drink "coffee" }}mug: "true"{{ end }} +``` + +Оскільки ми закоментували `drink: coffee` у нашому останньому прикладі, вихідний файл не повинен містити прапорець `mug: "true"`. Але якщо ми додамо цей рядок назад у наш файл `values.yaml`, вихід виглядатиме так: + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: eyewitness-elk-configmap +data: + myvalue: "Hello World" + drink: "coffee" + food: "PIZZA" + mug: "true" +``` + +## Контроль пробілів {#controlling-whitespace} + +Під час роботи з умовами варто звернути увагу на те, як контролюється кількість пробілів у шаблонах. Розглянемо попередній приклад і відформатуємо його для зручнішого читання: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + drink: {{ .Values.favorite.drink | default "tea" | quote }} + food: {{ .Values.favorite.food | upper | quote }} + {{ if eq .Values.favorite.drink "coffee" }} + mug: "true" + {{ end }} +``` + +Спочатку це має гарний вигляд. Але якщо ми пропустимо його через рушій шаблонів, отримаємо неприємний результат: + +```console +$ helm install --dry-run --debug ./mychart +SERVER: "localhost:44134" +CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart +Error: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key +``` + +Що сталося? Ми згенерували некоректний YAML через пробіли. + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: eyewitness-elk-configmap +data: + myvalue: "Hello World" + drink: "coffee" + food: "PIZZA" + mug: "true" +``` + +`mug` має невірний відступ. Виправимо це, зменшивши відступ цього рядка, і запустимо знову: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + drink: {{ .Values.favorite.drink | default "tea" | quote }} + food: {{ .Values.favorite.food | upper | quote }} + {{ if eq .Values.favorite.drink "coffee" }} + mug: "true" + {{ end }} +``` + +Коли ми запустимо це, отримаємо валідний YAML, але з кількома порожніми рядками: + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: telling-chimp-configmap +data: + myvalue: "Hello World" + drink: "coffee" + food: "PIZZA" + + mug: "true" +``` + +Помітно, що у нас є кілька пустих рядків у YAML. Чому? Коли рушій шаблонів виконує шаблон, він _видаляє_ вміст всередині `{{` і `}}`, але залишає пробіли без змін. + +YAML надає значення пробілам, тому управління пробілами стає важливим. На щастя, шаблони Helm мають кілька інструментів у поміч. + +По-перше, синтаксис фігурних дужок шаблонів можна модифікувати за допомогою спеціальних символів, щоб вказати движку шаблонів обрізати пробіли. `{{- ` (з тире і пробілом) вказує, що пробіли зліва повинні бути видалені, тоді як ` -}}` означає, що пробіли справа повинні бути видалені. _Будьте обережні! Нові рядки — це пробіли!_ + +> Переконайтеся, що є пробіл між `-` і рештою вашої директиви. `{{- 3 }}` означає "вирізати ліві пробіли та вивести 3", тоді як `{{-3 }}` означає "вивести -3". + +Використовуючи цей синтаксис, ми можемо змінити наш шаблон, щоб позбутися від тих нових рядків: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + drink: {{ .Values.favorite.drink | default "tea" | quote }} + food: {{ .Values.favorite.food | upper | quote }} + {{- if eq .Values.favorite.drink "coffee" }} + mug: "true" + {{- end }} +``` + +Щоб прояснити це, відзначимо кожен пробіл, який буде видалено відповідно до цього правила. `*` в кінці рядка вказує на символ нового рядка, який буде видалений: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + drink: {{ .Values.favorite.drink | default "tea" | quote }} + food: {{ .Values.favorite.food | upper | quote }}* +**{{- if eq .Values.favorite.drink "coffee" }} + mug: "true"* +**{{- end }} + +``` + +Зважаючи на це, ми можемо запустити наш шаблон через Helm і побачити результат: + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: clunky-cat-configmap +data: + myvalue: "Hello World" + drink: "coffee" + food: "PIZZA" + mug: "true" +``` + +Будьте обережні з модифікаторами обрізання пробілів. Легко випадково зробити ось так: + +```yaml + food: {{ .Values.favorite.food | upper | quote }} + {{- if eq .Values.favorite.drink "coffee" -}} + mug: "true" + {{- end -}} + +``` + +Це створить `food: "PIZZA"mug: "true"`, оскільки пробіли з обох сторін будуть видалені. + +> Для деталей про контроль пробілів у шаблонах дивіться [Офіційну документацію Go шаблонів](https://godoc.org/text/template) + +Нарешті, іноді легше сказати системі шаблонів, як вам потрібно робити відступи, замість того, щоб намагатися освоїти розташування пробілів у директивах шаблону. З цієї причини іноді корисно використовувати функцію `indent` (`{{ indent 2 "mug:true" }}`). + +## Модифікація області видимості за допомогою `with` {#modifying-scope-using-with} + +Наступна структура управління, яку розглянемо, це дія `with`. Вона контролює область видимості змінних. Нагадаємо, що `.` є посиланням на _поточну область видимості_. Отже, `.Values` вказує шаблону знайти обʼєкт `Values` у поточній області видимості. + +Синтаксис для `with` схожий на простий оператор `if`: + +```none +{{ with PIPELINE }} + # обмежена область видимості +{{ end }} +``` + +Області видимості можуть змінюватися. `with` дозволяє вам встановити поточну область видимості (`.`) на певний обʼєкт. Наприклад, ми працювали з `.Values.favorite`. Перепишемо наш ConfigMap, щоб змінити область видимості `.` на `.Values.favorite`: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + {{- with .Values.favorite }} + drink: {{ .drink | default "tea" | quote }} + food: {{ .food | upper | quote }} + {{- end }} +``` + +Зверніть увагу, що ми видалили умову `if` з попереднього прикладу, оскільки вона тепер непотрібна — блок після `with` виконується лише якщо значення `PIPELINE` не є порожнім. + +Тепер ми можемо звертатися до `.drink` і `.food` без додаткових уточнень. Це відбувається тому, що оператор `with` встановлює `.` на `.Values.favorite`. `.` скидається до попередньої області видимості після `{{ end }}`. + +Але є одне застереження! Усередині обмеженої області видимості ви не зможете отримати доступ до інших обʼєктів з батьківської області видимості за допомогою `.`. Наприклад, це не спрацює: + +```yaml + {{- with .Values.favorite }} + drink: {{ .drink | default "tea" | quote }} + food: {{ .food | upper | quote }} + release: {{ .Release.Name }} + {{- end }} +``` + +Це викличе помилку, оскільки `Release.Name` не знаходиться в межах обмеженої області видимості для `.`. Однак, якщо ми поміняємо місцями останні два рядки, все працюватиме як очікувалося, тому що область видимості скидається після `{{ end }}`. + +```yaml + {{- with .Values.favorite }} + drink: {{ .drink | default "tea" | quote }} + food: {{ .food | upper | quote }} + {{- end }} + release: {{ .Release.Name }} +``` + +Або ми можемо використовувати `$` для доступу до обʼєкта `Release.Name` з батьківської області видимості. `$` привʼязується до кореневої області видимості на початку виконання шаблону і не змінюється під час виконання шаблону. Ось таке рішення також спрацює: + +```yaml + {{- with .Values.favorite }} + drink: {{ .drink | default "tea" | quote }} + food: {{ .food | upper | quote }} + release: {{ $.Release.Name }} + {{- end }} +``` + +Після розгляду `range` ми перейдемо до змінних шаблону, які пропонують одне рішення для проблеми з областю видимості вище. + +## Цикли за допомогою дії `range` {#looping-with-the-range-action} + +Багато мов програмування підтримують цикли за допомогою `for` циклів, `foreach` циклів або подібних функціональних механізмів. У мові шаблонів Helm, для перебору колекції використовується оператор `range`. + +Спочатку додамо список інгредієнтів для піци до нашого файлу `values.yaml`: + +```yaml +favorite: + drink: coffee + food: pizza +pizzaToppings: + - mushrooms + - cheese + - peppers + - onions +``` + +Тепер у нас є список (в шаблонах він називається `slice`) інгредієнтів для піци. Ми можемо змінити наш шаблон, щоб вивести цей список у наш ConfigMap: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + {{- with .Values.favorite }} + drink: {{ .drink | default "tea" | quote }} + food: {{ .food | upper | quote }} + {{- end }} + toppings: |- + {{- range .Values.pizzaToppings }} + - {{ . | title | quote }} + {{- end }} +``` + +Ми можемо використовувати `$` для доступу до списку `Values.pizzaToppings` з батьківської області видимості. `$` привʼязується до кореневої області видимості на початку виконання шаблону і не змінюється під час виконання шаблону. Ось таке рішення також спрацює: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + {{- with .Values.favorite }} + drink: {{ .drink | default "tea" | quote }} + food: {{ .food | upper | quote }} + toppings: |- + {{- range $.Values.pizzaToppings }} + - {{ . | title | quote }} + {{- end }} + {{- end }} +``` + +Розглянемо детальніше список `toppings:`. Функція `range` буде "перебирати" список `pizzaToppings`. Але тепер відбувається щось цікаве. Так само як `with` встановлює область видимості для `.`, так і оператор `range` встановлює область видимості. Кожного разу під час циклу `.` встановлюється на поточний інгредієнт для піци. Тобто, під час першої ітерації `.` буде дорівнювати `mushrooms`. Під час другої ітерації він буде дорівнювати `cheese`, і так далі. + +Ми можемо безпосередньо передавати значення `.` в конвеєр, тому коли ми використовуємо `{{ . | title | quote }}`, воно передається в `title` (функцію для перетворення на заголовні літери) і потім в `quote`. Якщо ми запустимо цей шаблон, результат буде: + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: edgy-dragonfly-configmap +data: + myvalue: "Hello World" + drink: "coffee" + food: "PIZZA" + toppings: |- + - "Mushrooms" + - "Cheese" + - "Peppers" + - "Onions" +``` + +У цьому прикладі ми зробили дещо хитре. Лінія `toppings: |-` оголошує багаторядковий рядок. Отже, наш список інгредієнтів для піци насправді не є YAML списком. Це великий рядок. Чому ми так робимо? Тому що дані в ConfigMaps `data` складаються з пар ключ/значення, де і ключ, і значення є простими рядками. Щоб зрозуміти, чому це так, ознайомтеся з [документацією Kubernetes ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/). Для нас цей нюанс не так важливий. + +> Маркер `|-` в YAML приймає багаторядковий рядок. Це може бути корисною технікою для вбудовування великих блоків даних у ваші маніфести, як показано тут. + +Іноді корисно швидко створити список у шаблоні, а потім перебирати цей список. Шаблони Helm мають функцію для спрощення цього завдання: `tuple`. У компʼютерних науках кортеж (tuple) — це список фіксованого розміру, але з довільними типами даних. Це приблизно передає те, як використовується `tuple`. + +```yaml + sizes: |- + {{- range tuple "small" "medium" "large" }} + - {{ . }} + {{- end }} +``` + +Вищезазначене створить: + +```yaml + sizes: |- + - small + - medium + - large +``` + +Окрім списків і кортежів, `range` можна використовувати для перебору колекцій, які мають ключ і значення (як `map` або `dict`). Ми розглянемо, як це зробити в наступному розділі, коли введемо змінні шаблону. diff --git a/content/uk/docs/chart_template_guide/data_types.md b/content/uk/docs/chart_template_guide/data_types.md new file mode 100644 index 000000000..fec177262 --- /dev/null +++ b/content/uk/docs/chart_template_guide/data_types.md @@ -0,0 +1,18 @@ +--- +title: "Додаток: Типи даних Go та шаблони" +description: "Короткий огляд змінних у шаблонах." +weight: 16 +--- + +Мова шаблонів Helm реалізована мовою програмування Go, яка має сувору типізацію. З цієї причини змінні в шаблонах мають _типи_. Здебільшого змінні будуть представлені одним із наступних типів: + +- `string`: Рядок тексту +- `bool`: значення `true` або `false` +- `int`: Ціле число (існують також 8, 16, 32 і 64-бітні знакові та беззнакові варіанти) +- `float64`: 64-бітне число з плаваючою комою (також є 8, 16 та 32-бітні різновиди) +- `byte slice` (`[]byte`): Масив байтів, часто використовується для зберігання (можливо) бінарних даних +- `struct`: Обʼєкт із властивостями та методами +- `slice`: Список з індексами одного з попередніх типів +- `map`: Map з ключами-рядками (`map[string]interface{}`), де значенням є один із попередніх типів + +Існує багато інших типів у Go, і іноді вам доведеться конвертувати між ними в шаблонах. Найпростіший спосіб налагодження типу обʼєкта — передати його через `printf "%t"` у шаблоні, що виведе тип. Також корисно ознайомитись із функціями `typeOf` та `kindOf`. diff --git a/content/uk/docs/chart_template_guide/debugging.md b/content/uk/docs/chart_template_guide/debugging.md new file mode 100644 index 000000000..0b7c49b08 --- /dev/null +++ b/content/uk/docs/chart_template_guide/debugging.md @@ -0,0 +1,32 @@ +--- +title: "Виправлення помилок у шаблонах" +description: "Виправлення проблем з розгортанням чартів." +weight: 13 +--- + +Виправлення помилок у шаблонах може бути складним, оскільки відрендерені шаблони надсилаються на сервер API Kubernetes, який може відхиляти YAML-файли з інших причин, окрім форматування. + +Є кілька команд, які можуть допомогти в процесі налагодження: + +- `helm lint` є вашим основним інструментом для перевірки того, чи ваш чарт відповідає найкращим практикам. +- `helm template --debug` дозволяє тестувати рендеринг шаблонів чарту локально. +- `helm install --dry-run --debug` також рендерить ваш чарт локально без його встановлення, але також перевіряє, чи конфліктують ресурси вже з запущеними на кластері. Налаштування `--dry-run=server` додатково виконає будь-які `lookup` у вашому чарті на сервері. +- `helm get manifest`: Це хороший спосіб побачити, які шаблони встановлені на сервері. + +Коли ваш YAML не проходить перевірку, але ви хочете побачити, що було згенеровано, простий спосіб отримати YAML — закоментувати проблемний розділ у шаблоні, а потім повторно запустити `helm install --dry-run --debug`: + +```yaml +apiVersion: v2 +# деяка: проблемна секція +# {{ .Values.foo | quote }} +``` + +Вищенаведене буде відрендерене і повернуто з коментарями, що дозволяє швидко переглядати згенерований контент без помилок парсингу YAML: + +```yaml +apiVersion: v2 +# деяка: проблемна секція +# "bar" +``` + +Це забезпечує швидкий спосіб перегляду згенерованого контенту без блокування помилками парсингу YAML. diff --git a/content/uk/docs/chart_template_guide/function_list.md b/content/uk/docs/chart_template_guide/function_list.md new file mode 100644 index 000000000..1ce0d770b --- /dev/null +++ b/content/uk/docs/chart_template_guide/function_list.md @@ -0,0 +1,2044 @@ +--- +title: "Список функцій шаблонів" +description: "Список функцій шаблонів, доступних у Helm" +weight: 6 +--- + +Helm містить багато функцій шаблонів, якими ви можете скористатися у шаблонах. Вони перераховані тут і розбиті на наступні категорії: + +* [Криптографія та безпека](#cryptographic-and-security-functions) +* [Дата](#date-functions) +* [Словники](#dictionaries-and-dict-functions) +* [Кодування](#encoding-functions) +* [Шлях до файлу](#file-path-functions) +* [Kubernetes та чарти](#kubernetes-and-chart-functions) +* [Логіка та керування потоком](#logic-and-flow-control-functions) +* [Списки](#lists-and-list-functions) +* [Математичні функції](#math-functions) +* [Математичні обчислення з комою](#float-math-functions) +* [Мережа](#network-functions) +* [Аналіз](#reflection-functions) +* [Регулярні вирази](#regular-expressions) +* [Семантичні версії](#semantic-version-functions) +* [Рядки](#string-functions) +* [Перетворення типів](#type-conversion-functions) +* [URL](#url-functions) +* [UUID](#uuid-functions) + +## Логічні функції та функції керування потоком {#logic-and-flow-control-functions} + +Helm містить численні логічні та контрольні функції, включаючи [and](#and), [coalesce](#coalesce), [default](#default), [empty](#empty), [eq](#eq), [fail](#fail), [ge](#ge), [gt](#gt), [le](#le), [lt](#lt), [ne](#ne), [not](#not), [or](#or), і [required](#required). + +### and + +Повертає логічне AND для двох або більше аргументів (перший пустий аргумент або останній аргумент). + +```none +and .Arg1 .Arg2 +``` + +### or + +Повертає логічне OR для двох або більше аргументів (перший непустий аргумент або останній аргумент). + +```none +or .Arg1 .Arg2 +``` + +### not + +Повертає логічне заперечення свого аргументу. + +```none +not .Arg +``` + +### eq + +Повертає логічну рівність аргументів (наприклад, Arg1 == Arg2). + +```none +eq .Arg1 .Arg2 +``` + +### ne + +Повертає логічну нерівність аргументів (наприклад, Arg1 != Arg2) + +```none +ne .Arg1 .Arg2 +``` + +### lt + +Повертає логічне `true`, якщо перший аргумент менший за другий. В іншому випадку повертає `false` (наприклад, Arg1 < Arg2). + +```none +lt .Arg1 .Arg2 +``` + +### le + +Повертає логічне `true`, якщо перший аргумент менший або дорівнює другому. В іншому випадку повертає `false` (наприклад, Arg1 <= Arg2). + +```none +le .Arg1 .Arg2 +``` + +### gt + +Повертає логічне `true`, якщо перший аргумент більший за другий. В іншому випадку повертає `false` (наприклад, Arg1 > Arg2). + +```none +gt .Arg1 .Arg2 +``` + +### ge + +Повертає логічне `true`, якщо перший аргумент більший або дорівнює другому. В іншому випадку повертає `false` (наприклад, Arg1 >= Arg2). + +```none +ge .Arg1 .Arg2 +``` + +### default + +Щоб встановити просте стандартне значення, використовуйте `default`: + +```none +default "foo" .Bar +``` + +У наведеному прикладі, якщо `.Bar` має непусте значення, воно буде використане. Якщо ж воно пусте, повернеться `foo`. + +Визначення "пустого" залежить від типу: + +* Числові: 0 +* Рядок: "" +* Списки: `[]` +* Словники: `{}` +* Логічний: `false` +* І завжди `nil` (або null) + +Для структур немає визначення пустого значення, тому структура ніколи не поверне стандартного значення. + +### required + +Вкажіть значення, які повинні бути встановлені, за допомогою `required`: + +```none +required "A valid foo is required!" .Bar +``` + +Якщо `.Bar` є пустим або не визначеним (див. [default](#default) щодо того, як це оцінюється), шаблон не буде згенерований і поверне надане повідомлення про помилку. + +### empty + +Функція `empty` повертає `true`, якщо надане значення вважається пустим, і `false` в іншому випадку. Пусті значення перелічені в розділі `default`. + +```none +empty .Foo +``` + +Зверніть увагу, що в умовах шаблонів Go пустота розраховується автоматично. Таким чином, рідко потрібно використовувати `if not empty .Foo`. Замість цього просто використовуйте `if .Foo`. + +### fail + +Безумовно повертає пустий `string` та `error` з зазначеним текстом. Це корисно в ситуаціях, коли інші умови визначили, що рендеринг шаблону повинен зазнати невдачі. + +```none +fail "Please accept the end user license agreement" +``` + +### coalesce + +Функція `coalesce` приймає список значень і повертає перше непусте. + +```none +coalesce 0 1 2 +``` + +У наведеному випадку повертає `1`. + +Ця функція корисна для перевірки кількох змінних або значень: + +```none +coalesce .name .parent.name "Matt" +``` + +Цей приклад спочатку перевірить, чи є `.name` непустим. Якщо це так, буде повернене це значення. Якщо ж воно _пусте_, `coalesce` перевірить `.parent.name` на пустоту. Нарешті, якщо обидва `.name` і `.parent.name` пусті, буде повернене `Matt`. + +### ternary + +Функція `ternary` приймає два значення і тестове значення. Якщо тестове значення є `true`, повернеться перше значення. Якщо тестове значення є пустим, повернеться друге значення. Це подібно до тернарного оператора в C та інших мовах програмування. + +#### тестове значення true {#true-test-value} + +```none +ternary "foo" "bar" true +``` + +або + +```none +true | ternary "foo" "bar" +``` + +У цьому випадку повертається `"foo"`. + +#### тестове значення false {#false-test-value} + +```none +ternary "foo" "bar" false +``` + +або + +```none +false | ternary "foo" "bar" +``` + +У цьому випадку повертається `"bar"`. + +## Функції для роботи з рядками {#string-functions} + +Helm включає такі функції для рядків: [abbrev](#abbrev), [abbrevboth](#abbrevboth), [camelcase](#camelcase), [cat](#cat), [contains](#contains), [hasPrefix](#hasprefix-and-hassuffix), [hasSuffix](#hasprefix-and-hassuffix), [indent](#indent), [initials](#initials), [kebabcase](#kebabcase), [lower](#lower), [nindent](#nindent), [nospace](#nospace), [plural](#plural), [print](#print), [printf](#printf), [println](#println), [quote](#quote-and-squote), [randAlpha](#randalphanum-randalpha-randnumeric-and-randascii), [randAlphaNum](#randalphanum-randalpha-randnumeric-and-randascii), [randAscii](#randalphanum-randalpha-randnumeric-and-randascii), [randNumeric](#randalphanum-randalpha-randnumeric-and-randascii), [repeat](#repeat), [replace](#replace), [shuffle](#shuffle), [snakecase](#snakecase), [squote](#quote-and-squote), [substr](#substr), [swapcase](#swapcase), [title](#title), [trim](#trim), [trimAll](#trimall), [trimPrefix](#trimprefix), [trimSuffix](#trimsuffix), [trunc](#trunc), [untitle](#untitle), [upper](#upper), [wrap](#wrap), і [wrapWith](#wrapwith). + +### print + +Повертає рядок, що є комбінацією його частин. + +```none +print "Matt has " .Dogs " dogs" +``` + +Типи, які не є рядками, перетворюються на рядки, якщо це можливо. + +Зверніть увагу, що коли два аргументи поруч один з одним не є рядками, між ними додається пробіл. + +### println + +Працює так само як [print](#print), але додає новий рядок наприкінці. + +### printf + +Повертає рядок на основі відформатованого рядка та аргументів, що передаються у до нього. + +```none +printf "%s has %d dogs." .Name .NumberDogs +``` + +Заповнювач, який слід використовувати, залежить від типу переданого аргументу. Серед них: + +Загального призначення: + +* `%v` значення в стандартному форматі + * при друку словників, прапорець `+` (%+v) додає імена полів +* `%%` літеральний знак відсотка; не використовує значення + +Логічний: + +* `%t` слово true або false + +Цілі числа: + +* `%b` двійкові, основа 2 +* `%c` символ, що відповідає точці Unicode +* `%d` десяткові, основа 10 +* `%o` вісімкові, основа 8 +* `%O` основа 8 з префіксом 0o +* `%q` вісімкові, однорядковий літерал символу, безпечно екранований +* `%x` шістнадцяткові, основа 16, з малими літерами для a-f +* `%X` шістнадцяткові, основа 16, з великими літерами для A-F +* `%U` Unicode формат: U+1234; те ж саме, що "U+%04X" + +Числа з плаваючою комою та складові частини: + +* `%b` десятковий формат без наукової нотації з показником ступеня двійки, наприклад + -123456p-78 +* `%e` наукова нотація, наприклад -1.234456e+78 +* `%E` наукова нотація, наприклад -1.234456E+78 +* `%f` десятковий формат без експоненти, наприклад 123.456 +* `%F` синонім для %f +* `%g` %e для великих експонент, %f в іншому випадку +* `%G` %E для великих експонент, %F в іншому випадку +* `%x` шістнадцяткова нотація (з десятковим показником ступеня), наприклад -0x1.23abcp+20 +* `%X` шістнадцяткова нотація у верхньому регістрі, наприклад -0X1.23ABCP+20 + +Рядок та зріз байтів (обробляються однаково з цими діями): + +* `%s` необроблені байти рядка або зрізу +* `%q` рядок в подвійних лапках, безпечно екранований +* `%x` основа 16, малий регістр, два символи на байт +* `%X` основа 16, великий регістр, два символи на байт + +Зріз: + +* `%p` адреса 0-го елемента у шістнадцятковій нотації, з передуючим 0x + +### trim + +Функція `trim` видаляє пробіли з обох сторін рядка: + +```none +trim " hello " +``` + +У результаті отримаємо `hello`. + +### trimAll + +Видаляє зазначені символи з початку та кінця рядка: + +```none +trimAll "$" "$5.00" +``` + +У результаті отримаємо `5.00` (як рядок). + +### trimPrefix + +Видаляє лише префікс з рядка: + +```none +trimPrefix "-" "-hello" +``` + +У результаті отримаємо `hello`. + +### trimSuffix + +Видаляє лише суфікс з рядка: + +```none +trimSuffix "-" "hello-" +``` + +У результаті отримаємо `hello`. + +### lower + +Перетворює весь рядок у нижній регістр: + +```none +lower "HELLO" +``` + +У результаті отримаємо `hello`. + +### upper + +Перетворює весь рядок у верхній регістр: + +```none +upper "hello" +``` + +У результаті отримаємо `HELLO`. + +### title + +Перетворює рядок у титульний регістр: + +```none +title "hello world" +``` + +У результаті отримаємо `Hello World`. + +### untitle + +Видаляє титульне оформлення. `untitle "Hello World"` поверне `hello world`. + +### repeat + +Повторює рядок кілька разів: + +```none +repeat 3 "hello" +``` + +У результаті отримаємо `hellohellohello`. + +### substr + +Отримує підрядок з рядка. Параметри: + +* start (int) +* end (int) +* рядок (string) + +```none +substr 0 5 "hello world" +``` + +У результаті отримаємо `hello`. + +### nospace + +Видаляє всі пробіли з рядка: + +```none +nospace "hello w o r l d" +``` + +У результаті отримаємо `helloworld`. + +### trunc + +Обрізає рядок: + +```none +trunc 5 "hello world" +``` + +У результаті отримаємо `hello`. + +```none +trunc -5 "hello world" +``` + +У результаті отримаємо `world`. + +### abbrev + +Обрізає рядок додаючи три крапки (`...`): + +Параметри: + +* максимальна довжина +* рядок + +```none +abbrev 5 "hello world" +``` + +У результаті отримаємо `he...`, оскільки ширина трьох крапок враховується до максимальної довжини. + +### abbrevboth + +Обрізає обидві сторони: + +```none +abbrevboth 5 10 "1234 5678 9123" +``` + +У результаті отримаємо `...5678...`. + +Параметри: + +* зсув ліворуч +* максимальна довжина +* рядок + +### initials + +Для кількох слів бере першу літеру кожного слова та обʼєднує їх: + +```none +initials "First Try" +``` + +У результаті отримаємо `FT`. + +### randAlphaNum, randAlpha, randNumeric та randAscii {#randalphanum-randalpha-randnumeric-and-randascii} + +Ці чотири функції генерують криптографічно безпечні (використовує ```crypto/rand```) випадкові рядки, але з різними базовими наборами символів: + +* `randAlphaNum` використовує `0-9a-zA-Z` +* `randAlpha` використовує `a-zA-Z` +* `randNumeric` використовує `0-9` +* `randAscii` використовує всі друковані ASCII символи + +Кожна з них приймає один параметр: цілу довжину рядка. + +```none +randNumeric 3 +``` + +У результаті отримаємо випадковий рядок з трьох цифр. + +### wrap + +Виконує перенесення тексту на вказаній кількості стовпців: + +```none +wrap 80 $someText +``` + +У результаті для рядка `$someText` буде виконано перенесення на 80-му стовпці. + +### wrapWith + +`wrapWith` працює так само як і `wrap`, але дозволяє вказати рядок для перенесення. +(`wrap` використовує `\n`) + +```none +wrapWith 5 "\t" "Hello World" +``` + +У результаті отримаємо `Hello World` (де пробіл є символом ASCII табуляції). + +### contains + +Перевіряє, чи один рядок міститься всередині іншого: + +```none +contains "cat" "catch" +``` + +У результаті отримаємо `true`, оскільки `catch` містить `cat`. + +### hasPrefix і hasSuffix {#hasprefix-and-hassuffix} + +Функції `hasPrefix` і `hasSuffix` перевіряють, чи має рядок заданий префікс або суфікс: + +```none +hasPrefix "cat" "catch" +``` + +У результаті отримаємо `true`, оскільки `catch` має префікс `cat`. + +### quote і squote {#quote-and-squote} + +Ці функції обгортають рядок у подвійні лапки (`quote`) або одинарні лапки (`squote`). + +### cat + +Функція `cat` обʼєднує кілька рядків в один, розділяючи їх пробілами: + +```none +cat "hello" "beautiful" "world" +``` + +У результаті отримаємо `hello beautiful world`. + +### indent + +Функція `indent` додає відступ у кожному рядку вказаного тексту на зазначену кількість символів. Це корисно для вирівнювання багаторядкових текстів: + +```none +indent 4 $lots_of_text +``` + +У результаті кожен рядок тексту буде мати відступ на 4 символи пробілу. + +### nindent + +Функція `nindent` є такою ж, як і `indent`, але додає новий рядок на початку рядка. + +```none +nindent 4 $lots_of_text +``` + +У результаті кожен рядок тексту буде мати відступ на 4 символи пробілу, а також буде додано новий рядок на початку. + +### replace + +Виконує просту заміну рядків. + +Вона приймає три аргументи: + +* рядок для заміни +* рядок, на який замінювати +* вихідний рядок + +```none +"I Am Henry VIII" | replace " " "-" +``` + +У результаті отримаємо `I-Am-Henry-VIII`. + +### plural + +Форма множини. + +```none +len $fish | plural "one anchovy" "many anchovies" +``` + +У наведеному випадку, якщо довжина рядка дорівнює 1, буде надруковано перший аргумент (`one anchovy`). В іншому випадку буде надруковано другий аргумент (`many anchovies`). + +Аргументи: + +* однина +* множина +* довжина (ціле число) + +ПРИМІТКА: Helm наразі не підтримує мови зі складнішими правилами множини. І `0` вважається множиною, оскільки англійська мова ставиться до нього саме так (`zero anchovies`). + +### snakecase + +Перетворює рядок з camelCase в snake_case. + +```none +snakecase "FirstName" +``` + +У результаті отримаємо `first_name`. + +### camelcase + +Перетворює рядок з snake_case в CamelCase. + +```none +camelcase "http_server" +``` + +У результаті отримаємо `HttpServer`. + +### kebabcase + +Перетворює рядок з camelCase в kebab-case. + +```none +kebabcase "FirstName" +``` + +У результаті отримаємо `first-name`. + +### swapcase + +Змінює регістр рядка за допомогою алгоритму на основі слів. + +Алгоритм перетворення: + +* Символи у верхньому регістрі перетворюються у нижній регістр +* Символи в титульному регістрі перетворюються у нижній регістр +* Символи у нижньому регістрі після пробілу або на початку перетворюються у титульний регістр +* Інші символи у нижньому регістрі перетворюються у верхній регістр +* Пробіли визначаються як unicode.IsSpace(char) + +```none +swapcase "This Is A.Test" +``` + +У результаті отримаємо `tHIS iS a.tEST`. + +### shuffle + +Перемішує рядок. + +```none +shuffle "hello" +``` + +У результаті отримаємо випадковий порядок літер у `hello`, можливо, `oelhl`. + +## Функції перетворення типів {#type-conversion-functions} + +Helm пропонує такі функції для перетворення типів: + +* `atoi`: Перетворює рядок на ціле число. +* `float64`: Перетворює на `float64`. +* `int`: Перетворює на `int` відповідно до ширини системи. +* `int64`: Перетворює на `int64`. +* `toDecimal`: Перетворює unix octal на `int64`. +* `toString`: Перетворює на рядок. +* `toStrings`: Перетворює список, зріз або масив на список рядків. +* `toJson` (`mustToJson`): Перетворює список, зріз, масив, словник або обʼєкт на JSON. +* `toPrettyJson` (`mustToPrettyJson`): Перетворює список, зріз, масив, словник або обʼєкт на форматований JSON. +* `toRawJson` (`mustToRawJson`): Перетворює список, зріз, масив, словник або обʼєкт на JSON з неекранованими HTML символами. +* `fromYaml`: Перетворює YAML рядок на обʼєкт. +* `fromJson`: Перетворює JSON рядок на обʼєкт. +* `fromJsonArray`: Перетворює JSON масив на список. +* `toYaml`: Перетворює список, зріз, масив, словник або обʼєкт на відформатований YAML. +* `toToml`: Перетворює список, зріз, масив, словник або обʼєкт на TOML. +* `fromYamlArray`: Перетворює YAML масив на список. + +### toStrings + +Перетворює колекцію схожу на список на зріз рядків. + +```none +list 1 2 3 | toStrings +``` + +Перетворює `1` на `"1"`, `2` на `"2"` і так далі, а потім повертає їх як список. + +### toDecimal + +Перетворює unix octal на десятковий формат. + +```none +"0777" | toDecimal +``` + +Перетворює `0777` на `511` і повертає значення як int64. + +### toJson, mustToJson + +Функція `toJson` кодує елемент у JSON рядок. Якщо елемент не може бути перетворений на JSON, функція поверне порожній рядок. `mustToJson` поверне помилку, якщо елемент не може бути закодований в JSON. + +```none +toJson .Item +``` + +Поверне JSON рядкове представлення `.Item`. + +### toPrettyJson, mustToPrettyJson + +Функція `toPrettyJson` кодує елемент у форматований (з відступами) JSON рядок. + +```none +toPrettyJson .Item +``` + +Поверне відформатоване JSON рядкове представлення `.Item`. + +### toRawJson, mustToRawJson + +Функція `toRawJson` кодує елемент у JSON рядок з неекранованими HTML символами. + +```none +toRawJson .Item +``` + +Поверне неекрановане JSON рядкове представлення `.Item`. + +### fromYaml + +Функція `fromYaml` приймає YAML рядок і повертає обʼєкт, який можна використовувати в шаблонах. + +Файл `yamls/person.yaml`: + +```yaml +name: Bob +age: 25 +hobbies: + - hiking + - fishing + - cooking +``` + +```yaml +{{- $person := .Files.Get "yamls/person.yaml" | fromYaml }} +greeting: | + Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. + My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}. +``` + +### fromJson + +Функція `fromJson` приймає JSON рядок і повертає обʼєкт, який можна використовувати в шаблонах. + +Файл `jsons/person.json`: + +```json +{ + "name": "Bob", + "age": 25, + "hobbies": [ + "hiking", + "fishing", + "cooking" + ] +} +``` + +```yaml +{{- $person := .Files.Get "jsons/person.json" | fromJson }} +greeting: | + Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. + My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}. +``` + +### fromJsonArray + +Функція `fromJsonArray` приймає JSON масив і повертає список, який можна використовувати в шаблонах. + +Файл `jsons/people.json`: + +```json +[ + { "name": "Bob","age": 25 }, + { "name": "Ram","age": 16 } +] +``` + +```yaml +{{- $people := .Files.Get "jsons/people.json" | fromJsonArray }} +{{- range $person := $people }} +greeting: | + Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. +{{ end }} +``` + +### fromYamlArray + +Функція `fromYamlArray` приймає YAML масив і повертає список, який можна використовувати в шаблонах. + +Файл `yamls/people.yml`: + +```yaml +- name: Bob + age: 25 +- name: Ram + age: 16 +``` + +```yaml +{{- $people := .Files.Get "yamls/people.yml" | fromYamlArray }} +{{- range $person := $people }} +greeting: | + Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. +{{ end }} +``` + +## Регулярні Вирази {#regular-expressions} + +Helm включає такі функції для роботи з регулярними виразами: [regexMatch](#regexmatch-mustregexmatch), [regexFindAll](#regexfindall-mustregexfindall), [regexFind](#regexfind-mustregexfind), [regexReplaceAll](#regexreplaceall-mustregexreplaceall), [regexReplaceAllLiteral](#regexreplaceallliteral-mustregexreplaceallliteral), [regexSplit](#regexsplit-mustregexsplit). + +### regexMatch, mustRegexMatch + +Повертає `true`, якщо вхідний рядок містить хоча б один збіг для регулярного виразу. + +```yaml +regexMatch "^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}$" "test@acme.com" +``` + +Поверне `true`. + +`regexMatch` викликає паніку у разі проблеми, а `mustRegexMatch` поверне помилку у рушії шаблонів у разі проблеми. + +### regexFindAll, mustRegexFindAll + +Повертає зріз усіх збігів регулярного виразу у вхідному рядку. Останній параметр `n` визначає кількість підрядків для повернення, де `-1` означає повернути всі збіги. + +```yaml +regexFindAll "[2,4,6,8]" "123456789" -1 +``` + +Поверне `[2 4 6 8]`. + +`regexFindAll` викликає паніку у разі проблеми, а `mustRegexFindAll` поверне помилку у рушії шаблонів у разі проблеми. + +### regexFind, mustRegexFind + +Повертає перший (зліва) збіг регулярного виразу у вхідному рядку. + +```yaml +regexFind "[a-zA-Z][1-9]" "abcd1234" +``` + +Поверне `d1`. + +`regexFind` викликає паніку у разі проблеми, а `mustRegexFind` поверне помилку у рушії шаблонів у разі проблеми. + +### regexReplaceAll, mustRegexReplaceAll + +Повертає копію вхідного рядка, замінюючи збіг регулярного виразу на рядок заміни `replacement`. У рядку заміни знаки `$` інтерпретуються як в Expand, тому, наприклад, `$1` представляє текст першого збігу. + +```yaml +regexReplaceAll "a(x*)b" "-ab-axxb-" "${1}W" +``` + +Поверне `-W-xxW-`. + +`regexReplaceAll` викликає паніку у разі проблеми, а `mustRegexReplaceAll` поверне помилку у рушії шаблонів у разі проблеми. + +### regexReplaceAllLiteral, mustRegexReplaceAllLiteral + +Повертає копію вхідного рядка, замінюючи збіг регулярного виразу на рядок заміни `replacement`. Рядок заміни підставляється без використання Expand. + +```yaml +regexReplaceAllLiteral "a(x*)b" "-ab-axxb-" "${1}" +``` + +Поверне `-${1}-${1}-`. + +`regexReplaceAllLiteral` викликає паніку у разі проблеми, а `mustRegexReplaceAllLiteral` поверне помилку у рушії шаблонів у разі проблеми. + +### regexSplit, mustRegexSplit + +Розбиває вхідний рядок на підрядки, розділені виразом, і повертає зріз підрядків між збігами цього виразу. Останній параметр `n` визначає кількість підрядків для повернення, де `-1` означає повернути всі збіги. + +```yaml +regexSplit "z+" "pizza" -1 +``` + +Поверне `[pi a]`. + +`regexSplit` викликає паніку у разі проблеми, а `mustRegexSplit` поверне помилку у рушії шаблонів у разі проблеми. + +## Функції криптографії та безпеки {#cryptographic-and-security-functions} + +Helm надає декілька розширених криптографічних функцій, серед яких: [adler32sum](#adler32sum), [buildCustomCert](#buildcustomcert), [decryptAES](#decryptaes), [derivePassword](#derivepassword), [encryptAES](#encryptaes), [genCA](#genca), [genPrivateKey](#genprivatekey), [genSelfSignedCert](#genselfsignedcert), [genSignedCert](#gensignedcert), [htpasswd](#htpasswd), [sha1sum](#sha1sum), та [sha256sum](#sha256sum). + +### sha1sum + +Функція `sha1sum` отримує рядок і обчислює його SHA1-дайджест. + +```yaml +sha1sum "Hello world!" +``` + +### sha256sum + +Функція `sha256sum` отримує рядок і обчислює його SHA256-дайджест. + +```yaml +sha256sum "Hello world!" +``` + +Це обчислює SHA 256 контрольну суму у форматі "ASCII armored", який є безпечним для друку. + +### adler32sum + +Функція `adler32sum` отримує рядок і обчислює його контрольну суму Adler-32. + +```yaml +adler32sum "Hello world!" +``` + +### htpasswd + +Функція `htpasswd` приймає `username` і `password` та генерує `bcrypt` хеш паролю. Результат може бути використаний для базової автентифікації на [Apache HTTP Server](https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#basic). + +```yaml +htpasswd "myUser" "myPassword" +``` + +Зверніть увагу, що небезпечно зберігати пароль безпосередньо в шаблоні. + +### derivePassword + +Функція `derivePassword` може бути використана для виведення певного пароля на основі деяких спільних "основних" обмежень пароля. Алгоритм для цього добре [описаний](https://web.archive.org/web/20211019121301/https://masterpassword.app/masterpassword-algorithm.pdf). + +```yaml +derivePassword 1 "long" "password" "user" "example.com" +``` + +Зверніть увагу, що небезпечно зберігати частини безпосередньо в шаблоні. + +### genPrivateKey + +Функція `genPrivateKey` генерує новий приватний ключ, закодований у PEM-блок. + +Вона приймає одне з наступних значень для свого першого параметра: + +* `ecdsa`: Генерує ключ еліптичної кривої DSA (P256) +* `dsa`: Генерує DSA ключ (L2048N256) +* `rsa`: Генерує RSA 4096 ключ + +### buildCustomCert + +Функція `buildCustomCert` дозволяє налаштувати сертифікат. + +Вона приймає наступні строкові параметри: + +* Сертифікат у форматі PEM, закодований у base64 +* Приватний ключ у форматі PEM, закодований у base64 + +Функція повертає обʼєкт сертифіката з наступними атрибутами: + +* `Cert`: Сертифікат у форматі PEM +* `Key`: Приватний ключ у форматі PEM + +Приклад: + +```yaml +$ca := buildCustomCert "base64-encoded-ca-crt" "base64-encoded-ca-key" +``` + +Зверніть увагу, що повернутий обʼєкт може бути переданий до функції `genSignedCert` для підписання сертифіката за допомогою цього CA. + +### genCA + +Функція `genCA` генерує новий самопідписний сертифікат x509 для центру сертифікацї. + +Вона приймає наступні параметри: + +* Загальне імʼя субʼєкта (cn) +* Термін дії сертифіката у днях + +Функція повертає обʼєкт з наступними атрибутами: + +* `Cert`: Сертифікат у форматі PEM +* `Key`: Приватний ключ у форматі PEM + +Приклад: + +```yaml +$ca := genCA "foo-ca" 365 +``` + +Зверніть увагу, що повернутий обʼєкт може бути переданий до функції `genSignedCert` для підписання сертифіката за допомогою цього CA. + +### genSelfSignedCert + +Функція `genSelfSignedCert` генерує новий самопідписаний сертифікат x509. + +Вона приймає наступні параметри: + +* Загальне імʼя субʼєкта (cn) +* Необовʼязковий список IP-адрес; може бути nil +* Необовʼязковий список альтернативних DNS-імен; може бути nil +* Термін дії сертифіката у днях + +Функція повертає обʼєкт з наступними атрибутами: + +* `Cert`: Сертифікат у форматі PEM +* `Key`: Приватний ключ у форматі PEM + +Приклад: + +```yaml +$cert := genSelfSignedCert "foo.com" (list "10.0.0.1" "10.0.0.2") (list "bar.com" "bat.com") 365 +``` + +### genSignedCert + +Функція `genSignedCert` генерує новий сертифікат x509, підписаний зазначеним CA. + +Вона приймає наступні параметри: + +* Спільне імʼя субʼєкта (cn) +* Необовʼязковий список IP-адрес; може бути nil +* Необовʼязковий список альтернативних DNS-імен; може бути nil +* Термін дії сертифіката у днях +* CA (див. `genCA`) + +Приклад: + +```yaml +$ca := genCA "foo-ca" 365 +$cert := genSignedCert "foo.com" (list "10.0.0.1" "10.0.0.2") (list "bar.com" "bat.com") 365 $ca +``` + +### encryptAES + +Функція `encryptAES` шифрує текст за допомогою AES-256 CBC і повертає рядок, закодований у base64. + +```yaml +encryptAES "secretkey" "plaintext" +``` + +### decryptAES + +Функція `decryptAES` отримує рядок у форматі base64, закодований за допомогою алгоритму AES-256 CBC, і повертає розкодований текст. + +```yaml +"30tEfhuJSVRhpG97XCuWgz2okj7L8vQ1s6V9zVUPeDQ=" | decryptAES "secretkey" +``` + +## Функції дати {#date-functions} + +Helm включає наступні функції дати, які ви можете використовувати в шаблонах: [ago](#ago), [date](#date), [dateInZone](#dateinzone), [dateModify (mustDateModify)](#datemodify-mustdatemodify), [duration](#duration), [durationRound](#durationround), [htmlDate](#htmldate), [htmlDateInZone](#htmldateinzone), [now](#now), [toDate (mustToDate)](#todate-musttodate) та [unixEpoch](#unixepoch). + +### now + +Поточна дата/час. Використовуйте це разом з іншими функціями дати. + +### ago + +Функція `ago` повертає тривалість від часу. Зараз у секундах. + +```none +ago .CreatedAt +``` + +повертає у форматі `time.Duration` String() + +```none +2h34m7s +``` + +### date + +Функція `date` форматує дату. + +Формат дати до РІК-МІСЯЦЬ-ДЕНЬ: + +```none +now | date "2006-01-02" +``` + +Форматування дати в Go [дещо відрізняється](https://pauladamsmith.com/blog/2011/05/go_time.html). + +Коротко, візьміть цю базову дату: + +```none +Mon Jan 2 15:04:05 MST 2006 +``` + +Запишіть її у потрібному форматі. Вище, `2006-01-02` — це та ж дата, але в потрібному форматі. + +### dateInZone + +Те ж саме, що і `date`, але з часовою зоною. + +```none +dateInZone "2006-01-02" (now) "UTC" +``` + +### duration + +Форматує задану кількість секунд як `time.Duration`. + +Це повертає 1m35s + +```none +duration "95" +``` + +### durationRound + +Округлює задану тривалість до найзначнішої одиниці. Рядки та `time.Duration` аналізуються як тривалість, тоді як `time.Time` обчислюється як тривалість з моменту. + +Це повертає 2h + +```none +durationRound "2h10m5s" +``` + +Це повертає 3mo + +```none +durationRound "2400h10m5s" +``` + +### unixEpoch + +Повертає кількість секунд з unix-епохи для `time.Time`. + +```none +now | unixEpoch +``` + +### dateModify, mustDateModify + +Функція `dateModify` приймає модифікацію та дату і повертає часову мітку. + +Відніміть годину і тридцять хвилин від поточного часу: + +```none +now | dateModify "-1.5h" +``` + +Якщо формат модифікації неправильний, `dateModify` поверне дату немодифікованою. `mustDateModify` поверне помилку в іншому випадку. + +### htmlDate + +Функція `htmlDate` форматує дату для вставки в поле введення дати в HTML. + +```none +now | htmlDate +``` + +### htmlDateInZone + +Те ж саме, що і htmlDate, але з часовою зоною. + +```none +htmlDateInZone (now) "UTC" +``` + +### toDate, mustToDate + +Функція `toDate` перетворює рядок у дату. Перший аргумент — це макет дати, а другий — рядок дати. Якщо рядок не можна перетворити, він поверне нульове значення. `mustToDate` поверне помилку в разі, якщо рядок не можна перетворити. + +Це корисно, коли ви хочете перетворити дату-рядок в інший формат (використовуючи конвеєр). Нижче наведений приклад перетворює "2017-12-31" на "31/12/2017". + +```none +toDate "2006-01-02" "2017-12-31" | date "02/01/2006" +``` + +## Словники та функції словників {#dictionaries-and-dict-functions} + +Helm надає тип зберігання ключ/значення, який називається `dict` (скорочено від "dictionary" ["словник"], як у Python). `dict` є _невпорядкованим_ типом. + +Ключ у словнику **має бути рядком**. Однак значення може бути будь-якого типу, навіть іншим `dict` або `list`. + +На відміну від `list`, `dict` не є незмінним. Функції `set` та `unset` змінюють вміст словника. + +Helm надає такі функції для роботи зі словниками: [deepCopy (mustDeepCopy)](#deepcopy-mustdeepcopy), [dict](#dict), [dig](#dig), [get](#get), [hasKey](#haskey), [keys](#keys), [merge (mustMerge)](#merge-mustmerge), [mergeOverwrite (mustMergeOverwrite)](#mergeoverwrite-mustmergeoverwrite), [omit](#omit), [pick](#pick), [pluck](#pluck), [set](#set), [unset](#unset) та [values](#values). + +### dict + +Створення словників здійснюється шляхом виклику функції `dict` і передачі їй списку пар. + +Наступний приклад створює словник з трьома елементами: + +```none +$myDict := dict "name1" "value1" "name2" "value2" "name3" "value 3" +``` + +### get + +За наявності map і ключа отримає значення з map. + +```none +get $myDict "name1" +``` + +Наведений вище приклад поверне `"value1"`. + +Зверніть увагу, що якщо ключ не знайдено, ця операція просто поверне `""`. Помилка не буде згенерована. + +### set + +Використовуйте `set`, щоб додати нову пару ключ/значення до словника. + +```none +$_ := set $myDict "name4" "value4" +``` + +Зверніть увагу, що `set` _повертає словник_ (вимога функцій шаблону Go), тому вам може знадобитися захопити значення, як це зроблено вище за допомогою присвоєння `$_`. + +### unset + +За наявності map і ключа видалить ключ з map. + +```none +$_ := unset $myDict "name4" +``` + +Як і у випадку з `set`, це повертає словник. + +Зверніть увагу, що якщо ключ не знайдено, ця операція просто повернеться. Помилка не буде згенерована. + +### hasKey + +Функція `hasKey` повертає `true`, якщо даний словник містить даний ключ. + +```none +hasKey $myDict "name1" +``` + +Якщо ключ не знайдено, це повертає `false`. + +### pluck + +Функція `pluck` дозволяє вказати один ключ і кілька map, і отримати список усіх знайдених збігів: + +```none +pluck "name1" $myDict $myOtherDict +``` + +Наведений вище приклад поверне `list`, що містить усі знайдені значення (`[value1 otherValue1]`). + +Якщо даний ключ _не знайдено_ в map, цей map не буде мати елемента у списку (і довжина повернутого списку буде меншою, ніж кількість словників у виклику `pluck`). + +Якщо ключ _знайдено_, але значення є порожнім, це значення буде вставлено. + +Поширеною ідіомою у шаблонах Helm є використання `pluck... | first`, щоб отримати перший відповідний ключ із колекції словників. + +### dig + +Функція `dig` проходить через вкладені набори словників, вибираючи ключі зі списку значень. Вона повертає стандартне значення, якщо будь-який з ключів не знайдено в асоційованому словнику. + +```none +dig "user" "role" "humanName" "guest" $dict +``` + +За наявності словника, структурованого таким чином: + +```none +{ + user: { + role: { + humanName: "curator" + } + } +} +``` + +наведений вище приклад поверне `"curator"`. Якщо у словнику навіть не було поля `user`, результатом буде `"guest"`. + +`dig` може бути дуже корисним у випадках, коли ви хочете уникнути охоронних конструкцій, особливо тому, що `and` у пакеті шаблонів Go не є скороченим. Наприклад, `and a.maybeNil a.maybeNil.iNeedThis` завжди буде оцінювати `a.maybeNil.iNeedThis` і викличе паніку, якщо у `a` відсутнє поле `maybeNil`. + +`dig` приймає свій аргумент словника останнім, щоб підтримувати конвеєрну обробку. Наприклад: + +```none +merge a b c | dig "one" "two" "three" "" +``` + +### merge, mustMerge + +Обʼєднує два або більше словників в один, надаючи перевагу словнику призначення: + +Наприклад: + +```yaml +dst: + default: default + overwrite: me + key: true + +src: + overwrite: overwritten + key: false +``` + +результатом буде: + +```yaml +newdict: + default: default + overwrite: me + key: true +``` + +```none +$newdict := merge $dest $source1 $source2 +``` + +Це операція глибокого обʼєднання, але не глибокого копіювання. Вкладені обʼєкти, що обʼєднуються, є однією і тією ж сутністю в обох словниках. Якщо ви хочете глибоке копіювання разом з обʼєднанням, то використовуйте функцію `deepCopy` разом з обʼєднанням. Наприклад, + +```none +deepCopy $source | merge $dest +``` + +`mustMerge` поверне помилку в разі невдалого обʼєднання. + +### mergeOverwrite, mustMergeOverwrite {#mergeoverwrite-mustmergeoverwrite} + +Обʼєднує два або більше словників в один, надаючи перевагу з **права наліво**, ефективно перезаписуючи значення в словнику призначення: + +Наприклад: + +```yaml +dst: + default: default + overwrite: me + key: true + +src: + overwrite: overwritten + key: false +``` + +результатом буде: + +```yaml +newdict: + default: default + overwrite: overwritten + key: false +``` + +```none +$newdict := mergeOverwrite $dest $source1 $source2 +``` + +Це операція глибокого обʼєднання, але не глибокого копіювання. Вкладені обʼєкти, що обʼєднуються, є однією і тією ж сутністю в обох словниках. Якщо ви хочете глибоке копіювання разом з обʼєднанням, то використовуйте функцію `deepCopy` разом з обʼєднанням. Наприклад, + +```none +deepCopy $source | mergeOverwrite $dest +``` + +`mustMergeOverwrite` поверне помилку в разі невдалого обʼєднання. + +### keys + +Функція `keys` повертає `list` усіх ключів одного або декількох типів `dict`. Оскільки словник є _невпорядкованим_, ключі не будуть у передбачуваному порядку. Їх можна відсортувати за допомогою `sortAlpha`. + +```none +keys $myDict | sortAlpha +``` + +При поданні кількох словників ключі будуть обʼєднані. Використовуйте функцію `uniq` разом із `sortAlpha`, щоб отримати унікальний, відсортований список ключів. + +```none +keys $myDict $myOtherDict | uniq | sortAlpha +``` + +### pick + +Функція `pick` вибирає тільки зазначені ключі зі словника, створюючи новий `dict`. + +```none +$new := pick $myDict "name1" "name2" +``` + +Наведений вище приклад поверне `{name1: value1, name2: value2}`. + +### omit + +Функція `omit` схожа на `pick`, за винятком того, що вона повертає новий `dict` з усіма ключами, які _не_ збігаються з даними ключами. + +```none +$new := omit $myDict "name1" "name3" +``` + +Наведений вище приклад поверне `{name2: value2}`. + +### values + +Функція `values` схожа на `keys`, за винятком того, що вона повертає новий `list` з усіма значеннями вихідного `dict` (підтримується тільки один словник). + +```none +$vals := values $myDict +``` + +Наведений вище приклад поверне `list["value1", "value2", "value 3"]`. Зверніть увагу, що функція `values` не дає жодних гарантій щодо порядку результатів; якщо це важливо, використовуйте `sortAlpha`. + +### deepCopy, mustDeepCopy + +Функції `deepCopy` і `mustDeepCopy` приймають значення і роблять глибоку копію цього значення. Це включає словники та інші структури. `deepCopy` викликає паніку, коли виникає проблема, тоді як `mustDeepCopy` повертає помилку системі шаблонів, коли виникає помилка. + +```none +dict "a" 1 "b" 2 | deepCopy +``` + +### Примітка про внутрішню структуру Dict {#a-note-on-dict-internals} + +`dict` реалізовано в Go як `map[string]interface{}`. Розробники Go можуть передавати значення `map[string]interface{}` у контекст, щоб зробити їх доступними для шаблонів як `dict`. + +## Функції кодування {#encoding-functions} + +Helm має такі функції для кодування та декодування: + +* `b64enc`/`b64dec`: Кодування або декодування з використанням Base64 +* `b32enc`/`b32dec`: Кодування або декодування з використанням Base32 + +## Списки та функції для роботи зі списками {#lists-and-list-functions} + +Helm надає простий тип `list`, який може містити довільні послідовні дані. Це схоже на масиви або зрізи, але списки призначені для використання як незмінні типи даних. + +Створення списку цілих чисел: + +```none +$myList := list 1 2 3 4 5 +``` + +Це створить список `[1 2 3 4 5]`. + +Helm надає наступні функції для роботи зі списками: [append (mustAppend)](#append-mustappend), [compact (mustCompact)](#compact-mustcompact), [concat](#concat), [first (mustFirst)](#first-mustfirst), [has (mustHas)](#has-musthas), [initial (mustInitial)](#initial-mustinitial), [last (mustLast)](#last-mustlast), [prepend (mustPrepend)](#prepend-mustprepend), [rest (mustRest)](#rest-mustrest), [reverse (mustReverse)](#reverse-mustreverse), [seq](#seq), [index](#index), [slice (mustSlice)](#slice-mustslice), [uniq (mustUniq)](#uniq-mustuniq), [until](#until), [untilStep](#untilstep) та [without (mustWithout)](#without-mustwithout). + +### first, mustFirst + +Щоб отримати перший елемент списку, використовуйте `first`. + +`first $myList` повертає `1`. + +`first` викликає panic у разі проблеми, тоді як `mustFirst` повертає помилку в рушій шаблонів, якщо виникає проблема. + +### rest, mustRest + +Щоб отримати залишок списку (все, окрім першого елемента), використовуйте `rest`. + +`rest $myList` повертає `[2 3 4 5]`. + +`rest` викликає panic у разі проблеми, тоді як `mustRest` повертає помилку в рушій шаблонів, якщо виникає проблема. + +### last, mustLast + +Щоб отримати останній елемент списку, використовуйте `last`: + +`last $myList` повертає `5`. Це аналогічно до реверсування списку та виклику `first`. + +### initial, mustInitial + +Ця функція доповнює `last`, повертаючи всі елементи, окрім останнього. `initial $myList` повертає `[1 2 3 4]`. + +`initial` викликає panic у разі проблеми, тоді як `mustInitial` повертає помилку в рушій шаблонів, якщо виникає проблема. + +### append, mustAppend + +Додає новий елемент до існуючого списку, створюючи новий список. + +```none +$new = append $myList 6 +``` + +Це встановлює `$new` до `[1 2 3 4 5 6]`. `$myList` залишається незмінним. + +`append` викликає panic у разі проблеми, тоді як `mustAppend` повертає помилку в рушій шаблонів, якщо виникає проблема. + +### prepend, mustPrepend + +Додає елемент на початок списку, створюючи новий список. + +```none +prepend $myList 0 +``` + +Це створить `[0 1 2 3 4 5]`. `$myList` залишається незмінним. + +`prepend` викликає panic у разі проблеми, тоді як `mustPrepend` повертає помилку в рушій шаблонів, якщо виникає проблема. + +### concat + +Обʼєднує довільну кількість списків в один. + +```none +concat $myList (list 6 7) (list 8) +``` + +Це створить `[1 2 3 4 5 6 7 8]`. `$myList` залишається незмінним. + +### reverse, mustReverse + +Створює новий список з елементами у зворотному порядку. + +```none +reverse $myList +``` + +Це генерує список `[5 4 3 2 1]`. + +`reverse` викликає panic у разі проблеми, тоді як `mustReverse` повертає помилку в рушій шаблонів, якщо виникає проблема. + +### uniq, mustUniq + +Створює список без дублікатів. + +```none +list 1 1 1 2 | uniq +``` + +Це створить `[1 2]`. + +`uniq` викликає panic у разі проблеми, тоді як `mustUniq` повертає помилку в рушій шаблонів, якщо виникає проблема. + +### without, mustWithout + +Функція `without` видаляє елементи зі списку. + +```none +without $myList 3 +``` + +Це створить `[1 2 4 5]`. + +`without` може приймати більше одного фільтра: + +```none +without $myList 1 3 5 +``` + +Це створить `[2 4]`. + +`without` викликає panic у разі проблеми, тоді як `mustWithout` повертає помилку в рушій шаблонів, якщо виникає проблема. + +### has, mustHas + +Перевіряє, чи містить список певний елемент. + +```none +has 4 $myList +``` + +Це поверне `true`, а `has "hello" $myList` поверне `false`. + +`has` викликає panic у разі проблеми, тоді як `mustHas` повертає помилку в рушій шаблонів, якщо виникає проблема. + +### compact, mustCompact + +Приймає список та видаляє елементи з пустими значеннями. + +```none +$list := list 1 "a" "foo" "" +$copy := compact $list +``` + +`compact` поверне новий список з видаленим пустим (тобто "") елементом. + +`compact` викликає panic у разі проблеми, тоді як `mustCompact` повертає помилку в рушій шаблонів, якщо виникає проблема. + +### index + +Щоб отримати n-й елемент списку, використовуйте `index list [n]`. Щоб отримати +елемент у багатовимірних списках, використовуйте `index list [n] [m] ...`. + +* `index $myList 0` повертає `1`. Це те саме, що і `myList[0]`. +* `index $myList 0 1` повертає той самий результат, що і `myList[0][1]`. + +### slice, mustSlice + +Щоб отримати часткові елементи списку, використовуйте `slice list [n] [m]`. Це еквівалентно до `list[n:m]`. + +* `slice $myList` повертає `[1 2 3 4 5]`. Це те саме, що і `myList[:]`. +* `slice $myList 3` повертає `[4 5]`. Це те саме, що і `myList[3:]`. +* `slice $myList 1 3` повертає `[2 3]`. Це те саме, що і `myList[1:3]`. +* `slice $myList 0 3` повертає `[1 2 3]`. Це те саме, що і `myList[:3]`. + +`slice` викликає panic у разі проблеми, тоді як `mustSlice` повертає помилку в рушій шаблонів, якщо виникає проблема. + +### until + +Функція `until` створює діапазон цілих чисел. + +```none +until 5 +``` + +Це генерує список `[0, 1, 2, 3, 4]`. + +Це корисно для циклів з `range $i, $e := until 5`. + +### untilStep + +Як і `until`, функція `untilStep` створює список рахуючих цілих чисел. Але вона дозволяє визначити початок, кінець та крок: + +```none +untilStep 3 6 2 +``` + +Це створить `[3 5]`, починаючи з 3 та додаючи 2, поки не буде досягнуто або перевищено 6. Це схоже на функцію `range` в Python. + +### seq + +Працює як команда `seq` у bash. + +* 1 параметр (end) — генерує всі рахуючі цілі числа між 1 та `end` включно. +* 2 параметри (start, end) — генерує всі рахуючі цілі числа між `start` та `end` включно, збільшуючи або зменшуючи на 1. +* 3 параметри (start, step, end) — генерує всі рахуючі цілі числа між `start` та `end` включно, збільшуючи або зменшуючи на `step`. + +```none +seq 5 => 1 2 3 4 5 +seq -3 => 1 0 -1 -2 -3 +seq 0 2 => 0 1 2 +seq 2 -2 => 2 1 0 -1 -2 +seq 0 2 10 => 0 2 4 6 8 10 +seq 0 -2 -5 => 0 -2 -4 +``` + +## Математичні функції {#math-functions} + +Усі математичні функції працюють із значеннями типу `int64`, якщо не зазначено інше. + +Доступні наступні математичні функції: [add](#add), [add1](#add1), [ceil](#ceil), [div](#div), [floor](#floor), [len](#len), [max](#max), [min](#min), [mod](#mod), [mul](#mul), [round](#round) та [sub](#sub). + +### add + +Додавайте числа за допомогою `add`. Приймає два або більше аргументів. + +```none +add 1 2 3 +``` + +### add1 + +Щоб збільшити на 1, використовуйте `add1`. + +### sub + +Щоб відняти, використовуйте `sub`. + +### div + +Виконуйте цілочисельне ділення за допомогою `div`. + +### mod + +Залишок від ділення можна отримати за допомогою `mod`. + +### mul + +Множте за допомогою `mul`. Приймає два або більше аргументів. + +```none +mul 1 2 3 +``` + +### max + +Повертає найбільше із серії цілих чисел. + +Це поверне `3`: + +```none +max 1 2 3 +``` + +### min + +Повертає найменше із серії цілих чисел. + +`min 1 2 3` поверне `1`. + +### len + +Повертає довжину аргументу у вигляді цілого числа. + +```none +len .Arg +``` + +## Математичні функції з плаваючою комою {#float-math-functions} + +Усі математичні функції працюють із значеннями типу `float64`. + +### addf + +Додавайте числа за допомогою `addf`. + +Це поверне `5.5`: + +```none +addf 1.5 2 2 +``` + +### add1f + +Щоб збільшити на 1, використовуйте `add1f`. + +### subf + +Щоб відняти, використовуйте `subf`. + +Це еквівалентно `7.5 - 2 - 3` і поверне `2.5`: + +```none +subf 7.5 2 3 +``` + +### divf + +Виконуйте ділення з плаваючою комою за допомогою `divf`. + +Це еквівалентно `10 / 2 / 4` і поверне `1.25`: + +```none +divf 10 2 4 +``` + +### mulf + +Множте за допомогою `mulf`. + +Це поверне `6`: + +```none +mulf 1.5 2 2 +``` + +### maxf + +Повертає найбільше із серії чисел з плаваючою комою: + +Це поверне `3`: + +```none +maxf 1 2.5 3 +``` + +### minf + +Повертає найменше із серії чисел з плаваючою комою. + +Це поверне `1.5`: + +```none +minf 1.5 2 3 +``` + +### floor + +Повертає найбільше число з плаваючою комою, яке менше або рівне вхідному значенню. + +`floor 123.9999` поверне `123.0`. + +### ceil + +Повертає найбільше число з плаваючою комою, яке більше або рівне вхідному значенню. + +`ceil 123.001` поверне `124.0`. + +### round + +Повертає число з плаваючою комою з округленим залишком до зазначеної кількості цифр +після десяткової крапки. + +`round 123.555555 3` поверне `123.556`. + +## Мережеві функції {#network-functions} + +Helm має одну мережеву функцію, `getHostByName`. + +Функція `getHostByName` приймає доменне імʼя і повертає IP-адресу. + +`getHostByName "www.google.com"` поверне відповідну IP-адресу для `www.google.com`. + +## Функції роботи з шляхами до файлів {#file-path-functions} + +Хоча функції шаблонів Helm не надають доступ до файлової системи, вони забезпечують функції для роботи з рядками, які відповідають конвенціям шляхів до файлів. До них відносяться [base](#base), [clean](#clean), [dir](#dir), [ext](#ext) та [isAbs](#isabs). + +### base + +Повертає останній елемент шляху. + +```none +base "foo/bar/baz" +``` + +Вищезазначене поверне "baz". + +### dir + +Повертає теку, видаляючи останню частину шляху. Отже, `dir "foo/bar/baz"` повертає `foo/bar`. + +### clean + +Очищує шлях. + +```none +clean "foo/bar/../baz" +``` + +Вищезазначене знаходить `..` і повертає `foo/baz`. + +### ext + +Повертає розширення файлу. + +```none +ext "foo.bar" +``` + +Вищезазначене поверне `.bar`. + +### isAbs + +Щоб перевірити, чи є шлях до файлу абсолютним, використовуйте `isAbs`. + +## Функції аналізу {#reflection-functions} + +Helm надає базові інструменти аналізу. Це допомагає розробникам шаблонів зрозуміти основну інформацію про типи Go для конкретного значення. Helm написано на Go і він має строгий типізований підхід. Система типів застосовується всередині шаблонів. + +Go має кілька примітивів _видів (kind)_, таких як `string`, `slice`, `int64` і `bool`. + +Go має відкриту систему _типів_, яка дозволяє розробникам створювати власні типи. + +Helm надає набір функцій для кожного з них через [функції kind](#kind-functions) і [функції type](#type-functions). Також надана функція [deepEqual](#deepequal) для порівняння значень. + +### Функції kind {#kind-functions} + +Є дві функції видів: `kindOf` повертає вид обʼєкта. + +```none +kindOf "hello" +``` + +Вищезазначене поверне `string`. Для простих тестів (наприклад, у блоці `if`), функція `kindIs` дозволяє перевірити, що значення має певний вид: + +```none +kindIs "int" 123 +``` + +Вищезазначене поверне `true`. + +### Функції type {#type-functions} + +Типи трохи складніше обробляти, тому є три різні функції: + +* `typeOf` повертає основний тип значення: `typeOf $foo` +* `typeIs` подібна до `kindIs`, але для типів: `typeIs "*io.Buffer" $myVal` +* `typeIsLike` працює як `typeIs`, але також розіменовує покажчики + +**Примітка:** Жодна з цих функцій не може перевірити, чи реалізує щось певний інтерфейс, оскільки це вимагало б компіляції інтерфейсу заздалегідь. + +### deepEqual + +`deepEqual` повертає `true`, якщо два значення є ["глибоко рівними"](https://golang.org/pkg/reflect/#DeepEqual). + +Працює і для типів непримітивів (в порівнянні з вбудованим `eq`). + +```none +deepEqual (list 1 2 3) (list 1 2 3) +``` + +Вищезазначене поверне `true`. + +## Функції семантичного версіонування {#semantic-version-functions} + +Деякі схеми версій легко розпізнати та порівнювати. Helm надає функції для роботи з версіями [SemVer 2](http://semver.org). До них відносяться [semver](#semver) і [semverCompare](#semvercompare). Нижче ви також знайдете деталі про використання діапазонів для порівнянь. + +### semver + +Функція `semver` розбирає рядок у семантичну версію: + +```none +$version := semver "1.2.3-alpha.1+123" +``` + +_Якщо синтаксичний аналізатор не спрацює, виконання шаблону буде зупинено з помилкою._ + +На цьому етапі `$version` є покажчиком на обʼєкт `Version` з наступними властивостями: + +* `$version.Major`: Основний номер (`1` вище) +* `$version.Minor`: Мінорний номер (`2` вище) +* `$version.Patch`: Номер патчу (`3` вище) +* `$version.Prerelease`: Пре-реліз (`alpha.1` вище) +* `$version.Metadata`: Метадані збірки (`123` вище) +* `$version.Original`: Оригінальна версія у вигляді рядка + +Крім того, ви можете порівнювати `Version` з іншою версією, використовуючи функцію `Compare`: + +```none +semver "1.4.3" | (semver "1.2.3").Compare +``` + +Вищезазначене поверне `-1`. + +Значення повернення такі: + +* `-1`, якщо дана версія SemVer більша за версію, метод `Compare` якої був викликаний +* `1`, якщо версія, для якої була викликана функція `Compare`, більша +* `0`, якщо версії однакові + +(Зверніть увагу, що в SemVer поле `Metadata` не порівнюється під час операцій порівняння версій.) + +### semverCompare + +Більш надійна функція порівняння надається як `semverCompare`. Ця версія підтримує діапазони версій: + +* `semverCompare "1.2.3" "1.2.3"` перевіряє на точний збіг +* `semverCompare "~1.2.0" "1.2.3"` перевіряє, що основні та мінорні версії збігаються, і що номер патчу другої версії _більший або рівний_ першому параметру. + +Функції SemVer використовують бібліотеку [Masterminds semver](https://github.com/Masterminds/semver), від творців Sprig. + +### Основні порівняння {#basic-comparisons} + +Є два елементи порівнянь. По-перше, рядок порівняння є списком порівнянь з AND, розділених пробілом або комою. Ці порівняння потім розділяються операцією || (OR). Наприклад, `">= 1.2 < 3.0.0 || >= 4.2.3"` шукає порівняння, яке більше або дорівнює 1.2 і менше 3.0.0 або більше або дорівнює 4.2.3. + +Основні порівняння: + +* `=`: рівно (аналогічно відсутності оператора) +* `!=`: не рівно +* `>`: більше ніж +* `<`: менше ніж +* `>=`: більше або рівно +* `<=`: менше або рівно + +### Робота з версіями пре-релізів {#working-with-prerelease-versions} + +Пре-релізи, для тих, хто не знайомий з ними, використовуються для випусків програмного забезпечення до стабільних або загальнодоступних випусків. Прикладами пре-релізів є розробка, альфа, бета та реліз-кандидат. Пре-реліз може бути версією, наприклад, `1.2.3-beta.1`, в той час як стабільний реліз буде `1.2.3`. За порядком пріоритету пре-релізи йдуть перед їх повʼязаними релізами. У цьому прикладі `1.2.3-beta.1 < 1.2.3`. + +Згідно з специфікацією Semantic Version, пре-релізи можуть не відповідати API сумісності зі своїм релізом. Вона говорить, + +> Версія пре-релізу вказує, що версія нестабільна і може не відповідати запланованим вимогам сумісності, як зазначено у відповідній нормальній версії. + +Порівняння SemVer з використанням обмежень без компаратора пре-релізу пропустять пре-релізи. Наприклад, `>=1.2.3` пропустить пре-релізи при перегляді списку релізів, тоді як `>=1.2.3-0` буде оцінювати і знаходити пре-релізи. + +Причина для `0` як версії пре-релізу у прикладі порівняння полягає в тому, що пре-релізи можуть містити лише ASCII числа, літери та дефіси (разом з роздільниками `.`), згідно з специфікацією. Сортування відбувається в ASCII порядку сортування, згідно з специфікацією. Найнижчий символ — це `0` в ASCII порядку сортування (див. [ASCII Таблицю](http://www.asciitable.com/)). + +Розуміння ASCII порядку сортування важливе, оскільки A-Z йде перед a-z. Це означає, що `>=1.2.3-BETA` поверне `1.2.3-alpha`. Те, що ви могли б очікувати від чутливості до регістру, тут не застосовується. Це через ASCII порядок сортування, який зазначено у специфікації. + +### Порівняння діапазонів з дефісами {#hyphen-range-comparisons} + +Є кілька методів обробки діапазонів, і перший — діапазони з дефісами. Вони виглядають так: + +* `1.2 - 1.4.5`, що еквівалентно `>= 1.2 <= 1.4.5` +* `2.3.4 - 4.5`, що еквівалентно `>= 2.3.4 <= 4.5` + +### Підстановочні символи в порівняннях {#wildcard-in-comparisons} + +Символи `x`, `X` та `*` можуть використовуватися як символи заміщення. Це працює для всіх операторів порівняння. Коли використовується з оператором `=`, він переходить до порівняння рівня патчу (див. тильду нижче). Наприклад, + +* `1.2.x` еквівалентно `>= 1.2.0, < 1.3.0` +* `>= 1.2.x` еквівалентно `>= 1.2.0` +* `<= 2.x` еквівалентно `< 3` +* `*` еквівалентно `>= 0.0.0` + +### Порівняння діапазонів з тильдою (patch) {#tilde-range-comparisons-patch} + +Оператор порівняння тильди (`~`) використовується для діапазонів рівня патчу, коли вказана мінорна версія, і для змін на рівні основної версії, коли мінорний номер відсутній. Наприклад, + +* `~1.2.3` еквівалентно `>= 1.2.3, < 1.3.0` +* `~1` еквівалентно `>= 1, < 2` +* `~2.3` еквівалентно `>= 2.3, < 2.4` +* `~1.2.x` еквівалентно `>= 1.2.0, < 1.3.0` +* `~1.x` еквівалентно `>= 1, < 2` + +### Порівняння діапазонів з кареткою (major) {#caret-range-comparisons-major} + +Оператор порівняння каретки (`^`) використовується для змін на рівні основної версії після випуску стабільної (1.0.0) версії. До випуску 1.0.0 мінорні версії діють як рівень стабільності API. Це корисно при порівнянні версій API, оскільки велика зміна є порушенням API. Наприклад, + +* `^1.2.3` еквівалентно `>= 1.2.3, < 2.0.0` +* `^1.2.x` еквівалентно `>= 1.2.0, < 2.0.0` +* `^2.3` еквівалентно `>= 2.3, < 3` +* `^2.x` еквівалентно `>= 2.0.0, < 3` +* `^0.2.3` еквівалентно `>=0.2.3 <0.3.0` +* `^0.2` еквівалентно `>=0.2.0 <0.3.0` +* `^0.0.3` еквівалентно `>=0.0.3 <0.0.4` +* `^0.0` еквівалентно `>=0.0.0 <0.1.0` +* `^0` еквівалентно `>=0.0.0 <1.0.0` + +## Функції URL {#url-functions} + +Helm включає функції [urlParse](#urlparse), [urlJoin](#urljoin) і [urlquery](#urlquery), які дозволяють працювати з частинами URL. + +### urlParse + +Розбирає рядок для URL і створює словник з частинами URL + +```none +urlParse "http://admin:secret@server.com:8080/api?list=false#anchor" +``` + +Вищезазначене повертає словник, що містить обʼєкт URL: + +```yaml +scheme: 'http' +host: 'server.com:8080' +path: '/api' +query: 'list=false' +opaque: nil +fragment: 'anchor' +userinfo: 'admin:secret' +``` + +Це реалізовано за допомогою пакетів URL з стандартної бібліотеки Go. Для отримання додаткової інформації перевірте https://golang.org/pkg/net/url/#URL + +### urlJoin + +Обʼєднує словник (створений за допомогою `urlParse`) для створення рядка URL + +```none +urlJoin (dict "fragment" "fragment" "host" "host:80" "path" "/path" "query" "query" "scheme" "http") +``` + +Вищезазначене поверне наступний рядок: + +```none +http://host:80/path?query#fragment +``` + +### urlquery + +Повертає екрановану версію значення, переданого як аргумент, так що воно підходить для вбудовування в частину запиту URL. + +```none +$var := urlquery "string for query" +``` + +## Функції UUID {#uuid-functions} + +Helm може генерувати UUID v4, унікальні ідентифікатори. + +```none +uuidv4 +``` + +Вищезазначене повертає новий UUID типу v4 (згенерований випадковим чином). + +## Функції Kubernetes і Chart {#kubernetes-and-chart-functions} + +Helm включає функції для роботи з Kubernetes, зокрема [`.Capabilities.APIVersions.Has`](#capabilitiesapiversionshas), [Files](#file-functions) та [lookup](#lookup). + +### lookup + +`lookup` використовується для пошуку ресурсу в працюючому кластері. При використанні з командою `helm template` він завжди повертає порожній результат. + +Більше деталей можна знайти в [документації по функції lookup](functions_and_pipelines.md/#using-the-lookup-function). + +### .Capabilities.APIVersions.Has + +Повертає, чи доступна API-версія або ресурс у кластері. + +```none +.Capabilities.APIVersions.Has "apps/v1" +.Capabilities.APIVersions.Has "apps/v1/Deployment" +``` + +Більше інформації доступно в [документації по вбудованих обʼєктах](builtin_objects.md). + +### Функції файлів {#file-functions} + +Є кілька функцій, які дозволяють отримати доступ до не-спеціальних файлів всередині chart. Наприклад, для доступу до конфігураційних файлів програми. Ці функції документовані в [Доступ до файлів всередині шаблонів](accessing_files.md). + +_Зверніть увагу, що документація для багатьох з цих функцій надходить з [Sprig](https://github.com/Masterminds/sprig). Sprig — це бібліотека функцій шаблонів, доступна для застосунків на Go._ diff --git a/content/uk/docs/chart_template_guide/functions_and_pipelines.md b/content/uk/docs/chart_template_guide/functions_and_pipelines.md new file mode 100644 index 000000000..bbf93ad6e --- /dev/null +++ b/content/uk/docs/chart_template_guide/functions_and_pipelines.md @@ -0,0 +1,206 @@ +--- +title: "Функції шаблонів та конвеєри" +description: "Використання функцій у шаблонах." +weight: 5 +--- + +Дотепер ми бачили, як розміщувати інформацію в шаблоні. Але ця інформація розміщується в шаблоні без змін. Іноді ми хочемо перетворити надані дані таким чином, щоб вони були більш корисними для нас. + +Почнемо з найкращої практики: коли вставляємо рядки з об’єкта `.Values` у шаблон, ми повинні обов’язково обгорнути ці рядки в лапки. Ми можемо зробити це, викликавши функцію `quote` в директиві шаблону: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + drink: {{ quote .Values.favorite.drink }} + food: {{ quote .Values.favorite.food }} +``` + +Функції шаблонів дотримуються синтаксису `functionName arg1 arg2...`. У наведеному вище фрагменті `quote .Values.favorite.drink` викликає функцію `quote` і передає їй один аргумент. + +Helm має понад 60 доступних функцій. Деякі з них визначені [мовою шаблонів Go](https://godoc.org/text/template). Більшість інших є частиною [бібліотеки шаблонів Sprig](https://masterminds.github.io/sprig/). Ми побачимо багато з них у міру того, як будемо розглядати приклади. + +> Хоча ми говоримо про "мову шаблонів Helm", як про щось специфічне для Helm, насправді це комбінація мови шаблонів Go, деяких додаткових функцій і різноманітних обгорток, які дозволяють передавати певні обʼєкти в шаблони. Багато ресурсів про шаблони Go можуть бути корисними, коли ви вивчаєте шаблони. + +## Конвеєри {#pipelines} + +Однією з потужних функцій мови шаблонів є концепція _конвеєрів_. Запозичивши концепцію з UNIX, конвеєри є інструментом для обʼєднання серії команд шаблонів для компактного вираження низки перетворень. Іншими словами, конвеєри — це ефективний спосіб виконання кількох завдань послідовно. Перепишемо наведений вище приклад, використовуючи конвеєр. + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + drink: {{ .Values.favorite.drink | quote }} + food: {{ .Values.favorite.food | quote }} +``` + +У цьому прикладі замість виклику `quote ARGUMENT` ми інвертували порядок. Ми "надіслали" аргумент функції за допомогою конвеєра (`|`): `.Values.favorite.drink | quote`. Використовуючи конвеєри, ми можемо обʼєднати кілька функцій: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + drink: {{ .Values.favorite.drink | quote }} + food: {{ .Values.favorite.food | upper | quote }} +``` + +> Інверсія порядку є поширеною практикою в шаблонах. Ви частіше побачите `.val | quote`, ніж `quote .val`. Обидві практики є правильними. + +Під час обробки цей шаблон створить такий результат: + +```yaml + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: trendsetting-p-configmap +data: + myvalue: "Hello World" + drink: "coffee" + food: "PIZZA" +``` + +Зверніть увагу, що наша початкова `pizza` тепер перетворилася на `"PIZZA"`. + +Коли аргументи передаються за допомогою конвеєра, результат першого обчислення (`.Values.favorite.drink`) надсилається як _останній аргумент функції_. Ми можемо змінити приклад із напоєм вище, щоб продемонструвати функцію, яка приймає два аргументи: `repeat COUNT STRING`: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + drink: {{ .Values.favorite.drink | repeat 5 | quote }} + food: {{ .Values.favorite.food | upper | quote }} +``` + +Функція `repeat` буде повторювати даний рядок задану кількість разів, тому ми отримаємо такий вихідний результат: + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: melting-porcup-configmap +data: + myvalue: "Hello World" + drink: "coffeecoffeecoffeecoffeecoffee" + food: "PIZZA" +``` + +## Використання функції `default` {#using-the-default-function} + +Однією з функцій, яку часто використовують у шаблонах, є функція `default`: `default DEFAULT_VALUE GIVEN_VALUE`. Ця функція дозволяє вам вказати стандартне значення в шаблоні, у разі якщо значення відсутнє. Використаємо її, щоб змінити приклад з напоєм вище: + +```yaml +drink: {{ .Values.favorite.drink | default "tea" | quote }} +``` + +Якщо ми запустимо це як зазвичай, ми отримаємо наш `coffee`: + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: virtuous-mink-configmap +data: + myvalue: "Hello World" + drink: "coffee" + food: "PIZZA" +``` + +Тепер ми видалимо параметр улюбленого напою з `values.yaml`: + +```yaml +favorite: + #drink: coffee + food: pizza +``` + +Тепер повторний запуск `helm install --dry-run --debug fair-worm ./mychart` створить такий YAML: + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: fair-worm-configmap +data: + myvalue: "Hello World" + drink: "tea" + food: "PIZZA" +``` + +В реальній схемі всі статичні стандартні значення повинні зберігатися у файлі `values.yaml` і не повинні дублюватися за допомогою команди `default` (інакше вони будуть надлишковими). Однак команда `default` ідеально підходить для обчислюваних значень, які не можуть бути оголошені у файлі `values.yaml`. Наприклад: + +```yaml +drink: {{ .Values.favorite.drink | default (printf "%s-tea" (include "fullname" .)) }} +``` + +У деяких випадках умова `if` може бути кращим рішенням, ніж `default`. Ми побачимо їх у наступному розділі. + +Функції та конвеєри шаблонів — це потужний спосіб перетворення інформації та її вставки у ваш YAML. Але іноді необхідно додати деяку логіку шаблонів, яка трохи складніша, ніж просто вставка рядка. У наступному розділі ми розглянемо структури керування, які надає мова шаблонів. + +## Використання функції `lookup` {#using-the-lookup-function} + +Функцію `lookup` можна використовувати для _пошуку_ ресурсів у працюючому кластері. Синопсис функції lookup — це `lookup apiVersion, kind, namespace, name -> resource or resource list`. + +| параметр | тип | +|------------|--------| +| apiVersion | string | +| kind | string | +| namespace | string | +| name | string | + +Обидва параметри `name` та `namespace` є необов’язковими та можуть передаватися як порожній рядок (`""`). + +Можливі такі комбінації параметрів: + +| Поведінка | Функція пошуку | +|----------------------------------------|--------------------------------------------| +| `kubectl get pod mypod -n mynamespace` | `lookup "v1" "Pod" "mynamespace" "mypod"` | +| `kubectl get pods -n mynamespace` | `lookup "v1" "Pod" "mynamespace" ""` | +| `kubectl get pods --all-namespaces` | `lookup "v1" "Pod" "" ""` | +| `kubectl get namespace mynamespace` | `lookup "v1" "Namespace" "" "mynamespace"` | +| `kubectl get namespaces` | `lookup "v1" "Namespace" "" ""` | + +Коли `lookup` повертає обʼєкт, він поверне словник. Цей словник може бути додатково досліджений для отримання конкретних значень. + +Наступний приклад поверне анотації, присутні для обʼєкта `mynamespace`: + +```go +(lookup "v1" "Namespace" "" "mynamespace").metadata.annotations +``` + +Коли `lookup` повертає список обʼєктів, можливо отримати доступ до списку обʼєктів через поле `items`: + +```go +{{ range $index, $service := (lookup "v1" "Service" "mynamespace" "").items }} + {{/* робимо щось з кожним сервісом */}} +{{ end }} +``` + +Коли обʼєкт не знайдено, повертається порожнє значення. Це може бути використано для перевірки наявності обʼєкта. + +Функція `lookup` використовує поточну конфігурацію зʼєднання Kubernetes Helm для запиту до Kubernetes. Якщо при взаємодії з викликом сервера API виникає помилка (наприклад, через відсутність дозволу на доступ до ресурсу), обробка шаблонів Helm зазнає невдачі. + +Майте на увазі, що Helm не призначений для контакту з Kubernetes API Server під час операцій `helm template|install|upgrade|delete|rollback --dry-run`. Щоб протестувати `lookup` на працюючому кластера, слід використовувати `helm template|install|upgrade|delete|rollback --dry-run=server`, щоб дозволити з’єднання з кластером. + +## Оператори як функції {#operators-are-functions} + +Для шаблонів оператори (`eq`, `ne`, `lt`, `gt`, `and`, `or` і так далі) реалізовані як функції. У конвеєрах операції можуть бути згруповані дужками (`(` і `)`). + +Тепер ми можемо перейти від функцій і конвеєрів до управління потоком з умовами, циклами та модифікаторами області видимості. diff --git a/content/uk/docs/chart_template_guide/getting_started.md b/content/uk/docs/chart_template_guide/getting_started.md new file mode 100644 index 000000000..e08abd311 --- /dev/null +++ b/content/uk/docs/chart_template_guide/getting_started.md @@ -0,0 +1,216 @@ +--- +title: "Початок роботи" +weight: 2 +description: "Короткий посібник з шаблонів чартів." +--- + +У цьому розділі посібника ми створимо чарт і додамо перший шаблон. Чарт, який ми створимо тут, буде використовуватися протягом усього цього посібника. + +Щоб розпочати, давайте коротко ознайомимося з чартом Helm. + +## Чарти {#charts} + +Як описано в [Посібнику з чартів](../../topics/charts), чарти Helm мають таку структуру: + +```none +mychart/ + Chart.yaml + values.yaml + charts/ + templates/ + ... +``` + +Тека `templates/` призначена для файлів шаблонів. Коли Helm обробляє чарт, він передає всі файли з теки`templates/` до механізму рендерингу шаблонів. Потім збирає результати цих шаблонів і передає їх до Kubernetes. + +Файл `values.yaml` також важливий для шаблонів. Цей файл містить _стандартні значення_ для чарту. Користувачі можуть перевизначити ці значення під час `helm install` або `helm upgrade`. + +Файл `Chart.yaml` містить опис чарту. Ви можете отримати до нього доступ із шаблону. + +Тека `charts/` _може_ містити інші чарти (які ми називаємо _субчартами_). Пізніше в цьому посібнику ми побачимо, як вони працюють під час рендерингу шаблонів. + +## Стартовий чарт {#starter-chart} + +У цьому посібнику ми створимо простий чарт з назвою `mychart`, а потім створимо кілька шаблонів всередині чарту. + +```console +$ helm create mychart +Creating mychart +``` + +### Швидкий огляд `mychart/templates/` {#quick-glimpse-of-mychart-templates} + +Якщо ви поглянете на теку `mychart/templates/`, то помітите кілька файлів, які вже там є. + +- `NOTES.txt`: Вміст тексту довідки для вашого чарту. Його буде показана користувачам під час виконання `helm install`. +- `deployment.yaml`: Основний маніфест для створення [deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) у Kubernetes. +- `service.yaml`: Основний маніфест для створення [точки доступу сервісу](https://kubernetes.io/docs/concepts/services-networking/service/) для вашого deployment. +- `_helpers.tpl`: Місце для розміщення допоміжних шаблонів, які ви можете використовувати повторно по всьому чарту. + +І що ми збираємося зробити, це… _видалити їх усі!_ Таким чином, ми зможемо працювати з нашим посібником з нуля. Ми фактично створимо власні `NOTES.txt` та `_helpers.tpl` під час роботи. + +```console +$ rm -rf mychart/templates/* +``` + +Коли ви пишете чарти для операційної діяльності, мати базові версії цих чартів може бути дійсно корисно. Тож у повсякденному створенні чартів ви, ймовірно, не захочете їх видаляти. + +## Перший шаблон {#a-first-template} + +Перший шаблон, який ми збираємося створити, буде `ConfigMap`. У Kubernetes `ConfigMap` — це обʼєкт для зберігання конфігураційних даних. Інші речі, такі як podʼи, можуть отримувати доступ до даних у `ConfigMap`. + +Оскільки `ConfigMap` є базовим ресурсом, він стане чудовою відправною точкою для нас. + +Почнемо зі створення файлу з назвою `mychart/templates/configmap.yaml`: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: mychart-configmap +data: + myvalue: "Hello World" +``` + +**ПОРАДА:** Імена шаблонів не слідують жорсткому шаблону іменування. Проте ми рекомендуємо використовувати розширення `.yaml` для YAML-файлів та `.tpl` для допоміжних шаблонів. + +Наведений вище YAML-файл є мінімальною версією `ConfigMap`, що містить лише необхідні поля. Завдяки тому, що цей файл знаходиться в теці `mychart/templates/`, він буде переданий через механізм рендерингу шаблонів. + +Можна просто помістити звичайний YAML-файл, як цей, у теку `mychart/templates/`. Коли Helm читає цей шаблон, він просто передає його в Kubernetes у такому вигляді. + +За допомогою цього простого шаблону ми отримали чарт, який можна інсталювати. І ми можемо встановити його ось так: + +```console +$ helm install full-coral ./mychart +NAME: full-coral +LAST DEPLOYED: Tue Nov 1 17:36:01 2016 +NAMESPACE: default +STATUS: DEPLOYED +REVISION: 1 +TEST SUITE: None +``` + +За допомогою Helm ми можемо отримати реліз і побачити фактичний шаблон, який був завантажений. + +```console +$ helm get manifest full-coral + +--- +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: mychart-configmap +data: + myvalue: "Hello World" +``` + +Команда `helm get manifest` приймає імʼя релізу (`full-coral`) і виводить усі ресурси Kubernetes, які були завантажені на сервер. Кожен файл починається з `---`, що вказує на початок YAML-документа, а потім слідує автоматично згенерований коментар, який повідомляє нам, який файл шаблону згенерував цей YAML-документ. + +З цього моменту ми можемо побачити, що YAML-дані саме такі, як ми їх розмістили у файлі `configmap.yaml`. + +Тепер ми можемо видалити наш реліз: `helm uninstall full-coral`. + +### Додавання виклику простого шаблону {#adding-a-simple-template-call} + +Жорстке кодування поля `name:` у ресурсі зазвичай вважається поганою практикою. Імена повинні бути унікальними для кожного релізу. Тому ми можемо захотіти згенерувати поле імені, вставивши назву релізу. + +**ПОРАДА:** Поле `name:` обмежене 63 символами через обмеження системи DNS. З цієї причини імена релізів обмежені 53 символами. У Kubernetes версії 1.3 та раніше було обмежено лише 24 символами (тобто імена довжиною до 14 символів). + +Змінимо файл `configmap.yaml` відповідно. + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" +``` + +Основна зміна полягає в значенні поля `name:`, яке тепер має вигляд `{{ .Release.Name }}-configmap`. + +> Директива шаблону міститься у дужках `{{` та `}}`. + +Директива шаблону `{{ .Release.Name }}` вставляє назву релізу в шаблон. Значення, які передаються в шаблон, можна вважати _обʼєктами з просторами імен_, де точка (`.`) розділяє кожен елемент простору імен. + +Точка перед `Release` вказує, що ми починаємо з найвищого простору імен для цієї області застосування (про область ми поговоримо трохи пізніше). Таким чином, ми могли б прочитати `Release.Name` як: "почати з верхнього простору імен, знайти обʼєкт `Release`, а потім шукати всередині нього обʼєкт з назвою `Name`". + +Обʼєкт `Release` є одним із вбудованих обʼєктів для Helm, і ми розглянемо його більш детально пізніше. Але поки достатньо сказати, що це покаже назву релізу, яку бібліотека присвоює нашому релізу. + +Тепер, коли ми встановлюємо наш ресурс, ми одразу побачимо результат використання цієї директиви шаблону: + +```console +$ helm install clunky-serval ./mychart +NAME: clunky-serval +LAST DEPLOYED: Tue Nov 1 17:45:37 2016 +NAMESPACE: default +STATUS: DEPLOYED +REVISION: 1 +TEST SUITE: None +``` + +Ви можете запустити `helm get manifest clunky-serval`, щоб побачити весь згенерований YAML. + +Зверніть увагу, що імʼя ConfigMap всередині Kubernetes тепер є `clunky-serval-configmap`, замість попереднього `mychart-configmap`. + +На цьому етапі ми бачили шаблони в їх найпростішому вигляді: YAML-файли з вбудованими директивами шаблонів між `{{` та `}}`. У наступній частині ми глибше розглянемо шаблони. Але перед тим, як перейти далі, є один простий трюк, який може зробити створення шаблонів швидшим: коли ви хочете протестувати рендеринг шаблону, але насправді нічого не встановлювати, ви можете використати `helm install --debug --dry-run goodly-guppy ./mychart`. Це опрацює шаблони, але замість того, щоб встановити чарт, він поверне вам опрацьований шаблон, щоб ви могли побачити результат: + +```console +$ helm install --debug --dry-run goodly-guppy ./mychart +install.go:149: [debug] Original chart version: "" +install.go:166: [debug] CHART PATH: /Users/ninja/mychart + +NAME: goodly-guppy +LAST DEPLOYED: Thu Dec 26 17:24:13 2019 +NAMESPACE: default +STATUS: pending-install +REVISION: 1 +TEST SUITE: None +USER-SUPPLIED VALUES: +{} + +COMPUTED VALUES: +affinity: {} +fullnameOverride: "" +image: + pullPolicy: IfNotPresent + repository: nginx +imagePullSecrets: [] +ingress: + annotations: {} + enabled: false + hosts: + - host: chart-example.local + paths: [] + tls: [] +nameOverride: "" +nodeSelector: {} +podSecurityContext: {} +replicaCount: 1 +resources: {} +securityContext: {} +service: + port: 80 + type: ClusterIP +serviceAccount: + create: true + name: null +tolerations: [] + +HOOKS: +MANIFEST: +--- +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: goodly-guppy-configmap +data: + myvalue: "Hello World" + +``` + +Використання `--dry-run` полегшить тестування вашого коду, але це не гарантує, що сам Kubernetes прийме згенеровані вами шаблони. Краще не припускати, що ваш чарт буде встановлений тільки тому, що `--dry-run` працює. + +У [Посібнику з шаблонів чарту](_index.md) ми розглянемо базовий чарт, який ми визначили тут, і детально дослідимо мову шаблонів Helm. І ми почнемо з вбудованих обʼєктів. diff --git a/content/uk/docs/chart_template_guide/helm_ignore_file.md b/content/uk/docs/chart_template_guide/helm_ignore_file.md new file mode 100644 index 000000000..44c83a219 --- /dev/null +++ b/content/uk/docs/chart_template_guide/helm_ignore_file.md @@ -0,0 +1,56 @@ +--- +title: "Файл .helmignore" +description: "Файл `.helmignore` використовується для вказівки файлів, які не слід включати у ваш Helm чарт." +weight: 12 +--- + +Файл `.helmignore` використовується для вказівки файлів, які не слід включати у ваш Helm чарт. + +Якщо цей файл існує, команда `helm package` ігноруватиме всі файли, які відповідають шаблону, зазначеному у файлі `.helmignore`, під час упаковки вашого застосунку. + +Це може допомогти уникнути додавання непотрібних або конфіденційних файлів або тек у ваш Helm чарт. + +Файл `.helmignore` підтримує глобальний збіх Unix shell, відносний збіг шляхів та заперечення (з префіксом !). Розглядається лише один шаблон на рядок. + +Ось приклад файлу `.helmignore`: + +```none +# коментар + +# Відповідає будь-якому файлу або шляху з імʼям .helmignore +.helmignore + +# Відповідає будь-якому файлу або шляху з імʼям .git +.git + +# Відповідає будь-якому текстовому файлу +*.txt + +# Відповідає тільки текам з імʼям mydir +mydir/ + +# Відповідає тільки текстовим файлам на верхньому рівні теки +/*.txt + +# Відповідає тільки файлу foo.txt на верхньому рівні теки +/foo.txt + +# Відповідає будь-якому файлу з імʼям ab.txt, ac.txt або ad.txt +a[b-d].txt + +# Відповідає будь-якому файлу у субтеці subdir, що відповідає temp* +*/temp* + +*/*/temp* +temp? +``` + +Декілька важливих відмінностей від `.gitignore`: + +- Синтаксис '**' не підтримується. +- Бібліотека globbing є Go's `filepath.Match`, а не `fnmatch(3)`. +- Пробіли на кінці ігноруються завжди (немає підтримки екранованих послідовностей). +- Немає підтримки '\!' як спеціальної початкової послідовності. +- Файл `.helmignore` стандартно не виключає себе, потрібно додати явний запис для `.helmignore`. + +**Ми будемо вдячні за вашу допомогу** у покращенні цього документа. Щоб додати, виправити або видалити інформацію, [відкрийте тікет](https://github.com/helm/helm-www/issues) або надішліть нам запит на внесення змін. diff --git a/content/uk/docs/chart_template_guide/named_templates.md b/content/uk/docs/chart_template_guide/named_templates.md new file mode 100644 index 000000000..4dbfcd04a --- /dev/null +++ b/content/uk/docs/chart_template_guide/named_templates.md @@ -0,0 +1,286 @@ +--- +title: "Іменовані шаблони" +description: "Як визначити іменовані шаблони." +weight: 9 +--- + +Пора перейти від одного шаблону до створення інших. У цьому розділі ми побачимо, як визначити _іменовані шаблони_ в одному файлі, а потім використовувати їх в інших місцях. _Іменований шаблон_ (іноді його називають _частковим_ або _підшаблоном_) — це просто шаблон, визначений у файлі, якому надали імʼя. Ми розглянемо два способи створення таких шаблонів і кілька способів їх використання. + +У розділі [Керування потоком](./control_structures.md) ми представили три дії для оголошення та управління шаблонами: `define`, `template` і `block`. У цьому розділі ми розглянемо ці три дії, а також введемо спеціальну функцію `include`, яка працює подібно до дії `template`. + +Важлива деталь, яку слід памʼятати при іменуванні шаблонів: **імена шаблонів є глобальними**. Якщо ви оголосите два шаблони з однаковим імʼям, використовуватиметься той, який був завантажений останнім. Оскільки шаблони в субчартах компілюються разом з шаблонами верхнього рівня, слід бути обережним при іменуванні шаблонів, використовуючи _імена, специфічні для чарту_. + +Популярним способом іменування є префіксування кожного визначеного шаблону іменем чарту: `{{ define "mychart.labels" }}`. Використовуючи конкретне імʼя чарту як префікс, ми можемо уникнути будь-яких конфліктів, які можуть виникнути через два різних чарти, що реалізують шаблони з однаковим іменем. + +Ця поведінка також стосується різних версій чарту. Якщо у вас є `mychart` версії `1.0.0`, яка визначає шаблон одним способом, і `mychart` версії `2.0.0`, яка змінює наявний іменований шаблон, буде використовуватися той, який був завантажений останнім. Ви можете обійти цю проблему, додавши версію в імʼя чарту: `{{ define "mychart.v1.labels" }}` та `{{ define "mychart.v2.labels" }}`. + +## Часткові та `_` файли {#partials-and-_files} + +До цього часу ми використовували один файл, і цей один файл містив один шаблон. Але мова шаблонів Helm дозволяє створювати іменовані вкладені шаблони, до яких можна звертатися за іменем в інших місцях. + +Перед тим як перейти до деталей написання цих шаблонів, варто згадати про правила іменування файлів: + +* Більшість файлів у `templates/` обробляються як файли з маніфестами Kubernetes +* `NOTES.txt` є винятком +* Але файли, імʼя яких починається з підкреслення (`_`), вважаються такими, що _не мають_ маніфесту всередині. Ці файли не перетворюються на обʼєкти Kubernetes, але доступні в інших шаблонах чартів для використання. + +Ці файли використовуються для зберігання часткових шаблонів і допоміжних функцій. Насправді коли ми вперше створили `mychart`, ми бачили файл з назвою `_helpers.tpl`. Цей файл є стандартним місцем для часткових шаблонів. + +## Оголошення та використання шаблонів з `define` та `template` {#declaring-and-using-templates-with-define-and-template} + +Дія `define` дозволяє створювати іменовані шаблони всередині файлу шаблону. Її синтаксис виглядає так: + +```yaml +{{- define "MY.NAME" }} + # тіло шаблону тут +{{- end }} +``` + +Наприклад, ми можемо визначити шаблон для інкапсуляції блоку міток Kubernetes: + +```yaml +{{- define "mychart.labels" }} + labels: + generator: helm + date: {{ now | htmlDate }} +{{- end }} +``` + +Тепер ми можемо вбудувати цей шаблон всередині нашого наявного ConfigMap і включити його за допомогою дії `template`: + +```yaml +{{- define "mychart.labels" }} + labels: + generator: helm + date: {{ now | htmlDate }} +{{- end }} +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap + {{- template "mychart.labels" }} +data: + myvalue: "Hello World" + {{- range $key, $val := .Values.favorite }} + {{ $key }}: {{ $val | quote }} + {{- end }} +``` + +Коли рушій шаблонів читає цей файл, він зберігає посилання на `mychart.labels` до того часу, поки не буде викликано `template "mychart.labels"`. Тоді він рендерить цей шаблон безпосередньо. Результат виглядатиме так: + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: running-panda-configmap + labels: + generator: helm + date: 2016-11-02 +data: + myvalue: "Hello World" + drink: "coffee" + food: "pizza" +``` + +Примітка: `define` не створює виводу, якщо не буде викликано шаблон, як у цьому прикладі. + +Зазвичай шаблони Helm розміщують у файлах часткових шаблонів, зазвичай у `_helpers.tpl`. Перенесемо цю функцію туди: + +```yaml +{{/* Генерація базових міток */}} +{{- define "mychart.labels" }} + labels: + generator: helm + date: {{ now | htmlDate }} +{{- end }} +``` + +Згідно з домовленостями, функції `define` повинні мати простий блок документації (`{{/* ... */}}`), що описує їх призначення. + +Навіть якщо це визначення знаходиться в `_helpers.tpl`, його все ще можна використовувати в `configmap.yaml`: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap + {{- template "mychart.labels" }} +data: + myvalue: "Hello World" + {{- range $key, $val := .Values.favorite }} + {{ $key }}: {{ $val | quote }} + {{- end }} +``` + +Як уже згадувалося, **імена шаблонів є глобальними**. В результаті, якщо два шаблони оголошені з однаковим імʼям, буде використано останній варіант. Оскільки шаблони в субчартах компілюються разом з шаблонами верхнього рівня, краще давати шаблонам _специфічні для чарту імена_. Популярний спосіб іменування — це префіксувати кожен визначений шаблон іменем чарту: `{{ define "mychart.labels" }}`. + +## Встановлення області видимості шаблону {#setting-the-scope-of-a-template} + +У шаблоні, який ми визначили вище, ми не використовували жодних обʼєктів. Ми просто використовували функції. Змінимо наш визначений шаблон, щоб включити назву чарту та версію чарту: + +```yaml +{{/* Генерація базових міток */}} +{{- define "mychart.labels" }} + labels: + generator: helm + date: {{ now | htmlDate }} + chart: {{ .Chart.Name }} + version: {{ .Chart.Version }} +{{- end }} +``` + +Якщо ми його відрендеримо, ми отримаємо помилку, схожу на цю: + +```console +$ helm install --dry-run moldy-jaguar ./mychart +Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [unknown object type "nil" in ConfigMap.metadata.labels.chart, unknown object type "nil" in ConfigMap.metadata.labels.version] +``` + +Щоб побачити, що було відрендерено, повторіть команду з `--disable-openapi-validation`: `helm install --dry-run --disable-openapi-validation moldy-jaguar ./mychart`. Результат не буде таким, як ми очікували: + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: moldy-jaguar-configmap + labels: + generator: helm + date: 2021-03-06 + chart: + version: +``` + +Що сталося з назвою та версією? Вони не були в області видимості для нашого визначеного шаблону. Коли іменований шаблон (створений за допомогою `define`) рендериться, він отримує область видимості, передану через виклик `template`. У нашому прикладі ми включили шаблон ось так: + +```yaml +{{- template "mychart.labels" }} +``` + +Область видимості не була передана, тому всередині шаблону ми не можемо звертатися до нічого в `.`. Це досить легко виправити. Ми просто передаємо область видимості до шаблону: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap + {{- template "mychart.labels" . }} +``` + +Зверніть увагу, що ми передаємо `.` в кінці виклику `template`. Ми могли б так само легко передати `.Values` або `.Values.favorite`, або будь-яку іншу область видимості, яку хочемо. Але те, що нам потрібно, це область видимості верхнього рівня. + +Тепер, коли ми виконаємо цей шаблон з `helm install --dry-run --debug plinking-anaco ./mychart`, ми отримаємо таке: + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: plinking-anaco-configmap + labels: + generator: helm + date: 2021-03-06 + chart: mychart + version: 0.1.0 +``` + +Тепер `{{ .Chart.Name }}` розвʼязується в `mychart`, а `{{ .Chart.Version }}` розвʼязується в `0.1.0`. + +## Функція `include` {#the-include-function} + +Припустимо, ми визначили простий шаблон, який виглядає ось так: + +```yaml +{{- define "mychart.app" -}} +app_name: {{ .Chart.Name }} +app_version: "{{ .Chart.Version }}" +{{- end -}} +``` + +Тепер припустимо, я хочу вставити це як в розділ `labels:`, так і в розділ `data:`: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap + labels: + {{ template "mychart.app" . }} +data: + myvalue: "Hello World" + {{- range $key, $val := .Values.favorite }} + {{ $key }}: {{ $val | quote }} + {{- end }} +{{ template "mychart.app" . }} +``` + +Якщо ми це відрендеримо, ми отримаємо помилку, схожу на цю: + +```console +$ helm install --dry-run measly-whippet ./mychart +Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [ValidationError(ConfigMap): unknown field "app_name" in io.k8s.api.core.v1.ConfigMap, ValidationError(ConfigMap): unknown field "app_version" in io.k8s.api.core.v1.ConfigMap] +``` + +Щоб побачити, що було відрендеровано, повторіть команду з `--disable-openapi-validation`: `helm install --dry-run --disable-openapi-validation measly-whippet ./mychart`. Вихідні дані не будуть такими, як ми очікували: + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: measly-whippet-configmap + labels: + app_name: mychart +app_version: "0.1.0" +data: + myvalue: "Hello World" + drink: "coffee" + food: "pizza" +app_name: mychart +app_version: "0.1.0" +``` + +Зверніть увагу, що відступ на `app_version` неправильний в обох місцях. Чому? Тому що шаблон, який вставляється, має текст вирівняний по лівому краю. Оскільки `template` є дією, а не функцією, немає способу передати вихідний результат виклику `template` іншим функціям; дані просто вставляються в рядок. + +Щоб обійти цю проблему, Helm надає альтернативу `template`, яка імплементує вміст шаблону в поточний конвеєр, де він може бути переданий іншим функціям у конвеєрі. + +Ось приклад вище, виправлений з використанням `indent`, щоб правильно відступити шаблон `mychart.app`: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap + labels: +{{ include "mychart.app" . | indent 4 }} +data: + myvalue: "Hello World" + {{- range $key, $val := .Values.favorite }} + {{ $key }}: {{ $val | quote }} + {{- end }} +{{ include "mychart.app" . | indent 2 }} +``` + +Тепер створений YAML має вірний відступ для кожного розділу: + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: edgy-mole-configmap + labels: + app_name: mychart + app_version: "0.1.0" +data: + myvalue: "Hello World" + drink: "coffee" + food: "pizza" + app_name: mychart + app_version: "0.1.0" +``` + +> Вважається за краще використовувати `include` замість `template` у шаблонах Helm, щоб краще керувати форматуванням виходу для YAML-документів. + +Іноді ми хочемо імплементувати вміст, але не як шаблони. Тобто, ми хочемо імплементувати файли без змін. Ми можемо досягти цього, звертаючись до файлів через обʼєкт `.Files`, описаний у наступному розділі. diff --git a/content/uk/docs/chart_template_guide/notes_files.md b/content/uk/docs/chart_template_guide/notes_files.md new file mode 100644 index 000000000..4b396e896 --- /dev/null +++ b/content/uk/docs/chart_template_guide/notes_files.md @@ -0,0 +1,49 @@ +--- +title: "Створення файлу NOTES.txt" +description: "Як надати інструкції користувачам вашого чарту." +weight: 10 +--- + +У цьому розділі ми розглянемо інструмент Helm для надання інструкцій користувачам вашого чарту. Після виконання `helm install` або `helm upgrade` Helm може вивести блок корисної інформації для користувачів. Цю інформацію можна налаштувати за допомогою шаблонів. + +Щоб додати нотатки по установці до вашого чарту, просто створіть файл `templates/NOTES.txt`. Цей файл є звичайним текстовим файлом, але обробляється як шаблон і має всі звичайні функції та обʼєкти шаблонів. + +Створимо простий файл `NOTES.txt`: + +```none +Дякуємо за встановлення {{ .Chart.Name }}. + +Ваш реліз називається {{ .Release.Name }}. + +Щоб дізнатися більше про реліз, спробуйте: + + $ helm status {{ .Release.Name }} + $ helm get all {{ .Release.Name }} + +``` + +Тепер, якщо ми виконаємо `helm install rude-cardinal ./mychart`, ми побачимо це повідомлення внизу: + +``` +RESOURCES: +==> v1/Secret +NAME TYPE DATA AGE +rude-cardinal-secret Opaque 1 0s + +==> v1/ConfigMap +NAME DATA AGE +rude-cardinal-configmap 3 0s + + +NOTES: +Дякуємо за встановлення mychart. + +Ваш реліз називається rude-cardinal. + +Щоб дізнатися більше про реліз, спробуйте: + + $ helm status rude-cardinal + $ helm get all rude-cardinal +``` + +Використання `NOTES.txt` таким чином є чудовим способом надати вашим користувачам детальну інформацію про те, як використовувати новостворений чарт. Створення файлу `NOTES.txt` наполегливо рекомендується, хоча це і не є обовʼязковим. diff --git a/content/uk/docs/chart_template_guide/subcharts_and_globals.md b/content/uk/docs/chart_template_guide/subcharts_and_globals.md new file mode 100644 index 000000000..aa7c785f9 --- /dev/null +++ b/content/uk/docs/chart_template_guide/subcharts_and_globals.md @@ -0,0 +1,206 @@ +--- +title: "Субчарти та глобальні значення" +description: "Взаємодія з значеннями субчартів і глобальними значеннями." +weight: 11 +--- + +До цього моменту ми працювали тільки з одним чартом. Але чарти можуть мати залежності, які називаються _субчартами_, що також мають свої власні значення і шаблони. У цьому розділі ми створимо субчарт і розглянемо різні способи доступу до значень зсередини шаблонів. + +Перед тим, як перейти до коду, є кілька важливих деталей, які слід знати про субчарти: + +1. Субчарт вважається "автономним", що означає, що субчарт ніколи не може прямо залежати від батьківського чарту. +2. Тому субчарт не може отримувати доступ до значень свого пращура. +3. Батьківський чарт може перевизначати значення для субчартів. +4. Helm має концепцію _глобальних значень_, які можуть бути доступні всім чартам. + +> Ці обмеження не завжди застосовуються до [бібліотечних чартів]({{< ref "/docs/topics/library_charts.md" >}}), які розроблені для надання стандартної функціональності. + +Під час роботи з прикладами в цьому розділі ці концепції стануть зрозумілішими. + +## Створення субчарту {#creating-a-subchart} + +Для цих вправ ми почнемо з чарту `mychart/`, який ми створили на початку цього посібника, і додамо новий чарт всередину його. + +```console +$ cd mychart/charts +$ helm create mysubchart +Creating mysubchart +$ rm -rf mysubchart/templates/* +``` + +Зверніть увагу, що ми видалили всі базові шаблони, щоб почати з нуля. У цьому посібнику ми зосереджені на тому, як працюють шаблони, а не на управлінні залежностями. Але [Посібник з Чартів]({{< ref "../topics/charts.md" >}}) містить більше інформації про те, як працюють субчарти. + +## Додавання значень та шаблону до субчарту {#adding-values-and-a-template-to-the-subchart} + +Далі створимо простий шаблон і файл значень для чарту `mysubchart`. У `mychart/charts/mysubchart` вже має бути файл `values.yaml`. Налаштуємо його так: + +```yaml +dessert: cake +``` + +Далі створимо новий шаблон ConfigMap у `mychart/charts/mysubchart/templates/configmap.yaml`: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-cfgmap2 +data: + dessert: {{ .Values.dessert }} +``` + +Оскільки кожен субчарт є _самостіним чартом_, ми можемо протестувати `mysubchart` окремо: + +```console +$ helm install --generate-name --dry-run --debug mychart/charts/mysubchart +SERVER: "localhost:44134" +CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart/charts/mysubchart +NAME: newbie-elk +TARGET NAMESPACE: default +CHART: mysubchart 0.1.0 +MANIFEST: +--- +# Source: mysubchart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: newbie-elk-cfgmap2 +data: + dessert: cake +``` + +## Перевизначення значень з батьківського чарту {#overriding-values-from-a-parent-chart} + +Наш оригінальний чарт, `mychart`, тепер є _батьківським_ чартом для `mysubchart`. Ці стосунки базується виключно на тому, що `mysubchart` знаходиться в `mychart/charts`. + +Оскільки `mychart` є батьківським чартом, ми можемо вказати конфігурацію в `mychart` і передати цю конфігурацію в `mysubchart`. Наприклад, ми можемо змінити `mychart/values.yaml` таким чином: + +```yaml +favorite: + drink: coffee + food: pizza +pizzaToppings: + - mushrooms + - cheese + - peppers + - onions + +mysubchart: + dessert: ice cream +``` + +Зверніть увагу на останні два рядки. Будь-які директиви всередині секції `mysubchart` будуть передані в чарт `mysubchart`. Отже, якщо ми виконаємо `helm install --generate-name --dry-run --debug mychart`, однією з речей, які ми побачимо, буде ConfigMap `mysubchart`: + +```yaml +# Source: mychart/charts/mysubchart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: unhinged-bee-cfgmap2 +data: + dessert: ice cream +``` + +Значення на верхньому рівні тепер перевизначило значення субчарту. + +Важливо помітити, що ми не змінили шаблон `mychart/charts/mysubchart/templates/configmap.yaml`, щоб вказати на `.Values.mysubchart.dessert`. З точки зору цього шаблону, значення все ще розташоване в `.Values.dessert`. Оскільки шаблонний движок передає значення далі, він встановлює область видимості. Отже, для шаблонів `mysubchart` тільки значення, специфічні для `mysubchart`, будуть доступні в `.Values`. + +Іноді, проте, ви хочете, щоб певні значення були доступні всім шаблонам. Це досягається за допомогою глобальних значень чарту. + +## Глобальні значення чарту {#global-chart-values} + +Глобальні значення — це значення, які можуть бути доступні з будь-якого чарту або субчарту під тим самим імʼям. Глобальні значення потребують явного оголошення. Ви не можете використовувати вже наявні неглобальні значення як глобальні. + +Тип даних Values має зарезервовану секцію `Values.global`, де можна задати глобальні значення. Визначимо одне в нашому файлі `mychart/values.yaml`. + +```yaml +favorite: + drink: coffee + food: pizza +pizzaToppings: + - mushrooms + - cheese + - peppers + - onions + +mysubchart: + dessert: ice cream + +global: + salad: caesar +``` + +Завдяки способу роботи глобальних значень, як `mychart/templates/configmap.yaml`, так і `mysubchart/templates/configmap.yaml` повинні мати змогу отримати це значення як `{{ .Values.global.salad }}`. + +`mychart/templates/configmap.yaml`: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + salad: {{ .Values.global.salad }} +``` + +`mysubchart/templates/configmap.yaml`: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-cfgmap2 +data: + dessert: {{ .Values.dessert }} + salad: {{ .Values.global.salad }} +``` + +Тепер, якщо ми виконаємо установку в режимі dry run, ми побачимо одне й те ж значення в обох виводах: + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: silly-snake-configmap +data: + salad: caesar + +--- +# Source: mychart/charts/mysubchart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: silly-snake-cfgmap2 +data: + dessert: ice cream + salad: caesar +``` + +Глобальні значення корисні для передачі такої інформації, хоча це вимагає певного планування, щоб переконатися, що правильні шаблони налаштовані для використання глобальних значень. + +## Поширення шаблонів з субчартами {#sharing-templates-with-subcharts} + +Батьківські чарти та субчарти можуть ділитися шаблонами. Будь-який визначений блок у будь-якому чарті доступний іншим чартам. + +Наприклад, ми можемо визначити простий шаблон таким чином: + +```yaml +{{- define "labels" }}from: mychart{{ end }} +``` + +Згадайте, як мітки на шаблонах є _глобально спільними_. Отже, шаблон `labels` можна включити з будь-якого іншого чарту. + +Хоча розробники чартів можуть вибирати між `include` та `template`, однією з переваг використання `include` є те, що `include` може динамічно посилатися на шаблони: + +```yaml +{{ include $mytemplate }} +``` + +Вищезазначене призведе до розʼєднання посилань на `$mytemplate`. Функція `template`, навпаки, приймає тільки рядковий літерал. + +## Уникнення використання блоків {#avoid-using-blocks} + +Мова шаблонів Go надає ключове слово `block`, яке дозволяє розробникам надати стандартну реалізацію, яка потім перевизначається. У чарті Helm блоки не є найкращим інструментом для перевизначення, оскільки якщо кілька реалізацій одного блоку надаються, вибір однієї з них є непередбачуваним. + +Рекомендація — використовувати `include`. diff --git a/content/uk/docs/chart_template_guide/values_files.md b/content/uk/docs/chart_template_guide/values_files.md new file mode 100644 index 000000000..a861c261c --- /dev/null +++ b/content/uk/docs/chart_template_guide/values_files.md @@ -0,0 +1,161 @@ +--- +title: "Файли значень" +description: "Інструкції щодо використання прапорця --values." +weight: 4 +--- + +У попередньому розділі ми розглянули вбудовані обʼєкти, які пропонують шаблони Helm. Один з вбудованих обʼєктів — це `Values`. Цей обʼєкт надає доступ до значень, переданих у шаблон. Його вміст походить з кількох джерел: + +- Файл `values.yaml` у шаблоні +- Якщо це субшаблон, файл `values.yaml` батьківського шаблону +- Файл значень передається в `helm install` або `helm upgrade` з прапорцем `-f` (`helm install -f myvals.yaml ./mychart`) +- Окремі параметри передаються з `--set` (наприклад, `helm install --set foo=bar ./mychart`) + +Наведений вище список розташований у порядку специфічності: `values.yaml` є стандартним, яке може бути перевизначене файлом `values.yaml` батьківського шаблону, який, своєю чергою, може бути перевизначений файлом значень, наданим користувачем, який, своєю чергою, може бути перевизначений параметрами `--set`. + +Файли значень — це прості YAML-файли. Відредагуємо `mychart/values.yaml`, а потім відредагуємо наш шаблон ConfigMap. + +Видаливши стандартні значення у `values.yaml`, ми встановимо лише один параметр: + +```yaml +favoriteDrink: coffee +``` + +Тепер ми можемо використовувати його всередині шаблону: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + drink: {{ .Values.favoriteDrink }} +``` + +Зверніть увагу, що в останньому рядку ми отримуємо доступ до `favoriteDrink` як до атрибута `Values`: `{{ .Values.favoriteDrink }}`. + +Подивімося, як це відобразиться. + +```console +$ helm install geared-marsupi ./mychart --dry-run --debug +install.go:158: [debug] Original chart version: "" +install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart + +NAME: geared-marsupi +LAST DEPLOYED: Wed Feb 19 23:21:13 2020 +NAMESPACE: default +STATUS: pending-install +REVISION: 1 +TEST SUITE: None +USER-SUPPLIED VALUES: +{} + +COMPUTED VALUES: +favoriteDrink: coffee + +HOOKS: +MANIFEST: +--- +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: geared-marsupi-configmap +data: + myvalue: "Hello World" + drink: coffee +``` + +Оскільки `favoriteDrink` встановлено в стандартне значення у файлі `values.yaml` як `coffee`, це значення відображається в шаблоні. Ми можемо легко перевизначити його, додавши прапорець `--set` у наш виклик `helm install`: + +```console +$ helm install solid-vulture ./mychart --dry-run --debug --set favoriteDrink=slurm +install.go:158: [debug] Original chart version: "" +install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart + +NAME: solid-vulture +LAST DEPLOYED: Wed Feb 19 23:25:54 2020 +NAMESPACE: default +STATUS: pending-install +REVISION: 1 +TEST SUITE: None +USER-SUPPLIED VALUES: +favoriteDrink: slurm + +COMPUTED VALUES: +favoriteDrink: slurm + +HOOKS: +MANIFEST: +--- +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: solid-vulture-configmap +data: + myvalue: "Hello World" + drink: slurm +``` + +Оскільки `--set` має вищий пріоритет, ніж файл `values.yaml`, наш шаблон генерує `drink: slurm`. + +Файли значень також можуть містити більш структурований контент. Наприклад, ми могли б створити розділ `favorite` у нашому файлі `values.yaml`, а потім додати туди кілька ключів: + +```yaml +favorite: + drink: coffee + food: pizza +``` + +Тепер нам потрібно трохи змінити шаблон: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + drink: {{ .Values.favorite.drink }} + food: {{ .Values.favorite.food }} +``` + +Хоча структурування даних таким чином є можливим, рекомендується тримати дерева значень пласкими, надаючи перевагу рівній структурі. Коли ми розглядатимемо призначення значень субшаблонам, ми побачимо, як значення називаються, використовуючи структуру дерева. + +## Видалення стандартного ключа {#deleting-a-default-key} + +Якщо вам потрібно видалити ключ зі стандартних значень, ви можете перевизначити значення ключа як `null`, у цьому випадку Helm видалить ключ з злиття перевизначених значень. + +Наприклад, стабільний шаблон Drupal дозволяє налаштовувати перевірку життєздатності (liveness probe) у випадку, якщо ви налаштовуєте власний образ. Ось стандартні значення: + +```yaml +livenessProbe: + httpGet: + path: /user/login + port: http + initialDelaySeconds: 120 +``` + +Якщо ви спробуєте перевизначити обробник livenessProbe на `exec` замість `httpGet`, використовуючи `--set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt]`, Helm обʼєднає стандартні ключі разом з перевизначеними, що дасть нам наступний YAML: + +```yaml +livenessProbe: + httpGet: + path: /user/login + port: http + exec: + command: + - cat + - docroot/CHANGELOG.txt + initialDelaySeconds: 120 +``` + +Однак Kubernetes тоді видасть помилку, оскільки не можна оголошувати більше одного обробника livenessProbe. Щоб це обійти, ви можете інструктувати Helm видалити `livenessProbe.httpGet`, встановивши його значення в null: + +```sh +helm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null +``` + +На цьому етапі ми розглянули кілька вбудованих обʼєктів і використали їх для вставки інформації в шаблон. Тепер ми розглянемо інший аспект шаблонного механізму: функції та конвеєри. diff --git a/content/uk/docs/chart_template_guide/variables.md b/content/uk/docs/chart_template_guide/variables.md new file mode 100644 index 000000000..91921fb32 --- /dev/null +++ b/content/uk/docs/chart_template_guide/variables.md @@ -0,0 +1,132 @@ +--- +title: "Змінні" +description: "Використання змінних у шаблонах." +weight: 8 +--- + +Маючи функції, конвеєри, обʼєкти та структури управління, ми можемо перейти до однієї з основних ідей у багатьох мовах програмування: змінних. У шаблонах вони використовуються рідше. Але ми побачимо, як їх можна використовувати для спрощення коду та для кращого використання `with` і `range`. + +У попередньому прикладі ми побачили, що цей код не працює: + +```yaml + {{- with .Values.favorite }} + drink: {{ .drink | default "tea" | quote }} + food: {{ .food | upper | quote }} + release: {{ .Release.Name }} + {{- end }} +``` + +`Release.Name` не знаходиться в межах області видимості, обмеженої блоком `with`. Один зі способів обійти проблеми з областю видимості — присвоїти обʼєкти змінним, до яких можна отримати доступ без врахування поточної області видимості. + +У шаблонах Helm змінна є іменованим посиланням на інший обʼєкт. Вона має формат `$name`. Змінні присвоюються за допомогою спеціального оператора присвоєння: `:=`. Ми можемо переписати вищезазначене, використовуючи змінну для `Release.Name`. + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + {{- $relname := .Release.Name -}} + {{- with .Values.favorite }} + drink: {{ .drink | default "tea" | quote }} + food: {{ .food | upper | quote }} + release: {{ $relname }} + {{- end }} +``` + +Зверніть увагу, що перед тим як почати блок `with`, ми присвоюємо `$relname := .Release.Name`. Тепер всередині блоку `with` змінна `$relname` все ще вказує на імʼя релізу. + +Запуск цього коду дасть наступний результат: + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: viable-badger-configmap +data: + myvalue: "Hello World" + drink: "coffee" + food: "PIZZA" + release: viable-badger +``` + +Змінні особливо корисні в циклах `range`. Їх можна використовувати для спископодібних обʼєктів, щоб захопити як індекс, так і значення: + +```yaml + toppings: |- + {{- range $index, $topping := .Values.pizzaToppings }} + {{ $index }}: {{ $topping }} + {{- end }} +``` + +Зверніть увагу, що `range` йде першим, потім змінні, потім оператор присвоєння, а потім список. Це присвоїть ціле число (починаючи з нуля) змінній `$index` і значення змінній `$topping`. Запуск цього коду дасть: + +```yaml + toppings: |- + 0: mushrooms + 1: cheese + 2: peppers + 3: onions +``` + +Для структур даних, які мають як ключ, так і значення, ми можемо використовувати `range`, щоб отримати обидва. Наприклад, ми можемо перебрати `.Values.favorite` таким чином: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name }}-configmap +data: + myvalue: "Hello World" + {{- range $key, $val := .Values.favorite }} + {{ $key }}: {{ $val | quote }} + {{- end }} +``` + +Тепер на першій ітерації `$key` буде `drink`, а `$val` буде `coffee`, а на другій `$key` буде `food`, а `$val` буде `pizza`. Запуск цього коду створить: + +```yaml +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: eager-rabbit-configmap +data: + myvalue: "Hello World" + drink: "coffee" + food: "pizza" +``` + +Змінні зазвичай не є "глобальними". Вони мають область видимості в межах блоку, в якому вони оголошені. Раніше ми присвоїли `$relname` на верхньому рівні шаблону. Ця змінна буде видима для всього шаблону. Але в нашому останньому прикладі змінні `$key` і `$val` будуть видимі лише всередині блоку `{{ range... }}{{ end }}`. + +Однак є одна змінна, яка завжди є глобальною — `$`, ця змінна завжди буде вказувати на кореневий контекст. Це може бути дуже корисно, коли ви перебираєте в діапазоні і вам потрібно знати імʼя релізу чарту. + +Приклад, що ілюструє це: + +```yaml +{{- range .Values.tlsSecrets }} +apiVersion: v1 +kind: Secret +metadata: + name: {{ .name }} + labels: + # Багато шаблонів Helm використовували б `.` тут, але це не спрацює, + # однак `$` спрацює тут + app.kubernetes.io/name: {{ template "fullname" $ }} + # Я не можу звертатися до .Chart.Name, але можу використовувати $.Chart.Name + helm.sh/chart: "{{ $.Chart.Name }}-{{ $.Chart.Version }}" + app.kubernetes.io/instance: "{{ $.Release.Name }}" + # Значення з appVersion у Chart.yaml + app.kubernetes.io/version: "{{ $.Chart.AppVersion }}" + app.kubernetes.io/managed-by: "{{ $.Release.Service }}" +type: kubernetes.io/tls +data: + tls.crt: {{ .certificate }} + tls.key: {{ .key }} +--- +{{- end }} +``` + +До цього часу ми розглянули лише один шаблон, оголошений в одному файлі. Але одна з потужних можливостей мови шаблонів Helm — це можливість оголошувати кілька шаблонів і використовувати їх разом. Ми перейдемо до цього в наступному розділі. diff --git a/content/uk/docs/chart_template_guide/wrapping_up.md b/content/uk/docs/chart_template_guide/wrapping_up.md new file mode 100644 index 000000000..9354f293c --- /dev/null +++ b/content/uk/docs/chart_template_guide/wrapping_up.md @@ -0,0 +1,26 @@ +--- +title: "Наступні кроки" +description: "Підсумок — корисні вказівки на іншу документацію, яка може допомогти вам." +weight: 14 +--- + +Цей посібник має на меті надати вам, розробнику чартів, глибоке розуміння того, як використовувати мову шаблонів Helm. Посібник зосереджений на технічних аспектах розробки шаблонів. + +Але є багато аспектів практичного щоденного розроблення чартів, які цей посібник не охоплює. Ось кілька корисних вказівок на іншу документацію, яка допоможе вам у створенні нових чартів: + +- CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0) є незамінним джерелом чартів. +- [Документація Kubernetes](https://kubernetes.io/docs/home/) надає детальні приклади різних ресурсів, які ви можете використовувати, від ConfigMaps і Secrets до DaemonSets і Deployments. +- Посібник [Чарти Helm](../../topics/charts/) пояснює робочий процес використання чартів. +- Посібник [Хуки чартів Helm](../../topics/charts_hooks/) пояснює, як створювати хук для життєвого циклу. +- Стаття [Поради та підказки для розробки чартів](../../howto/charts_tips_and_tricks/) надає кілька корисних порад для написання чартів. +- Документація [Sprig](https://github.com/Masterminds/sprig) описує більше ніж шістдесят функцій шаблонів. +- Документація [Go templates](https://godoc.org/text/template) детально пояснює синтаксис шаблонів. +- Інструмент [Schelm](https://github.com/databus23/schelm) є корисною утилітою для налагодження чартів. + +Іноді легше поставити кілька запитань і отримати відповіді від досвідчених розробників. Найкраще місце для цього — канали Helm у [Slack Kubernetes](https://kubernetes.slack.com): + +- [#helm-users](https://kubernetes.slack.com/messages/helm-users) +- [#helm-dev](https://kubernetes.slack.com/messages/helm-dev) +- [#charts](https://kubernetes.slack.com/messages/charts) + +Нарешті, якщо ви знайдете помилки або упущення в цьому документі, хочете запропонувати новий контент або хотіли б внести свій внесок, відвідайте [The Helm Project](https://github.com/helm/helm-www). diff --git a/content/uk/docs/chart_template_guide/yaml_techniques.md b/content/uk/docs/chart_template_guide/yaml_techniques.md new file mode 100644 index 000000000..1ce7fa6b8 --- /dev/null +++ b/content/uk/docs/chart_template_guide/yaml_techniques.md @@ -0,0 +1,294 @@ +--- +title: "Додаток: Техніки YAML" +description: "Ближчий погляд на специфікацію YAML та її застосування до Helm." +weight: 15 +--- + +Більшість цього посібника зосереджена на написанні мови шаблонів. Тут ми розглянемо формат YAML. YAML має кілька корисних функцій, які ми, як автори шаблонів, можемо використовувати для того, щоб зробити наші шаблони менш схильними до помилок і легшими для читання. + +## Масиви та Колекції {#scalars-and-collections} + +Згідно зі [специфікацією YAML](https://yaml.org/spec/1.2/spec.html), існують два типи колекцій та багато типів скалярів. + +Два типи колекцій — це map та послідовності: + +```yaml +map: + one: 1 + two: 2 + three: 3 + +sequence: + - one + - two + - three +``` + +Скалярні значення – це окремі значення (на відміну від колекцій). + +### Типи скалярів у YAML {#scalar-types-in-yaml} + +У діалекті YAML Helm тип даних значення визначається складним набором правил, включаючи схему Kubernetes для ресурсних визначень. Але при визначенні типів, наступні правила зазвичай є правильними. + +Якщо ціле число або десяткове число є без лапок, це зазвичай трактуватиметься як числовий тип: + +```yaml +count: 1 +size: 2.34 +``` + +Але якщо вони укладені в лапки, вони трактуються як рядки: + +```yaml +count: "1" # <-- рядок, не int +size: '2.34' # <-- рядок, не float +``` + +Те ж саме стосується булевих значень: + +```yaml +isGood: true # bool +answer: "true" # рядок +``` + +Слово для пустого значення — `null` (не `nil`). + +Зверніть увагу, що `port: "80"` є дійсним YAML і пройде через рушій шаблонів та парсер YAML, але зазнає невдачі, якщо Kubernetes очікує, що `port` буде цілим числом. + +У деяких випадках ви можете примусово визначити певний тип, використовуючи теґи вузлів YAML: + +```yaml +coffee: "yes, please" +age: !!str 21 +port: !!int "80" +``` + +У наведеному вище прикладі `!!str` говорить парсеру, що `age` є рядком, навіть якщо він виглядає як int. А `port` трактуватиметься як int, навіть якщо він укладений в лапки. + +## Рядки в YAML {#strings-in-yaml} + +Більшість даних, які ми розміщуємо в документах YAML, є рядками. YAML має кілька способів представлення рядків. Цей розділ пояснює способи та демонструє, як використовувати деякі з них. + +Існують три "вбудовані" способи оголошення рядка: + +```yaml +way1: просто слова +way2: "рядки в подвійних лапках" +way3: 'рядки в одинарних лапках' +``` + +Всі вбудовані стилі мають бути в одному рядку. + +- Невкладені слова не мають лапок і не екрановані. Тому потрібно бути обережним із символами, які ви використовуєте. +- Рядки в подвійних лапках можуть мати спеціальні символи екрановані за допомогою `\`. Наприклад, `"\"Hello\", she said"`. Можна екранувати розриви рядка за допомогою `\n`. +- Рядки в одинарних лапках є "літеральними" рядками та не використовують `\` для екранування символів. Єдине екранування — це `''`, яке декодується як один символ `'`. + +Окрім рядків в один рядок, можна оголосити багаторядкові рядки: + +```yaml +coffee: | + Latte + Cappuccino + Espresso +``` + +Вищенаведене буде трактувати значення `coffee` як один рядок, еквівалентний `Latte\nCappuccino\nEspresso\n`. + +Зверніть увагу, що перший рядок після `|` повинен мати вірний відступ. Тому ми можемо зламати приклад вище, зробивши це: + +```yaml +coffee: | + Latte + Cappuccino + Espresso + +``` + +Оскільки `Latte` має неправильний відступ, ми отримаємо помилку на кшталт: + +```none +Error parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key +``` + +У шаблонах іноді безпечніше помістити несправжній "перший рядок" у багаторядковому документі лише для захисту від цієї помилки: + +```yaml +coffee: | + # Коментований перший рядок + Latte + Cappuccino + Espresso + +``` + +Зауважте, що яким би не був цей перший рядок, його буде збережено у виведенні рядка. Тому, якщо ви, наприклад, використовуєте цю техніку для вливання вмісту файлу в ConfigMap, коментар має бути типу, який очікується тим, хто читає цей запис. + +### Керування пробілами в багаторядкових рядках {#controlling-spaces-in-multiline-strings} + +У наведеному вище прикладі ми використовували `|`, щоб позначити багаторядковий рядок. Але зверніть увагу, що вміст нашого рядка завершувався з кінцевим `\n`. Якщо ми хочемо, щоб обробник YAML видалив кінцевий перенос рядка, ми можемо додати `-` після `|`: + +```yaml +coffee: |- + Latte + Cappuccino + Espresso +``` + +Тепер значення `coffee` буде: `Latte\nCappuccino\nEspresso` (без кінцевого `\n`). + +В інших випадках ми можемо захотіти зберегти весь кінцевий пробіл. Ми можемо зробити це за допомогою позначення `|+`: + +```yaml +coffee: |+ + Latte + Cappuccino + Espresso + + +another: value +``` + +Тепер значення `coffee` буде `Latte\nCappuccino\nEspresso\n\n\n`. + +Відступи всередині текстового блоку зберігаються, що призводить до збереження переносу рядків: + +```yaml +coffee: |- + Latte + 12 oz + 16 oz + Cappuccino + Espresso +``` + +У наведеному вище випадку значення `coffee` буде `Latte\n 12 oz\n 16 oz\nCappuccino\nEspresso`. + +### Відступи та шаблони {#indenting-and-templates} + +Коли ви пишете шаблони, ви можете захотіти вставити вміст файлу в шаблон. Як ми бачили в попередніх розділах, є два способи зробити це: + +- Використовуйте `{{ .Files.Get "FILENAME" }}`, щоб отримати вміст файлу в чартах. +- Використовуйте `{{ include "TEMPLATE" . }}`, щоб відобразити шаблон, а потім вставити його вміст у чарти. + +Коли ви вставляєте файли в YAML, корисно розуміти правила багаторядкових рядків. Найчастіше найпростіший спосіб вставити статичний файл — зробити щось на кшталт цього: + +```yaml +myfile: | +{{ .Files.Get "myfile.txt" | indent 2 }} +``` + +Зверніть увагу, як ми виконуємо відступ вище: `indent 2` говорить шаблонному двигуну відступити кожен рядок у "myfile.txt" на два пробіли. Зверніть увагу, що ми не відступаємо сам рядок шаблону. Це тому, що якщо ми це зробимо, вміст файлу першого рядка буде відступлений двічі. + +### Згортання багаторядкових рядків {#folded-multi-line-strings} + +Іноді вам потрібно представити рядок у вашому YAML на кількох рядках, але ви хочете, щоб він трактувався як один довгий рядок під час інтерпретації. Це називається "згортанням". Щоб оголосити згортання блоку, використовуйте `>` замість `|`: + +```yaml +coffee: > + Latte + Cappuccino + Espresso + + +``` + +Значення `coffee` буде `Latte Cappuccino Espresso\n`. Зверніть увагу, що всі, крім останнього переносу рядка, будуть перетворені на пробіли. Ви можете поєднувати контроль пробілів із позначкою згортання тексту, тому `>-` замінить або обрізає всі нові рядки. + +Зверніть увагу, що в згортанні синтаксису відступ тексту призведе до збереження рядків. + +```yaml +coffee: >- + Latte + 12 oz + 16 oz + Cappuccino + Espresso +``` + +Наведене вище створить `Latte\n 12 oz\n 16 oz\nCappuccino Espresso`. Зверніть увагу, що і пробіли, і нові рядки все ще присутні. + +## Вбудовування кількох документів в один файл {#embedding-multiple-documents-in-one-file} + +Можливо розмістити більше одного YAML-документа в одному файлі. Це робиться шляхом префіксації нового документа `---` і закінчення документа `...` + +```yaml + +--- +document:1 +... +--- +document: 2 +... +``` + +У багатьох випадках можна опустити `---` або `...`. + +Деякі файли в Helm не можуть містити більше одного документа. Якщо, наприклад, у файлі `values.yaml` надано більше одного документа, буде використано лише перший. + +Однак файли шаблонів можуть мати більше одного документа. Коли це трапляється, файл (і всі його документи) обробляється як один обʼєкт під час рендерингу шаблонів. Але потім отриманий YAML розділяється на кілька документів, перш ніж він буде переданий Kubernetes. + +Ми рекомендуємо використовувати кілька документів у файлі лише в разі крайньої потреби. Наявність кількох документів у файлі може ускладнити налагодження. + +## YAML є надмножиною JSON {#yaml-is-a-superset-of-json} + +Оскільки YAML є надмножиною JSON, будь-який дійсний JSON-документ _повинен_ бути дійсним YAML. + +```json +{ + "coffee": "yes, please", + "coffees": [ + "Latte", "Cappuccino", "Espresso" + ] +} +``` + +Вищенаведене є іншим способом представлення цього: + +```yaml +coffee: yes, please +coffees: +- Latte +- Cappuccino +- Espresso +``` + +І їх можна змішувати (з обережністю): + +```yaml +coffee: "yes, please" +coffees: [ "Latte", "Cappuccino", "Espresso"] +``` + +Усі три повинні перетворюватись в однакове внутрішнє подання. + +Це означає, що файли, такі як `values.yaml`, можуть містити дані JSON, але Helm не трактує розширення файлу `.json` як дійсний суфікс. + +## Якорі YAML {#yaml-anchors} + +Специфікація YAML надає спосіб зберігати посилання на значення і пізніше посилатися на це значення за допомогою посилання. YAML називає це "якорінням": + +```yaml +coffee: "yes, please" +favorite: &favoriteCoffee "Cappuccino" +coffees: + - Latte + - *favoriteCoffee + - Espresso +``` + +У наведеному вище прикладі `&favoriteCoffee` встановлює посилання на `Cappuccino`. Пізніше це посилання використовується як `*favoriteCoffee`. Таким чином, `coffees` стає `Latte, Cappuccino, Espresso`. + +Хоча є кілька випадків, коли якорі корисні, існує один аспект їх використання, який може спричинити тонкі помилки: під час першого використання YAML посилання розширюється і потім видаляється. + +Тому, якщо ми декодуємо і потім повторно кодуємо приклад вище, отриманий YAML буде таким: + +```yaml +coffee: yes, please +favorite: Cappuccino +coffees: +- Latte +- Cappuccino +- Espresso +``` + +Оскільки Helm і Kubernetes часто читають, змінюють і потім переписують файли YAML, якорі будуть втрачені. diff --git a/content/uk/docs/community/_index.md b/content/uk/docs/community/_index.md new file mode 100644 index 000000000..02146b4e8 --- /dev/null +++ b/content/uk/docs/community/_index.md @@ -0,0 +1,8 @@ +--- +title: "Спільнота" +weight: 7 +--- + +# Настанови спільноти {#community-guides} + +Дізнайтесь про процес розробки проєкту Helm та як ви можете зробити свій внесок. diff --git a/content/uk/docs/community/developers.md b/content/uk/docs/community/developers.md new file mode 100644 index 000000000..498bc3372 --- /dev/null +++ b/content/uk/docs/community/developers.md @@ -0,0 +1,109 @@ +--- +title: "Посібник для розробників" +description: "Інструкції щодо налаштування середовища для розробки Helm." +weight: 1 +--- + +Цей посібник пояснює, як налаштувати ваше середовище для розробки на Helm. + +## Передумови {#prerequisites} + +- Остання версія Go +- Кластер Kubernetes з kubectl (необовʼязково) +- Git + +## Збирання Helm {#building-helm} + +Ми використовуємо Make для компіляції наших програм. Найпростіший спосіб почати: + +```console +$ make +``` + +Якщо потрібно, спочатку будуть встановлені залежності та перевірена конфігурація. Потім буде скомпільовано `helm` і розміщено у `bin/helm`. + +Щоб запустити Helm локально, ви можете запустити `bin/helm`. + +- Helm відомий тим, що працює на macOS та більшості дистрибутивів Linux, включаючи Alpine. + +## Запуск тестів {#running-tests} + +Щоб запустити всі тести, виконайте `make test`. Перед цим вам потрібно мати встановлений [golangci-lint](https://golangci-lint.run). + +## Настанови щодо участі {#contribution-guidelines} + +Ми раді вашій участі. Цей проєкт має деякі настанови, щоб забезпечити (а) високу якість коду, (б) послідовність проєкту, і (в) відповідність юридичним вимогам проєктів з відкритими сирцями. Наша мета не обтяжувати учасників, а побудувати елегантний та якісний відкритий код, щоб наші користувачі отримали користь. + +Переконайтеся, що ви прочитали та зрозуміли основний посібник щодо участі: + + + +### Структура коду {#structure-of-the-code} + +Код проєкту Helm організовано наступним чином: + +- Самостійні програми знаходяться в `cmd/`. Код всередині `cmd/` не призначений для повторного використання як бібліотеки. +- Спільні бібліотеки зберігаються в `pkg/`. +- Тека `scripts/` містить кілька скриптів утиліт. Більшість з них використовується конвеєром CI/CD. + +Управління залежностями Go змінюється, і, ймовірно, змінюватиметься протягом життєвого циклу Helm. Ми рекомендуємо розробникам _не_ намагатися вручну управляти залежностями. Натомість ми радимо покладатися на `Makefile` проєкту для цього. З Helm 3 рекомендується використовувати версію Go 1.13 або новішу. + +### Написання документації {#writing-documentation} + +З Helm 3 документація була перенесена в окремий репозиторій. При написанні нових функцій, будь ласка, напишіть супутню документацію та надішліть її до репозиторію [helm-www](https://github.com/helm/helm-www). + +Єдине виключення: [вивід CLI Helm (англійською)](https://helm.sh/docs/helm/) генеруються безпосередньо з бінарного файлу `helm`. Дивіться [Оновлення довідкових документів CLI Helm](https://github.com/helm/helm-www#updating-the-helm-cli-reference-docs) для інструкцій, як згенерувати цей вивід. Після перекладу, вивід CLI не генерується і може бути знайдений у `/content//docs/helm`. + +### Домовленості Git {#git-conventions} + +Ми використовуємо Git як нашу систему контролю версій. Гілка `main` є домом для поточного кандидата на розробку. Релізи позначаються теґами. + +Ми приймаємо зміни до коду через Pull Requests (PRs) на GitHub. Один з робочих процесів для цього виглядає наступним чином: + +1. Форкніть репозиторій `github.com/helm/helm` у ваш обліковий запис GitHub +2. Зробіть `git clone` цього форку у бажану теку +3. Створіть нову робочу гілку (`git checkout -b feat/my-feature`) і працюйте з цією гілкою. +4. Коли ви будете готові до перегляду, залийте вашу гілку на GitHub, а потім відкрийте новий pull request у нас. + +Для повідомлень комітів Git ми дотримуємося [Semantic Commit Messages](https://karma-runner.github.io/0.13/dev/git-commit-msg.html): + +``` +fix(helm): add --foo flag to 'helm install' + +When 'helm install --foo bar' is run, this will print "foo" in the +output regardless of the outcome of the installation. + +Closes #1234 +``` + +Звичайні типи комітів: + +- fix: Виправити проблему або помилку +- feat: Додати нову функцію +- docs: Змінити документацію +- test: Покращити тестування +- ref: рефакторинг поточного коду + +Звичайні області: + +- helm: CLI Helm +- pkg/lint: Пакет lint. Дотримуйтеся аналогічної конвенції для будь-якого пакету +- `*`: дві або більше областей + +Дізнатись більше: + +- [Deis Guidelines](https://github.com/deis/workflow/blob/master/src/contributing/submitting-a-pull-request.md) були натхненням для цього розділу. +- Karma Runner [визначає](https://karma-runner.github.io/0.13/dev/git-commit-msg.html) ідею семантичного повідомлення коміту. + +### Домовленості Go {#go-conventions} + +Ми дуже уважно дотримуємося стандартів стилю кодування Go. Зазвичай запуск `go fmt` зробить ваш код красивим для вас. + +Ми також зазвичай дотримуємося конвенцій, рекомендованих `go lint` і `gometalinter`. Запустіть `make test-style`, щоб перевірити відповідність стилю. + +Дізнатись більше: + +- Effective Go [представляє форматування](https://golang.org/doc/effective_go.html#formatting). +- Wiki Go має чудову статтю про [форматування](https://github.com/golang/go/wiki/CodeReviewComments). + +Якщо ви запускаєте `make test`, будуть виконані не тільки юніт-тести, а й тести стилю. Якщо `make test` не пройде, навіть з причин стилю, ваш PR не буде вважатися готовим до злиття. diff --git a/content/uk/docs/community/history.md b/content/uk/docs/community/history.md new file mode 100644 index 000000000..c8642b71a --- /dev/null +++ b/content/uk/docs/community/history.md @@ -0,0 +1,20 @@ +--- + +title: "Історія Проєкту" +description: "Надає загальний огляд історії проєкту." +weight: 4 +--- + +Helm є [дипломованим](https://helm.sh/blog/celebrating-helms-cncf-graduation/) [проєктом CNCF](https://www.cncf.io/projects/). + +Helm почався як те, що тепер відоме як [Helm Classic](https://github.com/helm/helm-classic), проєкт Deis, розпочатий у 2015 році та представлений на перших KubeCon. + +У січні 2016 року проєкт обʼєднався з інструментом GCS під назвою Kubernetes Deployment Manager, і проєкт було переведено під [Kubernetes](https://kubernetes.io). В результаті злиття кодових баз, Helm 2.0 був випущений пізніше того ж року. Ключова особливість Deployment Manager, яка збереглася в Helm 2, — це серверна компонента, перейменована з DM на Tiller для фінального релізу Helm 2.0. + +Helm був піднятий з підпроєкту Kubernetes до повноцінного проєкту CNCF у червні 2018 року. Helm сформував орган управління на вищому рівні, і кілька проєктів були інтегровані під парасолею проєкту Helm, включаючи Monocular, Helm Chart Repo, Chart Museum і пізніше Helm Hub. + +Коли розпочався цикл розробки Helm 3, Tiller було видалено, що наблизило Helm до його первісного бачення як клієнтського інструменту. Але Helm 3 продовжує відслідковувати релізи всередині кластеру Kubernetes, що дозволяє командам працювати разом над спільним набором релізів Helm. Helm 3 був випущений у листопаді 2019 року. + +Helm [випустився як проєкт CNCF у квітні 2020 року](https://www.cncf.io/announcement/2020/04/30/cloud-native-computing-foundation-announces-helm-graduation/). + +[CNCF Artifact Hub](https://artifacthub.io) замінив [Helm Hub](https://hub.helm.sh) у жовтні 2020 року. diff --git a/content/uk/docs/community/localization.md b/content/uk/docs/community/localization.md new file mode 100644 index 000000000..a9e571b1b --- /dev/null +++ b/content/uk/docs/community/localization.md @@ -0,0 +1,110 @@ +--- +title: "Локалізація документації Helm" +description: "Інструкції для локалізації документації Helm." +weight: 5 +--- + +Цей посібник пояснює, як локалізувати документацію Helm. + +## Початок роботи {#getting-started} + +Внесення змін у переклади використовує той самий процес, що й внесення змін у документацію. Переклади подаються через [пул-реквести](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests) до репозиторію [helm-www](https://github.com/helm/helm-www), і пул-реквести перевіряються командою, яка управляє вебсайтом. + +### Дволітерний код мови {#two-letter-language-code} + +Документація організована відповідно до стандарту [ISO 639-1](https://www.loc.gov/standards/iso639-2/php/code_list.php) для мовних кодів. Наприклад, дволітерний код для корейської мови — `ko`, української — `uk`. + +У контенті та конфігураціях ви знайдете використовувані мовні коди. Ось 3 приклади: + +- У теці `content` мовні коди використовуються як підтеки, і локалізований контент для кожної мови знаходиться в кожній теці, переважно в підтеці `docs` кожної теки мовного коду. +- Тека `i18n` містить конфігураційний файл для кожної мови з фразами, що використовуються на вебсайті. Файли називаються за шаблоном `[LANG].toml`, де `[LANG]` — це дволітерний код мови. +- У конфігураційному файлі верхнього рівня `config.toml` є конфігурація для навігації та інших деталей, організованих за мовним кодом. + +Англійська мова, з мовним кодом `en`, є стандартною мовою та джерелом для перекладів. + +### Форк, Гілка, Зміна, Пул-Реквест {#fork-branch-change-pull-request} + +Щоб зробити переклад, почніть зі [створення форку](https://help.github.com/en/github/getting-started-with-github/fork-a-repo) репозиторію [helm-www](https://github.com/helm/helm-www) на GitHub. Ви почнете з внесення змін у вашому форку. + +Стандартно ваш форк буде налаштовано на роботу з основною гілкою, відомою як `main`. Будь ласка, використовуйте гілки для розробки ваших змін та створення пул-реквестів. Якщо ви не знайомі з гілками, ви можете [прочитати про них у документації GitHub](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-branches). + +Коли у вас зʼявиться гілка, внесіть зміни для додавання перекладів та локалізації контенту потрібною мовою. + +Зверніть увагу, що Helm використовує [Developers Certificate of Origin](https://developercertificate.org/). Всі коміти повинні мати підпис. При виконанні коміту ви можете використовувати прапорець `-s` або `--signoff`, щоб використовувати ваше налаштоване імʼя та адресу електронної пошти для підпису коміту. Більше деталей можна знайти у файлі [CONTRIBUTING.md](https://github.com/helm/helm-www/blob/main/CONTRIBUTING.md#sign-your-work). + +Коли ви будете готові, створіть [пул-реквест](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests) з перекладом назад до репозиторію helm-www. + +Після створення пул-реквесту один з підтримувачів перевірить його. Деталі цього процесу можна знайти у файлі [CONTRIBUTING.md](https://github.com/helm/helm-www/blob/main/CONTRIBUTING.md). + +## Переклад Контенту {#translating-content} + +Локалізація всього контенту Helm є великою задачею. Добре почати з малого. Переклади можуть розширюватися з часом. + +### Переклади новою мовою {#starting-a-new-language} + +Коли ви починаєте переклад новою мовою, є необхідний мінімум. Він включає: + +- Додавання теки `content/[LANG]/docs`, що містить файл `_index.md`. Це головна сторінка документації для мови. +- Створення файлу `[LANG].toml` в теці `i18n`. Спочатку ви можете скопіювати файл `en.toml` як відправну точку. +- Додавання розділу для мови до файлу `config.toml`, щоб відкрити новий мовний розділ. Наявні мовні розділи можуть слугувати відправною точкою. + +### Переклад {#translation} + +Перекладений контент має знаходитися в теці `content/[LANG]/docs`. Він повинен мати ту ж URL-адресу, що й англійське джерело. Наприклад, для перекладу вступу на корейську мову може бути корисно скопіювати англійське джерело як: + +```sh +mkdir -p content/ko/docs/intro +cp content/en/docs/intro/install.md content/ko/docs/intro/install.md +``` + +Контент у новому файлі може бути перекладено іншою мовою. + +Не додавайте неперекладену копію англійського файлу в `content/[LANG]/`. Як тільки мова існує на сайті, будь-які неперекладені сторінки автоматично перенаправлятимуться на англійську версію. Переклад займає час, і ви завжди хочете перекладати найактуальнішу версію документації, а не застарілу версію. + +Переконайтеся, що ви видалили будь-які рядки `aliases` з розділу заголовка. Рядка на зразок `aliases: ["/docs/using_helm/"]` не має бути в перекладах. Це перенаправлення для старих посилань, які не існують для нових сторінок. + +Зверніть увагу, що інструменти для перекладу можуть допомогти в процесі. Це включає автоматично згенеровані переклади. Автоматично згенеровані переклади повинні бути переглянути та перевірені носієм мови перед публікацією. + +## Навігація між мовами {#navigation-between-languages} + +![Скріншот 2020-05-11 о 11 24 22 +AM](https://user-images.githubusercontent.com/686194/81597103-035de600-937a-11ea-9834-cd9dcef4e914.png) + +Глобальний файл [config.toml](https://github.com/helm/helm-www/blob/main/config.toml#L83L89) є місцем, де налаштована навігація між мовами. + +Щоб додати нову мову, додайте новий набір параметрів, використовуючи [дволітерний мовний код](./localization/#two-letter-language-code), визначений вище. Приклад: + +```toml +# Korean +[languages.ko] +title = "Helm" +description = "Helm - The Kubernetes Package Manager." +contentDir = "content/ko" +languageName = "한국어 Korean" +weight = 1 +``` + +## Розвʼязання внутрішніх посилань {#resolving-internal-links} + +Перекладений контент іноді міститиме посилання на сторінки, які існують тільки в іншій мові. Це призведе до [помилок збірки сайту](https://app.netlify.com/sites/helm-merge/deploys). Приклад: + +``` +12:45:31 PM: htmltest started at 12:45:30 on app +12:45:31 PM: ======================================================================== +12:45:31 PM: ko/docs/chart_template_guide/accessing_files/index.html +12:45:31 PM: hash does not exist --- ko/docs/chart_template_guide/accessing_files/index.html --> #basic-example +12:45:31 PM: ✘✘✘ failed in 197.566561ms +12:45:31 PM: 1 error in 212 documents +``` + +Щоб вирішити це, потрібно перевірити ваш контент на наявність внутрішніх посилань. + +- посилання-якоря повинні відображати перекладене значення `id` +- внутрішні посилання на сторінки потрібно виправити + +Для внутрішніх сторінок, які не існують _(або ще не були перекладені)_, сайт не збереться до тих пір, поки не буде внесено виправлення. Як альтернативний варіант, URL може вказувати на іншу мову, де цей контент _існує_, наступним чином: + +`< relref path="/docs/topics/library_charts.md" lang="en" >` + +Дивіться [документацію Hugo про перехресні посилання між +мовами](https://gohugo.io/content-management/cross-references/#link-to-another-language-version) для докладнішої інформації. diff --git a/content/uk/docs/community/related.md b/content/uk/docs/community/related.md new file mode 100644 index 000000000..a772940e2 --- /dev/null +++ b/content/uk/docs/community/related.md @@ -0,0 +1,76 @@ +--- +title: "Повʼязані проекти та документація" +description: "сторонні інструменти, втулки та документація, надані спільнотою!" +weight: 3 +--- + +Спільнота Helm розробила безліч додаткових інструментів, втулків та документації про Helm. Нам завжди цікаво дізнатися про ці проєкти. + +Якщо у вас є щось, що ви хочете додати до цього списку, будь ласка, відкрийте [issue](https://github.com/helm/helm-www/issues) або [pull request](https://github.com/helm/helm-www/pulls). + +## Втулки Helm {#helm-plugins} + +- [helm-adopt](https://github.com/HamzaZo/helm-adopt) — Втулок Helm v3 для включення поточних ресурсів k8s у нові згенеровані Helm чарти. +- [helm-chartsnap](https://github.com/jlandowner/helm-chartsnap) — Втулок для тестування знімків для Helm чартів. +- [Helm Diff](https://github.com/databus23/helm-diff) — Попередній перегляд `helm upgrade` у вигляді кольорового diff. +- [Helm Dt](https://github.com/vmware-labs/distribution-tooling-for-helm) — Втулок, який допомагає розподілити Helm чарти між OCI реєстрами та в умовах Air gap. +- [Helm Dashboard](https://github.com/komodorio/helm-dashboard) — GUI для Helm, візуалізація релізів та репозиторіїв, відмінності у маніфестах. +- [helm-gcs](https://github.com/hayorov/helm-gcs) — Втулок для керування репозиторіями на Google Cloud Storage. +- [helm-git](https://github.com/aslafy-z/helm-git) — Встановлює чарти та отримує файли значень з ваших Git репозиторіїв. +- [helm-k8comp](https://github.com/cststack/k8comp) — Втулок для створення Helm чартів з hiera за допомогою k8comp. +- [helm-mapkubeapis](https://github.com/helm/helm-mapkubeapis) — Оновлює метадані релізу Helm для заміни застарілих або видалених API Kubernetes. +- [helm-monitor](https://github.com/ContainerSolutions/helm-monitor) — Втулок для моніторингу релізу та відкату на основі запиту Prometheus/ElasticSearch. +- [helm-release-plugin](https://github.com/JovianX/helm-release-plugin) — Втулок для управління релізами, оновлення значень релізу, витягує (перестворює) Helm чарти з розгорнутих релізів, встановлює TTL релізу Helm. +- [helm-s3](https://github.com/hypnoglow/helm-s3) — Втулок Helm, який дозволяє використовувати AWS S3 як [приватний] репозиторій чартів. +- [helm-schema-gen](https://github.com/karuppiah7890/helm-schema-gen) — Втулок Helm, який генерує схему yaml значень для ваших Helm 3 чартів. +- [helm-secrets](https://github.com/jkroepke/helm-secrets) — Втулок для безпечного керування та зберігання секретів (на основі [sops](https://github.com/mozilla/sops)). +- [helm-sigstore](https://github.com/sigstore/helm-sigstore) — Втулок для Helm для інтеграції з екосистемою [sigstore](https://sigstore.dev/). Пошук, завантаження та перевірка підписаних Helm чартів. +- [helm-tanka](https://github.com/Duologic/helm-tanka) — Втулок Helm для рендерингу Tanka/Jsonnet всередині Helm чартів. +- [hc-unit](https://github.com/xchapter7x/hcunit) — Втулок для юніт-тестування чартів локально за допомогою OPA (Open Policy Agent) & Rego. +- [helm-unittest](https://github.com/quintush/helm-unittest) — Втулок для юніт-тестування чартів локально з YAML. +- [helm-val](https://github.com/HamzaZo/helm-val) — Втулок для отримання значень з попереднього релізу. +- [helm-external-val](https://github.com/kuuji/helm-external-val) — Втулок, який отримує значення helm з зовнішніх джерел (configMaps, Secrets тощо). +- [helm-images](https://github.com/nikhilsbhat/helm-images) — Втулок Helm для отримання всіх можливих зображень з чарту перед розгортанням або з розгорнутого релізу. +- [helm-drift](https://github.com/nikhilsbhat/helm-drift) — Втулок Helm, який виявляє конфігурацію, яка відрізняється від Helm чарту. + +Ми також заохочуємо авторів на GitHub використовувати теґ [helm-plugin](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories) у своїх репозиторіях втулків. + +## Додаткові інструменти {#additional-tools} + +Інструменти, які використовуються поверх Helm. + +- [Armada](https://airshipit.readthedocs.io/projects/armada/en/latest/) — Керування префіксованими релізами через різні Kubernetes простори імен, а також видалення завершених завдань для складних розгортань. +- [avionix](https://github.com/zbrookle/avionix) — Інтерфейс Python для генерації Helm чартів та Kubernetes yaml, що дозволяє успадкування та зменшення дублювання коду. +- [Botkube](https://botkube.io) — Виконання Helm команд безпосередньо з Slack, Discord, Microsoft Teams та Mattermost. +- [Captain](https://github.com/alauda/captain) — Контролер Helm3, що використовує HelmRequest та Release CRD. +- [Chartify](https://github.com/appscode/chartify) — Генерація Helm чартів з наявних ресурсів Kubernetes. +- [ChartMuseum](https://github.com/helm/chartmuseum) — Репозиторій Helm Chart з підтримкою Amazon S3 та Google Cloud Storage. +- [chart-registry](https://github.com/hangyan/chart-registry) — Хостинг Helm чартів на OCI Registry. +- [Codefresh](https://codefresh.io) — Кластерна CI/CD платформа з UI панелями для управління Helm чартами та релізами. +- ⁠[Cyclops](https://cyclops-ui.com) — Динамічний UI для Kubernetes на основі Helm чартів. +- [Flux](https://fluxcd.io/docs/components/helm/) — Безперервна та прогресивна доставка з Git до Kubernetes. +- [Helmfile](https://github.com/helmfile/helmfile) — Helmfile - це декларативна специфікація для розгортання Helm чартів. +- [Helmper](https://github.com/ChristofferNissen/helmper) — Helmper допомагає імплементувати Helm чарти, включаючи всі OCI артефакти (образи) у ваші OCI реєстри. Helmper також полегшує сканування безпеки та застосування патчів до OCI образів. Helmper використовує Helm, Oras, Trivy, Copacetic та Buildkitd. +- [Helmsman](https://github.com/Praqma/helmsman) — Helmsman, це інструмент helm-charts-as-code, який дозволяє встановлювати/оновлювати/захищати/переміщувати/видаляти релізи з версійно контрольованих файлів стану (описаних у простому форматі TOML). +- [HULL](https://github.com/vidispine/hull) — Ця бібліотека чартів надає готовий інтерфейс для специфікації всіх обʼєктів Kubernetes безпосередньо у `values.yaml`. Вона усуває необхідність писати будь-які шаблони для ваших чартів і має багато додаткових функцій для спрощення створення та використання Helm чартів. +- [Konveyor Move2Kube](https://konveyor.io/move2kube/) — Генерація Helm чартів для ваших поточних проєктів. +- [Landscaper](https://github.com/Eneco/landscaper/) — "Landscaper бере набір посилань на Helm Chart зі значеннями (бажаний стан) і реалізує їх в кластері Kubernetes." +- [Monocular](https://github.com/helm/monocular) — Веб UI для репозиторіїв Helm Chart. +- [Monokle](https://monokle.io) — Десктопний інструмент для створення, налагодження та розгортання ресурсів Kubernetes та Helm чартів. +- [Orkestra](https://azure.github.io/orkestra/) — Хмарна платформа оркестрування релізів та управління життєвим циклом (LCM) для повʼязаних груп Helm релізів та їх субчартів. +- [Tanka](https://tanka.dev/helm) — Grafana Tanka налаштовує ресурси Kubernetes через Jsonnet з можливістю споживання Helm чартів. +- [Terraform Helm Provider](https://github.com/hashicorp/terraform-provider-helm) — Провайдер Helm для HashiCorp Terraform дозволяє управління життєвим циклом Helm чартів з декларативним синтаксисом інфраструктури як коду. Провайдер Helm часто поєднується з іншими провайдерами Terraform, такими як провайдер Kubernetes, для створення спільного робочого процесу серед усіх інфраструктурних послуг. +- [VIM-Kubernetes](https://github.com/andrewstuart/vim-kubernetes) — Втулок VIM для Kubernetes та Helm. + +## Мають Helm {#helm-included} + +Платформи, дистрибутиви та сервіси, що включають підтримку Helm. + +- [Kubernetic](https://kubernetic.com/) — Десктопний клієнт Kubernetes. +- [Jenkins X](https://jenkins-x.io/) — Відкритий автоматизований CI/CD для Kubernetes, який використовує Helm для [просування](https://jenkins-x.io/docs/getting-started/promotion/) застосунків через середовища за допомогою GitOps. + +## Різне {#misc} + +Корисні речі для авторів чартів та користувачів Helm. + +- [Await](https://github.com/saltside/await) — Docker образ для "очікування" різних умов, особливо корисний для init контейнерів. [Детальніше](https://blog.slashdeploy.com/2017/02/16/introducing-await/). diff --git a/content/uk/docs/community/release_checklist.md b/content/uk/docs/community/release_checklist.md new file mode 100644 index 000000000..6eaf1106c --- /dev/null +++ b/content/uk/docs/community/release_checklist.md @@ -0,0 +1,378 @@ +--- +title: "Перевірка випуску" +description: "Чеклист для супровідників при випуску нової версії Helm." +weight: 2 +--- + +# Посібник для супровідників щодо випуску Helm + +Час для нового випуску Helm! Як супровідник Helm, який випускає нову версію, ви є найкращою людиною, щоб [оновити цей чеклист випуску](https://github.com/helm/helm-www/blob/main/content/en/docs/community/release_checklist.md) у разі, якщо ваш досвід відрізняється від задокументованого тут. + +Усі випуски будуть мати формат vX.Y.Z, де X — це основний номер версії, Y — це номер мінорної версії, а Z — це номер патч-релізу. Цей проєкт суворо дотримується [семантичного версіювання](https://semver.org/), тому дотримання цього етапу є критично важливим. + +Helm заздалегідь оголошує дату свого наступного мінорного випуску. Кожне зусилля має бути спрямоване на дотримання оголошеної дати. Крім того, під час запуску процесу випуску дату наступного випуску має бути обрано, оскільки вона буде використана в процесі випуску. + +Ці інструкції охоплюють початкову конфігурацію, а потім процес випуску для трьох різних типів випусків: + +* Основні випуски — випускаються рідше, мають критичні зміни +* Мінорні випуски — випускаються кожні 3-4 місяці, не мають критичних змін +* Патч-релізи — випускаються щомісяця, не потребують виконання всіх кроків цього посібника + +[Початкова конфігурація](#initial-configuration) + +1. [Створення гілки випуску](#1-create-the-release-branch) +2. [Основні/Мінорні випуски: змініть номер версії в Git](#2-majorminor-releases-change-the-version-number-in-git) +3. [Основні/Мінорні випуски: зафіксуйте і надішліть гілку випуску](#3-majorminor-releases-commit-and-push-the-release-branch) +4. [Основні/Мінорні випуски: створіть кандидат у випуск](#4-majorminor-releases-create-a-release-candidate) +5. [Основні/Мінорні випуски: повторіть на наступних кандидатах у випуск](#5-majorminor-releases-iterate-on-successive-release-candidates) +6. [Завершення випуску](#6-finalize-the-release) +7. [Написання приміток до випуску](#7-write-the-release-notes) +8. [PGP-підписання завантажень](#8-pgp-sign-the-downloads) +9. [Публікація випуску](#9-publish-release) +10. [Оновлення документації](#10-update-docs) +11. [Оповіщення спільноти](#11-tell-the-community) + +## Початкова конфігурація {#initial-configuration} + +### Налаштування віддаленого репозиторію Git {#set-up-git-remote} + +Важливо зазначити, що цей документ передбачає, що віддалений репозиторій у вашій копії, який відповідає , називається "upstream". Якщо це не так (наприклад, якщо ви вирішили назвати його "origin" або щось подібне), обовʼязково змініть наведену інформацію відповідно до вашого локального середовища. Якщо ви не впевнені, як називається ваш upstream, використовуйте команду `git remote -v`, щоб дізнатися. + +Якщо у вас немає [upstream remote](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/configuring-a-remote-for-a-fork), ви можете додати його, використовуючи таку команду: + +```shell +git remote add upstream git@github.com:helm/helm.git +``` + +### Налаштування змінних середовища {#set-up-environment-variables} + +У цьому документі також буде використано кілька змінних середовища, які ви можете налаштувати для зручності. Для основних/мінорних випусків використовуйте наступне: + +```shell +export RELEASE_NAME=vX.Y.0 +export RELEASE_BRANCH_NAME="release-X.Y" +export RELEASE_CANDIDATE_NAME="$RELEASE_NAME-rc.1" +``` + +Якщо ви створюєте патч-реліз, використовуйте наступне: + +```shell +export PREVIOUS_PATCH_RELEASE=vX.Y.Z +export RELEASE_NAME=vX.Y.Z+1 +export RELEASE_BRANCH_NAME="release-X.Y" +``` + +### Налаштування ключа підпису {#set-up-signing-key} + +Ми також додамо безпеку та перевірку процесу випуску шляхом хешування бінарних файлів і надання файлів підпису. Ми виконуємо це, використовуючи [GitHub та GPG](https://help.github.com/en/articles/about-commit-signature-verification). Якщо у вас ще не налаштовано GPG, ви можете виконати такі кроки: + +1. [Встановіть GPG](https://gnupg.org/index.html) +2. [Згенеруйте GPG ключ](https://help.github.com/en/articles/generating-a-new-gpg-key) +3. [Додайте ключ до облікового запису GitHub](https://help.github.com/en/articles/adding-a-new-gpg-key-to-your-github-account) +4. [Налаштуйте ключ підпису в Git](https://help.github.com/en/articles/telling-git-about-your-signing-key) + +Після того, як у вас буде ключ підпису, вам потрібно додати його до файлу KEYS у кореневій теці репозиторію. Інструкції щодо додавання його до файлу KEYS містяться у файлі. Якщо ви ще не зробили цього, вам потрібно додати ваш публічний ключ до мережі keyserver. Якщо ви використовуєте GnuPG, ви можете дотримуватися [інструкцій, наданих Debian](https://debian-administration.org/article/451/Submitting_your_GPG_key_to_a_keyserver). + +## 1. Створення гілки випуску {#1-create-the-release-branch} + +### Основні/Мінорні випуски {#majorminor-releases} + +Основні випуски включають нові функції та зміни в поведінці, *які порушують зворотну сумісність*. Мінорні випуски містять нові функції, які не порушують зворотну сумісність. Для створення основного або мінорного випуску почніть зі створення гілки `release-X.Y` від основної гілки (main). + +```shell +git fetch upstream +git checkout upstream/main +git checkout -b $RELEASE_BRANCH_NAME +``` + +Ця нова гілка буде основою для випуску, в якій ми будемо надалі працювати. + +Переконайтеся, що на GitHub існує [віха в helm/helm](https://github.com/helm/helm/milestones) для цього випуску (створіть її, за потреби). Переконайтеся, що PR та issues для цього випуску входять до цього етапу. + +Для основних і мінорних випусків переходьте до кроку 2: [Основні/Мінорні випуски: зміна номеру версії в Git](#2-majorminor-releases-change-the-version-number-in-git). + +### Патч-релізи {#patch-releases} + +Патч-релізи включають кілька критичних виправлень для поточних випусків. Почніть зі створення гілки `release-X.Y`: + +```shell +git fetch upstream +git checkout -b $RELEASE_BRANCH_NAME upstream/$RELEASE_BRANCH_NAME +``` + +Звідси ми можемо вибрати коміти, які хочемо включити до патч-релізу: + +```shell +# отримуємо ідентифікатори комітів, які хочемо вибрати +git log --oneline +# вибираємо коміти, починаючи з найстарішого, без включення комітів злиття +git cherry-pick -x +``` + +Після вибору комітів гілку випуску потрібно надіслати у віддалений репозиторій. + +```shell +git push upstream $RELEASE_BRANCH_NAME +``` + +Надсилання гілки викличе запуск тестів. Переконайтеся, що вони проходять перед створенням теґу. Цей новий теґ стане основою для патч-релізу. + +Створення [віхи в helm/helm](https://github.com/helm/helm/milestones) є необов’язковим для патч-релізів. + +Обов’язково перевірте [helm на CircleCI](https://circleci.com/gh/helm/helm), щоб переконатися, що випуск пройшов CI, перш ніж продовжити. Патч-релізи можуть пропустити кроки 2-5 і перейти до кроку 6 для [Завершення випуску](#6-finalize-the-release). + +## 2. Основні/Мінорні випуски: Зміна номера версії в Git {#2-majorminor-releases-change-the-version-number-in-git} + +При виконанні основного або мінорного випуску переконайтеся, що оновили файл `internal/version/version.go` з новою версією випуску. + +```shell +$ git diff internal/version/version.go +diff --git a/internal/version/version.go b/internal/version/version.go +index 712aae64..c1ed191e 100644 +--- a/internal/version/version.go ++++ b/internal/version/version.go +@@ -30,7 +30,7 @@ var ( + // Збільшіть основний номер для додавання нових функцій та змін в поведінці. + // Збільшіть мінорний номер для виправлення помилок та підвищення продуктивності. + // Збільшіть номер патча для критичних виправлень в поточних версіях. +- version = "v3.3" ++ version = "v3.4" + + // metadata — це додаткові дані часу побудови + metadata = "" +``` + +Окрім оновлення версії у файлі `version.go`, вам також потрібно оновити відповідні тести, що використовують цей номер версії. + +* `cmd/helm/testdata/output/version.txt` +* `cmd/helm/testdata/output/version-client.txt` +* `cmd/helm/testdata/output/version-client-shorthand.txt` +* `cmd/helm/testdata/output/version-short.txt` +* `cmd/helm/testdata/output/version-template.txt` +* `pkg/chartutil/capabilities_test.go` + +```shell +git add . +git commit -m "bump version to $RELEASE_NAME" +``` + +Це оновить версію лише для гілки $RELEASE_BRANCH_NAME. Вам також потрібно буде інтегрувати ці зміни в основну гілку, щоб підготувати її до наступного випуску, як у [цьому прикладі з 3.2 до 3.3](https://github.com/helm/helm/pull/8411/files), та додати його до віхи наступного випуску. + +```shell +# отримуємо ідентифікатор останнього коміта, тобто коміт для підвищення версії +git log --format="%H" -n 1 + +# створюємо нову гілку від основної гілки +git checkout main +git checkout -b bump-version- + +# вибираємо коміт за допомогою ідентифікатора з першої команди +git cherry-pick -x + +# комітимо зміни +git push origin bump-version- +``` + +## 3. Основні/Мінорні випуски: Коміт та збереження гілки релізу {#3-majorminor-releases-commit-and-push-the-release-branch} + +Щоб інші могли почати тестування, тепер можна надіслати гілку релізу в upstream і розпочати процес тестування. + +```shell +git push upstream $RELEASE_BRANCH_NAME +``` + +Переконайтеся, що перевірили [Helm на CircleCI](https://circleci.com/gh/helm/helm), щоб побачити, що реліз пройшов CI перед тим, як продовжити. + +Якщо є можливість, дайте іншим перевірити гілку, перш ніж продовжувати, щоб переконатися, що всі необхідні зміни внесені та всі коміти для релізу присутні. + +## 4. Основні/Мінорні випуски: Створення реліз-кандидата {#4-majorminor-releases-create-a-release-candidate} + +Тепер, коли гілку релізу створено та підготовлено, настав час почати створення та ітерацію реліз-кандидатів. + +```shell +git tag --sign --annotate "${RELEASE_CANDIDATE_NAME}" --message "Helm release ${RELEASE_CANDIDATE_NAME}" +git push upstream $RELEASE_CANDIDATE_NAME +``` + +CircleCI автоматично створить образ з теґом релізу та клієнтський бінарний файл для тестування. + +Для тестувальників процес початку тестування після завершення побудови артефактів CircleCI включає наступні кроки для отримання клієнта: + +Linux/amd64, використовуючи /bin/bash: + +```shell +wget https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-linux-amd64.tar.gz +``` + +Darwin/amd64, використовуючи Terminal.app: + +```shell +wget https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-darwin-amd64.tar.gz +``` + +Windows/amd64, використовуючи PowerShell: + +```shell +PS C:\> Invoke-WebRequest -Uri "https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-windows-amd64.tar.gz" -OutFile "helm-$ReleaseCandidateName-windows-amd64.tar.gz" +``` + +Потім розпакуйте та перемістіть бінарний файл в теку, що знаходиться в $PATH, або перемістіть його в інше місце та додайте його до $PATH (наприклад, /usr/local/bin/helm для Linux/macOS, C:\Program Files\helm\helm.exe для Windows). + +## 5. Основні/Мінорні випуски: Ітерація на наступних реліз-кандидатах {#5-majorminor-releases-iterate-on-successive-release-candidates} + +Протягом кількох днів активно інвестуйте час та ресурси, щоб спробувати виявити будь-які проблеми з Helm, документуючи всі важливі висновки для релізу. Цей час слід витратити на тестування та пошук способів, у яких реліз міг би викликати проблеми з різними функціями або середовищами оновлення, а не на написання коду. У цей період реліз перебуває в стані заморожування коду, і будь-які додаткові зміни коду будуть перенесені на наступний реліз. + +Протягом цієї фази гілка $RELEASE_BRANCH_NAME буде продовжувати розвиватися, оскільки ви будете створювати нові реліз-кандидати. Частота появи нових кандидатів залежить від менеджера релізу: використовуйте здоровий глузд, враховуючи серйозність виявлених проблем, доступність тестувальників та дату завершення релізу. Загалом, краще перенести реліз на пізніший термін, ніж випустити зламаний реліз. + +Кожен раз, коли ви хочете створити нового реліз-кандидата, починайте з додавання комітів до гілки, використовуючи cherry-pick з main: + +```shell +git cherry-pick -x +``` + +Також не забудьте надіслати гілку на GitHub та переконатися, що вона пройшла CI. + +Після цього додайте теґ та повідомте користувачів про нового реліз-кандидата: + +```shell +export RELEASE_CANDIDATE_NAME="$RELEASE_NAME-rc.2" +git tag --sign --annotate "${RELEASE_CANDIDATE_NAME}" --message "Helm release ${RELEASE_CANDIDATE_NAME}" +git push upstream $RELEASE_CANDIDATE_NAME +``` + +Після того як теґ надіслано на GitHub, перевірте, чи успішно збирається гілка з цим тегом в CI. + +Далі просто повторюйте цей процес, постійно тестуючи, поки не будете задоволені реліз-кандидатом. Для реліз-кандидата повноцінні нотатки до релізу ще не пишуться, але можна підготувати [чернетку реліз-нотаток](#7-write-the-release-notes). + +## 6. Завершення релізу {#6-finalize-the-release} + +Коли ви нарешті задоволені якістю реліз-кандидата, можна переходити до створення остаточного релізу. Перевірте ще раз, чи все в порядку, а потім надішліть теґ релізу. + +```shell +git checkout $RELEASE_BRANCH_NAME +git tag --sign --annotate "${RELEASE_NAME}" --message "Helm release ${RELEASE_NAME}" +git push upstream $RELEASE_NAME +``` + +Переконайтеся, що реліз успішно пройшов на [CircleCI](https://circleci.com/gh/helm/helm). Якщо ні, вам доведеться виправити помилки та знову надіслати реліз. + +Оскільки CI-завдання займе деякий час для виконання, ви можете перейти до написання реліз-нотаток, поки процес триває. + +## 7. Написання реліз-нотаток {#7-write-the-release-notes} + +Ми автоматично створимо лог змін на основі комітів, які відбулися протягом циклу випуску, але для кінцевого користувача зазвичай корисніше, якщо реліз-нотатки будуть написані вручну людиною або командою маркетингу. + +Якщо ви випускаєте мажорний або мінорний реліз, достатньо перерахувати помітні зміни, що впливають на користувачів. Для патч-релізів зробіть те саме, але також зазначте симптоми та на кого вони впливають. + +Реліз-нотатки повинні містити версію та заплановану дату наступного релізу. + +Приклад реліз-нотаток для мінорного релізу (переклад дано для наочності): + +```markdown +## vX.Y.Z + +Helm vX.Y.Z — це реліз з новими функціями. Цього разу ми зосередилися на <вставте ключову тезу>. Користувачам рекомендується оновитися щоб мати найкращий досвід. + +Спільнота продовжує зростати, і ми були б раді бачити вас серед нас! + +- Приєднуйтеся до обговорення в [Kubernetes Slack](https://kubernetes.slack.com): + - `#helm-users` для запитань і просто для спілкування + - `#helm-dev` для обговорення PR, коду та багів +- Відвідайте публічну зустріч розробників: щочетверга, 9:30 за тихоокеанським часом в [Zoom](https://zoom.us/j/696660622) +- Тестуйте, налагоджуйте та робіть свій внесок у чарти: [Artifact Hub helm charts](https://artifacthub.io/packages/search?kind=0) + +## Важливі зміни + +- Додано підтримку Kubernetes 1.16, включаючи нові apiVersions для маніфестів. +- Оновлено Sprig до версії 2.22. + +## Встановлення та оновлення + +Завантажте Helm X.Y.Z. Бінарні файли для загальних платформ тут: + +- [MacOS amd64](https://get.helm.sh/helm-vX.Y.Z-darwin-amd64.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-darwin-amd64.tar.gz.sha256sum) / CHECKSUM_VAL) +- [Linux amd64](https://get.helm.sh/helm-vX.Y.Z-linux-amd64.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-amd64.tar.gz.sha256sum) / CHECKSUM_VAL) +- [Linux arm](https://get.helm.sh/helm-vX.Y.Z-linux-arm.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-arm.tar.gz.sha256) / CHECKSUM_VAL) +- [Linux arm64](https://get.helm.sh/helm-vX.Y.Z-linux-arm64.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-arm64.tar.gz.sha256sum) / CHECKSUM_VAL) +- [Linux i386](https://get.helm.sh/helm-vX.Y.Z-linux-386.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-386.tar.gz.sha256) / CHECKSUM_VAL) +- [Linux ppc64le](https://get.helm.sh/helm-vX.Y.Z-linux-ppc64le.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-ppc64le.tar.gz.sha256sum) / CHECKSUM_VAL) +- [Linux s390x](https://get.helm.sh/helm-vX.Y.Z-linux-s390x.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-s390x.tar.gz.sha256sum) / CHECKSUM_VAL) +- [Windows amd64](https://get.helm.sh/helm-vX.Y.Z-windows-amd64.zip) ([checksum](https://get.helm.sh/helm-vX.Y.Z-windows-amd64.zip.sha256sum) / CHECKSUM_VAL) + +[Короткий посібник з налаштування](https://docs.helm.sh/using_helm/#quickstart-guide) допоможе вам розпочати роботу. Для інструкцій з оновлення або детальних нотаток з встановлення перегляньте [посібник з встановлення](https://docs.helm.sh/using_helm/#installing-helm). Ви також можете використовувати [скрипт для встановлення](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3) на будь-якій системі з `bash`. + +## Що далі + +- vX.Y.Z+1 міститиме лише виправлення багів і планується на <вставте ДАТУ>. +- vX.Y+1.0 — це наступний реліз з новими функціями, який планується на <вставте ДАТУ>. Цей реліз буде зосереджений на ... + +## Лог змін + +- chore(*): bump version to v2.7.0 08c1144f5eb3e3b636d9775617287cc26e53dba4 (Adam Reese) +- fix circle not building tags f4f932fabd197f7e6d608c8672b33a483b4b76fa (Matthew Fisher) +``` + +Частково заповнений набір реліз-нотаток, включаючи лог змін, можна створити за допомогою наступної команди: + +```shell +export VERSION="$RELEASE_NAME" +export PREVIOUS_RELEASE=vX.Y.Z +make clean +make fetch-dist +make release-notes +``` + +Це створить гарну базову версію реліз-нотаток, до яких вам потрібно буде лише додати розділи **Важливі зміни** та **Що далі**. + +Не соромтеся додавати свій стиль до реліз-нотаток; людям приємно думати, що ми не всі тут роботи. + +Ви також повинні переконатися, що URL-адреси та контрольні суми правильні в автоматично згенерованих реліз-нотатках. + +Після завершення перейдіть до [helm/helm releases](https://github.com/helm/helm/releases) на GitHub і відредагуйте реліз-нотатки для теґу релізу за допомогою написаних тут нотаток. Для цільової гілки встановіть $RELEASE_BRANCH_NAME. + +На цьому етапі варто залучити інших людей для перегляду реліз-нотаток перед публікацією релізу. Надішліть запит у [#helm-dev](https://kubernetes.slack.com/messages/C51E88VDG) для перегляду. Це завжди корисно, оскільки легко щось пропустити. + +## 8. PGP Підпис файлів для завантаження {#8-pgp-sign-the-downloads} + +Хоча хеші забезпечують підпис, що вміст завантажуваних файлів відповідає тому, що було згенеровано, підписані пакунки забезпечують простежуваність походження пакунка. + +Щоб це зробити, виконайте наступні команди `make`: + +```shell +export VERSION="$RELEASE_NAME" +make clean # якщо ще не виконано +make fetch-dist # якщо ще не виконано +make sign +``` + +Це створить файли підписів у форматі ascii armored для кожного з файлів, завантажених CI. + +Усі файли підписів (`*.asc`) необхідно завантажити до релізу на GitHub (додати до бінарних файлів). + +## 9. Оприлюднення релізу {#9-publish-release} + +Час зробити реліз офіційним! + +Після того, як реліз-нотатки збережено на GitHub, завершено збірку CI та додано файли підписів до релізу, можна натиснути "Publish" на сторінці релізу. Це опублікує реліз, позначивши його як "latest" (останній) та покаже його на головній сторінці репозиторію [helm/helm](https://github.com/helm/helm). + +## 10. Оновлення документації {#10-update-docs} + +Розділ документації на сайті [Helm](https://helm.sh/docs) містить версії Helm. Необхідно оновити на сайті версії для major, minor і patch. Також потрібно оновити дату наступного minor релізу. + +Щоб це зробити, створіть pull request в репозиторії [helm-www](https://github.com/helm/helm-www). У файлі `config.toml` знайдіть відповідний розділ `params.versions` та оновіть версію Helm, як у цьому прикладі [оновлення поточної версії](https://github.com/helm/helm-www/pull/676/files). У тому ж файлі `config.toml` оновіть розділ `params.nextversion`. + +Закрийте [milestone](https://github.com/helm/helm/milestones) для релізу, якщо це прийнятно. + +Оновіть [version skew](https://github.com/helm/helm-www/blob/main/content/en/docs/topics/version_skew.md) для major і minor релізів. + +Оновіть календар релізів [тут](https://helm.sh/calendar/release): +* створіть запис для наступного minor релізу з нагадуванням на цей день о 17:00 GMT +* створіть запис для RC1 наступного minor релізу в понеділок тижня перед запланованим релізом, з нагадуванням на цей день о 17:00 GMT + +## 11. Сповістіть спільноту {#11-tell-the-community} + +Вітаємо! Ви закінчили. Візьміть собі $DRINK_OF_CHOICE. Ви цього заслуговуєте. + +Після того, як насолодитеся своїм $DRINK_OF_CHOICE, повідомте про новий реліз у Slack та Twitter з посиланням на [реліз на GitHub](https://github.com/helm/helm/releases). + +Опційно, напишіть блог пост про новий реліз і покажіть деякі з нових функцій там! diff --git a/content/uk/docs/faq/_index.md b/content/uk/docs/faq/_index.md new file mode 100644 index 000000000..1d1e45593 --- /dev/null +++ b/content/uk/docs/faq/_index.md @@ -0,0 +1,10 @@ +--- +title: "Часті питання" +weight: 8 +--- + +# Часті питання + +> Цей розділ надає допомогу з найпоширенішими питаннями. + +**Ми будемо вдячні за вашу допомогу** у покращенні цього документу. Щоб додати, виправити або видалити інформацію, [створіть тікет](https://github.com/helm/helm-www/issues) або надішліть нам пул-реквест. diff --git a/content/uk/docs/faq/changes_since_helm2.md b/content/uk/docs/faq/changes_since_helm2.md new file mode 100644 index 000000000..480f1f835 --- /dev/null +++ b/content/uk/docs/faq/changes_since_helm2.md @@ -0,0 +1,278 @@ +--- +title: "Зміни з часів Helm 2" +weight: 1 +--- + +## Зміни з часів Helm 2 {#changes-since-helm-2} + +Ось вичерпний список усіх основних змін, введених у Helm 3. + +### Видалення Tiller {#removal-of-tiller} + +Під час циклу розробки Helm 2 ми впровадили Tiller. Tiller відігравав важливу роль для команд, що працюють на спільному кластері — він дозволяв кільком різним операторам взаємодіяти з одним і тим же набором релізів. + +З увімкненим контролем доступу на основі ролей (RBAC) у Kubernetes 1.6, контроль доступу до Tiller у випадках операційної діяльності став важчим у керуванні. Через велику кількість можливих політик безпеки наше ставлення полягало в тому, щоб забезпечити стандартну дозвільну конфігурацію. Це дозволяло новачкам почати експериментувати з Helm і Kubernetes без необхідності заглиблюватися в керування безпекою. На жаль, ця дозвільна конфігурація могла надавати користувачеві широкий спектр дозволів, які йому не були надані. DevOps і SRE доводилося вивчати додаткові оперативні кроки при встановленні Tiller в мультиорендний кластер. + +Після того як ми дізналися, як члени спільноти використовують Helm у певних сценаріях, ми виявили, що система управління релізами Tiller не має покладатися на оператора в кластері для підтримки стану або дії як центральний центр інформації про релізи Helm. Натомість ми могли просто отримувати інформацію з сервера API Kubernetes, рендерити чарти на стороні клієнта і зберігати запис про установку в Kubernetes. + +Основна мета Tiller могла бути досягнута без Tiller, тому одне з перших рішень, яке ми прийняли щодо Helm 3, полягало в повному видаленні Tiller. + +З відсутністю Tiller модель безпеки Helm радикально спростилася. Helm 3 тепер підтримує всі сучасні функції безпеки, ідентифікації та авторизації сучасного Kubernetes. Дозволи Helm оцінюються за допомогою вашого [файлу kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/). Адміністратори кластерів можуть обмежити дозволи користувачів на будь-якому рівні деталізації, який вони вважають за потрібний. Релізи все ще записуються в кластері, а решта функціональності Helm залишається. + +### Поліпшена стратегія оновлення: 3-сторонні стратегічні зливання патчів {#improved-upgrade-strategy-3-way-strategic-merge-patches} + +Helm 2 використовував двостороннє стратегічне злиття патчів. Під час оновлення він порівнював маніфест останньої версії чарту з маніфестом запропонованого чарту (той, що надається під час `helm upgrade`). Він порівнював різницю між цими двома чартами, щоб визначити, які зміни потрібно застосувати до ресурсів у Kubernetes. Якщо зміни були внесені до кластера поза планом (наприклад, під час `kubectl edit`), ці зміни не враховувалися. Це призводило до того, що ресурси не могли повернутися до попереднього стану: оскільки Helm розглядав тільки останній застосований маніфест чарту як поточний стан, якщо у стані чарту не було змін, поточний стан залишався незмінним. + +У Helm 3 тепер використовується тристороннє стратегічне злиття патчів. Helm враховує старий маніфест, його поточний стан і новий маніфест при генерації патчу. + +#### Приклади {#examples} + +Розглянемо кілька поширених прикладів того, на що впливають ці зміни. + +##### Повернення до попереднього стану, де поточний стан змінився {#rolling-back-where-live-state-has-changed} + +Ваша команда щойно розгорнула свій застосунок для операційної діяльності на Kubernetes за допомогою Helm. Чарт містить обʼєкт Deployment, де кількість реплік встановлено на три: + +```console +$ helm install myapp ./myapp +``` + +Новий розробник приєднується до команди. В перший день, спостерігаючи за операційним кластером, трапляється жахлива аварія, коли кава проливається на клавіатуру, в наслідок чого `kubectl scale` згортає deployment з трьох реплік до нуля. + +```console +$ kubectl scale --replicas=0 deployment/myapp +``` + +Ще один розробник у вашій команді помічає, що операційний сайт не працює, і вирішує повернути реліз до попереднього стану: + +```console +$ helm rollback myapp +``` + +Що відбувається? + +У Helm 2 буде згенеровано патч, порівнюючи старий маніфест з новим маніфестом. Оскільки це повернення, це той самий маніфест. Helm визначає, що немає нічого для зміни, оскільки немає різниці між старим і новим маніфестом. Кількість реплік продовжує залишатися на нулі. Паніка зростає. + +У Helm 3 патч генерується з використанням старого маніфесту, поточного стану і нового маніфесту. Helm визнає, що старий стан був на трьох, поточний стан — на нулі, а новий маніфест хоче змінити його назад на три, тому він генерує патч, щоб змінити стан назад на три екземпляри. + +##### Оновлення, де поточний стан змінився {#updating-where-live-state-has-changed} + +Багато сервісних мереж та інших застосунків на основі контролерів вбудовують дані в обʼєкти Kubernetes. Це може бути щось на кшталт sidecar, міток або іншої інформації. Раніше, якщо у вас був даний маніфест, створений з чарту: + +```yaml +containers: +- name: server + image: nginx:2.0.0 +``` + +А поточний стан був змінений іншим застосунком на + +```yaml +containers: +- name: server + image: nginx:2.0.0 +- name: my-injected-sidecar + image: my-cool-mesh:1.0.0 +``` + +Тепер ви хочете оновити теґ образу `nginx` до `2.1.0`. Отже, ви оновлюєте чарт до маніфесту: + +```yaml +containers: +- name: server + image: nginx:2.1.0 +``` + +Що відбувається? + +У Helm 2 Helm генерує патч обʼєкта `containers` між старим маніфестом і новим маніфестом. Поточний стан кластера не враховується під час генерації патчу. + +Поточний стан кластера модифікується, щоб виглядати наступним чином: + +```yaml +containers: +- name: server + image: nginx:2.1.0 +- name: my-injected-sidecar + image: my-cool-mesh:1.0.0 +``` + +Виникає більше паніки. + +У Helm 3 Helm генерує патч обʼєкта `containers` між старим маніфестом, поточним станом і новим маніфестом. Він помічає, що новий маніфест змінює теґ образу на `2.1.0`, але поточний стан містить контейнер sidecar. + +Поточний стан кластера модифікується, щоб виглядати наступним чином: + +```yaml +containers: +- name: server + image: nginx:2.1.0 +- name: my-injected-sidecar + image: my-cool-mesh:1.0.0 +``` + +### Імена релізів тепер обмежені простором імен {#release-names-are-now-scoped-to-the-namespace} + +З видаленням Tiller інформація про кожен реліз повинна була десь зберігатися. У Helm 2 вона зберігалась в тому ж просторі імен, що й Tiller. Це означало, що після використання імені для одного релізу жоден інший реліз не міг використовувати те ж саме імʼя, навіть якщо він був розгорнутий в іншому просторі імен. + +У Helm 3 інформація про конкретний реліз тепер зберігається в тому ж просторі імен, що і сам реліз. Це означає, що користувачі тепер можуть робити `helm install wordpress stable/wordpress` у двох окремих просторах імен, і кожен з них можна буде переглядати за допомогою `helm list`, змінивши контекст простору імен (наприклад, `helm list --namespace foo`). + +З цим більшим узгодженням з нативними просторами імен кластера команда `helm list` більше не стандартно виводить перелік всіх релізів. Натомість вона буде виводити лише релізи в просторі імен вашого поточного контексту Kubernetes (тобто простір імен, що відображається, коли ви виконуєте `kubectl config view --minify`). Це також означає, що ви повинні вказати прапорець `--all-namespaces` для `helm list`, щоб отримати поведінку, подібну до Helm 2. + +### Secrets як стандартний драйвер зберігання {#secrets-as-the-default-storage-driver} + +У Helm 3 Secrets тепер використовуються як [стандартний драйвер зберігання](/docs/topics/advanced/#storage-backends). Helm 2 стандартно використовував ConfigMaps для зберігання інформації про релізи. У Helm 2.7.0 було впроваджено новий бекенд зберігання, що використовує Secrets для зберігання інформації про релізи, і тепер це є стандартним починаючи з Helm 3. + +Перехід на Secrets як стандарт для Helm 3 забезпечує додаткову безпеку у захисті чарту разом з випуском шифрування Secrets у Kubernetes. + +[Шифрування секретів в спокої](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) стало доступним як альфа функція в Kubernetes 1.7 і стало стабільним починаючи з Kubernetes 1.13. Це дозволяє користувачам шифрувати метадані релізів Helm в спокої, і це є хорошою відправною точкою, яку можна пізніше розширити на використання чогось на кшталт Vault. + +### Зміни в шляху Go import {#go-import-path-changes} + +У Helm 3 шлях імпорту Go був змінений з `k8s.io/helm` на `helm.sh/helm/v3`. Якщо ви плануєте оновити бібліотеки клієнтів Go для Helm 3, переконайтеся, що змінюєте свої шляхи імпорту. + +### Можливості {#capabilities} + +Вбудований обʼєкт `.Capabilities`, доступний під час етапу рендерингу, був спрощений. + +[Вбудовані Обʼєкти](/docs/chart_template_guide/builtin_objects/) + +### Перевірка значень чарту з JSONSchema {#validating-chart-values-with-jsonschema} + +Тепер можна накласти JSON Schema на значення чарту. Це забезпечує, що значення, надані користувачем, відповідають схемі, визначеній автором чарту, що забезпечує кращу звітність про помилки, коли користувач надає неправильний набір значень для чарту. + +Перевірка відбувається при виконанні будь-якої з наступних команд: + +* `helm install` +* `helm upgrade` +* `helm template` +* `helm lint` + +Дивіться документацію про [Файли схем](/docs/topics/charts#schema-files) для додаткової інформації. + +### Консолідація `requirements.yaml` в `Chart.yaml` {#consolidation-of-requirementsyaml-into-chartyaml} + +Система управління залежностями чартів перейшла з `requirements.yaml` та `requirements.lock` у `Chart.yaml` та `Chart.lock`. Рекомендується, щоб нові чарти для Helm 3 використовували новий формат. Тим не менш, Helm 3 все ще розуміє API версію 1 (`v1`) і буде завантажувати наявні файли `requirements.yaml`. + +У Helm 2 файл `requirements.yaml` виглядав так: + +```yaml +dependencies: +- name: mariadb + version: 5.x.x + repository: https://charts.helm.sh/stable + condition: mariadb.enabled + tags: + - database +``` + +У Helm 3 залежність виражена так само, але тепер у вашому `Chart.yaml`: + +```yaml +dependencies: +- name: mariadb + version: 5.x.x + repository: https://charts.helm.sh/stable + condition: mariadb.enabled + tags: + - database +``` + +Чарти все ще завантажуються і розміщуються в теці `charts/`, тому субчарти, які знаходяться в теці `charts/`, будуть продовжувати працювати без змін. + +### Імʼя (або `--generate-name`) тепер необхідне при встановленні {#name-or---generate-name-is-now-required-on-install} + +У Helm 2, якщо імʼя не було надане, імʼя автоматично генерувалося. В операційній експлуатації це виявилося більше проблемою, ніж корисною функцією. У Helm 3 Helm видасть помилку, якщо імʼя не буде надано при `helm install`. + +Для тих, хто все ще бажає автоматичне генерування імені, можна використовувати прапорець `--generate-name`, щоб створити його. + +### Публікація чартів в OCI реєстрах {#publishing-charts-to-oci-registries} + +Це експериментальна функція, введена в Helm 3. Щоб використовувати, встановіть змінну середовища `HELM_EXPERIMENTAL_OCI=1`. + +На високому рівні, репозиторій чартів — це місце, де чарти можуть зберігатися та ними можна обмінюватися. Клієнт Helm пакує і відправляє чарт в репозиторій чартів. Простими словами, репозиторій чартів — це базовий HTTP сервер, який містить файл `index.yaml` і деякі упаковані чарти. + +Хоча є кілька переваг в API репозиторію чартів, що відповідає найосновнішим вимогам зберігання, деякі недоліки почали виявлятися: + +* Репозиторії чартів мають великі труднощі з абстрагуванням більшості реалізацій безпеки, необхідних у виробничому середовищі. Наявність стандартного API для автентифікації та авторизації є дуже важливим в операційних сценаріях. +* Інструменти перевірки походження чартів Helm, що використовуються для підписання та перевірки цілісності та походження чарту, є необовʼязковою частиною процесу публікації чарту. +* У багатокористувацьких сценаріях один і той же чарт може бути завантажений іншим користувачем, що призводить до двократних витрат на зберігання того ж контенту. Розумніші репозиторії чартів були спроєктовані для обробки цього, але це не є частиною офіційної специфікації. +* Використання одного індексного файлу для пошуку, інформації про метадані та отримання чартів ускладнило проєктування у безпечних багатокористувацьких реалізаціях. + +Проєкт Docker Distribution (також відомий як Docker Registry v2) є спадкоємцем проєкту Docker Registry. Багато великих хмарних постачальників мають промислову пропозицію проєкту Distribution, і з такою кількістю постачальників, які пропонують один і той же продукт, проєкт Distribution отримав багато років удосконалення, кращих практик безпеки та випробувань у бою. + +Будь ласка, ознайомтеся з `helm help chart` та `helm help registry` для отримання додаткової інформації про те, як упакувати чарт і опублікувати його в Docker реєстрі. + +Більше інформації можна знайти на [цій сторінці](/docs/topics/registries/). + +### Видалення `helm serve` {#removal-of-helm-serve} + +`helm serve` запускав локальний репозиторій чартів на вашій машині для цілей розробки. Проте, він не отримав великого визнання як інструмент для розробки та мав численні проблеми з його дизайном. Зрештою, ми вирішили видалити його та винести у втулок. + +Для досвіду подібного до `helm serve`, подивіться на локальний файловий системний варіант у [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) та втулок [servecm](https://github.com/jdolitsky/helm-servecm). + +### Підтримка бібліотечних чартів {#library-chart-support} + +Helm 3 підтримує клас чартів, що називається “бібліотечний чарт”. Це чарт, який використовується іншими чартами, але не створює жодних артефактів релізів самостійно. Шаблони бібліотечного чарту можуть лише оголошувати елементи `define`. Глобально скопійовані не-`define` вмісти просто ігноруються. Це дозволяє користувачам повторно використовувати та ділитися фрагментами коду, які можна використовувати в багатьох чартах, уникати повторюваності та зберігати чарт [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself). + +Бібліотечні чарти оголошуються в директиві залежностей у Chart.yaml, і їх можна встановлювати та керувати як будь-яким іншим чартом. + +```yaml +dependencies: + - name: mylib + version: 1.x.x + repository: quay.io +``` + +Ми дуже раді бачити сценарії використання цієї функції для розробників чартів, а також будь-які найкращі практики, які виникають від споживання бібліотечних чартів. + +### Зміна apiVersion Chart.yaml {#chartyaml-apiversion-bump} + +З впровадженням підтримки бібліотечних чартів та консолідацією `requirements.yaml` в `Chart.yaml`, клієнти, які розуміли формат пакетів Helm 2, не зможуть зрозуміти ці нові функції. Тому, ми підняли версію apiVersion у Chart.yaml з `v1` на `v2`. + +`helm create` тепер створює чарт з використанням цього нового формату, тому стандартний apiVersion був піднятий там також. + +Клієнти, які бажають підтримувати обидві версії чартів Helm, повинні перевіряти поле `apiVersion` у Chart.yaml, щоб зрозуміти, як розібрати формат пакету. + +### Підтримка XDG Base Directory {#xdg-base-directory-support} + +[Специфікація XDG Base Directory](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) є портативним стандартом, що визначає, де слід зберігати конфігурації, дані та кешовані файли у файловій системі. + +У Helm 2 Helm зберігав всю цю інформацію в `~/.helm` (відомій як `helm home`), що можна було змінити, встановивши змінну середовища `$HELM_HOME`, або використовуючи глобальний прапорець `--home`. + +У Helm 3 тепер Helm поважає наступні змінні середовища відповідно до специфікації XDG Base Directory: + +* `$XDG_CACHE_HOME` +* `$XDG_CONFIG_HOME` +* `$XDG_DATA_HOME` + +Втулки Helm все ще отримують `$HELM_HOME` як псевдонім до `$XDG_DATA_HOME` для зворотної сумісності з втулками, які використовують `$HELM_HOME` як середовище для тимчасових даних. + +Також кілька нових змінних середовища передаються в середовище втулка для врахування цієї зміни: + +* `$HELM_PATH_CACHE` для кешованого шляху +* `$HELM_PATH_CONFIG` для конфігураційного шляху +* `$HELM_PATH_DATA` для шляхів даних + +Втулки Helm, які прагнуть підтримувати Helm 3, повинні розглянути можливість використання цих нових змінних середовища замість старих. + +### Перейменування команд CLI {#cli-command-renames} + +Щоб краще узгодити термінологію з іншими менеджерами пакетів, `helm delete` було перейменовано на `helm uninstall`. `helm delete` все ще зберігається як псевдонім до `helm uninstall`, тож можна використовувати будь-яку форму. + +У Helm 2, щоб очистити лог релізів, потрібно було вказати прапорець `--purge`. Ця функціональність тепер є стандартно увімкненою. Щоб зберегти попередню поведінку, використовуйте `helm uninstall --keep-history`. + +Крім того, кілька інших команд були перейменовані для узгодження з тією ж термінологією: + +* `helm inspect` -> `helm show` +* `helm fetch` -> `helm pull` + +Ці команди також зберегли старі дієслова як псевдоніми, тому ви можете продовжувати використовувати їх у будь-якому вигляді. + +### Автоматичне створення просторів імен {#automatically-creating-namespaces} + +При створенні релізу в просторі імен, який не існує, Helm 2 створював простір імен. Helm 3 дотримується поведінки іншого інструменту Kubernetes і повертає помилку, якщо простір імен не існує. Helm 3 створить простір імен, якщо ви явно вкажете прапорець `--create-namespace`. + +### Що сталося з .Chart.ApiVersion? {#what-happened-to-chartapiversion} + +Helm дотримується звичайної домовленості CamelCasing, яка передбачає використання великої літери для абревіатури. Ми зробили це і в іншому коді, наприклад, у `.Capabilities.APIVersions.Has`. У Helm v3 ми виправили `.Chart.ApiVersion`, перейменувавши його на `.Chart.APIVersion`. diff --git a/content/uk/docs/faq/installing.md b/content/uk/docs/faq/installing.md new file mode 100644 index 000000000..433a45e6d --- /dev/null +++ b/content/uk/docs/faq/installing.md @@ -0,0 +1,26 @@ +--- +title: "Встановлення" +weight: 2 +--- + +## Встановлення {#installing} + +### Чому немає рідних пакетів Helm для Fedora та інших дистрибутивів Linux? {#why-aren-t-there-native-packages-of-helm-for-fedora-and-other-linux-distros} + +Проєкт Helm не підтримує пакети для операційних систем та середовищ. Спільнота Helm може надати рідні пакети, і якщо проєкт Helm дізнається про них, вони будуть вказані. Саме так почалася та була вказана формула Homebrew. Якщо ви зацікавлені в підтримці пакета, ми будемо раді цьому. + +### Чому ви надаєте скрипт `curl ...|bash`? {#why-do-you-provide-a-curl-bash-script} + +У нашому репозиторії є скрипт (`scripts/get-helm-3`), який можна виконати як `curl ..|bash` скрипт. Передача захищена HTTPS, а скрипт проводить деякий аудит пакетів, які він завантажує. Проте скрипт має всі звичайні небезпеки будь-якого скрипта оболонки. + +Ми надаємо його, тому що це корисно, але ми радимо користувачам ретельно ознайомитися зі скриптом перед виконанням. Те, що ми насправді хотіли б, — це кращі упаковані релізи Helm. + +### Як мені помістити файли клієнта Helm в інше місце, не стандартне місце? {#how-do-i-put-the-helm-client-files-somewhere-other-than-their-defaults} + +Helm використовує структуру XDG для зберігання файлів. Існують змінні середовища, які ви можете використовувати для зміни цих місць: + +- `$XDG_CACHE_HOME`: встановіть альтернативне місце для зберігання кешованих файлів. +- `$XDG_CONFIG_HOME`: встановіть альтернативне місце для зберігання конфігурацій Helm. +- `$XDG_DATA_HOME`: встановіть альтернативне місце для зберігання даних Helm. + +Зверніть увагу, що якщо у вас є наявні репозиторії, вам доведеться повторно їх додати за допомогою `helm repo add...`. diff --git a/content/uk/docs/faq/troubleshooting.md b/content/uk/docs/faq/troubleshooting.md new file mode 100644 index 000000000..28d926fe3 --- /dev/null +++ b/content/uk/docs/faq/troubleshooting.md @@ -0,0 +1,132 @@ +--- +title: "Усунення несправностей" +weight: 4 +--- + +## Усунення несправностей {#troubleshooting} + +### Я отримую попередження про "Не вдалося отримати оновлення з репозиторію чартів 'stable'" {#i-am-getting-a-warning-about-unable-to-get-an-update-from-the-stable-chart-repository} + +Запустіть `helm repo list`. Якщо він показує ваш репозиторій `stable`, який вказує на URL `storage.googleapis.com`, вам потрібно оновити цей репозиторій. 13 листопада 2020 року репозиторій Helm Charts [перестав підтримуватися](https://github.com/helm/charts#deprecation-timeline) після річного періоду відмови від обслуговування. Архів доступний за адресою `https://charts.helm.sh/stable`, але більше не отримуватиме оновлень. + +Ви можете виконати наступну команду для виправлення репозиторію: + +```console +$ helm repo add stable https://charts.helm.sh/stable --force-update +``` + +Те ж саме стосується репозиторію `incubator`, для якого є архів за адресою https://charts.helm.sh/incubator. Ви можете виконати наступну команду для його відновлення: + +```console +$ helm repo add incubator https://charts.helm.sh/incubator --force-update +``` + +### Я отримую попередження 'WARNING: "kubernetes-charts.storage.googleapis.com" is deprecated for "stable" and will be deleted Nov. 13, 2020.' {#i-am-getting-the-warning-warning-kubernetes-chartsstoragegoogleapiscom-is-deprecated-for-stable-and-will-be-deleted-nov-13-2020} + +Старий репозиторій чартів Google було замінено новим репозиторієм Helm чартів. + +Запустіть наступну команду для остаточного виправлення цього: + +```console +$ helm repo add stable https://charts.helm.sh/stable --force-update +``` + +Якщо ви отримуєте подібну помилку для `incubator`, виконайте цю команду: + +```console +$ helm repo add incubator https://charts.helm.sh/incubator --force-update +``` + +### Коли я додаю репозиторій Helm, я отримую помилку 'Error: Repo "https://kubernetes-charts.storage.googleapis.com" is no longer available' {#when-i-add-a-helm-repo-i-get-the-error-error-repo-httpskubernetes-chartsstoragegoogleapiscom-is-no-longer-available} + +Репозиторії чартів Helm більше не підтримуються після [річного періоду відмови від обслуговування](https://github.com/helm/charts#deprecation-timeline). Архіви цих репозиторіїв доступні за адресами `https://charts.helm.sh/stable` та `https://charts.helm.sh/incubator`, але більше не отримуватимуть оновлень. Команда `helm repo add` не дозволяє додати старі URL-адреси, якщо не вказати `--use-deprecated-repos`. + +### На GKE (Google Container Engine) я отримую "No SSH tunnels currently open" {#on-gke-google-container-engine-i-get-no-ssh-tunnels-currently-open} + +```none +Error: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user "gke-[redacted]"? +``` + +Ще одна версія повідомлення про помилку: + +```none +Unable to connect to the server: x509: certificate signed by unknown authority +``` + +Проблема в тому, що ваш локальний файл конфігурації Kubernetes повинен містити правильні облікові дані. + +Коли ви створюєте кластер на GKE, він надає вам облікові дані, включаючи SSL сертифікати та центри сертифікації. Їх потрібно зберігати у файлі конфігурації Kubernetes (стандартно: `~/.kube/config`), щоб `kubectl` та `helm` могли їх використовувати. + +### Після міграції з Helm 2 команда `helm list` показує лише деякі (або жодного) мої релізи {#after-migration-from-helm-2-helm-list-shows-only-some-or-none-of-my-releases} + +Можливо, ви пропустили те, що Helm 3 тепер використовує простори імен кластера для визначення релізів. Це означає, що для всіх команд, що посилаються на реліз, ви повинні або: + +* покластися на поточний простір імен в активному контексті kubernetes (як описано командою `kubectl config view --minify`), +* вказати правильний простір імен, використовуючи прапорець `--namespace`/`-n`, або +* для команди `helm list`, вказати прапорець `--all-namespaces`/`-A`. + +Це стосується `helm ls`, `helm uninstall` та всіх інших команд `helm`, що посилаються на реліз. + +### На macOS звертається до файлу `/etc/.mdns_debug`. Чому? {#on-macos-the-file-etcmdns_debug-is-accessed-why} + +Ми знаємо про випадок на macOS, коли Helm намагається звернутися до файлу з назвою `/etc/.mdns_debug`. Якщо файл існує, Helm тримає дескриптор файлу відкритим під час виконання. + +Це викликано бібліотекою MDNS macOS. Вона намагається завантажити цей файл для читання налаштувань відладки (якщо увімкнено). Дескриптор файлу, ймовірно, не повинен залишатися відкритим, і ця проблема була передана Apple. Однак це macOS, а не Helm, викликає цю поведінку. + +Якщо ви не хочете, щоб Helm завантажував цей файл, ви можете спробувати скомпілювати Helm як статичну бібліотеку, яка не використовує стек мережі хосту. Це збільшить розмір бінарного файлу Helm, але завадить відкриттю файлу. + +Цю проблему спочатку було позначено як потенційну проблему безпеки. Але з того часу було визначено, що ця поведінка не має жодних недоліків або вразливостей. + +### helm repo add не вдається, хоча раніше працювало {#helm-repo-add-fails-when-it-used-to-work} + +У helm 3.3.1 та раніше команда `helm repo add ` не видає жодного виходу, якщо ви намагаєтеся додати репозиторій, який вже існує. Прапорець `--no-update` викликав помилку, якщо репозиторій вже був зареєстрований. + +У helm 3.3.2 та пізніших версіях спроба додати наявний репозиторій викличе помилку: + +`Error: repository name (reponame) already exists, please specify a different name` + +Тепер стандартна поведінка змінилася. Прапорець `--no-update` тепер ігнорується, а якщо ви хочете замінити (перезаписати) наявний репозиторій, ви можете використовувати `--force-update`. + +Це повʼязано з переломною зміною для виправлення проблеми безпеки, як пояснено в [замітках про реліз Helm 3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2). + +### Увімкнення ведення логів клієнта Kubernetes {#enabling-kubernetes-client-logging} + +Друк повідомлень логу для відладки клієнта Kubernetes можна увімкнути за допомогою прапорців [klog](https://pkg.go.dev/k8s.io/klog). Використання прапорця `-v` для налаштування рівня деталізації буде достатнім для більшості випадків. + +Наприклад: + +```shell +helm list -v 6 +``` + +### Встановлення Tiller припинило працювати і доступ заборонено {#installing-tiller-stopped-working-and-access-is-denied} + +Релізи Helm раніше були доступні за адресою . Як пояснюється в ["Announcing get.helm.sh"](https://helm.sh/blog/get-helm-sh/), офіційне місце розташування змінилося у червні 2019 року. [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller) робить всі старі образи Tiller доступними. + +Якщо ви намагаєтеся завантажити старі версії Helm з кошику зберігання, який ви використовували раніше, ви можете виявити, що вони відсутні: + +```none + + AccessDenied + Access denied. +
Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object.
+ +``` + +[Місце розташування старих образів Tiller](https://gcr.io/kubernetes-helm/tiller) розпочало видалення образів у серпні 2021 року. Ми зробили ці образи доступними за адресою [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller). Наприклад, щоб завантажити версію v2.17.0, замініть: + +`https://storage.googleapis.com/kubernetes-helm/helm-v2.17.0-linux-amd64.tar.gz` + +на: + +`https://get.helm.sh/helm-v2.17.0-linux-amd64.tar.gz` + +Щоб ініціалізувати Helm v2.17.0: + +`helm init —upgrade` + +Або, якщо потрібна інша версія, використовуйте прапорець `--tiller-image`, щоб перевизначити стандартне місце розташування та встановити конкретну версію Helm v2: + +`helm init --tiller-image ghcr.io/helm/tiller:v2.16.9` + +**Примітка:** Розробники Helm рекомендують міграцію на підтримувану версію Helm. Helm v2.17.0 був останнім випуском Helm v2; Helm v2 більше не підтримується з листопада 2020 року, як детально описано в [Helm 2 та проєкт Charts більше не підтримуються](https://helm.sh/blog/helm-2-becomes-unsupported/). Багато CVE було виявлено в Helm з того часу, і ці експлойти виправлені в Helm v3, але ніколи не будуть виправлені в Helm v2. Перегляньте [актуальний список опублікованих сповіщень Helm](https://github.com/helm/helm/security/advisories?state=published) і складіть план [міграції на Helm v3](https://helm.sh/docs/topics/v2_v3_migration/#helm) сьогодні. diff --git a/content/uk/docs/faq/uninstalling.md b/content/uk/docs/faq/uninstalling.md new file mode 100644 index 000000000..21304ddff --- /dev/null +++ b/content/uk/docs/faq/uninstalling.md @@ -0,0 +1,22 @@ +--- +title: "Видалення" +weight: 3 +--- + +## Видалення {#uninstalling} + +### Я хочу видалити свій локальний Helm. Де зберігаються всі його файли? {#i-want-to-uninstall-my-local-helm-where-are-all-of-its-files} + +Разом з бінарним файлом `helm`, Helm зберігає деякі файли в наступних розташуваннях: + +- $XDG_CACHE_HOME +- $XDG_CONFIG_HOME +- $XDG_DATA_HOME + +Наступна таблиця показує стандартні теки для кожного з цих розташувань, за операційними системами: + +| Операційна система | Шлях до кешу | Шлях до конфігурацій | Шлях до даних | +|--------------------|-----------------------------|----------------------------------|-----------------------------| +| Linux | `$HOME/.cache/helm` | `$HOME/.config/helm` | `$HOME/.local/share/helm` | +| macOS | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm` | +| Windows | `%TEMP%\helm` | `%APPDATA%\helm` | `%APPDATA%\helm` | diff --git a/content/uk/docs/glossary/_index.md b/content/uk/docs/glossary/_index.md new file mode 100644 index 000000000..b5a3493d1 --- /dev/null +++ b/content/uk/docs/glossary/_index.md @@ -0,0 +1,118 @@ +--- +title: "Глосарій" +description: "Терміни, що використовуються для опису компонентів архітектури Helm." +weight: 9 +--- + +# Глосарій {#glossary} + +## Чарт {#chart} + +Пакет Helm, що містить інформацію, достатню для встановлення набору ресурсів Kubernetes у кластер Kubernetes. + +Чарти містять файл `Chart.yaml`, а також шаблони, стандартні значення (`values.yaml`) та залежності. + +Чарти розробляються у чітко визначеній структурі тек, а потім упаковуються у формат архіву, що називається _чарт-архівом_. + +## Чарт-архів {#chart-archive} + +_Чарт-архів_ — це архів, що містить tar і gzipped (і, за бажанням, підписаний) чарт. + +## Залежність чарту (субчарти) {#chart-dependency-subcharts} + +Чарти можуть залежати від інших чартів. Залежність може бути здійснена двома способами: + +- М’яка залежність: Чарт може просто не функціонувати без іншого чарту, встановленого в кластері. Helm не надає інструментів для цього випадку. У цьому випадку залежності можуть управлятися окремо. +- Жорстка залежність: Чарт може містити (всередині теки `charts/`) інший чарт, від якого він залежить. У цьому випадку, встановлення чарту також встановить усі його залежності. У цьому випадку чарт і його залежності управляються як колекція. + +Коли чарт упаковується (через `helm package`), всі його жорсткі залежності упаковуються разом з ним. + +## Версія чарту {#chart-version} + +Чарти версіонуються відповідно до [специфікації SemVer 2](https://semver.org). Номер версії є обов’язковим для кожного чарта. + +## Chart.yaml + +Інформація про чарт зберігається в спеціальному файлі з назвою `Chart.yaml`. Кожен чарт повинен мати цей файл. + +## Helm (та helm) {#helm-and-helm} + +Helm — це менеджер пакетів для Kubernetes. Як менеджер пакетів для операційних систем полегшує встановлення інструментів на ОС, так Helm полегшує встановлення застосунків та ресурсів у кластери Kubernetes. + +Хоча _Helm_ — це назва проєкту, клієнт командного рядка також називається `helm`. Зазвичай, коли йдеться про проєкт, _Helm_ пишеться з великої літери. Коли йдеться про клієнт, _helm_ пишеться з маленької літери. + +## Конфігураційні файли Helm (XDG) {#helm-configuration-files-xdg} + +Helm зберігає свої конфігураційні файли в теках XDG. Ці теки створюються при першому запуску `helm`. + +## Kube Config (KUBECONFIG) + +Клієнт Helm дізнається про кластери Kubernetes, використовуючи файли у форматі _Kube config_. Стандартно, Helm намагається знайти цей файл у місці, де його створює `kubectl` (`$HOME/.kube/config`). + +## Лінтинг (Linting) {#lint-linting} + +Лінтинг чарта — це перевірка того, що він відповідає домовленостям і вимогам стандарту чарту Helm. Helm надає інструменти для цього, зокрема команду `helm lint`. + +## Provenance (Файл provenance) {#provenance-provenance-file} + +Чарти Helm можуть супроводжуватися _файлом provenance_, який надає інформацію про те, звідки походить чарт і що він містить. + +Файли provenance є частиною історії безпеки Helm. Файл provenance містить криптографічний хеш файлу чарт-архіву, дані Chart.yaml і блок підпису (блок OpenPGP "clearsign"). У поєднанні з вʼязкою ключів він надає користувачам чартів можливість: + +- Перевірити, що чарт був підписаний довіреною стороною +- Перевірити, що файл чарту не був змінений +- Перевірити вміст метаданих чарту (`Chart.yaml`) +- Швидко зіставити чарт з даними provenance + +Файли provenance мають розширення `.prov` і можуть бути надані з сервера репозиторію чартів або будь-якого іншого HTTP-сервера. + +## Реліз {#release} + +Коли чарт встановлюється, бібліотека Helm створює _реліз_, щоб відстежувати це встановлення. + +Один і той же чарт може бути встановлений кілька разів в одному кластері, створюючи багато різних релізів. Наприклад, можна встановити три бази даних PostgreSQL, запустивши `helm install` три рази з різними іменами релізів. + +## Номер релізу (Версія релізу) {#release-number-release-version} + +Один реліз може бути оновлений кілька разів. Для відстеження релізів, коли вони змінюються, використовується послідовний лічильник. Після першого `helm install` реліз матиме _номер релізу_ 1. Кожного разу, коли реліз оновлюється або скасовується, номер релізу буде збільшений. + +## Відкат {#rollback} + +Реліз можна оновити до новішого чарту або конфігурації. Але оскільки історія релізів зберігається, реліз також може бути _відкочений_ до попереднього номера релізу. Це робиться за допомогою команди `helm rollback`. + +Важливо, що реліз, що відкочується, отримає новий номер релізу. + +| Операція | Номер релізу | +|-----------|----------------------------------------------------| +| встановлення | реліз 1 | +| оновлення | реліз 2 | +| оновлення | реліз 3 | +| відкат 1 | реліз 4 (але виконує ту ж конфігурацію, що й реліз 1) | + +Вищенаведена таблиця ілюструє, як номери релізів збільшуються під час встановлення, оновлення та відкату. + +## Бібліотека Helm (або SDK) {#helm-library-or-sdk} + +Бібліотека Helm (або SDK) належить до коду Go, який безпосередньо взаємодіє з сервером API Kubernetes для встановлення, оновлення, запиту та видалення ресурсів Kubernetes. Її можна імплементувати у проєкт для використання Helm як бібліотеки клієнта замість CLI. + +## Репозиторій (Repo, Репозиторій чартів) {#repository-repo-chart-repository} + +Чарти Helm можуть зберігатися на спеціалізованих HTTP-серверах, які називаються _репозиторіями чартів_ (_репозиторіями_, або просто _repo_). + +Сервер репозиторію чартів є простим HTTP-сервером, який може надавати файл `index.yaml`, який описує групу чартів, і надає інформацію про те, звідки можна завантажити кожен чарт. (Багато серверів репозиторіїв чартів надають як чарт, так і файл `index.yaml`.) + +Клієнт Helm може вказати нуль або більше репозиторіїв чартів. Стандартно клієнти Helm не налаштовані на жодні репозиторії чартів. Репозиторії чартів можна додати в будь-який час за допомогою команди `helm repo add`. + +## Реєстр чартів (OCI реєстр) {#chart-registry-oci-based-registry} + +Реєстр чартів Helm є системою зберігання та розподілу на основі [OCI](https://opencontainers.org/about/overview/), яка використовується для розміщення та обміну пакетами чартів Helm. Для отримання додаткової інформації див. [документацію Helm про реєстри](https://helm.sh/docs/topics/registries/). + +## Значення (Файли значень, values.yaml) {#values-values-files-valuesyaml} + +Значення надають спосіб перевизначити стандартні значення шаблонів вашою інформацією. + +Чарти Helm є "параметризованими", що означає, що розробник чарта може експонувати конфігурацію, яку можна перевизначити під час установки. Наприклад, чарт може експонувати поле `username`, яке дозволяє встановити імʼя користувача для сервісу. + +Ці експоновані змінні називаються _значеннями_ в термінах Helm. + +Значення можна встановити під час операцій `helm install` та `helm upgrade`, або безпосередньо передаючи їх, або використовуючи файл `values.yaml`. diff --git a/content/uk/docs/helm/_index.md b/content/uk/docs/helm/_index.md new file mode 100644 index 000000000..3d17e220c --- /dev/null +++ b/content/uk/docs/helm/_index.md @@ -0,0 +1,10 @@ +--- +title: "Команди Helm" +description: "Документація для повного списку команд CLI для Helm." +weight: 6 +slug: helm +--- + +# Команди Helm {#helm-commands} + +Тут ви знайдете список команд CLI для Helm з інформацією щодо їх використання. diff --git a/content/uk/docs/helm/helm.md b/content/uk/docs/helm/helm.md new file mode 100644 index 000000000..0d9123b60 --- /dev/null +++ b/content/uk/docs/helm/helm.md @@ -0,0 +1,113 @@ +--- +title: "Helm" +--- + +## helm + +Менеджер пакетів Helm для Kubernetes. + +### Опис {#synopsis} + +Менеджер пакетів для Kubernetes + +Загальні дії для Helm: + +- helm search: пошук чартів +- helm pull: завантаження чарту у вашу локальну теку для перегляду +- helm install: завантаження чарту в Kubernetes +- helm list: перегляд списку релізів чартів + +Змінні середовища: + +| Імʼя | Опис | +|------------------------------------|------------------------------------------------------------------------------------------------------------| +| $HELM_CACHE_HOME | вказує альтернативне місце для зберігання кешованих файлів. | +| $HELM_CONFIG_HOME | вказує альтернативне місце для зберігання конфігурації Helm. | +| $HELM_DATA_HOME | вказує альтернативне місце для зберігання даних Helm. | +| $HELM_DEBUG | вказує, чи працює Helm в режимі налагодження | +| $HELM_DRIVER | вказує драйвер бекенду для зберігання. Значення: configmap, secret, memory, sql. | +| $HELM_DRIVER_SQL_CONNECTION_STRING | вказує рядок підключення, який повинен використовувати SQL-драйвер для зберігання. | +| $HELM_MAX_HISTORY | вказує максимальну кількість історії релізів Helm. | +| $HELM_NAMESPACE | вказує простір імен, що використовується для операцій Helm. | +| $HELM_NO_PLUGINS | відключає втулки. Встановіть HELM_NO_PLUGINS=1, щоб відключити втулки. | +| $HELM_PLUGINS | вказує шлях до теки плагінів | +| $HELM_REGISTRY_CONFIG | вказує шлях до файлу конфігурації реєстру. | +| $HELM_REPOSITORY_CACHE | вказує шлях до теки кешу репозиторіїв | +| $HELM_REPOSITORY_CONFIG | вказує шлях до файлу репозиторіїв | +| $KUBECONFIG | вказує альтернативний файл конфігурації Kubernetes (стандартно "~/.kube/config") | +| $HELM_KUBEAPISERVER | вказує точку доступу сервера API Kubernetes для автентифікації | +| $HELM_KUBECAFILE | вказує файл центру сертифікації для Kubernetes. | +| $HELM_KUBEASGROUPS | вказує групи для використання імперсонації, використовуючи список, розділений комами. | +| $HELM_KUBEASUSER | вказує імʼя користувача для імперсонації під час операції. | +| $HELM_KUBECONTEXT | вказує імʼя контексту kubeconfig. | +| $HELM_KUBETOKEN | вказує токен Bearer KubeToken для автентифікації. | +| $HELM_KUBEINSECURE_SKIP_TLS_VERIFY | вказує, чи слід пропустити перевірку сертифіката сервера API Kubernetes (небезпечний режим) | +| $HELM_KUBETLS_SERVER_NAME | вказує імʼя сервера для перевірки сертифіката сервера API Kubernetes | +| $HELM_BURST_LIMIT | вказує стандартне обмеження на кількість викликів у випадку великої кількості CRD (стандартно — 100, -1 для відключення) | +| $HELM_QPS | вказує кількість запитів в секунду у випадках, коли велика кількість викликів перевищує параметр для більш високих значень | + +Helm зберігає кеш, конфігурацію та дані на основі наступного порядку конфігурації: + +- Якщо встановлена змінна середовища HELM_*_HOME, вона буде використана +- В іншому випадку на системах, що підтримують специфікацію базової теки XDG, будуть використані змінні XDG +- Якщо не встановлено інше місце, буде використане стандартне місце залежно від операційної системи + +Типово, стандартні теки залежать від операційної системи. Нижче наведені їх значення: + +| Операційна система | Шлях до кешу | Шлях до конфігурації | Шлях до даних | +|--------------------|---------------------------|------------------------------|--------------------------| +| Linux | $HOME/.cache/helm | $HOME/.config/helm | $HOME/.local/share/helm | +| macOS | $HOME/Library/Caches/helm | $HOME/Library/Preferences/helm | $HOME/Library/helm | +| Windows | %TEMP%\helm | %APPDATA%\helm | %APPDATA%\helm | + +### Параметри {#options} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug вмикає розширений вивід + -h, --help довідка helm + --kube-apiserver string адреса і порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВИТИСЯ ТАКОЖ {#see-also} + +- [helm completion](helm_completion.md) — генерувати скрипти автодоповнення для вказаного shell +- [helm create](helm_create.md) — створити новий чарт з вказаною назвою +- [helm dependency](helm_dependency.md) — керування залежностями чарту +- [helm env](helm_env.md) — інформація про середовище клієнта helm +- [helm get](helm_get.md) — завантажити розширену інформацію про зазначений реліз +- [helm history](helm_history.md) — отримати історію релізу +- [helm install](helm_install.md) — встановити чарт +- [helm lint](helm_lint.md) — перевірити чарт на можливі проблеми +- [helm list](helm_list.md) — переглянути список релізів +- [helm package](helm_package.md) — упакувати теку чарту в архів чарту +- [helm plugin](helm_plugin.md) — встановити, переглянути або видалити втулки Helm +- [helm pull](helm_pull.md) — завантажити чарт з репозиторію та (за бажанням) розпакувати його в локальній теці +- [helm push](helm_push.md) — завантажити чарт до віддаленого сервера +- [helm registry](helm_registry.md) — увійти або вийти з реєстру +- [helm repo](helm_repo.md) — додати, переглянути, видалити, оновити та індексувати репозиторії чартів +- [helm rollback](helm_rollback.md) — відкотити реліз до попередньої версії +- [helm search](helm_search.md) — шукати ключове слово в чартах +- [helm show](helm_show.md) — показати інформацію про чарт +- [helm status](helm_status.md) — відобразити статус зазначеного релізу +- [helm template](helm_template.md) — локально рендерити шаблони +- [helm test](helm_test.md) — запустити тести для релізу +- [helm uninstall](helm_uninstall.md) — видалити реліз +- [helm upgrade](helm_upgrade.md) — оновити реліз +- [helm verify](helm_verify.md) — перевірити, чи підписаний та, чи є дійсним чарт за вказаним шляхом +- [helm version](helm_version.md) — відобразити інформацію про версію клієнта + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_completion.md b/content/uk/docs/helm/helm_completion.md new file mode 100644 index 000000000..6b5bfc1df --- /dev/null +++ b/content/uk/docs/helm/helm_completion.md @@ -0,0 +1,48 @@ +--- +title: "Helm Completion" +--- + +## helm completion + +Генерація скриптів автодоповнення для вказаної оболонки + +### Опис {#synopsis} + +Генерація скриптів автодоповнення Helm для вказаної оболонки. + +### Параметри {#options} + +```none + -h, --help довідка для completion +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug включити розширений вивід + --kube-apiserver string адреса і порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВИТИСЯ ТАКОЖ {#see-also} + +* [helm](helm.md) — Менеджер пакетів Helm для Kubernetes. +* [helm completion bash](helm_completion_bash.md) — генерувати скрипт автодоповнення для bash +* [helm completion fish](helm_completion_fish.md) — генерувати скрипт автодоповнення для fish +* [helm completion powershell](helm_completion_powershell.md) — генерувати скрипт автодоповнення для powershell +* [helm completion zsh](helm_completion_zsh.md) — генерувати скрипт автодоповнення для zsh + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_completion_bash.md b/content/uk/docs/helm/helm_completion_bash.md new file mode 100644 index 000000000..b38da6450 --- /dev/null +++ b/content/uk/docs/helm/helm_completion_bash.md @@ -0,0 +1,69 @@ +--- +title: "Helm Completion Bash" +--- + +## helm completion bash + +Генерація скрипта автодоповнення для bash + +### Опис {#synopsis} + +Генерація скрипта автодоповнення Helm для shell bash. + +Для завантаження автодоповнень у вашій поточній shell-сесії: + +```shell +source <(helm completion bash) +``` + +Для завантаження автодоповнень для кожної нової сесії, виконайте один раз: + +- Linux: + + ```shell + helm completion bash > /etc/bash_completion.d/helm + ``` + +- MacOS: + + ```shell + helm completion bash > /usr/local/etc/bash_completion.d/helm + ``` + +```shell +helm completion bash [прапорці] +``` + +### Параметри {#options} + +```none + -h, --help довідка для bash + --no-descriptions вимкнути описи автодоповнення +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +``` + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug вмикає розширений вивід + --kube-apiserver string адреса і порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВИТИСЯ ТАКОЖ {#see-also} + +- [helm completion](helm_completion.md) — генерувати скрипти автодоповнення для вказаного shell + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_completion_fish.md b/content/uk/docs/helm/helm_completion_fish.md new file mode 100644 index 000000000..b3d5885b0 --- /dev/null +++ b/content/uk/docs/helm/helm_completion_fish.md @@ -0,0 +1,63 @@ +--- +title: "Helm Completion Fish" +--- + +## helm completion fish + +Генерація скрипта автодоповнення для fish + +### Опис {#synopsis} + +Генерація скрипта автодоповнення Helm для shell fish. + +Для завантаження автодоповнень у вашій поточній shell-сесії: + +```shell +helm completion fish | source +``` + +Для завантаження автодоповнень для кожної нової сесії, виконайте один раз: + +```shell +helm completion fish > ~/.config/fish/completions/helm.fish +``` + +Потрібно запустити нову shell-сесію, щоб ці налаштування набули чинності. + +```shell +helm completion fish [прапорці] +``` + +### Параметри {#options} + +```none + -h, --help довідка для fish + --no-descriptions вимкнути описи автодоповнення +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug включити розширений вивід + --kube-apiserver string адреса і порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВИТИСЯ ТАКОЖ {#see-also} + +* [helm completion](helm_completion.md) — генерувати скрипти автодоповнення для вказаного shell + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_completion_powershell.md b/content/uk/docs/helm/helm_completion_powershell.md new file mode 100644 index 000000000..52ecdcb0c --- /dev/null +++ b/content/uk/docs/helm/helm_completion_powershell.md @@ -0,0 +1,58 @@ +--- +title: "Helm Completion Powershell" +--- + +## helm completion powershell + +Генерація скрипта автодоповнення для PowerShell + +### Опис {#synopsis} + +Генерація скрипта автодоповнення для PowerShell. + +Для завантаження автодоповнень у вашій поточній shell-сесії: + +```powershell +PS C:\> helm completion powershell | Out-String | Invoke-Expression +``` + +Для завантаження автодоповнень для кожної нової сесії, додайте вивід вищенаведеної команди до вашого профілю PowerShell. + + +```shell +helm completion powershell [прапорці] +``` + +### Параметри {#options} + +```none + -h, --help довідка для PowerShell + --no-descriptions вимкнути описи автодоповнення +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug включити розширений вивід + --kube-apiserver string адреса і порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВИТИСЯ ТАКОЖ {#see-also} + +* [helm completion](helm_completion.md) — генерувати скрипти автодоповнення для вказаного shell + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_completion_zsh.md b/content/uk/docs/helm/helm_completion_zsh.md new file mode 100644 index 000000000..a4eeddd32 --- /dev/null +++ b/content/uk/docs/helm/helm_completion_zsh.md @@ -0,0 +1,61 @@ +--- +title: "Helm Completion Zsh" +--- + +## helm completion zsh + +Генерація скрипта автодоповнення для zsh + +### Опис {#synopsis} + +Генерація скрипта автодоповнення Helm для оболонки zsh. + +Для завантаження автодоповнень у вашій поточній shell-сесії: + +```shell +source <(helm completion zsh) +``` + +Для завантаження автодоповнень для кожної нової сесії, виконайте один раз: + +```shell +helm completion zsh > "${fpath[1]}/_helm" +``` + +```shell +helm completion zsh [прапорці] +``` + +### Параметри {#options} + +```none + -h, --help довідка для zsh + --no-descriptions вимкнути описи автодоповнення +``` + +### Параметри, успадковані від батьківських команд + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug включити розширений вивід + --kube-apiserver string адреса і порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВИТИСЯ ТАКОЖ {#see-also} + +* [helm completion](helm_completion.md) — генерувати скрипти автодоповнення для вказаного shell + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_create.md b/content/uk/docs/helm/helm_create.md new file mode 100644 index 000000000..afbf32d84 --- /dev/null +++ b/content/uk/docs/helm/helm_create.md @@ -0,0 +1,65 @@ +--- +title: "Helm Create" +--- + +## helm create + +створити новий чарт із вказаним імʼям + +### Опис {#synopsis} + +Ця команда створює теку чарта разом із загальними файлами та +теками, що використовуються в чартах. + +Наприклад, `helm create foo` створить структуру тек, що виглядає +приблизно так: + +```none + foo/ + ├── .helmignore # Містить шаблони для ігнорування при упаковці Helm-чартів. + ├── Chart.yaml # Інформація про ваш чарт + ├── values.yaml # Стандартні значення для ваших шаблонів + ├── charts/ # Чарти, від яких залежить цей чарт + └── templates/ # Файли шаблонів + └── tests/ # Файли тестів +``` + +`helm create` приймає шлях як аргумент. Якщо теки у вказаному шляху не існують, Helm спробує створити їх по ходу. Якщо вказане призначення існує і там є файли, конфліктуючі файли будуть перезаписані, але інші файли залишаться незмінними. + +```none +helm create NAME [flags] +``` + +### Параметри {#options} + +```none + -h, --help довідка для create + -p, --starter string імʼя або абсолютний шлях до стартового шаблону Helm +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### Дивіться також {#see-also} + +* [helm](helm.md) — Менеджер пакетів Helm для Kubernetes. + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_delete.md b/content/uk/docs/helm/helm_delete.md new file mode 100644 index 000000000..80dbef21a --- /dev/null +++ b/content/uk/docs/helm/helm_delete.md @@ -0,0 +1,7 @@ +--- +section: deprecated +--- + +## helm delete + +Цю команду було перейменовано. Будь ласка, зверніться до [helm uninstall](helm_uninstall). diff --git a/content/uk/docs/helm/helm_dependency.md b/content/uk/docs/helm/helm_dependency.md new file mode 100644 index 000000000..8e5f81328 --- /dev/null +++ b/content/uk/docs/helm/helm_dependency.md @@ -0,0 +1,82 @@ +--- +title: "Helm Dependency" +--- + +## helm dependency + +керування залежностями чарту + +### Опис {#synopsis} + +Керуйте залежностями чарту. + +Чарти Helm зберігають свої залежності в теці `charts/`. Для розробників чарту часто простіше керувати залежностями у файлі `Chart.yaml`, який декларує всі залежності. + +Команди залежностей працюють з цим файлом, полегшуючи синхронізацію між бажаними залежностями та фактичними залежностями, збереженими в теці `charts/`. + +Наприклад, цей файл Chart.yaml декларує дві залежності: + +```yaml +# Chart.yaml +dependencies: +- name: nginx + version: "1.2.3" + repository: "https://example.com/charts" +- name: memcached + version: "3.2.1" + repository: "https://another.example.com/charts" +``` + +Поле 'name' повинно містити імʼя чарту, яке повинно збігатися з імʼям у файлі 'Chart.yaml' цього чарту. + +Поле 'version' повинно містити семантичну версію або діапазон версій. + +URL-адреса 'repository' повинна вказувати на репозиторій чарту. Helm очікує, що додавання '/index.yaml' до URL-адреси дозволить отримати індекс репозиторію чарту. Примітка: 'repository' може бути псевдонімом, який повинен починатися з 'alias:' або '@'. + +Починаючи з версії 2.2.0, репозиторій може бути визначений як шлях до теки залежних чартів, збережених локально. Шлях повинен починатися з префіксу "file://". Наприклад, + +```yaml +# Chart.yaml +dependencies: +- name: nginx + version: "1.2.3" + repository: "file://../dependency_chart/nginx" +``` + +Якщо залежний чарт отримано локально, його не потрібно додавати до helm за допомогою команди "helm repo add". Підтримується також відповідність версій для цього випадку. + +### Параметри {#options} + +```none + -h, --help довідка для dependency +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації підучас операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для викорисуання + --kube-insecure-skip-tls-verify якщо встановлено truу, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить вашу HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифікату сервера API Kubernetes. Якщо уе вказано, використовується імʼя хоста, що використовуєтуся для пудключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconуig + -n, --namespace string простір імен для цього запиту + --qps float32 у кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### Дивіться також {#see-also} + +* [helm](helm.md) — Менеджер пакетів Helm для Kubernetes. +* [helm dependency build](helm_dependency_build.md) — відновлення теки charts/ на основі файлу Chart.lock +* [helm dependency list](helm_dependency_list.md) — перелік залежностей для даного чарта +* [helm dependency update](helm_dependency_update.md) — оновлення charts/ на основі вмісту Chart.yaml + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_dependency_build.md b/content/uk/docs/helm/helm_dependency_build.md new file mode 100644 index 000000000..76376921b --- /dev/null +++ b/content/uk/docs/helm/helm_dependency_build.md @@ -0,0 +1,55 @@ +--- +title: "Helm Dependency Build" +--- + +## helm dependency build + +перебудувати теку charts/ на основі файлу Chart.lock + +### Опис {#synopsis} + +Ця команда будує теку `charts/` на основі файлу `Chart.lock`. + +Команда `build` використовується для відновлення залежностей чарту до стану, зазначеного у файлі блокування. Вона не переузгоджуватиме залежності, як це робить `helm dependency update`. + +Якщо файл блокування не знайдено, `helm dependency build` дзеркально повторюватиме поведінку команди `helm dependency update`. + +```none +helm dependency build CHART [flags] +``` + +### Параметри {#options} + +```none + -h, --help довідка для build + --keyring string вʼязка ключів, що містить публічні ключі (стандартно "~/.gnupg/pubring.gpg") + --skip-refresh не оновлювати кеш локального репозиторію + --verify перевіряти пакети за підписами +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### Дивіться також {#see-also} + +* [helm dependency](helm_dependency.md) — керувати залежностями чарту + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_dependency_list.md b/content/uk/docs/helm/helm_dependency_list.md new file mode 100644 index 000000000..298fed7a0 --- /dev/null +++ b/content/uk/docs/helm/helm_dependency_list.md @@ -0,0 +1,53 @@ +--- +title: "Helm Dependency List" +--- + +## helm dependency list + +список залежностей для заданого чарту + +### Опис {#synopsis} + +Перелічує всі залежності, зазначені в чарті. + +Ця команда приймає на вхід як архіви чарту, так і теки чарту. Вона не змінює вміст чарту. + +Викликається помилка, якщо чарт не може бути завантажений. + +```none +helm dependency list CHART [flags] +``` + +### Параметри {#options} + +```none + -h, --help довідка для list + --max-col-width uint максимальна ширина стовпця для таблиці виводу (стандартно 80) +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### Дивіться також {#see-also} + +* [helm dependency](helm_dependency.md) — керувати залежностями чарту + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_dependency_update.md b/content/uk/docs/helm/helm_dependency_update.md new file mode 100644 index 000000000..ebae9b60c --- /dev/null +++ b/content/uk/docs/helm/helm_dependency_update.md @@ -0,0 +1,57 @@ +--- +title: "Helm Dependency Update" +--- + +## helm dependency update + +оновлення charts/ на основі вмісту Chart.yaml + +### Опис {#synopsis} + +Оновлює залежності на диску, щоб відобразити стан, зазначений у Chart.yaml. + +Ця команда перевіряє, що необхідні чарти, зазначені в `Chart.yaml`, присутні в `charts/` і відповідають прийнятній версії. Вона завантажує найновіші чарти, що задовольняють залежності, та очищає застарілі залежності. + +У разі успішного оновлення буде згенеровано файл блокування, який можна використовувати для відновлення залежностей до точної версії. + +Залежності не обовʼязково повинні бути представлені в `Chart.yaml`. З цієї причини команда оновлення не видалить чарти, якщо вони (а) присутні у файлі `Chart.yaml`, але (б) мають неправильну версію. + +```none +helm dependency update CHART [flags] +``` + +### Параметри {#options} + +```none + -h, --help довідка для update + --keyring string вʼязка ключів, що містить публічні ключі (стандартно "~/.gnupg/pubring.gpg") + --skip-refresh не оновлювати локальний кеш репозиторіїв + --verify перевірити пакети на відповідність підписам +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### Дивіться також {#see-also} + +* [helm dependency](helm_dependency.md) — керувати залежностями чарту + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_env.md b/content/uk/docs/helm/helm_env.md new file mode 100644 index 000000000..f57fabd42 --- /dev/null +++ b/content/uk/docs/helm/helm_env.md @@ -0,0 +1,48 @@ +--- +title: "Helm Env" +--- + +## helm env + +інформація про середовище клієнта Helm + +### Опис {#synopsis} + +Команда `helm env` виводить усю інформацію про середовище, яке використовується Helm. + +```shell +helm env [flags] +``` + +### Параметри {#options} + +```none + -h, --help довідка для env +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +``` + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### Дивіться також {#see-also} + +* [helm](helm.md) — Менеджер пакетів Helm для Kubernetes. + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_get.md b/content/uk/docs/helm/helm_get.md new file mode 100644 index 000000000..f5da53a02 --- /dev/null +++ b/content/uk/docs/helm/helm_get.md @@ -0,0 +1,56 @@ +--- +title: "Helm Get" +--- + +## helm get + +завантажити розширену інформацію про вказаний реліз + +### Опис {#synopsis} + +Ця команда складається з кількох підкоманд, які можна використовувати для отримання розширеної інформації про реліз, включаючи: + +- Значення, що використовувалися для генерації релізу +- Сформований файл маніфесту +- Примітки, надані чартом релізу +- Хуки, асоційовані з релізом +- Метадані релізу + +### Параметри {#options} + +```none + -h, --help довідка для get +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### Дивіться також {#see-also} + +- [helm](helm.md) — Менеджер пакетів Helm для Kubernetes. +- [helm get all](helm_get_all.md) — завантажити всю інформацію про вказаний реліз +- [helm get hooks](helm_get_hooks.md) — завантажити всі хуки для вказаного релізу +- [helm get manifest](helm_get_manifest.md) — завантажити маніфест для вказаного релізу +- [helm get metadata](helm_get_metadata.md) — отримати метадані для вказаного релізу +- [helm get notes](helm_get_notes.md) — завантажити примітки для вказаного релізу +- [helm get values](helm_get_values.md) — завантажити файл значень для вказаного релізу + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_get_all.md b/content/uk/docs/helm/helm_get_all.md new file mode 100644 index 000000000..af836e37a --- /dev/null +++ b/content/uk/docs/helm/helm_get_all.md @@ -0,0 +1,50 @@ +--- +title: "Helm Get All" +--- + +## helm get all + +завантажити всю інформацію про вказаний реліз + +### Опис {#synopsis} + +Ця команда виводить зрозумілий для людини набір інформації про нотатки, хуки, надані значення та згенерований маніфест для вказаного релізу. + +```shell +helm get all RELEASE_NAME [flags] +``` + +### Параметри {#options} + +```none + -h, --help довідка для all + --revision int отримати вказаний реліз з версією + --template string шаблон Go для форматування виводу, напр: {{.Release.Name}} +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### Дивіться також {#see-also} + +* [helm get](helm_get.md) — завантажити розширену інформацію про вказаний реліз + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_get_hooks.md b/content/uk/docs/helm/helm_get_hooks.md new file mode 100644 index 000000000..73326ac14 --- /dev/null +++ b/content/uk/docs/helm/helm_get_hooks.md @@ -0,0 +1,51 @@ +--- +title: "Helm Get Hooks" +--- + +## helm get hooks + +завантажити всі хуки для вказаного релізу + +### Опис {#synopsis} + +Ця команда завантажує хуки для вказаного релізу. + +Хуки форматуються у YAML і розділені роздільником YAML '---\n'. + +```shell +helm get hooks RELEASE_NAME [flags] +``` + +### Параметри + +```none + -h, --help довідка для hooks + --revision int отримати вказаний реліз з версією +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (станлартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (станлартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (станлартно "~/.config/helm/repositories.yaml") +``` + +### Дивіться також {#see-also} + +* [helm get](helm_get.md) — завантажити розширену інформацію про вказаний реліз + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_get_manifest.md b/content/uk/docs/helm/helm_get_manifest.md new file mode 100644 index 000000000..7c08b85b0 --- /dev/null +++ b/content/uk/docs/helm/helm_get_manifest.md @@ -0,0 +1,51 @@ +--- +title: "Helm Get Manifest" +--- + +## helm get manifest + +завантажити маніфест для вказаного релізу + +### Опис {#synopsis} + +Ця команда завантажує згенерований маніфест для вказаного релізу. + +Маніфест є YAML-кодованим представленням ресурсів Kubernetes, які були згенеровані з чарту(ів) цього релізу. Якщо чарт залежить від інших чартів, ці ресурси також будуть включені в маніфест. + +```shell +helm get manifest RELEASE_NAME [flags] +``` + +### Параметри {#options} + +```none + -h, --help довідка для manifest + --revision int отримати вказаний реліз з версією +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### Дивіться також {#see-also} + +* [helm get](helm_get.md) — завантажити розширену інформацію про вказаний реліз + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_get_metadata.md b/content/uk/docs/helm/helm_get_metadata.md new file mode 100644 index 000000000..2a865661c --- /dev/null +++ b/content/uk/docs/helm/helm_get_metadata.md @@ -0,0 +1,46 @@ +--- +title: "Helm Get Metadata" +--- + +## helm get metadata + +Ця команда завантажує метадані для вказаного релізу + +```shell +helm get metadata RELEASE_NAME [flags] +``` + +### Параметри {#options} + +```none + -h, --help довідка для metadata + -o, --output format виводить результати у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table) + --revision int вказати версію релізу +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### Дивіться також {#see-also} + +* [helm get](helm_get.md) — завантажити розширену інформацію про вказаний реліз + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_get_notes.md b/content/uk/docs/helm/helm_get_notes.md new file mode 100644 index 000000000..07ad427b0 --- /dev/null +++ b/content/uk/docs/helm/helm_get_notes.md @@ -0,0 +1,49 @@ +--- +title: "Helm Get Notes" +--- + +## helm get notes + +завантажити нотатки для вказаного релізу + +### Опис {#synopsis} + +Ця команда відображає нотатки, надані чартом для вказаного релізу. + +```shell +helm get notes RELEASE_NAME [flags] +``` + +### Параметри + +```none + -h, --help довідка для notes + --revision int отримати реліз з вказаною версією +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### Дивіться також {#see-also} + +* [helm get](helm_get.md) — завантажити розширену інформацію про вказаний реліз + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_get_values.md b/content/uk/docs/helm/helm_get_values.md new file mode 100644 index 000000000..0869b85bb --- /dev/null +++ b/content/uk/docs/helm/helm_get_values.md @@ -0,0 +1,51 @@ +--- +title: "Helm Get Values" +--- + +## helm get values + +завантажити файл значень для вказаного релізу + +### Опис {#synopsis} + +Ця команда завантажує файл значень для вказаного релізу. + +```shell +helm get values RELEASE_NAME [flags] +``` + +### Параметри {#options} + +```none + -a, --all вивести всі (обчислені) значення + -h, --help довідка для values + -o, --output format друкує вихід у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table) + --revision int отримати реліз з вказаною версією +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### Дивіться також {#see-also} + +* [helm get](helm_get.md) — завантажити розширену інформацію про вказаний реліз + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_history.md b/content/uk/docs/helm/helm_history.md new file mode 100644 index 000000000..b17372702 --- /dev/null +++ b/content/uk/docs/helm/helm_history.md @@ -0,0 +1,63 @@ +--- +title: "Helm History" +--- + +## helm history + +отримати історію релізу + +### Опис {#synopsis} + +History виводить історичні ревізії для вказаного релізу. + +Стандартна максимальна кількість ревізій, що повертається — 256. Встановлення '--max' налаштовує максимальну довжину списку ревізій, що повертаються. + +Історичний набір релізів виводиться у вигляді відформатованої таблиці, наприклад: + +```console +$ helm history angry-bird +REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION +1 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Initial install +2 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Upgraded successfully +3 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Rolled back to 2 +4 Mon Oct 3 10:15:13 2016 deployed alpine-0.1.0 1.0 Upgraded successfully +``` + +```shell +helm history RELEASE_NAME [flags] +``` + +### Параметри {#options} + +```none + -h, --help довідка для history + --max int максимальна кількість ревізій, включених в історію (стандартно 256) + -o, --output format виводити результат у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table) +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### Дивіться також {#see-also} + +* [helm](helm.md) — Менеджер пакетів Helm для Kubernetes. + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_init.md b/content/uk/docs/helm/helm_init.md new file mode 100644 index 000000000..37cfd2a2a --- /dev/null +++ b/content/uk/docs/helm/helm_init.md @@ -0,0 +1,9 @@ +--- +section: deprecated +--- + +## helm init + +Цієї команди не існує в Helm 3, після [видалення Tiller](https://helm.sh/docs/faq/#removal-of-tiller). Тепер вам не потрібно встановлювати Tiller у вашому кластері для використання Helm. + +Якщо ви використовуєте Helm 2, перейдіть на [v2.helm.sh](https://v2.helm.sh/docs/helm/#helm-init), щоб переглянути [документацію Helm Init](https://v2.helm.sh/docs/helm/#helm-init). diff --git a/content/uk/docs/helm/helm_inspect.md b/content/uk/docs/helm/helm_inspect.md new file mode 100644 index 000000000..a5d987838 --- /dev/null +++ b/content/uk/docs/helm/helm_inspect.md @@ -0,0 +1,7 @@ +--- +section: deprecated +--- + +## helm inspect + +Цю команду було перейменовано. Натомість зверніться до команди [helm show](../helm_show/). diff --git a/content/uk/docs/helm/helm_install.md b/content/uk/docs/helm/helm_install.md new file mode 100644 index 000000000..6f5a40923 --- /dev/null +++ b/content/uk/docs/helm/helm_install.md @@ -0,0 +1,164 @@ +--- +title: "Helm Install" +--- + +## helm install + +Встановлює чарт + +### Опис {#synopsis} + +Ця команда встановлює архів чарту. + +Аргумент для `install` має бути посиланням на чарт, шляхом до запакованого чарту, шляхом до розпакованої теки чарту або URL. + +Щоб перезаписати значення в чартах, використовуйте прапорець `--values` та передайте файл або прапорець `--set`, щоб передати конфігурацію з командного рядка. Щоб примусово встановити значення рядка, використовуйте `--set-string`. Ви також можете використовувати `--set-file`, щоб задати окремі значення з файлу, якщо значення занадто велике для командного рядка або є динамічно згенерованим. Ви також можете використовувати `--set-json`, щоб встановити значення JSON (скаляри/обʼєкти/масиви) з командного рядка. + +```shell +$ helm install -f myvalues.yaml myredis ./redis +``` + +або + +```shell +$ helm install --set name=prod myredis ./redis +``` + +або + +```shell +$ helm install --set-string long_int=1234567890 myredis ./redis +``` + +або + +```shell +$ helm install --set-file my_script=dothings.sh myredis ./redis +``` + +або + +```shell +$ helm install --set-json 'master.sidecars=[{"name":"sidecar","image":"myImage","imagePullPolicy":"Always","ports":[{"name":"portname","containerPort":1234}]}]' myredis ./redis +``` + +Ви можете вказати прапорець `--values`/'-f' кілька разів. Пріоритет буде наданий останньому (правому) файлу, що вказаний. Наприклад, якщо як `myvalues.yaml`, так і `override.yaml` містять ключ `Test`, значення, встановлене в `override.yaml`, матиме пріоритет: + +```shell +$ helm install -f myvalues.yaml -f override.yaml myredis ./redis +``` + +Ви можете вказати прапорець `--set` кілька разів. Пріоритет буде наданий останньому (правому) встановленому значенню. Наприклад, якщо для ключа `foo` встановлені значення `bar` і `newbar`, значення `newbar` матиме пріоритет: + +```shell +$ helm install --set foo=bar --set foo=newbar myredis ./redis +``` + +Аналогічно, у наступному прикладі `foo` встановлено в `["four"]`: + +```shell +$ helm install --set-json='foo=["one", "two", "three"]' --set-json='foo=["four"]' myredis ./redis +``` + +А в наступному прикладі `foo` встановлено в `{"key1":"value1","key2":"bar"}`: + +```shell +$ helm install --set-json='foo={"key1":"value1","key2":"value2"}' --set-json='foo.key2="bar"' myredis ./redis +``` + +Щоб перевірити згенеровані маніфести релізу без встановлення чарту, можна поєднати прапорці `--debug` і `--dry-run`. + +Якщо встановлено прапорець `--verify`, чарт ПОВИНЕН мати файл автентифікації, і цей файл ПОВИНЕН пройти всі кроки перевірки. + +Є шість різних способів казати чарт, який ви хочете встановити: + +1. З посиланням на чарт: `helm install mymaria example/mariadb` +2. З шляхом до запакованого чарту: `helm install mynginx ./nginx-1.2.3.tgz` +3. З шляхом до розпакованої теки чарту: `helm install mynginx ./nginx` +4. З абсолютним URL: `helm install mynginx https://example.com/charts/nginx-1.2.3.tgz` +5. З посиланням на чарт і URL репозиторію: `helm install --repo https://example.com/charts/ mynginx nginx` +6. З OCI реєстрами: `helm install mynginx --version 1.2.3 oci://example.com/charts/nginx` + +ПОСИЛАННЯ НА ЧАРТ + +Посилання на чарт — це зручний спосіб посилатися на чарт у репозиторії чарту. + +Коли ви використовуєте посилання на чарт з префіксом репозиторію (`example/mariadb`), Helm шукатиме в локальній конфігурації репозиторій чарту з імʼям `example`, а потім шукатиме чарт у цьому репозиторії, чия назва є `mariadb`. Він встановить останню стабільну версію цього чарту, поки ви не вкажете прапорець `--devel`, щоб також включити версії розробки (альфа, бета та реліз-кандидати), або не надасте номер версії за допомогою прапорця `--version`. + +Щоб переглянути список репозиторіїв чартів, використовуйте `helm repo list`. Щоб шукати чарти в репозиторії, використовуйте `helm search`. + +```shell +helm install [NAME] [CHART] [flags] +``` + +### Параметри {#options} + +```none + --atomic якщо вказано, процес встановлення видалить всnановлення у разі невдачі. Прапорець --wait буде встановлено автоматично, якщо використовується --atomic + --ca-file string перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету + --cert-file string ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату + --create-namespace створити простір імен релізу, якщо його не існує + --description string додати власний опис + --devel використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується. + --disable-openapi-validation якщо вказано, процес встановлення не буде перевіряти відрендерені шаблони за схемою OpenAPI Kubernetes + --dry-run string[="client"] імітувати встановлення. Якщо --dry-run вказано без жодної опції або як '--dry-run=client', він не буде намагатися підключитися до кластера. Встановлення '--dry-run=server' дозволяє намагатися підключитися до кластера. + --enable-dns увімкнути DNS запити при рендерингу шаблонів + --force примусово оновлювати ресурси через стратегію заміни + -g, --generate-name згенерувати імʼя (та опустити параметр NAME) + -h, --help довідка install + --insecure-skip-tls-verify пропустити перевірку сертифікатів TLS для завантаження чарту + --key-file string ідентифікувати клієнта HTTPS за допомогою цього SSL ключового файлу + --keyring string розташування публічних ключів, що використовуються для перевірки (стандартно "~/.gnupg/pubring.gpg") + -l, --labels stringToString Мітки, які будуть додані до метаданих релізу. Мають бути розділені комами. (стандартно []) + --name-template string вказати шаблон для назви релізу + --no-hooks запобігти виконанню хуків під час встановлення + -o, --output format виводить результат у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table) + --pass-credentials передати облікові дані всім доменам + --password string пароль до репозиторію чартів, де розташований запитуваний чарт + --plain-http використовувати небезпечні HTTP зʼєднання для завантаження чарту + --post-renderer postRendererString шлях до виконуваного файлу, що використовується для пост-рендерингу. Якщо він існує в $PATH, буде використано двійковий файл, в іншому випадку буде намагатися знайти виконуваний файл за вказаним шляхом + --post-renderer-args postRendererArgsSlice аргумент до пост-рендерера (можна вказати кілька) (стандартно []) + --render-subchart-notes якщо вказано, рендерити нотатки субчартів разом з батьківським + --replace повторно використовувати дане імʼя, тільки якщо це імʼя є вилученим релізом, який залишається в і єсторії. Це є небезпечним в операційному середовищі + --repo string URL репозиторію чартів, де розташований запитуваний чарт + --set stringArray встановити значення в командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2) + --set-file stringArray встановити значення з відповідних файлів, що вказані через командний рядок (можна вказати кілька або розділити значення комами: key1=path1,key2=pshellath2) + --set-json stringArray встановити значення JSON в командному рядку (можна вказати кілька або розділити значення комами: key1=jsonval1,key2=jsonval2) + --set-literal stringArray встановити літеральне значення STRING в командному рядку + --set-string stringArray встановити значення STRING на командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2) + --skip-crds якщо вказано, CRD не буде встановлено. Стандартно CRD встановлюються, якщо їх ще немає + --timeout duration час очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хуків) (стандартно 5м0с) + --username string імʼя користувача репозиторію чартів, де розташований запитуваний чарт + -f, --values strings вказати значення в YAML файлі або URL (можна вказати кілька) + --verify перевірити пакет перед використанням + --version string вказати обмеження версії для версії чарта, яку слід використовувати. Це обмеження може бути конкретним теґом (наприклад, 1.1.1) або може посилатися на допустимий діапазон (наприклад, ^2.0.0). Якщо це не вказано, використовується остання версія + --wait якщо вказано, буде чекати, поки всі Pods, PVCs, Сервіси і мінімальна кількість Pods Deployment, StatefulSet або ReplicaSet не будуть готові перед позначенням релізу як успішного. Чекати буде стільки, скільки встановлено --timeout + --wait-for-jobs якщо вказано і --wait увімкнено, чекатиме, поки всі Jobs не будуть завершені перед позначенням релізу як успішного. Чекати буде стільки, скільки встановлено --timeout +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +* [helm](helm.md) — Менеджер пакетів Helm для Kubernetes. + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_lint.md b/content/uk/docs/helm/helm_lint.md new file mode 100644 index 000000000..b55cae3ea --- /dev/null +++ b/content/uk/docs/helm/helm_lint.md @@ -0,0 +1,60 @@ +--- +title: "Helm Lint" +--- + +## helm lint + +перевіряє чарт на можливі проблеми + +### Опис {#synopsis} + +Ця команда приймає шлях до чарту і виконує ряд тестів, щоб перевірити, чи чарт добре сформований. + +Якщо лінтер знайде речі, які можуть призвести до помилки при встановленні чарту, він видасть повідомлення [ERROR]. Якщо він знайде проблеми, які порушують конвенції або рекомендації, він видасть повідомлення [WARNING]. + +```shell +helm lint PATH [flags] +``` + +### Параметри {#options} + +```none + -h, --help довідка lint + --kube-version string версія Kubernetes, що використовується для перевірки можливостей і застарілостей + --quiet виводити лише попередження та помилки + --set stringArray встановити значення в командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2) + --set-file stringArray встановити значення з відповідних файлів, зазначених через командний рядок (можна вказати кілька або розділити значення комами: key1=path1,key2=path2) + --set-json stringArray встановити JSON-значення в командному рядку (можна вказати кілька або розділити значення комами: key1=jsonval1,key2=jsonval2) + --set-literal stringArray встановити літеральне STRING-значення в командному рядку + --set-string stringArray встановити STRING-значення в командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2) + --strict видавати стан помилки на попередженнях lint + -f, --values strings вказати значення в YAML-файлі або URL (можна вказати кілька) + --with-subcharts перевірити залежні чарти +``` + +### Опції, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ + +* [helm](helm.md) — Менеджер пакетів Helm для Kubernetes. + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_list.md b/content/uk/docs/helm/helm_list.md new file mode 100644 index 000000000..0de17ff1d --- /dev/null +++ b/content/uk/docs/helm/helm_list.md @@ -0,0 +1,82 @@ +--- +title: "Helm List" +--- + +## helm list + +Перегляд релізів + +### Опис {#synopsis} + +Ця команда виводить список усіх релізів для вказаного простору імен (використовується поточний контекст простору імен, якщо не вказано). + +Стандартно вона перераховує тільки ті релізи, які розгорнуті або зазнали невдачі. Прапорці, такі як `--uninstalled` і `--all`, змінюють цю поведінку. Такі прапорці можна комбінувати: `--uninstalled --failed`. + +Як правило елементи сортуються в алфавітному порядку. Використовуйте прапорець `-d`, щоб сортувати за датою релізу. + +Якщо надано прапорець `--filter`, він буде використовуватися як фільтр. Фільтри є регулярними виразами (сумісними з Perl), які застосовуються до списку релізів. Будуть повернуті тільки ті елементи, які відповідають фільтру. + +```console +$ helm list --filter 'ara[a-z]+' +NAME UPDATED CHART +maudlin-arachnid 2020-06-18 14:17:46.125134977 +0000 UTC alpine-0.1.0 +``` + +Якщо результати не знайдені, команда `helm list` завершиться з кодом 0, але без виводу (або, у випадку без прапорця `-q`, тільки заголовки). + +Стандартно повертається до 256 елементів. Щоб обмежити це, використовуйте прапорець `--max`. Встановлення `--max` в 0 не поверне всі результати. Замість цього повернеться стандартне значення сервера, яке може бути значно більше ніж 256. Поєднання прапорців `--max` та `--offset` дозволяє переглядати результати посторінково. + +```shell +helm list [flags] +``` + +### Параметри {#options} + +```none + -a, --all показати всі релізи без жодного фільтра + -A, --all-namespaces список релізів по всіх просторах імен + -d, --date сортувати за датою релізу + --deployed показати розгорнуті релізи. Якщо нічого іншого не вказано, це буде автоматично увімкнено + --failed показати релізи з помилками + -f, --filter string регулярний вираз (сумісний з Perl). Будь-які релізи, що відповідають виразу, будуть включені в результати + -h, --help довідка list + -m, --max int максимальна кількість релізів для отримання (стандартно 256) + --no-headers не друкувати заголовки при використанні стандартного формату виводу + --offset int наступний індекс релізу у списку, використовується для зсуву від початкового значення + -o, --output format виводить результат у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table) + --pending показати невирішені релізи + -r, --reverse змінити порядок сортування на зворотний + -l, --selector string Селектор (запит за міткою) для фільтрації, підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Працює тільки для сховищ secret (стандартно) та configmap. + -q, --short короткий (тихий) формат виводу + --superseded показати замінені релізи + --time-format string форматувати час, використовуючи форматувальник часу golang. Приклад: --time-format "2006-01-02 15:04:05Z0700" + --uninstalled показати видалені релізи (якщо використовувався `helm uninstall --keep-history`) + --uninstalling показати релізи, які в даний час видаляються +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +* [helm](helm.md) — Менеджер пакетів Helm для Kubernetes. + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_package.md b/content/uk/docs/helm/helm_package.md new file mode 100644 index 000000000..8abbd2021 --- /dev/null +++ b/content/uk/docs/helm/helm_package.md @@ -0,0 +1,66 @@ +--- +title: "Helm Package" +--- + +## helm package + +упакувати теку чарту в архів чартів + +### Опис {#synopsis} + +Ця команда упаковує чарт в архів чартів з версією. Якщо вказано шлях, команда перевіряє цей шлях на наявність чарту (який повинен містити файл `Chart.yaml`) і потім упаковує цю теку. + +Архіви чартів з версією використовуються репозиторіями пакетів Helm. + +Щоб підписати чарт, використовуйте прапорець `--sign`. У більшості випадків вам також слід вказати `--keyring path/to/secret/keys` та `--key keyname`. + +```shell +helm package --sign ./mychart --key mykey --keyring ~/.gnupg/secring.gpg +``` + +Якщо `--keyring` не вказано, Helm зазвичай використовує публічний ключ, якщо тільки ваше середовище не налаштоване інакше. + +```shell +helm package [CHART_PATH] [...] [flags] +``` + +### Параметри {#options} + +```none + --app-version string встановити appVersion в чарті на цю версію + -u, --dependency-update оновити залежності з "Chart.yaml" в теці "charts/" перед упаковкою + -d, --destination string місце для запису чарту. (стандатно ".") + -h, --help довідка package + --key string імʼя ключа для використання під час підписання. Використовується, якщо `--sign` є true + --keyring string місце для публічного ключа (стандартно "~/.gnupg/pubring.gpg") + --passphrase-file string місце розташування файлу, що містить пароль для ключа підпису. Використовуйте "-" для читання з stdin. + --sign використовувати приватний ключ PGP для підписання цього пакету + --version string встановити версію чарту на цю версію semver +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +* [helm](helm.md) — Менеджер пакетів Helm для Kubernetes. + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_plugin.md b/content/uk/docs/helm/helm_plugin.md new file mode 100644 index 000000000..73c612be9 --- /dev/null +++ b/content/uk/docs/helm/helm_plugin.md @@ -0,0 +1,48 @@ +--- +title: "Helm Plugin" +--- + +## helm plugin + +встановлення, перегляд списку або видалення втулків Helm + +### Опис {#synopsis} + +Керування втулками Helm на стороні клієнта. + +### Параметри {#options} + +```none + -h, --help довідка plugin +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +* [helm](helm.md) — Менеджер пакетів Helm для Kubernetes. +* [helm plugin install](helm_plugin_install.md) — встановити один або кілька втулків Helm +* [helm plugin list](helm_plugin_list.md) — переглянути встановлені втулки Helm +* [helm plugin uninstall](helm_plugin_uninstall.md) — видалити один або кілька втулків Helm +* [helm plugin update](helm_plugin_update.md) — оновити один або кілька втулків Helm + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_plugin_install.md b/content/uk/docs/helm/helm_plugin_install.md new file mode 100644 index 000000000..74218f57e --- /dev/null +++ b/content/uk/docs/helm/helm_plugin_install.md @@ -0,0 +1,49 @@ +--- +title: "Helm Plugin Install" +--- + +## helm plugin install + +встановити один або кілька втулків Helm + +### Опис {#synopsis} + +Ця команда дозволяє встановити втулок з URL до VCS репозиторію або з локального шляху. + +```shell +helm plugin install [options] ... [flags] +``` + +### Параметри {#options} + +```none + -h, --help довідка install + --version string вказати обмеження версії. Якщо це не вказано, буде встановлена остання версія +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +* [helm plugin](helm_plugin.md) — встановити, вивести перелік або видалити втулки Helm + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_plugin_list.md b/content/uk/docs/helm/helm_plugin_list.md new file mode 100644 index 000000000..f0bbc0820 --- /dev/null +++ b/content/uk/docs/helm/helm_plugin_list.md @@ -0,0 +1,44 @@ +--- +title: "Helm Plugin List" +--- + +## helm plugin list + +вивести перелік встановлених втулків Helm + +```shell +helm plugin list [flags] +``` + +### Параметри {#options} + +```none + -h, --help довідка list +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +* [helm plugin](helm_plugin.md) — встановити, вивести перелік або видалити втулки Helm + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_plugin_uninstall.md b/content/uk/docs/helm/helm_plugin_uninstall.md new file mode 100644 index 000000000..399249d41 --- /dev/null +++ b/content/uk/docs/helm/helm_plugin_uninstall.md @@ -0,0 +1,44 @@ +--- +title: "Helm Plugin Uninstall" +--- + +## helm plugin uninstall + +видалити один або кілька втулків Helm + +```shell +helm plugin uninstall ... [flags] +``` + +### Параметри {#options} + +```none + -h, --help довідка uninstall +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +* [helm plugin](helm_plugin.md) — встановити, вивести перелік або видалити втулки Helm + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_plugin_update.md b/content/uk/docs/helm/helm_plugin_update.md new file mode 100644 index 000000000..04e5603ab --- /dev/null +++ b/content/uk/docs/helm/helm_plugin_update.md @@ -0,0 +1,44 @@ +--- +title: "Helm Plugin Update" +--- + +## helm plugin update + +оновити один або кілька втулків Helm + +```shell +helm plugin update ... [flags] +``` + +### Параметри {#options} + +```none + -h, --help довідка update +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +* [helm plugin](helm_plugin.md) — встановити, вивести перелік або видалити втулки Helm + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_pull.md b/content/uk/docs/helm/helm_pull.md new file mode 100644 index 000000000..f0cdf2d73 --- /dev/null +++ b/content/uk/docs/helm/helm_pull.md @@ -0,0 +1,71 @@ +--- +title: "Helm Pull" +--- + +## helm pull + +завантажити чарт з репозиторію та (за бажанням) розпакувати його в локальну теку + +### Опис {#synopsis} + +Отримати пакет із репозиторію пакетів та завантажити його локально. + +Це корисно для отримання пакетів для інспекції, модифікації або перепакування. Також це можна використовувати для криптографічної перевірки чарту без його встановлення. + +Існують параметри для розпакування чарту після завантаження. Це створить теку для чарту та розпакує в неї файли. + +Якщо вказано прапорець `--verify`, запитуваний чарт ПОВИНЕН мати файл підтвердження автентичності та ПОВИНЕН пройти процес перевірки. Будь-яка помилка призведе до помилки, і чарт не буде збережено локально. + +```shell +helm pull [URL чарта | репозиторій/назвачартa] [...] [flags] +``` + +### Параметри {#options} + +```none + --ca-file string перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету + --cert-file string ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату + -d, --destination string місце для збереження чарту. Якщо вказано разом із untardir, то untardir буде додано до нього (стандартно ".") + --devel використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується. + -h, --help довідка pull + --insecure-skip-tls-verify пропустити перевірку TLS-сертифікатів для завантаження чарту + --key-file string ідентифікувати HTTPS-клієнта за допомогою цього SSL-ключа + --keyring string місце розташування публічних ключів для перевірки (стандартно "~/.gnupg/pubring.gpg") + --pass-credentials передавати облікові дані всім доменам + --password string пароль для репозиторію чарта, де знаходиться запитуваний чарт + --plain-http використовувати незахищені HTTP-зʼєднання для завантаження чарта + --prov завантажити файл підтвердження автентичності, але не виконувати перевірку + --repo string URL репозиторію чарта, де знаходиться запитуваний чарт + --untar якщо встановлено, чарт буде розпаковано після завантаження + --untardir string якщо вказано untar, цей прапорець вказує назву теки, в яку буде розпаковано чарт (стандартно ".") + --username string імʼя користувача для репозиторію чарта, де знаходиться запитуваний чарт + --verify перевірити пакет перед використанням + --version string вказати обмеження на версію чарта для використання. Це обмеження може бути конкретною міткою (наприклад, 1.1.1) або посилатися на допустимий діапазон (наприклад, ^2.0.0). Якщо не вказано, використовується остання версія +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +* [helm](helm.md) — Менеджер пакетів Helm для Kubernetes. + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_push.md b/content/uk/docs/helm/helm_push.md new file mode 100644 index 000000000..a019bba78 --- /dev/null +++ b/content/uk/docs/helm/helm_push.md @@ -0,0 +1,55 @@ +--- +title: "Helm Push" +--- + +## helm push + +завантажити чарт на віддалений сервер + +### Опис {#synopsis} + +Завантаження чарту до реєстру. + +Якщо чарт має повʼязаний файл підтвердження автентичності, він також буде завантажений. + +```shell +helm push [chart] [remote] [flags] +``` + +### Параметри {#options} + +```none + --ca-file string перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету + --cert-file string ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату + -h, --help довідка push + --insecure-skip-tls-verify пропустити перевірку tls-сертифікатів під час завантаження чарту + --key-file string ідентифікувати клієнта реєстру за допомогою цього файлу ключа SSL + --plain-http використовувати небезпечні HTTP-зʼєднання для завантаження чарту +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +* [helm](helm.md) — Менеджер пакетів Helm для Kubernetes. + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_registry.md b/content/uk/docs/helm/helm_registry.md new file mode 100644 index 000000000..d43b17fa0 --- /dev/null +++ b/content/uk/docs/helm/helm_registry.md @@ -0,0 +1,46 @@ +--- +title: "Helm Registry" +--- + +## helm registry + +вхід до або вихід з реєстру + +### Опис {#synopsis} + +Ця команда містить декілька субкоманд для взаємодії з реєстрами. + +### Параметри {#options} + +```none + -h, --help довідка registry +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +* [helm](helm.md) — Менеджер пакетів Helm для Kubernetes. +* [helm registry login](helm_registry_login.md) — вхід до реєстру +* [helm registry logout](helm_registry_logout.md) — вихід з реєстру + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_registry_login.md b/content/uk/docs/helm/helm_registry_login.md new file mode 100644 index 000000000..db80bb125 --- /dev/null +++ b/content/uk/docs/helm/helm_registry_login.md @@ -0,0 +1,55 @@ +--- +title: "Helm Registry Login" +--- + +## helm registry login + +вхід до реєстру + +### Опис {#synopsis} + +Автентифікація на віддаленому реєстрі. + +```shell +helm registry login [host] [flags] +``` + +### Параметри {#options} + +```none + --ca-file string перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету + --cert-file string ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату + -h, --help довідка login + --insecure дозволити зʼєднання з TLS-реєстром без сертифікатів + --key-file string ідентифікувати клієнта реєстру за допомогою цього файлу ключа SSL + -p, --password string пароль для реєстру або токен ідентифікації + --password-stdin зчитати пароль або токен ідентифікації з stdin + -u, --username string імʼя користувача реєстру +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +* [helm](helm.md) — Менеджер пакетів Helm для Kubernetes. + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_registry_logout.md b/content/uk/docs/helm/helm_registry_logout.md new file mode 100644 index 000000000..4594d8569 --- /dev/null +++ b/content/uk/docs/helm/helm_registry_logout.md @@ -0,0 +1,48 @@ +--- +title: "Helm Registry Logout" +--- + +## helm registry logout + +вихід з реєстру + +### Опис {#synopsis} + +Видалення збережених облікових даних для віддаленого реєстру. + +```shell +helm registry logout [host] [flags] +``` + +### Параметри {#options} + +```none + -h, --help довідка logout +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +* [helm](helm.md) — Менеджер пакетів Helm для Kubernetes. + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_repo.md b/content/uk/docs/helm/helm_repo.md new file mode 100644 index 000000000..406539038 --- /dev/null +++ b/content/uk/docs/helm/helm_repo.md @@ -0,0 +1,51 @@ +--- +title: "Helm Repo" +--- + +## helm repo + +додати, вивести перелік, видалити, оновити та індексувати репозиторії чартів + +### Опис {#synopsis} + +Ця команда містить кілька субкоманд для взаємодії з репозиторіями чартів. + +Вона може використовуватися для додавання, видалення, виводу переліку та індексування репозиторіїв чартів. + +### Параметри {#options} + +```none + -h, --help довідка repo +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +* [helm](helm.md) — менеджер пакетів Helm для Kubernetes. +* [helm repo add](helm_repo_add.md) — додати репозиторій чартів +* [helm repo index](helm_repo_index.md) — згенерувати файл індексу для теки, що містить упаковані чарти +* [helm repo list](helm_repo_list.md) — вивести перелік репозиторіїв чартів +* [helm repo remove](helm_repo_remove.md) — видалити один або кілька репозиторіїв чартів +* [helm repo update](helm_repo_update.md) — оновити інформацію про доступні чарти локально з репозиторіїв чартів + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_repo_add.md b/content/uk/docs/helm/helm_repo_add.md new file mode 100644 index 000000000..3421ef598 --- /dev/null +++ b/content/uk/docs/helm/helm_repo_add.md @@ -0,0 +1,55 @@ +--- +title: "Helm Repo Add" +--- + +## helm repo add + +додати репозиторій чартів + +```shell +helm repo add [NAME] [URL] [flags] +``` + +### Параметри {#options} + +```none + --allow-deprecated-repos стандартно ця команда не дозволяє додавати офіційні репозиторії, які були назавжди видалені. Ця опція вимикає таку поведінку + --ca-file string перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету + --cert-file string ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату + --force-update замінити (перезаписати) репозиторій, якщо він уже існує + -h, --help довідка add + --insecure-skip-tls-verify пропустити перевірку tls-сертифікатів для репозиторію + --key-file string ідентифікувати HTTPS-клієнта за допомогою цього файлу ключа SSL + --no-update Ігнорується. Раніше ця опція відключала примусові оновлення. Застаріла через force-update. + --pass-credentials передавати облікові дані всім доменам + --password string пароль до репозиторію чартів + --password-stdin зчитати пароль до репозиторію чартів з stdin + --username string імʼя користувача репозиторію чартів +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +* [helm repo](helm_repo.md) — додавання, створення списку, видалення, оновлення та індексація репозиторіїв чартів + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_repo_index.md b/content/uk/docs/helm/helm_repo_index.md new file mode 100644 index 000000000..361d81eb9 --- /dev/null +++ b/content/uk/docs/helm/helm_repo_index.md @@ -0,0 +1,55 @@ +--- +title: "Helm Repo Index" +--- + +## helm repo index + +згенерувати файл індексу для теки, що містить упаковані чарти + +### Опис {#synopsis} + +Прочитати поточну теку і згенерувати файл індексу на основі знайдених чартів. + +Цей інструмент використовується для створення файлу 'index.yaml' для репозиторію чартів. Щоб встановити абсолютну URL-адресу для чартів, використовуйте прапорець '--url'. + +Щоб обʼєднати згенерований індекс із наявним файлом індексу, використовуйте прапорець '--merge'. У цьому випадку чарти, знайдені в поточній теці, будуть обʼєднані з наявним індексом, причому локальні чарти матимуть пріоритет над теперішніми. + +```shell +helm repo index [DIR] [flags] +``` + +### Параметри {#options} + +```none + -h, --help довідка index + --json вивід у форматі JSON + --merge string обʼєднати згенерований індекс із вказаним індексом + --url string URL репозиторію чартів +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +* [helm repo](helm_repo.md) — додавання, створення списку, видалення, оновлення та індексація репозиторіїв чартів + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_repo_list.md b/content/uk/docs/helm/helm_repo_list.md new file mode 100644 index 000000000..4fe8fb1e9 --- /dev/null +++ b/content/uk/docs/helm/helm_repo_list.md @@ -0,0 +1,45 @@ +--- +title: "Helm Repo List" +--- + +## helm repo list + +вивести перелік репозиторії чартів + +```shell +helm repo list [flags] +``` + +### Параметри {#options} + +```none + -h, --help довідка list + -o, --output format вивести результат у вказаному форматі. Доступні значення: table, json, yaml (стандартно table) +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +* [helm repo](helm_repo.md) — додавання, створення списку, видалення, оновлення та індексація репозиторіїв чартів + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_repo_remove.md b/content/uk/docs/helm/helm_repo_remove.md new file mode 100644 index 000000000..89b55a55a --- /dev/null +++ b/content/uk/docs/helm/helm_repo_remove.md @@ -0,0 +1,44 @@ +--- +title: "Helm Repo Remove" +--- + +## helm repo remove + +видалити один або кілька репозиторіїв чартів + +```shell +helm repo remove [REPO1 [REPO2 ...]] [flags] +``` + +### Параметри {#options} + +```none + -h, --help довідка remove +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +* [helm repo](helm_repo.md) — додавання, створення списку, видалення, оновлення та індексація репозиторіїв чартів + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_repo_update.md b/content/uk/docs/helm/helm_repo_update.md new file mode 100644 index 000000000..be15ae7ef --- /dev/null +++ b/content/uk/docs/helm/helm_repo_update.md @@ -0,0 +1,57 @@ +--- +title: "Helm Repo Update" +--- + +## helm repo update + +оновити інформацію про доступні чарти локально з репозиторіїв чартів + +### Опис {#synopsis} + +Команда update отримує останню інформацію про чарти з відповідних репозиторіїв чартів. Інформація кешується локально, де її використовують такі команди, як 'helm search'. + +Ви можете опційно вказати список репозиторіїв, які ви хочете оновити. + +```shell +helm repo update ... +``` + +Щоб оновити всі репозиторії, використовуйте 'helm repo update'. + +```shell +helm repo update [REPO1 [REPO2 ...]] [flags] +``` + +### Параметри {#options} + +```none + --fail-on-repo-update-fail оновлення не буде завершене, якщо будь-яке з оновлень репозиторіїв зазнає невдачі + -h, --help довідка update +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +* [helm repo](helm_repo.md) — додавання, створення списку, видалення, оновлення та індексація репозиторіїв чартів + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_rollback.md b/content/uk/docs/helm/helm_rollback.md new file mode 100644 index 000000000..65f1ea858 --- /dev/null +++ b/content/uk/docs/helm/helm_rollback.md @@ -0,0 +1,61 @@ +--- +title: "Helm Rollback" +--- + +## helm rollback + +відкотити реліз до попередньої версії + +### Опис {#synopsis} + +Ця команда відкотить реліз до попередньої версії. + +Перший аргумент команди rollback — це імʼя релізу, а другий — номер версії (revision). Якщо цей аргумент пропущений або встановлений на 0, реліз буде повернено до попередньої версії. + +Щоб побачити номери версій, виконайте команду 'helm history RELEASE'. + +```shell +helm rollback [REVISION] [flags] +``` + +### Параметри {#options} + +```none + --cleanup-on-fail дозволити видалення нових ресурсів, створених під час цього відкату, якщо відкат не вдається + --dry-run імітувати відкат + --force примусово оновити ресурси через видалення/пересворення, якщо потрібно + -h, --help довдідка rollback + --history-max int обмежити максимальну кількість збережених версій для кожного релізу. Використовуйте 0 для безмежної кількості (стандартно 10) + --no-hooks запобігти виконанню хуків під час відкату + --recreate-pods перезапускати podʼи для ресурсу, якщо це застосовується + --timeout duration час очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хуків) (стандартно 5m0s) + --wait якщо встановлено, буде чекати, поки всі Pods, PVCs, Services і мінімальна кількість Pods у Deployment, StatefulSet або ReplicaSet не перейдуть у стан готовності, перш ніж позначити реліз як успішний. Чекатиме стільки, скільки вказано у --timeout + --wait-for-jobs якщо встановлено і --wait увімкнено, буде чекати, поки всі Jobs не будуть завершені, перш ніж позначити реліз як успішний. Чекатиме стільки, скільки вказано у --timeout +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +* [helm](helm.md) — менеджер пакетів Helm для Kubernetes. + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_search.md b/content/uk/docs/helm/helm_search.md new file mode 100644 index 000000000..6c0df6940 --- /dev/null +++ b/content/uk/docs/helm/helm_search.md @@ -0,0 +1,47 @@ +--- +title: "Helm Search" +--- + +## helm search + +шукати ключове слово у чартах + +### Опис {#synopsis} + +Команда search надає можливість шукати Helm чарти в різних місцях, +де вони можуть зберігатися, включаючи Artifact Hub і репозиторії, які ви додали. Використовуйте субкоманди search для пошуку в різних місцях для чартів. + +### Параметри {#options} + +```none + -h, --help довідка search +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +* [helm](helm.md) — менеджер пакетів Helm для Kubernetes. +* [helm search hub](helm_search_hub.md) — шукати чарти в Artifact Hub або у власному екземплярі хабу +* [helm search repo](helm_search_repo.md) — шукати репозиторії за ключовим словом у чартах + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_search_hub.md b/content/uk/docs/helm/helm_search_hub.md new file mode 100644 index 000000000..dd217bb6c --- /dev/null +++ b/content/uk/docs/helm/helm_search_hub.md @@ -0,0 +1,59 @@ +--- +title: "Helm Search Hub" +--- + +## helm search hub + +шукати чарти в Artifact Hub або у власному екземплярі хабу + +### Опис {#synopsis} + +Шукайте Helm чарти в Artifact Hub або у власному екземплярі хабу. + +Artifact Hub — це вебзастосунок, що дозволяє знаходити, встановлювати та публікувати пакети та конфігурації для проєктів CNCF, включаючи публічно доступні розподілені Helm чарти. Це проєкт Sandbox Cloud Native Computing Foundation. Ви можете переглянути хаб за адресою https://artifacthub.io/ + +Аргумент [KEYWORD] приймає як ключове слово, так і рядок з параметрами розширеного запиту. Документацію з параметрів розширеного запиту дивіться на https://artifacthub.github.io/hub/api/?urls.primaryName=Monocular%20compatible%20search%20API#/Monocular/get_api_chartsvc_v1_charts_search + +Попередні версії Helm використовували екземпляр Monocular як стандартне значення для 'endpoint', тому для зворотної сумісності Artifact Hub сумісний з API пошуку Monocular. Аналогічно, при встановленні прапорця 'endpoint' зазначена точка доступу також має реалізовувати API пошуку, сумісний з Monocular. Зверніть увагу, що при вказівці екземпляра Monocular як 'endpoint', розширені запити не підтримуються. Для деталей API дивіться https://github.com/helm/monocular + +```shell +helm search hub [KEYWORD] [flags] +``` + +### Параметри {#options} + +```none + --endpoint string Екземпляр хаба для запитів чартів (стандартно "https://hub.helm.sh") + --fail-on-no-result пошук не вдається, якщо результати не знайдені + -h, --help довідка hub + --list-repo-url вивести URL репозиторію чартів + --max-col-width uint максимальна ширина стовпця для таблиці виводу (стандартно 50) + -o, --output format вивести результат у вказаному форматі. Доступні значення: table, json, yaml (стандартно table) +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +* [helm search](helm_search.md) — пошук ключового слова в чартах + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_search_repo.md b/content/uk/docs/helm/helm_search_repo.md new file mode 100644 index 000000000..08f5e59cb --- /dev/null +++ b/content/uk/docs/helm/helm_search_repo.md @@ -0,0 +1,73 @@ +--- +title: "Helm Search Repo" +--- + +## helm search repo + +шукати репозиторії за ключовим словом у чартах + +### Опис {#synopsis} + +Команда search проходить через всі репозиторії, налаштовані в системі, і шукає збіги. Пошук цих репозиторіїв використовує метадані, збережені в системі. + +Вона відобразить останні стабільні версії знайдених чартів. Якщо ви вказуєте прапорець --devel, у виводі будуть включені передрелізні версії. Якщо ви хочете шукати за допомогою обмеження версії, використовуйте --version. + +Приклади: + +```console +# Шукати стабільні версії релізів, що відповідають ключовому слову "nginx" +$ helm search repo nginx + +# Шукати версії релізів, що відповідають ключовому слову "nginx", включаючи версії передрелізні +$ helm search repo nginx --devel + +# Шукати останній стабільний реліз для nginx-ingress з основною версією 1 +$ helm search repo nginx-ingress --version ^1.0.0 +``` + +Репозиторії управляються командами 'helm repo'. + +```shell +helm search repo [keyword] [flags] +``` + +### Параметри {#options} + +```none + --devel використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується. + --fail-on-no-result повертає помилку, якщо результати не знайдені + -h, --help довідка repo + --max-col-width uint максимальна ширина стовпця для таблиці виводу (стандартно 50) + -o, --output format вивести результат у вказаному форматі. Доступні значення: table, json, yaml (стандартно table) + -r, --regexp використовувати регулярні вирази для пошуку в репозиторіях, які ви додали + --version string шукати, використовуючи обмеження семантичного версіонування в репозиторіях, які ви додали + -l, --versions показати довгий список, з кожною версією кожного чарту на окремому рядку, для репозиторіїв, які ви додали +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +* [helm search](helm_search.md) — пошук ключового слова в чартах + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 + diff --git a/content/uk/docs/helm/helm_show.md b/content/uk/docs/helm/helm_show.md new file mode 100644 index 000000000..b0bfe32ef --- /dev/null +++ b/content/uk/docs/helm/helm_show.md @@ -0,0 +1,49 @@ +--- +title: "Helm Show" +--- + +## helm show + +показати інформацію про чарт + +### Опис {#synopsis} + +Ця команда складається з кількох підкоманд для відображення інформації про чарт + +### Параметри {#options} + +```none + -h, --help довідка show +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +* [helm](helm.md) — менеджер пакетів Helm для Kubernetes. +* [helm show all](helm_show_all.md) — показати всю інформацію про чарт +* [helm show chart](helm_show_chart.md) — показати визначення чарту +* [helm show crds](helm_show_crds.md) — показати CRD чарту +* [helm show readme](helm_show_readme.md) — показати README чарту +* [helm show values](helm_show_values.md) — показати значення чарту + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_show_all.md b/content/uk/docs/helm/helm_show_all.md new file mode 100644 index 000000000..7baa50f90 --- /dev/null +++ b/content/uk/docs/helm/helm_show_all.md @@ -0,0 +1,61 @@ +--- +title: "Helm Show All" +--- + +## helm show all + +показати всю інформацію про чарт + +### Опис {#synopsis} + +Ця команда перевіряє чарт (теку, файл або URL) та показує весь його вміст (values.yaml, Chart.yaml, README). + +```shell +helm show all [CHART] [flags] +``` + +### Параметри {#options} + +```none + --ca-file string перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету + --cert-file string ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату + --devel використовувати версії в розробці також. Еквівалентно версії '>0.0.0-0'. Якщо вказано --version, це ігнорується + -h, --help довідка all + --insecure-skip-tls-verify пропустити перевірку сертифікатів TLS для завантаження чарту + --key-file string ідентифікувати HTTPS-клієнта за допомогою цього SSL ключового файлу + --keyring string розташування публічних ключів, які використовуються для перевірки (стандартно "~/.gnupg/pubring.gpg") + --pass-credentials передати облікові дані всім доменам + --password string пароль репозиторію чартів, де розташований запитуваний чарт + --plain-http використовувати небезпечні HTTP зʼєднання для завантаження чарту + --repo string URL репозиторію чартів, де розташований запитуваний чарт + --username string імʼя користувача репозиторію чартів, де розташований запитуваний чарт + --verify перевірити пакет перед використанням + --version string вказати обмеження версії для версії чарту, яку потрібно використовувати. Це обмеження може бути конкретним теґом (наприклад, 1.1.1) або може посилатися на дійсний діапазон (наприклад, ^2.0.0). Якщо це не вказано, буде використовуватися остання версія +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +* [helm show](helm_show.md) — показати інформацію про чарт + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_show_chart.md b/content/uk/docs/helm/helm_show_chart.md new file mode 100644 index 000000000..799532835 --- /dev/null +++ b/content/uk/docs/helm/helm_show_chart.md @@ -0,0 +1,61 @@ +--- +title: "Helm Show Chart" +--- + +## helm show chart + +показати визначення чарту + +### Опис {#synopsis} + +Ця команда перевіряє чарт (теку, файл або URL) і показує вміст файлу Chart.yaml. + +```shell +helm show chart [CHART] [flags] +``` + +### Параметри {#options} + +```none + --ca-file string перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету + --cert-file string ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату + --devel використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується. + -h, --help довідка chart + --insecure-skip-tls-verify пропустити перевірку сертифікатів TLS для завантаження чарту + --key-file string ідентифікувати HTTPS-клієнта за допомогою цього SSL ключового файлу + --keyring string розташування публічних ключів, які використовуються для перевірки (стандартно "~/.gnupg/pubring.gpg") + --pass-credentials передати облікові дані всім доменам + --password string пароль репозиторію чартів, де розташований запитуваний чарт + --plain-http використовувати небезпечні HTTP з'єднання для завантаження чарту + --repo string URL репозиторію чартів, де розташований запитуваний чарт + --username string імʼя користувача репозиторію чартів, де розташований запитуваний чарт + --verify перевірити пакет перед використанням + --version string вказати обмеження версії для версії чарту, яку потрібно використовувати. Це обмеження може бути конкретним тегом (наприклад, 1.1.1) або може посилатися на дійсний діапазон (наприклад, ^2.0.0). Якщо це не вказано, буде використовуватися остання версія +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +* [helm show](helm_show.md) — показати інформацію про чарт + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_show_crds.md b/content/uk/docs/helm/helm_show_crds.md new file mode 100644 index 000000000..8af8bc727 --- /dev/null +++ b/content/uk/docs/helm/helm_show_crds.md @@ -0,0 +1,62 @@ +--- +title: "Helm Show Crds" +--- + +## helm show crds + +показати CRD чарту + +### Опис {#synopsis} + +Ця команда перевіряє чарт (теку, файл або URL) та показує вміст +файлів CustomResourceDefinition (CRD). + +```shell +helm show crds [CHART] [flags] +``` + +### Параметри {#options} + +```none + --ca-file string перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету + --cert-file string ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату + --devel використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується. + -h, --help довідка crds + --insecure-skip-tls-verify пропустити перевірку сертифікатів TLS для завантаження чарту + --key-file string ідентифікувати HTTPS-клієнта за допомогою цього SSL ключового файлу + --keyring string розташування публічних ключів, які використовуються для перевірки (стандартно "~/.gnupg/pubring.gpg") + --pass-credentials передати облікові дані всім доменам + --password string пароль репозиторію чартів, де розташований запитуваний чарт + --plain-http використовувати небезпечні HTTP зʼєднання для завантаження чарту + --repo string URL репозиторію чартів, де розташований запитуваний чарт + --username string імʼя користувача репозиторію чартів, де розташований запитуваний чарт + --verify перевірити пакет перед використанням + --version string вказати обмеження версії для версії чарту, яку потрібно використовувати. Це обмеження може бути конкретним тегом (наприклад, 1.1.1) або може посилатися на дійсний діапазон (наприклад, ^2.0.0). Якщо це не вказано, буде використовуватися остання версія +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +* [helm show](helm_show.md) — показати інформацію про чарт + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_show_readme.md b/content/uk/docs/helm/helm_show_readme.md new file mode 100644 index 000000000..09d68a0fc --- /dev/null +++ b/content/uk/docs/helm/helm_show_readme.md @@ -0,0 +1,61 @@ +--- +title: "Helm Show Readme" +--- + +## helm show readme + +показати README файл чарту + +### Опис {#synopsis} + +Ця команда перевіряє чарт (теку, файл або URL) та показує вміст файлу README + +```shell +helm show readme [CHART] [flags] +``` + +### Параметри {#options} + +```none + --ca-file string перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету + --cert-file string ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату + --devel використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується. + -h, --help довідка readme + --insecure-skip-tls-verify пропустити перевірку сертифікатів TLS для завантаження чарту + --key-file string ідентифікувати HTTPS-клієнта за допомогою цього SSL ключового файлу + --keyring string розташування публічних ключів, які використовуються для перевірки (стандартно "~/.gnupg/pubring.gpg") + --pass-credentials передати облікові дані всім доменам + --password string пароль репозиторію чартів, де розташований запитуваний чарт + --plain-http використовувати небезпечні HTTP зʼєднання для завантаження чарту + --repo string URL репозиторію чартів, де розташований запитуваний чарт + --username string імʼя користувача репозиторію чартів, де розташований запитуваний чарт + --verify перевірити пакет перед використанням + --version string вказати обмеження версії для версії чарту, яку потрібно використовувати. Це обмеження може бути конкретним тегом (наприклад, 1.1.1) або може посилатися на дійсний діапазон (наприклад, ^2.0.0). Якщо це не вказано, буде використовуватися остання версія +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +* [helm show](helm_show.md) — показати інформацію про чарт + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_show_values.md b/content/uk/docs/helm/helm_show_values.md new file mode 100644 index 000000000..ccb76eb2f --- /dev/null +++ b/content/uk/docs/helm/helm_show_values.md @@ -0,0 +1,61 @@ +--- +title: "Helm Show Values" +--- + +## helm show values + +показати значення чарту + +### Опис {#synopsis} + +Ця команда перевіряє чарт (теку, файл або URL) та показує вміст файлу values.yaml + +```shell +helm show values [CHART] [flags] +``` + +### Параметри {#options} + +```none + --ca-file string перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету + --cert-file string ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату + --devel використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується. + -h, --help довідка values + --insecure-skip-tls-verify пропустити перевірку сертифікатів TLS для завантаження чарту + --key-file string ідентифікувати HTTPS-клієнта за допомогою цього SSL ключового файлу + --keyring string розташування публічних ключів, які використовуються для перевірки (стандартно "~/.gnupg/pubring.gpg") + --pass-credentials передати облікові дані всім доменам + --password string пароль репозиторію чартів, де розташований запитуваний чарт + --plain-http використовувати небезпечні HTTP зʼєднання для завантаження чарту + --repo string URL репозиторію чартів, де розташований запитуваний чарт + --username string імʼя користувача репозиторію чартів, де розташований запитуваний чарт + --verify перевірити пакет перед використанням + --version string вказати обмеження версії для версії чарту, яку потрібно використовувати. Це обмеження може бути конкретним тегом (наприклад, 1.1.1) або може посилатися на дійсний діапазон (наприклад, ^2.0.0). Якщо це не вказано, буде використовуватися остання версія +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +* [helm show](helm_show.md) — показати інформацію про чарт + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_status.md b/content/uk/docs/helm/helm_status.md new file mode 100644 index 000000000..97e4ac9fa --- /dev/null +++ b/content/uk/docs/helm/helm_status.md @@ -0,0 +1,61 @@ +--- +title: "Helm Status" +--- + +## helm status + +показати статус вказаного релізу + +### Опис {#synopsis} + +Ця команда показує статус вказаного релізу. Статус складається з: + +- часу останнього розгортання +- простору імен k8s, в якому знаходиться реліз +- стану релізу (може бути: unknown, deployed, uninstalled, superseded, failed, uninstalling, pending-install, pending-upgrade або pending-rollback) +- ревізії релізу +- опису релізу (може бути повідомленням про завершення або помилкою, потрібно увімкнути --show-desc) +- списку ресурсів, які входять до складу цього релізу (потрібно увімкнути --show-resources) +- деталей останнього запуску тестового набору, якщо застосовується +- додаткових приміток, наданих чартом + +```shell +helm status RELEASE_NAME [flags] +``` + +### Параметри {#options} + +```none + -h, --help довідка status + -o, --output format виводить результат у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table) + --revision int якщо вказано, показати статус вказаного релізу з ревізією + --show-desc якщо вказано, показати описове повідомлення вказаного релізу + --show-resources якщо вказано, показати ресурси вказаного релізу +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +- [helm](helm.md) — менеджер пакетів Helm для Kubernetes. + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_template.md b/content/uk/docs/helm/helm_template.md new file mode 100644 index 000000000..60d9769ee --- /dev/null +++ b/content/uk/docs/helm/helm_template.md @@ -0,0 +1,98 @@ +--- +title: "Helm Template" +--- + +## helm template + +локальний рендеринг шаблонів + +### Опис {#synopsis} + +Рендерить шаблони чарту локально та показує результат. + +Будь-які значення, які зазвичай шукалися або отримувалися в кластері, будуть імітуватися локально. Крім того, жодна з перевірок валідності чарту на сервері (наприклад, перевірка підтримки API) не проводиться. + +```shell +helm template [NAME] [CHART] [flags] +``` + +### Параметри + +```none + -a, --api-versions strings версії API Kubernetes, які використовуються для Capabilities.APIVersions + --atomic якщо вказано, процес встановлення видалить інсталяцію у разі невдачі. Прапорець --wait буде встановлено автоматично, якщо використовується --atomic + --ca-file string перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету + --cert-file string ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату + --create-namespace створити простір імен релізу, якщо його не існує + --dependency-update оновити залежності, якщо вони відсутні перед установкою чарту + --description string додати власний опис + --devel використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується. + --disable-openapi-validation якщо вказано, процес встановлення не буде перевіряти шаблони за схемою OpenAPI Kubernetes + --dry-run string[="client"] імітувати встановлення. Якщо --dry-run вказано без жодної опції або як '--dry-run=client', він не буде намагатися підключитися до кластера. Встановлення '--dry-run=server' дозволяє намагатися підключитися до кластера. + --enable-dns увімкнути DNS запити при рендерингу шаблонів + --force примусово оновлювати ресурси через стратегію заміни + -g, --generate-name згенерувати імʼя (та опустити параметр NAME) + -h, --help довідка по template + --include-crds включити CRD у вивід шаблонів + --insecure-skip-tls-verify пропустити перевірки TLS сертифікатів для завантаження чарту + --is-upgrade встановити .Release.IsUpgrade замість .Release.IsInstall + --key-file string ідентифікувати клієнта HTTPS, використовуючи цей файл SSL ключа + --keyring string розташування публічних ключів, використовуваних для перевірки (стандартно "~/.gnupg/pubring.gpg") + --kube-version string версія Kubernetes, яка використовується для Capabilities.KubeVersion + -l, --labels stringToString Мітки, які будуть додані до метаданих релізу. Мають бути розділені комами. (стандартно []) + --name-template string вказати шаблон, використаний для іменування релізу + --no-hooks запобігти виконанню хуків у процесі установки + --output-dir string записувати виконані шаблони у файли в output-dir замість stdout + --pass-credentials передати облікові дані всім доменам + --password string пароль до репозиторію чартів, де знайти запитуваний чарт + --plain-http використовувати небезпечні HTTP зʼєднання для завантаження чарту + --post-renderer postRendererString шлях до виконуваного файлу, який буде використаний для пост-рендерингу. Якщо він існує в $PATH, буде використано цей бінарний файл, інакше спробує знайти виконуваний файл за вказаним шляхом + --post-renderer-args postRendererArgsSlice аргумент для пост-рендерера (можна вказати кілька) (стандартно []) + --release-name використовувати імʼя релізу в шляху output-dir + --render-subchart-notes якщо вказано, рендерити нотатки субчарту разом з батьківським + --replace повторно використовувати дане імʼя, тільки якщо це імʼя є видаленим релізом, який залишається в історії. Це небезпечно в операційному середовищі + --repo string URL репозиторію чартів, де знайти запитуваний чарт + --set stringArray встановити значення в командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2) + --set-file stringArray встановити значення з відповідних файлів, зазначених через командний рядок (можна вказати кілька або розділити значення комами: key1=path1,key2=path2) + --set-json stringArray встановити JSON значення в командному рядку (можна вказати кілька або розділити значення комами: key1=jsonval1,key2=jsonval2) + --set-literal stringArray встановити літеральне STRING значення на командному рядку + --set-string stringArray встановити STRING значення в командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2) + -s, --show-only stringArray показати тільки маніфести, відрендерені з вказаних шаблонів + --skip-crds якщо вказано, CRD не будуть встановлені. Ствндартно CRD встановлюються, якщо ще не присутні + --skip-tests пропустити тести з виводу шаблонів + --timeout duration час очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хук) (стандартно 5м0с) + --username string імʼя користувача репозиторію чартів, де знайти запитуваний чарт + --validate перевірити ваші маніфести на відповідність кластеру Kubernetes, до якого ви в даний час звертаєтеся. Це така ж перевірка, яка виконується при установці + -f, --values strings вказати значення в YAML файлі або URL (можна вказати кілька) + --verify перевірити пакет перед його використанням + --version string вказати обмеження версії для версії чарту, яку потрібно використовувати. Це обмеження може бути конкретним тегом (наприклад, 1.1.1) або може посилатися на дійсний діапазон (наприклад, ^2.0.0). Якщо це не вказано, використовується остання версія + --wait якщо вказано, буде чекати, поки всі Pods, PVCs, Services та мінімальна кількість Pods Deployment, StatefulSet або ReplicaSet не будуть у стані готовності, перш ніж позначити реліз як успішний. Це буде чекати стільки, скільки вказано у --timeout + --wait-for-jobs якщо вказано і --wait увімкнено, буде чекати, поки всі Jobs не будуть завершені перед тим, як позначити реліз як успішний. Це буде чекати стільки, скільки вказано у --timeout +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +- [helm](helm.md) — менеджер пакетів Helm для Kubernetes. + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_test.md b/content/uk/docs/helm/helm_test.md new file mode 100644 index 000000000..a9a927695 --- /dev/null +++ b/content/uk/docs/helm/helm_test.md @@ -0,0 +1,53 @@ +--- +title: "Helm Test" +--- + +## helm test + +запустити тести для релізу + +### Опис {#synopsis} + +Команда test запускає тести для релізу. + +Аргументом цієї команди є імʼя розгорнутого релізу. Тести, що будуть виконані, визначені у чарті, який був встановлений. + +```shell +helm test [RELEASE] [flags] +``` + +### Параметри {#options} + +```none + --filter strings вказати тести за атрибутом (в даний час "name") використовуючи синтаксис attribute=value або '!attribute=value', щоб виключити тест (можна вказати кілька або розділити значення комами: name=test1,name=test2) + -h, --help довідка test + --logs отримати логи з тестових podʼів (це виконується після завершення всіх тестів, але перед будь-яким очищенням) + --timeout duration час очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хуків) (стандартно 5м0с) +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +- [helm](helm.md) — менеджер пакетів Helm для Kubernetes. + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_uninstall.md b/content/uk/docs/helm/helm_uninstall.md new file mode 100644 index 000000000..c093b12d6 --- /dev/null +++ b/content/uk/docs/helm/helm_uninstall.md @@ -0,0 +1,60 @@ +--- +title: "Helm Uninstall" +--- + +## helm uninstall + +видалити реліз + +### Опис {#synopsis} + +Ця команда приймає імʼя релізу і видаляє його. + +Вона видаляє всі ресурси, асоційовані з останнім релізом чарту, а також історію релізу, звільняючи його для подальшого використання. + +Використовуйте прапор '--dry-run', щоб побачити, які релізи будуть видалені без фактичного видалення. + +```shell +helm uninstall RELEASE_NAME [...] [flags] +``` + +### Параметри {#options} + +```none + --cascade string Має бути "background", "orphan" або "foreground". Вибирає стратегію каскадного видалення для залежних ресурсів. Стандартно background. (стандартно "background") + --description string додати власний опис + --dry-run симулювати видалення + -h, --help довідка uninstall + --ignore-not-found Вважати "release not found" як успішне видалення + --keep-history видалити всі асоційовані ресурси і помітити реліз як видалений, але зберегти історію релізу + --no-hooks запобігти виконанню хуків під час видалення + --timeout duration час очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хуків) (стандартно 5м0с) + --wait якщо вказано, буде чекати, поки всі ресурси не будуть видалені перед поверненням. Буде чекати стільки, скільки вказано у --timeout +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +- [helm](helm.md) — менеджер пакетів Helm для Kubernetes. + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_upgrade.md b/content/uk/docs/helm/helm_upgrade.md new file mode 100644 index 000000000..56f5a1404 --- /dev/null +++ b/content/uk/docs/helm/helm_upgrade.md @@ -0,0 +1,114 @@ +--- +title: "Helm Upgrade" +--- + +## helm upgrade + +оновити реліз + +### Опис {#synopsis} + +Ця команда оновлює реліз до нової версії чарту. + +Аргументи для оновлення повинні містити реліз і чарт. Аргумент чарту може бути або: посилання на чарт ('example/mariadb'), шлях до теки з чартом, упакований чарт або повністю кваліфікований URL. Для посилань на чарт буде вказана остання версія, якщо не встановлено прапорець '--version'. + +Щоб перевизначити значення в чарті, використовуйте або прапорець '--values' та передайте файл, або прапорець '--set' і передайте конфігурацію з командного рядка. Для примусового використання рядкових значень використовуйте '--set-string'. Можна також використовувати '--set-file', щоб задати окремі значення з файлу, коли значення занадто довге для командного рядка або генерується динамічно. Ви також можете використовувати '--set-json', щоб задати json-значення (скаляри/обʼєкти/масиви) з командного рядка. + +Ви можете вказати прапорець '--values'/'-f' кілька разів. Пріоритет буде надано останньому (правому) файлу. Наприклад, якщо і myvalues.yaml, і override.yaml містять ключ 'Test', значення, задане в override.yaml, матиме пріоритет: + +```shell +$ helm upgrade -f myvalues.yaml -f override.yaml redis ./redis +``` + +Ви можете вказати прапорець '--set' кілька разів. Пріоритет буде надано останньому (правому) заданому значенню. Наприклад, якщо значення 'bar' і 'newbar' встановлені для ключа 'foo', значення 'newbar' матиме пріоритет: + +```shell +$ helm upgrade --set foo=bar --set foo=newbar redis ./redis +``` + +Ви також можете оновити значення для поточного релізу за допомогою цієї команди з прапорцем '--reuse-values'. Аргументи 'RELEASE' і 'CHART' повинні бути встановлені на оригінальні параметри, поточні значення будуть обʼєднані з будь-якими значеннями, заданими через прапорці '--values'/'-f' або '--set'. Пріоритет надається новим значенням. + +```shell +$ helm upgrade --reuse-values --set foo=bar --set foo=newbar redis ./redis +``` + +```shell +helm upgrade [RELEASE] [CHART] [flags] +``` + +### Параметри + +```none + --atomic якщо встановлено, процес оновлення скасовує зміни у разі невдалого оновлення. Прапорець --wait буде автоматично встановлено, якщо використовується --atomic + --ca-file string перевіряти сертифікати HTTPS-серверів, використовуючи цей CA пакет + --cert-file string ідентифікувати HTTPS-клієнта, використовуючи цей SSL сертифікат + --cleanup-on-fail дозволити видалення нових ресурсів, створених в цьому оновленні, коли оновлення не вдалося + --create-namespace якщо встановлено --install, створити простір імен релізу, якщо він не присутній + --dependency-update оновити залежності, якщо вони відсутні, перед встановленням чарту + --description string додати власний опис + --devel використовувати також версії в розробці. Еквівалентно версії '>0.0.0-0'. Якщо вказано --version, це буде проігноровано + --disable-openapi-validation якщо встановлено, процес оновлення не буде перевіряти відрендерені шаблони на відповідність Kubernetes OpenAPI Schema + --dry-run string[="client"] симулювати установку. Якщо --dry-run встановлено без вказання опції або як '--dry-run=client', не буде спроб зʼєднання з кластером. Встановлення '--dry-run=server' дозволяє спробувати зʼєднання з кластером. + --hide-secret при встановленому --dry-run, вміст Secret видаляється з виводу + --enable-dns увімкнути DNS запити під час рендерингу шаблонів + --force примусове оновлення ресурсів через стратегію заміни + -h, --help довідка upgrade + --history-max int обмежити максимальну кількість ревізій, збережених для релізу. Використовуйте 0 для відсутності обмежень (стандартно 10) + --insecure-skip-tls-verify пропустити перевірки сертифікатів TLS для завантаження чарту + -i, --install якщо реліз з цим імʼям ще не існує, виконується установка + --key-file string ідентифікувати HTTPS-клієнта, використовуючи цей файл SSL ключа + --keyring string розташування публічних ключів, що використовуються для перевірки (стандартно "~/.gnupg/pubring.gpg") + -l, --labels stringToString Мітки, які будуть додані до метаданих релізу. Мають бути розділені комою. Оригінальні мітки релізу будуть обʼєднані з мітками оновлення. Ви можете скинути мітку, використовуючи null. (стандартно []) + --no-hooks вимкнути хуки перед/після оновлення + -o, --output format друкує вивід у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table) + --pass-credentials передати облікові дані всім доменам + --password string пароль репозиторію чарту для розташування запитуваного чарту + --plain-http використовувати небезпечні HTTP зʼєднання для завантаження чарту + --post-renderer postRendererString шлях до виконуваного файлу, що буде використано для пост-рендерингу. Якщо він існує в $PATH, буде використано двійковий файл, інакше буде спробовано знайти виконуваний файл за вказаним шляхом + --post-renderer-args postRendererArgsSlice аргумент для пост-рендерера (можна вказати кілька) (стандартно []) + --render-subchart-notes якщо встановлено, рендерити нотатки субчарту разом з батьківським чартом + --repo string URL репозиторію чарту для розташування запитуваного чарту + --reset-then-reuse-values при оновленні, скинути значення до вбудованих у чарт значень, застосувати значення останнього релізу та обʼєднати будь-які перекриття з командного рядка через --set і -f. Якщо вказано '--reset-values' або '--reuse-values', це буде проігноровано + --reset-values при оновленні, скинути значення до вбудованих у чарт значень + --reuse-values при оновленні, повторно використовувати значення останнього релізу та обʼєднати будь-які перекриття з командного рядка через --set і -f. Якщо вказано '--reset-values', це буде проігноровано + --set stringArray встановити значення з командного рядка (можна вказати кілька або розділити значення комами: key1=val1,key2=val2) + --set-file stringArray встановити значення з відповідних файлів, зазначених через командний рядок (можна вказати кілька або розділити значення комами: key1=path1,key2=path2) + --set-json stringArray встановити JSON значення з командного рядка (можна вказати кілька або розділити значення комами: key1=jsonval1,key2=jsonval2) + --set-literal stringArray встановити літеральне STRING значення з командного рядка + --set-string stringArray встановити STRING значення з командного рядка (можна вказати кілька або розділити значення комами: key1=val1,key2=val2) + --skip-crds якщо встановлено, CRD не будуть встановлені під час виконання оновлення з увімкненим прапорцем install. Стандартно, CRD встановлюються, якщо ще не присутні, під час виконання оновлення з увімкненим прапорцем install + --timeout duration час очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хуків) (стандартно 5м0с) + --username string імʼя користувача репозиторію чарту для розташування запитуваного чарту + -f, --values strings вказати значення у YAML файлі або URL (можна вказати кілька) + --verify перевірити пакет перед використанням + --version string вказати обмеження версії для версії чарту, яку слід використовувати. Це обмеження може бути конкретною міткою (наприклад, 1.1.1) або може посилатися на дійсний діапазон (наприклад, ^2.0.0). Якщо не вказано, буде використана остання версія + --wait якщо встановлено, чекатиме, поки всі Pods, PVC, Services і мінімальна кількість Pods Deployment, StatefulSet або ReplicaSet не перебуватимуть у стані готовності перед поміткою релізу як успішного. Буде чекати стільки, скільки вказано у --timeout + --wait-for-jobs якщо встановлено і --wait увімкнено, чекатиме, поки всі Jobs не будуть завершені перед поміткою релізу як успішного. Це буде чекати стільки, скільки вказано у --timeout +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +- [helm](helm.md) — менеджер пакетів Helm для Kubernetes. + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_verify.md b/content/uk/docs/helm/helm_verify.md new file mode 100644 index 000000000..46125f7fd --- /dev/null +++ b/content/uk/docs/helm/helm_verify.md @@ -0,0 +1,53 @@ +--- +title: "Helm Verify" +--- + +## helm verify + +перевірити, що чарт за вказаним шляхом підписаний і є дійсним + +### Опис {#synopsis} + +Перевірте, чи має вказаний чарт дійсний файл автентичності. + +Файли автентичності забезпечують криптографічну перевірку того, що чарт не був зміненим і був упакований надійним постачальником. + +Цю команду можна використовувати для перевірки локального чарту. Декілька інших команд надають прапорці '--verify', які виконують ту ж саму валідацію. Щоб згенерувати підписаний пакет, використовуйте команду 'helm package --sign'. + +```shell +helm verify PATH [flags] +``` + +### Параметри {#options} + +```none + -h, --help довідка verify + --keyring string вєящка ключів, що містить публічні ключі (стандартно "~/.gnupg/pubring.gpg") +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +- [helm](helm.md) — менеджер пакетів Helm для Kubernetes. + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/helm/helm_version.md b/content/uk/docs/helm/helm_version.md new file mode 100644 index 000000000..06e92c0bc --- /dev/null +++ b/content/uk/docs/helm/helm_version.md @@ -0,0 +1,68 @@ +--- +title: "Helm Version" +--- + +## helm version + +друкує інформацію про версію клієнта + +### Опис {#synopsis} + +Показує версію для Helm. + +Команда надрукує представлення версії Helm. Вивід виглядатиме приблизно так: + +version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"} + +- Version — семантична версія релізу. +- GitCommit — SHA коміту, з якого була збудована ця версія. +- GitTreeState — "clean", якщо при створенні цього бінарного файлу не було локальних змін у коді, і "dirty", якщо бінарний файл був збудований з локально зміненого коду. +- GoVersion — версія Go, яка була використана для компіляції Helm. + +При використанні прапорця --template доступні такі властивості для використання в шаблоні: + +- .Version містить семантичну версію Helm +- .GitCommit — git коміт +- .GitTreeState — стан git дерева, коли був збудований Helm +- .GoVersion містить версію Go, з якою був зібраний Helm + +Наприклад, --template='Version: {{.Version}}' надрукує 'Version: v3.2.1'. + +```shell +helm version [flags] +``` + +### Параметри {#options} + +```none + -h, --help довідка version + --short надрукувати номер версії + --template string шаблон для формату рядка версії +``` + +### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} + +```none + --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) + --debug увімкнути розширений вивід + --kube-apiserver string адреса та порт сервера API Kubernetes + --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. + --kube-as-user string імʼя користувача для імперсонації під час операції + --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes + --kube-context string імʼя контексту kubeconfig для використання + --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними + --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера + --kube-token string токен на предʼявника, який використовується для автентифікації + --kubeconfig string шлях до файлу kubeconfig + -n, --namespace string простір імен для цього запиту + --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески + --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") + --repository-cache string шлях до файлу, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") + --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") +``` + +### ДИВІТЬСЯ ТАКОЖ {#see-also} + +- [helm](helm.md) — менеджер пакетів Helm для Kubernetes. + +###### Автоматично згенеровано spf13/cobra 24 січня 2024 diff --git a/content/uk/docs/howto/_index.md b/content/uk/docs/howto/_index.md new file mode 100644 index 000000000..ee89e458a --- /dev/null +++ b/content/uk/docs/howto/_index.md @@ -0,0 +1,13 @@ +--- +title: "Поради" +weight: 2 +--- + +--- + +### Поради {#how-to-guides} + +Тут ви знайдете короткі відповіді на питання типу «Як я можу….?» +Ці посібники не охоплюють теми в деталях — ви знайдете такі +матеріали в [Тематичних посібниках](../topics). Однак ці +посібники допоможуть вам швидко виконати поширені завдання. diff --git a/content/uk/docs/howto/chart_releaser_action.md b/content/uk/docs/howto/chart_releaser_action.md new file mode 100644 index 000000000..3b141702d --- /dev/null +++ b/content/uk/docs/howto/chart_releaser_action.md @@ -0,0 +1,79 @@ +--- +title: "Chart Releaser Action для автоматизації випуску чартів на GitHub Pages" +description: "Описує, як використовувати Chart Releaser Action для автоматизації випуску чартів через GitHub Pages." +weight: 3 +--- + +Цей посібник описує, як використовувати [Chart Releaser Action](https://github.com/marketplace/actions/helm-chart-releaser) для автоматизації випуску чартів через GitHub Pages. Chart Releaser Action — це GitHub Action workflow, який перетворює GitHub проєкт на репозиторій чартів Helm, використовуючи CLI-інструмент [helm/chart-releaser](https://github.com/helm/chart-releaser). + +## Зміни в репозиторії {#repository-changes} + +Створіть Git-репозиторій у вашій організації на GitHub. Ви можете назвати репозиторій `helm-charts`, хоча також прийнятні інші назви. Джерела всіх чартів можуть бути розміщені на гілці `main`. Чарти повинні бути розміщені в теці `/charts` на верхньому рівні дерева тек. + +Також має бути інша гілка з назвою `gh-pages`, щоб публікувати чарти. Зміни в цій гілці будуть автоматично створюватися за допомогою Chart Releaser Action, описаного тут. Крім створення гілку `gh-pages` ви можете додати файл `README.md` до неї, який буде видимим користувачам, що відвідують сторінку. + +Ви можете додати інструкції в `README.md` щодо встановлення чартів, як показано нижче (замініть ``, ``, і ``): + +```md +## Використання + +Щоб використовувати чарти, необхідно встановити [Helm](https://helm.sh). Будь ласка, ознайомтеся з [документацією Helm](https://helm.sh/docs), щоб розпочати. + +Як тільки Helm буде налаштовано правильно, додайте репозиторій наступним чином: + + helm repo add https://.github.io/helm-charts + +Якщо ви вже додавали цей репозиторій раніше, виконайте команду `helm repo update`, щоб отримати останні версії пакетів. Потім ви можете виконати `helm search repo `, щоб побачити чарти. + +Щоб встановити чарт ``: + + helm install my- / + +Щоб видалити чарт: + + helm delete my- +``` + +Чарти будуть опубліковані на вебсайті з URL-адресою типу: + + https://.github.io/helm-charts + +## GitHub Actions Workflow {#github-actions-workflow} + +Створіть файл GitHub Actions workflow в гілці `main` за адресою `.github/workflows/release.yml`: + +```yaml +name: Release Charts + +on: + push: + branches: + - main + +jobs: + release: + permissions: + contents: write + runs-on: ubuntu-latest + steps: + - name: Checkout + uses: actions/checkout@v4 + with: + fetch-depth: 0 + + - name: Configure Git + run: | + git config user.name "$GITHUB_ACTOR" + git config user.email "$GITHUB_ACTOR@users.noreply.github.com" + + - name: Run chart-releaser + uses: helm/chart-releaser-action@v1.6.0 + env: + CR_TOKEN: "${{ secrets.GITHUB_TOKEN }}" +``` + +Наведена конфігурація використовує [@helm/chart-releaser-action](https://github.com/helm/chart-releaser-action), щоб перетворити ваш GitHub проєкт на самостійний репозиторій чартів Helm. Вона виконує це під час кожної операції push в гілку `main` шляхом перевірки кожного чарту у вашому проєкті, і коли знаходить нову версію чарту, створює відповідний реліз GitHub, додає артефакти Helm чарту до релізу і створює або оновлює файл `index.yaml` з метаданими про ці релізи, який потім хоститься на GitHub Pages. + +Версія Chart Releaser Action, використана в наведеному прикладі, — `v1.6.0`. Ви можете змінити її на [останню доступну версію](https://github.com/helm/chart-releaser-action/releases). + +Примітка: Chart Releaser Action майже завжди використовується в парі з [Helm Testing Action](https://github.com/marketplace/actions/helm-chart-testing) та [Kind Action](https://github.com/marketplace/actions/kind-cluster). diff --git a/content/uk/docs/howto/chart_repository_sync_example.md b/content/uk/docs/howto/chart_repository_sync_example.md new file mode 100644 index 000000000..a3ec27ac5 --- /dev/null +++ b/content/uk/docs/howto/chart_repository_sync_example.md @@ -0,0 +1,89 @@ +--- +title: "Синхронізація вашого репозиторію чартів" +description: "Описує, як синхронізувати ваші локальні та віддалені репозиторії чартів." +weight: 2 +--- + +*Примітка: Цей приклад для хмарного сховища Google (GCS), яке обслуговує репозиторій чартів.* + +## Попередні умови {#prerequisites} + +* Встановіть інструмент [gsutil](https://cloud.google.com/storage/docs/gsutil). *Ми значною мірою покладаємося на функціональність gsutil rsync.* +* Переконайтеся, що у вас є доступ до бінарного файлу Helm. +* *Необовʼязково: Ми рекомендуємо встановити [версіювання обʼєктів](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#top_of_page) у вашому сховищі GCS, на випадок, якщо ви випадково щось видалите.* + +## Налаштування теки локального репозиторію чартів {#set-up-a-local-chart-repository-directory} + +Створіть локальну теку, як ми це робили в [керівництві з репозиторію чартів]({{< ref "/docs/topics/chart_repository.md" >}}), і помістіть ваші упаковані чарти в цю теку. + +Наприклад: + +```console +$ mkdir fantastic-charts +$ mv alpine-0.1.0.tgz fantastic-charts/ +``` + +## Генерація оновленого файлу index.yaml {#generate-an-updated-index.yaml} + +Використовуйте Helm для генерації оновленого файлу index.yaml, передавши шлях до теки та URL-адресу віддаленого репозиторію команді `helm repo index`, як показано нижче: + +```console +$ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com +``` + +Це згенерує оновлений файл index.yaml і помістить його в теку `fantastic-charts/`. + +## Синхронізація ваших локальних та віддалених репозиторіїв чартів {#sync-your-local-and-remote-chart-repositories} + +Завантажте вміст теки у ваше сховище GCS, запустивши `scripts/sync-repo.sh` та передавши назву локальної теки та назву сховища GCS. + +Наприклад: + +```console +$ pwd +/Users/me/code/go/src/helm.sh/helm +$ scripts/sync-repo.sh fantastic-charts/ fantastic-charts +Getting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts +Verifying Prerequisites.... +Thumbs up! Looks like you have gsutil. Let's continue. +Building synchronization state... +Starting synchronization +Would copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz +Would copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml +Are you sure you would like to continue with these changes?? [y/N]} y +Building synchronization state... +Starting synchronization +Copying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]... +Uploading gs://fantastic-charts/alpine-0.1.0.tgz: 740 B/740 B +Copying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]... +Uploading gs://fantastic-charts/index.yaml: 347 B/347 B +Congratulations your remote chart repository now matches the contents of fantastic-charts/ +``` + +## Оновлення вашого репозиторію чартів {#updating-your-chart-repository} + +Ви захочете зберегти локальну копію вмісту вашого репозиторію чартів або використати `gsutil rsync` для копіювання вмісту вашого віддаленого репозиторію чартів до локальної теки. + +Наприклад: + +```console +$ gsutil rsync -d -n gs://bucket-name local-dir/ # прапорець -n виконує пробний запуск +Building synchronization state... +Starting synchronization +Would copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz +Would copy gs://bucket-name/index.yaml to file://local-dir/index.yaml + +$ gsutil rsync -d gs://bucket-name local-dir/ # виконує дії копіювання +Building synchronization state... +Starting synchronization +Copying gs://bucket-name/alpine-0.1.0.tgz... +Downloading file://local-dir/alpine-0.1.0.tgz: 740 B/740 B +Copying gs://bucket-name/index.yaml... +Downloading file://local-dir/index.yaml: 346 B/346 B +``` + +Корисні посилання: + +* Документація щодо [gsutil rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description) +* [Керівництво репозиторію чартів]({{< ref "/docs/topics/chart_repository.md" >}}) +* Документація щодо [версіювання обʼєктів та керування паралельністю](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview) у хмарному сховищі Google diff --git a/content/uk/docs/howto/charts_tips_and_tricks.md b/content/uk/docs/howto/charts_tips_and_tricks.md new file mode 100644 index 000000000..30a3e48c9 --- /dev/null +++ b/content/uk/docs/howto/charts_tips_and_tricks.md @@ -0,0 +1,237 @@ +--- + +title: "Поради та підказки для розробки чартів" +description: "Містить деякі поради та підказки, про які розробники чартів Helm дізнались під час створення чартів промислової якості." +weight: 1 +--- + +Цей посібник містить поради та підказки, про які розробники чартів Helm дізнались під час створення чартів промислової якості. + +## Знайомство з функціями шаблону {#know-your-template-functions} + +Helm використовує [шаблони Go](https://godoc.org/text/template) для шаблонування ваших ресурсних файлів. Хоча Go поставляється з кількома вбудованими функціями, ми додали багато інших. + +По-перше, ми додали всі функції з [бібліотеки Sprig](https://masterminds.github.io/sprig/), за винятком `env` і `expandenv`, з міркувань безпеки. + +Ми також додали дві спеціальні функції шаблонів: `include` і `required`. Функція `include` дозволяє додавати інший шаблон і передавати результати іншим функціям шаблонів. + +Наприклад, цей фрагмент шаблону включає шаблон з назвою `mytpl`, потім приводить результат у нижньому регістрі та обертає його в подвійні лапки. + +```yaml +value: {{ include "mytpl" . | lower | quote }} +``` + +Функція `required` дозволяє оголосити певний запис значення обовʼязковим для рендерингу шаблону. Якщо значення порожнє, рендеринг шаблону завершиться з повідомленням про помилку, наданим користувачем. + +Наступний приклад використання функції `required` оголошує запис для `.Values.who` обовʼязковим і виводить повідомлення про помилку, якщо цього запису не вистачає: + +```yaml +value: {{ required "Потрібен дійсний запис .Values.who!" .Values.who }} +``` + +## Використовуйте лапки для рядків, не використовуйте лапки для цілих чисел {#quote-strings-don-t-quote-integers} + +Коли ви працюєте з рядковими даними, завжди безпечніше використовувати лапки для рядків, ніж залишати їх без лапок: + +```yaml +name: {{ .Values.MyName | quote }} +``` + +Але при роботі з цілими числами _не беріть значення в лапки._ Це може викликати помилки парсингу всередині Kubernetes. + +```yaml +port: {{ .Values.Port }} +``` + +Це зауваження не стосується значень змінних середовища, які повинні бути рядками, навіть якщо вони представляють цілі числа: + +```yaml +env: + - name: HOST + value: "http://host" + - name: PORT + value: "1234" +``` + +## Використання функції `include` {#using-the-include-function} + +Go надає спосіб включати один шаблон в інший за допомогою вбудованої директиви `template`. Однак вбудована функція не може використовуватися в конвеєрах шаблонів Go. + +Щоб включити шаблон і виконати операцію з його результатом, Helm має спеціальну функцію `include`: + +```yaml +{{ include "toYaml" $value | indent 2 }} +``` + +Вищезазначене включає шаблон з назвою `toYaml`, передає йому `$value`, а потім передає результат з цього шаблону у функцію `indent`. + +Оскільки в YAML важливі відступи, це чудовий спосіб включати фрагменти коду, зберігаючи відступи в релевантному контексті. + +## Використання функції `required` {#using-the-required-function} + +Go надає спосіб налаштувати опції шаблону для керування поведінкою при зверненні до ключа, якого немає в map. Це зазвичай налаштовується за допомогою `template.Options("missingkey=option")`, де `option` може бути `default`, `zero` або `error`. Якщо встановити цю опцію з помилкою, виконання зупиниться з помилкою, але це стосуватиметься кожного відсутнього ключа в map. Можуть бути ситуації, коли розробник чарту захоче застосувати цю поведінку лише для певних значень у файлі `values.yaml`. + +Функція `required` дає розробникам можливість оголосити значення обовʼязковим для роботи в шаблоні. Якщо значення відсутнє в `values.yaml`, шаблон повертає повідомлення про помилку, надане розробником. + +Наприклад: + +```yaml +{{ required "Потрібен дійсний foo!" .Values.foo }} +``` + +Наведена вище конструкція використає шаблон, коли `.Values.foo` визначено, але не зможе це зробити та вийде з помилкою, коли `.Values.foo` не визначено. + +## Використання функції `tpl` {#using-the-tpl-function} + +Функція `tpl` дозволяє розробникам оцінювати рядки як шаблони всередині іншого шаблону. Це корисно для передачі рядка шаблону як значення до чарту або використання зовнішніх конфігураційних файлів. Синтаксис: `{{ tpl TEMPLATE_STRING VALUES }}`. + +Приклади: + +```yaml +# значення +template: "{{ .Values.name }}" +name: "Tom" + +# шаблон +{{ tpl .Values.template . }} + +# результат +Tom +``` + +Використання зовнішнього конфігураційного файлу: + +```yaml +# зовнішній конфігураційний файл conf/app.conf +firstName={{ .Values.firstName }} +lastName={{ .Values.lastName }} + +# значення +firstName: Peter +lastName: Parker + +# шаблон +{{ tpl (.Files.Get "conf/app.conf") . }} + +# результат +firstName=Peter +lastName=Parker +``` + +## Створення секретів для отримання образів {#creating-image-pull-secrets} + +Секрети для отримання образів по суті є комбінацією _registry_, _username_ та _password_. Вони можуть знадобитися у застосунку, який ви розгортаєте, але для їх створення потрібно кілька разів запустити `base64`. Ми можемо написати допоміжний шаблон, щоб скласти файл конфігурації Docker для використання у вигляді даних для секрету. Ось приклад: + +По-перше, припустимо, що облікові дані визначені у файлі `values.yaml` наступним чином: + +```yaml +imageCredentials: + registry: quay.io + username: someone + password: sillyness + email: someone@host.com +``` + +Ми визначаємо наш допоміжний шаблон наступним чином: + +```go +{{- define "imagePullSecret" }} +{{- with .Values.imageCredentials }} +{{- printf "{\"auths\":{\"%s\":{\"username\":\"%s\",\"password\":\"%s\",\"email\":\"%s\",\"auth\":\"%s\"}}}" .registry .username .password .email (printf "%s:%s" .username .password | b64enc) | b64enc }} +{{- end }} +{{- end }} +``` + +Нарешті, ми використовуємо допоміжний шаблон у більшому шаблоні для створення маніфесту секрету: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: myregistrykey +type: kubernetes.io/dockerconfigjson +data: + .dockerconfigjson: {{ template "imagePullSecret" . }} +``` + +## Автоматичне викатування розгортань {#automatically-roll-deployments} + +Часто ConfigMaps або Secrets підключаютсья як конфігураційні файли в контейнери або є інші зовнішні зміни залежностей, які вимагають перезапуску podʼів. Залежно від застосунку, перезапуск може знадобитися, якщо вони оновлюються при наступному `helm upgrade`, але якщо самі специфікації deployment не змінюються, застосунок продовжує працювати зі старою конфігурацією, що призводить до неконсистентного deployment. + +Функція `sha256sum` може бути використана для забезпечення оновлення секції анотацій розгортання, якщо змінюється інший файл: + +```yaml +kind: Deployment +spec: + template: + metadata: + annotations: + checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }} +[...] +``` + +ПРИМІТКА: Якщо ви додаєте це до бібліотечного чарту, ви не зможете отримати доступ до вашого файлу в `$.Template.BasePath`. Замість цього можна посилатися на ваше визначення за допомогою `{{ include ("mylibchart.configmap") . | sha256sum }}`. + +У випадку, коли ви завжди хочете перезапустити свій deployment, ви можете використати аналогічний крок з анотацією, як вище, замінивши його випадковим рядком, щоб він завжди змінювався і викликав перезапуск deployment: + +```yaml +kind: Deployment +spec: + template: + metadata: + annotations: + rollme: {{ randAlphaNum 5 | quote }} +[...] +``` + +Кожен виклик функції шаблону генеруватиме унікальний випадковий рядок. Це означає, що якщо необхідно синхронізувати випадкові рядки, що використовуються декількома ресурсами, всі відповідні ресурси повинні бути в одному файлі шаблону. + +Обидва ці методи дозволяють вашому deployment використовувати вбудовану логіку стратегії оновлення, щоб уникнути простоїв. + +ПРИМІТКА: Раніше ми рекомендували використовувати прапорець `--recreate-pods` як інший варіант. Цей прапорець було позначено застарілим у Helm 3 на користь більш декларативного методу, описаного вище. + +## Скажіть Helm не видаляти ресурс {#tell-helm-not-to-uninstall-a-resource} + +Іноді є ресурси, які не слід видаляти під час виконання команди `helm uninstall`. Розробники чартів можуть додати анотацію до ресурсу, щоб запобігти його видаленню. + +```yaml +kind: Secret +metadata: + annotations: + helm.sh/resource-policy: keep +[...] +``` + +Анотація `helm.sh/resource-policy: keep` говорить Helm не видаляти цей ресурс, коли операція Helm (така як `helm uninstall`, `helm upgrade` або `helm rollback`) призвела б до його видалення. _Однак_, цей ресурс стає сиротою. Helm більше не керує ним у будь-який спосіб. Це може призвести до проблем, якщо використовувати `helm install --replace` для релізу, який вже був видалений, але зберіг ресурси. + +## Використання "Partials" та включень шаблонів {#using-partials-and-template-includes} + +Іноді ви хочете створити деякі багаторазові частини у вашому чарті, незалежно від того, чи це блоки або часткові шаблони. І часто, чистіше зберігати їх у власних файлах. + +У теці `templates/`, будь-який файл, що починається з підкреслення (`_`), не призначений для виведення файлу маніфесту Kubernetes. Таким чином, за домовленістю, допоміжні шаблони та часткові шаблони розміщуються у файлі `_helpers.tpl`. + +## Складні чарти з багатьма залежностями {#complex-charts-with-many-dependencies} + +Багато чартів у CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0) є "будівельними блоками" для створення складніших застосунків. Але чарти можуть бути використані для створення екземплярів великомасштабних застосунків. У таких випадках один основний чарт може мати декілька вкладених субчартів, кожен з яких функціонує як частина цілого. + +Найкращою практикою для збирання складного застосунку з окремих частин є створення основного чарту, який надає глобальні конфігурації, а потім використання підтеки `charts/` для вбудовування кожного з компонентів. + +## YAML — це надмножина JSON {#yaml-is-a-superset-of-json} + +Згідно зі специфікацією YAML, YAML є надмножиною JSON. Це означає, що будь-яка допустима структура JSON має бути дійсною в YAML. + +Це має перевагу: іноді розробникам шаблонів може бути простіше виразити структуру даних з синтаксисом, схожим на JSON, ніж мати справу з чутливістю YAML до пробілів. + +Як правило, шаблони повинні відповідати синтаксису, схожому на YAML, _якщо_ синтаксис JSON суттєво не знижує ризик виникнення проблем з форматуванням. + +## Будьте обережні з генерацією випадкових значень {#be-careful-with-generating-random-values} + +У Helm є функції, які дозволяють генерувати випадкові дані, криптографічні ключі тощо. Вони цілком придатні для використання. Але майте на увазі, що під час оновлень шаблони виконуються знову. Коли виконання шаблону генерує дані, що відрізняються від останнього виконання, це викликає оновлення цього ресурсу. + +## Встановлення або оновлення релізу однією командою + +Helm надає можливість виконати встановлення або оновлення як одну команду. Використовуйте `helm upgrade` з командою `--install`. Це змусить Helm перевірити, чи реліз вже встановлено. Якщо ні, буде виконано встановлення. Якщо так, то наявний реліз буде оновлено. + +```console +$ helm upgrade --install <назва релізу> --values <файл значень> <тека чарту> +``` diff --git a/content/uk/docs/intro/CheatSheet.md b/content/uk/docs/intro/CheatSheet.md new file mode 100644 index 000000000..95ad5d0d5 --- /dev/null +++ b/content/uk/docs/intro/CheatSheet.md @@ -0,0 +1,141 @@ +--- +title: "Шпаргалка" +description: "Шпаргалка Helm" +weight: 4 +--- + +Підказка Helm з усіма необхідними командами для керування програмою через Helm. + +--- + +### Основні інтерпретації/контекст {#basic-interpretations-context} + +**Chart (Чарт):** +- Це назва вашого чарту у випадку, якщо його було завантаженла та розпаковано. +- Це `/`, якщо репозиторій був доданий, але чарт не завантажений. +- Це URL/Абсолютний шлях до чарту. + +**Name (Назва):** +- Це назва, яку ви хочете надати вашій поточній установці Helm-чарту. + +**Release (Реліз):** +- Це назва, яку ви присвоїли екземпляру установки. + +**Revision (Версія):** +- Це значення з команди Helm history. + +**Repo-name (Назва репозиторію):** +- Назва репозиторію. + +**DIR (Тека):** +- Назва/шлях теки. + +--- + +### Управління чартами {#chart-management} + +```bash +helm create # Створює теку чарту разом з загальними файлами та теками, які використовуються в чарті. +helm package # Упаковує чарт у файл архіву з версією. +helm lint # Запускає тести для перевірки чарту та виявлення можливих проблем. +helm show all # Переглядає чарт та виводить його вміст. +helm show values # Показує вміст файлу values.yaml. +helm pull # Завантажує/витягує чарт. +helm pull --untar=true # Якщо встановлено в true, розпаковує чарт після завантаження. +helm pull --verify # Перевіряє пакет перед використанням. +helm pull --version # СТандартно використовується остання версія, вкажіть обмеження версії для використання чарту. +helm dependency list # Відображає список залежностей чарту. +``` + +--- + +### Встановлення та видалення застосунків {#install-and-uninstall-apps} + +```bash +helm install # Встановлює чарт з зазначеною назвою. +helm install --namespace # Встановлює чарт у певному просторі імен. +helm install --set key1=val1,key2=val2 # Встановлює значення в командному рядку (можна вказати кілька значень, розділених комами). +helm install --values # Встановлює чарт з вказаними вами значеннями. +helm install --dry-run --debug # Запускає тестове встановлення для перевірки чарту. +helm install --verify # Перевіряє пакет перед використанням. +helm install --dependency-update # Оновлює залежності, якщо вони відсутні, перед встановленням чарту. +helm uninstall # Видаляє реліз. +``` + +--- + +### Оновлення застосунків та відкат {#perform-app-upgrade-and-rollback} + +```bash +helm upgrade # Оновлює реліз. +helm upgrade --atomic # Якщо встановлено, процес оновлення поверне зміни в разі невдалого оновлення. +helm upgrade --dependency-update # Оновлює залежності, якщо вони відсутні, перед встановленням чарту. +helm upgrade --version # Вказує обмеження версії для використання чарту. +helm upgrade --values # Вказує значення у YAML файлі або URL (можна вказати кілька). +helm upgrade --set key1=val1,key2=val2 # Встановлює значення d командному рядку (можна вказати кілька значень). +helm upgrade --force # Примусове оновлення ресурсів через стратегію заміни. +helm rollback # Повертає реліз до певної версії. +helm rollback --cleanup-on-fail # Дозволяє видалення нових ресурсів, створених під час цього відкату, якщо відкат не вдалося здійснити. +``` + +--- + +### Вивід списку, додавання, видалення та оновлення репозиторіїв {#list-add-remove-and-update-repositories} + +```bash +helm repo add # Додає репозиторій з Інтернету. +helm repo list # Переглядає список доданих репозиторіїв чартів. +helm repo update # Оновлює інформацію про доступні чарти локально з репозиторіїв чартів. +helm repo remove # Видаляє один або кілька репозиторіїв чартів. +helm repo index # Читає поточну теку та генерує файл індексу на основі знайдених чартів. +helm repo index --merge # Зливає згенерований індекс з існуючим файлом індексу. +helm search repo # Шукає в репозиторіях за ключовим словом в чарті. +helm search hub # Шукає чарт в Artifact Hub або у вашому власному хабі. +``` + +--- + +### Моніторинг релізів Helm {#helm-release-monitoring} + +```bash +helm list # Переглядає всі релізи для вказаного простору імен, використовує поточний контекст простору імен, якщо простір не вказано. +helm list --all # Показує всі релізи без жодних фільтрів, можна використовувати -a. +helm list --all-namespaces # Переглядає релізи по всіх просторах імен, можна використовувати -A. +helm list -l key1=value1,key2=value2 # Селектор (запит за мітками) для фільтрації, підтримує '=', '==' і '!='. +helm list --date # Сортує за датою релізу. +helm list --deployed # Показує розгорнуті релізи. Якщо не вказано інше, це буде автоматично увімкнено. +helm list --pending # Показує очікуючі релізи. +helm list --failed # Показує невдалі релізи. +helm list --uninstalled # Показує видалені релізи (якщо використовувався 'helm uninstall --keep-history'). +helm list --superseded # Показує замінені релізи. +helm list -o yaml # Виводить результат у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table). +helm status # Ця команда показує статус зазначеного релізу. +helm status --revision # Якщо встановлено, відображає статус зазначеного релізу з версією. +helm history # Історичні версії для даного релізу. +helm env # Env виводить всю інформацію про середовище, що використовується Helm. +``` + +--- + +### Завантаження інформації про реліз {#download-release-information} + +```bash +helm get all # Колекція інформації про нотатки, хуки, надані значення та згенерований маніфест файлу для вказаного релізу. +helm get hooks # Завантажує хуки для вказаного релізу. Хуки форматує у YAML і розділяє за допомогою роздільника YAML '---\n'. +helm get manifest # Маніфест є YAML-кодованим поданням ресурсів Kubernetes, що були згенеровані з цього релізу чарту. Якщо чарт залежить від інших чартів, ці ресурси також будуть включені в маніфест. +helm get notes # Показує нотатки, надані чартом для зазначеного релізу. +helm get values # Завантажує файл значень для даного релізу. Використовуйте -o для форматування виходу. +``` + +--- + +### Управління втулками {#plugin-management} + +```bash +helm plugin install # Встановлення втулків. +helm plugin list # Перегляд списку всіх встановлених втулків. +helm plugin update # Оновлення втулків. +helm plugin uninstall # Видалення втулка. +``` + +--- diff --git a/content/uk/docs/intro/_index.md b/content/uk/docs/intro/_index.md new file mode 100644 index 000000000..293fdf7ae --- /dev/null +++ b/content/uk/docs/intro/_index.md @@ -0,0 +1,8 @@ +--- +title: "Вступ" +weight: 1 +--- + +# Введення в Helm {#introduction-to-helm} + +Ви новачок у Helm? Це місце, з якого варто почати! diff --git a/content/uk/docs/intro/install.md b/content/uk/docs/intro/install.md new file mode 100644 index 000000000..ded081384 --- /dev/null +++ b/content/uk/docs/intro/install.md @@ -0,0 +1,145 @@ +--- +title: "Встановлення Helm" +description: "Дізнайтеся, як встановити та розпочати роботу з Helm." +weight: 2 +--- + +Цей посібник показує, як встановити Helm CLI. Helm можна встановити або з джерела, або з попередньо зібраних бінарних релізів. + +## Від проєкту Helm {#from-the-helm-project} + +Проєкт Helm надає два способи отримання та встановлення Helm. Це офіційні методи отримання релізів Helm. Крім того, спільнота Helm пропонує методи встановлення Helm через різні менеджери пакетів. Встановлення через ці методи можна знайти нижче офіційних методів. + +### З бінарних релізів {#from-the-binary-releases} + +Кожен [реліз](https://github.com/helm/helm/releases) Helm надає бінарні релізи для різних операційних систем. Ці бінарні версії можна завантажити та встановити вручну. + +1. Завантажте [бажану версію](https://github.com/helm/helm/releases) +2. Розпакуйте її (`tar -zxvf helm-v3.0.0-linux-amd64.tar.gz`) +3. Знайдіть бінарний файл `helm` у розпакованій директорії та перемістіть його в потрібне місце (`mv linux-amd64/helm /usr/local/bin/helm`) + +Після цього ви повинні мати можливість запускати клієнт і [додати стабільний репозиторій](https://helm.sh/docs/intro/quickstart/#initialize-a-helm-chart-repository): `helm help`. + +**Примітка:** Автоматизовані тести Helm виконуються лише для Linux AMD64 під час CircleCi збірок та релізів. Тестування інших операційних систем є відповідальністю спільноти, якій потрібен Helm для цієї операційної системи. + +### Зі сценарію {#from-script} + +Тепер Helm має скрипт інсталятора, який автоматично завантажує останню версію Helm і [встановлює її локально](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3). + +Ви можете завантажити цей скрипт, а потім виконати його локально. Він добре задокументований, щоб ви могли ознайомитися з ним і зрозуміти, що він робить перед його запуском. + +```console +$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 +$ chmod 700 get_helm.sh +$ ./get_helm.sh +``` + +Так, ви можете виконати `curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash`, якщо хочете жити на межі. + +## Через менеджери пакетів {#through-package-managers} + +Спільнота Helm надає можливість встановити Helm через менеджери пакетів операційних систем. Ці методи не підтримуються проєктом Helm і не вважаються надійними третіми сторонами. + +### Через Homebrew (macOS) {#from-homebrew-macos} + +Члени спільноти Helm додали формулу Helm до Homebrew. Ця формула зазвичай оновлюється. + +```console +brew install helm +``` + +(Примітка: Також існує формула для emacs-helm, яка є іншим проєктом.) + +### Через Chocolatey (Windows) {#from-chocolatey-windows} + +Члени спільноти Helm додали [пакет Helm](https://chocolatey.org/packages/kubernetes-helm) до [Chocolatey](https://chocolatey.org/). Цей пакет зазвичай оновлюється. + +```console +choco install kubernetes-helm +``` + +### Через Scoop (Windows) {#from-scoop-windows} + +Члени спільноти Helm додали [пакет Helm](https://github.com/ScoopInstaller/Main/blob/master/bucket/helm.json) до [Scoop](https://scoop.sh). Цей пакет зазвичай оновлюється. + +```console +scoop install helm +``` + +### Через Winget (Windows) {#from-winget-windows} + +Члени спільноти Helm додали [пакет Helm](https://github.com/microsoft/winget-pkgs/tree/master/manifests/h/Helm/Helm) до [Winget](https://learn.microsoft.com/en-us/windows/package-manager/). Цей пакет зазвичай оновлюється. + +```console +winget install Helm.Helm +``` + +### Через Apt (Debian/Ubuntu) {#from-apt-debian-ubuntu} + +Члени спільноти Helm додали [пакет Helm](https://helm.baltorepo.com/stable/debian/) для Apt. Цей пакет зазвичай оновлюється. + +```console +curl https://baltocdn.com/helm/signing.asc | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null +sudo apt-get install apt-transport-https --yes +echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/helm.gpg] https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list +sudo apt-get update +sudo apt-get install helm +``` + +### Через dnf/yum (fedora) {#from-dnf-yum-fedora} + +Починаючи з Fedora 35, helm доступний в офіційному репозиторії. Ви можете встановити helm, виконавши: + +```console +sudo dnf install helm +``` + +### Через Snap {#from-snap} + +Спільнота [Snapcrafters](https://github.com/snapcrafters) підтримує версію Snap пакету [Helm](https://snapcraft.io/helm): + +```console +sudo snap install helm --classic +``` + +### Через pkg (FreeBSD) {#from-pkg-freebsd} + +Члени спільноти FreeBSD додали [пакет Helm](https://www.freshports.org/sysutils/helm) до [Колекції портів FreeBSD](https://man.freebsd.org/ports). Цей пакет зазвичай оновлюється. + +```console +pkg install helm +``` + +### Збірки для розробників {#development-builds} + +Окрім релізів, ви можете завантажити або встановити розробницькі версії Helm. + +### З Canary збірок {#from-canary-builds} + +"Canary" збірки — це версії програмного забезпечення Helm, які створюються з останньої гілки `main`. Вони не є офіційними релізами та можуть бути нестабільними. Однак, вони надають можливість тестувати найновіші функції. + +Canary бінарні файли Helm зберігаються на [get.helm.sh](https://get.helm.sh). Ось посилання на основні збірки: + +- [Linux AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz) +- [macOS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz) +- [Експериментальний Windows AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip) + +### З сирців (Linux, macOS) {#from-source} + +Збірка Helm з сирців є дещо більш трудомісткою, але це найкращий спосіб, якщо ви хочете тестувати найновішу (передрелізну) версію Helm. + +У вас повинно бути налаштоване середовище Go. + +```console +$ git clone https://github.com/helm/helm.git +$ cd helm +$ make +``` + +За необхідності, будуть завантажені залежності та збережені в кеші, а також перевірено конфігурацію. Після цього `helm` буде скомпільований і розміщений у `bin/helm`. + +## Підсумки {#conclusion} + +У більшості випадків, встановлення настільки просте, як отримання попередньо зібраного бінарного файлу `helm`. Цей документ охоплює додаткові випадки для тих, хто хоче робити складніші речі з Helm. + +Після успішного встановлення клієнта Helm, ви можете перейти до використання Helm для керування чартами та [додавання стабільного репозиторію](https://helm.sh/docs/intro/quickstart/#initialize-a-helm-chart-repository). diff --git a/content/uk/docs/intro/quickstart.md b/content/uk/docs/intro/quickstart.md new file mode 100644 index 000000000..71c3fbf75 --- /dev/null +++ b/content/uk/docs/intro/quickstart.md @@ -0,0 +1,114 @@ +--- +title: "Швидкий старт" +description: "Як встановити та почати роботу з Helm, включаючи інструкції для дистрибутивів, поширені запитання та втулки." +weight: 1 +--- + +У цьому посібнику ви дізнаєтеся, як швидко почати користуватися Helm. + +## Попередні умови {#prerequisites} + +Для успішного та належного використання Helm потрібні наступні умови. + +1. Кластер Kubernetes +2. Визначення, які конфігурації безпеки застосувати до вашої інсталяції, якщо такі є +3. Встановлення та налаштування Helm. + +### Встановлення Kubernetes або доступ до кластера {#install-kubernetes-or-have-access-to-a-cluster} + +- У вас повинен бути встановлений Kubernetes. Для останньої версії Helm ми рекомендуємо використовувати останню стабільну версію Kubernetes, що в більшості випадків є передостанньою мінорною версією. +- У вас також має бути локально налаштована копія `kubectl`. + +Дивіться [Політику підтримки версій Helm](https://helm.sh/docs/topics/version_skew/) щодо максимальної підтримуваної різниці версій між Helm і Kubernetes. + +## Встановлення Helm {#install-helm} + +Завантажте бінарний реліз клієнта Helm. Ви можете використовувати такі інструменти, як `homebrew`, або перегляньте [сторінку офіційних релізів](https://github.com/helm/helm/releases). + +Для отримання більш детальної інформації або інших варіантів, дивіться [посібник з встановлення]({{< ref "install.md" >}}). + +## Ініціалізація репозиторію Helm Chart {#initialize-a-helm-chart-repository} + +Як тільки Helm буде готовий, ви можете додати репозиторій чартів. Перевірте [Artifact Hub](https://artifacthub.io/packages/search?kind=0) для доступних репозиторіїв чартів Helm. + +```console +$ helm repo add bitnami https://charts.bitnami.com/bitnami +``` + +Після цього ви зможете переглянути доступні для встановлення чарти: + +```console +$ helm search repo bitnami +NAME CHART VERSION APP VERSION DESCRIPTION +bitnami/bitnami-common 0.0.9 0.0.9 DEPRECATED Chart with custom templates used in ... +bitnami/airflow 8.0.2 2.0.0 Apache Airflow is a platform to programmaticall... +bitnami/apache 8.2.3 2.4.46 Chart for Apache HTTP Server +bitnami/aspnet-core 1.2.3 3.1.9 ASP.NET Core is an open-source framework create... +# ... і багато інших +``` + +## Встановлення прикладу чарту {#install-an-example-chart} + +Для встановлення чарту можна використати команду `helm install`. Helm пропонує кілька способів знаходження та встановлення чарту, але найпростіший — це використання чартів від `bitnami`. + +```console +$ helm repo update # Переконайтеся, що ви отримали останній список чартів +$ helm install bitnami/mysql --generate-name +NAME: mysql-1612624192 +LAST DEPLOYED: Sat Feb 6 16:09:56 2021 +NAMESPACE: default +STATUS: deployed +REVISION: 1 +TEST SUITE: None +NOTES: ... +``` + +У наведеному вище прикладі чарт `bitnami/mysql` було розгорнуто, а імʼя нашого нового релізу — `mysql-1612624192`. + +Ви можете отримати уявлення про можливості цього чарту MySQL, виконавши команду `helm show chart bitnami/mysql`. Або ви можете виконати `helm show all bitnami/mysql`, щоб отримати всю інформацію про чарт. + +Кожного разу, коли ви встановлюєте чарт, створюється новий реліз. Отже, один чарт може бути встановлений кілька разів у тому ж кластері. І кожен може керуватися та оновлюватися незалежно. + +Команда `helm install` є дуже потужною з багатьма можливостями. Щоб дізнатися більше про неї, перегляньте +[Посібник з використання Helm]({{< ref "using_helm.md" >}}). + +## Дізнайтеся про релізи {#learn-about-releases} + +Дуже просто побачити, що було розгорнуто за допомогою Helm: + +```console +$ helm list +NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION +mysql-1612624192 default 1 2021-02-06 16:09:56.283059 +0100 CET deployed mysql-8.3.0 8.0.23 +``` + +Функція `helm list` (або `helm ls`) покаже вам список усіх розгорнутих релізів. + +## Видалення релізу {#uninstall-a-release} + +Щоб видалити реліз, скористайтеся командою `helm uninstall`: + +```console +$ helm uninstall mysql-1612624192 +release "mysql-1612624192" uninstalled +``` + +Це видалить `mysql-1612624192` з Kubernetes, що видалить всі ресурси, повʼязані з релізом, а також історію релізу. + +Якщо буде надано прапорець `--keep-history`, історія релізу буде збережена. Ви зможете запитувати інформацію про цей реліз: + +```console +$ helm status mysql-1612624192 +Status: UNINSTALLED +... +``` + +Оскільки Helm відстежує ваші релізи навіть після того, як ви їх видалили, ви можете переглядати історію кластера і навіть відновити реліз (за допомогою `helm rollback`). + +## Ознайомлення з довідкою {#reading-the-help-text} + +Щоб дізнатися більше про доступні команди Helm, використовуйте `helm help` або введіть команду з прапорцем `-h`: + +```console +$ helm get -h +``` diff --git a/content/uk/docs/intro/using_helm.md b/content/uk/docs/intro/using_helm.md new file mode 100644 index 000000000..577d628a5 --- /dev/null +++ b/content/uk/docs/intro/using_helm.md @@ -0,0 +1,441 @@ +--- +title: "Використання Helm" +description: "Описує основи роботи з Helm." +weight: 3 +--- + +Цей посібник пояснює основи використання Helm для керування пакетами у вашому кластері Kubernetes. Передбачається, що ви вже [встановили]({{< ref "install.md" >}}) клієнт Helm. + +Якщо вас цікавить лише виконання кількох швидких команд, можливо, ви захочете почати з [Посібника зі швидкого старту]({{< ref "quickstart.md" >}}). У цьому розділі розглядаються особливості команд Helm та пояснюється, як використовувати Helm. + +## Три головні концепції {#three-big-concepts} + +*Chart* — це пакет Helm. Він містить усі необхідні визначення ресурсів для запуску застосунку, інструменту або сервісу всередині кластера Kubernetes. Думайте про це як про еквівалент формули Homebrew, пакету Apt dpkg або файлу Yum RPM для Kubernetes. + +*Repository* — це місце, де можна зібрати та поділитися чартами. Це як [архів CPAN](https://www.cpan.org) для Perl або [база пакетів Fedora](https://src.fedoraproject.org/), але для пакетів Kubernetes. + +*Release* — це екземпляр чарту, що працює в кластері Kubernetes. Один чарт можна встановити в кластер кілька разів. І кожного разу при встановленні створюється новий *реліз*. Наприклад, чарт MySQL. Якщо ви хочете, щоб у вашому кластері працювали дві бази даних, ви можете встановити цей чарт двічі. Кожен екземпляр матиме свій *реліз*, а також своє *імʼя релізу*. + +Маючи ці концепції на увазі, можна пояснити Helm так: + +Helm встановлює *чарти* у Kubernetes, створюючи новий *реліз* для кожного встановлення. А щоб знайти нові чарти, ви можете шукати їх у *репозиторіях чартів* Helm. + +## 'helm search': Пошук чартів {#helm-search-finding-charts} + +Helm постачається з потужною командою пошуку. Її можна використовувати для пошуку двох типів джерел: + +- `helm search hub` здійснює пошук у [Artifact Hub](https://artifacthub.io), який містить чарти helm із десятків різних репозиторіїв. +- `helm search repo` здійснює пошук у репозиторіях, які ви додали до свого локального клієнта helm (за допомогою `helm repo add`). Цей пошук здійснюється за локальними даними, і підключення до публічної мережі не потрібно. + +Ви можете знайти загальнодоступні чарти, виконавши команду `helm search hub`: + +```console +$ helm search hub wordpress +URL CHART VERSION APP VERSION DESCRIPTION +https://hub.helm.sh/charts/bitnami/wordpress 7.6.7 5.2.4 Платформа для веб-публікацій для створення блогів і ... +https://hub.helm.sh/charts/presslabs/wordpress-... v0.6.3 v0.6.3 Чарт Helm для розгортання сайту WordPress на ... +https://hub.helm.sh/charts/presslabs/wordpress-... v0.7.1 v0.7.1 Оператор WordPress для Helm +``` + +Вищенаведений пошук знаходить усі чарти `wordpress` в Artifact Hub. + +Без фільтрації `helm search hub` показує всі доступні чарти. + +За допомогою `helm search repo` ви можете знайти імена чартів у репозиторіях, які ви вже додали: + +```console +$ helm repo add brigade https://brigadecore.github.io/charts +"brigade" has been added to your repositories +$ helm search repo brigade +NAME CHART VERSION APP VERSION DESCRIPTION +brigade/brigade 1.3.2 v1.2.1 Brigade provides event-driven scripting of Kube... +brigade/brigade-github-app 0.4.1 v0.2.1 The Brigade GitHub App, an advanced gateway for... +brigade/brigade-github-oauth 0.2.0 v0.20.0 The legacy OAuth GitHub Gateway for Brigade +brigade/brigade-k8s-gateway 0.1.0 A Helm chart for Kubernetes +brigade/brigade-project 1.0.0 v1.0.0 Create a Brigade project +brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes +``` + +Helm search використовує алгоритм нечіткого порівняння рядків, тому можна вводити частини слів або фраз: + +```console +$ helm search repo kash +NAME CHART VERSION APP VERSION DESCRIPTION +brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes +``` + +Пошук — це чудовий спосіб знайти доступні пакети. Коли ви знайшли потрібний пакет, можете використовувати `helm install`, щоб встановити його. + +## 'helm install': Встановлення пакета {#helm-install-installing-a-package} + +Щоб встановити новий пакет, скористайтеся командою `helm install`. У найпростішому випадку вона приймає два аргументи: Імʼя релізу, яке ви вибираєте, та імʼя чарту, який ви хочете встановити. + +```console +$ helm install happy-panda bitnami/wordpress +NAME: happy-panda +LAST DEPLOYED: Вт Січ 26 10:27:17 2021 +NAMESPACE: default +STATUS: deployed +REVISION: 1 +NOTES: +** Будь ласка, будьте терплячими, поки чарт розгортається ** + +Ваш сайт WordPress можна відкрити за наступною DNS-адресою зсередини вашого кластера: + + happy-panda-wordpress.default.svc.cluster.local (порт 80) + +Щоб отримати доступ до вашого сайту WordPress з-за меж кластера, дотримуйтесь наступних кроків: + +1. Отримайте URL WordPress, виконавши наступні команди: + + ПРИМІТКА: Може знадобитися кілька хвилин для отримання IP-адреси LoadBalancer. + Слідкуйте за статусом за допомогою: 'kubectl get svc --namespace default -w happy-panda-wordpress' + + export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") + echo "URL WordPress: http://$SERVICE_IP/" + echo "Адмінка WordPress: http://$SERVICE_IP/admin" + +2. Відкрийте оглядач та отримайте доступ до WordPress, використовуючи отриманий URL. + +3. Увійдіть за допомогою наступних облікових даних: + + echo Логін: user + echo Пароль: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) +``` + +Тепер чарт `wordpress` встановлено. Зверніть увагу, що встановлення чарту створює новий *реліз* обʼєкта. Реліз вище називається `happy-panda`. (Якщо ви хочете, щоб Helm згенерував імʼя для вас, не вказуйте імʼя релізу і використовуйте `--generate-name`.) + +Під час встановлення клієнт `helm` надасть корисну інформацію про те, які ресурси були створені, який стан релізу, і чи є додаткові кроки конфігурації, які ви можете або повинні виконати. + +Helm встановлює ресурси в наступному порядку: + +- Namespace +- NetworkPolicy +- ResourceQuota +- LimitRange +- PodSecurityPolicy +- PodDisruptionBudget +- ServiceAccount +- Secret +- SecretList +- ConfigMap +- StorageClass +- PersistentVolume +- PersistentVolumeClaim +- CustomResourceDefinition +- ClusterRole +- ClusterRoleList +- ClusterRoleBinding +- ClusterRoleBindingList +- Role +- RoleList +- RoleBinding +- RoleBindingList +- Service +- DaemonSet +- Pod +- ReplicationController +- ReplicaSet +- Deployment +- HorizontalPodAutoscaler +- StatefulSet +- Job +- CronJob +- Ingress +- APIService + +Helm не чекає, поки всі ресурси будуть запущені, перш ніж завершити роботу. Багато чартів потребують Docker-образів розміром понад 600MB, і їхнє встановлення в кластер може тривати певний час. + +Щоб відстежувати стан релізу або повторно прочитати конфігураційну інформацію, ви можете використати команду `helm status`: + +```console +$ helm status happy-panda +NAME: happy-panda +LAST DEPLOYED: Tue Jan 26 10:27:17 2021 +NAMESPACE: default +STATUS: deployed +REVISION: 1 +NOTES: +** Будь ласка, будьте терплячими, поки чарт розгортається ** + +Ваш сайт WordPress можна відкрити за наступною DNS-адресою в межах вашого кластера: + + happy-panda-wordpress.default.svc.cluster.local (порт 80) + +Щоб отримати доступ до вашого сайту WordPress ззовні кластера, виконайте наступні дії: + +1. Отримайте URL WordPress, виконавши ці команди: + + ЗАУВАЖЕННЯ: Для появи IP LoadBalancer може знадобитися кілька хвилин. + Слідкуйте за статусом за допомогою: 'kubectl get svc --namespace default -w happy-panda-wordpress' + + export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") + echo "WordPress URL: http://$SERVICE_IP/" + echo "WordPress Admin URL: http://$SERVICE_IP/admin" + +2. Відкрийте оглядач і перейдіть на WordPress, використовуючи отриманий URL. + +3. Увійдіть за допомогою наведених нижче облікових даних, щоб побачити ваш блог: + + echo Username: user + echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) +``` + +Вищенаведене показує поточний стан вашого релізу. + +### Налаштування чарту перед встановленням {#customizing-the-chart-before-installing} + +Встановлення у спосіб, який ми розглянули, використовуватиме лише стандартні параметри конфігурації для цього чарту. У багатьох випадках вам захочеться налаштувати чарт для використання ваші налаштування. + +Щоб побачити, які параметри можна налаштувати в чарті, використовуйте команду `helm show values`: + +```console +$ helm show values bitnami/wordpress +## Параметри глобального Docker-образу +## Зверніть увагу, що це перевизначить параметри образу, включаючи залежності, налаштовані на використання глобального значення +## Наявні глобальні параметри Docker-образу: imageRegistry та imagePullSecrets +## +# global: +# imageRegistry: myRegistryName +# imagePullSecrets: +# - myRegistryKeySecretName +# storageClass: myStorageClass + +## Версія образу Bitnami WordPress +## ref: https://hub.docker.com/r/bitnami/wordpress/tags/ +## +image: + registry: docker.io + repository: bitnami/wordpress + tag: 5.6.0-debian-10-r35 + [..] +``` + +Ви можете перевизначити будь-які з цих налаштувань у файлі у форматі YAML, а потім передати цей файл під час встановлення. + +```console +$ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml +$ helm install -f values.yaml bitnami/wordpress --generate-name +``` + +Вищенаведене створить стандартного користувача MariaDB з імʼям `user0` і надасть цьому користувачеві доступ до новоствореної бази даних `user0db`, але всі інші параметри цього чарту залишаться стандартними. + +Існує два способи передати дані конфігурації під час встановлення: + +- `--values` (або `-f`): Вказати YAML-файл із перевизначеннями. Їх можна вказувати кілька разів, причому файл, що стоїть праворуч, матиме пріоритет +- `--set`: Вказати перевизначення в командному рядку. + +Якщо обидва варіанти використовуються, значення `--set` зливаються з `--values` з вищим пріоритетом. Перевизначення, зазначені за допомогою `--set`, зберігаються у Secret. Значення, що були встановлені через `--set`, можна переглянути для конкретного релізу за допомогою команди `helm get values `. Значення, встановлені за допомогою `--set`, можна скинути, виконавши `helm upgrade` з параметром `--reset-values`. + +#### Формат і обмеження параметра `--set` {#the-format-and-limitations-of-set} + +Опція `--set` приймає нуль або більше пар імʼя/значення. У найпростішому випадку вона використовується так: `--set name=value`. Еквівалент у YAML виглядає так: + +```yaml +name: value +``` + +Кілька значень розділяються символами `,`. Отже, `--set a=b,c=d` стає: + +```yaml +a: b +c: d +``` + +Підтримуються складніші вирази. Наприклад, `--set outer.inner=value` перетворюється на наступне: + +```yaml +outer: + inner: value +``` + +Списки можна записати, включивши значення в `{` і `}`. Наприклад, `--set name={a, b, c}` перетворюється на: + +```yaml +name: + - a + - b + - c +``` + +Деякі пари імʼя/ключ можна встановити як `null` або як порожній масив `[]`. Наприклад, `--set name=[],a=null` перетворюється на: + +```yaml +name: [] +a: null +``` + +Починаючи з Helm 2.5.0, можна отримувати доступ до елементів списку, використовуючи синтаксис індексу масиву. Наприклад, `--set servers[0].port=80` стає: + +```yaml +servers: + - port: 80 +``` + +Кілька значень можна встановити таким чином. Наприклад, рядок `--set servers[0].port=80,servers[0].host=example` перетворюється на: + +```yaml +servers: + - port: 80 + host: example +``` + +Іноді вам потрібно використовувати спеціальні символи у ваших рядках `--set`. Ви можете використовувати зворотний слеш для екранування символів; `--set name=value1\,value2` перетвориться на: + +```yaml +name: "value1,value2" +``` + +Аналогічно, можна екранувати послідовності крапок, що може знадобитися, коли чарти використовують функцію `toYaml` для аналізу анотацій, міток і вибору вузлів. Синтаксис для `--set nodeSelector."kubernetes\.io/role"=master` виглядає так: + +```yaml +nodeSelector: + kubernetes.io/role: master +``` + +Глибоко вкладені структури даних можуть бути складними для виразу через `--set`. Розробникам чартів рекомендується враховувати використання `--set` при розробці формату файлу `values.yaml` (докладніше про [Файли значень](../chart_template_guide/values_files/)). + +### Інші методи встановлення {#more-installation-methods} + +Команда `helm install` може встановлювати чарт із кількох джерел: + +- Репозиторій чартів (як ми бачили вище) +- Локальний архів чарту (`helm install foo foo-0.1.1.tgz`) +- Тека із розпакованим чартом (`helm install foo path/to/foo`) +- Повний URL (`helm install foo https://example.com/charts/foo-1.2.3.tgz`) + +## 'helm upgrade' і 'helm rollback': Оновлення релізу та відновлення у разі невдачі {#helm-upgrade-and-helm-rollback-updating-a-release-and-reverting-on-failure} + +Коли виходить нова версія чарту або коли ви хочете змінити конфігурацію вашого релізу, ви можете скористатися командою `helm upgrade`. + +Оновлення бере поточний реліз і оновлює його відповідно до інформації, що міститься в чарті. Ви можете оновити чарт, який було встановлено зі сховища, або чарт, який знаходиться на вашому локальному диску. + +```console +$ helm upgrade -f panda.yaml happy-panda bitnami/wordpress +``` + +У наведеному випадку реліз `happy-panda` оновлюється з використанням того ж чарту, але з новим YAML файлом: + +```yaml +mariadb.auth.username: user1 +``` + +Ми можемо використати команду `helm get values`, щоб переконатися, що нові налаштування набрали чинності. + +```console +$ helm get values happy-panda +mariadb: + auth: + username: user1 +``` + +Команда `helm get` є корисним інструментом для перегляду релізу в кластері. І як ми бачили вище, вона показує, що наші нові значення з `panda.yaml` були розгорнуті в кластері. + +Тепер, якщо під час релізу щось піде не так, можна легко повернутися до попереднього релізу, використовуючи команду `helm rollback [RELEASE] [REVISION]`. + +```console +$ helm rollback happy-panda 1 +``` + +Ця команда повертає наш реліз `happy-panda` до його першої версії. Версія релізу є інкрементним переглядом. Кожного разу, коли відбувається встановлення, оновлення або відкат, номер версії збільшується на 1. Перша версія завжди має номер 1. І ми можемо використовувати команду `helm history [RELEASE]`, щоб побачити номери версій для певного релізу. + +## Корисні опції для Install/Upgrade/Rollback {#useful-options-for-install-upgrade-rollback} + +Є кілька інших корисних опцій, які можна вказати для налаштування поведінки Helm під час встановлення/оновлення/відкату. Зауважте, що це не повний список CLI-прапорців. Щоб побачити опис усіх прапорців, просто запустіть `helm --help`. + +- `--timeout`: Значення [Go duration](https://golang.org/pkg/time/#ParseDuration), яке визначає, скільки чекати на завершення команд Kubernetes. Стандартно `5m0s`. +- `--wait`: Очікує, доки всі Podʼи не перейдуть у стан готовності, PVC не будуть повʼязані, а Deployment не матиме мінімальну кількість Podʼів у стані готовності (`Desired` мінус `maxUnavailable`), а також не отримає IP-адресу (і Ingress, якщо це `LoadBalancer`) перед тим, як визнати реліз успішним. Чекання триватиме стільки часу, скільки вказано в опції `--timeout`. Якщо тайм-аут досягнуто, реліз буде позначено як `FAILED`. Примітка: У ситуаціях, коли Deployment має `replicas` значення 1, а `maxUnavailable` не встановлено в 0 як частина стратегії rolling update, `--wait` поверне готовність, коли задоволено мінімальну кількість Podʼів у готовому стані. +- `--no-hooks`: Пропускає запуск хук для команди. +- `--recreate-pods` (доступно лише для `upgrade` та `rollback`): Цей прапорець викличе повторне створення всіх Podʼів (за винятком Podʼів, що належать до Deployment). (Застаріле в Helm 3) + +## `helm uninstall`: Видалення релізу {#helm-uninstall-uninstalling-a-release} + +Коли настає час видалити реліз з кластера, використовуйте команду `helm uninstall`: + +```console +$ helm uninstall happy-panda +``` + +Це видалить реліз з кластера. Ви можете переглянути всі ваші поточні розгорнуті релізи за допомогою команди `helm list`: + +```console +$ helm list +NAME VERSION UPDATED STATUS CHART +inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0 +``` + +З виводу вище ми можемо побачити, що реліз `happy-panda` було видалено. + +У попередніх версіях Helm, коли реліз видалявся, запис про його видалення залишався. У Helm 3 видалення також видаляє запис про реліз. Якщо ви хочете зберегти запис про видалений реліз, використовуйте `helm uninstall --keep-history`. Використання `helm list --uninstalled` покаже лише ті релізи, які були видалені з прапорцем `--keep-history`. + +Прапорець `helm list --all` покаже вам всі записи релізів, які зберіг Helm, включаючи записи для невдалих або видалених елементів (якщо було вказано `--keep-history`): + +```console +$ helm list --all +NAME VERSION UPDATED STATUS CHART +happy-panda 2 Wed Sep 28 12:47:54 2016 UNINSTALLED wordpress-10.4.5.6.0 +inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0 +kindred-angelf 2 Tue Sep 27 16:16:10 2016 UNINSTALLED alpine-0.1.0 +``` + +Зверніть увагу, що через те, що релізи тепер стандартно видаляються, більше неможливо зробити відкат до видаленого ресурсу. + +## `helm repo`: Робота з репозиторіями {#helm-repo-working-with-repositories} + +Helm 3 більше не постачається зі стандартним репозиторієм чартів. Група команд `helm repo` надає команди для додавання, перегляду та видалення репозиторіїв. + +Ви можете переглянути, які репозиторії налаштовані, використовуючи `helm repo list`: + +```console +$ helm repo list +NAME URL +stable https://charts.helm.sh/stable +mumoshu https://mumoshu.github.io/charts +``` + +Нові репозиторії можна додати за допомогою `helm repo add`: + +```console +$ helm repo add dev https://example.com/dev-charts +``` + +Оскільки репозиторії чартів часто змінюються, у будь-який момент ви можете переконатися, що ваш клієнт Helm актуальний, запустивши `helm repo update`. + +Репозиторії можна видалити за допомогою `helm repo remove`. + +## Створення власних чартів {#creating-your-own-charts} + +[Посібник з розробки чартів]({{< ref "../topics/charts.md" >}}) пояснює, як розробляти власні чарти. Але ви можете швидко розпочати, використовуючи команду `helm create`: + +```console +$ helm create deis-workflow +Creating deis-workflow +``` + +Тепер у вас є чарт в теці `./deis-workflow`. Ви можете редагувати його та створювати власні шаблони. + +Коли ви редагуєте свій чарт, ви можете перевірити, чи він добре сформований, запустивши команду `helm lint`. + +Коли настане час упакувати чарт для розповсюдження, ви можете скористатися командою `helm package`: + +```console +$ helm package deis-workflow +deis-workflow-0.1.0.tgz +``` + +І цей чарт тепер може бути легко встановлена за допомогою `helm install`: + +```console +$ helm install deis-workflow ./deis-workflow-0.1.0.tgz +... +``` + +Упаковані чарти можуть бути завантажені в репозиторії чартів. Для отримання додаткової інформації дивіться документацію про [репозиторії чартів Helm]({{< ref "/docs/topics/chart_repository.md" >}}). + +## Висновки {#conclusion} + +У цьому розділі було розглянуто основні шаблони використання клієнта `helm`, включаючи пошук, встановлення, оновлення та видалення. Також було розглянуто корисні утиліти, такі як `helm status`, `helm get` і `helm repo`. + +Для отримання додаткової інформації про ці команди перегляньте вбудовану довідку Helm: `helm help`. + +У [наступному розділі](../howto/charts_tips_and_tricks/) ми розглянемо процес створення чартів. diff --git a/content/uk/docs/topics/_index.md b/content/uk/docs/topics/_index.md new file mode 100644 index 000000000..976fe3712 --- /dev/null +++ b/content/uk/docs/topics/_index.md @@ -0,0 +1,8 @@ +--- +title: "Посібники" +weight: 3 +--- + +# Тематичні посібники + +Тут ви знайдете вступ до всіх ключових частин Helm, які вам знадобляться або які ви хочете знати. diff --git a/content/uk/docs/topics/advanced.md b/content/uk/docs/topics/advanced.md new file mode 100644 index 000000000..3c6eec76f --- /dev/null +++ b/content/uk/docs/topics/advanced.md @@ -0,0 +1,160 @@ +--- +title: "Розширені техніки Helm" +description: "Описує різні розширені функції для досвдічених користувачів Helm" +weight: 9 +--- + +Цей розділ пояснює різні розширені функції та техніки використання Helm. Інформація в цьому розділі призначена для "досвідчених користувачів" Helm, які бажають здійснювати докладні налаштування та маніпуляції з їх чартами та випусками. Кожна з цих розширених функцій має свої переваги та обмеження, тому кожну з них потрібно використовувати обережно і з глибокими знаннями Helm. Іншими словами, памʼятайте про [принцип Пітера Паркера](https://en.wikipedia.org/wiki/With_great_power_comes_great_responsibility). + +## Пост-рендеринг {#post-rendering} + +Пост-рендеринг дає можливість встановлювачу чартів вручну маніпулювати, налаштовувати та/або перевіряти створені маніфести перед їх встановленням через Helm. Це дозволяє користувачам з додатковими потребами у налаштуванні використовувати інструменти, такі як [`kustomize`](https://kustomize.io), для застосування змін конфігурації без необхідності створювати форк публічного чарту або вимагати від супроводжувачів чартів вказувати всі можливі опції конфігурації для програмного забезпечення. Є також випадки для впровадження загальних інструментів та контейнерів sidecar у корпоративних середовищах або для аналізу маніфестів перед розгортанням. + +### Передумови {#prerequisites} + +- Helm 3.1+ + +### Використання {#usage} + +Пост-рендерер може бути будь-яким виконуваним файлом, який приймає створені маніфести Kubernetes через STDIN та повертає дійсні маніфести Kubernetes через STDOUT. Він повинен повертати ненульовий код завершення у випадку помилки. Це єдиний "API" між двома компонентами. Це дозволяє значну гнучкість у тому, що ви можете робити з вашим процесом пост-рендерингу. + +Пост-рендерер можна використовувати з `install`, `upgrade` і `template`. Щоб використовувати пост-рендерер, використовуйте прапорець `--post-renderer` з шляхом до виконуваного файлу рендерера, який ви бажаєте використовувати: + +```shell +$ helm install mychart stable/wordpress --post-renderer ./path/to/executable +``` + +Якщо шлях не містить жодних роздільників, пошук буде здійснюватись в $PATH, в іншому випадку буде створено будь-які відносні шляхи до повністю кваліфікованого шляху. + +Якщо ви бажаєте використовувати кілька пост-рендерерів, викликайте їх усіх у скрипті або разом у будь-якому бінарному інструменті, який ви створили. У bash це буде так просто, як `renderer1 | renderer2 | renderer3`. + +Приклад використання `kustomize` як пост-рендерера можна побачити [тут](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render). + +### Обмеження {#caveats} + +При використанні пост-рендерерів є кілька важливих моментів, які слід враховувати. Найважливіше з них полягає в тому, що при використанні пост-рендерера всі особи, які модифікують цей випуск, **МУСЯТЬ** використовувати той же рендерер для забезпечення повторюваних збірок. Ця функція спеціально створена для того, щоб дозволити будь-якому користувачеві змінювати рендерер або перестати використовувати рендерер, але це слід робити обережно, щоб уникнути випадкових змін або втрати даних. + +Ще одне важливе зауваження стосується безпеки. Якщо ви використовуєте пост-рендерер, ви повинні впевнитися, що він надходить з надійного джерела (так само як і будь-яке інше програмне забезпечення). Використання ненадійних або неперевірених рендерерів НЕ рекомендовано, оскільки вони мають повний доступ до створених шаблонів, які часто містять секретні дані. + +### Власні пост-рендерери {#custom-post-renderers} + +Крок пост-рендерингу пропонує ще більше гнучкості при використанні в Go SDK. Будь-який пост-рендерер повинен реалізувати наступний Go інтерфейс: + +```go +type PostRenderer interface { + // Run очікує один буфер, заповнений відрендереними маніфестами Helm. Він + // очікує, що модифіковані результати будуть повернені в окремому буфері або + // помилку, якщо виникла проблема або збій під час виконання кроку пост-рендерингу + Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error) +} +``` + +Більше інформації про використання Go SDK можна знайти в [розділі Go SDK](#go-sdk). + +## Go SDK {#go-sdk} + +Helm 3 представив повністю переписаний Go SDK для кращого досвіду при розробці програмного забезпечення та інструментів, які використовують Helm. Повну документацію можна знайти на [https://pkg.go.dev/helm.sh/helm/v3](https://pkg.go.dev/helm.sh/helm/v3), але короткий огляд деяких найбільш популярних пакетів і простий приклад наведені нижче. + +### Огляд пакетів {#package-overview} + +Ось список найбільш часто використовуваних пакетів з простим поясненням кожного: + +- `pkg/action`: Містить основний "клієнт" для виконання дій Helm. Це той самий пакет, який використовує CLI "під капотом". Якщо вам просто потрібно виконати базові команди Helm з іншої програми Go, цей пакет для вас. +- `pkg/{chart,chartutil}`: Методи та допоміжні засоби для завантаження та маніпулювання чартами. +- `pkg/cli` і його пакети: Містять усі обробники стандартних змінних середовища Helm, а його пакети містять обробку виводів та файлів значень. +- `pkg/release`: Визначає обʼєкт `Release` та статуси. + +Очевидно, існує багато інших пакетів, тому перегляньте документацію для отримання додаткової інформації! + +### Простий приклад {#simple-example} + +Ось простий приклад виконання `helm list` за допомогою Go SDK: + +```go +package main + +import ( + "log" + "os" + + "helm.sh/helm/v3/pkg/action" + "helm.sh/helm/v3/pkg/cli" +) + +func main() { + settings := cli.New() + + actionConfig := new(action.Configuration) + // Ви можете передати порожній рядок замість settings.Namespace(), щоб + // перелічити всі простори імен + if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv("HELM_DRIVER"), log.Printf); err != nil { + log.Printf("%+v", err) + os.Exit(1) + } + + client := action.NewList(actionConfig) + // Лише перерахувати розгорнуті + client.Deployed = true + results, err := client.Run() + if err != nil { + log.Printf("%+v", err) + os.Exit(1) + } + + for _, rel := range results { + log.Printf("%+v", rel) + } +} +``` + +## Сховища даних {#storage-backends} + +Helm 3 змінив стандартне зберігання інформації про випуски на Secrets у просторі імен випуску. Helm 2 стандартно зберігає інформацію про випуски як ConfigMaps у просторі імен екземпляра Tiller. Підрозділи, що йдуть далі, показують, як налаштувати різні бекенди. Це налаштування базується на змінній середовища `HELM_DRIVER`. Вона може бути встановлена на одне зі значень: `[configmap, secret, sql]`. + +### Бекенд зберігання ConfigMap {#configmap-storage-backend} + +Щоб активувати бекенд ConfigMap, потрібно встановити змінну середовища `HELM_DRIVER` на `configmap`. + +Ви можете встановити її в оболонці наступним чином: + +```shell +export HELM_DRIVER=configmap +``` + +Якщо ви хочете перемикнутися зі стандартного бекенду на бекенд ConfigMap, вам потрібно буде виконати міграцію самостійно. Ви можете отримати інформацію про випуски за допомогою наступної команди: + +```shell +kubectl get secret --all-namespaces -l "owner=helm" +``` + +**Примітки щодо операційної діяльності**: Інформація про випуски включає вміст чартів та файлів значень і тому може містити чутливі дані (наприклад, паролі, приватні ключі та інші облікові дані), які потрібно захищати від несанкціонованого доступу. При керуванні авторизацією Kubernetes, наприклад, з [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), можливо надати ширший доступ до ресурсів ConfigMap, одночасно обмежуючи доступ до ресурсів Secret. Наприклад, стандартна роль [користувача](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) "view" надає доступ до більшості ресурсів, але не до Secrets. Крім того, дані секретів можуть бути налаштовані для [шифрування](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/). Будь ласка, врахуйте це, якщо ви вирішите перейти на бекенд ConfigMap, оскільки це може розкрити чутливі дані вашого застосунку. + +### Бекенд зберігання SQL {#sql-storage-backend} + +Існує ***бета*** бекенд зберігання SQL, який зберігає інформацію про випуски в SQL базі даних. + +Використання такого бекенду зберігання є особливо корисним, якщо інформація про ваші випуски перевищує 1 МБ (у цьому випадку її не можна зберігати в ConfigMaps/Secrets через внутрішні обмеження сховища ключ-значення etcd у Kubernetes). + +Щоб активувати SQL бекенд, потрібно розгорнути SQL базу даних і встановити змінну середовища `HELM_DRIVER` на `sql`. Деталі бази даних задаються змінною середовища `HELM_DRIVER_SQL_CONNECTION_STRING`. + +Ви можете встановити її в оболонці наступним чином: + +```shell +export HELM_DRIVER=sql +export HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme +``` + +> Примітка: Зараз підтримується лише PostgreSQL. + +**Примітки щодо операційної діяльності**: + +Рекомендується: + +- Підготувати вашу базу даних для операційної діяльності. Для PostgreSQL перегляньте [документацію з адміністрування сервера](https://www.postgresql.org/docs/12/admin.html) для отримання додаткової інформації. +- Увімкнути [управління дозволами](/docs/permissions_sql_storage_backend/) для дзеркального відображення Kubernetes RBAC для інформації про випуски. + +Якщо ви хочете перемикнутися зі стандартного бекенду на SQL бекенд, вам потрібно буде виконати міграцію самостійно. Ви можете отримати інформацію про випуски за допомогою наступної команди: + +```shell +kubectl get secret --all-namespaces -l "owner=helm" +``` diff --git a/content/uk/docs/topics/architecture.md b/content/uk/docs/topics/architecture.md new file mode 100644 index 000000000..1a48969ef --- /dev/null +++ b/content/uk/docs/topics/architecture.md @@ -0,0 +1,54 @@ +--- +title: "Архітектура Helm" +description: "Описує архітектуру Helm на високому рівні." +weight: 8 +--- + +# Архітектура Helm {#helm-architecture} + +Цей документ описує архітектуру Helm на високому рівні. + +## Призначення Helm {#the-purpose-of-helm} + +Helm — це інструмент для керування пакетами Kubernetes, що називаються _чартами_. Helm може: + +- Створювати нові чарти з нуля +- Упаковувати чарт в архіви чартів (tgz) +- Взаємодіяти з репозиторіями чартів, де зберігаються чарти +- Встановлювати та видаляти чарти в наявному кластері Kubernetes +- Керувати циклом випуску чартів, які були встановлені за допомогою Helm + +Для Helm є три важливі концепції: + +1. _Chart_ — це пакет інформації, необхідної для створення екземпляра застосунку Kubernetes. +2. _Config_ містить конфігураційну інформацію, яку можна обʼєднати з упакованим чартом для створення обʼєкта, що підлягає випуску. +3. _Release_ — це запущений екземпляр _чарту_, поєднаний з конкретним _конфігом_. + +## Компоненти {#components} + +Helm є виконуваним файлом, який реалізовано в двох окремих частинах: + +**Клієнт Helm** — це клієнт командного рядка для кінцевих користувачів. Клієнт відповідає за: + +- Розробку локальних чартів +- Керування репозиторіями +- Керування випусками +- Взаємодію з бібліотекою Helm + - Надсилання чартів для встановлення + - Запит на оновлення або видалення наявних випусків + +**Бібліотека Helm** надає логіку для виконання всіх операцій Helm. Вона взаємодіє з API-сервером Kubernetes і забезпечує такі можливості: + +- Обʼєднання чарту і конфігурації для створення випуску +- Встановлення чартів у Kubernetes і надання наступного обʼєкта випуску +- Оновлення та видалення чартів шляхом взаємодії з Kubernetes + +Окрема бібліотека Helm інкапсулює логіку Helm, щоб її можна було використовувати різними клієнтами. + +## Реалізація {#implementation} + +Клієнт та бібліотека Helm написані мовою програмування Go. + +Бібліотека використовує клієнтську бібліотеку Kubernetes для комунікації з Kubernetes.Зараз ця бібліотека використовує REST+JSON. Інформація зберігається у Secrets, розташованих всередині Kubernetes. Вона не потребує власної бази даних. + +Конфігураційні файли, коли це можливо, написані у YAML. diff --git a/content/uk/docs/topics/chart_repository.md b/content/uk/docs/topics/chart_repository.md new file mode 100644 index 000000000..82114a181 --- /dev/null +++ b/content/uk/docs/topics/chart_repository.md @@ -0,0 +1,230 @@ +--- +title: "Репозиторій чартів" +description: "Як створити та працювати з репозиторіями чартів Helm." +weight: 6 +--- + +Цей розділ пояснює, як створювати та працювати з репозиторіями чартів Helm. На високому рівні, репозиторій чартів — це місце, де можуть зберігатися та розповсюджуватися упаковані чарти. + +Розподілений репозиторій спільноти чартів Helm знаходиться на [Artifact Hub](https://artifacthub.io/packages/search?kind=0) та запрошує вас долучитися. Однак Helm також дозволяє вам створювати власні репозиторії чартів. Цей посібник пояснює, як це зробити. + +### Передумови {#prerequisites} + +- Пройдіть [Керівництво з швидкого старту]({{< ref "quickstart.md" >}}) +- Ознайомтеся з документом [Чарти]({{< ref "/docs/topics/charts.md" >}}) + +### Створення репозиторію чартів {#create-a-chart-repository} + +_Репозиторій чартів_ — це HTTP-сервер, який містить файл `index.yaml` і, за бажанням, деякі упаковані чарти. Коли ви готові поділитися своїми чартами, найкращий спосіб зробити це — завантажити їх до репозиторію чартів. + +З версії Helm 2.2.0 підтримується SSL-автентифікація клієнта для репозиторіїв. Інші протоколи автентифікації можуть бути доступні як втулки. + +Оскільки репозиторій чартів може бути будь-яким HTTP-сервером, який може обслуговувати YAML і tar файли та відповідати на GET-запити, у вас є безліч варіантів для хостингу власного репозиторію чартів. Наприклад, ви можете використовувати Google Cloud Storage (GCS), Amazon S3, GitHub Pages або навіть розгорнути власний вебсервер. + +### Структура репозиторію чартів {#the-chart-repository-structure} + +Репозиторій чартів складається з упакованих чартів і спеціального файлу з назвою `index.yaml`, який містить індекс усіх чартів у репозиторії. Зазвичай чарти, описані в `index.yaml`, також розміщуються на тому ж сервері, як і [файли походження]({{< ref "provenance.md" >}}). + +Наприклад, структура репозиторію `https://example.com/charts` може виглядати так: + +```none +charts/ + | + |- index.yaml + | + |- alpine-0.1.2.tgz + | + |- alpine-0.1.2.tgz.prov +``` + +У цьому випадку файл індексу міститиме інформацію про один чарт, Alpine, і надаватиме URL для завантаження `https://example.com/charts/alpine-0.1.2.tgz` для цього чарту. + +Не обовʼязково, щоб пакет чарту розміщувався на тому ж сервері, що й файл `index.yaml`. Однак, це часто є найпростішим варіантом. + +### Файл індексу {#the-index-file} + +Файл індексу — це YAML-файл з назвою `index.yaml`. Він містить деякі метадані про пакети, включаючи вміст файлу `Chart.yaml` чарту. Дійсний репозиторій чартів повинен мати файл індексу. Файл індексу містить інформацію про кожен чарт у репозиторії чартів. Команда `helm repo index` створить файл індексу на основі заданої локальної теки, яка містить упаковані чарти. + +Приклад файлу індексу: + +```yaml +apiVersion: v1 +entries: + alpine: + - created: 2016-10-06T16:23:20.499814565-06:00 + description: Deploy a basic Alpine Linux pod + digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd + home: https://helm.sh/helm + name: alpine + sources: + - https://github.com/helm/helm + urls: + - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz + version: 0.2.0 + - created: 2016-10-06T16:23:20.499543808-06:00 + description: Deploy a basic Alpine Linux pod + digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727 + home: https://helm.sh/helm + name: alpine + sources: + - https://github.com/helm/helm + urls: + - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz + version: 0.1.0 + nginx: + - created: 2016-10-06T16:23:20.499543808-06:00 + description: Create a basic nginx HTTP server + digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff + home: https://helm.sh/helm + name: nginx + sources: + - https://github.com/helm/charts + urls: + - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz + version: 1.1.0 +generated: 2016-10-06T16:23:20.499029981-06:00 +``` + +## Хостинг репозиторіїв чартів {#hosting-chart-repositories} + +У цьому розділі показано кілька способів хостингу репозиторію чартів. + +### Google Cloud Storage (GCS) + +Першим кроком є **створення кошика GCS**. Назвемо його `fantastic-charts`. + +![Створення кошика GCS](https://helm.sh/img/create-a-bucket.png) + +Далі, зробіть свій кошик публічним, **редагувавши дозволи кошику**. + +![Редагування дозволів](https://helm.sh/img/edit-permissions.png) + +Додайте цей пункт, щоб **зробити кошик публічним**: + +![Зробити кошик публічним](https://helm.sh/img/make-bucket-public.png) + +Вітаємо, тепер у вас є порожній кошик GCS, готовий для обслуговування чартів! + +Ви можете завантажити свій репозиторій чартів за допомогою командного рядка Google Cloud Storage або через вебінтерфейс GCS. Доступ до публічного кошика GCS можна отримати через простий HTTPS за цією адресою: `https://bucket-name.storage.googleapis.com/`. + +### Cloudsmith {#cloudsmith} + +Ви також можете налаштувати репозиторії чартів за допомогою Cloudsmith. Дізнайтеся більше про репозиторії чартів з Cloudsmith [тут](https://help.cloudsmith.io/docs/helm-chart-repository). + +### JFrog Artifactory {#jfrog-artifactory} + +Аналогічно, ви можете налаштувати репозиторії чартів за допомогою JFrog Artifactory. Дізнайтеся більше про репозиторії чартів з JFrog Artifactory [тут](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories). + +### Приклад GitHub Pages {#github-pages-example} + +Подібним чином ви можете створити репозиторій чартів за допомогою GitHub Pages. + +GitHub дозволяє обслуговувати статичні вебсторінки двома різними способами: + +- Налаштувавши проєкт на обслуговування вмісту його теки `docs/` +- Налаштувавши проєкт на обслуговування певної гілки + +Ми скористаємося другим підходом, хоча перший також простий. + +Перший крок — **створити гілку gh-pages**. Ви можете зробити це локально: + +```console +$ git checkout -b gh-pages +``` + +Або через веббраузер, використовуючи кнопку **Branch** у вашому репозиторії GitHub: + +![Створення гілки GitHub Pages](https://helm.sh/img/create-a-gh-page-button.png) + +Далі потрібно переконатися, що ваша **гілка gh-pages** налаштована як GitHub Pages. Для цього натисніть у вашому репо кнопку **Settings** і прокрутіть до розділу **GitHub pages** і налаштуйте його, як показано нижче: + +![Налаштування гілки GitHub Pages](https://helm.sh/img/set-a-gh-page.png) + +Стандартно **Source** зазвичай встановлюється на **gh-pages branch**. Якщо це не встановлено, виберіть його. + +Ви можете використовувати **власний домен**, якщо бажаєте. + +І переконайтеся, що **Enforce HTTPS** відмічено, щоб **HTTPS** використовувався під час обслуговування чартів. + +У такому налаштуванні ви можете використовувати основну гілку для зберігання коду чартів, а **гілку gh-pages** як репозиторій чартів, наприклад: `https://USERNAME.github.io/REPONAME`. Демонстраційний репозиторій [TS Charts](https://github.com/technosophos/tscharts) доступний за адресою `https://technosophos.github.io/tscharts/`. + +Якщо ви вирішили використовувати GitHub Pages для хостингу репозиторію чартів, ознайомтеся з [Chart Releaser Action]({{< ref "/docs/howto/chart_releaser_action.md" >}}). Chart Releaser Action — це робочий процес GitHub Action, який перетворює проєкт GitHub у репозиторій чартів Helm, використовуючи CLI-інструмент [helm/chart-releaser](https://github.com/helm/chart-releaser). + +### Звичайні вебсервери {#ordinary-web-servers} + +Щоб налаштувати звичайний вебсервер для обслуговування чартів Helm, вам просто потрібно зробити наступне: + +- Помістіть ваш індекс і чарти в теку, яку сервер може обслуговувати +- Переконайтеся, що файл `index.yaml` доступний без необхідності автентифікації +- Переконайтеся, що файли `yaml` обслуговуються з правильним типом вмісту (`text/yaml` або `text/x-yaml`) + +Наприклад, якщо ви хочете обслуговувати свої чарти з теки `$WEBROOT/charts`, переконайтеся, що у вашому вебкорені є тека `charts/`, і помістіть туди файл індексу та чарти. + +### Сервер репозиторію ChartMuseum {#chartmuseum-repository-server} + +ChartMuseum — це сервер репозиторію чартів Helm з відкритим кодом, написаний на Go (Golang), з підтримкою хмарних сховищ, включаючи [Google Cloud Storage](https://cloud.google.com/storage/), [Amazon S3](https://aws.amazon.com/s3/), [Microsoft Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/), [Alibaba Cloud OSS Storage](https://www.alibabacloud.com/product/oss), [Openstack Object Storage](https://developer.openstack.org/api-ref/object-store/), [Oracle Cloud Infrastructure Object Storage](https://cloud.oracle.com/storage), [Baidu Cloud BOS Storage](https://cloud.baidu.com/product/bos.html), [Tencent Cloud Object Storage](https://intl.cloud.tencent.com/product/cos), [DigitalOcean Spaces](https://www.digitalocean.com/products/spaces/), [Minio](https://min.io/) та [etcd](https://etcd.io/). + +Ви також можете використовувати сервер [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) для хостингу репозиторію чартів з локальної файлової системи. + +### Реєстр пакетів GitLab {#gitlab-package-registry} + +З GitLab ви можете публікувати чарти Helm у реєстрі пакетів вашого проєкту. Дізнайтеся більше про налаштування репозиторію пакетів Helm за допомогою GitLab [тут](https://docs.gitlab.com/ee/user/packages/helm_repository/). + +## Управління репозиторіями чартів {#managing-chart-repositories} + +Тепер, коли у вас є репозиторій чартів, остання частина цього посібника пояснює, як підтримувати чарти в цьому репозиторії. + +### Зберігання чартів у вашому репозиторії чартів {#storing-charts-in-your-chart-repository} + +Тепер, коли у вас є репозиторій чартів, завантажимо чарти та файл індексу до репозиторію. Чарти в репозиторії мають бути запаковані (`helm package chart-name/`) та правильно версійовані (відповідно до рекомендацій [SemVer 2](https://semver.org/)). + +Наступні кроки складають приклад робочого процесу, але ви можете використовувати будь-який зручний вам процес для зберігання та оновлення чартів у вашому репозиторії. + +Як тільки у вас є готовий запакований чарт, створіть нову теку і перемістіть туди ваш запакований чарт. + +```console +$ helm package docs/examples/alpine/ +$ mkdir fantastic-charts +$ mv alpine-0.1.0.tgz fantastic-charts/ +$ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com +``` + +Остання команда бере шлях до щойно створеної локальної теки та URL вашого віддаленого репозиторію чартів і створює файл `index.yaml` у вказаній теці. + +Тепер ви можете завантажити чарт і файл індексу у ваш репозиторій чартів, використовуючи інструмент синхронізації або вручну. Якщо ви використовуєте Google Cloud Storage, ознайомтеся з цим [прикладом робочого процесу]({{< ref "/docs/howto/chart_repository_sync_example.md" >}}), що використовує клієнт gsutil. Для GitHub ви можете просто помістити чарти у відповідну гілку призначення. + +### Додавання нових чартів до наявного репозиторію {#adding-new-charts-to-an-existing-repository} + +Щоразу, коли ви хочете додати новий чарт у ваш репозиторій, потрібно перестворити індекс. Команда `helm repo index` повністю перебудовує файл `index.yaml` з нуля, включаючи лише ті чарти, які вона знаходить локально. + +Однак, ви можете використовувати прапорець `--merge` для поступового додавання нових чартів до наявного файлу `index.yaml` (чудовий варіант під час роботи з віддаленим репозиторієм, як-от GCS). Виконайте команду `helm repo index --help`, щоб дізнатися більше. + +Переконайтеся, що ви завантажили як оновлений файл `index.yaml`, так і чарт. Якщо ви згенерували файл підтвердження цілісності, завантажте і його. + +### Поділитися чартами з іншими {#share-your-charts-with-others} + +Коли ви готові поділитися чартами, просто повідомте комусь URL вашого репозиторію. + +Після цього вони додадуть репозиторій до свого клієнта helm через команду `helm repo add [NAME] [URL]` з будь-яким імʼям, яке вони хочуть використовувати для позначення репозиторію. + +```console +$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com +$ helm repo list +fantastic-charts https://fantastic-charts.storage.googleapis.com +``` + +Якщо чарти захищені за допомогою базової автентифікації HTTP, ви також можете вказати імʼя користувача та пароль тут: + +```console +$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password +$ helm repo list +fantastic-charts https://fantastic-charts.storage.googleapis.com +``` + +**Примітка:** Репозиторій не буде додано, якщо він не містить дійсний файл `index.yaml`. + +**Примітка:** Якщо ваш репозиторій helm, наприклад, використовує самопідписний сертифікат, ви можете використовувати `helm repo add --insecure-skip-tls-verify ...`, щоб пропустити перевірку CA. + +Після цього ваші користувачі зможуть шукати серед ваших чартів. Після того, як ви оновите репозиторій, вони можуть використовувати команду `helm repo update`, щоб отримати найновішу інформацію про чарт. + +_Під капотом команди `helm repo add` і `helm repo update` завантажують файл index.yaml і зберігають його в теці `$XDG_CACHE_HOME/helm/repository/cache/`. Саме тут функція `helm search` знаходить інформацію про чарти._ diff --git a/content/uk/docs/topics/chart_tests.md b/content/uk/docs/topics/chart_tests.md new file mode 100644 index 000000000..14eca54fb --- /dev/null +++ b/content/uk/docs/topics/chart_tests.md @@ -0,0 +1,85 @@ +--- +title: "Тести чартів" +description: "Опис того, як запускати та тестувати ваші чарти." +weight: 3 +--- + +Чарт містить ряд ресурсів та компонентів Kubernetes, які працюють разом. Як автор чарту, ви можете захотіти написати деякі тести, щоб перевірити, чи ваш чарт працює відповідно до очікувань після його встановлення. Ці тести також допомагають споживачеві чарту зрозуміти, що саме повинен робити ваш чарт. + +**Тест** у Helm чарті розміщується в теці `templates/` і є визначенням Job, яке вказує контейнер з певною командою для виконання. Контейнер повинен успішно завершити роботу (exit 0), щоб тест вважався успішним. Визначення Job повинно містити анотацію хука Helm: `helm.sh/hook: test`. + +Зверніть увагу, що до Helm v3, визначення Job повинно було містити одну з цих анотацій хука Helm: `helm.sh/hook: test-success` або `helm.sh/hook: test-failure`. `helm.sh/hook: test-success` все ще приймається як зворотно сумісна альтернатива `helm.sh/hook: test`. + +Приклади тестів: + +- Перевірте, що ваша конфігурація з файлу values.yaml була правильно вбудована. + - Переконайтеся, що ваше імʼя користувача та пароль працюють правильно. + - Переконайтеся, що неправильне імʼя користувача та пароль не працюють. +- Перевірте, що ваші сервіси працюють та правильно здійснюють балансування навантаження. +- тощо. + +Ви можете запустити заздалегідь визначені тести у Helm для релізу за допомогою команди `helm test `. Для споживача чарту це чудовий спосіб перевірити, чи їх реліз чарту (або програми) працює відповідно до очікувань. + +## Приклад тесту {#example-test} + +Команда [helm create](/docs/helm/helm_create) автоматично створює кілька тек і файлів. Щоб спробувати функціональність тестів Helm, спочатку створіть демонстраційний Helm чарт. + +```console +$ helm create demo +``` + +Тепер ви побачите таку структуру у вашому демонстраційному Helm чарті. + +```none +demo/ + Chart.yaml + values.yaml + charts/ + templates/ + templates/tests/test-connection.yaml +``` + +У `demo/templates/tests/test-connection.yaml` ви побачите тест, який ви можете спробувати. Ось визначення Pod для тесту: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: "{{ include "demo.fullname" . }}-test-connection" + labels: + {{- include "demo.labels" . | nindent 4 }} + annotations: + "helm.sh/hook": test +spec: + containers: + - name: wget + image: busybox + command: ['wget'] + args: ['{{ include "demo.fullname" . }}:{{ .Values.service.port }}'] + restartPolicy: Never +``` + +## Кроки для запуску тестового набору на релізі + +По-перше, встановіть чарт у ваш кластер, щоб створити реліз. Можливо, вам доведеться почекати, поки всі podʼи стануть активними; якщо ви запустите тест одразу після цього встановлення, це може показати транзитивну помилку, і вам доведеться повторити тестування. + +```console +$ helm install demo demo --namespace default +$ helm test demo +NAME: demo +LAST DEPLOYED: Mon Feb 14 20:03:16 2022 +NAMESPACE: default +STATUS: deployed +REVISION: 1 +TEST SUITE: demo-test-connection +Last Started: Mon Feb 14 20:35:19 2022 +Last Completed: Mon Feb 14 20:35:23 2022 +Phase: Succeeded +[...] +``` + +## Примітки {#notes} + +- Ви можете визначити стільки тестів, скільки бажаєте, в одному yaml файлі або розподілити їх по кількох yaml файлах у теці `templates/`. +- Ви можете організувати ваші тести у теці `tests/`, наприклад, `/templates/tests/` для більшої ізоляції. +- Тест є [Helm хуком](/docs/charts_hooks/), тому анотації, такі як `helm.sh/hook-weight` і `helm.sh/hook-delete-policy`, можуть використовуватися з ресурсами тестів. diff --git a/content/uk/docs/topics/charts.md b/content/uk/docs/topics/charts.md new file mode 100644 index 000000000..48e610001 --- /dev/null +++ b/content/uk/docs/topics/charts.md @@ -0,0 +1,874 @@ +--- +title: "Чарти" +description: "Пояснює формат чартів та надає основні рекомендації щодо створення чартів з використанням Helm." +weight: 1 +--- + +Helm використовує формат пакування, який називається _чарти_. Чарт — це набір файлів, які описують повʼязаний набір ресурсів Kubernetes. Один чарт може бути використаний для розгортання чогось простого, як, наприклад, pod з memcached, або чогось складного, як повний вебстек з HTTP серверами, базами даних, кешами й так далі. + +Чарти створюються як файли, розташовані в певній структурі тек. Вони можуть бути упаковані у версійні архіви для розгортання. + +Якщо ви хочете завантажити та переглянути файли опублікованого чарту без його встановлення, ви можете зробити це за допомогою команди `helm pull chartrepo/chartname`. + +Цей документ пояснює формат чарту та надає основні рекомендації щодо створення чартів з використанням Helm. + +## Структура файлів чарту {#chart-file-structure} + +Чарт організовано як набір файлів всередині теки. Назва теки відповідає назві чарту (без інформації про версію). Наприклад, чарт, який описує WordPress, буде зберігатися в теці `wordpress/`. + +Всередині цієї теки Helm очікує структуру, яка відповідає наступному: + +```text +wordpress/ + Chart.yaml # YAML файл, що містить інформацію про чарт + LICENSE # НЕОБОВʼЯЗКОВО: Текстовий файл, що містить ліцензію для чарту + README.md # НЕОБОВʼЯЗКОВО: Файл README + values.yaml # Файл стандартної конфігурації для цього чарту + values.schema.json # НЕОБОВʼЯЗКОВО: JSON-схема для накладання структури на файл values.yaml + charts/ # Тека, що містить чарти, від яких залежить цей чарт. + crds/ # Custom Resource Definitions + templates/ # Тека шаблонів, які в поєднанні з values + # генерують валідні файли маніфестів Kubernetes. + templates/NOTES.txt # НЕОБОВʼЯЗКОВО: Текстовий файл з короткими інструкціями +``` + +Helm резервує використання тек `charts/`, `crds/` і `templates/`, а також перелічених назв файлів. Інші файли буде залишено без змін. + +## Файл Chart.yaml {#the-chart-yaml-file} + +Файл `Chart.yaml` є обовʼязковим для чарту. Він містить наступні поля: + +```yaml +apiVersion: Версія API чарту (обовʼязкове) +name: Назва чарту (обовʼязкове) +version: Версія SemVer 2 (обовʼязкове) +kubeVersion: Діапазон сумісних версій Kubernetes (необовʼязкове) +description: Короткий опис цього проекту (необовʼязкове) +type: Тип чарту (необовʼязкове) +keywords: + - Список ключових слів про цей проект (необовʼязкове) +home: URL головної сторінки проєкту (необовʼязкове) +sources: + - Список URL-адрес з вихідним кодом проєкту (необовʼязкове) +dependencies: # Список залежностей чарту (необовʼязкове) + - name: Назва чарту (nginx) + version: Версія чарту ("1.2.3") + repository: (необовʼязкове) URL репозиторію ("https://example.com/charts") або псевдонім ("@repo-name") + condition: (необовʼязкове) YAML шлях, який відповідає за логічне значення, використовується для увімкнення/вимкнення чартів (наприклад, subchart1.enabled ) + tags: # (необовʼязкове) + - Теґи можуть бути використані для групування чартів для одночасного увімкнення/вимкнення + import-values: # (необовʼязкове) + - ImportValues містить зіставлення вихідних значень з ключем батьківського елемента для імпорту. Кожен елемент може бути рядком або парою дочірніх/батьківських субсписків. + alias: (необовʼязкове) Псевдонім для чарту. Корисно, коли вам потрібно додати той самий чарт кілька разів +maintainers: # (необовʼязкове) + - name: Імʼя мейнтейнера (обовʼязкове для кожного мейнтейнера) + email: Електронна пошта мейнтейнера (необовʼязкове для кожного мейнтейнера) + url: URL для мейнтейнера (необовʼязкове для кожного мейнтейнера) +icon: URL до SVG або PNG зображення для використання як іконки (необовʼязкове). +appVersion: Версія програми, яку містить цей чарт (необовʼязкове). Не обовʼязково має бути SemVer. Рекомендується використовувати лапки. +deprecated: Чи цей чарт застарілий (необовʼязкове, булеве значення) +annotations: + example: Список анотацій, згрупованих за іменами (необовʼязкове). +``` + +Починаючи з [v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2), додаткові поля не дозволені. Рекомендований підхід — додавати власні метадані в `annotations`. + +### Чарти та версіювання {#charts-and-versioning} + +Кожен чарт повинен мати номер версії. Версія повинна відповідати стандарту [SemVer 2](https://semver.org/spec/v2.0.0.html). На відміну від Helm Classic, Helm версії 2 та новіші використовують номери версій як маркери випуску. Пакети в репозиторіях ідентифікуються за назвою та версією. + +Наприклад, чарт `nginx`, у якого в полі версії вказано `version: 1.2.3`, буде мати таку назву: + +```text +nginx-1.2.3.tgz +``` + +Підтримуються також складніші імена SemVer 2, такі як `version: 1.2.3-alpha.1+ef365`. Але імена, які не відповідають стандарту SemVer, системою не допускаються. + +**Примітка:** Якщо Helm Classic та Deployment Manager були тісно повʼязані з GitHub у контексті чартів, то Helm версії 2 та новіші не залежать від GitHub або навіть Git. Відповідно, він не використовує Git SHAs для версіювання. + +Поле `version` у файлі `Chart.yaml` використовується багатьма інструментами Helm, включаючи CLI. При генерації пакета, команда `helm package` використовує версію, яку знаходить у `Chart.yaml`, як частину назви пакета. Система припускає, що номер версії в назві пакета чарту збігається з номером версії у `Chart.yaml`. Невідповідність цього припущення викличе помилку. + +### Поле `apiVersion` {#the-apiversion-field} + +Поле `apiVersion` має бути `v2` для чартів Helm, які вимагають Helm версії 3 або новішої. Чарти, які підтримують попередні версії Helm, мають `apiVersion`, встановлену на `v1`, і все ще можуть бути встановлені за допомогою Helm 3. + +Зміни з `v1` на `v2`: + +- Поле `dependencies`, що визначає залежності чарту, яке в чартах `v1` знаходилося в окремому файлі `requirements.yaml` (див. [Залежності чарту](#chart-dependencies)). +- Поле `type`, що дозволяє відрізняти чарт-застосунок від бібліотеки (див. [Типи чартів](#chart-types)). + +### Поле `appVersion` {#the-appversion-field} + +Зверніть увагу, що поле `appVersion` не повʼязане з полем `version`. Це спосіб вказати версію застосунку. Наприклад, чарт `drupal` може мати `appVersion: "8.2.1"`, що вказує на версію Drupal, включену в чарт (стандартно), і це буде версія `8.2.1`. Це поле є інформаційним і не впливає на розрахунки версії чарту. Наполегливо рекомендується використовувати лапки навколо значення версії. Це змушує YAML-парсер сприймати номер версії як рядок. Якщо залишити його без лапок, це може призвести до проблем із парсингом у деяких випадках. Наприклад, YAML інтерпретує `1.0` як число з плаваючою точкою, а git-коміт SHA, як `1234e10`, як наукову нотацію. + +З версії Helm v3.5.0 команда `helm create` автоматично обгортає поле `appVersion` у лапки. + +### Поле `kubeVersion` {#the-kubeversion-field} + +Необовʼязкове поле `kubeVersion` може визначати обмеження версій semver для підтримуваної версії Kubernetes. Helm перевірить обмеження версії під час встановлення чарту та відхилить дію, якщо кластер працює на непідтримуваній версії Kubernetes. + +Обмеження версій можуть складатися з розділених пробілами AND-порівнянь, таких як: + +```yaml +>= 1.13.0 < 1.15.0 +``` + +які можуть бути обʼєднані за допомогою оператора OR `||`, як у наступному прикладі: + +```yaml +>= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0 +``` + +У цьому прикладі версія `1.14.0` виключена, що може мати сенс, якщо відомо про помилку в певних версіях, яка не дозволяє чарту працювати правильно. + +Окрім обмежень версій з використанням операторів `=` `!=` `>` `<` `>=` `<=`, підтримуються такі скорочені нотації: + +- діапазони для закритих інтервалів, де `1.1 - 2.3.4` еквівалентно `>= 1.1 <= 2.3.4`. +- підстановки `x`, `X` і `*`, де `1.2.x` еквівалентно `>= 1.2.0 < 1.3.0`. +- діапазони з тильдою (допускаються зміни патч-версії), де `~1.2.3` еквівалентно `>= 1.2.3 < 1.3.0`. +- діапазони з `^` (допускаються зміни мінорної версії), де `^1.2.3` еквівалентно `>= 1.2.3 < 2.0.0`. + +Для детального пояснення підтримуваних обмежень версій semver див. [Masterminds/semver](https://github.com/Masterminds/semver). + +### Застарівання чартів {#deprecating-charts} + +Під час керування чартами в репозиторії чартів іноді виникає необхідність зняти чарт з підтримки, визнати його застарілим (deprecated). Для цього можна використовувати необовʼязкове поле `deprecated` у файлі `Chart.yaml`. Якщо **остання** версія чарту в репозиторії позначена як знята з підтримки, тоді весь чарт вважається застарілим. Назву чарту можна пізніше використовувати повторно, опублікувавши нову версію, яка не позначена як знята з підтримки. Процедура зняття чартів з підтримки включає такі кроки: + +1. Оновіть файл `Chart.yaml` чарту, позначивши його як знятий з підтримки, і збільште номер версії. +2. Опублікуйте нову версію чарту в репозиторії чартів. +3. Видаліть чарт із репозиторію коду (наприклад, з git). + +### Типи чартів {#chart-types} + +Поле `type` визначає тип чарту. Є два типи: `application` та `library`. Стандартний тип — `application`, і це стандартний чарт, з яким можна повністю працювати. [Чарт-бібліотека]({{< ref "/docs/topics/library_charts.md" >}}) надає утиліти або функції для розробників чарту. Чарт-бібліотека відрізняється від чарту-застосунку тим, що він не встановлюється і зазвичай не містить жодних обʼєктів ресурсу. + +**Примітка:** Чарт-застосунок можна використовувати як чарт-бібліотеку. Це активується шляхом встановлення типу `library`. Чарт тоді буде оброблятися як чарт-бібліотека, де всі утиліти та функції можуть бути використані. Усі обʼєкти ресурсів чарту не будуть оброблені. + +## Ліцензії, README та ПРИМІТКИ до чарту {#chart-license-readme-and-notes} + +Чарти також можуть містити файли, які описують встановлення, конфігурацію, використання та ліцензію чарту. + +Файл LICENSE є простим текстовим файлом, який містить [ліцензію](https://en.wikipedia.org/wiki/Software_license) для чарту. Чарт може містити ліцензію, оскільки він може містити програмну логіку в шаблонах і, отже, не буде лише конфігураційним. Також можуть бути окремі ліцензії для застосунку, який встановлюється чартом, якщо це необхідно. + +README для чарту повинен бути відформатований у Markdown (README.md) і, як правило, містити: + +- Опис застосунку або служби, яку надає чарт +- Будь-які передумови або вимоги для запуску чарту +- Опис опцій у `values.yaml` та стандартні значення +- Будь-яку іншу інформацію, яка може бути релевантною для встановлення або конфігурації чарту + +Коли хаби та інші інтерфейси користувача відображають деталі про чарт, ці дані витягуються з вмісту файлу `README.md`. + +Чарт також може містити короткий текстовий файл `templates/NOTES.txt`, який буде надрукований після встановлення і під час перегляду статусу релізу. Цей файл обробляється як [шаблон](#templates-and-values) і може використовуватися для відображення заміток щодо використання, наступних кроків або будь-якої іншої інформації, яка стосується релізу чарту. Наприклад, можна надати інструкції щодо підключення до бази даних або доступу до вебінтерфейсу. Оскільки цей файл друкується в STDOUT під час виконання команд `helm install` або `helm status`, рекомендується зберігати вміст коротким та вказувати на README для детальнішої інформації. + +## Залежності чартів {#chart-dependencies} + +У Helm один чарт може залежати від будь-якої кількості інших чартів. Ці залежності можна динамічно звʼязувати за допомогою поля `dependencies` у файлі `Chart.yaml` або вручну керувати ними в теці `charts/`. + +### Керування залежностями за допомогою поля `dependencies` {#managing-dependencies-with-the-dependencies-field} + +Чарти, від яких залежить поточний чарт, визначаються як список у полі `dependencies`. + +```yaml +dependencies: + - name: apache + version: 1.2.3 + repository: https://example.com/charts + - name: mysql + version: 3.2.1 + repository: https://another.example.com/charts +``` + +- Поле `name` містить імʼя потрібного чарту. +- Поле `version` містить версію потрібного чарту. +- Поле `repository` містить повну URL-адресу репозиторію чартів. Зверніть увагу, що ви також повинні використовувати команду `helm repo add`, щоб додати цей репозиторій локально. +- Ви можете використовувати імʼя репозиторію замість URL-адреси. + +```console +$ helm repo add fantastic-charts https://charts.helm.sh/incubator +``` + +```yaml +dependencies: + - name: awesomeness + version: 1.0.0 + repository: "@fantastic-charts" +``` + +Після того як ви визначили залежності, ви можете виконати команду `helm dependency update`, і вона використає ваш файл залежностей для завантаження всіх вказаних чартів у вашу теку `charts/`. + +```console +$ helm dep up foochart +Hang tight while we grab the latest from your chart repositories... +...Successfully got an update from the "local" chart repository +...Successfully got an update from the "stable" chart repository +...Successfully got an update from the "example" chart repository +...Successfully got an update from the "another" chart repository +Update Complete. Happy Helming! +Saving 2 charts +Downloading apache from repo https://example.com/charts +Downloading mysql from repo https://another.example.com/charts +``` + +Коли `helm dependency update` отримує чарти, вона зберігає їх як архіви чартів у теці `charts/`. Тому в наведеному вище прикладі очікується, що в теці charts будуть такі файли: + +```text +charts/ + apache-1.2.3.tgz + mysql-3.2.1.tgz +``` + +#### Поле `alias` у залежностях {#alias-field-in-dependencies} + +Крім інших полів, кожен запис у вимогах може містити необовʼязкове поле `alias`. + +Додавання псевдоніма для чарту-залежності дозволяє додати чарт у залежності, використовуючи псевдонім як назву нової залежності. + +Псевдонім може бути корисним, коли вам потрібно отримати доступ до чарту під іншим імʼям (іменами). + +```yaml +# parentchart/Chart.yaml + +dependencies: + - name: subchart + repository: http://localhost:10191 + version: 0.1.0 + alias: new-subchart-1 + - name: subchart + repository: http://localhost:10191 + version: 0.1.0 + alias: new-subchart-2 + - name: subchart + repository: http://localhost:10191 + version: 0.1.0 +``` + +У наведеному вище прикладі для `parentchart` буде три залежності: + +```text +subchart +new-subchart-1 +new-subchart-2 +``` + +Ручний спосіб досягнення цього — копіювання/вставка одного й того ж чарту в теку `charts/` кілька разів під різними іменами. + +#### Поля `tags` та `condition` у залежностях {#tags-and-condition-fields-in-dependencies} + +Крім інших полів, кожен запис у вимогах може містити необовʼязкові поля `tags` та `condition`. + +Всі чарти будуть стандартно завантажені. Якщо присутні поля `tags` або `condition`, вони будуть оцінені та використані для керування завантаженням чартів, до яких вони застосовуються. + +**Condition** — поле condition містить один або кілька шляхів YAML (розділених комами). Якщо цей шлях існує у значеннях основного чарту та оцінюється як булеве значення, чарт буде включений або виключений залежно від цього булевого значення. Оцінюється лише перший дійсний шлях у списку, і якщо шляхи не існують, то condition не має жодного ефекту. + +**Tags** — поле tags є списком міток YAML, повʼязаних із цим чартом. У значеннях основного чарту всі чарти з мітками можуть бути включені або виключені шляхом вказання мітки та булевого значення. + +```yaml +# parentchart/Chart.yaml + +dependencies: + - name: subchart1 + repository: http://localhost:10191 + version: 0.1.0 + condition: subchart1.enabled,global.subchart1.enabled + tags: + - front-end + - subchart1 + - name: subchart2 + repository: http://localhost:10191 + version: 0.1.0 + condition: subchart2.enabled,global.subchart2.enabled + tags: + - back-end + - subchart2 +``` + +```yaml +# parentchart/values.yaml + +subchart1: + enabled: true +tags: + front-end: false + back-end: true +``` + +У наведеному вище прикладі всі чарти з міткою `front-end` будуть вимкнені, але оскільки шлях `subchart1.enabled` у значеннях основного чарту має значення `true`, умова переважає мітку `front-end`, і `subchart1` буде включений. + +Оскільки `subchart2` має мітку `back-end`, і ця мітка має значення `true`, `subchart2` буде включений. Також зверніть увагу, що хоча `subchart2` має зазначену умову, у значеннях основного чарту немає відповідного шляху та значення, тому ця умова не має ефекту. + +##### Використання CLI з Tags та Conditions {#using-the-cli-with-tags-and-conditions} + +Параметр `--set` можна використовувати як зазвичай для зміни значень міток та умов. + +```console +helm install --set tags.front-end=true --set subchart2.enabled=false +``` + +##### Опрацювання Tags та Conditions {#tags-and-conditions-resolution} + +- **Умови (коли вони встановлені в значеннях) завжди переважають мітки.** Перемагає перший існуючий шлях умови, а наступні для цього чарту ігноруються. +- Мітки оцінюються так: "якщо будь-яка з міток чарту має значення true, тоді увімкніть чарт". +- Значення міток та умов повинні бути встановлені у значеннях основного чарту. +- Ключ `tags:` у значеннях має бути ключем верхнього рівня. Глобальні та вкладені таблиці `tags:` наразі не підтримуються. + +#### Імпорт значень дочірніх чартів через залежності {#importing-values-from-child-charts-via-dependencies} + +У деяких випадках корисно, щоб значення дочірнього чарту передавалися до батьківського чарту та використовувалися як стандартні загальні значення. Додаткова перевага використання формату `exports` полягає в тому, що це дозволяє майбутнім інструментам інспектувати значення, які може налаштувати користувач. + +Ключі, що містять значення для імпорту, можуть бути вказані у полі `dependencies` батьківського чарту в полі `import-values`, використовуючи список YAML. Кожен елемент у списку — це ключ, який імпортується з поля `exports` дочірнього чарту. + +Для імпорту значень, які не містяться в ключі `exports`, використовуйте [формат child-parent](#using-the-child-parent-format). Приклади обох форматів описані нижче. + +##### Використання формату `exports` {#using-the-exports-format} + +Якщо файл `values.yaml` дочірнього чарту містить поле `exports` на рівні кореня, його вміст може бути імпортований безпосередньо у значення батьківського чарту, через вказання ключів для імпорту, як у прикладі нижче: + +```yaml +# файл Chart.yaml батьківського чарту + +dependencies: + - name: subchart + repository: http://localhost:10191 + version: 0.1.0 + import-values: + - data +``` + +```yaml +# файл values.yaml дочірнього чарту + +exports: + data: + myint: 99 +``` + +Оскільки ми вказуємо ключ `data` у нашому списку імпорту, Helm шукає цей ключ у полі `exports` дочірнього чарту та імпортує його вміст. + +Фінальні значення батьківського чарту міститимуть наше експортоване поле: + +```yaml +# значення батьківського чарту + +myint: 99 +``` + +Зверніть увагу, що ключ `data` не міститься у фінальних значеннях батьківського чарту. Якщо вам потрібно вказати ключ батьківського чарту, використовуйте формат "child-parent". + +##### Використання формату `child-parent` {#using-the-child-parent-format} + +Щоб отримати доступ до значень, які не містяться у ключі `exports` значень дочірнього чарту, вам потрібно вказати шлях до джерела значень для імпорту (`child`) та шлях до місця призначення у значеннях батьківського чарту (`parent`). + +У прикладі нижче `import-values` інструктує Helm взяти будь-які значення, знайдені в шляху `child:`, та скопіювати їх у значення батьківського чарту в шлях, вказаний у `parent:`. + +```yaml +# файл Chart.yaml батьківського чарту + +dependencies: + - name: subchart1 + repository: http://localhost:10191 + version: 0.1.0 + ... + import-values: + - child: default.data + parent: myimports +``` + +У наведеному вище прикладі значення, знайдені у шляху `default.data` у значеннях subchart1, будуть імпортовані до ключа `myimports` у значеннях батьківського чарту, як показано нижче: + +```yaml +# файл values.yaml батьківського чарту + +myimports: + myint: 0 + mybool: false + mystring: "helm rocks!" +``` + +```yaml +# файл values.yaml subchart1 + +default: + data: + myint: 999 + mybool: true +``` + +Фінальні значення батьківського чарту будуть такими: + +```yaml +# фінальні значення батьківського чарту + +myimports: + myint: 999 + mybool: true + mystring: "helm rocks!" +``` + +Фінальні значення батьківського чарту тепер містять поля `myint` та `mybool`, імпортовані з subchart1. + +### Керування залежностями вручну через теку `charts/` {#managing-dependencies-manually-via-the-charts-directory} + +Якщо потрібен більший контроль над залежностями, їх можна визначити явно, скопіювавши залежні чарти в теку `charts/`. + +Залежність повинна бути розпакованою текою чарту, але її імʼя не може починатися з `_` або `.`. Такі файли ігноруються завантажувачем чартів. + +Наприклад, якщо чарт WordPress залежить від чарту Apache, то чарт Apache (відповідної версії) розміщується в теці `charts/` чарту WordPress: + +```yaml +wordpress/ + Chart.yaml + # ... + charts/ + apache/ + Chart.yaml + # ... + mysql/ + Chart.yaml + # ... +``` + +Наведений вище приклад показує, як чарт WordPress виражає свою залежність від Apache та MySQL, включаючи ці чарти всередині своєї текиу `charts/`. + +**ПОРАДА:** _Щоб завантажити залежність у вашу теку `charts/`, використовуйте команду `helm pull`._ + +### Операційні аспекти використання залежностей {#operational-aspects-of-using-dependencies} + +Попередні розділи пояснюють, як визначати залежності чартів, але як це впливає на встановлення чарту за допомогою `helm install` і `helm upgrade`? + +Припустимо, що чарт з назвою "A" створює такі обʼєкти Kubernetes: + +- namespace "A-Namespace" +- statefulset "A-StatefulSet" +- service "A-Service" + +Крім того, A залежить від чарту B, який створює обʼєкти: + +- namespace "B-Namespace" +- replicaset "B-ReplicaSet" +- service "B-Service" + +Після встановлення/оновлення чарту A створюється або змінюється єдиний реліз Helm. Цей реліз створить або оновить усі вищевказані обʼєкти Kubernetes у такому порядку: + +- A-Namespace +- B-Namespace +- A-Service +- B-Service +- B-ReplicaSet +- A-StatefulSet + +Це відбувається тому, що під час встановлення/оновлення чартів Helm агрегує обʼєкти Kubernetes з чарту та всіх його залежностей в єдиний набір, який потім сортується за типом, а потім за іменем, і створюється або оновлюється в такому порядку. + +Таким чином, створюється єдиний реліз, який містить усі обʼєкти для чарту та його залежностей. + +Порядок встановлення типів Kubernetes визначається переліком InstallOrder у файлі kind_sorter.go (див. [вихідний файл Helm](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go)). + +### Шаблони та Значення {#templates-and-values} + +Шаблони Helm Chart написані на [Go template](https://golang.org/pkg/text/template/), з додатковими функціями з бібліотеки [Sprig](https://github.com/Masterminds/sprig) та кількома іншими [спеціалізованими функціями]({{< ref "/docs/howto/charts_tips_and_tricks.md" >}}). + +Всі файли шаблонів зберігаються у теці `templates/` чарту. Коли Helm обробляє чарти, він пропускає кожен файл у цій теці через механізм шаблонів. + +Значення для шаблонів надаються двома способами: + +- Розробники чартів можуть надати файл з назвою `values.yaml` всередині чарту. Цей файл може містити стандартні значення. +- Користувачі чартів можуть надати YAML файл, який містить значення. Це можна зробити за допомогою команди `helm install`. + +Коли користувач надає власні значення, ці значення перезаписують значення у файлі `values.yaml` чарту. + +### Файли шаблонів {#template-files} + +Файли шаблонів дотримуються стандартних конвенцій написання Go шаблонів (див. [документацію пакету text/template Go](https://golang.org/pkg/text/template/) для деталей). Приклад файлу шаблону може виглядати так: + +```yaml +apiVersion: v1 +kind: ReplicationController +metadata: + name: deis-database + namespace: deis + labels: + app.kubernetes.io/managed-by: deis +spec: + replicas: 1 + selector: + app.kubernetes.io/name: deis-database + template: + metadata: + labels: + app.kubernetes.io/name: deis-database + spec: + serviceAccount: deis-database + containers: + - name: deis-database + image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} + imagePullPolicy: {{ .Values.pullPolicy }} + ports: + - containerPort: 5432 + env: + - name: DATABASE_STORAGE + value: {{ default "minio" .Values.storage }} +``` + +Вищенаведений приклад, заснований на [https://github.com/deis/charts](https://github.com/deis/charts), є шаблоном для контролера реплікацій Kubernetes. Він може використовувати наступні чотири значення шаблону (зазвичай визначені у файлі `values.yaml`): + +- `imageRegistry`: Джерело реєстру для Docker образу. +- `dockerTag`: Теґ для образу Docker. +- `pullPolicy`: Політика отримання образу Docker в Kubernetes. +- `storage`: Сховище, стандартне значення для якого є `"minio"` + +Всі ці значення визначені автором шаблону. Helm не вимагає або не диктує параметри. + +Щоб побачити багато робочих чартів, перегляньте CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0). + +### Попередньо визначені значення {#predefined-values} + +Значення, які постачаються через файл `values.yaml` (або за допомогою прапорця `--set`), доступні з обʼєкта `.Values` у шаблоні. Але є й інші попередньо визначені дані, які можна використовувати у ваших шаблонах. + +Наступні значення є попередньо визначеними, доступні кожному шаблону і не можуть бути перевизначені. Як і всі значення, імена є _чутливими до регістру_: + +- `Release.Name`: Назва релізу (не чарту) +- `Release.Namespace`: Простір імен, в який був розгорнутий чарт. +- `Release.Service`: Сервіс, який здійснив реліз. +- `Release.IsUpgrade`: Це значення буде `true`, якщо поточна операція є оновленням або відкатом. +- `Release.IsInstall`: Це значення буде `true`, якщо поточна операція є встановленням. +- `Chart`: Зміст `Chart.yaml`. Таким чином, версію чарту можна отримати як `Chart.Version`, а авторів — з `Chart.Maintainers`. +- `Files`: Обʼєкт, схожий на map, який містить всі неспеціальні файли в чарті. Це не дає вам доступ до шаблонів, але надає доступ до додаткових файлів, які присутні (якщо вони не виключені за допомогою `.helmignore`). До файлів можна отримати доступ, використовуючи `{{ index .Files "file.name" }}` або функцію `{{.Files.Get name }}`. Також можна отримати вміст файлу як `[]byte`, використовуючи `{{ .Files.GetBytes }}` +- `Capabilities`: Обʼєкт, схожий на map, який містить інформацію про версії Kubernetes (`{{ .Capabilities.KubeVersion }}`) та підтримувані версії API Kubernetes (`{{ .Capabilities.APIVersions.Has "batch/v1" }}`) + +**ПРИМІТКА:** Будь-які невідомі поля `Chart.yaml` будуть відкинуті. Вони не будуть доступні всередині обʼєкта `Chart`. Таким чином, `Chart.yaml` не можна використовувати для передачі довільно структурованих даних у шаблон. Проте для цього можна використовувати файл значень. + +### Файли значень {#values-files} + +Беручи до уваги шаблон у попередньому розділі, файл `values.yaml`, який постачає необхідні значення, виглядатиме так: + +```yaml +imageRegistry: "quay.io/deis" +dockerTag: "latest" +pullPolicy: "Always" +storage: "s3" +``` + +Файл значень має формат YAML. Чарт може містити файл стандартних значень `values.yaml`. Команда Helm install дозволяє користувачеві перевизначити значення, надавши додаткові YAML значення: + +```console +$ helm install --generate-name --values=myvals.yaml wordpress +``` + +Коли значення передаються таким чином, вони зливаються з файлом стандартних значень. Наприклад, розглянемо файл `myvals.yaml`, який виглядає так: + +```yaml +storage: "gcs" +``` + +При злитті з `values.yaml` у чарті, результат буде: + +```yaml +imageRegistry: "quay.io/deis" +dockerTag: "latest" +pullPolicy: "Always" +storage: "gcs" +``` + +Зверніть увагу, що тільки останнє поле було перевизначене. + +**ПРИМІТКА:** Файл стандартних значень, що включений всередині чарту, _повинен_ називатися `values.yaml`. Але файли, вказані в командному рядку, можуть мати будь-яке імʼя. + +**ПРИМІТКА:** Якщо прапорець `--set` використовується з `helm install` або `helm upgrade`, ці значення просто перетворюються в YAML на клієнтському боці. + +**ПРИМІТКА:** Якщо будь-які необхідні записи у файлі значень існують, їх можна оголосити як обовʼязкові в шаблоні чарту, використовуючи функцію [ʼrequiredʼ]({{< ref "/docs/howto/charts_tips_and_tricks.md" >}}). + +Будь-які з цих значень доступні всередині шаблонів, використовуючи обʼєкт `.Values`: + +```yaml +apiVersion: v1 +kind: ReplicationController +metadata: + name: deis-database + namespace: deis + labels: + app.kubernetes.io/managed-by: deis +spec: + replicas: 1 + selector: + app.kubernetes.io/name: deis-database + template: + metadata: + labels: + app.kubernetes.io/name: deis-database + spec: + serviceAccount: deis-database + containers: + - name: deis-database + image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} + imagePullPolicy: {{ .Values.pullPolicy }} + ports: + - containerPort: 5432 + env: + - name: DATABASE_STORAGE + value: {{ default "minio" .Values.storage }} +``` + +### Область видимості, залежності та значення {#scope-dependencies-and-values} + +Файли значень можуть оголошувати значення як для верхнього рівня чарту, так і для будь-яких чартів, які включені у теку `charts/` цього чарту. Інакше кажучи, файл значень може надавати значення чарту та його залежностям. Наприклад, чарт WordPress, що демонструється вище, має як `mysql`, так і `apache` як залежності. Файл значень може надавати значення всім цим компонентам: + +```yaml +title: "My WordPress Site" # Надсилається до шаблону WordPress + +mysql: + max_connections: 100 # Надсилається до MySQL + password: "secret" + +apache: + port: 8080 # Передається Apache +``` + +Чарти вищого рівня мають доступ до всіх змінних, визначених нижче. Отже, чарт WordPress може отримати пароль MySQL як `.Values.mysql.password`. Але чарт нижчого рівня не може отримати доступ до елементів в батьківських чартах, тому MySQL не зможе отримати доступ до властивості `title`. Так само він не може отримати доступ до `apache.port`. + +Значення обмежені просторами імен, але префікси просторів імен обрізаються. Тобто для чарту WordPress, він може отримати доступ до поля пароля MySQL як `.Values.mysql.password`. Але для чарту MySQL область значень зменшена і префікс простору видалено, тому він буде бачити поле пароля просто як `.Values.password`. + +#### Глобальні значення {#global-values} + +З версії 2.0.0-Alpha.2, Helm підтримує спеціальне "глобальне" значення. Розгляньте цю змінену версію попереднього прикладу: + +```yaml +title: "My WordPress Site" # Надсилається до шаблону WordPress + +global: + app: MyWordPress + +mysql: + max_connections: 100 # Надсилається до MySQL + password: "secret" + +apache: + port: 8080 # Передається Apache +``` + +Вищенаведене додає розділ `global` зі значенням `app: MyWordPress`. Це значення доступне _всім_ чартам як `.Values.global.app`. + +Наприклад, шаблони `mysql` можуть отримати доступ до `app` як `{{ .Values.global.app }}`, так само і чарт `apache`. Фактично, файл значень вище перегенерується таким чином: + +```yaml +title: "My WordPress Site" # Надсилається до шаблону WordPress + +global: + app: MyWordPress + +mysql: + global: + app: MyWordPress + max_connections: 100 # Надсилається до MySQL + password: "secret" + +apache: + global: + app: MyWordPress + port: 8080 # Передається Apache +``` + +Це забезпечує спосіб поділитися однією змінною верхнього рівня з усіма субчартами, що корисно для таких речей, як встановлення властивостей `metadata`, наприклад, міток. + +Якщо субчарт оголошує глобальну змінну, ця глобальна змінна буде передана _далі вниз_ (в субчарти субчартів), але не _вгору_ до батьківського чарту. Немає способу, щоб субдчарт впливав на значення батьківського чарту. + +Також, глобальні змінні батьківських чартів мають перевагу над глобальними змінними з субчартів. + +### Файли схем {#schema-files} + +Іноді розробник чарту може захотіти визначити структуру для своїх значень. Це можна зробити, визначивши схему у файлі `values.schema.json`. Схема представляється як [JSON Schema](https://json-schema.org/). Вона може виглядати приблизно так: + +```json +{ + "$schema": "https://json-schema.org/draft-07/schema#", + "properties": { + "image": { + "description": "Container Image", + "properties": { + "repo": { + "type": "string" + }, + "tag": { + "type": "string" + } + }, + "type": "object" + }, + "name": { + "description": "Service name", + "type": "string" + }, + "port": { + "description": "Port", + "minimum": 0, + "type": "integer" + }, + "protocol": { + "type": "string" + } + }, + "required": [ + "protocol", + "port" + ], + "title": "Values", + "type": "object" +} +``` + +Ця схема буде застосовуватися до значень для їх перевірки. Перевірка відбувається при виконанні будь-якої з наступних команд: + +- `helm install` +- `helm upgrade` +- `helm lint` +- `helm template` + +Приклад файлу `values.yaml`, який відповідає вимогам цієї схеми, може виглядати так: + +```yaml +name: frontend +protocol: https +port: 443 +``` + +Зверніть увагу, що схема застосовується до фінального обʼєкта `.Values`, а не тільки до файлу `values.yaml`. Це означає, що наступний `yaml` файл є дійсним, за умови що чарт встановлюється з відповідним параметром `--set`, як показано нижче: + +```yaml +name: frontend +protocol: https +``` + +```console +helm install --set port=443 +``` + +Крім того, фінальний обʼєкт `.Values` перевіряється на відповідність _усім_ схемам субчартів. Це означає, що обмеження на субчарт не можуть бути обійдені батьківським чартом. Це також працює в зворотному напрямку — якщо субчарт має вимогу, яка не виконується у файлі `values.yaml` субчарту, батьківський чарт _повинен_ задовольняти ці вимоги, щоб бути дійсним. + +### Посилання {#references} + +При написанні шаблонів, файлів значень і схем є кілька стандартних посилань, які можуть бути корисними: + +- [Go шаблони](https://godoc.org/text/template) +- [Додаткові функції шаблонів](https://godoc.org/github.com/Masterminds/sprig) +- [Формат YAML](https://yaml.org/spec/) +- [JSON Schema](https://json-schema.org/) + +## Custom Resource Definitions (CRD) {#custom-resource-definitions-crd} + +Kubernetes надає механізм для оголошення нових типів обʼєктів Kubernetes. Використовуючи CustomResourceDefinitions (CRD), розробники Kubernetes можуть оголошувати власні типи ресурсів. + +У Helm 3, CRD розглядаються як особливий вид обʼєктів. Вони встановлюються перед рештою чарту і мають певні обмеження. + +Файли CRD YAML повинні бути поміщені в теку `crds/` всередині чарту. Можна помістити кілька CRD (розділених маркерами початку та кінця YAML) в один файл. Helm спробує завантажити _всі_ файли в теці CRD в Kubernetes. + +Файли CRD _не можуть бути шаблонізовані_. Вони повинні бути звичайними YAML документами. + +Коли Helm встановлює новий чарт, він завантажує CRD, призупиняється, поки CRD не будуть доступні через API сервер, а потім запускає механізм шаблонів, рендерить решту чарту та завантажує її в Kubernetes. Завдяки цьому CRD інформація доступна в обʼєкті `.Capabilities` в шаблонах Helm, і шаблони Helm можуть створювати нові екземпляри обʼєктів, які були оголошені в CRD. + +Наприклад, якщо у вашому чарті є CRD для `CronTab` в теці `crds/`, ви можете створити екземпляри типу `CronTab` в теці `templates/`: + +```text +crontabs/ + Chart.yaml + crds/ + crontab.yaml + templates/ + mycrontab.yaml +``` + +Файл `crontab.yaml` повинен містити CRD без директив шаблона: + +```yaml +kind: CustomResourceDefinition +metadata: + name: crontabs.stable.example.com +spec: + group: stable.example.com + versions: + - name: v1 + served: true + storage: true + scope: Namespaced + names: + plural: crontabs + singular: crontab + kind: CronTab +``` + +Тоді шаблон `mycrontab.yaml` може створити новий `CronTab` (використовуючи шаблони як звичайно): + +```yaml +apiVersion: stable.example.com/v1 +kind: CronTab +metadata: + name: {{ .Values.name }} +spec: + # ... +``` + +Helm забезпечить, що тип обʼєкта `CronTab` був встановлений і доступний з API сервера Kubernetes, перш ніж продовжити встановлення обʼєктів в `templates/`. + +### Обмеження на CRD {#limitations-on-crds} + +На відміну від більшості обʼєктів у Kubernetes, CRD (Custom Resource Definitions) встановлюються глобально. Тому Helm вживає дуже обережний підхід до управління CRD. CRD підлягають таким обмеженням: + +- CRD ніколи не перевстановлюються. Якщо Helm визначає, що CRD у теці `crds/` вже присутні (незалежно від версії), Helm не намагатиметься їх встановити чи оновити. +- CRD ніколи не встановлюються під час оновлення або відкату. Helm створює CRD тільки під час операцій встановлення. +- CRD ніколи не видаляються. Видалення CRD автоматично видаляє весь вміст CRD у всіх просторах імен у кластері. Тому Helm не видалятиме CRD. + +Операторам, які хочуть оновити або видалити CRD, рекомендується робити це вручну і з великою обережністю. + +## Використання Helm для управління чартами {#using-helm-to-manage-charts} + +Інструмент `helm` має кілька команд для роботи з чартами. + +Він може створити новий чарт для вас: + +```console +$ helm create mychart +Created mychart/ +``` + +Після редагування чарта, `helm` може упакувати його в архів чартів для вас: + +```console +$ helm package mychart +Archived mychart-0.1.-.tgz +``` + +Ви також можете використовувати `helm`, щоб знайти проблеми з форматуванням або інформацією вашого чарта: + +```console +$ helm lint mychart +No issues found +``` + +## Репозиторії чартів {#chart-repositories} + +Репозиторій чартів — це HTTP-сервер, який містить один або більше упакованих чартів. Хоча `helm` можна використовувати для управління локальними теками чартів, для обміну чартами переважно використовують репозиторій чартів. + +Будь-який HTTP-сервер, який може надавати YAML файли та tar файли та може відповідати на GET запити, можна використовувати як сервер репозиторіїв. Команда Helm тестувала деякі сервери, включаючи Google Cloud Storage з увімкненим режимом веб-сайту та S3 з увімкненим режимом веб-сайту. + +Репозиторій характеризується наявністю спеціального файлу з назвою `index.yaml`, який містить список всіх пакетів, наданих репозиторієм, разом із метаданими, які дозволяють отримувати та перевіряти ці пакети. + +На стороні клієнта репозиторії управляються командами `helm repo`. Однак Helm не надає інструменти для завантаження чартів на віддалені сервери репозиторіїв. Це повʼязано з тим, що така функціональність вимагала б значних вимог до сервера, що реалізує репозиторій, і підвищувала б барʼєр для налаштування репозиторію. + +## Стартер-паки чартів {#chart-starter-packs} + +Команда `helm create` має необовʼязковий параметр `--starter`, який дозволяє вказати "стартовий чарт". Також параметр стартера має короткий псевдонім `-p`. + +Приклади використання: + +```console +helm create my-chart --starter starter-name +helm create my-chart -p starter-name +helm create my-chart -p /absolute/path/to/starter-name +``` + +Стартери — це звичайні чарти, але вони розташовані в `$XDG_DATA_HOME/helm/starters`. Як розробник чартів, ви можете створювати чарти, які спеціально призначені для використання як стартери. Такі чарти повинні бути спроектовані з урахуванням наступних міркувань: + +- Файл `Chart.yaml` буде перезаписаний генератором. +- Користувачі очікують, що зміст такого чарта буде змінений, тому документація повинна вказувати, як користувачі можуть це зробити. +- Всі входження `` будуть замінені на вказане імʼя чарту, щоб стартові чарти можна було використовувати як шаблони, за винятком деяких змінних файлів. Наприклад, якщо ви використовуєте власні файли в теці `vars` або певні файли `README.md`, `` НЕ буде переважати всередині них. Крім того, опис чарту не успадковується. + +На даний момент єдиний спосіб додати чарт до `$XDG_DATA_HOME/helm/starters` — це вручну скопіювати його туди. У документації вашого чарту ви можете пояснити цей процес. diff --git a/content/uk/docs/topics/charts_hooks.md b/content/uk/docs/topics/charts_hooks.md new file mode 100644 index 000000000..f796c98b5 --- /dev/null +++ b/content/uk/docs/topics/charts_hooks.md @@ -0,0 +1,152 @@ +--- +title: "Хуки чартів" +description: "Опис, як працювати з хуками чартів." +weight: 2 +--- + +Helm надає механізм _хуків_, що дозволяє розробникам чартів втручатися на певних етапах життєвого циклу релізу. Наприклад, ви можете використовувати хуки для: + +- Завантаження ConfigMap або Secret під час встановлення до завантаження будь-яких інших чартів. +- Виконання Job для резервного копіювання бази даних перед встановленням нового чарту, а потім виконання другого Job після оновлення для відновлення даних. +- Запуску Job перед видаленням релізу для мʼякого виведення сервісу з обігу перед його видаленням. + +Хуки працюють як звичайні шаблони, але мають спеціальні анотації, які змушують Helm використовувати їх по-іншому. У цьому розділі ми розглянемо базовий шаблон використання хуків. + +## Доступні хуки {#available-hooks} + +Ось які хуки визначені: + +| Значення анотації | Опис | +| ----------------- | -------------------------------------------------------------------------------------------------------- | +| `pre-install` | Виконується після рендерингу шаблонів, але до створення будь-яких ресурсів у Kubernetes | +| `post-install` | Виконується після завантаження всіх ресурсів у Kubernetes | +| `pre-delete` | Виконується під час запиту на видалення перед видаленням будь-яких ресурсів з Kubernetes | +| `post-delete` | Виконується під час запиту на видалення після видалення всіх ресурсів релізу | +| `pre-upgrade` | Виконується під час запиту на оновлення після рендерингу шаблонів, але до оновлення будь-яких ресурсів | +| `post-upgrade` | Виконується під час запиту на оновлення після оновлення всіх ресурсів | +| `pre-rollback` | Виконується під час запиту на відкат після рендерингу шаблонів, але до відкату будь-яких ресурсів | +| `post-rollback` | Виконується під час запиту на відкат після модифікації всіх ресурсів | +| `test` | Виконується, коли викликано підкоманду Helm test ([переглянути документацію тестів](/docs/chart_tests/)) | + +_Зверніть увагу, що хук `crd-install` був видалений на користь теки `crds/` у Helm 3._ + +## Хуки та життєвий цикл релізу {#hooks-and-the-release-lifecycle} + +Хуки дозволяють вам, як розробнику чартів, виконувати операції на стратегічних етапах життєвого циклу релізу. Наприклад, розглянемо життєвий цикл для `helm install`. Стандартно життєвий цикл виглядає так: + +1. Користувач виконує `helm install foo`. +2. Викликається API бібліотеки Helm для встановлення. +3. Після деякої перевірки бібліотека рендерить шаблони `foo`. +4. Бібліотека завантажує результуючі ресурси у Kubernetes. +5. Бібліотека повертає обʼєкт релізу (та інші дані) клієнту. +6. Клієнт виходить. + +Helm визначає два хуки для життєвого циклу `install`: `pre-install` і `post-install`. Якщо розробник чарту `foo` реалізує обидва хуки, життєвий цикл змінюється таким чином: + +1. Користувач виконує `helm install foo`. +2. Викликається API бібліотеки Helm для встановлення. +3. CRD у теці `crds/` встановлюються. +4. Після деякої перевірки бібліотека рендерить шаблони `foo`. +5. Бібліотека готується виконати хуки `pre-install` (завантаження ресурсів хука у Kubernetes). +6. Бібліотека сортує хуки за вагою (стандартно вага дорівнює 0), за типом ресурсу та нарешті за імʼям за зростанням. +7. Бібліотека завантажує хук з найменшою вагою спочатку (від негативної до позитивної) +8. Бібліотека чекає, поки хук стане "Ready" (крім CRD) +9. Бібліотека завантажує результуючі ресурси у Kubernetes. Зверніть увагу, що якщо встановлено прапорець `--wait`, бібліотека чекатиме, поки всі ресурси не стануть готовими, і не запустить хук `post-install`, поки вони не будуть готові. +10. Бібліотека виконує хук `post-install` (завантаження ресурсів хука). +11. Бібліотека чекає, поки хук стане "Ready". +12. Бібліотека повертає обʼєкт релізу (та інші дані) клієнту. +13. Клієнт виходить. + +Що означає чекати, поки хук стане готовим? Це залежить від ресурсу, оголошеного в хуку. Якщо ресурс є типу `Job` або `Pod`, Helm чекатиме, поки він успішно виконається. І якщо хук не вдається, реліз зазнає невдачі. Це _блокуюча операція_, тому клієнт Helm призупиниться, поки Job виконується. + +Для всіх інших типів, як тільки Kubernetes позначає ресурс як завантажений (доданий або оновлений), ресурс вважається "Ready". Коли оголошено багато ресурсів у хуку, ресурси виконуються послідовно. Якщо у них є ваги хуків (див. нижче), вони виконуються в порядку ваг. Починаючи з Helm 3.2.0, ресурси хуків з однаковою вагою встановлюються в тому ж порядку, що і звичайні не-хукові ресурси. В іншому випадку, порядок не гарантується. (У Helm 2.3.0 і пізніше вони сортуються в алфавітному порядку. Це поведінка не є обовʼязковою і може змінитися в майбутньому.) Вважається гарною практикою додати вагу хуку та встановити її на `0`, якщо вага не є важливою. + +### Ресурси хуків не управляються відповідними релізами {#hook-resources-are-not-managed-by-releases} + +Ресурси, які створює хук, наразі не відстежуються та не управляються як частина релізу. Як тільки Helm перевіряє, що хук досяг свого готового стану, він залишає ресурс хука без змін. Збір сміття ресурсів хуків при видаленні відповідного релізу може бути додано до Helm 3 у майбутньому, тому будь-які ресурси хуків, які ніколи не повинні бути видалені, повинні бути анотовані як `helm.sh/resource-policy: keep`. + +Практично це означає, що якщо ви створюєте ресурси в хуку, ви не можете покладатися на `helm uninstall`, щоб видалити ресурси. Щоб знищити такі ресурси, вам потрібно або [додати власну анотацію `helm.sh/hook-delete-policy`](#hook-deletion-policies) до файлу шаблону хука, або [встановити поле часу життя (TTL) ресурсу Job](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/). + +## Написання хуку {#writing-a-hook} + +Хуки — це просто манифести Kubernetes з особливими анотаціями в секції `metadata`. Оскільки це шаблони, ви можете використовувати всі звичайні можливості шаблонів, включаючи читання `.Values`, `.Release` та `.Template`. + +Наприклад, цей шаблон, збережений у `templates/post-install-job.yaml`, оголошує Job, який буде виконаний при `post-install`: + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: "{{ .Release.Name }}" + labels: + app.kubernetes.io/managed-by: {{ .Release.Service | quote }} + app.kubernetes.io/instance: {{ .Release.Name | quote }} + app.kubernetes.io/version: {{ .Chart.AppVersion }} + helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" + annotations: + # Це те, що визначає цей ресурс як хук. Без цього рядка + # job вважається частиною релізу. + "helm.sh/hook": post-install + "helm.sh/hook-weight": "-5" + "helm.sh/hook-delete-policy": hook-succeeded +spec: + template: + metadata: + name: "{{ .Release.Name }}" + labels: + app.kubernetes.io/managed-by: {{ .Release.Service | quote }} + app.kubernetes.io/instance: {{ .Release.Name | quote }} + helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" + spec: + restartPolicy: Never + containers: + - name: post-install-job + image: "alpine:3.3" + command: ["/bin/sleep","{{ default "10" .Values.sleepyTime }}"] +``` + +Що робить цей шаблон хуком, так це анотація: + +```yaml +annotations: + "helm.sh/hook": post-install +``` + +Один ресурс може реалізовувати кілька хуків: + +```yaml +annotations: + "helm.sh/hook": post-install,post-upgrade +``` + +Аналогічно, немає обмежень на кількість різних ресурсів, які можуть реалізувати даний хук. Наприклад, можна оголосити як secret, так і config map як pre-install хук. + +Коли субчарти оголошують хуки, вони також оцінюються. Немає способу для основного чарту відключити хуки, оголошені субчартами. + +Можливо визначити вагу для хука, що допоможе створити детерміністичний порядок виконання. Ваги визначаються за допомогою наступної анотації: + +```yaml +annotations: + "helm.sh/hook-weight": "5" +``` + +Ваги хуків можуть бути позитивними або негативними числами, але повинні бути представлені як рядки. Коли Helm починає цикл виконання хуків певного типу, він сортує ці хуки у висхідному порядку. + +### Політики видалення хуків {#hook-deletion-policies} + +Можливо визначити політики, які визначають, коли видаляти відповідні ресурси хуків. Політики видалення хуків визначаються за допомогою наступної анотації: + +```yaml +annotations: + "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded +``` + +Ви можете вибрати одне або кілька визначених значень анотацій: + +| Значення анотації | Опис | +| ----------------------- | ---------------------------------------------------------------- | +| `before-hook-creation` | Видалити попередній ресурс перед запуском нового хуку (стандартно) | +| `hook-succeeded` | Видалити ресурс після успішного виконання хука | +| `hook-failed` | Видалити ресурс, якщо хук зазнав невдачі під час виконання | + +Якщо анотація політики видалення хука не вказана, стандартно застосовується поведінка `before-hook-creation`. diff --git a/content/uk/docs/topics/kubernetes_apis.md b/content/uk/docs/topics/kubernetes_apis.md new file mode 100644 index 000000000..d521b329f --- /dev/null +++ b/content/uk/docs/topics/kubernetes_apis.md @@ -0,0 +1,84 @@ +--- +title: "Застарілі API Kubernetes" +description: "Пояснення щодо застарілих API Kubernetes у Helm" +weight: 14 +--- + +Kubernetes є системою, що керується API, і API еволюціонує з часом, відображаючи зміну розуміння проблемного простору. Це загальноприйнята практика для систем та їх API. Важливою частиною еволюції API є наявність чіткої політики застарівання та процесу, який інформує користувачів про те, як впроваджуються зміни до API. Іншими словами, споживачі вашого API повинні знати заздалегідь, коли та в якій версії API буде видалено або змінено. Це дозволяє уникнути неприємних сюрпризів та руйнівних змін для споживачів. + +[Політика застарівання Kubernetes](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) документує, як Kubernetes обробляє зміни версій API. Політика щодо застарівання визначає часові рамки підтримки версій API після оголошення про їх застарівання. Тому важливо бути в курсі оголошень про застарівання та знати, коли версії API будуть видалені, щоб мінімізувати вплив. + +Прикладом такого оголошення є [оголошення про видалення застарілих версій API у Kubernetes 1.16](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/), яке було опубліковано за кілька місяців до релізу. Ці версії API були оголошені застарілими ще раніше. Це свідчить про наявність чіткої політики, яка інформує споживачів про підтримку версій API. + +Шаблони Helm вказують [групу API Kubernetes](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups) при визначенні обʼєкта Kubernetes, аналогічно до маніфесту Kubernetes. Це вказується в полі `apiVersion` шаблону і визначає версію API обʼєкта Kubernetes. Це означає, що користувачі Helm та підтримувачі чартів повинні знати, коли версії API Kubernetes були оголошені застарілими та в якій версії Kubernetes вони будуть видалені. + +## Підтримувачі чартів {#chart-maintainers} + +Вам слід перевіряти свої чарти на наявність версій API Kubernetes, які оголошені застарілими або видаленими у певній версії Kubernetes. Виявлені версії API, які скоро перестануть підтримуватися або вже не підтримуються, слід оновити до підтримуваних версій і випустити нову версію чарту. Версія API визначається полями `kind` і `apiVersion`. Наприклад, ось версія API обʼєкта `Deployment`, яка була видалена в Kubernetes 1.16: + +```yaml +apiVersion: apps/v1beta1 +kind: Deployment +``` + +## Користувачі Helm {#helm-users} + +Вам слід перевірити чарти, які ви використовуєте (аналогічно до [підтримувачів чартів](#chart-maintainers)), і визначити будь-які чарти, у яких версії API застарілі або видалені у певній версії Kubernetes. Для виявлених чартів вам потрібно знайти останню версію чарту (яка містить підтримувані версії API) або оновити чарт самостійно. + +Крім того, вам також потрібно перевірити будь-які розгорнуті чарти (тобто релізи Helm) на наявність застарілих або видалених версій API. Це можна зробити, отримавши деталі релізу за допомогою команди `helm get manifest`. + +Метод оновлення релізу Helm до підтримуваних API залежить від ваших знахідок, як описано нижче: + +1. Якщо ви знайшли лише застарілі версії API, то: + - Виконайте `helm upgrade` з версією чарту, яка підтримує версії API Kubernetes. + - Додайте опис до оновлення, щось на зразок "не виконувати відкат до версії Helm, що передує цій поточній версії". + +2. Якщо ви знайшли будь-яку версію API, яка була видалена у версії Kubernetes, то: + - Якщо ви використовуєте версію Kubernetes, де ці версії API все ще доступні (наприклад, ви використовуєте Kubernetes 1.15 і виявили, що використовуєте API, які будуть видалені у Kubernetes 1.16): + - Дотримуйтесь процедури, описаної у пункті 1. + - Інакше (наприклад, ви вже використовуєте версію Kubernetes, де деякі версії API, зазначені у `helm get manifest`, більше не доступні): + - Вам потрібно відредагувати маніфест релізу, який зберігається в кластері, щоб оновити версії API до підтримуваних. Див. [Оновлення версій API маніфесту релізу](#updating-api-versions-of-a-release-manifest) для отримання додаткової інформації. + +> Примітка: У всіх випадках оновлення релізу Helm до підтримуваних API ніколи не слід виконувати відкат релізу до версії, яка передує версії релізу з підтримуваними API. + +> Рекомендація: Найкраща практика — оновлювати релізи, використовуючи застарілі версії API, до підтримуваних версій API до того, як виконати оновлення кластера Kubernetes, який видаляє ці версії API. + +Якщо ви не оновите реліз, як запропоновано вище, ви отримаєте помилку, схожу на наступну, при спробі оновити реліз у версії Kubernetes, де його версія API була видалена: + +```log +Error: UPGRADE FAILED: current release manifest contains removed kubernetes api(s) +for this kubernetes version and it is therefore unable to build the kubernetes +objects for performing the diff. error from kubernetes: unable to recognize "": +no matches for kind "Deployment" in version "apps/v1beta1" +``` + +Helm не вдається виконати оновлення в такому випадку, оскільки він намагається створити патч відмінностей між поточним розгорнутим релізом (який містить версії API Kubernetes, що були видалені в цій версії Kubernetes) та чартом, який ви передаєте з оновленими/підтримуваними версіями API. Основна причина невдачі полягає в тому, що коли Kubernetes видаляє версію API, клієнтська бібліотека Go для Kubernetes більше не може аналізувати застарілі обʼєкти, і тому Helm зазнає невдачі при виклику бібліотеки. На жаль, Helm не в змозі відновитися з такої ситуації та більше не може керувати таким релізом. Див. [Оновлення версій API маніфесту релізу](#updating-api-versions-of-a-release-manifest) для отримання додаткової інформації про те, як відновитися з такої ситуації. + +## Оновлення версій API маніфесту релізу {#updating-api-versions-of-a-release-manifest} + +Маніфест є властивістю обʼєкта релізу Helm, який зберігається в полі `data` в Secret (стандартно) або ConfigMap у кластері. Поле `data` містить обʼєкт у стиснутому вигляді, закодований у base64 (існує додаткове кодування base64 для Secret). Для кожної версії/ревізії релізу існує свій Secret/ConfigMap у просторі імен релізу. + +Ви можете використовувати втулок Helm [mapkubeapis](https://github.com/helm/helm-mapkubeapis) для оновлення релізу до підтримуваних API. Ознайомтеся з readme для отримання додаткової інформації. + +Альтернативно, ви можете дотримуватися цих ручних кроків для оновлення версій API маніфесту релізу. Залежно від вашої конфігурації, дотримуйтесь кроків для Secret або ConfigMap. + +- Отримайте імʼя Secret або ConfigMap, повʼязане з останнім розгорнутим релізом: + - Secret: `kubectl get secret -l owner=helm,status=deployed,name= --namespace | awk ʼ{print $1}ʼ | grep -v NAME` + - ConfigMap: `kubectl get configmap -l owner=helm,status=deployed,name= --namespace | awk ʼ{print $1}ʼ | grep -v NAME` +- Отримайте деталі останнього розгорнутого релізу: + - Secret: `kubectl get secret -n -o yaml > release.yaml` + - ConfigMap: `kubectl get configmap -n -o yaml > release.yaml` +- Зробіть резервну копію релізу на випадок, якщо вам знадобиться відновлення у разі помилки: + - `cp release.yaml release.bak` + - У разі необхідності, відновіть: `kubectl apply -f release.bak -n ` +- Розкодуйте обʼєкт релізу: + - Secret: `cat release.yaml | grep -oP ʼ(?<=release: ).*ʼ | base64 -d | base64 -d | gzip -d > release.data.decoded` + - ConfigMap: `cat release.yaml | grep -oP ʼ(?<=release: ).*ʼ | base64 -d | gzip -d > release.data.decoded` +- Змініть версії API маніфестів. Ви можете використовувати будь-який інструмент (наприклад, редактор) для внесення змін. Це знаходиться у полі `manifest` вашого розкодованого обʼєкта релізу (`release.data.decoded`). +- Закодуйте обʼєкт релізу: + - Secret: `cat release.data.decoded | gzip | base64 | base64` + - ConfigMap: `cat release.data.decoded | gzip | base64` +- Замість значення властивості `data.release` у файлі розгорнутого релізу (`release.yaml`) вставте новий закодований обʼєкт релізу. +- Застосуйте файл до простору імен: `kubectl apply -f release.yaml -n ` +- Виконайте `helm upgrade` з версією чарта, яка підтримує версії API Kubernetes. +- Додайте опис до оновлення, щось на зразок "не виконувати відкат до версії Helm, що передує цій поточній версії". diff --git a/content/uk/docs/topics/kubernetes_distros.md b/content/uk/docs/topics/kubernetes_distros.md new file mode 100644 index 000000000..3fb7408f3 --- /dev/null +++ b/content/uk/docs/topics/kubernetes_distros.md @@ -0,0 +1,76 @@ +--- +title: "Дистрибутиви Kubernetes" +description: "Містить інформацію про використання Helm у специфічних середовищах Kubernetes." +weight: 10 +--- + +Helm повинен працювати з будь-якою [відповідною версією Kubernetes](https://github.com/cncf/k8s-conformance) (сертифікованою чи ні). + +Цей документ містить інформацію про використання Helm у специфічних середовищах Kubernetes. Будь ласка, додайте більше деталей про будь-які дистрибутиви (відсортовано за алфавітом), якщо це потрібно. + +## AKS + +Helm працює з [Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm). + +## DC/OS + +Helm було протестовано і він працює на платформі Kubernetes Mesosphere DC/OS 1.11, і не вимагає додаткової конфігурації. + +## EKS + +Helm працює з Amazon Elastic Kubernetes Service (Amazon EKS): +[Використання Helm з Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html). + +## GKE + +Хостингова платформа Kubernetes Google GKE відома своєю сумісністю з Helm і не потребує додаткової конфігурації. + +## `scripts/local-cluster` та Hyperkube {#scripts-local-cluster-and-hyperkube} + +Hyperkube, налаштований через `scripts/local-cluster.sh`, відомий своєю сумісністю. Для чистого Hyperkube можливо, що знадобиться деяка ручна конфігурація. + +## IKS + +Helm працює з [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-helm). + +## KIND (Kubernetes IN Docker) + +Helm регулярно тестується з [KIND](https://github.com/kubernetes-sigs/kind). + +## KubeOne + +Helm працює у кластерах, які налаштовані за допомогою KubeOne без обмежень. + +## Kubermatic + +Helm працює у кластерах користувачів, створених Kubermatic без обмежень. Оскільки кластер seed може бути налаштований по-різному, підтримка Helm залежить від їх конфігурації. + +## MicroK8s + +Helm можна активувати в [MicroK8s](https://microk8s.io) за допомогою команди: +`microk8s.enable helm3` + +## Minikube + +Helm протестований і відомий своєю сумісністю з [Minikube](https://github.com/kubernetes/minikube). Додаткової конфігурації не потребує. + +## Openshift + +Helm працює без проблем на OpenShift Online, OpenShift Dedicated, OpenShift Container Platform (версія >= 3.6) або OpenShift Origin (версія >= 3.6). Щоб дізнатися більше, прочитайте [цей блог](https://blog.openshift.com/getting-started-helm-openshift/). + +## Platform9 + +Helm попередньо встановлений в [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/?utm_source=helm_distro_notes). Platform9 надає доступ до всіх офіційних чартів Helm через інтерфейс App Catalog і нативний Kubernetes CLI. Додаткові репозиторії можна додати вручну. Додаткові відомості можна знайти в [статті Platform9 App Catalog](https://platform9.com/support/deploying-kubernetes-apps-platform9-managed-kubernetes/?utm_source=helm_distro_notes). + +## Ubuntu з `kubeadm` {#ubuntu-with-kubeadm} + +Kubernetes, налаштований за допомогою `kubeadm`, відомий своєю сумісністю з наступними дистрибутивами Linux: + +- Ubuntu 16.04 +- Fedora release 25 + +Деякі версії Helm (v2.0.0-beta2) вимагають від вас `export KUBECONFIG=/etc/kubernetes/admin.conf` або створення `~/.kube/config`. + +## VMware Tanzu Kubernetes Grid + +Helm працює на VMware Tanzu Kubernetes Grid, TKG, без необхідності змінювати конфігурацію. Tanzu CLI може управляти встановленням пакетів для [helm-controller](https://fluxcd.io/flux/components/helm/), що дозволяє декларативно управляти релізами чартів Helm. Додаткові відомості доступні в документації TKG для [CLI-управлінських пакетів](https://docs.vmware.com/en/VMware-Tanzu-Kubernetes-Grid/1.6/vmware-tanzu-kubernetes-grid-16/GUID-packages-user-managed-index.html#package-locations-and-dependencies-5). diff --git a/content/uk/docs/topics/library_charts.md b/content/uk/docs/topics/library_charts.md new file mode 100644 index 000000000..99f256855 --- /dev/null +++ b/content/uk/docs/topics/library_charts.md @@ -0,0 +1,351 @@ +--- +title: "Бібліотечні чарти" +description: "Описує бібліотечні чарти та приклади їх використання" +weight: 4 +--- + +Бібліотечний чарт — це тип [Helm чарту]({{< ref "/docs/topics/charts.md" >}}), який визначає примітиви або визначення, що можуть бути спільно використані шаблонами Helm в інших чартах. Це дозволяє користувачам ділитися фрагментами коду, які можна повторно використовувати у різних чартах, уникаючи повторень та підтримуючи чарти [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) (Don't Repeat Yourself). + +Бібліотечний чарт було представлено у Helm 3 для формального визнання загальних або допоміжних чартів, які використовувалися авторами чартів ще з Helm 2. Додавши його як тип чарту, він надає: + +- Спосіб чітко розрізняти загальні та чарти застосунків +- Логіку, що запобігає встановленню загального чарту +- Відсутність рендерингу шаблонів у загальному чарті, які можуть містити артефакти релізу +- Дозвіл залежним чартам використовувати контекст імпортера + +Автор чарту може визначити загальний чарт як бібліотечний чарт та бути впевненим, що Helm обробить чарт стандартним узгодженим способом. Це також означає, що визначення у прикладному чарті можуть бути спільно використані шляхом зміни типу чарту. + +## Створення простого бібліотечного чарту {#creating-a-simple-library-chart} + +Як вже згадувалося раніше, бібліотечний чарт — це тип [Helm чарту]({{< ref "/docs/topics/charts.md" >}}). Це означає, що ви можете почати зі створення шаблонного чарту: + +```console +$ helm create mylibchart +Creating mylibchart +``` + +Спочатку видаліть усі файли в теці `templates`, оскільки ми будемо створювати власні визначення шаблонів у цьому прикладі. + +```console +$ rm -rf mylibchart/templates/* +``` + +Файл значень (values.yaml) також не буде потрібен. + +```console +$ rm -f mylibchart/values.yaml +``` + +Перш ніж перейти до створення загального коду, давайте швидко переглянемо деякі відповідні концепції Helm. [іменований шаблон]({{< ref "/docs/chart_template_guide/named_templates.md" >}}) (іноді називають частковим або субшаблоном) — це просто шаблон, визначений у файлі та який має назву. У теці `templates/` будь-який файл, який починається з підкреслення (_), не призначений для виводу маніфесту Kubernetes. Тому зазвичай допоміжні шаблони та часткові шаблони розміщуються у файлах `_*.tpl` або `_*.yaml`. + +У цьому прикладі ми створимо загальний ConfigMap, який створює пустий ресурс ConfigMap. Ми визначимо загальний ConfigMap у файлі `mylibchart/templates/_configmap.yaml` наступним чином: + +```yaml +{{- define "mylibchart.configmap.tpl" -}} +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} +data: {} +{{- end -}} +{{- define "mylibchart.configmap" -}} +{{- include "mylibchart.util.merge" (append . "mylibchart.configmap.tpl") -}} +{{- end -}} +``` + +Конструкція ConfigMap визначена у шаблоні з назвою `mylibchart.configmap.tpl`. Це простий ConfigMap з пустим ресурсом `data`. У цьому файлі є ще один іменований шаблон назвою, назва якого `mylibchart.configmap`. Цей іменований шаблон включає інший іменований шаблон `mylibchart.util.merge`, який приймає 2 іменовані шаблони як аргументи: шаблон, що викликає `mylibchart.configmap` та `mylibchart.configmap.tpl`. + +Допоміжна функція `mylibchart.util.merge` є іменованим шаблоном у `mylibchart/templates/_util.yaml`. Це зручний інструмент з [Загального допоміжного чарту Helm](#the-common-helm-helper-chart), оскільки він обʼєднує 2 шаблони та перевизначає будь-які спільні частини в обох: + +```yaml +{{- /* +mylibchart.util.merge зʼєднує два YAML-шаблони та виводить результат. +Він приймає масив із трьох значень: +- контекст верхнього рівня +- ім'я шаблону перевизначення (призначення) +- ім'я шаблону бази (джерело) +*/}} +{{- define "mylibchart.util.merge" -}} +{{- $top := first . -}} +{{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}} +{{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}} +{{- toYaml (merge $overrides $tpl) -}} +{{- end -}} +``` + +Це важливо, коли чарт хоче використовувати загальний код, який йому потрібно налаштувати за допомогою своєї конфігурації. + +Нарешті, змініть тип чарту на `library`. Це вимагає редагування файлу `mylibchart/Chart.yaml` наступним чином: + +```yaml +apiVersion: v2 +name: mylibchart +description: Helm чарт для Kubernetes + +# Чарт може бути або 'application', або 'library'. +# +# Чарти застосунків є колекцією шаблонів, які можуть бути упаковані +# у версійні архіви для розгортання. +# +# Бібліотечні чарти надають корисні утиліти або функції для розробника +# чартів. Вони включаються як залежність прикладних чартів для вбудування +# цих утиліт та функцій у процес рендерингу. Бібліотечні чарти не визначають +# жодних шаблонів і тому не можуть бути розгорнуті. +# type: application +type: library + +# Це версія чарту. Це номер версії повинен збільшуватися кожного разу, +# коли ви вносите зміни в чарт і його шаблони, включаючи версію програми. +version: 0.1.0 + +# Це номер версії програми, що розгортається. Цей номер версії повинен +# збільшуватися кожного разу, коли ви вносите зміни в програму, і +# рекомендується використовувати з лапками. +appVersion: "1.16.0" +``` + +Тепер бібліотечний чарт готовий до спільного використання, а його визначення ConfigMap — до повторного використання. + +Перш ніж продовжити, варто перевірити, чи розпізнає Helm чарт як бібліотечний: + +```console +$ helm install mylibchart mylibchart/ +Error: library charts are not installable +``` + +## Використання простого бібліотечного чарту {#use-a-simple-library-chart} + +Настав час використати бібліотечний чарт. Для цього створимо знову шаблонний чарт: + +```console +$ helm create mychart +Creating mychart +``` + +Знову очистимо файли шаблонів, оскільки ми хочемо створити лише ConfigMap: + +```console +$ rm -rf mychart/templates/* +``` + +Якщо ми хочемо створити простий ConfigMap у шаблоні Helm, він може виглядати приблизно так: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} +data: + myvalue: "Hello World" +``` + +Однак, ми будемо повторно використовувати загальний код, створений у `mylibchart`. ConfigMap можна створити у файлі `mychart/templates/configmap.yaml` наступним чином: + +```yaml +{{- include "mylibchart.configmap" (list . "mychart.configmap") -}} +{{- define "mychart.configmap" -}} +data: + myvalue: "Hello World" +{{- end -}} +``` + +Ви бачите, що це спрощує нашу роботу, успадковуючи загальне визначення ConfigMap, яке додає стандартні властивості для ConfigMap. У нашому шаблоні ми додаємо конфігурацію, у цьому випадку ключ даних `myvalue` та його значення. Конфігурація перекриває пустий ресурс загального ConfigMap. Це можливо завдяки допоміжній функції `mylibchart.util.merge`, яку ми згадували у попередньому розділі. + +Щоб мати можливість використовувати загальний код, нам потрібно додати `mylibchart` як залежність. Додайте наступний код в кінець файлу `mychart/Chart.yaml`: + +```yaml +# Мій загальний код у бібліотечному чарті +dependencies: +- name: mylibchart + version: 0.1.0 + repository: file://../mylibchart +``` + +Це включає бібліотечний чарт як динамічну залежність із файлової системи, яка знаходиться на тому самому рівні, що і наш прикладний чарт. Оскільки ми включаємо бібліотечний чарт як динамічну залежність, нам потрібно виконати `helm dependency update`. Це скопіює бібліотечний чарт у вашу теку `charts/`. + +```console +$ helm dependency update mychart/ +Hang tight while we grab the latest from your chart repositories... +...Successfully got an update from the "stable" chart repository +Update Complete. ⎈Happy Helming!⎈ +Saving 1 charts +Deleting outdated charts +``` + +Тепер ми готові розгорнути наш чарт. Перш ніж встановлювати, варто перевірити спочатку рендеринг шаблону. + +```console +$ helm install mydemo mychart/ --debug --dry-run +install.go:159: [debug] Original chart version: "" +install.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart + +NAME: mydemo +LAST DEPLOYED: Tue Mar 3 17:48:47 2020 +NAMESPACE: default +STATUS: pending-install +REVISION: 1 +TEST SUITE: None +USER-SUPPLIED VALUES: +{} + +COMPUTED VALUES: +affinity: {} +fullnameOverride: "" +image: + pullPolicy: IfNotPresent + repository: nginx +imagePullSecrets: [] +ingress: + annotations: {} + enabled: false + hosts: + - host: chart-example.local + paths: [] + tls: [] +mylibchart: + global: {} +nameOverride: "" +nodeSelector: {} +podSecurityContext: {} +replicaCount: 1 +resources: {} +securityContext: {} +service: + port: 80 + type: ClusterIP +serviceAccount: + annotations: {} + create: true + name: null +tolerations: [] + +HOOKS: +MANIFEST: +--- +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +data: + myvalue: Hello World +kind: ConfigMap +metadata: + labels: + app: mychart + chart: mychart-0.1.0 + release: mydemo + name: mychart-mydemo +``` + +Це виглядає як ConfigMap, який ми хочемо, з перезаписуванням даних `myvalue: Hello World`. Встановімо його: + +```console +$ helm install mydemo mychart/ +NAME: mydemo +LAST DEPLOYED: Tue Mar 3 17:52:40 2020 +NAMESPACE: default +STATUS: deployed +REVISION: 1 +TEST SUITE: None +``` + +Ми можемо отримати реліз і побачити, що фактичний шаблон був завантажений. + +```console +$ helm get manifest mydemo +--- +# Source: mychart/templates/configmap.yaml +apiVersion: v1 +data: + myvalue: Hello World +kind: ConfigMap +metadata: + labels: + app: mychart + chart: mychart-0.1.0 + release: mydemo + name: mychart-mydemo +``` + +## Переваги бібліотечних чартів {#library-chart-benefits} + +З огляду на те, що бібліотечні чарти не можуть працювати як самостійні чарти, вони можуть використовувати такі функції: + +- Об’єкт `.Files` посилається на шляхи файлів у головному чарті, а не на локальний шлях до бібліотечного чарту. +- Об’єкт `.Values` є таким самим, як і в головному чарті, на відміну від [субчартів]({{< ref "/docs/chart_template_guide/subcharts_and_globals.md" >}}) застосунків, які отримують розділ значень, налаштованих під їхнім заголовком у головному чарті. + +## Common Helm Helper Chart {#the-common-helm-helper-chart} + +```markdown +Примітка: Репозиторій Common Helm Helper Chart на Github більше не підтримується, і репозиторій було визнано застарілим та зархівовано. +``` + +Цей [чарт](https://github.com/helm/charts/tree/master/incubator/common) був початковим зразком для спільних чартів. Він надає утиліти, які відображають найкращі практики розробки чартів Kubernetes. Найкраще, що ви можете використати його одразу, коли розробляєте свої чарти, щоб отримати корисний загальний код. + +Ось короткий спосіб його використання. Для отримання додаткових деталей перегляньте [README](https://github.com/helm/charts/blob/master/incubator/common/README.md). + +Створіть знову шаблонний чарт: + +```console +$ helm create demo +Creating demo +``` + +Використаймо загальний код з helper chart. Спочатку відредагуйте файл deployment `demo/templates/deployment.yaml` наступним чином: + +```yaml +{{- template "common.deployment" (list . "demo.deployment") -}} +{{- define "demo.deployment" -}} +## Вкажіть перевизначення для вашого ресурсу Deployment тут, наприклад +apiVersion: apps/v1 +spec: + replicas: {{ .Values.replicaCount }} + selector: + matchLabels: + {{- include "demo.selectorLabels" . | nindent 6 }} + template: + metadata: + labels: + {{- include "demo.selectorLabels" . | nindent 8 }} + +{{- end -}} +``` + +І тепер файл сервісу, `demo/templates/service.yaml`, наступним чином: + +```yaml +{{- template "common.service" (list . "demo.service") -}} +{{- define "demo.service" -}} +## Вкажіть перевизначення для вашого ресурсу Service тут, наприклад +# metadata: +# labels: +# custom: label +# spec: +# ports: +# - port: 8080 +{{- end -}} +``` + +Ці шаблони демонструють, як використання загального коду з helper chart спрощує ваше кодування до налаштування чи конфігурації ресурсів. + +Щоб мати можливість використовувати загальний код, нам потрібно додати `common` як залежність. Додайте наступне в кінець файлу `demo/Chart.yaml`: + +```yaml +dependencies: +- name: common + version: "^0.0.5" + repository: "https://charts.helm.sh/incubator/" +``` + +Примітка: вам потрібно буде додати `incubator` до списку репозиторіїв Helm (`helm repo add`). + +Оскільки ми включаємо чарт як динамічну залежність, нам потрібно виконати `helm dependency update`. Це скопіює helper chart у вашу теку `charts/`. + +Оскільки helper chart використовує деякі конструкції Helm 2, вам потрібно буде додати наступне до `demo/values.yaml`, щоб дозволити завантаження образу `nginx`, оскільки це було оновлено в шаблонному чарті Helm 3: + +```yaml +image: + tag: 1.16.0 +``` + +Ви можете перевірити, чи правильні шаблони чарту, перед розгортанням, використовуючи команди `helm lint` і `helm template`. + +Якщо все добре, розгорніть чарт, використовуючи `helm install`! diff --git a/content/uk/docs/topics/permissions_sql_storage_backend.md b/content/uk/docs/topics/permissions_sql_storage_backend.md new file mode 100644 index 000000000..0b348df33 --- /dev/null +++ b/content/uk/docs/topics/permissions_sql_storage_backend.md @@ -0,0 +1,45 @@ +--- +title: "Управління правами доступу для SQL-сховища" +description: "Дізнайтеся, як налаштувати права доступу при використанні SQL-сховища." +weight: 16 +--- + +Цей документ надає рекомендації користувачам щодо налаштування та управління правами доступу при використанні SQL-сховища. + +## Вступ {#introduction} + +Для керування правами доступу Helm використовує функцію RBAC (Role-Based Access Control) Kubernetes. Проте, коли використовується SQL-сховище, ролі Kubernetes не можуть бути використані для визначення, чи може користувач отримати доступ до певного ресурсу. У цьому документі описано, як створювати та керувати такими правами доступу. + +## Ініціалізація {#initialization} + +При першому підключенні CLI Helm до вашої бази даних клієнт перевірить, чи було її попередньо ініціалізовано. Якщо ні, клієнт автоматично подбає про необхідне налаштування. Для цього ініціалізація потребує адміністративних привілеїв у схемі public або принаймні можливості: + +* створення таблиці; +* надання привілеїв на схему public. + +Після виконання міграції в базі даних всі інші ролі зможуть використовувати клієнт. + +## Надання привілеїв неадміністративному користувачеві в PostgreSQL {#grant-privileges-to-a-non-admin-user-in-postgresql} + +Для керування правами доступу драйвер SQL-сховища використовує функцію [RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html) (Row-Level Security) PostgreSQL. RLS дозволяє всім користувачам читати/записувати в одну й ту ж таблицю, але без можливості маніпулювати однаковими рядками, якщо їм це не було явно дозволено. Стандартно будь-яка роль, яка не отримала відповідних привілеїв, завжди отримуватиме порожній список при виконанні команди `helm list` і не матиме змоги отримати або змінити будь-який ресурс у кластері. + +Розглянемо, як надати певній ролі доступ до конкретних просторів імен: + +```sql +CREATE POLICY <назва> ON releases_v1 FOR ALL TO <роль> USING (namespace = 'default'); +``` + +Ця команда надасть дозволи на читання та запис всіх ресурсів, які відповідають умові `namespace = 'default'`, для ролі `role`. Після створення цієї політики користувач, підключений до бази даних від імені ролі `role`, зможе бачити всі випуски в просторі імен `default` при виконанні команди `helm list`, а також змінювати та видаляти їх. + +Привілеї можна керувати детально за допомогою RLS, і можливо буде корисним обмежити доступ, залежно від різних стовпців таблиці: + +* key +* type +* body +* name +* namespace +* version +* status +* owner +* createdAt +* modifiedAt diff --git a/content/uk/docs/topics/plugins.md b/content/uk/docs/topics/plugins.md new file mode 100644 index 000000000..e61834b3b --- /dev/null +++ b/content/uk/docs/topics/plugins.md @@ -0,0 +1,286 @@ +--- +title: "Втулки Helm" +description: "Описує, як використовувати та створювати втулки для розширення функціональності Helm." +weight: 12 +--- + +Втулок Helm — це інструмент, до якого можна отримати доступ через CLI `helm`, але який не є частиною основного коду Helm. + +Наявні втулки можна знайти у [відповідному]({{< ref "/docs/community/related.md#helm-plugins" >}}) розділі або шукаючи на [GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories). + +Цей посібник пояснює, як використовувати та створювати втулки. + +## Огляд {#an-overview} + +Втулки Helm є додатковими інструментами, які безперешкодно інтегруються з Helm. Вони надають спосіб розширення основного набору функцій Helm без потреби написання кожної нової функції на Go і додавання її до основного інструменту. + +Втулки Helm мають такі особливості: + +- Їх можна додавати та видаляти з установки Helm без впливу на основний інструмент Helm. +- Вони можуть бути написані будь-якою мовою програмування. +- Вони інтегруються з Helm і будуть відображатися в `helm help` та інших місцях. + +Втулки Helm знаходяться в `$HELM_PLUGINS`. Ви можете дізнатися поточне значення цієї змінної, включаючи стандартні значення, коли не задано в середовищі, за допомогою команди `helm env`. + +Модель втулків Helm частково моделюється на основі моделі втулків Git. Відповідно, іноді ви можете чути, що `helm` називають _porcelain_ шаром, а втулки — _plumbing_. Це скорочений спосіб зазначити, що Helm забезпечує користувацький досвід і верхній рівень обробки логіки, тоді як втулки виконують "детальну роботу" для виконання бажаної дії. + +## Встановлення втулка {#installing-a-plugin} + +Втулки встановлюються за допомогою команди `$ helm plugin install `. Ви можете передати шлях до втулка у вашій локальній файловій системі або URL віддаленого репозиторію VCS. Команда `helm plugin install` клонуватиме або копіюватиме втулок за вказаним шляхом/URL у `$HELM_PLUGINS`. + +```console +$ helm plugin install https://github.com/adamreese/helm-env +``` + +Якщо у вас є дистрибутив втулка у форматі tar, просто розпакуйте втулок у теку `$HELM_PLUGINS`. Ви також можете встановлювати втулки tarball безпосередньо з URL, використовуючи `helm plugin install https://domain/path/to/plugin.tar.gz`. + +## Створення втулків {#building-a-plugin} + +З усіх боків втулок схожий на чарт. Кожен втулок має теку верхнього рівня, а також файл `plugin.yaml`. + +```none +$HELM_PLUGINS/ + |- last/ + | + |- plugin.yaml + |- last.sh + +``` + +У наведеному прикладі втулок `last` міститься у теці, що називається `last`. Він має два файли: `plugin.yaml` (обовʼязковий) та виконуваний скрипт, `last.sh` (необовʼязковий). + +Ядро втулка — це простий YAML файл, названий `plugin.yaml`. Ось YAML для втулка, який допомагає отримати останню назву релізу: + +```yaml +name: "last" +version: "0.1.0" +usage: "отримати останню назву релізу" +description: "отримати останню назву релізу" +ignoreFlags: false +command: "$HELM_BIN --host $TILLER_HOST list --short --max 1 --date -r" +platformCommand: + - os: linux + arch: i386 + command: "$HELM_BIN list --short --max 1 --date -r" + - os: linux + arch: amd64 + command: "$HELM_BIN list --short --max 1 --date -r" + - os: windows + arch: amd64 + command: "$HELM_BIN list --short --max 1 --date -r" +``` + +`name` — це імʼя втулка. Коли Helm виконує цей втулок, це імʼя буде використовуватися (наприклад, `helm NAME` викликає цей втулок). + +_`name` повинно відповідати імені теки._ У нашому прикладі втулок з `name: last` має бути поміщений у теку з назвою `last`. + +Обмеження для `name`: + +- `name` не може дублювати одну з наявних команд на верхньому рівні `helm`. +- `name` має бути обмежено символами ASCII a-z, A-Z, 0-9, `_` та `-`. + +`version` — це версія втулка за SemVer 2. `usage` і `description` використовуються для створення тексту довідки команди. + +Перемикач `ignoreFlags` вказує Helm, що _не_ слід передавати прапорці втулку. Якщо втулок викликаний з `helm myplugin --foo` і `ignoreFlags: true`, тоді `--foo` буде мовчки відкинуто. + +Нарешті, і найголовніше, `platformCommand` або `command` — це команда, яку цей втулок виконає, коли його викликають. Розділ `platformCommand` визначає специфічні для ОС/Архітектури варіації команди. Наступні правила застосовуються при визначенні, яку команду використовувати: + +- Якщо `platformCommand` присутній, він буде перевірений першим. +- Якщо `os` та `arch` відповідають поточній платформі, пошук зупиниться, і команда буде використана. +- Якщо `os` відповідає і немає більш специфічного `arch` відповідності, команда буде використана. +- Якщо жодної відповідності `platformCommand` не знайдено, буде використана стандартна команда `command`. +- Якщо жодної відповідності не знайдено в `platformCommand` і `command` не присутній, Helm завершить виконання з помилкою. + +Змінні середовища підставляються перед виконанням втулка. Шаблон вище ілюструє рекомендований спосіб вказівки, де знаходиться програма втулка. + +Є кілька стратегій для роботи з командами втулків: + +- Якщо втулок включає виконуваний файл, виконуваний файл для `platformCommand:` або `command:` має бути упакований у теку втулка. +- Рядок `platformCommand:` або `command:` буде мати розширені змінні середовища перед виконанням. `$HELM_PLUGIN_DIR` вказуватиме на теку втулка. +- Команда сама по собі не виконується в оболонці. Тому ви не можете використовувати однорядковий скрипт оболонки. +- Helm вбудовує багато конфігурацій у змінні середовища. Ознайомтеся з середовищем, щоб дізнатися, яка інформація доступна. +- Helm не робить припущень щодо мови втулка. Ви можете написати його будь-якою мовою, яка вам подобається. +- Команди відповідають за реалізацію специфічного тексту допомоги для `-h` та `--help`. Helm використовуватиме `usage` та `description` для `helm help` та `helm help myplugin`, але не обробляє `helm myplugin --help`. + +## Завантажувач втулків {#downloader-plugins} + +Стандартно Helm здатен завантажувати чарти за допомогою HTTP/S. Починаючи з версії Helm 2.4.0, втулки можуть мати спеціальну можливість завантажувати чарти з довільних джерел. + +Втулки повинні оголосити цю спеціальну можливість у файлі `plugin.yaml` (на верхньому рівні): + +```yaml +downloaders: +- command: "bin/mydownloader" + protocols: + - "myprotocol" + - "myprotocols" +``` + +Якщо такий втулок встановлений, Helm може взаємодіяти з репозиторієм, використовуючи вказану схему протоколу, викликавши `command`. Спеціальний репозиторій слід додати так само як і звичайні: `helm repo add favorite myprotocol://example.com/`. Правила для спеціальних репозиторіїв такі ж, як і для звичайних: Helm повинен бути здатен завантажити файл `index.yaml`, щоб виявити та зберегти список доступних чартів. + +Визначена команда буде викликана за схемою: `command certFile keyFile caFile full-URL`. Облікові відомості SSL беруться з визначення репозиторію, що зберігається в `$HELM_REPOSITORY_CONFIG` (тобто `$HELM_CONFIG_HOME/repositories.yaml`). Очікується, що команда завантажувача виведе сирий контент на stdout і повідомить про помилки на stderr. + +Команда завантажувача також підтримує підкоманди або аргументи, що дозволяє, наприклад, вказати `bin/mydownloader subcommand -d` у `plugin.yaml`. Це корисно, якщо ви хочете використовувати один і той же виконуваний файл для основної команди втулка та команди завантажувача, але з різною підкомандою для кожної. + +## Змінні середовища {#environment-variables} + +Коли Helm виконує втулок, він передає зовнішнє середовище втулку та також вбудовує деякі додаткові змінні середовища. + +Змінні, такі як `KUBECONFIG`, встановлюються для втулка, якщо вони встановлені у зовнішньому середовищі. + +Гарантовано будуть встановлені такі змінні: + +- `HELM_PLUGINS`: Шлях до теки втулків. +- `HELM_PLUGIN_NAME`: Імʼя втулка, яке використовується при виклику через `helm`. Тобто `helm myplug` матиме коротке імʼя `myplug`. +- `HELM_PLUGIN_DIR`: Тека, що містить втулок. +- `HELM_BIN`: Шлях до команди `helm` (як виконана користувачем). +- `HELM_DEBUG`: Вказує, чи був встановлений прапорець налагодження. +- `HELM_REGISTRY_CONFIG`: Місце для конфігурації реєстру (якщо використовується). Зазначте, що використання Helm з реєстрами є експериментальною функцією. +- `HELM_REPOSITORY_CACHE`: Шлях до кеш-файлів репозиторіїв. +- `HELM_REPOSITORY_CONFIG`: Шлях до файлу конфігурації репозиторію. +- `HELM_NAMESPACE`: Простір імен, вказаний команді `helm` (зазвичай за допомогою прапорця `-n`). +- `HELM_KUBECONTEXT`: Назва контексту конфігурації Kubernetes, наданого команді `helm`. + +Крім того, якщо конфігураційний файл Kubernetes був явно вказаний, він буде встановлений як змінна `KUBECONFIG`. + +## Примітка про парсинг прапорців {#note-on-flag-parsing} + +При виконанні втулка Helm буде розбирати глобальні прапорці для власного використання. Жоден з цих пропорців не передається втулку. + +- `--debug`: Якщо цей прапорець вказаний, `$HELM_DEBUG` встановлюється в `1`. +- `--registry-config`: Це перетворюється в `$HELM_REGISTRY_CONFIG`. +- `--repository-cache`: Це перетворюється в `$HELM_REPOSITORY_CACHE`. +- `--repository-config`: Це перетворюється в `$HELM_REPOSITORY_CONFIG`. +- `--namespace` та `-n`: Це перетворюється в `$HELM_NAMESPACE`. +- `--kube-context`: Це перетворюється в `$HELM_KUBECONTEXT`. +- `--kubeconfig`: Це перетворюється в `$KUBECONFIG`. + +Втулки _повинні_ відображати текст довідки та виходити для `-h` та `--help`. У всіх інших випадках втулки можуть використовувати прапорці за потреби. + +## Надання автозавершення оболонки {#providing-shell-auto-completion} + +Починаючи з Helm 3.2, втулок може додатково підтримувати автозавершення оболонки як частину наявного механізму автозавершення Helm. + +### Статичне автозавершення {#static-auto-completion} + +Якщо втулок надає свої власні прапорці та/або підкоманди, він може сповістити Helm про них, маючи файл `completion.yaml`, розташований у кореневій теці втулка. Файл `completion.yaml` має форму: + +```yaml +name: +flags: +- +- +validArgs: +- +- +commands: + name: + flags: + - + - + validArgs: + - + - + commands: + +``` + +Примітки: +1. Усі секції є необовʼязковими, але їх слід надати, якщо треба. +1. Прапорці не повинні включати префікс `-` або `--`. +1. Як короткі, так і довгі прапорці можуть і повинні бути вказані. Короткий прапорець не потребує асоціації з відповідною довгою формою, але обидві форми слід перерахувати. +1. Прапорці не потрібно упорядковувати будь-яким чином, але їх слід перераховувати в правильному місці в ієрархії підкоманд файлу. +1. Глобальні прапорці Helm вже обробляються механізмом автозавершення Helm, тому втулкам не потрібно вказувати наступні прапорці `--debug`, `--namespace` або `-n`, `--kube-context`, і `--kubeconfig`, або будь-які інші глобальні прапорці. +1. Список `validArgs` надає статичний список можливих завершень для першого параметра після підкоманди. Можливо не завжди надати такий список заздалегідь (див. розділ [Динамічне завершення](#dynamic-completion) нижче), у цьому випадку розділ `validArgs` можна пропустити. + +Файл `completion.yaml` є повністю необовʼязковим. Якщо він не надається, Helm просто не буде надавати автозавершення оболонки для втулка (якщо не підтримується [Динамічне завершення](#dynamic-completion) втулком). Крім того, додавання файлу `completion.yaml` є сумісним з попередніми версіями та не вплине на поведінку втулка при використанні старіших версій Helm. + +Як приклад, для втулка [`fullstatus`](https://github.com/marckhouzam/helm-fullstatus), який не має підкоманд, але приймає ті ж прапорці, що й команда `helm status`, файл `completion.yaml` виглядає так: + +```yaml +name: fullstatus +flags: +- o +- output +- revision +``` + +Складніший приклад для втулка [`2to3`](https://github.com/helm/helm-2to3), має файл `completion.yaml` наступного вигляду: + +```yaml +name: 2to3 +commands: +- name: cleanup + flags: + - config-cleanup + - dry-run + - l + - label + - release-cleanup + - s + - release-storage + - tiller-cleanup + - t + - tiller-ns + - tiller-out-cluster +- name: convert + flags: + - delete-v2-releases + - dry-run + - l + - label + - s + - release-storage + - release-versions-max + - t + - tiller-ns + - tiller-out-cluster +- name: move + commands: + - name: config + flags: + - dry-run +``` + +### Динамічне автозавершення {#dynamic-completion} + +Починаючи з Helm 3.2, втулки можуть надавати динамічне автозавершення оболонки. Динамічне автозавершення забезпечує завершення значень параметрів або прапорців, які не можуть бути визначені заздалегідь. Наприклад, завершення імен Helm релізів, які наразі доступні в кластері. + +Щоб втулок підтримував динамічне автозавершення, він повинен надати **виконуваний** файл з назвою `plugin.complete` у своїй кореневій теці. Коли скрипт автозавершення Helm потребує динамічного завершення для втулка, він виконає файл `plugin.complete`, передаючи йому командний рядок, який потрібно завершити. Виконуваний файл `plugin.complete` повинен містити логіку для визначення правильних варіантів завершення та виводити їх на стандартний вихід, щоб їх можна було спожити скриптом автозавершення Helm. + +Файл `plugin.complete` є повністю необовʼязковим. Якщо він не надається, Helm просто не буде надавати динамічне автозавершення для втулка. Крім того, додавання файлу `plugin.complete` є сумісним з попередніми версіями та не вплине на поведінку втулка при використанні старіших версій Helm. + +Вихідний результат скрипту `plugin.complete` повинен бути списком, розділеним новими рядками, наприклад: + +```none +rel1 +rel2 +rel3 +``` + +Коли `plugin.complete` викликаний, середовище втулка встановлено так само, як і при виклику основного скрипту втулка. Отже, змінні `$HELM_NAMESPACE`, `$HELM_KUBECONTEXT` та всі інші змінні втулка вже будуть встановлені, а відповідні глобальні прапорці будуть видалені. + +Файл `plugin.complete` може бути будь-якої виконуваної форми; це може бути shell-скрипт, програма на Go або будь-яка інша програма, яку Helm може виконати. Файл `plugin.complete` _**повинен**_ мати права на виконання для користувача. Файл `plugin.complete` _**повинен**_ завершитися з кодом успіху (значення 0). + +У деяких випадках динамічне завершення вимагатиме отримання інформації з кластера Kubernetes. Наприклад, втулок `helm fullstatus` потребує імені релізу як вводу. У втулку `fullstatus`, щоб скрипт `plugin.complete` надав завершення для поточних імен релізів, він може просто виконати `helm list -q` і вивести результат. + +Якщо ви бажаєте використовувати один і той же виконуваний файл для виконання втулка та для завершення втулка, скрипт `plugin.complete` може викликати основний виконуваний файл втулка з певним спеціальним параметром або прапорцем; коли основний виконуваний файл втулка виявляє спеціальний параметр або прапорець, він буде знати, що потрібно виконати завершення. У нашому прикладі `plugin.complete` може бути реалізований так: + +```sh +#!/usr/bin/env sh + +# "$@" є всім командним рядком, який потребує завершення. +# Важливо використовувати подвійні лапки в змінній "$@", щоб зберегти можливий пустий останній параметр. +$HELM_PLUGIN_DIR/status.sh --complete "$@" +``` + +Справжній скрипт втулка `fullstatus` (`status.sh`) повинен тоді шукати прапорець `--complete` і, якщо знайде його, вивести правильні завершення. + +### Поради та підказки {#tips-and-tricks} + +1. Оболонка автоматично відфільтровує варіанти завершення, які не відповідають введенню користувача. Отже, втулок може повернути всі відповідні завершення без видалення тих, які не відповідають введенню користувача. Наприклад, якщо командний рядок `helm fullstatus ngin`, скрипт `plugin.complete` може вивести _всі_ імена релізів (з простору імен `default`), а не лише ті, що починаються з `ngin`; оболонка зберігає лише ті, що починаються з `ngin`. +2. Щоб спростити підтримку динамічного завершення, особливо якщо у вас складний втулок, ви можете налаштувати скрипт `plugin.complete`, щоб він викликав основний скрипт втулка і запитував варіанти завершення. Дивіться розділ [Динамічне завершення](#dynamic-completion) вище для прикладу. +3. Для налагодження динамічного завершення та файлу `plugin.complete` можна виконати наступне, щоб побачити результати завершення: + - `helm __complete `. Наприклад: + - `helm __complete fullstatus --output js`, + - `helm __complete fullstatus -o json ""` diff --git a/content/uk/docs/topics/provenance.md b/content/uk/docs/topics/provenance.md new file mode 100644 index 000000000..95af76416 --- /dev/null +++ b/content/uk/docs/topics/provenance.md @@ -0,0 +1,225 @@ +--- +title: "Підтвердження походження та цілісності в Helm" +description: "Описує, як перевірити цілісність та походження чарту." +weight: 5 +--- + +Helm має інструменти підтвердження походження, які допомагають користувачам чартів перевіряти цілісність та походження пакета. Використовуючи інструменти на основі PKI, GnuPG та відомих менеджерів пакетів, Helm може створювати та перевіряти підписані файли. + +## Огляд {#overview} + +Цілісність встановлюється шляхом порівняння чарту з записом про походження. Записи про походження зберігаються у _файлах походження_, які зберігаються поряд з упакованим чартом. Наприклад, якщо чарти називаються `myapp-1.2.3.tgz`, то файл походження буде `myapp-1.2.3.tgz.prov`. + +Файли походження генеруються під час пакування (`helm package --sign ...`) і можуть бути перевірені кількома командами, зокрема `helm install --verify`. + +## Робочий процес {#the-workflow} + +Цей розділ описує можливий робочий процес ефективного використання даних походження. + +Передумови: + +- Дійсна пара ключів PGP у бінарному (не ASCII-зашифрованому) форматі +- Інструмент командного рядка `helm` +- Інструменти командного рядка GnuPG (необов’язково) +- Інструменти командного рядка Keybase (необов’язково) + +**ПРИМІТКА:** Якщо ваш приватний ключ PGP має парольну фразу, вам буде запропоновано ввести її для будь-яких команд, які підтримують опцію `--sign`. + +Створення нового чарту виконується так само як і раніше: + +```console +$ helm create mychart +Creating mychart +``` + +Коли ви готові до пакування, додайте прапорець `--sign` до команди `helm package`. Також вкажіть ім’я, під яким відомий ключ підпису, і вʼязку ключів, що містить відповідний приватний ключ: + +```console +$ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart +``` + +**Примітка:** Значення аргументу `--key` повинно бути субрядком бажаного `uid` ключа (виведеного командою `gpg --list-keys`), наприклад імʼя або електронна пошта. **Відбиток _не може_ бути використаний.** + +**ПОРАДА:** Для користувачів GnuPG ваша секретна вʼязка ключів знаходиться в `~/.gnupg/secring.gpg`. Ви можете використовувати команду `gpg --list-secret-keys`, щоб переглянути наявні ключі. + +**Попередження:** у GnuPG версії 2 ваша секретна вʼязка ключів зберігається у новому форматі `kbx` стандартно у `~/.gnupg/pubring.kbx`. Будь ласка, використовуйте такі команди, щоб перетворити свою вʼязку ключів у старий формат gpg: + +```console +$ gpg --export >~/.gnupg/pubring.gpg +$ gpg --export-secret-keys >~/.gnupg/secring.gpg +``` + +На цьому етапі ви повинні побачити як `mychart-0.1.0.tgz`, так і `mychart-0.1.0.tgz.prov`. Обидва файли зрештою мають бути завантажені у ваш бажаний репозиторій чартів. + +Ви можете перевірити чарт за допомогою команди `helm verify`: + +```console +$ helm verify mychart-0.1.0.tgz +``` + +Приклад невдалої перевірки: + +```console +$ helm verify topchart-0.1.0.tgz +Error: sha256 сума не співпадає для topchart-0.1.0.tgz: "sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7" != "sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a" +``` + +Щоб перевірити під час встановлення, використовуйте прапорець `--verify`. + +```console +$ helm install --generate-name --verify mychart-0.1.0.tgz +``` + +Якщо вʼязка ключів, що містить публічний ключ, асоційований із підписаним чартом, не знаходиться в стандартному місці, можливо, вам доведеться вказати шлях до вʼязки ключів за допомогою `--keyring PATH`, як у прикладі з `helm package`. + +Якщо перевірка не вдалася, встановлення буде перервано ще до того, як чарт буде навіть оброблено. + +### Використання облікових даних Keybase.io {#using-keybase-io-credentials} + +Сервіс [Keybase.io](https://keybase.io) спрощує створення ланцюга довіри для криптографічної ідентичності. Облікові дані Keybase можуть бути використані для підписання чартів. + +Передумови: + +- Налаштований обліковий запис Keybase.io +- Встановлений локально GnuPG +- Встановлений локально CLI для Keybase + +#### Підписання пакетів {#signing-packages} + +Першим кроком є імпорт ваших ключів Keybase у вашу локальну вʼязку ключів GnuPG: + +```console +$ keybase pgp export -s | gpg --import +``` + +Це перетворить ваш ключ Keybase у формат OpenPGP і потім імпортує його локально у файл `~/.gnupg/secring.gpg`. + +Ви можете перевірити це, виконавши команду `gpg --list-secret-keys`. + +```console +$ gpg --list-secret-keys +/Users/mattbutcher/.gnupg/secring.gpg +------------------------------------- +sec 2048R/1FC18762 2016-07-25 +uidtechnosophos (keybase.io/technosophos) +ssb 2048R/D125E546 2016-07-25 +``` + +Зверніть увагу, що ваш секретний ключ матиме рядок ідентифікатора: + +```none +technosophos (keybase.io/technosophos) +``` + +Це повне імʼя вашого ключа. + +Далі, ви можете упакувати та підписати чарт за допомогою `helm package`. Переконайтеся, що ви використовуєте хоча б частину цього рядка назви у `--key`. + +```console +$ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart +``` + +Як результат, команда `package` має створити як файл `.tgz`, так і файл `.tgz.prov`. + +#### Перевірка пакетів {#verifying-packages} + +Ви також можете використовувати аналогічний метод для перевірки чарту, підписаного ключем Keybase іншого користувача. Наприклад, ви хочете перевірити пакет, підписаний `keybase.io/technosophos`. Для цього скористайтесь інструментом `keybase`: + +```console +$ keybase follow technosophos +$ keybase pgp pull +``` + +Перша команда відстежує користувача `technosophos`. Далі, команда `keybase pgp pull` завантажує ключі OpenPGP всіх облікових записів, які ви відстежуєте, розміщуючи їх у вашій вʼязці ключів GnuPG (`~/.gnupg/pubring.gpg`). + +На цьому етапі ви можете використовувати `helm verify` або будь-які команди з прапорцем `--verify`: + +```console +$ helm verify somechart-1.2.3.tgz +``` + +### Причини, через які чарт може не пройти перевірку {#reasons-a-chart-may-not-verify} + +Це поширені причини невдач. + +- Файл `.prov` відсутній або пошкоджений. Це вказує на те, що щось неправильно налаштовано або що початковий підтримувач не створив файл походження. +- Ключ, використаний для підписання файлу, не знаходиться у вашій вʼязці ключів. Це означає, що особа, яка підписала чарт, не є тією, кому ви вже довіряєте. +- Перевірка файлу `.prov` не пройшла. Це вказує на те, що щось не так із чартом або даними походження. +- Хеші файлів у файлі походження не збігаються з хешем архівного файлу. Це свідчить про те, що архів було підроблено. + +Якщо перевірка не пройшла, це є підставою для недовіри до пакета. + +## Файл походження {#the-provenance-file} + +Файл походження містить YAML файл чарту та кілька елементів верифікаційної інформації. Файли походження розроблені для автоматичної генерації. + +Додаються наступні частини даних походження: + +- Файл чарту (`Chart.yaml`) включається для зручного перегляду вмісту чарту як людьми, так і інструментами. +- Підпис (SHA256, аналогічно до Docker) пакету чарту (файл `.tgz`) включається та може бути використаний для перевірки цілісності пакета чарту. +- Весь зміст підписується за допомогою алгоритму OpenPGP (див. [Keybase.io](https://keybase.io) для спрощення процесу криптографічного підпису та перевірки). + +Це надає користувачам такі гарантії: + +- Пакет не було підроблено (перевірка контрольної суми пакета `.tgz`). +- Особа, яка випустила цей пакет, є відомою (через підпис GnuPG/PGP). + +Формат файлу виглядає приблизно так: + +```none +Hash: SHA512 + +apiVersion: v2 +appVersion: "1.16.0" +description: Sample chart +name: mychart +type: application +version: 0.1.0 + +... +files: + mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92 +-----BEGIN PGP SIGNATURE----- + +wsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd +nvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI +mYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2 +cR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi +hZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D +qtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8= +=aHfz +-----END PGP SIGNATURE----- +``` + +Зверніть увагу, що розділ YAML містить два документи (розділені `...\n`). Перший файл — це вміст `Chart.yaml`. Другий — це контрольні суми, map імен файлів та SHA-256 дайджестів вмісту цього файлу на момент пакування. + +Блок підпису є стандартним підписом PGP, який забезпечує [стійкість до підробок](https://www.rossde.com/PGP/pgp_signatures.html). + +## Репозиторії чартів {#chart-repositories} + +Репозиторії чартів слугують як централізоване зібрання чартів Helm. + +Репозиторії чартів повинні забезпечувати можливість надання файлів походження через HTTP за певним запитом і повинні робити їх доступними за тим же шляхом URI, що й чарт. + +Наприклад, якщо базовий URL для пакета — `https://example.com/charts/mychart-1.2.3.tgz`, файл походження, якщо він існує, ПОВИНЕН бути доступний за адресою `https://example.com/charts/mychart-1.2.3.tgz.prov`. + +З погляду кінцевого користувача, команда `helm install --verify myrepo/mychart-1.2.3` повинна призвести до завантаження як чарту, так і файлу походження без додаткових налаштувань або дій користувача. + +### Підписи в OCI-реєстрах {#signatures-in-oci-based-registries} + +При публікації чартів до [реєстру на основі OCI]({{< ref "registries.md" >}}), втулок [`helm-sigstore`](https://github.com/sigstore/helm-sigstore/) може бути використаний для публікації файлів походження у [sigstore](https://sigstore.dev/). Як описано у [документації](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md), процес створення файлів походження та підписання за допомогою ключа GPG є загальним, але команда `helm sigstore upload` може бути використана для публікації файлів походження до незмінного прозорого логу. + +## Встановлення авторитету та автентичності {#establishing-authority-and-authenticity} + +У системах ланцюга довіри важливо мати можливість встановити авторитет підписувача. Іншими словами, система залежить від того, що ви довіряєте особі, яка підписала чарт. Це означає, що вам потрібно довіряти публічному ключу підписувача. + +Одне з проєктних рішень щодо Helm полягало в тому, що проєкт Helm не буде вставляти себе в ланцюжок довіри як обовʼязкову сторону. Ми не хочемо бути "центром сертифікації" для всіх підписувачів чартів. Замість цього ми дуже підтримуємо децентралізовану модель, що є частиною причини, чому ми вибрали OpenPGP як нашу основну технологію. Тому, коли йдеться про встановлення авторитету, ми залишили цей крок більш-менш невизначеним у Helm 2 (рішення було перенесене у Helm 3). + +Проте, у нас є кілька порад і рекомендацій для тих, хто зацікавлений у використанні системи походження: + +- Платформа [Keybase](https://keybase.io) надає публічне централізоване сховище для інформації про довіру. + - Ви можете використовувати Keybase для зберігання своїх ключів або отримання публічних ключів інших. + - Keybase також має чудову документацію. + - Хоча ми не тестували це, функція "захищений вебсайт" Keybase може бути використана для сервісу чартів Helm. + - Основна ідея полягає в тому, що офіційний "рецензент чартів" підписує чарти своїм ключем, а отриманий файл походження потім завантажується в репозиторій чартів. + - Було зроблено деякі роботи над ідеєю, що список дійсних підписуючих ключів може бути включений у файл `index.yaml` репозиторію. diff --git a/content/uk/docs/topics/rbac.md b/content/uk/docs/topics/rbac.md new file mode 100644 index 000000000..83160ce0b --- /dev/null +++ b/content/uk/docs/topics/rbac.md @@ -0,0 +1,148 @@ +--- +title: "Контроль доступу на основі ролей" +description: "Пояснює, як Helm взаємодіє з контролем доступу на основі ролей Kubernetes." +weight: 11 +--- + +У Kubernetes надання ролей користувачу або службовому обліковому запису, специфічному для застосунку, є найкращою практикою для забезпечення роботи вашого застосунку в межах, які ви визначили. Дізнайтеся більше про дозволи службових облікових записів [в офіційній документації Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions). + +З версії Kubernetes 1.6 контроль доступу на основі ролей (RBAC) стандартно увімкнено. RBAC дозволяє вам визначати, які типи дій дозволені залежно від користувача та його ролі у вашій організації. + +З RBAC ви можете: + +- надавати привілейовані операції (створення ресурсів на рівні кластеру, таких як нові ролі) адміністраторам +- обмежити можливість користувача створювати ресурси (pods, persistent volumes, deployments) до певних просторів імен або в межах кластера (квоти ресурсів, ролі, визначення власних ресурсів) +- обмежити можливість користувача переглядати ресурси або в певних просторах імен, або в межах кластера. + +Цей посібник призначений для адміністраторів, які хочуть обмежити область доступу користувача до API Kubernetes. + +## Управління обліковими записами користувачів {#managing-user-accounts} + +Усі кластери Kubernetes мають дві категорії користувачів: службові облікові записи, керовані Kubernetes, та звичайні користувачі. + +Передбачається що звичайними користувачами керує зовнішній незалежний сервіс. Це може бути адміністратор, який розподіляє приватні ключі, сховище користувачів, таке як Keystone або Google Accounts, або навіть файл зі списком імен користувачів та паролів. У цьому відношенні Kubernetes не має обʼєктів, які представляють звичайні облікові записи користувачів. Звичайних користувачів не можна додати до кластера через API-запит. + +На відміну від цього, службові облікові записи є користувачами, керованими API Kubernetes. Вони привʼязані до певних просторів імен і створюються автоматично API сервером або вручну через API-запити. службові Облікові записи привʼязані до набору облікових даних, які зберігаються як Secrets і монтуються в podʼи, що дозволяє процесам всередині кластера спілкуватися з API Kubernetes. + +API-запити привʼязані або до звичайного користувача, або до облікового запису служби, або розглядаються як анонімні запити. Це означає, що кожен процес всередині або зовні кластера, від людини, що набирає `kubectl` на робочій станції, до kubelets на вузлах, до членів панелі управління, повинен пройти автентифікацію при здійсненні запитів до API сервера або бути розглянутим як анонімний користувач. + +## Roles, ClusterRoles, RoleBindings та ClusterRoleBindings {#roles-clusterroles-rolebindings-and-clusterrolebindings} + +У Kubernetes облікові записи користувачів і службові облікові записи можуть переглядати та редагувати лише ресурси, до яких їм надано доступ. Цей доступ надається за допомогою Roles і RoleBindings. Ролі та RoleBindings привʼязані до певного простору імен, надаючи користувачам можливість переглядати та/або редагувати ресурси в цьому просторі імен, до яких надає доступ Role. + +На рівні кластера ці обʼєкти називаються ClusterRoles і ClusterRoleBindings. Надаючи користувачу ClusterRole, ви надаєте їм доступ до перегляду та/або редагування ресурсів по всьому кластеру. Це також необхідно для перегляду та/або редагування ресурсів на рівні кластера (простори імен, квоти ресурсів, вузли). + +ClusterRoles можна привʼязати до певного простору імен через посилання в RoleBinding. `admin`, `edit` та `view` стандартні ClusterRoles часто використовуються таким чином. + +Ось кілька ClusterRoles, стандартно доступних у Kubernetes. Вони призначені для користувачів. До них відносяться суперкористувацькі ролі (`cluster-admin`) та ролі з більш детальним доступом (`admin`, `edit`, `view`). + +| Стандартна ClusterRole | Стандартна ClusterRoleBinding | Опис +|-------------------------|--------------------------------|------------- +| `cluster-admin` | Група `system:masters` | Дозволяє суперкористувацький доступ для виконання будь-якої дії над будь-яким ресурсом. При використанні в ClusterRoleBinding надає повний контроль над кожним ресурсом в кластері та у всіх просторах імен. При використанні в RoleBinding надає повний контроль над кожним ресурсом в просторі імен, що привʼязується до RoleBinding, включаючи сам простір імен. +| `admin` | Немає | Дозволяє адміністративний доступ, призначений для надання всередині простору імен за допомогою RoleBinding. Якщо використовується в RoleBinding, дозволяє читання/запис доступу до більшості ресурсів у просторі імен, включаючи можливість створювати ролі та RoleBindings всередині простору імен. Не дозволяє записувати доступ до квоти ресурсів або до самого простору імен. +| `edit` | Немає | Дозволяє читання/запис доступу до більшості обʼєктів у просторі імен. Не дозволяє переглядати або модифікувати ролі або RoleBindings. +| `view` | Немає | Дозволяє доступ лише для читання, щоб побачити більшість обʼєктів у просторі імен. Не дозволяє переглядати ролі або RoleBindings. Не дозволяє переглядати secrets, оскільки це є ескалацією доступу. + +## Обмеження доступу облікових записів користувачів за допомогою RBAC {#restricting-a-users-accont-s-access-using-rbac} + +Тепер, коли ми розуміємо основи контролю доступу на основі ролей, розглянемо, як адміністратор може обмежити область доступу користувача. + +### Приклад: Надання користувачу доступу для читання/запису в певного простору імен {#example-grnt-a-user-read-write-access-to-a-particular-namespace} + +Щоб обмежити доступ користувача до певного простору імен, можна використовувати роль `edit` або `admin`. Якщо ваші чарти створюють або взаємодіють з Roles і RoleBindings, ви захочете використовувати `admin` ClusterRole. + +Крім того, ви також можете створити RoleBinding з доступом `cluster-admin`. Надаючи користувачу доступ `cluster-admin` на рівні простору імен, ви надаєте повний контроль над кожним ресурсом у просторі імен, включаючи сам простір імен. + +Для цього прикладу ми створимо користувача з роллю `edit`. Спочатку створіть простір імен: + +```shell +$ kubectl create namespace foo +``` + +Тепер створіть RoleBinding у цьому просторі імен, надаючи користувачу роль `edit`. + +```shell +$ kubectl create rolebinding sam-edit + --clusterrole edit \​ + --user sam \​ + --namespace foo +``` + +### Приклад: Надання користувачу доступу для читання/запису на рівні кластера {#example-grant-a-user-read-write-access-at-the-cluster-scope} + +Якщо користувач хоче встановити чарт, який встановлює ресурси на рівні кластера (простори імен, ролі, визначення власних ресурсів тощо), їм знадобиться доступ для запису на рівні кластера. + +Для цього надайте користувачу доступ `admin` або `cluster-admin`. + +Надання користувачу доступу `cluster-admin` надає їм доступ до всіх ресурсів Kubernetes, включаючи доступ до вузлів з `kubectl drain` та інші адміністративні завдання. Рекомендується розглянути можливість надання користувачу доступу `admin`, або створити власну ClusterRole, адаптовану до їхніх потреб. + +```shell +$ kubectl create clusterrolebinding sam-view + --clusterrole view \​ + --user sam + +$ kubectl create clusterrolebinding sam-secret-reader + --clusterrole secret-reader \​ + --user sam +``` + +### Приклад: Надання користувачу доступу лише для читання до певного простору імен {#example-grant-a-user-read-only-access-to-a-particular-namespace} + +Ви могли помітити, що не існує ClusterRole, доступної для перегляду secrets. Роль `view` не надає користувачу доступ до Secrets через проблеми з ескалацією. Helm стандартно зберігає метадані релізів як Secrets. + +Щоб користувач міг виконати команду `helm list`, їм потрібно мати можливість читати ці секрети. Для цього ми створимо спеціальний `secret-reader` ClusterRole. + +Створіть файл `cluster-role-secret-reader.yaml` і напишіть наступний вміст у файл: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1​ +kind: ClusterRole​ +metadata:​ + name: secret-reader​ +rules:​ +- apiGroups: [""]​ + resources: ["secrets"]​ + verbs: ["get", "watch", "list"] +``` + +Потім створіть ClusterRole за допомогою: + +```shell +$ kubectl create -f clusterrole-secret-reader.yaml​ +``` + +Як тільки це буде зроблено, ми можемо надати користувачу доступ для читання до більшості ресурсів, а потім надати їм доступ до секретів: + +```shell +$ kubectl create namespace foo + +$ kubectl create rolebinding sam-view + --clusterrole view \​ + --user sam \​ + --namespace foo + +$ kubectl create rolebinding sam-secret-reader + --clusterrole secret-reader \​ + --user sam \​ + --namespace foo +``` + +### Приклад: Надання користувачу доступу лише для читання на рівні кластера {#example-grant-a-user-read-only-access-at-the-cluster-scope} + +В деяких випадках може бути корисно надати користувачу доступ на рівні кластера. Наприклад, якщо користувач хоче виконати команду `helm list --all-namespaces`, API вимагає, щоб користувач мав доступ для читання на рівні кластера. + +Для цього надайте користувачу як `view`, так і `secret-reader` доступ, як описано вище, але за допомогою ClusterRoleBinding. + +```shell +$ kubectl create clusterrolebinding sam-view + --clusterrole view \​ + --user sam + +$ kubectl create clusterrolebinding sam-secret-reader + --clusterrole secret-reader \​ + --user sam +``` + +## Додатково {#additional-thoughts} + +Вищезазначені приклади використовують стандартні ClusterRoles, надані Kubernetes. Для більш детального контролю над ресурсами, до яких користувачі мають доступ, ознайомтеся з [документацією Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) по створенню власних Roles і ClusterRoles. diff --git a/content/uk/docs/topics/registries.md b/content/uk/docs/topics/registries.md new file mode 100644 index 000000000..689c67fa7 --- /dev/null +++ b/content/uk/docs/topics/registries.md @@ -0,0 +1,233 @@ +--- +title: "Використання реєстрів на основі OCI" +description: "Описує, як використовувати OCI для розповсюдження чартів." +weight: 7 +--- + +Починаючи з Helm 3, ви можете використовувати реєстри контейнерів з підтримкою [OCI](https://www.opencontainers.org/) для зберігання та обміну пакетами чартів. Починаючи з Helm v3.8.0, підтримка OCI є стандартно увімкнено. + +## Підтримка OCI до v3.8.0 {#oci-support-prior-to-v3.8.0} + +Підтримка OCI перейшла з експериментального статусу в загальну доступність з Helm v3.8.0. У попередніх версіях Helm підтримка OCI працювала інакше. Якщо ви використовували підтримку OCI до Helm v3.8.0, важливо зрозуміти, що змінилося в Helm. + +### Увімкнення підтримки OCI до v3.8.0 {#enabling-oci-support-prior-to-v3.8.0} + +До Helm v3.8.0 підтримка OCI є *експериментальною* і має бути увімкнена вручну. + +Щоб увімкнути експериментальну підтримку OCI для версій Helm до v3.8.0, задайте `HELM_EXPERIMENTAL_OCI` у вашому середовищі. Наприклад: + +```console +export HELM_EXPERIMENTAL_OCI=1 +``` + +### Визнання застарілою функції OCI та зміни поведінки з v3.8.0 {#oci-deprecation-and-behavior-changes-with-v3.8.0} + +З виходом [Helm v3.8.0](https://github.com/helm/helm/releases/tag/v3.8.0) наступні функції та поведінка відрізняються від попередніх версій Helm: + +- При встановленні chart у залежностях як OCI, версію можна задати у вигляді діапазону, як і для інших залежностей. +- Теги SemVer, які містять інформацію про збірку, можна публікувати та використовувати. Реєстри OCI не підтримують `+` як символ теґу. Helm перетворює `+` на `_`, коли він зберігається як теґ. +- Команда `helm registry login` тепер дотримується тієї ж структури, що й Docker CLI для зберігання облікових даних. Те ж місце для конфігурації реєстру може бути передане як Helm, так і Docker CLI. + +### Визнання застарілою функції OCI та зміни поведінки з v3.7.0 + +Випуск [Helm v3.7.0](https://github.com/helm/helm/releases/tag/v3.7.0) включав реалізацію [HIP 6](https://github.com/helm/community/blob/main/hips/hip-0006.md) для підтримки OCI. Як результат, наступні функції та поведінка відрізняються від попередніх версій Helm: + +- Субкоманда `helm chart` була видалена. +- Кеш chart був видалений (немає `helm chart list` тощо). +- Посилання на реєстри OCI тепер завжди починаються з `oci://`. +- Базове імʼя посилання на реєстр має *завжди* відповідати імені chart. +- Тег посилання на реєстр має *завжди* відповідати семантичній версії chart (тобто без тегів `latest`). +- Тип медіа шару chart був змінений з `application/tar+gzip` на `application/vnd.cncf.helm.chart.content.v1.tar+gzip`. + +## Використання реєстру на основі OCI {#using-an-oci-based-registry} + +### Репозиторії Helm у реєстрах на основі OCI {#helm-repositories-in-oci-based-registries} + +[Репозиторій Helm]({{< ref "chart_repository.md" >}}) — це спосіб зберігання та розподілу упакованих Helm chart. Реєстр на основі OCI може містити нуль або більше репозиторіїв Helm, і кожен з цих репозиторіїв може містити нуль або більше упакованих Helm chart. + +### Використання послуг реєстрів {#use-hosted-registries} + +Існує кілька реєстрів контейнерів з підтримкою OCI, які ви можете використовувати для ваших Helm chart. Наприклад: + +- [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html) +- [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact) +- [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/) +- [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts) +- [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/) +- [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts) +- [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories) + +Щоб створити та налаштувати реєстр з підтримкою OCI, дотримуйтесь документації постачальника реєстру контейнерів на хостингу. + +**Примітка:** Ви можете запускати [Docker Registry](https://docs.docker.com/registry/deploying/) або [`zot`](https://github.com/project-zot/zot), які є реєстрами на основі OCI, на вашому компʼютері для розробки. Запуск реєстру на основі OCI на вашому компʼютері, де відбувається розробка, слід використовувати лише для тестування. + +### Використання sigstore для підписування чартів на основі OCI {#using-sigstore-to-sign-oci-charts} + +Втулок [`helm-sigstore`](https://github.com/sigstore/helm-sigstore) дозволяє використовувати [Sigstore](https://sigstore.dev/) для підписування Helm чартів тими ж інструментами, які використовуються для підписування контейнерних образів. Це є альтернативою [перевірки походження]({{< ref "provenance.md" >}}), що використовує GPD, яке підтримується класичними [репозиторіями чартів]({{< ref "chart_repository.md" >}}). + +Для отримання додаткової інформації про використання втулка `helm sigstore`, дивіться [документацію цього проєкту](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md). + +## Команди для роботи з реєстрами {#commands-for-working-with-registries} + +### Команда `registry` {#the-registry-subcommand} + +#### `login` + +Вхід до реєстру (зручний варіант з ручним введенням пароля) + +```console +$ helm registry login -u myuser localhost:5000 +Password: +Login succeeded +``` + +#### `logout` + +Вийти з реєстру + +```console +$ helm registry logout localhost:5000 +Logout succeeded +``` + +### Команда `push` {#the-push-subcommand} + +Завантажити чарт до реєстру на основі OCI: + +```console +$ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts +Pushed: localhost:5000/helm-charts/mychart:0.1.0 +Digest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723 +``` + +Команда `push` може використовуватися тільки для `.tgz` файлів, створених заздалегідь за допомогою `helm package`. + +При використанні `helm push` для завантаження чарту до реєстру OCI, посилання має починатися з `oci://` і не повинно містити базове імʼя або теґ. + +Базове імʼя посилання на реєстр визначається з імені чарту, а теґ визначається з семантичної версії чарту. Це наразі є строгими вимогами. + +Деякі реєстри вимагають, щоб репозиторій та/або простір імен (якщо вказано) були створені заздалегідь. В іншому випадку під час операції `helm push` буде згенеровано помилку. + +Якщо ви створили [файл походження]({{< ref "provenance.md" >}}) (`.prov`), і він присутній поруч з файлом чарту `.tgz`, він автоматично буде завантажено до реєстру при виконанні `push`. Це призводить до появи додаткового шару у [маніфесті Helm chart](#helm-chart-manifest). + +Користувачі втулка [helm-push](https://github.com/chartmuseum/helm-push) (для завантаження chart до [ChartMuseum]({{< ref "chart_repository.md" >}}#chartmuseum-repository-server)) можуть стикатися з проблемами, оскільки втулок конфліктує з новою вбудованою командою `push`. З версії v0.10.0 втулок був перейменований на `cm-push`. + +### Інші підкоманди {#other-subcommands} + +Підтримка протоколу `oci://` також доступна в різних інших підкомандах. Ось повний список: + +- `helm pull` +- `helm show ` +- `helm template` +- `helm install` +- `helm upgrade` + +Базове імʼя (імʼя chart) посилання на реєстр *включено* для будь-якого типу дії, що стосується завантаження chart (на відміну від `helm push`, де воно пропущене). + +Ось кілька прикладів використання наведених вище підкоманд для chart на основі OCI: + +```shell +$ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0 +Pulled: localhost:5000/helm-charts/mychart:0.1.0 +Digest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff + +$ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0 +apiVersion: v2 +appVersion: 1.16.0 +description: A Helm chart for Kubernetes +name: mychart +... + +$ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 +--- +# Source: mychart/templates/serviceaccount.yaml +apiVersion: v1 +kind: ServiceAccount +... + +$ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 +NAME: myrelease +LAST DEPLOYED: Wed Oct 27 15:11:40 2021 +NAMESPACE: default +STATUS: deployed +REVISION: 1 +NOTES: +... + +$ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0 +Release "myrelease" has been upgraded. Happy Helming! +NAME: myrelease +LAST DEPLOYED: Wed Oct 27 15:12:05 2021 +NAMESPACE: default +STATUS: deployed +REVISION: 2 +NOTES: +... +``` + +## Вказання залежностей {#specifying-dependencies} + +Залежності chart можна завантажити з реєстру за допомогою підкоманди `dependency update`. + +`repository` для певного запису в `Chart.yaml` вказується як посилання на реєстр без базового імені: + +```yaml +dependencies: + - name: mychart + version: "2.7.0" + repository: "oci://localhost:5000/myrepo" +``` + +Це завантажить `oci://localhost:5000/myrepo/mychart:2.7.0`, коли виконується `dependency update`. + +## Маніфест Helm чарту {#helm-chart-manifest} + +Приклад маніфесту Helm чарту, представленого в реєстрі (зверніть увагу на поля `mediaType`): + +```json +{ + "schemaVersion": 2, + "config": { + "mediaType": "application/vnd.cncf.helm.config.v1+json", + "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", + "size": 117 + }, + "layers": [ + { + "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", + "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", + "size": 2487 + } + ] +} +``` + +Наступний приклад містить [файл походження]({{< ref "provenance.md" >}}) (зверніть увагу на додатковий шар): + +```json +{ + "schemaVersion": 2, + "config": { + "mediaType": "application/vnd.cncf.helm.config.v1+json", + "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", + "size": 117 + }, + "layers": [ + { + "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", + "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", + "size": 2487 + }, + { + "mediaType": "application/vnd.cncf.helm.chart.provenance.v1.prov", + "digest": "sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a", + "size": 643 + } + ] +} +``` + +## Міграція з репозиторіїв чартів + +Міграція з класичних [репозиторіїв чартів]({{< ref "chart_repository.md" >}}) +(репозиторії на основі index.yaml) є простою: використовуйте `helm pull`, а потім `helm push`, щоб завантажити отримані файли `.tgz` до реєстру. diff --git a/content/uk/docs/topics/release_policy.md b/content/uk/docs/topics/release_policy.md new file mode 100644 index 000000000..29cbe5028 --- /dev/null +++ b/content/uk/docs/topics/release_policy.md @@ -0,0 +1,45 @@ +--- +title: "Політика графіку випусків" +description: "Описує політику графіку випусків Helm." +weight: 17 +--- + +Для зручності користувачів Helm визначає та оголошує дати випусків заздалегідь. Цей документ описує політику, що регулює графік випусків Helm. + +## Календар випусків {#release-calendar} + +Публічний календар із запланованими випусками Helm можна знайти [тут](https://helm.sh/calendar/release). + +## Семантичне версіювання {#semantic-versioning} + +Версії Helm виражаються як `x.y.z`, де `x` — це основна версія, `y` — мінорна версія, а `z` — випуск патча, відповідно до термінології [семантичного версіювання](https://semver.org/spec/v2.0.0.html). + +## Випуски патчів {#patch-releases} + +Випуски патчів надають користувачам виправлення помилок і виправлення з безпеки. Вони не містять нових функцій. + +Новий випуск патча, що стосується останньої мінорної/основної версії, зазвичай здійснюється один раз на місяць, у другу середу кожного місяця. + +Випуск патча для виправлення пріоритетної регресії або проблеми безпеки може бути здійснений за потребою. + +Випуск патча буде скасовано з будь-якої з наступних причин: + +- якщо з моменту попереднього випуску не було додано нового вмісту; +- якщо дата випуску патча припадає на тиждень до першого реліз-кандидата (RC1) майбутнього мінорного випуску; +- якщо дата випуску патча припадає на чотири тижні після мінорного випуску. + +## Мінорні випуски {#minor-releases} + +Мінорні випуски містять виправлення безпеки та помилок, а також нові функції. Вони є зворотно сумісними з API та використанням CLI. + +Щоб узгодитися з випусками Kubernetes, мінорний випуск Helm здійснюється кожні 4 місяці (3 випуски на рік). + +Додаткові мінорні випуски можуть здійснюватися за потреби, але це не вплине на графік оголошеного майбутнього випуску, якщо до нього не залишилося менше 7 днів. + +Одночасно з публікацією випуску буде оголошено дату наступного мінорного випуску, яка буде опублікована на головній вебсторінці Helm. + +## Основні випуски + +Основні випуски містять зміни, що порушують сумісність. Такі випуски є рідкісними, але іноді необхідні для подальшого важливого розвитку Helm. + +Основні випуски можуть бути складними для планування. З огляду на це, остаточна дата випуску буде вибрана та оголошена лише після того, як буде доступна перша бета-версія такого випуску. diff --git a/content/uk/docs/topics/v2_v3_migration.md b/content/uk/docs/topics/v2_v3_migration.md new file mode 100644 index 000000000..bdc80d87a --- /dev/null +++ b/content/uk/docs/topics/v2_v3_migration.md @@ -0,0 +1,83 @@ +--- +title: "Міграція з Helm v2 на Helm v3" +description: "Дізнайтеся, як мігрувати з Helm v2 на v3." +weight: 13 +--- + +Цей посібник показує, як мігрувати з Helm v2 на Helm v3. Для цього необхідно мати встановлений Helm v2, який управляє релізами в одному або кількох кластерах. + +## Огляд змін у Helm 3 {#overview-of-helm-3-changes} + +Повний список змін між Helm 2 і 3 задокументований у [розділі FAQ](https://v3.helm.sh/docs/faq/#changes-since-helm-2). Ось деякі з основних змін, про які слід знати перед і під час міграції: + +1. Видалення Tiller: + - Заміна архітектури клієнт/сервер на клієнт/бібліотека (тільки бінарний файл `helm`) + - Безпека тепер залежить від користувача (делеговано безпеці кластера Kubernetes) + - Релізи тепер зберігаються як секрети в кластері, а метадані обʼєкта релізу змінилися + - Релізи зберігаються на основі простору імен релізу, а не в просторі імен Tiller + +2. Оновлено репозиторій чартів: + - `helm search` тепер підтримує як локальні запити в репозиторії, так і запити до Artifact Hub + +3. Зміни у `apiVersion` чарту: + - Динамічно підключені залежності чартів переміщені до `Chart.yaml` (`requirements.yaml` видалено і requirements --> dependencies) + - Тепер можна додавати бібліотечні чарти (helper/common charts) як динамічно підключені залежності + - Чарти мають поле метаданих `type`, яке визначає, чи є чарт `application` чи `library`. Стандартно це `application`, що означає, що його можна рендерити та інсталювати + - Чарти Helm 2 (apiVersion=v1) все ще можна встановлювати + +4. Додано специфікацію теки XDG: + - Домівка Helm видалена і замінена специфікацією теки XDG для зберігання конфігураційних файлів + - Більше не потрібно ініціалізувати Helm + - `helm init` і `helm home` видалені + +5. Додаткові зміни: + - Установка/налаштування Helm спрощено: + - Тільки клієнт Helm (бінарний файл helm) (без Tiller) + - Парадигма "run-as-is" + - `local` або `stable` репозиторії стандартно не налаштовані + - Хук `crd-install` видалено і замінено на теку `crds` у чарті, де всі CRD, визначені в ній, будуть встановлені перед будь-яким рендерингом чарту + - Значення анотації хука `test-failure` видалене, а `test-success` застаріле. Використовуйте `test` замість + - Команди видалені/замінені/додані: + - delete --> uninstall : стандартно видаляє всю історію релізів за (раніше потрібно було `--purge`) + - fetch --> pull + - home (видалено) + - init (видалено) + - install: вимагає імʼя релізу або аргумент `--generate-name` + - inspect --> show + - reset (видалено) + - serve (видалено) + - template: аргумент `-x`/`--execute` перейменовано на `-s`/`--show-only` + - upgrade: Додано аргумент `--history-max`, який обмежує максимальну кількість збережених ревізій на реліз (0 - без обмежень) + - Бібліотека Helm 3 на Go зазнала значних змін і несумісна з бібліотекою Helm 2 + - Бінарники Helm тепер розміщені на `get.helm.sh` + +## Сценарії міграції {#migration-use-cases} + +Сценарії міграції такі: + +1. Helm v2 і v3 управляють одним кластером: + - Цей сценарій рекомендується тільки якщо ви плануєте поступове видалення Helm v2 і не потребуєте v3 для управління жодними релізами, розгорнутими v2. Усі нові релізи, що розгортаються, повинні виконуватися v3, а наявні релізи, розгорнуті v2, оновлюються/видаляються тільки v2 + - Helm v2 і v3 можуть без проблем управляти одним кластером. Версії Helm можуть бути встановлені на одній або окремих системах + - Якщо ви встановлюєте Helm v3 на тій же системі, вам потрібно виконати додатковий крок, щоб обидві версії клієнтів могли співіснувати до того часу, поки ви не будете готові видалити клієнта Helm v2. Перейменуйте або помістіть бінарний файл Helm v3 в іншу теку, щоб уникнути конфліктів + - Інакше немає конфліктів між обома версіями через наступні відмінності: + - зберігання релізів (історії) v2 і v3 є незалежним один від одного. Зміни включають ресурс Kubernetes для зберігання та метадані обʼєкта релізу, що містяться в ресурсі. Релізи також будуть в просторі імен користувача, а не в просторі імен Tiller (наприклад, простір імен Tiller стандартно kube-system v2). v2 використовує "ConfigMaps" або "Secrets" у просторі імен Tiller і `TILLER` ownership. v3 використовує "Secrets" у просторі імен користувача і `helm` ownership. Релізи є інкрементальними в обох версіях v2 і v3 + - Єдина проблема може бути, якщо ресурси кластера Kubernetes (наприклад, `clusterroles.rbac`) визначені в чарті. Розгортання v3 тоді буде невдалим, навіть якщо унікальне в просторі імен, оскільки ресурси будуть конфліктувати + - Конфігурація v3 більше не використовує `$HELM_HOME` і використовує специфікацію теки XDG замість цього. Вона також створюється на льоту за необхідності. Тому вона є незалежною від конфігурації v2. Це стосується тільки випадків, коли обидві версії встановлені на одній системі + +2. Міграція з Helm v2 на Helm v3: + - Цей сценарій застосовується, коли ви хочете, щоб Helm v3 управляв наявними релізами Helm v2 + - Слід зазначити, що клієнт Helm v2: + - може управляти одним або кількома кластерами Kubernetes + - може підключатися до одного або кількох екземплярів Tiller для кластера + - Це означає, що ви повинні бути обізнані про це під час міграції, оскільки релізи розгортаються в кластери Tiller і його простір імен. Тому ви повинні бути обізнані про міграцію для кожного кластера та кожного екземпляра Tiller, який управляється екземпляром клієнта Helm v2 + - Рекомендований шлях міграції даних такий: + 1. Резервне копіювання даних v2 + 2. Міграція конфігурації Helm v2 + 3. Міграція релізів Helm v2 + 4. Коли ви впевнені, що Helm v3 управляє всіма даними Helm v2 (для всіх кластерів і екземплярів Tiller клієнта Helm v2) як очікується, очистіть дані Helm v2 + - Процес міграції автоматизований втулком Helm v3 [2to3](https://github.com/helm/helm-2to3) + +## Посилання {#references} + + - Втулок Helm v3 [2to3](https://github.com/helm/helm-2to3) + - [Блог пост](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) з поясненням використання втулка `2to3` з прикладами diff --git a/content/uk/docs/topics/version_skew.md b/content/uk/docs/topics/version_skew.md new file mode 100644 index 000000000..6db23dee1 --- /dev/null +++ b/content/uk/docs/topics/version_skew.md @@ -0,0 +1,62 @@ +--- +title: "Політика підтримки версій Helm" +description: "Описує політику випуску патчів Helm, а також максимальну підтримувану різницю версій між Helm і Kubernetes." +weight: 15 +--- + +Цей документ описує максимальну підтримувану різницю версій між Helm і Kubernetes. + +## Підтримувані версії {#supported-versions} + +Версії Helm виражаються у форматі `x.y.z`, де `x` — це основна версія, `y` — це мінорна версія, а `z` — це версія патчу, відповідно до [семантичного версіювання](https://semver.org/spec/v2.0.0.html). + +Проєкт Helm підтримує релізну гілку для останнього мінорного випуску. Застосовні виправлення, включаючи виправлення безпеки, додаються в релізну гілку залежно від їх серйозності та можливості впровадження. Більше деталей можна знайти в [політиці випусків Helm](release_policy.md). + +## Підтримувана різниця версій {#supported-version-skew} + +Коли випускається нова версія Helm, вона компілюється з певною мінорною версією Kubernetes. Наприклад, Helm 3.0.0 взаємодіє з Kubernetes, використовуючи клієнт Kubernetes версії 1.16.2, тому він сумісний з Kubernetes 1.16. + +Починаючи з Helm 3, вважається, що Helm сумісний з версіями Kubernetes до `n-3` відносно версії, з якою він був скомпільований. Через зміни в Kubernetes між мінорними версіями, політика підтримки Helm 2 є трохи більш суворою і передбачає сумісність з версіями Kubernetes до `n-1`. + +Наприклад, якщо ви використовуєте версію Helm 3, яка була скомпільована з клієнтськими API Kubernetes версії 1.17, тоді її можна безпечно використовувати з Kubernetes 1.17, 1.16, 1.15 і 1.14. Якщо ж ви використовуєте версію Helm 2, скомпільовану з клієнтськими API Kubernetes версії 1.16, то її можна безпечно використовувати з Kubernetes 1.16 і 1.15. + +Не рекомендується використовувати Helm з версією Kubernetes, яка є новішою за ту, з якою він був скомпільований, оскільки Helm не гарантує зворотної сумісності. + +Якщо ви вирішите використовувати Helm з версією Kubernetes, яку він не підтримує, ви робите це на свій ризик. + +Будь ласка, зверніться до таблиці нижче, щоб визначити, яка версія Helm сумісна з вашим кластером. + +| Версія Helm | Підтримувані версії Kubernetes | +|--------------|-------------------------------| +| 3.14.x | 1.29.x - 1.26.x | +| 3.13.x | 1.28.x - 1.25.x | +| 3.12.x | 1.27.x - 1.24.x | +| 3.11.x | 1.26.x - 1.23.x | +| 3.10.x | 1.25.x - 1.22.x | +| 3.9.x | 1.24.x - 1.21.x | +| 3.8.x | 1.23.x - 1.20.x | +| 3.7.x | 1.22.x - 1.19.x | +| 3.6.x | 1.21.x - 1.18.x | +| 3.5.x | 1.20.x - 1.17.x | +| 3.4.x | 1.19.x - 1.16.x | +| 3.3.x | 1.18.x - 1.15.x | +| 3.2.x | 1.18.x - 1.15.x | +| 3.1.x | 1.17.x - 1.14.x | +| 3.0.x | 1.16.x - 1.13.x | +| 2.16.x | 1.16.x - 1.15.x | +| 2.15.x | 1.15.x - 1.14.x | +| 2.14.x | 1.14.x - 1.13.x | +| 2.13.x | 1.13.x - 1.12.x | +| 2.12.x | 1.12.x - 1.11.x | +| 2.11.x | 1.11.x - 1.10.x | +| 2.10.x | 1.10.x - 1.9.x | +| 2.9.x | 1.10.x - 1.9.x | +| 2.8.x | 1.9.x - 1.8.x | +| 2.7.x | 1.8.x - 1.7.x | +| 2.6.x | 1.7.x - 1.6.x | +| 2.5.x | 1.6.x - 1.5.x | +| 2.4.x | 1.6.x - 1.5.x | +| 2.3.x | 1.5.x - 1.4.x | +| 2.2.x | 1.5.x - 1.4.x | +| 2.1.x | 1.5.x - 1.4.x | +| 2.0.x | 1.4.x - 1.3.x | diff --git a/i18n/uk.toml b/i18n/uk.toml new file mode 100644 index 000000000..dcb24876f --- /dev/null +++ b/i18n/uk.toml @@ -0,0 +1,223 @@ +# site-wide copy + +## actions and labels +[action_get_started] +other = "Розпочати" + +[action_get_started_link] +other = "/uk/docs/intro/quickstart" + +[action_translate] +other = "Перекласти" + +[action_translate_link] +other = "https://github.com/helm/helm-www#internationalization--translation" + +[action_copy] +other = "Копіювати" + +## site-wide banner about versioning +[banner_1] +other = "" + +## footer +[footer_support_title] +other = "Helm підтримується та створюється спільнотою з понад 400 розробників." + +[footer_support_subtitle] +other = "...та багато інших чудових супровідників ядра [helm](https://github.com/helm/helm/blob/main/OWNERS)." + +[footer_cncf_status] +other = "Ми є дипломованим проєктом Cloud Native Computing Foundation." + +# homepage copy + +## homepage intro +[main_title] +other = "**Пакетний менеджер** **для Kubernetes**" + +[main_subtitle] +other = "Helm — це найкращий спосіб знаходити, ділитися та використовувати програмне забезпечення, створене для [Kubernetes](https://kubernetes.io)." + +## homepage about helm +[main_what_is_helm_title] +other = "Що таке Helm?" + +[main_what_is_helm_description] +other = """ +Helm допомагає керувати застосунками Kubernetes — чарти Helm допоможуть вам визначити, встановити та оновити навіть найскладніший застосунок Kubernetes. + +Чарти легко створювати, редагувати, поширювати та публікувати — тож почніть користуватися Helm і припиніть копіювати та вставляти. + +Helm є дипломованим проєктом [CNCF](https://cncf.io) та підтримується [спільнотою Helm](https://github.com/helm/community). + +### Дізнатись більше: + +* [Архітектура Helm](./docs/topics/architecture/) +* [Швидкий старт](./docs/intro/quickstart/) +* [Відео: Вступ до роботи з Helm](https://www.youtube.com/watch?v=Zzwq9FmZdsU&t=2s) +""" + +[main_why_teams_love] +other = 'Чому команди Helm' + +[feature_01_title] +other = "Керує складним" + +[feature_01_desc] +other = "Чарти описують навіть найскладніші застосунки, забезпечують повторюваність встановлення застосунків і слугують єдиним центром управління." + +[feature_02_title] +other = "Легкі оновлення" + +[feature_02_desc] +other = "Позбавте себе від болю при оновленні за допомогою вбудованих оновлень і власних хуків." + +[feature_03_title] +other = "Просто ділитися" + +[feature_03_desc] +other = "Чарти легко редагувати, ділитися ними та розміщувати на публічних або приватних серверах." + +[feature_04_title] +other = "Відкати" + +[feature_04_desc] +other = "Використовуйтк `helm rollback` для повернення до старішої версії релізу з легкістю." + +## homepage get helm +[get_helm_title] +other = "Отримайте Helm!" + +[get_helm_desc] +other = "Встановітьт Helm за допомогою менеджера пакунків, або [завантажте двійковий файл](https://github.com/helm/helm/releases/latest)." + +[get_helm_next] +other = "Після встановлення розпакуйте двійковий файл helm і додайте його до вашого PATH, і ви готові до роботи! Перевірте [документи](./docs/intro/install/) для подальшого [встановлення](./docs/intro/install/) та [інструкції з використання](./docs/intro/using_helm/)." + +[get_charts_title] +other = "Отримання чартів" + +[get_charts_desc] +other = "Відвідайте [Artifact Hub](https://artifacthub.io) для пошуку [чартів Helm](https://artifacthub.io/packages/search?kind=0) з багатоьох публічних репозиторіїв." + +[get_upgrade_title] +other = "[Оновлення з v2 до v3?](https://helm.sh/docs/topics/v2_v3_migration/)" + +[get_upgrade_desc] +other = "[Прочитайте документ про міграцію, щоб дізнатися більше.](https://helm.sh/docs/topics/v2_v3_migration/)" + +## homepage community +[community_title] +other = "Приєднуйтесь до спільноти" + +[community_desc] +other = "Більше інформації про проект Helm та про те, як зробити свій внесок." + +[community_next_release] +other = "Наступний реліз" + +[community_next_release_version] +other = "__Версія:__ " + +[community_next_release_date] +other = "__Дата:__ " + +[community_release_calendar] +other = "[Календар випусків](https://helm.sh/calendar/release)" + +[community_events_title] +other = "Події" + +[community_upcoming_events_title] +other = "Майбутні події" + +[community_upcoming_events_desc] +other = "Слідкуйте за новинами..." + +[community_past_events_title] +other = "Минулі події" + +[community_past_event_01] +other = "_25 лютого 2020_ - [Вебінар з безпеки Helm](https://www.cncf.io/webinars/helm-security-a-look-below-deck/)" + +[community_past_event_02] +other = "_18 листопада 2019_ - [KubeCon North America](https://events19.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019/)" + +[community_past_event_03] +other = "_11 вересня 2019_ - [Helm Summit 2019](https://events19.linuxfoundation.org/events/helm-summit-2019/)" + +[community_sig_title] +other = "SIG Apps" + +[community_sig_subtitle] +other = "Профільна група для розгортання та роботи з застосунками в Kubernetes." + +[community_sig_desc] +other = """ +[SIG-Apps](https://github.com/kubernetes/community/blob/master/sig-apps/README.md) — профільна група для розгортання та роботи з застосунками в Kubernetes. + +Група [зустрічається щотижня](https://github.com/kubernetes/community/blob/master/sig-apps/README.md), щоб продемонструвати та обговорити інструменти та проєкти. Зустрічі спільноти записуються та [публікуються на YouTube](https://www.youtube.com/results?search_query=kubernetes+sig+apps). +""" + +[community_standup_title] +other = "Зустрічі розробників" + +[community_standup_time] +other = "Четвер 9:30-10:00 (PT)" + +[community_standup_desc] +other = "Ці зустрічі відкриті для всіх. Перевірте [репозиторій спільноти](https://github.com/helm/community/blob/main/communication.md#meetings) для нотаток і подробиць." + +[community_slack_title] +other = "Slack" + +[community_slack_group_01_title] +other = "Користвачі Helm" + +[community_slack_group_01_desc] +other = "Обговорення використання Helm, роботи з чартами та вирішення типових помилок." + +[community_slack_group_02_title] +other = "Розробка Helm" + +[community_slack_group_02_desc] +other = "Теми, що стосуються розвитку Helm, поточних PR, релізів тощо." + +[community_slack_group_03_title] +other = "Чарти" + +[community_slack_group_03_desc] +other = "Обговорення для користувачів та авторів Helm Charts." + +[community_slack_join] +other = "[Отримайте доступ](https://slack.k8s.io/), щоб приєднатись до команди в Kubernetes Slack." + +[community_contrib_title] +other = "Участь" + +[community_contrib_subtitle] +other = "Helm завжди вітає нові надходження до проекту!" + + +[community_contrib_desc] +other = """ +### З чого почати? + +Helm - це великий проект з великою кількістю користувачів та учасників. Він може бути досить складним для сприйняття! + +У нас є перелік [good first issues](https://github.com/helm/helm/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20label%3A%22good+first+issue%22) на випадок, якщо ви хочете допомогти але не знаєте з чого розпочати. + +### Що мені робити? + +Перед тим, як внести код, будь ласка, прочитайте наше [Керівництво участі](https://github.com/helm/helm/blob/main/CONTRIBUTING.md). У ньому описані процеси створення та перевірки pull requests. + +Після написання коду, будь ласка, [підпишіть ваші комміти](https://helm.sh/blog/helm-dco/index.html), щоб переконатися, що Helm дотримується угоди [DCO](https://developercertificate.org/), яку використовує [CNCF](https://www.cncf.io/). +""" + +# 404 page +[404_title] +other = "**404** **Сторінку не знайдено.**" + +[404_subtitle] +other = "Вибачте за це. Якщо щось не працює, будь ласка, [повідомте про це тут] (https://github.com/helm/helm-www/issues/new)."