Update docs on DNS provider (#51)

README.md

@@ -18,7 +18,7 @@ You can find the generated HAProxy Configuration [here](hack/example/haproxy_gen
   - [TLS Termination](docs/user-guide/component/ingress/tls.md),
   - Multi-cloud supports,
   - [Name and Path based virtual hosting](docs/user-guide/component/ingress/named-virtual-hosting.md),
-  - [Cross namespace routing support](docs/user-guide/component/ingress/named-virtual-hosting.md),
+  - [Cross namespace routing support](docs/user-guide/component/ingress/named-virtual-hosting.md#cross-namespace-traffic-routing),
   - [URL and Request Header Re-writing](docs/user-guide/component/ingress/header-rewrite.md),
   - [Wildcard Name based virtual hosting](docs/user-guide/component/ingress/named-virtual-hosting.md),
   - Persistent sessions, Loadbalancer stats.
@@ -49,6 +49,9 @@ Kubernetes Controller to manage TLS Certificate.
 - Use issued Certificates with Ingress to Secure Communications.
 
 
+### Supported Domain Providers
+Read more about supported DNS Providers [here](/docs/user-guide/component/certificate/provider.md)
+
 ## Supported Versions
 Kubernetes 1.3+
 
@@ -60,7 +63,7 @@ To deploy voyager in Kubernetes follow this [guide](docs/user-guide/README.md).
 2. Deploy voyager to kubernetes.
 
 ## Running voyager alongside with other ingress controller
-voyager can be configured to handle default kubernetes ingress or only ingress.appscode.com. voyager can also be run
+Voyager can be configured to handle default kubernetes ingress or only ingress.appscode.com. voyager can also be run
 along side with other controllers.
 
 ```sh

docs/developer-guide/README.md

@@ -83,3 +83,34 @@ specified HAProxy - that is configured with auto reload while any changes happen
 by performing processing on the resources.
 
 Certificate watcher watch and process certificates third party data and obtain a ACME certificates.
+
+
+### Third Party Resources
+`voyager` depends on two Third Party Resource Object `ingress.appscode.com` and `certificate.appscode.com`. Those two objects
+can be created using following data.
+
+```yaml
+metadata:
+  name: ingress.appscode.com
+apiVersion: extensions/v1beta1
+kind: ThirdPartyResource
+description: "Extended ingress support for Kubernetes by appscode.com"
+versions:
+  - name: v1beta1
+```
+
+```yaml
+metadata:
+  name: certificate.appscode.com
+apiVersion: extensions/v1beta1
+kind: ThirdPartyResource
+description: "A specification of a Let's Encrypt Certificate to manage."
+versions:
+  - name: v1beta1
+```
+
+```sh
+# Create Third Party Resource
+$ kubectl apply -f https://raw.githubusercontent.com/appscode/k8s-addons/master/api/extensions/ingress.yaml
+$ kubectl apply -f https://raw.githubusercontent.com/appscode/k8s-addons/master/api/extensions/certificate.yaml
+```

docs/user-guide/README.md

@@ -1,55 +1,29 @@
 # User Guide
 This guide will walk you through deploying the Voyager controller.
 
-## High Level Tasks
-* Create `ingress.appscode.com` and `certificate.appscode.com` Third Party Resource
-* Create Voyager Deployment
-
-## Deploying Voyager
-
-### Create the Third Party Resources
-`voyager` depends on two Third Party Resource Object `ingress.appscode.com` and `certificate.appscode.com`. Those two objects
-can be created using following data.
-
-```yaml
-metadata:
-  name: ingress.appscode.com
-apiVersion: extensions/v1beta1
-kind: ThirdPartyResource
-description: "Extended ingress support for Kubernetes by appscode.com"
-versions:
-  - name: v1beta1
-```
-
-```yaml
-metadata:
-  name: certificate.appscode.com
-apiVersion: extensions/v1beta1
-kind: ThirdPartyResource
-description: "A specification of a Let's Encrypt Certificate to manage."
-versions:
-  - name: v1beta1
-```
-
-```sh
-# Create Third Party Resource
-$ kubectl apply -f https://raw.githubusercontent.com/appscode/k8s-addons/master/api/extensions/ingress.yaml
-$ kubectl apply -f https://raw.githubusercontent.com/appscode/k8s-addons/master/api/extensions/certificate.yaml
-```
-
-
-### Deploy Controller
+### Deploying Voyager
 Voyager controller communicates with kube-apiserver at inCluster mode if no master or kubeconfig is provided. It watches Ingress and Certificate resource
 to handle corresponding events.
 
 ```sh
-$ export CLOUD_PROVIDER=<provider-name> // eg: gce, gke, aws, azure
-$ export CLUSTER_NAME=<clustername>     // eg: Name of your GKE cluster. This is used to create firewall rules.
+$ export CLOUD_PROVIDER=<provider-name> // ie:
+                                        // - gce
+                                        // - gke
+                                        // - aws
+                                        // - azure
+
+$ export CLUSTER_NAME=<clustername>     // eg: Name of your cluster. This is used to create firewall rules.
+
 $ curl https://raw.githubusercontent.com/appscode/voyager/master/hack/deploy/deployments.yaml | \
         envsubst | \
         kubectl apply -f -
 ```
 
+Once Controller is *Running* It will create the [required ThirdPartyResources for ingress and certificates](/docs/developer-guide#third-party-resources).
+Check the Controller is running or not via `kubectl get pods` there should be a pod nameed `appscode-voyager-xxxxxxxxxx-xxxxx`.
+Now Create Your Ingress/Certificated.
+
+
 #### Configuration Options
 ```
 --master          // The address of the Kubernetes API server (overrides any value in kubeconfig)
@@ -91,14 +65,14 @@ spec:
   - host: appscode.example.com
     http:
       paths:
-      - path: "/testPath"
+      - path: '/testPath'
         backend:
           serviceName: test-service
           servicePort: '80'
           headerRule:
           - X-Forwarded-Host %[base]
           rewriteRule:
-          - "^([^\\ :]*)\\ /(.*)$ \\1\\ /testings/\\2"
+          - '^([^\\ :]*)\\ /(.*)$ \\1\\ /testings/\\2'
 ```
 
 POSTing this to Kubernetes, API server will need to create a loadbalancer.

docs/user-guide/component/certificate/README.md

@@ -64,6 +64,9 @@ type CertificateStatus struct {
   - spec.acmeUserSecretName - acme user information to use for obtaining certificates. If none is provided one will be created
   - spec.acmeStagingURL - server to obtain a certificate from. Default uses Let's Encrypt.
 
+### Supported Providers
+[This Providers](provider.md) are supported as domain's DNS provider. The `providerCredentialSecretName` Must match the
+format.
 
 ## Usage
 - [Creating a Certificate](create.md)

docs/user-guide/component/certificate/create.md

@@ -21,6 +21,19 @@ spec:
   providerCredentialSecretName: test-gcp-secret
 ```
 
+In this example the domains DNS providers are `googlecloude`. Example Test `test-gcp-secret` should look like
+```yaml
+kind: Secret
+metadata:
+  name: ssl-appscode-io
+  namespace: default
+data:
+  GCE_PROJECT: <project-name>
+  GOOGLE_APPLICATION_CREDENTIALS: <credential>
+```
+
+See the Supported Providers List [here](provider.md)
+
 ```sh
 kubectl create -f example.yaml
 ```

docs/user-guide/component/certificate/provider.md

@@ -2,68 +2,80 @@
 
 ## DNS Providers
 Voyager uses kubernetes secret within the pod to fetch credentials required for various DNS providers.
-Making those correctly accessible to Voyager will require specifing the secret name inside an certificate objects.
+Making those correctly accessible to Voyager will require specifying the secret name inside an certificate objects.
 The Secret will need the Key name exactly provided.
 
-### HTTP
-HTTP Provider will requires an Ingress refrence to resolve with. Reference an Ingress name for http provider.
+### HTTP (beta)
+HTTP Provider will requires an [Ingress](/docs/user-guide/component/ingress) reference to resolve with.
+Reference an Ingress name for http provider. Ingress IP should be setted as domain A record in its provider.
 
 ### Cloudflare
-`CLOUDFLARE_EMAIL`: The email of the cloudflare user
-`CLOUDFLARE_API_KEY`: The API key corresponding to the email
+`CLOUDFLARE_EMAIL`: The email of the cloudflare user <br>
+`CLOUDFLARE_API_KEY`: The API key corresponding to the email <br>
 
 ### Digital Ocean
-`DO_AUTH_TOKEN`: The digital ocean authorization token
+`DO_AUTH_TOKEN`: The digital ocean authorization token <br>
 
 ### DNSimple
-`DNSIMPLE_EMAIL`: The email fo the DNSimple user
-`DNSIMPLE_API_KEY`: The API key corresponding to the email
+`DNSIMPLE_EMAIL`: The email fo the DNSimple user <br>
+`DNSIMPLE_API_KEY`: The API key corresponding to the email <br>
 
 ### DNS Made Easy
-`DNSMADEEASY_API_KEY`: The API key for DNS Made Easy
-`DNSMADEEASY_API_SECRET`: The api secret corresponding with the API key
-`DNSMADEEASY_SANDBOX`: A boolean flag, if set to true or 1, requests will be sent to the sandbox API
+`DNSMADEEASY_API_KEY`: The API key for DNS Made Easy <br>
+`DNSMADEEASY_API_SECRET`: The api secret corresponding with the API key <br>
+`DNSMADEEASY_SANDBOX`: A boolean flag, if set to true or 1, requests will be sent to the sandbox API <br>
 
 ### Dyn
-`DYN_CUSTOMER_NAME`: The customer name of the Dyn user
-`DYN_USER_NAME`: The user name of the Dyn user
-`DYN_PASSWORD`: The password of the Dyn user
+`DYN_CUSTOMER_NAME`: The customer name of the Dyn user <br>
+`DYN_USER_NAME`: The user name of the Dyn user <br>
+`DYN_PASSWORD`: The password of the Dyn user <br>
 
 ### Gandi
-`GANDI_API_KEY`: The API key for Gandi
+`GANDI_API_KEY`: The API key for Gandi <br>
 
 ### Google Cloud
-`GCE_PROJECT`: The name of the Google Cloud project to use
-`GOOGLE_APPLICATION_CREDENTIALS`: Credential Data.
+`GCE_PROJECT`: The name of the Google Cloud project to use <br>
+`GOOGLE_APPLICATION_CREDENTIALS`: Credential Data. <br>
 
 ### Namecheap
-`NAMECHEAP_API_USER`: The username of the namecheap user
-`NAMECHEAP_API_KEY`: The API key corresponding with the namecheap user
+`NAMECHEAP_API_USER`: The username of the namecheap user <br>
+`NAMECHEAP_API_KEY`: The API key corresponding with the namecheap user <br>
 
 ### OVH
-`OVH_ENDPOINT`: The URL of the API endpoint to use
-`OVH_APPLICATION_KEY`: The application key
-`OVH_APPLICATION_SECRET`: The secret corresponding to the application key
-`OVH_CONSUMER_KEY`: The consumer key
+`OVH_ENDPOINT`: The URL of the API endpoint to use <br>
+`OVH_APPLICATION_KEY`: The application key <br>
+`OVH_APPLICATION_SECRET`: The secret corresponding to the application key <br>
+`OVH_CONSUMER_KEY`: The consumer key <br>
 
 ### PDNS
-`PDNS_API_KEY`: The API key to use
+`PDNS_API_KEY`: The API key to use <br>
 
 ### RFC2136
 The rfc2136 provider works with any DNS provider implementing the DNS Update rfc2136.
 the TSIG variables need only be set if using TSIG authentication.
 
-`RFC2136_NAMESERVER`: The network address of the provider, in the form of "host" or "host:port"
-`RFC2136_TSIG_ALGORITHM`: The algorithm to use for TSIG authentication.
-`RFC2136_TSIG_KEY`: The key to use for TSIG authentication.
-`RFC2136_TSIG_SECRET`: The secret to use for TSIG authentication.
+`RFC2136_NAMESERVER`: The network address of the provider, in the form of "host" or "host:port" <br>
+`RFC2136_TSIG_ALGORITHM`: The algorithm to use for TSIG authentication. <br>
+`RFC2136_TSIG_KEY`: The key to use for TSIG authentication. <br>
+`RFC2136_TSIG_SECRET`: The secret to use for TSIG authentication. <br>
 
 ### Amazon Route53
-`AWS_ACCESS_KEY_ID`: The access key ID
-`AWS_SECRET_ACCESS_KEY`: The secret corresponding to the access key
+`AWS_ACCESS_KEY_ID`: The access key ID <br>
+`AWS_SECRET_ACCESS_KEY`: The secret corresponding to the access key <br>
 
 ### Vultr
-`VULTR_API_KEY`: The API key to use
+`VULTR_API_KEY`: The API key to use <br>
 
 ### Linode
-`LINODE_API_KEY`: API Key for linode to use.
+`LINODE_API_KEY`: API Key for linode to use. <br>
+
+An Example Secret would look like
+```yaml
+kind: Secret
+metadata:
+  name: ssl-appscode-io
+  namespace: default
+data:
+  GCE_PROJECT: <project-name>
+  GOOGLE_APPLICATION_CREDENTIALS: <credential>
+```

docs/user-guide/component/ingress/README.md

@@ -122,7 +122,7 @@ same ingress resource. Learn more by reading the certificate doc.
 ## Next Reading
 - [Single Service example](single-service.md)
 - [Simple Fanout](simple-fanout.md)
-- [Virtual Hosting](named-virtual-hostin.md)
+- [Virtual Hosting](named-virtual-hosting.md)
 - [URL and Header Rewriting](header-rewrite.md)
 - [TCP Loadbalancing](tcp.md)
 - [TLS Termination](tls.md)

docs/user-guide/component/ingress/named-virtual-hosting.md

@@ -34,6 +34,26 @@ spec:
 If the `host` field is set to `*.bar.com`, Ingress will forward traffic for any subdomain of `bar.com`.
 so `foo.bar.com` or `test.bar.com` will forward traffic to the desired backends.
 
+### Cross Namespace traffic routing
+If your ingress in namespace `foo` and your application is in namespace `bar` you can still forward traffic.
+
+```yaml
+apiVersion: appscode.com/v1beta1
+kind: Ingress
+metadata:
+  name: test-ingress
+  namespace: foo
+spec:
+  rules:
+  - host: foo.bar.com
+    http:
+      paths:
+      - backend:
+          serviceName: s1.bar # serviceName.Namespace
+          servicePort: '80'
+```
+
+
 ## Next Reading
 - [URL and Header Rewriting](header-rewrite.md)
 - [TCP Loadbalancing](tcp.md)