gitlab: Make a plan to base instance layout on gitlab-omnibus and to interconnect...
authorKirill Smelkov <kirr@nexedi.com>
Wed, 6 Jan 2016 18:34:27 +0000 (21:34 +0300)
committerKirill Smelkov <kirr@nexedi.com>
Thu, 7 Jan 2016 13:44:14 +0000 (16:44 +0300)
commite7c5c05aa34daa0730a5267038156feb81ec0f88
tree08c0477792bb1418cb764f855b0bd94be5816f82
parentab6d2f28ee56d4f84f5c9757db80e18622b737fa
gitlab: Make a plan to base instance layout on gitlab-omnibus and to interconnect all internal services via unix sockets

Upcoming changes will follow two points:

- we try to base our gitlab setup on how it is done in
  gitlab-omnibus[1] with the idea to ease tracking upstream changes to
  instance setup.

- we will interconnect all internal services via unix sockets only.

  The reason to do it is twofold:

    1. easier security: currently files on different slapos partitions
       are isolated from each other, but there is no "in-between-partitions"
       networking isolation - thus (potentially evil) programs can
       access internal services on other slapos partition.

       permissions to access unix sockets, on the other hand, are
       managed by filesystem-level permissions, and thus unix sockets in
       one partition will be, by default, isolated from programs on
       another partitions.

    2. It is well known that UNIX sockets are faster than TCP over
       loopback. For example for our std shuttles they have 2 times lower
       latency and ~ 2-3 times more throughput compared to TCP over loopback

    More details on 1 & 2 can be found e.g. here:

    https://lab.nexedi.com/nexedi/slapos/merge_requests/27
    https://gitlab.com/gitlab-org/gitlab-shell/merge_requests/30

/cc @kazuhiko, @jerome

[1] https://gitlab.com/gitlab-org/omnibus-gitlab
software/gitlab/instance-gitlab.cfg.in