31

Hello I have installed Gitlab using this
https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.md#installation

Now I want to use nginx to serve another content other than gitlab application how can I do this

  • Where are the config files that I need to modify
  • How can I point a directory like /var/www so that nginx knows that is the root for another app.

Update(forgot to mention I'm running this under Red Hat 6.5, Debian/Ubuntu solution welcome)

jangorecki
  • 16,384
  • 4
  • 79
  • 160
yokodev
  • 1,266
  • 2
  • 14
  • 28

6 Answers6

7

Here I am using

- gitlab.example.com to serve gitlab.example.com over https.
- example.com over http to serve another content other than gitlab application.

Gitlab installed from deb package is using chef to provision ngnix, so you have to modify chef recipies and add new vhost template into chef cookbooks directory

You can find all chef cookbooks here: /opt/gitlab/embedded/cookbooks/gitlab/

open /opt/gitlab/embedded/cookbooks/gitlab/recipes/nginx.rb

change:

nginx_vars = node['gitlab']['nginx'].to_hash.merge({
  :gitlab_http_config => File.join(nginx_etc_dir, "gitlab-http.conf"),
})

to:

nginx_vars = node['gitlab']['nginx'].to_hash.merge({
  :gitlab_http_config => File.join(nginx_etc_dir, "gitlab-http.conf"),
  :examplecom_http_config => File.join(nginx_etc_dir, "examplecom-http.conf"),
})

add this to the same file:

template nginx_vars[:examplecom_http_config] do
  source "nginx-examplecom-http.conf.erb"
  owner "root"
  group "root"
  mode "0644"
  variables(nginx_vars.merge(
    {
      :fqdn => "example.com",
      :port => 80,
    }
  ))
  notifies :restart, 'service[nginx]' if OmnibusHelper.should_notify?("nginx")
end

then in template directory(/opt/gitlab/embedded/cookbooks/gitlab/templates/default), create nginx vhost template file( nginx-examplecom-http.conf.erb) and add this there:

server {
  listen <%= @listen_address %>:<%= @port %>;
  server_name <%= @fqdn %>;
  root /var/www/example.com;

  access_log  <%= @log_directory %>/examplecom_access.log;
  error_log   <%= @log_directory %>/examplecom_error.log;

  location /var/www/example.com {
    # serve static files from defined root folder;.
    # @gitlab is a named location for the upstream fallback, see below
    try_files $uri $uri/index.html $uri.html;
  }

  error_page 502 /502.html;
}

you have to set nginx['redirect_http_to_https'] = false in(/etc/gitlab/gitlab.rb):

external_url "https://gitlab.example.com"
gitlab_rails['gitlab_email_from'] = "info@example.com"
gitlab_rails['gitlab_support_email'] = "support@example.com"



nginx['redirect_http_to_https'] = false
nginx['ssl_certificate'] = "/etc/gitlab/ssl/ssl-unified.crt"
nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/ssl.key"


gitlab_rails['gitlab_default_projects_limit'] = 10

add include <%= @examplecom_http_config %>; into /opt/gitlab/embedded/cookbooks/gitlab/templates/default/nginx.conf.erb :

http {
  sendfile <%= @sendfile %>;
  tcp_nopush <%= @tcp_nopush %>;
  tcp_nodelay <%= @tcp_nodelay %>;

  keepalive_timeout <%= @keepalive_timeout %>;

  gzip <%= @gzip %>;
  gzip_http_version <%= @gzip_http_version %>;
  gzip_comp_level <%= @gzip_comp_level %>;
  gzip_proxied <%= @gzip_proxied %>;
  gzip_types <%= @gzip_types.join(' ') %>;

  include /opt/gitlab/embedded/conf/mime.types;

  include <%= @gitlab_http_config %>;
  include <%= @examplecom_http_config %>;
}

after all those changes run:

gitlab-ctl reconfigure
gitlab-ctl restart
vndr
  • 71
  • 3
  • That worked for me, thank you! However, I had to write a :listen paramater into the new template in /opt/gitlab/embedded/cookbooks/gitlab/recipes/nginx.rb. In my case I wrote :listen_address => "*", – Tomusm Sep 16 '14 at 20:09
  • I followed these instructions to the letter and double checked three times. Not only does my other http site not work but my gitlab page is not displaying anymore either. Has anything changed in the new versions that these instructions don't include? – sadmicrowave Apr 06 '15 at 13:14
7

vndr's above solution would work but on the https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/settings/nginx.md, it said:

Inserting custom settings into the NGINX config

If you need to add custom settings into the NGINX config, for example to include existing server blocks, you can use the following setting.

Example: include a directory to scan for additional config files nginx['custom_nginx_config'] = "include /etc/nginx/conf.d/*.conf;"

So let's check your /opt/gitlab/embedded/cookbooks/gitlab/templates/default/nginx.conf.erb to see if it contains: <%= @custom_nginx_config %> (it looks like the current gitlab-7.5.3_omnibus.5.2.1.ci-1.el6.x86_64.rpm doesn't include it)

If not, then just add it above the line include <%= @gitlab_http_config %>; like:

<%= @custom_nginx_config %>
include <%= @gitlab_http_config %>;

Then open the /etc/gitlab/gitlab.rb to add: nginx['custom_nginx_config'] = "include /etc/nginx/conf.d/*.conf;"

We can make it simply by just add: include /etc/nginx/conf.d/*.conf; instead <%= @custom_nginx_config %>

Then create normal nginx .conf files in /etc/nginx/conf.d/ and gitlab-ctl reconfigure

Luan Nguyen
  • 111
  • 2
  • 4
  • 1
    Just for reference: https://gitlab.com/sanderboom/omnibus-gitlab/commit/5ba0485a489549a0bb33531e027a206b1775b3c0 – Nehal J Wani Aug 06 '15 at 22:16
  • 1
    I did this and verified that the include statement winds up in the generated nginx conf file, but GitLab is still being served on the new domain. My server block is the nginx default with a simplified "listen *:80" line and a new server name. Any guess why this isn't working for me? – Trip Nov 01 '15 at 05:22
  • I gave up on trying to get this to work since every indication was that it *should* be working. I went ahead and installed a non-bundled nginx and set up a new server block for my gitlab instance on that after changing the appropriate values in /etc/gitlab/gitlab.rb – Trip Nov 02 '15 at 16:20
6

As I did not wanted to change the config for gitlab Nginx server nor installing/configuring another Nginx and to make sure gitlab would survive an major update, I came to below solution for the Gitlab Omnibus package.

also as per

Gitlab:Ningx =>Inserting custom settings into the NGINX config

edit the /etc/gitlab/gitlab.rb of your gitlab:

nano /etc/gitlab/gitlab.rb

and sroll to nginx['custom_nginx_config'] and modify as below make sure to uncomment

# Example: include a directory to scan for additional config files
nginx['custom_nginx_config'] = "include /etc/nginx/conf.d/*.conf;"

create the new config dir:

mkdir -p /etc/nginx/conf.d/
nano /etc/nginx/conf.d/new_app.conf

and add content to your new config: /etc/nginx/conf.d/new_app.conf

server {
  listen *:80;
  server_name new_app.mycompany.com;
  server_tokens off;
  access_log  /var/log/new_app_access.log;
  error_log   /var/log/new_app_error.log;

  root /var/www/html/new_app/;
  index index.html index.htm;

 }

and reconfigure gitlab to get the new settings inserted

gitlab-ctl reconfigure

to restart nginx after changing your config's or adding more config's in /etc/nginx/conf.d:

gitlab-ctl restart nginx

to check nginx error log:

tail -f /var/log/gitlab/nginx/error.log

and see https://stackoverflow.com/a/39695791/6821811 for redirecting to another application server.

Community
  • 1
  • 1
Danny
  • 1,603
  • 1
  • 15
  • 25
  • Glad to see that your configuration works :D I've been updating Gitlab every time there is a new patch/update, and has still survive, and is working just fine, plus the other sites. Every use case is different, for instance: Linux version : Redhat, Ubuntu, Nginx installations, previous Sites configurations( SSL considerations, root options, server names filters, etc), a tons of lots of options, So yeah, I humbly can't say that your conf is the safest one... – yokodev Sep 26 '16 at 15:28
  • @JAT2007, I removed the offending "safest". – Danny Sep 26 '16 at 17:49
3

Even through you really can do it, a better practise would be to use upper level separate nginx server to serve both gitlab's nginx and your other custom content. Gitlab's nginx may change it's configuration at any time and it can break your custom content. Also, separate nginx is completely yours for configuring.

Just install those two instances to different ports and proxy gitlab's nginx with upper one. Of cause, it will be an overhead, but completely insignificant one.

Jehy
  • 4,729
  • 1
  • 38
  • 55
  • Nginx can change its configuration too. More important is if they support that and it looks like they are https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/settings/nginx.md#inserting-custom-settings-into-the-nginx-config – jangorecki Aug 16 '16 at 22:25
  • Nginx would not make breaking changes to configuration. But any changes to gitlab configuration can be breaking to your custom web sites. And yes, of cause gitlab supports custom configuration - it costs them one `include` directive. One more disadvantage of using gitlab's nginx is obvious difference in nginx's versions with main repository. – Jehy Aug 17 '16 at 04:48
3

I have tried both approaches, and the one that worked for me was to put a clean NGINX on top of gitlab's built in one. its more easy/convenient in the long run.

Depending on your needs here are some crucial things that have to be in place first:

  • DNS settings of your network/router/etc. (else this will not work, since the configurations here are based on server names,)
  • My setup is trivial one server, multiple sites hosted in the same server IP, and I filter by naming the apps thru NGINX name filter.

Here are the main steps to follow, keep in mind that depending on your needs this could imply more tweaking around, also this is a Ubuntu Server 14.04 .

  1. First deactivate the main Nginx (the one bundled with omnibus) edit /etc/gitlab/gitlab.rb

    nginx['enable'] = false ci_nginx['enable'] = false

  2. Now your free to install a clean instance of NGINX.
  3. Regarding the previous step: sometimes the installer doesn't create the sites-enabled/ and sites-available/ folders, create them, and make sure to include them in the /etc/nginx/nginx.conf file

    include /etc/nginx/sites-enabled/*.conf;

  4. In a general nginx workflow you include your site configurations under sites-available/ and then when your ready/happy you make a link to sites-enabled/ folder and restart nginx so the changes are effective
  5. Add your Gitlab configuration to Nginx site-available/ folder

here is my conf:

`upstream gitlab-workhorse {
  server unix:/var/opt/gitlab/gitlab-workhorse/socket;
}

## Normal HTTP host
server {
  ## Either remove "default_server" from the listen line below,
  ## or delete the /etc/nginx/sites-enabled/default file. This will cause gitlab
  ## to be served if you visit any address that your server responds to, eg.
  ## the ip address of the server (http://x.x.x.x/)n 0.0.0.0:80 default_server;
  #listen 0.0.0.0:80 default_server;
  listen 0.0.0.0:80 ;
#  listen [::]:80 default_server;
  server_name gitlab.mycompany.com; ## Replace this with something like gitlab.example.com
  server_tokens off; ## Don't show the nginx version number, a security best practice
  root /opt/gitlab/embedded/service/gitlab-rails/public;

  ## See app/controllers/application_controller.rb for headers set

  ## Individual nginx logs for this GitLab vhost
  access_log  /var/log/nginx/gitlab.access.log;
  error_log   /var/log/nginx/gitlab.error.log;

  location / { 
    client_max_body_size 0;
    gzip off;

    ## https://github.com/gitlabhq/gitlabhq/issues/694
    ## Some requests take more than 30 seconds.
    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-For     $proxy_add_x_forwarded_for;
    proxy_set_header    X-Forwarded-Proto   $scheme;

        proxy_pass http://gitlab-workhorse;
      }
    } 

you can find more detail of the configuration in here more options

  1. restart/reload nginx

    sudo service nginx restart

  2. restart gitlab omnibus and check your Gitlab configuration

    sudo gitlab-ctl reconfigure

    sudo gitlab-ctl tail (just to check if something is wrong in your gitlab configuration)

  3. Add extra (as many as you like) server configurations that you need in /etc/nginx/sites-available/ and eventually when happy/ready add the link to /etc/nginx/sites-enabled/
    here is another example of another app

    upstream app_server {
        server 127.0.0.1:9080 fail_timeout=0;
    }
    server {
        listen 80; 
        server_name jenkins.mycompany.com;    
        access_log            /var/log/nginx/jenkins.access.log;
        location / { 
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host $http_host;
            proxy_redirect off;
            if (!-f $request_filename) {
                proxy_pass http://app_server;
                break;
            }
    
        }   
    }
    
  4. remember to always restart/reload nginx so that you see your changes.

    sudo service nginx restart

  5. check the logs in case something is wrong /var/log/nginx/anysites*.log

  6. Please note that here we are using upstream with different ports and the names(They exist/are real/are registered in the domain of your company) are all pointing to the same IP address, meaning NIGNX will come and find the same IP address but it will not break because of the different ports in the upstreams this is really important

That's how my configuration is working right now I have not had any issues with Gitlab or any other apps.
So hopefully this will help anyone out there.

yokodev
  • 1,266
  • 2
  • 14
  • 28
2

Those "other content" are declared in NGiNX with "Server Blocks".

The GitLab one is in /etc/nginx/sites-available/gitlab (according to the documentation, and symlined in [/etc/nginx/sites-enabled][3]).
You can add other server blocks in it, similar to this one (you may have to choose a different port number), as illustrated in this process (updated here for Ubuntu 14.04)

server {
        listen   80; ## listen for ipv4; this line is default and implied
        #listen   [::]:80 default ipv6only=on; ## listen for ipv6

        root /var/www/example.com/public_html;
        index index.html index.htm;

        # Make site accessible from http://localhost/
        server_name example.com;
}

The root directive should reference the root folder of your webapp (/var/www or more likely a subfolder of /var/www).

That server block is quite separate from any GitLab config.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 1
    unfortunately since I've installed gitlab with Omnibus project the directory structure is quite different /opt/gitlab, /var/opt/gitlab, /etc/gitlab, /var/log/gitlab, so there is not such directory structure... – yokodev Jun 09 '14 at 14:29
  • @JAT2007 sure, you can adapt this config to any path you want. – VonC Jun 09 '14 at 15:40
  • 1
    I'm sure of that, the problem is tweaking the right file. I've search for a 'sites-available' && 'sites*' folder with no luck. I'm not sure if I should add some config to my gitlab.rb or something? – yokodev Jun 09 '14 at 20:01
  • @JAT2007 the file I mention is in /etc/nginx/sites-available/ (as mentioned in https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx-server-blocks-virtual-hosts-on-ubuntu-14-04-lts), so look for an nginx folder, and create underneath it a `sites-available/xxx` folder and file. – VonC Jun 09 '14 at 20:08
  • I've updated my post; Well there are 7 nginx folders and because of the omnibus setup everything is controlled by gitlab-ctl command so for instance there is gitlab-http.conf under /var/opt/gitlab/nginx/etc/ that has some conf similar to the one you mention but at the top of the page it states "...This file is managed by gitlab-ctl. Manual changes will be # erased! To change the contents below, edit /etc/gitlab/gitlab.rb ...." any ideas – yokodev Jun 10 '14 at 13:47
  • Do you have an NGiNX installed and running? that would give us the system path associated to NGiNX and should allow use to define 'sites-available' underneath. – VonC Jun 10 '14 at 14:07