mirror of https://github.com/knative/docs.git
Format markdown (#1245)
* Format markdown Produced via: `prettier --write --prose-wrap=always $(find -name '*.md' | grep -v vendor | grep -v .github)` * Revert the bad portion of the auto-format
This commit is contained in:
mattmoor-sockpuppet
Knative Prow Robot
parent
f8884fd0e9
commit
429da39a46
|
|
@ -1,8 +1,9 @@
|
|||
Get up and running with one of the community code samples.
|
||||
These samples are contributed and maintained by members of the Knative community.
|
||||
Get up and running with one of the community code samples. These samples are
|
||||
contributed and maintained by members of the Knative community.
|
||||
|
||||
Note: It is possible that one or more samples might become outdated or the original author is unable to maintain their
|
||||
contribution. If you find that something isn't working, lend a helping hand and fix it in a PR.
|
||||
Note: It is possible that one or more samples might become outdated or the
|
||||
original author is unable to maintain their contribution. If you find that
|
||||
something isn't working, lend a helping hand and fix it in a PR.
|
||||
[Learn more about the lifespan of samples](../../contributing/DOCS-CONTRIBUTING.md).
|
||||
|
||||
[**See all Knative code samples**](../../docs/samples/)
|
||||
|
|
@ -11,15 +12,15 @@ contribution. If you find that something isn't working, lend a helping hand and
|
|||
|
||||
Knative Serving sample apps.
|
||||
|
||||
| Sample Name | Description | Language(s) |
|
||||
| ----------- | ---------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Sample Name | Description | Language(s) |
|
||||
| ----------- | ----------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Hello World | A quick introduction to Knative Serving that highlights how to deploy an app. | [Clojure](./serving/helloworld-clojure/README.md), [Dart](./serving/helloworld-dart/README.md), [Elixir](./serving/helloworld-elixir/README.md), [Haskell](./serving/helloworld-haskell/README.md), [Rust](./serving/helloworld-rust/README.md), [Swift](./serving/helloworld-swift/README.md), [Vertx](./serving/helloworld-vertx/README.md) |
|
||||
|
||||
#### Build samples
|
||||
|
||||
* *Be the first to contribute a Build code sample to the community collection.*
|
||||
- _Be the first to contribute a Build code sample to the community collection._
|
||||
|
||||
#### Eventing and Eventing Sources samples
|
||||
|
||||
* *Be the first to contribute an Eventing or Eventing Sources code sample to the community collection.*
|
||||
|
||||
- _Be the first to contribute an Eventing or Eventing Sources code sample to the
|
||||
community collection._
|
||||
|
|
|
|||
|
|
@ -1,4 +1,3 @@
|
|||
|
||||
A simple web app written in Clojure that you can use for testing. It reads in an
|
||||
env variable `TARGET` and prints "Hello \${TARGET}!". If TARGET is not
|
||||
specified, it will use "World" as the TARGET.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,3 @@
|
|||
|
||||
A simple web app written in the [Dart](www.dartlang.org) programming language
|
||||
that you can use for testing. It reads in the env variable `TARGET` and prints
|
||||
`"Hello $TARGET"`. If `TARGET` is not specified, it will use `"World"` as
|
||||
|
|
|
|||
|
|
@ -1,4 +1,3 @@
|
|||
|
||||
A simple web application written in [Elixir](https://elixir-lang.org/) using the
|
||||
[Phoenix Framework](https://phoenixframework.org/). The application prints all
|
||||
environment variables to the main page.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,3 @@
|
|||
|
||||
A simple web app written in Haskell that you can use for testing. It reads in an
|
||||
env variable `TARGET` and prints "Hello \${TARGET}!". If TARGET is not
|
||||
specified, it will use "World" as the TARGET.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,3 @@
|
|||
|
||||
A simple web app written in Rust that you can use for testing. It reads in an
|
||||
env variable `TARGET` and prints "Hello \${TARGET}!". If
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,3 @@
|
|||
|
||||
A simple web app written in Swift that you can use for testing. The app reads in
|
||||
an env variable `TARGET` and prints "Hello \${TARGET}!". If TARGET is not
|
||||
specified, the app uses "World" as the TARGET.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,3 @@
|
|||
|
||||
Learn how to deploy a simple web app that is written in Java and uses Eclipse
|
||||
Vert.x. This samples uses Docker to build locally. The app reads in a `TARGET`
|
||||
env variable and then prints "Hello World: \${TARGET}!". If a value for `TARGET`
|
||||
|
|
|
|||
|
|
@ -26,8 +26,9 @@ behavior to knative-code-of-conduct@googlegroups.com.
|
|||
### Contributor license agreements
|
||||
|
||||
We'd love to accept your contributions! But before we can take them, you need to
|
||||
fill out the [Google CLA](https://cla.developers.google.com). Important: You must fill
|
||||
out the CLA with the same email address that you used to create your GitHub account.
|
||||
fill out the [Google CLA](https://cla.developers.google.com). Important: You
|
||||
must fill out the CLA with the same email address that you used to create your
|
||||
GitHub account.
|
||||
|
||||
Once you are CLA'ed, we'll be able to accept your pull requests. This is
|
||||
necessary because you own the copyright to your changes, even after your
|
||||
|
|
@ -64,8 +65,8 @@ Note that code issues should be filed against the
|
|||
[individual Knative repositories](http://github.com/knative), while
|
||||
documentation issues should go in the
|
||||
[`knative/docs`repo](https://github.com/knative/docs/issues). If the issue is
|
||||
specific to the [https://knative.dev](https://knative.dev) website, open the issue
|
||||
in the [`knative/website`repo](https://github.com/knative/website/issues).
|
||||
specific to the [https://knative.dev](https://knative.dev) website, open the
|
||||
issue in the [`knative/website`repo](https://github.com/knative/website/issues).
|
||||
|
||||
### Working group
|
||||
|
||||
|
|
@ -90,59 +91,62 @@ There are a couple different ways to jump in to the Knative doc set:
|
|||
[install guides](../install/README.md) and then try
|
||||
[Getting Started with Knative Serving](../install/getting-started-knative-app.md).
|
||||
|
||||
You should keep a
|
||||
[friction log](https://devrel.net/developer-experience/an-introduction-to-friction-logging)
|
||||
of your experience and then use that to open your first set of PRs.
|
||||
Examples:
|
||||
You should keep a
|
||||
[friction log](https://devrel.net/developer-experience/an-introduction-to-friction-logging)
|
||||
of your experience and then use that to open your first set of PRs. Examples:
|
||||
|
||||
- What was hard for you?
|
||||
- Did you stumble on something because it wasn't clear?
|
||||
- Was a dependency not mentioned?
|
||||
- What was hard for you?
|
||||
- Did you stumble on something because it wasn't clear?
|
||||
- Was a dependency not mentioned?
|
||||
|
||||
**A few pointers and other considerations**
|
||||
|
||||
- Think about how you can improve the documentation as a whole. <br>
|
||||
For example, how can you fix the issue you found so that others don't run
|
||||
into the same challenges?
|
||||
- Think about how you can improve the documentation as a whole. <br> For
|
||||
example, how can you fix the issue you found so that others don't run into the
|
||||
same challenges?
|
||||
|
||||
- Are there multiple places that could be fixed?
|
||||
- Are there multiple places that could be fixed?
|
||||
|
||||
- Are there other pages that you should apply your update?
|
||||
- Are there other pages that you should apply your update?
|
||||
|
||||
- Would it help if there was a link to more or related information on a
|
||||
the page? On a related page?
|
||||
- Would it help if there was a link to more or related information on a the
|
||||
page? On a related page?
|
||||
|
||||
- Was the title or description misleading? Did you expect to find something
|
||||
else?
|
||||
- Was the title or description misleading? Did you expect to find something
|
||||
else?
|
||||
|
||||
- If you find something and don't have the bandwidth to open a PR,
|
||||
make us aware of the pain point and open an
|
||||
[Issue](https://github.com/knative/docs/issues/new).
|
||||
- If you find something and don't have the bandwidth to open a PR, make us aware
|
||||
of the pain point and open an
|
||||
[Issue](https://github.com/knative/docs/issues/new).
|
||||
|
||||
### Submitting documentation PRs - what to expect
|
||||
|
||||
Here's what generally happens when you open a PR against the `knative/docs` repo:
|
||||
Here's what generally happens when you open a PR against the `knative/docs`
|
||||
repo:
|
||||
|
||||
1. One of the assigned repo maintainers will triage the PR by assigning relative
|
||||
priority, adding appropriate labels, and performing an initial documentation
|
||||
review.
|
||||
1. If the PR involves significant technical changes, for example new features,
|
||||
or new and changed sample code, the PR is assigned to a Subject Matter
|
||||
Expert (SME), typically an engineer working on Knative, for technical review and approval.
|
||||
1. When both the technical writers and SMEs are satisfied with the quality
|
||||
of the writing and the technical accuracy of the content, the PR can be
|
||||
merged. A PR requires two labels before it can merge:
|
||||
`lgtm` and `approved`.
|
||||
* The SME is responsible for reviewing the technical accuracy and adding
|
||||
the `lgtm` label.
|
||||
or new and changed sample code, the PR is assigned to a Subject Matter Expert
|
||||
(SME), typically an engineer working on Knative, for technical review and
|
||||
approval.
|
||||
1. When both the technical writers and SMEs are satisfied with the quality of
|
||||
the writing and the technical accuracy of the content, the PR can be merged.
|
||||
A PR requires two labels before it can merge: `lgtm` and `approved`.
|
||||
|
||||
* The [Knative technical writers](https://github.com/knative/docs/blob/master/OWNERS_ALIASES)
|
||||
are who provide the `approved` label when the content meets quality, clarity, and
|
||||
organization standards (see [Style Guide](#style-guide)).
|
||||
- The SME is responsible for reviewing the technical accuracy and adding the
|
||||
`lgtm` label.
|
||||
|
||||
We appreciate contributions to the docs, so if you open a PR we
|
||||
will help you get it merged. You can also post in the `#docs`
|
||||
[Slack channel](https://knative.slack.com/) to get input on your ideas before creating a PR.
|
||||
- The
|
||||
[Knative technical writers](https://github.com/knative/docs/blob/master/OWNERS_ALIASES)
|
||||
are who provide the `approved` label when the content meets quality,
|
||||
clarity, and organization standards (see [Style Guide](#style-guide)).
|
||||
|
||||
We appreciate contributions to the docs, so if you open a PR we will help you
|
||||
get it merged. You can also post in the `#docs`
|
||||
[Slack channel](https://knative.slack.com/) to get input on your ideas before
|
||||
creating a PR.
|
||||
|
||||
### Putting your docs in the right place
|
||||
|
||||
|
|
@ -155,129 +159,131 @@ Depending on the type of content that you want to contribute, it might belong in
|
|||
one of the Knative code repositories (`knative/serving`, `knative/eventing`,
|
||||
etc.) or in `knative/docs`, the Knative documentation repo.
|
||||
|
||||
* **Contributor-focused content**
|
||||
- **Contributor-focused content**
|
||||
|
||||
* *Documentation*: Includes content that is component specific and relevant
|
||||
only to contributors of a given component. Contributor focused
|
||||
documentation is located in the corresponding `docs` folder of that
|
||||
component's repository. For example, if you contribute code to
|
||||
the Knative Serving component, you might need to add contributor focused
|
||||
information into the `docs` folder of the
|
||||
- _Documentation_: Includes content that is component specific and relevant
|
||||
only to contributors of a given component. Contributor focused documentation
|
||||
is located in the corresponding `docs` folder of that component's
|
||||
repository. For example, if you contribute code to the Knative Serving
|
||||
component, you might need to add contributor focused information into the
|
||||
`docs` folder of the
|
||||
[knative/serving repo](https://github.com/knative/serving/tree/master/docs/).
|
||||
|
||||
* *Code samples*: Includes contributor related code or samples. Code or samples
|
||||
that are contributor focused also belong in their corresponding
|
||||
- _Code samples_: Includes contributor related code or samples. Code or
|
||||
samples that are contributor focused also belong in their corresponding
|
||||
component's repo. For example, Eventing specific test code is located in the
|
||||
[knative/eventing tests](https://github.com/knative/eventing/tree/master/test)
|
||||
folder.
|
||||
|
||||
* **User-focused content**
|
||||
- **User-focused content**
|
||||
|
||||
* *Documentation*: Includes all content for Knative users. The
|
||||
external-facing user documentation belongs in the
|
||||
- _Documentation_: Includes all content for Knative users. The external-facing
|
||||
user documentation belongs in the
|
||||
[`knative/docs` repo](https://github.com/knative/docs). All content in
|
||||
`knative/docs` is published to [https://knative.dev](https://knative.dev).
|
||||
|
||||
* *Code samples*: Includes user-facing code samples and their accompanying
|
||||
- _Code samples_: Includes user-facing code samples and their accompanying
|
||||
step-by-step instructions. User code samples are currently separated into
|
||||
two different locations within the `knative/docs` repo. See the following
|
||||
section for details about determining where you can add your code sample.
|
||||
|
||||
##### Determining where to add user focused code samples
|
||||
|
||||
There are currently two categories of user-focused code samples,
|
||||
*Knative owned and maintained* and *Community owned and maintained*.
|
||||
There are currently two categories of user-focused code samples, _Knative owned
|
||||
and maintained_ and _Community owned and maintained_.
|
||||
|
||||
* **Knative owned and maintained**: Includes code samples that are actively
|
||||
maintained and e2e tested. To ensure content currency and balance available
|
||||
resource, only the code samples that meet the following requirements are
|
||||
located in the `docs/[*component*]/samples` folders of the `knative/docs` repo:
|
||||
- **Knative owned and maintained**: Includes code samples that are actively
|
||||
maintained and e2e tested. To ensure content currency and balance available
|
||||
resource, only the code samples that meet the following requirements are
|
||||
located in the `docs/[*component*]/samples` folders of the `knative/docs`
|
||||
repo:
|
||||
|
||||
* *Actively maintained* - The code sample has an active Knative team member
|
||||
who has committed to regular maintenance of that content and ensures that
|
||||
the code is updated and working for every product release.
|
||||
* *Receives regular traffic* - To avoid hosting and maintaining unused
|
||||
or stale content, if code samples are not being viewed and fail to
|
||||
receive attention or use, those samples will be moved into the
|
||||
"[community maintained](https://github.com/knative/docs/tree/master/community/samples)"
|
||||
set of samples.
|
||||
* *Passes e2e testing* - All code samples within `docs/[*component*]/samples`
|
||||
folders must align with (and pass) the
|
||||
[`e2e` tests](https://github.com/knative/docs/tree/master/test).
|
||||
- _Actively maintained_ - The code sample has an active Knative team member
|
||||
who has committed to regular maintenance of that content and ensures that
|
||||
the code is updated and working for every product release.
|
||||
- _Receives regular traffic_ - To avoid hosting and maintaining unused or
|
||||
stale content, if code samples are not being viewed and fail to receive
|
||||
attention or use, those samples will be moved into the
|
||||
"[community maintained](https://github.com/knative/docs/tree/master/community/samples)"
|
||||
set of samples.
|
||||
- _Passes e2e testing_ - All code samples within `docs/[*component*]/samples`
|
||||
folders must align with (and pass) the
|
||||
[`e2e` tests](https://github.com/knative/docs/tree/master/test).
|
||||
|
||||
Depending on the Knative component covered by the code sample that you
|
||||
want to contribute, your PR should add that sample in one of the following
|
||||
folders:
|
||||
Depending on the Knative component covered by the code sample that you want to
|
||||
contribute, your PR should add that sample in one of the following folders:
|
||||
|
||||
* Build samples: [`/docs/build/samples`](https://github.com/knative/docs/tree/master/docs/build/samples)
|
||||
* Eventing samples: [`/docs/eventing/samples`](https://github.com/knative/docs/tree/master/docs/eventing/samples)
|
||||
* Serving samples: [`/docs/serving/samples`](https://github.com/knative/docs/tree/master/docs/serving/samples)
|
||||
- Build samples:
|
||||
[`/docs/build/samples`](https://github.com/knative/docs/tree/master/docs/build/samples)
|
||||
- Eventing samples:
|
||||
[`/docs/eventing/samples`](https://github.com/knative/docs/tree/master/docs/eventing/samples)
|
||||
- Serving samples:
|
||||
[`/docs/serving/samples`](https://github.com/knative/docs/tree/master/docs/serving/samples)
|
||||
|
||||
* **Community owned and maintained samples**: Code samples that have
|
||||
been contributed by Knative community members. These samples might not receive
|
||||
regular maintenance. It is possible that a sample is no longer current and
|
||||
is not actively maintained by its original author. While we encourage a
|
||||
- **Community owned and maintained samples**: Code samples that have been
|
||||
contributed by Knative community members. These samples might not receive
|
||||
regular maintenance. It is possible that a sample is no longer current and is
|
||||
not actively maintained by its original author. While we encourage a
|
||||
contributor to maintain their content, we acknowledge that it's not always
|
||||
possible for certain reasons, for example other commitments and time
|
||||
constraints.
|
||||
|
||||
While a sample might be out of date, it could still provide assistance and
|
||||
help you get up-and-running with certain use-cases. If you find that
|
||||
something is not right or contains outdated info, open an
|
||||
[Issue](https://github.com/knative/docs/issues/new). The sample might be
|
||||
fixed if bandwidth or available resource exists, or the sample might be
|
||||
taken down and archived into the last release branch where it worked.
|
||||
While a sample might be out of date, it could still provide assistance and help
|
||||
you get up-and-running with certain use-cases. If you find that something is not
|
||||
right or contains outdated info, open an
|
||||
[Issue](https://github.com/knative/docs/issues/new). The sample might be fixed
|
||||
if bandwidth or available resource exists, or the sample might be taken down and
|
||||
archived into the last release branch where it worked.
|
||||
|
||||
#### Choosing the correct branch
|
||||
|
||||
It is likely that your docs contribution is either for new or changed
|
||||
features in the product, or for a fix or update existing content.
|
||||
It is likely that your docs contribution is either for new or changed features
|
||||
in the product, or for a fix or update existing content.
|
||||
|
||||
* **New or changed features**:
|
||||
If you are adding or updating documentation for a new or changed feature,
|
||||
you likely want to open your PR against the `master` branch. All pre-release
|
||||
content for active Knative development belongs in
|
||||
[`master`](https://github.com/knative/docs/tree/master/).
|
||||
- **New or changed features**: If you are adding or updating documentation for a
|
||||
new or changed feature, you likely want to open your PR against the `master`
|
||||
branch. All pre-release content for active Knative development belongs in
|
||||
[`master`](https://github.com/knative/docs/tree/master/).
|
||||
|
||||
* **Fixes and updates**:
|
||||
If you find an issue in a past release, for example a typo or out-of-date
|
||||
content, you likely need to open multiple and subsequent PRs. If not a
|
||||
followup PR, at least add the "`cherrypick` labels" to your original PR
|
||||
to indicate in which of the past release that your change affects.
|
||||
- **Fixes and updates**: If you find an issue in a past release, for example a
|
||||
typo or out-of-date content, you likely need to open multiple and subsequent
|
||||
PRs. If not a followup PR, at least add the "`cherrypick` labels" to your
|
||||
original PR to indicate in which of the past release that your change affects.
|
||||
|
||||
For example, if you find a typo in a page of the `v0.5` release, then that
|
||||
page in the `master` branch likely also has that typo.
|
||||
For example, if you find a typo in a page of the `v0.5` release, then that
|
||||
page in the `master` branch likely also has that typo.
|
||||
|
||||
To fix the typo:
|
||||
1. Open a PR against the
|
||||
[`master`](https://github.com/knative/docs/tree/master/) branch.
|
||||
1. Add one or more `cherrypick-#.#` labels to that PR to indicate which
|
||||
of the past release branches should also be fixed. Generally, we only maintain the most recent numbered release.
|
||||
1. If you want to complete the fix yourself (best practice), you then open
|
||||
a subsequent PR by running `git cherry-pick [COMMIT#]` against
|
||||
the [release-0.5](https://github.com/knative/docs/tree/release-0.5).
|
||||
Where [COMMIT#] is the commit of your merged PR.
|
||||
To fix the typo:
|
||||
|
||||
Note: Depending on workload and available bandwidth, one of
|
||||
the Knative team members might be able to help handle the
|
||||
`git cherry-pick` in order to push the fix into the affected release
|
||||
branch(es).
|
||||
1. Open a PR against the
|
||||
[`master`](https://github.com/knative/docs/tree/master/) branch.
|
||||
1. Add one or more `cherrypick-#.#` labels to that PR to indicate which of
|
||||
the past release branches should also be fixed. Generally, we only
|
||||
maintain the most recent numbered release.
|
||||
1. If you want to complete the fix yourself (best practice), you then open a
|
||||
subsequent PR by running `git cherry-pick [COMMIT#]` against the
|
||||
[release-0.5](https://github.com/knative/docs/tree/release-0.5). Where
|
||||
[COMMIT#] is the commit of your merged PR.
|
||||
|
||||
For a list of the available branches in the `knative/docs` repo, see
|
||||
[Documentation Releases](https://github.com/knative/docs/blob/master/doc-releases.md).
|
||||
Note: Depending on workload and available bandwidth, one of the Knative
|
||||
team members might be able to help handle the `git cherry-pick` in order
|
||||
to push the fix into the affected release branch(es).
|
||||
|
||||
For a list of the available branches in the `knative/docs` repo, see
|
||||
[Documentation Releases](https://github.com/knative/docs/blob/master/doc-releases.md).
|
||||
|
||||
## Assigning owners and reviewers
|
||||
|
||||
For both documentation and code samples, you should assign your PR to a single
|
||||
owner ("*Assignee*"). It's best to set the "Assignee" and include other stakeholders
|
||||
as "Reviewers" rather than leaving it unassigned or allowing
|
||||
owner ("_Assignee_"). It's best to set the "Assignee" and include other
|
||||
stakeholders as "Reviewers" rather than leaving it unassigned or allowing
|
||||
[Prow](https://prow.k8s.io/command-help) to auto assign reviewers.
|
||||
|
||||
Use the `/assign` command to set the owner. For example: `/assign @owner_id`
|
||||
|
||||
For code samples, initially set the owner of your PR to the SME who should review
|
||||
for technical accuracy. If you don't know who the appropriate owner is, nor
|
||||
who your reviewers should be for your PR, you can assign the
|
||||
For code samples, initially set the owner of your PR to the SME who should
|
||||
review for technical accuracy. If you don't know who the appropriate owner is,
|
||||
nor who your reviewers should be for your PR, you can assign the
|
||||
[current working group lead](./WORKING-GROUPS.md) of the related component.
|
||||
|
||||
If you want to notify and include other stakeholders in your PR review, use the
|
||||
|
|
|
|||
|
|
@ -83,15 +83,15 @@ the KSC will, from time to time, consider if this policy should be changed.
|
|||
The current membership of the committee is currently (listed alphabetically by
|
||||
first name):
|
||||
|
||||
| | Member | Organization | Profile |
|
||||
| --------------------------------------------------------- | -------------- | ------------ | ---------------------------------------- |
|
||||
| <img width="30px" src="https://github.com/dewitt.png"> | DeWitt Clinton | Google | [@dewitt](https://github.com/dewitt) |
|
||||
| <img width="30px" src="https://github.com/mchmarny.png"> | Mark Chmarny | Google | [@mchmarny](https://github.com/mchmarny) |
|
||||
| <img width="30px" src="https://github.com/mbehrendt.png"> | Michael Behrendt | IBM | [@mbehrendt](https://github.com/mbehrendt) |
|
||||
| <img width="30px" src="https://github.com/pmorie.png"> | Paul Morie | Red Hat | [@pmorie](https://github.com/pmorie) |
|
||||
| <img width="30px" src="https://github.com/rgregg.png"> | Ryan Gregg | Google | [@rgregg](https://github.com/rgregg) |
|
||||
| <img width="30px" src="https://github.com/isdal.png"> | Tomas Isdal | Google | [@isdal](https://github.com/isdal) |
|
||||
| | TBD | Pivotal | |
|
||||
| | Member | Organization | Profile |
|
||||
| --------------------------------------------------------- | ---------------- | ------------ | ------------------------------------------ |
|
||||
| <img width="30px" src="https://github.com/dewitt.png"> | DeWitt Clinton | Google | [@dewitt](https://github.com/dewitt) |
|
||||
| <img width="30px" src="https://github.com/mchmarny.png"> | Mark Chmarny | Google | [@mchmarny](https://github.com/mchmarny) |
|
||||
| <img width="30px" src="https://github.com/mbehrendt.png"> | Michael Behrendt | IBM | [@mbehrendt](https://github.com/mbehrendt) |
|
||||
| <img width="30px" src="https://github.com/pmorie.png"> | Paul Morie | Red Hat | [@pmorie](https://github.com/pmorie) |
|
||||
| <img width="30px" src="https://github.com/rgregg.png"> | Ryan Gregg | Google | [@rgregg](https://github.com/rgregg) |
|
||||
| <img width="30px" src="https://github.com/isdal.png"> | Tomas Isdal | Google | [@isdal](https://github.com/isdal) |
|
||||
| | TBD | Pivotal | |
|
||||
|
||||
There is currently one unfilled seat, as indicated by TBD.
|
||||
|
||||
|
|
|
|||
|
|
@ -68,14 +68,14 @@ API
|
|||
|
||||
[Build](https://github.com/knative/build), Builders, and Build templates
|
||||
|
||||
| Artifact | Link |
|
||||
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Forum | [knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) |
|
||||
| Community Meeting VC | [meet.google.com/hau-nwak-tgm](https://meet.google.com/hau-nwak-tgm) <br>Or dial in:<br>(US) +1 219-778-6103 PIN: 573 000# |
|
||||
| Artifact | Link |
|
||||
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| Forum | [knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) |
|
||||
| Community Meeting VC | [meet.google.com/hau-nwak-tgm](https://meet.google.com/hau-nwak-tgm) <br>Or dial in:<br>(US) +1 219-778-6103 PIN: 573 000# |
|
||||
| Community Meeting Calendar | Every other Wednesday 10:00a-10:30a PST <br>[Calendar](https://calendar.google.com/calendar/embed?src=google.com_18un4fuh6rokqf8hmfftm5oqq4%40group.calendar.google.com) |
|
||||
| Meeting Notes | [Notes](https://docs.google.com/document/d/1e7gMVFlJfkFdTcaWj2qETeRD9kSBG2Vh8mASPmQMYC0/edit) |
|
||||
| Document Folder | [Folder](https://drive.google.com/corp/drive/folders/1ov16HvPam-v_FXAGEaUdHok6_hUAoIoe) |
|
||||
| Slack Channel | [#build-crd](https://slack.knative.dev/messages/build-crd) |
|
||||
| Meeting Notes | [Notes](https://docs.google.com/document/d/1e7gMVFlJfkFdTcaWj2qETeRD9kSBG2Vh8mASPmQMYC0/edit) |
|
||||
| Document Folder | [Folder](https://drive.google.com/corp/drive/folders/1ov16HvPam-v_FXAGEaUdHok6_hUAoIoe) |
|
||||
| Slack Channel | [#build-crd](https://slack.knative.dev/messages/build-crd) |
|
||||
|
||||
| | Leads | Company | Profile |
|
||||
| -------------------------------------------------------- | ---------- | ------- | --------------------------------------- |
|
||||
|
|
|
|||
|
|
@ -5,12 +5,13 @@ weight: 90
|
|||
type: "docs"
|
||||
---
|
||||
|
||||
Use the following code samples to help you understand the various use cases for Knative
|
||||
Build. [Learn more about Knative Build](../index.html).
|
||||
Use the following code samples to help you understand the various use cases for
|
||||
Knative Build. [Learn more about Knative Build](../index.html).
|
||||
|
||||
[**See all Knative code samples**](../samples/)
|
||||
|
||||
Use the following code samples to learn about configuring and createing your Knative Builds.
|
||||
Use the following code samples to learn about configuring and createing your
|
||||
Knative Builds.
|
||||
|
||||
Tip: Review and reference multiple samples to piece together more complex
|
||||
builds.
|
||||
|
|
@ -22,7 +23,6 @@ builds.
|
|||
|
||||
#### Build template samples
|
||||
|
||||
|
||||
- View the collection of build templates in the `knative/build-template` repo:
|
||||
[Sample build templates](https://github.com/knative/build-templates).
|
||||
|
||||
|
|
|
|||
|
|
@ -9,8 +9,8 @@ Knative Eventing is designed around the following goals:
|
|||
1. Knative Eventing services are loosely coupled. These services can be
|
||||
developed and deployed independently on, and across a variety of platforms
|
||||
(for example Kubernetes, VMs, SaaS or FaaS).
|
||||
1. Event producers and event consumers are independent. Any producer (or source),
|
||||
can generate events before there are active event consumers that are
|
||||
1. Event producers and event consumers are independent. Any producer (or
|
||||
source), can generate events before there are active event consumers that are
|
||||
listening. Any event consumer can express interest in an event or class of
|
||||
events, before there are producers that are creating those events.
|
||||
1. Other services can be connected to the Eventing system. These services can
|
||||
|
|
|
|||
|
|
@ -5,7 +5,8 @@ weight: 90
|
|||
type: "docs"
|
||||
---
|
||||
|
||||
Use the following code samples to help you understand the various use cases for Knative
|
||||
Eventing and Event Sources. [Learn more about Knative Eventing and Eventing Sources](../index.html).
|
||||
Use the following code samples to help you understand the various use cases for
|
||||
Knative Eventing and Event Sources.
|
||||
[Learn more about Knative Eventing and Eventing Sources](../index.html).
|
||||
|
||||
[**See all Knative code samples**](../../samples/)
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ spec:
|
|||
template:
|
||||
spec:
|
||||
containers:
|
||||
- image: gcr.io/knative-releases/github.com/knative/eventing-sources/cmd/event_display
|
||||
- image: gcr.io/knative-releases/github.com/knative/eventing-sources/cmd/event_display
|
||||
```
|
||||
|
||||
Use following command to create the service from `service.yaml`:
|
||||
|
|
|
|||
|
|
@ -209,7 +209,7 @@ files from the Knative repositories:
|
|||
| [`monitoring-tracing-zipkin.yaml`][1.5] | Installs only [Zipkin][2.3].**\*** | Serving component, ELK stack (monitoring-logs-elasticsearch.yaml) |
|
||||
| [`monitoring-tracing-zipkin-in-mem.yaml`][1.6] | Installs only [Zipkin in-memory][2.3]**\*** | Serving component |
|
||||
| **knative/build** | | |
|
||||
| [`build.yaml`][3.1]† | Installs the Build component. | Cluster roles enabled, if interacting with Serving |
|
||||
| [`build.yaml`][3.1]† | Installs the Build component. | Cluster roles enabled, if interacting with Serving |
|
||||
| **knative/eventing** | | |
|
||||
| [`release.yaml`][4.1]† | Installs the Eventing component. Includes the in-memory channel provisioner. | Serving component |
|
||||
| [`eventing.yaml`][4.2] | Installs the Eventing component. Does not include the in-memory channel provisioner. | Serving component |
|
||||
|
|
@ -305,17 +305,18 @@ commands below.
|
|||
|
||||
1. To install Knative components or plugins, specify the filenames in the
|
||||
`kubectl apply` command. To prevent install failures due to race conditions,
|
||||
run the install command first with the `-l knative.dev/crd-install=true` flag,
|
||||
then a second time without the selector flag. This installs the CRDs first:
|
||||
run the install command first with the `-l knative.dev/crd-install=true`
|
||||
flag, then a second time without the selector flag. This installs the CRDs
|
||||
first:
|
||||
|
||||
```bash
|
||||
kubectl apply --selector knative.dev/crd-install=true \
|
||||
--filename [FILE_URL] \
|
||||
--filename [FILE_URL]
|
||||
```
|
||||
```bash
|
||||
kubectl apply --selector knative.dev/crd-install=true \
|
||||
--filename [FILE_URL] \
|
||||
--filename [FILE_URL]
|
||||
```
|
||||
|
||||
- Then run the `kubectl apply` command again without the `-l` flag to
|
||||
complete the install:
|
||||
complete the install:
|
||||
|
||||
```bash
|
||||
kubectl apply --filename [FILE_URL] \
|
||||
|
|
@ -339,45 +340,46 @@ commands below.
|
|||
**Example install commands:**
|
||||
|
||||
- To install the Knative Serving component with the set of observability
|
||||
plugins, enter the following command. The `--selector` flag
|
||||
installs the CRDs first:
|
||||
plugins, enter the following command. The `--selector` flag installs the
|
||||
CRDs first:
|
||||
|
||||
```bash
|
||||
kubectl apply --selector knative.dev/crd-install=true \
|
||||
--filename https://github.com/knative/serving/releases/download/v0.5.0/serving.yaml \
|
||||
--filename https://github.com/knative/serving/releases/download/v0.5.0/monitoring.yaml
|
||||
--filename https://github.com/knative/serving/releases/download/v0.5.0/serving.yaml \
|
||||
--filename https://github.com/knative/serving/releases/download/v0.5.0/monitoring.yaml
|
||||
```
|
||||
|
||||
Then complete the install by running the command again, this time without
|
||||
`--selector knative.dev/crd-install=true`:
|
||||
|
||||
```bash
|
||||
kubectl apply --filename https://github.com/knative/serving/releases/download/v0.5.0/serving.yaml \
|
||||
--filename https://github.com/knative/serving/releases/download/v0.5.0/monitoring.yaml
|
||||
--filename https://github.com/knative/serving/releases/download/v0.5.0/monitoring.yaml
|
||||
```
|
||||
|
||||
* To install all three Knative components and the set of Eventing sources
|
||||
without an observability plugin, enter the following command. The
|
||||
`--selector` flag installs the CRDs first:
|
||||
`--selector` flag installs the CRDs first:
|
||||
|
||||
```bash
|
||||
kubectl apply --selector knative.dev/crd-install=true \
|
||||
--filename https://github.com/knative/serving/releases/download/v0.5.0/serving.yaml \
|
||||
--filename https://github.com/knative/build/releases/download/v0.5.0/build.yaml \
|
||||
--filename https://github.com/knative/eventing/releases/download/v0.5.0/release.yaml \
|
||||
--filename https://github.com/knative/eventing-sources/releases/download/v0.5.0/eventing-sources.yaml \
|
||||
--filename https://raw.githubusercontent.com/knative/serving/v0.5.0/third_party/config/build/clusterrole.yaml
|
||||
```
|
||||
```bash
|
||||
kubectl apply --selector knative.dev/crd-install=true \
|
||||
--filename https://github.com/knative/serving/releases/download/v0.5.0/serving.yaml \
|
||||
--filename https://github.com/knative/build/releases/download/v0.5.0/build.yaml \
|
||||
--filename https://github.com/knative/eventing/releases/download/v0.5.0/release.yaml \
|
||||
--filename https://github.com/knative/eventing-sources/releases/download/v0.5.0/eventing-sources.yaml \
|
||||
--filename https://raw.githubusercontent.com/knative/serving/v0.5.0/third_party/config/build/clusterrole.yaml
|
||||
```
|
||||
|
||||
Then complete the install by running the command again, this time without
|
||||
`--selector knative.dev/crd-install=true`:
|
||||
|
||||
```bash
|
||||
kubectl apply --filename https://github.com/knative/serving/releases/download/v0.5.0/serving.yaml \
|
||||
--filename https://github.com/knative/build/releases/download/v0.5.0/build.yaml \
|
||||
--filename https://github.com/knative/eventing/releases/download/v0.5.0/release.yaml \
|
||||
--filename https://github.com/knative/eventing-sources/releases/download/v0.5.0/eventing-sources.yaml \
|
||||
--filename https://raw.githubusercontent.com/knative/serving/v0.5.0/third_party/config/build/clusterrole.yaml
|
||||
```
|
||||
```bash
|
||||
kubectl apply --filename https://github.com/knative/serving/releases/download/v0.5.0/serving.yaml \
|
||||
--filename https://github.com/knative/build/releases/download/v0.5.0/build.yaml \
|
||||
--filename https://github.com/knative/eventing/releases/download/v0.5.0/release.yaml \
|
||||
--filename https://github.com/knative/eventing-sources/releases/download/v0.5.0/eventing-sources.yaml \
|
||||
--filename https://raw.githubusercontent.com/knative/serving/v0.5.0/third_party/config/build/clusterrole.yaml
|
||||
```
|
||||
|
||||
1. Depending on what you chose to install, view the status of your installation
|
||||
by running one or more of the following commands. It might take a few
|
||||
|
|
|
|||
|
|
@ -209,8 +209,8 @@ your Knative installation, see
|
|||
```
|
||||
|
||||
1. To complete the install of Knative and its dependencies, run the
|
||||
`kubectl apply` command again, this time without the `--selector`
|
||||
flag, to complete the install of Knative and its dependencies:
|
||||
`kubectl apply` command again, this time without the `--selector` flag, to
|
||||
complete the install of Knative and its dependencies:
|
||||
|
||||
```bash
|
||||
kubectl apply --filename https://github.com/knative/serving/releases/download/v0.5.0/serving.yaml \
|
||||
|
|
|
|||
|
|
@ -219,8 +219,8 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
|
|||
```
|
||||
|
||||
1. To complete the install of Knative and its dependencies, run the
|
||||
`kubectl apply` command again, this time without the `--selector`
|
||||
flag, to complete the install of Knative and its dependencies:
|
||||
`kubectl apply` command again, this time without the `--selector` flag, to
|
||||
complete the install of Knative and its dependencies:
|
||||
|
||||
```bash
|
||||
kubectl apply --filename https://github.com/knative/serving/releases/download/v0.5.0/serving.yaml \
|
||||
|
|
|
|||
|
|
@ -145,8 +145,8 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
|
|||
```
|
||||
|
||||
1. To complete the install of Knative and its dependencies, run the
|
||||
`kubectl apply` command again, this time without the `--selector`
|
||||
flag, to complete the install of Knative and its dependencies:
|
||||
`kubectl apply` command again, this time without the `--selector` flag, to
|
||||
complete the install of Knative and its dependencies:
|
||||
|
||||
```bash
|
||||
kubectl apply --filename https://github.com/knative/serving/releases/download/v0.5.0/serving.yaml \
|
||||
|
|
|
|||
|
|
@ -188,10 +188,10 @@ spec:
|
|||
template:
|
||||
spec:
|
||||
containers:
|
||||
- image: docker.io/{username}/helloworld-go
|
||||
env:
|
||||
- name: TARGET
|
||||
value: "Go Sample v1"
|
||||
- image: docker.io/{username}/helloworld-go
|
||||
env:
|
||||
- name: TARGET
|
||||
value: "Go Sample v1"
|
||||
```
|
||||
|
||||
Once the sample code has been created, we'll build and deploy it
|
||||
|
|
|
|||
|
|
@ -130,13 +130,14 @@ Knative: via a one-click "add-on" or manually.
|
|||
|
||||
## Installing Knative using an IKS managed add-on
|
||||
|
||||
The easiest way to install it is using the Managed Knative add-on facility.
|
||||
This one-click install process will install Knative, and Istio if not already
|
||||
The easiest way to install it is using the Managed Knative add-on facility. This
|
||||
one-click install process will install Knative, and Istio if not already
|
||||
installed, and provide automatic updates and lifecycle management of your
|
||||
Knative control plane.
|
||||
|
||||
You can get the add-on via the "Add-ons" tab of your Kubernetes cluster's
|
||||
console page, or via the command line:
|
||||
|
||||
```bash
|
||||
ibmcloud ks cluster-addon-enable -y knative $CLUSTER_NAME
|
||||
```
|
||||
|
|
@ -146,10 +147,10 @@ For more information about the add-on see
|
|||
|
||||
## Manually installing Knative on IKS
|
||||
|
||||
However, if you'd like to install Knative manually, see the instructions
|
||||
below. Kind in mind that if you do not use the add-on mechanism then you will
|
||||
need to manually manage the upgrade of your Istio and Knative installs
|
||||
yourself going forward.
|
||||
However, if you'd like to install Knative manually, see the instructions below.
|
||||
Kind in mind that if you do not use the add-on mechanism then you will need to
|
||||
manually manage the upgrade of your Istio and Knative installs yourself going
|
||||
forward.
|
||||
|
||||
### Installing Istio
|
||||
|
||||
|
|
@ -226,8 +227,8 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
|
|||
```
|
||||
|
||||
1. To complete the install of Knative and its dependencies, run the
|
||||
`kubectl apply` command again, this time without the `--selector`
|
||||
flag, to complete the install of Knative and its dependencies:
|
||||
`kubectl apply` command again, this time without the `--selector` flag, to
|
||||
complete the install of Knative and its dependencies:
|
||||
|
||||
```bash
|
||||
kubectl apply --filename https://github.com/knative/serving/releases/download/v0.5.0/serving.yaml \
|
||||
|
|
|
|||
|
|
@ -131,8 +131,8 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
|
|||
```
|
||||
|
||||
1. To complete the install of Knative and its dependencies, run the
|
||||
`kubectl apply` command again, this time without the `--selector`
|
||||
flag, to complete the install of Knative and its dependencies:
|
||||
`kubectl apply` command again, this time without the `--selector` flag, to
|
||||
complete the install of Knative and its dependencies:
|
||||
|
||||
```bash
|
||||
kubectl apply --filename https://github.com/knative/serving/releases/download/v0.5.0/serving.yaml \
|
||||
|
|
|
|||
|
|
@ -91,8 +91,8 @@ minishift start
|
|||
that is usually after successful start of Minishift
|
||||
- The [addon](https://docs.okd.io/latest/minishift/using/addons.html) **anyuid**
|
||||
allows the `default` service account to run the application with uid `0`
|
||||
- The [addon](https://docs.okd.io/latest/minishift/using/addons.html) **admissions-webhook**
|
||||
allows cluster to register admissions webhooks
|
||||
- The [addon](https://docs.okd.io/latest/minishift/using/addons.html)
|
||||
**admissions-webhook** allows cluster to register admissions webhooks
|
||||
|
||||
- The command `minishift profile set knative` is required every time you start
|
||||
and stop minishift to make sure that you are on right `knative` minishift
|
||||
|
|
|
|||
|
|
@ -119,8 +119,8 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
|
|||
```
|
||||
|
||||
1. To complete the install of Knative and its dependencies, run the
|
||||
`kubectl apply` command again, this time without the `--selector`
|
||||
flag, to complete the install of Knative and its dependencies:
|
||||
`kubectl apply` command again, this time without the `--selector` flag, to
|
||||
complete the install of Knative and its dependencies:
|
||||
|
||||
```bash
|
||||
kubectl apply --filename https://github.com/knative/serving/releases/download/v0.5.0/serving.yaml \
|
||||
|
|
|
|||
|
|
@ -98,8 +98,8 @@ your Knative installation, see
|
|||
```
|
||||
|
||||
1. To complete the install of Knative and its dependencies, run the
|
||||
`kubectl apply` command again, this time without the `--selector`
|
||||
flag, to complete the install of Knative and its dependencies:
|
||||
`kubectl apply` command again, this time without the `--selector` flag, to
|
||||
complete the install of Knative and its dependencies:
|
||||
|
||||
```bash
|
||||
kubectl apply --filename https://github.com/knative/serving/releases/download/v0.5.0/serving.yaml \
|
||||
|
|
|
|||
|
|
@ -56,10 +56,10 @@ spec:
|
|||
template:
|
||||
spec:
|
||||
containers:
|
||||
- image: gcr.io/knative-samples/helloworld-go # The URL to the image of the app
|
||||
env:
|
||||
- name: TARGET # The environment variable printed out by the sample app
|
||||
value: "Go Sample v1"
|
||||
- image: gcr.io/knative-samples/helloworld-go # The URL to the image of the app
|
||||
env:
|
||||
- name: TARGET # The environment variable printed out by the sample app
|
||||
value: "Go Sample v1"
|
||||
```
|
||||
|
||||
If you want to deploy the sample app, leave the config file as-is. If you're
|
||||
|
|
|
|||
|
|
@ -5,18 +5,19 @@ weight: 90
|
|||
type: "docs"
|
||||
---
|
||||
|
||||
Find and use Knative code samples to help you get up and running with common use cases.
|
||||
Code samples include content from the Knative team and community members.
|
||||
Find and use Knative code samples to help you get up and running with common use
|
||||
cases. Code samples include content from the Knative team and community members.
|
||||
|
||||
Browse all code samples to find other languages and use cases that might align closer with your goals.
|
||||
Browse all code samples to find other languages and use cases that might align
|
||||
closer with your goals.
|
||||
|
||||
### Knative owned and maintained
|
||||
|
||||
View the set of Knative code samples that are actively tested and maintained:
|
||||
|
||||
* [Build code samples](./build/samples.md)
|
||||
* [Eventing and Eventing Sources code samples](./eventing/samples/)
|
||||
* [Serving code samples](./serving/samples/README.md)
|
||||
- [Build code samples](./build/samples.md)
|
||||
- [Eventing and Eventing Sources code samples](./eventing/samples/)
|
||||
- [Serving code samples](./serving/samples/README.md)
|
||||
|
||||
### Community owned and maintained
|
||||
|
||||
|
|
@ -24,6 +25,7 @@ View the set of Knative code samples that are actively tested and maintained:
|
|||
|
||||
### External code samples
|
||||
|
||||
A list of links to Knative code samples that live outside of [https://knative.dev](https://knative.dev):
|
||||
A list of links to Knative code samples that live outside of
|
||||
[https://knative.dev](https://knative.dev):
|
||||
|
||||
* *Be the first to link your externally hosted Knative code sample.*
|
||||
- _Be the first to link your externally hosted Knative code sample._
|
||||
|
|
|
|||
|
|
@ -4,19 +4,19 @@ Serving resources and how they can be applied across common use cases.
|
|||
|
||||
[**See all Knative code samples**](../../samples/)
|
||||
|
||||
| Name | Description | Languages |
|
||||
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: |
|
||||
| Name | Description | Languages |
|
||||
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: |
|
||||
| Hello World | A quick introduction that highlights how to deploy an app using Knative Serving. | [C#](./hello-world/helloworld-csharp/README.md), [Go](./hello-world/helloworld-go/README.md), [Java](./hello-world/helloworld-java/README.md), [Kotlin](./hello-world/helloworld-kotlin/README.md), [Node.js](./hello-world/helloworld-nodejs/README.md), [PHP](./hello-world/helloworld-php/README.md), [Python](./hello-world/helloworld-python/README.md), [Ruby](./hello-world/helloworld-ruby/README.md), [Scala](./hello-world/helloworld-scala/README.md), [Shell](./hello-world/helloworld-shell/README.md) |
|
||||
| Advanced Deployment | Simple blue/green-like application deployment pattern illustrating the process of updating a live application without dropping any traffic. | [YAML](./blue-green-deployment.md) |
|
||||
| Autoscale | A demonstration of the autoscaling capabilities of Knative. | [Go](./autoscale-go/README.md) |
|
||||
| Private Repo Build | An example of deploying a Knative Serving Service using a Github deploy-key and a DockerHub image pull secret. | [Go](./build-private-repo-go/README.md) |
|
||||
| Buildpack for Applications | A sample app that demonstrates using Cloud Foundry buildpacks on Knative Serving. | [.NET](./buildpack-app-dotnet/README.md) |
|
||||
| Buildpack for Functions | A sample function that demonstrates using Cloud Foundry buildpacks on Knative Serving. | [Node.js](./buildpack-function-nodejs/README.md) |
|
||||
| Github Webhook | A simple webhook handler that demonstrates interacting with Github. | [Go](./gitwebhook-go/README.md) |
|
||||
| gRPC | A simple gRPC server. | [Go](./grpc-ping-go/README.md) |
|
||||
| Knative Routing | An example of mapping multiple Knative services to different paths under a single domain name using the Istio VirtualService concept. | [Go](./knative-routing-go/README.md) |
|
||||
| Knative Secrets | A simple app that demonstrates how to use a Kubernetes secret as a Volume in Knative. | [Go](./secrets-go/README.md) |
|
||||
| REST API | A simple Restful service that exposes an endpoint defined by an environment variable described in the Knative Configuration. | [Go](./rest-api-go/README.md) |
|
||||
| Telemetry | This sample runs a simple web server that makes calls to other in-cluster services and responds to requests with "Hello World!". The purpose of this sample is to show generating metrics, logs, and distributed traces. | [Go](./telemetry-go/README.md) |
|
||||
| Thumbnailer | An example of deploying a "dockerized" application to Knative Serving which takes video URL as an input and generates its thumbnail image. | [Go](./thumbnailer-go/README.md) |
|
||||
| Traffic Splitting | This samples builds off the [Creating a RESTful Service](./rest-api-go) sample to illustrate applying a revision, then using that revision for manual traffic splitting. | [YAML](./traffic-splitting/README.md) |
|
||||
| Advanced Deployment | Simple blue/green-like application deployment pattern illustrating the process of updating a live application without dropping any traffic. | [YAML](./blue-green-deployment.md) |
|
||||
| Autoscale | A demonstration of the autoscaling capabilities of Knative. | [Go](./autoscale-go/README.md) |
|
||||
| Private Repo Build | An example of deploying a Knative Serving Service using a Github deploy-key and a DockerHub image pull secret. | [Go](./build-private-repo-go/README.md) |
|
||||
| Buildpack for Applications | A sample app that demonstrates using Cloud Foundry buildpacks on Knative Serving. | [.NET](./buildpack-app-dotnet/README.md) |
|
||||
| Buildpack for Functions | A sample function that demonstrates using Cloud Foundry buildpacks on Knative Serving. | [Node.js](./buildpack-function-nodejs/README.md) |
|
||||
| Github Webhook | A simple webhook handler that demonstrates interacting with Github. | [Go](./gitwebhook-go/README.md) |
|
||||
| gRPC | A simple gRPC server. | [Go](./grpc-ping-go/README.md) |
|
||||
| Knative Routing | An example of mapping multiple Knative services to different paths under a single domain name using the Istio VirtualService concept. | [Go](./knative-routing-go/README.md) |
|
||||
| Knative Secrets | A simple app that demonstrates how to use a Kubernetes secret as a Volume in Knative. | [Go](./secrets-go/README.md) |
|
||||
| REST API | A simple Restful service that exposes an endpoint defined by an environment variable described in the Knative Configuration. | [Go](./rest-api-go/README.md) |
|
||||
| Telemetry | This sample runs a simple web server that makes calls to other in-cluster services and responds to requests with "Hello World!". The purpose of this sample is to show generating metrics, logs, and distributed traces. | [Go](./telemetry-go/README.md) |
|
||||
| Thumbnailer | An example of deploying a "dockerized" application to Knative Serving which takes video URL as an input and generates its thumbnail image. | [Go](./thumbnailer-go/README.md) |
|
||||
| Traffic Splitting | This samples builds off the [Creating a RESTful Service](./rest-api-go) sample to illustrate applying a revision, then using that revision for manual traffic splitting. | [YAML](./traffic-splitting/README.md) |
|
||||
|
|
|
|||
|
|
@ -177,7 +177,7 @@ spec:
|
|||
autoscaling.knative.dev/metric: cpu
|
||||
spec:
|
||||
containers:
|
||||
- image: gcr.io/knative-samples/autoscale-go:0.1
|
||||
- image: gcr.io/knative-samples/autoscale-go:0.1
|
||||
```
|
||||
|
||||
Additionally the autoscaler targets and scaling bounds can be specified in
|
||||
|
|
@ -204,7 +204,7 @@ spec:
|
|||
autoscaling.knative.dev/maxScale: "100"
|
||||
spec:
|
||||
containers:
|
||||
- image: gcr.io/knative-samples/autoscale-go:0.1
|
||||
- image: gcr.io/knative-samples/autoscale-go:0.1
|
||||
```
|
||||
|
||||
Note: for an `hpa.autoscaling.knative.dev` class service, the
|
||||
|
|
|
|||
|
|
@ -69,20 +69,20 @@ metadata:
|
|||
spec:
|
||||
template:
|
||||
spec:
|
||||
- containers:
|
||||
# Replace {DOCKER_HUB_USERNAME} with your actual docker hub username
|
||||
image: docker.io/{DOCKER_HUB_USERNAME}/gitwebhook-go
|
||||
env:
|
||||
- name: SECRET_TOKEN
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: githubsecret
|
||||
key: secretToken
|
||||
- name: ACCESS_TOKEN
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: githubsecret
|
||||
key: accessToken
|
||||
- containers:
|
||||
# Replace {DOCKER_HUB_USERNAME} with your actual docker hub username
|
||||
image: docker.io/{DOCKER_HUB_USERNAME}/gitwebhook-go
|
||||
env:
|
||||
- name: SECRET_TOKEN
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: githubsecret
|
||||
key: secretToken
|
||||
- name: ACCESS_TOKEN
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: githubsecret
|
||||
key: accessToken
|
||||
```
|
||||
|
||||
1. Use `kubectl` to apply the `service.yaml` file.
|
||||
|
|
|
|||
|
|
@ -96,10 +96,10 @@ recreate the source files from this folder.
|
|||
template:
|
||||
spec:
|
||||
containers:
|
||||
- image: docker.io/{username}/helloworld-csharp
|
||||
env:
|
||||
- name: TARGET
|
||||
value: "C# Sample v1"
|
||||
- image: docker.io/{username}/helloworld-csharp
|
||||
env:
|
||||
- name: TARGET
|
||||
value: "C# Sample v1"
|
||||
```
|
||||
|
||||
## Building and deploying the sample
|
||||
|
|
|
|||
|
|
@ -97,10 +97,10 @@ recreate the source files from this folder.
|
|||
template:
|
||||
spec:
|
||||
containers:
|
||||
- image: docker.io/{username}/helloworld-go
|
||||
env:
|
||||
- name: TARGET
|
||||
value: "Go Sample v1"
|
||||
- image: docker.io/{username}/helloworld-go
|
||||
env:
|
||||
- name: TARGET
|
||||
value: "Go Sample v1"
|
||||
```
|
||||
|
||||
## Building and deploying the sample
|
||||
|
|
|
|||
|
|
@ -41,9 +41,8 @@ recreate the source files from this folder.
|
|||
|
||||
4. In your project directory, create a file named `Dockerfile` and copy the code
|
||||
block below into it. For detailed instructions on dockerizing a Spark Java
|
||||
app, see
|
||||
[Spark with Docker](http://sparkjava.com/tutorials/docker).
|
||||
For additional information on multi-stage docker builds for Java see
|
||||
app, see [Spark with Docker](http://sparkjava.com/tutorials/docker). For
|
||||
additional information on multi-stage docker builds for Java see
|
||||
[Creating Smaller Java Image using Docker Multi-stage Build](http://blog.arungupta.me/smaller-java-image-docker-multi-stage-build/).
|
||||
|
||||
```docker
|
||||
|
|
@ -169,9 +168,8 @@ folder) you're ready to build and deploy the sample app.
|
|||
--output jsonpath={.status.domain})
|
||||
```
|
||||
|
||||
6. Now you can make a request to your app to see the result. Presuming,
|
||||
the IP address you got in the step above is in the `${IP_ADDRESS}`
|
||||
env variable:
|
||||
6. Now you can make a request to your app to see the result. Presuming, the IP
|
||||
address you got in the step above is in the `${IP_ADDRESS}` env variable:
|
||||
|
||||
```shell
|
||||
curl -H "Host: ${DOMAIN_NAME}" http://${IP_ADDRESS}
|
||||
|
|
|
|||
|
|
@ -124,10 +124,10 @@ recreate the source files from this folder.
|
|||
template:
|
||||
spec:
|
||||
containers:
|
||||
- image: docker.io/{username}/helloworld-java-spring
|
||||
env:
|
||||
- name: TARGET
|
||||
value: "Spring Boot Sample v1"
|
||||
- image: docker.io/{username}/helloworld-java-spring
|
||||
env:
|
||||
- name: TARGET
|
||||
value: "Spring Boot Sample v1"
|
||||
```
|
||||
|
||||
## Building and deploying the sample
|
||||
|
|
|
|||
|
|
@ -145,10 +145,10 @@ recreate the source files from this folder.
|
|||
template:
|
||||
spec:
|
||||
containers:
|
||||
- image: docker.io/{username}/helloworld-kotlin
|
||||
env:
|
||||
- name: TARGET
|
||||
value: "Kotlin Sample v1"
|
||||
- image: docker.io/{username}/helloworld-kotlin
|
||||
env:
|
||||
- name: TARGET
|
||||
value: "Kotlin Sample v1"
|
||||
```
|
||||
|
||||
## Build and deploy this sample
|
||||
|
|
|
|||
|
|
@ -119,10 +119,10 @@ recreate the source files from this folder.
|
|||
template:
|
||||
spec:
|
||||
containers:
|
||||
- image: docker.io/{username}/helloworld-nodejs
|
||||
env:
|
||||
- name: TARGET
|
||||
value: "Node.js Sample v1"
|
||||
- image: docker.io/{username}/helloworld-nodejs
|
||||
env:
|
||||
- name: TARGET
|
||||
value: "Node.js Sample v1"
|
||||
```
|
||||
|
||||
## Building and deploying the sample
|
||||
|
|
|
|||
|
|
@ -66,10 +66,10 @@ recreate the source files from this folder.
|
|||
template:
|
||||
spec:
|
||||
containers:
|
||||
- image: docker.io/{username}/helloworld-php
|
||||
env:
|
||||
- name: TARGET
|
||||
value: "PHP Sample v1"
|
||||
- image: docker.io/{username}/helloworld-php
|
||||
env:
|
||||
- name: TARGET
|
||||
value: "PHP Sample v1"
|
||||
```
|
||||
|
||||
## Building and deploying the sample
|
||||
|
|
|
|||
|
|
@ -79,10 +79,10 @@ recreate the source files from this folder.
|
|||
template:
|
||||
spec:
|
||||
containers:
|
||||
- image: docker.io/{username}/helloworld-python
|
||||
env:
|
||||
- name: TARGET
|
||||
value: "Python Sample v1"
|
||||
- image: docker.io/{username}/helloworld-python
|
||||
env:
|
||||
- name: TARGET
|
||||
value: "Python Sample v1"
|
||||
```
|
||||
|
||||
## Build and deploy this sample
|
||||
|
|
|
|||
|
|
@ -88,10 +88,10 @@ recreate the source files from this folder.
|
|||
template:
|
||||
spec:
|
||||
containers:
|
||||
- image: docker.io/{username}/helloworld-ruby
|
||||
env:
|
||||
- name: TARGET
|
||||
value: "Ruby Sample v1"
|
||||
- image: docker.io/{username}/helloworld-ruby
|
||||
env:
|
||||
- name: TARGET
|
||||
value: "Ruby Sample v1"
|
||||
```
|
||||
|
||||
## Build and deploy this sample
|
||||
|
|
|
|||
|
|
@ -63,12 +63,12 @@ spec:
|
|||
template:
|
||||
spec:
|
||||
containers:
|
||||
- image: "your_repository_name/helloworld-scala:0.0.1"
|
||||
env:
|
||||
- name: MESSAGE
|
||||
value: "Scala & Akka on Knative says hello!"
|
||||
- name: HOST
|
||||
value: "localhost"
|
||||
- image: "your_repository_name/helloworld-scala:0.0.1"
|
||||
env:
|
||||
- name: MESSAGE
|
||||
value: "Scala & Akka on Knative says hello!"
|
||||
- name: HOST
|
||||
value: "localhost"
|
||||
```
|
||||
|
||||
## Publishing to Docker
|
||||
|
|
|
|||
|
|
@ -88,10 +88,10 @@ recreate the source files from this folder.
|
|||
template:
|
||||
spec:
|
||||
containers:
|
||||
- image: docker.io/{username}/helloworld-shell
|
||||
env:
|
||||
- name: TARGET
|
||||
value: "Shell Sample v1"
|
||||
- image: docker.io/{username}/helloworld-shell
|
||||
env:
|
||||
- name: TARGET
|
||||
value: "Shell Sample v1"
|
||||
```
|
||||
|
||||
## Building and deploying the sample
|
||||
|
|
|
|||
|
|
@ -161,25 +161,25 @@ recreate the source files from this folder.
|
|||
spec:
|
||||
containers:
|
||||
# Replace {username} with your DockerHub username
|
||||
- image: docker.io/{username}/secrets-go
|
||||
- image: docker.io/{username}/secrets-go
|
||||
|
||||
env:
|
||||
# This directs the Google Cloud SDK to use the identity and project
|
||||
# defined by the Service Account (aka robot) in the JSON file at
|
||||
# this path.
|
||||
# - `/var/secret` is determined by the `volumeMounts[0].mountPath`
|
||||
# below. This can be changed if both places are changed.
|
||||
# - `robot.json` is determined by the "key" that is used to hold the
|
||||
# secret content in the Kubernetes secret. This can be changed
|
||||
# if both places are changed.
|
||||
- name: GOOGLE_APPLICATION_DEFAULT
|
||||
value: /var/secret/robot.json
|
||||
env:
|
||||
# This directs the Google Cloud SDK to use the identity and project
|
||||
# defined by the Service Account (aka robot) in the JSON file at
|
||||
# this path.
|
||||
# - `/var/secret` is determined by the `volumeMounts[0].mountPath`
|
||||
# below. This can be changed if both places are changed.
|
||||
# - `robot.json` is determined by the "key" that is used to hold the
|
||||
# secret content in the Kubernetes secret. This can be changed
|
||||
# if both places are changed.
|
||||
- name: GOOGLE_APPLICATION_DEFAULT
|
||||
value: /var/secret/robot.json
|
||||
|
||||
# This section specified where in the container we want the
|
||||
# volume containing our secret to be mounted.
|
||||
volumeMounts:
|
||||
- name: robot-secret
|
||||
mountPath: /var/secret
|
||||
# This section specified where in the container we want the
|
||||
# volume containing our secret to be mounted.
|
||||
volumeMounts:
|
||||
- name: robot-secret
|
||||
mountPath: /var/secret
|
||||
|
||||
# This section attaches the secret "google-robot-secret" to
|
||||
# the Pod holding the user container.
|
||||
|
|
|
|||
|
|
@ -15,10 +15,10 @@ cd $GOPATH/src/github.com/knative/docs
|
|||
## Using the `traffic:` block
|
||||
|
||||
The service was originally created without a `traffic:` block, which means that
|
||||
it will automatically deploy the latest updates as they become ready. To split
|
||||
it will automatically deploy the latest updates as they become ready. To split
|
||||
traffic between multiple Revisions, we will start to use a customized `traffic:`
|
||||
block. The `traffic:` block enables users to split traffic over any number of
|
||||
fixed Revisions, or the floating "latest revision" for the Service. It also
|
||||
block. The `traffic:` block enables users to split traffic over any number of
|
||||
fixed Revisions, or the floating "latest revision" for the Service. It also
|
||||
enables users to name the specific sub-routes, so that they can be directly
|
||||
addressed for qualification or debugging.
|
||||
|
||||
|
|
@ -26,7 +26,7 @@ The first thing we will do is look at the traffic block that was defaulted for
|
|||
us in the previous sample:
|
||||
|
||||
1. Fetch the state of the Service, and note the `traffic:` block that will run
|
||||
the latest ready revision, each time we update our template. Also note that
|
||||
the latest ready revision, each time we update our template. Also note that
|
||||
under `status:` we see a specific `revisionName:` here, which is what it has
|
||||
resolved to (in this case the name we asked for).
|
||||
|
||||
|
|
@ -71,10 +71,10 @@ kubectl get ksvc stock-service-example --output yaml
|
|||
|
||||
This section describes how to create a new Revision by updating your Service.
|
||||
|
||||
A new Revision is created every time a value in the `template` section
|
||||
of the Service `spec` is updated. The `updated_sample.yaml` in this folder
|
||||
changes the environment variable `RESOURCE` from `stock` to `share`. Applying
|
||||
this change will result in a new Revision.
|
||||
A new Revision is created every time a value in the `template` section of the
|
||||
Service `spec` is updated. The `updated_sample.yaml` in this folder changes the
|
||||
environment variable `RESOURCE` from `stock` to `share`. Applying this change
|
||||
will result in a new Revision.
|
||||
|
||||
For comparison, you can diff the `release_sample.yaml` with the
|
||||
`updated_sample.yaml`.
|
||||
|
|
@ -90,10 +90,10 @@ serving/samples/traffic-splitting/updated_sample.yaml
|
|||
kubectl apply --filename serving/samples/traffic-splitting/updated_sample.yaml
|
||||
```
|
||||
|
||||
2. With our `traffic` block, traffic will _not_ shift to the new
|
||||
Revision automatically. However, it will be available via the URL associated
|
||||
with our `latest` sub-route. This can be verified through the Service status,
|
||||
by finding the entry of `status.traffic` for `latest`:
|
||||
2. With our `traffic` block, traffic will _not_ shift to the new Revision
|
||||
automatically. However, it will be available via the URL associated with our
|
||||
`latest` sub-route. This can be verified through the Service status, by
|
||||
finding the entry of `status.traffic` for `latest`:
|
||||
|
||||
```shell
|
||||
kubectl get ksvc stock-service-example --output yaml
|
||||
|
|
@ -102,8 +102,8 @@ kubectl get ksvc stock-service-example --output yaml
|
|||
3. The readiness of the Service can be verified through the Service Conditions.
|
||||
When the Service conditions report it is ready again, you can access the new
|
||||
Revision using the same method as found in the
|
||||
[previous sample](../rest-api-go/README.md#access-the-service) using
|
||||
the Service hostname found above.
|
||||
[previous sample](../rest-api-go/README.md#access-the-service) using the
|
||||
Service hostname found above.
|
||||
|
||||
```shell
|
||||
# Replace "latest" with whichever tag for which we want the hostname.
|
||||
|
|
|
|||
Loading…
Reference in New Issue