Merge branch 'dz-use-nip-io' into 'master'

Use nip.io instead of xip.io

See merge request gitlab-org/gitlab-ce!19688

doc/administration/integration/koding.md

@@ -100,14 +100,14 @@ As it's pointed out before, you will need public access to this machine that
 you've installed Koding and GitLab on. Better to use a domain but a static IP
 is also fine.
 
-For IP based installation you can use [xip.io](https://xip.io) service which is
+For IP based installation you can use [nip.io](https://nip.io) service which is
 free and provides DNS resolution to IP based requests like following;
 
-  - 127.0.0.1.xip.io              -> resolves to 127.0.0.1
-  - foo.bar.baz.127.0.0.1.xip.io  -> resolves to 127.0.0.1
+  - 127.0.0.1.nip.io              -> resolves to 127.0.0.1
+  - foo.bar.baz.127.0.0.1.nip.io  -> resolves to 127.0.0.1
   - and so on...
 
-As Koding needs subdomains for team names; `foo.127.0.0.1.xip.io` requests for
+As Koding needs subdomains for team names; `foo.127.0.0.1.nip.io` requests for
 a running koding instance on `127.0.0.1` server will be handled as `foo` team
 requests.
 
@@ -127,8 +127,8 @@ your Koding installation. Team called `gitlab` has integration on Koding out
 of the box, so if you didn't change anything your team on Koding should be
 `gitlab`.
 
-So, if your Koding is running on `http://1.2.3.4.xip.io:8090` your URL needs
-to be `http://gitlab.1.2.3.4.xip.io:8090`. You need to provide the same host
+So, if your Koding is running on `http://1.2.3.4.nip.io:8090` your URL needs
+to be `http://gitlab.1.2.3.4.nip.io:8090`. You need to provide the same host
 with your Koding installation here.
 
 
@@ -192,7 +192,7 @@ cd koding
 docker-compose run                              \
   --service-ports backend                       \
   /opt/koding/scripts/bootstrap-container build \
-  --host=**YOUR_IP**.xip.io                     \
+  --host=**YOUR_IP**.nip.io                     \
   --gitlabHost=**GITLAB_IP**                    \
   --gitlabPort=**GITLAB_PORT**                  \
   --gitlabToken=**SECRET_TOKEN**                \
@@ -224,7 +224,7 @@ cd koding
 docker-compose run                              \
   --service-ports backend                       \
   /opt/koding/scripts/bootstrap-container build \
-  --host=**YOUR_IP**.xip.io                     \
+  --host=**YOUR_IP**.nip.io                     \
 ```
 
 #### Enable Single Sign On
@@ -233,7 +233,7 @@ Once you restarted your Koding and logged in with your username and password
 you need to activate oauth authentication for your user. To do that
 
  - Navigate to Dashboard on Koding from;
-   `http://gitlab.**YOUR_IP**.xip.io:8090/Home/my-account`
+   `http://gitlab.**YOUR_IP**.nip.io:8090/Home/my-account`
  - Scroll down to Integrations section
  - Click on toggle to turn On integration in GitLab integration section
 

doc/install/kubernetes/gitlab_omnibus.md

@@ -120,7 +120,7 @@ gitlabConfigStorageSize: 1Gi
 Ingress routing and SSL are automatically configured within this Chart. An NGINX ingress is provisioned and configured, and will route traffic to any service. SSL certificates are automatically created and configured by [kube-lego](https://github.com/kubernetes/charts/tree/master/stable/kube-lego).
 
 > **Note:**
-Let's Encrypt limits a single TLD to five certificate requests within a single week. This means that common DNS wildcard services like [xip.io](http://xip.io) and [nip.io](http://nip.io) are unlikely to work.
+Let's Encrypt limits a single TLD to five certificate requests within a single week. This means that common DNS wildcard services like [nip.io](http://nip.io) and [nip.io](http://nip.io) are unlikely to work.
 
 ## Installing GitLab using the Helm Chart
 > **Note:**

doc/install/openshift_and_gitlab/index.md

@@ -307,10 +307,10 @@ hostname** and use greater values for the volume sizes. If you don't provide a
 password for PostgreSQL, it will be created automatically.
 
 >**Note:**
-The `gitlab.apps.10.2.2.2.xip.io` hostname that is used by default will
+The `gitlab.apps.10.2.2.2.nip.io` hostname that is used by default will
 resolve to the host with IP `10.2.2.2` which is the IP our VM uses. It is a
 trick to have distinct FQDNs pointing to services that are on our local network.
-Read more on how this works in <http://xip.io>.
+Read more on how this works in <http://nip.io>.
 
 Now that we configured this, let's see how to manage and scale GitLab.
 
@@ -347,7 +347,7 @@ Navigate back to the **Overview** and hopefully all pods will be up and running.
 ![GitLab running](img/gitlab-running.png)
 
 Congratulations! You can now navigate to your new shinny GitLab instance by
-visiting <http://gitlab.apps.10.2.2.2.xip.io> where you will be asked to
+visiting <http://gitlab.apps.10.2.2.2.nip.io> where you will be asked to
 change the root user password. Login using `root` as username and providing the
 password you just set, and start using GitLab!
 

doc/topics/autodevops/index.md

@@ -135,9 +135,9 @@ and `1.2.3.4` is the IP address of your load balancer; generally NGINX
 ([see requirements](#requirements)). How to set up the DNS record is beyond
 the scope of this document; you should check with your DNS provider.
 
-Alternatively you can use free public services like [xip.io](http://xip.io) or
+Alternatively you can use free public services like [nip.io](http://nip.io) or
 [nip.io](http://nip.io) which provide automatic wildcard DNS without any
-configuration. Just set the Auto DevOps base domain to `1.2.3.4.xip.io` or
+configuration. Just set the Auto DevOps base domain to `1.2.3.4.nip.io` or
 `1.2.3.4.nip.io`.
 
 Once set up, all requests will hit the load balancer, which in turn will route