Django сървърна структура и конвенции

Мисля, че трябва да има повече информация за това какви видове сайтове внедрявате: ще има разлики въз основа на отношенията между сайтовете, както програмно, така и „законно“ (както при бизнес отношения):

• Наличието на системен акаунт за всеки „сайт“ може да бъде удобно, ако сайтовете са „собственост“ на различни хора – ако сте уеб дизайнер или програмист с няколко клиента, тогава може да се възползвате от разделянето.
• Ако вашите сайтове са свързани, т.е. форумен сайт, блогов сайт и т.н., може да се възползвате от единна система за внедряване (като нашата).
• за библиотеки, ако се хостват на реномирани източници (pypy, github и т.н.), вероятно е добре да ги оставите там и да ги разположите от тях - ако са на измамни хостове, които работят или не работят, ние вземаме копие и ги поставяме в папка /thirdparty в нашето git repo.

FABRIC Fabric е невероятен - ако е настроен и конфигуриран правилно за вас:

• Тук имаме политика, която означава, че никой никога не трябва да влиза в сървър (което е най-вече вярно - има случаи, в които искаме да погледнем необработения лог файл на nginx, но това е рядкост).
• Имаме конфигуриран плат, така че да има отделни функционални блокове (restart_nginx, restart_uwsgi и т.н.), но също
• „бизнес“ функции от по-високо ниво, които изпълняват всички малки блокове в правилния ред – за да актуализираме всичките си сървъри, просто въвеждаме „fab -i secretkey live deploy“ – live задава настройките за живите сървъри и разгръщането на ldeploys ( -i не е задължително, ако вашите .ssh ключове са настроени правилно)
• Имаме дори контролен флаг, който, ако се използва настройката на живо, ще попита „сигурни ли сте“, преди да извърши внедряването.

Оформление на нашия код

Така че нашият базов код изглежда малко по следния начин:

/         <-- folder containing readme file etc
/bin/     <-- folder containing nginx & uwsgi binaries (!)
/config/  <-- folder containing nginx config and pip list but also things like pep8 and pylint configs 
/fabric/  <-- folder containing fabric deployment
/logs/    <-- holding folder that nginx logs get written into (but not committed)
/src/     <-- actual source is in here!
/thirdparty/ <-- third party libs that we didn't trust the hosting of for pip

Вероятно противоречиво, защото зареждаме нашите двоични файлове в нашето репо, но това означава, че ако надстроя nginx на кутиите и искам да се върна назад, просто го правя чрез манипулиране на git. Знам какво работи срещу каква конструкция.

Как работи нашето внедряване:

Целият ни изходен код се хоства в частно хранилище на bitbucket (имаме много хранилища и няколко потребители, затова bitbucket е по-добър за нас от github). Имаме потребителски акаунт за „сървърите“ със собствен ssh ключ за bitbucket.

Deploy in fabric изпълнява следното на всеки сървър:

• irc бот обявява началото в irc канала
• git тегли
• pip deploy (от pip списък в нашето репо)
• syncdb
• мигрират на юг
• uwsgi рестартиране
• целина рестарт
• irc бот обявява завършване в irc канала
• започнете тестване на наличността
• обявете резултатите от тестването на наличността (и публикувайте отчета в частния pastebin)

„Тестът за наличност“ (мислете за единичен тест, но срещу сървър на живо) – удря всички уеб страници и API на „тестовия“ акаунт, за да се увери, че получава обратно нормални данни, без да засяга статистиката на живо.

Имаме и резервна git услуга, така че ако bitbucket не работи, той преминава към това грациозно и дори имаме интеграция на jenkins, която при ангажимент към клона „deploy“ кара внедряването да премине

Страшното

Тъй като използваме облачни изчисления и очакваме висока производителност, нашите кутии се появяват автоматично. Има изображение по подразбиране, което съдържа копие на git repo и т.н., но неизменно ще бъде остаряло, така че има стартиращ скрипт, който извършва внедряване в себе си, което означава, че новите кутии, добавени към клъстера, автоматично се актуализират.