-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Да сложим ли Nginx (и други) конфигурации във VCS? #30
Comments
Аз съм много да има VCS, но той не трябва да е public IMO, иначе си въобразявах че имате backup на /etc от koi, ама това явно е било моето оптимистично мислене :) |
Ами практиката ми е да има една директория със sample файлове за всички deployment настройки. Единствена разлика на тези sample файлове с реалните им копия са на paths и разни secrets. Пример: В момента в нея има:
Към такива директории може да се добавят и настройки за host-машината. Като се замисля, такава директория може да се казва @mitio ти искаш да имаме едно централно repo с server настройки за всички проекти? |
Може би, не съм сигурен. По-скоро централно хранилище за специфични конкретни настройки на сървъра и на контейнерите, които не се държат във VCS. Добра практика е във всеки проект да има Струва ми се, че няма да е страшно и фатално да публикуваме всички конфигурационни файлове, като пропуснем само такива с ключове и пароли. Но всичко останало – портове, конфигурации, модули, пътища – да го имаме в хранилище. Не знам дали да е публично или не – това се чудя. Чудя се и как да се структурира. Малка част от нещата ги има вече тук. Това е донякъде свързано и с #31. |
Проблема с това да е 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-овете им някъде. |
Забравих да кажа, че според мен е хубаво да има някакъв механизъм (може би IM или mail-based), с който да си съобщаваме за разни nice-to-know промени (примерно "разместих конфигурацията" или "Смених конвенцията за именуване в /etc/nginx/sites-available", "добавих guest X"), че иначе в issue-та в obshtestvo.bg проекта ми се струва че ще е "досаден" спам за останалите. |
Конфигурациите на Nginx от хост-машината, както и от някои от проектите в контейнерите, са доста сложни. Струва ми се добра идея да ги систематизираме в едно хранилище. Някои проекти си имат примерна Nginx конфигурация, но не е реалната, а и не всички проекти имат.
Освен Nginx конфигурации, има и други конфигурации, които не са съвсем тривиални и може би не е лоша идея да имаме и тях във VCS.
Алтернатива на това би било да ползваме нещо като Ansible/Chef.
Мнения?
The text was updated successfully, but these errors were encountered: