docs: use werf cr login instead docker login command

Signed-off-by: Aleksei Igrychev <[email protected]>

_includes/en/guides/100_basic/20_cluster.md.liquid

@@ -56,13 +56,9 @@ In this guide, we will use the Docker Hub container registry. However, you can u
 ### Authorizing in Docker Hub
 Create a [Docker Hub](https://hub.docker.com/signup) ID  and create a [private repository](https://hub.docker.com/repository/create) named `werf-guide-app`. We will store the built images in it.
 
-Using the `docker login` command, log in to the new repository by entering the username and password of the Docker Hub user:
+Using the `werf cr login` command, log in to the new repository by entering the username and password of the Docker Hub user:
 ```shell
-docker login
-# Enter the name of the Docker Hub user
-Username: <DOCKER HUB USERNAME>
-# Enter the password of the Docker Hub user
-Password: <DOCKER HUB PASSWORD>
+werf cr login https://index.docker.io/v1/ -u <DOCKER HUB USERNAME> -p <DOCKER HUB PASSWORD> 
 ```
 
 If the login is successful, you will see the following message:

_includes/en/guides/100_basic/20_cluster/has_cluster.md.liquid

@@ -71,8 +71,8 @@ This guide assumes that the example application (or its Nginx Ingress, to be mor
 
 ### Registry authorization
 
-You must be logged on the local machine using `docker login` for werf to be able to push the built image to the registry:
+You must be logged on the local machine using `werf cr login` for werf to be able to push the built image to the registry:
 
 ```shell
-docker login <registry_domain> -u <account_login> -p <account_password>
+werf cr login <registry_domain> -u <account_login> -p <account_password>
 ```

_includes/en/guides/400_ci_cd_workflow/030_gitlab_ci_cd.md.liquid

@@ -106,13 +106,13 @@ Build and Publish:
 
 It should be noted that cleaning up stages and the container registry implies running the corresponding task according to a schedule. Since building images during the cleanup is not needed, you should specify `except: [schedules]` so that the build stage is not triggered when the pipeline is running on a schedule.
 
-The task configuration is quite simple, that is why we prefer to focus on what it lacks — an explicit authorization in the container registry, and calling the `docker login`.
+The task configuration is quite simple, that is why we prefer to focus on what it lacks — an explicit authorization in the container registry, and calling the `werf cr login`.
 
 In the simplest case, if an integrated container registry is used, then the authorization is performed automatically when the `werf ci-env` command is executed. The `CI_JOB_TOKEN` (you can learn more about the GitLab job permissions model [here](https://docs.gitlab.com/ee/user/permissions.html)) and `CI_REGISTRY_IMAGE` GitLab environment variables act as arguments in this case.
 
 As a result of the `werf ci-env` command, a temporary docker config is created. It is used by all the commands in the shell session (including docker). It means that parallel tasks do not overlap when using docker, and the temporary token is preserved (not overwritten) in the configuration.
 
-If you need to authorize using the custom credentials, the `docker login` command must be executed after invoking `werf ci-env`.
+If you need to authorize using the custom credentials, the `werf cr login` command must be executed after invoking `werf ci-env`.
 
 ## Deploying an application
 

_includes/en/guides/400_ci_cd_workflow/040_github_actions.md.liquid

@@ -88,11 +88,11 @@ The `kubectl` interface is already pre-installed on GitHub virtual machines, so
 ```
 {% endraw %}
 
-Job configuring is quite simple, so we prefer to focus on what it lacks — an explicit authorization in the container registry, and calling the `docker login`.
+Job configuring is quite simple, so we prefer to focus on what it lacks — an explicit authorization in the container registry, and calling the `werf cr login`.
 
 In the simplest case, if an [integrated GitHub Packages-like container registry](https://help.github.com/en/packages/using-github-packages-with-your-projects-ecosystem/configuring-docker-for-use-with-github-packages) is used, then the authorization is performed automatically when the `werf ci-env` command is invoked. This command is run with several required arguments such as GitHub environment variables, the [`GITHUB_TOKEN` secret](https://help.github.com/en/actions/configuring-and-managing-workflows/authenticating-with-the-github_token#about-the-github_token-secret) (you have to explicitly declare it), and the name of the user (`GITHUB_ACTOR`) who started the workflow process.
 
-If there is a need to perform authorization using custom credentials or in an external container registry, then you have to use a ready-made action tailored to your container registry (or just run `docker login` before using werf).
+If there is a need to perform authorization using custom credentials or in an external container registry, then you have to use a ready-made action tailored to your container registry (or just run `werf cr login`).
 
 Now, let us explore other parameters used in this step:
 

_includes/ru/guides/100_basic/20_cluster.md.liquid

@@ -56,13 +56,9 @@ curl http://werf-guide-app.test/ping
 ### Авторизация в Docker Hub
 Регистрируемся на [Docker Hub](https://hub.docker.com/signup), после чего [создаём приватный репозиторий](https://hub.docker.com/repository/create) с именем `werf-guide-app`, в котором будем хранить собираемые образы.
 
-С помощью `docker login` получим доступ с текущего компьютера к новому репозиторию, введя логин и пароль от нашего пользователя на Docker Hub:
+С помощью `werf cr login` получим доступ с текущего компьютера к новому репозиторию, введя логин и пароль от нашего пользователя на Docker Hub:
 ```shell
-docker login
-# Введем ИМЯ ПОЛЬЗОВАТЕЛЯ DOCKER HUB.
-Username: <ИМЯ ПОЛЬЗОВАТЕЛЯ DOCKER HUB>
-# Введем ПАРОЛЬ ПОЛЬЗОВАТЕЛЯ DOCKER HUB.
-Password: <ПАРОЛЬ ПОЛЬЗОВАТЕЛЯ DOCKER HUB>
+werf cr login https://index.docker.io/v1/ -u <ИМЯ ПОЛЬЗОВАТЕЛЯ DOCKER HUB> -p <ПАРОЛЬ ПОЛЬЗОВАТЕЛЯ DOCKER HUB>
 ```
 
 В случае успеха получим ответ:

_includes/ru/guides/100_basic/20_cluster/has_cluster.md.liquid

@@ -71,8 +71,8 @@ werf поддерживает [множество имплементаций]({{
 
 ### Авторизация в Registry
 
-Для того, чтобы werf смог загрузить собранный образ в registry, нужно на локальной машине авторизоваться с помощью `docker login` примерно так:
+Для того, чтобы werf смог загрузить собранный образ в registry, нужно на локальной машине авторизоваться с помощью `werf cr login` примерно так:
 
 ```shell
-docker login <registry_domain> -u <account_login> -p <account_password>
+werf cr login <registry_domain> -u <account_login> -p <account_password>
 ```

_includes/ru/guides/400_ci_cd_workflow/030_gitlab_ci_cd.md.liquid

@@ -102,13 +102,13 @@ Build and Publish:
 Забегая вперед, очистка хранилища стадий и container registry предполагает запуск соответствующего задания по расписанию.
 Так как при очистке не требуется выполнять сборку образов, то указываем `except: [schedules]`, чтобы стадия сборки не запускалась в случае работы pipeline по расписанию.
 
-Конфигурация задания достаточно проста, поэтому хочется сделать акцент на том, чего в ней нет — явной авторизации в container registry, вызова `docker login`.
+Конфигурация задания достаточно проста, поэтому хочется сделать акцент на том, чего в ней нет — явной авторизации в container registry, вызова `werf cr login`.
 
 В простейшем случае, при использовании встроенного container registry, авторизация выполняется автоматически при вызове команды `werf ci-env`. В качестве необходимых аргументов используются переменные окружения GitLab `CI_JOB_TOKEN` (подробнее про модель разграничения доступа при выполнении заданий в GitLab можно прочитать [здесь](https://docs.gitlab.com/ee/user/permissions.html)) и `CI_REGISTRY_IMAGE`.
 
 При вызове `werf ci-env` создаётся временный docker config, который используется всеми командами в shell-сессии (в том числе docker). Таким образов, параллельные задания никак не пересекаются при использовании docker и временный токен в конфигурации не перетирается.
 
-Если необходимо выполнить авторизацию с произвольными учётными данными, `docker login` должен выполняться после вызова `werf ci-env`.
+Если необходимо выполнить авторизацию с произвольными учётными данными, `werf cr login` должен выполняться после вызова `werf ci-env`.
 
 ## Развёртывание приложения
 

_includes/ru/guides/400_ci_cd_workflow/040_github_actions.md.liquid

@@ -86,11 +86,11 @@
 ```
 {% endraw %}
 
-Конфигурация задания достаточно проста, поэтому хочется сделать акцент на том, чего в ней нет — явной авторизации в container registry, вызова `docker login`.
+Конфигурация задания достаточно проста, поэтому хочется сделать акцент на том, чего в ней нет — явной авторизации в container registry, вызова `werf cr login`.
 
 В простейшем случае, при использовании встроенного [container registry](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#external-events-repository_dispatch), авторизация выполняется автоматически при вызове команды `werf ci-env`. В качестве необходимых аргументов используются переменные окружения GitHub, [секретная переменная `GITHUB_TOKEN`](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#about-the-github_token-secret), а также имя пользователя (`GITHUB_ACTOR`) инициировавшего запуск workflow.
 
-Если необходимо выполнить авторизацию с произвольными учётными данными или с внешним container registry, то необходимо использовать готовый action для вашего container registry или просто выполнить `docker login` перед использованием werf.
+Если необходимо выполнить авторизацию с произвольными учётными данными или с внешним container registry, то необходимо использовать готовый action для вашего container registry или просто выполнить `werf cr login` перед.
 
 Рассмотрим оставшиеся используемые параметры на этом шаге: