Onderstaand is een overzicht van activiteiten tijdens de migratie. Om duidelijk weer te geven wie verantwoordelijk is voor welke stap is het stappenplan opgedeeld in een kolom 'actie bij Team Hosting & Streaming' en een kolom waar de actie ligt bij de afdeling/omroep zelf. Mocht er iets onduidelijk zijn of iets in onderstaande tabel of pagina missen, laat het ons weten! We zijn ons ervan bewust dat het verandering van wie wat doet in een DevOps omgeving als dit containerplatform kan zorgen voor een overweldigend gevoel, je staat er echt niet alleen voor, we helpen graag!

Ondertussen is voor de meesten bekend dat gezien de bijna 'End Of Life' status van het appcluster, we als Team Hosting & Streaming ernaar streven 31 december 2021 het appcluster uit te zetten. Voor we dit daadwerkelijk kunnen doen, zullen we eerst alles wat er op het appcluster gehost wordt, verhuizen naar een andere plek.

Mocht je nu bij jezelf denken; 'uitfaseren.. WAT?? hier weet ik niks van! En mijn spul dan??' schiet dan even een ticket in via support.npohosting.nl, zodat we samen kunnen kijken wat er gemigreerd moet worden, en hoe we de migratie in gang zetten.

Op deze pagina vind je het globale stappenplan; wat er minimaal nodig gaat zijn om een website te migreren, wat jullie van ons kunnen verwachten, en welke kennis jullie nodig zullen hebben om de website/apps naar CHP4 te migreren.

Onderstaande items zijn uitgebreider uitgelegd in de rest van dit document. (vanaf punt 11 is optioneel)

1. 1. Ik heb iets extra's nodig wat hier niet op staat

Chroom niet om dan een ticket in te schieten! Deze pagina omvat de basis van wat je met CHP/OpenShift kunt, maar is zeker niet volledig dekkend!

1. 2. Ik heb een vraag over de diensten die jullie bieden

Stel je vraag in slack! Daar zitten we actief op, en helpen we je gauw verder

1. 3. Valt je vraag tussen punt 1 en 2 in en weet je niet of je een ticket moet inschieten of je ons in slack moet contacten, houd dan de volgende stelregel aan; schiet een ticket in wanneer je ons aan het werk wilt zetten, heb je alleen een vraag, dan voldoet slack.
2. 4. Om de lijntjes kort te houden tussen omroepen/afdelingen en dev partijen die nu allemaal aan't migreren zijn naar CHP hebben we een slack kanaal genaamd #openshift in de NPOHOSTING slack. Daar zitten wij ook in, maar is primair bedoelt om met collega's te sparren hoe zij zaken inregelen in CHP. We hoeven natuurlijk niet allemaal het wiel opnieuw uit te vinden, dus maak daar gebruik van! Mocht je nog in slack zitten, laat ons dat even weten, dan voegen we je toe (kan gewoon via slack ;) )

Om alle onderstaande items aan te vragen kun je een ticket in schieten via support.npohosting.nl. Dit omvat dan meteen de 'start van de migratie', dat wil zeggen; wij starten niet voor jullie er klaar voor zijn, dus om daadwerkelijk te starten ligt de bal bij jullie.

1. user - een account koppelen we aan een persoonlijk email adres (dus niet aan info@…). Als je team al projecten heeft draaien op CHP, vermeld dan onder welke groep zij dat doen, zodat we je meteen in die groep kunnen toevoegen.
2. groep - groepen gebruiken we om rechten toe te kennen aan projecten. We definiëren hierin 2 typen;

   1. Omroep/afdeling groep: dit is de eigenaar van het project, hierin dient ten minste 1 technisch persoon te zitten welke projecten aan kan maken. Mocht er bij de omroep/afdeling geen technisch persoon zitten die dat kan doen, laat dat dan aan ons weten, dan maken wij projecten voor je aan, eventueel tot zo'n persoon er wel is.
   2. Development groep: een groep voor developers(partij), deze groep heeft geen rechten om projecten aan te maken
3. project - om containers te kunnen draaien heb je een project nodig, dit project kun je met de juiste rechten zelf aanmaken, of aan ons vragen om aan te maken.

We starten alle projecten met de eigenaar, gevolgd door een streepje. De eigenaar is altijd de afdeling/omroep, niet een development partij. Vervolgens kunnen jullie kiezen wat voor naam het project krijgt, die komt op de plaats van <projectnaam> in het voorbeeld. Als laatste raden wij aan de naam te eindigen met het gedeelte van de OTAP straat die dit project behelst (bijv -test of -prod) Bijvoorbeeld: npo-<projectnaam>-test

Met een actief user account (na de eerste keer inloggen is je account actief) kun je nu zelf aan de slag op het CHP. Mocht je nog niet eerder gewerkt hebben met OpenShift, of met CHP, dan raden we je aan de CHP workshop te volgen, dit is een interactieve workshop die we voor je kunnen aanmaken, en waarmee je in je eigen tempo aan de slag kan gaan op CHP. De workshop duurt gemiddeld 2 a 3 uur, en leert je alle basis kennis die je nodig hebt om containers te kunnen draaien op CHP. Het workshop project kun je aanvragen via een ticket. Houdt er rekening mee dat je het workshop project 7 dagen kunt gebruiken, daarna wordt het automatisch opgeruimd. Let op: om je de rechten te geven op jouw eigen workshop project dien je 1x ingelogd te zijn in OpenShift, anders kunnen we de rechten niet toe kennen, houd daar bij aanvraag rekening mee.

Nu je een user, groep, project en de kennis hebt om aan de slag te gaan kun je beginnen met het opzetten van containers! Veel plezier! ;)

Er zijn meerdere bronnen om containerimages vandaan te halen, dit gaat om:

1. images die wij beheren, wij bieden momenteel images aan voor ruby, php, java nginx
2. images vanuit OpenShift
3. eigen images gebruiken (uit andere source) hierbij geldt:

   1. niet als root draaien
   2. geen support vanuit Team Hosting & Streaming

Databases kunnen zelf ingericht worden, en hoeven jullie niet bij ons aan te vragen wanneer je die in OpenShift zelf draait. Voor databases zijn er de volgende opties:

• In een pod in OpenShift
• Door ons in AWS
• Zelf in AWS regelen, hierbij moet vervolgens VPC peering worden opgezet

Als uitgangspunt adviseren wij om relationele databases en databases die niet een paar seconden offline kunnen, in AWS neer te zetten. De overige databases, inclusief alle (ook relationele) test/acceptatie databases kunnen cloud-native in OpenShift gedraaid worden.

Het idee van containers is dat de code om deze te configureren wordt opgeslagen in bijvoorbeeld een versioning systeem, en er een nieuwe container (opnieuw) wordt gemaakt wanneer nodig. Belangrijk om te weten is dat data als persistent storage opgeslagen dient te worden, want anders ben je deze kwijt na het restarten van een pod/container (zie kopje storage voor mogelijkheden). Containerconfiguratie wordt door developers zelf gemaakt en gebackuped/ veilig bewaard. Deze configuratie als de containers zelf worden niet door ons gebackuped.

We onderscheiden drie soorten content:

1. statische content voor intern gebruik
2. statische content voor extern gebruik
3. mediacontent (filmpjes ed.)

De keuze om statische content voor intern en extern gebruik op te delen is een financiële overweging, daar Scalia traffic voor een lager tarief aanbiedt dan AWS.

Alle storage voor intern gebruik kan in AWS opgeslagen worden in S3 buckets. Dit kan zowel in een eigen AWS instantie, als bij de AWS dienst die team Hosting & Streaming biedt. Als je gebruik wilt maken van S3 storage via Team Hosting & Streaming kun je dit vragen via een ticket.

Data in AWS S3 buckets kunnen gebackuped en gerestored worden. Meer over hoe dit gebeurd en wat er gebackuped wordt kun je hier lezen.

Wanneer statische content opgeslagen moet worden om naar de buitenwereld te sturen bieden wij een S3 storage dienst aan via Scalia. Mocht je gebruik willen maken van de S3 dienst die Scalia aanbiedt kun je dit aanvragen via een ticket.

Scalia maakt op dit moment geen gebruik van een backup functionaliteit op haar S3 dienst, maar biedt continuïteit en bescherming op haar storage dienst op basis van het volgende:

1. gegevens worden op meerdere locaties opgeslagen
2. op elke locatie worden gegevens drievoudig opgeslagen
3. een opslaglocatie wordt pas bevestigd wanneer minimaal twee kopieën bevestigd zijn opgeslagen
4. alle objecten worden na het opslaan op de primaire locatie direct gesynchroniseerd naar additionele locaties
5. synchronisatie gebeurd live, waardoor mutaties zoals bijwerken en verwijderen ook worden verwerkt op de secundaire locatie
6. versioning beschermd tegen onomkeerbare veranderingen / verwijderen van bestanden. Dit houdt in dat er meerdere versies van een object in een bucket worden bijgehouden, waardoor iedere change teruggezet kan worden naar een eerdere versie

Voor het opslaan van mediacontent wordt er gebruikt gemaakt van NEP. Dit is niet een dienst welke Team Hosting & Streaming biedt, om hier gebruik van te maken kun je het beste contact opnemen met de IT Servicedesk.