Enabling Pages Service⌗

Adding Domain Resolution Records⌗

Resolve the * record of your domain to the corresponding IP address of the Gitlab server.

Georges:~ george$ dig *.example.com

; <<>> DiG 9.10.6 <<>> *.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25903
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;*.example.com.			IN	A

;; ANSWER SECTION:
*.example.com.		599	IN	A	192.168.2.88

;; Query time: 909 msec
;; SERVER: 192.168.5.1#53(192.168.5.1)
;; WHEN: Fri May 31 14:51:10 CST 2019
;; MSG SIZE  rcvd: 59

If you’re sure the resolution has been set up but the IP is still not the expected one, it might be caused by DNS caching.

Enable by Default When Running Container⌗

docker run --detach \
  --hostname example.com \
  --env GITLAB_OMNIBUS_CONFIG="external_url 'https://example.com'; gitlab_rails['lfs_enabled'] = true; nginx['redirect_http_to_https'] = true; pages_external_url 'https://example.com'; gitlab_pages['enable'] = true; gitlab_pages['inplace_chroot'] = true; pages_nginx['enable'] = true; nginx['ssl_certificate'] = '/etc/gitlab/ssl/fullchain.cer'; nginx['ssl_certificate_key'] = '/etc/gitlab/ssl/example.com.key'; pages_nginx['ssl_certificate'] = '/etc/gitlab/ssl/fullchain.cer'; pages_nginx['ssl_certificate_key'] = '/etc/gitlab/ssl/example.com.key';" \
  --publish 443:443 --publish 80:80 --publish 22:22 \
  --name gitlab \
  --restart always \
  --volume /srv/gitlab/config:/etc/gitlab \
  --volume /srv/gitlab/logs:/var/log/gitlab \
  --volume /srv/gitlab/data:/var/opt/gitlab \
  gitlab/gitlab-ce:latest

gitlab_pages[’enable’] = true; Enable Pages service
pages_external_url ‘https://example.com’; Replace with your own domain
gitlab_pages[‘inplace_chroot’] = true; This must be enabled when running Gitlab as a Docker container
pages_nginx[’enable’] = true; Enable the vhost for Pages service, which will generate a separate Nginx configuration file named gitlab-pages.conf in the /var/opt/gitlab/nginx/conf directory.
nginx[‘ssl_certificate’] = ‘/etc/gitlab/ssl/fullchain.cer’;
nginx[‘ssl_certificate_key’] = ‘/etc/gitlab/ssl/example.com.key’;
pages_nginx[‘ssl_certificate’] = ‘/etc/gitlab/ssl/fullchain.cer’;
pages_nginx[‘ssl_certificate_key’] = ‘/etc/gitlab/ssl/example.com.key’;

The last four configurations are used to specify the HTTPS certificate paths for both the Gitlab main site and Pages service.

As you can see, we’ve added Gitlab’s runtime parameters to the container startup command environment, eliminating the need for additional configuration. If you’ve already run the container, you only need to modify the configuration items mentioned above in the gitlab.rb configuration file, and then execute the following command:

# Enter the Gitlab container
docker exec -it gitlab /bin/bash
# Execute the command to generate service configuration files
gitlab-ctl reconfigure

If you want to enable HTTPS for the Pages service domain, you must use a wildcard certificate. For information on how to obtain one, please refer to my blog post “Applying for a Wildcard Certificate for Your Domain”

Verifying Results⌗

Creating a Project⌗

Visit the Create Project page, then click Create from template and click the Use template button for the Pages/Plain HTML item in the list to create a project.

Create project from template

Enable Runner for the Project⌗

Visit the project’s Settings > CI/CD, expand the Runners configuration section, and check if there are available Runners. If there are, note down the Tag; if not, refer to my article “DevOps: Registering Gitlab Runner” for registration.

Modify .gitlab-ci.yml⌗

Modify the project’s CI/CD configuration file, add the tags configuration item, and fill in the Runner’s Tag you noted earlier. This way, when you commit, the automatic deployment operation will be executed on the Runner with the same Tag.

image: alpine:latest

pages:
  stage: deploy
  script:
  - echo 'Nothing to do...'
  artifacts:
    paths:
    - public
  only:
  - master
  tags:
  - pages

If your Runner is Docker or another container type, you need to define the image option; if it’s shell or ssh, you can ignore it. Also worth mentioning is the artifacts option, which is used to define the configuration for uploading deployment results to Gitlab, such as binary files generated after compiling Golang projects. More detailed usage instructions will be provided in future articles.

After the task is completed, you can visit the project’s Settings > Pages page to view the URL generated by the Pages service.

View the project’s Pages service configuration

About Access Control⌗

If you want your Pages to be visible only to authorized people, you can refer to the official documentation for configuration.

I hope this is helpful, Happy hacking…

Enabling Gitlab Pages Service