Site improvements (#3430)

- Add linter support to detect internal links to aliases. Those are now flagged as bad links so the source needs to be updated to point to the real destination, avoiding the user a redirect. - Fixed occurences of links to aliases. - Now only load popper.js on pages that use popups in order to improve load times.
2019-02-28 13:58:54 -08:00 · 2019-02-28 13:58:54 -08:00 · dd0ecdf9ab
parent 10415287c8
commit dd0ecdf9ab
17 changed files with 34 additions and 26 deletions
--- a/.circleci/config.yml
+++ b/.circleci/config.yml
@ -11,7 +11,7 @@ jobs:

      - run:
          name: Generating Site
-          command: scripts/gen_site.sh "" -no_minify
+          command: scripts/gen_site.sh "" -no_minify -no_aliases

      - run:
          name: Running Linters
--- a/4
+++ b/4
@ -16,7 +16,7 @@ build:
 	$(docker) scripts/build_site.sh

 gen:
-	$(docker) scripts/gen_site.sh ""
+	$(docker) scripts/gen_site.sh "" -minify -no_aliases

 lint:
 	$(docker) scripts/lint_site.sh
@ -25,4 +25,4 @@ serve:
 	docker run -t -i --sig-proxy=true --rm -v $(shell pwd):/site -w /site -p 1313:1313 $(img) hugo serve --baseURL "http://${ISTIO_SERVE_DOMAIN}:1313/" --bind 0.0.0.0 --disableFastRender

 netlify:
-	scripts/gen_site.sh "$(baseurl)"
+	scripts/gen_site.sh "$(baseurl)" -minify -aliases
--- a/content/about/feature-stages/index.md
+++ b/content/about/feature-stages/index.md
@ -44,7 +44,7 @@ Below is our list of existing features and their current phases. This informatio
 | Feature           | Phase
 |-------------------|-------------------
 | [Prometheus Integration](/docs/tasks/telemetry/querying-metrics/) | Stable
-| [Local Logging (STDIO)](/docs/examples/telemetry/) | Stable
+| [Local Logging (STDIO)](/docs/tasks/telemetry/) | Stable
 | [Statsd Integration](/docs/reference/config/policy-and-telemetry/adapters/statsd/) | Stable
 | [Client and Server Telemetry Reporting](/docs/concepts/policies-and-telemetry/) | Stable
 | [Service Dashboard in Grafana](/docs/tasks/telemetry/using-istio-dashboard/) | Beta
--- a/content/blog/2018/traffic-mirroring/index.md
+++ b/content/blog/2018/traffic-mirroring/index.md
@ -9,7 +9,7 @@ keywords: [traffic-management,mirroring]

 Trying to enumerate all the possible combinations of test cases for testing services in non-production/test environments can be daunting. In some cases, you'll find that all of the effort that goes into cataloging these use cases doesn't match up to real production use cases. Ideally, we could use live production use cases and traffic to help illuminate all of the feature areas of the service under test that we might miss in more contrived testing environments.

-Istio can help here. With the release of [Istio 0.5.0](/about/notes/0.5/), Istio can mirror traffic to help test your services. You can write route rules similar to the following to enable traffic mirroring:
+Istio can help here. With the release of [Istio 0.5.0](/about/notes/older/0.5/), Istio can mirror traffic to help test your services. You can write route rules similar to the following to enable traffic mirroring:

 {{< text yaml >}}
 apiVersion: config.istio.io/v1alpha2
--- a/content/docs/concepts/security/index.md
+++ b/content/docs/concepts/security/index.md
@ -100,7 +100,7 @@ Istio provides a more comprehensive security solution, including authentication,

 ## PKI

-The Istio PKI is built on top of Istio Citadel and securely provisions strong workload identities to every workload.
+The Istio PKI is built on top of Istio Citadel and securely provisions strong identities to every workload.
 Istio uses X.509 certificates to carry the identities in [SPIFFE](https://spiffe.io/) format.
 The PKI also automates the key & certificate rotation at scale.

@ -122,7 +122,7 @@ Currently we use different certificate key provisioning mechanisms for each scen
   which defines what service account or accounts can run a certain service.
   Pilot then passes the secure naming information to the sidecar Envoy.

-### on-premises machines scenario
+### On-premises machines scenario

 1. Citadel creates a gRPC service to take [Certificate Signing Requests](https://en.wikipedia.org/wiki/Certificate_signing_request) (CSRs).

@ -135,7 +135,7 @@ Currently we use different certificate key provisioning mechanisms for each scen

 1. The above CSR process repeats periodically for certificate and key rotation.

-### Node Agent in Kubernetes
+### Node agent in Kubernetes

 Istio provides the option of using node agent in Kubernetes for certificate and key provisioning, as shown in the figure below.
 Note that the identity provisioning flow for on-premises machines will be similar in the near future, we only describe the Kubernetes scenario here.
@ -165,7 +165,7 @@ In this section, we provide a few deployment guidelines and discuss a real-world
 If there are multiple service operators (a.k.a. [SREs](https://en.wikipedia.org/wiki/Site_reliability_engineering))
 deploying different services in a medium- or large-size cluster, we recommend creating a separate
 [Kubernetes namespace](https://kubernetes.io/docs/tasks/administer-cluster/namespaces-walkthrough/) for each SRE team to isolate their access.
- For example, you can create a `team1-ns` namespace for `team1`, and `team2-ns` namespace for `team2`, such
+For example, you can create a `team1-ns` namespace for `team1`, and `team2-ns` namespace for `team2`, such
 that both teams cannot access each other's services.

 {{< warning >}}
@ -310,7 +310,7 @@ the request. For mutual TLS, Istio provides a [destination rule](/docs/concepts/
 The operator can use the destination rule to instruct client proxies to make
 initial connections using TLS with the certificates expected on the server
 side. You can find out more about how mutual TLS works in Istio in
-[PKI and identity section](/docs/concepts/security/mutual-tls/).
+[Mutual TLS authentication](/docs/concepts/security/#mutual-tls-authentication).

 {{< image width="60%" link="./authn.svg" caption="Authentication Architecture" >}}

--- a/content/docs/reference/commands/istioctl/index.html
+++ b/content/docs/reference/commands/istioctl/index.html
@ -945,7 +945,7 @@ istioctl verify-install -f istio-demo.yaml
 </code></pre>
 <h2 id="istioctl-kube-inject">istioctl kube-inject</h2>
 <p></p>
-<p>kube-inject manually injects envoy sidecar into kubernetes
+<p>kube-inject manually injects the Envoy sidecar into Kubernetes
 workloads. Unsupported resources are left unmodified so it is safe to
 run kube-inject over a single file that contains multiple Service,
 ConfigMap, Deployment, etc. definitions for a complex application. Its
@ -1112,7 +1112,7 @@ istioctl kube-inject -f deployment.yaml -o deployment-injected.yaml
 kubectl get deployment -o yaml | istioctl kube-inject -f - | kubectl apply -f -

 # Create a persistent version of the deployment with Envoy sidecar
-# injected configuration from kubernetes configmap &#39;istio-inject&#39;
+# injected configuration from Kubernetes configmap &#39;istio-inject&#39;
 istioctl kube-inject -f deployment.yaml -o deployment-injected.yaml --injectConfigMapName istio-inject

 </code></pre>
--- a/content/docs/reference/config/policy-and-telemetry/adapters/cloudwatch/index.html
+++ b/content/docs/reference/config/policy-and-telemetry/adapters/cloudwatch/index.html
@ -20,9 +20,6 @@ number_of_entries: 4
 <p>To push metrics and logs to CloudWatch using this adapter you must provide AWS credentials to the AWS SDK.
 (see <a href="https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/setup-credentials.html">AWS docs</a>).</p>

-<p>To activate the CloudWatch adapter, operators need to provide configuration for the
-<a href="/docs/reference/config/adapters/cloudwatch.html">cloudwatch adapter</a>.</p>
-
 <p>The handler configuration must contain the same metrics as the instance configuration.
 The metrics specified in both instance and handler configurations will be sent to CloudWatch.</p>

--- a/content/docs/reference/config/policy-and-telemetry/templates/edge/index.html
+++ b/content/docs/reference/config/policy-and-telemetry/templates/edge/index.html
@ -16,11 +16,10 @@ number_of_entries: 1

 <p>When writing the configuration, the value for the fields associated
 with this template can either be a literal or an
-<a href="/docs/reference/config/mixer/expression-language.html">expression</a>. Please
+<a href="/docs/reference/config/policy-and-telemetry/expression-language/">expression</a>. Please
 note that if the datatype of a field is not
 istio.mixer.adapter.model.v1beta1.Value, then the expression&rsquo;s
-<a href="/docs/reference/config/policy-and-telemetry/expression-language/#type-checking">inferred
-type</a>
+<a href="/docs/reference/config/policy-and-telemetry/expression-language/#type-checking">inferred type</a>
 must match the datatype of the field.</p>

 <p>Example config:</p>
--- a/content/docs/tasks/security/mtls-migration/index.md
+++ b/content/docs/tasks/security/mtls-migration/index.md
@ -26,7 +26,7 @@ down once the migration is done.

 ## Before you begin

-* Understand Istio [authentication policy](/docs/concepts/security/authn-policy/) and related [mutual TLS authentication](/docs/concepts/security/mutual-tls/) concepts.
+* Understand Istio [authentication policy](/docs/concepts/security/#authentication-policies) and related [mutual TLS authentication](/docs/concepts/security/#mutual-tls-authentication) concepts.

 * Have a Kubernetes cluster with Istio installed, without global mutual TLS enabled (e.g use `install/kubernetes/istio-demo.yaml` as described in [installation steps](/docs/setup/kubernetes/quick-start/#installation-steps), or set `global.mtls.enabled` to false using [Helm](/docs/setup/kubernetes/helm-install/)).

--- a/content/docs/tasks/security/rbac-groups/index.md
+++ b/content/docs/tasks/security/rbac-groups/index.md
@ -12,7 +12,7 @@ authorization and the authorization of list-typed claims in Istio.

 * Read the [authorization](/docs/concepts/security/#authorization) concept
 and go through the guide on how to
-[configure Istio authorization](/docs/tasks/security/role-based-access-control).
+[configure Istio authorization](/docs/tasks/security/authz-http).

 * Read the Istio
 [authentication policy](/docs/concepts/security/#authentication-policies)
--- a/content_zh/blog/2018/istio-authorization/index.md
+++ b/content_zh/blog/2018/istio-authorization/index.md
@ -62,7 +62,7 @@ keywords: [authorization,Role Based Access Control,security]

 ## 示例

-[授权任务](/zh/docs/tasks/security/role-based-access-control/)向您展示如何操作使用 Istio 的授权功能来控制命名空间级别
+[授权任务](/zh/docs/tasks/security/authz-http/)向您展示如何操作使用 Istio 的授权功能来控制命名空间级别
 和服务级别访问 [Bookinfo 应用](/zh/docs/examples/bookinfo/)。在本节中，您将看到有关如何实现的更多示例使用 Istio 授权进行
 微分割。

--- a/content_zh/docs/tasks/security/mtls-migration/index.md
+++ b/content_zh/docs/tasks/security/mtls-migration/index.md
@ -135,7 +135,7 @@ $ for from in "foo" "bar" "legacy"; do kubectl exec $(kubectl get pod -l app=sle
 503
 {{< /text >}}

-也就是说，如果不能把所有服务都迁移到 Istio (进行 Sidecar 注入)的话，就只能使用 `PERMISSIVE` 模式了。然而在配置为 `PERMISSIVE` 的时候，是不会对明文流量进行授权和鉴权方面的检查的。我们推荐使用 [RBAC](/zh/docs/tasks/security/role-based-access-control/) 来给不同的路径配置不同的授权策略。
+也就是说，如果不能把所有服务都迁移到 Istio (进行 Sidecar 注入)的话，就只能使用 `PERMISSIVE` 模式了。然而在配置为 `PERMISSIVE` 的时候，是不会对明文流量进行授权和鉴权方面的检查的。我们推荐使用 [RBAC](/zh/docs/tasks/security/authz-http/) 来给不同的路径配置不同的授权策略。

 ## 清理

--- a/content_zh/docs/tasks/security/rbac-groups/index.md
+++ b/content_zh/docs/tasks/security/rbac-groups/index.md
@ -9,7 +9,7 @@ keywords: [security,authorization]

 ## 开始之前

-* 阅读[授权](/zh/docs/concepts/security/#授权和鉴权)概念并阅读有关如何配置 [Istio 授权的指南](/zh/docs/tasks/security/role-based-access-control)。
+* 阅读[授权](/zh/docs/concepts/security/#授权和鉴权)概念并阅读有关如何配置 [Istio 授权的指南](/zh/docs/tasks/security/authz-http)。

 * 阅读 Istio 身份[验证策略](/zh/docs/concepts/security/#认证策略)和相关的[双向 TLS 身份验证](/zh/docs/concepts/security/#双向-tls-认证)概念。

--- a/content_zh/help/faq/security/k8s-health-checks.md
+++ b/content_zh/help/faq/security/k8s-health-checks.md
@ -8,7 +8,7 @@ weight: 50
 ，因此当这个模式打开时他们可以接受 http 和双向 TLS 流量。这可以解决健康检查问题。
 请记住，双向 TLS 没有强制执行，因为其他服务可以使用 http 流量与该服务进行通信。

-您可以使用单独的端口进行健康检查，并只在常规服务端口上启用双向 TLS。请参阅 [Istio 服务的健康检查](/docs/tasks/traffic-management/app-health-check/)了解更多信息。
+您可以使用单独的端口进行健康检查，并只在常规服务端口上启用双向 TLS。请参阅 [Istio 服务的健康检查](/help/ops/setup/app-health-check/)了解更多信息。

 另一种解决方法是对健康检查使用 [liveness 命令](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-liveness-command)，例如，可以在服务 Pod 中安装 `curl` 并在 Pod 内对自身执行 `curl` 操作。

--- a/layouts/_default/baseof.html
+++ b/layouts/_default/baseof.html
@ -126,8 +126,7 @@
            const buttonDownload = '{{ i18n "button_download" }}';
        </script>

-        <!-- libraries we pull in -->
-        <script src="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.14.7/umd/popper.min.js" defer></script>
+        <!-- libraries we unconditionally pull in -->
        <script src="https://www.google.com/cse/brand?form=search-form" defer></script>

        <!-- our own stuff -->
@ -137,6 +136,11 @@
        {{ block "main" . }}{{ end }}
        {{ partial "footer.html" . }}

+        <!-- libraries we conditionally pull in -->
+        {{ if .Scratch.Get "needPopper" }}
+            <script src="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.14.7/umd/popper.min.js" defer></script>
+        {{ end }}
+
        <div id="scroll-to-top-container">
            <button id="scroll-to-top" aria-hidden="true" title='{{ i18n "button_top"}}'>
                {{ partial "icon.html" "top" }}
--- a/layouts/shortcodes/gloss.html
+++ b/layouts/shortcodes/gloss.html
@ -1,3 +1,5 @@
+{{ .Page.Scratch.Set "needPopper" true }}
+
 {{- $position := .Position }}
 {{- $term := .Inner -}}
 {{- $gloss_entry := $term -}}
--- a/scripts/gen_site.sh
+++ b/scripts/gen_site.sh
@ -3,6 +3,12 @@ set -e

 hugo version

+if [[ "$3" == "-no_aliases" ]]
+then
+    HUGO_DISABLEALIASES=true
+    export HUGO_DISABLEALIASES
+fi
+
 if [[ "$2" == "-no_minify" ]]
 then
    hugo --baseURL "$1"