Merge pull request #57202 from apinnick/gh52120-remove-discrete-tags

GH52120: Replace discrete tags with anchor IDs

Author: apinnick

modules/images-create-guide-openshift.adoc

@@ -7,18 +7,19 @@
 The following are guidelines that apply when creating container images specifically
 for use on {product-title}.
 ifdef::openshift-online[]
-[discrete]
+
+[id="privileges-and-volume-builds_{context}"]
 == Privileges and volume builds
 
 Container images cannot be built using the `VOLUME` directive in the `DOCKERFILE`. Images using a read/write file system must use persistent volumes or `emptyDir` volumes instead of local storage. Instead of specifying a volume in the Dockerfile, specify a directory for local storage and mount either a persistent volume or `emptyDir` volume to that directory when deploying the pod.
 endif::[]
 
-[discrete]
+[id="enable-images-for-source-to-image_{context}"]
 == Enable images for source-to-image (S2I)
 
 For images that are intended to run application code provided by a third party, such as a Ruby image designed to run Ruby code provided by a developer, you can enable your image to work with the link:https://github.com/openshift/source-to-image[Source-to-Image (S2I)] build tool. S2I is a framework that makes it easy to write images that take application source code as an input and produce a new image that runs the assembled application as output.
 
-[discrete]
+
 [id="use-uid_{context}"]
 == Support arbitrary user ids
 
@@ -52,7 +53,6 @@ If your S2I image does not include a `USER` declaration with a numeric user, you
 ====
 endif::[]
 
-[discrete]
 [id="use-services_{context}"]
 == Use services for inter-image communication
 
@@ -62,12 +62,11 @@ For cases where your image needs to communicate with a service provided by anoth
 For more information see https://kubernetes.io/docs/concepts/services-networking/service/[this documentation].  (NOTE to docs team:  this link should really go to something in the openshift docs once we have it)
 ////
 
-[discrete]
+[id="provide-common-libraries_{context}"]
 == Provide common libraries
 
 For images that are intended to run application code provided by a third party, ensure that your image contains commonly used libraries for your platform. In particular, provide database drivers for common databases used with your platform. For example, provide JDBC drivers for MySQL and PostgreSQL if you are creating a Java framework image. Doing so prevents the need for common dependencies to be downloaded during application assembly time, speeding up application image builds. It also simplifies the work required by application developers to ensure all of their dependencies are met.
 
-[discrete]
 [id="use-env-vars_{context}"]
 == Use environment variables for configuration
 
@@ -92,31 +91,31 @@ in containers:
 - Blog article - http://fabiokung.com/2014/03/13/memory-inside-linux-containers[Memory inside Linux containers]
 ////
 
-[discrete]
+[id="set-image-metadata_{context}"]
 == Set image metadata
 
 Defining image metadata helps {product-title} better consume your container images, allowing {product-title} to create a better experience for developers using your image. For example, you can add metadata to provide helpful descriptions of your image, or offer suggestions on other images that are needed.
 
-[discrete]
+[id="clustering_{context}"]
 == Clustering
 
 You must fully understand what it means to run multiple instances of your image. In the simplest case, the load balancing function of a service handles routing traffic to all instances of your image. However, many frameworks must share information to perform leader election or failover state; for example, in session replication.
 
 Consider how your instances accomplish this communication when running in {product-title}. Although pods can communicate directly with each other, their IP addresses change anytime the pod starts, stops, or is moved. Therefore, it is important for your clustering scheme to be dynamic.
 
-[discrete]
+[id="logging_{context}"]
 == Logging
 
 It is best to send all logging to standard out. {product-title} collects standard out from containers and sends it to the centralized logging service where it can be viewed. If you must separate log content, prefix the output with an appropriate keyword, which makes it possible to filter the messages.
 
 If your image logs to a file, users must use manual operations to enter the running container and retrieve or view the log file.
 
-[discrete]
+[id="liveness-and-readiness-probes_{context}"]
 == Liveness and readiness probes
 
 Document example liveness and readiness probes that can be used with your image. These probes allow users to deploy your image with confidence that traffic is not be routed to the container until it is prepared to handle it, and that the container is restarted if the process gets into an unhealthy state.
 
-[discrete]
+[id="templates_{context}"]
 == Templates
 
 Consider providing an example template with your image. A template gives users an easy way to quickly get your image deployed with a working configuration. Your template must include the liveness and readiness probes you documented with the image, for completeness.