Use consistent asciidoctor subs attribute

Closes gh-25101

spring-boot-project/spring-boot-docs/src/docs/asciidoc/deployment/cloud.adoc

@@ -27,7 +27,7 @@ Once you have built your application (by using, for example, `mvn clean package`
 Be sure to have https://docs.cloudfoundry.org/cf-cli/getting-started.html#login[logged in with your `cf` command line client] before pushing an application.
 The following line shows using the `cf push` command to deploy an application:
 
-[indent=0,subs="verbatim,quotes,attributes"]
+[indent=0,subs="verbatim"]
 ----
 	$ cf push acloudyspringtime -p target/demo-0.0.1-SNAPSHOT.jar
 ----
@@ -39,7 +39,7 @@ If there is a Cloud Foundry https://docs.cloudfoundry.org/devguide/deploy-apps/m
 
 At this point, `cf` starts uploading your application, producing output similar to the following example:
 
-[indent=0,subs="verbatim,quotes,attributes"]
+[indent=0,subs="verbatim,quotes"]
 ----
 	Uploading acloudyspringtime... *OK*
 	Preparing to start acloudyspringtime... *OK*
@@ -68,7 +68,7 @@ Congratulations! The application is now live!
 
 Once your application is live, you can verify the status of the deployed application by using the `cf apps` command, as shown in the following example:
 
-[indent=0,subs="verbatim,quotes,attributes"]
+[indent=0,subs="verbatim"]
 ----
 	$ cf apps
 	Getting applications in ...
@@ -93,7 +93,7 @@ Process-scoped environment variables are language agnostic.
 
 Environment variables do not always make for the easiest API, so Spring Boot automatically extracts them and flattens the data into properties that can be accessed through Spring's `Environment` abstraction, as shown in the following example:
 
-[source,java,indent=0]
+[source,java,indent=0,subs="verbatim"]
 ----
 include::{docs-java}/deployment/cloud/cloudfoundry/bindingtoservices/MyBean.java[]
 ----
@@ -124,7 +124,7 @@ You can configure a sleep execution in a preStop handler to avoid requests being
 This sleep should be long enough for new requests to stop being routed to the pod and its duration will vary from deployment to deployment.
 The preStop handler can be configured via the PodSpec in the pod's configuration file as follows:
 
-[source,yml,indent=0]
+[source,yml,indent=0,subs="verbatim"]
 ----
 spec:
   containers:
@@ -161,7 +161,7 @@ The `$PORT` environment variable is assigned to us by the Heroku PaaS.
 This should be everything you need.
 The most common deployment workflow for Heroku deployments is to `git push` the code to production, as shown in the following example:
 
-[indent=0,subs="verbatim,quotes,attributes"]
+[indent=0,subs="verbatim,quotes"]
 ----
 	$ git push heroku main
 
@@ -270,7 +270,7 @@ By default, Elastic Beanstalk uploads sources and compiles them in AWS.
 However, it is best to upload the binaries instead.
 To do so, add lines similar to the following to your `.elasticbeanstalk/config.yml` file:
 
-[source,xml,indent=0,subs="verbatim,quotes,attributes"]
+[source,xml,indent=0,subs="verbatim"]
 ----
 	deploy:
 		artifact: target/demo-0.0.1-SNAPSHOT.jar
@@ -321,7 +321,7 @@ If your executable jar or war contains an https://boxfuse.com/docs/payloads/spri
 
 At this point, `boxfuse` creates an image for your application, uploads it, and configures and starts the necessary resources on AWS, resulting in output similar to the following example:
 
-[indent=0,subs="verbatim,quotes,attributes"]
+[indent=0,subs="verbatim"]
 ----
 	Fusing Image for myapp-1.0.jar ...
 	Image fused in 00:06.838s (53937 K) -> axelfontaine/myapp:1.0
@@ -362,7 +362,7 @@ Follow https://github.com/GoogleCloudPlatform/java-docs-samples/tree/master/appe
 Alternatively, App Engine Flex requires you to create an `app.yaml` file to describe the resources your app requires.
 Normally, you put this file in `src/main/appengine`, and it should resemble the following file:
 
-[source,yaml,indent=0]
+[source,yaml,indent=0,subs="verbatim"]
 ----
 	service: default
 
@@ -388,7 +388,7 @@ Normally, you put this file in `src/main/appengine`, and it should resemble the
 
 You can deploy the app (for example, with a Maven plugin) by adding the project ID to the build configuration, as shown in the following example:
 
-[source,xml,indent=0,subs="verbatim,quotes,attributes"]
+[source,xml,indent=0,subs="verbatim"]
 ----
 	<plugin>
 		<groupId>com.google.cloud.tools</groupId>

spring-boot-project/spring-boot-docs/src/docs/asciidoc/deployment/installing.adoc

@@ -15,7 +15,7 @@ A standard-format jar file that contains one or more zip64-format nested jars ca
 
 To create a '`fully executable`' jar with Maven, use the following plugin configuration:
 
-[source,xml,indent=0,subs="verbatim,quotes,attributes"]
+[source,xml,indent=0,subs="verbatim"]
 ----
 	<plugin>
 		<groupId>org.springframework.boot</groupId>
@@ -28,7 +28,7 @@ To create a '`fully executable`' jar with Maven, use the following plugin config
 
 The following example shows the equivalent Gradle configuration:
 
-[source,gradle,indent=0,subs="verbatim,quotes,attributes"]
+[source,gradle,indent=0,subs="verbatim"]
 ----
 	bootJar {
 		launchScript()
@@ -66,7 +66,7 @@ The script supports the following features:
 
 Assuming that you have a Spring Boot application installed in `/var/myapp`, to install a Spring Boot application as an `init.d` service, create a symlink, as follows:
 
-[indent=0,subs="verbatim,quotes,attributes"]
+[indent=0,subs="verbatim"]
 ----
 	$ sudo ln -s /var/myapp/myapp.jar /etc/init.d/myapp
 ----
@@ -74,7 +74,7 @@ Assuming that you have a Spring Boot application installed in `/var/myapp`, to i
 Once installed, you can start and stop the service in the usual way.
 For example, on a Debian-based system, you could start it with the following command:
 
-[indent=0,subs="verbatim,quotes,attributes"]
+[indent=0,subs="verbatim"]
 ----
 	$ service myapp start
 ----
@@ -84,7 +84,7 @@ TIP: If your application fails to start, check the log file written to `/var/log
 You can also flag the application to start automatically by using your standard operating system tools.
 For example, on Debian, you could use the following command:
 
-[indent=0,subs="verbatim,quotes,attributes"]
+[indent=0,subs="verbatim"]
 ----
 	$ update-rc.d myapp defaults <priority>
 ----
@@ -101,7 +101,7 @@ When the environment variable is not set, the user who owns the jar file is used
 You should never run a Spring Boot application as `root`, so `RUN_AS_USER` should never be root and your application's jar file should never be owned by root.
 Instead, create a specific user to run your application and set the `RUN_AS_USER` environment variable or use `chown` to make it the owner of the jar file, as shown in the following example:
 
-[indent=0,subs="verbatim,quotes,attributes"]
+[indent=0,subs="verbatim"]
 ----
 	$ chown bootapp:bootapp your-app.jar
 ----
@@ -114,7 +114,7 @@ For example, you can set the account's shell to `/usr/sbin/nologin`.
 You should also take steps to prevent the modification of your application's jar file.
 Firstly, configure its permissions so that it cannot be written and can only be read or executed by its owner, as shown in the following example:
 
-[indent=0,subs="verbatim,quotes,attributes"]
+[indent=0,subs="verbatim"]
 ----
 	$ chmod 500 your-app.jar
 ----
@@ -123,7 +123,7 @@ Second, you should also take steps to limit the damage if your application or th
 If an attacker does gain access, they could make the jar file writable and change its contents.
 One way to protect against this is to make it immutable by using `chattr`, as shown in the following example:
 
-[indent=0,subs="verbatim,quotes,attributes"]
+[indent=0,subs="verbatim"]
 ----
 	$ sudo chattr +i your-app.jar
 ----
@@ -134,7 +134,7 @@ If root is used to control the application's service and you <<deployment#deploy
 It should be secured accordingly.
 Use `chmod` so that the file can only be read by the owner and use `chown` to make root the owner, as shown in the following example:
 
-[indent=0,subs="verbatim,quotes,attributes"]
+[indent=0,subs="verbatim"]
 ----
 	$ chmod 400 your-app.conf
 	$ sudo chown root:root your-app.conf
@@ -174,7 +174,7 @@ Consult the https://www.freedesktop.org/software/systemd/man/systemd.service.htm
 
 To flag the application to start automatically on system boot, use the following command:
 
-[indent=0,subs="verbatim,quotes,attributes"]
+[indent=0,subs="verbatim"]
 ----
 	$ systemctl enable myapp.service
 ----
@@ -370,7 +370,7 @@ The file is expected to be next to the jar file and have the same name but suffi
 For example, a jar named `/var/myapp/myapp.jar` uses the configuration file named `/var/myapp/myapp.conf`, as shown in the following example:
 
 .myapp.conf
-[indent=0,subs="verbatim,quotes,attributes"]
+[indent=0,subs="verbatim"]
 ----
 	JAVA_OPTS=-Xmx1024M
 	LOG_FOLDER=/custom/log/folder