GitLab on FreeBSD

Drawing heavy inspiration from Matthias Fechner's work on the GitLab port and deployment instructions, I took the approach of deploying PosgtreSQL & Redis services into standalone Bastille jails for each, and GitLab & Nginx services into their own compound Bastille jail, copying configuration files into each as appropriate and rendering them at jail deployment time, plus utility scripts (e.g. post-install, post-upgrade, service status, backup, etc.) for each jail as well.

Everything communicates over a private network, and critical data directories are mounted into each jail as necessary, e.g. Gitlab's repository directory, backup directories, etc.

As a result, all deployment recipes and configurations are abstract and versioned in Git, and deployment, backups, and all other operations (such as log rotation) are automated. If anyone is interested in discussing this setup, feel free to hit me up!
 
My thought/take is if you're just a solo developer or just a small team then why go to all that trouble (all you're doing is adding to your maintenance work load)? All you technically need is: <a VCS> + ssh. #1 benefit is that you don't have to leave the terminal. #2 benefit is that one can switch VCS programs (from git to got for example) and not change server interaction workflow one iota (obviously the local side may change a bit if you go from git to svn or fossil for example).

Eliminating all that complexity and using just '<VCS> + ssh' eliminates: 1) dependencies 2) security 3) update times (e.g., "pkg update git-tiny") 4) general overhead things like "space" and other stuff.

...who wants to "system admin" when you can "just write code" instead?
 
What's wrong with git hooks?

...I even have a generic build system which I invoke with git hooks. My 'build system' "makes the project" and "creates a pkg" of it for "deployment/running" to/on other servers.
 
JohnK said:
My thought/take is if you're just a solo developer or just a small team then why go to all that trouble (all you're doing is adding to your maintenance work load)? All you technically need is: <a VCS> + ssh. #1 benefit is that you don't have to leave the terminal. #2 benefit is that one can switch VCS programs (from git to got for example) and not change server interaction workflow one iota (obviously the local side may change a bit if you go from git to svn or fossil for example).

Eliminating all that complexity and using just '<VCS> + ssh' eliminates: 1) dependencies 2) security 3) update times (e.g., "pkg update git-tiny") 4) general overhead things like "space" and other stuff.

...who wants to "system admin" when you can "just write code" instead?
Click to expand...
I can't count the number of deployment scripts and infrastructure I've created over my career, solving one specific problem here, another specific problem there, etc., etc. After not too long you realize that, time and time again, you're solving pretty much the same problems over and over again, even if with slight differences here and there, but almost always with quite a bit of fragility, actually, when those solutions that you're putting together, however good, are 100% homegrown (e.g. high bus factor, among others).

If I can reduce that with solid & well established CI/CD pipelines, I'm all for it, however much of a maintenance burden the required infrastructure might be (not much, actually, at least at my scale, once you're through with the initial assembly of said infrastructure, a process that I personally enjoy quite a bit, actually).
 
I think you should take your deployment script(s) and infrastructure written in Bastille to Ansible then (this is the basis of my point).

Here is a link to the basic infrastructure I have for my git server. I can deploy this without any "jail manager" and is not dependable on anything other than sh(1).
github.com

jcreate/example/git at main · JohnKaul/jcreate

Script to create a FreeBSD jail.conf style jail with setup script, mounts, copy-in abilities - JohnKaul/jcreate
github.com github.com

My actual git-server side scripts can be put inside a FreeBSD jail, *nix host, and/or on a MacBook laptop.
 
JohnK said:
I think you should take your deployment script(s) and infrastructure written in Bastille to Ansible then (this is the basis of my point).

Here is a link to the basic infrastructure I have for my git server. I can deploy this without any "jail manager" and is not dependable on anything other than sh(1).
github.com

jcreate/example/git at main · JohnKaul/jcreate

Script to create a FreeBSD jail.conf style jail with setup script, mounts, copy-in abilities - JohnKaul/jcreate
github.com github.com

My actual git-server side scripts can be put inside a FreeBSD jail, *nix host, and/or on a MacBook laptop.
Click to expand...
Ansible manages my jail hosts, Bastille the jails themselves, perfect match. Full automation and recording in VCS of infrastructure at every level, the right tool for the job in each of them.
 
I use neither of those and I have full automation and recording as well. What does that have to do with anything? I’m speaking about dependencies and overhead in general. You seem to be saying my setup is inferior.
 
JohnK said:
I use neither of those and I have full automation and recording as well. What does that have to do with anything? I’m speaking about dependencies and overhead in general. You seem to be saying my setup is inferior.
Click to expand...
Not a question of inferior but different. You do not but others may want a more standard solution. Just answering your "why go to all that trouble" question!
 
bakul said:
Not a question of inferior but different. You do not but others may want a more standard solution. Just answering your "why go to all that trouble" question!
Click to expand...
Exactly, I never ever said anything about anyone's solutions being inferior nor superior to others. You make your own choices and decide what solutions and tools are a good fit for your problems and environment and context, plain and simple. And, to that point, I simply described my choice of solutions and tools and how I arrived at the conclusions I reached, and why for me developing and maintaining them was not only not a burden but, actually, quite an enjoyable process. No more, no less.
 
*face-palm* ...Then why imply my solution(s) are not "up-to-par"? I'm a coder, I want to code. One day, I wanted to code up server-side VCS scripts. If you want to write playbooks or templates or whatever, what's that to me (I was only trying to point out to future readers of this thread, there are other--less dependency laden--options)?

Phrases (in seeming contradiction to 'my setup') like: "solid & well established" and "critical" are being used but I actually wonder if we may have different definitions (to me 'critical' and 'solid' mean things like: frictionless, deployable, (easily) auditable, (easy) maintenance, can be taken elsewhere, etc). But given the tones of responses, I doubt you'd even click a link or try an alternate so I should just assume you don't/will not understand the reasons for—the implications of—my setup and just move on.
 
You must log in or register to reply here.
Back
Top