-
Notifications
You must be signed in to change notification settings - Fork 180
feat(ingress) Experimental Native Ingress #732
Changes from 8 commits
430b391
81c9f2c
9ed34ea
62d8684
2f585c1
d8b6f8c
8f3b769
e8c4692
69c5dad
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,84 @@ | ||
# Experimental Native Ingress | ||
|
||
## Install Deis Workflow (With experimental native ingress support) | ||
|
||
Now that Helm is installed and the repository has been added, install Workflow with a native ingress by running: | ||
|
||
``` | ||
$ helm install deis/workflow --namespace deis --set global.experimental_native_ingress=true,controller.platform_domain=deis.com | ||
``` | ||
|
||
Where `controller.platform_domain` is a **required** parameter that is traditionally not required for Workflow. In this example we are using `deis.com` for `$hostname`. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we make a prelude here saying that this is documented further below in "Configuring DNS"? |
||
|
||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. there's a few extra unneeded newlines here inbetween paragraphs. Mind removing them? |
||
|
||
Helm will install a variety of Kubernetes resources in the `deis` namespace. | ||
Wait for the pods that Helm launched to be ready. Monitor their status by running: | ||
|
||
``` | ||
$ kubectl --namespace=deis get pods | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. add There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Kubernetes will have the pod information stored very quickly, and I think adding a |
||
``` | ||
|
||
You should also notice that several Kubernetes ingresses has been installed on your cluster. You can view it by running: | ||
|
||
``` | ||
$ kubectl get ingress --namespace deis | ||
``` | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. extra newline here |
||
|
||
Depending on the order in which the Workflow components initialize, some pods may restart. This is common during the | ||
installation: if a component's dependencies are not yet available, that component will exit and Kubernetes will | ||
automatically restart it. | ||
|
||
Here, it can be seen that the controller, builder and registry all took a few loops before they were able to start: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. took a few loops waiting for minio* extra context is good :) |
||
|
||
``` | ||
$ kubectl --namespace=deis get pods | ||
NAME READY STATUS RESTARTS AGE | ||
deis-builder-hy3xv 1/1 Running 5 5m | ||
deis-controller-g3cu8 1/1 Running 5 5m | ||
deis-database-rad1o 1/1 Running 0 5m | ||
deis-logger-fluentd-1v8uk 1/1 Running 0 5m | ||
deis-logger-fluentd-esm60 1/1 Running 0 5m | ||
deis-logger-sm8b3 1/1 Running 0 5m | ||
deis-minio-4ww3t 1/1 Running 0 5m | ||
deis-registry-asozo 1/1 Running 1 5m | ||
deis-workflow-manager-68nu6 1/1 Running 0 5m | ||
``` | ||
|
||
## Install a Kubernetes Ingress Controller | ||
|
||
Now that Workflow has been deployed with the `global.experimental_native_ingress` flag set to `true`, we will need a Kubernetes ingress controller in place to begin routing traffic. | ||
|
||
Here is an example of how to use [traefik](https://traefik.io/) as an ingress controller for Workflow. Of course, you are welcome to use any controller you wish. | ||
|
||
``` | ||
$ helm install stable/traefik --name deis-ingress-001 --namespace kube-system | ||
``` | ||
|
||
## Configure DNS | ||
|
||
The experimental ingress feature requires a user to set up a hostname, and assumes the `deis.$host` convention. | ||
|
||
We need to point the `*.$host` record to the public IP address of your ingress controller. You can get the public IP using the following command. A wildcard entry is necessary here as apps will use the same rule after they are deployed. | ||
|
||
``` | ||
$ kubectl get svc deis-ingress-001 --namespace kube-system | ||
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE | ||
deis-ingress-001 10.23.253.220 104.154.159.184 80:30231/TCP,443:32264/TCP 19m | ||
``` | ||
|
||
If we were using `deis.com` as a hostname we would need to create the following A DNS record. | ||
|
||
| Name | Type | Value | | ||
| ----------------- |:-------------:| ---------------:| | ||
| deis.deis.com | A | 104.154.159.184 | | ||
|
||
|
||
Once all of the pods are in the `READY` state, and `deis.$host` resolves to the external IP found above Workflow is up an running! | ||
|
||
After installing Workflow, [register a user and deploy an application](../quickstart/deploy-an-app.md). | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Since it's experimental, should we provide a link in the docs to github issue reporting? Or encourage users to share their stories of success with different ingress controllers by submitting docs PRs as HOWTOs? Not necessary, just thinking... |
||
|
||
##### Feedback | ||
|
||
While this feature is experimental we welcome feedback on the issue. We would like to learn more about use cases, and user experience. Please [open a new issue](https://github.com/deis/workflow/issues/new) for feedback. |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -33,6 +33,9 @@ More rigorous installations would benefit from using outside sources for the fol | |
* [Redis](../managing-workflow/platform-logging.md#configuring-off-cluster-redis) - Such as AWS Elasticache | ||
* [InfluxDB](../managing-workflow/platform-monitoring.md#configuring-off-cluster-influxdb) and [Grafana](../managing-workflow/platform-monitoring.md#off-cluster-grafana) | ||
|
||
#### (Experimental) Kubernetes Native Ingress | ||
|
||
Workflow now offers [experimental native ingress](experimental-native-ingress.md) to take advantage of native Kubernetes routing. Any compatible Kubernetes ingress controller can be used in place of Workflow's nginx-based deis-router. Follow [this guide](experimental-native-ingress.md) to enable experimental native ingress. | ||
## Add the Deis Chart Repository | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can you add an extra newline here between the paragraph and the new heading? Just a small pet peeve of mine :) |
||
|
||
The Deis Chart Repository contains everything needed to install Deis Workflow onto a Kubernetes cluster, with a single `helm install deis/workflow --namespace deis` command. | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,26 +1,44 @@ | ||
## Register an Admin User | ||
## Determine Your Host and Hostname Values | ||
|
||
The first user to register against Deis Workflow will automatically be given administrative privileges. | ||
For the rest of this example we will refer to a special variables called `$hostname`. Please choose one of the two methods for building your `$hostname`. | ||
|
||
If you installed Deis on GKE or AWS, Deis automatically creates a load balancer for the cluster. To get the IP of this load balancer, run `kubectl --namespace=deis describe svc deis-router`. | ||
#### Option 1: Standard Installation | ||
|
||
For a standard installation that includes deis-router, you can calculate the hostname value using its public IP address and a wildcard DNS record. | ||
|
||
If your router IP is `1.1.1.1`, its `$hostname` will be `1.1.1.1.nip.io`. You can find your IP address by running: | ||
|
||
``` | ||
kubectl --namespace=deis describe svc deis-router | ||
``` | ||
|
||
If you do not have an load balancer IP, the router automatically forwards traffic from a kubernetes node to the router. In this case, use the IP of a kubernetes node and the node | ||
port that routes to port 80 on the controller. | ||
|
||
Deis requires a wildcard DNS record to dynamically map app names to the router. Instead of setting up DNS records, this example will use `nip.io`. If your router IP is `1.1.1.1`, its url will be `1.1.1.1.nip.io`. The URL of the controller component will be `deis.1.1.1.1.nip.io`. | ||
Deis workflow requires a wildcard DNS record to dynamically map app names to the router. | ||
|
||
#### Option 2: Experimental Native Ingress Installation | ||
|
||
Use the controller url to register a user in the cluster. | ||
In this example, the user should already have DNS set up pointing to their known host. The `$hostname` value can be calculated by prepending `deis.` to the value set in `controller.platform_domain`. | ||
|
||
**$hostname**: deis.com | ||
|
||
## Register an Admin User | ||
|
||
The first user to register against Deis Workflow will automatically be given administrative privileges. | ||
|
||
Use the controller `$hostname` to register a user in the cluster. | ||
|
||
``` | ||
$ deis register http://deis.104.197.125.75.nip.io | ||
$ deis register http://$hostname | ||
username: admin | ||
password: | ||
password (confirm): | ||
email: [email protected] | ||
Registered admin | ||
Logged in as admin | ||
$ deis whoami | ||
You are admin at http://deis.104.197.125.75.nip.io | ||
You are admin at http://$hostname | ||
``` | ||
|
||
You have now registered your first user and you are ready to deploy an application. | ||
|
@@ -50,7 +68,7 @@ Let's use the CLI to tell the platform to deploy an application and then use cur | |
``` | ||
$ deis pull deis/example-go -a proper-barbecue | ||
Creating build... done | ||
$ curl http://proper-barbecue.104.197.125.75.nip.io | ||
$ curl http://proper-barbecue.$hostname | ||
Powered by Deis | ||
``` | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if this page repeats too much documentation from the "normal" doc for installing without this experimental feature. Do we want to consider a lesser page that just highlights what's different when you install with this feature flag set? I really don't know what's best here. I'm just asking the question.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I already considered hooking into the existing page, I think it makes sense to have a clear change in flow for an entire section, than to try to add a bunch of conditional logic to an existing flow. I visualize the flows like this:
Separate and clear
Together and conditional
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does "separate and clear" become a maintenance burden if / as additional flags for major / experimental features get added. I'm afraid of committing to the notion of a page per permutation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the wise thing to do here is to let problems present themselves instead of trying to be too defensive and predict the future. If it becomes a problem, we can always change. The concern seems trivial to be honest, and this an
experimental
feature after all, shouldn't we beexperimenting
to see what works best?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it's a trivial concern. We generally accept the practice of avoiding DRY exceptions in code. imo, docs shouldn't be any different. In either case, a DRY exception represents an on-going maintenance burden.
Though I don't think it's a trivial concern, I'm not going to belabor it either. You're doing the legwork on this, so I defer to your judgement.