search

VNG-Realisatie / api-test-platform

6 stars 3 forks source link

As VNG I want to migrate the dedicated Maykin server for hosting the test platform to Haven #171

Closed HenriKorver closed 4 years ago

HenriKorver commented 5 years ago

such that VNG has full control over the hosting environment.

Toelichting: This user story is complementary to #170.

Oplossingsrichting:

Definition of ready

Definition of done algemeen

Definition of done specifiek voor deze user story

Acceptatiecriteria

Taken Taken worden apart uitgewerkt in issues.

alextreme commented 5 years ago

@kciredor @HenriKorver wilt dit zoals overlegd graag in gang zetten, hoe wil je dit aanvliegen?

Is het wenselijk om hierover eerst met jou en de ATP team te overleggen of heb je een stappenplan wat we kunnen volgen voor onboarding voor het draaiend krijgen van het ATP op Haven?

We kunnen op Haven api-test.nl installeren op een wijze vergelijkbaar als de ZGW APIs (in welk geval we Sergei hiervoor nodig zullen hebben gezien de benodigde K8s expertise), of we kunnen zoals je eerder aangaf (als er een VPS beschikbaar is op Haven) onze standaard Ansible playbook op de VPS uitvoeren.

kciredor commented 5 years ago

Ik zie de vps oplossing onveranderd als het backup plan. Het echte plan zou Haven moeten zijn in de vorm van Kubernetes.

Het betreft een enkele deployment, de ad-hoc deployments die opgespint worden draaien ergens anders, correct? In dat geval kun je op hetzelfde cluster als ZGW een namespace krijgen.

Sergei weet inderdaad hoe dat werkt. Ik kan met hem hetzelfde doen als met ZGW: credentials overdragen en naast hem gaan zitten, maar hij heeft mij verder weinig nodig heb ik al gezien toen :-)

alextreme commented 5 years ago

@HenriKorver het is aan jou om aan te geven wat je wilt.

VPS - dit is vergelijkbaar met onze huidige installaties en kunnen we zelfstandig inrichten na het aanleveren Kubernetes - dit is vergelijkbaar met ZGW, zal fors meer tijd vergen qua setup en we zullen hiervoor Sergei nodig hebben van het ZGW team (dus dit zou een impediment voor ZGW worden)

Persoonlijk zie ik het nut er niet van in qua overhead om het ATP op Kubernetes te draaien.

alextreme commented 5 years ago

@kciredor je aanname is trouwens correct, de ad-hoc deployments draaien nog op de GCP Kubernetes Engine, dit naar Haven migreren is stap 2

HenriKorver commented 5 years ago

@JanWillemKooi Kun je deze discussie agenderen voor a.s. donderdag?

JanWillemKooi commented 5 years ago

Jazeker

@JanWillemKooi Kun je deze discussie agenderen voor a.s. donderdag?

Doe ik.

kciredor commented 5 years ago

Van belang wat mij betreft is dat een VM vluchtig is. Kun je niet echt van op aan. Ook in AWS en GCP gaan die wel eens stuk, dat is niet OpenStack of Haven specifiek. Met deployment van ATP op een VM, heb je dus een single point of failure. VM down = ATP down.

In een Kubernetes deployment kun je bijvoorbeeld kiezen voor redundantie van 3 pods. Gaat er dan een pod stuk, wordt de load naar de andere 2 pods gestuurd terwijl er een nieuwe wordt naast gezet en je weer op 3 zit (self healing, geen downtime).

Ik begrijp dat Kubernetes meer tijd en energie kost. Zeker om het goed te doen. Die afweging is niet aan mij, maar het is wel van belang dat beide opties inhoudelijk helder zijn.

alextreme commented 5 years ago

Besproken met @HenriKorver

We gaan beide wegen onderzoeken. Binnen het ATP team zullen we de VM-installatie uitvoeren (aangezien dit het beste aansluit op onze huidige deployment), dan zitten we zo snel mogelijk op Haven met zo min mogelijk impact op de ontwikkeltijd voor het ATP. Hiervoor krijgen we graag 2 VM'en (productie en test/staging)

@joeribekker zal een tweede installatie van het ATP op een K8s namespace uitvoeren, dit zal buiten het ATP team om worden ingericht. Hiervoor krijgen we graag 3 namespaces (TAP).

kciredor commented 5 years ago

Prima, gaan we zo doen.

Wat voor type vm's? Cores, RAM, Disk size (bij benadering).

Zie ook: https://gitlab.com/commonground/haven/issues/14

alextreme commented 5 years ago

De huidige capaciteit zal in mijn ogen meer dan voldoende zijn:

Test/staging: Debian 10, 8GB RAM, 8 cores, 100GB disk (~10GB in gebruik voor ATP) Productie: Debian 10, 16GB RAM, 8 cores, 1TB disk (~8GB in gebruik voor ATP)

Hier zit flexibiliteit in, we hebben op deze servers een stuk meer draaien dan alleen ATP.

kciredor commented 5 years ago

Om mee te beginnen 2 debian vm's gemaakt met 4 cores, 8gb ram en 160gb ssd. Kunnen altijd op en neer schalen zonder dataverlies. Je kunt het gebruik even aankijken, bijvoorbeeld met top: blijven de load averages beneden de 4 (want 4 cores) en zit ram niet prop vol, dan zit je goed.

Wat ik nodig heb is jouw / jullie ssh public key(s) voor vm access. Vervolgens geef ik jullie de ip adressen. Wanneer kubernetes namespaces in beeld komen, moet ik secrets overhandigen. Heeft iemand van jullie bijvoorbeeld keybase?

Heb nu de security group ssh open access gegeven, is niet wenselijk. Kunnen jullie zelf een firewall installeren, ufw ofzo? Standaard alles dicht, tenzij je expliciet wilt openen. Dan kan ik van mijn kant de security group geheel open zetten. Kan ook de voor jullie de security groups aanpassen naar wens, maar dan ben je dus van mij afhankelijk voor changes.

alextreme commented 5 years ago

Top, de VM's zo zullen voldoende zijn.

Bij deze mijn pubkey. Keybase username: alexdelandgraaf

alex_ssh_pubkey.txt

Toegang wordt door ons tijdens de installatie automatisch dichtgezet (alleen SSH toegang vanaf specifieke IPs, non-root account+pubkey), inderdaad incl server-firewall met ufw.

Na de installatie zullen we even moeten afstemmen hoe we jou erbij kunnen laten komen, dan kun je kijken of het dicht genoeg voor je staat en kunnen we met Henri afstemmen hoe we omgaan met server-beheer.

kciredor commented 5 years ago

Inzake VM's:

Security group van OpenStack staat nu helemaal open, klaar voor jouw bootstrap met ufw om weer dicht te tikken.

Pubkey toegevoegd, ip's via Keybase app verstuurd in Chat.

Ik hoef er verder niet meer bij te kunnen, is bij deze van jullie. Mocht er een (hard) reboot nodig zijn bij onbereikbaarheid o.i.d., dan hoor ik het wel.

kciredor commented 5 years ago

Inzake Kubernetes:

kubectl get ns | grep atp atp Active 31s atp-acc Active 3s atp-test Active 6s

Credentials volgen via Keybase.

alextreme commented 5 years ago

@stevenbal vandaag in gang gezet, we zijn met het ATP over naar Haven. alice is de test/staging server, aleid is de productieserver. De omgevingen op rachel en melinda zijn uitgeschakeld.

Graag maandag het ATP dubbel-checken (api-test.nl en staging.api-test.nl) voor de zekerheid. E-mail lijkt nog niet aan te komen, maar dit kan nog met de DNS switch te maken hebben.

stevenbal commented 5 years ago

De emails van de scheduled tests doen het bij mij voor zowel staging als productie en consumer sessies werken ook op productie, alleen niet op staging (maar daar had ik al een aparte issue voor aangemaakt https://github.com/VNG-Realisatie/api-test-platform/issues/298)

alextreme commented 5 years ago

Dank, de demo API op demo.api-test.nl is inmiddels ook overgezet.

@HenriKorver wees vrij om te reviewen