kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Use nip.io instead of xip.io

Browse source 
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
This commit is contained in:
Dmitriy Zaporozhets 2018-06-12 10:39:16 +03:00
parent 26c9d71666
commit 8070632b74
No known key found for this signature in database
GPG key ID: 627C5F589F467F17
4 changed files with 16 additions and 16 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
doc/administration/integration/koding.md
View file

@ -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

2
doc/install/kubernetes/gitlab_omnibus.md
View file

@ -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:**

6
doc/install/openshift_and_gitlab/index.md
View file

@ -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!

4
doc/topics/autodevops/index.md
View file

@ -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