BigW Consortium Gitlab
Skip to content
Projects
Groups
Snippets
Help
This project
Loading...
Sign in / Register
Toggle navigation
G
gitlab-ce
Project
Overview
Details
Activity
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Board
Labels
Milestones
Merge Requests
0
Merge Requests
0
Registry
Registry
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Commits
Issue Boards
Open sidebar
Forest Godfrey
gitlab-ce
Commits
dfc3e58a
Commit
dfc3e58a
authored
Feb 21, 2016
by
Achilleas Pipinellis
Committed by
James Edwards-Jones
Jan 31, 2017
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Add configuration scenarios
parent
acf7ae5e
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
34 additions
and
12 deletions
+34
-12
administration.md
doc/pages/administration.md
+34
-12
No files found.
doc/pages/administration.md
View file @
dfc3e58a
...
...
@@ -88,18 +88,40 @@ The `gitlab-pages` daemon is included in the Omnibus package.
## Configuration
There are a couple of things to consider before enabling GitLab pages in your
GitLab EE instance.
1.
You need to properly configure your DNS to point to the domain that pages
will be served
1.
Pages use a separate Nginx configuration file which needs to be explicitly
added in the server under which GitLab EE runs
1.
Optionally but recommended, you can add some
[
shared runners
](
../ci/runners/README.md
)
so that your users don't have to
bring their own.
Both of these settings are described in detail in the sections below.
There are multiple ways to set up GitLab Pages according to what URL scheme you
are willing to support. Below you will find all possible scenarios to choose
from.
### Configuration scenarios
Before proceeding you have to decide what Pages scenario you want to use.
Remember that in either scenario, you need:
1.
A separate domain
1.
A separate Nginx configuration file which needs to be explicitly added in
the server under which GitLab EE runs (Omnibus does that automatically)
1.
(Optional) A wildcard certificate for that domain if you decide to serve
pages under HTTPS
1.
(Optional but recommended)
[
Shared runners
](
../ci/runners/README.md
)
so that
your users don't have to bring their own.
The possible scenarios are depicted in the table below.
| URL scheme | Option | Wildcard certificate | Pages daemon | Custom domain with HTTP support | Custom domain with HTTPS support | Secondary IP |
| --- |:---:|:---:|:---:|:---:|:---:|:---:|:---:|
|
`http://page.gitlab.io`
| 1 | no | no | no | no | no |
|
`https://page.gitlab.io`
| 1 | yes | no | no | no | no |
|
`http://page.gitlab.io`
and
`http://page.com`
| 2 | no | yes | yes | no | yes |
|
`https://page.gitlab.io`
and
`https://page.com`
| 2 | yes | yes | yes/no | yes | yes |
As you see from the table above, each URL scheme comes with an option:
1.
Pages enabled, daemon is enabled and NGINX will proxy all requests to the
daemon. Pages daemon doesn't listen to the outside world.
1.
Pages enabled, daemon is enabled AND pages has external IP support enabled.
In that case, the pages daemon is running, NGINX still proxies requests to
the daemon but the daemon is also able to receive requests from the outside
world. Custom domains and TLS are supported.
### DNS configuration
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment