Waarom verplaatsen ontwikkelaars CI-runners, registers en testdatabases van hun laptops naar elders?

Teams verplaatsen deze diensten van laptops om builds reproduceerbaar te maken, gedeelde afhankelijkheden bereikbaar te houden, testgegevens wegwerpbaar te maken en de oplevering onafhankelijk te maken van de accu of werkomgeving van één ontwikkelaar.

De server is geen grotere laptop. Een CI-runner voert niet-vertrouwde projectinstructies uit, een register slaat artefacten uit de softwaretoeleveringsketen op en een testdatabase bevat veranderlijke gegevens. Ze combineren kan voor een klein team efficiënt zijn, maar alleen als identiteiten, netwerken, opslag, geheimen, quota en herstel per rol zijn gescheiden.

Begin bij het probleem in de workflow

CI die op een laptop draait, valt uit wanneer de eigenaar slaapt, reist, van netwerk wisselt, de klep dichtdoet of de lokale CPU en het geheugen nodig heeft. Een lokaal register verdwijnt zodra die computer uitvalt, terwijl een testdatabase steeds meer gegevens bevat die maar één ontwikkelaar begrijpt.

Continuous integration is afhankelijk van frequente, geautomatiseerde controles waarvan iedereen de resultaten kan zien. De praktijken voor continuous integration van Martin Fowler leggen de nadruk op automatisch zelftestende builds en zichtbare resultaten - eigenschappen die lastig te garanderen zijn met een laptop die slechts af en toe beschikbaar is.

Verplaats een rol pas nadat je hebt vastgesteld welk probleem daarmee wordt opgelost: wachtrijvertraging, omgevingsverschillen, image-distributie, gedeelde integratiestatus of capaciteitsproblemen op de laptop.

Scheid de vertrouwensgrens van de runner

Behandel CI-taken als code-uitvoering. Gebruik waar praktisch tijdelijke containers of virtuele machines, koppel de Docker-socket van de host niet aan onbetrouwbare taken en ken per repository of pipeline beperkt toegankelijke inloggegevens toe.

Stel quota in voor de buildwerkruimte en caches. Een mislukte taak mag het rootbestandssysteem van de server niet vullen en mag geen registergegevens lezen die niets met het project te maken hebben.

Definieer runnerlabels op basis van vertrouwen en mogelijkheden. Stuur geen code uit een pull request van een onbekende bijdrager naar een runner die toegang heeft tot productiegeheimen of het thuisnetwerk.

Maak van het register een duurzame distributierol

Sla registergegevens en configuratie op permanente opslag op met authenticatie, TLS op onbetrouwbare verbindingen, bewaartermijnen en perioden voor garbagecollection. Scheid onveranderlijke releasetags van tijdelijke branch-images.

Maak back-ups van de configuratie, metadata en alle artefacten die niet opnieuw kunnen worden opgebouwd. Als images reproduceerbaar zijn vanuit de broncode, documenteer dan de tijd die het opnieuw opbouwen kost en bewaar de broncode, builddefinities en externe afhankelijkheden in plaats van een back-up te maken van elke cachelaag.

Houd de capaciteit in de gaten voordat je opruimt. Garbagecollection van de registry kan veel I/O vergen en, afhankelijk van de implementatie, een onderhoudsmodus vereisen.

Featured

ZimaCube 2 persoonlijke cloud-home-NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Houd testdatabases wegwerpbaar maar representatief

Geef elke pipeline of branch een geïsoleerde databasenaam, schema, container of VM. Vul deze vanuit versiebeheerde fixtures of een opgeschoonde dataset, voer migraties automatisch uit en verwijder deze na afloop van de bewaartermijn.

Kopieer nooit productgeheimen of onbewerkte persoonsgegevens naar de testomgeving. Beperk het netwerkbereik zodat een gehackte taak niet vanuit de testdatabase kan doordringen tot niet-gerelateerde services.

Bewaar alleen de logs en artefacten die nodig zijn om mislukte tests te diagnosticeren. Langlevende, ondoorzichtige databases brengen het laptopprobleem terug, maar dan op een grotere machine.

Bouw de servertopologie voor kleine teams

Gebruik aparte serviceaccounts, containernetwerken, volumes, quota's en back-upregels voor de rollen van runner, registry en database. Deze gids voor NAS- en Dockerplatformen helpt bepalen of containers of virtuele machines voor de isolatie moeten zorgen.

Plaats de beheerinterface op een afgeschermd netwerk. Stel de registry en CI-interface alleen beschikbaar aan het team of via een geverifieerde toegangslaag. Leg voor elke service updates, eigenaarschap en terugdraaien vast.

Test het opnieuw aanmaken van een runner, het herstellen of opnieuw opbouwen van de registry, het opnieuw vullen van de database, een situatie met een volle schijf en het opnieuw opstarten van de server. Ontwikkelaars moeten lokaal kunnen blijven werken terwijl de gedeelde services worden hersteld.

Laatste configuratiecontrole

De overstap is geslaagd wanneer builds zonder een specifieke laptop draaien, omgevingen opnieuw worden aangemaakt op basis van versiebeheerde definities, registryartefacten een bewaartermijn en herstelplan hebben, testdatabases geïsoleerd en wegwerpbaar zijn en geen enkele runner meer geheimen kan inzien dan voor zijn taak nodig is.