diff --git a/docs/pages_ru/resources/comparison.md b/docs/pages_ru/resources/comparison.md index aad4526721..720c2c69a1 100644 --- a/docs/pages_ru/resources/comparison.md +++ b/docs/pages_ru/resources/comparison.md @@ -15,7 +15,7 @@ GitOps требует разделять разработку и эксплуа Helm используется только для развертывания и дистрибуции чартов, а werf ещё и для разработки, сборки, тестирования, дистрибуции образов и бандлов, а также очистки container registry. -В werf встроен Helm с дополнительными возможностями: продвинутым отслеживанием, порядком развертывания не только для хуков, но и для обычных ресурсов, и другими. +Для развертывания чартов и их дистрибуции мы используем Nelm: совместимую с Helm альтернативу, которая предоставляет множество новых возможностей и улучшений, таких как продвинутое отслеживание ресурсов, гибкий порядок выката ресурсов во время развертывания, Server-Side Apply вместо 3-Way Merge, `terraform plan`-подобные возможности и многое другое. ## werf vs Argo CD diff --git a/docs/pages_ru/usage/deploy/deployment_order.md b/docs/pages_ru/usage/deploy/deployment_order.md index 05ba074551..2680bd8976 100644 --- a/docs/pages_ru/usage/deploy/deployment_order.md +++ b/docs/pages_ru/usage/deploy/deployment_order.md @@ -48,45 +48,6 @@ werf converge По умолчанию werf объединяет все основные ресурсы (основные — не являющиеся хуками или CRDs из `crds/*.yaml`) в одну группу, создаёт ресурсы этой группы, а затем отслеживает их готовность. -Создание ресурсов группы происходит в следующем порядке: - -- 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. - -Отслеживание готовности включается для всех ресурсов группы одновременно сразу после создания *всех* ресурсов группы. - Для изменения порядка развертывания ресурсов можно создать *новые группы ресурсов* через задание ресурсам *веса*, отличного от веса по умолчанию `0`. Все ресурсы с одинаковым весом объединяются в группы, а затем группы ресурсов развертываются по очереди, от группы с меньшим весом к большему, например: ``` @@ -264,5 +225,3 @@ metadata: secret.external-dependency.werf.io/resource: secret/my-dynamic-vault-secret secret.external-dependency.werf.io/namespace: my-namespace ``` - -*Обратите внимание, что ожидать готовность внешнего ресурса будут и все другие ресурсы релиза с тем же весом, так как ресурсы объединяются по весу в группы и развертываются именно группами.* diff --git a/docs/pages_ru/usage/deploy/deployment_scenarios.md b/docs/pages_ru/usage/deploy/deployment_scenarios.md index 2d1736076a..4ad9ee75f3 100644 --- a/docs/pages_ru/usage/deploy/deployment_scenarios.md +++ b/docs/pages_ru/usage/deploy/deployment_scenarios.md @@ -159,7 +159,7 @@ kubectl apply -f manifests.yaml werf build --repo example.org/mycompany/myapp ``` -``` +```shell werf render --require-built-images --output manifests.yaml --repo example.org/mycompany/myapp ``` diff --git a/docs/pages_ru/usage/deploy/overview.md b/docs/pages_ru/usage/deploy/overview.md index 18cf2b2801..e652b2049d 100644 --- a/docs/pages_ru/usage/deploy/overview.md +++ b/docs/pages_ru/usage/deploy/overview.md @@ -5,7 +5,7 @@ permalink: usage/deploy/overview.html При организации доставки приложения в Kubernetes необходимо определиться с тем, какой формат выбрать для управления конфигурацией развёртывания (параметризации, управления зависимостями, конфигурации под различные окружения и т.д.), а также способом применения этой конфигурации – непосредственно механизмом развёртывания. -В werf встроен Helm, и именно он используется для решения перечисленных задач. Разработка и сопровождение конфигурации реализуется с помощью Helm-чарта, а для процесса развёртывания предлагается Helm c дополнительными возможностями: +Nelm — обратно-совместимая с Helm альтернатива — встроена в werf и используется для решения перечисленных задач. Разработка и сопровождение конфигурации реализуется с помощью Helm-чартов, а для процесса развёртывания предлагается Nelm c дополнительными возможностями: - отслеживание состояния выкатываемых ресурсов (с возможностью изменения поведения [для каждого ресурса]({{ "/reference/deploy_annotations.html" | true_relative_url }})): - умное ожидание готовности ресурсов; @@ -13,9 +13,11 @@ permalink: usage/deploy/overview.html - прогресс развёртывания, логи, системные события и ошибки приложения. - использование произвольного порядка развертывания для любых ресурсов, а не только для хуков; - ожидание создания и готовности ресурсов, не принадлежащих релизу; +- использование более надежного метода Server-Side Apply для обновления ресурсов вместо 3-Way Merge; +- возможности по типу `terraform plan`, доступные "из коробки"; - интеграция сборки и развертывания и многое другое. -werf стремится сделать работу с Helm более простой, удобной и гибкой, при этом не ломая обратную совместимость с Helm-чартами, Helm-шаблонами и Helm-релизами. +werf стремится сделать работу с Helm-развертываниями более простой, удобной и гибкой, при этом не ломая обратную совместимость с Helm-чартами, Helm-шаблонами и Helm-релизами. ## Простой пример развертывания diff --git a/docs/pages_ru/usage/deploy/releases.md b/docs/pages_ru/usage/deploy/releases.md index 625b621947..ef00a312f4 100644 --- a/docs/pages_ru/usage/deploy/releases.md +++ b/docs/pages_ru/usage/deploy/releases.md @@ -58,30 +58,6 @@ werf converge --release backend-production # или $WERF_RELEASE=... Вручную отформатировать любую строку согласно формату RFC 1123 Label Names можно командой `werf slugify -f helm-release`. -## Добавление в релиз уже существующих в кластере ресурсов - -werf не позволяет развернуть новый ресурс релиза поверх уже существующего в кластере ресурса, если ресурс в кластере *не является частью текущего релиза*. Такое поведение предотвращает случайные обновления ресурсов, принадлежащих другому релизу или развернутых без werf. Если все же попытаться это сделать, то отобразится следующая ошибка: - -``` -Error: helm upgrade have failed: UPGRADE FAILED: rendered manifests contain a resource that already exists... -``` - -Чтобы добавить ресурс в кластере в текущий релиз и разрешить его обновление, выставьте ресурсу в кластере аннотации `meta.helm.sh/release-name: <имя текущего релиза>`, `meta.helm.sh/release-namespace: ` и лейбл `app.kubernetes.io/managed-by: Helm`, например: - -```shell -kubectl annotate deploy/myapp meta.helm.sh/release-name=myapp-production -kubectl annotate deploy/myapp meta.helm.sh/release-namespace=myapp-production -kubectl label deploy/myapp app.kubernetes.io/managed-by=Helm -``` - -... после чего перезапустите развертывание: - -```shell -werf converge -``` - -Результат: ресурс релиза `myapp` успешно обновил ресурс `myapp` в кластере и теперь ресурс в кластере является частью текущего релиза. - ## Автоматическое аннотирование выкатываемых ресурсов релиза werf автоматически выставляет следующие аннотации всем ресурсам чарта в процессе развёртывания: