1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00

SRVCOM-1664: ensure that docs have right context attribute

This commit is contained in:
Ashleigh Brennan
2022-02-07 15:01:19 -06:00
committed by openshift-cherrypick-robot
parent 7d0ca67ae9
commit a5b8bfbb53
24 changed files with 104 additions and 45 deletions

Binary file not shown.

Before

Width:  |  Height:  |  Size: 44 KiB

After

Width:  |  Height:  |  Size: 47 KiB

View File

@@ -1,3 +1,7 @@
// Module included in the following assemblies:
//
// * serverless/develop/serverless-applications.adoc
:_content-type: PROCEDURE
[id="creating-serverless-apps-kn_{context}"]
= Creating serverless applications by using the Knative CLI
@@ -5,6 +9,7 @@
The following procedure describes how you can create a basic serverless application using the `kn` CLI.
.Prerequisites
* {ServerlessOperatorName} and Knative Serving are installed on your cluster.
* You have installed the `kn` CLI.
@@ -19,7 +24,6 @@ $ kn service create <service-name> --image <image> --env <key=value>
+
.Example command
[source,terminal]
[source,terminal]
----
$ kn service create event-display \
--image quay.io/openshift-knative/knative-eventing-sources-event-display:latest

View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// serverless/knative_serving/serverless-applications.adoc
// * serverless/develop/serverless-applications.adoc
:_content-type: PROCEDURE
[id="creating-serverless-apps-yaml_{context}"]
@@ -35,5 +35,4 @@ spec:
$ oc apply -f <filename>
----
After the service is created and the application is deployed, Knative creates an immutable revision for this version of the application.
Knative also performs network programming to create a route, ingress, service, and load balancer for your application and automatically scales your pods up and down based on traffic, including inactive pods.
After the service is created and the application is deployed, Knative creates an immutable revision for this version of the application. Knative also performs network programming to create a route, ingress, service, and load balancer for your application and automatically scales your pods up and down based on traffic, including inactive pods.

View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// serverless/knative_serving/serverless-applications.adoc
// serverless/develop/serverless-applications.adoc
:_content-type: PROCEDURE
[id="interacting-serverless-apps-http2-gRPC_{context}"]
@@ -11,68 +11,59 @@
Insecure or edge-terminated routes do not support HTTP2 on {product-title}.
These routes also do not support gRPC because gRPC is transported by HTTP2.
If you use these protocols in your application, you must call the application using the ingress gateway directly.
To do this you must find the ingress gateway's public address and the application's specific host.
If you use these protocols in your application, you must call the application using the ingress gateway directly. To do this you must find the ingress gateway's public address and the application's specific host.
// FIXME: Uncomment for Serverless 1.19.0
// [IMPORTANT]
// ====
// This method needs to expose Kourier Gateway using the `LoadBalancer` service type. You can configure this by adding the following YAML to your `KnativeServing` custom resource definition (CRD):
[IMPORTANT]
====
This method needs to expose Kourier Gateway using the `LoadBalancer` service type. You can configure this by adding the following YAML to your `KnativeServing` custom resource definition (CRD):
// [source,yaml]
// ----
// ...
// spec:
// ingress:
// kourier:
// service-type: LoadBalancer
// ...
// ----
// ====
[source,yaml]
----
...
spec:
ingress:
kourier:
service-type: LoadBalancer
...
----
====
.Procedure
. Find the application host. See the instructions in _Verifying your serverless application deployment_.
. Find the ingress gateway's public address:
+
[source,terminal]
----
$ oc -n knative-serving-ingress get svc kourier
----
+
.Example output
+
[source,terminal]
----
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kourier LoadBalancer 172.30.51.103 a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com 80:31380/TCP,443:31390/TCP 67m
----
+
The public address is surfaced in the `EXTERNAL-IP` field, and in this case is `a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com`.
. Manually set the host header of your HTTP request to the application's host, but direct the request itself against the public address of the ingress gateway.
+
[source,terminal]
----
$ curl -H "Host: hello-default.example.com" a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com
----
+
.Example output
[source,terminal]
----
Hello Serverless!
----
+
You can also make a gRPC request by setting the authority to the application's host, while directing the request against the ingress gateway directly:
+
[source,yaml]
----
grpc.Dial(
@@ -81,7 +72,6 @@ grpc.Dial(
grpc.WithInsecure(),
)
----
+
[NOTE]
====

View File

@@ -1,3 +1,9 @@
// Module included in the following assemblies:
//
// * serverless/develop/serverless-applications.adoc
// * serverless/reference/kn-serving-ref.adoc
:_content-type: REFERENCE
[id="kn-service-apply_{context}"]
= Applying service declarations

View File

@@ -1,3 +1,9 @@
// Module included in the following assemblies:
//
// * serverless/develop/serverless-applications.adoc
// * serverless/reference/kn-serving-ref.adoc
:_content-type: REFERENCE
[id="kn-service-describe_{context}"]
= Describing serverless applications by using the Knative CLI

View File

@@ -1,6 +1,7 @@
// Module included in the following assemblies:
//
// serverless/cli_reference/kn-offline-services.adoc
// * serverless/cli_reference/kn-offline-services.adoc
// * serverless/develop/serverless-applications.adoc
:_content-type: CONCEPT
[id="kn-service-offline-about_{context}"]

View File

@@ -1,6 +1,7 @@
// Module included in the following assemblies:
//
// serverless/cli_reference/kn-offline-services.adoc
// * serverless/cli_reference/kn-offline-services.adoc
// * serverless/develop/serverless-applications.adoc
:_content-type: PROCEDURE
[id="creating-an-offline-service_{context}"]

View File

@@ -1,3 +1,9 @@
// Module included in the following assemblies:
//
// * serverless/develop/serverless-applications.adoc
// * serverless/reference/kn-serving-ref.adoc
:_content-type: REFERENCE
[id="kn-service-update_{context}"]
= Updating serverless applications by using the Knative CLI

View File

@@ -1,3 +1,7 @@
// Module included in the following assemblies:
//
// * serverless/develop/serverless-traffic-management.adoc
:_content-type: PROCEDURE
[id="odc-splitting-traffic-between-revisions-using-developer-perspective_{context}"]
= Managing traffic between revisions by using the {product-title} web console
@@ -6,6 +10,11 @@ After you create a serverless application, the application is displayed in the *
Any new change in the code or the service configuration creates a new revision, which is a snapshot of the code at a given time. For a service, you can manage the traffic between the revisions of the service by splitting and routing it to the different revisions as required.
.Prerequisites
* The {ServerlessOperatorName} and Knative Serving are installed on your cluster.
* You have logged in to the {product-title} web console.
.Procedure
To split traffic between multiple revisions of an application in the *Topology* view:

View File

@@ -1,9 +1,17 @@
// Module included in the following assemblies:
//
// * serverless/develop/serverless-traffic-management.adoc
:_content-type: PROCEDURE
[id="serverless-blue-green-deploy_{context}"]
= Routing and managing traffic by using a blue-green deployment strategy
You can safely reroute traffic from a production version of an app to a new version, by using a link:https://en.wikipedia.org/wiki/Blue-green_deployment[blue-green deployment strategy].
.Prerequisites
* The {ServerlessOperatorName} and Knative Serving are installed on the cluster.
.Procedure
. Create and deploy an app as a Knative service.

View File

@@ -1,3 +1,8 @@
// Module included in the following assemblies:
//
// * serverless/develop/serverless-traffic-management.adoc
:_content-type: REFERENCE
[id="serverless-custom-revision-urls_{context}"]
= Custom URLs for revisions

View File

@@ -1,7 +1,8 @@
// Module is included in the following assemblies:
//
// * serverless/knative_serving/serverless-applications.adoc
// * serverless/develop/serverless-applications.adoc
:_content-type: REFERENCE
[id="serverless-https-redirect-service_{context}"]
= HTTPS redirection per service

View File

@@ -11,7 +11,7 @@ You can use the following procedure to install Knative Eventing by using the {pr
.Prerequisites
* You have access to an {product-title} account with cluster administrator access.
* You have logged into the {product-title} web console.
* You have logged in to the {product-title} web console.
* You have installed the {ServerlessOperatorName}.
.Procedure

View File

@@ -11,7 +11,7 @@ You can use the following procedure to install Knative Serving by using the {pro
.Prerequisites
* You have access to an {product-title} account with cluster administrator access.
* You have logged into the {product-title} web console.
* You have logged in to the {product-title} web console.
* You have installed the {ServerlessOperatorName}.
.Procedure

View File

@@ -11,7 +11,7 @@ This procedure describes how to install and subscribe to the {ServerlessOperator
.Prerequisites
* You have access to an {product-title} account with cluster administrator access.
* You have logged into the {product-title} web console.
* You have logged in to the {product-title} web console.
.Procedure

View File

@@ -1,13 +1,15 @@
// Module included in the following assemblies:
//
// * serverless/cli_tools/kn-serving-ref.adoc
// * serverless/knative_serving/serverless-applications.adoc
// * serverless/develop/serverless-applications.adoc
// * serverless/reference/kn-serving-ref.adoc
:_content-type: REFERENCE
[id="serverless-kn-container_{context}"]
= Knative client multi-container support
You can use the `kn container add` command to print YAML container spec to standard output. This command is useful for multi-container use cases because it can be used along with other standard `kn` flags to create definitions. The `kn container add` command accepts all container-related flags that are supported for use with the `kn service create` command. The `kn container add` command can also be chained by using UNIX pipes (`|`) to create multiple container definitions at once.
[discrete]
[id="serverless-kn-container-examples_{context}"]
== Example commands

View File

@@ -1,3 +1,7 @@
// Module included in the following assemblies:
//
// * serverless/develop/serverless-applications.adoc
:_content-type: PROCEDURE
[id="serverless-services-network-policies_{context}"]
= Enabling communication with Knative applications on a cluster with restrictive network policies
@@ -25,9 +29,8 @@ To allow access to your applications from Knative system pods, you must add a la
====
A network policy that denies requests to non-Knative services on your cluster still prevents access to these services. However, by allowing access from Knative system namespaces to your Knative application, you are allowing access to your Knative application from all namespaces in the cluster.
If you do not want to allow access to your Knative application from all namespaces on the cluster, you might want to use _JSON Web Token authentication for Knative services_ instead (see the _Knative Serving_ documentation). JSON Web Token authentication for Knative services requires Service Mesh.
If you do not want to allow access to your Knative application from all namespaces on the cluster, you might want to use _JSON Web Token authentication for Knative services_ instead. JSON Web Token authentication for Knative services requires Service Mesh.
====
// xrefs for modules would be nice here to link to the JWT docs
.Procedure
@@ -82,4 +85,4 @@ spec:
- Ingress
----
<1> Provide a name for your network policy.
<2> The namespace where your application (Knative service) exists.
<2> The namespace where your application exists.

View File

@@ -1,3 +1,8 @@
// Module included in the following assemblies:
//
// * serverless/develop/serverless-traffic-management.adoc
:_content-type: REFERENCE
[id="serverless-traffic-management-kn_{context}"]
= Traffic management using the Knative CLI

View File

@@ -1,3 +1,8 @@
// Module included in the following assemblies:
//
// * serverless/develop/serverless-traffic-management.adoc
:_content-type: REFERENCE
[id="serverless-traffic-routing-examples_{context}"]
= Traffic routing examples

View File

@@ -1,3 +1,8 @@
// Module included in the following assemblies:
//
// * serverless/develop/serverless-traffic-management.adoc
:_content-type: REFERENCE
[id="traffice-splitting-flags_{context}"]
= Knative CLI traffic management flags

View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// serverless/knative_serving/serverless-applications.adoc
// serverless/develop/serverless-applications.adoc
:_content-type: PROCEDURE
[id="verifying-serverless-app-deployment_{context}"]

View File

@@ -1,8 +1,8 @@
:_content-type: ASSEMBLY
include::modules/serverless-document-attributes.adoc[]
[id="serverless-applications"]
= Serverless applications
include::modules/common-attributes.adoc[]
include::modules/serverless-document-attributes.adoc[]
:context: serverless-applications
toc::[]
@@ -62,6 +62,10 @@ include::modules/interacting-serverless-apps-http2-gRPC.adoc[leveloffset=+1]
// Using Knative services w/ restrictive NetworkPolicies
include::modules/serverless-services-network-policies.adoc[leveloffset=+1]
.Additional resources
* See xref:../../serverless/security/serverless-ossm-with-kourier-jwt.adoc#serverless-ossm-with-kourier-jwt[Configuring JSON Web Token authentication for Knative services].
// HTTPS redirection
include::modules/serverless-https-redirect-service.adoc[leveloffset=+1]

View File

@@ -1,8 +1,8 @@
:_content-type: ASSEMBLY
include::modules/serverless-document-attributes.adoc[]
[id="serverless-traffic-management"]
= Traffic management
include::modules/common-attributes.adoc[]
include::modules/serverless-document-attributes.adoc[]
:context: serverless-traffic-management
toc::[]
@@ -13,7 +13,6 @@ A _revision_ is a point-in-time snapshot of the code and configuration for each
You can manage traffic routing to different revisions of a Knative service by modifying the `traffic` spec of the service resource.
image::knative-service-architecture.png[Knative service architecture]
// placeholder image until we get a nice diagram to replace this
// routing basics - YAML examples
include::modules/serverless-traffic-routing-examples.adoc[leveloffset=+1]