An error occurred fetching the project authors.
- 28 Feb, 2016 1 commit
-
-
Kirill Smelkov authored
- relative URL support: comment out - we do not need it - gitlab is always located at /. - Nginx-http: restore our version for proxy_set_header - upstream turned to allowing users to configure this, see e.g. https://gitlab.com/gitlab-org/omnibus-gitlab/commit/e13d5e42 https://gitlab.com/gitlab-org/omnibus-gitlab/commit/a450585e but doing this way creates more complexity for gitlab SR, so I've restored our version which essentially does the same as default in omnibus-gitlab, and if we'll need to tune it - we can do directly in Nginx config. In other words slapos version does not allow users to tune nginx headers as instance parameter.
-
- 11 Feb, 2016 1 commit
-
-
Kirill Smelkov authored
- there is a section for gitlab pages, which we stub-out; - there is no longer a need to add /raw/... handling to nginx - as now nginx is just an SSL terminator for gitlab-workhorse, all URL handling is done inside gitlab-workhorse and is dealt with ok by our patches. - as now nginx does not directly connect to unicorn, there is no need to pass unicorn section to nginx's template. /cc @kazuhiko, @jerome
-
- 17 Jan, 2016 3 commits
-
-
Kirill Smelkov authored
In slapos we do a lot of automated software rebuild constantly, and thus there is constant flow of requests to get raw blobs from git service, e.g. like this https://lab.nexedi.com/nexedi/slapos/raw/master/software/wendelin/software.cfg A lot of requests comes to slapos.git repository and currently gitlab, out of the box, cannot keep up with that load. I've prepared patches to offload raw blobs download requests handling from unicorn (ruby) to gitlab-workhorse (go), and that resulted in ~ 17x speedup - e.g. previously our std shuttle can handle ~ 70 raw-blob requests/s and with my changes it is now ~ 1200 requests/s. The patches were sent upstream https://gitlab.com/gitlab-org/gitlab-workhorse/merge_requests/17 and we discussed with GitLab people and made a plan how to proceed incrementally. It will probably take some time for gitlab team to fully accept the approach though. For now we can use our gitlab-workhorse fork. The patches itself are: kirr/gitlab-workhorse@1b274d0d kirr/gitlab-workhorse@2beb8c95 /cc @kazuhiko, @jerome, @jm
-
Kirill Smelkov authored
Go through nginx configuration templates and convert them to jinja2 with slapos parameters (reminder: names and default values are imported from omnibus-gitlab 8.2.3+ce.0-0-g8eda093), except commenting out features we do not want to support (yet ?). As nginx is a reverse-proxy, i.e. it integrates all internal services and works as frontend to them, our gitlab service is now ready to listen and talk to the world over (standard to slapos services backend) IPv6. Nginx also acts as SSL termination point - for it to work by default we setup self-signed certificate for the backend, which can be manually changed to proper certificate if needed. Backend certificate is used if gitlab is configured to work in HTTPS mode (and frontend certificate is another story). NOTE ssl certificate is generated with just `openssl req ...` - yes, there is slapos.cookbook:certificate_authority.request but it requires to start whole service and has up to 60 seconds latency to generate certificate. And we only need to run 1 command to do that... The features disabled are: - http -> https redirection not needed for us at nginx level - the frontend can do the redirection and also gitlab speaks HSTS on https port so when we access https port via http protocol, it gets redirected to https. - kerberos - ssl_dhparam - providing custom nginx configuration via instance parameter /cc @kazuhiko, @jerome
-
Kirill Smelkov authored
Like with Rails configuration files, hook nginx configuration files into SR / instance build process; rename *.erb -> *.in and add our header. The templates are still not valid - a lot of erb code is left there - we'll slapos'ify it incrementally in the following patches. /cc @kazuhiko, @jerome
-