Door Sander den Heijer

Product Lead

Devops bij Tweakers en gebruik van Usabilla - Development-iteratie #197

22-12-2020 • 14:00

26

In deze .plan geven we een inkijkje in devops bij Tweakers en ons gebruik van Usabilla. Daarnaast zijn er de releasenotes van de laatste twee iteraties.

Devops bij Tweakers

Juist als die ene collega met vakantie is, gaat de website down. Je weet dat hij het al opgelost zou hebben voordat iemand het zelfs maar doorhad. Nu moet je het zelf doen en kom je erachter dat de documentatie uit 2006 stamt. Bovendien staan er servernamen in waar je nog nooit van gehoord hebt, en is de IRC-bot al een paar jaar uitgefaseerd. Een busfactor van 1 is een groot risico voor een bedrijf. Toch gebeurt het maar al te vaak; die collega die zo goed is in iets, mag het project uitvoeren omdat hij de kennis toch al heeft.

Om deze vicieuze cirkel te doorbreken bij Tweakers, zijn er naast onze fulltime bofh twee developers parttime verantwoordelijk voor devops. Zo proberen we de kennis van onze bofh, die hij in twintig jaar heeft opgebouwd, over meer personen te verdelen.

Bij Tweakers gebruiken we onder meer Puppet, een tool om configuraties op servers te beheren. Normaal maak je een commit in de juiste repository, push je deze en is de configuratie binnen een half uur beschikbaar op de server. Als dit echter niet zo is en de bofh zegt dat je dit zelf mag uitzoeken? Dan leer je snel de pipeline en servers kennen, op de harde manier het verschil tussen een puppet agent en een puppet server, en krijg je een zeer voldaan gevoel als je de docker container hebt weten te starten op de juiste server.

Aanpassingen in onze loadbalancer doen? Een IP-adres aanpassen is prima te doen in een taal die je niet goed beheerst, maar als er een nieuw script toegevoegd moet worden? Dan is twaalf regels TrafficScript schrijven ineens een dagtaak. Zo kost het uitvoeren van deze taken, waarvoor onze bofh zijn hand niet zou omdraaien, veel tijd en zweet. Het resultaat? Dezelfde uitkomst, maar dan wel met een hogere busfactor.

Techupdate

Het techteam is verdergegaan met het beveiligingsplan. Naast verbeteringen aan het plan zelf, heeft 't team ook concrete dingen kunnen doen. Zo is Renovatebot geïmplementeerd om dependencies te beheren. Deze bot maakt merge requests aan voor elke dependency die out-of-date is. Hierdoor is het eenvoudiger om dependencies up-to-date te houden, ook voor de projecten waar niet dagelijks in gewerkt wordt. Verder is het dashboard dat de devops gebruikt om serverstatus te bekijken, uitgebreid en zijn er weer stappen gemaakt om het beheer van Hardware Info eenvoudiger te maken.

Usabilla op Tweakers

Sinds begin dit jaar maken we gebruik van Usabilla-surveys over de hele website. Deze surveys waren geïmplementeerd via Sitespect, onze A/B-testtool, maar nu zijn ze netjes geïntegreerd in de Tweakers-codebase. Om te voorkomen dat er op elke pagina een survey in je scherm verschijnt, hebben we twee extra checks ingebouwd. Je krijgt een survey maar één keer per zestig dagen te zien en daarnaast laten we de survey zien aan een beperkt percentage bezoekers.

Ook staat er onder nieuws- en reviewartikelen een feedbackwidget, waarmee je je mening over het artikel kunt geven en een toelichting kunt achterlaten. Deze widget verschijnt eenmaal per artikel.

Releasenotes

  • Bij reviews wordt nu weergegeven wanneer het product te leen was gegeven.

review-geleendproduct

  • Bug in DM-search is opgelost.
  • De call-to-action voor het plaatsen van een V&A-advertentie is aangepast.
  • De oude URL-structuur waarin naar de laatste pagina van een artikel werd verwezen, is opgeschoond.
  • Verwijzingen naar het magazine in het profiel zijn verwijderd.

Reacties (26)

26
25
23
1
0
1
Wijzig sortering
Je krijgt een survey maar één keer per zestig dagen te zien en daarnaast laten we de survey zien aan een beperkt percentage bezoekers.
Dus elke 60 dagen krijgen dezelfde set bezoekers een survey, of na 60 dagen wordt er een andere set bezoekers geselecteerd?

[Reactie gewijzigd door ge-flopt op 24 juli 2024 13:13]

de "dobbelsteen" wordt iedere 60 dagen opnieuw gegooit.

Bron: Ik heb de code geschreven :)
Zijn jullie een beetje tevreden met de usabilla SDK? Wij gebruiken ze op mobile en lopen toch best wel vaak aan tegen trage updates en nare bugs...
Dat vraag ik mij dus ook af. Ik neem aan dat de pool bezoekers die de survey krijgt ook willekeurig is, maar dat staat zo niet omschreven in het artikel.
We kijken of je in de afgelopen 60 dagen een survey voorgeschoteld hebt gekregen, als dit het geval is doen we niks. Als je er nog geen gezien hebt, dan maak je x% kans om er een te zien te krijgen. Als je binnen dat x% zit, krijg je er eentje te zien en zie je er voor minimaal 60 dagen geen meer.
Ik gok dat er automatisch gebruikers worden geselecteerd, dan wordt gekeken of zij in de afgelopen 60 dagen een survey hebben gekregen, zo ja, dan krijgen ze hem niet.
ipv puppet doen we heir salt; https://www.saltstack.com/ werkt mooi :P stiekem meer inhoudelijk artikel verwacht, proeft beetje als computer-totaal niveau :X
Wij werken ook met Saltstack, wel leuke software. Hoor ook veel mensen over Ansible praten omdat je daar geen agent voor nodig hebt.
SaltStack heeft ook een SSH agent, alleen als je de voordelen van Salt wilt hebben qua snelheid zou ik toch de agent aanraden.
Maar voor initieel provisionen van je servers(bijv. de agent installeren, kan je salt-ssh gebruiken)
https://docs.saltstack.com/en/getstarted/ssh/index.html
Ssh is ook gewoon een (generieke) agent imo
Ansible is leuk zolang je geen windows servers moet beheren. Je hebt python op target hosts nodig. Behalve op windows targets, daar is alles powershell. |:(
Wat zou je nog meer willen weten?

Het is lastig om een artikel te schrijven met diepgaande inhoud, omdat we niet alles kunnen uitleggen hoe 't werkt bij Tweakers in 1 artikel. Het is vooral bedoeld als een kijkje in de keuken :)
Puppet. Ik ben er van af gestapt. Als je niet heel goed op past wordt het een spaghetti monster. Puppet modules die je naar binnen trekt van Puppet Forge blijken steeds nou net niet die nieuwe feature te ondersteunen enzovoorts enzovoorts.

SaltStack is toch heel wat vriendelijker, sneller en duidelijker. Heel eenvoudig om tailor made states te bouwen die eenvoudig zijn te begrijpen ( ook voor toekomstige collegae ).

Loadbalancers configureren ? Ja, maar alleen om verkeer door te sluizen naar je fabio of traefik loadbalancers. Je applicaties registreer je in consul en fabio of traefik zal automagisch het verkeer naar de juiste services dirigeren. Scheelt weer een hoop configuratie werk! En doordat consul precies weet of een service healthy is, worden niet healthy services automatisch uit de loadbalancer getrokken en vice versa. Daarnaast kan bijvoorbeeld prometheus mooi gebruik maken van die health checks van consul, waardoor je dus ook direct een groot deel van je monitoring met minimale inspanning voorelkaar hebt!
Prometheus als datasource gebruiken in Grafana en pats boem! Coole set up met minimale inspanning!

Luiheid is de key! ;-)

En voor de rest? Kijk eens naar het portfolio van HashiCorp! Vault, Nomad, Boundary, Consul, stuk voor stuk prachtige tools om een betrouwbaar platform op te bouwen!

[Reactie gewijzigd door TheAnimaL op 24 juli 2024 13:13]

Leuke tips, dank je wel. Ik ga ze 'ns bestuderen.

Zelf zie ik liever minder dan meer services, dus een loadbalancer achter een loadbalancer plaatsen klinkt voor mij niet direct als een goed idee. Daarnaast maken we geen gebruik van een cloud, maar hebben eigen hardware dus het lijkt mij niet triviaal om consul in te zetten.

Verder hou ik zelf niet van "automagisch", want in mijn ogen betekent dat "Alles werkt, als je de documentatie volgt en exact dezelfde setup hebt als daar". Als je setup anders is, heb je heel wat te proberen met trial-and-error. Ik zeg niet dat het hier zo is, maar dat is helaas mijn ervaring.

Overigens houdt mij dat niet tegen om het eens te gaan bestuderen, en er misschien zelfs een beetje mee te gaan spelen om te zien of ik er toch nog iets van kan leren :)
Met services bedoel ik: http services, je web applicatie. Daarvan draai je er vanuit high availability oogpunt niet 1, maar meerdere.

Fabio en traefik zijn te vergelijken met haproxy, alleen krijgen Fabio of traefik hun configuratie niet van een config file, maar uit consul. Dus helemaal automagisch is het niet, je kunt alles prima beïnvloeden als jij dat wilt.

Daarnaast is consul op eigen hardware zeker een aanwinst! Al is het alleen maar om monitoring te vereenvoudigen!

Doe je onderzoek en je zult tot de conclusie komen dat dit tools zijn die ook ( of juist bij uitstek ) buiten een public cloud environment heel erg nuttig zijn!

Oh, en nog ff dit... Automagisch is gewoon automatisch, alleen zo ontzettend simpel en mooi dat je het magisch zou kunnen noemen. In dit geval precies te maken en boetseren hoe jij dat in jouw environment wilt! Niets engs dus ;-)

[Reactie gewijzigd door TheAnimaL op 24 juli 2024 13:13]

Het "probleem" met jouw setup (die wij overigens al deels gebruiken, maar dan voor onze testomgevingen die in kubernetes draaien met traefik als verdeler) is dat er nog best veel configuratie (om performance redenen) in onze loadbalancer zit. Overigens is dat geen normale config file, maar grotendeels stukken code die 'inline' in de loadbalancer zit in plaats van op de webservers.

Om maar een voorbeeld te geven, onze ipban functionaliteit zit in de loadbalancers. Dat gaat simpel op basis van een array waarbij elke loadbalancer alleen maar een key-lookup hoeft te doen om te zien of een ip is gebanned zodat die dan direct een response kan terugsturen zonder resources te verspillen op de webservers.

Voor onze productiesetup is een consul/traefik setup overkill omdat er bijna nooit iets veranderd omdat het geen micro-service architectuur is. Uiteraard heeft die loadbalancer gewoon ook (custom) healthchecks en service discovery en gooit hij timings in een influxdb welke we dan met grafana plotten.

Elke verandering naar een eenvoudigere/autmatische oplossing kost zodanig veel werk dat het 'goedkoper' is om de huidige oplossing te blijven gebruiken. Daarnaast speelt er ook een stukje performance mee, we willen de site graag snel houden, waarbij we snelheid prefereren over eenvoudiger beheer. En een oplossing waarbij je meerdere reverse proxies er tussen zet zal hoe dan ook voor minder performance zorgen.

[Reactie gewijzigd door Kees op 24 juli 2024 13:13]

.oisyn Moderator Devschuur® 22 december 2020 19:07
Ik vind die surveys onder artikelen dus echt strontirritant, met name op mobiel. Daarom heb ik een custom CSS snippet gemaakt om die weg te halen: custom css snippet: [FP] Weg met "geef je mening" onder artikelen
De gemiddelde ad en tracking blocker zorgt er volgens mij ook al voor dat de survey niet meer word getoond.
Bedankt voor de tip over Renovatebot. Zag dat soort automatische pull requests wel eens voorbijkomen op GitHub.
Maar eens onderzoeken of het ook een beetje makkelijk in Azure Devops toe te voegen is voor onze projecten.
Naast Renovatebot bestaat er ook nog Dependabot. Beide doen hetzelfde. Wij hebben uiteindelijk voor Renovatebot gekozen omdat ie makkelijk draait in een self-hosted GitLab omgeving.

Het voordeel nu al is dat we al een paar merge requests ("pull requests" bij github) hebben gekregen voor dependencies die we eigenlijk niet meer gebruiken. We hebben nog een achterstand weg te werken qua mr's ("pr's"), maar doordat we het maximum aantal mr's limiteren worden we er niet door overspoeld. Verder kan Renovatebot heel uitgebreid worden geconfigureerd, zodat je de branch-naam kunt bepalen en bepaalde packages aan bepaalde devvers kan assignen. Zo assignen we alle npm-packages aan het front-end team, en een package die weer impact heeft op de pipeline aan het devOps team.
Bij het releasenotes plaatje zit het is het blauwe driehoekje naar boven niet helemaal goed gepositioneerd :+
Om te voorkomen dat er op elke pagina een survey in je scherm verschijnt, hebben we twee extra checks ingebouwd. Je krijgt een survey maar één keer per zestig dagen te zien en daarnaast laten we de survey zien aan een beperkt percentage bezoekers.
Survey ingevuld en een week later alsnog een mailtje krijgen om een survey in te vullen hoeft toch ook niet?

Titel was: Tweakers: denk mee over onze online events.
De call-to-action voor het plaatsen van een V&A-advertentie is aangepast.
Irritant dat vraag en aanbod linkjes nu weg zijn boven in bij V&A nu kan niet met 1 klik vraag zien :/ . Nu zijn er 2 knoppen die vroeger in 1 formulier (dus via 1 knop te bereiken) was. (Op de mobiel, op de pc zijn die linkjes er nog wel gelukkig)

Met een omweg weer een filter aangemaakt voor alle vraag ads te zien.
https://tweakers.net/aanbod/zoeken/?vat=v

[Reactie gewijzigd door RobbyTown op 24 juli 2024 13:13]

Als dit echter niet zo is en de bofh zegt dat je dit zelf mag uitzoeken? Dan leer je snel de pipeline en servers kennen, op de harde manier het verschil tussen een puppet agent en een puppet server, en krijg je een zeer voldaan gevoel als je de docker container hebt weten te starten op de juiste server.
Goed bezig :-)
Ik heb de survey meerdere keren binnen de 60 dagen gekregen. Dit lijkt te komen door de vele devices en browsers die ik gebruikt. Alle keren was ik wel gewoon ingelogd. Echt een beetje irritant.

Op dit item kan niet meer gereageerd worden.