Is it possible / how could I setup a web server and a gitlab server on a single system and have them share a domain name? Gitlab uses nginx, so could I just setup gitlab and then modify the nginx setting to add the webserver? I would like to have something like www.website.com would be the webserver and then www.website.com/gitlab would be the gitlab server.
Should be doable.
Another option could be host-based routing if you don’t want it to be website.com/gitlab, it could be gitlab.website.com
You can do it on one domain on nginx, proxying specific paths. I had problems with that in the past, some applications can’t be easily configured that way, for example they request resources from the wrong place, because they don’t know about the path given. It basically comes down to specifying a location in nginx and proxy_pass to Gitlab. Gitlab must be configured with it’s new path www.domain.com/gitlab (this varies, usually root path, or host is the name of such option), otherwise it will request resources from where they’re not. I’m guessing Gitlab doesn’t have a very special nginx config and it is a well supported thing, so this should work easily.
I’d prefer the alternative, which is subdomains with virtual hosts. If you can completely control your domain it’s possible to add a wildcard (like *.domain.com) record to be resolved as one certain server, or just two separate entries for what you need. This has a drawback of needing two (or a relatively expensive wildcard one) certificates. I guess that is why you want this solution, though you could get away with using LetsEncrypt certificates I think.
Using the linuxserver letsencrypt docker image, you can create a reverse proxy that allows https subdomains.
I wrote a tool to help with this. Just run the following:
git clone https://github.com/reavessm/MDS.git
cd MDS
make init # Search for gitlab and nginx, changing the appropriate settings
Following the prompts should set up the two services and a reverse proxy in front of them. Then you can go to gitlab.domain.com and nginx.domain.com. If you want your nginx to be your main domain.com, just run
make CMD=remove nginx # Does not delete mounted volumes, just container
mv nginx.d website.d
make -j website proxyReset
Then you’ll have gitlab.domain.com as gitlab and your nginx container will resolve to just domain.com
Its very doable. I have it setup that way. You can disable gitlabs integrated nginx and reverseproxy to the ‘gitlab-workhorse’ (yeah I think thats what its called), or was it unicorn 
. One of the two. lul
Can put the config in here later. Not at a pc right now.
You basically do what the nginx bundled with gitlab was gonna do in the first place.
That’s the nginx config I’m using. I’m not sure about the TLS version, probably could remove everything apart from 1.2 at this point.
The way I have it setup is gitlab.mydomain.com and mydomain.com. Rather than the /gitlab route. Though I didn’t put the mydomain.com part in the example I copied here. It’s probably obvious how to get there from this. You could even put it into the same file and just use a different server_name, but I’d recommend going with the way Ubuntu would set it up by default (otherwise set it up that way). It’s making 2 folders sites-enabled and sites-available with one config for every service you will be running in sites-available that you then are supposed to symlink to sites-enabled. That way you can easiely toggle sites on and off without touching any config files.
upstream gitlab-workhorse {
server unix:/var/opt/gitlab/gitlab-workhorse/socket;
}
server {
listen 80;
server_name gitlab.yourdomain.com;
return 301 https://gitlab.yourdomain.com$request_uri;
}
server {
listen 443;
server_name gitlab.yourdomain.com;
server_tokens off;
access_log /var/log/nginx/gitlab_https_access.log;
error_log /var/log/nginx/gitlab_https_error.log;
ssl on;
ssl_certificate /etc/letsencrypt/live/gitlab.yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/gitlab.yourdomain.com/privkey.pem;
# GitLab needs backwards compatible ciphers to retain compatibility with Java IDEs
ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 5m;
location / {
client_max_body_size 0;
gzip off;
proxy_read_timeout 300;
proxy_connect_timeout 300;
proxy_redirect off;
proxy_http_version 1.1;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Ssl on;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://gitlab-workhorse;
}
}
You can disable gitlabs nginx in /etc/gitlab/gitlab.rb nginx['enable'] = false
Then run gitlab-ctl reconfigure
An SSL cert you can get for free from letsencrypt. It’s fairly easy to do that.
The only thing you can’t access that way is gitlab pages. Since you’d need to do another reverse proxy for that and I did not set that up.
As you can see here pages is completely seperated from everything else.
Though I’ve never had the need to use pages. And otherwise this has been running flawless for a year now.
You probably could also set it up in a similar fashion so you either have gitlab.mydomain.com/pages or pages.mydomain.com.
Hey @Mr_Pyro
Let me know which route you decide to go. I’m interested. I caved and started running windows server in a VM to handle DNS. Reverse lookup might be necessary for some application services. I would set it up even if its not needed in case an update needs to refer to itself and the base URL doesn’t resolve correctly. Had that problem with Jira until I enabled reverse lookup.
I think the way I did it is pretty good. Since you have a much easier time getting automatic security updates than with docker. You can do it however you want. I dont dislike docker, but I like my public facing NGINX with no docker and if there is docker its gonna be likely behind that NGINX. Have not figured out how to actually have your docker container not be public when you bind ports to the ‘outside’ normally it goes threw every firewall. But digitalocean gives you the option to put a firewall on top of your entire droplet for no charge. So that is what I did.
I also dont know how good the dockerized gitlab is. Since Ive never used it. The normal omnibus install is pretty painless and updates work mostly fine with the occassional bug making it threw. I can neither say the docker variant is better or worse. I simply dont know.
One thing though. If you are getting ‘This site is not reachable’ a lot. I started with a 1gb ram droplet. Gitlab kinda needs 4gb RAM to function properly. At least thats what they recommend. And I still got those errors at 2GB a lot (like every commit). But you can try 3GB, that may work out fine. Didnt test. The initial requirements are just kinda high, though it does seem to scale fairly well beyond that. 4GB is fine for gitlab use including having a gitlab worker running on the same box for ci. If youre mostly using it for yourself. When you want to run a company with it, you might want to think about that a bit differently.
...
server {
listen 80;
allow 192.168.0.0/24; # Allow default lan
allow 172.17.0.0/16; # Allow default docker network
deny all; # Deny public access
server_name foo.domain.com;
location / {
proxy_pass http://localhost:<docker port>;
}
}
...
There’s some more info you can put in the location directive but the important part is the allow and deny.
FWIW, I am using containerized Gitlab and the only thing that doesn’t work is the web IDE. Everything else has been flawless.