Small fixes in other pages

Signed-off-by: Zhbert <konstantin.nezhbert@flant.com>

docs/pages_en/usage/build/stapel/imports.md

@@ -8,7 +8,7 @@ directive_summary: import
 The size of the final image can grow dramatically due to the assembly tools and source files eating up space. These files are generally not needed in the final image.
 To avoid this, the Docker community suggests installing tools, building, and removing irrelevant files in one step:
 
-```
+```Dockerfile
 RUN “download-source && cmd && cmd2 && remove-source”
 ```
 
@@ -26,7 +26,7 @@ However, this method does not support caching. Thus, a build toolkit will be ins
 
 Another way is to use a multi-stage build, a feature supported in Docker since version 17.05:
 
-```
+```Dockerfile
 FROM node:latest AS storefront
 WORKDIR /app
 COPY react-app .
@@ -76,7 +76,7 @@ As with the _git mappings_ configuration, include and exclude file and directory
 You can also specify an owner and a group for the imported resources, `owner: <owner>` and `group: <group>`.
 This behavior is similar to the one used when adding code from Git repositories, and you can read more about it in the [git directive section]({{ "usage/build/stapel/git.html" | true_relative_url }}).
 
-> Note that the path of imported resources and the path specified in _git mappings_ must not overlap
+> Note that the path of imported resources and the path specified in _git mappings_ must not overlap.
 
 Refer to [this section]({{ "usage/build/stapel/imports.html#what-is-an-artifact" | true_relative_url }}) to learn more about _using artifacts_.
 

docs/pages_en/usage/build/stapel/instructions.md

@@ -551,11 +551,11 @@ The build script can be used to download the `some-library-latest.tar.gz` archiv
 
 Working with remote Git repositories relies on the `SSH_AUTH_SOCK` UNIX socket, which is mounted in all build containers. This way, the build instructions can use the SSH agent over the specified UNIX socket.
 
-> **NOTE** There is a restriction that only the `root` user inside the build container can access the UNIX socket defined by the `SSH_AUTH_SOCK` environment variable.
+> **NOTE:** There is a restriction that only the `root` user inside the build container can access the UNIX socket defined by the `SSH_AUTH_SOCK` environment variable.
 
 By default (if no parameters are specified), werf tries to use the SSH-agent running on the system by checking its availability via the `SSH_AUTH_SOCK` environment variable.
 
-If no SSH agent is running on the system, werf tries to act as an SSH client, using the user's default SSH key (`~/.ssh/id_rsa|id_dsa`). If werf finds one of these files, it runs a temporary SSH agent and adds to it the keys it has found. 
+If no SSH agent is running on the system, werf tries to act as an SSH client, using the user's default SSH key (`~/.ssh/id_rsa|id_dsa`). If werf finds one of these files, it runs a temporary SSH agent and adds to it the keys it has found.
 
 You have to specify the `--ssh-key PRIVATE_KEY_FILE_PATH` startup option to use specific SSH keys only (you can use this option more than once to specify multiple SSH keys). In this case, werf runs a temporary SSH agent and adds to it only the specified SSH keys.
 

docs/pages_en/usage/build/stapel/mounts.md

@@ -34,4 +34,4 @@ The implementation allows for inheriting mount points from the [base image]({{ "
 
 Also, during the `from` stage, werf cleans up assembly container mount points in the [base image]({{ "usage/build/stapel/base.html" | true_relative_url }}), so these directories in the image are empty.
 
-> By default, the `fromPath` and `from: build_dir` directives are not allowed by giterminism (read more about it [here]({{ "/usage/project_configuration/giterminism.html#mount" | true_relative_url }}))
+> By default, the `fromPath` and `from: build_dir` directives are not allowed by giterminism (read more about it [here]({{ "/usage/project_configuration/giterminism.html#mount" | true_relative_url }})).

docs/pages_en/usage/deploy/overview.md

@@ -18,7 +18,7 @@ werf strives to make working with Helm easier, more convenient and flexible with
 
 You only need two files and the `werf converge` command (run it in the application's Git repository) to deploy a basic application:
 
-```
+```yaml
 # .helm/templates/hello.yaml:
 apiVersion: apps/v1
 kind: Deployment
@@ -37,7 +37,7 @@ spec:
       - image: nginxdemos/hello:plain-text
 ```
 
-```
+```yaml
 # werf.yaml:
 configVersion: 1
 project: hello
@@ -53,7 +53,7 @@ The above command will deploy the `hello` Deployment to the `hello-production` N
 
 Here is a more complex deployment example involving image assembly and external Helm charts:
 
-```
+```yaml
 # werf.yaml:
 configVersion: 1
 project: myapp
@@ -87,7 +87,7 @@ backend:
 
 {% raw %}
 
-```
+```yaml
 # .helm/templates/backend.yaml:
 apiVersion: apps/v1
 kind: Deployment

docs/pages_ru/usage/build/stapel/imports.md

@@ -8,7 +8,7 @@ directive_summary: import
 Из-за используемых инструментов сборки либо просто из-за исходных файлов размер конечного образа может увеличиваться в несколько раз. Зачастую эти файлы не нужны в конечном образе. Для решения таких проблем сообщество Docker предлагает выполнять установки инструментов, сборку и удаление ненужных файлов за один шаг.
 
 Условный пример:
-```
+```Dockerfile
 RUN “download-source && cmd && cmd2 && remove-source”
 ```
 
@@ -26,7 +26,7 @@ shell:
 
 Другой способ — использование multi-stage сборки, которая поддерживается в Docker, начиная с версии 17.05.
 
-```
+```Dockerfile
 FROM node:latest AS storefront
 WORKDIR /app
 COPY react-app .
@@ -76,7 +76,7 @@ import:
 Вы также можете указывать владельца и группу для импортируемых ресурсов с помощью параметров `owner: <owner>` и `group: <group>` соответственно.
 Это поведение аналогично используемому при добавлении кода из Git-репозиториев, и вы можете подробнее почитать об этом [в соответствующем разделе]({{ "usage/build/stapel/git.html" | true_relative_url }}).
 
-> Обратите внимание, что путь импортируемых ресурсов и путь указанный в _git mappings_ не должны пересекаться
+> Обратите внимание, что путь импортируемых ресурсов и путь указанный в _git mappings_ не должны пересекаться.
 
 ## Что такое артефакты?
 

docs/pages_ru/usage/build/stapel/instructions.md

@@ -6,7 +6,7 @@ directive_summary: shell_and_ansible
 
 ## Пользовательские стадии
 
-***Пользовательские стадии*** — это стадии со сборочными инструкциями [из конфигурации. Другими словами — это стадии, конфигурируемые пользователем (существуют также служебные стадии, которые пользователь конфигурировать не может). В настоящее время существует два вида сборочных инструкций: _shell_ и _ansible_.
+***Пользовательские стадии*** — это стадии со сборочными инструкциями из конфигурации. Другими словами — это стадии, конфигурируемые пользователем (существуют также служебные стадии, которые пользователь конфигурировать не может). В настоящее время существует два вида сборочных инструкций: _shell_ и _ansible_.
 
 werf поддерживает четыре _пользовательские стадии_, которые выполняются последовательно в следующем порядке: _beforeInstall_, _install_, _beforeSetup_ и _setup_. В результате выполнения инструкций пользовательской стадии создается один Docker-слой. Т.е. по одному слою на каждую стадию вне зависимости от количества инструкций.
 
@@ -579,7 +579,7 @@ shell:
 
 При работе с удаленными Git-репозиториями используется UNIX-сокет `SSH_AUTH_SOCK`, который монтируется во все сборочные контейнеры. Таким образом, сборочные инструкции могут использовать SSH-агент через указанный UNIX-сокет.
 
-> **ЗАМЕЧАНИЕ** Существует ограничение, из-за которого только пользователь `root` внутри сборочного контейнера имеет доступ к UNIX-сокету из переменной окружения `SSH_AUTH_SOCK`.
+> **ЗАМЕЧАНИЕ:** Существует ограничение, из-за которого только пользователь `root` внутри сборочного контейнера имеет доступ к UNIX-сокету из переменной окружения `SSH_AUTH_SOCK`.
 
 По умолчанию (без указания каких-либо параметров) werf пытается использовать SSH-agent, запущенный в системе, проверяя его доступность с помощью переменной окружения `SSH_AUTH_SOCK`.
 

docs/pages_ru/usage/build/stapel/mounts.md

@@ -24,10 +24,10 @@ directive_summary: mount
 - `tmp_dir` временная директория, индивидуальная для каждого описанного образа, создаваемая заново при каждой сборке;
 - `build_dir` общая директория, доступная всем образам проекта и сохраняемая между сборками (находится по пути `~/.werf/shared_context/mounts/projects/<project name>/<mount id>/`). Вы можете использовать эту директорию для хранения, например, кэша и т.п.
 
-> werf монтирует служебные директории с возможностью чтения и записи при каждой сборке, но в образе содержимого этих директорий не будет. Если вам необходимо сохранить какие-либо данные из этих директорий непосредственно в образе, то вы должны их скопировать при сборке
+> werf монтирует служебные директории с возможностью чтения и записи при каждой сборке, но в образе содержимого этих директорий не будет. Если вам необходимо сохранить какие-либо данные из этих директорий непосредственно в образе, то вы должны их скопировать при сборке.
 
 На стадии `from` werf добавляет специальные лейблы к образу стадии согласно описанных точек монтирования. Затем на каждой стадии werf использует эти лейблы при монтировании директорий в сборочный контейнер. Такая реализация позволяет наследовать точки монтирования [от базового образа]({{ "usage/build/stapel/base.html" | true_relative_url }}).
 
 Также нужно иметь в виду, что на стадии `from` werf очищает точки монтирования [в базовом образе]({{ "usage/build/stapel/base.html" | true_relative_url }}) (т.е. эти каталоги будут пусты).
 
-> По умолчанию использование директивы `fromPath` и `from: build_dir` запрещено гитерминизмом (подробнее об этом [в статье]({{ "/usage/project_configuration/giterminism.html#mount" | true_relative_url }}))
+> По умолчанию использование директивы `fromPath` и `from: build_dir` запрещено гитерминизмом (подробнее об этом [в статье]({{ "/usage/project_configuration/giterminism.html#mount" | true_relative_url }})).

docs/pages_ru/usage/deploy/overview.md

@@ -18,7 +18,7 @@ werf стремится сделать работу с Helm более прос
 
 Для развертывания простого приложения достаточно двух файлов и команды `werf converge`, запущенной в Git-репозитории приложения:
 
-```
+```yaml
 # .helm/templates/hello.yaml:
 apiVersion: apps/v1
 kind: Deployment
@@ -37,7 +37,7 @@ spec:
       - image: nginxdemos/hello:plain-text
 ```
 
-```
+```yaml
 # werf.yaml:
 configVersion: 1
 project: hello
@@ -53,7 +53,7 @@ werf converge --repo registry.example.org/repo --env production
 
 Более сложный пример развертывания со сборкой образов и внешними Helm-чартами:
 
-```
+```yaml
 # werf.yaml:
 configVersion: 1
 project: myapp
@@ -87,7 +87,7 @@ backend:
 
 {% raw %}
 
-```
+```yaml
 # .helm/templates/backend.yaml:
 apiVersion: apps/v1
 kind: Deployment

docs/pages_ru/usage/deploy/values.md

@@ -441,7 +441,7 @@ secretValue
 
 6. При дальнейших вызовах werf секретный ключ должен быть установлен в вышеупомянутых переменной окружения или файлах, иначе файл секретных параметров не сможет быть расшифрован.
 
-> Имеющий доступ к секретному ключу может расшифровать содержимое файла секретных параметров, поэтому **держите секретный ключ в безопасном месте**!.
+> Имеющий доступ к секретному ключу может расшифровать содержимое файла секретных параметров, поэтому **держите секретный ключ в безопасном месте**!
 
 При использовании файла `<корень Git-репозитория>/.werf_secret_key` обязательно добавьте его в `.gitignore`, чтобы случайно не сохранить его в Git-репозитории.