Hoe gebruik je pip, virtualenv en Fabric om de implementatie af te handelen?

Wat zijn je instellingen, je trucs en vooral je workflow?

Deze tools zijn geweldig, maar er zijn nog steeds geen best practices voor het gebruik ervan, dus ik weet niet wat de meest efficiënte manier is om ze te gebruiken.

• Gebruik je pip-bundels of altijd
  downloaden?
• Stel je Apache/Cherokee/MySQL handmatig in of doe je dat?
  heb je daar een script voor?
• Plaats je alles in virtualenven gebruik je --no-site-packages?
• Gebruik je één virtualenv voor meerdere projecten?
• Waarvoor gebruikt u Stofvoor (welk deel van
  uw implementatie doe je script)?
• Plaats je je Fabric-scripts op de client of de server?
• Hoe ga je om met migratie van databases en mediabestanden?
• Heeft u ooit een build-tool nodig zoals SCons?
• Wat zijn de stappen van uw implementatie? Hoe vaak voer je ze allemaal uit?
• enz.

Antwoord 1, autoriteit 100%

‘Best practices’ zijn erg contextafhankelijk, dus ik zal niet beweren dat mijn werkwijzen de beste zijn, alleen dat ze voor mij werken. Ik werk op voornamelijk kleine sites, dus geen implementaties met meerdere servers, CDN’s enz. Ik moet de implementatie van gedeelde hosting van Webfaction ondersteunen, omdat sommige klanten de goedkoopste hosting nodig hebben die ze kunnen vinden. Ik moet sites vaak meerdere keren in verschillende omgevingen implementeren, dus herhaalbare implementaties met scripts zijn van cruciaal belang.

• Ik gebruik geen pip-bundels, ik installeer vanaf een requirements.txt. Ik heb mijn eigen chishop-server met sdists van alles wat ik nodig heb, dus er zijn niet meerdere afzonderlijke punten van mislukking in het bouwproces. Ik gebruik ook PIP_DOWNLOAD_CACHE op mijn ontwikkelmachines om het opstarten van projectomgevingen te versnellen, aangezien de meeste vereisten van mijn projecten elkaar nogal overlappen.
• Ik heb Fabric-scripts die nginx + Apache/mod_wsgi automatisch kunnen instellen en configureren op een Ubuntu VPS, of de equivalent op Webfactionshared hosting en implementeer vervolgens het project.
• Ik gebruik geen –no-site-packages met virtualenv, omdat ik er de voorkeur aan geef langzaam bewegende gecompileerde pakketten (Python Imaging Library, psycopg2) op systeemniveau te installeren; te traag en lastig om in elke virtualenv te doen. Ik heb geen problemen gehad met vervuilde systeemsite-pakketten, omdat ik het over het algemeen niet vervuil. En in ieder geval kun je een andere versie van iets in de virtualenv installeren en dat heeft voorrang.
• Elk project heeft zijn eigen virtualenv. Ik heb wat bash-scripts (niet virtualenvwrapper, hoewel veel mensen dat gebruiken en er dol op zijn) die de implementatie van de virtualenv voor een bepaald project op een bekende locatie automatiseren en de vereisten van dat project erin installeren.
• Het hele implementatieproces, van een kale Ubuntu-server VPS of Webfaction shared hosting-account tot een draaiende website, wordt gescript met Fabric.
• Stofscripts maken deel uit van de bronstructuur van het project en ik voer ze uit vanaf een lokale ontwikkelingscheckout.
• Ik heb geen SCons nodig (voor zover ik weet).

Implementatie

Op dit moment is een nieuwe implementatie opgesplitst in de volgende stappen:

• fab staging bootstrap(serverconfiguratie en initiële code-implementatie)
• fab staging enable(schakel de Apache/nginx-configuratie voor deze site in)
• fab staging reload_server(herlaad Apache/nginx config).

Die kunnen natuurlijk worden gecombineerd in een enkele opdrachtregel fab staging bootstrap enable reload_server.

Zodra deze stappen zijn uitgevoerd, is het bijwerken van de implementatie met nieuwe code slechts fab staging deploy.

Als ik een update moet terugdraaien, fab staging rollback. Niets bijzonders in het terugdraaien; het zet de code gewoon terug naar de laatst geïmplementeerde versie en migreert de database naar de vorige staat (dit vereist wel het opnemen van enkele metadata over de migratiestatus van de DB na de implementatie, ik doe dat gewoon in een tekstbestand).

Voorbeelden

Ik heb de Fabric-scripts die in dit antwoord worden beschreven al een paar jaar niet meer gebruikt, dus ze worden helemaal niet onderhouden en ik wijs de verantwoordelijkheid voor hun kwaliteit af 🙂 Maar je kunt ze zien op https://bitbucket.org/carljm/django-project-template– in fabfile.pyin de repo root, en in de deploy/subdirectory.

Antwoord 2, autoriteit 11%

Ik gebruik fabric om mijn code te bouwen en te implementeren en ga ervan uit dat daar al een systeem voor is ingesteld. Ik denk dat een tool als puppetmeer geschikt is om de installatie van zaken als apache en mysql te automatiseren, hoewel ik moet het nog echt in mijn workflow opnemen.

Bovendien heb ik meestal een andere virtualenv per project. Ze zijn gemaakt op basis van een ‘basis’-installatie van python waar je – zoals Carl opmerkte – een aantal wereldwijde python-bibliotheken kunt achterlaten.

Dus in termen van workflow zou dat zijn:

1. pop om vereiste services te installeren (webserver, database, ssh-server, …)
2. pop om vereiste gebruikers en basismappen in te stellen
3. fabric om virtualenv voor de applicatie te maken
4. fabric to pip install van requirements.txt
5. fabric om uw app te implementeren
6. fabric om configuratiebestanden te implementeren (webserver, …)