doc(v2): sync RU documentation for v2

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
 

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 
 ```
-
-*Обратите внимание, что ожидать готовность внешнего ресурса будут и все другие ресурсы релиза с тем же весом, так как ресурсы объединяются по весу в группы и развертываются именно группами.*

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
 ```
 

docs/pages_ru/usage/deploy/overview.md

@@ -5,17 +5,19 @@ permalink: usage/deploy/overview.html
 
 При организации доставки приложения в Kubernetes необходимо определиться с тем, какой формат выбрать для управления конфигурацией развёртывания (параметризации, управления зависимостями, конфигурации под различные окружения и т.д.), а также способом применения этой конфигурации – непосредственно механизмом развёртывания.
 
-В werf встроен Helm, и именно он используется для решения перечисленных задач. Разработка и сопровождение конфигурации реализуется с помощью Helm-чарта, а для процесса развёртывания предлагается Helm c дополнительными возможностями:
+Nelm — обратно-совместимая с Helm альтернатива — встроена в werf и используется для решения перечисленных задач. Разработка и сопровождение конфигурации реализуется с помощью Helm-чартов, а для процесса развёртывания предлагается Nelm c дополнительными возможностями:
 
 - отслеживание состояния выкатываемых ресурсов (с возможностью изменения поведения [для каждого ресурса]({{ "/reference/deploy_annotations.html" | true_relative_url }})):
   - умное ожидание готовности ресурсов;
   - мгновенное завершение проблемного развертывания без необходимости ожидания таймаута;
   - прогресс развёртывания, логи, системные события и ошибки приложения.
 - использование произвольного порядка развертывания для любых ресурсов, а не только для хуков;
 - ожидание создания и готовности ресурсов, не принадлежащих релизу;
+- использование более надежного метода Server-Side Apply для обновления ресурсов вместо 3-Way Merge;
+- возможности по типу `terraform plan`, доступные "из коробки";
 - интеграция сборки и развертывания и многое другое.
 
-werf стремится сделать работу с Helm более простой, удобной и гибкой, при этом не ломая обратную совместимость с Helm-чартами, Helm-шаблонами и Helm-релизами.
+werf стремится сделать работу с Helm-развертываниями более простой, удобной и гибкой, при этом не ломая обратную совместимость с Helm-чартами, Helm-шаблонами и Helm-релизами.
 
 ## Простой пример развертывания
 

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: <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 автоматически выставляет следующие аннотации всем ресурсам чарта в процессе развёртывания: