Polish

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"]
+[source,shell,indent=0,subs="verbatim"]
 ----
 	$ cf push acloudyspringtime -p target/demo-0.0.1-SNAPSHOT.jar
 ----
@@ -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"]
+[source,shell,indent=0,subs="verbatim"]
 ----
 	$ cf apps
 	Getting applications in ...
@@ -126,14 +126,14 @@ The preStop handler can be configured via the PodSpec in the pod's configuration
 
 [source,yml,indent=0,subs="verbatim"]
 ----
-spec:
-  containers:
-  - name: example-container
-    image: example-image
-    lifecycle:
-      preStop:
-        exec:
-          command: ["sh", "-c", "sleep 10"]
+	spec:
+	  containers:
+	  - name: example-container
+	    image: example-image
+	    lifecycle:
+	      preStop:
+	        exec:
+	          command: ["sh", "-c", "sleep 10"]
 ----
 
 Once the pre-stop hook has completed, SIGTERM will be sent to the container and <<features#features.graceful-shutdown,graceful shutdown>> will begin, allowing any remaining in-flight requests to complete.
@@ -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"]
+[source,shell,indent=0,subs="verbatim,quotes"]
 ----
 	$ git push heroku main
 
@@ -308,7 +308,7 @@ Boxfuse leverages this information both for the images it produces as well as fo
 
 Once you have created a https://console.boxfuse.com[Boxfuse account], connected it to your AWS account, installed the latest version of the Boxfuse Client, and ensured that the application has been built by Maven or Gradle (by using, for example, `mvn clean package`), you can deploy your Spring Boot application to AWS with a command similar to the following:
 
-[indent=0]
+[source,shell,indent=0,subs="verbatim"]
 ----
 	$ boxfuse run myapp-1.0.jar -env=prod
 ----

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

@@ -5,7 +5,7 @@ Certain PaaS implementations may also choose to unpack archives before they run.
 For example, Cloud Foundry operates this way.
 One way to run an unpacked archive is by starting the appropriate launcher, as follows:
 
-[indent=0]
+[source,shell,indent=0,subs="verbatim"]
 ----
 	$ jar -xf myapp.jar
 	$ java org.springframework.boot.loader.JarLauncher
@@ -16,7 +16,7 @@ At runtime you shouldn't expect any differences.
 
 Once you have unpacked the jar file, you can also get an extra boost to startup time by running the app with its "natural" main method instead of the `JarLauncher`. For example:
 
-[indent=0]
+[source,shell,indent=0,subs="verbatim"]
 ----
 	$ jar -xf myapp.jar
 	$ java -cp BOOT-INF/classes:BOOT-INF/lib/* com.example.MyApplication

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

@@ -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"]
+[source,shell,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"]
+[source,shell,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"]
+[source,shell,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"]
+[source,shell,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"]
+[source,shell,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"]
+[source,shell,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"]
+[source,shell,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"]
+[source,shell,indent=0,subs="verbatim"]
 ----
 	$ systemctl enable myapp.service
 ----