From df0b163f3f1b7273f20d2acc2e3ce2953050a40a Mon Sep 17 00:00:00 2001 From: Mark Mandel Date: Mon, 28 Oct 2019 11:55:51 -0700 Subject: [PATCH] Replace `>` quoted text with alert shortcodes (#1152) Now that we've updates docsy, we can use the alert shortcodes for notes, tips and warnings - because they are prettier, and easier to see. --- .../Advanced/scheduling-and-autoscaling.md | 4 ++- site/content/en/docs/Contribute/_index.md | 5 ++- .../en/docs/Getting Started/create-fleet.md | 12 +++++-- .../docs/Getting Started/create-gameserver.md | 12 +++++-- .../edit-first-gameserver-go.md | 5 +-- .../en/docs/Guides/Client SDKs/_index.md | 8 +++-- .../en/docs/Guides/Client SDKs/local.md | 4 ++- .../en/docs/Guides/Client SDKs/rest.md | 10 ++++-- .../en/docs/Guides/Client SDKs/unity.md | 4 ++- site/content/en/docs/Guides/fleet-updates.md | 6 ++-- .../en/docs/Guides/gameserver-lifecycle.md | 4 ++- site/content/en/docs/Guides/metrics.md | 31 +++++++++++++------ site/content/en/docs/Installation/_index.md | 28 +++++++++++------ site/content/en/docs/Installation/helm.md | 25 ++++++++++----- 14 files changed, 111 insertions(+), 47 deletions(-) diff --git a/site/content/en/docs/Advanced/scheduling-and-autoscaling.md b/site/content/en/docs/Advanced/scheduling-and-autoscaling.md index 3cc389d9c2..5fc9ec1ebe 100644 --- a/site/content/en/docs/Advanced/scheduling-and-autoscaling.md +++ b/site/content/en/docs/Advanced/scheduling-and-autoscaling.md @@ -109,8 +109,10 @@ Under the "Packed" strategy, Pods will be scheduled using the [`PodAffinity`](ht with a `preferredDuringSchedulingIgnoredDuringExecution` affinity with [hostname](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#interlude-built-in-node-labels) topology. This attempts to group together `GameServer` Pods within as few nodes in the cluster as it can. -> The default Kubernetes scheduler doesn't do a perfect job of packing, but it's a good enough job for what we need - +{{< alert title="Note" color="info">}} +The default Kubernetes scheduler doesn't do a perfect job of packing, but it's a good enough job for what we need - at least at this stage. +{{< /alert >}} #### Fleet Scale Down Strategy diff --git a/site/content/en/docs/Contribute/_index.md b/site/content/en/docs/Contribute/_index.md index 4d5d612160..11c8adfdf0 100644 --- a/site/content/en/docs/Contribute/_index.md +++ b/site/content/en/docs/Contribute/_index.md @@ -63,9 +63,12 @@ or to hide a section from 0.8.0 onward: {{%/* /feature */%}} ``` -> Due to [this hugo bug](https://github.com/gohugoio/hugo/issues/4695) headers wrapped in this shortcode will + +{{< alert title="Warning" color="warning">}} + Due to [this hugo bug](https://github.com/gohugoio/hugo/issues/4695) headers wrapped in this shortcode will not be displayed in the Table of Contents. So we will need to actively remove the `feature` shortcode once the release versions have been passed for new content, for content that is affected. +{{< /alert >}} ## Regenerate Diagrams diff --git a/site/content/en/docs/Getting Started/create-fleet.md b/site/content/en/docs/Getting Started/create-fleet.md index 1cf6c58921..a604728d91 100644 --- a/site/content/en/docs/Getting Started/create-fleet.md +++ b/site/content/en/docs/Getting Started/create-fleet.md @@ -149,8 +149,10 @@ simple-udp-sdhzn-wnhsw Ready 192.168.122.205 7478 minikube 52m Since we have a fleet of warm gameservers, we need a way to request one of them for usage, and mark that it has players access it (and therefore, it should not be deleted until they are finished with it). -> In production, you would likely do the following through a [Kubernetes API call]({{< ref "/docs/Guides/access-api.md" >}}), but we can also +{{< alert title="Note" color="info">}} + In production, you would likely do the following through a [Kubernetes API call]({{< ref "/docs/Guides/access-api.md" >}}), but we can also do this through `kubectl` as well, and ask it to return the response in yaml so that we can see what has happened. +{{< /alert >}} We can do allocation of a GameServer for usage through a `GameServerAllocation`, which will both return to us the details of a `GameServer` (assuming one is available), and also move it to the `Allocated` state, @@ -223,8 +225,10 @@ simple-udp-sdhzn-wng5k Ready 192.168.122.205 7709 minikube 53m simple-udp-sdhzn-wnhsw Ready 192.168.122.205 7478 minikube 52m ``` -> `GameServerAllocations` are create only and not stored for performance reasons, so you won't be able to list +{{< alert title="Note" color="info">}} + `GameServerAllocations` are create only and not stored for performance reasons, so you won't be able to list them after they have been created - but you can see their effects on `GameServers` +{{< /alert >}} A handy trick for checking to see how many `GameServers` you have `Allocated` vs `Ready`, run the following: @@ -335,7 +339,9 @@ Run `kubectl edit fleet simple-udp`, and make the necessary changes, and then sa This will start the deployment of a new set of `GameServers` running with a Container Port of `6000`. -> NOTE: This will make it such that you can no longer connect to the simple-udp game server. +{{< alert title="Warning" color="warning">}} +This will make it such that you can no longer connect to the simple-udp game server. +{{< /alert >}} Run `watch kubectl get gs` until you can see that there is diff --git a/site/content/en/docs/Getting Started/create-gameserver.md b/site/content/en/docs/Getting Started/create-gameserver.md index bf1fce75d1..03aafe09aa 100644 --- a/site/content/en/docs/Getting Started/create-gameserver.md +++ b/site/content/en/docs/Getting Started/create-gameserver.md @@ -150,24 +150,30 @@ NAME STATE ADDRESS PORT NODE AGE simple-udp-7pjrq Ready 35.233.183.43 7190 agones 4m ``` -> Note: if you have Agones installed on minikube the address printed will not be +{{< alert title="Note" color="info">}} + If you have Agones installed on minikube the address printed will not be reachable from the host machine. Instead, use the output of `minikube ip` for the following section. +{{< /alert >}} ### 3. Connect to the GameServer -> NOTE: if you have Agones installed on Google Kubernetes Engine, and are using +{{< alert title="Note" color="info">}} +If you have Agones installed on Google Kubernetes Engine, and are using Cloud Shell for your terminal, UDP is blocked. For this step, we recommend SSH'ing into a running VM in your project, such as a Kubernetes node. You can click the 'SSH' button on the [Google Compute Engine Instances](https://console.cloud.google.com/compute/instances) page to do this. Run `toolbox` on GKE Node to run docker container with tools and then `nc` command would be available. +{{< /alert >}} You can now communicate with the Game Server : -> NOTE: if you do not have netcat installed +{{< alert title="Note" color="info">}} +If you do not have netcat installed (i.e. you get a response of `nc: command not found`), you can install netcat by running `sudo apt install netcat`. +{{< /alert >}} ``` nc -u {IP} {PORT} diff --git a/site/content/en/docs/Getting Started/edit-first-gameserver-go.md b/site/content/en/docs/Getting Started/edit-first-gameserver-go.md index 9a57822df3..4c0ecf4876 100644 --- a/site/content/en/docs/Getting Started/edit-first-gameserver-go.md +++ b/site/content/en/docs/Getting Started/edit-first-gameserver-go.md @@ -94,7 +94,6 @@ Apply the latest settings to kubernetes container. >> kubectl apply -f gameserver.yaml ``` - ### Check the GameServer Status ```bash >> kubectl describe gameserver @@ -109,9 +108,11 @@ kubectl get gs simple-udp -o jsonpath='{.status.address}:{.status.ports[0].port} You can now communicate with the Game Server : -> NOTE: if you do not have netcat installed +{{< alert title="Note" color="info">}} +If you do not have netcat installed (i.e. you get a response of `nc: command not found`), you can install netcat by running `sudo apt install netcat`. +{{< /alert >}} ``` nc -u {IP} {PORT} diff --git a/site/content/en/docs/Guides/Client SDKs/_index.md b/site/content/en/docs/Guides/Client SDKs/_index.md index 0dd3606261..b16559c8d1 100644 --- a/site/content/en/docs/Guides/Client SDKs/_index.md +++ b/site/content/en/docs/Guides/Client SDKs/_index.md @@ -87,7 +87,9 @@ backing Pod will be deleted, if they have not shut themselves down already. This will set a [Label](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) value on the backing `GameServer` record that is stored in Kubernetes. To maintain isolation, the `key` value is automatically prefixed with "agones.dev/sdk-" -> Note: There are limits on the characters that be used for label keys and values. Details are [here](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set). +{{< alert title="Warning" color="warning">}} +There are limits on the characters that be used for label keys and values. Details are [here](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set). +{{< /alert >}} This can be useful if you want to information from your running game server process to be observable or searchable through the Kubernetes API. @@ -138,9 +140,11 @@ and the {{< ghlink href="examples" >}}examples{{< /ghlink >}}. With some matchmakers and game matching strategies, it can be important for game servers to mark themselves as `Allocated`. For those scenarios, this SDK functionality exists. -> Note: Using a [GameServerAllocation]({{< ref "/docs/Reference/gameserverallocation.md" >}}) is preferred in all other scenarios, +{{< alert title="Note" color="info">}} +Using a [GameServerAllocation]({{< ref "/docs/Reference/gameserverallocation.md" >}}) is preferred in all other scenarios, as it gives Agones control over how packed `GameServers` are scheduled within a cluster, whereas with `Allocate()` you relinquish control to an external service which likely doesn't have as much information as Agones. +{{< /alert >}} ### Reserve(seconds) diff --git a/site/content/en/docs/Guides/Client SDKs/local.md b/site/content/en/docs/Guides/Client SDKs/local.md index d2ecd2973b..c8f6de3688 100644 --- a/site/content/en/docs/Guides/Client SDKs/local.md +++ b/site/content/en/docs/Guides/Client SDKs/local.md @@ -53,9 +53,11 @@ this will be picked up by the local server, and will change the current active c events for `WatchGameServer()`. This is a useful way of testing functionality, such as changes of state from `Ready` to `Allocated` in your game server code. -> File modification events can fire more than one for each save (for a variety of reasons), +{{< alert title="Note" color="info">}} +File modification events can fire more than one for each save (for a variety of reasons), but it's best practice to ensure handlers that implement `WatchGameServer()` be idempotent regardless, as repeats can happen when live as well. +{{< /alert >}} For example: diff --git a/site/content/en/docs/Guides/Client SDKs/rest.md b/site/content/en/docs/Guides/Client SDKs/rest.md index 5372a06f66..14960c74be 100644 --- a/site/content/en/docs/Guides/Client SDKs/rest.md +++ b/site/content/en/docs/Guides/Client SDKs/rest.md @@ -22,8 +22,10 @@ use a non-default port. Generally the REST interface gets used if gRPC isn't well supported for a given language or platform. -> Note: The SDK Server sidecar process may startup after your game server binary. So your REST SDK API calls should -> contain some retry logic to take this into account. +{{< alert title="Warning" color="warning">}} +The SDK Server sidecar process may startup after your game server binary. So your REST SDK API calls should +contain some retry logic to take this into account. +{{< /alert >}} ## Generating clients @@ -237,9 +239,11 @@ $ curl -d '{"seconds": "5"}' -H "Content-Type: application/json" -X POST http:// With some matchmakers and game matching strategies, it can be important for game servers to mark themselves as `Allocated`. For those scenarios, this SDK functionality exists. -> Note: Using a [GameServerAllocation]({{< ref "/docs/Reference/gameserverallocation.md" >}}) is preferred in all other scenarios, +{{< alert title="Note" color="info">}} +Using a [GameServerAllocation]({{< ref "/docs/Reference/gameserverallocation.md" >}}) is preferred in all other scenarios, as it gives Agones control over how packed `GameServers` are scheduled within a cluster, whereas with `Allocate()` you relinquish control to an external service which likely doesn't have as much information as Agones. +{{< /alert >}} #### Example diff --git a/site/content/en/docs/Guides/Client SDKs/unity.md b/site/content/en/docs/Guides/Client SDKs/unity.md index 95da15ecd5..6954ace3c5 100644 --- a/site/content/en/docs/Guides/Client SDKs/unity.md +++ b/site/content/en/docs/Guides/Client SDKs/unity.md @@ -45,7 +45,8 @@ Similarly `SetAnnotation(string key, string value)` and `SetLabel(string key, st And there is no need to call `Health()`, it is automatically called. -> Note: The following code causes deadlock. Do not use a `Wait` method with the returned Task. +{{% alert title="Warning" color="warning"%}} +The following code causes deadlock. Do not use a `Wait` method with the returned Task. ```csharp void Deadlock() { @@ -53,6 +54,7 @@ void Deadlock() t.Wait(); // deadlock!!! } ``` +{{% /alert %}} ## Settings diff --git a/site/content/en/docs/Guides/fleet-updates.md b/site/content/en/docs/Guides/fleet-updates.md index db7823d014..ef55fc5805 100644 --- a/site/content/en/docs/Guides/fleet-updates.md +++ b/site/content/en/docs/Guides/fleet-updates.md @@ -62,8 +62,10 @@ up and the older `Fleet` down as required by your specific rollout strategy. This also allows you to rollback if issues arise with the newer version, as you can delete the newer `Fleet` and scale up the old Fleet to its previous levels, resulting in minimal impact to the players. -> For GameServerAllocation, you will need to have at least a single shared label between the `GameServers` in each -> Fleet. +{{< alert title="Note" color="info">}} +For GameServerAllocation, you will need to have at least a single shared label between the `GameServers` in each +Fleet. +{{< /alert >}} ### GameServerAllocation Across Fleets diff --git a/site/content/en/docs/Guides/gameserver-lifecycle.md b/site/content/en/docs/Guides/gameserver-lifecycle.md index fb6d16de95..8549a1b725 100644 --- a/site/content/en/docs/Guides/gameserver-lifecycle.md +++ b/site/content/en/docs/Guides/gameserver-lifecycle.md @@ -22,8 +22,10 @@ matchmaker decides which `GameServer` players are sent to, this flow is common: ![Reserved Lifecyle Sequence Diagram](../../../diagrams/gameserver-reserved.puml.png) -> This does relinquish control over how `GameServers` are packed across the cluster to the external matchmaker. It is likely +{{< alert title="Warning" color="warning">}} +This does relinquish control over how `GameServers` are packed across the cluster to the external matchmaker. It is likely it will not do as good a job at packing and scaling as Agones. +{{< /alert >}} ## Next Steps: diff --git a/site/content/en/docs/Guides/metrics.md b/site/content/en/docs/Guides/metrics.md index 81bcb0af74..8657863b04 100644 --- a/site/content/en/docs/Guides/metrics.md +++ b/site/content/en/docs/Guides/metrics.md @@ -92,7 +92,9 @@ Dashboard screenshots : ![grafana dashboard controller](../../../images/grafana-dashboard-controller.png) -> You can import our dashboards by copying the json content from {{< ghlink href="/build/grafana" branch="master" >}}each config map{{< /ghlink >}} into your own instance of Grafana (+ > Create > Import > Or paste json) or follow the [installation](#installation) guide. +{{< alert title="Note" color="info">}} +You can import our dashboards by copying the json content from {{< ghlink href="/build/grafana" branch="master" >}}each config map{{< /ghlink >}} into your own instance of Grafana (+ > Create > Import > Or paste json) or follow the [installation](#installation) guide. +{{< /alert >}} ## Installation @@ -114,9 +116,11 @@ helm upgrade --install --wait prom stable/prometheus --namespace metrics \ -f ./build/prometheus.yaml ``` -> You can also run our {{< ghlink href="/build/Makefile" branch="master" branch="master" >}}Makefile{{< /ghlink >}} target `make setup-prometheus` -or `make kind-setup-prometheus` and `make minikube-setup-prometheus` for {{< ghlink href="/build/README.md#running-a-test-kind-cluster" branch="master" >}}Kind{{< /ghlink >}} -and {{< ghlink href="/build/README.md#running-a-test-minikube-cluster" branch="master" >}}Minikube{{< /ghlink >}}. +{{% alert title="Note" color="info"%}} +You can also run our {{< ghlink href="/build/Makefile" branch="master" branch="master" >}}Makefile{{< /ghlink >}} target `make setup-prometheus` +or `make kind-setup-prometheus` and `make minikube-setup-prometheus` +for {{< ghlink href="/build/README.md#running-a-test-kind-cluster" branch="master" >}}Kind{{< /ghlink >}} and {{< ghlink href="/build/README.md#running-a-test-minikube-cluster" branch="master" >}}Minikube{{< /ghlink >}}. +{{% /alert %}} For resiliency it is recommended to run Prometheus on a dedicated node which is separate from nodes where Game Servers are scheduled. If you use the above command, with our {{< ghlink href="/build/prometheus.yaml" branch="master" >}}prometheus.yaml{{< /ghlink >}} to set up Prometheus, it will schedule Prometheus pods on nodes @@ -143,15 +147,18 @@ Finally to access Prometheus metrics, rules and alerts explorer use kubectl port-forward deployments/prom-prometheus-server 9090 -n metrics ``` -> Again you can use our Makefile {{< ghlink href="/build/README.md#prometheus-portforward" branch="master" >}}`make prometheus-portforward`{{< /ghlink >}}. - (For {{< ghlink href="/build/README.md#running-a-test-kind-cluster" branch="master" >}}Kind{{< /ghlink >}} and - {{< ghlink href="/build/README.md#running-a-test-minikube-cluster" branch="master" >}}Minikube{{< /ghlink >}} use their specific targets `make kind-prometheus-portforward` and `make minikube-prometheus-portforward`) +{{< alert title="Note" color="info">}} + Again you can use our Makefile {{< ghlink href="/build/README.md#prometheus-portforward" branch="master" >}}`make prometheus-portforward`{{< /ghlink >}}. + (For {{< ghlink href="/build/README.md#running-a-test-kind-cluster" branch="master" >}}Kind{{< /ghlink >}} and {{< ghlink href="/build/README.md#running-a-test-minikube-cluster" branch="master" >}}Minikube{{< /ghlink >}} use their specific targets `make kind-prometheus-portforward` and `make minikube-prometheus-portforward`) +{{< /alert >}} Now you can access the prometheus dashboard [http://localhost:9090](http://localhost:9090). On the landing page you can start exploring metrics by creating [queries](https://prometheus.io/docs/prometheus/latest/querying/basics/). You can also verify what [targets](http://localhost:9090/targets) Prometheus currently monitors (Header Status > Targets), you should see Agones controller pod in the `kubernetes-pods` section. -> Metrics will be first registered when you will start using Agones. +{{< alert title="Note" color="info">}} +Metrics will be first registered when you will start using Agones. +{{< /alert >}} Now let's install some Grafana dashboards. @@ -174,7 +181,9 @@ helm install --wait --name grafana stable/grafana --namespace metrics \ This will install Grafana with our prepopulated dashboards and prometheus datasource [previously installed](#prometheus-installation) -> You can also use our {{< ghlink href="/build/Makefile" branch="master" >}}Makefile{{< /ghlink >}} targets (`setup-grafana`,`minikube-setup-grafana` and `kind-setup-grafana`). +{{< alert title="Note" color="info">}} +You can also use our {{< ghlink href="/build/Makefile" branch="master" >}}Makefile{{< /ghlink >}} targets (`setup-grafana`, `minikube-setup-grafana` and `kind-setup-grafana`). +{{< /alert >}} Finally to access dashboards run @@ -184,7 +193,9 @@ kubectl port-forward deployments/grafana 3000 -n metrics Open a web browser to [http://localhost:3000](http://localhost:3000), you should see Agones [dashboards](#grafana-dashboards) after login as admin. -> Makefile targets `make grafana-portforward`,`make kind-grafana-portforward` and `make minikube-grafana-portforward`. +{{< alert title="Note" color="info">}} +You can also use our `Makefile` targets `make grafana-portforward`, `make kind-grafana-portforward` and `make minikube-grafana-portforward`. +{{< /alert >}} ### Stackdriver installation diff --git a/site/content/en/docs/Installation/_index.md b/site/content/en/docs/Installation/_index.md index f19c9bef6b..b8b5f76248 100644 --- a/site/content/en/docs/Installation/_index.md +++ b/site/content/en/docs/Installation/_index.md @@ -8,10 +8,12 @@ description: > In this quickstart, we will create a Kubernetes cluster, and populate it with the resource types that power Agones. -> When running in production, Agones should be scheduled on a dedicated pool of nodes, distinct from where Game Servers -> are scheduled for better isolation and resiliency. By default Agones prefers to be scheduled on nodes labeled with -> `agones.dev/agones-system=true` and tolerates the node taint `agones.dev/agones-system=true:NoExecute`. -> If no dedicated nodes are available, Agones will run on regular nodes. +{{< alert title="Note" color="info">}} +When running in production, Agones should be scheduled on a dedicated pool of nodes, distinct from where Game Servers +are scheduled for better isolation and resiliency. By default Agones prefers to be scheduled on nodes labeled with +`agones.dev/agones-system=true` and tolerates the node taint `agones.dev/agones-system=true:NoExecute`. +If no dedicated nodes are available, Agones will run on regular nodes. +{{< /alert >}} ## Usage Requirements @@ -27,8 +29,10 @@ In this quickstart, we will create a Kubernetes cluster, and populate it with th - Firewall access for the range of ports that Game Servers can be connected to in the cluster. - Game Servers must have the [game server SDK]({{< ref "/docs/Guides/Client SDKs/_index.md" >}}) integrated, to manage Game Server state, health checking, etc. -> Later versions of Kubernetes may work, but this project is tested against 1.12, and is therefore the supported version. -> Agones will update its support to n-1 version of what is available across all major cloud providers - GKE, EKS and AKS +{{< alert title="Warning" color="warning">}} +Later versions of Kubernetes may work, but this project is tested against 1.12, and is therefore the supported version. +Agones will update its support to n-1 version of what is available across all major cloud providers - GKE, EKS and AKS +{{< /alert >}} ## Setting up a Google Kubernetes Engine (GKE) cluster @@ -218,7 +222,9 @@ eksctl create cluster \ --node-ami auto ``` -> Note: EKS does not use the normal Kubernetes networking since it is [incompatible with Amazon VPC networking](https://www.contino.io/insights/kubernetes-is-hard-why-eks-makes-it-easier-for-network-and-security-architects). +{{< alert title="Note" color="info">}} +EKS does not use the normal Kubernetes networking since it is [incompatible with Amazon VPC networking](https://www.contino.io/insights/kubernetes-is-hard-why-eks-makes-it-easier-for-network-and-security-architects). +{{< /alert >}} #### Allowing UDP Traffic @@ -317,9 +323,11 @@ kubectl apply -f https://raw.githubusercontent.com/googleforgames/agones/{{< rel You can also find the install.yaml in the latest `agones-install` zip from the [releases](https://github.com/googleforgames/agones/releases) archive. -> Note: Installing Agones with the `install.yaml` will setup the TLS certificates stored in this repository for securing -> kubernetes webhooks communication. If you want to generate new certificates or use your own, -> we recommend using the helm installation. +{{< alert title="Warning" color="warning">}} +Installing Agones with the `install.yaml` will setup the TLS certificates stored in this repository for securing +kubernetes webhooks communication. If you want to generate new certificates or use your own, +we recommend using the helm installation. +{{< /alert >}} ### Install using Helm diff --git a/site/content/en/docs/Installation/helm.md b/site/content/en/docs/Installation/helm.md index d346f11693..59a7a79fb2 100644 --- a/site/content/en/docs/Installation/helm.md +++ b/site/content/en/docs/Installation/helm.md @@ -16,7 +16,9 @@ description: > ## Installing the Chart -> If you don't have `Helm` installed locally, or `Tiller` installed in your Kubernetes cluster, read the [Using Helm](https://docs.helm.sh/using_helm/) documentation to get started. +{{< alert title="Note" color="info">}} +If you don't have `Helm` installed locally, or `Tiller` installed in your Kubernetes cluster, read the [Using Helm](https://docs.helm.sh/using_helm/) documentation to get started. +{{< /alert >}} To install the chart with the release name `my-release` using our stable helm repository: @@ -34,10 +36,13 @@ pool for Agones, see the [Agones installation instructions]({{< relref "../_inde The command deploys Agones on the Kubernetes cluster with the default configuration. The [configuration](#configuration) section lists the parameters that can be configured during installation. -> **Tip**: List all releases using `helm list` +{{< alert title="Tip" color="info">}} +List all releases using `helm list` +{{< /alert >}} - -> If you are installing a development build of Agones (i.e. not the {{< release-version >}} release), you will need to install Agones the following way: +{{< alert title="Note" color="info">}} +If you are installing a development build of Agones (i.e. not the {{< release-version >}} release), you will need to install Agones the following way: +{{< /alert >}} ```bash $ cd install/helm/ @@ -59,7 +64,9 @@ $ kubectl create namespace xbox $ helm install --set "gameservers.namespaces={default,xbox}" --namespace agones-system --name my-release agones/agones ``` -> You need to create your namespaces before installing Agones. +{{< alert title="Note" color="info">}} +You need to create your namespaces before installing Agones. +{{< /alert >}} If you want to add a new namespace afterward simply upgrade your release: @@ -191,14 +198,18 @@ Alternatively, a YAML file that specifies the values for the parameters can be p $ helm install --name my-release --namespace agones-system -f values.yaml agones/agones ``` -> **Tip**: You can use the default {{< ghlink href="install/helm/agones/values.yaml" >}}values.yaml{{< /ghlink >}} +{{< alert title="Tip" color="info">}} +You can use the default {{< ghlink href="install/helm/agones/values.yaml" >}}values.yaml{{< /ghlink >}} +{{< /alert >}} ## TLS Certificates By default agones chart generates tls certificates used by the adminission controller, while this is handy, it requires the agones controller to restart on each `helm upgrade` command. For most used cases the controller would have required a restart anyway (eg: controller image updated). However if you really need to avoid restarts we suggest that you turn off tls automatic generation (`agones.controller.generateTLS` to `false`) and provide your own certificates (`certs/server.crt`,`certs/server.key`). -> **Tip**: You can use our script located at `cert/cert.sh` to generates them. +{{< alert title="Tip" color="info">}} +You can use our script located at `cert/cert.sh` to generates them. +{{< /alert >}} ## Confirm Agones is running