Да сложим ли Nginx (и други) конфигурации във VCS?

[mitio]

Конфигурациите на Nginx от хост-машината, както и от някои от проектите в контейнерите, са доста сложни. Струва ми се добра идея да ги систематизираме в едно хранилище. Някои проекти си имат примерна Nginx конфигурация, но не е реалната, а и не всички проекти имат.

Освен Nginx конфигурации, има и други конфигурации, които не са съвсем тривиални и може би не е лоша идея да имаме и тях във VCS.

Алтернатива на това би било да ползваме нещо като Ansible/Chef.

Мнения?

[tochev]

Аз съм много да има VCS, но той не трябва да е public IMO, иначе си въобразявах че имате backup на /etc от koi, ама това явно е било моето оптимистично мислене :)

[antitoxic]

Ами практиката ми е да има една директория със sample файлове за всички deployment настройки. Единствена разлика на тези sample файлове с реалните им копия са на paths и разни secrets.

Пример: https://github.com/obshtestvo/obshtestvo.bg/tree/master/server

В момента в нея има:

1. съвсем истинските файлове използвани на production, само че .sample
2. vagrant командите за инсталация.
3. нужните настройки per-server за проекта (база данни, paths към binaries ...) под формата на .env файл, който разбира се може да не се ползва ако са зададени ENV променливи.
4. middleware скрипт (ако е нужен) за run-ването на проекта през http сървър (примерно за python - това е wsgi файл)
5. helper скриптове, като например скрипт който проверява дали даден процес върви на машината или не

Към такива директории може да се добавят и настройки за host-машината.

Като се замисля, такава директория може да се казва install.

@mitio ти искаш да имаме едно централно repo с server настройки за всички проекти?

[mitio]

Може би, не съм сигурен. По-скоро централно хранилище за специфични конкретни настройки на сървъра и на контейнерите, които не се държат във VCS.

Добра практика е във всеки проект да има .sample/.example файлове и инструкции как да си го подкара човек. Може би и Vagrant. Така, както е в този проект и в някои (не всички) други. Мисля, че това е необходимост, която е отделна от това, което имам предвид аз.

Струва ми се, че няма да е страшно и фатално да публикуваме всички конфигурационни файлове, като пропуснем само такива с ключове и пароли. Но всичко останало – портове, конфигурации, модули, пътища – да го имаме в хранилище. Не знам дали да е публично или не – това се чудя. Чудя се и как да се структурира. Малка част от нещата ги има вече тук.

Това е донякъде свързано и с #31.

[tochev]

Проблема с това да е public е че ще трябва да си играем ръчно да сменяме разни sensitive неща, т.е. един път ще трябва да го промениш на production-a, после в repo-то, после в repo-то на проекта, ... пък някой променил на production-a пък го няма в repo-то и т.н.

За private repo може да се ползва ssh директно на koi (или един gitolite) - не мисля че ще ни трябва gui.

Аз лично на повечето места май разчитам на backup-a за тези конфигурацията (т.е. правя пълен backup на /etc/) като оставям sample conf или в README за важните настройки на проекта (примерно специфични postgres параметри).

Иначе ако имахме повече машини щеше да е хубаво и да има ssh fingerprint-овете им някъде.

[tochev]

Забравих да кажа, че според мен е хубаво да има някакъв механизъм (може би IM или mail-based), с който да си съобщаваме за разни nice-to-know промени (примерно "разместих конфигурацията" или "Смених конвенцията за именуване в /etc/nginx/sites-available", "добавих guest X"), че иначе в issue-та в obshtestvo.bg проекта ми се струва че ще е "досаден" спам за останалите.