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

Use nip.io instead of xip.io

See merge request gitlab-org/gitlab-ce!19688
parents 2c1e47f0 8070632b
...@@ -100,14 +100,14 @@ As it's pointed out before, you will need public access to this machine that ...@@ -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 you've installed Koding and GitLab on. Better to use a domain but a static IP
is also fine. 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; free and provides DNS resolution to IP based requests like following;
- 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.xip.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... - 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 a running koding instance on `127.0.0.1` server will be handled as `foo` team
requests. requests.
...@@ -127,8 +127,8 @@ your Koding installation. Team called `gitlab` has integration on Koding out ...@@ -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 of the box, so if you didn't change anything your team on Koding should be
`gitlab`. `gitlab`.
So, if your Koding is running on `http://1.2.3.4.xip.io:8090` your URL needs 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.xip.io:8090`. You need to provide the same host to be `http://gitlab.1.2.3.4.nip.io:8090`. You need to provide the same host
with your Koding installation here. with your Koding installation here.
...@@ -192,7 +192,7 @@ cd koding ...@@ -192,7 +192,7 @@ cd koding
docker-compose run \ docker-compose run \
--service-ports backend \ --service-ports backend \
/opt/koding/scripts/bootstrap-container build \ /opt/koding/scripts/bootstrap-container build \
--host=**YOUR_IP**.xip.io \ --host=**YOUR_IP**.nip.io \
--gitlabHost=**GITLAB_IP** \ --gitlabHost=**GITLAB_IP** \
--gitlabPort=**GITLAB_PORT** \ --gitlabPort=**GITLAB_PORT** \
--gitlabToken=**SECRET_TOKEN** \ --gitlabToken=**SECRET_TOKEN** \
...@@ -224,7 +224,7 @@ cd koding ...@@ -224,7 +224,7 @@ cd koding
docker-compose run \ docker-compose run \
--service-ports backend \ --service-ports backend \
/opt/koding/scripts/bootstrap-container build \ /opt/koding/scripts/bootstrap-container build \
--host=**YOUR_IP**.xip.io \ --host=**YOUR_IP**.nip.io \
``` ```
#### Enable Single Sign On #### Enable Single Sign On
...@@ -233,7 +233,7 @@ Once you restarted your Koding and logged in with your username and password ...@@ -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 you need to activate oauth authentication for your user. To do that
- Navigate to Dashboard on Koding from; - 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 - Scroll down to Integrations section
- Click on toggle to turn On integration in GitLab integration section - Click on toggle to turn On integration in GitLab integration section
......
...@@ -120,7 +120,7 @@ gitlabConfigStorageSize: 1Gi ...@@ -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). 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:** > **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 ## Installing GitLab using the Helm Chart
> **Note:** > **Note:**
......
...@@ -307,10 +307,10 @@ hostname** and use greater values for the volume sizes. If you don't provide a ...@@ -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. password for PostgreSQL, it will be created automatically.
>**Note:** >**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 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. 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. 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. ...@@ -347,7 +347,7 @@ Navigate back to the **Overview** and hopefully all pods will be up and running.
![GitLab running](img/gitlab-running.png) ![GitLab running](img/gitlab-running.png)
Congratulations! You can now navigate to your new shinny GitLab instance by 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 change the root user password. Login using `root` as username and providing the
password you just set, and start using GitLab! password you just set, and start using GitLab!
...@@ -521,4 +521,4 @@ PaaS and managing your applications with the ease of containers. ...@@ -521,4 +521,4 @@ PaaS and managing your applications with the ease of containers.
[autoscaling]: https://docs.openshift.org/latest/dev_guide/pod_autoscaling.html "Documentation - Autoscale" [autoscaling]: https://docs.openshift.org/latest/dev_guide/pod_autoscaling.html "Documentation - Autoscale"
[basic-cli]: https://docs.openshift.org/latest/cli_reference/basic_cli_operations.html "Documentation - Basic CLI operations" [basic-cli]: https://docs.openshift.org/latest/cli_reference/basic_cli_operations.html "Documentation - Basic CLI operations"
[openshift-docs]: https://docs.openshift.org "OpenShift documentation" [openshift-docs]: https://docs.openshift.org "OpenShift documentation"
[scc]: https://docs.openshift.org/latest/admin_guide/manage_scc.html "Documentation - Managing Security Context Constraints" [scc]: https://docs.openshift.org/latest/admin_guide/manage_scc.html "Documentation - Managing Security Context Constraints"
\ No newline at end of file
...@@ -135,9 +135,9 @@ and `1.2.3.4` is the IP address of your load balancer; generally NGINX ...@@ -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 ([see requirements](#requirements)). How to set up the DNS record is beyond
the scope of this document; you should check with your DNS provider. 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 [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`. `1.2.3.4.nip.io`.
Once set up, all requests will hit the load balancer, which in turn will route Once set up, all requests will hit the load balancer, which in turn will route
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment