Skip to content
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

Open
mitio opened this issue Sep 10, 2014 · 5 comments
Labels

Comments

@mitio
Copy link
Member

mitio commented Sep 10, 2014

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

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

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

Мнения?

@mitio mitio added the question label Sep 10, 2014
@tochev
Copy link

tochev commented Sep 11, 2014

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

@antitoxic
Copy link
Member

Ами практиката ми е да има една директория със 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
Copy link
Member Author

mitio commented Sep 11, 2014

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

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

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

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

@tochev
Copy link

tochev commented Sep 11, 2014

Проблема с това да е 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
Copy link

tochev commented Sep 11, 2014

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants