Source for the site
Clone or download
vadimeisenbergibm and frankbu An example of configuring access to an external legacy HTTPS proxy (#…

* initial version

* ServiceEntry -> service entry (in text)

* config map -> `ConfigMap`

* fix a link

* task -> example

* through such proxy -> through it

* elaborate what has been done after the proxy is deployed and tested

* split a long line

* explain why there is no need to define service entries for external services accessed through the proxy

* rewrite the sentence about simulating the proxy outside the cluster

* check the log and see your request -> check the log for your request

* HTTP CONNECT method -> the HTTP CONNECT method

* between the application and the proxies -> between the application and the proxy

* add explanation how this example is different from other egress examples
Latest commit 79cd5ce Dec 11, 2018

This repository contains the source code for the, and sites.

Please see the main Istio README file to learn about the overall Istio project and how to get in touch with us. To learn how you can contribute to any of the Istio components, please see the Istio contribution guidelines.

Editing and testing content

We use Hugo to generate our sites. To build and test the site locally, we use a docker image that contains Hugo. To build and serve the site, simply go to the root of the tree and do:

$ make serve

This will build the site and start a web server hosting the site. You can then connect to the web server at http://localhost:1313.

All normal content for the site is located in the content directory, as well as in sibling translated directories such as content_zh.


We use linters to ensure some base quality to the site's content. We currently run 3 linters as a precommit requirement:

  • HTML proofing, which ensures all your links are valid along with other checks.

  • Spell checking.

  • Style checking, which makes sure your markdown files comply with our common style rules.

You can run these linters locally using:

$ make build
$ make gen
$ make lint

If you get spelling errors, you have three choices to address each:

  • It's a real typo, so fix your markdown.

  • It's a command/field/symbol name, so stick some backticks around it.

  • It's really valid, so go add the word to the .spelling file at the root of the repo.

Site infrastructure

Here's how things work:

  • Primary site content is in the content directory. This is mostly markdown files which Hugo processes into HTML.

  • Additional site content is in the static directory. These are files that Hugo directly copies to the site without any processing.

  • The src directory contains the source material for certain files from the static directory. You use

    $ make build

    to build the material from the src directory and refresh what's in the static directory.

Versions and releases

Istio maintains three variations of its public site.

  • is the main site, showing documentation for the current release of the product.

  • contains snapshots of the documentation for previous releases of the product. This is useful for customers still using these older releases.

  • contains the actively updated documentation for the next release of the product.

The user can trivially navigate between the different variations of the site using the gear menu in the top right of each page. All three sites are hosted on Netlify.

How versioning works

  • Documentation changes are primarily committed to the master branch of Changes committed to this branch are automatically reflected on

  • The content of is taken from the latest release-XXX branch. The specific branch that is used is determined by the Netlify project's configuration.

  • The content of is taken from the older release-XXX branches. The set of branches that are included on is determined by the TOBUILD variable in this script

The above means that if you want to do a change to the main site, you need to make the change in the master branch of and then merge that change into the current release branch.

Publishing content immediately

Checking in updates to the master branch will automatically update, and will only be reflected on the next time a release is created, which can be several weeks in the future. If you'd like some changes to be immediately reflected on, you need to check your changes both to the master branch and to the current release branch (named release-XXX such as release-0.7).

Creating a version

Here are the steps necessary to create a new documentation version. Let's assume the current version of Istio is 0.6 and you wish to introduce 0.7 which has been under development.

Creating the release branch

  1. Switch to the istio/ repo and make sure everything is up to date.

  2. Create a new release branch off of master, named as release-major.minor, which in this case would be release-0.7. There is one such branch for every release.

  3. In the release branch you created, edit the file data/args.yml. Set the preliminary field to false and the source_branch_name and doc_branch_name fields to the name of the branch, in this case release-0.7.

  4. Commit the previous edit to your local git repo and push your release branch to GitHub.


  1. Switch to the istio/ repo and make sure everything is up to date.

  2. In the master branch, edit the file data/releases.yml and add a new entry at the top of the file for version 0.8. You'll need to make sure the URLs are updated for the first few entries. The top entry (0.8) should point to The second entry (0.7) should point to The third and subsequent entries should point to

  3. In the master branch, edit the file data/args.yml and update the version and full_version fields to have the version of the next Istio release. In this case, you would set the fields to 0.8 and 0.8.0 respectively.

  4. Commit the previous edits to your local git repo and push the master branch to GitHub.

  5. Wait a while (~2 minutes) and browse to make sure everything looks good.


  1. Go to the project on Netlify

  2. Change the branch that is built from the previous release's branch to the new release branch, in this case release-0.7

  3. Select the option to trigger an immediate rebuild and redeployment.

  4. Once deployment is done, browse and make sure everything looks good.


  1. Switch to the istio/ repo and make sure everything is up to date.

  2. Go to the Google Custom Search Engine and do the following:

    • Download the CSE context file from the Advanced tab.

    • Add a new FacetItem at the top of the file containing the previous release's version number. In this case, this would be "V0.6".

    • Upload the updated CSE context file to the site.

    • In the Setup section, add a new site that covers the previous release's archive directory. In this case, the site URL would be*. Set the label of this site to the name of the facet item created above (V0.6 in this case).

  3. In the previous release's branch (in this case release-0.6), edit the file data/args.yml. Set the archive field to true and the archive_date field to the current date.

  4. Commit the previous edit to your local git repo and push the *previous release's branch to GitHub.

  5. Switch to the istio/admin-sites repo.

  6. Edit the script to add the newest archive version (in this case release-0.6) to the TOBUILD variable.

  7. Commit the previous edit to your local git repo and push the change to GitHub.

  8. Wait a while (~10 minutes) and browse and make sure everything looks good.